당신의 에이전트(Agents)들은 생산적입니다. 풀 리퀘스트(Pull request) 양은 늘어났고, 데모는 성공적으로 진행되며, 모든 머지(Merge) 시 파이프라인은 초록색(Green)을 유지합니다. 여기서 불편한 사실이 있습니다. 초록색이라는 것은 코드가 컴파일되었고 테스트가 통과했다는 것을 의미하는데, 점점 더 코드를 작성한 것과 동일한 에이전트가 테스트까지 작성하고 있다는 점입니다. 그 파이프라인의 그 어떤 것도 작업이 실제로 올바른지를 측정하지 못합니다. 과거에 "검증된 정확함(verified right)"이 담당하던 무게를 이제는 "맞아 보임(Looks right)"이 대신하고 있습니다.

당신 앞의 결정은, CI가 인간이 작성한 코드에 대한 수락 계층(Acceptance layer)이 된 것처럼 에이전트가 생성한 작업에 대한 수락 계층을 구축할 것인지, 아니면 시각적 검사(Visual inspection) 위에 에이전트의 자율성을 계속 확장할 것인지에 관한 것입니다. 에이전트는 요란하게 실패하지 않습니다. 모델 업데이트가 배포되고, 지원 에이전트가 에스컬레이션(Escalation) 신호를 놓치기 시작해도 에러는 발생하지 않으며, 몇 주 뒤 이탈률(Churn metrics)을 보고서야 이를 알게 됩니다. 자율성을 안전하게 확장하는 팀은 가장 좋은 프롬프트(Prompts)를 가진 팀이 아닐 것입니다. 그들은 가장 규율 있는 평가(Evals)를 가진 팀이 될 것입니다.

먼저, 이 용어 자체가 논쟁의 핵심을 담고 있습니다. 평가(Eval)란 당신이 정의한 기준에 따라 에이전트의 출력물을 반복 가능하고 점수가 매겨지는 방식으로 테스트하는 것입니다. 이는 "테스트를 통과했는가"가 아니라 "이 변경 사항이 티켓의 범위 내에서 정확하고 머지하기에 안전한가"를 묻는 것입니다. 유닛 테스트(Unit test)가 결정론적(Deterministic)인 코드에 대해 통과 또는 실패를 반환하는 반면, 평가는 단순한 스크립트부터 작성된 루브릭(Rubric)을 바탕으로 다른 모델을 심사하는 모델에 이르기까지 다양한 채점자(Graders)를 사용하여 여러 차원에서 판단을 등급화합니다. CI가 모든 커밋(Commit)에 대해 실행되는 것처럼, 모든 변경 사항에 대해 실행되는 이러한 평가 체계를 저는 평가 자산(Eval estate)이라고 부를 것입니다. 이 시리즈의 이전 글에서 저는 작성하는 에이전트가 검사하는 에이전트가 되어서는 안 된다고 주장했으며, 이를 통해 누가 심판할지는 결정되었습니다. 더 어려운 문제이자 이번 에피소드의 주제는, 심판자가 무엇이 좋은 것인지 어떻게 아느냐는 것입니다.

수락 계층이 산업 전반에 걸쳐 재구축되고 있습니다

