AI 기능, 정확도 95%면 출시해도 될까: 답변·권한·업무 결과를 나누어 검증하는 법

95%라는 숫자에서 먼저 확인할 것은 분모다

이 글에서 확인할 것

• 답변 품질, 정보 접근, 도구 실행과 업무 완료를 다른 기준으로 평가하는 방법
• 정상 질문에 편중되지 않은 평가셋과 실제 상태를 확인하는 채점 방법
• 평균 점수가 좋아져도 출시를 멈춰야 할 조건과 제한 공개의 범위

대상은 고객 상담 AI, 사내 지식 검색, 문서 처리, 주문·CRM 업무 에이전트를 운영 환경에 넣으려는 제품 책임자와 개발·QA 팀입니다. 코드를 AI로 작성했는지를 검토하는 글이 아니라, 제품 안에서 AI가 수행하는 기능 자체의 합격 기준을 다룹니다.

다음은 가상의 고객지원 AI 평가입니다. 200개 요청 중 190개를 성공으로 판정했습니다. 대시보드에는 성공률 95%가 표시됩니다.

전체 점수만 보면 출시할 수 있을 것처럼 보입니다. 그러나 정보 경계 시험에서는 3건, 상태 변경 시험에서는 5건이 실패했습니다. 더 쉬운 상품 질문을 800개 추가해 모두 통과시키면 전체 점수는 99%가 됩니다. 위험한 실패 8건은 그대로 남습니다.

이 예시는 통계적으로 예상되는 실제 오류율을 뜻하지 않습니다. 시험 구성과 집계 방식만 바꿔도 전체 점수의 인상이 달라진다는 설명입니다. 출시 판단에는 전체 수치 외에 업무 유형과 위험별 결과가 필요합니다.

NIST의 생성형 AI 위험관리 프로파일도 제한적이거나 일화적인 평가에서 확인한 성능을 더 넓은 운영 환경으로 확대 해석하지 않도록 권고합니다. 공개 벤치마크나 몇 번의 시연은 참고 자료가 될 수 있지만 우리 고객, 데이터와 업무 정책에 따른 합격 근거를 대신하지는 못합니다.^[1]

평가 대상은 모델 하나가 아니라 실제로 배포할 조합이다

같은 모델이라도 어떤 문서를 검색하는지, 어떤 사용자 권한으로 도구를 실행하는지에 따라 결과가 달라집니다. 따라서 평가 대상 버전에는 최소한 모델 식별자, 시스템 지침, 검색 설정, 지식 문서 버전, 도구 정의, 권한 정책과 애플리케이션 변경사항을 함께 기록하는 편이 좋습니다.

예를 들어 반품 안내의 문장이 정확해도 검색 대상이 지난달 정책이라면 현재 요청에는 틀린 답일 수 있습니다. 생성된 도구 인자가 맞아도 서버가 다른 조직의 주문을 받아들인다면 접근 제어가 실패한 것입니다. AI가 “처리했습니다”라고 응답해도 실제 주문 상태가 바뀌지 않았다면 업무는 완료되지 않았습니다.

모델의 답변은 이런 과정에서 발생한 하나의 결과입니다. 화면, API, 업무 상태와 운영 전환까지 합쳐서 출시할 기능을 정의해야 합니다.

기존 소프트웨어 QA와 AI 평가는 서로 다른 증거를 만든다

로그인, 세션 만료, 권한 검사, 금액 계산, 데이터 저장과 중복 실행 방지는 명시적인 규칙으로 시험할 수 있습니다. 반면 설명의 충분함, 문맥상 적절한 질문, 근거와 답변의 의미적 일치는 사람이 정한 평가 기준이 필요합니다.

AI 평가를 시작했다고 기존 API·브라우저·회귀 테스트가 사라지는 것은 아닙니다. API 응답의 정확성은 기능 테스트로 확인하고 그 응답을 AI가 잘 해석했는지는 별도로 평가합니다. 어느 층에서 실패했는지 구분해야 수정도 좁힐 수 있습니다.

합격 기준을 일곱 가지 질문으로 나눈다

아래 표는 업무형 AI 기능을 위한 평가 설계 예시입니다. 모든 제품에 같은 기준을 강제하기 위한 표가 아니라, 누락된 판단 항목을 찾기 위한 출발점입니다.

Google의 공식 평가 문서도 텍스트 품질, 지시 준수, 근거 일치와 도구 사용 품질 등을 구별합니다. 하나의 “좋은 답변” 점수에 모든 것을 담기보다 실제 업무에서 독립적으로 실패할 수 있는 항목을 나누는 것이 평가 설계에 유용합니다.^[2]

