AI 에이전트 스모크 런은 ‘성공’이 아니라 증거로 판정해야 한다
워커가 “성공했습니다”라고 했는데, 정말 성공한 걸까?
AI 에이전트를 하나만 쓸 때는 성공 여부가 비교적 단순하다. 명령이 끝났고, 결과가 보이면 된다. 하지만 Pi가 오케스트레이터가 되고 GJC와 Codex가 워커가 되는 순간부터는 다르다. 한쪽은 “구현 완료”라고 하고, 다른 쪽은 “검토 완료”라고 하며, 오케스트레이터는 전체 실행을 “succeeded”로 기록할 수 있다. 그런데 실제 diff가 비어 있거나 테스트 로그가 없으면, 우리는 무엇을 믿어야 할까?
내가 이번에 얻은 결론은 간단하다. 스모크 런의 상태는 워커의 요약문이 아니라 서로 맞물린 산출물로 판정해야 한다. 이 기준 하나를 세워두면 “실패인가, 부분 성공인가, 재실행해도 되는가”를 감으로 결정하지 않게 된다.
에이전트가 늘수록 ‘성공’이라는 단어가 위험해진다
Pi·GJC·Codex 조합의 장점은 역할 분리다. Pi는 대화를 받고, GJC는 읽기 전용 계획을 만들고, Codex는 구현과 테스트를 맡고, 다시 GJC가 독립적으로 diff를 검토한다. 사람이 매번 모든 단계를 붙잡지 않아도 되는 구조다.
문제는 역할이 분리된 만큼 상태도 여러 개가 된다는 데 있다. 워커가 남긴 설명, 오케스트레이터 manifest, 실제 검토 파일, Git diff, 테스트 결과가 서로 다른 이야기를 할 수 있다. 이때 가장 그럴듯한 문장 하나를 골라 상태를 정하면 편하지만, 그 편리함이 곧 운영 리스크가 된다.
예를 들어 Codex가 “테스트까지 통과했다”고 요약했더라도 테스트 로그가 없으면 검증된 사실이 아니다. GJC가 “독립 검토 완료”라고 응답했더라도 검토 산출물이 비어 있으면 검토가 있었다고 볼 수 없다. 반대로 워커의 요약이 어긋났다는 이유만으로 전체 실행을 곧바로 partial이라고 부르는 것도 정확하지 않다. 먼저 실제 단계와 파일을 맞춰봐야 한다.
이번 작업에서 내가 실제로 확인한 것
출처 구분 — 상호작용(에이전트-드루 대화·작업)
이번 작업의 목표는 Pi를 메인 에이전트로 두고 GJC·Codex·Antigravity를 워커로 연결하는 구성을 깨끗한 임시 Git 저장소에서 시험하는 것이었다. 이미 변경이 많은 .drewgent 작업 트리를 시험 장소로 쓰지 않고, 먼저 drewgent 런처가 의도한 Pi 규칙과 도구 선언을 불러오는지 새 세션에서 확인하는 순서였다.
하지만 워커를 실제로 끝까지 돌린 성공 사례는 아니었다. GJC 설정 확인 과정에서 자격 증명이 출력에 노출된 정황이 발견됐고, 작업 트리도 깨끗하지 않았다. 그래서 자격 증명을 교체하고 안전한 임시 저장소를 준비하기 전에는 시험을 중단해야 했다. Antigravity 역시 크레딧 사용 설정과 계정 상태를 먼저 확인해야 했다.
여기서 중요한 점은 “실행이 안 됐으니 얻은 게 없다”가 아니다. 오히려 실행을 억지로 성공시키려 하지 않고, 다음 실행의 판정 기준을 정할 수 있었다. 실행을 시작하기 전의 안전 조건과, 실행이 끝난 뒤의 증거 조건을 분리하는 것이다.
내가 스모크 런을 판정하는 네 가지 증거
이제 실행 결과를 볼 때 아래 네 가지를 한 묶음으로 확인한다. 어느 하나만 초록색이어도 전체를 성공으로 표시하지 않는다.
- Workflow manifest — 실행이 실제로 어느 단계까지 갔는지 본다. 시작, 계획, 구현, 독립 검토, 완료의 순서가 기록돼 있어야 한다.
- 실제 독립 검토 산출물 — 검토 파일이 존재하는지만 보지 않는다. diff를 읽고, 이전 워커의 결론을 그대로 반복하지 않는 지적이 들어 있는지 확인한다.
- 최종 diff — 구현 대상 파일의 변경이 실제로 남아 있는지 본다. staged·unstaged·untracked 변경을 포함하되, 실행 기록 디렉터리 자체는 결과로 세지 않는다.
- 테스트 결과 — “테스트함”이라는 문장이 아니라 어떤 명령이 실행됐고 어떤 결과가 나왔는지 확인한다. 결과가 없으면 통과가 아니라 미검증이다.
이 네 가지가 서로 일치하면 성공으로 분류한다. 실행 전 안전 조건에서 멈췄다면 blocked다. 단계는 진행됐지만 증거가 빠졌다면 partial 또는 미검증으로 남긴다. 단, 워커의 요약문 하나가 다른 산출물과 다르다는 이유만으로 partial이라고 결론 내리지는 않는다. 먼저 manifest의 단계 순서와 실제 파일을 source of truth로 삼는다.
상태 판정은 재실행 버튼을 누르는 문제다
이 기준이 실무에서 유용한 이유는 명확하다. 상태를 잘못 붙이면 다음 행동도 틀린다. 사실은 검토까지 끝났는데 worker summary가 어긋났다는 이유로 전체를 재실행하면, 같은 변경을 다시 만들고 리뷰를 중복 수행할 수 있다. 반대로 manifest만 보고 성공 처리하면 테스트가 빠진 결과를 배포 단계로 넘길 수 있다.
나는 그래서 “누가 뭐라고 썼는가”보다 “어떤 산출물이 어떤 순서로 남았는가”를 먼저 본다. 이 방식은 AI를 덜 믿자는 이야기가 아니다. AI가 여러 역할로 나뉘어 일할수록, 각 역할의 말을 서로 검증할 수 있는 작업면을 만들어야 한다는 뜻이다.
런처도 새 세션에서 따로 검증해야 한다
오케스트레이터의 manifest만 봐서는 충분하지 않은 경우가 있다. 사람이 실제로 쓰는 진입점이 다른 규칙과 도구를 불러오면, 워커 파이프라인이 아무리 깔끔해도 운영 환경과 시험 환경이 달라진다.
그래서 drewgent 런처는 별도 체크 대상으로 둔다. 새 세션을 시작한 뒤 Pi가 의도한 규칙을 읽었는지, 메모리 브리지와 오케스트레이터 도구가 선언됐는지 확인한다. 평소 쓰던 세션의 기억이나 화면에 기대지 않고, 빈 상태에서 같은 진입 경로를 다시 확인하는 것이다.
이 작은 절차가 중요한 이유는 “코드는 맞는데 실제 명령은 다른 환경에서 실행되는” 종류의 오류를 초기에 잡아주기 때문이다. 스모크 런은 워커 호출만 통과하면 끝나는 테스트가 아니다. 사용자가 실제로 누르는 입구부터 최종 diff와 테스트까지 같은 경로인지 확인하는 테스트다.
당장 적용할 수 있는 5분짜리 판정 루틴
Pi 기반 오케스트레이션을 이미 쓰고 있거나 도입하려는 사람이라면 다음 순서만 먼저 고정해도 된다.
- manifest를 열고 실제 phase 순서를 확인한다.
- 독립 검토 파일을 직접 열어, 요약이 아닌 검토 내용이 있는지 본다.
- 최종 diff에서 기대한 파일만 바뀌었는지 확인한다.
- 테스트 명령과 결과를 실행 로그에서 대조한다.
- 마지막으로 새 세션에서 실제 런처와 도구 선언을 확인한다.
이 루틴은 화려하지 않다. 대신 자동화가 실패했을 때 어디까지 믿을 수 있는지를 알려준다. 결국 좋은 오케스트레이션은 워커를 많이 부르는 시스템이 아니라, 완료를 증명할 수 있는 시스템이다.
AI 도구를 붙이는 일보다, 증거를 연결하는 일이 먼저다
Pi·GJC·Codex를 연결하면 더 많은 일을 자동화할 수 있다. 하지만 도구가 늘어난 만큼 “완료”라는 단어의 기준도 함께 설계해야 한다. 이번 작업에서 내게 남은 가장 실용적인 교훈은 이것이다. 워커의 자신감은 결과가 아니고, 서로 독립적인 산출물이 같은 결론을 가리킬 때 비로소 결과가 된다.
다음에 스모크 런을 돌린다면 성공 메시지부터 읽지 말고 네 가지 파일과 테스트를 먼저 열어보자. 지금 쓰는 에이전트 파이프라인에도 manifest, 독립 검토, 최종 diff, 테스트 결과가 없다면 그 네 칸부터 추가하면 된다. 그때부터 자동화는 “잘 된 것 같다”가 아니라 “이만큼은 확인됐다”로 바뀐다.
당신의 워크플로에서 가장 자주 믿고 있는 성공 신호는 무엇인가? 다음 스모크 런에서 그 신호를 실제 산출물 하나와 대조해보자. 첫 번째 대조 결과를 기록하는 것부터, 도구를 믿을 수 있는 워크플로를 만드는 시작이다.
근거 출처
외부 정보(하베스터 수집)
이번 글에서는 외부 기사·트렌드·통계·제품 문서를 사용하지 않았다. 따라서 시의성 있는 시장 규모나 도구 성능 수치를 제시하지 않는다. 외부 정보 연구는 주제에 필요한 근거가 아니어서 생략했다.
상호작용(에이전트-드루 대화·작업)
- Pi Agent Orchestrator의 workflow 설명과 manifest·diff·독립 검토·테스트 단계 정의
- Pi를 메인 오케스트레이터로 두고 GJC·Codex·Antigravity를 워커로 시험하려 한 실제 작업 기록
- 실행 전 자격 증명 노출 정황과 dirty worktree를 확인한 뒤 워커 시험을 중단한 결정
- “워커 요약이 충돌해도 reconciled evidence를 먼저 확인하라”는 작업 교훈
이 글은 위 상호작용 기록을 바탕으로 재구성한 경험형 글이다. 실제 워커 실행을 성공한 사례로 포장하지 않고, 실행을 안전하게 판정하기 위해 정리한 운영 기준만 다룬다.