AI 에이전트의 작업을 어떻게 검품할 것인가──Trace, Eval, Pre-CI Review의 사고방식 제2회

이 기사는 「AI 에이전트를 공정에 넣기」 시리즈의 제2회입니다.

제1회에서는 AI 에이전트에게 전달할 사양서(Specification)를 작성하는 방법을 다루었습니다.

이번에는 그 이후에 반드시 찾아오는 문제, 즉 「나온 결과물을 어떻게 검품할 것인가」를 다룹니다.

AI 에이전트를 사용하기 시작하면 가장 먼저 빨라지는 것은 구현입니다.

Claude Code나 Codex에 맡기면, 기존 코드를 읽고, 차분(diff)을 만들고, 테스트를 추가하고, 실패 로그를 읽고 수정합니다. 지금까지 인간이 하나씩 해왔던 작업을 상당한 속도로 진행할 수 있습니다.

하지만 그다음 다른 병목 현상(Bottleneck)이 발생합니다.

리뷰(Review)입니다.

AI가 단 1개의 PR을 만든다면 인간이 보면 됩니다.

10개라면 아직 어떻게든 할 수 있습니다.

하지만 50개, 100개, 700개가 된다면 어떻게 해야 할까요.

생성만 한다면 700개도 낼 수 있습니다. 하지만 검품 메커니즘이 없다면, 똑같은 700개가 이번에는 700건분의 리뷰 부채(Review Debt)가 됩니다.

여기서 필요한 것은 「AI에게 다시 한번 리뷰를 시키는 것」만이 아닙니다.

어떤 변경 사항을 인간이 봐야 하는가.

어떤 변경 사항은 기계적으로 탈락시킬 수 있는가.

어떤 실패를 eval(평가)로 넘길 것인가.

어떤 trace(추적)를 남길 것인가.

CI에 들어가기 전에 어디서 멈출 것인가.

리뷰 결과를 다음 사양서나 AGENTS.md로 되돌릴 것인가.

이러한 계층을 만들지 않으면, AI 에이전트는 빠른 작업자가 아니라 빠른 리뷰 부채 생성기가 됩니다.

인간이 작성한 코드의 리뷰라면, PR을 열고 diff를 읽고, 코멘트를 달고, 수정을 요청하는 방식으로 순환됩니다.

AI 에이전트의 출력물도 처음에는 똑같아 보입니다.

하지만 양이 변하면 성질이 변합니다.

AI는 지치지 않습니다. 병렬로 동작합니다. 작은 수정도 대량으로 만들 수 있습니다. 로그를 읽고 몇 번이고 수정할 수 있습니다. 즉, 출력의 상한선이 인간의 손보다 높습니다.

그만큼 리뷰 측이 막히게 됩니다.

여기서 review를 「인간이 읽는 작업」이라고만 생각하면 파탄 납니다.

AI 에이전트 시대의 review는 다음 4가지로 나누는 것이 좋습니다.

1. Trace: 무슨 일이 일어났는지 남기기
2. Triage: 무엇을 봐야 할지 분류하기
3. Eval: 기계적으로 판정할 수 있는 것을 판정하기
...

인간 리뷰는 마지막에 남습니다.

다만, 인간에게 넘기기 전에 상당한 양을 정리할 수 있습니다.

AI 에이전트 작업에서 곤란한 점은 나중에 추적하기 어렵다는 것입니다.

어떤 프롬프트(Prompt)로 시작되었는지.

어떤 파일을 읽었는지.

어떤 명령어를 실행했는지.

어떤 테스트가 실패했는지.

어떤 로그를 보고 어떻게 수정했는지.

어떤 판단을 인간이 승인했는지.

이것이 남아 있지 않으면, 리뷰는 diff로부터 추리할 수밖에 없습니다.

인간이 작성한 PR이라도 배경이 없는 diff는 읽기 어렵습니다. AI가 만든 diff라면 더욱 그렇습니다.

그래서 우선 trace가 필요해집니다.

trace는 깔끔한 대시보드일 필요는 없습니다. 처음에는 작업 로그로 충분합니다.

agent에게 마지막에 이렇게 출력하게 하는 것만으로도 달라집니다.

마지막으로 작업 로그를 정리해 주세요.
- 최초의 목적
- 읽은 주요 파일
...

이것이 있으면 reviewer는 diff를 보기 전에 문맥(Context)을 읽을 수 있습니다.

Trace에서 보고 싶은 것은 긴 대화 로그 그 자체가 아닙니다.

봐야 할 것은 판단에 필요한 지점입니다.

보는 것	필요한 이유
목적	최초의 의뢰에서 벗어나지 않았는지 확인
...

