"에이전트 잘 되나요"는 답할 수 없는 질문이다 — 평가 지점 3계층과 메트릭 3계층

"에이전트가 잘 되나요?"라는 질문에는 답할 수 없다. 라우팅이 틀린 것인지, 도구 선택이 틀린 것인지, 근거는 맞았는데 문장이 나쁜 것인지가 구분되지 않은 상태에서 나온 질문이기 때문이다. 답을 만들려면 질문을 쪼개야 한다.

이 글은 그 쪼개기를 두 축으로 한다. 하나는 평가 지점 — 라우팅·도구 호출·최종 답변 셋으로 나누면 "어디가 틀렸나"에 답할 수 있게 된다. 다른 하나는 지표의 수신자 — 엔지니어용 지표만 있으면 품질 대화가 개발팀 안에 갇힌다. 여기에 세 가지 평가 방식(오프라인·온라인·루프)을 언제 쓰는가와, 이 모두를 실제로 세우는 7단계 절차를 붙인다.

앞 편에서 승인 데이터가 회귀 테스트 자산으로 재사용되는 구조를 봤다. 그 자산을 무엇에 쓸 것인가가 이 글의 주제이며, 첫 편의 배팅 우선순위 1위이기도 하다 — 보안·지연·비용이 시장에서 해소되는 동안 품질만 남았기 때문이다.

이 글은 2025년 5월과 7월의 자료를 정리한 것이다. 제품 화면 구성과 기능명은 그 시점의 것이다.

용어 정리

앞 편의 용어표에서 이 글이 쓰는 행만 추리고, 평가 용어를 더했다.

왜 어려운가 — 여섯 가지 이유

여섯 중 앞의 넷은 무엇을 정답으로 볼 것인가의 문제이고, 뒤의 둘은 어디를 볼 것인가의 문제다. 이 글의 전반부가 앞의 넷을, 후반부가 뒤의 둘을 다룬다.

LangSmith가 스스로를 규정한 문구가 이 구분을 정확히 말한다 — "Large, Unstructured, Multi-modal Payloads", "Built for an agent engineer not an SRE".

기존 APM·모니터링 도구와 목적이 다르다는 선언이다. SRE는 서비스가 살아 있는지를 보지만 에이전트 엔지니어는 판단의 품질을 봐야 한다. 응답이 200으로 돌아오면서도 완전히 틀린 답을 담고 있을 수 있다는 것이 이 도메인의 특징이고, 그래서 가용성 지표만으로는 아무것도 알 수 없다.

세 가지 평가 방식

오프라인 평가 — 운영 전, 준비된 데이터셋으로

장단점이 같은 성질의 앞뒷면이다. 통제됐기 때문에 비교가 가능하고, 통제됐기 때문에 현실과 다르다.

온라인 평가 — 실제 트래픽에서

루프 평가 — 실행 중에 즉시

도식의 C → D → B 되돌림이 Agentic RAG의 관련성 검증 루프와 같은 형태라는 점이 눈에 띈다. 자기교정 루프를 "평가"의 한 방식으로 분류하면, 관련성 판정기와 근거성 채점기가 전부 루프 평가기가 된다.

세 방식 비교

이 비교표는 위 세 개별 표의 요약이지 대체가 아니다. 비교표는 각 방식의 결정적 축(소스·시점·장단점 한 줄씩)만 남기므로, 오프라인의 구성요소 넷이나 루프의 장점 셋 같은 것은 여기 없다. 방식을 고를 때는 비교표를, 고른 뒤 실제로 세울 때는 개별 표를 본다.

셋의 관계는 배타가 아니라 순서다 — 오프라인으로 배포 게이트를 만들고, 온라인으로 실패 케이스를 수집하고, 그 케이스를 다시 오프라인 데이터셋에 넣는다. 루프는 되돌릴 수 없는 행위 앞에서만 쓴다. 비용이 가장 크기 때문이다.

무엇을 평가할 것인가 — 지점 3계층

같은 Email Assistant 구조도를 세 번 반복하면서 평가 대상 지점만 바꿔 가며 설명한 것이 이 자료의 백미다.

왜 나누는지는 구조도 아래 붙은 설명 두 줄이 말한다.

한 시스템 안에서 앞단과 뒷단의 평가 방법이 달라야 한다는 것이 이 절의 결론이다.

이 구분이 값을 하는 이유는 앞단을 에이전트로 만들지 않을 근거가 되기 때문이다. 분류 단계를 라우터로 두면 Exact Match로 채점되는 유닛테스트가 성립하고, 같은 자리를 에이전트로 만들면 그 시점부터 궤적 평가밖에 못 한다. 평가 가능성이 아키텍처 선택의 기준이 되는 자리이며, 경로를 누가 정하는가의 판단에 축이 하나 더 붙는 셈이다.

정리하면 "에이전트가 잘 되나요"는 라우팅 정확도 / 도구 선택 정확도 / 최종 답변 품질 셋으로 쪼개야 답이 되고, 쪼개야 개선 지점이 특정된다.

정형과 비정형은 채점기가 다르다

비정형 평가에서 레퍼런스는 "정답 문장"이 아니라 성공 기준(Success Criteria)이다.

