Forward Deployed Engineer 로드맵

8. 평가와 관측성: 고객에게 가치 증명하기

AI 시스템이 쓸 만하다는 말은 점수와 기록으로 증명될 때만 고객에게 닿습니다. 평가는 얼마나 좋은지를 재고, 관측성은 무슨 일이 있었는지를 남기며, FDE는 이 둘로 "이 시스템이 가치가 있다"를 근거와 함께 말합니다.

학습 동기: 이 장을 읽으면 고객이 내민 벤치마크 점수나 "잘 되는 것 같다"는 인상을 의심할 수 있고, 평가 방법을 작업에 맞게 고르며, 에이전트가 틀렸을 때 어느 단계에서 틀렸는지 기록으로 찾는 방법을 설명할 수 있습니다.
선행 가정: 정밀도와 재현율(1.8.2, 1.8.3), 임베딩(1.4.4), 환각(2.18), 에이전트의 구성(6.1)을 알고 있다고 가정합니다. 에이전트를 단계 그래프로 설계하는 방식(7.3)과 프롬프트 인젝션(9.2)은 사례에서 짧게 언급되므로, 낯설면 해당 절을 먼저 훑어 보십시오.

8.1 LLM 평가(LLM Evaluation)

원문: What is LLM Evaluation? Metrics, Benchmarks, and Methods Explained

고객이 "이 챗봇이 좋은가요?"라고 물을 때 "좋아 보입니다"는 답이 되지 못합니다. LLM 평가는 모델의 출력이 정확하고 유용하며 안전한지를 숫자와 근거로 보여 주는 절차이며, 이 절은 그 도구 상자 전체를 펼칩니다. 이하 내용은 2026년 5월 글 기준입니다.

8.1.1 평가 유형

LLM 평가(LLM Evaluation)는 모델에 입력을 주고 출력을 관찰하여, 우리가 기대한 작업을 얼마나 잘 해내는지 재는 과정입니다. 챗봇을 만들었다면 정답을 말하는지, 공손한지, 안전한지, 지난주 버전보다 나은지를 모두 이 과정으로 답합니다. LLM은 사실이 아닌 내용을 자신 있게 말하는 환각(2.18 참조)과 유해하거나 편향된 출력을 낼 수 있으므로, 출시 전에 거동을 알아야 하고 출시 후에도 품질이 떨어지지 않는지 계속 확인해야 합니다.

평가가 필요한 이유는 여섯 가지로 나뉩니다.

평가 방법은 크게 네 가지입니다.

유형 방식 한 줄 요약
자동 지표(Automatic Metrics) 수식으로 출력을 기준 답과 비교해 점수화 빠르고 싸지만 표면 비교
벤치마크(Benchmarks) 모두가 쓰는 표준 데이터셋으로 시험 모델 간 비교에 적합
사람 평가(Human Evaluation) 사람이 읽고 등급을 매김 가장 정확하지만 느리고 비쌈
LLM 판정(LLM as a Judge) 다른 LLM이 점수를 매김 사람 대신 규모를 확보 (8.2 참조)

이 네 가지에 더해 작업별 평가(Task-Specific Evaluation)와 안전 평가(Safety Evaluation)가 있습니다. 둘은 별도 방법이 아니라 위 네 방법을 재사용하되 무엇을 시험할지를 정하는 층입니다(8.1.6 참조). 실제 프로젝트에서는 한 가지만 쓰지 않고 조합하며, 평가 없이 출시하는 것은 실사용자가 달린 제품에서 추측에 의존하는 일입니다.

FDE는 첫 미팅에서 "무엇을 좋다고 부를 것인가"를 고객과 합의해야 합니다. 이 합의가 어느 평가 유형을 주력으로 삼을지 정합니다.

8.1.2 자동 지표(Automatic Metrics)

자동 지표는 모델 출력과 사람이 써 둔 기준 답(reference)을 수식으로 비교하여 점수를 내는 방법입니다. 영어 문장을 프랑스어로 번역시키고, 사람이 번역한 정답과 모델 번역이 얼마나 가까운지 재는 장면이 전형적입니다. 주요 지표는 다음과 같습니다.

지표 무엇을 보는가 주 용도
BLEU 모델 출력의 n-gram(작은 단어 묶음) 중 기준 답에도 나오는 비율, 정밀도 기반 번역
ROUGE 기준 요약의 n-gram 중 모델 요약이 포함한 비율 요약
BERTScore 문맥 임베딩으로 의미 유사도 비교 표현이 다양한 작업
METEOR BLEU에 동의어, 어간, 어순 처리를 더한 것 표면 일치와 의미 일치의 중간
퍼플렉시티(Perplexity) 모델이 실제 다음 토큰에 부여하는 확률, 낮을수록 좋음 학습 중 진행 추적 (2.14 참조)
완전 일치(Exact Match) 출력이 기준 답과 같으면 1, 아니면 0 수학 문제, 짧은 사실 질문

BLEU와 BERTScore의 차이는 예문으로 확인됩니다. 기준 답이 "The cat sat on the mat"이고 모델이 똑같이 출력하면 BLEU는 높습니다. 모델이 "A feline rested on the rug"라고 하면 뜻은 같아도 BLEU가 낮습니다. 단어 하나씩(1-gram) 세어 보면 모델 출력 6단어 중 기준 답에 나오는 것은 on, the 두 개뿐이므로 1-gram 정밀도는 2/6 ≈ 0.33이고, 두 단어 묶음(2-gram)은 5개 중 on the 하나만 일치하여 0.20입니다. 실제 BLEU는 여러 n-gram 정밀도를 결합하므로 이 값은 직관을 위한 계산입니다. 반면 BERTScore는 임베딩(1.4.4 참조)으로 의미를 비교하므로 같은 쌍에서 높은 점수를 줍니다.

장점과 한계는 분명합니다.

원문은 현대 LLM 평가에서 BLEU와 ROUGE 같은 기준 답 기반 지표가 주로 연구 논문과 번역 파이프라인에서 쓰이며, 운영 중인 LLM 애플리케이션은 LLM 판정이나 작업별 평가에 의존한다고 밝힙니다. 고객 팀이 BLEU 점수를 보고서에 올려 왔다면, 그 작업이 정답 문장이 하나로 정해지는 작업인지부터 물어야 합니다.

8.1.3 벤치마크

벤치마크는 연구 커뮤니티 전체가 모델 시험에 쓰는 표준 데이터셋입니다. 새 모델이 나오면 개발사가 유명 벤치마크 점수를 공개하므로, 같은 시험지 위에서 모델끼리 공정하게 비교할 수 있습니다. 벤치마크마다 시험하는 능력이 다르므로 범주별로 알아 둡니다.

범주 벤치마크 시험 내용
일반 지식 MMLU 역사, 법, 수학, 의학 등 57개 과목의 객관식
일반 지식 MMLU-Pro 보기 10개와 사고의 연쇄 추론(4.1 참조)을 요구하는 더 어려운 판
상식 추론 HellaSwag 짧은 이야기의 가장 그럴듯한 결말 고르기
코딩 HumanEval 간단한 함수 작성
코딩 SWE-bench Verified 오픈소스 프로젝트의 실제 GitHub 이슈 해결
코딩 LiveCodeBench 모델 학습 시점 이후 공개된 문제를 써서 오염에 강함
수학 GSM8K, MATH, AIME 초등 수준 문장제, 경시 수준, 올림피아드 문제
최전선 추론 GPQA-Diamond 박사 수준 과학 문제
최전선 추론 Humanity's Last Exam(HLE) 여러 분야 전문가 수준 2,500문항(공개 세트)
지시 따르기 IFEval "정확히 세 개의 불릿으로 답하라" 같은 검증 가능한 제약
도구 사용 BFCL(Berkeley Function-Calling Leaderboard) 도구와 함수 호출 능력, 에이전트에 직결 (6.2 참조)
긴 컨텍스트 RULER 모델이 주장하는 명목 길이보다 정직한 유효 컨텍스트 윈도우 측정
진실성 TruthfulQA 흔한 거짓 믿음을 따라 하지 않고 사실을 답하는지
대화 품질 Chatbot Arena(LMArena) 실사용자가 익명 모델 둘을 비교해 고르고, 체스의 Elo와 같은 계열의 점수로 순위를 매김