PromptLayer와 같은 trace 계열 도구는 이 위치에 들어갑니다.

「프롬프트 관리 도구」로 보기보다, review의 재료를 남기는 부품으로 보는 것이 이해하기 쉽습니다. 어떤 의뢰로부터 어떤 출력이 태어났고, 어디서 비용이나 실패가 발생했는지를 추적할 수 있다면 나중에 개선할 수 있습니다.

trace가 없는 eval은 만들기 어렵습니다. trace가 없는 review는 개인의 역량에 의존하게 됩니다.

다음에 필요한 것은 triage입니다.

모든 AI 생성 diff를 같은 무게로 볼 필요는 없습니다.

예를 들어, 다음 변경 사항은 가볍습니다.

• typo 수정
• README의 작은 보충
• 테스트 이름 수정
• 명백하게 국소적인 타입(Type) 수정

반면, 다음은 무겁습니다.

• 인증 관련
• 결제 관련
• DB migration
• 권한 체크
• 외부 API 호출
• 보안 경계
• 대규모 리팩토링
• 테스트 삭제

같은 review queue에 넣으면 인간은 지칩니다.

그래서 우선 분류합니다.

이 diff를 triage(분류) 해주세요.
분류:
- trivial (사소한 변경): 문구, 주석, 국소적인 타입 수정
...

이 triage는 사람이 해도 되고, 다른 agent (에이전트)에게 시켜도 됩니다.

중요한 것은 reviewer (리뷰어)가 갑자기 모든 diff (차이점)를 마주하지 않는 것입니다.

GitHub의 diff view는 사람이 작성한 중소규모 PR (Pull Request)을 읽기에는 잘 만들어져 있습니다.

하지만 AI 에이전트 시대에는 PR에 포함되는 내용이 늘어납니다.

• 구현 차이 (Implementation diff)
• 테스트 차이 (Test diff)
• 생성된 보조 파일
• 스냅샷 업데이트
• 로그
• agent (에이전트)의 작업 메모
• 여러 차례의 수정 이력

diff만 봐서는 문맥 (Context)이 부족합니다.

Linear Diffs와 같은 PR review workflow (리뷰 워크플로우)는 이 문맥을 바탕으로 봅니다. 단순히 diff를 보기 좋게 만드는 도구가 아니라, 사람이 봐야 할 변경 사항을 어떻게 나열할지, 어떤 변경 사항을 먼저 볼지, 어디를 접을지 결정하는 triage (분류)의 부품입니다.

AI 생성 코드가 늘어날수록, review UI (리뷰 UI)는 '전부를 보여주는 곳'에서 '봐야 할 것을 좁히는 곳'으로 변합니다.

review (리뷰)에서 매번 같은 것을 보고 있다면, 그것은 eval (평가)로 만들 수 있습니다.

eval (평가)에서 중요한 것은 평가를 분위기로 하지 않는 것입니다. 자신의 프로덕트에 맞춘 평가 항목을 만들고, 실제 데이터와 실패 사례를 보며 개선 루프를 돌려야 합니다.

coding agent (코딩 에이전트)도 마찬가지입니다.

처음부터 거창한 eval (평가) 기반을 만들 필요는 없습니다.

처음에는 checklist (체크리스트)로 충분합니다.

AI 생성 diff 최소 체크 사항:
- 변경 대상 외의 파일을 건드리지 않았는가
- 기존 테스트를 삭제하지 않았는가
...

이것을 사람이 매번 확인합니다.

다음으로, 기계화할 수 있는 것들을 스크립트로 만듭니다.

- 테스트 삭제를 검출한다
- migration (마이그레이션) 변경을 검출한다
- auth (인증) 디렉토리 변경을 risky (위험)로 분류한다
...

나아가, AI에 의한 1차 판정이 적합한 것들만 자동 판정으로 넘깁니다.

- 사양에서 벗어나지 않았는가
- 에러 상태에 대한 설명이 충분한가
- review summary (리뷰 요약)가 올바른가
...

전부를 LLM judge (LLM 판사)로 만들 필요는 없습니다.

규칙으로 걸러낼 수 있는 것은 규칙으로 걸러냅니다.

test (테스트)로 걸러낼 수 있는 것은 테스트로 걸러냅니다.

LLM judge (LLM 판사)는 언어적·문맥적 판단이 필요한 곳에 사용합니다.

이러한 구분 방식이 중요합니다.

eval (평가)는 세세한 체크만으로는 부족합니다.

작은 eval (평가)는 하나의 출력을 보는 것입니다.

