Claude Code로 더 나은 AI 평가 만들기

URL: https://www.youtube.com/watch?v=bdMHQLvtVaQ 날짜: 2026-08-25 채널: Peter Yang 원문 제목: How to Build Better AI Evals with Claude Code in 5 Steps | Shreya & Hamel 영상 ID: bdMHQLvtVaQ 영상 길이: 53분 53초

---

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

==AI 평가(Eval)를 잘 만드는 핵심은 모델에게 평가 기준을 전부 발명하게 하는 것이 아니라, 사람이 실제 데이터를 읽으며 취향과 판단을 외부화하고 에이전트가 그 판단을 확장하도록 설계하는 데 있다.==

• 평가의 출발점은 모델이 만든 점수나 임의의 기준이 아니라 실제 트레이스(Trace)와 출력에 대한 오류 분석(Error Analysis)이다.
• 작업 설명만 보고 정하는 하향식(Top-down) 기준과 여러 샘플을 관찰하며 발견하는 상향식(Bottom-up) 기준을 분리해야 한다.
• 에이전트는 샘플을 클러스터링하고, 사람이 남긴 자유형 피드백을 루브릭(Rubric)으로 정리하고, 알려진 실패 모드를 전체 데이터에 확장하는 데 강하다.
• 자동 평가 도구는 명백한 오류를 넓게 찾는 좋은 기준선이지만 제품의 취향·맥락·판단이 필요한 오류까지 대신 발견하지는 못한다.

좋은 평가 시스템은 루브릭 하나로 끝나지 않는다. 사람이 대표 샘플을 읽고 어떤 결과가 좋은지 판단해야 하며, 그 판단을 데이터셋과 LLM Judge로 측정 가능한 형태로 바꾸고, CI/CD와 모니터링에 연결해야 한다. 평가 방식은 사용자 인터페이스(UI) 설계에도 영향을 준다. 생성물을 통째로 덮어쓰는 대신 왜 문제가 되는지 보여주고 사람이 수락·거부하도록 해야 취향과 통제권을 보존할 수 있다.

1. AI 평가의 기본 원리와 달라진 점

실제 데이터를 먼저 읽고 오류를 구조적으로 분해한 뒤, 사람의 취향을 평가 기준으로 외부화해야 한다.

1.1. 변하지 않은 평가의 출발점

1. 데이터 우선 접근

   1. 실제 고객 트레이스와 대화를 먼저 살펴 어디에서 문제가 발생하는지 파악한다.
   2. 데이터에 없는 임의의 점수나 무작위 스코어를 만들어내기보다, 관찰된 오류에 근거해 평가한다.
   3. 오류 분석을 체계화하면 사람이 머릿속으로만 갖고 있던 취향과 판단을 재현 가능한 기준으로 바꿀 수 있다.

2. 사람의 판단을 외부화하는 순서

   1. 작업을 시작하기 전에 좋은 결과와 나쁜 결과를 가르는 감각을 언어로 정리한다.
   2. 그 판단을 평가 기준과 LLM Judge에 넣어 여러 출력에 반복 적용한다.
   3. 평가의 궁극적 목적은 점수를 만드는 것이 아니라 제품이 어떤 행동을 보여야 하는지 아는 데 있다.

1.2. 에이전트가 만든 새로운 레버리지

1. 데이터 검토를 돕는 백그라운드 에이전트

   1. 에이전트가 과거보다 강력해지면서 사람이 데이터를 읽는 동안 샘플을 구조화하고 패턴을 찾을 수 있게 됐다.
   2. 사람은 실제 출력에 집중하고, 에이전트는 뒤에서 분류·주석·루브릭 초안 작성을 병렬로 진행한다.
   3. 초기 데이터 검토 단계에서 에이전트의 도움을 받으면 사람이 같은 시간에 더 많은 샘플과 실패 모드를 확인할 수 있다.

2. LLM Judge의 적용 범위 확대

   1. LLM Judge는 트레이스를 보고 특정 실패 모드에 대해 판단하는 LLM이다.
   2. 출력이 너무 길거나 짧은지, 특정 구조를 따르는지처럼 기준이 잘 정의된 문제에서는 정확도가 크게 좋아졌다.
   3. 판단 기준이 명확할수록 LLM Judge를 신뢰하기 쉽지만, 제품의 취향과 맥락을 모델이 스스로 발명해 내리게 해서는 안 된다.

2. 팟캐스트 후처리 스킬에서 드러난 평가의 문제

팟캐스트의 원본 트랜스크립트에서 핵심 요약과 뉴스레터 초안을 만드는 작업은 평가 기준이 많고, 에피소드마다 좋은 문장의 형태가 달라 한 번에 완벽하게 만들기 어렵다.

2.1. Peter Yang의 실제 스킬과 기존 평가

1. 스킬의 출력 흐름

   1. 인터뷰 영상과 원본 트랜스크립트를 입력으로 받는다.
   2. 영상을 보지 않는 사람도 이해할 수 있도록 상위 10개 핵심 요약(Top 10 Takeaways)을 만든다.
   3. 핵심 요약을 바탕으로 뉴스레터 포스트의 초안까지 작성한다.
   4. 초안을 그대로 게시하지 않고 직접 읽으며 여러 차례 피드백을 주고 다시 작성한다.

2. 이미 만든 하향식·판단형 기준

   1. 각 요약이 240~330자 사이인지 확인하는 객관적 길이 기준이 있다.
   2. 에피소드를 보지 않아도 각 요약이 독립적으로 이해되는지 확인한다.
   3. 사람이 실제로 활용할 수 있는 평이하고 유용한 조언을 주는지 판단한다.
   4. 문자 수처럼 기계적으로 검사할 수 있는 기준과, 이해 가능성·유용성처럼 판단이 필요한 기준이 섞여 있다.

2.2. 반복 수정이 평가 기준을 만든다

