MCP 명세의 재시도 안전성

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Fabian Williams의 MCP storefront는 Claude Desktop과 오프라인 Qwen3.6 27B에서 같은 감사 영수증을 반환했지만, Nexum의 명세 규칙을 적용하자 purchase_free_bundle에 Idempotency-Key가 없어 timeout 재시도 때 번들과 이메일이 중복 발급되는 문제가 드러났다. IP별 시간당 5회 제한과 하루 5달러 상한은 호출량과 비용만 제어해 이 구조적 결함을 잡지 못했다. 수정안은 스키마와 HTTP header에 멱등성 키를 추가하고 Azure Table Storage와 Blob storage로 성공 결과를 재생하며 실패 결과는 캐시하지 않는다. 다만 동시 요청 중복과 TTL 부재가 v1의 한계로 남아 정적 명세 검사와 런타임 방어를 함께 운용해야 한다.

섹션별 상세

MCP callable endpoint가 Claude Desktop과 오프라인에서 실행한 Qwen3.6 27B 양쪽에서 동일한 감사 영수증을 반환했지만, 실행 결과만으로는 명세 단계의 재시도 위험을 포착하지 못했다. Fabian Williams는 공개 전인 Nexum scanner의 다섯 가지 규칙을 storefront의 purchase_free_bundle 명세에 수동 적용했고, 네 가지 규칙은 통과하거나 해당되지 않았지만 NEXUM-004 IdempotencyMissing이 HIGH로 판정됐다. 이 사례는 같은 엔드포인트가 보안 감사와 금융 청구라는 두 소비자를 지원할 때 호출 주체가 에이전트인지와 별개로 입력 명세의 안전성이 중요하다는 점을 드러낸다.

purchase_free_bundle은 영수증 발급, Brevo 연락처 upsert, JOSE 서명 다운로드 토큰 생성, fulfillment email 발송을 한 번에 수행하는 변경형 MCP tool이다. 그러나 inputSchema에 Idempotency-Key가 없어 timeout 뒤 LLM SDK의 기본 재시도가 발생하면 같은 bundle과 이메일이 두 번 발급될 수 있었다. IP별 시간당 5회 제한과 하루 5달러 비용 상한은 두 번의 재시도가 각각 제한과 비용 문턱 아래에 머물기 때문에 이 중복 실행을 차단하지 못했다.

수정 PR #1은 inputSchema에 8~128자 길이와 [A-Za-z0-9._-] 패턴을 갖는 선택적 idempotency_key를 추가하고, /api/a2a/mcp와 /api/a2a/purchase에서 표준 Idempotency-Key HTTP header도 받도록 바꿨다. 두 값이 함께 있으면 tool argument를 우선하며, 유효한 키는 input validation보다 먼저 Azure Table Storage에서 조회한다. 기존 성공 영수증이 있으면 Blob storage에서 원본을 그대로 반환하고, 실패 결과는 저장하지 않아 일시적인 Brevo 장애 뒤 재시도가 정상 흐름을 다시 실행하도록 구성했다.

v1 구현은 캐시 조회 실패나 저장 실패를 오류로 노출하지 않고 삼키는 fail-open 정책을 사용한다. 같은 키를 가진 동시 요청은 모두 캐시를 놓칠 수 있어 두 흐름이 실행되고, 테이블에서는 last-write-wins가 적용되며 Blob storage에도 영수증 두 개가 기록될 수 있다. 또한 table TTL이 없어 매핑을 수동 정리해야 하므로, v2에서는 optimistic concurrency로 processing 상태를 선점하고 충돌 요청에 409를 반환하는 잠금과 10k+ rows 규모 이후의 TTL 검토가 필요하다.

이 사례에서 rate limit과 cost ceiling은 호출 빈도와 비용을 제어하지만 한 번의 호출이 재시도에 안전한지는 판단하지 못한다. 반면 정적 명세 검사는 첫 번째 에이전트 호출 전에 입력 스키마에 멱등성 식별자가 빠졌는지 확인해 런타임 통제가 놓치는 중복 부작용을 찾는다. 따라서 Nexum Cert의 전제는 런타임 거버넌스를 대체하는 단일 검사보다 서로 다른 실패 유형을 겨냥하는 defense-in-depth에 가깝다.

용어 해설

멱등성 키(Idempotency-Key): — 같은 요청을 여러 번 보내도 작업 결과가 한 번만 생성되도록 요청을 식별하는 값이다. 서버는 키를 저장한 뒤 동일 키가 다시 들어오면 작업을 재실행하지 않고 최초 성공 결과를 반환한다. 결제·파일 발급·이메일 발송처럼 재시도 때 중복 부작용이 생기는 작업에 중요하다.
정적 분석(Static Analysis): — 프로그램이나 도구의 실행 없이 소스 코드와 명세 구조를 검사해 잠재적 문제를 찾는 방식이다. 이 글에서는 MCP 도구의 inputSchema에 필요한 안전장치가 있는지 확인한다. 요청량이나 비용을 관찰하는 런타임 제어와 달리 실행 전 구조적 결함을 발견할 수 있다.
심층 방어(Defense in Depth): — 하나의 보안 통제에 의존하지 않고 서로 다른 계층의 방어 수단을 겹쳐 배치하는 전략이다. Rate limit과 비용 상한은 호출량을 제한하고, 명세 검사는 재시도 안전성과 같은 구조적 조건을 확인한다. 각 통제가 놓치는 실패 유형이 다르므로 함께 적용할 때 보호 범위가 넓어진다.
재생 의미론(Replay Semantics): — 동일한 요청 식별자가 다시 들어왔을 때 서버가 어떤 결과를 돌려줄지 정하는 동작 규칙이다. 구현에 따라 최초 결과를 그대로 반환하거나 요청을 다시 실행할 수 있다. 이 글의 방식은 성공한 원본 영수증을 Blob storage에서 읽어 변경 없이 반환한다.
낙관적 동시성 제어(Optimistic Concurrency): — 충돌이 드물다고 보고 작업을 진행한 뒤 저장 시점에 다른 요청의 변경 여부를 확인하는 동시성 처리 방식이다. 같은 Idempotency-Key 요청이 동시에 캐시를 놓치는 문제를 막으려면 처리 중 상태를 기록하고 충돌 요청에 409를 반환하는 데 활용할 수 있다. 글에서는 이 기능을 v2 보강 계획으로 제시한다.

기술

MCP
Claude Desktop
Qwen3.6 27B
Nexum scanner
Brevo
JOSE
Azure Table Storage
Blob storage

활용 사례

무료 번들 발급 도구의 중복 실행 방지
에이전트가 호출하는 결제·다운로드·이메일 발송 workflow
MCP tool 명세의 정적 안전성 검사