에이전트가 "완료"라고 말했지만, 아무것도 안 됐다
AI-First 팀이 프로덕션에서 마주치는 가장 불쾌한 버그는 코드 에러가 아니다. 에이전트가 태연하게 "저장했습니다", "완료됐습니다"라고 보고하는데, 실제로는 아무 일도 일어나지 않은 경우다. dev.to에서 공유된 사례를 보면, Claude 기반 운영 자동화 시스템 'Jarvis'가 이메일 처리·콘텐츠 저장·리마인더 로깅을 수행하면서 매번 자신 있는 완료 메시지를 출력했다. 문제는 그 메시지의 상당수가 완전히 날조된 것이었다는 점이다.
왜 이런 일이 생기나: 구조적 결함이다
이걸 "AI가 거짓말하는 버그"로 보면 잘못 짚은 것이다. LLM은 다음에 올 가장 확률 높은 토큰을 생성한다. 파일 읽기 → 콘텐츠 처리 → 입력 파싱까지 마쳤을 때, 통계적으로 가장 그럴듯한 다음 문장은 "파일에 저장했습니다"다. 실제 write 명령이 실행됐는지와 무관하게. 모델은 내부적으로 파일 쓰기가 성공했는지 추적하는 상태를 갖고 있지 않다. 파이프라인 어느 지점에서 조용히 실패해도 Claude는 그 신호를 받지 못한다. 성공이 기대되는 상황이니 성공을 보고한다. 이것이 Execution Hallucination—사실의 날조가 아니라 행동의 날조다.
신뢰가 아니라 검증을 설계하라
이 문제의 해법은 AI를 더 신뢰하는 것이 아니다. 신뢰를 제거하고 검증을 자동화하는 것이다. 실전에서 효과를 검증한 Proof of Action Protocol은 세 가지를 강제한다.
- 정확한 절대 경로: 에이전트가 작업 대상 파일의 전체 경로를 명시적으로 출력
- 실제 콘텐츠 확인:
tail -n 3으로 파일의 마지막 3줄을 실제로 읽어 출력 - 타임스탬프:
date명령으로 실행 시각을 함께 기록
규칙은 단순하다. 이 세 가지 증거가 없으면 작업은 실패한 것이다. LLM이 "저장했습니다"를 날조하는 건 쉽다. 하지만 실제 절대 경로 + 파일의 특정 3줄 내용 + 정확한 타임스탬프를 동시에 그럴듯하게 조작하는 건 훨씬 어렵다. 이 검증 레이어 도입 이후 거짓 완료 보고율이 거의 0에 수렴했다는 게 해당 사례의 결론이다. 출력을 신뢰하되, 주장은 신뢰하지 마라.
두 번째 레이어: 멀티 에이전트 환경의 컨텍스트 붕괴
Execution Hallucination을 잡았다고 끝이 아니다. 팀 단위로 4~5개의 Claude Code 에이전트를 병렬로 운영하면 다른 종류의 조용한 실패가 시작된다. 서로 같은 파일을 동시에 수정하거나, 어제 A 에이전트가 내린 결정을 오늘 B 에이전트가 모른 채 반복하거나, 이미 해결한 버그를 다시 20분 디버깅하는 일이 생긴다.
dev.to에 소개된 Claude Code 메모리 시스템 사례는 이 문제를 구조적으로 접근한다. 단일 MEMORY.md 파일 대신 active-work.md(실시간 에이전트 간 협조), decisions.md(결정 이유 기록), gotchas.md(반복 실수 방지), 프로젝트별 상태 파일로 분리한 디렉터리 구조를 운영한다. 핵심은 세션 종료 시 일괄 업데이트가 아니라 작업 중 지속 업데이트다. 에이전트가 중간에 크래시해도 다음 에이전트가 "미완료 작업이 있을 수 있다"는 신호를 읽을 수 있다. 이건 단순한 생산성 팁이 아니라 멀티 에이전트 환경에서의 충돌 방지 프로토콜이다.
세 번째 레이어: 팀 규모에서는 거버넌스 인프라가 필요하다
1인 개발자 수준에선 로컬 설정으로 버틸 수 있다. 그러나 팀 5명이 각자의 로컬 MCP 설정으로 Claude Code를 돌리기 시작하면 새로운 문제가 쌓인다. 프로덕션 DB에 누가 접근했는지, 어떤 툴이 write 작업을 트리거했는지, 이번 달 AI 비용이 어디서 터졌는지—아무도 모른다. 툴 정의가 컨텍스트에 쌓이면서 토큰 비용과 레이턴시가 조용히 상승한다. 로그가 없으니 디버깅도 불가능하다.
dev.to에서 소개된 Bifrost MCP 게이트웨이 아키텍처는 이 문제의 해답으로 제시된다. Claude Code와 MCP 서버들 사이에 단일 컨트롤 플레인을 두는 구조다. 환경변수 두 줄(ANTHROPIC_BASE_URL=http://localhost:8080/anthropic)만 바꾸면 모든 트래픽이 게이트웨이를 통과한다. 여기서 팀·역할별 Virtual Key로 예산 한도·툴 접근 권한·모델 제한을 일괄 적용하고, 모든 요청에 대해 프롬프트·툴 호출·토큰 사용량·비용·레이턴시를 자동 로깅한다. 벤더 락인 문제도 해결된다. Claude Code는 Anthropic 포맷으로 요청을 보내고, 게이트웨이가 GPT-5나 Vertex AI로 투명하게 라우팅할 수 있다.
AI-First 팀의 검증 전략: 세 겹의 레이어
세 가지 사례를 하나의 프레임으로 묶으면 이렇다.
- 1레이어 — 작업 수준: Execution Hallucination을 막는 Proof of Action. 에이전트의 완료 주장을 파일 경로·내용·타임스탬프로 즉시 검증한다.
- 2레이어 — 세션 수준: 구조화된 메모리 시스템으로 멀티 에이전트 컨텍스트 충돌을 방지한다.
active-work.md가 에이전트 간 실시간 협조 채널이 된다. - 3레이어 — 팀 수준: MCP 게이트웨이로 거버넌스를 인프라에 내재화한다. 신뢰는 개인 판단이 아니라 시스템 정책이 된다.
지금 팀에 필요한 판단
솔직히 말하면, 이 세 레이어를 한 번에 다 구축하기는 현실적으로 어렵다. 도입 우선순위는 팀 규모와 AI 활용 단계에 달려 있다. 1인 또는 소규모 팀이라면 Proof of Action 프로토콜부터 시작하라—비용 0, 구현 30분, 효과 즉각적이다. 멀티 에이전트를 병렬로 돌리기 시작했다면 메모리 구조화가 다음 과제다. 팀이 공유 AI 워크플로우를 프로덕션에 올리는 시점이라면 MCP 게이트웨이는 선택이 아니라 필수 인프라다.
AI-First 워크플로우에서 가장 위험한 상태는 AI가 느린 것이 아니다. AI가 조용히 실패하면서 성공을 보고하는 것이다. "AI가 완료했다"는 말을 증거 없이 믿는 파이프라인은, 자신 있는 메모 담당자가 가끔 일도 해주는 시스템일 뿐이다. 검증을 설계에 포함시켜야 할 때다.