4부가 시작됩니다. AI 에이전트를 개발할 때 많은 개발자가 간과하는 부분이 바로 LLM 평가입니다. 특히 LangGraph를 활용한 복잡한 에이전트 시스템을 구축할수록 평가의 중요성은 더욱 커집니다.
17.1 LLM의 예측 불가능성
전통적인 소프트웨어 시스템은 프로그래머가 작성한 명시적인 규칙과 로직에 따라 동작하기 때문에 입력에 대한 출력이 결정적이고 예측할 수 있습니다. 반면 LLM은 다릅니다.
| 특성 | 내용 |
|---|---|
| 확률적 생성 | 다음 토큰을 예측할 때 확률 분포를 사용한다. 동일한 프롬프트라도 매번 다른 응답이 나올 수 있다. 1장의 온도 파라미터가 여기에 영향을 미치는데, 0으로 설정해도 부동 소수점 연산의 미세한 차이로 완벽한 동일성은 보장하기 어렵다 |
| 콘텍스트 의존성 | 동일한 질문이라도 대화의 맥락에 따라 다른 답변을 제공한다 |
| 프롬프트 민감성 | 프롬프트의 미묘한 변화가 출력에 큰 영향을 미칠 수 있다 |
| 복잡한 상호작용 | 도구 사용, 외부 API 호출 등에서 예측하기 어려운 행동을 보일 수 있다 |
이런 특성이 왜 문제인지 책은 구체적인 장면으로 보여 줍니다.
사용자 내 세금을 계산해줘.
에이전트 어떤 종류의 세금에 대해 알고 싶으신가요? 소득세, 종합부동산세, 양도소득세 등이 있습니다.
사용자 연봉 5천만 원이야.
에이전트 [소득세 계산 도구 호출 실패: 연봉 정보가 정확히 파싱되지 않음]
이 오류가 LLM의 확률적 특성 때문에 발생한 일회성 문제인지, 아니면 프롬프트나 도구 설계의 결함 때문인지 어떻게 판단할 수 있을까요? 또한 이 문제가 특정 사용자 시나리오에서만 발생하는지, 아니면 모든 소득 관련 질문에서 발생하는지 어떻게 확인할 수 있을까요?
바로 이러한 이유로 체계적인 LLM 평가가 필요합니다.
17.2 평가가 왜 중요한가
일관성 보장과 행동의 예측 가능성
세금 계산 에이전트가 동일한 연봉 정보에 대해 매번 정확히 같은 계산 도구를 호출하고, 올바른 수치(인수)를 전달하는지 검증해야 합니다. 도구 호출이 누락되거나 추출된 연봉 수치가 달라지는 등 응답의 변동성이 크다면, 프롬프트 엔지니어링이나 도구 설계 단계에서 개선이 필요하다는 신호입니다.
test_cases = [
{"input": "종합부동산세 계산해줘", "expected_tool": "get_house_tax"},
{"input": "소득세 얼마야?", "expected_tool": "get_income_tax"},
{"input": "10억짜리 집을 2채 가지고 있어", "expected_tool": "get_house_tax"},
]
for case in test_cases:
result = evaluate_agent_behavior(agent, case["input"], case["expected_tool"])
12장에서 “에이전트는 예측 불가능하다”고 했던 문제를, 예상 도구를 명시한 테스트 케이스로 다루는 것입니다.
오류를 다섯 가지로 분류한다
LLM 기반 에이전트의 오류는 다양한 단계에서 발생합니다. 이 분류가 실무에서 유용합니다.
| 오류 유형 | 발생 지점 |
|---|---|
| 프롬프트 이해 오류 | LLM이 프롬프트의 지시를 잘못 이해했을 때 |
| 도구 선택 오류 | 상황에 맞지 않는 도구를 선택했을 때 |
| 도구 사용 오류 | 도구에 잘못된 인수를 전달했을 때 |
| 콘텍스트 관리 오류 | 대화의 맥락을 잘못 해석했을 때 |
| 출력 파싱 오류 | 도구 호출을 위한 JSON 형식을 지키지 않았거나 약속된 스키마와 다른 구조로 데이터를 반환해 시스템이 해석하지 못했을 때 |
체계적인 평가 시스템은 이러한 오류들을 효과적으로 탐지하고 분류할 수 있으며, 이는 디버깅 과정을 크게 간소화합니다.
성능 지표는 서로 트레이드오프다
응답 시간, 토큰 사용량, 성공률을 모니터링해 최적화 포인트를 식별합니다. 그런데 중요한 단서가 붙습니다.
특히 이러한 지표들은 서로 트레이드오프(상충 관계) 에 있을 수 있습니다. 예를 들어 더 똑똑한 모델(GPT-5, Claude-4.5, Gemini-3 등)을 쓰면 ‘성공률’은 올라가지만 ‘응답 시간’과 ‘비용(토큰)’이 증가합니다. 반대로 가벼운 모델을 쓰면 빠르고 저렴하지만 복잡한 추론에서 실패할 수 있습니다. 따라서 평가는 이들 사이의 최적 균형점을 찾는 과정이어야 합니다.
8장에서 gpt-4o를 gpt-4o-mini로 바꿔 94%를 절감했던 그 선택을, 측정으로 정당화하는 방법이 여기 있습니다.
신뢰성 있는 배포 — 세 가지 장치
평가 없이 LLM 기반 에이전트를 프로덕션 환경에 배포하는 것은 예측할 수 없는 위험을 감수하는 것과 같습니다.
- 품질 게이트: 배포 파이프라인(CI/CD) 중간에 평가 단계를 배치하여 미리 설정된 기준 점수(예: 성공률 95% 이상)를 통과하지 못하면 배포가 자동으로 중단되도록 설정한다.
- 회귀 테스트: 새로운 기능을 추가하거나 프롬프트를 수정했을 때 기존에 잘 작동하던 기능이 망가지지 않았는지 확인한다. LLM은 작은 변화가 예상치 못한 부작용을 낳을 수 있으므로 필수적인 과정이다.
- 가드레일: 평가를 통과해 배포되었더라도 실시간 운영 환경에서 발생할 수 있는 환각이나 유해한 응답을 막기 위해 입력과 출력을 검증하는 별도의 안전장치를 마련한다.
17.3 LLM 평가의 고유한 어려움
정답의 다양성
소프트웨어 테스트에는 명확한 ‘정답’이 있습니다. 하지만 LLM의 응답은 표현이 다양하더라도 의미적으로 동등할 수 있습니다.
예상 응답 연봉 5천만 원에 대한 소득세는 624만 원입니다.
실제 응답 1 5천만 원 연봉에 대해 납부해야 할 소득세액은 624만 원입니다.
실제 응답 2 소득세액을 계산해보니 624만 원이 나왔습니다.
세 응답은 표현은 다르지만 의미적으로는 동일합니다. 단순한 문자열 비교로는 응답의 정확성을 평가하기 어렵습니다.
복잡한 시나리오 테스트
LLM 기반 에이전트는 복잡한 대화와 다단계 작업을 처리해야 합니다. 이는 단순한 입력-출력 테스트를 넘어 복잡한 시나리오 테스트가 필요함을 의미합니다.
conversation = [
{"role": "user", "content": "세금 계산 좀 도와줘"},
{"role": "assistant", "content": "어떤 세금에 대해 알고 싶으신가요?"},
{"role": "user", "content": "작년에 집을 샀어"},
{"role": "assistant", "content": "언제, 얼마에 구매하셨나요?"},
{"role": "user", "content": "2023년 12월에 5억에 샀어"},
# ...대화 계속...
]
evaluation_result = evaluate_conversation(agent, conversation)
이러한 복잡한 시나리오 테스트는 설계하기 어렵고, 자동화하기도 쉽지 않습니다.
주관적 평가 요소 여섯 가지
에이전트의 성공은 단순한 기능적 정확성을 넘어 사용자 경험의 품질에도 달려 있습니다. 책은 여섯 가지를 짚습니다.
① 응답의 유용성 — 기술적으로 정확하더라도 실질적 도움이 되지 않으면 좋은 평가를 받을 수 없습니다.
[유용하지 않음] 연봉 5천만 원의 소득세는 624만 원입니다.
[유용함] 연봉 5천만 원의 경우 소득세는 624만 원입니다. 세금을 합법적으로 줄이는 방법은:
1. 연금저축/IRP 납입(연 900만 원 한도)
2. 신용카드 소득공제(연봉의 25% 초과 사용액)
3. 의료비 공제(연봉의 3% 초과분)
등이 있습니다. 구체적인 상황을 알려주시면 더 자세히 안내해드릴 수 있습니다.
② 톤과 스타일의 적절성 — 특히 세금 같은 민감한 주제에서 더욱 중요합니다.
tone_criteria = {
"professional": "전문적이면서도 이해하기 쉬운가?",
"empathetic": "사용자의 상황에 공감하는가?",
"clarity": "복잡한 개념을 명확하게 설명하는가?",
"consistency": "일관된 어투를 유지하는가?"
}
부적절한 예로 “세금이 624만 원이네요. 많이 내시네요.” 처럼 불필요한 평가가 포함된 경우를 듭니다.
③ 콘텍스트 이해도 — “작년에 집을 샀는데 요즘 세금 고지서가 계속 나와요”라는 말에 “집을 구매하신 것을 축하드립니다”라고 답하면 맥락을 놓친 것입니다. 우수한 응답은 재산세(5월)와 지역자원시설세(7월) 일정을 짚고 취득세와의 차이를 설명한 뒤 주택 유형과 공시가격을 되묻습니다.
④ 응답의 구조화
structure_evaluation = {
"has_summary": "핵심 내용 요약이 있는가?",
"step_by_step": "복잡한 계산을 단계별로 설명하는가?",
"visual_aids": "표나 목록을 적절히 활용하는가?",
"logical_flow": "논리적인 흐름으로 전개되는가?"
}
⑤ 오류 처리의 우아함 — 사용자가 잘못된 정보를 제공할 때의 대응입니다.
사용자 연봉이 마이너스인데 세금을 계산해줘.
[부적절] 오류: 잘못된 입력값입니다.
[우아함] 연봉은 일반적으로 양수여야 합니다. 혹시 사업 손실이나 특별한 상황이 있으신가요?
정확한 상황을 알려주시면 적절한 세금 관련 안내를 드릴 수 있습니다.
⑥ 주관적 평가의 정량화 — 완전히 객관화하기는 어렵지만 1~5점 척도와 판단 기준을 함께 명시해 일관성을 높입니다.
subjective_scoring = {
"helpfulness": {
"scale": [1, 5],
"criteria": [
"질문에 직접적으로 답변했는가?",
"추가적인 유용한 정보를 제공했는가?",
"실행 가능한 조언을 포함했는가?",
]
},
"clarity": {"scale": [1, 5], "criteria": ["전문 용어를 적절히 설명했는가?", ...]},
"user_satisfaction": {"scale": [1, 5], "criteria": ["사용자가 추가 질문 없이 만족할 만한가?", ...]}
}
이러한 주관적 평가 요소는 자동화하기 어렵지만, LLM 기반 에이전트의 실제 성공에 결정적인 영향을 미칩니다.
17.4 체계적인 LLM 평가 접근법
평가 데이터셋 구축 — 다섯 범주
첫 번째 단계는 다양한 사용자 시나리오를 포괄하는 테스트 케이스 구축입니다. 각 범주에 붙은 수치가 설득력 있습니다.
| 범주 | 왜 필요한가 |
|---|---|
| ① 직접적인 질문 (“연봉 5천만 원에 대한 소득세는 얼마인가요?”) | 핵심 기능을 검증하는 기본 테스트. 실제로 사용자의 약 40~50%는 이렇게 명확한 질문으로 서비스를 시작한다. 이 단계에서 실패하면 사용자가 곧바로 떠난다 |
| ② 간접적인 질문 (“세금 얼마나 내야 하는지 알고 싶어요”) | 한국세무사회 조사에 따르면 세금 관련 문의 중 약 30%가 불명확한 표현으로 시작된다. 처리하지 못하면 “전문가만 쓸 수 있구나”라고 판단하고 이탈한다 |
| ③ 불완전한 정보 (“세금 계산해줘”) | 사용자는 어떤 정보가 필요한지조차 모르는 경우가 많다. 다 알고 있다고 가정하면 전체 사용자의 60% 이상을 잃는다. 필요한 정보를 점진적으로 수집하는 능력이 전문가 시스템과 단순 계산기를 구분 짓는 핵심이다 |
| ④ 다단계 질문 (“연봉 5천만 원에 10억 원짜리 집 두 채가 있을 때 세금은?”) | 실생활에서 세금은 단일 항목으로 계산되지 않는다. 처리하지 못하면 ‘부분적으로만 유용한 서비스’ 로 인식되어 자산가 등 고가치 사용자층을 놓친다 |
| ⑤ 예외(에지) 케이스 (법정 한도 초과, 특별 규정) | 제대로 처리하지 못하면 법적 책임이 따르거나 서비스 신뢰를 잃는다. 특히 세금 분야에서는 잘못된 정보가 금전적 손실로 직결된다. 이런 특수 상황일수록 사용자가 전문적인 도움을 절실히 필요로 하는 순간이다 |
불완전한 정보 케이스는 기대하는 대화 시퀀스 자체를 테스트 케이스로 적어 둡니다.
incomplete_info_cases = [
{
"input": "세금을 계산해줘",
"expected_sequence": [
"에이전트: 어떤 세금을 계산해드릴까요? (소득세/재산세/종부세 등)",
"사용자: 소득세",
"에이전트: 연봉이나 월급을 알려주시겠어요?",
"사용자: 4200만 원",
"에이전트: 4200만 원이 연봉인가요, 월급인가요?",
"사용자: 연봉이요",
"에이전트: 연봉 4200만 원의 소득세는 약 450만 원입니다."
],
"evaluation_points": ["정보 요청의 논리적 순서", "모호함 해소를 위한 확인 질문", "최종 답변의 정확성"]
},
]
이러한 테스트 케이스는 실제 사용자 데이터를 기반으로 하거나 도메인 전문가의 도움을 받아 구축하는 것이 이상적입니다. 카테고리별 테스트 케이스가 없으면 서비스의 사각지대가 생기고, 이는 사용자 이탈과 신뢰도 하락으로 직결됩니다. 특히 세무사, 회계사 등 전문가의 검토를 거쳐 엣지 케이스와 최신 법규 변경 사항을 반영하는 것이 중요합니다.
다양한 평가 지표 설정
지표가 필요한 이유가 셋입니다.
- 예측 불가능성과 객관적 기준의 필요성 — GPT-4의 경우 온도 0.1에서도 약 15~20%의 응답 변동성을 보인다. 주관적 평가만으로는 팀원 간 의견 차이가 발생하고 개선 방향을 결정하기 어려워진다.
- 지속적 개선을 위한 기준점 확립 — 명확한 지표가 없으면 변경이 실제로 개선인지 판단할 수 없다. 프롬프트를 수정한 후 ‘응답이 더 자연스러워졌다’는 느낌이 들어도 정확성이나 완전성 측면에서는 오히려 퇴보했을 수 있다.
- 위험 관리와 품질 보증 — 잘못된 세금 정보는 사용자의 직접적인 금전적 손해로 이어진다. 안전성과 정확성 지표는 법적 리스크를 최소화하는 핵심 도구다.
핵심 지표 여섯 개는 이렇습니다.
| 지표 | 질문 |
|---|---|
| 정확성 | 응답이 사실과 일치하는가? 세금·법률처럼 정확성이 생명인 도메인에서 가장 중요하다 |
| 관련성 | 응답이 질문과 관련이 있는가? 소득세를 물었는데 부가가치세를 설명하면 아무리 정확해도 무의미하다 |
| 완전성 | 질문에 충분히 답변하고 있는가? 일부만 제공해 추가 질문을 여러 번 해야 한다면 사용성이 크게 떨어진다 |
| 효율성 | 응답까지 몇 단계가 필요했는가? 너무 많은 단계는 사용자 경험을 해치고 비용도 증가시킨다 |
| 일관성 | 유사한 질문에 일관된 방식으로 응답하는가? 동일 조건에서 계산 결과가 매번 달라진다면 금융 서비스에서는 치명적이다 |
| 안전성 | 부적절한 요청이나 입력에 적절히 대응하는가? 개인정보 유출이나 잘못된 조언 제공을 방지하는 핵심 지표다 |
이 지표들은 정량적으로 측정할 수 있어야 하며, 지표별로 목표 수치와 허용 임곗값을 설정해 지속적인 모니터링과 개선의 기준으로 활용해야 합니다.
자동화된 평가 파이프라인
평가 프로세스는 가능한 한 자동화되어야 합니다. LangSmith 같은 도구를 활용하면 다섯 단계로 구축할 수 있습니다.
1. 테스트 실행 → 2. 응답 수집 → 3. 평가 실행 → 4. 결과 분석 → 5. 보고서 생성
(자동 입력) (도구 호출· (정의된 (집계 및 (요약 보고)
상태 변화 기록) 지표 적용) 문제점 식별)
이러한 자동화된 파이프라인은 코드베이스의 변경이나 LLM 모델 업데이트를 할 때마다 실행되어 성능의 일관성을 보장할 수 있습니다.
인간 평가와의 결합
자동화된 평가만으로는 모든 측면을 평가하기 어렵습니다. 특히 응답의 품질, 자연스러움, 유용성 같은 주관적 측면에서는 인간 평가자의 피드백이 중요합니다.
- 자동화된 평가: 기본적인 정확성, 일관성, 효율성 등 측정
- 인간 평가: 응답의 품질, 명확성, 사용자 친화성 등 주관적 측면 평가
정리
- LLM은 온도를 0으로 둬도 완벽히 같은 답을 보장하지 못한다. 그래서 오류가 일회성인지 구조적 결함인지 판단하려면 평가가 필요하다.
- 오류를 프롬프트 이해 / 도구 선택 / 도구 사용 / 콘텍스트 관리 / 출력 파싱 다섯 가지로 나누면 디버깅이 쉬워진다.
- 성능 지표는 서로 상충한다. 평가는 성공률·응답 시간·비용 사이의 균형점을 찾는 과정이다.
- 배포에는 세 장치가 필요하다 — 품질 게이트(CI/CD), 회귀 테스트, 가드레일.
- 정답이 하나가 아니다. 문자열 비교로는 안 되고, 주관적 요소는 1~5점 척도와 판단 기준을 함께 명시해 정량화한다.
- 테스트 케이스는 다섯 범주로 나눈다. 특히 불완전한 정보를 처리하지 못하면 사용자의 60% 이상을 잃는다.
- 지표 없이 프롬프트를 고치면 “자연스러워진 느낌”인데 정확성은 퇴보할 수 있다.
- 자동화는 다섯 단계 파이프라인으로, 그리고 주관적 측면은 인간 평가와 결합해 메운다.