통과율만 보면 안 보이는 실패: YouTube 광고팀의 프로덕션 Eval 운영법

프롬프트를 잘 쓰면 에이전트가 말을 듣는다는 기대는 데모까지만 유효하다. 프로덕션에 올리면 같은 프롬프트, 같은 입력에도 실행마다 결과가 달라진다. 어제 통과한 케이스가 오늘 실패하고, 어제 실패한 케이스가 오늘 통과한다. 이 상태에서 “출시해도 되는가"를 판단하려면 감이 아니라 측정 장치가 필요하다.

Google YouTube 광고팀의 Preetika Bhateja와 Daniel Bump가 강연 How Evals and Prompts Shape Agent Behavior에서 이 문제를 다뤘다. 두 사람은 YouTube 광고용 이미지·비디오 모델을 만드는 팀에 속해 있다. 광고 소재를 만들고 손보는 에이전트를 실제 사용자에게 내보내야 하는 입장이라, 실패의 비용이 크고 출시 기준이 명확해야 하는 쪽이다.

여기서 말하는 eval(evaluation)은 정해진 입력 묶음에 에이전트를 돌리고, 미리 합의한 기준으로 결과를 채점해 수치로 만드는 장치다. 유닛 테스트와 비슷하지만 정답이 하나로 고정되지 않고, 채점 자체가 판단을 요구한다는 점이 다르다. 왜 이 장치가 필요한지도 강연이 짚는다. 생성 모델의 출력은 결정적이지 않아서 같은 케이스가 한 번은 성공하고 한 번은 실패한다. 실제 서비스에서 어떻게 행동할지 보장할 방법이 없으니, 무엇이 좋은 출력인지를 먼저 정의하고 그 정의로 규모 있게 재는 수밖에 없다. eval을 만드는 작업의 절반은 목표 출력을 문장으로 못 박는 일이다.

이 강연의 가치는 eval을 어떤 도구로 만드느냐가 아니라, 사람과 팀을 어떻게 붙여서 운영하느냐에 있다.

아래 영상은 원본 강연에 한국어·영어 자막을 입힌 재편집본이다. 영어 원본은 How Evals and Prompts Shape Agent Behavior에서 볼 수 있다.

도구, 자기수정 루프, 그다음 Eval

강연은 eval 이야기를 바로 시작하지 않는다. 그 앞에 두 단계를 먼저 놓는다.

첫째, LLM이 쓰기 편한 도구 세트를 좁고 단단하게 만든다. 도구 설명이 모호하거나 인자 설계가 지저분하면 에이전트는 계속 같은 자리에서 넘어진다. 이 상태로 eval을 붙이면 도구 결함을 반복해서 측정하는 셈이고, 프롬프트를 아무리 손봐도 점수가 오르지 않는다.

둘째, 결과물을 검토하는 독립 비평 에이전트를 두고 지적된 문제를 고치는 remediation 루프를 붙인다. 도구 세트로 못 메우는 빈틈을 자기수정으로 덮는 장치다.

이 기반이 잡힌 다음에 eval을 만든다. Bump는 eval의 역할을 두 가지로 정리한다. 변경이 실제로 가치를 만들었는지 증명하는 것, 그리고 ablation을 가능하게 하는 것이다. ablation은 구성 요소 하나를 빼거나 끄고 같은 테스트를 돌려 성능 차이를 재는 실험이다. 비평 에이전트를 껐을 때 점수가 얼마나 떨어지는지 모르면, 그 비평 에이전트가 값을 하는지도 알 수 없다.

Bump는 이 두 역할 때문에 강한 eval을 품질 사다리(quality ladder)를 올라가는 데 필수인 도구라고 부른다. 품질을 한 칸씩 밀어 올리는 작업을 강연 내내 이 표현으로 가리킨다. eval은 다음에 어느 칸을 잡을지 알려 주는 계측기이고, 그래서 그 아래 기반이 먼저 서 있어야 한다는 말을 반복한다.

강연이 정리한 문장은 이렇다. 에이전트의 신뢰성은 능력, 가드레일, eval 세 가지의 함수다. 셋 중 하나만 붙들고 있으면 나머지가 무너진다.

