"Evaluation & Operations — 측정 가능해야 개선 가능하다 (하네스 시리즈 6/6)"
← Multi-Provider Routing — 어느 모델에게… 📚 시리즈 목차 (시리즈 끝) 시리즈를 종합하는 마지막 글 . 컨텍스트(2)·메모리(3)·도구(4)·라우팅(5)을 다 잘 만들었는데, 작동 중인지 어떻게 아는가? 답은 측정. 측정 못하면 개선도 못한다. 이 글은 LLM 에이전트의 Evaluation (품질 측정)과 Operations (운영) 영역을 다룬다. 시리즈 1~5에서 다룬 모든 컴포넌트를 지속적으로 검증 하는 마지막 레이어. 시리즈 (6편 완결) 하네스 엔지니어링이란 Context Engineering Memory Systems Tools & Sandboxing Multi-Provider Routing Evaluation & Operations ← 이 글 (최종) 1. 왜 Evaluation이 따로 필요한가 일반 소프트웨어와 다르다 단위 테스트 통과 ≠ 사용자가 만족 동일 입력 다른 출력 (비결정적) "정답"이 항상 명확하지 않음 (창작·요약·코드 리팩터) 모델 변경 시 모든 동작 이 미세 변화 에이전트는 연속적 으로 검증해야 한다 새 모델 출시 → 라우팅 정책 영향 시스템 프롬프트 수정 → 회귀 가능성 새 도구 추가 → 기존 작업 변화 메모리 누적 → 답변 변동 결론: Eval은 한 번 하는 것이 아니라 상시 돌리는 인프라. 2. Eval 종류 2-1. Automatic Metrics (정량) BLEU, ROUGE (번역·요약, 한계 많음) Code execution: 코드가 실행 되는가, 테스트 통과하는가 Schema validation: JSON 출력이 schema 맞는가 Length, latency, cost (자동 추적) 2-2. LLM-as-Judge (모델로 평가) 더 큰 모델(Opus 4.7)이 작은 모델 출력을 평가 Rubric 기반 채점 (0~10 점) 한계: 같은 모델이 평가자·생성자면 s...