독립 감사(audit)가 코딩 에이전트 테스트 보고서를 수정한 사례

공지: 이 기사는 AiOrch의 공개 데모 기록을 활용하여 AI의 도움으로 작성되었습니다. 초안은 AI 어시스턴트에 의해 생성되었고 해당 기록과 교차 확인되었습니다. 저는 여기서 논의되는 상용 라이선스 엔지니어링 오케스트레이션 플랫폼인 AiOrch의 설립자입니다.

코딩 에이전트 워크플로우는 여러 종류의 증거를 생성할 수 있습니다: 구현(implementation), 리뷰 판정(review verdict), 통합 브랜치(integrated branch), 테스트 결과(test result), 그리고 풀 리퀘스트(pull request). 이 기록들은 서로 불일치할 수 있습니다.

기록된 AiOrch Python TODO CLI 데모에서 최종 개발 보고서는 36개의 테스트를 주장했습니다. 별도의 감사가 python -m pytest tests/ -v를 재실행하여 종료 상태 코드 zero와 함께 35개가 통과한 것을 기록했습니다.

이는 사소한 불일치입니다. 하지만 생성된 보고서가 자체 검증 경계(verification boundary)를 필요로 하는 이유에 대한 유용한 예시이기도 합니다.

실제로 기록된 내용

작업은 핵심 로직, CLI 작업, 패키징을 담당하는 세 개의 구현 에이전트에게 할당되었습니다. 종속적인 작업은 선행 조건이 승인된 후에 시작되었습니다. 세 구현 모두 최종 승인 전에 변경 요청(change requests)을 받았습니다. 이 변경 사항들은 범위 정리, CLI 오류 처리, 그리고 패키징/문서화 수정에 관한 것이었습니다.

통합 과정에서 기록은 CLI 브랜치에서의 충돌과 그 이후의 해결 과정을 포착했습니다. 세 브랜치 모두 세션 내에서 병합(merged)된 것으로 표시되었습니다.

별도의 감사 세션에서는 네 개의 감사/후속 에이전트가 사용되었습니다. 테스트 개수 수정 외에도, 이는 사양/보고서 불일치를 식별하고 후속 수정 사항을 준비했습니다. 검사된 기록에는 병합된 감사 결과가 나타나지 않았습니다. 따라서 승인된 감사 세션은 그 모든 후속 변경 사항이 공개 PR에 도달했음을 확립하지 못합니다.

이 사례 연구는 demo-projects의 PR #5와 연결됩니다. 이 PR은 2026년 10월 5일에 확인했을 때 여전히 열려 있었습니다. 세션 내에서의 브랜치 통합과 GitHub PR 병합은 다른 상태입니다.

에이전트 핸드오프에 추가할 가치가 있는 다섯 가지 검사 항목

1. 승인된 작업 사양을 보존해야 합니다. 이번 기록 실행에서는 원본 작업 파일이 제거되었고, 감사(audit)가 저장된 설정에서 그 사양을 재구성했습니다. 영구적인 복사본은 나중에 검토하는 사람들에게 안정적인 참고 자료를 제공합니다.
2. 주장되는 모든 검증 결과에 대해 정확한 명령어와 종료 상태를 기록해야 합니다. 명령어, 수정 사항 및 캡처된 출력이 없는 성공적인 결과는 재현하기 어렵습니다.
3. 증거와 에이전트가 해석한 내용을 구분해야 합니다. 테스트 출력은 서술형 요약과 분리하여 보관함으로써 개수나 실패 분류를 확인할 수 있습니다.
4. 통합 상태를 명시적으로 보여줘야 합니다. 검토된 브랜치, 통합된 브랜치, 그리고 전달된 PR(Pull Request) 각각이 고유한 상태를 가져야 합니다. 감사 수정 사항이 아직 통합되지 않았다면, 그렇게 언급해야 합니다.
5. 해결되지 않은 게이트는 보존되어야 합니다. 누락된 통합 증거는 '통과'로 조용히 번역되는 대신 핸드오프(handoff)에서 계속 보이도록 해야 합니다.

병렬성이 핸드오프를 변경하는 이유

별도의 git worktree를 사용하면 에이전트가 공유된 체크아웃을 덮어쓰지 않으면서 독립적인 구현 작업을 할당할 수 있습니다. 하지만 이것이 결합된 결과가 작업 사양을 만족한다는 것을 증명하지는 못합니다. 의존성, 변경된 인터페이스, 그리고 병합 충돌은 여전히 통합 작업을 필요로 합니다.

검토 판정(Review verdicts)과 테스트 명령어는 서로 다른 질문에 답합니다. 검토자는 범위나 동작상의 문제를 식별할 수 있고; 테스트 명령어는 특정 체크아웃에서 무엇이 통과했는지 확인할 수 있습니다. 이 두 가지 기록을 모두 보관하는 것이 최종 결과를 검사하기 더 쉽게 만듭니다.

이 예시의 범위

이것은 도구 비교 벤치마크나 생산 신뢰성에 대한 주장이 아닌, 작게 기록된 Python 데모입니다. 이 실행에는 재개(resume) 이벤트가 포함되어 있으며, 기록은 모든 재개의 행위자(actor)를 식별하지 않습니다. 또한 운영자의 개입 없이 진행된 실행을 확립하지도 못합니다.

사용 데이터는 여러 에이전트에서 누락되었기 때문에, 대시보드에 표시되는 '0 비용'은 이 실행이 무료였다는 주장을 뒷받침할 수 없습니다. 발표된 사례 연구는 과거의 결과를 검사한 것이며, 출판 과정 중에 이를 재실행하지 않았습니다.

AiOrch는 사용자의 인프라에서 오케스트레이션과 작업 트리를 실행합니다. 설정된 클라우드 추론 제공업체는 여전히 전송되는 컨텍스트를 받습니다. 코디네이터를 자체 호스팅하는 것이 모든 추론이 로컬로 유지된다는 증거라고 설명되어서는 안 됩니다.

여기서 유용한 엔지니어링 결과물은 작업(task)부터 구현, 검토, 통합, 감사(audit), 그리고 인계(handoff)에 이르는 검사 가능한 체인이며, 의견 불일치까지 기록으로 유지됩니다.

전체 사례 기록, 한계 및 공개 PR

병렬 오케스트레이션 가이드