에이전트가 코드를 짜고, 테스트를 돌리고, 초록 체크마크를 반환한다. 여기서 팀이 멈추면 안 된다. 초록 불은 '코드가 맞다'는 증거가 아니라 '에이전트가 자기 가정과 일치하는 코드를 썼다'는 증거일 뿐이다. 그 간극이 바로 팀이 메워야 할 지점이다.
에이전트의 자기 검증은 왜 구조적으로 실패하는가
dev.to에 올라온 한 솔로 개발자의 실험이 이 문제를 교과서처럼 보여준다. 그는 에이전트에게 코드를 짜게 한 뒤, 같은 에이전트에게 '독립 리뷰어' 역할을 맡겨 red-team 검수를 시켰다. 첫 번째 패스에서 에이전트는 자기 코드의 문제를 찾아 수정했다. 그런데 두 번째 패스를 돌리자 첫 번째에서 놓친 버그가 또 나왔다. 핵심 결론은 이렇다. 에이전트에게 자기 코드를 비판하는 도구를 줘도, 맹점은 제거되지 않는다. 처음부터 볼 수 있었던 문제만 드러날 뿐이다. 코드의 blind spot과 테스트의 blind spot은 동일한 가정에서 출발하기 때문이다.
더 근본적인 문제도 있다. 에이전트가 작성하는 테스트는 '현실이 던지는 것'이 아니라 '에이전트가 예상한 것'을 검증한다. 빈 문자열, null, 타임아웃, 레이스 컨디션—이런 경계 케이스는 실제 프로덕션을 디버깅해본 경험에서 나오는 방어적 사고의 산물이다. 에이전트에게는 그 경험이 없다. 그래서 happy path 테스트는 통과하고, 실제 장애는 배포 이후에 터진다.
형식 기법이 다시 주목받는 이유
Jane Street는 최근 형식 기법(formal methods) 전담 팀을 꾸렸다. 25년간 '비용 대비 가치가 낮다'고 선을 그어온 조직이 입장을 바꾼 이유는 하나다. 에이전트가 만드는 코드의 양이 급증하면서, 검증 병목이 생산성 병목보다 더 커졌기 때문이다. 에이전트는 목표 달성에는 뛰어나지만, 코드베이스의 핵심 불변식을 유지하거나 경계 케이스를 스스로 잡는 데는 충분하지 않다. 사람이 에이전트 코드를 검증하는 데 쏟는 시간이 늘어날수록, 형식 기법이 그 부담을 줄이는 현실적 수단으로 재평가받는다.
타입 시스템은 이미 우리가 일상적으로 쓰는 가장 가벼운 형식 기법이다. Jane Street이 실험 중인 OxCaml처럼, 타입 수준 제약으로 데이터 레이스나 XSS 취약점을 구조적으로 불가능하게 만들면—에이전트가 그 취약점을 '실수로' 심을 여지 자체가 없어진다. 테스트는 상태 공간의 일부만 커버하지만, 타입 시스템은 보편 보장(universal guarantee)을 제공한다. 에이전트 코딩이 확산될수록, 이 차이가 커진다.
팀이 지금 당장 설계할 수 있는 외부 검증 구조
형식 증명은 당장 팀에 들여놓기 어렵다. 그렇다면 현실적으로 '저자 바깥'의 검증을 어떻게 설계할까. 몇 가지 원칙을 짚는다.
첫째, 검증 모델을 저자 모델과 분리하라. 같은 에이전트가 코드를 쓰고 검토하게 두지 말 것. red-team 패스는 별도 모델 호출로, 다른 시스템 프롬프트로 분리해야 한다. '작성자 역할'과 '파괴자 역할'은 같은 컨텍스트 안에서 공존할 수 없다.
둘째, 검증 범위를 리스크 기반으로 설계하라. 모든 변경에 adversarial review를 걸면 토큰 비용과 컨텍스트가 폭발한다. 외부 입력 파싱, 인증, 결제 플로우처럼 '바깥 세계와 맞닿는 경계'에 집중하고, 내부 리팩터링이나 UI 텍스트 변경에는 생략하는 명시적 기준이 필요하다.
셋째, 구조 검증을 코드 라인 검증보다 먼저 하라. 에이전트에게 구현 코드와 함께 시스템 수준 개요—무엇이 무엇을 호출하는지, 경계가 어디인지—를 텍스트로 생성하게 하고, 그 구조도를 두 번째 모델에 넘겨 '코드와 실제로 일치하는가'를 먼저 검증하라. 라인 단위 리뷰는 구조가 맞다는 확신이 생긴 이후의 작업이다.
넷째, 'looks good' 응답을 금지하는 프롬프트 규칙을 명문화하라. 에이전트가 아무 문제도 못 찾았을 때, '이상 없음'이 아니라 '무엇을 어떻게 확인했는지'를 구체적으로 명시하게 강제해야 한다. 검증의 흔적이 없는 초록 불은 신뢰할 수 없다.
검증 비용을 팀이 의식적으로 지불해야 하는 이유
MiMo Code가 장기 태스크에서 보여주는 아키텍처—컨텍스트 20/45/70% 시점에 체크포인트를 찍고, 별도 writer 서브에이전트가 메모리를 관리하는 구조—는 '에이전트 혼자 판단하게 두면 결국 실패한다'는 전제에서 출발한다. 검증과 메모리를 에이전트 루프 외부에 설계한 것이다. 이 원칙은 코드 품질 검증에도 그대로 적용된다. 에이전트 루프 안에서 자기 완결을 기대하면 안 된다.
검증에는 비용이 따른다. 토큰, 시간, 컨텍스트 예산. 그 비용을 '어디에 얼마나 쓸 것인가'를 팀이 명시적으로 설계하지 않으면, 비용은 아무 데나 쓰이거나 아예 안 쓰인다. Jane Street이 형식 기법 팀을 만든 것도, 솔로 개발자가 red-team 명령어를 opt-in으로 설계한 것도 같은 판단에서 나왔다. 검증 비용을 어디서 의도적으로 낼 것인가—이것이 AI-First 팀이 지금 설계해야 할 아키텍처 결정이다.
전망: 외부 검증이 표준 레이어가 되는 시점
에이전트 코딩이 팀의 기본 모드가 될수록, 외부 검증 레이어는 선택이 아니라 파이프라인의 필수 단계가 된다. 형식 기법이 타입 시스템처럼 일상적 도구로 내려오는 데는 시간이 걸리겠지만, 방향은 분명하다. 단기적으로는 모델 분리, 리스크 기반 검증 트리거, 구조 우선 검토가 팀이 내일 당장 설계할 수 있는 현실적 출발점이다. AI가 자기 코드를 믿는 한, 팀이 그 신뢰를 검증하는 구조를 바깥에서 쥐고 있어야 한다.