프롬프트의 함정, Eval로 잡았다

URL: https://www.youtube.com/watch?v=hfaUTT8bLzU 날짜: 2026-08-03 채널: Tech Bridge

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

Google YouTube Ads 팀의 다니엘 범(Daniel Bump)과 프라티카(Pratika)는 실제 프로덕션에 올라가는 에이전트를 만들며 얻은 eval(평가) 노하우를 발표한다. ==프롬프트를 잘 쓴다고 에이전트가 원하는 대로 작동하는 게 아니며, 생성형 AI 에이전트는 비결정론적(non-deterministic)이기 때문에 초반에는 직관적·비확장적으로 빠르게 시작하고, 이후 엄격하고 측정 가능한 방식으로 eval을 키워가야 신뢰할 수 있는 시스템이 된다==는 것이 이 발표의 핵심 메시지다.

• 에이전트는 한 번은 성공하고 한 번은 실패할 수 있는 비결정론적 시스템이므로, 개별 사례가 아니라 대규모 측정과 패턴 파악이 필요하다
• eval을 구축하는 순서는 "도구 최적화 → 자기수정(복구) 루프 → 검증 → 확장 가능한 eval" 순이어야 하며, 순서를 건너뛰면 밑빠진 독에 물 붓기가 된다
• 사람 평가자(rater)에게는 명확한 루브릭과 구체적 예시, 그리고 판단 이유(설명)까지 받아야 근본 원인 파악이 가능하다
• LLM-as-judge를 실전에 쓰려면 사람 전문가와의 의견 불일치율을 지속 모니터링하며 보정(calibration)해야 한다
• "지우지 말라"고 명시적으로 여러 번 안내했음에도 규칙을 어긴 에이전트 사례는, 합격/불합격 같은 범주형 지표만으로는 절대 발견할 수 없고 trace(추적 로그)를 직접 들여다봐야만 드러난다는 것을 보여준다

발표자들은 결국 "eval은 처음부터 완벽하게 만드는 것이 아니라, 작게 시작해서 팀과 데이터 세트를 점진적으로 확장하며 키워나가는 살아있는 시스템"이라는 메시지로 발표를 마무리한다.

---

1. 에이전트 신뢰성의 두 축: 기반 다지기와 eval

에이전트를 프로덕션에 안정적으로 올리려면 eval 이전에 먼저 에이전트 자체의 기초 체력을 갖춰야 한다.

1.1. 에이전트 구축이 어려운 이유

1. 에이전트 개발 자체의 난이도

   1. 시간과 신뢰성 확보의 어려움: 개인 프로젝트든 프로덕션 시스템이든 에이전트를 직접 만들어본 사람이라면 시간이 많이 걸리고 신뢰성 확보가 특히 어렵다는 것을 안다
   2. 실제 운영 환경에서의 불확실성: 원하는 대로 작동하게 하고, 다양한 기능과의 상호작용을 이해하고, 최종 사용자에게 출시했을 때 어떻게 반응할지 파악하는 일이 항상 매우 어렵다
   3. 온라인 eval의 역할: 이런 불확실성을 관리하는 데 온라인 평가(online eval)가 매우 유용한 방법이라는 것이 발표의 출발점이다

2. 에이전트 기반을 다지는 순서

   1. 도구 최적화가 최우선: 에이전트를 육성할 때는 LLM에 적합한 도구들을 집중적으로 최적화해 탄탄한 기반을 제공하는 것이 먼저다. 도구가 최적화된 후에야 더 큰 규모의 에이전트 평가에 착수해야 한다
   2. 자기수정(복구) 루프: 도구가 최적화되면 독립적인 비평 에이전트(critic agent)를 만드는 등 다음 단계로 넘어갈 수 있다. 복구 루프(recovery loop)를 사용하면 자체 수정 메커니즘을 통해 기본 도구 세트의 한계를 보완하고 격차를 메울 수 있다
   3. 검증(validation) 단계: 기본 구조가 정의된 뒤에야 검증 단계로 넘어간다. 강력한 검증은 변경 사항의 가치를 입증하고, 변경에 대한 제거 실험(ablation)을 수행할 수 있게 해주는 필수 도구다. 다만 가장 중요한 것은 처음부터 탄탄한 기초를 다지는 것 자체다

