Cursor가 API 필드명을 깔끔하게 바꿔치기했다. 테스트는 전부 통과했고, PR diff는 완벽해 보였다. 문제는 2주 뒤 모바일 클라이언트와 파트너 통합이 조용히 무너지고 나서야 드러났다. dev.to에 공개된 사례인데, 읽으면서 "아, 나도 이럴 수 있겠다"는 생각이 먼저 들었다. 에이전트는 빠르고 두려움이 없다. 그리고 당신의 API 컨트랙트에 대해서는 완전히 무지하다.
이 문제를 구조적으로 뜯어보면 세 가지 한계가 동시에 작동하고 있다. Breaking Change 미감지, 에이전트의 자체검증 불가능성, 그리고 검증 비용의 폭주다. 각각 독립된 이슈처럼 보이지만, 실제로는 같은 뿌리에서 나온다. 에이전트는 코드 컨텍스트 안에서만 사고하고, 그 바깥의 현실—다운스트림 소비자, 자신의 실제 실행 상태, 검증 비용—을 감지하는 독립적인 채널이 없다.
첫 번째 한계: 에이전트는 컨트랙트가 아니라 코드를 본다
OpenAPI 스펙을 diff해서 제거된 엔드포인트, 응답 필드 삭제, request 타입 강화, enum 축소 같은 클래식한 Breaking Change를 잡는 건 사람이 수동으로 하던 일이었다. 에이전트는 그 과정을 건너뛴다. 코드가 컴파일되고, 내 테스트가 통과하면 끝이다. 소비자의 테스트가 깨지는 건 에이전트 루프 밖의 일이다.
이 갭을 메우기 위해 specshield-mcp-server라는 MCP 도구가 공개됐다. Model Context Protocol을 통해 에이전트가 is_change_safe 툴을 직접 호출해서, 변경 전에 "이 API 변경을 소비자에게 배포해도 안전한가?"라는 질문에 답을 받는 방식이다. 결과는 단순하다—safeToMerge: false, riskLevel: CRITICAL, 차단 이유와 권장 액션. 커밋하기 전에, 타이핑하는 도중에 잡는다.
여기서 핵심 아이디어는 배포 게이트를 에이전트 루프 안으로 끌어들이는 것이다. CI 단계에서 보는 경고는 이미 맥락을 잃은 뒤다. 에이전트가 변경을 만드는 바로 그 순간이 "이게 안전한가?"를 물어야 할 자리다.
두 번째 한계: 에이전트는 구조적으로 자신을 검증할 수 없다
Claude Code로 50회 이상 장기 세션을 돌린 개발자의 관찰은 더 근본적인 문제를 드러낸다. 에이전트는 점차 드리프트한다. 초반에 설정한 규칙을 잊고, config 파일은 배포됐다고 주장하지만 실제로는 훅에 연결조차 안 됐고, 자기 평가와 현실이 벌어진다. HOT 항목 13개라고 했는데 실제는 53개였다.
처음엔 기계적 게이트를 쌓았다—실행 게이트, 훅 감사, 품질 게이트, 클레임 게이트. 효과는 있었다. 그런데 모든 문제의 형태가 동일했다: "나는 X라고 주장했지만 X는 사실이 아니었다." 게이트를 계속 추가하는 규칙 인플레이션이 시작됐다.
철학자 한 명이 핵심 질문을 던졌다. "에이전트가 자기 평가를 생성하는 디코더와 코드를 생성하는 디코더가 같은데, 독립적인 검증 채널이 어디 있냐?" 없다. 트랜스포머 기반 에이전트는 자기 모델 서술과 실제 실행 능력을 같은 P(token | context; θ)에서 샘플링한다. "나는 X를 할 수 있다"는 주장과 X를 실제로 하는 행위가 같은 분포에서 나온다. 이걸 Prose Barrier라고 부른다. 이건 버그가 아니라 구조적 제약이다.
Pearl의 인과 계층으로 표현하면, 에이전트의 자기 평가는 L1(연관)이고, 신뢰성 검증은 L2(개입)을 요구한다. do(execute) → observe exit code. 에이전트가 자신의 성장 로그를 다시 읽어서 자기 모델을 재생성할 때, 그것은 측정이 아니라 거울을 보는 것이다.
해법으로 제시된 이중 레이어 아키텍처는 흥미롭다. 파일시스템 레이어(mtime, 훅 연결, exit code)는 "정보가 문 앞에 도달했는가?"를 NL 주장을 우회해서 확인한다. 신경망 레이어(제약 echo 감지, logprob 차이, 잔차 스트림 프로브)는 "정보가 집 안을 실제로 통과했는가?"를 묻는다. 두 레이어는 독립적이어야 한다. 같은 채널을 공유하면 Prose Barrier를 그대로 재현하는 것이기 때문이다.
세 번째 한계: 검증이 비용이 되는 AI 제품의 딜레마
AI 위에 AI를 얹은 제품을 테스트하는 건 차원이 다른 문제다. 한 과정 제품 팀은 5개 과제를 완주하는 E2E 테스트를 돌릴 때마다 라우팅, 전문가 응답, 평가자 호출이 모두 실제 모델 콜로 발생한다는 걸 깨달았다. 테스트를 늘릴수록 비용이 선형으로 늘어난다.
이들의 해법은 "전체를 목(mock)하지 않고 가장 비싼 한 레이어만 교체"였다. Playwright로 실제 데스크톱 앱을 구동하되, window에 노출된 chat provider를 가로채서 모델 콜 대신 스크립트 응답을 돌려준다. UI, 메시지 플로우, 타임라인, 루브릭—모든 것이 실제로 실행된다. 빠진 건 청구서뿐이다.
여기서 정직한 가드레일이 핵심이다. 매칭되지 않는 메시지가 실제 provider로 fall-through되면 "무료처럼 보이지만 몰래 돈 내는" 테스트가 된다. 그게 더 위험하다. 믿는 사이에 비용이 올라가기 때문이다. 그래서 하네스는 엄격하다—매칭 실패 시 실제 모델에 절대 위임하지 않고, 평가자가 진짜로 인터셉트됐는지 단언한다. 테스트 프로젝트 이름에도 no-credit을 박아 넣었다.
가드레일 설계의 공통 원리
세 사례를 겹쳐보면 하나의 패턴이 나온다. 에이전트의 루프 안에 독립적인 검증 지점을 주입하라.
- API 컨트랙트 검증은 에이전트가 변경을 생성하는 순간 MCP 툴 호출로 끌어들인다
- 에이전트 자기 평가는 NL 채널이 아닌 파일시스템 상태와 신경망 신호로 이중 검증한다
- 테스트 비용은 "모두 가짜"가 아니라 "가장 비싼 한 지점만 교체"로 통제한다
공통점은 신뢰를 기대하지 않고 구조로 강제한다는 것이다. 에이전트를 믿으려고 애쓰는 게 아니라, 에이전트가 틀렸을 때 그 신호가 자동으로 가시화되는 경로를 설계한다.
전망: "왼쪽으로 이동"의 다음 단계는 에이전트 루프
우리는 10년 동안 검증을 "왼쪽으로 이동"시켰다—프로덕션에서 CI로, CI에서 pre-commit 훅으로. AI 에이전트는 그 다음 "왼쪽"이다. 변경이 만들어지는 곳, 에이전트 루프 안이 이제 검증이 살아야 할 자리다.
문제는 우리의 안전 도구 대부분이 아직 거기까지 따라오지 못했다는 거다. MCP 기반 deploy gate, Prose Barrier를 우회하는 이중 검증 아키텍처, 모델 레이어만 교체하는 테스트 하네스—이 세 접근법은 각각 다른 문제를 풀지만 같은 방향을 가리킨다. 에이전트 속도를 늦추는 게 아니라, 에이전트가 자신도 모르게 만드는 리스크를 에이전트 루프 안에서 잡는 것.
빠른 프로토타이핑 → 사용자 검증 → 고도화 흐름에서 AI 도구의 진짜 가치는 속도에 있다. 그 속도를 신뢰할 수 있게 만드는 건 검증 레이어를 얼마나 잘 설계했느냐에 달려 있다. 에이전트를 믿기 전에, 먼저 설계해야 할 건 그 믿음이 깨졌을 때 울리는 알람이다.