벤치마크 점수를 읽을 때 알아야 할 세 가지 개념이 있습니다.

그림 8.1.3 — 시험 문제를 미리 본 모델의 높은 점수는 실력이 아니라 기억일 수 있습니다.
그림 8.1.3 — 시험 문제를 미리 본 모델의 높은 점수는 실력이 아니라 기억일 수 있습니다.

장점은 같은 데이터셋이라 비교가 쉽고 넓은 능력을 덮으며 커뮤니티의 뒷받침이 있다는 점입니다. 한계는 높은 점수가 우리 용도에서의 성능을 보장하지 않으며, 포화나 오염 또는 둘 다로 점수가 오도할 수 있고, 공개 벤치마크가 우리 제품의 정확한 작업과 거의 일치하지 않는다는 점입니다. 고객이 "벤치마크 1위 모델이니 도입하자"고 하면 그 벤치마크가 고객 업무와 닮았는지, 오염되었는지를 되묻고, 고객 데이터로 만든 작은 평가 세트를 제안합니다.

8.1.4 사람 평가

사람 평가는 실제 사람이 출력을 읽고 점수를 매기는 방법이며 여전히 최종 기준(gold standard)입니다. 어조, 유용성, 창의성, 안전성은 수식으로 잴 수 없습니다. 짧은 시를 쓰게 했을 때 정답은 하나가 아니고, 좋은 시인지 판단하는 것은 사람입니다. 대표 방식은 세 가지입니다.

장점은 의미, 어조, 품질을 판단하고 정답이 하나가 아닌 작업에 통하며 실패 지점에 대한 깊은 통찰을 준다는 점입니다. 한계는 느리고 비싸며, 같은 출력에도 사람마다 점수가 다르고, 수천 수백만 건으로 확장할 수 없다는 점입니다. 쌍대 비교는 점수를 매기는 데만 쓰이지 않고 사람의 순위를 보상 모델로 바꾸어 모델을 학습시키는 데도 쓰입니다(11.6 참조).

그래서 사람을 대체하는 도구가 LLM 판정(LLM as a Judge)입니다. 강력한 LLM에 입력과 출력을 주고 "도움이 되고 공손한가를 1~5점으로 평가하고 이유를 짧게 적어라"라고 요청하면 점수와 이유가 나오며, 이를 사람 점수처럼 쓸 수 있습니다. 사람보다 훨씬 싸고 빠르며 수백만 건에 확장되고 수식이 실패하는 개방형 작업에도 통용됩니다. 대신 판정 모델에도 편향이 있습니다.

판정자도 틀릴 수 있으므로 작은 표본에서 판정 점수를 사람 점수와 비교하여 검증해야 합니다. 판정자의 구축 절차와 편향 대응은 별도 절로 분리되어 있습니다(8.2 참조). FDE는 사람 평가를 모든 건에 쓰지 않고, 판정자를 검증하는 기준 표본과 출시 직전 최종 점검에 쓰는 구조로 설계합니다.

8.1.5 평가의 도전 과제

LLM 평가가 어려운 이유는 여섯 가지입니다.

도전 과제 내용 예
개방형 출력 정답이 하나가 아니라 수식이 잘 맞지 않음 좋은 이메일 답장을 쓰는 방법은 수천 가지
데이터 오염 모델이 시험 데이터를 학습 중 봄 벤치마크 점수가 부풀려짐 (8.1.3 참조)
비용 사람 평가도, 큰 평가 세트를 강력한 LLM에 돌리는 일도 비쌈 평가 예산이 빠르게 소진
판정자의 편향 판정이 실사용자와 다른 선호를 가짐 긴 답, 자기 계열 답을 선호
시간에 따른 표류(Drift) 파인튜닝, 프롬프트 수정, 심지어 제공사의 서버 측 모델 갱신으로도 행동이 바뀜 출시 전 점수가 석 달 뒤에는 맞지 않음
극단 사례(Edge cases) 평균은 좋아도 드물지만 중요한 경우에 크게 실패 평가 세트에 따로 추가해야 함

특히 표류 때문에 평가는 출시 전 한 번으로 끝나지 않습니다. 프롬프트, 모델, 시스템을 바꿀 때마다 평가를 돌리고 결과를 저장하여 추세를 봐야 합니다. 이 도전 과제에 대응하는 모범 사례는 일곱 가지입니다.

고객 현장에서는 "마지막으로 평가를 돌린 것이 언제입니까"가 첫 질문입니다. 석 달 전 점수만 있다면 제공사 측 모델 갱신을 반영하지 못한 수치입니다.

8.1.6 상황별 방법 선택

네 방법의 특성은 다음과 같이 비교됩니다.

방법 속도 비용 판정 품질 적합한 용도
자동 지표 가장 빠름 가장 낮음 낮음 번역, 요약, 정답이 정해진 작업
벤치마크 빠름 낮음 중간 연구 수준의 모델 비교
사람 평가 가장 느림 가장 높음 가장 높음 최종 품질 점검, 개방형 작업
LLM 판정 빠름 중간 높음 대화, RAG, 에이전트 평가의 규모 확장

실제 제품에서는 넷을 모두 조합합니다. 학습 중에는 자동 지표, 모델 선택에는 벤치마크, 일상 모니터링에는 LLM 판정, 출시 직전에는 사람 평가를 씁니다.

flowchart LR
    A[학습: 자동 지표] --> B[모델 선택: 벤치마크]
    B --> C[일상 모니터링: LLM 판정]
    C --> D[출시 직전: 사람 평가]

그림 8.1.6 — 개발 단계에 따라 평가 방법을 바꾸어 쓰는 순서.

작업별 평가는 이 표 위에 얹히는 층입니다. 내부적으로는 자동 지표나 LLM 판정을 쓰지만, 던지는 질문, 시험 입력, 채점 대상을 우리 작업에 맞게 정합니다. 일반 벤치마크는 평균적 성능을 알려 줄 뿐이고 실제 제품에는 구체적 작업이 있기 때문입니다.

안전 평가와 레드팀(Red-Teaming)은 적대적이고 유해한 입력으로 모델을 시험하는 별도 범주입니다. 탈옥(9.3 참조), 프롬프트 인젝션(9.2 참조), 유해 요청을 시도하여 모델이 올바르게 거절하는지, 민감 정보를 누설하지 않는지, 민감 주제에서 편향을 보이지 않는지 확인합니다. 입력과 출력에서 이 검사를 강제하는 방법은 가드레일입니다(9.1 참조). 널리 알려진 안전 벤치마크는 유해하고 적대적인 요청에 대한 행동을 보는 HarmBench, 모델 공격용 적대 프롬프트 표준 세트인 AdvBench, 진실성, 안전, 공정성, 견고성, 프라이버시, 윤리를 아우르는 TrustLLM입니다. 새로운 공격 패턴이 계속 나오므로 운영 환경에서는 실제 트래픽에 대한 안전 모니터링을 계속 돌립니다.

FDE가 방법을 고를 때는 작업의 성격으로 시작합니다. 정답이 하나로 정해지면 자동 지표와 완전 일치, 개방형이면 검증된 LLM 판정과 사람 표본, 외부 행동을 하는 에이전트라면 안전 평가를 반드시 추가합니다. 마지막으로 품질만 보지 않고 응답 속도와 호출당 비용을 함께 기록하도록 고객에게 요청합니다.

8.2 LLM-as-a-Judge

원문: What is LLM as a Judge? How to Use an LLM to Evaluate LLM Outputs

사람 평가는 정확하지만 확장되지 않고, 수식 지표는 확장되지만 의미를 놓칩니다. LLM-as-a-Judge는 그 사이의 공백을 메우는 기법이며, 8.1에서 한 줄로 소개한 LLM 판정을 구축 절차, 프롬프트, 편향까지 내려가서 다룹니다. 이하 내용은 2026년 5월 글 기준입니다.

8.2.1 동작 방식과 유형