1.2. 왜 eval이 필수인가: 비결정론이라는 근본 원인

1. 에이전트 신뢰성의 정의

   1. 안전장치 + 평가 기능: 에이전트의 신뢰성은 기본적으로 안전장치(safeguard)와 평가 기능(eval)에 달려 있다
   2. 비결정론적 출력: 생성형 AI의 출력물은 완전히 결정론적이지 않다. 같은 상황에서 한 번은 성공하고 한 번은 실패할 수 있으며, 특정 영역에서 반복적으로 실패할 수도 있다

2. 대규모 측정의 필요성

   1. 목표 출력값 정의: 실제 환경에서 어떻게 작동할지 장담할 수 없기 때문에, 대규모로 측정하고 모델의 비결정성에도 불구하고 원하는 결과를 얻고 있는지 확인할 방법이 필요하다
   2. "좋음"을 평가로 정의: eval을 통해 "좋은 것"이 무엇인지 정의함으로써 모델이 실제 세계에서 어떻게 작동하는지 이해하고 개선할 수 있다. 이것이 곧 목표 출력값을 설정하는 작업이다

---

2. eval을 키워가는 전략: 처음엔 감으로, 이후엔 엄격하게

확장 가능한 eval을 만들려면 엄격하고 측정 가능해야 하지만, 역설적으로 ==초반에는 비확장적인 방식으로 "분위기를 타는 것"(vibe check)이 오히려 더 효과적==이라는 것이 이 발표의 반직관적 핵심 주장이다.

2.1. 초기 단계: 확장성보다 직관을 우선하라

1. "분위기 타기"(vibe check)의 정의와 효과

   1. 비확장적 접근의 의도적 선택: 처음부터 포괄적인 평가 체계를 구축하는 대신, 애초에 확장성이 떨어지는 방식으로 직관적인 접근을 먼저 사용하는 것이 실제로 더 효과적이었다
   2. 문제 파악의 용이성: 이 단계에서는 기능을 살펴보고 결과물을 직접 확인하는 것으로 어떤 문제가 있는지 꽤 쉽게 파악할 수 있고, 값을 변경했을 때 어떤 일이 일어나는지도 잘 파악할 수 있어 반복 속도가 빨라진다

2. 초기 단계가 허용하는 유연성

   1. 프롬프트 미세조정의 영향력: 이 단계에서는 프롬프트를 약간만 조정해도 성능이 크게 향상될 수 있다
   2. 아키텍처 근본 변경의 자유: 평가 시스템이 방해가 되지 않으므로 아키텍처를 근본적으로 바꿀 수도 있다. 마치 초기 단계 스타트업처럼 급진적인 변화를 빠르게 시도하기에 적합한 시기다

3. 너무 이른 스케일링의 위험

   1. 결과의 큰 기복(swing): 너무 일찍 스케일링된 평가 도구를 도입하면, 모델을 근본적으로 바꾸면서 평가를 반복·보정하는 과정에서 결과에 큰 기복이 생길 수 있다
   2. 작게, 일찍 시작: 첫날부터 화려하고 방대한 골든 세트(golden set)를 갖출 필요는 없다. 몇 가지 핵심 작업부터 시작해 에이전트의 주요 타겟을 정하고, 개략적인 것에서 점차 자세한 표현으로 나아가면 된다

