에이전트 신뢰가 무너지는 순간은 대부분 극적이지 않다. 12개 파일에서 함수명을 깔끔하게 바꿔놓은 에이전트가, 13번째 파일은 grep 경로에 없었다는 이유만으로 그냥 넘겨버린다. 에러 메시지도 없고, 경고도 없다. 결과물은 완성된 것처럼 보인다. dev.to의 한 개발자가 털어놓은 이 경험은 단순한 버그 제보가 아니다. AI 에이전트 도입 초기에 거의 모든 팀이 겪는 신뢰 설계 실패의 전형이다.
문제는 이 신뢰 붕괴가 '한 번 경험하면 고치면 된다'는 식으로 끝나지 않는다는 데 있다. 흥미로운 건 그 개발자가 스스로 덧붙인 말이다. "워크플로우를 바꿨냐고요? 잠깐은요. 근데 일주일 지나면 또 믿게 되더라고요." 경각심이 반감기를 가진다. 팀 단위에서는 더 위험하다. 에이전트가 자신 있게 내놓은 결과물을 반박할 수단이 없으면, 사람은 결국 그것을 믿는 방향으로 수렴한다.
레거시 현대화 현장은 이 문제가 훨씬 더 구조적으로 터진다. dev.to에 공개된 레거시 리라이트 사례 분석은 Claude Code를 직접 레거시 코드베이스에 투입한 경험을 솔직하게 정리한다. 결과는 '부분적 성공'이었다. 에이전트는 새 구현을 그럴듯하게 만들어냈고, 리뷰어는 고개를 끄덕였다. 그런데 세 가지가 계속 틀렸다. 토큰 비용은 폭발했고, 동작 일치 여부는 '눈으로 두 화면 나란히 놓고 비교'하는 방식에 의존했으며, 한번 검토된 슬라이스가 다음 슬라이스 작업 중에 조용히 퇴행해도 아무도 몰랐다. 저자가 내린 진단은 명확하다. "나는 측정 문제를 더 좋은 프롬프트로 풀려 했다."
이 진단이 핵심이다. 프롬프트를 아무리 정교하게 다듬어도, 에이전트의 해석이 얼마나 설득력 있어 보여도, 그것은 여전히 '해석'이다. 레거시 시스템의 동작은 코드 한 곳에 모여 있지 않다. 저장 프로시저, 야간 배치 잡, 아무도 소유권을 주장하지 않는 스케줄러 항목, 문서에 없는 외부 서비스 응답 형태, 그리고 특정 사람의 머릿속에만 있는 운영 규칙. 이것들을 전부 읽어도 실제 프로덕션에서 어느 분기가 실행되는지, 인보이스 반올림이 경로마다 왜 다른지는 알 수 없다. 실행해서 기록하는 수밖에 없다.
저자가 도달한 접근법은 간결하다. 레거시 시스템을 오라클로 삼아 실행 결과를 캡처하고, 그것을 실행 가능한 스펙으로 삼아 에이전트가 그린을 낼 때까지 구현하게 한다. 테스트 주도 현대화다. 여기서 핵심 자산은 새 코드가 아니라 하네스—에이전트의 결과물을 사람 없이 반박할 수 있는 판단 장치다. 비교기 설계도 섬세하다. ID나 타임스탬프 같은 표현 차이는 정규화할 수 있다. 그러나 동작 자체를 없애거나 바꾸는 결정은 정규화가 아니라 마이그레이션 정책으로 명시적으로 기록해야 한다. '이 차이는 무시'가 일상 어휘가 되는 순간, 그린 결과는 협상으로 얻어내는 것이 된다.
Cursor + BrowserAct 조합은 이 검증 루프 설계의 실전 버전을 보여준다. 브라우저 자동화의 오랜 적은 하드코딩된 셀렉터다. 프론트엔드가 조금만 바뀌어도 멀쩡히 작동하는 기능을 테스트가 잡아내지 못한다. BrowserAct가 도입한 전환은 단순하다. 'Remember → Click → Hope' 패턴을 'Inspect → Act → Wait → Inspect Again'으로 바꾼다. 에이전트가 이전 스냅샷의 가정에 의존하지 않고, 매 인터랙션마다 현재 페이지 상태를 다시 읽는다. 셀렉터를 지정하지 않아도 현재 존재하는 요소를 찾아 동작하고, UI 변경 후에도 스스로 재조정한다. 이 워크플로우가 보여주는 것은 기술적 묘수가 아니라 하나의 원칙이다. 에이전트에게 과거의 가정이 아닌 현재 상태를 기준으로 판단하게 하는 것.
세 사례를 겹쳐보면 패턴이 보인다. 에이전트 신뢰 붕괴는 에이전트가 나빠서 생기지 않는다. 에이전트 결과물을 반박할 수 있는 독립적 장치 없이 에이전트를 돌렸기 때문에 생긴다. 함수 리네임 에이전트에게 필요했던 건 '모든 파일을 더 꼼꼼히 grep하라'는 더 나은 프롬프트가 아니었다. 변경 후 레퍼런스가 남아있는 파일을 탐지하는 검증 단계였다. 레거시 리라이트 에이전트에게 필요했던 건 더 정교한 분석 스킬이 아니었다. 에이전트의 해석과 독립적으로 동작을 비교하는 하네스였다. 브라우저 자동화 에이전트에게 필요했던 건 더 안정적인 셀렉터가 아니었다. 매 스텝마다 현재 상태를 다시 확인하는 루프였다.
팀 도입 관점에서 시사점은 하나로 수렴한다. 에이전트를 먼저 돌리고 나중에 검증을 붙이는 순서는 작동하지 않는다. 검증 루프를 먼저 설계하고, 그 루프가 에이전트 결과물을 사람 없이 반박할 수 있는 상태가 된 다음에 에이전트에게 작업을 맡겨야 한다. 이건 속도를 늦추자는 말이 아니다. 검증 없는 속도는 결국 인간이 모든 결과물을 눈으로 재확인하는 병목으로 돌아온다. 그 병목이 생기면 에이전트는 자동화 도구가 아니라 검토 부담을 늘리는 코드 생성기가 된다.
앞으로 에이전트 도구는 더 빠르고 더 유창해질 것이다. 그럴수록 결과물은 더 설득력 있어 보일 것이고, 검증 없이 믿고 싶은 유혹은 더 커진다. 신뢰는 프롬프트의 품질에서 오지 않는다. 에이전트와 독립적으로 작동하는 검증 루프를 갖췄는가, 그 루프가 에이전트 결과물을 사람의 개입 없이 반박할 수 있는가—이 두 질문에 답할 수 있을 때 비로소 에이전트를 신뢰하는 게 된다. 그 전까지는 그냥 기대하는 것이다.