AI 에이전트의 진짜 문제는 지능이 아니다
팀에 AI 코딩 에이전트를 도입하고 나서 가장 먼저 부딪히는 벽은 '모델이 부족해서'가 아니다. FROST 런타임을 만든 개발자가 dev.to에 공개한 글이 이걸 잘 정리해준다. FastAPI 레포지토리를 Python 3.10에서 3.14로, Pydantic V1에서 V2로, SQLAlchemy 1.4에서 2.0으로 한 번에 올리는 작업을 에이전트에게 맡기면 어떤 일이 벌어지는가. 테스트 47개 실패 → 무작위 수정 → 31개 실패 → 컨텍스트 오염 → 이전 결정을 잊은 에이전트 → 처음부터 다시. 이 루프가 반복될수록 레포지토리는 시작점보다 더 복잡해진다.
핵심 진단은 명확하다. 에이전트는 추론 문제가 아니라 실행 문제를 갖고 있다. Pydantic V2의 존재를 모르는 게 아니다. '지금 호환성 심을 넣어야 하는가, 아니면 의존성을 일시적으로 고정해야 하는가, 이 접근 방식을 이미 시도했는가'라는 엔지니어링 불확실성 지점에서 올바른 판단을 내리고 실패를 복구하는 인프라가 없는 것이다. FROST가 제안하는 방향—브랜칭, 체크포인팅, 루프 탐지, 진행 상태 보존—은 스마트한 모델이 아니라 안전한 레포지토리 진화 인프라다. 테크 리드 관점에서 이 구분은 중요하다. 에이전트가 막혔을 때 모델을 바꾸는 게 답이 아니라, 실행 컨텍스트를 어떻게 설계하느냐가 답이다.
에이전트 두 개를 싸움 붙이면 버그가 나온다
실행 문제를 해결했다고 치자. 그다음 문제는 AI가 생성하거나 수정한 코드를 어떻게 검증하는가다. 여기서 흥미로운 접근이 하나 있다. Claude Code와 OpenAI Codex CLI를 대립적 리뷰어로 연결하고 수렴 루프를 돌리는 방식이다. dev.to에 공개된 구현 사례를 보면 구조가 단순하다. Claude가 코드를 작성하면 Codex가 신선한 세션에서 독립적으로 검토하고, 지적 사항이 없을 때까지 라운드를 반복한다.
여기서 설계상 핵심은 두 가지다. 첫째, 리뷰어는 반드시 신선한 세션이어야 한다. 1라운드에서 지적한 리뷰어가 2라운드에서 같은 세션을 이어가면 자신의 이전 판단을 방어하는 앵커링이 발생한다. LLM도 예외가 아니다. 둘째, '코드가 맞아 보인다'는 건 증거가 아니다. 리뷰어는 테스트 출력, 커맨드 실행 결과 같은 실증적 증거를 기반으로 판단해야 한다. 실제로 이 시스템을 자기 자신의 구현에 돌렸더니 3라운드에 걸쳐 매번 실제 버그가 나왔다. tail이 stdout 끝만 보여줘서 세션 ID가 사라지는 문제, 이미 시도한 수정이 '반복 지적'으로 처리되어 수렴으로 오인되는 false convergence, Windows 커맨드라인 길이 제한. 세 번 모두 실제로 작동하는 버그였다.
팀 적용 관점에서 이 패턴의 진짜 가치는 오케스트레이터가 판단권을 유지한다는 점이다. 리뷰어의 지적을 전부 수용하는 게 아니라 '타당한 지적만 반영'하고, 거부한 이유를 기록한다. AI가 생성한 리뷰는 적대적 증인이지 상사가 아니다. 라운드 상한을 명시하고, 상한에 도달했을 때 'NOT CONVERGED'를 솔직하게 반환하는 것도 설계에 넣어야 한다. 조용히 통과시키는 것보다 실패를 명시적으로 드러내는 게 팀 신뢰에 낫다.
에이전트 간 상태를 어떻게 넘길 것인가
단일 에이전트의 실행 인프라와 대립적 리뷰 구조를 갖췄다면, 이제 남은 문제는 여러 에이전트 세션이 서로의 작업 상태를 어떻게 공유하는가다. dev.to에 공개된 Claude-Codex 멀티세션 파이프라인 사례가 이 문제를 정면으로 다룬다. Claude가 기사를 생성하고 끝나면, Codex가 별도 GitHub Actions 워크플로우에서 리뷰하고, 그 결과를 다음 Claude 세션이 읽어서 퍼블리시 여부를 결정한다. 세션들은 겹치지 않는다. 각자 실행하고 종료한다.
이 문제에서 push가 아니라 pull 패턴이 정답인 이유는 구조적이다. 지속적으로 실행 중인 서비스라면 이벤트를 구독하면 된다. 하지만 cron 기반으로 실행되고 종료되는 에이전트들 사이에서는 한쪽이 보낼 때 다른 쪽이 듣고 있다는 보장이 없다. 해법은 레포지토리에 커밋된 JSON 파일 하나다. 120줄짜리 Node.js 스크립트가 start, check, complete 세 커맨드로 레코드를 관리하고, check는 태스크가 지연됐을 때 exit code 3을 반환해 CI 스텝이 직접 키오프할 수 있게 한다. 114개 핸드오프 동안 조율 누락이 없었다는 결과가 이 단순함의 설득력이다.
설계에서 주목할 지점은 실패를 숨기지 않는 선택들이다. 같은 ID의 태스크가 이미 활성화되어 있으면 start가 에러를 던진다. 조용히 덮어쓰는 대신 이전 런이 정리되지 않았음을 명시적으로 드러낸다. max_silence_minutes가 지나도록 상태가 running이면 check가 플래그를 세운다. Codex 워크플로우 자체가 실행되지 않은 경우도 이렇게 탐지된다. 이건 기술 선택의 문제가 아니라 에이전트 파이프라인 운영 철학의 문제다. 자동 복구보다 문제를 표면에 드러내는 쪽이 팀에게 낫다.
팀에 통합하기 전에 설계해야 할 세 가지
세 가지 사례를 묶어보면 멀티 에이전트를 팀 워크플로우에 실제로 통합하기 위해 반드시 설계해야 할 레이어가 보인다.
첫째, 실행 인프라. 에이전트가 불확실성 지점에서 멈추지 않고 브랜치를 만들고, 실패를 복구하고, 이전 시도를 기억하게 하는 구조. 이게 없으면 장시간 레포지토리 마이그레이션 작업은 에이전트에게 맡길 수 없다.
둘째, 대립적 검증 루프. AI가 만든 결과물을 같은 AI에게 검토시키지 말고, 신선한 세션의 다른 에이전트가 실증적 증거 기반으로 검토하게 하라. 단, 오케스트레이터가 최종 판단권을 가져야 한다. 라운드 상한과 미수렴 처리도 명시적으로 설계해야 한다.
셋째, 상태 핸드오프 원장. 에이전트 세션들이 독립적으로 실행되고 종료된다면, 공유 상태는 외부 서비스가 아니라 레포지토리 안에 두는 게 운영 비용이 낮다. pull 기반으로 폴링하고, 실패는 조용히 넘기지 말고 exit code로 드러내라.
앞으로: 에이전트는 동료처럼 관리해야 한다
세 가지 구조를 갖추면 공통적으로 향하는 방향이 하나 있다. AI 코딩 에이전트를 코드 생성기가 아니라 엔지니어링 인프라 위에서 작동하는 소프트웨어 엔지니어로 취급하기 시작한다는 것이다. 신입 엔지니어에게 체크포인트 없이 프로덕션 마이그레이션을 통으로 맡기지 않듯, 에이전트에게도 실행 컨텍스트와 실패 복구 구조를 먼저 설계해줘야 한다. 대립적 리뷰어를 두는 것도, 핸드오프 원장을 레포에 심는 것도 같은 맥락이다.
당장 팀에 적용하려면 순서가 있다. 단일 에이전트의 장시간 작업부터 실행 인프라를 설계하고, 그 위에 교차 검증 루프를 얹고, 멀티 에이전트 파이프라인으로 확장할 때 상태 핸드오프를 명시적으로 구조화하라. 세 가지를 한꺼번에 도입하려 하면 학습 곡선과 운영 복잡도가 동시에 올라간다. 하나씩 검증하면서 팀이 소화할 수 있는 속도로 가는 게 현실적이다.