패킷 캡처를 AI가 읽는 텍스트

.pcap · .pcapng 파일을 업로드하면 LLM 전수 분석에 맞춘 .txt로 즉시 변환해 내려받습니다. 파일은 서버에 저장되지 않습니다.

서버 확인 중…
캡처 파일을 여기에 놓으세요 클릭하여 선택 · .pcap .pcapng .cap · 최대 100MB
변환 모드
안내 — 무료 서버는 15분 이상 미사용 시 절전 모드로 들어가며, 첫 요청 시 깨어나는 데 최대 90초가 걸릴 수 있습니다. 변환 자체도 파일 크기에 따라 수 분이 소요될 수 있으니 진행 로그가 흐르는 동안 탭을 닫지 마세요.

Chrome·Edge에서는 시작 버튼을 누르는 즉시 저장 위치를 묻는 창이 뜹니다 — 위치를 지정해야 변환이 시작됩니다.

Field Guide

PCAP을 AI에게 읽히는 가장 현실적인 방법

pcap2ai는 네트워크 패킷 캡처 파일을 대형 언어 모델(LLM)이 전수 분석할 수 있는 구조화 텍스트로 바꿔 주는 징검다리 유틸리티입니다. 이 문서는 이 도구가 왜 필요한지, 어떤 원리로 동작하는지, 그리고 변환된 파일을 ChatGPT나 Gemini에서 어떻게 활용하면 되는지를 실무 관점에서 정리한 가이드입니다.

이 도구가 해결하는 문제

메인 방화벽이나 백본 구간에서 트래픽을 캡처하면 몇 초 만에 수십만 개의 패킷이 쌓입니다. 그 속에서 실제 장애의 실마리 — 특정 시각에 IPsec 터널이 내려간 순간, 잘 흐르던 TCP 세션이 갑자기 RST으로 끊긴 지점, 재전송이 몰리기 시작한 구간 — 는 전체의 0.1%도 되지 않는 미세한 흔적으로만 남습니다. 숙련된 엔지니어도 Wireshark 필터를 수십 번 바꿔 가며 한참을 뒤져야 찾아내는 작업입니다.

LLM은 이런 대량 로그 속 이상 패턴 탐지에 탁월합니다. 시간 순서로 정렬된 패킷 기록을 통째로 읽고 "여기서부터 응답이 사라졌다", "이 시점에 IKE 재협상이 실패했다"를 몇 초 만에 짚어 냅니다. 문제는 단 하나 — AI가 pcap 파일 자체를 읽지 못한다는 점이고, pcap2ai는 정확히 그 간극을 메웁니다.

왜 PCAP을 그대로 AI에 올리면 안 되는가

.pcap과 .pcapng는 libpcap 계열의 바이너리 포맷입니다. 파일 안의 각 패킷은 링크 계층부터 애플리케이션 계층까지 비트 단위로 인코딩된 원시 프레임이라, 텍스트를 다루도록 설계된 LLM에 그대로 첨부하면 다음과 같은 문제가 생깁니다.

  • 해석 불가 — 모델은 바이너리를 토큰화하는 과정에서 프로토콜 구조를 잃어버립니다. 운 좋게 일부를 읽어도 필드 경계를 스스로 지어내는 환각(hallucination)이 섞입니다.
  • 토큰 낭비 — 바이너리를 base64 등으로 우회 인코딩하면 원본보다 부피가 커지고, 의미 있는 정보 밀도는 오히려 급락합니다.
  • 도구 부재 — ChatGPT의 코드 인터프리터가 파이썬으로 파싱을 시도할 수는 있지만, 대용량 파일에서는 실행 시간과 메모리 제한에 걸려 중간에 끊어지기 일쑤입니다.

반면 패킷을 한 줄 = 한 패킷의 고정 폭 텍스트로 펼쳐 놓으면 상황이 완전히 달라집니다. 시간·출발지·목적지·프로토콜·플래그가 열로 정렬된 텍스트는 LLM이 가장 잘 다루는 입력 형태이며, 수십만 줄 속에서도 시퀀스가 끊긴 지점이나 비정상 플래그 조합을 정확히 참조하며 답할 수 있습니다. pcap2ai가 Wireshark 패킷 리스트와 같은 컬럼 구조를 그대로 텍스트로 옮기는 이유가 여기에 있습니다.

요약 모드와 상세 모드, 언제 무엇을 쓰나

