AI-First 전환을 선언한 팀이 가장 많이 하는 착각이 있다. 도구를 도입한 순간 설계가 끝났다고 생각하는 것이다. Cursor를 쓰고, Claude Code를 붙이고, MCP 서버를 연결하면 그다음은 자동으로 굴러간다는 믿음. 프로덕션은 그 믿음을 조용히—그리고 가끔은 매우 시끄럽게—부수는 곳이다.
이번 주 세 개의 기사가 각자 다른 각도에서 같은 문제를 가리켰다. MCP 위임 체인의 보안 공백(dev.to), Self-Healing 테스트의 신뢰 경계(dev.to), 그리고 Claude Code의 토큰 과금 구조(dev.to). 세 주제는 겉으로 달라 보이지만 실은 하나의 질문으로 수렴한다. AI 도구를 켠 뒤 팀이 설계하지 않으면 무엇이 터지는가?
1. MCP 위임 체인: 아무도 감사하지 않는 권한 이동
에이전트가 뚫린 게 아니었다. 모델이 뚫린 것도, 툴이 뚫린 것도 아니었다. 모든 컴포넌트가 설계된 대로 정확히 동작했다. 그런데도 아무도 승인하지 않은 액션이 실행됐다. 이게 MCP 보안 논의에서 가장 불편한 부분이다. 패치할 구현 결함이 없다.
CVE-2025-49596(CVSS 9.4)은 Anthropic 공식 MCP SDK에서 발견된 RCE 경로였다. 핵심은 취약한 구현이 아니었다. SDK가 신뢰 모델을 스펙 수준에서 잘못 가정했다는 것이다. 구현은 스펙과 일치했고, 스펙이 틀렸다. 패치는 현재 표현을 닫을 뿐, 같은 신뢰 가정 위에서 동작하는 다음 표현은 여전히 취약하다.
문제의 구조는 네 가지 실패 상태로 정리된다. 도구가 선언된 권한 범위 밖에서 호출되는 스코프 크리프 위임, 오케스트레이터의 자격증명이 툴 실행 컨텍스트로 그대로 넘어가는 암묵적 신뢰 상속, 배포 없이는 권한을 회수할 수 없는 비취소 위임, 그리고 실행 후 권한 이동 경로를 재구성할 증거 자체가 없는 권한 체인 불투명성이다. 마지막 상태가 가장 위험하다. 나머지 셋은 경계가 무너졌다는 걸 설명하고, 이것은 왜 아무도 그 사실을 모르는지를 설명하기 때문이다.
테크 리드 입장에서 실질적으로 점검해야 할 질문은 하나다. 지금 우리 에이전트 시스템이 호출할 수 있는 모든 툴의 목록을 만들 수 있는가? 각 툴에 부여된 권한 범위와 회수 가능 여부까지? 대부분의 팀이 이 질문에 답하지 못한다. 그 자체가 노출 수준이다. Copilot Studio, Bedrock Agents, LangChain 기반 워크플로우에서 외부 MCP 서버를 소비하는 구성은 이미 Medium~Extreme 노출 구간에 있다.
2. Self-Healing 테스트: 자동 수복이 버그를 숨기는 순간
"Self-Healing 테스트"는 요즘 가장 과장된 마케팅 용어 중 하나다. 팀은 테스트 실패가 마법처럼 사라지는 미래를 상상하지만, 현실은 훨씬 좁다. 자동 수복 시스템이 실제로 잘 처리하는 건 구조적 변경이다. JSON 필드 이름 변경, 선택적 프로퍼티 추가, 엔드포인트 경로 업데이트. 이것들은 의도된 진화이고 자동화할 수 있다.
위험한 구간은 세 곳이다. 비즈니스 로직 변경, 누락된 비즈니스 결과, 보안 관련 실패. 어제 20이던 할인율이 오늘 10이 됐을 때, 비즈니스 규칙이 바뀐 건지 버그가 생긴 건지 테스트 실패만 보고는 알 수 없다. Self-Healing 엔진이 "값이 바뀌었으니 기댓값을 업데이트하겠습니다"라고 판단하는 순간, 테스트는 통과되고 버그는 프로덕션에 탄다.
실용적인 접근은 신뢰도 점수 기반 임계값이다. 95~100% 신뢰도면 자동 적용, 75~95%면 사람에게 승인 요청, 75% 미만이면 수동 조사 강제. 필드 이름 변경처럼 의미 유사도·타입 일치·위치 패턴이 모두 맞아떨어지는 경우(신뢰도 96%)는 자동화해도 된다. 하지만 accountBalance가 availableCredit으로 바뀌었다는 제안이 올라왔을 때, 이 둘은 비슷해 보이지만 전혀 다른 개념이다. 사람이 1분이면 검토할 수 있다.
핵심 원칙은 간단하다. 비즈니스 어설션은 절대 자동 수복하지 않는다. False Positive가 줄면 시간이 절약된다. 하지만 False Success가 늘면 버그가 출시된다. 성숙한 QA 조직은 이 트레이드오프에서 항상 후자를 더 나쁘게 본다. Self-Healing의 목적은 사람의 일을 줄이는 것이지, 사람의 감시를 없애는 것이 아니다.
3. Claude Code 토큰 과금: 멀티 에이전트 워크로드에서 수학이 달라진다
1~2명이 간헐적으로 Claude Code를 쓰는 구성에서 토큰 과금은 체감되지 않는다. 문제는 팀 단위 병렬 세션, 긴 컨텍스트를 공유하는 멀티 에이전트 파이프라인으로 확장할 때다. 이때 월 과금이 $200을 넘기는 건 어렵지 않다.
한 팀이 이 문제를 OAuth 심(shim) 패턴으로 해결한 사례가 공개됐다. Claude Max 구독(월 $100~$200, 정액제)은 브라우저 OAuth 플로우만 제공하고 API 키를 주지 않는다. 이 팀은 FastAPI 기반 ~200줄짜리 래퍼를 만들어 Max 구독의 Bearer 토큰을 Anthropic Messages API 인터페이스로 브리지했다. 에이전트 코드는 ANTHROPIC_BASE_URL과 공유 시크릿만 바꾸면 되고, 나머지 인터페이스는 1:1로 동일하다.
이 패턴을 그대로 따라하라는 게 아니다. 주목할 부분은 비용 구조 자체를 설계 대상으로 봤다는 관점이다. 토큰 과금 vs. 정액제의 손익분기점은 팀의 워크로드 믹스에 따라 다르다. 공개된 사례에서도 "우리 숫자를 일반화하지 말라, 직접 계산하라"고 명시했다. 멀티 에이전트 운영을 시작하기 전에 토큰 사용량을 측정하고, 정액제 전환 시점을 사전에 정의해두는 것이 핵심이다.
한 가지 현실적인 경고도 있다. 이 심은 단일 조직 내 팀 사용을 위한 구조다. 멀티테넌트 API, 사용자별 과금, 감사 로그가 필요하다면 이 200줄로는 부족하다. Max 플랜이 부과하는 요율 제한도 우회되지 않는다. 도구가 아니라 비용 설계 패턴으로 참고하는 게 맞다.
공통 진단: 설계 없이 운영하면 어디서 터지는가
세 문제를 나란히 놓으면 패턴이 보인다. MCP는 권한 위임 체인을 설계하지 않으면 아무도 실행을 승인하지 않은 액션이 조용히 발생한다. Self-Healing 테스트는 수복 경계를 설계하지 않으면 테스트가 통과하면서 버그를 숨긴다. 토큰 과금은 비용 구조를 설계하지 않으면 스케일업 시점에 고지서가 먼저 알려준다.
세 경우 모두 AI 도구 자체의 문제가 아니다. 도구는 설계된 대로 동작한다. 문제는 팀이 그 도구를 운영 환경에 올리기 전에 물어야 할 질문을 건너뛰었다는 점이다. 권한 체인을 감사할 수 있는가, 수복과 방치의 경계는 어디인가, 스케일업 시 비용이 어떻게 움직이는가. 이 질문들은 개발 환경에서는 티가 나지 않는다. 프로덕션에서만 터진다.
AI-First 팀이 지금 설계해야 할 것은 도구 선택이 아니라 운영 레이어다. 권한 체인 감사 구조, 자동화의 신뢰도 임계값, 비용 모니터링과 전환 기준점. 이 세 가지를 운영 전에 정의한 팀과 그렇지 않은 팀의 차이는 스케일이 커질수록 벌어진다.