1 · 교육 세션 · 측정이 먼저다1 · Learning session · measure first

지금까지 우리는 좋은 프롬프트를 쓰고, 좋은 에이전트를 설계하고, 팀을 조율하는 법을 배웠어요. 그런데 솔직히 물어볼게요. 지금 여러분이 쓰는 Claude가 정말 잘 되고 있는지, 어떻게 알고 있나요? 느낌으로? 감으로? 오늘은 룰 넘버 에이틴, "측정하지 않으면 개선할 수 없다"입니다. 평가와 벤치마킹이에요.Up to now we've learned to write good prompts, design good agents, and coordinate teams. But let me ask honestly: how do you know the Claude you're using is actually working well? By feel? By intuition? Today is Rule Number Eighteen: "what you don't measure, you can't improve." Evals and benchmarking.

2 · 1막 — '잘 되는 것 같아요'의 함정2 · Act 1 — the trap of "it seems fine"

한 가지 장면을 볼게요. 프롬프트를 하나 만들고 몇 번 돌려봤습니다. 응답이 그럴듯해 보여요. 그래서 "잘 되는 것 같다"고 판단합니다. 그런데 엣지 케이스는 아직 안 봤어요. 내일 프롬프트를 조금 수정했을 때, 어제보다 나빠지는지도 모릅니다. 팀원이 "이 버전이 더 낫다"고 할 때, 그게 숫자로 뒷받침되는 말인지도 불분명해요.Let's look at a scene. You build a prompt, run it a few times. The responses look plausible. So you decide: 'it seems to work.' But you haven't checked edge cases. When you tweak the prompt tomorrow, you won't know if it got worse. When a teammate says 'this version is better,' it's unclear whether numbers back that up.

이게 '잘 되는 것 같아요'의 함정입니다. 그럴듯한 느낌은 회귀도, 개선도 잡아내지 못해요. 측정이 없으면 어디서 무엇이 망가졌는지 볼 수 없고, 무엇을 고쳐야 하는지도 모릅니다. 그래서 오늘의 질문은 이거예요. Claude 출력을 어떻게 숫자로 측정하는가.That's the trap of 'it seems fine.' A plausible feeling catches neither regressions nor improvements. Without measurement you can't see where something broke, and you don't know what to fix. So today's question is: how do you measure Claude output in numbers?

3 · 2막 — 평가 방법 3가지3 · Act 2 — three eval methods

그럼 평가에는 어떤 방법이 있을까요. 크게 세 가지입니다. 첫째, 인간 평가. 사람이 직접 출력을 보고 채점합니다. 가장 정확하지만 비용과 시간이 많이 들어요. 둘째, 자동 평가. 코드로 기준을 만들어서 반복적으로 검증합니다. 빠르고 재현 가능해요. 셋째, 엘엘엠 애즈 저지. 모델이 다른 모델의 출력을 평가합니다. 의미적인 판단이 필요할 때 유용해요.So what methods are there for evaluation? Broadly, three. First: human evaluation — a person directly reads the output and grades it. Most accurate, but costs time and money. Second: automated evaluation — you write code to define criteria and run checks repeatedly. Fast and reproducible. Third: LLM-as-Judge — a model evaluates another model's output. Useful when you need semantic judgment.

이 세 가지는 상호 배타적이 아니에요. 보통 같이 씁니다. Anthropic 공식 문서를 보면 코드 기반 자동 평가, 인간 평가, 엘엘엠 애즈 저지를 상황에 따라 조합해서 쓰라고 권장하고 있어요. 중요한 건, 어떤 방법을 쓰든 출력이 기준에 맞는지 숫자로 확인한다는 점입니다.These three aren't mutually exclusive — you typically use them together. The Anthropic official docs recommend combining code-based automated evaluation, human evaluation, and LLM-as-Judge depending on the situation. The key point: no matter which method you use, you're checking whether the output meets a criterion — in numbers.

4 · 2막 — 골든셋 설계4 · Act 2 — the golden set

측정을 하려면 기준이 필요합니다. 이 기준의 핵심이 바로 골든 셋이에요. 골든 셋은 정답이 알려진 입출력 쌍의 모음입니다. 예를 들어, "이 입력에는 이런 출력이 맞다"고 사전에 정해 둔 테스트 케이스들이죠. 골든 셋 없이 평가하면, 무엇이 좋은 출력인지 정의가 없어서 사람마다 판단이 달라집니다.To measure, you need a standard. The core of that standard is the golden set. A golden set is a collection of input-output pairs with known correct answers — test cases where you've pre-defined 'this input calls for this output.' Without a golden set, there's no definition of good output, and every person judges differently.

