5. 에이전트 제품의 품질 검증은 어떻게 하지?

에이전트 품질 측정과 지표 설정

에이전트 프레임워크도 정했고, 내부 기능을 조작하는 '도구(Tool)'도 쥐어주며 에이전트의 능력을 확장했다. 테스트 삼아 채팅창에 명령을 내려보니 꽤 그럴싸하게 동작한다. 그러면 바로 고객에게 제공해도 될까?

절대 아니다. 이제 에이전트를 기획할 때 가장 고통스럽고, 동시에 가장 중요한 단계가 남았다. 바로 '품질 검증(Evaluation)'이다.

기존 화면 기반의 서비스는 QA(품질 검증)가 명확하다. 버튼을 눌러서 팝업이 뜨면 성공, 안 뜨면 버그다. 혹은 API가 정확하게 동작해서 데이터를 조작하면 성공이다. 하지만 자연어로 동작하는 에이전트는 어떨 땐 성공하고 어떨 땐 엉뚱한 소리를 한다.

그렇기에 에이전트를 기획하는 PM은 "이 에이전트가 얼마나 똑똑한가?"라는 모호한 질문을, "이 에이전트는 100점 만점에 85점짜리다"라는 정량적인 지표로 바꿔내야 한다.

이번 글에서는 이 막막했던 에이전트 품질 검증의 개념과 기준(지표)을 어떻게 세웠는지, 그리고 어떤 방법으로 평가를 진행하고 있는지 풀어보려 한다.

챗봇의 평가와 에이전트의 평가는 다르다

에이전트 제품 검증이란 무엇일까? 앞선 글에서 다뤘던 에이전트의 핵심인 "목표(Goal)-맥락(Context)-도구(Tool)"가 잘 맞물려 돌아가서, 고객에게 '의도된 경험'을 정확히 제공하는지 측정하는 것이다.

여기서 단순 챗봇 서비스와 에이전트 서비스의 결정적인 차이가 발생한다.

단순 챗봇은 LLM이 내뱉는 답변의 '정성적인 요소(말투, 문맥의 자연스러움 등)'만 평가하면 된다. 하지만 에이전트는 답변 이면에 숨겨진 "정확한 도구"가 사용됐는지를 반드시 챙겨야 한다.

예시 ©카카오뱅크AI

예를 들어 카카오뱅크 AI에게 "계좌이체 하고 싶어"라고 말했다고 치자. 챗봇이 "네, 계좌이체를 도와드릴게요"라고 텍스트로만 대답하면 아무 소용이 없다. 카카오뱅크 AI 서비스 설계상 화면에 "정확하게 계좌 이체를 할 수 있는 UI 컴포넌트"를 띄워줘야한다.

즉, 에이전트로 동작하는 기능을 측정할 때는 단순히 채팅 메시지뿐만 아니라, 실제 동작하는 API 응답값에 이 UI를 그리기 위한 데이터가 정확히 찍혀서 내려오는지 같이 챙겨야 한다. 그래서 검증 기준을 짤 때는 백엔드와 프론트엔드가 설계한 데이터 인터페이스 문서를 옆에 펴두고 작업하곤 한다. (애초에 인터페이스 설계 단계부터 참여하기도 한다.)

그래서 에이전트 서비스를 기획할 땐, 화면설계 위주의 스킬보다 시뮬레이션, 기술적 지식, 그리고 커뮤니케이션 능력이 더 요구된다.

품질 측정을 하는 두 가지 이유

이렇게 복잡한 품질 측정을 굳이 왜 해야 할까? 크게 두 가지 목적으로 나뉜다.

① 내부 기준점 확립 (벤치마킹): 에이전트의 프롬프트를 수정하거나, LLM 모델을 변경하거나, 새로운 도구를 추가했을 때 "이전보다 나아졌는가?"를 판단하는 기준이 된다.

② 실제 운영 모니터링: 제품이 라이브로 나간 후, 실제 고객이 사용했을 때 본인의 의도를 잘 달성했는지 대화 로그를 바탕으로 측정한다.

어떻게 측정할 것인가? 3가지 평가 방법

측정해야 할 대상은 알겠는데, 그럼 이걸 '누가, 어떻게' 채점할까? 대표적인 에이전트 평가 방법은 아래 세 가지로 나뉜다.

