\”Claude가 더 좋아졌다\”가 위험한 말인 이유

이 글은 「AI 공부 지도 20부작」의 15편(M5) 입니다.
앞 편: M4 — 좋은 Agent 는 좋은 하네스를 가진다
다음 편: M6 — Autoresearch, agent 가 스스로 리서치하는 구조

0. 시리즈 안내 — 실무 섹션 M 의 다섯 번째 편

AI 공부 지도 M 시리즈가 어느덧 다섯 번째예요. M1 에서 retrieval 4 층을 잡았고, M2 에서 long-context 와 memory 를, M3 에서 agent 와 LLM 의 경계를, M4 에서 하네스를 부품 단위로 뜯어봤습니다. 이번 편은 그 흐름의 관절 같은 자리예요. 왜냐하면 M1~M4 를 다 읽고 나면 “agent 를 개선한다”, “하네스를 튜닝한다” 같은 말이 계속 따라붙거든요. 그런데 “좋아졌다” 라는 판정 자체를 뭘로 내리는지 를 안 잡아놓으면 그 다음 편들이 전부 공중에 떠요.

이 편을 다 읽고 나면 세 가지가 되실 거예요.

• “이번 달에 agent 를 개선했다” 라는 말을 듣고 무슨 기준으로 좋아졌다고 하는지 를 되물을 수 있음
• Benchmark · task-specific · production eval 세 층이 각자 뭘 측정하고 어디서 배신하는지 감이 잡힘
• DSPy 같은 자동 최적화 프레임워크가 왜 평가 위에만 올라탈 수 있는지 이해함

M6 (autoresearch) 와 M7 (Meta-Harness) 가 전부 이 평가 구조 위에서만 돌아갑니다. 이 편이 공구 상자 역할을 해요.

1. “Claude 가 예전보다 똑똑해졌다” 라는 말이 위험한 이유

개발자 커뮤니티에서 자주 올라오는 문장이에요. “요즘 Claude 진짜 좋아진 것 같지 않아?” “GPT-5 보다 Claude 4.7 이 코딩은 더 나아졌더라.” 저도 이런 말 자주 하고 자주 들어요. 일상 대화로는 문제 없어요.

그런데 이 말을 프로덕트 개선 근거 로 쓰면 위험해집니다. “좋아졌다” 는 단어에 기준이 없거든요. 기준 없이 “좋아졌다” 를 계속 굴리면 세 가지 고장이 나요.

첫째, 무한 반복. 언제 멈출지를 모르니까 계속 튜닝해요. 어제는 프롬프트를 바꿨고, 오늘은 도구 정의를 바꾸고, 내일은 모델을 바꿔요. 그런데 어제와 오늘을 비교할 공통 자가 없으니 정말 좋아진 건지 모릅니다. 그래서 또 바꿔요. 사이클이 끊어지지 않아요.

둘째, 나빠지는 방향으로도 계속 감. 기준이 있어야 “이 방향은 틀렸다” 가 나오거든요. 없으면 체감에만 의존해요. 체감은 배반해요. 어제 잘 되던 케이스에서 오늘도 잘 되면 “좋아졌다” 고 느껴요. 그런데 실제로는 어제 잘 되던 다른 10 개 케이스에서 오늘은 다 터지고 있을 수 있어요. 체감만으론 그 뒷면이 안 보여요.

셋째, 개선 착시. 제자리인데 좋아졌다고 믿는 상태. 이게 제일 무서워요. 평가 없이 일하면 뇌가 알아서 “좋아졌다” 는 이야기를 만들어줘요. 그 이야기를 근거로 다음 결정을 내리니까 실패가 복리로 쌓여요.

그래서 self-improving loop 를 말하려면 “좋아졌다” 를 판정하는 기준이 먼저 있어야 돼요. 기준이 돌아가는 게 evaluation 이고, 그 기준 점수를 올리는 활동이 optimization 입니다. 이 두 개를 한 편에서 붙여서 다루는 이유는 기준 없이는 최적화가 불가능 해서예요. 순서가 있습니다. 과녁이 먼저, 활쏘기가 그 다음.

2. Evaluation 은 “과녁 정의” 부터 — 다트 비유로 감각 잡기

가장 쉬운 비유로 시작해 볼게요. 다트를 친다고 상상해 봐요.

