장애 채널에 "네트워크가 안 됩니다"라는 한 줄만 올라왔습니다. ping은 되는지, 포트는 열렸는지, HTTP 응답은 오는지 구분하지 않으면 모두가 각자 다른 문제를 상상합니다.
OSI 계층은 외우는 표가 아니라 장애를 쪼개는 언어입니다. 계층별 도구를 쓰면 원인을 좁힐 수 있습니다.
OSI 7계층과 TCP/IP 모델
네트워크 문제가 발생했을 때 "어디서 막혔는지"를 빠르게 좁히려면 계층 모델을 이해해야 합니다. 인프라 엔지니어가 가장 먼저 배우는 개념이면서, 실무에서도 매일 사용하는 사고 프레임워크입니다.
- 1OSI 7계층 모델의 각 계층 역할과 데이터 단위
- 2TCP/IP 4계층 모델과 OSI 계층 간 매핑
- 3계층별 식별자: MAC 주소(L2), IP 주소(L3), 포트 번호(L4)
- 4ping(ICMP)으로 L3 통신 검증하기
- 5telnet/nc으로 L4 TCP 포트 열림 여부 확인하기
- 6curl로 L7 HTTP/HTTPS 응답 검증 및 장애 계층 좁히기
ping -c 1 8.8.8.8nc -h 2>&1 | head -1 || sudo apt-get install -y netcatcurl --version | head -1telnet 2>&1 | head -1 || sudo apt-get install -y telnetOSI 7계층 모델이란?
서버에 배포한 서비스가 갑자기 안 된다는 신고가 들어왔습니다. 어디서부터 확인해야 할까요? 서버 자체가 살아있는지, 포트가 열려있는지, 애플리케이션이 응답하는지 — 순서 없이 여기저기 찔러보다가 시간만 가는 상황을 막으려면 계층별 사고 프레임이 필요합니다. OSI 7계층 모델이 바로 이 프레임입니다.