1. 사람과 모델의 왕복 작업

   1. 실제 인터뷰에서 만든 초안을 읽고 “이 부분을 바꿔라”라는 구체적 피드백을 여러 번 준다.
   2. Anthropic의 Tharic과 진행한 인터뷰 사례에서도 한 번 실행한 결과가 끝이 아니었다.
   3. 수정 후에도 추가 피드백과 재실행이 이어지며, 에피소드마다 요구되는 표현과 구조가 달라진다.
   4. 아무리 기준과 평가를 추가해도 모든 인터뷰를 첫 시도에 완벽하게 처리할 수 없다.

2. 평가를 작업 중인 시스템으로 보기

   1. 더 많은 샘플을 볼수록 새로운 실패 모드가 드러난다.
   2. 반복 작업에서 나온 피드백을 평가에 외부화하면 같은 실수를 다음 작업에서 줄일 수 있다.
   3. 평가 기준은 처음부터 완성되는 명세가 아니라, 실제 사례를 통해 계속 다듬어지는 작업물이다.

3. 과적합(Overfitting) 위험

   1. 한 팟캐스트에서 요약이 MECE(Mutually Exclusive, Collectively Exhaustive)가 아니었다고 판단하면 그 문제를 기준으로 추가할 수 있다.
   2. 그러나 다음 인터뷰에서는 MECE가 덜 중요한 주제일 수 있는데도 동일한 기준을 강제하면 특정 에피소드에 과적합된다.
   3. 따라서 한 사례에서 나온 피드백을 여러 에피소드와 샘플에서 다시 확인해 일반적인 실패 모드인지 검증해야 한다.

3. 하향식(Top-down)과 상향식(Bottom-up)을 분리하는 5단계 사고법

평가의 완전성은 작업을 설명만 보고 생각한 기준과, 실제 데이터에서 발견한 기준을 함께 관리할 때 높아진다.

3.1. 하향식 기준: 작업 설명과 도메인 지식에서 시작하기

1. 하향식의 정의

   1. 데이터 샘플을 아직 보지 않았다고 가정하고, 도메인 전문가가 작업 설명만 읽고 무엇을 살필지 정하는 방식이다.
   2. “좋은 팟캐스트 요약이란 무엇인가?”라는 질문에서 출발한다.
   3. 데이터 자체에서 직접 도출되는 것이 아니라, 과업의 본질에 대한 전문가의 이해에서 나온다.

2. 팟캐스트 요약의 대표 기준

   1. 요약의 길이가 정해진 범위에 들어가는지 확인한다.
   2. 행동을 촉구하는 동사(Action Verb)를 올바르게 사용하는지 본다.
   3. 사람이 실제로 실행할 수 있는 조언인지 확인한다.
   4. 영상이나 전체 대화를 보지 않은 사람도 문맥을 이해할 수 있는지 점검한다.

3. Claude의 강점과 한계

   1. 작업 설명과 일반적인 도메인 원칙을 바탕으로 기준을 제안하는 데 Claude가 비교적 강하다.
   2. 그러나 실제 샘플을 많이 읽은 사람이 “왠지 이상하다”고 느끼는 미묘한 실패 모드를 스스로 충분히 만들어내지는 못한다.

3.2. 상향식 기준: 실제 샘플과 인간의 직감에서 시작하기

1. 상향식의 정의

   1. 많은 샘플 출력을 읽으며 생기는 직감과 피드백을 평가 기준으로 외부화하는 방식이다.
   2. Peter가 모델과 왕복하면서 “이 요약은 왜 마음에 들지 않는가”를 찾아낸 사례가 상향식 기준의 출발점이다.
   3. 상향식 평가는 데이터에 직접 뿌리를 두므로, Claude에게 기준을 창작하라고 맡기기보다 사람이 관찰하며 발견해야 한다.

2. 과거 데이터 전체를 활용하는 방법

   1. 과거 10~20개 인터뷰의 원본 트랜스크립트와 사람이 최종 편집한 결과를 함께 준비한다.
   2. 현재의 팟캐스트 스킬을 10개 이상의 원본에 다시 적용해 모델이 만든 결과를 얻는다.
   3. 모델 출력과 사람이 승인한 최종 결과를 나란히 비교한다.
   4. 여러 사례에 반복되는 차이와 실패 패턴을 AI 에이전트에게 찾아보게 한다.
   5. 실제 정답 또는 사람이 확정한 라벨이 있으므로, 에이전트가 두 결과의 차이를 반성하며 데이터에서 직접 상향식 기준을 도출할 수 있다.

3.3. 두 기준을 스킬에 구현하기

1. 평가 목록을 명시적으로 분리하기

   1. 스킬 파일 안에서 Top-down Evals와 Bottom-up Evals를 별도 영역으로 관리한다.
   2. 새 기준이 어느 쪽에서 나왔는지 기록하면 한 사례의 피드백이 일반 원칙인지 특정 데이터의 관찰인지 구분할 수 있다.

2. 기준별 하위 에이전트로 분산하기

   1. 평가 기준이 많으면 모든 항목을 한 모델 호출에 맡기지 않는다.
   2. 각 기준 또는 서로 관련된 기준 묶음마다 하위 에이전트를 하나씩 배정한다.
   3. 한 하위 에이전트가 한 영역에 집중하면 긴 체크리스트를 한꺼번에 받았을 때 생기는 누락과 게으른 평가를 줄일 수 있다.
   4. 예를 들어 여러 요약을 평가할 때 길이, 독립적 이해 가능성, 행동 가능성, 문체를 각각 집중적으로 검사할 수 있다.

3. 스프레드시트·피벗 테이블로 판단권을 남기기

   1. 하위 에이전트가 각 기준의 결과와 비교 대상(Comparison), 통과·실패(Pass/Fail) 또는 예·아니오 값을 표로 만들게 한다.
   2. 사람은 표를 보고 어떤 기준이 모든 작업에서 중요한지 빠르게 판단한다.
   3. 반드시 수치 가중치(Weight)를 계산할 필요는 없으며, 기준별 결과를 한눈에 보는 것만으로도 중요도 계층을 직접 조정할 수 있다.
   4. 특정 에피소드에서 눈에 띈 MECE 문제가 다른 에피소드에서는 핵심이 아닐 수 있다는 사실도 표에서 확인할 수 있다.

