ioob.dev
Go back

네트워크 기초 1편 — OSI와 TCP/IP 모델

· 11분 읽기
Network 시리즈 (1/7)
  1. 네트워크 기초 1편 — OSI와 TCP/IP 모델
  2. 네트워크 기초 2편 — IP 주소와 서브넷
  3. 네트워크 기초 3편 — TCP와 UDP
  4. 네트워크 기초 4편 — DNS
  5. 네트워크 기초 5편 — HTTP와 HTTPS
  6. 네트워크 기초 6편 — TLS/SSL
  7. 네트워크 기초 7편 — 로드 밸런서와 프록시
Table of contents

Table of contents

패킷은 혼자 움직이지 않는다

브라우저에 https://example.com을 입력하고 엔터를 치면, 화면에 웹페이지가 뜬다. 이 과정에서 실제로 벌어지는 일은 단순하지 않다. 도메인을 IP로 바꿔야 하고, 목적지까지 가는 경로를 찾아야 하고, 암호화된 연결을 맺어야 하고, 데이터를 쪼개서 보내야 하고, 도중에 손실되면 재전송해야 한다. 이 복잡한 일을 한 덩어리의 프로그램이 전부 처리한다면 아무도 네트워크 소프트웨어를 만들 수 없었을 것이다.

네트워크는 이 문제를 계층(layer)이라는 발상으로 풀었다. 한 계층은 자기 바로 아래 계층의 서비스만 쓰고, 자기 바로 위 계층에게만 서비스를 제공한다. 브라우저는 HTTP만 신경 쓰면 되고, HTTP는 TCP만 신경 쓰면 되고, TCP는 IP만 신경 쓰면 된다. 이 분업 구조가 없었다면 인터넷은 지금처럼 굴러가지 못한다.

이 글에서는 그 분업 구조를 기술한 두 개의 모델 — OSI 7계층과 TCP/IP 4계층을 나란히 놓고 본다. 시험 문제처럼 외우는 게 아니라, 패킷 하나가 컴퓨터를 떠나 목적지 서버의 애플리케이션까지 도달하기까지 어떤 경로를 지나는지 감각으로 잡는 것이 목표다.

왜 계층으로 나누는가

네트워크 설계자들이 계층을 도입한 이유는 한마디로 관심사의 분리다. 소프트웨어 엔지니어링에서 함수나 모듈로 일을 쪼개는 것과 같은 논리다.

계층을 나누지 않으면 브라우저 하나를 만들 때마다 이더넷 드라이버부터 TLS 암호화까지 전부 직접 짜야 한다. 실제로 초기 네트워크는 그렇게 만들어졌고, 그 혼란 속에서 표준이 필요해졌다.

OSI 7계층 — 이론의 교과서

OSI(Open Systems Interconnection) 모델은 1984년 ISO가 표준화한 7계층 구조다. 당시 각 벤더가 자기만의 네트워크 규격을 만들어 파편화됐던 상황을 정리하려는 시도였다. 실제로 이 모델 그대로 구현된 네트워크는 별로 없지만, 오늘날까지도 “네트워크를 이야기할 때 쓰는 공통 언어”로 살아남았다.

flowchart TB
    L7["7. Application<br/>HTTP, FTP, SMTP, DNS"]
    L6["6. Presentation<br/>TLS, 문자 인코딩, 압축"]
    L5["5. Session<br/>세션 수립/유지/종료"]
    L4["4. Transport<br/>TCP, UDP"]
    L3["3. Network<br/>IP, ICMP, 라우팅"]
    L2["2. Data Link<br/>Ethernet, MAC, 스위치"]
    L1["1. Physical<br/>전기 신호, 광 신호, 케이블"]

    L7 --> L6 --> L5 --> L4 --> L3 --> L2 --> L1

각 계층이 무엇을 하는지 한 줄씩 정리하면 이렇다.

실무에서는 특히 L4와 L7이라는 약어를 자주 쓴다. L4 로드밸런서는 TCP/UDP 포트 기반으로 트래픽을 분산하고, L7 로드밸런서는 HTTP 헤더나 경로 같은 애플리케이션 정보를 보고 분산한다. 이 구분이 네트워크 장비와 클라우드 인프라 설계 곳곳에 등장한다.

