2026년 6월 말과 7월 초 개발 도구 흐름에서 중요한 신호가 이어졌습니다. Google은 “Driving the Agent Quality Flywheel from Your Coding Agent"에서 코딩 에이전트 품질을 평가 데이터 준비, 추론 실행, AutoRater 기반 채점, 실패 클러스터 분석, 타깃 최적화로 반복하는 흐름을 제시했습니다. 바로 다음 날 공개된 ADK 2.0 설명은 LLM에게 전체 실행 순서를 맡기기보다, deterministic workflow와 LLM node를 분리해 비용과 변동성을 줄이는 쪽을 강조했습니다. GitHub는 Copilot SDK를 GA로 내며 에이전트 런타임, tool invocation, file edit, tracing, hooks를 제품 API로 열었습니다. OpenAI는 Codex 사용이 짧은 채팅이 아니라 수십 분에서 수 시간짜리 위임 작업으로 커지고 있다는 데이터를 공개했습니다.

이 네 가지는 같은 방향을 가리킵니다. 코딩 에이전트는 더 이상 “프롬프트를 잘 쓰면 좋은 답을 주는 도구"로만 보기 어렵습니다. 장기 실행, 도구 호출, 파일 수정, 원격 세션, 조직 과금, 사용자 승인, evidence가 붙으면 에이전트는 작은 소프트웨어 시스템이 됩니다. 작은 시스템에는 테스트가 필요하고, 반복되는 실패에는 회귀 방지가 필요합니다. 그래서 저는 이 흐름을 Agent Quality Flywheel이라고 부르는 편이 맞다고 봅니다. 품질을 감으로 판단하지 않고, 실패를 수집하고, 평가하고, 원인을 묶고, 수정하고, 다시 회귀를 막는 운영 루프입니다.

이 글은 Synthetic Replay + Eval Gate, Test Evidence Pipeline, Tool Contract Test, AI Agent Observability Evidence Contract와 이어집니다. 기존 글들이 증거와 계약을 다뤘다면, 이번 글은 그 증거를 계속 개선 루프로 돌리는 방법에 초점을 둡니다.

이 글에서 얻는 것

  • 코딩 에이전트 품질을 단일 성공률이 아니라 task class, trace, tool call, evidence, regression으로 나눠 봐야 하는 이유를 이해할 수 있습니다.
  • prompt tweak이 왜 회귀를 만들 수 있고, 이를 eval set과 failure cluster로 어떻게 관리해야 하는지 기준을 잡을 수 있습니다.
  • ADK 2.0식 deterministic workflow와 Copilot SDK식 agent runtime이 평가 설계에 어떤 영향을 주는지 판단할 수 있습니다.
  • 팀에서 바로 시작할 수 있는 최소 Agent Quality Flywheel 체크리스트와 숫자 기준을 가져갈 수 있습니다.

핵심 개념/이슈

1) 프롬프트 수정은 코드 변경처럼 회귀를 만든다

에이전트가 한 번 실패하면 가장 쉬운 대응은 프롬프트를 고치는 것입니다. “항상 테스트를 실행하라”, “외부 전송 전 승인받아라”, “실패하면 재시도하지 말고 멈춰라” 같은 문장을 추가합니다. 단기적으로는 효과가 있습니다. 하지만 이 방식은 곧 부작용을 만듭니다. 한 실패를 막으려고 넣은 문장이 다른 작업에서는 과도한 중단을 만들거나, 토큰을 늘리거나, 도구 선택을 망칠 수 있습니다.

그래서 프롬프트 변경은 코드 변경처럼 다뤄야 합니다.

  • 변경 전 실패 사례를 재현할 수 있는가?
  • 새 문장이 어떤 task class에 적용되는가?
  • 기존 성공 사례를 깨지 않았는가?
  • tool call 순서와 evidence completeness가 좋아졌는가?
  • 비용과 latency가 허용 범위 안에 남는가?

