MCP 서버 관측성은 장애가 났을 때만 쓰는 장식이 아닙니다. 호출 흐름, 도구 선택, 승인 여부, 실패 복구를 이어 붙여야 에이전트 품질을 유지할 수 있습니다. 로그가 있어도 연결이 안 되면 디버깅은 느립니다.
이 글은 MCP 서버의 tracing, audit log, failure replay를 하나의 관측성 체계로 묶어 설명합니다. Remote MCP Architecture와 MCP Debugging를 함께 보면 구조가 더 선명해집니다.
이런 분께 추천합니다 #
- MCP 서버 장애를 빠르게 재현하고 싶은 팀
- 호출 추적과 감사 로그를 함께 관리해야 하는 개발자
MCP observability,tracing,audit log,failure replay를 정리하려는 분
개요 #
관측성은 세 가지 질문에 답해야 합니다.
- 누가 어떤 도구를 호출했는가
- 어떤 입력과 출력이 오갔는가
- 실패가 어디서 시작됐는가
이 질문에 답할 수 있으면 서버 문제와 에이전트 문제를 분리해서 볼 수 있습니다.
왜 중요한가 #
MCP는 도구 호출의 경계가 분명해서 좋아 보이지만, 관측성을 빼면 오히려 원인 파악이 어려워집니다.
- 호출은 성공했는데 결과가 이상한 경우가 있습니다.
- 승인 단계에서 막혔는데 왜 막혔는지 남지 않는 경우가 있습니다.
- 여러 MCP 서버를 쓰면 어느 서버에서 실패했는지 헷갈립니다.
- 재현용 입력이 없으면 같은 장애를 다시 만들 수 없습니다.
그래서 관측성은 운영의 마지막 단계가 아니라 첫 설계 단계입니다.
운영 방식 #
관측성은 다음 순서로 설계하는 것이 좋습니다.
- request id와 session id를 통일합니다.
- tool call, approval, error를 같은 trace에 묶습니다.
- audit log에는 사용자와 도구, 시간을 남깁니다.
- failure replay용 샘플 입력을 저장합니다.
- 대시보드에서 오류 유형별로 분류합니다.
Cloudflare MCPAgent는 edge와 session을 묶는 데 좋고, OpenAI Remote MCP는 승인과 도구 호출을 추적하는 패턴을 이해하는 데 도움이 됩니다. FastMCP를 함께 보면 서버 측 로그 구조도 잡기 쉽습니다.
아키텍처 도식 #
workflow는 관측 데이터가 어디서 수집되고 어디로 흘러가는지 보여줍니다.
choice-flow는 tracing, audit, replay 중 무엇을 먼저 구현할지 정리합니다.
architecture는 서버, 로그 저장소, 대시보드의 역할 분리를 보여줍니다.
체크리스트 #
- request id와 session id가 남는가
- 승인 여부가 trace에 포함되는가
- 실패 재현 입력을 저장하는가
- 도구별 latency를 볼 수 있는가
- 오류 유형별로 alert를 보낼 수 있는가
- audit log 보존 정책이 있는가
- 재현 가능한 최소 샘플이 남는가
결론 #
MCP 서버의 관측성은 “문제가 생기면 확인한다"가 아니라 “문제를 나눠서 보고, 재현하고, 복구한다"입니다. tracing, audit log, replay가 같이 돌아가야 MCP 운영이 실제로 안정화됩니다.