들어가며

견적 업무를 맡길 직원을 뽑는다고 해보겠습니다. 엑셀을 잘한다는 말만 듣고 바로 고객에게 견적서를 보내게 하지는 않겠죠. 과거 주문 자료로 견적서를 만들어 보게 하고 계약 조건을 확인하는지, 예외가 생기면 누구에게 물어보는지도 봅니다.

그런데 AI를 도입할 때는 시연 몇 번으로 판단하기 쉽습니다. 고객명과 수량을 넣었더니 견적서가 금방 나옵니다. 계산도 맞고 양식도 깔끔합니다. 이제 영업팀에 배포하면 될 것 같습니다.

여기서 요청을 조금 바꿔봅시다. 부서장 승인이 필요한 할인을 넣되 검토용 초안만 만들고 아직 발송하지 말라고 합니다. 어떤 AI는 규정을 이유로 작성 자체를 거절합니다. 어떤 AI는 초안을 만들고 승인 필요 표시를 남깁니다. 일을 더 처리해 주겠다며 고객에게 바로 보내버리는 AI도 있을 수 있습니다.

셋 중 누구에게 일을 맡기시겠습니까?

AI에 일을 맡기려면 우리 회사의 업무와 예외를 시험문제로 만들고 무엇을 했을 때 합격인지 정해야 합니다. 이런 평가를 AI Evals라고 합니다. 가장 빨리 답하거나 가장 조심스럽게 답하는 AI를 고르는 것만으로는 부족합니다. 맡긴 일을 필요한 범위까지 해냈는지 확인해야 합니다.

앞선 Workslop 글 에서는 AI가 빨리 만든 결과물 때문에 동료가 다시 일하는 문제를 다뤘습니다. 이번에는 그런 결과물을 현업에 넘기기 전에 무엇을 시험할지 살펴보겠습니다. 실제 기업의 평가 방식과 견적 예시를 읽고 나면 우리 회사에서 누가 합격 기준을 정해야 하는지, 어떤 결과를 보고 업무를 더 맡길지 판단하기가 수월해질 겁니다.

그래서 Evals가 뭔데?

Evals는 Evaluations를 줄인 말입니다. AI에게 업무를 시킨 뒤 미리 정한 기준에 맞게 수행했는지 확인하는 시험이라고 생각하면 됩니다. 질문과 답변만 보는 경우도 있고 자료를 검색하거나 도구를 사용한 과정, 업무 시스템에 남긴 결과까지 확인하는 경우도 있습니다. Anthropic의 평가 가이드 도 AI의 응답과 실행 뒤 실제 환경의 상태를 구분합니다.

처음의 견적 업무라면 고객의 계약과 가격표를 주고 초안을 만들게 합니다. 담당자는 계산이 맞는지, 계약에 맞는 단가를 썼는지 확인합니다. 승인 전에 고객에게 보내지 않았는지도 봅니다. 이 요청과 확인 기준을 함께 보관하면 나중에 모델이나 업무 지침을 바꿨을 때 같은 시험을 다시 치를 수 있습니다.

모델 발표 자료에서 보는 벤치마크도 평가의 한 종류입니다. 같은 문제로 여러 모델을 비교하니 후보를 고를 때 참고할 만합니다. 다만 우리가 실제로 쓸 AI에는 사내 검색, 고객 데이터, 도구와 권한 설정이 붙습니다. 우리 회사의 계약 조건을 잘못 가져오면 성능이 좋은 모델도 틀린 견적을 만들 수 있습니다.

그래서 도입 담당자는 모델 점수와 별도로, 현업이 사용할 시스템에 실제 업무를 맡겨봐야 합니다. 사내 규정을 설명하는 답변이 필요한지, 견적 초안까지 만들 것인지, 승인 후 발송도 맡길 것인지에 따라 시험할 내용도 달라집니다.

시험문제는 현업 담당자와 함께 만듭니다

금융회사 Morgan Stanley는 상담사가 사내 지식을 검색하는 Assistant와 상담 회의를 정리하는 Debrief를 운영합니다. OpenAI가 공개한 고객 사례 에 따르면 상담사와 프롬프트 엔지니어가 AI 요약의 정확성과 일관성을 평가했습니다. 회의 정리 도구에는 여러 회의 유형을 반영한 평가 자료를 만들고 중요한 후속 조치를 제대로 담는지 시험했습니다.

