AI 코딩 에이전트를 팀에 도입하면 처음에는 모두 프롬프트 품질을 봅니다. 하지만 실제로 막히는 지점은 검수입니다. 에이전트가 어떤 파일을 왜 바꿨는지, 브라우저에서 결과가 어떻게 보이는지, 테스트가 실제로 통과했는지 사람이 빠르게 확인하지 못하면 속도 이점이 사라집니다.
Google Antigravity 발표와 OpenAI Codex 모바일 발표는 공통적으로 “아티팩트 기반 검수”를 강조합니다. Antigravity는 agent가 task list, implementation plan, screenshot, browser recording 같은 Artifacts를 만든다고 설명합니다. Codex 모바일은 screenshots, terminal output, diffs, test results, approvals를 실시간으로 확인할 수 있다고 설명합니다. 두 발표가 가리키는 방향은 같습니다. 원시 tool log를 읽게 하지 말고, 사람이 판단할 수 있는 산출물로 요약해야 합니다.
이 글은 AI 코딩 에이전트를 운영하는 개발팀이 로그 중심 검수에서 아티팩트 중심 검수로 옮겨가는 실전 기준을 정리합니다.
에이전트 로그는 길고 시끄럽습니다. 파일 목록, 셸 출력, dependency install, 테스트 재시도, 브라우저 탐색, 중간 reasoning 비슷한 설명이 섞입니다. 사람이 이 로그를 끝까지 읽어야 한다면 에이전트를 쓰는 의미가 줄어듭니다.
검수자는 세 가지 질문에 답하고 싶습니다. 첫째, 요구사항을 제대로 이해했나. 둘째, 코드 변경이 안전한가. 셋째, 실제 결과가 의도대로 동작하나. Tool log는 이 질문에 직접 답하지 않습니다. 오히려 많은 줄을 읽게 만들어 판단을 늦춥니다.
아티팩트는 이 질문을 직접 겨냥합니다. 구현 계획은 요구사항 이해를 보여줍니다. Diff summary는 변경 범위와 리스크를 보여줍니다. 테스트 결과는 회귀 여부를 보여줍니다. 스크린샷과 녹화는 UI 결과를 보여줍니다. 승인 요청은 사람이 판단해야 할 위험 액션을 분리합니다.
코딩 에이전트 작업마다 모든 산출물을 만들 필요는 없습니다. 그러나 팀 운영 기준으로 최소 세트는 정해두는 편이 좋습니다.
첫째, task brief입니다. 에이전트가 이해한 목표, 범위 밖 항목, 성공 기준을 5줄 이내로 적습니다. 둘째, implementation plan입니다. 어떤 파일을 볼지, 어떤 전략으로 수정할지, 어떤 테스트를 돌릴지 적습니다. 셋째, diff summary입니다. 파일별 변경 목적, public API 변경 여부, migration 여부, 위험도를 정리합니다.
넷째, verification artifact입니다. 테스트 명령, 결과, 실패 시 원인, 재시도 여부를 남깁니다. UI 작업이면 screenshot 또는 browser recording을 추가합니다. 다섯째, approval log입니다. 사람이 승인한 명령, 시간, 이유, 승인자가 남아야 합니다.
이 다섯 가지가 있으면 리뷰어는 전체 로그를 보지 않고도 핵심 판단을 할 수 있습니다. 필요할 때만 raw log로 내려가면 됩니다.
문서 수정 작업에는 screenshot이 필요 없습니다. 반대로 프런트엔드 UI 변경에는 테스트 결과만으로 부족합니다. 그래서 작업 유형별 아티팩트 정책을 나눠야 합니다.
이 정책이 없으면 에이전트는 매번 과하거나 부족한 산출물을 냅니다. 특히 UI 변경에서 스크린샷 없이 “완료”라고 하는 패턴은 피해야 합니다. 눈으로 확인할 결과물이 없으면 리뷰가 늦어집니다.
가장 안전한 방식은 에이전트 작업을 PR 단위로 닫는 것입니다. 에이전트가 직접 main에 반영하지 않고, 브랜치와 PR을 만들고, PR 설명에 아티팩트를 붙입니다. PR 템플릿을 에이전트 친화적으로 바꾸면 효과가 큽니다.
추천 PR 템플릿은 다음 항목을 포함합니다.
에이전트가 이 구조로 PR을 작성하게 하면 리뷰어는 같은 위치에서 판단할 수 있습니다. 또한 나중에 장애가 났을 때 “왜 이 변경을 했는가”를 추적하기 쉽습니다.
아티팩트도 형식만 갖추면 소용없습니다. “테스트 완료”라고 적고 실제 명령이 없거나, screenshot이 오래된 상태거나, diff summary가 너무 추상적이면 리뷰 품질이 떨어집니다. 따라서 CI나 hook으로 최소 품질을 검사해야 합니다.
예를 들어 PR 본문에 테스트 명령이 없으면 fail, UI 변경 파일이 있는데 screenshot 링크가 없으면 warning, migration 파일이 있는데 rollback plan이 없으면 fail로 처리할 수 있습니다. 에이전트가 만든 PR도 사람 PR과 같은 정책을 통과해야 합니다.
또한 아티팩트는 저장 위치가 중요합니다. 스크린샷은 PR에 첨부하거나 object storage에 올리고, terminal output은 너무 길면 요약과 원본 링크를 분리합니다. 승인 로그는 별도 감사 로그에 남기는 편이 좋습니다.
출처: Google Developers Blog “Build with Google Antigravity”, OpenAI “Work with Codex from anywhere” 공개 내용 기반.