건물에 비유하면, 전기가 들어오는지(L1), 인터폰이 작동하는지(L2), 주소를 찾아오는지(L3), 문이 열리는지(L4), 안에 사람이 있는지(L7) — 각 층을 차례로 확인하면 어디가 문제인지 빠르게 좁혀집니다. 네트워크 장애 대응이 정확히 이 방식으로 이루어집니다.
OSI(Open Systems Interconnection) 모델은 ISO가 1984년에 정의한 네트워크 통신의 표준 참조 모델입니다. 네트워크 통신을 7개의 계층으로 나누어, 각 계층이 하는 역할을 명확하게 정의했습니다.
실제 구현에서는 TCP/IP 모델을 사용하지만, 장애 진단과 개념 설명에서는 OSI 7계층이 훨씬 세밀하기 때문에 지금도 표준 언어로 사용됩니다.
L7 애플리케이션 계층 (Application) HTTP, HTTPS, DNS, SMTP, FTP
L6 표현 계층 (Presentation) TLS/SSL, 인코딩, 압축
L5 세션 계층 (Session) 세션 관리, 인증
L4 전송 계층 (Transport) TCP, UDP — 포트 번호
L3 네트워크 계층 (Network) IP — 라우팅, 논리 주소
L2 데이터링크 계층 (Data Link) Ethernet, MAC 주소
L1 물리 계층 (Physical) 케이블, 광섬유, 전기 신호
계층의 핵심 원칙: 각 계층은 자신의 역할만 담당하고, 위아래 계층에 서비스를 제공합니다. 데이터는 송신 측에서 L7→L1 방향으로 **캡슐화(Encapsulation)**되고, 수신 측에서 L1→L7 방향으로 **역캡슐화(Decapsulation)**됩니다.
각 계층 상세 설명
L1 — 물리 계층 (Physical Layer)
전기 신호, 광 신호를 물리적으로 전송합니다. 케이블, NIC 카드, 허브, 리피터 등이 여기에 해당합니다.
- 데이터 단위: 비트(Bit)
- 장비: 케이블, 허브, 리피터
- 장애 증상: 링크 다운, 케이블 불량, NIC 오류
- 확인 방법:
ip link show—UP/DOWN상태 확인
# 실습 디렉토리 준비
mkdir -p /tmp/networking/part1/exam_1 && cd /tmp/networking/part1/exam_1
# 물리 계층 상태 확인
ip link show eth0
# 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
# ↑ UP이면 물리 연결 정상
- 계층별 성공 지점—ping, telnet/nc, curl 중 어디까지 성공하는지 확인합니다
- 실패 계층—L3, L4, L7 중 처음 실패하는 지점을 장애 후보로 잡습니다
- 다음 도구—성공한 계층 다음 단계의 도구로 좁혀 갑니다
L2 — 데이터링크 계층 (Data Link Layer)
같은 네트워크 세그먼트(LAN) 내에서 프레임을 전달합니다. MAC 주소로 목적지를 식별합니다.
- 데이터 단위: 프레임(Frame)
- 주소 체계: MAC 주소 (48비트, 예:
aa:bb:cc:dd:ee:ff) - 장비: 스위치, 브리지
- 확인 방법:
arp -n— MAC 주소 테이블 확인
# ARP 테이블 확인 (L2 통신이 이루어진 호스트 목록)
arp -n
# Address HWtype HWaddress Flags Iface
# 192.168.1.1 ether aa:bb:cc:dd:ee:ff C eth0
L3 — 네트워크 계층 (Network Layer)
IP 주소를 기반으로 다른 네트워크까지 패킷을 라우팅합니다. 인터넷이 동작하는 핵심 계층입니다.
- 데이터 단위: 패킷(Packet)
- 주소 체계: IP 주소 (IPv4 32비트, IPv6 128비트)
- 장비: 라우터
- 프로토콜: IP, ICMP, OSPF, BGP
# L3 통신 확인 — ping
ping -c 3 8.8.8.8
# 라우팅 경로 확인
ip route show
# default via 192.168.1.1 dev eth0
# 192.168.1.0/24 dev eth0 proto kernel
L4 — 전송 계층 (Transport Layer)
포트 번호를 사용해 프로세스 간 통신을 관리합니다. TCP(신뢰성)와 UDP(속도)가 대표적입니다.
- 데이터 단위: 세그먼트(TCP) / 데이터그램(UDP)
- 식별자: 포트 번호 (0~65535)
- 프로토콜: TCP, UDP
# L4 통신 확인 — telnet으로 특정 포트 열림 여부 확인
telnet 192.168.1.10 80
# Connected to 192.168.1.10. ← 연결 성공 (L4 정상)
# 현재 열려있는 포트 확인
ss -tlnp
# State Recv-Q Send-Q Local Address:Port
# LISTEN 0 128 0.0.0.0:80
L5, L6 — 세션/표현 계층
현대의 TCP/IP 구현에서는 L5(세션)와 L6(표현)이 애플리케이션 계층에 통합되는 경우가 많습니다. TLS/SSL 암호화가 L6에 해당합니다.
L7 — 애플리케이션 계층 (Application Layer)
사용자가 직접 사용하는 프로토콜 계층입니다. HTTP, HTTPS, DNS, SMTP 등이 여기에 해당합니다.
- 데이터 단위: 메시지(Message)
- 프로토콜: HTTP, HTTPS, DNS, FTP, SSH, SMTP
# L7 통신 확인 — curl로 HTTP 응답 확인
curl -I http://example.com
# HTTP/1.1 200 OK ← L7 애플리케이션 응답 정상
# Content-Type: text/html
TCP/IP 4계층 모델
OSI 7계층을 외웠는데 실제 코드나 문서에서는 "인터넷 계층", "전송 계층"이라는 말이 나옵니다. 팀원이 "L4에서 막힌 것 같다"고 할 때 OSI 기준인지 TCP/IP 기준인지 헷갈립니다. 두 모델을 자유롭게 오가며 매핑할 줄 알아야 문서를 읽고 장비 설정을 이해할 수 있습니다.
실제 인터넷 구현에 사용되는 모델입니다. OSI 7계층을 실용적으로 단순화하여 4계층으로 표현합니다.