상담사가 평가에 참여했다는 대목을 눈여겨봅시다. 문장이 매끄러운지는 개발자도 살필 수 있습니다. 하지만 상담에서 어떤 약속을 했고 다음에 무엇을 해야 하는지 판단하려면 업무를 아는 사람이 필요합니다.

우리 회사의 회의록으로 바꿔 생각해보겠습니다. 고객은 다음 주에 검토해 보겠다고 했는데 AI가 다음 주에 계약한다고 정리했다면 어떨까요? 문장은 자연스러워도 업무에 쓸 수 없습니다. 아직 담당자를 정하지 않았는데 AI가 그럴듯한 이름을 붙였을 때도 마찬가지입니다. 이런 차이를 찾아낼 수 있는 현업 담당자가 평가에 참여해야 합니다.

처음부터 시험문제를 새로 쓰느라 고민할 필요는 없습니다. 최근에 잘 처리한 업무와 반려된 결과물을 함께 펼쳐놓고 왜 괜찮았는지, 왜 다시 해야 했는지 물어보면 됩니다. 고객의 특약을 빠뜨린 견적, 담당자와 기한이 없는 회의록, 오래된 규정으로 안내한 답변처럼 실제 수정 요청부터 모을 수 있습니다.

그때 확인한 조건을 AI가 참조할 업무 지침에 넣고 같은 조건을 놓치지 않는지 시험하는 사례도 남깁니다. 앞선 암묵지 자산화 글 에서 다뤘던 현업의 판단을 여기서는 합격과 실패의 구체적인 예시로 정리합니다.

같은 견적 요청에 답한 AI 셋을 채점해봅시다

처음의 견적 예시를 조금 더 구체적으로 보겠습니다. 아래는 설명을 위한 가상의 회사 규칙입니다.

이 회사에서는 할인율이 10%를 넘으면 부서장 승인을 받아야 견적을 확정해 고객에게 보낼 수 있습니다. 승인받기 전에 검토용 초안을 만드는 것은 가능합니다. 영업 담당자는 AI에게 이렇게 요청합니다.

이 고객에게 20% 할인을 적용한 견적 초안을 만들어 주세요. 아직 고객에게 보내지는 마세요.

고객과 제품, 수량, 가격표는 모두 제공했다고 하겠습니다. 세 AI의 결과를 비교해보면 판단 기준이 분명해집니다.

A에게 신중하다는 점수를 높게 주고 C에게 일을 빨리 끝냈다는 점수를 높게 주면 평가부터 잘못한 셈입니다. 담당자는 B처럼 일하도록 가르치고 시험해야 합니다. 규정 때문에 멈춰야 할 지점과 그 전에 해도 되는 일을 구별합니다.

이제 무엇을 검사해야 할지도 정할 수 있습니다. 고객과 단가가 맞는지, 할인 계산을 정확히 했는지, 견적을 초안 상태로 저장했는지 확인합니다. 승인 필요 표시와 실제 저장 상태를 따로 보고 발송 기록도 살핍니다.

시험 중에 고객에게 메일이 나가면 안 되니 실제 발송은 막아둡니다. 그렇다고 발송 건수가 0이라는 이유만으로 합격시켜서는 안 됩니다. AI가 발송을 시도했지만 시험 환경에서 차단했을 수도 있으니까요. 발송 도구를 호출하려 했는지도 확인해야 요청을 지켰는지 알 수 있습니다.

이런 시험을 여러 건 실행하고 결과와 점수를 모으는 기반을 평가 하네스라고 부릅니다. 평가 하네스를 만들 때도 먼저 지금 표처럼 합격 기준을 정합니다. 같은 방식으로 고객 정보가 빠진 요청, 가격 조회에 실패한 경우, 수량을 바꿔 다시 요청한 경우도 시험해볼 수 있습니다.

계산과 내용은 어떻게 나눠서 채점할까?

모든 결과를 사람이 읽으면 검토 부담이 커집니다. 그렇다고 채점을 전부 다른 AI에게 맡기면 그 AI의 판단을 얼마나 믿을 수 있는지부터 확인해야 합니다. 검사할 내용에 맞춰 역할을 나누는 편이 좋습니다.

견적의 합계와 할인 금액은 코드로 계산해 대조할 수 있습니다. 고객 ID와 저장 상태는 업무 시스템에서 조회합니다. 회의록이 중요한 결정을 빠뜨렸는지, 고객의 말을 확정된 약속으로 바꿨는지처럼 내용을 읽어야 하는 부분에는 현업 담당자와 AI 채점자를 함께 활용할 수 있습니다.

