AI 에이전트의 자율성은 '신뢰'가 아니라 '구조'의 문제다
AI 에이전트가 버그를 읽고, 수정하고, 배포까지 완료한다. 듣기엔 좋다. 그런데 실제로 그 에이전트가 틀렸을 때 누가, 어떤 구조로 잡아내는가? 이 질문에 답 없이 에이전트를 프로덕션에 올리는 팀이 여전히 많다.
최근 dev.to에 올라온 세 편의 글이 각자 다른 각도에서 같은 결론을 가리킨다. Doer-Checker 패턴으로 버그 75%를 자율 해결하면서 프로덕션 인시던트 0건을 기록한 사례, LLM 없이 작동하는 결정론적 정적 분석 도구 4종, 그리고 AI가 만든 웹앱을 런칭 전에 점검하는 9가지 체크리스트. 이 세 가지는 모두 하나의 주제로 수렴한다: 검증 게이트를 어떻게 설계할 것인가.
핵심 이슈: 에이전트는 자기 작업을 스스로 통과시킨다
가장 날카로운 통찰은 Doer-Checker 패턴 아티클에서 나온다. 저자가 Fortune 500 기업에서 자율 버그 수정 에이전트를 처음 만들었을 때, 첫 버전은 "자신이 만든 기준으로 자신의 결과물을 통과시키는" 시스템이었다. 에이전트는 항상 자기 작업을 긍정적으로 평가했다. 독립된 기준점이 없기 때문이다.
이걸 구조적으로 해결한 게 Doer-Checker 패턴이다. 핵심 원칙은 단순하다: 작업을 생성하는 시스템과 작업을 검증하는 시스템은 반드시 분리되어야 한다. Doer(생성자)가 출력을 만들면, Checker(검증자)는 Doer의 프롬프트도, 추론 과정도, 중간 단계도 보지 않는다. 오직 원본 데이터와 최종 결과물만 받아 독립적으로 판단한다.
구체적으로 이 에이전트는 4단계(트리아지 → 재현 → 수정 → 배포)를 거치며 각 단계 사이에 검증 게이트를 배치한다. Checker는 Doer보다 낮은 temperature(0.2 vs 0.7)로 실행된다. Doer는 창의적 추론이 필요하고, Checker는 일관된 pass/fail 판단이 필요하기 때문이다. 검증 실패 시 거부 이유가 Doer에게 피드백으로 돌아가고, 일정 횟수 재시도 후에도 통과 못 하면 인간에게 라우팅된다. 이 구조 덕분에 버그 75% 자율 해결, 프로덕션 인시던트 0건이라는 결과가 나왔다.
맥락 해석: LLM으로 LLM을 검증하는 것의 한계
Doer-Checker가 LLM 레이어의 검증을 다룬다면, 또 다른 아티클은 다른 방향을 제안한다. LLM 없이 작동하는 결정론적 도구들이다.
개발자 Diya가 공개한 4개의 오픈소스 도구는 "AI가 짠 코드를 검증할 때 또 다른 LLM을 쓰면 블랙박스 위에 블랙박스를 쌓는 것"이라는 문제의식에서 출발한다. API 비용도, 비결정론적 판단도 없이 정적 분석과 그래프 알고리즘만으로 작동한다.
네 도구의 역할을 간단히 정리하면 이렇다. skillcheck는 Claude Code, Cursor 같은 에이전트가 읽는 SKILL.md 파일의 형식과 토큰 예산을 린팅한다. 에이전트의 컨텍스트가 시작 전부터 오염되는 걸 막는다. mcp-schema-watch는 MCP 서버의 툴 스키마 변경을 감지하고, 브레이킹 체인지가 발생하면 Slack으로 알린다. 에이전트가 의존하는 외부 툴이 조용히 바뀌는 걸 잡는다. pr-blast-radius는 PR에서 변경된 파일의 AST와 임포트 그래프를 분석해 실제 영향 범위를 계산한다. 에이전트가 범위를 벗어난 파일을 건드렸는지 확인할 수 있다. swarm-trace-viewer는 멀티 에이전트 환경에서 실패가 근본 원인인지 연쇄 실패인지를 분류한다.
이 도구들이 공유하는 철학이 중요하다: 검증 레이어 자체는 예측 가능해야 한다. LLM 기반 Checker가 "왜 통과시켰는가"를 설명하기 어렵다면, 정적 분석 기반 게이트는 항상 동일한 입력에 동일한 결과를 낸다. 두 레이어를 병행하는 게 현실적으로 가장 강한 구조다.
시사점: 런칭 전 9가지 체크포인트가 드러내는 것
AI가 만든 웹앱의 런칭 전 점검 체크리스트를 다룬 세 번째 아티클은 조금 다른 관점을 추가한다. 이 글은 AI 생성 코드가 나쁜 게 아니라, 생성 속도가 검증 속도를 앞질러서 문제가 생긴다고 지적한다.
9가지 체크 중 팀 단위로 즉시 적용 가능한 것들을 추려보면 이렇다. 첫째, 검증 대상을 전체 앱이 아니라 3~6개 화면의 단일 여정으로 좁혀라. 막연한 "백엔드 리뷰"는 아무것도 검증하지 않는다. 둘째, 잘못된 사용자로 같은 동작을 시도하라. UI가 버튼을 숨기는 것만으로는 부족하다. 서버와 DB 경계에서 실제로 거부되는지 확인해야 한다. 셋째, 동일한 요청을 반복하라. 브라우저 새로고침, 더블클릭, 네트워크 타임아웃 시나리오에서 중복 레코드나 중복 청구가 발생하는지 확인한다. 넷째, 중간에 실패시켜라. 첫 번째 쓰기는 성공했는데 두 번째가 실패했을 때 시스템의 상태가 관찰 가능하고 복구 가능한지를 봐야 한다.
이 체크리스트가 흥미로운 이유는 AI 생성 코드에만 적용되는 게 아니라는 점이다. 동일한 기준을 인간이 짠 코드에도 적용하면 대부분의 팀에서 구멍이 발견된다. AI가 이 문제를 만든 게 아니라, AI가 이 문제를 더 빠르게, 더 크게 드러낸다.
전망: 검증 구조 설계가 테크 리드의 핵심 역량이 된다
세 글이 합쳐서 말하는 것은 결국 이것이다. AI 에이전트의 자율성 수준은 팀이 설계한 검증 게이트의 수준에 비례해야 한다. 게이트 없이 자율성을 높이는 건 속도가 아니라 부채다.
실용적인 시작점은 단순하다. 지금 당장 Doer-Checker 패턴을 전체 파이프라인에 적용하기 어렵다면, 가장 위험한 단일 스테이지(보통 배포 직전 코드 수정 단계)에만 독립 검증 레이어를 붙이는 것부터 시작할 수 있다. pr-blast-radius 같은 결정론적 도구를 CI에 통합하는 건 며칠 안에 가능하다. 런칭 전 체크리스트 9개 중 팀이 실제로 통과할 수 있는 것이 몇 개인지 세어보는 것도 현재 검증 구조의 수준을 객관적으로 가늠하는 방법이다.
테크 리드의 역할이 바뀌고 있다. 코드를 직접 리뷰하는 것에서, 에이전트의 결과물이 통과해야 하는 게이트를 설계하는 것으로. 에이전트가 "됐다"고 말할 때 실제로 된 건지 확인하는 구조는 모델이 만들어주지 않는다. 그 구조를 설계하는 사람이 팀에서 가장 중요한 역할이 되고 있다.