지난 기사로부터

지난번에는 AI 에이전트에게 0.001 USDC로 외부의 유료 MCP 도구를 구매하게 하는 이야기를 했습니다. 결제 자체는 작동했습니다. 작동하지 않은 것은 그 이후의 신뢰——판매자가 누구인지, 돌아온 데이터가 올바른지, 틀렸을 때 어떻게 구제할 것인지와 같은 부분이 기계 판독 가능하게 갖춰져 있지 않다는 점입니다.

그 신뢰의 부품 중 하나가 manifest입니다. 각 MCP 서버가 "자신이 어디에 쓰이는지·네트워크에 연결되는지·서브 프로세스 (Subprocess)를 실행하는지"를 적어두는, 그 선언 파일 말입니다.

지난번에는 외부 판매자를 살펴보았습니다. 이번에는 자신의 환경을 살펴봅니다.

기사 요약 (3줄 요약)

• AI 에이전트에게 작성하게 한 MCP 서버 69개를 정적 감사(Static Audit)한 결과, 선언과 실태가 어긋난 사례가 73건 발견됨
• 어긋난 사례의 3분의 2는 네트워크 관련. 작성자가 "HTTP를 추가하자"라고 결정한 케이스는 거의 없었으며, 의존 관계 (Dependency)가 멋대로 표면적 공격 접점 (Surface)을 가져온 것임
• 가장 많은 사례는 감사 도구 자체 (73건 중 46건). 1년간 리뷰를 해왔지만 인력으로는 단 1건도 찾아내지 못함

69개에 대한 정적 감사

지난 1년간 개인의 운영 환경에서 69개의 MCP 서버를 돌리고 있습니다. 대부분 AI 코딩 에이전트에게 작성하게 한 것들입니다. 각각 manifest도 가지고 있습니다 (AOS 계열의 capability 스키마).

2026년 7월 중순, 69개 전부를 대상으로 동일한 정적 감사를 실시했습니다. manifest에 적혀 있는 내용과 코드상에서 보이는 동작을 대조하여, 어긋난 부분을 모두 집계했습니다.

결과는 73건이었습니다.

69개 중 11개에서만 나타났습니다. 악의적인 사례는 단 한 건도 없었습니다. 전부 방치하면 manifest가 낡아질 뿐인 문제입니다.

다만, 가장 많았던 것이 감사 도구 자체였다는 점이 가장 큰 아이러니였습니다.

73건의 내역

감사 도구 자체가 46건이었습니다. dev 의존성 import를 통해, 선언되지 않은 네트워크 도달 가능 코드 경로가 조용히 쌓여 있었습니다.

검출 결과 읽는 법

이 73건은 곧바로 "실제로 인터넷에 접속한 횟수"는 아닙니다. 정적 분석은 보수적입니다.

• URL을 파싱하는 헬퍼(Helper)도 실제 소켓(Socket) 호출과 동일한 급으로 계산함
• 쓰기(Write) 검출에는 실제 존재하지 않는 경로의 리터럴이 섞임 (문자열 추출의 오검출)

따라서 network / write 관련은 많게 나오는 상한값으로 읽어주세요. 반대로, 읽기(Read) 계열의 어긋남은 독립된 클래스가 없고 일부는 쓰기(Write) 쪽으로 묶어서 기록했기 때문에, 73건보다 적을 가능성도 있습니다. 양쪽을 모두 더하면 진정한 어긋남의 수는 이 표만으로는 알 수 없습니다.

오검출 자체는 검출기의 교정 데이터가 되었으며, 이번 연습을 통해 자신의 스캐너 버그도 잡아낼 수 있었습니다.

1년간 왜 놓쳤는가

manifest를 수정하라고 CI가 화를 내지 않는 한, 선언은 작성한 날부터 낡아갑니다. "작동한다"와 "manifest대로 작동한다"는 별개의 문제이며, 후자는 일반적인 기능 테스트로는 보이지 않습니다. 테스트는 올바름을 보지만, 범위 내에 있는지는 보지 않습니다.

AI 코딩 에이전트도 검출기를 전달받지 않는 한 자신의 어긋남을 깨달을 수 없습니다.

이번 73건은 모두 도구 검출로 이루어졌으며, 인력 리뷰로 발견된 것은 0건이었습니다. 지난 1년간 저는 코드 리뷰도 해왔는데 말입니다. 부끄럽습니다.

