OSI 7계층과 TCP/IP 4계층: 웹사이트가 열리는 과정으로 이해하기

NETWORK BASIC · OSI & TCP/IP

케이블은 꽂혀 있는데, 왜 웹사이트는 열리지 않을까요?

PC의 연결 표시가 정상이어도 웹페이지는 안 열릴 수 있습니다. 이름을 찾지 못할 수도 있고, 서버의 특정 포트가 막혔을 수도 있습니다. 연결이라는 한 단어 안에 서로 다른 일이 들어 있기 때문입니다.

OSI 7계층은 그 일을 일곱 가지 역할로 나눠 보는 지도입니다. TCP/IP 4계층은 인터넷에서 사용하는 통신 체계를 네 개의 큰 묶음으로 설명합니다. 이름을 외우기 전에, 웹페이지 하나가 도착하려면 어떤 일이 필요한지부터 따라가 보겠습니다.

1. 7계층과 4계층은 어떻게 연결될까?

같은 통신을 얼마나 잘게 나누어 설명하느냐가 다릅니다. OSI의 응용·표현·세션 역할은 TCP/IP의 응용 계층으로, 데이터 링크·물리 역할은 네트워크 접근 계층으로 묶어 비교하면 이해하기 쉽습니다.

7 → 4는 통신 단계가 생략됐다는 뜻이 아닙니다.
현실의 프로그램과 프로토콜은 여러 역할을 함께 수행할 수 있습니다. OSI의 각 계층을 소프트웨어 일곱 개나 장비 일곱 대로 생각할 필요는 없습니다.

TCP/IP 계층	핵심 질문	대표 예
응용	무슨 서비스를 주고받나?	HTTP, DNS
전송	어느 통신 종점으로, 어떤 방식으로 전달하나?	TCP, UDP와 포트 번호
인터넷	다른 네트워크의 목적지로 어떻게 보내나?	IP 주소와 라우팅
네트워크 접근	지금 연결된 링크에서 어떻게 주고받나?	Ethernet, Wi-Fi와 전송 매체

2. OSI는 아래에서 위로 읽으면 쉽습니다

1·2·3계층: 신호, 가까운 이웃, 목적지까지의 경로

1계층 물리(Physical)는 비트를 전기·빛·무선 신호로 전송하는 영역입니다. 케이블, 광모듈, 무선 신호와 인터페이스 상태가 여기와 관련됩니다. 링크가 올라왔다는 것은 출발점이 준비됐다는 신호이지, 웹서비스까지 정상이라는 보장은 아닙니다.

2계층 데이터 링크(Data Link)는 직접 연결된 링크에서 프레임을 주고받는 역할입니다. Ethernet의 MAC 주소, 일반적인 스위칭과 VLAN을 떠올리면 됩니다. 같은 스위치에 꽂혀 있어도 VLAN이 다르면 같은 Layer 2 통신 구역이 아닐 수 있습니다.

3계층 네트워크(Network)는 서로 다른 IP 네트워크 사이에서 패킷을 전달하는 역할입니다. 목적지 IP를 보고 적절한 다음 경로를 선택합니다. 다른 네트워크로 갈 때 사용하는 기본 게이트웨이도 이 흐름과 연결됩니다.

4계층: 같은 서버의 어느 통신으로 보낼까?

4계층 전송(Transport)의 대표 프로토콜은 TCP와 UDP입니다. 같은 IP 주소에서도 웹, 이름 조회 등 여러 서비스가 동작할 수 있으므로 포트 번호로 통신 종점을 구분합니다. 여기서 포트는 케이블을 꽂는 물리 포트가 아닙니다.

TCP는 연결을 설정하고, 바이트 순서와 재전송 등을 관리해 신뢰성 있는 바이트 스트림을 제공합니다. UDP는 데이터그램을 전달하며, UDP 자체가 도착·순서·재전송을 보장하지는 않습니다. 다만 응용 프로그램이 UDP 위에 필요한 기능을 더할 수 있어, “UDP를 쓰면 언제나 신뢰성이 없다”라고 결론 내리면 안 됩니다.

5·6·7계층: 대화를 유지하고, 표현하고, 서비스를 주고받기

OSI 계층	나누어 보는 역할	기억할 점
5 세션 Session	대화의 설정·유지·종료와 동기화	TCP 연결이나 웹 로그인 세션과 무조건 같은 개념은 아닙니다.
6 표현 Presentation	데이터 표현 형식과 변환, 암호화 같은 역할	실제 인터넷 구현에서 반드시 독립 계층으로 분리되는 것은 아닙니다.
7 응용 Application	응용 서비스가 사용하는 통신 규칙	HTTP·DNS 같은 프로토콜을 생각합니다. 브라우저 프로그램 전체가 곧 한 계층인 것은 아닙니다.

