AI 답변을 고객에게 내보내기 전: 오류 유형과 출시 판정표 만들기

시연에서 자연스러운 답변을 몇 번 받았다고 고객에게 공개할 준비가 끝나는 것은 아닙니다. 고객은 설명이 없는 질문을 하고, 오래된 문서를 올리고, 권한 밖의 정보를 요구하기도 합니다. 출시 전에 필요한 것은 멋진 답변 모음보다 어떤 입력에서 어떤 결과를 허용할지 정한 평가표입니다. 여기서는 고객지원 답변의 초안을 작성하는 가상 서비스를 기준으로 작은 팀이 시작할 수 있는 평가 과정을 설계합니다.

미국 NIST의 생성형 AI 위험관리 프로파일 소개는 AI 제품의 설계·개발·사용·평가에 신뢰성 고려사항을 반영하도록 돕는 자발적 활용 자료입니다. 이 글의 테스트 수, 오류 분류, 출시 판단은 해당 기관의 공식 합격 기준이 아니라 제품 범위에 맞춰 작성한 실무 예시입니다. 특정 공급자나 모델의 성능을 비교하지 않습니다.

평가보다 먼저 한 문장으로 제한할 제품의 일

가상 서비스의 역할을 ‘승인된 고객지원 문서에서 근거를 찾아 상담원이 검토할 답변 초안을 작성한다’로 정합니다. 실제 환불을 실행하거나 고객 계정을 수정하는 권한은 없습니다. 그러면 평가할 대상도 분명해집니다. 문서와 맞는지, 근거를 찾을 수 있는지, 모를 때 확인을 요청하는지, 실행하지 않은 일을 완료했다고 말하지 않는지를 살펴볼 수 있습니다.

입력에는 사용자 질문 외에 고객 조직, 접근 가능한 문서, 문서 버전, 검색 결과가 포함됩니다. 같은 질문이라도 어느 고객의 어떤 자료를 볼 수 있는지에 따라 허용 답변이 달라집니다. 평가 기록에는 질문 문자열만 남기지 말고 이 조건들을 함께 저장해야 다음 변경 때 같은 상황을 재현할 수 있습니다.

‘틀림’을 다섯 가지로 나누기

• 사실 오류: 날짜·조건·수량·계산이 제공된 근거와 다릅니다.
• 근거 오류: 존재하지 않는 문서를 인용하거나, 인용한 부분이 답변의 주장을 뒷받침하지 않습니다.
• 범위 오류: 정보가 부족한데 단정하거나, 서비스가 하지 않은 처리를 완료했다고 말합니다.
• 권한 오류: 다른 고객의 자료나 허용되지 않은 정보를 결과에 포함합니다.
• 전달 오류: 필요한 필드가 빠지거나 출력 형식이 깨져 후속 화면에서 사용할 수 없습니다.

한 응답에 여러 문제가 있으면 유형을 여러 개 기록할 수 있습니다. 다만 전체 실패 응답 수에서는 한 번만 세고, 유형별 건수는 중복될 수 있다고 표시합니다. 표현이 딱딱한 문제와 다른 고객 정보가 보이는 문제를 같은 점수로 평균내면 출시 판단에 필요한 차이가 사라집니다. 실패의 영향도도 함께 정하세요.

바로 확장할 수 있는 테스트 사례 표

다음 자료·정책·금액은 전부 테스트를 위한 가상 예시입니다. 실제 고객정보나 실제 서비스 약관을 뜻하지 않습니다. 정답 문구를 한 문장으로 고정하기보다 반드시 포함할 사실과 금지할 행동을 적으면 표현이 다른 정상 답변도 평가할 수 있습니다.

문서 속 지시 사례는 외부 자료가 모델의 동작을 바꾸려는 상황을 점검합니다. OWASP의 프롬프트 인젝션 안내는 입력·출력 검증과 최소 권한, 위험한 동작에 대한 사람의 승인 등을 완화 방법으로 다룹니다. 프롬프트에 주의 문장을 넣는 것만으로 해결됐다고 판단하지 말고 검색 권한과 실제 실행 권한도 각각 테스트해야 합니다.

실행 기록과 판정 방법

작은 시작점으로 정상·경계·실패 유도 사례를 섞어 고정 평가 묶음을 만듭니다. 서비스 변경 때마다 같은 묶음을 실행하고, 새로 발견한 문제는 해당 상황을 재현할 수 있는 사례로 추가합니다. 평가에 쓰는 자료는 공개 자료나 인공 자료부터 구성하고, 실제 기록을 활용해야 한다면 적절한 사용 권한과 비식별 처리 범위를 확인합니다.

실행 한 건에는 사례 ID, 자료 버전, 프롬프트와 설정 버전, 모델 식별정보, 실제 출력, 검색된 문서 ID, 처리 시간, 판정 이유를 남깁니다. 모델만 같아도 검색 문서나 지시문이 달라지면 결과가 바뀔 수 있으므로 서비스 전체의 변경 사항을 묶어 추적합니다. 출력 저장소의 접근 범위와 보관 기간도 정합니다.

계산·필수 필드·문서 ID 존재 여부는 코드로 확인할 수 있습니다. 문장 속 주장이 실제 근거와 맞는지, 확인 요청이 적절한지는 사람이 읽을 평가 규칙이 필요합니다. 자동 평가를 보조로 쓰더라도 정답을 잘못 정한 사례나 애매한 판정은 사람이 검토할 수 있게 남깁니다. 이 글은 검토 절차의 제안이며 실제 평가를 수행했다는 보고가 아닙니다.

평균 통과율이 높아도 보류할 수 있다

가상 평가에서 40개 사례를 각 3회 실행해 120개 응답을 얻었다고 합시다. 113개가 통과하고 서로 다른 7개가 실패했다면 응답 단위 통과율은 113 ÷ 120 × 100 = 약 94.2%입니다. 실패의 주된 원인이 사실 오류 3개, 근거 오류 2개, 권한 오류 1개, 전달 오류 1개라면 합계는 7개입니다. 실제 통계나 특정 제품의 성능 수치가 아닙니다.

팀이 미리 ‘고객 간 정보 노출이 한 번이라도 발견되면 공개를 보류한다’고 정했다면 이 결과는 보류입니다. 전체 평균으로 치명적인 실패를 덮지 않기 위해서입니다. 같은 사례의 반복 실행은 서로 독립적인 고객 사용 표본도 아니므로, 94.2%를 실제 운영 정확도나 안전 확률로 발표해서는 안 됩니다.

수정 뒤에는 실패 사례와 기존 평가 묶음을 다시 실행해 다른 행동이 나빠지지 않았는지 확인합니다. 공개할 때에도 적용 업무, 사람이 확인할 지점, 문제 신고 경로를 제품 안에 마련하고 품질이 악화됐을 때 기능을 제한하거나 이전 설정으로 되돌릴 담당자를 정합니다. 평가표의 역할은 모든 오류가 사라졌다는 선언이 아니라 공개 범위를 결정할 근거를 남기는 것입니다.