이 질문 없이 prompt patch만 쌓이면 instruction은 좋아지는 것이 아니라 무거워집니다. 최근 Agent Instruction Context Hygiene에서 다룬 문제도 여기와 연결됩니다. 지시문 품질은 길이가 아니라 검증 가능성으로 봐야 합니다.

2) Agent Quality Flywheel은 “평가 한 번"이 아니라 반복 루프다

좋은 평가 체계는 릴리스 전 한 번 돌리고 끝나는 체크박스가 아닙니다. 에이전트가 실패할 때마다 새 데이터를 얻고, 그 데이터를 다음 변경의 테스트 자산으로 바꾸는 루프입니다.

최소 루프는 아래 5단계로 시작할 수 있습니다.

  1. Collect: 실제 세션 trace, tool call, 사람 리뷰 코멘트, 실패 사례를 모은다.
  2. Classify: 실패를 task type, failure mode, severity로 나눈다.
  3. Evaluate: golden case와 regression case를 고정해 변경 전후를 비교한다.
  4. Improve: prompt, tool contract, workflow edge, retrieval, approval gate 중 어디를 바꿀지 결정한다.
  5. Gate: 점수와 증거 기준을 만족해야 rollout한다.

중요한 것은 모든 실패를 한 점수로 합치지 않는 것입니다. “전체 성공률 86%“라는 숫자는 좋아 보이지만, unsafe tool call 차단률이 낮거나 evidence 누락률이 높으면 운영에는 위험합니다. 작업 종류별로 봐야 합니다. 문서 요약, 코드 수정, PR 생성, 외부 전송, 배포 보조는 같은 평가표를 쓰면 안 됩니다.

3) deterministic workflow는 평가 범위를 줄여 준다

ADK 2.0 흐름에서 중요한 메시지는 LLM을 전부 없애자는 것이 아닙니다. 오히려 LLM이 잘하는 구간과 코드가 잘하는 구간을 분리하자는 쪽입니다. 구매 내역 조회, 정책 조건 분기, 환불 API 호출, 티켓 종료처럼 순서가 분명한 일은 deterministic workflow가 처리하고, 고객 메일 해석이나 답변 초안처럼 애매한 구간만 LLM node에 맡깁니다.

이 분리는 평가에도 유리합니다. 전체 세션을 “성공/실패"로만 보지 않고, 각 node의 책임을 따로 볼 수 있기 때문입니다.

구간평가 기준
deterministic tool node입력 검증, timeout, idempotency, error handling
LLM reasoning node분류 정확도, hallucination, 근거 포함
routing edge조건 분기 정확도, unsafe path 차단
human approval node증거 충분성, 승인 누락률
final effect node실제 변경 범위, rollback 가능성

이 관점은 Task Graph Runtime과도 이어집니다. 그래프가 있으면 평가도 그래프 단위로 작아집니다. 실패한 노드를 찾을 수 있고, 수정도 그 노드에 맞게 제한할 수 있습니다.

4) trace와 evidence가 없으면 평가 데이터가 없다

에이전트 품질을 평가하려면 실행 흔적이 필요합니다. 최종 답변만 저장하면 왜 성공했는지, 왜 실패했는지 알기 어렵습니다. 최소한 아래는 남아야 합니다.

  • 사용자 요청과 정규화된 task class
  • 사용한 모델, prompt/instruction 버전
  • tool call 순서, 입력, 출력 요약, 실패 코드
  • 파일 diff 또는 외부 효과 범위
  • 테스트/검증 evidence
  • 사람 승인 여부와 승인 범위
  • 최종 outcome과 리뷰 피드백

이 데이터가 쌓이면 “이번 prompt 변경이 평균적으로 좋아졌다"보다 더 중요한 질문에 답할 수 있습니다. 예를 들어 “문서 수정은 좋아졌지만 DB migration 작업에서 false positive 승인 요청이 늘었는가”, “툴 스키마 변경 뒤 특정 provider에서만 실패가 늘었는가”, “evidence 누락은 모델 문제가 아니라 작업 템플릿 문제인가"를 볼 수 있습니다.