4. 글쓰기 평가를 위한 오류 발견 인터페이스

글쓰기는 모델이 문법적으로 맞는 문장을 만드는 것보다 사람의 취향에 맞는 문장을 만드는 일이 훨씬 어려워 “LLM의 최종 보스”가 된다.

4.1. 글쓰기 작업의 주관성과 모델의 슬롭(Slop)

1. 정답보다 느낌이 중요한 작업

   1. 기준이 많고 서로 주관적이며, 글의 주제에 따라 일부 기준을 완화해야 할 때도 있다.
   2. 어떤 생각이 다른 생각과 자연스럽게 연결되는지는 결과를 직접 읽기 전까지 판단하기 어렵다.
   3. 글쓰기는 읽고, 고치고, 다시 읽으며 취향을 정교하게 만드는 창의적 흐름을 포함한다.

2. 모델에 직접 편집을 맡겼을 때의 문제

   1. AI가 블로그 글을 직접 수정하면 무엇을 바꿨는지 사람이 알기 어렵다.
   2. 문장에 원하지 않는 AI 슬롭을 추가할 수 있다.
   3. 따라서 결과를 통째로 덮어쓰게 하기보다 평가 결과를 보여주고 사람이 원문과 수동 비교하는 흐름이 안전하다.

3. AI 슬롭 제거 스킬의 역설

   1. Shreya는 글에서 AI 특유의 뻔한 표현을 제거하는 스킬을 만들었고, 자신이 쓰는 모든 글에 그 패스를 적용한다.
   2. 같은 스킬에 “AI 슬롭을 최대한 많이 넣어라”라고 반대로 요청하면 “여기서 중요한 점은”, “패러다임 전환” 같은 표현을 쏟아내는 우스운 결과가 나온다.
   3. 스킬이 지나치게 강하면 작성자의 개성까지 제거할 수 있다.
   4. 두 사람이 각자의 스킬을 합치자는 농담을 주고받았고, Shreya의 스킬은 Plain Writing Skills라는 이름으로 공개할 계획이라고 했다.

4.2. 오류 발견 스킬의 5단계

1. 1단계 — 데이터셋의 의미적 유형 읽기

   1. 문자열·숫자 같은 단순 자료형을 확인하는 데 그치지 않고 데이터의 의미적 유형을 파악한다.
   2. 데이터가 기사(Article)인지, 코드(Code)인지, 에이전트 트레이스(Trace)인지 결정한다.
   3. 데이터 유형을 알아야 이후의 렌더링과 샘플 선택 방식이 맞게 설계된다.

2. 2단계 — 사람이 읽기 쉬운 시각 인코딩(Visual Encoding) 설계

   1. 데이터에서 무엇이 변하는지 살핀다.
   2. 에이전트 트레이스라면 턴 수(Number of Turns) 같은 변이를 시각화할 수 있다.
   3. 색상, 여백, 불투명도(Opacity)와 같은 시각적 수단으로 변이를 표시해 인간의 시각 처리 능력을 활용한다.
   4. 로그 파일이나 거대한 스프레드시트를 읽는 대신 실제 사용자가 읽는 방식으로 결과를 보여준다.

3. 3단계 — 리뷰 앱(Review App) 만들기

   1. 백엔드는 Python으로 만들고 프론트엔드는 JavaScript와 HTML로 구성한다.
   2. 목적은 기술적으로 복잡한 제품을 만드는 것이 아니라 사람이 데이터를 빠르게 읽고 주석을 남길 인터페이스를 만드는 것이다.
   3. 데이터 유형에 따라 기사, 트레이스, 고객지원 대화 등 서로 다른 화면이 자동으로 설계될 수 있다.

4. 4단계 — 초기 검토 샘플 선택하기

   1. 수백~수천 개의 트레이스가 있을 때 무엇을 먼저 읽을지 AI 에이전트가 결정한다.
   2. 에이전트는 데이터의 의미 있는 클러스터를 만들고 각 클러스터에서 다양한 대표 샘플을 뽑는다.
   3. 첫 샘플이 한 종류의 실패에만 몰리지 않도록 다양성을 확보한다.

5. 5단계 — 사람과 에이전트의 상호작용 루프

   1. 사람이 인터페이스에서 남긴 클릭·주석·자유형 피드백을 Claude Code나 Codex가 관찰한다.
   2. 에이전트는 자유형 피드백을 실시간으로 읽고, 새로운 라벨을 사람이 직접 발명하는 대신 실행 가능한 루브릭 기준으로 묶어낸다.
   3. 필요한 경우 사람이 다음에 볼 샘플을 추가로 제안하거나, 이미 발견된 기준으로 전체 데이터를 주석 처리한다.
   4. 데이터 검토 도중 에이전트가 백그라운드에서 생각하도록 하면 사람이 멈춰서 회고 결과를 기다리지 않고 읽기 흐름을 유지할 수 있다.

4.3. 실제 데모의 데이터와 실행 환경

1. 합성 글쓰기 데이터

   1. 데이터는 AI 평가 강의에서 만든 합성 입력과, 사람들이 AI에게 글쓰기를 부탁할 법한 사례로 구성됐다.
   2. 기사 샘플을 사용했지만 같은 스킬은 최종 사용자와의 엔드투엔드 트레이스에도 적용할 수 있다.
   3. 실행에는 처음 약 5분이 걸릴 것으로 예상했으나 실제 인터페이스가 완성되기까지 약 15분이 걸렸다.
   4. 에이전트는 그동안 데이터 구조를 읽고 클러스터링한 뒤, 다양성을 갖춘 첫 라벨링 샘플을 선택했다.

