💡 글의 핵심 3줄 요약

1. 데모는 잘 되는데 실서비스에서 무너지는 AI를 막으려면, '느낌'이 아니라 숫자로 품질을 측정하는 평가(Eval) 체계가 필수입니다.
2. 손으로 만든 50~100개의 골든 데이터셋과 실제 사용 로그를 기반으로, 정답이 명확한 부분은 코드로, 애매한 부분은 LLM-as-Judge로 채점하는 것이 2026년의 표준입니다.
3. 평가는 한 번 하고 끝이 아니라, 코드를 고칠 때마다 자동으로 돌리고 프로덕션을 실시간 감시하며 실패 사례를 다시 데이터셋에 넣는 순환 구조여야 합니다.

데모는 멀쩡한데 실서비스는 왜 무너질까? AI 에이전트 평가의 모든 것

안녕하세요 여러분! 요즘 AI 에이전트를 직접 만들어 보신 분들이 정말 많아졌죠? 프롬프트 몇 줄 다듬고, 도구 몇 개 연결하고 나면 시연 자리에서는 마법처럼 척척 동작합니다. 그런데 막상 실제 사용자에게 풀어놓으면 이상하게 엉뚱한 답을 내놓거나, 어제는 잘 되던 기능이 오늘은 깨져 있는 경험, 다들 한 번쯤 해보셨을 거예요.

이게 바로 2026년 AI 개발 현장에서 가장 뜨거운 화두인 평가(Evaluation) 문제입니다. 모델을 잘 만드는 것만큼이나, 그 모델이 정말 잘 동작하는지를 객관적으로 증명하는 일이 중요해졌거든요. 오늘은 '내 AI가 정말 괜찮은가?'라는 막연한 질문에 숫자로 답할 수 있게 해주는 평가 엔지니어링 이야기를 차근차근 풀어보려고 합니다.

느낌으로 판단하는 시대는 끝났습니다

예전에는 AI 결과물의 품질을 어떻게 확인했을까요? 솔직히 말하면 개발자가 직접 몇 개 질문을 던져보고 "오, 괜찮은데?" 하고 넘어가는 경우가 대부분이었습니다. 이걸 흔히 '바이브 체크(vibe check)'라고 부르는데요. 문제는 이 방식이 사람의 기분이나 그날의 컨디션에 따라 들쭉날쭉하다는 점입니다.

생각해보면 당연한 일이에요. 일반적인 소프트웨어는 입력이 같으면 출력이 항상 같으니 테스트가 명확하지만, 언어 모델은 같은 질문에도 매번 조금씩 다른 답을 내놓습니다. 게다가 그 답이 '맞다, 틀리다'로 딱 나뉘지 않고 '더 자연스럽다, 덜 정확하다' 같은 애매한 영역에 걸쳐 있죠. 이런 대상을 사람이 매번 눈으로 검수하는 건 규모가 커지면 금방 한계에 부딪힙니다.

그래서 등장한 개념이 바로 평가입니다. AI의 출력을 일정한 기준으로 점수화하고, 그 점수가 시간이 지나도 떨어지지 않는지 추적하는 것이죠. 마치 학생이 시험을 보듯이, AI에게도 정해진 문제집을 주고 채점표로 점수를 매기는 셈입니다. 이렇게 해야만 "프롬프트를 바꿨더니 성능이 3퍼센트 올랐다" 혹은 "모델을 교체했더니 특정 영역에서 오히려 나빠졌다" 같은 판단을 자신 있게 내릴 수 있습니다.

평가의 출발점, 골든 데이터셋 만들기

평가 체계를 세울 때 가장 먼저, 그리고 가장 공들여야 하는 작업이 바로 골든 데이터셋(Golden Dataset)을 만드는 일입니다. 쉽게 말해 'AI가 풀어야 할 모범 문제집'인데요. 의외로 많은 분들이 이 부분을 가볍게 여겼다가 나중에 크게 후회합니다.

데이터셋을 만드는 방법은 크게 두 가지입니다. 첫째는 전문가가 직접 손으로 좋은 질문과 기대하는 답변, 그리고 에이전트가 거쳐야 할 행동 순서를 적어두는 방식이에요. 처음에는 50개에서 100개 정도를 기준 삼아 정성껏 만드는 것을 추천합니다. 숫자는 적어 보여도, 사람이 직접 검증한 이 핵심 묶음이 평가의 뼈대가 되어줍니다.

둘째는 실제 사용자들이 남긴 대화 기록, 즉 프로덕션 로그에서 의미 있는 사례를 캐내는 방식입니다. 진짜 사용자가 어떻게 질문하고 어디서 AI가 헤맸는지가 고스란히 담겨 있으니 이보다 현실적인 자료가 없죠. 다만 집계된 평가 수치를 믿을 만한 수준으로 만들려면 최소 500건 이상은 모으는 것이 좋습니다. 표본이 너무 적으면 우연히 나온 결과에 휘둘리기 쉽거든요.

단순 정답 비교를 넘어, 행동 경로까지 본다