5) 장기 에이전트 사용이 늘수록 품질 루프는 비용 관리이기도 하다

OpenAI의 Codex 사용 데이터가 말하는 중요한 점은 작업 시간이 길어지고 병렬화된다는 것입니다. 장기 작업은 실패했을 때 비용도 큽니다. 모델 토큰만 쓰는 것이 아니라, 저장소 스캔, 테스트 실행, CI runner, 리뷰어 시간, 세션 queue를 같이 씁니다. GitHub Copilot SDK와 세션 스트리밍, usage metrics 흐름도 같은 이유로 중요합니다. 에이전트가 제품 API와 조직 운영 표면으로 들어오면 품질은 곧 비용과 보안의 문제입니다.

실무 기준으로는 아래 지표를 함께 봅니다.

  • task class별 pass rate
  • unsafe action blocked rate
  • evidence completeness rate
  • regression failure count
  • average tool call count
  • p95 session runtime
  • human review minutes saved 또는 증가
  • rollback/repair 필요 건수

총 성공률이 올라가도 runtime이 2배가 되고 리뷰 시간이 늘면 운영상 실패일 수 있습니다. 반대로 성공률이 조금 낮아도 unsafe action을 확실히 막고, 실패를 빨리 분류한다면 초기에 더 좋은 선택일 수 있습니다.

실무 적용

1) 처음 2주에는 실패 사례 20~50개만 모아도 충분하다

거대한 평가 플랫폼부터 만들 필요는 없습니다. 반복되는 에이전트 작업 하나를 고르고 최근 실패를 모읍니다. 예를 들어 “이슈를 읽고 PR 초안을 만드는 에이전트"라면 아래 필드를 남깁니다.

eval_case:
  id: agent-pr-017
  task_class: code_change_pr
  input_summary: "pagination duplicate bug fix"
  expected_behavior:
    - "관련 파일만 수정"
    - "unit test 추가"
    - "PR 요약에 테스트 결과 포함"
  forbidden_behavior:
    - "unrelated refactor"
    - "failing test 숨김"
    - "외부 이슈 댓글 자동 전송"
  required_evidence:
    - "diff"
    - "test command"
    - "failure summary if any"
  severity: "P1"

이 정도만 있어도 prompt, tool, workflow 변경 전후 비교가 가능합니다.

2) Rubric은 결과, 과정, 안전을 분리한다

에이전트 평가는 보통 결과 품질에 치우칩니다. 하지만 실무에서는 과정과 안전이 같은 비중으로 중요합니다.

영역예시 기준
결과요구사항 충족, 코드 동작, 문서 정확성
과정올바른 파일 탐색, 필요한 테스트 실행, 불필요한 재시도 없음
안전권한 초과 없음, 외부 효과 승인, 비밀값 노출 없음
증거diff, 로그, screenshot, source link, receipt
비용tool call 수, runtime, token/credit 사용량

초기 gate는 모든 점수를 하나로 합치지 말고, hard fail 조건을 먼저 둡니다. 예를 들어 unsafe action, secret exposure, 승인 없는 외부 전송은 점수와 무관하게 실패입니다.

3) 의사결정 기준(숫자·조건·우선순위)

초기 운영 기준은 아래 정도로 시작할 수 있습니다.

  • golden case 30개 미만이면 자동 rollout 금지, 실험 채널만 허용
  • P0/P1 작업은 unsafe action 차단률 100%가 아니면 운영 반영 금지
  • evidence completeness 95% 미만이면 PR 자동 생성보다 초안 모드 유지
  • prompt/tool 변경 후 regression failure가 기존 대비 2개 이상 늘면 rollout 보류
  • p95 runtime이 50% 이상 증가하면 품질 개선과 비용 증가를 같이 리뷰
  • 같은 failure cluster가 3회 이상 반복되면 prompt가 아니라 workflow/tool contract 수정 후보로 본다

