출처 https://youtu.be/v9FTCvkV_a0 · 채널 Claude (Code w/ Claude 행사) · 길이 39:16 포맷 anthropic 워크숍 발표자가 청중 앞에서 슬라이드 생성 에이전트를 실시간으로 개선하며 evals 설계·채점·재보정 과정을 시연 원본 자막: 2026-07-11-evals-for-taste-slide-generation-agent (raw/transcripts) · 관련 이정표: moc-ai-agents
한눈에 보는 요약
- Evals는 “느낌”과 “확신” 사이의 다리다. 시스템적 테스트로 AI 시스템 성능을 특정 도메인·유스케이스에서 측정하고, 실패 시 무엇이 왜 잘못됐는지 실행 가능한 정보를 준다. Evals 없이는 프로덕션에서만 문제를 발견하고, 하나 고치면 다른 게 깨지고, 진짜 피드백과 노이즈를 구분하지 못하며, 개선/퇴행을 검증할 방법이 없다.
- SweetBench·Terminal-bench 같은 범용 벤치마크는 당신의 유스케이스를 대변하지 않는다. 그래서 “네 자신의 evals를 만들어라”가 핵심 메시지 — 모델이 릴리스마다 스코어카드를 들고 나오는 것과 같은 이유로, 에이전트 빌더도 자기 도메인에 맞는 evals가 필요하다.
- 그레이더는 3종류, 트레이드오프가 뚜렷하다. 코드 기반(빠르고 결정적이지만 뉘앙스에 약함) · 모델 기반(유연하고 확장 가능하지만 비결정적·보정 필요) · 휴먼(가장 고품질이지만 느리고 비쌈). 슬라이드 개수처럼 딱 떨어지는 것은 코드로, “레이아웃이 겹치는가” 같은 뉘앙스는 모델 그레이더로 잡는다.
- 실제 하일클라이밍 사이클: 시스템 프롬프트를 손보고 → evals로 채점하고 → 그레이더 자체도 재보정한다. 나이브 프롬프트(teal 색 남용, 텍스트 겹침, 이모지) → 타이포그래피·밀도 규칙 + “AI 티” 금지 규칙 추가(01-polish) → 다이어그램 필수화(02-diagram) → 적대적 QA 루프 추가(03-qa-loop) → 스마트한 모델로 교체(04-model-swap, Opus)까지 각 단계마다 점수가 개선됐다.
- QA 루프(critique-then-fix)는 도메인을 가리지 않는 만능 패턴이다. “문제가 없다고 가정하지 말고, 버그 헌트하듯 찾아라”는 지시를 주고, 만든 것을 렌더링해서 스스로 검사·수정·재검사하는 사이클을 최소 1회 완료할 때까지 반복시킨다. 코딩에서 흔한 생성-비평 에이전트 패턴을 슬라이드 생성에도 그대로 적용했다.
- judge 그레이더 설계에서 두 가지 함정이 드러났다. ① 숫자 점수(0~5)만 주면 모델이 “좋다/나쁘다”의 기준점(anchor)이 없어 무의미한 숫자를 뱉는다 — 극단 예시로 캘리브레이션해야 한다. ② 점수를 먼저 말하게 하고 이유를 물으면, LLM이 자기회귀적으로 그 점수를 정당화하는 이유만 만들어낸다(사후 합리화) — 대신 장단점을 먼저 나열시키고 그걸 바탕으로 최종 점수를 매기게 해야 한다.
- 더 똑똑한 모델(Opus)로 바꾸면 수작업 프롬프트 엔지니어링의 상당 부분을 대체한다. 같은 초기 프롬프트로도 이모지 0개, 작은 폰트 슬라이드 감소 등 “슬라이드 덱이 이래야 한다”는 내재적 지식을 보여줬다. 다만 이미지가 전혀 없는데도 이미지 judge가 5점을 주는 등, 그레이더 자체의 신뢰도 문제는 모델을 바꿔도 남는다.
장면별 상세 설명
[00:01] 1. Evals란 무엇인가
발표자는 evals를 “AI 시스템이 특정 도메인·유스케이스에서 얼마나 잘 작동하는지 측정하는 시스템적 테스트”로 정의한다. Evals는 시나리오를 정의하는 태스크와, 그 기대치를 채점 로직으로 인코딩한 것으로 구성된다. 핵심은 “그럭저럭 되는 것 같다(it seems to work)“는 감(vibe)과 “확실히 잘 되고 있다(we know it works)“는 확신 사이의 다리 역할이라는 것이다. Vibes도 대략적인 상황 감지에는 쓸모 있지만, 실행 가능한(actionable) 정보를 주지는 못한다.
[00:03] 2. 유명한 evals와 실제 벤치마크 표
공개 벤치마크를 세 갈래로 정리한다 — Agentic Coding(SWE-Bench, Terminal-bench), Tool Use & Agents(tau-Bench, MCP Atlas, OSWorld, BrowseComp), Reasoning & Knowledge(GPQA Diamond, MMMLU, MMMU, ARC-AGI-2). 화면 우측에는 Opus 4.7 / Opus 4.6 / GPT-5.4 / Gemini 3.1 Pro / Mythos Preview를 나란히 비교한 실제 스코어카드가 떠 있다. 모델이 릴리스마다 이런 벤치마크 성적표를 함께 내놓는 것처럼, 발표자는 “이 범용 벤치마크들은 여러분의 특정 유스케이스를 대변하지 않는다”는 점을 강조한다 — 그래서 자체 evals가 필요하다.
[00:07] 3. Evals가 없을 때 vs 있을 때
Evals 없이 팀은 “날아다니는 눈먼 상태(flying blind)“로 반응 루프에 갇힌다 — 프로덕션에서만 문제를 발견하고, 하나를 고치면 다른 문제를 만들고, 진짜 피드백과 노이즈를 구분 못 하고, 개선/퇴행을 검증할 방법이 없다. Evals가 있으면 팀은 ① 성공이 무엇인지 명확히 정의하고, ② 최적 에이전트 설정을 반복 개선하고, ③ 성능·지연시간·비용·에러율에 대한 인사이트를 얻으며 새 모델을 빠르게 도입하고, ④ 런칭 전에 문제를 가시화해 일관된 품질 기준을 지킬 수 있다.
[00:09] 4. 프롬프트 엔지니어링 라이프사이클의 필수 요소
원래 프롬프트 엔지니어링 흐름은 “eval 테스트 케이스 개발 → 예비 에이전트 설정 작성 → 태스크에 대해 에이전트 실행 → (evals로 채점하며) 설정 개선 → 다듬어진 설정 출시”라는 단순한 루프였다. 시간이 지나며 툴 콜·스킬·컨텍스트 엔지니어링 기법이 더해지면서 에이전트 설정(agent config = 아키텍처, 시스템 프롬프트, 툴 설계, 컨텍스트 엔지니어링 기법 등)을 조정할 레버가 훨씬 많아졌고, 그럴수록 무엇을 바꿨을 때 실제로 좋아지는지 판단할 evals의 중요성이 커진다.
[00:12] 5. 세 가지 그레이더 — 코드/모델/휴먼
코드 기반 그레이더는 문자열 매치·정규식·퍼지 매치, 유닛 테스트(fail-to-pass, p-2-p), 정적 분석(린트·타입), 최종 상태·툴 콜 체크 등으로 구성된다. 빠르고 저렴하며 결정적이지만, 뉘앙스가 필요한 판단에는 취약하다. 모델 기반 그레이더는 루브릭 기반 채점, 페어와이즈 비교(“두 결과 중 어느 게 더 나은가, 왜?”), 멀티 저지 컨센서스(예: 3명의 심사위원 중 다수결)로 구성된다. 유연하고 확장 가능하며 뉘앙스를 포착하지만, 비결정적이고 비용이 들며 보정이 필요하다. 휴먼 그레이더는 SME(주제 전문가) 리뷰, 크라우드소싱 판단, 스팟체크 샘플링, A/B 테스트로, 가장 유연하고 고품질이지만 느리고 비싸서 실제로는 가장 적게 쓰이는 방식이다.
발표자는 결정적 체크가 오히려 필요한 경우(예: “슬라이드 덱이 다섯 장이어야 한다”)와, 뉘앙스가 필요해 모델 그레이더로 넘어가야 하는 경우(“이 슬라이드 품질이 좋은가?”)를 구분해서 설명한다. 페어와이즈 비교는 “무엇이 더 나은지 판단할 명확한 기준이 없는 경우”에 특히 유용하다고 강조한다.
[00:13] 6. 워크숍 레포 구조
실습용 레포 eval-driven-agent-development를 훑어본다. resources/agent.yaml에 에이전트(시스템 프롬프트 + 툴)를 정의하고, pre-made/에는 각 단계별 사전 실행 결과가 들어 있으며, solutions/에는 이번 세션에서 다룰 네 단계(01-polish, 02-diagram, 03-qa-loop, 04-model-swap)의 에이전트 설정이 미리 준비돼 있다. src/에는 graders/, batch.ts, eval-runner.ts, parse-pptx.ts, render.ts 등 실제 채점 파이프라인 코드가 들어 있다.
[00:16] 7. 나이브 에이전트의 첫 결과물
“슬라이드 생성 에이전트를 만들어라, 주제를 주면 PowerPoint를 만들어라”는 최소한의 시스템 프롬프트로 만든 첫 결과물이다. 다섯 장 슬라이드가 나오긴 했지만, teal 색이 과하게 반복되고, 텍스트가 겹치거나 삐져나오고, 색상이 뒤죽박죽인 문제가 눈에 띈다. 발표자는 이 결과를 청중에게 보여주며 “여기서 어떤 grader를 정의하고 싶은가?”를 묻고, 이모지 개수·클러터(도형 수)·슬라이드 개수·이미지 포함 여부·작은 폰트·텍스트 과다 등을 그레이더 후보로 함께 도출한다.
[00:19] 8. Judge 그레이더의 실제 프롬프트 코드
src/graders/judge/judge.ts의 실제 코드를 보여준다. Claude Opus 4.7에 슬라이드 이미지를 주고 “text(제목은 간결해야 한다, 본문은 텍스트를 너무 많이 넣지 마라), image(고품질 이미지, 이미지가 없다고 감점하지 마라), layout(요소가 겹치지 않고 정렬돼야 한다), color(텍스트-배경 대비가 높아야 한다)” 네 기준에 대해 0~5점을 매기게 하는 시스템 프롬프트다. 출력은 Zod 스키마로 강제해 text/image/layout/color 점수와 comment를 구조화해서 받는다.
[00:22] 9. 01-polish — 타이포그래피·밀도 규칙 추가
시스템 프롬프트를 대폭 보강한다. 타이포그래피 위계(제목 36–44pt, 섹션 헤더 20–24pt, 본문 14–16pt, 캡션 10–12pt), 레이아웃/밀도 규칙(본문 50단어 넘으면 줄이기, 여백 0.5인치 이상, 왼쪽 정렬), 그리고 “AI 생성 티” 회피 규칙(제목 아래 얇은 강조선 금지, 장식용 이모지 금지)까지 명시한다. 이는 나이브 버전에서 관찰된 실패 모드(작은 폰트, 텍스트 과다, 이모지 남용)를 그대로 규칙화한 것이다.
[00:23] 10. 폴리시 버전의 결과물
주제를 “career”(연봉 협상)로 바꿔 실행한 결과다. 겹치는 요소 없이 훨씬 깔끔해졌고, 색상도 일관되며, “Key principle” 박스로 핵심 조언을 강조하는 구조가 생겼다. 다만 발표자는 재실행 결과에서 이모지 카운트가 갑자기 20으로 튀는 등 이상한 수치를 발견하고, “이건 그레이더 자체가 뭔가 잘못 측정하고 있다는 신호”라며 evals는 한 번 만들고 끝이 아니라 계속 재보정해야 하는 living artifact임을 강조한다. 텍스트가 실제로는 괜찮아 보이는데 여전히 “text-heavy”로 플래그되는 경우도 그레이더 정의 자체를 의심해야 하는 신호로 짚는다.
[00:26] 11. 02-diagram — 다이어그램 필수화
이번엔 “매 슬라이드는 실제 이미지로 삽입된 생성 다이어그램이나 차트를 최소 1개 포함해야 한다”는 요구사항을 추가한다. 화면에는 이전 단계의 타이포그래피·밀도·anti-AI-tells 규칙이 그대로 유지된 채 이 항목만 추가된 것이 보인다 — 반복적으로 규칙을 누적시켜가는 방식이다.
[00:26] 12. 다이어그램이 들어간 실제 결과
Step 1 슬라이드에 25th/50th/75th 퍼센타일과 목표 연봉을 비교하는 막대그래프가 실제로 삽입됐다. 발표자는 이게 “그냥 텍스트로 이야기하는 것보다 훨씬 설득력 있어 보인다”고 평가하면서도, 일부 슬라이드의 이미지는 “약간 늘어나 보인다”며 완벽하지 않음을 인정한다. score.json을 확인하니 이모지·클러터는 깨끗한데 텍스트 과다·작은 폰트는 여전히 남아 있고, 이미지 judge 점수(3.8/5)는 “그 숫자가 정확히 무엇을 의미하는지 알기 어렵다”는 한계를 그대로 노출한다.
[00:29] 13. 03-qa-loop — 적대적 QA 루프 지시
코딩에서 흔히 쓰는 생성-비평 에이전트 패턴을 그대로 가져온다. “문제가 없다고 가정하지 마라. 네 임무는 문제를 찾는 것이다. QA를 확인 절차가 아니라 버그 헌트처럼 접근하라”는 문구로 에이전트를 의도적으로 적대적(adversarial)으로 행동하게 만든다. 이어서 “슬라이드 덱을 이미지로 변환 → 모든 슬라이드 이미지를 직접 검사 → 문제를 고치고 재렌더링 → 재검사 → 최소 한 번의 수정-검증 사이클을 완료할 때까지 멈추지 마라”는 구체적 절차를 명시한다.
[00:31] 14. QA 루프 이후 점수 상승
QA 루프를 거친 뒤 텍스트/이미지/레이아웃/색상 judge 점수가 모두 4.2~4.4 사이로 올라갔다(“이제 우리는 좋은 궤도에 있다”). 발표자는 여기서부터 계속 작은 개선을 반복할 수도 있지만, 더 흥미롭고 미묘한 다음 선택지는 “더 똑똑한 모델로 갈아타는 것”이라고 소개하며 다음 단계로 넘어간다.
[00:32] 15. 04-model-swap — Opus로 교체한 결과물
정교하게 다듬은 프롬프트를 버리고, 최초의 단순한 프롬프트(“슬라이드 생성 에이전트다, 주제를 주면 PowerPoint를 만들어라”)로 되돌린 뒤 모델만 Sonnet 4.7에서 Opus 4.7로 바꿨다. 결과는 “Yes / Maybe / No”라는 3열 카드에 각각 다른 색(초록/노랑/빨강)을 입히고, 하단에 “Key Takeaway” 박스까지 갖춘, 훨씬 구조화되고 완성도 높은 슬라이드였다. Opus는 별도 지시 없이도 이모지를 전혀 쓰지 않았고 작은 폰트 슬라이드도 줄었다 — “슬라이드 덱이 어때야 하는지”에 대한 내재적 지식이 있다는 뜻이라고 해석한다.
[00:35] 16. 그레이더 신뢰성의 함정 — 앵커링과 사후 합리화
Opus 버전은 text 4.4, image 5, layout 4.2, color 4.8, title-body coherence 4.4로 전반적으로 높은 점수를 받았다. 그런데 이미지가 하나도 없는 슬라이드에 image judge가 5점을 준 사례가 발견되며, “이건 우리가 제대로 된 것을 측정하고 있지 않다는 신호”라고 짚는다. 코드 그레이더(emoji-count.ts, cluttered-slides.ts, slide-count.ts 등)는 단순하지만, judge 그레이더의 텍스트 프롬프트(“0~5점을 매겨라”)에는 모델이 참조할 “닻(anchor)“이 없다는 근본 문제가 있다 — 0점이 어떤 모습인지, 5점이 어떤 모습인지 예시가 없으면 모델은 임의의 숫자를 뱉는다.
더 미묘한 함정은 점수와 근거를 묻는 순서다. “점수를 먼저 말하고, 그다음 이유를 설명해라”라고 하면 LLM은 자기회귀적으로 이미 뱉은 점수를 정당화하는 이유만 만들어낸다 — 발표자가 직접 겪은 실수다(“4점을 줬으니 4점인 이유를 대라”는 식으로, 실제로 1점이어야 할 결과에도 그럴듯한 근거를 지어낸다). 해결책은 순서를 뒤집는 것 — 먼저 장점과 단점, “왜 높아야 하는지”와 “왜 낮아야 하는지”를 모두 나열시킨 다음, 그 근거들을 종합해 최종 점수를 매기게 한다. 같은 원리가 QA 루프에도 적용된다 — 법률 문서 요약처럼 환각이 위험한 도메인에서는, 문제를 찾는 에이전트와 그걸 반박하는 에이전트를 따로 두거나 여러 그레이더의 합의를 보는 식으로 신뢰도를 높일 수 있다.
부록 — 실전 체크리스트
- 범용 벤치마크로 만족하지 말 것. SWE-bench, Terminal-bench 같은 공개 벤치마크는 일반적 능력만 보여준다. 자기 에이전트의 실제 유스케이스에 맞는 evals를 직접 만들어라.
- 그레이더를 딱 떨어지는 것과 뉘앙스가 필요한 것으로 나눠라. 슬라이드 개수·이모지 개수처럼 셀 수 있는 건 코드 그레이더로, “레이아웃이 자연스러운가” 같은 건 모델 그레이더(judge)로 잡는다.
- 정보를 주지 않는 그레이더는 evals에서 빼라. 각 그레이더마다 “이게 실패하면 무엇을 알 수 있고, 어떻게 조치할 것인가”를 답할 수 없다면 그 항목은 필요 없다.
- judge 프롬프트에는 반드시 앵커(기준점)를 줘라. “0~5점을 매겨라”만으로는 부족하다 — 0점짜리 나쁜 예시, 5점짜리 좋은 예시를 구체적으로 묘사해 모델이 참조할 기준을 만들어라.
- judge에게 점수부터 말하게 하지 마라. 장점/단점, 높아야 할 이유/낮아야 할 이유를 먼저 나열시킨 뒤 최종 점수를 매기게 해야 사후 합리화(anchoring)를 피할 수 있다.
- evals는 한 번 만들고 끝이 아니다. 점수가 이상하게 튀거나(예: 이모지 20개), 결과물은 좋아졌는데 그레이더가 여전히 나쁘다고 하면 그레이더 자체를 재보정하라. Eval이 saturate(더 이상 유용한 정보를 안 줌)됐는지도 주기적으로 점검하라.
- 적대적 QA 루프를 도메인 불문 기본으로 넣어라. “문제가 없다고 가정하지 말고 버그 헌트하듯 찾아라”는 지시 + 렌더링→검사→수정→재검사 사이클을 최소 1회 강제하는 패턴은 코딩 외 도메인(슬라이드, 문서 등)에도 그대로 통한다.
- 프롬프트를 정교화하기 전에 더 똑똑한 모델부터 시도해봐라. 수십 줄의 수작업 규칙이 하던 일을 모델 스왑 한 번이 대신할 수 있다. 다만 판단 신뢰도(그레이더 자체 정확성) 문제는 모델을 바꿔도 별개로 남는다.
- 환각 위험이 큰 도메인(법률 요약 등)에는 다중 그레이더/반박 에이전트를 고려하라. 한 에이전트가 문제를 찾고 다른 에이전트가 그걸 반박하게 하거나, 여러 그레이더의 합의를 보는 방식으로 판단의 신뢰도를 높인다.
원문 인용 모음
- [00:03] “Evals are systematic tests that measure how well an AI system performs on a specific domain or use case.” — evals의 정의.
관련 노트
- 2026-07-10-tool-skill-or-subagent — 같은 컨퍼런스, evals를 hill climbing 개념으로 명시적으로 인용한 에이전트 재설계 워크숍
- 2026-07-11-building-the-future-of-agentic-infrastructure — 같은 컨퍼런스, Managed Agents/하네스 철학 좌담
- 2026-07-10-how-we-claude-code — 같은 컨퍼런스, “검증은 테스트가 아니다” 3단계 워크플로우로 evals와 짝을 이루는 검증 사례
- moc-ai-agents — AI 에이전트 이정표(인사이트 & 의견 섹션에 이 노트 수록)
- [00:07] “Without evals… you’re always in a reactive loop.” — evals 없이 일할 때의 상태.
- [00:09] “It really depends — it really depends from use case to use case what makes a good grader.” — 그레이더 설계에 만능 공식은 없다는 경고.
- [00:18] “If you have a grader that you get no useful information out of, then you should not have that part of your eval.” — 무의미한 그레이더는 빼라는 원칙.
- [00:20] “It’s not because you have set up your evals once that they are now like the ground truth… evals over time they can evolve. They need to be a living artifact.” — evals 재보정의 필요성.
- [00:28] “Approach QA as a bug hunt, not a confirmation step.” — 적대적 QA 루프의 핵심 지시문.
- [00:33] “Opus just does not use any emojis… it kind of has this innate knowledge of, ‘Okay, it should be readable. This is how a slide deck should function.’” — 더 스마트한 모델이 프롬프트 규칙을 대체하는 사례.
- [00:35] “If it is anchored on like this four, it will do anything it can to argue why it should be a four… even if it’s like extremely bad.” — judge 그레이더의 사후 합리화(anchoring) 문제.
- [00:35] “First you say like, ‘Give me a bunch of reasons… reasons why it should be high, reasons why it should be bad.’ And then based on all of those reasons together, then you need to make your final decision.” — anchoring을 피하는 순서 뒤집기 기법.