벽에 판이 있어요. 판 가운데 빨간 원이 있고, 주변에 점점 넓어지는 고리들이 있죠. 한가운데가 50 점, 바깥 고리로 갈수록 점수가 낮아지고요. 당신은 다트를 던져요. 맞춘 자리의 점수를 합산해서 승부를 가립니다.

이 구조에서 제일 중요한 게 뭘까요. 던지는 사람의 실력? 다트의 무게? 아니에요. 벽에 과녁이 그려져 있어야 한다는 것 이에요.

과녁이 없는 벽에 다트를 아무리 잘 던져도 점수가 안 나와요. “가운데를 맞췄다” 를 판정할 기준이 없으니까요. 던진 사람이 “딱 저기가 과녁이었다” 라고 사후에 말해봤자 의미 없고요. 다른 사람이 “아니 내가 던진 자리가 과녁이었다” 라고 해도 반박이 안 돼요.

LLM 평가가 똑같아요. 과녁 = 평가 기준 이에요. 이게 없으면 모델이 내놓은 답이 아무리 멋져 보여도 “좋다” 를 선언할 근거가 없어요. 반대로 과녁이 정의되어 있으면, 평범해 보이는 답이라도 “이 과녁에 몇 점인지” 는 정확히 나오죠.

그래서 평가 설계의 절반은 “과녁을 어떻게 그릴 것인가” 입니다. 어떤 입력을 줄지, 어떤 출력을 기대할지, 맞췄다는 걸 어떻게 측정할지. 이걸 미리 정의해 두지 않고 “돌려보고 느낌으로 본다” 는 사람이 생각보다 많아요. 그 순간 평가는 평가가 아니라 주관 이 됩니다.

다트 비유를 한 번 더 밀어붙이면, 과녁에는 크기와 위치가 다 있어요. 가운데가 어디인지, 고리가 몇 개인지, 한 고리당 몇 점인지 정해져 있어야 점수가 나오죠. 평가도 똑같이 구체적이어야 해요. “답이 괜찮으면 된다” 는 과녁이 아니고, “답이 JSON 형식을 지키고, 세 가지 필수 필드를 포함하고, 숫자 오차가 1 % 이내면 만점” 같은 게 과녁이에요. 이 구체성이 빠지면 평가를 돌려도 숫자만 나오고 판단이 안 돼요.

3. 평가의 3 가지 층 — 지도 펼치기

이제 과녁이 한 종류가 아니라는 얘기를 할 차례입니다. 실무에서는 평가가 세 층 으로 움직여요. 각 층이 다른 질문에 답해요.

3-1. Benchmark evaluation — “일반적으로 잘하는가”

첫 번째 층은 공식 benchmark 예요. 업계가 같이 쓰는 표준 시험지. 대표적으로 MMLU (언어 지식 전반), SWE-bench (실제 GitHub 이슈 해결), GSM8K (초등 수학 문제), HumanEval (파이썬 코딩) 같은 게 있어요.

이건 대학 수능 같은 거예요. 전국의 수험생이 같은 문제를 풀고 같은 채점 기준으로 점수가 나오죠. 그래서 모델들 사이를 비교 할 때 편해요. Claude 4.7 이 GPT-5 보다 SWE-bench 점수가 몇 퍼센트 높다, 이런 얘기가 기사에 나오는 건 benchmark 덕분이에요.

장점은 비교 가능성 이에요. 약점은 우리 문제가 아니라는 것. 우리 회사의 실무는 MMLU 의 일반 상식 문제가 아니고, SWE-bench 의 오픈소스 레포 이슈가 아니거든요. 그런데 benchmark 점수가 올라갔다는 뉴스만 보고 모델을 바꾸면, 정작 우리 실무에서는 똑같거나 더 나빠지는 경우가 흔해요.

3-2. Task-specific evaluation — “내 작업에 잘하는가”

두 번째 층은 자체 과녁 이에요. 내가 하려는 작업에 맞춰서 내가 만든 평가셋. 이걸 golden set 이라고도 부르고 eval set 이라고도 해요.

