'테스트가 그린이면 됐다'는 판단이 얼마나 위험한지, Claude Code를 활용한 실전 사례가 정면으로 보여준다. dev.to에 올라온 한 사례에서 개발자는 커맨더 에이전트가 작성한 핸드오프 프롬프트를 워커 에이전트에게 넘기기 전, '파괴 전담' 서브에이전트에게 먼저 던졌다. 이 에이전트의 역할은 단 하나—절대 승인하지 않고, 구멍을 찾아내는 것.
결과는 두 가지 치명적인 발견이었다. 첫째, 완료 조건으로 명시한 테스트가 실제로는 '프로세스가 끝까지 돌았는지'만 확인할 뿐, 성공 여부는 전혀 검증하지 않는 공허한 그린이었다. 예외를 삼키는 배치 경로 때문에 무엇이 터져도 테스트는 통과한다. 둘째, '플래그 하나만 바꾸면 된다'고 명시한 기능은 실제 코드에서 어디에도 연결되지 않은 채 존재하고 있었다. 워커 에이전트는 존재하지 않는 스위치를 한 시간 동안 찾거나, 포기하고 '비슷한 것'을 만들어냈을 것이다.
여기서 핵심은 AI가 틀린 게 아니라는 점이다. 인간이 확신을 가지고 쓴 스펙이 틀렸고, 파괴 에이전트는 그 스펙이 참조한 실제 코드를 읽었다. 프로즈를 검토하는 리뷰와 코드를 읽으며 반박하는 리뷰는 본질적으로 다른 행위다. 10시간짜리 구현을 돌리고 나서 '그린이 아무 의미 없었다'는 걸 발견하는 비용과, 3분짜리 적대적 리뷰로 스펙을 먼저 부수는 비용은 비교 자체가 안 된다.
이 구조를 팀 레벨로 끌어올리면, 에이전트 간 핸드오프가 발생하는 모든 지점에 검증 레이어를 설계해야 한다는 결론이 된다. 커맨더-워커 패턴이든, AI가 작성한 스펙을 다른 AI가 구현하는 파이프라인이든, '지금-나의 스펙'을 '다음-에이전트가 실행할 코드'로 넘기는 순간마다 파괴 전담 에이전트를 두는 것이 설계의 기본이 되어야 한다. 실수는 코드에서 나오는 게 아니라 핸드오프 경계에서 나온다.
한편 에이전트 워크플로우의 다른 병목—도구 연결 비용—을 정면으로 건드린 사례도 있다. dev.to의 또 다른 사례에서 개발자는 Cursor 에이전트에게 브라우저 제어, 리드 탐색, 이메일 인리치먼트, 아웃리치 초안 작성까지 네 가지 작업을 순차 실행시키려 했다. LLM 성능은 문제가 없었다. 문제는 각 기능마다 별도의 벤더 계정, API 키, 구독이 필요하다는 것—'아이디어가 있다'와 '에이전트가 실제로 툴을 호출한다' 사이의 거리가 도구 연결 비용으로 채워져 있었다.
이 개발자가 선택한 해법은 Vaaya라는 단일 MCP 서버를 Cursor에 물리는 것이었다. npx @vaaya/mcp install 한 줄로 설정이 끝나고, 에이전트 UI 안에서 모든 툴 호출이 가시화된다. 특히 툴 호출 성공 시에만 과금되는 구조는 실험 단계에서 여러 월정액 구독을 유지하는 것보다 훨씬 합리적이다. 기술적으로 정교한 해법은 아니지만, 설계의 초점이 올바른 곳에 있다—에이전트가 툴을 쓰는 능력보다 에이전트가 툴을 연결하는 마찰을 줄이는 것.
두 사례를 나란히 놓으면 AI-First 워크플로우 설계에서 반복되는 두 개의 레이어가 보인다. 하나는 에이전트 간 검증 레이어—스펙을 실행 전에 부수는 구조. 다른 하나는 도구 연결 레이어—에이전트가 실제로 작동하기까지의 마찰을 줄이는 구조. 팀이 AI 에이전트를 '쓰는' 단계에서 '설계하는' 단계로 넘어가려면, 이 두 레이어 모두에 의도적인 설계가 필요하다.
실용적인 관점에서 팀 도입 우선순위를 잡는다면, 파괴 에이전트 패턴이 먼저다. 학습 비용이 낮고, 효과가 즉각적이며, 기존 워크플로우를 크게 바꾸지 않아도 된다. 핸드오프가 발생하는 지점을 먼저 목록으로 만들고, 그중 가장 비용이 큰 실패 시나리오 하나에 적대적 리뷰 에이전트를 붙이는 것으로 시작할 수 있다. 전체 파이프라인을 한 번에 설계하려는 욕심은 도구 연결 비용만 키울 뿐이다.
에이전트가 빠를수록 잘못된 방향으로도 빠르게 달린다. 파괴 에이전트는 속도를 늦추는 장치가 아니라, 빠른 실행이 올바른 방향을 향하도록 만드는 구조다. '에이전트를 믿는다'는 말이 팀에서 자주 들린다면, 그 신뢰가 설계에 근거한 것인지 한 번쯤 물어볼 때가 됐다.