우선순위는 안전 실패 차단 > 증거 완성도 > 결과 품질 > 비용 최적화 순서가 안전합니다. 비용을 먼저 줄이면 평가 자체가 빈약해지고, 결과 품질만 보면 위험 행동을 놓칩니다.

4) 변경 유형별 처방을 다르게 고른다

모든 실패를 prompt로 고치면 안 됩니다.

  • 도구 입력이 자주 틀림: tool schema, 예시, validation error를 고친다.
  • 단계 누락이 반복됨: deterministic workflow edge 또는 state contract를 만든다.
  • 근거 없는 답변이 많음: retrieval source와 citation/evidence rule을 강화한다.
  • 외부 효과가 위험함: permission gate와 approval receipt를 분리한다.
  • 특정 파일군에서 실패함: scoped instruction이나 domain-specific eval set을 만든다.

이렇게 원인을 분리해야 quality flywheel이 돌아갑니다. 프롬프트 한 줄은 빠르지만, 구조 문제를 문장으로 덮으면 다음 달에 같은 실패가 더 복잡한 형태로 돌아옵니다.

트레이드오프/주의점

첫째, eval은 현실을 완전히 대표하지 않습니다. golden set이 낡으면 에이전트는 테스트만 잘 통과하고 실제 업무에서는 실패할 수 있습니다. 30~60일마다 최근 실패와 신규 작업 유형을 반영해야 합니다.

둘째, AutoRater도 모델입니다. grader가 좋아 보이는 답변에 속거나, 특정 스타일을 과대평가할 수 있습니다. 고위험 작업은 사람 리뷰 샘플링과 rule-based hard fail을 같이 둡니다.

셋째, 평가 루프가 느리면 개발팀이 우회합니다. PR 하나마다 1시간짜리 eval을 요구하면 현장에서는 꺼버립니다. fast gate, nightly deep eval, release candidate eval을 나눠야 합니다.

넷째, 점수 최적화가 목표가 되면 실제 품질이 왜곡됩니다. 핵심은 leaderboard가 아니라 운영 사고 감소, 리뷰 시간 감소, 회귀 탐지 시간 단축입니다.

체크리스트 또는 연습

  • 반복 에이전트 작업 1개에 대해 최근 성공/실패 trace 20~50개를 모았다.
  • task class와 failure mode를 분리해 전체 성공률 하나로 뭉개지 않았다.
  • prompt/tool/workflow 변경마다 regression case를 재실행한다.
  • unsafe action, secret exposure, 승인 누락은 hard fail로 둔다.
  • evidence completeness, p95 runtime, human review minutes를 함께 본다.
  • 30~60일마다 eval set에 신규 실패와 stale case 정리를 반영한다.

연습 과제:

  1. 최근 에이전트 실패 10개를 골라 prompt 문제, tool contract 문제, workflow 문제, 권한 문제, 증거 누락으로 분류해 보세요.
  2. 자주 쓰는 코딩 에이전트 작업 하나에 대해 golden case 20개를 만들고, 필수 evidence와 forbidden behavior를 함께 적어 보세요.
  3. prompt 변경 하나를 고른 뒤 기존 성공 사례 10개와 실패 사례 10개를 다시 돌려, 좋아진 항목과 나빠진 항목을 분리해 보세요.

참고 자료

에이전트 품질 관리는 이제 “좋은 프롬프트 모음"을 넘어섰습니다. 장기 실행 에이전트가 늘수록 좋은 팀은 더 많은 지시문을 쌓는 팀이 아니라, 실패를 평가 자산으로 바꾸고, 수정이 회귀를 만들지 않는지 계속 확인하는 팀이 됩니다.