TCP/IP 4계층 OSI 7계층 대응
────────────────────────────────────────
애플리케이션 계층 L5(세션) + L6(표현) + L7(애플리케이션)
(Application) HTTP, HTTPS, DNS, FTP, SSH, SMTP
전송 계층 L4 (전송)
(Transport) TCP, UDP
인터넷 계층 L3 (네트워크)
(Internet) IP, ICMP, ARP
네트워크 접근 계층 L1(물리) + L2(데이터링크)
(Network Access) Ethernet, Wi-Fi, PPP
실무에서 OSI와 TCP/IP를 모두 알아야 하는 이유:
- 장비/제조사 문서, RFC, 교재 → OSI 계층 용어 사용
- 실제 프로토콜/코드 이해 → TCP/IP 모델
- 두 모델 간 매핑을 자유롭게 할 수 있어야 합니다.
계층별 핵심 식별자 정리
각 계층은 서로 다른 주소 체계로 통신 대상을 식별합니다. 방화벽 규칙을 설정하거나 장애 원인을 좁힐 때 어느 계층의 식별자를 다루고 있는지 알면 명령어와 도구 선택이 명확해집니다.
| 계층 | 식별자 | 예시 | 담당 장비 |
|---|---|---|---|
| L7 | URL, 호스트명 | https://api.example.com/users | 로드밸런서(L7) |
| L4 | 포트 번호 | :443, :3306 | 방화벽, L4 LB |
| L3 | IP 주소 | 10.0.1.25 | 라우터 |
| L2 | MAC 주소 | aa:bb:cc:dd:ee:ff | 스위치 |
계층별 도구로 장애 좁히기
네트워크 장애가 발생하면 L1부터 L7까지 순서대로 확인하는 것이 기본입니다. 하위 계층이 정상이어야 상위 계층이 동작할 수 있기 때문입니다.
ping은 ICMP Echo Request/Reply를 사용하는 L3 진단 도구입니다.
# 기본 ping (4회)
ping -c 4 8.8.8.8
# 예상 출력
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=3.45 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=3.21 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=3.67 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=3.33 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 3.21/3.41/3.67/0.17 ms
출력 해석:
4 received, 0% packet loss→ L3 통신 정상time=3.45 ms→ RTT(왕복 지연 시간), 낮을수록 좋음ttl=118→ 경유한 라우터 수를 역산 가능 (보통 초기값 128 또는 64)
ping 실패 시나리오:
ping -c 4 10.0.1.99
# PING 10.0.1.99: 56 data bytes
# Request timeout for icmp_seq 0
# Request timeout for icmp_seq 1
# --- 10.0.1.99 ping statistics ---
# 4 packets transmitted, 0 packets received, 100% packet loss
→ L1~L3 중 어딘가 문제. 또는 ICMP가 방화벽에서 차단됨.
telnet으로 특정 호스트의 TCP 포트가 열려있는지 확인합니다.
# 80번 포트 연결 테스트
telnet 192.168.1.10 80
# 연결 성공 시:
Trying 192.168.1.10...
Connected to 192.168.1.10.
Escape character is '^]'.
# → 빈 커서가 깜빡임 (HTTP 요청을 기다리는 상태)
# Ctrl+] 후 quit으로 종료
# 연결 실패 시:
Trying 192.168.1.10...
telnet: connect to address 192.168.1.10: Connection refused
# → 포트가 닫혀 있거나 방화벽에서 차단됨
telnet 대신 nc(netcat) 사용:
# nc로 포트 열림 여부 확인 (-z: 연결만 확인, -v: 상세 출력)
nc -zv 192.168.1.10 80
# Connection to 192.168.1.10 80 port [tcp/http] succeeded!
# 타임아웃 설정 (5초)
nc -zvw5 192.168.1.10 443
curl은 HTTP, HTTPS 등 애플리케이션 계층 프로토콜을 직접 테스트합니다.
# HTTP 헤더만 확인 (-I: HEAD 요청)
curl -I http://example.com
# HTTP/1.1 200 OK
# Content-Type: text/html; charset=UTF-8
# Content-Length: 1256
# Server: nginx/1.24.0
# 상세 연결 정보 포함 (-v: verbose)
curl -v https://api.example.com/health
# * Trying 93.184.216.34:443...
# * Connected to api.example.com (93.184.216.34) port 443
# * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
# > GET /health HTTP/2
# < HTTP/2 200
# {"status":"ok"}
# 응답 시간 측정
curl -o /dev/null -s -w \
"연결: %{time_connect}s\nTLS: %{time_appconnect}s\n전체: %{time_total}s\n" \
https://example.com
계층별 장애 진단 플로우
사용자로부터 "웹사이트에 접속이 안 된다"는 신고를 받았습니다. 체계적으로 계층을 좁혀 나가겠습니다.
1단계: 물리/링크 확인 (L1/L2)
# NIC 상태 확인
ip link show
# eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> → UP이면 L1/L2 정상
# 만약 DOWN 상태라면:
# eth0: <BROADCAST,MULTICAST> → 링크 다운, 케이블/포트 확인 필요
2단계: IP 통신 확인 (L3)
# 게이트웨이 ping
ping -c 3 192.168.1.1
# 인터넷 IP ping
ping -c 3 8.8.8.8
3단계: TCP 포트 확인 (L4)
# 웹 서버의 80/443 포트 확인
telnet web-server.example.com 80
nc -zv web-server.example.com 443
4단계: HTTP 응답 확인 (L7)
# HTTP 응답 코드와 헤더 확인
curl -I http://web-server.example.com
curl -v https://web-server.example.com
진단 결과 매트릭스:
| L1/L2 | L3 ping | L4 telnet | L7 curl | 원인 |
|---|---|---|---|---|
| DOWN | 실패 | 실패 | 실패 | 케이블/NIC 문제 |
| UP | 실패 | 실패 | 실패 | 라우팅/방화벽(L3) |
| UP | 성공 | 실패 | 실패 | 포트 차단/서비스 미기동 |
| UP | 성공 | 성공 | 실패 | 애플리케이션 오류 |
| UP | 성공 | 성공 | 성공 | 클라이언트 측 문제 |
ping이 성공하면 L3까지는 정상입니다. 그런데 브라우저에서 접속이 안 된다면?
# 1. ping 성공 확인 (L3 정상)
ping -c 3 web-server.example.com
# 64 bytes from 93.184.216.34: icmp_seq=1 ttl=64 time=2.1 ms ← 성공
# 2. TCP 443 포트 확인 (L4)
nc -zv web-server.example.com 443
# nc: connect to web-server.example.com port 443 (tcp) failed: Connection refused
# 원인 파악: HTTPS 포트(443)가 닫혀 있음
# 가능한 원인:
# a) nginx/apache가 실행 중이지 않음
# b) 방화벽(iptables, 보안그룹)에서 443 차단
# c) 서비스가 443이 아닌 다른 포트에서 실행 중
# 3. 서버에서 서비스 상태 확인
ss -tlnp | grep ':443'
# (아무 출력 없음) → nginx가 실행 중이지 않음
systemctl status nginx
# Active: inactive (dead) ← nginx 중지 상태
교훈: ping 성공 ≠ 서비스 정상. 반드시 L4(포트), L7(응답) 확인까지 해야 합니다.
실전 진단 스크립트
자주 사용하는 계층별 진단 명령어를 정리합니다.
#!/bin/bash
# 네트워크 계층별 진단 스크립트
TARGET="example.com"
TARGET_IP="93.184.216.34"
echo "=== L1/L2: 네트워크 인터페이스 상태 ==="
ip link show | grep -E "^[0-9]+:|state"
echo ""
echo "=== L3: IP 통신 (ping) ==="
ping -c 3 -W 2 $TARGET_IP && echo "L3 정상" || echo "L3 실패"
echo ""
echo "=== L3: 라우팅 경로 ==="
ip route get $TARGET_IP
echo ""
echo "=== L4: TCP 포트 확인 ==="
for PORT in 80 443; do
nc -zvw3 $TARGET $PORT 2>&1 && echo "Port $PORT: 열림" || echo "Port $PORT: 닫힘"
done
echo ""
echo "=== L7: HTTP 응답 ==="
curl -s -o /dev/null -w "HTTP 상태: %{http_code}, 시간: %{time_total}s\n" \
http://$TARGET
echo ""
echo "=== L7: HTTPS 응답 ==="
curl -s -o /dev/null -w "HTTPS 상태: %{http_code}, TLS: %{time_appconnect}s\n" \
https://$TARGET
실제 업무에서 OSI 계층 모델은 다음과 같이 활용됩니다.
온콜 장애 대응 시:
새벽 2시, 모니터링 알람 — "API 서버 응답 없음"
1. L3 확인: ping → 성공 (서버는 살아있음)
2. L4 확인: nc -zv api-server 8080 → 실패
3. 결론: 애플리케이션 프로세스가 죽었거나 포트가 닫힘
4. 조치: systemctl restart api-server
ACL(방화벽 규칙) 요청 시: 팀원이 "방화벽 열어주세요"라고 요청할 때, 계층을 명확히 해야 합니다:
- L3: 어떤 소스 IP → 어떤 목적지 IP
- L4: 어떤 프로토콜(TCP/UDP), 어떤 포트
- L7: 특정 URL 패턴 (L7 방화벽/WAF의 경우)
인프라 문서 작성 시:
"L4 로드밸런서", "L7 라우팅", "L2 스위치" 같은 용어를 정확히 사용하면 동료와의 소통이 명확해집니다.
면접에서 자주 나오는 질문:
- "HTTPS 통신에서 각 계층이 하는 역할을 설명해보세요."
- "L4 LB와 L7 LB의 차이는 무엇인가요?"
- "ping은 성공하는데 서비스 접속이 안 될 때 어떻게 디버깅하시나요?"
요약
| 개념 | 핵심 내용 |
|---|---|
| OSI 7계층 | L1(물리)~L7(애플리케이션)으로 통신을 표준화한 참조 모델 |
| TCP/IP 4계층 | OSI를 실용화한 실제 인터넷 프로토콜 스택 |
| L2 식별자 | MAC 주소 — 같은 LAN 내 통신 |
| L3 식별자 | IP 주소 — 라우팅을 통한 네트워크 간 통신 |
| L4 식별자 | 포트 번호 — 프로세스/서비스 구분 |
| L7 식별자 | URL, 호스트명 — 애플리케이션 수준 통신 |
| ping | ICMP, L3 검증 도구 |
| telnet/nc | L4 TCP 포트 열림 여부 확인 도구 |
| curl | L7 HTTP/HTTPS 응답 확인 도구 |
| 장애 진단 원칙 | 하위 계층(L1)부터 순서대로 확인하며 범위를 좁힘 |
다음 챕터에서는 L3의 핵심인 **IP 주소 체계와 서브네팅(CIDR)**을 학습합니다.