TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 30 READS

AI 에이전트가 도구랑 뭘 주고받는지 훤히 보인다 — 'MCP판 와이어샤크' mcpsnoop

AI 에이전트가 도구랑 뭘 주고받는지 훤히 보인다 — 'MCP판 와이어샤크' mcpsnoop

MCP 디버깅, 다들 감으로 하고 계셨죠?

요즘 AI 에이전트 개발하시는 분들은 MCP를 피해갈 수 없을 거예요. MCP(Model Context Protocol)가 뭐냐면, AI 모델이 외부 도구나 데이터 소스와 대화할 때 쓰는 표준 프로토콜이에요. AI 세계의 USB 포트 같은 거라고 보면 되는데요. 문제는 클라이언트(예: Claude Desktop이나 IDE 에이전트)와 MCP 서버 사이에 실제로 무슨 메시지가 오가는지 들여다보기가 은근히 어렵다는 거예요. 도구 호출이 왜 실패하는지, 서버가 모델한테 뭘 보내는지 알 수가 없으니 로그 찍어가며 감으로 디버깅하게 되죠. mcpsnoop은 바로 이 지점을 파고든 도구예요. 스스로를 'MCP판 와이어샤크'라고 소개하는데요, 네트워크 패킷을 눈으로 보게 해주는 와이어샤크처럼 MCP 트래픽을 실시간으로 보여주거든요.

동작 원리: 투명 프록시

구조가 아주 영리해요. MCP 클라이언트 설정에서 서버 실행 명령을 mcpsnoop -- 원래-서버-명령 형태로 한 줄만 바꾸면 끝이에요. 그러면 mcpsnoop이 중간에 앉아서 진짜 서버를 대신 띄우고, 양방향으로 오가는 모든 JSON-RPC 메시지를 그대로 중계하면서 기록해요. 서버 코드는 한 글자도 안 고쳐도 되는 '투명 프록시' 방식이죠. stdio 전송(로컬 프로세스 방식)은 물론이고 HTTP/SSE 방식도 리버스 프록시 모드로 지원해요.

뭘 보여주냐면요

터미널에서 실행되는 TUI(텍스트 기반 UI)가 핵심인데요. 요청, 응답, 알림이 방향과 메서드별로 색깔 구분되어 스크롤 목록으로 흐르고, 선택하면 상세 패널에서 JSON-RPC 페이로드를 예쁘게 펼쳐서 보여줘요. tools/call이나 resources/read 같은 메서드별 필터, 서버별 필터, 자유 텍스트 검색도 되고요. 요청과 응답을 짝지어서 소요 시간을 재주기 때문에 어떤 도구 호출이 느린지 바로 보이고, 통계 화면에서는 메서드별 호출 수, 에러율, 도구별 p50/p95 지연시간까지 나와요.

실무에서 특히 반가운 기능 두 가지가 있는데요. 하나는 세션 캡처예요. 모든 트래픽을 JSONL 파일로 저장해뒀다가 mcpsnoop replay로 나중에 다시 열어볼 수 있어서, '아까 그 실패 재현해 봐요' 상황에 딱이죠. 다른 하나는 마스킹(redaction)이에요. 환경변수의 API 키나 인증 헤더 같은 민감한 필드를 설정으로 가린 뒤에 캡처 파일에 쓰기 때문에, 기록을 팀과 공유해도 비밀값이 새지 않아요. 서버 여러 개를 동시에 프록시해서 하나의 TUI에 태그 붙여 모아 보는 것도 되고요.

구현도 깔끔해요. Go 단일 바이너리에 TUI는 bubbletea로 만들었고, 특정 MCP SDK에 의존하지 않아요. 메시지를 일단 불투명한 JSON-RPC로 다루고 알려진 MCP 메서드에만 얇은 스키마 층을 얹는 방식이라, MCP 프로토콜 버전이 바뀌어도 잘 버티는 설계거든요. 라이선스는 MIT예요.

업계 맥락: 관측성이 에이전트 개발의 다음 격전지

웹 개발에 브라우저 개발자 도구의 네트워크 탭이 있고, API 개발에 Postman이 있듯이, 에이전트 개발에도 트래픽을 눈으로 보는 도구가 필요해지는 시점이에요. MCP Inspector 같은 공식 도구도 있지만 그건 서버를 직접 찔러보는 테스트 클라이언트에 가깝고, mcpsnoop처럼 실제 클라이언트와 서버 사이의 살아 있는 트래픽을 엿보는 관측 도구는 결이 달라요. 보안 관점에서도 의미가 있는데요, MCP 서버가 모델에게 실제로 어떤 데이터를 보내는지 감사(audit)하거나 도구 결과에 섞여 나가는 비밀값을 잡아내는 용도로 쓸 수 있거든요.

한국 개발자에게 주는 시사점

MCP 서버를 만들고 있거나 사내에 에이전트를 도입 중이라면 당장 넣어볼 만해요. 설정 한 줄이면 되니 부담도 없고요. 특히 '에이전트가 이상하게 동작하는데 어디서 꼬였는지 모르겠다' 싶을 때 프롬프트 탓인지, 도구 스키마 탓인지, 서버 응답 탓인지를 트래픽 수준에서 갈라낼 수 있다는 게 커요. MCP 프로토콜 자체를 공부하는 용도로도 좋아요. 실제 메시지가 흐르는 걸 보는 것만큼 빠른 학습법이 없거든요.

한줄 요약: MCP 클라이언트와 서버 사이에 유리창을 하나 끼워 넣는 도구, 설정 한 줄이면 에이전트 디버깅이 감에서 관측으로 바뀐다.

여러분은 MCP 서버 디버깅할 때 어떻게 하고 계세요? 이런 관측 도구가 에이전트 개발 표준 스택에 들어가야 한다고 보시나요?


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://github.com/kerlenton/mcpsnoop
SHARE
처리 중...