다들 평가(evals)에만 집착하는데, 추적(traces)은 아무도 안 보네.
핵심 요약
AI 시스템의 문제 해결을 위해 결과값만 보는 평가보다는 실행 과정을 추적하는 관측 가능성(observability)이 더 중요하다는 의견입니다.
- 평가의 한계 — 결과값만 확인해서는 디버깅에 필요한 맥락을 파악하기 어려움
- 관측 가능성 부족 — 기존 마이크로서비스용 도구는 AI의 복잡한 실행 흐름을 담아내지 못함
- 의미론적 계층 필요 — AI 고유의 실행 흐름을 이해하는 추적 시스템이 필수적임
- 오픈소스 프로젝트 — GenAI 워크로드에 특화된 추적 도구인 Monocle을 대안으로 제시함
평가(evals)는 당신의 에이전트가 실패했다는 사실만 알려줍니다.
추적(traces)은 그 이유를 알려주죠. 현재 AI 도구 생태계는 평가에만 집착하고 있습니다. 벤치마크, LLM-as-judge, 레드 티밍, 회귀 테스트 스위트 같은 것들 말이죠. 모두 가치 있는 것들입니다. 하지만 평가는 결과만 봅니다. 잘못된 출력물을 보고 있을 때쯤이면, 이미 디버깅에 필요한 맥락의 대부분은 사라진 상태입니다.
RAG 답변이 잘못된 경우를 예로 들어보죠. 문제는 보통 평가 스위트가 뭔가를 놓친 게 아닙니다. 검색기가 관련성 낮은 청크 3개를 가져왔거나, 리랭커(reranker)가 상황을 더 악화시켰거나, 프롬프트가 토큰 제한에 걸려 맥락의 절반을 조용히 날려버린 게 문제죠.
이건 평가의 문제가 아니라 관측 가능성(observability)의 문제입니다.
문제는 기존의 관측 가능성 도구들이 AI 시스템을 위해 만들어지지 않았다는 점입니다. 프레임워크 홉, 검색 파이프라인, 도구 호출, 에이전트 핸드오프, 메모리 조회, 프롬프트 변환, 모델 호출 등은 마이크로서비스용 추적 방식으로는 깔끔하게 매핑되지 않습니다.
지금 부족한 것은 AI 고유의 실행 흐름을 일반적인 스팬(span)으로 취급하지 않고 이해할 수 있는 의미론적 계층(semantic layer)입니다.
제가 지켜보고 있는 프로젝트 중 하나는 Monocle입니다. 요청 체인을 시각화하는 수준을 넘어, GenAI 워크로드에 의미 있는 추적을 제공하는 데 집중하는 몇 안 되는 오픈소스 프로젝트 중 하나입니다.