① 인간 평가 (Human Evaluation): 기획자나 QA 담당자가 직접 채팅창에 질문을 던지고, 눈으로 텍스트를 읽고, 개발자 도구나 에이전트 로그(Traces)를 열어 API 로그까지 하나하나 뜯어보는 방식이다.

실무 예시: "기획자용 7점 척도 만들어줘"라고 입력한 뒤, 화면에 챗봇이 자연스럽게 대답했는지 읽어본다. 동시에 백엔드 로그를 뒤져서 create_scale API가 정상 호출됐는지, 파라미터에 scale_type: 7이 제대로 꽂혔는지 확인한다.

장단점: 사람이 직접 맥락을 파악하므로 가장 정확하고 미묘한 예외 상황을 찰떡같이 잡아낸다. 하지만 질의셋이 100개를 넘어가는 순간 눈알이 빠질 것 같고 퇴근이 늦어진다. 대규모 자동화가 불가능하다는 치명적인 단점이 있다.

② 규칙 기반 평가 (Rule-Base): 파이썬 스크립트나 자동화 툴을 이용해, 기대하는 결과값(특정 단어, JSON 키값 등)이 응답에 정확히 포함되었는지 기계적으로 검사하는 방식이다.

실무 예시: 테스트 코드를 짠다. 에이전트가 뱉은 API 응답 JSON 결과물에 "status": 200이 있고, 생성된 척도의 제목 필드에 "기획자"라는 단어가 정확히 일치하여 포함되어 있으면 'PASS' 처리한다.

장단점: 채점 기준이 명확하고 눈 깜짝할 새 수천 개를 자동 채점할 수 있다. 평가에 추가 비용도 안 든다. 하지만 치명적인 한계가 있다. LLM이 제목을 "서비스 기획 직무 평가 척도"라고 유연하게 생성해 버리면, 의미상으론 정답인데 코드 상으로는 'FAIL'이 뜬다. 또한 에이전트가 사용자에게 건넨 자연어 인사말이 얼마나 친절한지 같은 '정성 평가'는 아예 불가능하다.

③ LLM 판단 (LLM-as-a-Judge): 가장 최근에 각광받고, 실무에서 내가 최종적으로 선택한 방식이다. 높은 추론 능력을 가진 모델에게 채점 기준(루브릭)을 쥐여주고 평가를 통째로 맡겨버린다.

실무 예시: 심판관 역할을 할 LLM에게 [사용자 질문], [에이전트의 답변 텍스트], [호출된 API 로그 데이터]를 모두 던져준다. 그리고 프롬프트로 지시한다.

장단점: 사람처럼 문맥을 이해하면서도, 코드처럼 대규모 자동화가 가능하다. 규칙 기반 평가가 잡아내지 못하는 유연한 대답도 의미를 파악해 채점해 낸다. 다만 심판용 LLM을 호출할 때마다 API 비용이 발생하고, 이 심판관이 헛소리하지 않도록 '평가용 프롬프트'를 정교하게 깎아야 하는 또 다른 수고로움이 따른다.

에이전트 품질 측정 지표 설정 노하우

평가 방법을 알았으니, 이제 우리 제품에 맞는 '평가 항목(지표)'을 세워야 한다.

초기에는 4개 축(질의 정확도, 일관성, 중위값 속도, 비용)을 뼈대로 잡았다. 이후 실무에서 에이전트를 굴려보며, 우리 제품 구조의 특성에 맞춰 최종적으로 아래 5가지 지표를 확정했다.

① 의도 충족 (정성): 사용자 의도에 맞는 커뮤니케이션 품질. 에이전트가 기능을 던져주는 것과 별개로, 질문의 맥락에 맞춰 적절한 텍스트 답변을 생성했는지 측정한다.

② 정확성 (정량): 기능 수행의 정합성. A라는 의도가 입력됐을 때 B라는 기능(API)을 정확하게 뱉어내는지, 기대 결과값 대비 꼼꼼하게 체크한다.

③ 일관성 (신뢰도): 유사한 질문을 반복해서 던졌을 때, 의도 파악과 도구 사용 결과가 일관되게 재현되는지 본다.