4. 부정 사례(negative case) 테스트의 중요성

   1. "하지 말아야 할 것"도 검증: 모델이 뭔가 잘못된 일을 하지 않았는지 확인하는 것은, 잘못된 일이 발생했을 때 모델이 작업을 제대로 수행했는지 확인하는 것만큼 중요하다
   2. 평가서 작성 vs 루브릭 합의: 흥미로운 비유로, 평가서 자체를 작성하는 것은 사소한 일이지만 사람들이 평가 기준표(rubric)를 어떻게 정할지를 놓고 논쟁하는 것은 훨씬 큰 과제처럼 느껴진다는 점을 짚었다

2.2. 확장 단계: 팀과 데이터 세트를 넓혀가기

1. 화이트박스 평가에서 시작해 점진적으로 팀 확대

   1. 초기: 소수 핵심 팀만 참여: 처음에는 화이트박스 eval을 통해 모델이 잘 작동하는 부분, 에이전트가 실패하는 부분, 패턴을 파악한다. 이때는 PM과 UX 담당자 같은 핵심 팀만 참여한다
   2. 이후: 여러 부서로 확장: 결국에는 더 많은 팀을 참여시키게 되고, 더 큰 기준 데이터 세트를 갖추게 된다. 이 단계에서 척도 평가자(scale rater), LLM 평가자(LLM judge) 같은 도구가 본격 등장한다

2. 패턴 중심 사고로의 전환

   1. 개별 사례 집착의 함정: 모델의 아주 작은 예시 하나하나에 지나치게 집착하고 싶은 유혹에 빠지기 쉽다. 특정 상황에서 실패하는 것을 보고 즉시 프롬프트를 수정하고 싶어지지만, 이는 함정이다
   2. 비결정론이 만드는 함정: 에이전트가 비결정론적 시스템이기 때문에, 개별 사례가 아니라 실제로는 패턴에 의존해야 한다. 골든 세트에는 원하는 패턴을 모두 포괄할 수 있는 여러 예시가 포함되어야 하며, 특정 개별 예시가 아니라 해당 패턴이 얼마나 자주 실패하는지 전체 그림을 봐야 한다

---

3. 사람 평가자(rater)와 협업하는 법

척도 평가자와 협업하며 효과적이었던 구체적인 방법들을 다룬다.

3.1. 명확한 루브릭과 구체적 예시 제공

1. 루브릭 문서화의 중요성

   1. 초기 단계의 예외 상황 부족: 특히 초기 개발 단계에서는 평가자가 마주칠 수 있는 예외 상황과 어려운 문제들을 아직 테스트해보지 못한 경우가 많아, 평가자가 "이런 경우엔 어떻게 해야 하나요?"라고 계속 되묻게 된다
   2. 팀 내부 기준의 불일치: 팀 내에서도 "이건 통과, 이건 실패" 판단이 갈릴 때가 있으므로, 어떤 사용 사례가 좋은 평가 기준이고 어떤 것이 통과 기준인지 팀 내 합의가 확고해야 한다

2. 명확한 설명이 평가 품질을 좌우한다

   1. 최대한 구체적인 사례 제공: 평가자들에게 최대한 명확한 설명과 구체적인 사례를 제공하는 것이 초기에 매우 중요하며, 이는 평가 정확도에 큰 도움이 된다

3.2. 판단 이유(설명)까지 받아내기

1. 합격/불합격만으로는 부족한 이유

   1. 개선점 파악 불가: 단순히 합격/불합격에만 초점을 맞추면 에이전트가 어떤 부분을 개선해야 하는지, 어떤 사고 과정을 거쳐 그 결론에 도달했는지 알 수 없다
   2. 단일 평가와 병렬 평가 모두 해당: 이는 단일 측면 평가든, 두 모델을 동시에 비교하는 병렬 평가든 마찬가지로 적용된다