LLM-as-a-Judge는 한 LLM이 다른 LLM의 출력을 읽고, 우리가 정한 기준에 비추어 점수나 판정을 이유와 함께 내놓는 기법입니다. 숙제를 채점하는 교사에 비유하면 학생이 평가 대상 LLM이고, 교사가 기대 답과 비교하여 등급과 피드백을 주는 판정자 역할의 LLM입니다.

이 기법이 필요한 이유는 기존 방법 둘이 각자 한계를 가졌기 때문입니다. LLM 출력은 개방형 텍스트라서 정답이 하나가 아니고, 서로 다른 두 답이 모두 맞을 수 있습니다.

접근 장점 문제
사람 평가 언어를 이해하므로 품질이 높음 느리고 비싸며 지치고, 하루 수백만 건을 못 봄
BLEU, ROUGE 같은 규칙 기반 지표 빠르고 쌈 단어 겹침만 봄. 같은 뜻을 다른 단어로 쓴 정답에 낮은 점수를 줌
LLM-as-a-Judge 의미를 이해하고, 단어가 달라도 비교하며, 하루 수백만 건을 처리 판정자 자체의 편향 (8.2.4 참조)

원문은 강한 LLM 판정자가 사람 평가자와 80% 넘게 일치하며 이는 두 사람이 같은 작업에서 서로 일치하는 비율과 비슷하다는 연구 결과를 전합니다. 잘 만든 판정자는 사람만큼 믿을 만하면서 훨씬 빠르고 싸므로 LLM 애플리케이션 평가의 기본 방식이 되었습니다. 다만 이 수치는 연구 환경의 일반론이며 우리 작업에서의 일치율은 직접 재야 합니다(8.2.2 참조). 더 근본적인 질문은 그 작업에 정확한 검사기가 있는가이며, 정의가 불분명한 작업은 판정자도 기준을 잡지 못합니다.

동작은 다섯 단계입니다. 고객 지원 챗봇의 예로 보겠습니다.

  1. 사용자 질문과 챗봇 답변을 가져옵니다.
  2. 판정 LLM에 줄 프롬프트를 씁니다. 질문, 답변, 판정 규칙이 들어갑니다.
  3. 이 프롬프트를 판정 LLM에 보냅니다.
  4. 판정 LLM이 읽고 점수와 이유를 냅니다.
  5. 점수로 챗봇이 잘하고 있는지 판단합니다.

"비밀번호를 어떻게 재설정하나요?"라는 질문에 "로그인 페이지의 비밀번호 찾기 링크를 누르고 이메일 주소를 입력하면 재설정 링크가 메일로 옵니다"라는 답변을 주고 "도움됨 기준 1~5점과 이유를 달라"고 하면, 판정자는 "5점: 명확하고 단계별이며 질문에 직접 답합니다"처럼 응답합니다. 실제 시스템에서 판정자는 더 큰 흐름 안의 한 단계로 놓이며, 낮은 점수가 나오면 작업을 되돌려 다시 시도하게 연결됩니다(7.3 참조).

판정 방식은 네 유형이 있습니다.

FDE는 고객의 질문이 "어느 버전이 낫나"이면 쌍대 비교, "시간에 따라 떨어지나"이면 단일 채점, "무엇이 문제인가"이면 루브릭을 고릅니다.

8.2.2 Judge 구축 단계와 프롬프트 템플릿

판정자는 일곱 단계로 만듭니다.

단계 할 일 핵심
1. 기준 정의 평가할 것을 쉬운 말로 적음 지원 챗봇이라면 정확한가, 명확한가, 공손한가
2. 판정 모델 선택 강한 모델을 고름 평가 대상 이상의 능력이 필요함. 아니면 실수를 놓침
3. 판정 프롬프트 작성 작업 설명, 사용자 입력, 평가할 출력, 척도와 규칙, 출력 형식을 포함 아래 템플릿 참조
4. 표본에 실행 작은 표본에 돌려 점수와 이유를 읽음 판정이 제 역할을 하는지 점검
5. 사람 평점과 비교 같은 표본을 사람이 채점하여 대조 근접하면 좋은 판정자, 아니면 프롬프트 개선
6. 반복 개선 규칙 추가, 더 좋은 예시 제공, 재시험 판정 평점이 사람 평점과 맞을 때까지
7. 대규모 사용 신뢰가 쌓이면 수천 수백만 건에 사용 모델, 프롬프트, 버전 비교에도 활용

원문 시점(2026년 5월)의 판정 모델 예로 GPT-5, Claude Opus 4.7, Gemini 3.1 Pro가 거론됩니다. 모델명은 빠르게 바뀌므로 "평가 대상보다 약하지 않은 모델"이라는 원칙이 본질입니다. 데이터를 폐쇄형 API에 보내고 싶지 않다면 오픈소스 판정 모델을 검토할 수 있습니다.

완성된 프롬프트 템플릿은 다음 요소로 이루어집니다.

당신은 전문 평가자입니다. AI 어시스턴트가 사용자 질문에 준 응답을 평가하십시오.
평가 기준: 1. 정확성(사실과 맞는가) 2. 유용성(문제를 해결하는가) 3. 명확성(이해하기 쉬운가)

사용자 질문: {user_question}
어시스턴트 응답: {assistant_response}

형식: 정확성 점수(1-5), 유용성 점수(1-5), 명확성 점수(1-5), 종합 점수(1-5), 이유(짧은 설명)
공정하고 일관되게 평가하고, 위 응답만 근거로 점수를 매기십시오.

이 템플릿이 신뢰도를 주는 이유는 판정자가 과제, 기준, 입력, 출력 형식을 모두 알기 때문입니다. 판정자를 만들 때 FDE가 가장 먼저 하는 일은 고객이 무엇을 좋은 답으로 부르는지 문장으로 받아 적는 것(1단계)이며, 5단계의 사람 평점은 고객 현업 담당자가 맡아야 합니다.

8.2.3 G-Eval: 사고의 연쇄 판정

기본 프롬프트도 작동하지만 판정자에게 먼저 생각하고 나중에 점수를 내라고 하면 더 좋아집니다. 이 기법이 사고의 연쇄 판정(chain-of-thought judging)이며 G-Eval이라고도 합니다. G-Eval은 평가 단계를 생성한 뒤 점수를 매기는 것(Generate evaluation steps + Score)입니다.

바로 점수를 요구하면 판정자는 깊이 생각하지 않고 숫자를 고르므로 점수가 얕아집니다. 먼저 평가 단계를 쓰게 하면 판정자는 천천히 답을 읽고 단계를 하나씩 적용하여 최종 점수가 훨씬 믿을 만해집니다. 이는 사고의 연쇄 프롬프팅(4.1 참조)을 평가에 적용한 것입니다. G-Eval 형식의 프롬프트는 이렇게 구성됩니다.

기준: 유용성
1단계: 응답이 유용한지 확인할 평가 단계를 직접 적어라.
2단계: 각 단계를 응답에 하나씩 적용하고 단계마다 근거를 적어라.
3단계: 그 근거를 바탕으로 1~5점의 최종 점수를 내라.
(사용자 질문과 어시스턴트 응답을 아래에 첨부)

원문은 G-Eval이 기본 채점 프롬프트보다 사람 평점과 훨씬 잘 일치한다고 주장하므로, 신뢰할 수 있는 판정자를 원하면 사고의 연쇄 판정을 쓰라고 권합니다. 일치 정도는 모델과 작업에 따라 다르므로 8.2.2의 5단계로 직접 확인합니다. 지연과 토큰 비용이 늘어나는 점은 일상 모니터링의 호출량과 함께 따져야 합니다.

8.2.4 Judge의 편향

판정자는 강력하지만 완벽하지 않으며 신뢰하기 전에 편향을 알아야 합니다. 원문이 꼽는 편향은 일곱 가지입니다.

