네트워크 1편 - OSI 7계층, 병목을 찾는 지도
작성일: 2026년 3월 27일
지난 글에서 우리는 AWS 서버 하나의 DNS 설정 오류가 전 세계 3,500개 기업을 동시에 멈춰 세우는 장면을 봤다. DNS는 OSI 7계층 중 L7에 속한다. 그 장애는 L7에서 시작됐다.
이런 일은 반복된다. 2022년 6월 21일, Cloudflare의 L3 라우팅 설정 오류 하나가 전 세계 HTTP 요청의 50%를 차단했다. 서버가 과부하된 것도, 배포가 잘못된 것도 아니었다. 패킷이 경로를 잃고 네트워크 안을 맴돌았다. 이번엔 L3였다.
두 사건 모두 원인을 찾는 데 너무 오래 걸렸다. 어느 계층이 문제인지 몰랐기 때문이다.
OSI 7계층은 통신 교과서에 나오는 암기 항목이 아니다. 장애가 발생했을 때 어느 계층에서 터졌는지 짚어내는 진단 지도다.
왜 계층을 나눴는가
섹션 제목: “왜 계층을 나눴는가”진단 지도가 작동하려면 먼저 이 질문을 짚어야 한다. OSI는 왜 굳이 7개의 계층으로 나뉘어 있는가. 각 계층이 서로의 내부를 알면 더 효율적으로 동작할 수 있지 않을까.
1968년, 소프트웨어 엔지니어 멜빈 콘웨이는 이런 명제를 남겼다.
“시스템의 구조는 그것을 설계한 조직의 커뮤니케이션 구조를 닮는다.” — Conway’s Law
OSI는 이 원칙의 네트워크 버전이다. 각 계층은 아래위 계층과 약속된 인터페이스로만 소통한다. 내부 구현은 공개하지 않는다. L4는 L7이 HTTP를 쓰는지 gRPC를 쓰는지 알지 못한다. L3는 L4가 TCP인지 UDP인지 관여하지 않는다.
이 설계는 의도적 무지다. 그리고 그 무지가 두 가지 트레이드오프를 만든다.
- 변경의 자유: L7에서 HTTP/1.1을 HTTP/2로 바꿔도 L4 이하는 손댈 필요가 없다. 계층이 분리되어 있기 때문이다.
- 장애의 격리: L3에서 발생한 라우팅 오류는 L7 애플리케이션 로직과 무관하다. 문제가 한 계층 안에 머문다.
Cloudflare 장애를 분석할 때 “L3 문제”라고 바로 특정할 수 있었던 것은 이 구조 덕분이다. 계층이 나뉘어 있지 않았다면, 원인은 전체 스택 어딘가에 묻혀버렸을 것이다.
각 계층이 서로를 모르기로 선택했기 때문에, 우리는 어느 계층이 문제인지 알 수 있다.
계층마다 병목의 특성이 다르다
섹션 제목: “계층마다 병목의 특성이 다르다”골드랫의 제약이론(TOC)에 따르면, 시스템 전체의 처리량은 가장 취약한 지점 하나에 의해 결정된다. 네트워크도 마찬가지다. 단, 어느 계층이 막히느냐에 따라 병목의 원인과 해결 방식이 완전히 달라진다.
패킷은 송신 측에서 L7부터 L1까지 내려가며 각 계층의 헤더를 덧붙이고, 수신 측에서 L1부터 L7까지 올라오며 헤더를 벗겨낸다. 대용량 트래픽이 몰릴 때, 이 경로 어딘가에서 처리가 밀리기 시작한다. ‘어디서 밀리는지’가 문제의 핵심이다.
L4 — 속도를 얻기 위해 인식을 포기했다
L4는 패킷의 내용을 보지 않는다. IP 주소, 포트 번호, TCP인지 UDP인지. 그것만 확인하고 전달한다. 봉투 안을 뜯어보지 않는 택배 기사와 같다. 그래서 빠르다.
이 무지는 설계 선택이다. 내용을 모르는 대신 속도를 얻었다. 그런데 그 선택이 구조적 한계를 만든다. TCP는 통신을 시작할 때 반드시 연결을 맺는다. 연결 하나당 포트 하나가 소모된다. 사용 가능한 포트는 약 28,000개 수준이다. 동시 접속자가 이 수를 넘어서면 새로운 연결 요청은 그냥 거절된다.
L4의 병목은 포트 고갈, 즉 동시 연결 수의 한계다. 티켓팅 오픈이나 라이브 방송 시작처럼 수만 명이 동시에 접속하는 순간이 정확히 이 한계를 건드린다.
L7 — 인식을 얻기 위해 속도를 포기했다
L7은 패킷 안을 들여다본다. HTTP 헤더, URL 경로, 쿠키, 요청 본문. 내용을 읽고 해석해서 어디로 보낼지 판단한다. 그만큼 할 수 있는 게 많다.
이 지식이 비용이다. 파싱, 인증, 압축 해제, 비즈니스 로직이 모두 여기서 일어난다. 요청 한 건을 처리하는 데 걸리는 시간, 즉 Logic Latency가 L4보다 구조적으로 높다. 트래픽이 늘수록 이 비용이 쌓이면서 Saturation이 빠르게 올라간다.
L4는 모르는 대신 빠르고, L7은 아는 대신 느리다. 둘 다 틀린 설계가 아니다. 각자 다른 트레이드오프를 선택한 것이다.
전체 계층을 놓고 보면 이렇다.
Saturation 임계점 도달 속도 L7 [████████████░░] Logic Latency 급등 ← 가장 먼저 체감 L4 [███████░░░░░░░] Concurrency 한계 L3 [█████░░░░░░░░░] 라우팅 오버헤드 L1 [███░░░░░░░░░░░] Throughput 포화 ← 터지면 전부 끝L7이 가장 먼저 벽에 부딪힌다. L1이 터지면 아무것도 통과하지 못한다. 결국 장애 대응의 첫 질문은 하나로 좁혀진다. 지금 어느 계층의 Saturation이 100%에 가까워지고 있는가.
L4와 L7 병목을 실제로 어떻게 해소하는지는 4편(로드 밸런서)에서 다룬다.
정리하며
섹션 제목: “정리하며”OSI 7계층은 프로토콜 분류표가 아니다. 각 계층은 고유한 병목 특성을 가진 독립적인 처리 단계다. 그리고 그 계층이 나뉜 이유 자체가 트레이드오프의 결과다. 인식을 포기하고 속도를 얻거나. 속도를 포기하고 인식을 얻거나. Saturation이 어느 계층에서 먼저 100%에 닿는지가 시스템의 제약 지점을 결정하고, 계층 간 인터페이스 덕분에 그 제약은 전체가 아닌 특정 계층의 문제로 격리된다.
장애가 났을 때 전체 스택을 뒤집는 엔지니어와, 먼저 어느 계층인지 묻는 엔지니어의 차이는 여기서 나온다.
다음 편에서는 L4를 더 깊이 들여다본다. TCP가 데이터를 주고받기 전에 반드시 거치는 3-way handshake, 그 짧은 과정에 숨겨진 비용이 대용량 트래픽 앞에서 어떤 의미를 갖는지 알아본다.