
네트워크 수업 과제로 Wireshark를 처음 설치했던 날, 솔직히 이건 예상 밖이었습니다. 화면 가득 흘러내리는 패킷들, 알 수 없는 숫자와 컬럼들. 어디서부터 봐야 할지조차 몰랐습니다. 솔직히 처음 10분은 그냥 창을 멍하니 바라봤습니다. 그런데 레이어별로 헤더를 뜯어보는 법을 익히고 나니, 그 혼돈처럼 보이던 화면이 오히려 네트워크의 속살을 보여주는 창처럼 느껴지기 시작했습니다. 이 감각의 전환이 생각보다 오래 걸렸고, 생각보다 훨씬 값어치 있었습니다.
레이어 구조: 헤더를 읽는 법부터 시작했다
저도 처음엔 패킷 전체를 한꺼번에 이해하려다가 계속 벽에 부딪혔습니다. "이 수천 개의 패킷 중에서 내가 뭘 봐야 하지?"라는 막막함이 먼저였습니다. 그러다 OSI 모델의 레이어 단위로 쪼개서 보기 시작하면서 비로소 방향이 잡혔습니다.
Wireshark에서 패킷을 클릭하면 하단 패널에 레이어별로 헤더 정보가 펼쳐집니다. 가장 아래 L2, 즉 데이터링크 계층에 해당하는 Ethernet 헤더부터 보면, 출발지와 목적지 MAC 주소가 나옵니다. 여기서 MAC 주소란 네트워크 인터페이스 카드에 물리적으로 부여된 고유 식별자로, 같은 로컬 네트워크 안에서 장치끼리 서로를 찾을 때 사용하는 주소입니다. 그리고 EtherType 필드가 있는데, 이 두 바이트짜리 값이 상위 프로토콜이 무엇인지 알려줍니다. 0x0800이면 IPv4, 0x86DD이면 IPv6, 0x0806이면 ARP입니다. 이 숫자들이 처음에는 암호처럼 보였는데, 몇 번 반복하다 보니 눈에 익었습니다.
L3, 즉 네트워크 계층의 IP 헤더로 올라가면 TTL 필드가 눈에 들어옵니다. TTL이란 Time To Live의 약자로, 패킷이 라우터를 거칠 때마다 1씩 감소하다가 0이 되면 폐기되는 값입니다. 쉽게 말해 패킷이 네트워크를 떠도는 수명이라고 보면 됩니다. 그리고 Protocol 필드는 상위 전송 계층 프로토콜을 나타내는데, 6이면 TCP, 17이면 UDP, 1이면 ICMP입니다. 이 숫자들은 IANA(Internet Assigned Numbers Authority)가 공식적으로 관리하는 프로토콜 번호 체계에 기반합니다.
이 레이어 구조를 머릿속에 넣고 나서야 패킷 하나를 보면서 "이건 어느 장치에서 출발해, 어떤 프로토콜로, 어디까지 가는 패킷이다"라는 흐름이 자연스럽게 읽혔습니다. 전에는 숫자의 나열로만 보이던 것들이 맥락이 생기는 순간이었습니다. 개인적으로 이 감각이 생기는 순간이 Wireshark 학습에서 가장 중요한 전환점이라고 생각합니다. 그 전까지는 도구를 쓰는 게 아니라 화면을 구경하는 것에 불과하거든요.
Ethernet 헤더와 IP 헤더에서 확인해야 할 핵심 필드를 간추리면 이렇습니다. EtherType은 상위 프로토콜을 식별해주고, TTL은 패킷 생존 홉 수로 라우팅 경로 이상 탐지에 활용됩니다. Protocol 필드는 전송 계층 프로토콜 번호를 알려주고, ToS(Type of Service)는 QoS 우선순위 결정에 영향을 주는 서비스 품질 필드입니다. 이 네 가지 필드만 익숙해져도 패킷의 맥락을 상당히 읽을 수 있습니다.
필터 활용: 실제 문제를 풀면서 감각을 익혔다
처음에는 필터 없이 흘러가는 패킷을 그냥 보려 했는데, 그건 완전히 잘못된 접근이었습니다. 실제 트래픽은 수백, 수천 개의 패킷이 동시에 쏟아지기 때문에 필터 없이는 아무것도 건질 수 없습니다. 제 경험상 이건 좀 다릅니다. 필터 문법을 익히는 것이 곧 분석 능력 자체라고 해도 과언이 아닙니다. 도구를 쓰는 능력과 그 도구를 활용해 답을 찾는 능력은 다른데, 필터는 그 경계를 넘는 열쇠입니다.
가장 자주 쓴 필터는 특정 MAC 주소를 기준으로 출발지든 목적지든 해당 주소가 포함된 패킷만 걸러주는 방식이었습니다. 네트워크 안에 장치가 많을 때 특정 단말을 추적하는 데 실질적으로 가장 유용했습니다. TTL 값이 비정상적으로 낮은 패킷을 걸러내는 필터도 생각보다 요긴하게 썼습니다. TTL 값이 낮다는 건 패킷이 이미 수많은 라우터를 거쳐왔거나, 라우팅 루프 같은 이상이 생겼을 가능성이 있다는 신호이기 때문입니다.
가장 인상 깊었던 경험은 서버 응답이 유독 느린 원인을 찾던 때였습니다. 며칠을 삽질하다 결국 IP 헤더 안의 ToS 필드를 들여다봤는데, ToS란 Type of Service의 약자로 네트워크 장비가 패킷의 처리 우선순위를 결정할 때 참고하는 값입니다. 이 값이 잘못 설정되어 QoS(Quality of Service) 처리에서 해당 트래픽이 최하위 우선순위로 분류되고 있었습니다. 코드나 서버 설정에서는 아무 문제가 없었는데, 패킷 헤더 하나가 원인이었습니다. Wireshark가 아니었으면 찾는 데 훨씬 더 오래 걸렸을 것입니다. 그리고 이 경험이 "헤더 하나도 허투루 보지 말자"는 습관을 만들어줬습니다.
비판적으로 돌아보면, 필터 문법을 익히는 과정이 생각보다 가파른 학습 곡선을 요구합니다. 공식 문서가 잘 정리되어 있기는 하지만, 실제 문제 상황에서 어떤 필터를 조합해야 할지는 결국 반복 경험으로만 쌓입니다. 지름길은 없습니다. 저도 필터를 처음 접했을 때 문서를 읽고 이해했다고 생각했는데, 막상 실제 패킷 앞에서는 어떤 필터를 써야 할지 몰라서 한참 헤맸습니다.
암호화 한계: Wireshark가 못 보는 세계도 있다
솔직히 이건 Wireshark를 배우다 보면 반드시 마주치는 현실입니다. 강력한 도구이지만, 암호화 앞에서는 속수무책인 영역이 분명히 존재합니다. 이 사실을 처음 직면했을 때 약간 허탈했습니다. "패킷을 다 볼 수 있다"는 전제로 공부했는데, 실제로는 절반 이상이 암호화된 바이트 덩어리인 현실이었기 때문입니다.
오늘날 웹 트래픽의 대부분은 TLS 위에서 동작합니다. TLS란 Transport Layer Security의 약자로, 클라이언트와 서버 사이에 암호화된 통신 채널을 만들어주는 프로토콜입니다. 특히 TLS 1.3에서는 핸드셰이크 과정 자체도 암호화되기 때문에, Pre-Master Secret이라고 불리는 세션 키 재료를 갖고 있지 않으면 페이로드는 물론 일부 메타데이터도 해독이 불가능합니다. Wireshark가 패킷을 잡아두더라도, 내용물은 암호화된 바이트 덩어리로만 보입니다.
그러나 여기서 포기할 이유는 없습니다. 헤더는 암호화되지 않기 때문에 IP 주소, TTL, ToS, 포트 번호 같은 정보는 여전히 읽을 수 있습니다. 페이로드를 못 보더라도 트래픽 패턴, 연결 빈도, 패킷 크기 변화 같은 요소를 통해 이상 징후를 포착하는 방식으로 분석 방향을 전환할 수 있습니다. 개인적으로 이 관점 전환이 중요하다고 생각합니다. "내용을 볼 수 없다"에서 멈추는 것과 "그럼 메타데이터로 무엇을 읽을 수 있는가"로 넘어가는 것은 분석자로서의 성숙도 차이입니다.
또 하나 반드시 짚어야 할 것이 있습니다. Wireshark는 아무 환경에서나 써도 되는 도구가 아닙니다. 타인의 트래픽을 무단으로 캡처하는 것은 명백한 개인정보 침해이자 불법입니다. 본인 소유의 네트워크, 또는 명시적인 허가가 있는 환경에서만 사용해야 한다는 점을 항상 먼저 인식하고 있어야 합니다. 도구의 강력함이 클수록 그것을 다루는 윤리 의식도 함께 높아야 한다는 것을, 배우면서 처음에는 간과하기 쉬운 지점입니다.
마치며
<
출처 및 참고 경로
- Wireshark 공식 문서: https://www.wireshark.org/docs/
- Wireshark 사용자 가이드: https://www.wireshark.org/docs/wsug_html_chunked/
- Wireshark Display Filter Reference: https://www.wireshark.org/docs/dfref/
- RFC 826 - ARP: https://datatracker.ietf.org/doc/html/rfc826
- RFC 791 - IPv4: https://datatracker.ietf.org/doc/html/rfc791
- IEEE 802.3 Ethernet Standard: https://standards.ieee.org/ieee/802.3/7071/
- Wireshark Wiki: https://wiki.wireshark.org/
- BPF 필터 문법 참고: https://biot.com/capstats/bpf.html
'IT적응기' 카테고리의 다른 글
| Cisco ACL 차단 (ACL 구성, 암묵적 Deny, 동적 차단) (0) | 2026.04.16 |
|---|---|
| LACP로 2Gbps 만들기 (구성, 로드밸런싱, 단일플로우) (0) | 2026.04.15 |
| ARP 테이블 (IP 충돌, ARP 스푸핑, 네트워크 진단) (0) | 2026.04.14 |
| 네트워크 장애 대응 (케이블 불량, 포트 에러, VLAN 설정) (0) | 2026.04.14 |
| L3 스위치 vs 라우터 (트래픽 패턴, 장비 선택, 네트워크 설계) (0) | 2026.04.14 |