2. Claude·Codex·Fable에 대한 사용 경험

   1. Shreya는 Fable이 더 규모 있는 소프트웨어 엔지니어링 작업에 적합하다고 느꼈고, Codex/GPT 계열의 새 Soul 모델이 어려운 작업을 처리하며 사람이 읽기 쉬운 결과를 내는 점을 높이 평가했다.
   2. Claude 계열 모델은 때때로 일상적으로 쓰지 않는 전문용어를 과하게 사용해 결과를 읽기 어렵게 만들었다.
   3. Hamel은 Codex 앱의 모바일 지원을 특히 강조했다. 여러 기기의 세션을 한곳에서 보고, 메시지를 예약하고, 작업을 조종하고, 모델을 바꾸고, 아티팩트를 확인할 수 있다.
   4. Codex가 다른 Codex를 조종할 수 있다는 점도 장점으로 꼽았다. 스레드를 만들고 서로 대화하게 하거나, 실행 중인 스레드에 다른 스레드를 태그해 연구와 선행 작업을 맡길 수 있다.
   5. 스레드 이름을 일괄 변경하는 등 에이전트가 에이전트를 운영하게 만들 수 있어, 완전한 코드 팩토리까지 가지 않아도 오케스트레이션이 가능하다.
   6. 프론티어 모델 사용량 제한이 비교적 적고 구독에 포함된 경제성도 Codex를 선택하게 하는 요인으로 언급됐다. 사용량 한도가 50%에 도달해도 계속 초기화되는 상황을 두고 농담이 오갔다.
   7. 현재의 저렴한 AI 가격은 과거 Uber·Lyft가 2달러에 서비스를 제공하던 시기와 같은 보조금 시대이며, 언젠가 보조금이 끝날 것이라는 전망도 나왔다.
   8. Anthropic의 커뮤니케이션 전략이 엉망이고 Dario Amodei가 Twitter를 싫어하는 것 아니냐는 농담이 나왔지만, 내부 사정 때문에 소통하고 싶은 직원들이 제약받을 수 있다는 추측 수준의 대화였다.
   9. Peter는 몇 달 전까지만 해도 Claude의 열성 팬이었지만 이제는 Fable로 계획과 버그 탐색을 하는 경우를 제외하면 Codex와 GPT를 거의 모든 일에 사용한다고 했다.
   10. API가 없는 웹사이트도 Codex 브라우저로 직접 클릭하며 사용할 수 있다는 점을 높이 평가했다.
   11. Peter가 가장 자주 쓰는 역공학(Reverse Engineering) 스킬은 웹사이트의 네트워크 트래픽을 관찰하고 API를 문서화해 스크립트로 보존한다. 덕분에 어떤 웹사이트든 API처럼 만들 수 있다는 농담이 나왔다.
   12. 비슷한 작업을 하는 Printing Press CLI도 언급됐다.

5. 사람이 읽고 남긴 피드백을 루브릭으로 확장하기

리뷰 앱은 사람이 판단하는 화면과 AI가 패턴을 확장하는 화면을 분리해, 취향의 주도권은 사람에게 두고 반복 작업은 에이전트에게 맡긴다.

5.1. 인터페이스의 세 가지 보기

1. 문서별 보기(Article-by-article)

   1. 기사 한 편씩, 또는 데이터의 단위에 따라 트레이스 하나씩 읽는다.
   2. 글쓰기처럼 결과를 최종 사용자에게 보이는 형태 그대로 읽고 그 자리에서 주석을 남긴다.

2. 맵 보기(Map View)

   1. 에이전트가 만든 의미적 클러스터를 시각적으로 보여준다.
   2. 사람이 어떤 종류의 샘플을 이미 읽었는지, 어떤 영역이 비어 있는지 파악할 수 있다.

3. 진행 상황 보기(Progress View)

   1. 사람이 남긴 주석에서 공통 실패 모드가 무엇인지 집계한다.
   2. 에이전트가 새로운 피드백을 발명하는 대신, 사람의 피드백을 그룹화하고 실행 가능한 루브릭으로 정리한다.

5.2. 인시추(In situ) 검토와 라이브 반성

1. 실제 글을 읽으며 바로 기록하기

   1. 수면 위생(Sleep Hygiene)에 관한 AI 생성 글을 읽으며 하향식 기준은 Claude가 처리한다고 가정한다.
   2. “X가 아니라 Y다” 형태의 부정 대조(Negative Contrast)를 글에서 싫어한다고 바로 기록한다.
   3. “이 표현은 짜증나지만 아직 정확한 라벨을 붙일 수 없다”처럼 이유를 완전히 설명하지 못하는 감정도 그대로 남긴다.
   4. 추가 사례를 읽으며 같은 감각이 반복되는지 확인하면 막연한 불편함이 구체적인 실패 모드로 발전한다.

2. 백그라운드 모니터의 역할

   1. Claude Monitor 도구가 사람이 남긴 주석을 뒤에서 관찰하고 의미를 해석한다.
   2. 사람은 AI 화면을 계속 기다리지 않고, 클러스터에서 고른 다음 샘플을 읽으며 자신의 생각을 이어간다.
   3. 보통 사람은 여러 샘플을 봐야 피드백을 만들 수 있으므로 초반에 충분히 많은 데이터를 직접 검토해야 한다.

3. 수동 검토와 자동 확장의 경계

   1. 사람이 처음 약 10개의 주석을 남기면 에이전트가 실패 모드의 분류 체계를 만들기 시작한다.
   2. 이후 에이전트는 모든 샘플에서 부정 대조처럼 이미 알려진 패턴을 자동으로 찾아 라벨을 붙인다.
   3. 사람이 판단하는 것은 목소리·문체·취향이고, 사실 오류를 전부 자동화하는 것이 아니다.
   4. AI가 기준을 제대로 이해했는지 확인하기 위해 제안된 주석을 빠르게 훑고 수락한다. 부정 대조의 의미를 제대로 이해했으면 전체 수락을 해도 되지만, 처음에는 샘플을 점검해야 한다.

5.3. 실제로 발견된 문체 실패 모드

1. 부정 대조

   1. “X가 아니라 Y”라는 반복적인 대조 문형이 AI 문체처럼 느껴진다.
   2. 사람이 한두 번 지적한 뒤 에이전트가 전체 데이터의 유사 문장을 찾아낼 수 있다.