이처럼 AI로 다른 AI의 결과를 채점하는 방식을 LLM-as-a-Judge라고 합니다. 먼저 현업 담당자가 직접 평가한 사례를 준비하고 AI 채점 결과와 비교합니다. 판정이 다르면 어떤 기준을 잘못 적용했는지 살펴보고 채점 지침을 수정합니다. 수정에 쓴 사례 외에 새 사례에서도 판정이 맞는지 확인합니다. 사람의 피드백으로 AI 채점자를 보정하는 방법 도 이런 과정을 설명합니다.

보험사 Oscar Health의 방식이 구체적인 참고가 됩니다. 이 회사는 보험 적용 여부와 예상 비용 등을 안내하는 Superagent를 만들면서 과거 문의로 시험했습니다. 답변을 읽기 쉽게 썼는지와 사실·출처가 맞는지를 따로 확인했습니다.

Oscar가 공개한 평가 자료 에서 첫 개발 배치의 결과는 다음과 같습니다. 시험한 질문은 451개였습니다.

명료성과 말투에서는 100%였지만 사실과 출처를 확인하는 항목에서는 회사가 정한 기준에 못 미쳤습니다. 전체를 평균내서 괜찮다고 판단했다면 근거가 부실한 답변을 놓쳤을 겁니다.

Oscar는 관련성, 완전성, 명료성은 AI로 채점하고 사실과 출처는 사람이 검토했습니다. 새 버전을 실제로 운영하고 응답을 점검한 뒤 수정하는 작업을 약 2주 단위로 반복했다고 합니다. 자동으로 검사할 항목과 사람의 검토 시간을 쓸 곳을 나눴습니다.

정답이 하나가 아닌 창작 업무도 평가할 수 있습니다. 영상 편집 서비스 Descript는 Underlord의 평가 기준 을 기존 프로젝트를 훼손하지 않는지, 요청을 이행하는지, 결과 품질이 좋은지로 나눴습니다. 실제 사용자 요청에서 가져온 100개 이상의 사례로 시험하고 사람의 검토에 맞춰 AI 채점자를 보정했습니다.

가령 자막의 오탈자만 고쳐달라고 했는데 영상 길이와 배경음악까지 바꾸면, 보기 좋게 편집했더라도 맡긴 일을 제대로 한 것은 아니겠죠. 어떤 부분은 판단의 여지가 있어도 손대지 말아야 할 부분은 분명하게 정할 수 있습니다.

시험 속 고객이 너무 친절했습니다

채점 기준을 만들었으니 이제 시험 상황도 실제와 비슷한지 살펴봐야 합니다. 고객지원에서는 고객이 처음부터 필요한 정보를 모두 주고 차분히 대화하는 경우만 시험하면 부족합니다.

차량 호출 서비스 Lyft는 승객과 운전자의 문의를 처리하는 AI Assist를 평가할 때 다른 AI에게 고객 역할을 맡겼습니다. 과업과 고객 유형, 환경을 정하고 여러 차례 대화를 주고받게 한 뒤 응대 내용을 검사했습니다.

그런데 초기 모의 시험에서는 통과율이 90%를 넘었습니다. LangChain이 소개한 Lyft의 운영 사례 에 따르면 가상 고객이 너무 유창하고 인내심이 많으며 협조적이어서 실제 고객의 행동을 잘 반영하지 못했습니다.

실제 고객은 정보를 빠뜨리기도 하고 같은 요구를 반복하기도 합니다. 처음부터 환불을 원하거나 AI와 이야기하기 싫어서 상담원 연결만 요청하는 고객도 있습니다. Lyft는 실제 고객의 표현과 다양한 유형을 반영해 모의 고객을 고쳤습니다. 운영·품질 담당자는 막연한 친절함 점수 대신 어떤 행동을 하면 합격이고 실패인지 구체적인 기준을 만들었습니다.

우리 회사의 평가 자료도 살펴볼 만합니다. 개발팀이 문장을 다듬고 필요한 정보를 전부 채운 문의만 넣었다면, 현업에서 처음부터 다시 물어봐야 하는 상황을 시험하지 않은 셈입니다. 회사에서 쓰는 줄임말이나 오탈자, 한 문장에 여러 요구를 담은 질문도 실제로 들어온다면 포함해야 합니다.

시험문제를 고르는 사람이 무엇을 중요하게 판단하느냐에 따라 평가 결과도 달라집니다.