예를 들어 저는 블로그 운영 agent 를 씁니다. 매주 기사를 써서 발행해요. 이 agent 가 “좋아졌다” 를 판정하려면 뭐가 필요할까요. MMLU 점수? 의미 없어요. SWE-bench 점수? 아예 관련이 없죠. 내게 필요한 건 “지난 달에 쓴 기사 30 편 중 SEO 81 점을 넘긴 비율” 같은 거예요. 그리고 거기에 우리 스타일 가이드를 어긴 비율, 잘못된 링크가 들어간 비율, 발행 후 수정을 몇 번 해야 했는지 같은 걸 더하죠.

이게 task-specific eval 이에요. benchmark 는 세상 공용 과녁이고, 이건 내 벽에 내가 그린 과녁이에요.

3-3. Production eval (A/B) — “실제 사용자에게 잘하는가”

세 번째 층은 실사용 데이터 예요. Offline 테스트가 아니라 진짜 사용자 트래픽에 모델을 태워놓고 결과를 측정해요. 제일 흔한 형태가 A/B 테스트죠. 사용자 절반은 이전 버전을, 절반은 새 버전을 쓰게 한 다음, 만족도 · 완료율 · 재사용률 같은 지표를 비교하는 거예요.

이 층이 셋 중에 가장 믿을 만해요. 왜냐하면 진짜 사용자 가 진짜 맥락 에서 진짜 결과 를 만든 숫자니까요. 대신 제일 느리고 제일 비싸요. 돌리려면 실사용 트래픽이 있어야 하고, 통계적으로 유의미해질 때까지 시간이 걸리고, 잘못된 버전을 내보내면 실제 피해가 납니다.

세 층의 성격 차이를 표로 정리해 둘게요.

층	질문	속도	비용	신뢰도
Benchmark	일반적으로 잘하는가	빠름	낮음	비교용 중간
Task-specific	내 작업에 잘하는가	중간	중간	실무적 높음
Production A/B	실사용자에게 잘하는가	느림	높음	최종 판정

실무에서 건강한 구조는 세 층을 순서대로 쓰는 거예요. Benchmark 에서 후보 모델을 거르고, task-specific 으로 내 작업에 맞는지 보고, 마지막에 production A/B 로 최종 판정. 한 층만 보고 결정하면 뒤에서 반드시 구멍이 납니다.

4. Benchmark 의 함정 — “점수는 올랐는데 실무는 왜 엉망이지”

Benchmark 를 더 파볼게요. 왜냐하면 이 층에서 속는 사람이 가장 많거든요.

함정 1: Contamination (오염). 모델이 학습할 때 benchmark 문제가 훈련 데이터에 섞여 들어갔을 수 있어요. 그러면 시험을 치는 게 아니라 외운 답을 복구하는 셈이에요. 점수가 높아도 진짜 실력인지 판별이 안 되죠. 실제로 여러 공개 benchmark 는 인터넷에 답과 함께 퍼져 있어서, 대형 모델의 훈련 코퍼스에 우연이든 고의든 섞일 가능성이 계속 지적되고 있어요.

함정 2: Over-specialization (과적합). 모델을 만든 쪽이 해당 benchmark 에서 잘 나오게 특별히 튜닝했을 수 있어요. 그 benchmark 의 형식에 딱 맞는 답을 잘 내지만, 조금 다른 형식으로 바뀌면 확 떨어지는 식이에요. SWE-bench 점수가 잘 나오는 모델이 SWE-bench 와 살짝 다른 스타일의 버그 수정 작업에서는 평범한 경우가 있어요.

함정 3: Narrow task coverage (좁은 과제 범위). Benchmark 는 결국 특정 과제 에 대한 점수예요. SWE-bench 는 “GitHub 에 올라온 오픈소스 레포의 버그 이슈를 해결하는 작업” 만 측정해요. 그런데 당신의 실무는 어쩌면 “사내 모놀리식 앱의 DB 마이그레이션 스크립트 수정” 이에요. 둘은 겉보기엔 같은 “코딩” 이지만 성격이 전혀 달라요. SWE-bench 점수가 높다고 당신의 마이그레이션 작업에 강한 모델은 아니에요.