2. 삼단 병렬 열거(Triadic Parallel Enumeration)

   1. AI가 목록을 세 항목으로 나누는 패턴을 지나치게 자주 사용한다.
   2. “알아야 할 두세 가지”, “기억해야 할 몇 가지”처럼 항목을 인위적으로 늘리는 문단도 같은 슬롭의 신호로 볼 수 있다.

3. 단문 파편과 문장 구조

   1. 네 단어보다 짧은 단문 파편(Staccato Fragment)을 별도 실패 모드로 기록한다.
   2. 문장 중간의 콜론(Colon) 사용도 반복적으로 나타나는 패턴으로 집계된다.
   3. 문단이 작은 내용을 시작하는 방식과 주제 문장(Topic Sentence)을 어떻게 배치하는지 확인한다.
   4. 완전한 문장(Complete Sentence)을 요구해 지나치게 끊긴 문체를 줄인다.

4. 빈도 분석이 사람의 예상과 다를 때

   1. 리뷰 결과 361개의 자동 제안이 생성됐다.
   2. “4단어 미만 단문 파편” 규칙 하나가 249개의 사례를 설명했다.
   3. 사람은 처음에 부정 대조가 가장 많을 것이라 생각했지만, 실제 데이터에서는 단문 파편이 가장 빈번한 패턴으로 나타났다.
   4. 에이전트가 전체 데이터를 훑고 빈도를 보여주면 사람은 자신의 막연한 인상과 실제 분포를 비교할 수 있다.

5.4. 루브릭·벤치마크·스킬로 이어지는 경로

1. 발견된 실패 모드를 평가로 전환하기

   1. 인시추 주석과 자동 확장 결과가 문체 실패 모드의 데이터셋을 만든다.
   2. 각 실패 모드를 LLM Judge의 한 가지 기준으로 바꾼다.
   3. 새 글이 들어올 때마다 단문 파편, 부정 대조, 삼단 열거 등 기준별 결과를 측정한다.
   4. 여러 Judge를 대시보드에 연결해 에이전트 트레이스나 글쓰기 출력의 변화를 실시간으로 모니터링할 수 있다.

2. 루브릭만으로는 평가가 완성되지 않는다

   1. 루브릭은 무엇을 볼지 정의할 뿐, 실제 데이터에서 얼마나 잘 작동하는지 보여주지 않는다.
   2. 주석이 붙은 샘플 데이터셋을 벤치마크로 삼아 기준의 측정 결과를 비교해야 한다.
   3. 따라서 오류 분석은 루브릭 작성과 데이터셋 구축을 동시에 포함한다.

3. 쓰기 스킬 생성

   1. “발견된 실패 모드에 따라 AI 보조 글쓰기를 평가하는 스킬을 작성하라”고 요청하면 스킬과 루브릭 초안을 만들 수 있다.
   2. 다섯 개 샘플만 보고 멈추지 말고 18개 전체를 검토하는 등 포화(Saturation)가 느껴질 때까지 몇 시간 더 오류 발견을 진행해야 한다.
   3. 그 후 새 글마다 생성된 평가 스킬을 실행하고, 예를 들어 단문 파편이 얼마나 많은지 확인한다.

6. 평가 인터페이스가 제품 인터페이스를 결정한다

결과를 자동으로 덮어쓰는 평가보다 문제의 이유를 보여주고 사람이 수락·거부하는 평가가 실제 제품 경험을 더 잘 설계하게 한다.

6.1. 주석 화면에서 글쓰기 IDE로

1. 평가 방식과 사용자 화면의 연결

   1. 리뷰 앱이 부정 대조, 단문 파편, 삼단 열거를 찾아내면 실제 글쓰기 IDE도 같은 항목을 표시할 수 있다.
   2. 문장 옆에 “부정 대조”, “단문 파편”처럼 문제가 되는 이유를 보여준다.
   3. AI가 문장을 통째로 바꾸는 대신 제안을 수락하거나 거부하게 하면 사람이 계속 읽고 판단할 수 있다.

2. 데이터마다 다른 인터페이스

   1. 글쓰기에는 인시추 편집 화면이 적합하다.
   2. 고객지원 봇은 고객 메시지, 도구 호출, 답변, 채널 맥락을 함께 보여주는 완전히 다른 화면이 필요하다.
   3. 오류 발견 스킬이 데이터의 성격을 읽고 시각 인코딩을 설계하는 이유도 여기에 있다.

6.2. “데이터 검토를 건너뛴다”는 오해

1. AI가 해주는 것은 가속이지 대체가 아니다

   1. 에이전트는 사람이 만든 기준을 전체 데이터에 적용하고 반복 패턴을 집계한다.
   2. 사람이 실제 데이터를 읽는 단계 자체를 없애지는 않는다.
   3. AGI가 등장해도 제품을 만드는 사람은 자기 데이터에 취향을 주입해야 하므로 출력을 직접 보지 않고는 좋은 제품을 만들 수 없다.

2. 사람과 AI의 역할 분담

   1. 사람은 어떤 표현이 좋은지, 고객에게 어떤 행동이 바람직한지, 어떤 맥락이 중요한지 정한다.
   2. AI는 사람이 발견한 기준을 확장하고, 샘플을 분류하고, 주석을 달고, 빈도와 예외를 보여준다.
   3. 핵심은 사람이 맛(Taste)을 주도하고 AI가 그 맛을 규모 있게 적용하는 것이다.

6.3. 개인 도구와 SaaS의 유연성

1. 자기 워크플로에 맞춘 도구

   1. 전용 SaaS는 일반적인 사용 사례를 중심으로 설계되므로, 특정 사용자의 취향과 예외를 모두 담기 어렵다.
   2. Claude 안에 직접 스킬과 인터페이스를 만들면 왼쪽 대화창에서 누락된 테마를 즉시 수정할 수 있다.
   3. UI가 놓친 실패 모드가 있어도 기존 제품의 제한된 흐름에 갇히지 않고 에이전트에게 바로 보완을 지시할 수 있다.