골든 셋이 있으면 같은 기준으로 언제든 재현 가능한 점수를 낼 수 있어요. Anthropic 공식 문서를 보면 '양을 우선하라'며 가능하면 수백 개 규모를 권장하고 있습니다. 처음엔 열 개로 시작해 점차 키워도 됩니다. 골든 셋은 처음부터 완벽하게 만들 필요가 없어요. 조금씩 키워 나가는 겁니다.With a golden set you can produce reproducible scores against the same standard any time. The Anthropic docs say 'prioritize volume' and recommend hundreds of examples if possible. Starting with ten and growing gradually is fine. The golden set doesn't need to be perfect from the start — you grow it incrementally.

5 · 2막 — 회귀 방지5 · Act 2 — preventing regression

평가가 왜 그렇게 중요한지, 회귀라는 개념으로 설명해 드릴게요. 프롬프트를 수정했을 때, 수정 전엔 잘 되던 케이스가 수정 후에 갑자기 실패하는 일이 생길 수 있어요. 이걸 회귀라고 합니다. 개선하려다 다른 걸 망가뜨리는 거죠. 평가 없이 배포하면 이런 회귀를 발견할 수가 없습니다.Let me explain why evaluation matters so much using the concept of regression. When you edit a prompt, a case that worked fine before may suddenly fail after the edit. That's a regression — trying to improve something and breaking something else. If you deploy without evaluation, you'll never catch these regressions.

방지법은 간단합니다. 수정 전과 수정 후에 모두 골든 셋으로 점수를 내고, 비교하는 거예요. 점수가 내려가면 뭔가 망가진 거니까 경고를 띄웁니다. 이렇게 하면 프롬프트를 마음껏 실험하면서도, 이전보다 나빠지는 일이 없도록 보호할 수 있어요. 이게 바로 골든 셋이 있어야 하는 실용적인 이유입니다.Prevention is straightforward: score with the golden set both before and after the edit, then compare. If the score drops, something broke — raise an alert. This way you can experiment freely with your prompt while being protected from making things worse. That's the practical reason you need a golden set.

6 · 2막 — 비용 vs 품질6 · Act 2 — cost vs quality

평가를 설계할 때 또 하나 고려해야 할 게 있어요. 바로 비용입니다. 인간 평가는 정확도가 가장 높지만, 사람이 하나씩 봐야 하니까 시간과 비용이 많이 들어요. 자동 평가는 빠르고 저렴하지만, 의미적인 판단이 어렵습니다. 엘엘엠 애즈 저지는 그 중간 어딘가에 있고, 에이피아이 비용이 발생합니다.When designing evaluation, there's another thing to consider: cost. Human evaluation has the highest accuracy but takes time and money since a person reviews each case. Automated evaluation is fast and cheap but struggles with semantic judgment. LLM-as-Judge sits somewhere in the middle and incurs API costs.

실용적인 조합이 있어요. 자동 평가로 빠르게 일차 필터링하고, 실패한 케이스나 특이한 케이스에 한해서만 인간 평가나 엘엘엠 애즈 저지를 돌리는 겁니다. 이렇게 하면 비용을 최소화하면서도 중요한 케이스는 꼼꼼하게 볼 수 있어요. 완벽한 평가를 0에서 시작할 필요는 없습니다. 작은 자동 평가부터 시작해서 점점 정교하게 만들어 가면 됩니다.There's a practical combination: automated evaluation as a fast first-pass filter, then apply human evaluation or LLM-as-Judge only to the cases that fail or look unusual. This minimizes cost while ensuring careful attention on what matters. You don't need a perfect evaluation system from day one — start with a small automated check and refine it over time.

7 · 3막 — LLM-as-Judge 작동 원리7 · Act 3 — how LLM-as-Judge works

그럼 엘엘엠 애즈 저지가 정확히 어떻게 작동하는지 들여다볼게요. 아이디어는 간단합니다. 평가 기준, 그러니까 루브릭과 실제 출력을 함께 판사 모델에게 넘깁니다. 판사 모델은 그 기준에 따라 점수를 매기고, 왜 그 점수를 줬는지 이유를 반환해요. 이게 엘엘엠 애즈 저지의 핵심 구조예요.So let's look at exactly how LLM-as-Judge works. The idea is simple: you pass the evaluation criteria — the rubric — along with the actual output to a judge model. The judge model scores it against those criteria and returns the score plus a reason for it. That's the core structure of LLM-as-Judge.