강연의 진행 순서와 launch readiness 설명을 하나의 흐름으로 재구성한 도식.

초기엔 감으로, 나중에 엄격하게

규모를 견디는 eval의 조건은 엄격함과 측정 가능성이다. 그 조건을 1일차부터 맞추려 하면 역효과가 난다는 게 이 강연에서 가장 의외인 대목이다. 초기에는 “vibing"이 오히려 도움이 된다. 여기서 vibing은 규모를 키울 수 없는 방식, 즉 출력을 직접 눈으로 읽고 직관으로 좋고 나쁨을 가르며 빠르게 고치는 단계를 말한다.

1일차부터 종합적인 eval을 만드는 선택지도 있다. 그런데 초기에는 아키텍처를 크게 뒤집거나 프롬프트를 대폭 손질하는 일이 잦고, 그때마다 eval과 루브릭을 다시 보정해야 한다. 점수가 크게 출렁이면 모델이 나아졌는지 채점 기준이 흔들렸는지 구분이 안 된다. 정교한 eval이 오히려 과감한 변경을 막는 브레이크가 된다.

강연은 이 위험을 채점 인력을 늘리는 시점과 연결한다. 외부 채점자를 너무 이른 시점에 붙이면 모델을 크게 흔드는 작업과 eval을 보정하는 작업이 동시에 굴러가고, 점수는 위아래로 크게 요동친다. 어느 쪽이 원인인지 아무도 말할 수 없는 상태가 된다.

초기 단계에서는 문제가 눈에 잘 보인다는 점도 있다. 출력 몇 개만 봐도 무엇이 어긋났는지 바로 안다. 프롬프트를 조금 만져도 성능이 크게 뛰는 구간이라 반복 주기가 짧을수록 유리하다. 이 과정에서 실패 패턴을 몸으로 익히고, 그렇게 얻은 감각이 나중에 제대로 된 eval을 설계할 때 재료가 된다. Bump의 표현을 빌리면 자기가 무엇을 만드는지 깊이 알게 되고, 그래야 아무 데나 찍는 대신 목표를 정해 품질을 올린다.

넘어가는 방식도 점진적이다. golden set을 처음부터 크게 만들 필요가 없다. golden set은 정답 또는 기대 판정이 확정된 기준 데이터셋이다. 에이전트를 훑어서 반드시 잘해야 하는 핵심 태스크 몇 개를 먼저 고르고, 진행하며 세부를 채운다.

부정 케이스를 빼먹지 않는 것도 강조된다. 해야 할 일을 했는지 확인하는 것만큼, 하지 말라고 한 일을 안 했는지 확인하는 것이 중요하다. 이 지점이 뒤에 나오는 disclaimer 사례와 바로 연결된다.

강연에는 이런 농담도 나온다. eval 코드를 쓰는 일은 작은 점이고, 루브릭을 어떻게 정할지 사람들이 다투는 일이 훨씬 큰 덩어리다. 실제로 운영해 본 팀만 할 수 있는 말이다.

Scale rater와 함께 일하는 법

초기 팀은 PM과 UX 담당자 몇 명 규모다. 이 인원으로 감을 잡는 단계가 끝나면 관련 팀이 더 들어오고, 테스트하려는 golden set과 데이터셋도 같이 커진다. 그 규모를 사람 손으로 채점하려면 전담 인력이 필요하고, 강연은 이 사람들을 scale rater라고 부른다. 제품을 만든 팀이 아니라 채점만 맡는 별도 인력이다. 팀이 머릿속에만 갖고 있던 판정 기준을 문서로 꺼내야 하는 시점이 정확히 여기다. LLM 채점자도 같은 이유로 이 단계에서 등장한다. Bhateja가 이 단계에서 효과를 본 것을 두 가지로 정리한다.

명확한 루브릭과 구체적인 예시. 초기에는 팀이 예상하지 못한 edge case가 계속 나온다. 채점자가 “이 경우는 어떻게 처리하나요"라고 물어 오고, 정작 팀 내부에서도 pass인지 fail인지 의견이 갈린다. 그래서 팀 내 human-human agreement, 즉 같은 샘플을 여러 사람이 채점했을 때 결론이 일치하는 정도가 먼저 확보되어야 한다. 이게 낮으면 어떤 채점 결과도 신뢰할 근거가 없다. 외부 채점자에게 판정을 맡기기 전에 팀이 먼저 합의를 끝내야 한다는 뜻이다.