두 번째 행이 이 표의 전부다. 문장을 맞히라고 하면 평가가 불가능해진다 — 같은 뜻의 이메일을 쓰는 방법이 수십 가지이고 그중 하나만 정답이 될 이유가 없다. 조건을 만족했는지 묻는 순간 평가가 가능해지고, 마지막 행처럼 결과가 두 방식 모두 true / false로 떨어진다. 채점기는 달라도 출력 계약은 같게 유지한다는 설계다.

누가 볼 것인가 — 메트릭 3계층

두 표는 행 수가 같지만 세는 단위가 다르다. 위는 계층당 지표 셋을 나열하고, 아래는 계층당 수신자와 질문을 적는다. 위만 보면 아홉 개 지표 목록이고, 아래만 보면 지표 이름이 사라진다.

이 3계층은 지표 분류가 아니라 조직 확장 장치다.

Traditional만 있으면 품질 대화가 개발팀 안에 갇힌다. Business Metrics 행(Cost / User Feedback / Topic Summarization)이 생기는 순간 PM·CS·재무가 같은 대시보드를 보게 되고, 이때부터 "이 기능이 개선됐다"는 주장이 개발팀 밖에서 검증 가능해진다. 자료가 이 표에 "개발자 1인의 온전한 책임이 아닌 팀으로의 확장"이라는 부제를 붙인 이유가 여기 있다.

무엇을 추적하는가

세 화면을 질문 쪽에서 다시 세우면 이렇게 된다.

두 표는 행 수가 셋으로 같지만 열 축이 다르다. 위 표는 화면에서 출발해 무엇이 보이는지를 적고, 아래 표는 질문에서 출발해 어느 화면으로 가는지를 적는다. 하나로 합치려면 네 열(질문·관측 대상·화면 이름·보는 것)짜리 단일 표가 되어야 하는데, 그러면 질문 열이 나머지 셋에 종속된 것처럼 보인다. 실무에서는 대개 질문이 먼저 오므로 두 방향을 따로 두는 편이 쓰기 낫다.

셋 중 마지막이 성격이 다르다는 점도 짚어 둘 만하다. 앞의 둘은 운영 중인 시스템을 보는 것이고, Comparing Tests는 바꾸기 전과 후를 보는 것이다. 관측과 평가가 만나는 자리가 여기다.

프롬프트 버저닝

프롬프트를 코드 리포지터리 안 문자열로 두면 셋이 동시에 막힌다 — ① 변경 이력이 커밋에 섞여 추적이 어렵고 ② 비개발자가 손댈 수 없고 ③ 어떤 버전이 어떤 실험 결과를 냈는지 연결되지 않는다. 허브로 빼면 이 셋이 함께 풀린다. 특히 ③은 위 Comparing Tests가 성립하기 위한 전제라, 버저닝 없이 실험 비교를 하면 무엇을 비교한 것인지 나중에 알 수 없다.

도입 절차 7단계

원 자료는 절차를 한 장으로 정리해 두지 않았다. 아래는 위 요소들을 도입 순서로 재구성한 것이다.

도식은 노드 일곱인데 표는 여덟 행이다. 마지막 행(7 → 4 회귀)이 도식에서는 화살표 하나라 노드로 세어지지 않기 때문인데, 그 화살표가 이 절차의 요점이다. 7단계를 한 번 완주하는 것은 프로젝트지만, 4번으로 돌아오는 화살표가 있어야 체계가 된다.

세 번째 열도 눈여겨볼 만하다. 완료 판정이 전부 "무엇에 답할 수 있게 되는가"로 쓰여 있고 산출물 이름이 아니다. 대시보드를 만든 것과 비개발자가 그것을 해석할 수 있는 것은 다른 사건이다.

현장의 고민 — 완벽주의가 착수를 늦춘다

20분짜리 거친 평가라도 먼저 돌리는 것이 완벽한 지표를 설계하는 것보다 낫다.

이유는 위 7단계의 순서에 이미 들어 있다. 데이터셋 구축(4번)이 온라인 평가(6번)보다 먼저 오지만, 처음에 만드는 데이터셋은 어차피 틀린다 — 실제 사용자가 무엇을 묻는지 모르는 상태에서 만들었기 때문이다. 그 오차를 없애려고 4번에 오래 머무는 것이 과잉 투자이고, 6번을 돌려 실패 케이스를 회수하는 편이 빠르다. 평가 체계는 설계하는 것이 아니라 수렴시키는 것이라는 뜻이다.

여섯 번째 행의 "새 과제"는 아직 열려 있다. 도구가 표준 프로토콜로 붙기 시작하면서 도구 선택 자체가 평가 대상이 됐는데, 그 표준이 만든 다른 변화들은 다음 편의 주제다.

여기까지가 품질을 재는 체계다. 지점을 셋으로 쪼개고, 방식을 셋으로 나누고, 지표를 셋으로 층지어 개발팀 밖으로 내보낸다.

그런데 위 마지막 표의 여섯 번째 행이 새 문제를 열어 둔 채 끝난다 — 도구를 표준 프로토콜로 붙이기 시작하면 도구 선택 정확도가 새 평가 대상이 되고, 동시에 접근 제어라는 전혀 다른 문제가 따라온다. 사내 지식베이스를 프로토콜로 여는 순간 검색 품질보다 권한이 먼저가 된다. 다음 편에서 MCP가 실제로 바꾼 것과, 벡터스토어를 애플리케이션 밖으로 떼어 내는 재편을 다룬다.