• 테스트를 삭제하지 않았는가
• migration (마이그레이션)이 늘어나지 않았는가
• secret (비밀 정보) 같은 문자열이 없는가
• 사양에 없는 파일을 건드리지 않았는가
• PR 설명에 테스트 결과가 있는가

이것은 기계화하기 쉽습니다.

반면, 큰 eval (평가)는 작업 전체를 보는 것입니다.

• 조사부터 구현까지의 흐름이 타당한가
• 최초의 가설이 틀리지 않았는가
• failing test (실패하는 테스트)가 정말로 버그를 나타냈는가
• 수정 후에 동일한 종류의 실패를 방지할 수 있는가
• review (리뷰)의 지적 사항이 다음 회차의 규칙으로 반영되었는가

이것은 단순한 lint (린트)로는 볼 수 없습니다.

작업 로그, diff (차이점), 테스트, review (리뷰), Compound note (복합 노트)를 종합적으로 봅니다.

AI 에이전트의 eval (평가)은 단발적인 답변 채점만으로는 약합니다.

실무에서는 하나의 출력보다, 하나의 작업이 마무리되는 방식을 볼 필요가 있습니다.

좋은 작업:
- 목적이 명확함
- 변경 범위가 작음
...

이러한 관점을 도입하면, eval (평가)은 '채점'이 아니라 작업 품질을 보는 메커니즘이 됩니다.

AI 에이전트의 출력 중에는 CI (지속적 통합) 단계까지 가기 전에 차단하고 싶은 것들이 있습니다.

예를 들어, 다음과 같은 차이점들입니다.

• 관계없는 파일을 대량으로 변경함
• 테스트를 삭제함
• 테스트를 skip (건너뛰기) 함
• lockfile (잠금 파일)만 크게 변함
• migration (마이그레이션)이 있는데 rollback (롤백)이 없음
• 인증·권한 관련을 건드리고 있는데 설명이 없음
• secrets (비밀 정보) 같은 문자열이 섞여 있음

이것들은 CI (지속적 통합) 이전에 검출할 수 있습니다.

Chunk sidecars와 같은, CI (지속적 통합)에 진입하기 전의 검증 계열 메커니즘은 이 위치에 해당합니다.

목적은 'AI 리뷰를 똑똑하게 만드는 것'이 아닙니다.

CI (지속적 통합)에 넣기 전에, 명백히 위험한 차이점을 차단하는 것입니다.

예를 들어, CI (지속적 통합)에 들어가기 전에 다음과 같은 분류를 수행합니다.

safe:
- docs-only
- test-only
...

blocked는 인간의 승인 없이 진행할 수 없습니다.

needs-review는 review queue에 넣습니다.

safe는 가벼운 review로 넘깁니다.

이렇게 나누면 인간의 눈을 사용해야 할 곳을 좁힐 수 있습니다.

여기까지 trace, triage, eval, CI에 들어가기 전의 검증에 대해 작성했습니다.

그럼에도 불구하고, 인간의 리뷰(human review)는 남습니다.

오히려, 이곳이 남을 수 있도록 전 단계를 구축합니다.

인간이 판단해야 할 것은 다음과 같습니다.

• 이 사양(specification)이 정말 필요한가
• 이번 PR(Pull Request)에서 수행해야 하는 작업인가
• 리스크를 수용할 것인가
• 기존 설계와 다르지만, 바꿀 가치가 있는가
• 사용자 경험(UX)으로서 자연스러운가
• 운영 팀이 다룰 수 있는가
• 보안상 이 경계가 적절한가

이것은 에이전트(agent)에게 전적으로 맡길 수 없습니다.

에이전트는 재료를 정리할 수 있습니다. 후보를 제시할 수 있습니다. 위험한 점을 지적할 수 있습니다. 하지만 제품상의 우선순위나 조직으로서의 리스크 허용 범위는 인간이 가져야 합니다.

따라서 좋은 리뷰 흐름(review flow)은 인간을 제거하지 않습니다.

인간이 봐야 할 것들만 남깁니다.

제1회 사양서에서 만든 상품 검색 기능을 예로 들어보겠습니다.

에이전트가 구현하여 PR을 만들었다고 가정합니다.

먼저 trace를 출력하게 합니다.

이 PR의 작업 로그를 정리해 주세요.
- 최초 목적
- 읽은 파일
...

그다음 triage를 수행합니다.

이 PR을 risky / normal / trivial로 분류해 주세요.
관점:
- API 변경
...

그다음 eval/checklist를 통과시킵니다.

다음 사항을 확인해 주세요.
- 상품명 검색에만 국한되어 있는가
- SKU 검색을 추가하지 않았는가
...

마지막으로 인간이 확인합니다.

인간은 모든 것을 보는 것이 아닙니다.