pass/fail 말고 판단 이유까지 받기. 통과 여부만 모으면 에이전트를 어디서 어떻게 고쳐야 하는지 알 수 없다. 왜 그렇게 판정했는지 설명을 받아야 개선 지점이 드러난다. 두 모델의 출력을 나란히 놓고 비교하는 side-by-side eval에서도 마찬가지다. 어느 쪽이 이겼는지보다 왜 이겼는지가 다음 작업을 정한다.

출력이 여러 축으로 나뉘면 설명이 특히 중요해진다. 광고 소재를 채점할 때 이 팀은 정확성, 브랜드 안전성, 기대한 결과인지를 한 건에 대해 함께 물었다. 브랜드 안전성은 훌륭한데 정확성이 나쁜 결과가 나오면 단일 pass/fail로 압축할 수가 없다. 설명이 있어야 어느 축이 무너졌는지 보이고, 그 내용이 다시 에이전트 개선 입력이 된다.

LLM judge를 믿고 쓰기 위한 보정

채점 자체를 다른 LLM에게 맡기는 방식이 LLM-as-judge다. 사람보다 싸고 빠르지만, 채점자도 비결정적이라는 문제가 그대로 남는다. 이 팀도 그 길로 갔고, 신뢰를 세우기 위해 두 가지 장치를 붙였다.

하나는 일치율과 불일치율을 계속 추적하는 샘플링 파이프라인이다. 같은 샘플을 사람 전문가와 LLM 채점자에게 각각 채점시켜 결과가 얼마나 갈리는지 본다. 절대 수치보다 추세가 중요하다. 불일치율이 기대 범위 안에 머무는지, 특정 유형에서만 벌어지는지를 본다.

다른 하나는 pass/fail 결과를 넘어 채점 근거까지 spot check하는 것이다. 판정만 보면 채점자가 우연히 맞았는지 제대로 판단했는지 구분이 안 된다. 몇 건을 골라 논리를 직접 읽으면 판정이 어디서 나왔는지 확인된다.

전제 조건은 golden set 품질이다. 넓은 use case를 덮고 팀 내 human-human agreement가 높은 golden set이 없으면 일치율 자체가 의미를 갖지 못한다. 기준 자체가 흔들리는데 두 채점자가 얼마나 자주 같은 답을 내는지 세는 것은 잡음을 세는 일이다. 강연 뒤 질의응답에서 “판정을 전부 사람이 하나, LLM judge도 쓰나, 보정은 어떻게 하나"라는 질문이 나왔는데, 답은 use case마다 다르다는 것이었다. 벤치마킹 체계의 세부는 공개하지 않았다. 이식 가능한 부분은 특정 레시피가 아니라 불일치율 모니터링과 샘플링 파이프라인이라는 습관이다.

Trace에서만 드러난 disclaimer 삭제

trace는 에이전트가 결론에 도달하기까지 남긴 중간 사고와 도구 호출 기록이다. Bhateja가 이 대목에 붙인 한 줄은 이렇다. 에이전트가 무엇을 하는지 알고 싶으면 그 생각을 봐라.

이 팀은 프롬프트에 법적 이유로 disclaimer(광고에 붙는 고지·표기)를 절대 제거하면 안 된다고 명시했다. 한 번이 아니라 여러 번 반복해서 넣고, 그 방향으로 학습까지 시켰다. 한동안 잘 돌았다. 그런데 일부 edge case에서 에이전트가 프롬프트도 읽고 광고 안의 disclaimer도 발견한 상태에서 그것을 제거했다. trace에는 고지를 찾았다는 인식과 이제 지우겠다는 결정이 순서대로 남아 있었다.

강연에서 든 예는 Bhateja가 직접 만들어 에이전트에 넣어 본 공원 관련 공익 광고 이미지다. “America, we can do better.“라는 문구가 들어가고, 오른쪽 아래에 “Paid by the community of parks of keep parks clean"이라는 후원 주체 표기가 붙어 있다. 지우지 말라고 못 박은 쪽이 바로 이 표기인데, 에이전트는 그것을 지웠다.

