잘 돌아가던 서비스가 갑자기 느려지거나 특정 지역에서만 접속이 안 될 때, 엔지니어는 차분하게 문제의 실마리를 찾아야 합니다. 네트워크 장애는 원인이 매우 다양하기 때문에 감에 의존하기보다 체계적인 계층별 접근이 필수적입니다. 실전에서 바로 활용할 수 있는 트러블슈팅 전략을 소개합니다
1단계: 상향식(Bottom-up) 접근법
네트워크의 기초인 물리 계층부터 응용 계층까지 OSI 7계층을 차례로 점검합니다
- L1 (물리): 케이블이 연결되어 있는가? 장비에 불이 들어오는가?
- L2 (데이터 링크): MAC 주소가 보이는가? VLAN 설정이 올바른가?
- L3 (네트워크):
ping이 가는가? 라우팅 테이블이 정상인가? - L4 (전송): 포트가 열려있는가? (
telnet또는nc테스트) - L7 (응용): HTTP 응답 코드가 무엇인가? 인증서가 만료되지는 않았는가?
2단계: 필수 도구 활용하기
장애 상황에서 엔지니어의 눈이 되어주는 도구들입니다
- ping / mtr: 도달 가능성과 구간별 지연 시간을 확인합니다. 특히
mtr은traceroute와ping을 합친 도구로 경로상의 병목 지점을 찾기에 최고입니다 - nslookup / dig: DNS 설정 문제를 확인합니다
- netstat / ss: 현재 서버의 포트 상태와 연결 목록을 확인합니다
- tcpdump / Wireshark: 가장 강력한 무기입니다. 실제 패킷을 캡처하여 핸드셰이크가 왜 실패하는지, 데이터가 깨지는지 직접 확인합니다
실전 장애 사례별 진단 포인트
| 장애 증상 | 주요 의심 지점 | 확인 도구 |
|---|---|---|
| 특정 도메인 접속 불가 | DNS 설정 오류, 로컬 캐시 오염 | dig, nslookup |
| 간헐적인 패킷 손실 | 네트워크 혼잡, MTU 불일치, 하드웨어 불량 | mtr, ping -s |
| 응답 속도 저하 (Latency) | 라우팅 경로 우회, 로드 밸런서 부하 | traceroute, curl -w |
| 연결 거부 (Connection Refused) | 프로세스 다운, 방화벽 차단, 리슨 포트 오류 | nc -zv, iptables -L |
패킷 분석의 정석: tcpdump 핵심 필터
수많은 트래픽 속에서 원하는 정보만 골라내는 능력이 중요합니다
# 특정 포트(80)의 패킷만 실시간 출력
tcpdump -i eth0 port 80
# 특정 IP와 통신하는 패킷을 파일로 저장 (Wireshark 분석용)
tcpdump -i any host 1.2.3.4 -w issue.pcap
# TCP SYN 패킷만 필터링 (핸드셰이크 문제 진단)
tcpdump 'tcp[tcpflags] & (tcp-syn) != 0'
트러블슈팅의 핵심: “최근에 무엇이 바뀌었는가?”
대부분의 장애는 ‘변경’에서 시작됩니다. 기술적 분석과 동시에 다음을 확인해야 합니다
- 최근에 배포된 코드가 있는가?
- 방화벽 정책이나 보안 그룹 설정이 바뀌었는가?
- 인프라 설정(IaC)이 업데이트되었는가?
- 외부 연동 API나 SaaS 서비스에 공지된 장애가 있는가?
MTU(Maximum Transmission Unit)의 함정
네트워크 설정은 맞는데 큰 용량의 데이터만 전송이 안 된다면 MTU 크기 불일치를 의심해 보세요. 중간 경로의 장비가 처리할 수 있는 패킷보다 큰 데이터가 들어오면 패킷이 조용히 사라지는 'Black Hole' 현상이 발생할 수 있습니다
정리
- 장애 해결의 시작은 OSI 계층을 따라가는 체계적인 접근입니다
- 상황에 맞는 도구(
mtr,tcpdump등)를 능숙하게 다뤄야 합니다 - 기술적 분석만큼이나 변경 이력 확인이 중요합니다
시리즈의 마지막인 다음 글에서는 장애를 미리 예방하고 감시하는 네트워크 관측성 설계에 대해 알아봅니다