진짜로 LLM 성능 평가해야 할 때 꿀팁 — LinkedIn 포스트
한 줄 요약
AI 에이전트 성능 평가는 표준 지표나 도구부터 만들 게 아니라 실제 실패 트레이스를 직접 열어보고 실패 유형을 분류하는 데서 시작해야 하며, 애매한 점수 대신 Pass/Fail로 명확히 자르고 남의 메트릭이 아닌 우리 제품에서 실제로 터지는 실패 기준의 커스텀 메트릭을 써야 한다는 LinkedIn 포스트(원출처 인포그래픽: Hamel Husain & Shreya Shankar의 “How to Perform Error Analysis”).
출처 메타
- URL: https://lnkd.in/gixXi6ig
- 매체: LinkedIn 포스트(텍스트+인포그래픽 스크린샷)
- 작성자: 미상(재게시자, 스크린샷에 이름 미표시) — 인포그래픽 원출처는 Hamel Husain·Shreya Shankar(ML 엔지니어, productcompass.pm)
- 확인일: 2026-08-14 KST (🪽 헤르메스가 텔레그램 스크린샷에서 발췌 — 유튜브 자막 파이프라인 미해당, 수동 발행)
픽업
- 인프라부터 만들지 마라 — 처음부터 표준 지표나 평가 도구부터 붙잡고 있는 건 시간 낭비다. 반드시 실제 트레이스 100개를 직접 열어보고 실패 유형을 분류하며, 더 이상 새로운 실패 유형이 안 나올 때까지 파고들어야 한다. 노트북으로 20~50개 결과부터 직접 보는 게 최소 실행 가능한 평가이고, 커스텀 툴이나 LLM-as-judge는 에러 분석이 어느 정도 끝난 뒤에 도입해도 늦지 않다.
- Pass/Fail로 딱 잘라야 한다 — 1~5점 같은 애매한 점수는 그만 쓰고 성공/실패 평가만 명확하게 해야 주관성이 줄고 진짜 개선이 가능해진다. 세부 항목이 필요하면 Pass/Fail을 여러 개로 쪼개면 된다.
- 커스텀 메트릭을 써야 한다 — 우리 제품에서 실제로 터지는 실패를 기준으로 평가 기준을 만들어야지, 남의 메트릭으로 우리 제품을 재면 항상 틀린다. 애매한 정보만 알려주는 기성 툴보다 우리 지표에 맞게 추상화된 커스텀 어노테이션 툴을 직접 세팅하는 쪽이 훨씬 빠르다.
- (인포그래픽) “Helpfulness”·“toxicity” 같은 범용 지표는 도메인 특화 실패를 놓치는 경우가 잦다 — 애플리케이션에 특화된 지표가 필요하다.
- (인포그래픽) 에러 분석 4단계 — ①새 트레이스 추가(실사용 또는 합성) ②트레이스를 열어 짧고 서술적인 메모 작성(Open Coding: 문제·특이사항·잘못된 행동 기록) ③비슷한 메모끼리 클러스터링해 실패 유형(failure mode)을 도출(Axial Coding) ④더 많은 트레이스에 그 실패 유형으로 라벨링하고, 정의를 다듬어 merge·split 하며 반복(Re-coding). 새 실패 유형·재코딩 변화가 더 안 나올 때까지(이론적 포화) 이 루프를 돈다.
용어
- 에러 분석 (Error Analysis) [워크플로우 · 문화]: 실제 실행 트레이스를 직접 읽고 실패 유형을 분류해가는, ROI가 가장 높다고 소개된 LLM/AI 엔지니어링 활동.
- 트레이스 (Trace) [컨텍스트 · 캐시]: 파이프라인 실행의 전체 기록 — 사용자 쿼리·입력·추론·툴콜·출력을 포함.
- Open Coding [워크플로우 · 문화]: 트레이스를 읽으며 문제·특이사항·잘못된 행동에 대해 짧고 서술적인 메모를 남기는 1단계 작업.
- Axial Coding [워크플로우 · 문화]: 비슷한 메모들을 클러스터링해 실패 유형(failure mode)을 도출하는 2단계 작업.
- failure mode (실패 유형) [워크플로우 · 문화]: Axial Coding으로 도출되는, 반복되는 오류 카테고리.
- LLM-as-judge [모델 · 구독]: LLM 자신을 평가자로 써서 다른 LLM 출력의 품질을 판정하게 하는 기법. 에러 분석이 어느 정도 끝난 뒤 도입해도 늦지 않다고 언급됨.
- 커스텀 어노테이션 툴 (Custom Annotation Tool) [도구 통신 (MCP · CLI · API)]: 자사 제품의 실제 실패 기준에 맞춰 직접 세팅하는 평가·라벨링 도구. 범용 기성 툴보다 빠르다고 언급됨.