이 세 역할을 실무에서 매번 따로 떼어 장비를 찾는 것은 아닙니다. TCP/IP에서는 응용 계층이라는 큰 묶음으로 봅니다. TLS도 암호화라는 이유만으로 “항상 정확히 OSI 6계층 장비에서만 처리한다”고 분류하기보다는, 실제 프로토콜 구성과 종료 지점을 확인해야 합니다.

3. MAC·IP·포트·도메인, 주소도 역할이 다릅니다

이름	무엇을 구분하나?	예시
MAC 주소	해당 Ethernet 링크에서 프레임을 보낼 인터페이스	PC의 NIC, 게이트웨이의 인터페이스
IP 주소	IP 패킷의 출발지·목적지와 네트워크 경로	192.0.2.10
포트 번호	TCP/UDP 통신의 종점	HTTPS의 기본 서비스 포트 443
도메인 이름	사람이 사용하는 서비스 이름	example.com, DNS로 주소 조회

PC가 다른 네트워크의 서버로 보낼 때, 첫 Ethernet 프레임의 목적지 MAC은 보통 멀리 있는 서버가 아니라 다음 홉인 게이트웨이의 MAC입니다. 라우터는 패킷을 다음 링크에 맞는 새 프레임에 담아 전달합니다.

반대로 NAT가 있으면 IP 주소나 포트가 바뀔 수 있습니다. VLAN 태그, VPN과 터널, 프록시가 있는 환경은 이 그림보다 복잡합니다. 우선 MAC은 현재 링크의 다음 이웃, IP는 라우팅할 목적지, 포트는 통신 종점이라는 구분부터 잡으면 됩니다.

4. 데이터는 아래로 내려가며 포장됩니다

응용 프로그램이 만든 데이터에는 전송에 필요한 정보가 차례로 붙습니다. TCP 기반 통신이라면 TCP 헤더에 포트와 순서 정보 등이, IP 헤더에 IP 주소 등이 들어갑니다. Ethernet 링크에서는 그 패킷을 다시 프레임에 담습니다. 이 과정을 캡슐화라고 합니다.

수신 측은 반대 순서로 전달 정보를 해석해 위쪽으로 넘깁니다. 이를 역캡슐화라고 합니다. Ethernet의 전송 단위는 프레임, IP는 패킷, TCP는 세그먼트, UDP는 데이터그램이라고 구분해 부릅니다. 현장에서는 모두 패킷이라고 부르기도 하므로 문맥을 함께 봐야 합니다.

그렇다고 케이블 안에 상자 그림이 그대로 들어가는 것은 아닙니다. 실제 링크로는 비트를 표현하는 신호가 전송됩니다. 또 웹문서 하나가 반드시 프레임 하나에 들어가는 것도 아닙니다.

5. 주소창에 웹주소를 입력하면 무슨 일이 일어날까?

이번에는 네트워크 설정이 정상인 PC가 TCP 기반 HTTPS의 새 연결을 만드는 상황으로 보겠습니다. HTTP/1.1 또는 HTTP/2를 TLS 위에서 사용하는 예시이며, 실제 브라우저는 캐시·연결 재사용·병렬 요청을 활용합니다.

1. 이름 확인: 브라우저와 OS의 캐시 또는 DNS 조회를 통해 서버 주소를 확인합니다. DNS가 필요한 경우 어떤 전송 방식을 쓰는지는 환경에 따라 다릅니다.
2. TCP 연결: 선택한 서버 IP와 포트에 연결을 설정합니다. HTTPS의 기본 포트는 443이지만, 다른 포트를 명시한 서비스도 있습니다.
3. TLS 통신 준비: 서버 인증서를 확인하고 통신 보호에 필요한 조건과 키를 협의합니다. TCP 연결이 됐다고 인증서 검증도 성공하는 것은 아닙니다.
4. HTTP 요청·응답: 브라우저가 필요한 자원을 요청하고 서버가 상태 코드와 데이터를 돌려줍니다. 404나 500처럼 서버가 보낸 HTTP 응답이 문제 해결의 단서가 될 수 있습니다.
5. 화면 표시: 브라우저가 HTML 등을 해석하고 필요한 추가 자원을 요청해 화면을 구성합니다.

웹 통신이 전부 TCP인 것은 아닙니다.
HTTP/3는 UDP 위의 QUIC을 사용합니다. QUIC은 신뢰성 있는 스트림과 보안 기능 등을 제공합니다. “웹이니까 TCP”, “UDP니까 재전송이 없다”라는 식의 단정은 피해야 합니다.