SWE-bench 는 구체적인 예시로 한 번 더 파볼 가치가 있어요. 2024~2025 년 사이에 여러 모델이 SWE-bench 에서 점수를 크게 올렸어요. 그 뉴스를 본 팀들이 그 모델로 갈아탔는데, 실무에서는 오히려 회귀가 나온 사례가 퍼졌어요. 왜냐하면 SWE-bench 는 테스트가 이미 있는 오픈소스 프로젝트에서 “실패한 테스트를 통과시키는 작업” 에 집중되어 있거든요. 이건 매우 특수한 형태의 수정 작업이에요. 실무에서는 테스트가 없는 코드를 고치는 경우, 고치기 전에 먼저 재현을 해야 하는 경우, 사이드 이펙트가 중요한 경우가 훨씬 많아요. Benchmark 가 이 다양성을 안 커버해요.

이 층에서의 교훈 한 문장: “Benchmark 는 비교용이지 결정용이 아니다.” 뉴스에서 점수 올라갔다는 말을 들으면, 갈아타기 전에 반드시 다음 층을 돌려봐야 해요.

5. Task-specific eval — 내 작업에 맞는 과녁 만들기

두 번째 층이 실무자한테 제일 중요한 층이에요. 대부분의 개선 사이클이 여기서 돌거든요. 어떻게 만드는지 조금 구체적으로 보죠.

5-1. Golden set 구성

Golden set 은 대표 입력과 기대 출력의 짝 묶음이에요. 적게는 20~30 개, 많게는 몇 백 개. 너무 적으면 표본이 작아 흔들리고, 너무 많으면 돌릴 때마다 비용이 크죠. 시작할 때는 30~50 개로 잡아도 충분해요.

중요한 건 다양성 이에요. 쉬운 케이스만 넣으면 점수는 계속 100 점이 나오고 개선이 안 보여요. 어려운 케이스만 넣으면 점수가 거의 안 움직이고 좌절해요. 쉬움 · 중간 · 어려움 · 엣지 케이스를 고루 섞어야 점수가 의미 있게 움직여요. 실무 로그에서 실제로 일어난 실패 사례를 반드시 몇 개 넣어두는 게 좋아요.

5-2. Rubric — 채점 기준 문서화

Rubric 은 “어떻게 채점할지” 를 글로 풀어놓은 문서예요. “답이 맞으면 만점” 처럼 두루뭉술하게 쓰면 안 돼요. “답에 X 가 포함되면 1 점, X 가 포함되고 Y 순서로 서술되면 2 점, X, Y, Z 가 다 맞으면 3 점” 처럼 단계별로 써요. 사람 여럿이 같은 답을 채점해도 같은 점수가 나올 수 있게 만드는 게 목표예요.

Rubric 이 잘 설계되면 채점자가 누구든, 심지어 기계여도 비슷한 점수가 나옵니다. 이 성질이 다음 단계로 연결돼요.

5-3. LLM-as-judge — 판정을 자동화한다

사람 손으로 일일이 채점하는 건 비싸요. 50 개 golden set 에 대해 주 2 회 돌리면 매주 100 건씩 채점해야 해요. 오래 못 가요. 그래서 등장하는 게 LLM-as-judge 입니다.

구조는 간단해요. 평가용 LLM (보통 가장 강한 모델) 에게 rubric 과 입력 · 기대 답 · 실제 답을 주고 “이 답을 rubric 에 맞춰 채점하라” 고 시켜요. 그러면 숫자가 나와요. 이 숫자를 신뢰할 만한가를 사람이 샘플로 검수하는 거죠. Anthropic 이 공개한 평가 가이드에서도, 여러 연구팀에서도 LLM-as-judge 가 사람 채점과 꽤 높은 상관을 보인다고 보고되고 있어요. 100 % 는 아니지만 80~90 % 정도는 일치해요.

주의할 점이 있어요. 판정 모델과 평가 대상 모델을 똑같은 걸 쓰면 편향이 생깁니다. 자기가 만든 답을 자기가 채점하는 꼴이라, 자기 스타일의 답에 점수를 후하게 주는 경향이 있어요. 판정용은 다른 모델을 쓰거나, 최소한 다른 버전을 쓰는 게 권장돼요.

LLM-as-judge 로 파이프라인을 짜두면 코드 한 번 돌리면 점수가 자동으로 나오는 구조가 됩니다. 이 구조가 있어야 최적화가 돌아가요. 왜냐하면 최적화는 기본적으로 “점수를 계속 다시 측정하는 활동” 이거든요.

6. Optimization 이란 “과녁 맞히기 학습”