2. 다중 출력(multi-output) 평가와 다단계 평가 시스템

   1. 여러 축으로 평가하는 광고 사례: YouTube 광고 제작 시 평가자에게 "이 광고가 정확한가?", "올바른 조치를 취했는가?", "브랜드 이미지에 안전한가?", "예상과 비슷한가?" 등을 물었다. 사실상 다단계 평가 시스템을 운영한 것이다
   2. 명확한 합격/불합격이 없는 경우의 어려움: 예를 들어 평가자가 "브랜드 안전성은 훌륭하지만 정확성은 좋지 않다"고 답할 수 있어, 이런 케이스는 판정이 까다로울 수 있다. 이럴 때 설명(explanation)은 에이전트가 실제로 무엇을 놓치고 있는지 근본 원인을 파악하는 데 결정적으로 도움이 되며, 그 입력값으로 에이전트를 더 잘 학습시킬 수 있다

---

4. LLM-as-judge를 신뢰하고 실전에 쓰는 법

여러 부서 팀과 사람 평가자를 참여시키는 논의에 이어, LLM 평가자·LLM 심사자를 활용하는 방법을 다룬다.

4.1. 사람-LLM 간 보정(calibration)

1. 의견 불일치율 모니터링

   1. 샘플 파이프라인 구축: 전문가인 인간 평가자의 평가 결과와 LLM 평가 결과를 비교하는 샘플 파이프라인을 만들어, 추세와 합의율(agreement rate)이 예상 범위 내에 있는지 지속적으로 파악한다
   2. 계약 내용(contract) 모니터링: 경우에 따라 팀이 계약 조건 자체의 준수 여부를 모니터링하기도 한다

2. 합격/불합격을 넘어선 검증

   1. 논리 근거 확인을 위한 무작위 점검: 합격/불합격 평가를 진행하고 평가 기준을 이해하려 할 때, 판단 논리의 근거를 파악하기 위해 몇 차례 무작위 점검(spot check)을 실시했다. 그래야 어떤 기준으로 최종 판정이 내려지는지 제대로 알 수 있다
   2. 고품질 실제 데이터의 중요성 재강조: 매우 포괄적이고 광범위한 사용 사례를 다루면서도, 팀 내 사람 간 합의도가 매우 높은 최적의 골든 세트를 확보하는 것이 핵심이다

4.2. 사례 연구 — 면책 조항을 삭제한 에이전트

1. 사건의 전말

   1. 명시적 규칙 부여: 담당 팀은 에이전트에게 "법적인 이유로 면책 조항은 절대 삭제할 수 없다"는 안내 문구를 주었고, 안내 메시지에서 이 내용을 여러 차례 반복 언급했다
   2. 예외적 위반 발생: 모든 것이 순조로워 보였지만, 에이전트가 알림을 보고 광고에 면책 조항이 있음을 스스로 인식한 후에도 해당 조항을 삭제하는 예외 사례가 발생하기 시작했다

2. 범주형 지표의 한계와 trace 점검의 힘

   1. 합격률만으로는 발견 불가능: 단순히 "합격률이 x%인지 아닌지" 같은 범주형(categorical) 분석만 했다면 이 문제를 절대 발견하지 못했을 것이다
   2. trace를 직접 들여다봐야 원인이 드러남: 무슨 일이 벌어지고 있는지 알아내기 위해 에이전트의 초기 추적(trace)을 자세히 들여다봐야 했고, 실제로 검색 대상에 면책 조항이 포함되어 있었다는 사실이 trace 분석을 통해서만 드러났다

---

5. 패턴에 집중하기 & eval 구축 최종 정리

5.1. 개별 사례가 아니라 패턴에 집중하라 (재강조)

1. 함정에 빠지는 과정

   1. 개별 사례 기반 프롬프트 수정의 유혹: 에이전트가 특정 상황에서 실패했을 때 평가 결과와 trace를 바탕으로 "프롬프트를 업데이트해야겠다"고 바로 판단하기 쉽지만, 이는 함정이다
   2. 비결정론적 시스템이라는 근본 이유: 에이전트는 비결정론적 시스템이므로, 개별적·연속적 추세가 아니라 패턴에 의존해야 한다