여기서 DNS를 7계층이라고 부르는 것은 DNS 메시지의 역할을 말합니다. DNS 메시지를 실제로 운반할 때는 아래 계층도 필요합니다. 한 번의 동작이 한 계층에서만 끝나는 것은 아닙니다.

6. 계층을 배우는 진짜 이유는 장애 범위를 좁히기 위해서입니다

관측한 증상	먼저 살필 곳	바로 단정하면 안 되는 것
링크가 내려가 있음	케이블·광모듈·전원·포트 비활성화·무선 연결	케이블만의 문제라고 확정하지 않습니다.
같은 망의 이웃과 통신 안 됨	VLAN·IP/마스크·MAC/ARP·단말 정책	같은 스위치이므로 같은 망이라고 가정하지 않습니다.
다른 네트워크로만 안 됨	게이트웨이·경로·필터·반환 경로	송신 방향만 정상이라고 왕복 통신이 되는 것은 아닙니다.
이름으로만 접속 실패	DNS 결과·캐시·해당 이름의 서비스 설정	HTTPS를 IP로 열면 인증서·가상호스트 조건이 달라질 수 있습니다.
TCP 연결은 되지만 웹 오류	TLS·인증서·HTTP 상태·프록시·서버 로그	TCP 성공만으로 웹서비스 정상이라고 판단하지 않습니다.

내 PC에서 확인할 수 있는 작은 시작

Windows PowerShell에서는 다음처럼 상태를 조회할 수 있습니다. example.com은 설명용 이름이므로 실제 점검할 도메인으로 바꾸세요. 운영 장비의 설정을 바꾸는 명령은 아닙니다.

ipconfig /all
nslookup example.com
Test-NetConnection -ComputerName example.com -Port 443

ipconfig /all에서는 PC의 주소·마스크·게이트웨이·DNS 설정을, nslookup에서는 지정한 DNS 조회 결과를 확인합니다. 브라우저가 별도 보안 DNS나 캐시를 사용하면 결과를 함께 대조해야 합니다.

TcpTestSucceeded는 지정한 TCP 포트의 연결 시험 결과입니다. TLS 인증서나 HTTP 본문이 정상이라는 뜻은 아니며 HTTP/3의 UDP 연결을 검사한 것도 아닙니다. Ping 역시 실패하면 ICMP 차단 가능성 등을 함께 보고, 성공해도 웹서비스까지 정상이라고 결론 내리지 마세요.

장애를 찾기 위해 방화벽 전체를 끄기보다는 어디까지 확인됐고, 무엇이 아직 확인되지 않았는지를 적는 편이 안전하고 빠릅니다.

7. 이름보다 먼저 기억할 네 가지 질문

1. 링크: 신호를 주고받을 준비가 됐나?
2. 이웃: 같은 링크의 누구에게 프레임을 보내야 하나?
3. 경로와 전송: 어느 IP로, 어떤 TCP/UDP 종점에 전달하나?
4. 서비스: 이름 조회·보안 통신·응답 내용은 정상인가?

“이건 무조건 몇 계층 장비다”라고 외우는 것보다 지금 확인하는 기능이 어떤 역할인지를 구분해보세요. L3 스위치는 스위칭과 라우팅을 함께 할 수 있고, 방화벽이나 프록시도 여러 계층의 정보를 확인할 수 있습니다. 계층은 장비를 칸막이에 넣는 규칙이 아니라 통신을 설명하고 문제를 나눠 보는 도구입니다.

이어 읽기 · VLAN이란? 같은 스위치에서 네트워크를 나누는 방법

---

원리 대조: ITU-T X.200 · OSI 기본 모델 · RFC 1122 · 인터넷 계층 구조 · RFC 9293 · TCP · RFC 9114 · HTTP/3 · Microsoft · Test-NetConnection. 벤더 공통 입문 설명이며 특정 장비의 기능 지원이나 실제 장애 원인을 확정하는 자료는 아닙니다.

---

함께 보는 공식 표준 문서

글의 주제를 더 자세히 확인할 수 있는 공식 원문입니다. 문서별 적용 모델과 OS 버전을 확인해 주세요.

• RFC 1122 — Requirements for Internet Hosts
  인터넷 호스트의 통신 계층 구조
  TCP/IP 계층 구조와 호스트 통신 요구사항
  공식 문서 보기 ↗

• RFC 9293 — Transmission Control Protocol
  TCP 표준
  TCP 연결·신뢰성·전송 계층 동작
  공식 문서 보기 ↗

• RFC 9114 — HTTP/3
  HTTP/3 표준
  HTTP/3와 QUIC의 관계; 웹 통신 설명의 보충 자료
  공식 문서 보기 ↗