2. SaaS를 대체할 수 있는 조건

   1. 좋은 워크플로를 이미 이해하고 직접 구현할 수 있는 사람에게는 범용 SaaS보다 맞춤 스킬이 유연하다.
   2. 반대로 어디서 시작해야 할지 모르는 사람에게는 이 과정 자체가 어렵고, 좋은 평가 절차에 대한 지식이 먼저 필요하다.
   3. 결과적으로 코드로 만들 수 있다는 사실만으로 SaaS가 사라지는 것은 아니며, 도메인별 워크플로를 발견하고 설계하는 능력이 차별점이 된다.

7. 팟캐스트 스킬에 오류 발견을 적용하는 방법

기존 스킬과 사람이 승인한 과거 결과를 함께 제공하면 같은 오류 발견 인터페이스를 팟캐스트 요약 도메인에 맞춰 재생성할 수 있다.

7.1. 준비할 데이터

1. 폴더 구조

   1. 현재 사용하는 팟캐스트 핵심 요약 생성 스킬을 그대로 폴더에 넣는다.
   2. 과거 팟캐스트 트랜스크립트와 그중 사람이 좋다고 판단한 최종 요약을 함께 넣는다.
   3. 가능하면 모델 초안과 사람의 수정본을 둘 다 보관해 차이를 비교할 수 있게 한다.

2. 실행 요청

   1. 오류 발견 스킬을 호출하며 팟캐스트 요약 스킬의 오류를 분석해 달라고 요청한다.
   2. 에이전트가 기존 요약 스킬을 여러 트랜스크립트에 적용해 새 결과를 만든다.
   3. 새 결과를 사람의 승인 결과와 비교할 수 있는 인터페이스를 데이터에 맞춰 설계한다.

7.2. 결과를 신뢰하는 기준

1. 새 인터페이스는 데이터에 맞게 달라진다

   1. 글쓰기 샘플에서 만든 수면 위생용 화면을 팟캐스트에 그대로 복사하지 않는다.
   2. 에이전트가 트랜스크립트, 생성 요약, 사람의 최종 결과를 읽고 팟캐스트에 맞는 시각적 비교 방식을 새로 만든다.
   3. 예를 들어 AI 출력과 사람의 정답을 좌우에 배치하거나, 요약 간 중복·누락·행동 가능성을 별도 표시할 수 있다.

2. 목표는 자신감(Confidence)이다

   1. 오류 분석의 목적은 평가 화면을 예쁘게 만드는 데 있지 않다.
   2. 내 스킬이 실제로 어떤 행동을 하는지, 어떤 실패 모드를 반복하는지 확신을 얻는 것이 목표다.
   3. 인터페이스가 만들어진 뒤에도 약 15분을 들여 충분한 샘플을 읽고, 기준이 포화됐는지 확인해야 한다.

3. 공개 리소스

   1. 오류 발견 스킬은 GitHub의 Error Discovery Skill로 공개되어 있으며, 영상 설명에 링크를 넣겠다고 했다.
   2. Claude가 스킬 작성과 구현을 도왔다는 사실을 숨기지 않았다.
   3. 다만 프로세스 자체와 README를 만든 것은 Shreya이며, AI는 그 프로세스를 스킬로 구현하는 데 활용됐다.

8. 자동 평가 도구의 실제 성능과 한계

자동화된 평가는 명백한 오류를 빠르게 찾는 좋은 기준선이지만, 제품이 성공하기 위해 필요한 판단과 맥락을 발견하는 데에는 사람의 데이터 검토가 필수다.

8.1. “자동 평가 버튼”의 유혹

1. 상용 도구의 공통 구조

   1. 최근 여러 업체가 트레이스를 업로드하면 AI와 채팅하며 평가를 자동으로 만들어 주는 기능을 출시했다.
   2. Braintrust의 Trace Viewer와 Loop, Arize의 유사한 Alex 기능, LangSmith의 기능이 예로 언급됐다.
   3. 사용자는 “내 트레이스를 보고 평가를 해 달라”고 요청할 수 있어 실제 검토를 생략하고 싶은 유혹을 느낀다.

2. 사람 라벨 데이터셋으로 한 벤치마크

   1. 사람이 이미 오류를 표시한 데이터셋을 준비해 자동 평가 시스템이 같은 오류를 찾아내는지 비교했다.
   2. 도구들은 사람이 발견한 오류의 상당수를 회수했다.
   3. 그러나 여러 자동화 도구가 공통적으로 명백하지 않은 오류와 제품 판단이 필요한 오류를 놓쳤다.

8.2. 잘 찾는 오류와 놓치는 오류

1. 자동화에 강한 명백한 오류

   1. 도구 호출이 실패했다.
   2. 사용자가 불만을 직접 표현했다.
   3. 트레이스에서 어떤 단계가 뚜렷하게 잘못됐다.
   4. 이런 문제는 제품 전문지식 없이도 오류임을 알 수 있어 AI가 높은 성능으로 찾아낸다.

2. 자동화가 놓치는 제품 판단

   1. 벤치마크에는 아파트 매매·임대 문의를 처리하는 실제 부동산 판매 에이전트의 고객지원 트레이스가 사용됐다.
   2. 고객이 판매 이의를 제기했을 때 “해당 매물은 없다, 좋은 하루 보내라”고 끝내는 대신 다른 대안을 제시해야 했지만, 자동 평가가 이 미묘한 실패를 반복해서 놓쳤다.
   3. 고객이 웹, 문자 메시지, 전화로 소통하는 멀티채널 환경이라는 맥락도 자동 평가가 처음부터 알지 못했다.
   4. 문자 메시지에 Markdown을 넣으면 제대로 표시되지 않으므로 금지해야 하지만, 이런 채널 특유의 제약도 데이터와 제품 지식 없이는 발견하기 어렵다.
   5. 판매 이의 처리와 채널별 표현 규칙은 “명백히 실패했다”가 아니라 “제품이 잘 작동하려면 무엇이 좋아야 하는가”에 해당한다.

8.3. Coding Agent와 자동 평가 도구의 비교

