네트워크 계층 완전 정복 — OSI 7계층과 TCP/IP를 요청 흐름으로 이해하기
네트워크 계층, 왜 알아야 하나요?
백엔드 개발을 하다 보면 "API가 느리다", "연결이 안 된다", "간헐적으로 timeout 난다" 같은 말을 자주 듣습니다. 그런데 이런 증상은 원인이 전혀 다를 수 있습니다.
- DNS 조회가 느린 것일 수 있습니다
- TCP 연결 자체가 늦게 맺히는 것일 수 있습니다
- TLS handshake에서 인증서나 암호 협상이 꼬인 것일 수 있습니다
- 라우팅이나 방화벽 때문에 패킷이 중간에서 막히는 것일 수 있습니다
- 애플리케이션은 멀쩡한데 HTTP 레벨에서 잘못된 응답을 보내는 것일 수 있습니다
이때 유용한 기준이 OSI 7계층과 TCP/IP 모델입니다.
중요한 점은 계층 모델을 외우는 것 자체가 목적은 아니라는 것입니다. 진짜 목적은 이것입니다.
통신 문제를 어느 층에서 봐야 하는지 나누는 기준을 갖는 것
이 글에서는 OSI 7계층과 TCP/IP 4계층을 각각 따로 암기하지 않고, 브라우저에서 서버까지 요청 하나가 실제로 어떻게 내려가고 올라오는지를 기준으로 정리하겠습니다.
기준: 이 글은 일반적인
HTTP/1.1또는HTTP/2기반 웹 요청, 즉HTTP over TLS over TCP/IP흐름을 기준으로 설명합니다.HTTP/3는QUIC을 통해UDP위에서 동작하므로 전송 계층 해석이 조금 달라질 수 있습니다.
먼저 큰 그림부터 보면
OSI 7계층과 TCP/IP는 경쟁 관계가 아니라, 같은 통신 과정을 다른 해상도로 설명하는 모델이라고 보면 이해가 쉽습니다.
| 관점 | OSI 7계층 | TCP/IP 4계층 |
|---|---|---|
| 목적 | 통신 과정을 계층별로 세분화해 설명하는 참조 모델 | 실제 인터넷 프로토콜 묶음을 설명하는 실용 모델 |
| 계층 수 | 7 | 4 |
| 강점 | 역할을 더 세밀하게 나눠서 설명하기 좋음 | 현실의 프로토콜 스택과 더 가깝고 실무 설명에 자주 쓰임 |
| 대표 키워드 | Application, Presentation, Session, Transport, Network, Data Link, Physical | Application, Transport, Internet, Network Access |
| 실무에서 자주 듣는 표현 | L4, L7, L2 스위치, L3 라우터 |
HTTP, TCP, UDP, IP, Ethernet 같은 실제 스택 설명 |
핵심만 먼저 말하면:
- OSI 7계층은 설명용 지도가 더 가깝습니다
- TCP/IP는 실제 인터넷이 돌아가는 방식에 더 가깝습니다
- 그래서 실무에서는 두 모델을 섞어 말하는 경우가 많습니다
예를 들어:
- "이 로드밸런서는
L4에서 동작한다" - "이 프록시는
L7까지 본다" - "이 서비스는
TCP/IP기준으로TCP위에HTTP가 올라간다"
이런 표현은 모두 같은 통신 과정을 서로 다른 관점에서 설명하는 것입니다.
Phase 1. 왜 굳이 계층으로 나눌까?
계층 모델이 필요한 이유는 단순합니다. 통신은 한 번에 하나의 기술로 끝나지 않기 때문입니다.
브라우저에서 https://example.com에 요청을 보낸다고 가정해 보겠습니다. 이 요청 하나 안에는 사실 여러 역할이 겹쳐 있습니다.
- 어떤 형식으로 요청을 표현할 것인가? →
HTTP - 어떤 상대 프로세스와 통신할 것인가? →
TCP포트 - 목적지 호스트까지 어떻게 보낼 것인가? →
IP - 같은 네트워크 구간에서 실제로 어떤 장치에게 넘길 것인가? →
MAC,Ethernet,Wi-Fi - 전기 신호나 무선 신호로 어떻게 내보낼 것인가? → 물리 계층
이걸 하나의 거대한 프로토콜로 만들면 구현도 어렵고, 교체도 어렵고, 장애 분석도 매우 힘들어집니다. 그래서 역할을 층으로 나눕니다.
브라우저 요청
↓
HTTP 메시지 생성
↓
TCP가 포트와 순서를 관리
↓
IP가 목적지까지 라우팅
↓
Ethernet/Wi-Fi가 같은 링크의 다음 장치로 전달
↓
전기/무선 신호로 전송
계층을 나누면 얻는 장점은 분명합니다.
- 역할 분리 — 각 계층은 자기 책임에 집중합니다
- 표준화 — 아래 계층 구현이 바뀌어도 위 계층은 덜 흔들립니다
- 교체 가능성 — 애플리케이션은
Ethernet인지Wi-Fi인지 몰라도 됩니다 - 장애 분리 — 어디서 문제가 났는지 더 체계적으로 좁힐 수 있습니다
즉, 계층 모델은 이론 장난이 아니라 복잡한 통신을 분해해서 다루기 위한 공통 언어입니다.
Phase 2. OSI 7계층을 한 층씩 보면
OSI 7계층은 통신 과정을 가장 세밀하게 나눈 모델입니다. 아래에서 위로 올라가며 보면 다음과 같습니다.
L1. Physical Layer
가장 아래 층입니다. 비트를 실제 신호로 보내는 역할을 합니다.
- 케이블, 커넥터, 전파, 광신호 같은 물리 매체
- 전기적/기계적 특성
- 실제 0과 1을 어떻게 흘려보낼지
예를 들어 랜 케이블이 불량이거나, Wi-Fi 신호가 너무 약하거나, 포트 자체가 죽어 있으면 이 층의 문제일 가능성이 큽니다.
L2. Data Link Layer
같은 네트워크 구간 안에서 바로 다음 장치까지 데이터를 전달하는 층입니다.
MAC주소 사용Ethernet,Wi-Fi프레임 처리- 스위치가 주로 이 계층에서 동작
- 오류 검출, 프레임 단위 전달
핵심은 L2가 "전 세계 목적지"를 찾는 것이 아니라, 현재 링크에서 누구에게 넘길지를 다룬다는 점입니다.
예를 들어 같은 사내망 안에서 스위치나 VLAN 구성이 잘못되면 L2 문제가 될 수 있습니다.
L3. Network Layer
다른 네트워크까지 포함해서 목적지 호스트까지 경로를 찾아가는 층입니다.
IP주소 사용- 라우터가 주로 이 계층에서 동작
- 패킷 전달과 라우팅
ICMP,TTL(IPv6에서는Hop Limit) 같은 개념
우리가 흔히 말하는 "서버 IP", "라우팅", "서브넷", "게이트웨이"가 이 층과 강하게 연결됩니다.
즉:
- L2는 같은 링크 안에서 다음 장치를 찾고
- L3는 여러 네트워크를 거쳐 최종 목적지까지 가는 길을 찾습니다
L4. Transport Layer
호스트와 호스트가 아니라, 더 정확히는 프로세스와 프로세스 사이의 통신을 다루는 층입니다.
- 포트 번호 사용
TCP,UDP- 신뢰성, 순서 보장, 재전송, 흐름 제어
- 어떤 애플리케이션 프로세스로 데이터를 전달할지 구분
예를 들어:
443포트는 HTTPS 서버 프로세스3306포트는 MySQL 서버 프로세스
처럼 이해할 수 있습니다.
TCP는 연결 지향적이고, 순서 보장과 재전송을 제공합니다. 반면 UDP는 더 단순하고 가볍지만, 전송 보장은 애플리케이션이 직접 책임질 수 있습니다.
L5. Session Layer
통신 세션의 생성, 유지, 종료 같은 대화 흐름을 다루는 층입니다.
- 연결 상태 유지
- 대화 동기화
- 세션 재개 같은 개념
다만 현대 웹 애플리케이션에서는 이 층이 독립적인 프로토콜로 또렷하게 드러나기보다, 애플리케이션 프레임워크나 TLS, 인증 메커니즘, RPC 계층 안으로 흡수된 경우가 많습니다.
그래서 시험에서는 자주 보이지만, 실무에서는 "이건 정확히 세션 계층 문제다"라고 딱 잘라 말하는 경우는 많지 않습니다.
L6. Presentation Layer
데이터 표현 형식과 변환을 다루는 층입니다.
- 인코딩/디코딩
- 직렬화 포맷
- 압축
- 암호화
예를 들어:
UTF-8인코딩JSON,XML,Protocol Buffers- 압축
- 암호화
같은 주제가 이 층과 연결됩니다.
TLS도 교육용 설명에서는 이 층과 연결해 다루는 경우가 많습니다. 다만 현대 인터넷 스택에는 "TLS = OSI 6계층"처럼 고정된 공식 매핑이 있는 것은 아니고, 보통은 애플리케이션 위에서 동작하는 별도 보안 프로토콜로 이해하는 편이 더 정확합니다.
다만 이것도 현대 시스템에서는 독립 계층이라기보다, 애플리케이션과 보안 계층에 섞여 있는 경우가 많습니다.
L7. Application Layer
사용자나 애플리케이션이 직접 다루는 가장 위 계층입니다.
HTTPDNSSMTPFTPSSH
중요한 점은 여기서 말하는 Application이 "브라우저 앱", "서버 앱" 자체를 뜻한다기보다, 애플리케이션이 사용하는 네트워크 프로토콜 계층이라는 것입니다.
예를 들어 HTTP 500, 404, Cookie, Header, Path, Method 같은 것은 L7 수준 이야기입니다.
참고로 HTTPS는 실무에서 편의상 L7으로 묶어 부르기도 하지만, 엄밀히 보면 HTTP 위에 TLS가 추가된 형태입니다.
헷갈리기 쉬운 포인트
현실에서는 L5와 L6가 독립 장비나 독립 프로토콜 계층으로 선명하게 드러나지 않는 경우가 많습니다. 그래서 OSI 7계층은 이해용으로는 좋지만, 구현 관점에서는 다소 이상적인 모델로 느껴질 수 있습니다.
이 지점에서 TCP/IP 모델이 더 실용적으로 보이기 시작합니다.
Phase 3. TCP/IP 4계층은 실제로 어떻게 묶일까?
인터넷에서 실제로 자주 쓰는 설명은 TCP/IP 4계층입니다.
| TCP/IP 계층 | OSI 대응 | 대표 프로토콜 | 핵심 역할 |
|---|---|---|---|
| Application | 대체로 L7-L5에 걸침 (RFC 1122 관점에서는 L7/L6 중심) |
HTTP, DNS, SMTP, TLS, SSH | 애플리케이션 프로토콜과 데이터 표현 |
| Transport | L4 | TCP, UDP | 종단 간 전송, 포트, 신뢰성 |
| Internet | L3 | IP, ICMP | 라우팅과 패킷 전달 |
| Network Access | L2, L1 | Ethernet, Wi-Fi, ARP | 링크 전달과 물리 전송 |
실무에서 TCP/IP가 더 자주 쓰이는 이유는 단순합니다.
- 실제 인터넷 프로토콜 스택이 이 구조에 더 가깝습니다
- L5, L6를 따로 떼지 않아도 대부분의 설명이 충분합니다
- 운영체제 네트워크 스택, 라우터, NIC, 실제 장비와 대응이 쉽습니다
즉, 현대 시스템에서는 보통 이렇게 이해하면 충분합니다.
Application : HTTP, DNS, TLS
Transport : TCP, UDP
Internet : IP
Network Access: Ethernet, Wi-Fi
참고로 교재에 따라 TCP/IP 5계층처럼 Physical을 따로 떼어 설명하기도 합니다. 하지만 실무 감각에서는 보통 4계층 모델이 더 자주 쓰입니다.
Phase 4. 브라우저에서 서버까지 요청 하나를 따라가 보면
이제 이론 대신 실제 흐름으로 보겠습니다. 사용자가 브라우저에 https://example.com을 입력했다고 가정해 보겠습니다.
1. 먼저 DNS로 IP 주소를 찾습니다
브라우저는 도메인 이름만으로는 패킷을 보낼 수 없습니다. 먼저 example.com이 어떤 IP인지 알아야 합니다.
이 단계는 보통 애플리케이션 계층에서 다룹니다.
- 브라우저 캐시 확인
- OS 캐시 확인
- 필요하면 DNS resolver에 질의
즉, HTTP 요청을 보내기 전에도 이미 네트워크 통신이 한 번 일어날 수 있습니다.
2. 서버와 TCP 연결을 맺습니다
IP를 알게 되면 클라이언트는 서버의 443 포트와 TCP 연결을 시도합니다.
여기서 일어나는 것이 3-way handshake입니다.
Client → SYN
Server → SYN + ACK
Client → ACK
이 단계의 목적은:
- 서로 통신 가능한지 확인하고
- 초기 시퀀스 번호를 맞추고
- 신뢰성 있는 연결을 시작하는 것
입니다.
이때 timeout이 나면 흔히:
- 서버 포트가 안 열려 있거나
- 방화벽이 막고 있거나
- 중간 라우팅이 잘못되었거나
- 패킷 손실이 심한 상황
을 의심하게 됩니다.
3. HTTPS라면 TLS handshake가 이어집니다
TCP 연결이 맺어졌다고 바로 HTTP 본문을 보내는 것은 아닙니다. HTTPS라면 그 위에서 TLS handshake가 먼저 일어납니다.
여기서:
- 서버 인증서 확인
- 암호 스위트 협상
- 세션 키 생성
같은 작업이 수행됩니다.
OSI 관점으로 보면 Presentation이나 Session과 닿아 있는 역할처럼 설명할 수 있지만, 현대 실무에서는 보통 그냥 "TLS" 자체로 이해하는 경우가 많습니다.
4. 그 위에 HTTP 요청을 올립니다
이제서야 브라우저는 HTTP 메시지를 씁니다.
GET / HTTP/1.1
Host: example.com
User-Agent: ...
Accept: text/html
이 메시지는 애플리케이션 계층 데이터입니다.
5. HTTP 데이터는 TCP 세그먼트로 감싸집니다
TCP는 이 데이터를 받아:
- 출발지 포트
- 목적지 포트
- 시퀀스 번호
- ACK 번호
같은 정보를 헤더에 붙입니다.
이제 "HTTP 메시지"는 L4 입장에서는 단순한 payload가 됩니다.
6. TCP 세그먼트는 다시 IP 패킷이 됩니다
IP는 TCP 세그먼트를 받아:
- 출발지 IP
- 목적지 IP
TTL(IPv6에서는Hop Limit)- 프로토콜 번호
같은 정보를 붙입니다.
이제 TCP 세그먼트는 L3 입장에서는 또 하나의 payload가 됩니다.
7. IP 패킷은 Ethernet 또는 Wi-Fi 프레임이 됩니다
마지막으로 링크 계층은 다음 홉으로 보내기 위해:
- 출발지 MAC
- 목적지 MAC
같은 정보를 붙입니다.
이 단계에서 목적지 MAC은 "최종 서버의 MAC"이 아니라, 현재 링크에서 다음으로 넘길 장치의 MAC일 수 있습니다. 예를 들어 기본 게이트웨이의 MAC일 수 있습니다.
8. 중간 장비를 거치며 무엇이 바뀔까?
패킷이 라우터를 하나 지날 때마다:
- L2 헤더는 보통 다시 씌워집니다
- L3의
TTL(IPv6에서는Hop Limit)은 감소합니다 - L3의 출발지/목적지 IP는 대체로 유지됩니다 (
NAT같은 중간 장비가 없다는 전제)
즉, 프레임은 구간마다 바뀌고, IP 패킷은 종단까지 이어지는 축에 가깝습니다.
9. 서버는 반대로 역캡슐화합니다
서버는 받은 프레임에서 헤더를 하나씩 벗겨 냅니다.
Ethernet/Wi-Fi 프레임 제거
↓
IP 헤더 확인
↓
TCP 헤더 확인
↓
HTTP 메시지 전달
↓
웹 서버/애플리케이션 처리
이 과정을 역캡슐화(decapsulation) 라고 합니다.
Phase 5. 캡슐화만 이해해도 네트워크가 훨씬 덜 헷갈립니다
네트워크 입문에서 가장 중요한 개념 하나만 고르라면, 많은 경우 캡슐화(encapsulation) 를 꼽을 수 있습니다.
각 계층은 자기 헤더를 붙이고, 아래 계층에 데이터를 넘깁니다.
| 계층 | 데이터 단위 |
|---|---|
| Application | Data, Message |
| Transport | Segment (TCP), Datagram (UDP) |
| Internet | Packet |
| Data Link | Frame |
| Physical | Bit |
예를 들어:
HTTP 메시지
↓
TCP Segment
↓
IP Packet
↓
Ethernet Frame
↓
Bits
이 순서로 감싸집니다.
이걸 이해하면 이런 문장이 자연스럽게 해석됩니다.
- "L4에서 재전송이 발생했다"
- "L3 라우팅은 정상인데 L7 응답이 이상하다"
- "L2는 붙는데 L3 게이트웨이로 못 나간다"
즉, 문제를 "패킷이 이상하다" 수준에서 끝내지 않고, 어느 계층의 헤더와 책임에서 문제가 생겼는지로 더 구체적으로 볼 수 있습니다.
Phase 6. 실무에서는 계층별로 어떻게 장애를 나눠 볼까?
실무에서 계층 모델이 빛나는 순간은 장애 분석입니다. 증상만 보면 비슷해 보여도, 어느 층에서 보느냐에 따라 확인 순서가 달라집니다.
| 증상 | 먼저 볼 계층 | 흔한 원인 |
|---|---|---|
| 도메인으로 접속이 안 됨 | L7(Application) 또는 DNS | DNS 레코드 오류, resolver 문제, 캐시 문제 |
| IP는 보이는데 연결 timeout | L4/L3 | 포트 미오픈, 방화벽, 보안 그룹, 라우팅 문제 |
| 인증서 오류 발생 | L6에 가까운 보안 표현 영역 또는 L7 | 인증서 만료, SNI 설정 오류, TLS 설정 불일치 |
| 응답은 오지만 404/500/502 | L7 | 애플리케이션 버그, 프록시 설정 문제, 업스트림 장애 |
| 같은 서브넷 안 통신만 이상함 | L2 | VLAN, 스위치, ARP, MAC 학습 문제 |
| 케이블 교체 후 간헐적 패킷 손실 | L1/L2 | 물리 매체 불량, NIC, 포트 문제 |
예를 들어 "서비스가 안 된다"는 말을 들었을 때, 바로 애플리케이션 로그부터 보는 것이 항상 정답은 아닙니다.
아래처럼 좁혀 가는 편이 더 빠를 때가 많습니다.
- 도메인이 올바른 IP로 해석되는가?
- 해당 IP의 해당 포트까지 TCP 연결이 맺어지는가?
- TLS handshake는 정상인가?
- HTTP 응답 코드는 무엇인가?
- 그 뒤에야 애플리케이션 로직과 DB를 본다
즉, 네트워크 계층 모델은 문제를 아래에서 위로, 또는 위에서 아래로 잘라 보는 틀입니다.
Phase 7. 왜 실무에서는 OSI보다 TCP/IP가 더 자주 쓰일까?
실무에서 TCP/IP가 더 많이 등장하는 이유는 현실의 구현과 더 가깝기 때문입니다.
- 인터넷은 실제로
IP위에서 동작합니다 - 전송은 보통
TCP나UDP로 설명하면 충분합니다 Session,Presentation은 현대 시스템에서 별도 층으로 분리되지 않는 경우가 많습니다
조금 더 엄밀히 말하면, RFC 1122는 인터넷 프로토콜 스위트의 application layer가 OSI의 top two layers, 즉 presentation과 application 기능을 본질적으로 함께 가진다고 설명합니다. session 성격의 기능은 별도 고정 계층보다는 개별 프로토콜 내부 동작으로 흡수되는 경우가 많습니다.
그래서 개발자나 인프라 엔지니어는 흔히 이렇게 말합니다.
- "이 문제는
TCP연결 문제다" - "이건
IP라우팅 문제다" - "이건
HTTP레벨 문제다"
반면 OSI 7계층은 여전히 매우 유용합니다. 특히 장비와 역할을 구분할 때 그렇습니다.
L4와 L7이 왜 자주 나올까?
대표적인 예가 로드밸런서와 프록시입니다.
- L4 로드밸런서 — 주로 IP와 포트 같은 전송 계층 정보로 트래픽을 분산합니다
- L7 프록시/로드밸런서 — HTTP 헤더, URL 경로, Host, Cookie 같은 애플리케이션 계층 정보까지 보고 판단합니다
즉, 실무에서는:
- 구현은 TCP/IP 관점으로 이해하고
- 문제 범위 설명은 OSI 용어를 빌려서 말하는 경우가 많다
고 정리할 수 있습니다.
핵심만 다시 정리하면
마지막으로 OSI 7계층과 TCP/IP를 한 번 더 비교하면 이렇게 볼 수 있습니다.
| 구분 | OSI 7계층 |
TCP/IP 4계층 |
|---|---|---|
| 성격 | 통신 과정을 세밀하게 설명하는 참조 모델 | 실제 인터넷 스택에 더 가까운 실용 모델 |
| 장점 | 역할을 층별로 나눠 이해하기 쉽습니다 | 실제 프로토콜과 장비 설명에 바로 연결됩니다 |
| 자주 쓰는 상황 | L4, L7, 계층별 장애 분리 설명 |
HTTP, TCP, IP, Ethernet 같은 실제 스택 설명 |
핵심 포인트는 아래 다섯 가지입니다.
OSI 7계층은 암기용 표가 아니라, 통신 문제를 어느 층에서 봐야 하는지 나누는 기준입니다.TCP/IP 4계층은 현대 인터넷 구현과 더 가깝기 때문에 실무 설명에서 더 자주 등장합니다.- 웹 요청 하나는 보통
HTTP/TLS -> TCP -> IP -> Ethernet/Wi-Fi순서로 내려가며 캡슐화됩니다. - 반대로 서버는 프레임, 패킷, 세그먼트 헤더를 벗기며 역캡슐화한 뒤 최종적으로 애플리케이션에 메시지를 전달합니다.
- 장애 분석에서는 "네트워크가 안 된다"보다 DNS 문제인지,
TCP연결 문제인지,TLS문제인지,HTTP문제인지를 나눠 보는 것이 더 중요합니다.
결국 네트워크 계층 모델은 암기 과목이라기보다, 복잡한 통신을 구조적으로 보는 방법에 가깝습니다.