여기서 한 가지 짚고 갈 점이 있습니다. 챗봇이라면 "최종 답변이 맞았는가"만 봐도 되지만, 에이전트는 조금 다릅니다. 에이전트는 목표를 받아 여러 도구를 순서대로 호출하며 일을 처리하니까요. 그래서 최종 결과뿐 아니라 그 과정에서 올바른 도구를 적절한 순서로 불렀는지, 이른바 '행동 경로(trajectory)'까지 함께 평가해야 합니다. 답은 맞았는데 엉뚱한 경로로 돌아왔다면, 그건 운이 좋았던 것이지 잘 동작한 게 아니니까요.

애매한 품질은 AI가 채점한다, LLM-as-Judge

문제집은 만들었는데, 채점은 누가 할까요? 정답이 명확한 항목, 예를 들어 "특정 숫자를 정확히 계산했는가" 같은 건 코드로 기계적으로 채점하면 됩니다. 가장 빠르고 정확하니 가능한 한 이 방식을 우선하는 게 좋아요.

문제는 "이 답변이 사용자에게 친절하고 자연스러운가" 같은 질문입니다. 이런 건 정답을 숫자로 떨어뜨릴 수가 없죠. 여기서 등장하는 영리한 해법이 바로 LLM-as-Judge, 즉 'AI가 AI를 채점하게 하는' 방식입니다. 별도의 언어 모델에게 평가 기준을 자세히 알려주고, 다른 AI가 내놓은 답변에 점수를 매기게 하는 것이죠.

비유하자면 글쓰기 대회에서 채점 기준표를 든 심사위원을 한 명 더 앉히는 것과 비슷합니다. 사람이 일일이 읽는 것보다 훨씬 빠르고, 기준만 잘 정해두면 일관성도 상당히 높습니다. 2026년 현재 LLM-as-Judge는 RAG 시스템부터 복잡한 에이전트까지, 의미적이고 주관적인 품질을 대규모로 검증하는 핵심 도구로 완전히 자리를 잡았습니다. 물론 심사위원 AI도 완벽하진 않으니, 채점 기준을 구체적으로 적고 가끔은 사람이 그 채점 결과를 다시 검수해주는 보완이 필요하다는 점은 기억해 두세요.

평가는 한 번이 아니라 끝없는 순환입니다

마지막으로 가장 중요한 이야기를 해볼게요. 평가는 출시 전에 딱 한 번 하고 끝내는 행사가 아닙니다. 진짜 가치는 이걸 꾸준히 돌릴 때 나옵니다.

가장 좋은 습관은 코드나 프롬프트를 고칠 때마다, 그러니까 풀 리퀘스트를 올릴 때마다 골든 데이터셋으로 자동 평가를 돌리는 것입니다. 이렇게 해두면 "이 수정이 다른 기능을 망가뜨리지 않았는지"를 사람이 일일이 확인하지 않아도 됩니다. 점수가 떨어지면 바로 경고가 울리니까요. 여기에 더해, 어떤 점수가 정확히 어떤 버전의 프롬프트와 모델, 데이터셋에서 나온 건지 거슬러 추적할 수 있게 기록을 남겨두는 '추적 가능성'이 2026년 평가 체계의 핵심 덕목으로 꼽힙니다.

서비스를 운영하는 동안에는 실제 트래픽을 실시간으로 지켜보며 이상 징후에 알림을 걸고, 일주일에 한 번씩 문제 있는 대화를 모아 검토하는 리듬을 권합니다. 그리고 여기서 발견한 실패 사례를 다시 골든 데이터셋에 추가하는 것, 이게 바로 평가를 살아 움직이게 하는 마지막 고리입니다. 실패가 곧 다음 시험 문제가 되는 셈이죠. 이 순환이 돌기 시작하면, 여러분의 AI는 시간이 갈수록 더 똑똑해지는 게 아니라 더 믿을 만해집니다.

결론: 잘 만드는 것보다 잘 검증하는 것

지금까지 AI 에이전트의 품질을 객관적으로 측정하는 평가 엔지니어링에 대해 살펴봤습니다. 느낌으로 판단하던 시대를 넘어 골든 데이터셋을 만들고, 정답이 명확한 건 코드로 애매한 건 LLM-as-Judge로 채점하며, 이 모든 과정을 끊임없이 순환시키는 것까지 이야기했네요.

화려한 데모는 누구나 만들 수 있지만, 실서비스에서 사용자의 신뢰를 얻는 AI는 탄탄한 평가 체계 위에서만 탄생합니다. 결국 AI 개발의 승부처는 '얼마나 멋진 걸 만드느냐'에서 '얼마나 믿을 수 있게 검증하느냐'로 옮겨가고 있는 셈이죠.

여러분도 지금 만들고 있는 AI가 있다면, 거창한 시스템부터 갖추려 하기보다 우선 모범 문제 열 개를 손으로 적어보는 것에서 시작해보면 어떨까요? 그 작은 문제집 하나가 막연했던 품질을 또렷한 숫자로 바꿔주는 첫걸음이 되어줄 거예요. 검증할 수 있어야 비로소 개선할 수 있다는 사실, 꼭 기억하시길 바랍니다!