④ 응답 속도: 에이전트가 단일 도구 혹은 여러 도구를 연쇄적으로 사용할 때 걸리는 시간. (팁: 평가를 할 때는 '단일 의도'를 기준으로 속도를 재는 것이 노이즈를 줄이는 방법이다.)

⑤ 안정성: 서비스의 에러 발생 정도. 모델이 터지든, 우리 서버가 터지든 사용자에게 답변이 안 가면 실패다. 보통 에이전트의 조회 도구가 가져오는 응답값이 많아 토큰 한도를 초과할 때 잘 터지는데, 이를 모니터링하고 도구를 최적화할 때 주로 활용한다.

루브릭 설정, LLM-as-a-Judge를 선택한 이유

이 5가지 지표를 바탕으로 0점부터 5점까지 촘촘한 루브릭(채점 기준표)을 설계했다.

"의도 충족" 지표 루브릭 예시 ©작가편집

에이전트는 단순히 맞다/틀리다(Pass/Fail)로 측정하기엔 결괏값이 너무 복합적이다. 예를 들어 도구는 정확하게 썼는데 텍스트 대답이 퉁명스럽거나, 대답은 잘했는데 파라미터 하나를 빼먹을 수도 있다. 그래서 점수별 의미를 세밀하게 정의해야 한다.

이 루브릭을 채점하는 방법으로는 LLM-as-a-Judge를 사용하는 것으로 의사결정했다.

사실 '정확성' 지표 같은 경우, 응답값에 특정 데이터가 있는지 확인하는 거라 Rule-Base(로직 평가)로 처리하는 게 더 깔끔할 수 있다. 하지만 아직 내부적으로 여러 에이전트 구조를 실험하는 단계라 데이터 인터페이스가 수시로 변한다. 지금 섣부르게 룰 베이스 평가 코드를 짰다가는 유지보수가 힘들다. 게다가 요즘 최상위 모델(gpt-5.4 등)의 성능이 워낙 뛰어나서, 명확한 기준만 주면 로직만큼이나 정확하게 API 응답값의 정합성을 판단해 낸다.

평가용 프롬프트 일부 ©작가편집

그러면 실제 사용자 피드백은 어떻게 수집하지?

내부 품질 측정은 위에서 만든 지표와 루브릭으로 자동화를 돌리면 된다. 그런데 진짜 문제는 제품 출시 후, 외부의 실제 사용자 피드백을 어떻게 수집하고 분석할 것인가다.

솔직히 말해서 이 부분은 아직도 명확한 정답을 찾지 못해 매일 고민하고 있다. 현재 머릿속에 맴도는 선택지들은 이렇다.

① 직접적인 피드백 수집: 챗봇 응답 말풍선 옆에 '좋아요/별로예요(Thumbs up/down)' 버튼을 다는 가장 클래식한 방법. 하지만 B2B 솔루션 특성상 사용자들이 굳이 버튼을 눌러줄까 하는 의문이 있다.

② 로그 추출(Export) 및 후행 평가: 사용자의 실제 대화 로그를 주기적으로 뽑아내서, 우리가 구축한 내부 평가 기준(LLM Judge)에 넣고 재채점한다. 일단 이 방향을 채택했다. 전처리 과정이 필요한데, 일단 수동으로 진행하면서 점차 자동화할 생각.

③ 보안 및 악용 모니터링: 사용자가 에이전트를 속이려는 프롬프트 탈취(Prompt Injection)이나 탈옥(Jailbreak)을 시도하진 않았는지 탐지하는 로직.

어떤 방법이 가장 리소스 대비 뾰족한 인사이트를 줄지 아직은 확신하기 어렵다. 일단 가능한 방법들을 섞어 써보며 우리 제품에 맞는 최적의 운영 피드백 루프를 찾아가는 중이다.

이 다음엔?

에이전트 품질 측정을 위한 채점 기준(지표)과 평가 측정 방식(LLM Judge)을 세팅했다. 하지만 가장 중요한 게 남았다. '무엇을 물어보고 어떤 게 정답인지' 적힌 질의다.

다음 글에서는 '질의 데이터셋(Golden Set)'을 어떻게 구축했는지 공유할 예정이다. 수백 개의 테스트 시나리오를 쪼개고, 약 1,000개 이상의 질의를 깎아 만든 노하우를 다룬다.

ⓒ 2026. 327roy All rights reserved.