표의 모든 항목을 LLM 채점기에 맡길 필요는 없습니다. 조직 권한과 환불 금액처럼 시스템이 확정할 수 있는 사실은 권위 있는 데이터와 규칙을 기준으로 판정해야 합니다.

평가셋에는 잘 답할 질문과 멈춰야 할 요청이 함께 있어야 한다

처음에는 범위를 좁혀 실제로 자동화할 한 업무의 요청을 모읍니다. 공개 문서로 답할 수 있는 상품 안내를 먼저 공개한다면 그 업무의 정상 질문, 경계 조건과 이관 조건을 우선 다룹니다. 주문 변경을 공개하지 않을 것이라면 주문 변경 요청에서 실행하지 않고 적절히 안내하는지도 확인합니다.

아래는 가상의 고객지원 기능에 필요한 사례 분류입니다.

이런 사례는 실제 문의를 검토하면서 보완할 수 있습니다. 다만 운영 대화를 평가셋으로 옮길 때는 사용 목적, 접근 권한과 보관 방식을 확인하고 필요한 범위로 정보를 줄여야 합니다. 이름만 지워도 주문번호, 희귀한 사건과 문맥으로 개인이나 고객사를 알아볼 수 있으므로 식별 가능성을 다시 살펴야 합니다.

개발 중 쓰는 문제와 최종 확인용 문제를 구분한다

개발팀이 매일 보는 사례는 원인을 고치고 회귀를 확인하는 데 적합합니다. 그러나 그 사례에 맞춰 지침을 계속 고친 뒤 같은 문제만 다시 풀게 하면 새로운 입력에 대한 개선인지 구분하기 어렵습니다.

따라서 운영 사례를 반영한 개발용 평가셋과, 변경을 승인할 때 확인할 별도 평가셋을 나누어 관리할 수 있습니다. 별도 평가셋도 시간이 지나면 익숙한 문제가 되므로 갱신 기준을 정합니다. 공개 범위, 데이터 접근과 보관 책임도 함께 관리해야 합니다. Google의 안전성 평가 안내 역시 개발 중 평가와 별도로 관리되는 검증 평가를 구분합니다.^[3]

채점기는 확인할 사실에 맞게 고른다

Anthropic은 에이전트 평가에서 코드, 모델과 사람을 활용하는 채점 방식을 설명합니다. 이 구분을 우리 업무에 적용할 때 핵심은 가장 비싼 채점기를 쓰는 것이 아니라, 어떤 증거가 해당 질문의 정답을 결정하는가입니다.^[4]

금액, 주문 상태, 중복 작업, 접근 허용 여부는 가능한 한 프로그램과 서버 기록으로 확인합니다. “답변이 친절하다”는 평가로 잘못된 환불 금액을 합격시켜서는 안 됩니다. 반대로 자유로운 설명을 한 문장과 정확히 일치하는지만 비교하면 뜻이 맞는 답변도 실패할 수도 있습니다.

LLM 채점은 설명의 누락, 근거와 답변 사이의 의미적 관계 등을 빠르게 검토하는 데 활용할 수도 있습니다. 이때 채점 지침, 참고 자료, 모델 버전을 남기고 사람이 판정한 표본과 비교합니다. 채점 결과를 확정할 수 없는 사례는 “확인 필요”로 분리합니다. 실행하지 않은 항목, 환경 문제로 막힌 항목, 실행했지만 증거가 부족한 항목은 각각 미실행·차단·판정 불가로 집계하고 통과에 포함하지 않습니다. 점수를 낼 수 있는 사례만의 결과와 전체 계획 대비 검증 완료 범위를 함께 표시해야 합니다.

모델을 여러 개 써도 자동으로 독립적인 검증이 되지는 않습니다. 같은 잘못된 정책 문서나 불완전한 정답표를 공유하면 함께 틀릴 수 있습니다. LLM 판정의 위치·장문 선호 등 편향은 연구에서도 보고되어 있으므로, 답변 순서를 바꿔 비교하거나 사람의 기준과 불일치한 사례를 확인하는 절차가 필요합니다.^[5]

정답표에도 업무 책임자가 필요하다

개발자와 상담 담당자가 같은 답변을 다르게 평가한다면 채점 모델부터 바꾸지 말고 정책 해석을 확인합니다. 예외 처리가 문서화되지 않았거나 기준일이 다를 수 있습니다. 평가셋의 기대 결과를 누가 승인했는지, 언제 바꾸었는지 남겨야 이후의 점수 변화를 설명할 수도 있습니다.

