네트워크 용어에는 계층 번호가 붙어 다닌다. L2 스위치, L3 라우팅, L4 로드밸런서, L7 프록시. 나도 이 용어들을 일상적으로 쓰면서 정작 번호의 출처인 OSI 모델을 제대로 정리한 적이 없었다. 계층 이름을 외운 기억은 있는데, 그 암기가 실무 용어를 읽는 데 연결되지는 않은 상태였다.

정리하고 보니 OSI 모델의 쓰임은 암기보다 용어 읽기에 있었다. 실제 인터넷은 OSI 프로토콜로 동작하지 않지만, 장비와 소프트웨어의 이름에 붙는 L2, L3, L4, L7이라는 번호는 전부 이 모델에서 왔다.

OSI 모델과 TCP/IP 모델

OSI(Open Systems Interconnection, 개방형 시스템 상호 연결)는 ISO가 1984년 표준화한 참조 모델이다(ISO/IEC 7498). 통신에 필요한 기능을 7개 계층으로 나누고, 각 계층이 아래 계층의 서비스를 사용해 위 계층에 서비스를 제공하는 구조로 정의했다.

실제 인터넷을 지탱하는 것은 TCP/IP 스택이다. RFC 1122는 인터넷 호스트의 통신을 링크, 인터넷, 전송, 응용의 4계층으로 정의한다. 두 모델의 대응은 다음과 같다.

flowchart LR
    subgraph OSI["OSI 7계층"]
        direction TB
        O7["L7 응용 (Application)"]
        O6["L6 표현 (Presentation)"]
        O5["L5 세션 (Session)"]
        O4["L4 전송 (Transport)"]
        O3["L3 네트워크 (Network)"]
        O2["L2 데이터 링크 (Data Link)"]
        O1["L1 물리 (Physical)"]
        O7 --- O6 --- O5 --- O4 --- O3 --- O2 --- O1
    end
    subgraph TCPIP["TCP/IP 4계층"]
        direction TB
        T4["응용 (Application)"]
        T3["전송 (Transport)"]
        T2["인터넷 (Internet)"]
        T1["링크 (Link)"]
        T4 --- T3 --- T2 --- T1
    end
    O7 -.-> T4
    O6 -.-> T4
    O5 -.-> T4
    O4 -.-> T3
    O3 -.-> T2
    O2 -.-> T1
    O1 -.-> T1

    style O4 fill:#C8E6C9
    style O3 fill:#FFF3E0
    style T3 fill:#C8E6C9
    style T2 fill:#FFF3E0

프로토콜 표준 경쟁에서는 TCP/IP가 자리 잡았고, OSI 프로토콜 스택 자체는 거의 쓰이지 않는다. 그런데 계층을 나누는 어휘로는 OSI 쪽이 살아남았다. 전송 계층 장비를 TCP/IP 기준으로 “L3 장비"라고 부르지 않고 OSI 기준으로 “L4 로드밸런서"라고 부른다. 다만 L1 물리 계층은 케이블과 신호의 영역이라, 소프트웨어 개발의 어휘로 등장하는 일이 드물다.

L2 스위치와 MAC 주소

데이터 링크 계층은 같은 네트워크 안에서 프레임(frame)을 전달한다. 이 계층의 주소가 MAC(Media Access Control) 주소다. 네트워크 인터페이스마다 부여되는 하드웨어 식별자로, 같은 네트워크 안에서만 유효하다.

L2 스위치가 이 계층의 대표 장비다. 프레임의 MAC 헤더를 확인하고, 어느 MAC 주소가 어느 포트에 연결되어 있는지 테이블로 학습해서 해당 포트로만 프레임을 전달한다. “L2"라는 수식어는 이 장비가 프레임의 MAC 헤더까지만 해석한다는 뜻이다. IP 주소는 확인하지 않는다.

백엔드 개발에서 L2를 직접 다루는 일은 드물지만, 같은 서브넷 안의 통신은 결국 MAC 주소 기반의 프레임 전달로 이뤄진다. IP 주소로 통신을 시작해도, 같은 네트워크 안에서는 ARP(Address Resolution Protocol)로 IP에 대응하는 MAC 주소를 알아낸 뒤 프레임을 전달한다.

L3 라우팅과 IP

네트워크 경계를 넘는 순간부터는 네트워크 계층의 일이다. 전달 단위는 패킷(packet), 주소는 IP 주소, 대표 동작은 라우팅이다. 라우터는 패킷의 IP 헤더를 확인하고 라우팅 테이블에 따라 다음 홉으로 패킷을 전달한다.