Anthropic 공식 문서를 보면 이 패턴을 클로드 에이피아이로 구현할 수 있다고 나와 있어요. 판사 모델을 불러서 루브릭과 출력을 전달하면 됩니다. 주의할 점이 하나 있어요. 판사 모델도 편향을 가질 수 있습니다. 예를 들어, 긴 답변을 짧은 답변보다 더 좋게 보는 경향이 있을 수 있어요. 그래서 루브릭을 명확하게 설계하고, 가끔 인간 평가와 교차 검증하는 게 중요합니다.The Anthropic official docs show this pattern is implementable via the Claude API — you call the judge model and pass it the rubric and the output. One thing to watch: the judge model can have biases too. For example, it may tend to favor longer answers over shorter ones. That's why it's important to design the rubric clearly and cross-validate against human evaluation occasionally.

8 · 3막 — 벤치마크 설계 원칙8 · Act 3 — benchmark design principles

좋은 벤치마크를 설계하려면 네 가지를 갖춰야 합니다. 첫째, 재현 가능성. 같은 입력에 항상 같은 채점 방식이 적용돼야 해요. 매번 결과가 달라지면 믿을 수 없는 벤치마크예요. 둘째, 대표성. 실제 서비스에서 일어나는 케이스를 충분히 반영해야 합니다. 실제로 쓰이지 않는 케이스만 잔뜩 있으면 의미가 없어요.To design a good benchmark, you need four things. One: reproducibility. The same scoring method must apply to the same input, always. If results vary every time, you can't trust the benchmark. Two: representativeness. It should adequately reflect the cases that actually happen in your service. Filling it with cases nobody uses misses the point.

셋째, 명확한 기준. '좋다/나쁘다'를 숫자로 정의해야 합니다. '그럴듯하다'는 기준이 아니에요. 예를 들어, "핵심 키워드 세 개가 모두 포함됐는가"처럼 이진법이나 숫자로 나올 수 있어야 해요. 넷째, 유지 관리 가능성. 서비스가 바뀌어도 벤치마크를 갱신할 수 있는 구조여야 합니다. 벤치마크 자체가 너무 복잡해서 관리를 못 하게 되면, 결국 쓰이지 않아요.Three: clear criteria. 'Good/bad' must be defined in numbers. 'Looks plausible' isn't a criterion. For instance, 'do all three key keywords appear?' should yield a binary or numeric answer. Four: maintainability. The structure must allow updates as the service evolves. If the benchmark becomes too complex to maintain, it simply won't be used.

9 · 3막 — CI에 평가 통합9 · Act 3 — integrating eval into CI

평가를 어디서 실행해야 할까요. 가장 효과적인 방법은 씨아이, 즉 지속적 통합 파이프라인에 넣는 겁니다. 프롬프트를 수정할 때마다 씨아이가 자동으로 골든 셋 평가를 실행해요. 점수가 기준을 통과하면 배포가 진행되고, 실패하면 배포가 차단되고 알림이 옵니다. 회귀를 배포 전에 잡는 거예요.Where should you run evaluation? The most effective approach is to put it inside CI — continuous integration. Every time you edit a prompt, CI automatically runs the golden-set eval. If the score passes the threshold, deployment proceeds; if it fails, deployment is blocked and you get notified. You catch regressions before they ship.

처음에는 씨아이까지 갈 필요는 없어요. 그냥 "수정 전, 수정 후에 각각 한 번씩 평가를 돌리는 습관"으로 시작해도 충분합니다. 중요한 건 구조가 아니라 습관이에요. 수정했으면 측정하고, 비교하고, 그 다음에 배포한다. 이 순서를 지키는 게 시작입니다.You don't need to go all the way to CI at first. Just starting with the habit of 'run the eval once before and once after each edit' is enough. What matters isn't the infrastructure — it's the habit. Edit, measure, compare, then ship. Keeping that order is the start.

10 · 3막 — 평가→개선→재평가 루프10 · Act 3 — the eval-improve-re-eval loop