Anthropic의 엔지니어링 팀은 2026년 1월, ["Demystifying evals for AI agents">(https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)를 통해 이러한 재정의를 발표했습니다. 즉, 평가(evaluations)는 연구의 사후 고려 사항이 아니라, 에이전트 시스템(agentic systems)을 위한 CI/CD 파이프라인이라는 것입니다. 몇 주 만에 Braintrust는 테스트 주도 개발 (TDD)에 대한 에이전트 방식의 해답인 eval-driven development (평가 주도 개발, EDD)를 통해 이 비유를 정교화했습니다. 여기서 중요한 차이점 하나가 있습니다. TDD는 이진적(binary)이지만, EDD는 여러 차원에 걸쳐 점수를 매깁니다. 왜냐하면 답변이 사실적으로는 정확하지만 너무 길 수도 있고, 형식이 잘 갖춰져 있지만 핵심 정보가 누락될 수도 있기 때문입니다. 여러 벤더들이 같은 분기에 동일한 운영 규칙을 채택했습니다. 만약 에이전트의 지표가 벤치마크 세트의 임계값(threshold)을 충족하지 못하면, 배포는 자동으로 실패합니다. 이 글을 읽고 계신다면 평가가 중요하다는 사실을 설득할 필요는 없다고 생각합니다. 대신, 팀들이 실제로 평가를 어떻게 구축하는지, 그리고 어디에서 실수를 하는지를 보여드리고자 합니다.

Braintrust의 작업 예시는 일상적인 리듬을 가장 잘 보여줍니다. 팀이 더 최신 모델로 교체하면, 첫 번째 평가 실행에서 어조(tone)가 0.85에서 0.72로 떨어지는 것을 확인합니다. 그들은 프롬프트(prompt)를 조정하고 다시 실행하여, 정확도를 유지하면서 어조를 0.88로 회복시킵니다. 처음부터 끝까지 20분이 걸립니다. 평가 체계가 없다면, 이러한 퇴보(regression)는 2주 후에 고객 불만으로 나타나게 됩니다.

왜 당신의 테스트 스위트가 이 일을 수행할 수 없는가

단위 테스트 (Unit tests)가 작동하는 이유는 동일한 입력에 대해 동일한 출력이 반환되기 때문입니다. 에이전트는 그 계약을 깨뜨립니다. 동일한 프롬프트가 실행 시점과 모델 버전에 따라 서로 다른 출력을 생성하고, 오류는 다회차 상호작용 (multi-turn interactions)을 거치며 누적되며, 에이전트는 당신이 전혀 예상하지 못한 해결 경로를 선택합니다. 당신의 테스트 스위트는 코드를 검사합니다. 하지만 판단력 (judgment)을 검사하는 것은 아무것도 없습니다.

또한 인간이 코드를 작성할 때는 존재하지 않았던 실패 모드인 '테스트 게임화 (test-gaming)'가 있습니다. 개발자가 자신의 테스트 스위트를 속이는 경우는 드뭅니다. 하지만 에이전트의 경우, 의도적으로 이를 방지하도록 설계하지 않는 한 테스트 통과를 위해 최적화하는 것이 기본값입니다.

무엇을 채점할 것인가: 정확성은 쉬운 3분의 1일 뿐이다

Anthropic의 분류 체계(taxonomy)는 다음과 같은 메커니즘을 제공합니다:

• 결정론적 확인(deterministic checks)을 위한 코드 기반 채점기 (code-based graders)
• 루브릭 판단(rubric judgments)을 위한 모델 기반 채점기 (model-based graders)
• 모델 기반 채점기를 보정(calibrate)하기 위해 주로 제한적으로 사용되는 인간 채점기 (human graders)

하지만 "무엇을 채점할 것인가?"라는 질문에 대한 가장 유용한 답변은 36명의 외부 오픈 소스 유지 관리자(maintainers)를 통해 구축된 Cognition의 자체 벤치마크인 FrontierCode에서 나왔습니다. 이들은 다음 6가지 차원에서 패치(patch)를 평가했습니다:

• 행동적 정확성 (behavioural correctness)
• 회귀 안전성 (regression safety)
• 기계적 깔끔함 (mechanical cleanliness)
• 테스트 정확성 (test correctness)
• 범위 준수 (scope discipline)
• 코드 품질 (code quality)

오늘날 귀하의 파이프라인은 이 목록 중 얼마나 많은 항목을 측정하고 있습니까?

플레이북: 이미 보유한 자산으로부터 자산(Estate) 구축하기

표준적인 반론은 평가 세트(eval sets)를 만드는 데 엄청난 양의 수동 레이블링(manual labeling)이 필요하다는 것입니다. 하지만 귀하의 조직은 이미 원재료를 보유하고 있습니다. 프로덕션 환경에서 살아남을 수 있는 순서대로 4단계를 제시합니다.

1. PR 이력과 사후 분석(postmortems)으로부터 세트의 씨앗(Seed)을 심으십시오. SWE-bench가 템플릿을 확립했습니다: 연결된 이슈를 해결하고 테스트를 수정한 병합된 PR을 마이닝하고, 수정 전의 리포지토리(repo) 상태를 재구성한 뒤, 패치 전에는 테스트가 실패하고 패치 후에는 다른 모든 것이 정상(green)인 상태에서 테스트만 통과하는 사례만 남깁니다. 이들은 약 90,000개의 PR을 2,294개의 깨끗한 사례로 필터링했는데, 이는 실제 리포지토리가 얼마나 많은 재료를 보유하고 있는지와 필터링이 얼마나 엄격해야 하는지를 동시에 알려줍니다. 귀하의 리뷰 코멘트(review comments)는 두 번째 핵심 자원입니다. Cursor Bugbot, Qodo, Greptile, CodeRabbit은 정확히 이 데이터로부터 학습된 규칙을 구축하고 있습니다. 귀하의 인시던트(incidents)는 세 번째 자원입니다. 회귀 평가(regression eval)를 추가하는 것과 같이 무언가 변화가 생기기 전까지는 사후 분석(postmortem)이 완료된 것이 아닙니다. 그렇지 않다면 그것은 엔지니어링이 아니라 문서화에 불과합니다. 함정: 상상력을 동원해 평가 사례를 작성하는 것; 그렇게 하면 실제로 일어나는 일이 아니라 당신이 두려워하는 것을 테스트하게 될 것입니다. 신호: 모든 평가 사례는 실제 PR, 인시던트, 또는 프로덕션 트레이스(production trace)로 추적 가능해야 합니다.

2. 에이전트가 읽을 수 없는 곳에 행동 시나리오(behavioral scenarios)를 저장하세요. StrongDM의 구조적 해결책은 제가 본 것 중 가장 깔끔합니다. 행동 시나리오를 코드베이스 외부에 보관하여 에이전트가 작업하는 동안에는 보이지 않게 유지하며, 마치 머신러닝의 홀드아웃 세트(holdout set)처럼 작동하게 하는 방식입니다. 에이전트는 자신이 결코 볼 수 없는 기준에 대해서는 최적화할 수 없습니다. 이는 판사(judge)에게도 동일하게 적용됩니다. 판사는 제작자(maker)의 추론 과정을 봐서는 안 되며, 그렇지 않으면 제작자의 가정을 그대로 물려받게 됩니다. 함정: "투명성"을 위해 평가 기준을 리포지토리(repo)에 넣는 것인데, 이 경우 에이전트가 이를 읽고 체크리스트의 문구 그대로에 맞춰 최적화해 버립니다. 신호: 홀드아웃 시나리오에 대한 에이전트의 통과율이 리포지토리 내 테스트의 통과율보다 눈에 띄게 낮아야 합니다.

3. 판사가 게이트키핑(gate)을 하기 전에 교정(calibrate)하세요. LLM-as-judge는 이 모든 과정의 확장 메커니즘이지만, 규율이 보통 무너지는 지점이기도 합니다. 2026년까지 유통되는 업계 수치에 따르면, 판사를 제대로 구현하지 못하는 팀의 비율은 약 93%에 달합니다. 저는 이 수치를 방향성을 나타내는 지표로 보지만, 근본 원인은 모델의 성능 저하가 아니라 교정(calibration)의 부재입니다. 저는 이를 직접적인 경험을 통해 배웠습니다. Betsson의 AI-DLC 하네스(harness) 내에서 처음 실행했던 Reviewer 에이전트는 자신이 보는 거의 모든 것을 승인했습니다. 에이전트는 통과(pass) 또는 실패(fail)라는 이진 질문(binary question)에 답했고, 유능한 모델은 그럴싸해 보이는 코드에 대해 이진 질문을 던지면 통과라고 답했습니다. 게이트가 비로소 작업을 거부하기 시작한 것은, 예/아니오(yes/no) 체크를 실제 인간 검토자들이 거부했던 항목들로 구축된 점수 기반 루브릭(scored rubrics)으로 교체했을 때였습니다. 즉, 커버되었다고 선언되었으나 실제로는 그렇지 않은 에지 케이스(edge cases), 통과할 때까지 약화된 테스트, 티켓의 범위를 벗어나 방대해진 변경 사항 등을 포함한 루브릭입니다. 이를 통해 도출된 워크플로우는 다음과 같습니다: 각 등급을 평이한 용어로 정의하여 점수 기반 루브릭을 작성하세요(0.2는 어떤 모습인지, 0.8은 어떤 모습인지); 이미 알려진 실패 사례들로 구성된 고정된 그라운드 트루스(ground-truth) 세트를 유지하세요; 해당 세트에 대해 판사와 인간 검토자 간의 일치도를 측정하세요; 일치도가 대략 75~90% 미만인 경우에는 무엇도 게이트키핑하게 두지 마세요. 점수를 매기기 전에 이유를 먼저 요구하세요. 점수를 먼저 내뱉는 모델은 무엇이든 그 점수를 방어하려 들기 때문입니다.

합의가 정체될 때는 에이전트 프롬프트(agent prompt)가 아니라 루브릭(rubric, 평가 기준)을 디버깅하세요. 지루하고 반복적인 작업이지만, 우리가 수행한 작업 중 가장 레버리지가 높은 작업입니다. 함정: 10개의 샘플에 대해 당신과 의견이 일치한다는 이유로 판사(judge)를 신뢰하는 것. 신호: 새로 검토된 인간 샘나플(human-reviewed samples)에 대한 지속적인 합의율(agreement rate).

4. 게이트를 승인 프로세스(promotion)에 연결한 다음, 드리프트(drift)를 관찰하세요. 평가(Eval) 점수는 환경 간의 승인 기준이 됩니다. 임계값(threshold) 미만으로 지표를 떨어뜨리는 변경 사항은 배포(ship)되지 않습니다. 그다음에는 이 자산(estate)을 살아있는 유물(living artifact)로 취급하세요. 100% 통과하는 테스트 스위트(suite)는 건강한 스위트가 아니라, 죽은 센서입니다. 그리고 모든 모델 변경은 자산의 상태를 다시 노화시킵니다. Anthropic 엔지니어들은 동일한 도구 사용(tool-use) 프롬프트가 한 모델 버전에서는 트리거(trigger)가 급격히 적게 발생하고, 다음 버전에서는 과도하게 발생하는 현상을 설명합니다. 즉, 업그레이드 과정에서 해당 모델을 평가한 평가(eval)가 잘못된 신호를 준 것입니다. 함정: 포화된(saturated) 스위트를 성공으로 축하하는 것. 신호: 게이트가 대부분의 주에 실제 문제를 차단하고 있으며, 매달 새로운 케이스가 추가되는 것.

비용과 킬 메트릭 (Kill Metric)

정직한 비용은 당신의 워크플로우에 대해 "완료(done)"가 무엇을 의미하는지 정의하는 데 드는 시니어 인력의 시간입니다. 아무도 신뢰할 수 있는 달러 수치를 발표하지 않았으며, 저 또한 임의로 만들어내지 않겠습니다. 우선적으로 투자할 것: PR 이력과 인시던트(incidents)를 기반으로 구축된, 가장 가치 있는 단일 에이전트 워크플로우를 위한 회귀 테스트 스위트(regression suite)와 하나의 교정된 판사(calibrated judge). 나중에 투자할 것: 전체 플릿(fleet) 범위의 커버리지와 샘플링된 프로덕션 트래픽에 대한 드리프트 모니터링(drift monitoring). 분기 내의 킬 메트릭(kill metric): 게이트는 프로덕션 이전에 실제 회귀(regressions)를 포착해야 하며, 판사는 새로운 인간 샘플에 대해 합의율을 유지해야 합니다. 90일 동안 아무것도 걸러내지 못한 게이트는 장식품에 불과합니다. 루브릭을 수정하거나, 게이트가 있는 척하는 것을 그만두세요.

이러한 지출은 복리로 쌓입니다. 이는 테스트 효과성(test effectiveness)이 테스트 커버리지(test coverage)보다 중요한 지표라는 점과 같은 맥락입니다. 실제 실패 사례에서 추출한 모든 평가(eval)는 향후 모든 실행, 모델 교체(model swap), 그리고 벤더 협상 과정에서 지속적인 가치를 제공합니다. 또한 신뢰의 격차는 측정 가능합니다. DORA의 2025년 보고서에 따르면 개발자의 단 24%만이 AI 출력물을 "매우" 신뢰한다고 답했으며, LinearB의 2026년 벤치마크에 따르면 AI가 생성한 PR(Pull Request)의 병합률은 수동 PR의 절반에도 미치지 못했습니다. 이때 리더들은 장벽으로 정답성(correctness)이 아닌 컨텍스트(context)와 신뢰(trust)를 꼽았습니다. 평가(Evals)는 신뢰를 수치화하는 방법입니다.

시작할 것, 멈출 것, 계속할 것 (Start, Stop, Continue)

경영진 (Executives)
시작할 것: CI에 담당자가 있었던 것과 마찬가지로, 평가 자산(eval estate)을 명확한 책임자가 있는 수락 인프라(acceptance infrastructure)로 보고 자금을 지원하세요. 자율성(autonomy)을 높이기 전에는 반드시 판정자-인간 간의 일치율(judge-human agreement rates)을 요구하세요.
멈출 것: "파이프라인이 통과(green)되었다"는 것을 에이전트의 작업이 정확하다는 증거로 받아들이는 것. 에이전트가 직접 작성한 테스트만을 게이트로 삼아 에이전트 배포를 승인하는 것.
계속할 것: 모든 병합된 변경 사항에 대해 인간에게 책임을 묻되, 평가(evals)를 통해 인간이 얼마나 많은 검토 작업을 위임할 수 있을지 결정하세요.

엔지니어 (Engineers)
시작할 것: 지난 분기의 거절된 PR과 장애(incidents) 사례를 이번 주에 시드 평가 세트(seed eval set)로 추출하세요. 모든 판정자(judge)로부터 점수를 받기 전에 반드시 그 이유를 요구하세요.
멈출 것: 보정되지 않은 판정자(uncalibrated judge)를 기준으로 무엇인가를 게이트(gating)하는 것. 100% 통과율을 축하하는 것. 이진 체크(binary checks)로 품질을 점수화하는 것.
계속할 것: 에이전트가 배포하는 내용을 읽으세요. 평가 자산(eval estate)은 당신의 판단력을 확장하는 것이지, 대체하는 것이 아닙니다.

전략적 시사점 (Strategic Takeaway)

평가 자산(eval estate)은 복리로 쌓입니다. 발굴된 모든 실패 사례와 교정된 루브릭(rubric)은 다음 에이전트, 다음 모델, 그리고 다음 자율성 결정(autonomy decision)을 더 저렴하고 안전하게 만듭니다. 검사(Inspection)는 정체기에 도달합니다. 검사는 시니어의 주의력(attention)이 늘어나는 속도와 정확히 일치하여 확장되는데, 시니어의 주의력은 이미 당신의 병목 현상(bottleneck)입니다. Anthropic Institute의 자체 보고에 따르면, 생산 코드의 80% 이상을 AI가 작성하는 환경에서 인간의 검토가 새로운 제약 사항(constraint)이 되었다고 합니다. 또한, 그들의 필수적인 자동 검토기(automated reviewer)를 소급 적용했을 past incidents(과거 사고)의 버그 중 약 3분의 1을 잡아냈을 것이라고 합니다. 수락 계층(acceptance layer)은 제약 사항이 다음으로 이동할 지점입니다. 이를 가장 먼저 산업화(industrialize)하는 자가 스스로의 속도를 결정하게 될 것입니다.

따라서 당신의 조직에 이 테스트를 실행해 보십시오: 만약 내일 더 나은 모델이 출시된다면, 당신의 가장 중요한 에이전트 워크플로우가 개선되었는지 혹은 악화되었는지를 수치로써 오늘 업무 종료 전까지 말할 수 있습니까? 만약 대답이 '아니오'라면, 당신이 승인하는 모든 자율성(autonomy)의 증가는 눈을 가리고 거는 도박입니다. 제가 틀렸다면 말씀해 주십시오. 만약 당신의 팀이 평가 자산(eval estate) 없이도 자신 있게 에이전트 작업을 배포하고 있다면, 대신 무엇을 하고 있는지 알고 싶습니다. 그리고 이 논리가 타당하다면, 이 내용을 당신의 CI 파이프라인을 담당하는 사람에게 전달하여 평가(evals)를 누가 담당하고 있는지 물어보십시오.