편향 증상 대응
스타일 편향(Style bias) 불릿을 문단보다, 격식체를 구어체보다 선호. 원문은 가장 지배적인 편향이라고 설명하며(외부 출처로는 확인하지 못했습니다) 실제 품질을 압도할 수 있음 프롬프트에 기대하는 스타일을 명시
위치 편향(Position bias) A와 B 중 먼저 나온 답을 선호 순서를 바꾸어 두 번 돌리고 평균
장황함 편향(Verbosity bias) 짧은 답이 나아도 긴 답을 선호 프롬프트에서 긴 답을 선호하지 말라고 지시
자기 선호 편향(Self-preference bias) 자신이나 같은 계열 모델이 만든 답에 높은 점수 다른 계열 모델을 판정자로 쓰거나 서로 다른 계열의 판정단(Panel of Judges) 사용
선호 누출(Preference leakage) 파이프라인 전체의 평가 오염 판정 모델 계열을 학습 데이터 생성 계열과 분리
권위 편향(Authority bias) 자신감 있고 전문가나 출처를 인용하는 답에 높은 점수 어조나 자신감이 아닌 정확성만 보라고 상기
군중 편향(Bandwagon bias) 앞선 답들이 동의하면 따라감 같은 방식으로 정확성에만 집중하게 지시
그림 8.2.4 — 판정자의 저울은 내용보다 길이와 문체 쪽으로 기울 수 있습니다.
그림 8.2.4 — 판정자의 저울은 내용보다 길이와 문체 쪽으로 기울 수 있습니다.

위치 편향의 대응은 구체적입니다. 판정자가 (A, B) 순서에서 A를 고르고 순서를 바꾼 (B, A)에서는 B를 고른다면 두 결과가 갈리므로 내용이 아니라 자리를 보고 고른 신호이며, 두 번의 결과를 평균하면 이 영향이 상쇄됩니다.

선호 누출은 단일 답변이 아니라 파이프라인 수준에서 작동합니다. 자기 선호 편향이 메커니즘이고, 선호 누출은 그 메커니즘이 평가 체계 전체를 오염시키는 현상입니다. 예를 들어 GPT-5로 합성 학습 데이터를 만들어 모델을 학습시킨 뒤 같은 GPT-5로 그 모델을 평가한다고 해 봅시다. 학습 데이터가 이미 모델을 GPT-5 문체 쪽으로 밀었으므로, 판정자는 GPT-5 문체와 닮은 답을 조용히 보상합니다. 점수는 문서상 훌륭해 보이지만 실사용자 앞에서는 점수만큼 성능이 나오지 않습니다. 데이터 생성자와 판정자가 더 이상 독립이 아니기 때문입니다. 판정 모델 계열은 학습 데이터, 프롬프트 등 파이프라인에 닿는 모든 입력을 만든 계열과 달라야 합니다.

자기 선호 편향에서 판정자는 자기 머릿속에서는 공정하게 비교한다고 믿지만 자기 문체에 대한 숨은 선호를 가집니다. 원문은 최전선 판정 모델조차 편향이 강한 과제에서 여전히 실패한다고 경고하므로, 운영에 투입하기 전에 이 편향들에 대해 판정자를 시험해야 합니다. FDE는 고객이 "생성도 평가도 같은 벤더 모델로 하겠다"고 할 때 선호 누출의 위험을 설명하고 계열 분리를 요구합니다.

8.2.5 모범 사례

판정자를 믿을 만하게 쓰기 위한 아홉 가지 원칙이 있습니다.

실제 활용 사례는 여섯 가지입니다.

사례 내용
모델 평가 학습이나 파인튜닝(11.1 참조) 후 새 버전이 옛 버전보다 나은지 출력을 나란히 비교
챗봇 품질 모니터링 모든 대화를 읽을 수 없으므로 자동 채점하고 일일 리포트를 받음
콘텐츠 검열 출력이 유해한지 판정하고 사용자에게 가기 전에 차단. 출력 가드레일의 작동 방식 그대로임 (9.1 참조)
RAG 평가 답이 검색된 문서에 근거하는지 확인하여 환각 포착 (5.14 참조)
프롬프트 엔지니어링 같은 작업에 여러 프롬프트를 규모 있게 비교
에이전트 궤적 평가 에이전트가 도구를 선택하고 결과를 읽고 계획하는 전체 단계(궤적)를 읽고 도구 선택, 사용, 결과를 판정. 다른 방법으로는 평가하기 어려워서 가장 빠르게 늘어나는 활용 (8.3 참조)

원문의 권고는 판정자를 신뢰하기 전에 항상 사람 평점과 대조해 검증하라는 것입니다. 고객에게 판정자를 인도할 때는 사람과의 일치율, 순서 교환 시 결과 변동, 판정 모델 계열을 문서로 함께 남깁니다.

8.3 에이전트 평가(Agent Evaluation)

원문: How to Evaluate AI Agents? Metrics, Methods, and Best Practices

에이전트는 이메일을 보내고 데이터베이스에 쓰고 돈을 씁니다. 그래서 최종 답만 채점하는 LLM 평가(8.1 참조)로는 부족하고, 결과에 이르는 모든 단계와 도구를 함께 채점해야 합니다. 이하 내용은 2026년 5월 글 기준입니다.

8.3.1 LLM 평가와 다른 점

AI 에이전트는 LLM으로 계획하고, 도구로 행동하며, 스스로 작업을 끝내는 시스템입니다(6.1 참조). 일반 LLM은 텍스트만 내놓지만 에이전트는 도구를 호출하고 파일을 읽고 웹을 검색하고 코드를 실행하며 목표까지 여러 단계를 밟습니다. "델리에서 방갈로르로 가는 금요일 항공편을 예약해 줘"라고 요청하면 에이전트는 생각하고, 항공편 검색 도구를 부르고, 결과를 읽고, 항공편을 고르고, 예약 도구를 부르고, 확인을 돌려줍니다. 사용자에게 보이는 것은 최종 결과뿐이지만 그 사이에서 여러 새로운 방식으로 실패할 수 있습니다.

에이전트 평가는 같은 작업을 에이전트에게 주고 시작부터 끝까지 지켜보며 작업을 올바르게 끝냈는지, 알맞은 도구와 단계를 썼는지, 시간과 돈을 낭비하지 않았는지를 확인하는 과정입니다. 필요한 이유는 다음과 같습니다.

LLM 평가는 입력을 주고 최종 텍스트 출력을 채점하지만, 에이전트는 입력과 출력 사이에서 계획하고 도구를 고르고 호출하고 결과를 읽고 결정하며 실패하면 다시 시도합니다. 그래서 최종 답과 그 사이의 모든 일을 함께 봐야 합니다.

측면 LLM 평가 에이전트 평가
무엇을 보는가 최종 텍스트 출력 최종 출력과 중간 모든 단계
단계 수 한 단계 여러 단계
도구 사용 없음 많은 도구 호출
비용 추적 LLM 호출 1회 여러 LLM 호출과 도구 호출
실패 양상 틀린 텍스트 잘못된 도구, 잘못된 순서, 무한 루프 등

평가 유형은 넷입니다. 결과 평가(Outcome)는 최종 결과만, 궤적 평가(Trajectory)는 결과에 이르기까지의 모든 단계를, 도구 사용 평가(Tool Use)는 도구를 쓴 방식을, 계획 평가(Planning)는 계획의 품질을 봅니다. 실제 프로젝트에서는 둘 이상을 조합합니다. FDE는 에이전트 데모를 보고 "최종 답이 맞다"에서 멈추지 않고, 어떤 경로로 그 답에 도달했는지를 고객과 함께 확인해야 합니다.

8.3.2 결과(Outcome) 평가

결과 평가는 최종 결과만 보고 그 사이는 무시합니다. "델리에서 방갈로르로 가는 금요일 최저가 항공편을 찾아 예약하라"는 지시에서 5단계를 밟았는지 50단계를 밟았는지는 보지 않고, 금요일 최저가 항공편이 예약되었는지만 봅니다. 맞으면 결과가 옳고 아니면 틀립니다.

대표 지표는 세 가지입니다.

장점은 정의와 측정이 간단하고, 사용자가 실제로 신경 쓰는 것과 일치하며, 명확한 정답이 있는 작업에 잘 맞는다는 점입니다. 한계는 세 가지입니다.

결과 평가는 올바른 결과가 무엇인지 말할 수 있을 때만 성립합니다. "완료 기준(definition of done)"가 없는 작업은 결과 평가도 할 수 없습니다. 고객에게 "이 에이전트가 성공했다는 것을 누가, 무엇으로 판정합니까"를 먼저 묻고 합의되지 않으면 평가 설계를 시작하지 않는 것이 안전합니다.