자, 오늘 원리의 핵심입니다. 평가는 한 번 하고 끝나는 게 아니에요. 루프예요. 평가를 돌려서 약점을 발견하고, 프롬프트를 수정하고, 다시 평가를 돌립니다. 이 루프가 돌면서 품질이 점점 올라가요. 이 루프의 동력은 숫자입니다. "지난번보다 몇 점이 올랐다"는 게 다음 개선의 근거가 돼요.Now the core of today's principle. Evaluation isn't a one-time thing — it's a loop. Run the eval, spot a weakness, fix the prompt, run eval again. As this loop turns, quality climbs. The fuel of this loop is numbers. 'The score went up by X compared to last time' becomes the basis for the next improvement.

반대로, 느낌이 개선의 동력이 되면 어떻게 될까요. "뭔가 더 나아진 것 같다"는 말로는 팀을 설득할 수 없고, 이전과 비교도 안 되고, 언제부터 나빠졌는지도 모릅니다. 결국 루프가 멈춰요. 측정 없이는 개선의 루프가 돌지 않는다. 이게 룰 넘버 에이틴의 진심입니다. 한 가지 더, 요즘 평가에서 중요해진 관점이에요. 에이전트는 같은 입력에도 매번 똑같이 답하지 않아요. 일 강에서 봤듯이 조금씩 다르죠. 그래서 한 번 돌려서 통과했다고 된다고 믿으면 위험합니다. 한 번의 성공은 운일 수 있거든요. 그래서 같은 걸 여러 번 돌려봐요. 여러 번 중 한 번이라도 되는지, 아니면 여러 번이 전부 다 되는지는 완전히 다른 질문이에요. 한 번에 칠십오 퍼센트로 되는 일도, 세 번 연속 다 성공할 확률은 사십이 퍼센트로 뚝 떨어집니다. 진짜 신뢰할 수 있는 건 여러 번 다 통과하는 쪽이에요. 룰 넘버 원, 결과를 믿지 마라가 여기서 숫자로 돌아오는 겁니다. 그리고 평가할 때 한 가지 — 에이전트를 평가한다는 건 모델만이 아니라, 모델과 그걸 둘러싼 하네스를 함께 평가하는 거예요.What happens if feel drives improvement instead? 'Something seems better' can't convince a team, doesn't compare to the past, and you won't know when things started getting worse. The loop stalls. Without measurement, the improvement loop doesn't turn. That's the true meaning of Rule Number Eighteen. One more perspective that's become important in evaluation lately. An agent doesn't answer the same way every time to the same input — as we saw in Session One, it varies a little. So deciding it works from a single passing run is risky; one success can be luck. So you run the same thing many times. Whether it passes at least once, versus passing every single time, are completely different questions. Something that works seventy-five percent of the time has only about a forty-two percent chance of succeeding three times in a row. What you can really trust is the side that passes every time. Rule Number One — don't trust the result — comes back here, in numbers. And one note when you evaluate: testing an agent means testing not just the model, but the model together with the harness around it.

11 · 4막 — 평가 체크리스트11 · Act 4 — the eval checklist

자, 오늘의 완성형입니다. 지금 당장 할 수 있는 다섯 가지를 드릴게요. 첫째, 무엇을 측정할지 정합니다. 출력의 어떤 속성이 '좋음'인지를 먼저 정의해야 해요. 추상적인 '품질'이 아니라, 구체적인 속성이어야 합니다. 둘째, 골든 셋을 만듭니다. 처음엔 열 개로 시작해도 괜찮아요. 나중에 쉰 개까지 키우면 됩니다. 셋째, 채점 기준을 숫자로 만듭니다. '그럴듯하다'는 기준이 아닙니다. 이진법이나 숫자 점수로 정의해야 해요.Alright, today's capstone. Five things you can do right now. One: define what to measure — first define which property of the output counts as 'good.' Not abstract 'quality' — a concrete attribute. Two: build a golden set. Starting with ten is fine; grow it to fifty later. Three: make the scoring criterion numeric. 'Looks plausible' isn't a criterion — define it as binary or a numeric score.

넷째, 수정 전·후 비교를 습관으로 만듭니다. 이게 회귀를 막는 가장 간단한 방법이에요. 다섯째, 약점을 발견하면 기록합니다. 그 기록이 다음 개선의 입력이 됩니다. 이 다섯 가지는 거대한 인프라가 필요하지 않아요. 스프레드시트 한 장과, 클로드에게 직접 채점을 시키는 것만으로 시작할 수 있습니다. 채점을 시킨다는 건 클로드에게 '이 답이 채점 기준표에 맞는지 점수 매겨줘'라고 요청하는 방식이에요. 중요한 건 구조가 아니라 측정하는 습관을 만드는 거예요.Four: make before-and-after comparison a habit — that's the simplest way to prevent regressions. Five: log weaknesses when you find them. Those logs become the input for the next improvement. These five don't require grand infrastructure — you can start with a spreadsheet and by asking Claude to grade the outputs directly. That means prompting Claude: 'score this answer against the scoring criteria.' What matters is building the habit of measuring.