TCP/IP 4계층 — 실전의 표준

OSI가 교과서라면 TCP/IP 모델은 실제 인터넷이 쓰는 방식이다. 1970년대 미국 국방부 ARPANET 프로젝트에서 출발했고, OSI보다 먼저 만들어져 실전에서 검증됐다. 상세한 역사는 Wikipedia: Internet protocol suite에 잘 정리돼 있다.

TCP/IP는 4계층으로 뭉뚱그려져 있다. OSI의 상위 세 계층(5·6·7)을 하나의 Application 계층으로 묶고, 하위 두 계층(1·2)도 Network Access라는 하나의 층으로 묶는다.

flowchart LR
    subgraph OSI["OSI 7계층"]
        O7["Application"]
        O6["Presentation"]
        O5["Session"]
        O4["Transport"]
        O3["Network"]
        O2["Data Link"]
        O1["Physical"]
    end

    subgraph TCPIP["TCP/IP 4계층"]
        T4["Application"]
        T3["Transport"]
        T2["Internet"]
        T1["Network Access"]
    end

    O7 --> T4
    O6 --> T4
    O5 --> T4
    O4 --> T3
    O3 --> T2
    O2 --> T1
    O1 --> T1

TCP/IP 각 계층을 대표 프로토콜과 함께 정리하면 이렇다.

왜 두 모델이 공존하는가? OSI는 이론 정립과 교육에 좋고, TCP/IP는 현실을 더 잘 반영하기 때문이다. 대부분의 자료와 시험 문제는 OSI 7계층 용어로 설명하지만, 실제 리눅스 커널이 구현한 것은 TCP/IP 4계층이다. 둘 다 알고 있어야 문서와 현실을 오가며 이해할 수 있다.

패킷이 계층을 따라 내려가는 길 — 캡슐화

데이터를 보낼 때 일어나는 일을 따라가보자. 브라우저가 서버에 GET /index.html을 요청한다고 하자. 이 요청은 각 계층을 내려가면서 헤더가 하나씩 덧씌워지는 과정을 거친다. 이걸 캡슐화(encapsulation)라고 부른다.

flowchart TB
    APP["Application<br/>HTTP: GET /index.html"]
    T["Transport<br/>+ TCP 헤더<br/>(출발/목적 포트, 순서번호)"]
    N["Network<br/>+ IP 헤더<br/>(출발/목적 IP)"]
    L["Link<br/>+ Ethernet 헤더<br/>(출발/목적 MAC)"]
    P["Physical<br/>비트 스트림으로 전송"]

    APP --> T --> N --> L --> P

한 단계씩 풀어보자.

  1. Application: 브라우저는 HTTP 메시지 하나를 만든다. GET /index.html HTTP/1.1 같은 텍스트
  2. Transport: 이 메시지를 TCP 소켓에 쓰면, TCP가 세그먼트로 쪼개고 헤더를 붙인다. 헤더에는 출발지 포트(브라우저가 쓰는 임시 포트, 예: 54321)와 목적지 포트(보통 443), 순서번호, 체크섬 같은 정보가 들어간다
  3. Network (IP): TCP 세그먼트를 IP 패킷에 담는다. IP 헤더에는 출발지 IP(내 컴퓨터)와 목적지 IP(서버)가 붙는다. 라우터는 이 IP 주소만 보고 다음 홉(hop)을 결정한다
  4. Link (Ethernet): IP 패킷을 이더넷 프레임에 담는다. 프레임 헤더에는 출발지 MAC과 목적지 MAC이 붙는다. 여기서 목적지 MAC은 “최종 목적지 서버의 MAC”이 아니라 바로 다음 홉(대개 기본 게이트웨이)의 MAC이다. 이 점이 헷갈리기 쉬운데, 라우터를 하나 넘어갈 때마다 목적지 MAC은 새로 바뀐다. IP는 끝까지 살아 있고, MAC은 구간마다 갈아탄다
  5. Physical: 프레임은 전기 신호나 광 신호로 바뀌어 물리적으로 전송된다