8.3.3 궤적(Trajectory) 평가

궤적 평가는 에이전트가 결과에 이르기까지 밟은 모든 단계를 순서대로 살핍니다. 궤적은 에이전트가 지난 행동과 생각의 전체 경로입니다. "내일 방갈로르 날씨는 어떻고 우산을 가져가야 할까?"라는 질문에 좋은 궤적은 이렇습니다.

  1. 날씨 도구를 도시 = 방갈로르, 날짜 = 내일로 호출합니다.
  2. 결과를 읽습니다. 비 올 확률이 70%입니다.
  3. 사용자가 우산을 가져가야 한다고 판단합니다.
  4. 사용자에게 답합니다.

에이전트가 1단계를 건너뛰고 추측으로 답했다면, 최종 답이 우연히 맞아도 궤적은 틀린 것입니다. 점검 방식은 다섯 가지입니다.

방식 질문
완전 일치(Exact Match) 기대한 단계 순서를 정확히 따랐는가
순서 일치(In-Order Match) 필요한 단계를 올바른 순서로 수행했는가 (여분의 단계가 있어도 됨)
순서 무관 일치(Any-Order Match) 필요한 단계를 모두 수행했는가 (순서는 달라도 됨)
정밀도(Precision) 밟은 단계 중 유용했던 단계의 비율
재현율(Recall) 필요했던 단계 중 실제로 밟은 단계의 비율

마지막 둘은 분류 시스템에 쓰는 정밀도, 재현율과 같습니다(1.8 참조). 계산 예를 보겠습니다. 필요한 도구 호출이 search_flights, book_flight, send_email 세 단계인데 에이전트가 search_flights, search_flights, book_flight 세 번을 호출했다면, 밟은 3단계 중 유용한 서로 다른 단계는 2개이므로 정밀도는 2/3 ≈ 0.67이고, 필요한 3단계 중 수행한 것은 2개이므로 재현율도 2/3 ≈ 0.67입니다. 중복 호출이 정밀도를, 빠진 확인 메일이 재현율을 깎았습니다.

그림 8.3.3 — 같은 도착지라도 우회하고 되돌아간 경로는 비용을 낭비한 궤적입니다.
그림 8.3.3 — 같은 도착지라도 우회하고 되돌아간 경로는 비용을 낭비한 궤적입니다.

장점은 에이전트가 어디서 틀렸는지 정확히 찾을 수 있고, 운과 실제 이해를 구분하며, 디버깅과 개선에 도움이 된다는 점입니다. 한계는 좋은 경로가 흔히 여럿이라 하나의 정답 궤적을 정의하기 어렵고, 최종 답만 확인하는 것보다 평가 비용이 크며, 완전 일치를 요구하면 지나치게 엄격하다는 점입니다. 궤적을 평가하려면 먼저 모든 단계를 포착해야 하며, 그 포착을 제공하는 것이 에이전트 관측성입니다(8.4 참조). 고객의 에이전트가 정답이 여러 경로인 작업이라면 완전 일치 대신 순서 일치나 순서 무관 일치로 시작합니다.

8.3.4 도구 사용 평가

도구 사용 평가는 에이전트가 가용한 도구를 어떻게 썼는지 확인합니다. 도구는 에이전트의 손이므로 잘못된 도구를 고르거나 잘못된 인자를 넘기면 작업 전체가 실패할 수 있습니다. 점검 항목은 다섯 가지입니다.

예를 들어 도구가 search_flights, book_flight, send_email이고 사용자가 "금요일 방갈로르행 최저가 항공편을 예약해 줘"라고 한다면, 좋은 에이전트는 search_flights를 부르고 최저가 결과로 book_flight를 부른 뒤 send_email로 확인을 보냅니다. 나쁜 에이전트는 send_email을 먼저 부르거나, 항공편을 고르지 않은 채 book_flight를 부르거나, 존재하지 않는 cancel_flight를 부릅니다. 도구 사용 평가는 이런 실수를 모두 잡아냅니다.

장점은 에이전트 실패의 가장 흔한 원인을 잡고, 도구 호출이 구조화되어 있어 자동화하기 쉬우며, 도구 설명과 프롬프트를 개선하는 데 쓸 수 있다는 점입니다. 한계는 최종 답의 품질을 알려 주지 않고, 어느 도구를 써야 하는지에 대한 명확한 기준 답이 필요한데 그것을 정의하기 어려울 때가 있다는 점입니다. 도구 호출 로그는 구조화된 데이터이므로, 고객 현장에서 가장 먼저 자동화할 평가는 도구 선택과 인자 정확성입니다.

8.3.5 계획 평가

계획 평가는 에이전트가 행동하기 전에 세우는 계획의 품질을 봅니다. 많은 에이전트가 먼저 계획을 쓰고 그 계획을 단계별로 따르는데(6.5 참조), 계획이 나쁘면 도구가 아무리 좋아도 실패합니다. 여행 계획의 좋은 예는 이렇습니다: 날짜에 맞는 항공편을 찾고, 사용자 일정에 맞는 최저가를 고르고, 목적지 근처 호텔을 찾고, 예산 안에서 평점이 가장 높은 곳을 고른 뒤, 전체 일정을 사용자에게 보냅니다.

점검 기준은 네 가지입니다.

장점은 에이전트가 나쁜 계획으로 시간을 낭비하기 전에 실수를 일찍 잡고, 에이전트가 어떻게 생각하는지 이해하게 해 준다는 점입니다. 한계는 계획을 미리 만드는 에이전트에만 적용되고, 좋은 계획도 여럿이라 하나의 정답 계획을 정의하기 어렵다는 점입니다. 행동 전에 생각해야 하는 복잡한 작업에서 특히 유용합니다. 반응형으로 즉석에서 행동하는 에이전트를 만난 고객이라면 계획 평가 대신 궤적 평가를 쓰도록 안내합니다.

8.3.6 핵심 지표와 벤치마크

실무에서 추적하는 핵심 지표는 여덟 가지이며 모두 함께 봅니다. 성공률이 높아도 작업마다 큰돈이 들거나 오래 걸리면 쓸모가 없습니다.

지표 의미 비고
작업 성공률(Task Success Rate) 올바르게 끝낸 작업의 비율 가장 중요. 낮으면 나머지는 의미가 없음
도구 호출 정확도(Tool Call Accuracy) 올바르고 유용했던 도구 호출의 비율
작업당 단계 수(Number of Steps per Task) 작업을 끝내는 데 쓴 단계 적을수록 대체로 좋은 에이전트
작업당 비용(Cost per Task) LLM 호출과 도구 호출에 쓴 돈 운영 에이전트에 결정적
작업당 지연(Latency per Task) 작업 완료 시간 사용자는 무한히 기다리지 않음
복구율(Recovery Rate) 도구 호출이 실패해도 회복하여 끝내는 비율
안전 점수(Safety Score) 하지 말아야 할 해롭거나 위험한 행동을 했는가
루프 감지(Loop Detection) 같은 도구를 반복 호출하며 무한 루프에 빠졌는가 에이전트 루프 설계(6.3, 7.2 참조)

이 숫자 대부분은 사실상 에이전트 루프에 대한 판정입니다. 같은 지표를 서비스 운영 중 관측하는 방법은 8.4.4에 있습니다.

에이전트도 LLM처럼 비교용 벤치마크가 있고, 시험하는 능력이 다릅니다.

