AI 코딩 에이전트를 매일 쓰는 팀이라면 이 상황이 낯설지 않을 것이다. 에이전트에게 태스크를 던지고, 다른 일을 하다가 돌아와 보면 화면 하단에 한 줄이 떠 있다. "빌드, 회귀 스모크, 기존 분석 테스트 모두 통과." 그리고 아무도 스크롤을 올려 실제로 테스트가 실행됐는지 확인하지 않는다. dev.to에 공개된 한 개발자의 실증 감사에 따르면, 이 패턴이 수개월간 반복됐다. 249개 세션, 124번의 "테스트 통과" 발언, 그리고 실제로 잡힌 거짓말은 단 0건이었다.
그런데 이 결과를 "AI가 정직하다"는 증거로 읽으면 안 된다. 감사 도구 red-handed가 7개의 SUSPICIOUS 케이스로 표시한 세션들을 열어보니 문제의 본질이 드러났다. 에이전트는 실제로 브라우저를 열고 확인했다. 그런데 그 검증은 기계가 읽을 수 있는 흔적을 전혀 남기지 않았다. 출력 포맷이 파서에게 알려지지 않은 스크립트를 통해 실행된 경우도 마찬가지였다. AI가 거짓말을 한 게 아니었다. 검증이 일어났지만 아무도 나중에 읽을 수 없는 형태로 일어났다. 이것이 핵심이다.
이 문제가 더 무거운 이유가 있다. 사람이 직접 브라우저를 열어 확인할 때는 그 사람이 계속 그 코드를 바라봤다. 기억이 이어졌다. 하지만 에이전트는 세션이 끝나면 메모리가 리셋된다. 검증을 했어도 그 사실이 다음 세션으로 전달되지 않는다. 읽을 수 없는 검증은 검증이 아예 없었던 것과 구별이 불가능하다. 이건 AI의 문제라기보다 에이전트 기반 워크플로우가 만들어내는 구조적 공백이다.
여기서 Google의 Chrome 보안 파이프라인 사례를 겹쳐 보면 방향이 선명해진다. Google의 Gemini 기반 취약점 탐지 에이전트 Big Sleep은 13년간 인간 리뷰어와 퍼저를 모두 통과한 샌드박스 탈출 버그(CVE-2026-3545, CVSS 9.8)를 발견했다. Chrome 149·150 두 릴리즈에서 수정된 보안 버그가 1,072개—이전 23개 메이저 릴리즈의 합산을 넘는다. 하지만 Google이 이 성과를 낼 수 있었던 것은 에이전트가 뛰어나서만이 아니다. 에이전트가 인터넷 없이 격리된 머신에서만 동작하고, 서브에이전트의 접근 범위가 소스 디렉토리로 엄격히 제한되며, 패치 제안 에이전트와 이를 공격적으로 검토하는 크리틱 에이전트가 분리 운영되는 구조 덕분이다. 생성과 검증이 명시적으로 역할 분리된 파이프라인이 있었기 때문에 결과를 신뢰할 수 있었다.
한편 에이전트 메모리 설계 관점에서 보면 또 다른 레이어가 추가된다. MemoFS 같은 퍼시스턴트 메모리 런타임이 다루는 문제는 에이전트의 컨텍스트 압축(compaction) 이후 기존에 설정된 규칙이 사라진다는 것이다. 세션 시작 훅으로 프로젝트 컨텍스트를 주입하고, 서브에이전트에 메모리를 전파하고, 컴팩션 후 핵심 규칙을 재주입하는 구조가 없다면—에이전트는 이전 검증 결과가 무엇이었는지, 어떤 아키텍처 결정이 내려졌는지 알 수 없다. 검증 추적 체계의 가장 아래 레이어는 결국 에이전트가 "무엇을 기억하느냐"의 설계 문제다.
세 사례가 교차하는 지점에서 팀이 실제로 설계해야 할 것이 드러난다. 첫째, 검증은 기계가 읽을 수 있는 형식으로 남겨야 한다. 에이전트가 "통과"를 말했을 때 그 근거가 파싱 가능한 로그나 아티팩트로 존재하지 않으면, 그 발언은 검증 증거가 아니다. CI 파이프라인에 에이전트 세션 트랜스크립트를 연결하거나 표준 출력 포맷을 강제하는 것이 출발점이다. 둘째, 생성 에이전트와 검증 에이전트는 역할을 분리해야 한다. Google의 fixer-critic 루프가 실증한 것처럼, 동일한 에이전트가 코드를 쓰고 자신의 결과를 검증하게 하는 구조는 단일 LLM이 패치를 생성하는 데모 수준에 머문다. 셋째, 에이전트 메모리 설계는 검증 연속성의 문제다. 이전 세션의 검증 결과, 아키텍처 결정, 제약 조건이 다음 에이전트 세션으로 전달되지 않으면 팀은 매번 제로 베이스에서 신뢰를 재구축해야 한다.
red-handed 감사가 남긴 마지막 교훈도 놓치면 안 된다. 이 도구는 스스로 "0 false positives"라고 선언했지만, 실제로는 JavaScript/TypeScript 프로젝트 외의 코드 경로를 한 번도 실행하지 않았기 때문에 그 수치가 나온 것이었다. 검증 도구를 검증하지 않는 팀은 자신이 만든 도구가 하는 것과 똑같은 실수를 저지른다. AI가 생성한 것이든, 팀이 설계한 검증 파이프라인이든, 커버리지가 닿지 않은 경로에서의 침묵은 통과가 아니다.
에이전트의 자율성이 높아질수록 팀이 해야 할 일은 줄어드는 게 아니라 다른 층으로 이동한다. 코드를 직접 작성하는 시간이 줄어든 만큼, 검증이 어디서 어떻게 일어나고 있는지를 추적 가능한 구조로 설계하는 책임이 커진다. AI가 빠르게 코드를 쏟아낼수록, 그 속도를 뒷받침하는 검증 추적 체계의 설계는 더 인간의 몫이 된다.