평가가 과녁이라면, 최적화는 그 과녁에 맞추려고 자세를 계속 바꾸는 활동 이에요. 평가 점수를 올리는 모든 행동이 optimization 에 들어가요.

실무에서 최적화가 이뤄지는 대표적인 레이어 몇 개를 보죠.

• 프롬프트 최적화: system prompt, few-shot 예시, 출력 포맷 지시문을 바꿔가며 점수가 높아지는 조합을 찾음
• Hyperparameter 튜닝: temperature, max tokens, top-p 같은 생성 파라미터 변경
• 도구 정의 개선: agent 가 쓰는 tool 의 이름 · 설명 · 파라미터 스펙을 다듬기 (M4 의 하네스 개선과 연결)
• Retrieval 개선: RAG 를 쓰는 경우, chunk 크기 · 임베딩 모델 · 재랭커를 바꿔보기
• 모델 교체: 모델 자체를 다른 버전으로 바꿈

이 모든 활동이 공통적으로 요구하는 게 “바꾸기 전 점수와 바꾼 후 점수를 비교할 수 있어야 한다” 예요. 평가 없이 이걸 하려면 감으로 해야 되는데, 감은 배반한다고 앞에서 얘기했죠.

그리고 이 활동들이 가능해지면 자연스럽게 나오는 질문이 있어요. “이걸 자동으로 돌릴 수 없나?” 사람이 매번 프롬프트를 바꿔 가며 점수를 잰다는 건 지치는 일이거든요. 여기서 자동 최적화 프레임워크 가 등장합니다.

7. DSPy — 프롬프트를 gradient 처럼 optimize 한다

DSPy 는 Stanford NLP 그룹에서 나온 프레임워크예요. 2023 년부터 쓰이기 시작해서 지금은 agent 설계쪽에서 꽤 표준에 가까운 자리에 있어요.

한 줄 요약: 프롬프트를 사람이 손으로 다듬는 대신, 평가 데이터만 주면 자동으로 최적화해 주는 도구.

구조를 간단히 보면 이래요.

1. 사용자는 작업을 함수처럼 선언 해요. “입력 X 가 들어오면 출력 Y 를 내라” 라는 시그니처.
2. 사용자는 평가 함수 를 줘요. “이 출력이 얼마나 좋은지” 를 숫자로 돌려주는 함수. 여기에 앞서 만든 golden set · rubric · LLM-as-judge 를 꽂아요.
3. 사용자는 학습 데이터 (input, 기대 output) 예시 몇 개를 줘요.
4. DSPy 가 여러 프롬프트 변형을 시도 하고, 평가 점수를 기준으로 더 좋은 프롬프트를 찾아줘요. BootstrapFewShot, MIPRO 같은 optimizer 가 내부에서 돌아요.

감각적으로 말하면, 신경망을 gradient descent 로 학습시키듯 프롬프트를 gradient 비슷한 신호로 학습 시키는 거예요. 차이는 연속적인 가중치 대신 이산적인 프롬프트 텍스트를 바꾼다는 것뿐이고요.

이게 왜 중요하냐면, M7 에서 다룰 Meta-Harness 의 핵심 부품 중 하나예요. Meta-Harness 는 “하네스가 자기 자신을 개선한다” 는 개념인데, 그 자기 개선의 엔진 중 하나가 DSPy 같은 자동 프롬프트 최적화예요. 그리고 DSPy 가 돌려면 평가 함수 가 반드시 있어야 해요. 평가가 없으면 DSPy 는 한 발짝도 못 움직여요. 이 의존 관계가 이 편의 존재 이유입니다.

8. Eval 이 없으면 self-improving 이 착시인 이유 — 사례 3 개

추상적으로 얘기하면 덜 와닿으니까 구체 사례 3 개로 보죠. 가상의 팀이지만 실제 현장에서 흔히 일어나는 패턴이에요.

사례 A: “프롬프트를 개선했는데 지표가 왜 떨어지죠”

블로그 생성 agent 를 운영하는 팀이에요. 기사 품질을 높이려고 system prompt 에 “사실 확인 규칙” 을 빡빡하게 추가했어요. 읽어보니 훨씬 신중한 기사를 써줘요. 팀 내부에서 “개선됐다” 로 합의됐죠.