범주 벤치마크 내용
함수 호출 BFCL 알맞은 함수 선택과 올바른 인자 전달. 도구 사용에서 가장 많이 인용
고객 서비스 τ-bench / τ²-bench 도구를 쓰고 회사 정책을 따라야 하는 현실적 환경. 원래 τ-bench는 에이전트만 환경에 작용하는 단일 제어이고, τ²-bench는 에이전트와 시뮬레이션된 사용자가 각자 도구를 가지고 같은 세계에서 행동하는 이중 제어를 추가
코딩 에이전트 SWE-bench Verified 오픈소스의 실제 GitHub 이슈
코딩 에이전트 Terminal-Bench 샌드박스 명령줄에서 머신러닝 모델 학습, 리눅스 소스 빌드, 바이너리 리버스 엔지니어링 같은 실제 작업. diff 패치가 아니라 셸 명령을 실행하므로 진정한 에이전트형
코딩 에이전트 MLE-bench Kaggle 대회의 머신러닝 엔지니어링 작업
범용 비서 GAIA 추론, 도구 사용, 웹 브라우징을 결합한 작업
웹 브라우징 WebArena, VisualWebArena, BrowseComp 현실적 웹사이트(6.17 참조), 페이지의 시각 이해가 필요한 웹 작업, 열린 웹에서의 정보 탐색
컴퓨터 사용 OSWorld, AppWorld 에이전트가 컴퓨터 전체를 제어하는 실제 데스크톱 환경(6.16 참조), 일상 앱을 API로 다루는 에이전트

에이전트 벤치마크에도 두 가지 주의가 있습니다.

고객이 벤치마크 순위를 근거로 에이전트 프레임워크를 고르려 하면, 자기 업무에서 작업 성공률, 작업당 비용, 지연을 같은 표에 놓고 비교하도록 안내합니다.

8.3.7 프레임워크와 도구

대규모로 평가를 돌리는 방법은 세 가지이며, 각 방법의 틀과 한계는 8.1, 8.2에서 본 것과 같습니다.

방법 방식 장점 한계
자동 평가 테스트 작업 세트로 에이전트를 돌리고 출력과 궤적을 기대값과 코드로 비교. 항공편 번호를 비교하고 도구 호출 로그를 점검 빠르고 싸고 재현 가능 명확한 기준 답이 있을 때만 가능
LLM 판정 사용자 요청, 궤적 전체, 최종 답을 강한 LLM에게 주고 작업 완수, 올바른 도구, 효율적 경로, 정답 여부를 1~5점으로 이유와 함께 채점시킴 (8.2 참조) 확장되고 개방형 작업에 통함 판정자 편향이 있으므로 사람 평점과 대조 검증 필요
사람 평가 사람이 궤적과 최종 답을 보고 채점 복잡한 작업에서 자동 지표와 판정자가 놓치는 미묘한 문제까지 잡음, 최고 품질 느리고 비싸며 확장 어려움

실제 제품에서는 셋을 조합합니다. 빠른 피드백은 자동 평가, 일상 모니터링은 LLM 판정, 출시 전 최종 점검은 사람 평가가 맡습니다.

평가 프레임워크는 테스트 작업 정의, 에이전트 실행, 전체 궤적 포착, 실행별 채점, 대시보드 표시를 구조화해 줍니다. 원문이 소개하는 대표 도구는 두 가지입니다.

이 도구를 모두 배울 필요는 없고, 직접 평가 체계를 만들 때 무엇을 검색해야 하는지 알면 충분합니다.

에이전트 평가에는 고유한 어려움이 있고 각각에 대한 대응이 있습니다.

도전 과제 내용 대응
여러 개의 올바른 경로 정답 궤적이 하나가 아니라 궤적 비교가 까다로움 순서 일치 등 느슨한 방식 사용
비결정성 LLM이 결정적이지 않아 같은 입력에도 답이 다름(2.11 참조) 각 테스트를 여러 번 실행
긴 궤적 20, 50, 100 단계에 달해 직접 검토하기 고단함 소량 표본 검토와 LLM 판정 병행
환경 변화 검색 엔진이나 데이터베이스 같은 실제 시스템 결과가 매일 바뀌어 재현이 어려움 가짜 도구와 데이터의 샌드박스
연쇄 실패 2단계의 작은 실수가 10단계의 큰 실패가 됨 근본 원인까지 추적
안전 위험 잘못된 행동이 실제 돈을 쓰거나 실제 사용자에게 잘못된 메일을 보냄 사전에 포착
평가 비용 작업마다 LLM과 도구 호출이 많아 비쌈 비용도 지표로 추적

모범 사례 아홉 가지는 다음과 같습니다.

FDE는 평가 체계를 인도할 때 테스트 세트, 반복 실행 횟수, 샌드박스, 최대 단계 수 설정이 고객 환경에 갖춰졌는지부터 체크리스트로 확인합니다.

8.4 에이전트 관측성(Observability)

원문: What is AI Agent Observability? Traces, Spans, and Metrics Explained

에이전트는 최종 답 뒤에서 수많은 단계를 밟으므로, 고객이 "엉뚱한 항공편이 예약됐다"고 신고했을 때 어느 단계가 틀렸는지 기록이 없으면 추측밖에 할 수 없습니다. 관측성은 그 기록을 남기고 읽는 방법입니다. 이하 내용은 2026년 5월 글 기준입니다.

8.4.1 관측성의 세 기둥

관측성(Observability)은 "관찰(Observe) + 능력(Ability)"으로, 시스템이 내놓는 데이터를 보고 내부에서 무슨 일이 일어나는지 알아내는 능력입니다. "지금 시스템 안에서 무슨 일이 왜 일어나고 있는가"에 답할 수 있다는 뜻입니다. 자동차가 이상한 소리를 낼 때 엔진을 뜯지 않고 계기판의 속도, 연료, 엔진 온도로 내부를 짐작하는 것이 그 예이며, 의사가 몸속을 직접 보지 못하고 X선, 혈액 검사, 심박 모니터 신호로 상태를 파악하는 것도 같습니다.

AI 에이전트 관측성은 에이전트가 내부에서 하는 모든 일을 단계별로 기록하고 이해하여, 에이전트가 왜 그렇게 행동했는지 볼 수 있게 하는 실천입니다. 항공편 예약 에이전트는 겉으로는 "항공편이 예약되었습니다"라는 메시지만 보이지만, 안에서는 작업을 생각하고, 검색 도구를 입력과 함께 부르고, 도구가 항공편 목록을 돌려주고, 에이전트가 하나를 고르고, 예약 도구를 부르고, 확인을 받는 일이 일어납니다. 비행기의 블랙박스처럼 문제가 생기면 기록을 열어 정확히 무슨 일이 있었는지 확인할 수 있습니다.

필요한 이유는 에이전트가 예측하기 어렵기 때문입니다. 같은 작업에도 경로가 달라지고, 실제 도구를 호출하고, 실제 돈을 쓰고, 실제 이메일을 보냅니다. 사용자가 "에이전트가 엉뚱한 항공편을 예약했다"고 불평할 때 가능한 원인은 다섯 가지입니다.

관측성이 없으면 어느 것도 답할 수 없습니다. 필요한 이유를 모으면 다음과 같습니다.

모든 잘못된 단계가 사고는 아닙니다. 공격자가 에이전트가 읽는 페이지나 이메일에 지시문을 숨겨 놓았다면 트레이스가 무슨 일이 있었는지 보여 주는 거의 유일한 곳입니다(9.2 참조).

일반 소프트웨어 관측성과의 차이는 에이전트가 비결정적(non-deterministic)이라는 데 있습니다. 일반 소프트웨어는 2 + 2를 부르면 항상 4가 나오고 경로가 고정됩니다. 에이전트는 같은 작업에 오늘은 3단계, 내일은 6단계를 밟을 수 있고, 한 번은 도구를 부르고 다음엔 건너뛸 수 있습니다. 또한 일반 소프트웨어의 오류는 대체로 명확한 충돌이지만, 에이전트는 조용히 실패하여 완벽해 보이지만 완전히 틀린 답을 내면서도 충돌이나 붉은 오류가 없을 수 있습니다.

전통적 관측성 AI 에이전트 관측성
같은 입력에 같은 출력 같은 입력에 다른 출력 가능
고정된 실행 경로 실행마다 경로가 바뀜
오류는 명확한 충돌 조용히 실패하며 맞아 보일 수 있음
CPU, 메모리, 요청을 추적 토큰, 비용, 도구 호출, 추론도 추적
주로 "실행되었나" 확인 "답이 좋았나"도 확인
로그는 단순 텍스트 줄 프롬프트, 응답, 결정도 포착

그래서 에이전트 관측성은 전통적 관측성 전체에 에이전트 고유의 새로운 것들을 더한 것입니다.