LLM에는 컨텍스트(한 번에 읽을 수 있는 분량) 한계가 있습니다. Gemini가 가장 넉넉하지만 그래도 텍스트 수 MB 수준이고, 100MB 캡처를 전 필드로 풀면 수백 MB가 되어 어떤 모델에도 한 번에 들어가지 않습니다. 그래서 pcap2ai는 두 개의 모드를 제공합니다.

  1. 요약 모드 — 패킷당 한 줄. Wireshark 패킷 리스트의 No / Time / Source / Destination / Protocol / Length / Info 컬럼을 고정 폭으로 정렬합니다. TCP는 플래그와 Seq/Ack/Win까지 포함하므로 세션 수립·단절·재전송 흐름 추적에는 이것만으로 충분합니다. 먼저 요약 모드로 전체를 훑어 의심 구간을 특정하는 것이 정석입니다.
  2. 상세 모드 — 패킷마다 모든 프로토콜 계층의 전체 필드 값과 미해석 페이로드의 hex 덤프까지 기록합니다. Wireshark 상세 창(패킷 디테일 패널)에 보이는 정보가 그대로 텍스트가 된다고 보면 됩니다. 요약 모드로 찾아낸 의심 구간을 Wireshark에서 잘라내 (File → Export Specified Packets) 작은 파일로 만든 뒤 상세 모드로 변환하면, AI가 헤더 필드 하나하나를 근거로 원인을 설명해 줍니다.

AI에게 질문하는 법 — 프롬프트 실전 팁

변환된 .txt를 ChatGPT나 Gemini에 첨부한 뒤에는 구체적인 관측 사실 + 원하는 출력 형식을 함께 주는 것이 요령입니다. 실무에서 바로 쓸 수 있는 예시 세 가지를 소개합니다.

세션 단절 지점 추적

첨부한 파일은 방화벽에서 캡처한 패킷 기록이다. 14:02~14:05 사이에 10.20.1.34 ↔ 203.0.113.8 구간의 세션이 끊겼다. 이 시간대에서 TCP 플래그 흐름(SYN/ACK/FIN/RST)을 추적해서 어느 쪽이 먼저 연결을 끊었는지, 재전송이나 Zero Window 징후가 있었는지 패킷 번호를 근거로 설명해 줘.

IPsec 터널 다운 분석

이 캡처에는 IPsec(ESP, ISAKMP/IKE) 트래픽이 포함되어 있다. ESP SPI 값이 바뀌거나 시퀀스가 중단되는 지점, IKE 재협상 시도와 그 성패를 시간순으로 정리해 줘. 터널이 내려간 것으로 추정되는 패킷 번호와 그 직전 5개 패킷의 특이점을 표로 보여 줘.

전체 트래픽 이상 징후 스캔

이 패킷 기록 전체에서 비정상 패턴을 찾아 줘. 기준: (1) RST가 몰리는 구간 (2) 동일 Seq 재전송 반복 (3) 응답 없는 SYN (4) ICMP unreachable. 각 항목별로 발생 시각, 관련 IP 쌍, 패킷 번호 범위를 목록으로 정리하고 가장 의심되는 원인을 제시해 줘.

파일이 모델의 첨부 한도보다 크다면 텍스트 에디터로 시간대별로 나누거나, 처음부터 Wireshark에서 시간 필터(frame.time >= "...")로 구간을 좁혀 캡처를 줄인 뒤 변환하는 편이 훨씬 정확한 답을 얻습니다. AI에게는 "패킷 번호를 근거로 제시하라"고 요구하세요 — 답변의 검증 가능성이 완전히 달라집니다.

자주 묻는 질문

업로드한 캡처 파일은 서버에 남나요?
아니요. 파일은 변환 스트림이 진행되는 동안만 임시 영역에 존재하며, 변환이 끝나거나 중단되는 즉시 삭제됩니다. 변환 결과도 서버에 저장되지 않고 브라우저로만 전송됩니다. 상세 내용은 개인정보처리방침에 명시되어 있습니다.
왜 최대 100MB인가요?
이 서비스는 무료 인프라(512MB RAM)에서 운영됩니다. 스트리밍 구조 덕분에 메모리는 충분하지만 CPU 자원이 제한적이라, 100MB를 초과하면 변환 시간이 비현실적으로 길어집니다. 더 큰 캡처는 Wireshark의 editcap -c로 분할해서 올려 주세요.
변환이 오래 걸리는 것 같아요.
두 가지 이유가 있습니다. 첫째, 무료 서버는 15분 이상 요청이 없으면 절전 상태가 되어 첫 요청 시 깨어나는 데 최대 90초가 걸립니다. 둘째, 변환 자체가 패킷 수에 비례해 수 분이 걸릴 수 있습니다. 진행 로그의 수신량이 계속 늘고 있다면 정상 동작 중입니다.
변환된 텍스트를 사람이 직접 읽어야 하나요?
그럴 필요 없습니다. 출력 포맷은 사람의 가독성이 아니라 LLM의 해석 정확도에 맞춰 설계되었습니다. 파일 상단에 AI를 위한 포맷 설명(컬럼 정의, 플래그 표기)이 포함되어 있어서 그대로 첨부만 하면 됩니다.
어떤 프로토콜까지 해석되나요?
Ethernet, VLAN(802.1Q), ARP, IPv4/IPv6, TCP, UDP, ICMP/ICMPv6, DNS, HTTP, TLS 핸드셰이크, 그리고 IPsec 계열(ESP, AH, ISAKMP/IKE)을 해석합니다. 해석기가 없는 프로토콜의 페이로드는 상세 모드에서 hex 덤프로 보존되므로 정보가 유실되지 않습니다.