3 주 뒤 월간 분석을 돌리니 월간 PV 가 18 % 떨어졌어요. 왜냐하면 그 신중한 말투 때문에 기사들이 전부 비슷비슷하고 밋밋해졌거든요. SEO 상으로는 좋아 보였는데, 독자들이 몇 줄 읽고 닫아버렸어요.

빠진 게 뭐였나: Task-specific eval 에 “독자 체류 시간” 이나 “문체 다양성” 이 없었어요. “사실 정확도” 만 측정하고 있었던 거예요. 한쪽 과녁만 세워놓은 거죠.

사례 B: “새 모델로 바꿨더니 매출이 떨어졌어요”

고객 응답 agent 를 운영하는 SaaS 팀. 벤치마크 점수 더 좋다고 소개된 새 모델로 갈아탔어요. 대응 속도가 빨라졌고 응답 품질도 사내 QA 팀 평가로 올라갔어요. “업그레이드 성공” 으로 릴리스.

한 달 뒤 해약률이 눈에 띄게 올랐어요. 조사해 보니 새 모델이 이전 모델보다 사용자의 실수를 더 정확하게 지적하는 경향이 있었어요. 정확한데 차갑게 들렸던 거예요. 이전 모델은 부정확했지만 따뜻했고, 사용자는 따뜻함 쪽을 더 원했던 거죠.

빠진 게 뭐였나: Production eval 이 없었어요. Offline 벤치마크와 사내 QA 팀 평가만 믿었고, 실제 사용자 행동 지표를 A/B 로 재보지 않았어요.

사례 C: “매주 하네스를 손보는데 작업 속도가 더 느려진 느낌”

Agent 하네스를 계속 튜닝하는 1 인 개발자. 매주 skill 을 추가하고, hook 을 붙이고, permission 을 조이고 있어요. 본인은 “계속 좋아지고 있다” 고 느껴요.

6 개월 뒤 돌아보니 처음보다 작업 완료 시간이 30 % 늘어났어요. 하네스가 점점 복잡해져서 agent 가 매번 체크해야 할 규칙이 너무 많아졌고, 결국 작은 작업 하나에도 호출 수가 폭증한 거예요.

빠진 게 뭐였나: 하네스 변경 전/후의 “대표 작업 샘플 10 개” golden set 이 없었어요. 감으로만 “좋아졌다” 고 느끼고 있었고, 실제 시간 · 호출 수 · 비용은 측정된 적이 없었어요.

세 사례의 공통 병인: 평가가 없거나, 평가의 축이 한 개뿐이거나, offline 에서 끝났거나. 이 셋 중 어느 하나라도 놓으면 self-improving 은 이야기로만 존재해요.

9. 평가 설계에서 흔한 실수 5 가지

이쯤에서 평가 설계가 실제로 어떻게 무너지는지 를 정리해 둘게요. 이건 저 자신도 자주 빠지는 함정이라 노트처럼 써놓고 가끔 꺼내 봐요.

(a) Test set leakage. 모델이 학습 중에 eval set 의 답을 본 적이 있는 상태예요. 그러면 점수가 올라가도 진짜 실력인지 외운 건지 알 수 없어요. 공개 benchmark 는 특히 이 위험이 크고, 자체 golden set 도 모델에게 한 번 보여주고 피드백 받는 루프 안에 쓰면 leakage 가 생겨요. 해결은 학습용과 평가용 데이터를 엄격히 분리 하는 거예요. 자체 eval set 은 오직 평가 목적으로만 쓰고, 프롬프트 튜닝에는 별도의 dev set 을 쓰세요.

(b) Single metric 고정 — Goodhart’s Law. “측정치가 목표가 되면 좋은 측정치가 아니게 된다” 는 법칙이에요. 한 지표만 보면 모델이 그 지표만 올리게 최적화돼요. 예를 들어 “답 정확도” 만 보면 답 길이가 짧아지고 친절함이 사라져요. 해결은 서로 견제하는 지표 여러 개 를 같이 보는 거예요. 정확도와 길이, 정확도와 사용자 만족도, 속도와 비용, 이렇게 상충하는 짝을 두세 개 묶어서 보세요.