관측성은 고전적인 세 기둥 위에 서 있고, 이는 에이전트에도 적용됩니다.

기둥 정의 에이전트에서의 예
로그(Logs) 일어난 사건의 단순 텍스트 기록 "에이전트가 델리에서 방갈로르행 금요일로 항공편 검색 도구를 호출했다"
메트릭(Metrics) 시간에 따라 측정하는 숫자 사용한 토큰 수, 작업당 비용, 평균 소요 시간
트레이스(Traces) 한 요청이 시스템을 지나는 전체 여정을 단계별로 보여 줌 한 작업의 모든 생각, 도구 호출, LLM 호출

에이전트는 내부에서 너무 많은 단계를 밟으므로 행동을 이해하려면 전체 여정이 필요하기에, 에이전트에서는 트레이스가 가장 중요한 기둥입니다. 고객이 기존 APM 대시보드(CPU, 메모리, 요청 수)만 갖고 있다면 "답이 좋았는가"를 볼 수 없다는 점이 그 공백입니다.

8.4.2 트레이스(Trace)와 스팬(Span)

스팬(span)은 에이전트 안의 하나의 단계나 작업에 대한 기록이고, 트레이스(trace)는 에이전트의 한 번 전체 실행에 대한 기록으로 여러 스팬으로 이루어집니다. 스팬은 한 단계, 트레이스는 여러 단계로 된 전체 이야기입니다. 병원 진료에 비유하면 트레이스는 한 번 방문한 진료 보고서 전체이고, 스팬은 그 안의 개별 검사입니다.

항공편 예약 에이전트에서 사용자가 항공편을 요청하면 한 번 전체 실행이 일어나며 이것이 하나의 트레이스입니다. 그 안에 일곱 개의 스팬이 있습니다.

  1. 에이전트가 사용자 요청을 받음.
  2. LLM이 생각하고 항공편 검색을 결정.
  3. 에이전트가 항공편 검색 도구를 호출.
  4. 에이전트가 검색 결과를 읽음.
  5. LLM이 최저가 항공편을 고름.
  6. 에이전트가 예약 도구를 호출.
  7. 에이전트가 최종 확인을 돌려줌.

각 스팬은 입력, 출력, 걸린 시간, 오류 같은 유용한 세부를 기록합니다. 스팬은 서로 안에 중첩될 수 있습니다. 예를 들어 "계획" 스팬 안에 "LLM 호출" 스팬이 들어가며, 이 중첩이 트리를 이루어 에이전트 작업의 전체 구조를 보여 줍니다. 에이전트를 처음부터 작은 단계의 그래프로 설계하면 노드 하나마다 깔끔한 스팬이 공짜로 생깁니다(7.3 참조).

flowchart TD
    T["TRACE: 델리-방갈로르 항공편 예약"] --> S1["SPAN: 사용자 요청 수신"]
    T --> S2["SPAN: 작업 계획"]
    S2 --> S2a["SPAN: LLM 호출 (항공편 검색 결정)"]
    T --> S3["SPAN: 도구 호출 (항공편 검색)<br/>입력: 델리 → 방갈로르, 금요일<br/>출력: 항공편 12건 목록"]
    T --> S4["SPAN: 최저가 항공편 선택"]
    S4 --> S4a["SPAN: LLM 호출 (항공편 선택)"]
    T --> S5["SPAN: 도구 호출 (예약)<br/>출력: 예약 확정"]
    T --> S6["SPAN: 최종 확인 반환"]

그림 8.4.2 — 하나의 트레이스는 스팬의 트리이며, 일부 스팬은 더 작은 스팬을 품습니다.

한 사용자가 에이전트와 길게 대화하면 요청마다 트레이스가 하나씩 생깁니다. 이 트레이스를 모두 묶은 것이 세션(session)입니다. 세션은 여러 트레이스를, 트레이스는 여러 스팬을 포함합니다.

계층 의미 예
세션 한 사용자의 한 번 전체 대화 항공편 상담 대화
트레이스 요청 하나의 실행 트레이스 1: "항공편을 찾아 줘", 트레이스 2: "첫 번째 항공편을 예약해 줘"
스팬 트레이스 안의 한 단계 LLM 호출, 검색 도구 호출, 예약 도구 호출

고객 현장에서는 신고된 대화의 세션 ID로 문제의 트레이스를 찾고, 그 안의 스팬에서 입력과 출력을 하나씩 따라가는 순서로 디버깅합니다.

8.4.3 에이전트 내부에서 관측할 것

스팬마다 무엇을 포착해야 하는지는 에이전트의 구성 요소 여섯 가지로 나뉩니다.

구성 요소 포착할 것 이유
1. LLM 호출 보낸 전체 프롬프트, 받은 전체 응답, 모델명, 답의 창의성을 조절하는 온도 설정(2.11 참조), 입력 토큰 수, 출력 토큰 수, 비용 가장 중요. 에이전트의 생각과 비용을 이해
2. 도구 호출 어떤 도구를 불렀는가, 어떤 입력을 넘겼는가, 어떤 출력이 돌아왔는가, 성공했는가 실패했는가 에이전트는 대부분 잘못된 도구를 부르거나 잘못된 입력을 넘겨 실패하므로 가치가 큼
3. 추론과 계획 단계 행동 전 생각 에이전트가 특정 행동을 고른 이유를 이해
4. 메모리와 컨텍스트 메모리에서 읽은 것, 메모리에 쓴 것(6.7 참조) 과거 단계나 대화를 기억하는 에이전트의 상태 파악
5. 재시도와 오류 모든 재시도와 오류 에이전트가 어디서 고전하는지 파악
6. 최종 출력 사용자에게 준 최종 답 맞고 유용했는지 확인

이 여섯을 모두 포착하면 에이전트의 전체 모습을 얻고 숨는 것이 없습니다. "LLM을 호출했다"는 한 줄 로그로는 나중에 디버깅할 수 없으므로 실제 입력과 출력을 남깁니다. 다만 프롬프트와 도구 입력에는 사용자의 개인 정보가 들어 있을 수 있으므로, 저장하기 전에 민감 정보를 가리는 처리가 포착과 함께 설계되어야 합니다(8.4.5 참조).

8.4.4 핵심 지표

트레이스는 한 번 실행의 전체 이야기를 알려 주고, 시간에 따라 추적하려면 숫자인 메트릭이 필요합니다. 핵심 지표는 일곱 가지입니다.

지표 의미 주의점
지연(Latency) 작업을 끝내는 데 걸리는 시간 전체 시간과 단계별 시간 모두 추적. 느린 도구나 느린 LLM 호출이 전체를 느리게 함
토큰 사용량(Token Usage) 작업당 LLM이 읽고 쓰는 텍스트 조각의 수 토큰이 많을수록 비용이 큼
비용(Cost) 작업당 쓴 돈 에이전트는 LLM을 여러 번 호출하므로 빠르게 불어남
단계 수(Number of Steps) 작업을 끝내는 데 밟은 단계 지나치게 많으면 시간과 돈을 낭비하거나 루프에 빠진 것(6.3 참조)
도구 호출 성공률(Tool Call Success Rate) 성공한 도구 호출의 비율 낮으면 도구나 에이전트의 어딘가가 고장
오류율(Error Rate) 에이전트가 오류를 만나는 빈도 오르면 무언가 잘못되고 있다는 조기 경보
작업 성공률(Task Success Rate) 작업을 올바르게 끝내는 빈도 가장 중요

이 숫자를 시간에 따라 지켜보면 에이전트가 나빠지기 시작하는 시점을 빠르게 알아챌 수 있습니다. 작업 성공률은 평가 쪽 지표와 겹치므로 8.3.6의 정의를 그대로 씁니다. 고객과는 비용, 지연, 오류율에 알림 임계값을 정하는 것으로 시작하는 것이 현실적입니다.

8.4.5 도구와 프레임워크