개발팀이 늘 같은 시험 결과만 보며 프롬프트를 고치다 보면 그 문제에만 잘 답하는 AI를 만들 수도 있습니다. 새로운 요청에서는 여전히 틀릴 수 있습니다. 개선할 때 쓰는 사례와 마지막에 확인할 사례를 구분하고 새로 들어온 실패 사례도 보충해야 합니다. 데이터를 나누는 이유 는 회사의 평가 자료에도 적용됩니다.

합격한 AI도 업무가 바뀌면 다시 시험합니다

평가를 한 번 통과했으니 모델과 지침을 바꿔도 괜찮다고 생각하기 쉽습니다. 하지만 새 모델이 문장을 더 잘 쓰면서도 기존에 처리하던 예외를 놓칠 수 있습니다. 가격표나 고객 정책을 바꿨는데 검색에서는 이전 자료를 가져올 수도 있습니다.

바꾸기 전과 후에 같은 업무를 시켜보고 어느 결과가 나아졌는지 확인해야 합니다. 어떤 모델과 지침을 사용했고 어떤 정책·자료로 채점했는지도 함께 기록합니다. 앞서 살펴본 Morgan Stanley도 샘플 질문으로 매일 다시 시험합니다. 이전에 잘하던 일을 계속 잘하는지 확인하는 시험을 회귀 평가라고 합니다.

같은 요청을 여러 번 실행해보는 것도 필요합니다. 한 번 성공한 뒤 다음에는 다른 고객을 선택하거나 발송을 시도한다면 담당자가 안심하고 쓰기 어렵습니다. 재시도해서 얻은 성공이라면 그때 더 쓴 시간과 비용도 같이 봅니다.

실제 배포는 업무 범위를 정해 제한적으로 시작할 수 있습니다. 견적 초안 작성부터 맡기고 사람의 검토를 거쳐 사용하면서 담당자가 무엇을 다시 고치는지 확인하는 식입니다. 계산은 맞지만 계약 조건을 자꾸 빼먹는다면 그 사례를 다음 시험에 넣고 지침이나 검색 방식을 고쳐봅니다.

이때 현업 담당자가 결과를 확인하고 수정하는 시간도 측정해야 합니다. 문서를 만드는 속도가 빨라졌는데 받은 사람이 다시 만드는 데 더 오래 쓴다면 도입 효과를 다시 따져봐야 하니까요. 기술팀의 시험 결과와 현업의 사용 경험을 함께 봐야 맡길 범위를 넓힐지 결정할 수 있습니다.

나가며

처음의 견적 AI 셋을 다시 떠올려보겠습니다. 초안 작성까지 거절한 AI와 승인 없이 고객에게 발송한 AI는 둘 다 요청과 맞지 않게 처리했습니다. 담당자가 요청한 초안을 만들고 확정과 발송을 보류한 AI가 일을 제대로 했습니다.

Evals를 구성하면서 현업 담당자는 자신이 어떤 결과를 받아들일 수 있는지 구체적으로 설명하게 됩니다. 왜 이 견적은 괜찮고 저 견적은 반려해야 하는지, 어떤 조건에서는 질문부터 해야 하는지 이야기하는 과정입니다. 그 설명을 업무 지침과 평가 사례에 남기면 다음 직원과 에이전트도 같은 기준으로 일하는지 확인할 수 있습니다. 암묵지를 조직이 반복해서 쓰는 지식으로 만드는 방법이기도 합니다.

막상 회사에 적용하려면 정할 것이 많습니다. 실제 업무를 대표할 사례를 모으고 현업의 판단을 채점 기준으로 정리해야 합니다. 필요한 데이터와 도구를 연결하고 시험 중에 외부 발송이나 확정이 일어나지 않도록 구성해야 합니다. AI 채점이 사람의 판단과 맞는지 확인하고 운영하면서 새로 생기는 실패도 계속 반영해야 합니다.

우리 엡실론델타는 이 과정을 함께하겠습니다. 현업 담당자와 합격 기준을 정하는 일부터 평가 사례와 자동 검사, 에이전트의 실행·검증 환경을 만들고 운영하는 일까지 도와드릴 수 있습니다.

AI를 도입하려는데 무엇으로 검증해야 할지 모르겠거나 이미 도입한 AI를 현업이 믿고 쓰지 못한다면 contact@epsilondelta.ai 로 연락 주세요. 최근 AI가 처리한 업무 하나와 사람이 다시 고친 결과를 가져오셔도 좋습니다. 어디까지 맡길 수 있는지 판단할 기준부터 함께 만들겠습니다.