12 · 4막 — 첫 골든셋 만들기12 · Act 4 — building your first golden set

골든 셋을 만드는 게 어렵게 느껴진다면, 딱 세 단계로 생각해 주세요. 첫째, 실제로 자주 쓰이는 케이스를 열 개 골라 적습니다. 실제 사용 데이터가 있으면 거기서 뽑아요. 없으면 직접 만들어도 됩니다. 둘째, 각 케이스에 대한 이상적인 출력이나, 아니면 최소한 "이 정도면 통과"라는 기준을 적어요. 셋째, Claude에 돌리고 그 기준과 비교해 봅니다. 이게 골든 셋 버전 0.1입니다.If building a golden set feels daunting, think of it as three steps. One: pick and write down ten cases you actually use frequently. Pull from real usage data if you have it; create them yourself if you don't. Two: write the ideal output for each case, or at minimum 'this would pass' criteria. Three: run Claude against them and compare. This is your golden set version 0.1.

13 · 4막 — 평가 없이 vs 평가 있는 팀13 · Act 4 — teams without vs with evals

맨 처음에 봤던 그 장면으로 돌아가 볼게요. "잘 되는 것 같아요"로만 운영하는 팀과, 골든 셋과 평가를 갖춘 팀은 어떻게 다를까요. 평가 없는 팀은 회귀를 배포 후에 발견합니다. 이미 사용자한테 나간 다음이에요. 개선 방향이 불분명하고, 팀원마다 '좋다'의 기준이 달라서 회의할 때마다 주관이 충돌해요.Let's go back to that scene from the very beginning. What's the difference between a team running on 'it seems fine' and a team with a golden set and proper evals? The team without evals discovers regressions after deploy — after it's already reached users. The improvement direction is unclear, and each team member has a different standard for 'good,' so every meeting is a clash of subjectivity.

반대로 평가를 갖춘 팀은 어떨까요. 회귀를 배포 전에 씨아이가 잡아냅니다. 개선 방향이 숫자로 보여요. "지난 버전보다 삼 점 올랐다"가 근거가 됩니다. 팀 전체가 같은 기준을 쓰니까, 품질 논쟁이 아니라 품질 개선에 집중할 수 있어요. 측정은 팀을 같은 방향으로 정렬시켜 주는 공통 언어입니다.And the team with evaluation? CI catches regressions before deploy. The improvement direction is visible in numbers — 'the score went up three points from the last version' is evidence. The whole team uses the same standard, so instead of debating quality you can focus on improving it. Measurement is the shared language that aligns a team in the same direction.

14 · 닫으며 — Rule No.1814 · Closing — Rule No.18

오늘 네 단어만 가져가신다면, 이겁니다. 골든 셋, 평가, 비교, 루프. 골든 셋을 만들고, 평가를 돌리고, 전후를 비교하고, 이 루프를 반복한다. 거대한 인프라가 아니어도 돼요. 스프레드시트 하나, 클로드 에이피아이 몇 번. 오늘 당장 열 개로 시작할 수 있습니다.If you take four words from today, they're these: golden set, eval, compare, loop. Build the golden set, run the eval, compare before and after, repeat the loop. You don't need grand infrastructure — a spreadsheet, a few Claude API calls. You can start with ten examples today.

룰 넘버 에이틴은 이 코스 전체에 흐르는 원칙과 맞닿아 있어요. 룰 넘버 투, 컨텍스트를 지켜라. 룰 넘버 포틴, 팀을 만들어라. 이것들이 아무리 잘 설계돼 있어도, 측정하지 않으면 정말 잘 되고 있는지 알 수 없습니다. 측정이 설계를 완성시켜요. 자, 측정하는 법을 배웠으니, 다음 시간에는 지금까지 배운 것들이 실제로 어떻게 쓰이는지, 케이스 스터디로 마무리합니다. 룰 넘버 나인틴입니다.Rule Number Eighteen connects to the principle running through this entire course. Rule Number Two: guard your context. Rule Number Fourteen: build a team. No matter how well these are designed, without measurement you can't know if they're truly working. Measurement completes the design. Now that you know how to measure, next time we'll tie everything you've learned together with real case studies. That's Rule Number Nineteen.