모든 사례에서 사람 간 완전한 합의를 기대할 수는 없습니다. 다만 의견이 갈리는 항목을 숨긴 채 정답처럼 고정하면 평가 점수의 의미가 약해집니다. 적용 범위를 좁히거나 해당 항목을 수동 검토 대상으로 남기는 것도 하나의 결정입니다.

한 번의 답변보다 대화 뒤에 남은 상태를 확인한다

다음은 실제 고객 사례가 아닌, 주문 변경 에이전트를 위한 가상 시험입니다.

1. 사용자가 본인의 주문 배송지를 바꾸어 달라고 요청합니다.
2. AI가 변경할 주소와 주문을 제시하고 승인을 요청합니다.
3. 사용자가 승인하는 대신 “주소는 그대로 두고 수신자만 바꾸겠다”고 조건을 수정합니다. 이 시점에서는 변경 작업이 실행되지 않아야 합니다.
4. AI가 수정된 실행 내용을 다시 제시하고 사용자가 필요한 승인을 완료한 다음, 실행 요청의 응답이 일시적인 지연으로 돌아오지 않는 별도 경로를 시험합니다.
5. 사용자가 “끝난 거지?”라고 다시 묻습니다. 실제 처리 결과를 확인하기 전에는 완료라고 확정해서는 안 됩니다.

여기서 첫 번째 답변만 채점하면 뒤의 문제가 보이지 않습니다. 시험에서는 최종 수신자와 주소, 승인된 내용, 실행 횟수와 사용자에게 전달한 완료 상태를 함께 확인해야 합니다.

기대 결과는 미리 업무 정책으로 정합니다. 예를 들어 주소 변경 승인이 끝나지 않았으므로 주소는 유지되어야 하고 수신자 변경이 별도 확인 대상이라면 필요한 확인 없이 실행되어서는 안 됩니다. 외부 시스템의 결과가 불명확하면 완료라고 말하지 않고 상태를 확인하거나 담당자에게 넘겨야 합니다.

동일한 업무 목표를 달성하는 유효한 실행 경로가 여러 개라면 특정 도구 호출 순서만 정답으로 고정하지 않습니다. 하지만 본인 확인, 금액 한도와 실행 승인처럼 반드시 지켜야 하는 경계는 결과와 함께 검증합니다. 경로의 자유와 통제 생략은 다른 문제입니다.

답변률을 높이는 것과 업무 성공률을 높이는 것은 다르다

AI가 모든 질문에 답하면 응답률은 좋아집니다. 하지만 근거가 없는 질문까지 답하거나 이관해야 할 요청을 처리하면 실제 품질은 나빠질 수 있습니다. 반대로 모두 담당자에게 넘기면 위험한 실행은 줄어도 도입 목적을 달성하기 어렵습니다.

따라서 최소한 다음 수치의 분모를 구분해 기록합니다.

위험별 사례 수와 사례당 반복 횟수는 별도로 표시합니다. 예를 들어 서로 다른 10개 사례를 각각 3회 실행했다면 10개 사례·30회 실행으로 기록합니다. 환경 오류 등으로 판정하지 못한 실행은 그 이유와 수를 따로 남기며, 단순히 분모에서 제외한 성공률만 제시하지 않습니다.

분모를 정하기 어렵다면 기능의 지원 범위나 정책이 아직 불명확할 수도 있습니다. 이때는 점수를 먼저 만들기보다 “어떤 요청을 받아서 어디까지 책임질 것인가”를 정리합니다.

평가셋에서 위험한 행동이 한 번도 나오지 않았더라도 모든 요청에서 안전하다는 뜻은 아닙니다. 어떤 입력과 권한, 반복 횟수에서 관측되지 않았는지를 기록해야 합니다. 낮은 빈도의 실패가 중요한 기능이라면 시험 설계와 제한 공개 범위를 더 보수적으로 잡을 필요가 있습니다.

같은 사례를 다시 실행할 때 환경도 다시 맞춘다

AI의 행동은 실행마다 달라질 수 있습니다. 중요한 사례는 반복하여 확인하되 성공한 실행만 고르지 않습니다. 사례별 성공·실패 횟수와 실패 유형을 함께 남깁니다.

재시험 전에는 이전 실행이 만든 주문, 캐시, 대화 기록과 임시 파일이 결과에 영향을 주지 않는지 확인합니다. 한번 처리한 주문을 그대로 두고 시험하면 두 번째 실행의 실패가 모델 문제인지, 이미 완료된 상태 때문인지 구별하기 어렵습니다.