핵심은 이 실패가 통과율 %로는 보이지 않는다는 점이다. 집계된 pass rate 안에서 이런 케이스는 “몇 퍼센트 실패” 뭉치에 섞여 사라진다. 규칙을 못 봐서 놓친 것인지 보고도 어긴 것인지도 숫자만으로는 갈리지 않는다. 두 원인의 처방은 완전히 다르다. 못 봤다면 프롬프트 위치나 컨텍스트 문제이고, 보고도 지웠다면 규칙보다 다른 목표를 우선한 판단 문제다. 이 사례에서 답을 준 쪽은 trace였다. 에이전트는 규칙을 읽었고 고지를 찾았고 그다음에 지웠다. trace를 건너뛰면 이 구분이 그대로 묻히고, 프롬프트 문구를 더 강하게 고쳐 쓰는 헛수고로 이어진다.

패턴 단위 실패 분석과 회귀 관리

전통 ML의 습관이 여기서도 유효하다. 에이전트는 학습·평가에 쓴 데이터의 범위를 크게 벗어나면 잘 일반화하지 못한다. 그래서 edge case와 넓은 능력을 따로 확인하는 데이터셋을 갖추고, test set을 별도로 유지한다. test set은 아껴서 쓰고 프로덕션 데이터로 주기적으로 갱신한다.

Bump가 특히 강조한 함정이 개별 실행에 과몰입하는 것이다. 한 번 돌려서 실패한 케이스를 보고 그 케이스에 맞춰 프롬프트를 고치고 싶어진다. 비결정적 시스템에서 그 본능은 역효과를 낸다. 그 케이스는 다음 실행에서 그냥 통과할 수도 있고, 그동안 프롬프트에는 근거가 약한 문장이 하나 쌓인다. 대신 golden set에 같은 패턴을 여러 예시로 담아 두고, 그 패턴에서 얼마나 자주 실패하는지 전체 그림을 본다. 고칠 대상은 실행 하나가 아니라 패턴이다.

사람 eval 결과가 기준에 못 미쳤을 때의 루프도 소개된다. 먼저 eval 세트 자체를 검토하고 precision, recall 같은 수치를 확인한다. 그다음 eval이나 채점 가이드를 고칠지, 에이전트 쪽을 고칠지 결정하고 다시 돌린다. eval이 제대로 정의된 뒤에는 이 루프가 품질을 끌어올리는 주 엔진이 된다.

출시 판단(launch readiness)에서 필요한 것은 회귀를 이해하는 일이다. 강연이 보여준 순서는 이렇다. 모델 쪽을 여러 번 반복해 손본 다음 A/B diff나 ablation을 돌려 어디서 성능이 떨어졌는지, 왜 떨어졌는지 짚어낸다. 그 결과를 감수할 수 있는 tradeoff와 치명적 실패로 가른다. 여기서 결정적인 실무 조언 하나는 gatekeeping 기준을 미리 정해 두라는 것이다. precision과 recall 목표치인지 다른 지표인지, 모델 eval이라면 또 다른 기준인지 사전에 합의해 둔다. 미리 정하지 않으면 출시 직전에 기준 자체를 협상하게 되고, 그때는 이미 판단이 오염된다.

마지막으로 online eval에 투자하고 데이터가 실제 분포와 맞는지 확인하라는 조언이 붙는다. 오프라인 golden set이 현장 입력을 못 따라가면 수치가 좋아도 프로덕션에서 깨진다.

스킬 단위 eval과 에이전트 단위 eval

이 블로그에는 스킬 단위 eval을 다룬 글이 이미 있다. 거기서는 SKILL.md 하나를 대상으로 테스트 케이스 10~20개와 정규식 검사를 붙이고, 스킬을 켜고 끈 두 조건을 비교해 기여도를 재는 방식을 다룬다. 하네스는 스크립트 하나로 충분하다는 결론이 나온다.