(c) 자동 평가만 신뢰. LLM-as-judge 가 편해서 점수를 자동으로만 보다 보면, 판정 모델의 약점이 그대로 평가에 박혀요. 사람이 샘플 검수를 안 하면 판정 편향이 누적돼요. 해결은 주기적으로 사람 눈 샘플링 을 섞는 거예요. 매주 30 건 중 5 건은 사람이 직접 읽어보는 식.

(d) Production 평가 없음. 사례 B 가 이 경우예요. Offline 점수만 보고 릴리스하면 실사용 맥락에서 터져요. 해결은 가능한 한 실사용 A/B 또는 canary 배포 를 거치는 거예요. 트래픽이 작으면 느리게라도 흘려보세요.

(e) 비용과 지연 무시. 정확도만 보고 비용 · 응답 지연을 안 보면, 쓸모 없는 모델을 고르게 돼요. 초당 비용이 두 배이고 응답 지연이 세 배인데 정확도가 3 % 만 높은 모델은 실무에선 손해예요. 해결은 비용 · 지연을 지표 묶음에 반드시 포함 하는 거예요. 지표가 늘어나는 대신 현실적인 결정이 됩니다.

이 다섯 개는 한 번 겪어본 사람만 아는 함정이에요. 처음 평가를 짜는 사람은 대부분 (b) 와 (e) 에서 먼저 넘어집니다.

10. Claude Code 의 verification loop 가 왜 좋은 평가 설계인가

추상에서 실무로 한 번 내려오죠. Claude Code 의 verification loop 가 사실 아주 잘 만들어진 평가 구조예요. M4 에서 하네스의 8 층 중 마지막 층으로 간단히 언급했었는데, 이 편에서 다시 보면 평가 관점에서 왜 훌륭한지 이해가 돼요.

Claude Code 는 작업이 끝났다고 판단하기 전에 세 가지 관문을 통과시킵니다.

• 자동 lint · 포맷: 정해진 스타일 규칙을 코드가 지키는지 기계가 채점
• 테스트 실행: 해당 파일 관련 테스트를 돌려서 pass 여부 확인
• 사람 승인: 위 두 개가 통과해도 마지막은 사람이 본다

이 3 층이 앞서 얘기한 평가 3 층과 예쁘게 맞아요.

• Lint 는 자동 benchmark 성격. 객관적 규칙에 대한 빠른 판정.
• 테스트는 task-specific eval. 이 프로젝트에 맞춰 팀이 직접 쓴 과녁.
• 사람 승인은 production eval 의 축소판. 실사용 맥락을 알고 있는 인간이 최종 판정.

그리고 이 세 층이 “전부 통과해야 다음으로 넘어간다” 는 AND 게이트로 묶여 있어요. 한 층만 통과해도 안 되고, 한 층이라도 실패하면 멈춰요. 이게 평가 설계에서 아주 건강한 모양이에요. Goodhart 의 함정을 자연스럽게 피하고 있거든요. 어느 한 지표만 가지고 “좋아졌다” 를 선언할 수 없는 구조니까요.

덤으로 이 3 층은 비용 · 지연이 낮은 것부터 높은 것 순서 로 배치돼 있어요. Lint 가 제일 싸고 빠르니까 먼저 돌고, 테스트가 중간, 사람 승인이 제일 비싸고 느려요. 싼 관문에서 걸리면 비싼 관문까지 가지도 않으니 전체 비용이 최소화돼요. 평가 파이프라인 설계의 좋은 예시로 자주 인용되는 이유예요.

이 구조를 당신 팀의 agent 에 이식하는 건 어렵지 않아요. 자동 규칙 체크 · 자체 eval set · 사람 샘플 검수, 이 세 층을 AND 로 묶으면 됩니다.

11. Autoresearch · Meta-Harness 예고 — eval 이 있어야 다음 두 편이 성립

이 편의 마지막 자리예요. 왜 M5 를 M6 · M7 앞에 놓았는지 정리할게요.

M6 — Autoresearch. Agent 가 스스로 리서치하고 스스로 결과를 다듬는 구조예요. 그런데 “다듬는다” 는 게 돌려면 “이 결과가 괜찮은지” 를 스스로 판정할 수 있어야 해요. 판정이 곧 평가예요. 평가 함수가 없으면 autoresearch 는 그냥 무한 반복이 돼요. 검색해서 답을 내고, 검색해서 답을 내고, 멈출 자리가 없어요.