버전을 비교할 때는 가능한 한 같은 사례와 기준을 적용합니다. 지식 문서와 채점 모델까지 함께 바꾸었다면 개선 원인을 나누어 확인하기 어렵다는 점을 결과에 적습니다. 평가에 쓴 도구 모의 응답과 실제 연동 환경의 차이도 밝혀야 합니다. 모의 서버에서 통과했다는 결과는 실제 외부 서비스의 지연, 권한과 중복 처리까지 검증했다는 뜻이 아닙니다.

반복 평가의 목적은 완벽한 재현성을 선언하는 것이 아니라, 우연히 좋아 보인 결과를 출시 근거로 쓰지 않도록 하는 데 있습니다.^[4]

출시 범위와 중단 조건을 점수보다 먼저 합의한다

가상의 고객지원 서비스가 상품 안내, 주문 조회와 환불 실행을 한꺼번에 준비했다고 가정해 보겠습니다. 상품 안내는 기준을 충족했지만 주문 조회에서 권한 오류가 있고, 환불 실행은 재시도 검증이 끝나지 않았습니다.

이 경우 전체 기능의 평균 점수로 판단하기보다, 공개할 수 있는 범위를 분리합니다. 공개 정보 안내만 제한적으로 제공하고 주문 조회와 환불 실행은 비활성화할 수도 있습니다. 단순히 프롬프트에 “환불하지 말라”고 쓰는 것으로 끝내지 말고 실행 도구와 서버 권한에서도 차단되는지 확인합니다.

다음은 회사가 업무 위험에 맞게 조정할 출시 보류 조건의 예시입니다.

• 타 고객·타 조직의 정보를 반환하는 사례가 남아 있다.
• 승인받지 않은 외부 발송이나 상태 변경이 가능하다.
• 실행 여부가 불명확할 때 중복 처리할 수 있다.
• 근거가 없는 중요한 안내를 확정적으로 답한다.
• 사용 중인 버전과 평가한 버전의 차이를 설명할 수 없다.
• AI를 중단한 뒤 이어받을 담당자와 작업 목록이 없다.

이 조건을 해소했다고 모든 위험이 사라지는 것은 아닙니다. 허용하는 업무, 남은 한계와 모니터링 책임을 함께 기록하고 그 범위에서 공개를 판단합니다. 일반적인 출시 의사결정 기록과 잔여 위험 관리 방식은 출시 여부를 결정할 때 테스트 결과 외에 무엇을 확인해야 할까에서 이어서 확인할 수도 있습니다.

공개 후에는 어떤 변화가 재평가를 요구하는지 정한다

코드가 바뀌지 않아도 모델 버전, 지침, 검색 문서, 접근 권한과 연결 도구가 바뀌면 동작이 달라질 수 있습니다. 따라서 변경 요청에는 평가가 필요한 범위를 연결합니다.

문체만 조정한 지침 변경이라도 필수 고지나 이관 조건이 영향을 받는지 살펴야 합니다. 검색 문서를 교체하면 답변 근거와 적용 시점이 바뀝니다. 새 도구를 연결하면 기존에는 불가능했던 실행 경로가 생길 수 있습니다. 비용을 줄이기 위해 모델을 바꿀 때도 업무 유형별 결과와 예외 처리 능력을 다시 확인해야 합니다.

운영에서 발견한 오류는 원인에 맞게 추가합니다. 정책이 틀렸다면 정책을 먼저 고치고, 검색 누락이면 검색 평가에, 실행 오류면 API·상태 검증에 반영합니다. 같은 증상을 질문 하나로만 추가하면 다른 표현이나 다른 고객에서 반복될 수 있습니다. 기존 운영 오류를 회귀 테스트로 바꾸는 방법과 함께 운영하면 수정과 재검증을 연결하기 쉽습니다.

최소한의 기록에는 변경 버전, 평가셋 버전, 실패 유형별 결과, 미검증 범위, 공개 범위, 중단 담당자와 다음 검토 조건이 들어가야 합니다. 점수표가 아니라 다음 의사결정에 재사용할 수 있는 검증 기록이 목표입니다.

우리 서비스의 평가 범위를 정하려면

현재 공개하려는 AI 기능 하나와 대표 사용자 여정을 고르세요. 그 기능이 읽는 정보, 바꿀 수 있는 상태와 실패했을 때 넘길 곳을 적고, 일곱 가지 평가 질문에 어떤 증거로 답할 수 있는지 확인하면 시작할 수도 있습니다. IXC와 적용 범위를 검토하려면 프로젝트 문의에 기능 설명과 현재 테스트 자료를 전달해 주세요.