2. 골든 세트 설계 원칙

   1. 패턴 포괄이 핵심: 골든 세트에는 원하는 패턴을 모두 포괄할 수 있는 여러 예시가 포함되어야 한다
   2. 전체 실패율 관점 유지: 특정 개별 예시가 아니라 해당 패턴에서 얼마나 자주 실패하는지 전체적인 그림을 살펴봐야 하며, 이를 위해서도 온라인 평가에 투자하고 데이터가 실제 상황을 제대로 반영하는지 확인하는 것이 중요하다

5.2. 상황별 eval 설계 및 출시 기준 결정

1. "좋은 eval"은 제품 단계에 따라 달라진다

   1. MVP vs 프로덕션의 차이: 좋은 평가 시스템이란 제품이 탁월해야 하는 부분을 잘 반영해야 하며, 이는 담당자의 현재 상황에 따라 달라진다. MVP 개발 사례는 실제 운영 환경 배포 때와 다른 양상을 보인다
   2. 지속적 발전을 위한 인프라: 상황이 다르더라도 제품이 어떤 점에서 뛰어나길 원하는지를 계속 최적화해야 한다. 이를 위해 온라인 평가, 프로덕션 데이터로 업데이트되는 테스트 세트, 샘플링 파이프라인 구축 등을 병행한다. 골든 세트는 엄선된 최고급 제품 세트이며 사용 사례가 발전함에 따라 함께 진화해야 한다

2. 평가자 교육과 출시 지표 선택

   1. 평가 방법 교육의 필요성: 평가자든 여러 부서 팀이든 평가 방법을 교육하고 기대치를 명확히 전달하는 것이 매우 중요하다. 발표자는 "불과 6개월 전만 해도 팀들이 '이걸 어떻게 해야 하지?'를 여전히 고민하고 있었다"며, 이제는 점점 주류가 되어가고 있어 논란이 줄어들 것이라고 언급했다
   2. 루브릭 템플릿의 명확한 예시: 평가자용 템플릿과 루브릭에는 명확한 예시가 포함되어야 평가자들이 "어떻게 평가해야 할지 모르겠다"며 '알 수 없음'으로 표시하는 일이 줄어든다
   3. 적절한 출시 지표 선택: 모델을 여러 번 반복 검증하고, AB 차이 분석이나 제거 실험(ablation)을 통해 "어디서 퇴행(regression)이 일어나는가? 허용 가능한 퇴행 범위는 무엇인가?"를 확인해야 한다. 시스템 구축 초기에 어떤 규칙으로 접근을 제한할지, 출시 기준이 무엇인지(특정 정밀도/재현율 수치인지, 다른 지표인지) 명확히 정하는 것이 중요하다. 모델 평가 시에는 일반적인 정밀도·재현율과는 다른 지표를 사용할 가능성이 높다는 점도 유의해야 한다

---

6. Q&A — 평가는 모두 사람이 하는가, LLM도 쓰는가?

질문: 평가 판단은 모두 사람이 직접 수행하나요, 아니면 LLM도 평가 도구로 활용하고 있나요? 그렇다면 정확한 평가를 위해 심사위원(judge)을 보정하는 과정은 어떻게 되나요?

답변 요지:

1. "모두 다"는 아니다: 사용 사례에 따라, 어떤 시스템을 구축하려는지에 따라 다르다. YouTube 광고팀은 수많은 활용 사례를 가지고 있어 획일적으로 답할 수 없다
2. 벤치마킹 세부사항은 비공개: 벤치마킹이나 시스템 전반에 대한 자세한 내용은 공유할 수 없지만, 의견 불일치율 모니터링이나 샘플링 파이프라인 모니터링 같은 방법론은 일반적으로 적용 가능하다고 답했다

---

주요 발언 모음

"그것이 무엇을 하고 있는지 알고 싶다면, 그것이 어떻게 생각하는지 살펴보라는 거죠."

"평가서를 작성하는 건 아주 사소한 일인데, 사람들이 평가 기준표를 어떻게 정해야 할지를 놓고 논쟁하는 건 마치 아주 큰 과제처럼 보인다는 거예요."