1. 성능은 거의 같은 수준

   1. Claude Code, Codex 등 코딩 에이전트와 상용 자동 평가 도구를 비교했을 때 오류 탐지 방식이 크게 다르지 않았다.
   2. 자동 평가 도구의 하니스(Harness)는 얇고, 결국 모델에게 주는 프롬프트가 핵심이었다.
   3. 채팅으로 “평가해 달라”고 요청하면 도구 뒤에 숨은 프롬프트가 같은 모델을 불러 비슷한 작업을 수행한다.

2. 더 나은 방법은 기준으로 에이전트를 조종하는 것

   1. 좋은 결과와 나쁜 결과에 대한 구체적인 아이디어를 에이전트에게 제공해야 한다.
   2. 그러나 모든 기준을 미리 하향식으로 생각하는 것은 인간에게도 거의 불가능하다.
   3. 사람이 실제 데이터를 보고 오류 발견을 먼저 수행한 뒤, 발견된 기준으로 에이전트를 조종하는 순서가 현실적이다.

8.4. 기준선으로 사용하되 맹신하지 않기

1. 자동화 도구의 올바른 위치

   1. 자동 평가 도구는 많은 명백한 오류를 찾아주므로 반드시 사용해야 한다.
   2. 특히 트레이스가 이미 LangSmith에 저장돼 있다면 생태계에 통합된 LangSmith 평가를 쓰는 것이 자연스럽다.
   3. 자동화 결과를 수동 검토의 대체물이 아니라, 사람이 확인할 오류 후보를 넓혀주는 기준선으로 사용한다.

2. 정밀도(Precision)와 재현율(Recall) 함께 보기

   1. 최선의 경우에도 자동 평가 결과의 정밀도는 80~90% 수준이다.
   2. 따라서 찾아낸 오류의 10~20%는 실제 오류가 아닌 레드 헤링(Red Herring)일 수 있다.
   3. 잘못된 오류를 그대로 제품 개선에 반영하면 정상적인 행동을 문제로 고치거나 제품 방향을 왜곡할 수 있다.
   4. 얼마나 많은 실제 오류를 찾았는지 나타내는 재현율과, 찾은 오류 중 실제 오류가 얼마나 되는지 나타내는 정밀도를 모두 확인해야 한다.
   5. AI가 생성한 글뿐 아니라 코드도 선택적으로 직접 읽는 것이 경쟁 우위가 된다.

9. 강의가 제시하는 운영·제품화 로드맵

평가를 조직의 개발·배포·안전·개선 루프에 연결해야 장기적인 제품 차별화와 비용 절감으로 이어진다.

9.1. 다섯 모듈로 확장되는 평가 실무

1. 오류 분석 철학

   1. 실제 데이터를 보고 취향을 외부화하는 방법을 다룬다.
   2. 하향식·상향식 기준을 함께 만들고, 에이전트로 데이터 검토를 확장한다.

2. 조직에서의 운영화(Productionization)

   1. 여러 사람이 같은 제품을 만들 때 평가 기준을 맞추는 방법을 다룬다.
   2. 평가를 CI/CD 파이프라인에 통합해 변경 때마다 품질을 확인한다.
   3. 배포 후 수개월 동안 모델과 제품 행동이 변하는 드리프트(Drift)를 모니터링한다.

3. 안전과 적대적 평가(Adversarial Evaluation)

   1. 고객에게 실제로 배포할 때 테넌트 데이터가 유출되지 않는지 평가한다.
   2. 공격적인 입력과 경계 사례를 반복 테스트해 시간이 지나도 안전성이 유지되는지 확인한다.

4. 비용·정확도 개선

   1. 더 저렴한 모델로 바꿨을 때 정확도를 어떻게 유지하거나 개선할지 다룬다.
   2. 비용 절감과 정확도 개선은 서로 반대되는 목표가 아니라 함께 최적화할 수 있는 목표다.
   3. 평가를 자동 연구(Auto-research) 루프에 넣어 어떤 개선 전략을 실행할지 결정할 수 있다.

5. 반복 가능한 개선 루프

   1. 평가 결과를 이용해 프롬프트, 모델, 워크플로를 바꾸고 다시 측정한다.
   2. 컨설팅 사례와 수강생 사례에서 Opus 사용 대비 비용을 100배까지 줄인 사례가 소개됐다.
   3. Fable을 사용하면 더 큰 폭의 절감이 가능할 수 있다는 기대도 덧붙었다.

9.2. 최종 실행 체크리스트

1. 스킬을 평가할 때

   1. 실제 원본 데이터와 사람이 승인한 결과를 준비한다.
   2. 하향식 기준과 상향식 기준을 분리한다.
   3. 많은 샘플을 읽으며 사람의 직감과 실패 모드를 기록한다.
   4. 하위 에이전트로 기준별 평가를 분산한다.
   5. 주석 데이터셋을 만들고 pass/fail 결과를 표로 확인한다.

2. 자동 평가를 도입할 때

   1. 상용 도구나 코딩 에이전트로 명백한 오류를 먼저 넓게 찾는다.
   2. 자동 평가가 반환한 오류를 표본 검토해 정밀도를 확인한다.
   3. 사람이 제품 맥락과 취향이 필요한 오류를 추가로 찾는다.
   4. 재현율과 정밀도를 함께 기록하고, 레드 헤링을 제품 기준으로 오인하지 않는다.

3. 제품에 반영할 때

   1. AI가 결과물을 임의로 덮어쓰지 않고 오류의 이유와 수정 제안을 보여주게 한다.
   2. 사용자가 수락·거부할 수 있는 인터페이스를 제공한다.
   3. 평가 기준을 대시보드, CI/CD, 드리프트 모니터링, 안전 테스트에 연결한다.
   4. 사람이 직접 읽는 과정을 유지하면서 에이전트가 반복 작업을 확장하게 한다.

주요 발언 모음

“Writing is the final boss for LLMs.”

“Bottom-up is data driven. Top-down is not about the data.”

“Human is the one driving the taste, and AI is the one scaling it.”

“Actually reading and looking at stuff is the edge.”

“There is no world in the future where, even if you have AGI, you don't have to look at your data.”

핵심 데이터 & 수치