• 사양에서 벗어나지 않았는가
• UI로서 자연스러운가
• 테스트 관점이 충분한가
• 이번에 하지 않기로 결정한 사항을 준수하고 있는가

이 순서라면 리뷰어(reviewer)는 갑자기 diff의 바다에 빠지지 않아도 됩니다.

리뷰는 그 자리에서 끝내버리면 약합니다.

매번 같은 지적을 하고 있다면, 그것을 다음 사양서, AGENTS.md, checklist, eval로 되돌려 보내야 합니다.

예를 들어, 이번에 다음과 같은 지적이 나왔다고 가정해 봅시다.

카테고리 필터와 검색 조건을 동시에 사용하는 테스트가 누락되었다.

그 자리에서 고치기만 한다면, 다음에도 또 누락될 것입니다.

다음과 같이 되돌립니다.

AGENTS.md:

목록 화면에 검색/필터를 추가할 경우,
기존 필터와의 조합 테스트를 반드시 검토한다.

사양서 템플릿:

기존 필터, 정렬(sort), 페이지네이션(pagination)과의 조합을 확인한다.

eval/checklist:

filter / search / sort 중 하나라도 변경된 PR에서는,
조합 테스트의 유무를 확인한다.

이렇게 리뷰의 배움을 다음 계획(Plan)으로 되돌립니다.

이 과정이 없으면 리뷰는 단순한 소모가 됩니다.

이번 회차에서도 도구(tool)가 주인공은 아닙니다.

문제가 막히는 지점에서 도구가 등장합니다.

어떤 프롬프트에서 어떤 출력이 나왔는지, 어디서 비용이 증가하고 어디서 실패했는지를 추적하고 싶다면 PromptLayer와 같은 trace 계열 도구가 등장합니다.

봐야 할 점은 UI의 깔끔함이 아닙니다.

• 작업 단위로 trace를 추적할 수 있는가
• 리뷰에 필요한 정보만 추출할 수 있는가
• 비용과 실패를 연결 지을 수 있는가
• 나중에 eval dataset으로 돌릴 수 있는가

AI가 만든 차이(diff)를 CI에 넣기 전에 검증하고 싶다면 Chunk sidecars와 같은 메커니즘이 등장합니다.

봐야 할 점은 얼마나 많이 검출할 수 있는가만이 아닙니다.

• 오탐(false positive)으로 인해 개발이 너무 많이 중단되지 않는가
• blocked / needs-review / safe를 나눌 수 있는가
• 인간의 승인을 어디에 넣을 것인가
• 기존 CI와 어떻게 연결할 것인가

AI 에이전트의 PR이 늘어나 diff를 읽기 어려워진다면 Linear Diffs와 같은 리뷰 워크플로우(review workflow)가 등장합니다.

봐야 할 점은 diff의 외관만이 아닙니다.

• 변경 의도를 추적할 수 있는가
• 관련 파일을 모아서 볼 수 있는가
• 인간이 봐야 할 부분을 제시할 수 있는가
• 에이전트의 작업 로그와 diff를 연결할 수 있는가

도구는 리뷰 (review) 공정의 병목 현상에 대응하기 위해 등장합니다.

AI 에이전트 (AI agent)를 사용하면 구현 속도는 빨라집니다.

하지만 리뷰 (review) 방식이 그대로라면, 빨라진 속도만큼 리뷰 부채 (review debt)가 증가합니다.

필요한 것은 또 한 명의 AI 리뷰어 (AI reviewer)가 아닙니다.

Trace (트레이스).

Triage (트리아지).

Eval (평가).

Pre-CI Review (Pre-CI 리뷰).

Human Review (인간 리뷰).

그리고 리뷰 (review) 결과를 다음 플랜 (Plan)으로 되돌리는 메커니즘.

이러한 흐름이 있다면 AI 에이전트 (AI agent)의 출력물은 다루기 쉬워집니다.

반대로 이 흐름이 없다면, 에이전트 (agent)가 만들어낸 양을 인간이 전부 감당해야 합니다.

AI 시대의 리뷰 (review)는 '읽는 능력'만으로는 부족합니다.

어디를 기계에 맡길 것인가.

어디를 인간에게 남길 것인가.

어디에서 멈출 것인가.

무엇을 다음 회차의 규칙으로 되돌릴 것인가.

이 부분을 설계하는 것이 리뷰 (review)의 업무가 됩니다.

다음 회차에서는 리뷰 (review)에서 발견된 실패를 어떻게 다음 회차로 되돌릴지를 다룹니다.

AGENTS.md,

memory (메모리), skill (스킬), compound engineering (컴파운드 엔지니어링)에 관한 이야기입니다.