관측성이 실제로 작동하는 방식은 다섯 단계입니다.

  1. 계측(Instrumentation): 에이전트에 각 단계에서 입력, 출력, 시간, 오류를 기록하는 작은 코드를 추가합니다. 중요한 지점마다 작은 센서를 다는 것과 같으며, 원문은 최신 에이전트 프레임워크가 대체로 계측을 내장하고 있어 직접 쓸 코드가 적다고 설명합니다. 외부 출처로는 확인하지 못했으며 프레임워크마다 다를 수 있습니다.
  2. 데이터 수집: 실행 중에 계측이 트레이스, 스팬, 메트릭을 만들고 관측성 플랫폼으로 보냅니다.
  3. 저장과 연결: 플랫폼이 스팬을 저장하고 전체 트레이스로 연결하여 한 번 실행의 모든 단계를 하나의 이야기로 묶습니다.
  4. 시각화: 대시보드에서 트레이스를 스팬의 트리로 보고, 스팬을 눌러 정확한 프롬프트, 응답, 도구 입력과 출력을 확인합니다.
  5. 알림: 비용이 갑자기 오르거나 오류율이 높아지거나 에이전트가 느려지면 즉시 통지를 받습니다.
flowchart TD
    A["AI 에이전트 (계측 포함)<br/>각 단계를 기록"] --> B["트레이스, 스팬, 메트릭"]
    B --> C["관측성 플랫폼<br/>스팬을 저장하고 전체 트레이스로 연결"]
    C --> D["대시보드: 모든 단계 확인"]
    C --> E["알림: 비용, 오류, 지연 통지"]

그림 8.4.5 — 에이전트가 남긴 기록이 플랫폼을 거쳐 대시보드와 알림으로 나뉩니다.

중요한 표준은 OpenTelemetry입니다. 트레이스, 메트릭, 로그를 수집하는 공통 형식을 정의한 오픈소스 표준이므로, 데이터를 한 번 수집해 여러 도구로 보낼 수 있고 대부분의 관측성 도구가 이를 지원합니다. OpenTelemetry에는 모델명, 토큰 수 같은 AI 고유 항목에 표준 이름을 주는 GenAI 규약(GenAI conventions)이 있어(2026년 현재 개발 단계 규약이라 항목 이름이 바뀔 수 있습니다), 도구마다 같은 것을 다른 이름으로 부르는 문제가 없습니다.

대표 도구는 다음과 같습니다(2026년 5월 글 기준).

도구 특징
LangSmith LangChain 팀이 만든 관측성과 평가 플랫폼. 에이전트 단계별 상세 트레이스(7.4 참조)
Langfuse LLM 앱과 에이전트용 오픈소스 관측성 플랫폼. 트레이스, 비용, 메트릭 포착
Arize Phoenix OpenTelemetry 위에 만든 LLM 애플리케이션 추적과 평가용 오픈소스 도구
OpenTelemetry 트레이스, 메트릭, 로그를 공통 형식으로 수집하는 개방 표준
Laminar 단일 LLM 호출이 아니라 오래 걸리는 에이전트의 추적을 위해 만든 오픈소스, OpenTelemetry 네이티브 플랫폼
Datadog, Grafana LLM과 에이전트 모니터링도 지원하게 된 전통적 관측성 플랫폼

많은 도구가 OpenTelemetry를 지원하므로 하나의 도구에 묶이지 않습니다.

관측성에도 어려움이 있고 대응이 필요합니다.

도전 과제 내용
방대한 데이터 에이전트는 단계가 많아 트레이스 데이터가 막대하며, 저장과 검색이 비싸질 수 있음
민감 데이터 프롬프트와 도구 입력에 개인 정보가 있을 수 있으므로 가리거나 마스킹해야 함
비결정적 행동 매번 경로가 달라 두 실행을 직접 비교하기 어려움
관측 자체의 비용 모두 기록하면 시간과 비용이 늘어나므로 기록량의 균형이 필요
단계 연결 서브에이전트가 많은 복잡한 에이전트에서는 스팬을 하나의 깔끔한 트레이스로 잇기 어려워 좋은 계측이 필요(6.13 참조)

모범 사례는 여덟 가지입니다.

FDE가 고객 에이전트를 배포할 때는 OpenTelemetry 호환 도구를 고르고, 마스킹 규칙과 보관 기간을 개인정보 담당자와 함께 정해 둡니다.

8.4.6 관측성 vs 평가

관측성과 평가는 자주 혼동되지만 다르고, 함께 일합니다. 관측성은 에이전트가 무엇을 했는지 알려 주고, 평가는 그것이 얼마나 좋았는지 알려 줍니다. 관측성은 매 실행의 전체 이야기를 기록하고, 평가는 그 이야기가 좋은 이야기였는지 판단합니다.

항공편을 예약한 에이전트의 예에서, 관측성은 예약까지 밟은 모든 단계를 보여 주고, 평가는 최저가 항공편을 골랐는지, 올바른 날짜를 썼는지, 작업을 올바르게 끝냈는지를 확인합니다.

구분 관측성 평가
답하는 질문 무엇을 했는가 얼마나 좋았는가
산출물 트레이스, 스팬, 메트릭 (원시 데이터) 점수와 판정
의존 관계 먼저 있어야 함 관측성 데이터를 사용

관측성이 먼저 원시 데이터를 주고, 평가가 그 데이터로 에이전트를 채점합니다. 관측성이 없으면 평가할 것이 없고(8.3.3 참조), 평가가 없으면 관측성 데이터에는 품질에 대한 판단이 없습니다. 고객에게는 "트레이스는 모으고 있지만 그 점수는 누가 매깁니까"와 "점수는 있지만 문제 실행을 열어 볼 수 있습니까"를 함께 물어 두 쪽 중 빠진 쪽을 확인합니다.

8.5 고객이 내일 묻는다면

각 질문에 소리 내어 답해보고, 막히면 표시된 절로 돌아가십시오. 통과 기준은 "내일 고객이 물어도 설명하고 결정할 수 있는가"입니다.

  1. "이 챗봇이 좋은지 어떻게 알 수 있나요?" 평가 방법 네 가지 중 무엇을 어떻게 조합해 답합니까? (8.1.1, 8.1.6)
  2. "번역 품질을 BLEU 점수로 보고하려 합니다." 이 지표가 맞는 작업과 맞지 않는 작업을 어떻게 가릅니까? (8.1.2)
  3. "벤치마크 1위 모델이니 그걸로 가죠." 무엇을 되묻고 무엇을 대신 제안합니까? (8.1.3)
  4. "사람이 전부 읽어 볼 수는 없는데, 사람 평가는 언제 쓰나요?" 어디에 쓰도록 설계합니까? (8.1.4)
  5. "두 달 전에 평가했고 점수가 좋았는데 다시 해야 하나요?" 무엇 때문에 다시 해야 합니까? (8.1.5)
  6. "챗봇의 검색 품질과 답변 품질을 따로 보고 싶어요." 어떤 지표들로 나눕니까? (8.1.6)
  7. "다른 LLM에게 채점시키면 믿을 수 있나요?" 구축 단계에서 무엇을 검증합니까? (8.2.2, 8.2.5)
  8. "생성도 평가도 같은 벤더 모델로 하면 편하겠죠?" 어떤 편향이 생기고 어떻게 막습니까? (8.2.4)
  9. "에이전트 데모에서 최종 답이 맞았으니 합격 아닌가요?" 결과 평가만으로 놓치는 것은 무엇입니까? (8.3.1, 8.3.2, 8.3.3)
  10. "에이전트가 같은 도구를 계속 부르는 것 같아요." 무엇으로 재고 어떤 지표를 봅니까? (8.3.4, 8.3.6)
  11. "엉뚱한 항공편이 예약됐다는 신고가 들어왔습니다." 어떤 순서로 원인을 추적합니까? (8.4.1, 8.4.2)
  12. "대시보드에 CPU와 요청 수는 있는데 에이전트는 따로 볼 게 있나요?" 무엇을 더 기록합니까? (8.4.3, 8.4.4)
  13. "트레이스는 모으는데 품질은 누가 판단하나요?" 관측성과 평가의 관계를 설명해 보십시오. (8.4.6, 8.3.3)

위 질문에 막힌 곳이 없다면 이 장은 통과입니다. 막힌 곳은 표시된 절을 다시 읽고 같은 질문에 답해 보십시오.