• 4,500명 이상: Shreya와 Hamel이 운영한 AI 평가 강의의 누적 수강생 규모로 소개됐다.
• 240~330자: 팟캐스트 핵심 요약 하나에 적용한 길이 기준이다.
• 10~20개 인터뷰: 과거 원본 트랜스크립트와 최종 편집본을 비교해 상향식 패턴을 찾기 위한 예시 규모다.
• 5단계: 오류 발견 스킬은 데이터 유형 파악, 시각 인코딩, 리뷰 앱 구축, 샘플 선택, 상호작용 루프로 구성된다.
• 약 5분 예상·약 15분 실제: 합성 글쓰기 데이터에서 인터페이스가 완성되기까지 걸린 시간이다.
• 약 10개 주석: 에이전트가 피드백을 분류하고 자동 제안을 시작하는 기준으로 언급됐다.
• 361개 제안: 문체 오류를 전체 문서에 확장한 뒤 생성된 자동 주석 수다.
• 249개 사례: 4단어 미만 단문 파편 규칙으로 설명된 자동 주석 수다.
• 18개 샘플: 오류 발견을 다섯 개 정도만 보고 멈추지 말고 충분히 포화될 때까지 검토하라는 예시다.
• 80~90% 정밀도: 자동 평가 도구가 가장 좋은 경우에도 도달하는 오류 판정 정밀도다.
• 10~20% 레드 헤링: 자동 도구가 오류라고 표시하지만 실제 오류가 아닐 수 있는 비율이다.
• 100배 비용 절감: 강의의 컨설팅·수강생 사례에서 Opus 사용 대비 소개된 비용 절감 폭이다.

결론 및 시사점

1. 실제 데이터 검토를 생략한 자동 평가는 명백한 오류의 기준선일 뿐이며 제품의 성공 조건을 정의하지 못한다.
2. 과업 설명에서 나온 하향식 기준과 샘플 관찰에서 나온 상향식 기준을 분리하면 평가의 누락과 과적합을 함께 줄일 수 있다.
3. 사람이 남긴 자유형 피드백을 에이전트가 클러스터·주석·루브릭·벤치마크로 확장하게 하면 오류 분석의 반복 비용을 크게 낮출 수 있다.
4. 좋은 평가 루프는 생성물을 자동 수정하는 대신 문제의 이유를 설명하고 사람이 수락·거부하도록 해 사람의 취향과 제품 맥락을 보존한다.
5. 자동 평가 도구·Claude Code·Codex는 경쟁사의 기준선도 될 수 있으므로, 차별화는 모델이 아니라 제품에 얼마나 깊은 도메인 판단을 주입하느냐에서 나온다.
6. 가장 중요한 실행은 먼저 과거의 원본과 사람이 승인한 결과를 모아 오류 발견 스킬을 실행하고, 그 결과로 만든 루브릭을 새 출력·CI/CD·모니터링에 연결하는 것이다.

핵심 요약 (20줄)

실제 트레이스와 생성물을 먼저 읽고 오류를 구조적으로 분석하는 것이 AI 평가의 출발점이다.

하향식 평가는 작업 설명과 도메인 지식에서 나오고 상향식 평가는 여러 실제 샘플을 관찰하며 발견된다.

Claude는 일반적인 하향식 기준을 제안하는 데 강하지만 데이터에서 미묘한 상향식 실패 모드를 스스로 충분히 발굴하지 못한다.

팟캐스트 요약 평가는 240~330자 길이, 독립적 이해 가능성, 평이하고 실행 가능한 조언을 함께 검사해야 한다.

한 에피소드에서 발견한 MECE 문제를 모든 에피소드에 강제하면 평가 기준이 특정 사례에 과적합될 수 있다.

평가 기준이 많을수록 기준별 하위 에이전트를 사용하고 결과를 pass/fail 표나 피벗 테이블로 확인하는 편이 안전하다.

글쓰기는 문법보다 사람의 취향과 맥락이 중요해 LLM에게 가장 어려운 최종 보스에 가깝다.

AI가 글을 직접 덮어쓰게 하면 수정 내역을 알기 어렵고 원하지 않는 AI 슬롭이 추가될 수 있다.

오류 발견 스킬은 데이터 유형 파악, 시각 인코딩, 리뷰 앱 구축, 샘플 선택, 상호작용 루프의 5단계로 작동한다.

에이전트는 수백 개의 데이터를 의미 있는 클러스터로 묶고 사람이 읽을 다양성 있는 초기 샘플을 선택한다.

사람은 글을 인시추로 읽으며 부정 대조나 설명하기 어려운 불편함을 자유형 피드백으로 남긴다.

에이전트는 사람의 피드백을 백그라운드에서 분류하고 약 10개 주석 뒤 알려진 실패 모드를 전체 데이터에 확장한다.

단문 파편, 콜론, 삼단 병렬 열거, 불완전한 문장은 AI 글쓰기에서 반복적으로 나타나는 문체 실패 모드다.

자동 주석 361개 중 249개가 4단어 미만 단문 파편 규칙으로 설명돼 사람의 예상과 실제 빈도가 달라질 수 있음을 보여줬다.

발견된 실패 모드는 LLM Judge 기준, 대시보드, 데이터셋 벤치마크, 새 글쓰기 스킬로 전환할 수 있다.

평가 방식은 사용자 인터페이스 설계에도 영향을 주며 문제의 이유를 보여주고 수락·거부하게 해야 한다.

자동 평가 도구는 도구 호출 실패나 노골적인 사용자 불만처럼 명백한 오류를 빠르게 찾는 데 유용하다.

자동 평가는 판매 이의 처리나 문자 메시지의 Markdown 금지처럼 제품 맥락과 취향이 필요한 오류를 자주 놓친다.

최고 수준 자동 평가의 정밀도도 80~90%이므로 재현율과 함께 보고 10~20%의 레드 헤링을 걸러야 한다.

평가를 잘하는 제품은 사람이 데이터에 취향을 주입하고 에이전트가 그 판단을 규모 있게 적용하는 구조를 가진다.