M7 — Meta-Harness. 하네스가 자기 자신을 개선하는 구조예요. 이게 돌려면 “개선됐다” 를 재는 자가 있어야 해요. 그 자가 바로 평가 지표예요. DSPy 같은 프레임워크가 그 자를 엔진 안에 품고 있는 거고요. 평가가 없으면 Meta-Harness 는 개념상으로만 존재하고 돌지를 않아요.

그래서 순서가 이래요. 평가 (M5) → autoresearch (M6) → Meta-Harness (M7). 이 순서를 뒤집어도 이야기는 흘러가지만, 실무에서 돌리려고 하면 M5 가 바닥에 없으면 나머지가 다 흔들려요.

12. 닫는 한 문장과 다음 읽기

“좋아졌다” 는 감각이 아니라 과녁에 대한 점수다. 이 한 문장이 이 편에서 제일 가져가시면 좋겠어요. Agent 든 하네스든 프롬프트든, 개선 얘기가 나올 때 제일 먼저 되물어야 할 건 “무슨 과녁에 대한 점수가 올랐다는 거냐” 예요. 이 질문이 편하게 튀어나오기 시작하면 self-improving loop 가 이야기에서 도구로 바뀝니다.

다음 편은 M6 — Autoresearch, agent 가 스스로 리서치하는 구조 예요. Agent 가 검색하고, 읽고, 요약하고, 자기 요약을 재평가해서 다음 검색을 고르는 흐름을 다룹니다. 이 흐름이 이 편에서 짠 평가 구조 위에서 어떻게 돌아가는지 보면, agent 개선 사이클의 감각이 한 단계 더 내려올 거예요.

FAQ

Q1. 평가 데이터 (golden set) 는 몇 개부터 시작하면 되나요.

30~50 개로 시작하시면 충분해요. 중요한 건 개수가 아니라 다양성이에요. 쉬움 · 중간 · 어려움 · 엣지 케이스를 고루 섞고, 실제 실무 로그에서 실패한 케이스 몇 개를 반드시 포함하세요. 시간이 지나 실패 사례가 쌓이면 100~200 개로 늘려가면 됩니다.

Q2. LLM-as-judge 로 채점한 점수, 얼마나 믿어도 되나요.

연구들에서 사람 채점과 80~90 % 정도 일치한다고 보고돼요. 실무에서 쓰긴 충분한데, 주의점이 두 가지. 하나, 판정 모델과 평가 대상 모델을 다르게 쓰세요 (자기 편향 방지). 둘, 매주 5~10 % 는 사람이 직접 검수하세요. 완전 자동만 돌리면 판정 모델의 약점이 평가에 박혀요.

Q3. Benchmark 점수를 아예 무시해도 되나요.

아니요. 무시하지는 마시고 “비교 용도” 로만 쓰세요. 후보 모델들을 한 번 거르는 데는 유용해요. 대신 그 점수 하나로 릴리스 결정을 내리지 않는 게 원칙이에요. Task-specific eval 과 production eval 까지 반드시 거쳐야 해요.

소스

• Anthropic. “Evaluating Claude” — 공식 평가 가이드 (anthropic.com)
• SWE-bench 공식 논문 및 리더보드 (swebench.com)
• MMLU (Hendrycks et al., 2021) — 대규모 다중선택 언어 이해 벤치마크
• Khattab et al., “DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines” (2023)
• Zheng et al., “Judging LLM-as-a-Judge” (2023) — LLM 채점자 편향 연구

---

회원 등록 (무료) 으로 매주 월요일 뉴스레터를 받아보세요 → /wp-login.php?action=register

---

저자: 바이브코딩 태일러 (Lovable 공식 앰배서더)
운영: 테일러의 은신처 (shuntailor.net)

소스 리스트

• 태일러 지식백과사전 — AI 공부 지도 카테고리 (본 시리즈 20편 전체)
• AI 공부 지도 엔트리맵 — 전체 구조 + 3가지 독법
• “Attention Is All You Need” (Vaswani et al., 2017)
• Anthropic · OpenAI · Google 공식 docs
• mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown 영상 — 쉬운 설명 레퍼런스

---

著者: 바이브코딩 태일러 (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ “AI 공부 지도” 22편은 위키 자료와 공식 논문·공식 문서를 근거로 정리한 체계적 학습 커리큘럼입니다.