수신 측에서는 정확히 반대 순서로 헤더를 벗긴다(역캡슐화, decapsulation). Ethernet 헤더를 벗겨서 MAC 주소가 맞는지 확인하고, IP 헤더를 벗겨서 내 IP가 맞는지 확인하고, TCP 헤더를 벗겨서 포트에 해당하는 프로세스를 찾고, 마지막으로 HTTP 메시지를 애플리케이션에 전달한다. 각 계층은 자기 헤더만 본다. 이게 계층화의 핵심이다.

두 호스트 사이의 실제 흐름

한 호스트 안에서 내려가기만 보면 그림이 단순하지만, 실제로는 두 호스트 사이에 여러 개의 라우터와 스위치가 놓인다. 그 중간 구간에서 각 장비는 자기 일을 할 만큼만 상위 계층까지 패킷을 풀어본다.

sequenceDiagram
    participant A as 클라이언트
    participant S as L2 스위치
    participant R1 as 라우터 1
    participant R2 as 라우터 2
    participant B as 서버

    A->>S: Ethernet 프레임 (목적지 MAC = R1)
    Note over S: L2만 본다. MAC 기반 포워딩
    S->>R1: 프레임 전달
    Note over R1: L3까지 본다. IP 보고 경로 결정<br/>새 Ethernet 헤더 씌워 다음 홉으로
    R1->>R2: 새 프레임 (목적지 MAC = R2)
    Note over R2: 같은 방식. IP 보고 경로 결정
    R2->>B: 새 프레임 (목적지 MAC = B)
    Note over B: L2→L3→L4→L7 전부 역캡슐화<br/>애플리케이션에 HTTP 메시지 전달

실무에서 “L4 로드밸런서”, “L7 프록시” 같은 표현을 만나면, 그 장비가 어느 계층까지 들여다보는지를 말하는 것이다. 이 감각이 있으면 클라우드의 로드밸런서 선택이나 Kubernetes Service/Ingress 설계를 훨씬 수월하게 할 수 있다.

리눅스에서 계층을 눈으로 보기

이 추상적인 이야기를 리눅스 명령어로 확인해볼 수 있다. 각 계층에 대응하는 도구가 하나씩 있다.

# L2 — MAC 주소와 인터페이스 확인
ip link show

# L3 — IP 주소와 라우팅 테이블
ip addr show
ip route show

# L4 — 열려 있는 포트와 연결 상태
ss -tulnp

# L7 — HTTP 요청을 눈으로
curl -v https://example.com

각 명령이 건드리는 계층을 이해하면, 네트워크 장애를 마주했을 때 어느 도구부터 꺼내야 할지 판단이 선다. ping으로 L3이 열려 있는지 확인하고, curl이나 telnet으로 L4-L7이 열려 있는지 확인하는 식의 체계적인 진단이 가능해진다.

# 예: 5층 빌딩의 5층을 쓰려면 1층 입구부터 뚫려 있어야 한다
ping 93.184.216.34      # L3 살아 있나?
nc -zv example.com 443  # L4 포트 열려 있나?
curl -v https://example.com   # L7 HTTP 응답 오나?

이 순서로 확인하면 어느 계층에서 막혀 있는지 한눈에 보인다. 상위 계층이 안 되는 이유의 절반쯤은 아래 계층에 있다.

헷갈리기 쉬운 지점

계층 모델을 처음 배울 때 실수하기 쉬운 지점들을 미리 정리한다.

이 시리즈에서 걸어갈 길

이 글에서는 네트워크를 지탱하는 뼈대 — 계층 구조를 훑었다. 앞으로 세 편에서 각 계층의 핵심 프로토콜을 깊이 들여다본다.

한 편씩 쌓여갈수록 브라우저 주소창에 URL을 입력한 순간부터 서버가 응답하기까지의 전 과정이 머릿속에서 연결된다.

다음 편에서는 IP 주소라는 이름표를 해부한다. 32비트 숫자 하나가 왜 네 덩어리로 쓰이는지, 사설망과 공인망이 어떻게 나뉘는지, CIDR 표기가 무엇을 뜻하는지 살펴본다.

→ 2편: IP 주소와 서브넷

Related Posts

Share this post on:
Share this post via WhatsApp Share this post on Facebook Share this post on X Share this post via Telegram Share this post on Pinterest Share this post via email

Comments

Loading comments...

Previous Post
Linux 기초 8편 — Bash 스크립팅 기초
Next Post
네트워크 기초 2편 — IP 주소와 서브넷