이번 강연은 한 층 위를 본다. 대상이 스킬 하나가 아니라 에이전트 전체이고, 문제가 도구가 아니라 프로세스다. 채점 인력을 어떻게 교육하고, 판정 기준을 어떻게 합의하고, golden set을 어떤 주기로 갱신하고, 어떤 조건에서 출시를 허용할지가 논의 대상이다.

두 층이 다 필요하다. 스킬 eval은 변경 단위의 검증 도구이고, 에이전트 eval은 출시 단위의 판단 근거다. 앞쪽만 있으면 부품은 잘 도는데 제품이 언제 나갈 수 있는지 모르고, 뒤쪽만 있으면 점수가 왜 움직였는지 원인을 좁힐 수 없다.

좋은 eval 시스템의 조건

강연은 마지막 정리 앞에 조건을 하나 달았다. 여기 나오는 것은 이 팀에서 통한 방식이고, 애플리케이션에 따라 결과는 달라질 수 있다. 그 전제를 깔고 옮기면 다음과 같다.

• 제품이 잘해야 하는 것을 대표한다. MVP 단계와 프로덕션 롤아웃 단계의 eval은 모양이 다르다. 어느 쪽이든 제품이 강해야 할 영역에 맞춰 있어야 한다.
• 계속 진화한다. online eval, 프로덕션 데이터로 갱신되는 test set, 샘플링 파이프라인, 그리고 use case가 늘어나면 함께 넓어지는 golden set.
• 채점자 교육에 투자한다. Bhateja는 이 주제가 이제 어느 정도 상식이 됐다고 보면서도, 반년 전만 해도 자기들 팀부터 무엇을 어떻게 채점해야 하는지, 채점자에게 무엇을 기대하는지 정리하지 못한 상태였다고 말한다.
• 루브릭과 채점 템플릿에 예시가 충분하다. 채점자가 “이건 어떻게 판정하죠"라고 되묻는 빈도와 unknown으로 처리되는 건수가 이 투자의 성적표다.
• 출시 지표를 미리 고른다. 회귀가 어디서 났는지 확인한 뒤에 기준을 만드는 순서가 아니라, 기준을 정해 두고 회귀를 판정하는 순서다.

함께 보면 좋을 자료

• Eval 없는 Agent Skill은 배포하지 마라: 스킬 하나를 대상으로 eval 하네스를 만드는 방법과 SkillsBench 수치
• LLM Observability 오픈소스 스택: LangSmith 대안 5종 비교: trace를 실제로 저장하고 들여다보려면 필요한 관측 도구들
• AI 자기개선은 모델 밖 하네스에서 먼저 온다: 모델이 아니라 하네스 구성이 에이전트 성능을 좌우한다는 관점

정리

이 강연에서 가져갈 것을 세 줄로 줄이면 이렇다.

첫째, eval을 만드는 순서가 있다. 도구를 먼저 다듬고, 자기수정 루프를 붙이고, 그다음에 측정한다. 초기에는 감으로 빠르게 돌리다가 실패 패턴이 손에 잡힌 뒤에 엄격한 eval로 넘어간다.

둘째, 채점은 기술 문제가 아니라 합의 문제다. 팀 내 판정이 갈리는 상태에서 외부 채점자나 LLM judge를 붙이면 잡음만 늘어난다. 루브릭과 예시, 판단 이유 수집, 일치율 모니터링이 그 합의를 유지하는 장치다.

셋째, 숫자는 실패를 숨긴다. disclaimer 사례가 그 증거다. 프롬프트에 명시하고 학습까지 시킨 규칙을 에이전트가 인지한 뒤 어긴 일은 통과율 표에 나타나지 않았다. 집계 지표는 어디를 볼지 정해 주는 역할까지만 하고, 무슨 일이 있었는지는 trace가 알려준다.

참고 자료

• How Evals and Prompts Shape Agent Behavior: Preetika Bhateja, Daniel Bump (Google YouTube Ads), YouTube 강연. 조회일 2026-08-04
• 한영자막 재편집본: Tech Bridge 채널, 같은 강연에 한국어·영어 자막을 입힌 버전. 조회일 2026-08-04
• Daniel Bump (X): 발표자 계정
• Daniel Bump (LinkedIn): 발표자 프로필