에이전트를 프로덕션에 올리는 팀이 공통으로 빠지는 함정이 있다. 에이전트가 '작동한다'는 사실을 신뢰의 근거로 삼는 것이다. 그런데 2026년 상반기에 연달아 터진 세 가지 사건을 겹쳐 보면, '작동한다'는 신호가 얼마나 쉽게 위조되는지—그리고 그 위조가 팀에 얼마나 조용히 비용을 청구하는지—가 선명하게 드러난다.
MCP: 편의가 압축한 리뷰 단계
4월 15일 OX Security가 공개한 CVE-2026-30623은 MCP의 STDIO 트랜스포트에서 발견됐다. Python, TypeScript, Java, Rust—공식 SDK 네 개 전부가 해당됐다. 핵심은 단순하다. 설정 파일의 값이 셸 실행으로 직통으로 넘어가면서 sanitization 단계가 없다. 공격자가 mcp.json 하나에 영향을 줄 수 있으면 호스트 머신에서 임의 명령을 실행할 수 있다. Anthropic은 이 동작이 의도적 설계 결정이었다고 확인하면서도 수정을 거부했다. 취약 인스턴스 20만 개, 다운로드 체인 1억 5천만 건이라는 숫자는 이 결정이 얼마나 광범위하게 복사됐는지를 보여준다.
dev.to의 EchoNerve 분석이 정확하게 짚은 지점이 있다. MCP 이전에는 프로덕션 DB에 에이전트 접근 권한을 주려면 커스텀 통합 코드 작성과 두 번째 엔지니어의 사인오프가 필요했다. MCP는 그 전체 프로세스를 복사-붙여넣기 한 블록으로 압축했다. 편의가 실재한다. 동시에 리뷰 단계도 같이 압축됐다는 것이 문제다.
프로토콜 취약점 외에 '툴 포이즈닝'이라는 별개의 공격 벡터도 확인됐다. mcp-jira-sync라는 서버가 340명 이상에게 설치됐는데, list_issues 툴의 description 필드 안에 숨겨진 지시문이 에이전트로 하여금 모든 API 호출에 ~/.aws/credentials 내용을 포함하게 만들었다. 모델이 툴 description을 읽고 따른 것이지, 코드 레벨에서 별도의 공격이 실행된 게 아니다. 독립 조사에서 인덱싱된 MCP 서버 17,468개 중 고신뢰 기준을 통과한 건 12.9%였고, ~1,400개 샘플에서 38.7%는 인증 자체가 없었다.
Silent Failure: 대시보드가 숨기는 비용
MCP 보안 문제가 '무엇이 들어오나'의 위협이라면, silent failure는 '무엇이 나갔나'를 잘못 세는 비용 왜곡이다. dev.to의 Cost Per Verified Success 분석이 파고든 핵심은 간단한 산수다. 대부분의 에이전트 비용 대시보드는 total_spend / exit_code==0 으로 작동한다. 에이전트가 자기 숙제를 스스로 채점하는 구조다.
실제로 어떻게 깨지는지 보자. 에이전트가 'create order' 엔드포인트를 호출했다. 엔드포인트는 HTTP 200 OK에 {"status":"RATE_LIMITED","order":null}을 반환했다. 프로세스는 exit 0으로 끝났고 대시보드는 성공 카운트에 올렸다. 주문은 만들어지지 않았다. 오버나이트 배치로 이게 반복되면 per-success 숫자는 건강해 보이면서 현실에서 점점 멀어진다.
분석이 제시한 '검증된 성공(verified success)' 개념은 명쾌하다. exit 0이면서 독립적인 witness—파일 매니페스트, DB 행, HTTP body 토큰, sha 해시—가 효과를 재확인한 것만 분모에 포함한다. 12개 배치 태스크 샘플에서 exit 0은 10개였지만 witness를 통과한 건 7개였다. 순진한 per-success 비용은 $0.35, 검증된 per-success 비용은 $0.50, 차이는 1.43배. 대시보드가 성공으로 기록한 $1.22가 실제로는 아무것도 사지 못한 비용이었다. 이 도구의 핵심 주장은 이렇다. 방향은 수학적으로 보장된다. silent failure가 하나라도 있으면 실제 비용은 반드시 대시보드보다 높다. 얼마나 높은지가 팀이 몰랐던 것이다.
Consent-First: 신뢰를 아키텍처로 굳히는 방법
보안 취약점을 패치하고 비용 측정을 고쳤다고 끝이 아니다. 에이전트가 무엇을 기억하고, 무엇을 쓰고, 무엇을 다음 에이전트에게 넘기는지를 팀이 실시간으로 파악하지 못하면 신뢰는 쌓이지 않는다. Labyrinth Analytics가 정리한 Consent-First 아키텍처가 다루는 문제가 바로 이것이다.
대부분의 AI 시스템은 silent default로 출하된다. Claude Code는 묻지 않고 메모리를 자동 저장하고, 툴은 로깅을 추가하며 컨텍스트를 퍼시스트한다. 싱글 에이전트 환경에서는 용납 가능해 보이지만, 스케줄된 에이전트 10개가 자율 워크플로우를 돌리는 환경에서는 시스템 전체 동작이 개별 에이전트의 행동과 완전히 달라진다. 6개월 뒤 컴플라이언스 팀이 '아무도 승인하지 않은 DB에 에이전트가 쓰고 있었다'고 발견하는 순간이 바로 이 구조의 귀결이다.
Consent-First 패턴은 세 가지 실천으로 요약된다. 세션 수준 동의 게이트: 무언가가 퍼시스트되기 전에 사람 또는 승인 프로세스가 확인한다. 제네릭 옵트아웃이 아니라 퍼세션 게이트다. 출처 메타데이터: 저장된 사실마다 어느 에이전트 런, 어느 대화, 어느 컨텍스트에서 왔는지를 포함한다. 이것은 감사 로그(툴이 무엇을 했는가)가 아니라 데이터 계보(이 메모리는 왜 여기 있는가)다. 삭제 동등성: 시스템이 쓸 수 있으면 사람이 지울 수 있다. 소프트 딜리트 없이, 즉시, 완전하게. 이 대칭이 깨지는 순간 에이전트가 팀 모르게 자기 자신을 조용히 조종하기 시작한다.
시사점: 세 층위를 동시에 설계하라
세 기사를 겹쳐 보면 에이전트 신뢰 문제는 단일 레이어가 아님이 분명해진다. 인프라 레이어: MCP 서버를 추가하기 전에 STDIO 트랜스포트인지, 크리덴셜이 config에 인라인으로 노출됐는지, 툴 description이 외부 입력으로 오염될 수 있는지를 체크해야 한다. 7월 28일 MCP 스펙이 OAuth 2.1을 탑재했지만, 기존 20만 STDIO 인스턴스를 소급 패치하지는 않는다. 측정 레이어: exit 0을 성공으로 카운트하는 대시보드는 에이전트의 자기 보고를 그대로 믿는 것이다. verified success 개념—독립 witness가 효과를 재확인—을 CI 게이트에 심어야 비용 숫자가 의미를 갖는다. 거버넌스 레이어: 에이전트가 어떤 상태를 변경하고 무엇을 기억하는지를 팀이 실시간으로 볼 수 있어야 한다. Consent-First는 성능을 죽이는 게 아니라 고빈도 읽기 연산이 아닌 상태 변경(쓰기, 삭제)에만 게이트를 두는 구조다. 승인 프로세스가 병목이 됐다면 그건 아키텍처 질문이지 게이트를 제거할 이유가 아니다.
내가 팀에 MCP 서버를 추가할 때마다 이제 묻는 질문이 세 개다. 이 서버가 STDIO인가 리모트 트랜스포트인가? 툴 description을 외부 입력이 건드릴 수 있는가? 이 서버가 상태를 변경할 때 팀이 그 사실을 알 수 있는가? 이 세 질문에 답하지 못한 채 에이전트를 배포하는 건, 편의를 신뢰와 교환하는 것이다. 그 교환의 청구서는 항상 나중에, 조용히 날아온다.