"만약 우리가 단순히 합격률이 x%인지 아닌지와 같은 범주형 분석만 했다면 그런 결과를 얻을 수 없었을 것입니다. 그래서 우리는 무슨 일이 벌어지고 있는지 알아내기 위해 흔적을 자세히 살펴봐야 했습니다."

"개별적인 연속적인 추세보다는 패턴에 집중해야 합니다."

"특정 개별 예시가 아니라 해당 패턴에서 얼마나 자주 실패하는지 전체적인 그림을 살펴보는 것이 중요합니다."

핵심 데이터 & 수치

• 영상 길이: 약 18분 48초(1128초) — Tech Bridge 채널, 2026-08-03 게시
• 발표자: Daniel Bump(Google, YouTube Ads 팀), 프라티카(공동 발표자) — 둘 다 YouTube 광고용 이미지·비디오 모델을 다루는 온라인 평가(e-val) 트랙 담당
• 면책 조항 삭제 사례: 명시적으로 "절대 삭제 금지"를 여러 번 안내했음에도 에이전트가 조항을 인식한 후 삭제하는 예외가 발생 — 범주형 pass/fail 지표로는 발견 불가, trace 분석으로만 발견
• eval 확장 경로: 화이트박스 eval(핵심 팀: PM·UX) → 여러 부서 참여 → 대규모 골든 데이터셋 → 척도 평가자·LLM 평가자 활용
• 팀 인식 변화 시점: "불과 6개월 전"에는 팀들이 평가 방법 자체를 몰라 헤맸으나, 현재는 점차 주류화되는 추세라고 언급

결론 및 시사점

1. eval보다 먼저 에이전트 기반을 다져라: 도구 최적화 → 자기수정 루프 → 검증의 순서를 지켜야 그 위에 쌓는 eval이 의미를 가진다.
2. 처음엔 일부러 비확장적으로 움직여라: 초기 단계에는 화려한 골든 세트 대신 직관적인 "분위기 타기"로 빠르게 실패 패턴을 파악하고, 프롬프트·아키텍처를 자유롭게 실험하라. 너무 이른 스케일링은 오히려 결과의 기복을 키운다.
3. 부정 사례도 반드시 테스트하라: 모델이 하지 말아야 할 것을 하지 않는지 확인하는 것은 해야 할 일을 제대로 하는지 확인하는 것만큼 중요하다.
4. 사람 평가자에게는 루브릭+예시+설명(이유)까지 받아라: 합격/불합격만으로는 개선점을 알 수 없다. 다중 출력 평가나 다단계 평가 시스템에서는 설명이 근본 원인 파악의 핵심 열쇠다.
5. LLM-as-judge는 반드시 사람과의 불일치율로 보정하라: 샘플링 파이프라인으로 합의율 추세를 지속 모니터링하고, 합격/불합격 그 자체가 아니라 판단 논리까지 무작위 점검하라.
6. 개별 사례가 아니라 패턴에 집중하라: 비결정론적 시스템에서는 하나의 실패 사례에 즉각 반응해 프롬프트를 고치는 것이 함정이 될 수 있다. 골든 세트는 패턴을 포괄하도록 설계하고, 패턴별 실패율로 판단하라.
7. trace를 직접 들여다봐라: 프롬프트에 규칙을 명시했다고 안심하지 말 것. 범주형 지표가 정상으로 보여도 실제로는 규칙 위반이 숨어 있을 수 있으며, 이는 trace 점검을 통해서만 드러난다.
8. eval은 제품 단계에 맞춰 진화시켜라: MVP와 프로덕션은 다른 eval을 요구한다. 평가자 교육, 명확한 루브릭 템플릿, 적절한 출시 지표(정밀도/재현율, AB 차이, 허용 퇴행 범위) 선택까지 전체를 하나의 살아있는 시스템으로 관리해야 한다.