L3부터는 실무 어휘가 많아진다. 서브넷 분할, 라우팅 테이블, NAT(Network Address Translation, 네트워크 주소 변환) 게이트웨이가 모두 이 계층의 개념 위에서 동작한다. 클라우드의 VPC(Virtual Private Cloud)를 설계할 때 다루는 CIDR(Classless Inter-Domain Routing) 블록과 서브넷, 라우팅 테이블도 L3 어휘의 연장이다. “L3 스위치"라는 장비 이름도 있다. 스위치에 라우팅 기능이 결합된 장비인데, 이름의 번호가 “IP 헤더까지 해석한다"는 사실을 그대로 드러낸다.

L4 로드밸런서와 포트

IP가 호스트까지의 경로를 책임진다면, 그 호스트의 어느 프로세스에 전달할지는 전송 계층이 포트 번호로 구분한다. TCP와 UDP가 이 계층의 프로토콜이다.

L4 로드밸런서는 IP 주소와 포트까지만 확인하고 트래픽을 분배한다. 그 위에 실려 있는 데이터가 HTTP인지 gRPC인지는 해석하지 않는다. 그래서 분배가 연결(connection) 또는 플로우(flow) 단위로 이뤄지고, 오버헤드가 작으며, 애플리케이션 프로토콜과 무관하게 동작한다. AWS의 NLB(Network Load Balancer)가 이 계열이다.

L7 프록시와 HTTP

응용 계층이 다루는 것은 애플리케이션이 주고받는 데이터 자체다. HTTP, gRPC, DNS 같은 프로토콜이 여기에 속한다.

L7 프록시와 L7 로드밸런서는 요청 내용을 해석한다. HTTP 요청을 파싱해서 경로, 헤더, 메서드를 기준으로 라우팅하고, 요청 단위로 트래픽을 분배한다. nginx, HAProxy, Envoy가 이 계층에서 동작하고, AWS의 ALB(Application Load Balancer)도 같은 계열이다. 요청을 해석할 수 있으니 재시도, 타임아웃, 경로 기반 라우팅 같은 요청 수준의 제어가 가능해진다.

L4와 L7 중 무엇을 앞에 둘지는 워크로드가 결정한다.

L4가 적합한 경우:

  • TLS(Transport Layer Security)를 백엔드에서 종료해야 해서 중간 장비가 내용을 해석할 수 없을 때 (passthrough)
  • HTTP가 아닌 TCP/UDP 트래픽을 분배할 때
  • 해석 오버헤드를 줄이고 처리량을 우선할 때

L7이 적합한 경우:

  • 경로·헤더 기반 라우팅이 필요할 때 (하나의 진입점에서 여러 서비스로)
  • 연결이 아니라 요청 단위로 분배해야 할 때 (HTTP/2 멀티플렉싱 환경)
  • 재시도, 타임아웃 같은 요청 수준 제어를 진입점에서 처리하고 싶을 때

실무에서는 둘을 조합하는 구성도 흔하다. 진입점에 L4를 두고 그 뒤의 L7 프록시가 요청을 해석하는 식이다.

세션 계층과 표현 계층

세션 계층(L5)과 표현 계층(L6)의 어휘는 실무에서 보기 어렵다. “L5 장비"나 “L6 프록시"라는 말을 들어본 적이 없다. TCP/IP 모델이 두 계층을 별도로 두지 않고 응용 계층에 포함했고, 실제 프로토콜들도 이 경계를 따로 구현하지 않았기 때문이다. 세션 관리와 데이터 표현(직렬화, 인코딩)은 대부분 애플리케이션 프로토콜과 라이브러리가 함께 처리한다.

TLS가 좋은 예다. 전송 계층 위, 응용 계층 아래에서 동작하는데, OSI 기준으로는 세션 계층이라는 설명과 표현 계층이라는 설명이 함께 쓰인다. 어느 한 계층으로 깔끔하게 분류되지 않는다. 현실의 프로토콜이 이 경계에 맞춰 만들어지지는 않았기 때문이다.

정리

계층 번호는 장비가 패킷의 어느 헤더까지 해석하는지를 가리킨다. L2 스위치는 MAC 헤더까지, L3 라우터는 IP 헤더까지, L4 로드밸런서는 포트까지, L7 프록시는 애플리케이션 데이터까지 해석한다. 이 기준을 이해하고 나니 스위치, 라우터, 로드밸런서, 프록시라는 이름에서 그 장비가 무엇을 해석하는지가 바로 읽힌다. 각 계층에서 실제로 무슨 일이 벌어지는지는 프로토콜별 글에서 하나씩 다뤄가려 한다.

참고