"그저 오래된 문서일 뿐 아닌가?" Reddit에서의 지적

Reddit r/mcp에 먼저 올렸을 때, 정확히 이런 반론을 받았습니다. "자작 스키마의 선언을 본인이 업데이트하는 것을 잊었을 뿐이다. 무엇이 뉴스인가?"

확실히 일리가 있는 말씀입니다. 정면으로 마주하고 싶습니다.

이번 인사이트는 "문서는 부패한다"는 사실 그 자체가 아니라, 부패하는 방식에 있습니다. AI 생성 코드 1년 치로 73건. 3분의 2가 네트워크 관련이며, 그 대부분은 작성자의 의도가 아닌 의존 패키지를 경유합니다. 작성자가 "HTTP를 호출하자"라고 결정하는 순간은 거의 없으며, 네트워크 도달 가능 면만 계속해서 늘어납니다.

단순히 자체 스키마(Schema)의 문제로 국한되지 않습니다. 선언형 capability 스키마라면 무엇이든——MCP 본체 사양에서 논의 중인 tool risk metadata (SEP-2793)를 포함하여——동일한 역학에 노출됩니다. "manifest를 작성하면 끝"이라고 생각한다면, 이 정도 속도로 괴리가 발생합니다. 이것이 스키마 설계의 입력값이 되어야 한다는 이야기입니다.

manifest를 빌드 결과물로

해당 스레드에서 실무자(dark-epiphany 님)로부터 다음과 같은 답글이 있었습니다.

문서는 "썩어도 아무것도 망가지지 않기" 때문에 썩는다. manifest를 문서가 아니라 빌드 결과물(Build Artifact)로 취급하라. 동일한 정적 분석(Static Analysis)을 CI에서 실행하고, 선언과 실제 동작이 괴리되면 빌드를 실패시켜라. 그러면 부패가 "잊혀진 TODO"가 아니라 "실패하는 테스트"가 되므로, 선언은 정확한 상태를 유지할 수 있다.

이는 감사 도구 측에 이미 구현된 blocking 모드와 동일한 결론입니다. 외부의 사람도 독립적으로 같은 지점에 도달해 있었습니다.

"네트워크 집중은 대부분 의존성(Dependency)을 경유한다"는 관측도 일치합니다. 이는 capability 선언을 작성자의 의도보다 import / 런타임 레이어(Runtime Layer) 관점에서 바라봐야 한다는 설계론으로 이어집니다. SEP-2793에 대한 실측 데이터를 제공하게 된 것도 이 지적이 시발점이 되었습니다.

자신의 MCP로 테스트하기

pip install mcp-blast-radius
git clone --depth 1 https://github.com/YOUR_ORG/YOUR_MCP_SERVER.git /tmp/my-mcp
mcp-blast-radius-gate --gate-mode advisory --target-dir /tmp/my-mcp

(src/가 아니라, 리포지토리의 실제 패키지 루트를 지정해 주세요. manifest를 포함하고 있는 경우, 출력되는 JSON의 blocking 배열에 DIVERGENCE:가 괴리 목록으로서 나열됩니다.)

정적 분석만 수행하며, 대상은 수정하지 않고, 외부 전송은 전혀 없습니다. 자신의 MCP를 하나 clone 하여 적용해 보는 것이 가장 빠릅니다.

요약

지난번 0.001 USDC로 확인한 것은 "결제의 루프는 오늘 닫힌다"는 것이었습니다.

이번 73건을 통해 확인한 것은 "신뢰의 측면은 내버려 두면 닫히기는커녕 열려 버린다"는 것입니다. manifest는 작성하는 것만으로는 지켜지지 않습니다. 괴리를 "실패하는 테스트"로 바꾸기 전까지, 선언은 그저 메모에 불과합니다.

69개를 직접 세어보며, 그것을 스스로 실감했습니다.

관련 링크

• 이전 글— AI 에이전트에게 0.001 USDC로 외부 도구를 구매하게 해보았다: 마이크로페이먼트(Micropayment) 실증 실험
• MCP Blast-Radius Auditor— 외부 MCP를 도입하기 전의 폭발 반경 체크: aos-standard/mcp-blast-radius

감사받기를 원하는 MCP 서버가 있다면, GitHub Issue로 알려주시면 매우 기쁘겠습니다.

Discussion