새로운 AI 모델이 공개될 때마다 기업은 같은 질문을 합니다. “지금 쓰는 모델보다 좋아졌을까?”, “바꾸면 비용은 줄고 품질은 유지될까?”, “우리 업무에도 벤치마크만큼 잘할까?” 그런데 자체 평가 기준이 없는 조직은 결국 몇 명이 데모를 써 본 인상이나 공개 순위에 의존합니다. 모델은 빠르게 바뀌지만 의사결정 방식은 매번 처음으로 돌아갑니다.
기업이 장기적으로 축적해야 할 자산은 특정 모델의 프롬프트가 아니라 자사 업무에서 좋은 결과와 나쁜 결과를 구분하는 평가 데이터셋입니다. 실제 사용자 질문, 어려운 예외, 금지 행동, 정답과 성공 조건을 구조화해 두면 새 모델·프롬프트·RAG·에이전트 구조를 같은 기준으로 비교할 수 있습니다.
핵심: 모델은 누구나 살 수 있지만, 우리 업무에서 무엇이 성공인지 측정하는 기준은 조직이 직접 축적해야 한다.
데모는 잘 되는데 운영에서 흔들리는 이유
데모에는 보통 잘 정리된 질문과 대표 문서를 사용합니다. 개발자는 모델이 이해하기 쉬운 표현을 알고 있고, 답이 이상하면 바로 프롬프트를 다듬습니다. 반면 실제 사용자는 오타가 섞인 짧은 질문을 던지고, 여러 요구를 한 문장에 넣으며, 오래된 문서와 최신 문서를 함께 검색합니다.
운영 환경에서는 다음과 같은 차이가 생깁니다.
- 질문에 필요한 정보가 누락되거나 서로 모순된다.
- 정답이 하나가 아니라 업무 규정과 상황에 따라 달라진다.
- 모델 답변은 그럴듯하지만 근거 문서와 맞지 않는다.
- 에이전트가 최종 답은 맞혀도 불필요한 도구를 호출한다.
- 한 언어·상품·고객군에서는 좋지만 다른 구간에서 급격히 나빠진다.
- 모델이나 검색 인덱스가 바뀐 뒤 과거에 되던 질문이 실패한다.
이 문제를 프롬프트 수정만으로 따라가면 한 사례를 고칠 때 다른 사례가 망가지는 회귀가 반복됩니다. 자동화된 평가가 필요한 이유입니다.
평가 데이터셋은 ‘정답 모음’보다 넓다
전통적인 분류 모델에서는 입력과 정답 라벨이 있으면 평가가 비교적 단순합니다. 생성형 AI와 에이전트는 성공의 형태가 더 복잡합니다. 좋은 평가 사례에는 최소한 다음 요소가 필요합니다.
- 업무 맥락: 사용자 역할, 권한, 제품, 시점, 적용되는 정책
- 입력: 질문, 문서, 이미지, 대화 이력, 도구 상태
- 성공 조건: 반드시 포함할 사실, 허용되는 변형, 완료되어야 할 시스템 상태
- 금지 조건: 만들어내면 안 되는 정보, 호출하면 안 되는 도구, 넘으면 안 되는 권한
- 평가 방식: 코드, 규칙, 모델 채점, 전문가 검토 중 어떤 방법을 쓸지
- 중요도: 실패가 불편 수준인지 금전·안전·법적 피해로 이어지는지
- 출처와 버전: 어떤 운영 실패·요구사항에서 왔고 언제 유효한 기준인지
고객 상담 사례라면 모범 답변 문장 하나를 정답으로 고정할 필요는 없습니다. 환불 조건을 정확히 설명하고, 확인되지 않은 배송일을 만들지 않으며, 필요한 경우 상담원에게 이관하는지를 각각 채점할 수 있습니다. 표현은 달라도 업무적으로 성공한 답을 인정해야 합니다.
평균 점수 하나가 위험한 이유
전체 평가 점수가 90점에서 92점으로 올랐다고 항상 개선은 아닙니다. 자주 들어오는 쉬운 질문은 좋아졌지만 중요한 계약 검토나 개인정보 처리 질문이 나빠졌을 수 있습니다. 데이터 구성에 따라 평균은 쉽게 왜곡됩니다.
평가 결과는 최소한 업무 유형, 난이도, 고객군, 언어, 위험 등급으로 나눠 봐야 합니다. 중요한 사례에는 더 높은 가중치나 반드시 통과해야 하는 조건을 둡니다. 안전·권한·금전 관련 사례는 전체 평균이 높아도 한 건의 심각한 실패가 배포를 막을 수 있어야 합니다.
평가의 다섯 층을 조합한다
생성형 AI는 한 가지 채점 방식으로 충분하지 않습니다. NIST의 AI 위험관리 프레임워크도 객관적이고 반복 가능한 테스트·평가·검증 절차와 문서화를 강조합니다. 실무에서는 빠르고 확실한 검사부터 사람의 전문 판단까지 층을 쌓는 편이 좋습니다.
1층: 결정적 검사
형식, 숫자, ID, 날짜, 데이터베이스 상태처럼 코드로 확인할 수 있는 것은 코드로 검사합니다. JSON 스키마 통과 여부, 필수 필드, 금지어, SQL 결과, 파일 생성 여부, API 호출 횟수는 모델 채점보다 빠르고 일관됩니다.
2층: 규칙과 참조 비교
키워드 포함, 허용 오차 안의 숫자, 인용 문서 ID, 분류 라벨을 비교합니다. 정확히 같은 문장만 인정하는 방식은 자연스러운 표현을 부당하게 실패 처리하므로 업무 의미에 맞는 허용 범위를 정해야 합니다.
3층: 모델 기반 채점
도움 정도, 근거 충실도, 문체, 누락처럼 코드로 표현하기 어려운 기준은 별도 모델이 루브릭에 따라 채점할 수 있습니다. 단, 채점 모델도 오류가 있으므로 사람의 판단과 주기적으로 비교해 보정해야 합니다.
4층: 도메인 전문가 검토
법률, 의료, 제조, 재무처럼 맥락이 중요한 영역은 전문가 합의가 기준입니다. 모든 사례를 사람이 검토하기보다 고위험 사례, 채점기 간 의견이 다른 사례, 새 유형을 표본으로 검토합니다.
5층: 운영 모니터링
사전 평가는 알려진 문제를 측정합니다. 실제 운영에서는 새로운 표현과 환경 변화가 나타납니다. 사용자 피드백, 재질문, 상담원 이관, 작업 취소, 수정 행동을 품질 신호로 수집해 평가 데이터로 되돌려야 합니다.
LLM 심사위원을 맹신하면 안 된다
모델 기반 채점은 확장성이 좋지만 객관적인 정답은 아닙니다. 긴 답변을 더 좋게 보거나, 특정 표현 방식과 자신이 생성했을 법한 답을 선호할 수 있습니다. 루브릭이 모호하면 같은 답에도 점수가 흔들립니다.
“좋은 답변인가?” 대신 기준을 분리합니다. 핵심 사실이 모두 있는가, 근거와 주장이 연결되는가, 불확실성을 표시했는가, 금지된 조언을 하지 않았는가처럼 한 번에 한 속성을 평가합니다. 점수의 각 단계에는 관찰 가능한 예시를 제공합니다.
채점기는 전문가가 이미 판정한 교정 세트로 검증합니다. 사람과의 일치율, 거짓 양성·거짓 음성, 특정 범주에서의 편향을 봅니다. 모델이나 루브릭을 바꿀 때는 과거 결과와 비교해 채점 기준 자체가 이동하지 않았는지 확인해야 합니다.
에이전트는 답변보다 결과와 경로를 평가한다
에이전트가 “예약을 완료했습니다”라고 답했다고 성공한 것이 아닙니다. 실제 예약 레코드가 올바른 날짜와 고객으로 생성됐는지 확인해야 합니다. Anthropic의 에이전트 평가 가이드도 최종 출력, 전체 실행 기록, 환경의 최종 상태를 구분합니다.
에이전트 평가에서는 다음 세 가지를 함께 봅니다.
- 결과: 업무 목표가 실제 시스템 상태에서 달성됐는가
- 경로: 적절한 도구를 필요한 만큼 호출하고 권한과 승인 절차를 지켰는가
- 상호작용: 필요한 정보를 사용자에게 물었고 진행 상황과 실패를 정확히 설명했는가
정답에 도달했더라도 다른 고객의 데이터를 조회했거나, 같은 결제를 두 번 시도했거나, 금지된 우회 경로를 사용했다면 실패입니다. 반대로 계획한 순서와 달라도 안전하게 더 나은 결과를 만든 경우에는 평가 기준이 지나치게 구현 방식에 묶이지 않았는지 살펴야 합니다.
확률적 시스템은 여러 번 실행해야 한다
같은 입력도 매번 결과가 달라질 수 있습니다. 한 번 성공한 사례를 통과로 처리하면 실제 안정성을 과대평가합니다. 중요한 업무는 동일한 조건에서 여러 번 실행해 성공률과 최악의 실패를 확인합니다.
예를 들어 열 번 중 아홉 번 성공하는 에이전트는 데모에서 좋아 보이지만, 하루 만 건을 처리하면 실패가 천 건입니다. 평균 성공률과 함께 연속 실패, 심각한 오류가 한 번이라도 발생했는지, 실행 비용과 단계 수의 분산을 봐야 합니다.
첫 데이터셋은 20~50개로도 시작할 수 있다
평가를 미루는 가장 흔한 이유는 수천 개의 라벨 데이터가 필요하다고 생각하기 때문입니다. 초기에는 영향이 큰 20~50개 사례만 있어도 프롬프트와 모델 변경의 방향을 확인할 수 있습니다. Anthropic도 초기 에이전트 평가를 실제 실패와 수동 테스트에서 가져온 소수의 명확한 과제로 시작할 수 있다고 설명합니다.
초기 사례는 다음 네 바구니에서 고릅니다.
- 핵심 흐름: 가장 자주 발생하고 반드시 성공해야 하는 대표 업무
- 어려운 경계: 정보 부족, 모순, 긴 문서, 복합 요청
- 금지와 안전: 권한 밖 데이터, 민감정보, 위험 행동, 악성 지시
- 과거 실패: 사용자가 신고했거나 담당자가 수동으로 고친 실제 사례
쉬운 사례만 많이 모으면 점수는 높지만 개선에는 도움이 되지 않습니다. 현재 시스템이 자주 틀리면서 사업 영향이 큰 사례를 의도적으로 포함해야 합니다.
좋은 평가 과제의 조건
두 명의 도메인 전문가가 독립적으로 읽고 같은 성공·실패 판단을 내릴 수 있어야 합니다. 요구사항이 모호하면 모델 성능이 아니라 과제 해석 능력을 측정하게 됩니다. 필요한 파일 경로나 기준 시점, 사용할 수 있는 도구, 완료 상태를 구체적으로 적습니다.
또한 과제가 실제로 해결 가능해야 합니다. 필요한 문서가 제공되지 않았거나 정답 데이터가 오래됐는데 모델을 실패 처리하면 평가 신뢰도가 무너집니다. 낮은 점수가 나온 사례는 모델부터 고치기 전에 과제와 채점 기준이 공정한지 먼저 검토합니다.
데이터 오염과 벤치마크 암기를 막는다
평가 데이터가 프롬프트 예시나 학습 데이터에 섞이면 점수는 오르지만 일반화 능력은 좋아지지 않습니다. 개발용 사례, 회귀 평가, 최종 검증 세트를 분리하고 최종 검증의 정답은 제한된 사람만 접근하도록 합니다.
고정된 사례만 반복하면 팀이 점수에 과적합될 수 있습니다. 동일한 성공 조건을 유지하면서 이름, 숫자, 문서 배치, 질문 표현을 바꾼 변형 사례를 만들고, 운영에서 새로 발견된 분포를 정기적으로 추가합니다. 합성 데이터는 빈 구간을 채우는 데 유용하지만 실제 사용자 데이터의 비율과 차이를 추적해야 합니다.
운영 실패를 회귀 테스트로 바꾸는 플라이휠
사용자 신고나 운영 모니터링에서 실패를 발견하면 개인정보를 제거하고 재현 가능한 입력으로 만듭니다. 전문가가 기대 결과와 금지 조건을 정의하고, 기존 시스템에서 실제로 실패하는지 확인합니다. 수정 후에는 이 사례를 회귀 세트에 넣어 모든 모델·프롬프트·검색 변경 때 반복 실행합니다.
이 과정이 쌓이면 고객 지원 기록이 단순한 이슈 목록이 아니라 제품 품질을 지키는 테스트 자산이 됩니다. 모델 공급자가 바뀌어도 동일한 기준으로 며칠 안에 적합성을 검증할 수 있습니다.
평가 세트와 운영 데이터는 개인정보가 될 수 있다
실제 실패 사례에는 고객 이름, 계약 내용, 건강정보, 내부 문서가 포함될 수 있습니다. 평가 환경이 운영 환경보다 접근 통제가 약하면 데이터셋 자체가 새로운 유출 경로가 됩니다.
수집 단계에서 목적과 보관 기간을 정하고, 직접 식별자를 가명값으로 바꾸며, 꼭 필요한 문장만 남깁니다. 원본과 익명화 사례를 분리하고 접근 권한과 다운로드를 기록합니다. 외부 모델로 평가할 때 전송 가능한 데이터인지, 공급자의 보존·학습 정책은 무엇인지 확인합니다.
배포 파이프라인에 평가를 넣는 법
모든 변경에 전체 평가를 돌리면 느리고 비용이 큽니다. 계층적으로 운영합니다. 개발 중에는 소규모 핵심 세트를 빠르게 실행하고, 병합 요청에는 관련 범주의 회귀 세트를 돌립니다. 배포 전에는 전체 세트와 반복 시험을 실행하며, 운영에서는 일부 실제 요청을 지속 평가합니다.
배포 기준에는 품질, 안전, 비용, 지연시간을 함께 넣습니다. 전체 점수가 좋아도 중요 범주의 하락이나 심각한 안전 실패가 있으면 차단합니다. 새 모델을 일부 트래픽에만 적용하고 문제가 생기면 이전 버전으로 즉시 돌아갈 수 있도록 모델·프롬프트·검색 인덱스 버전을 묶어 관리합니다.
누가 평가 데이터셋을 소유해야 하나
AI팀만 소유하면 기술적으로 측정하기 쉬운 항목에 치우칩니다. 현업만 소유하면 자동 실행과 버전 관리가 어렵습니다. 플랫폼팀은 실행 환경과 공통 채점기를 관리하고, 제품·현업 담당자는 실제 과제와 성공 기준을 소유하며, 보안·법무는 고위험 기준을 검토하는 분업이 적합합니다.
새 기능 요구사항을 작성할 때 평가 사례도 함께 제안하게 하면 “좋은 결과”에 대한 모호함이 개발 전에 드러납니다. 평가 데이터 변경도 코드처럼 리뷰하고, 누가 왜 기준을 바꿨는지 이력을 남깁니다.
30일 도입 계획
1주차: 성공과 실패를 문장으로 정의한다
AI 기능 하나를 선택해 현업·개발·운영이 함께 성공 조건, 금지 조건, 가장 비싼 실패를 적습니다. 기존 수동 테스트와 최근 고객 문의에서 대표 사례를 모읍니다.
2주차: 20~50개 핵심 세트를 만든다
개인정보를 제거하고 범주와 위험도를 붙입니다. 코드로 검사할 항목과 모델·사람이 판단할 항목을 분리하고, 현재 운영 버전의 기준 점수를 확보합니다.
3주차: 반복 실행과 결과 비교를 자동화한다
모델, 프롬프트, RAG 버전을 기록하고 동일 사례를 여러 번 실행합니다. 점수뿐 아니라 실패 예시와 에이전트 실행 경로를 한 화면에서 비교할 수 있게 합니다.
4주차: 배포 게이트와 운영 피드백을 연결한다
심각한 실패와 범주별 최소 기준을 배포 조건으로 넣습니다. 사용자 피드백과 운영 이상을 익명화해 평가 후보로 보내고, 매주 담당자가 새 사례를 검토합니다.
네이처프랙탈이 제안하는 접근
네이처프랙탈은 AI PoC의 성공 여부를 데모 반응만으로 판단하지 않습니다. 실제 업무 사례와 위험도를 먼저 정의하고, 모델·RAG·에이전트의 결과를 반복 측정할 수 있는 최소 평가 세트를 함께 만듭니다. 이후 기존 개발·배포 파이프라인과 운영 모니터링에 평가를 연결해야 품질이 지속됩니다.
이 자산이 있으면 최신 모델이 나올 때마다 유행을 따라갈 필요가 없습니다. 우리 데이터에서 품질, 비용, 속도, 안전을 비교하고 가치가 확인된 경우에만 교체할 수 있습니다. 좋은 AI 조직은 정답을 모두 아는 조직이 아니라, 좋아졌는지 나빠졌는지를 빠르게 측정할 수 있는 조직입니다.
실무 체크리스트
- AI 기능의 성공과 금지 조건을 관찰 가능한 문장으로 정의했는가?
- 대표 흐름뿐 아니라 경계·안전·실제 실패 사례가 포함됐는가?
- 결정적 검사, 모델 채점, 전문가 검토를 적절히 조합했는가?
- 중요 사례를 여러 번 실행하고 최악의 실패를 확인하는가?
- 에이전트의 최종 답변뿐 아니라 도구 경로와 시스템 상태를 평가하는가?
- 개발·회귀·최종 검증 데이터를 분리해 오염을 막는가?
- 평가 데이터의 개인정보와 접근 권한을 관리하는가?
- 운영 실패가 자동으로 다음 회귀 테스트 후보가 되는가?
