직원이 AI 기능을 믿고 쓰기 전에 어떻게 테스트해야 할까요?

시제품은 몇 가지 질문에 잘 답합니다. 이제 직원들에게 사용하게 하자는 이야기가 나옵니다. 동의하기 전에 직원들이 실제로 맡길 업무를 어떻게 처리하는지, 답할 수 없는 질문까지 포함해 공급업체에 보여 달라고 하세요.

논의를 구체적으로 진행할 수 있습니다. 업무 하나를 정하고 쓸 만한 결과의 기준을 합의한 다음, 그 업무를 아는 사람과 현실적인 사례의 결과를 살펴보세요. 그러면 출시 여부를 판단할 근거가 생깁니다.

업무 하나와 기능의 한계를 먼저 정하세요

승인된 내부 지침을 바탕으로 답변 초안을 작성하고, 직원이 사용하기 전에 읽어 보는 기능을 생각해 보세요. 가상의 예시지만 무엇을 기준으로 받아들일지 살펴보는 데 도움이 됩니다.

기능이 사용할 수 있는 자료, 대상 사용자, 결과물을 적어 두세요. 이 예시에서는 직원이 열람 권한을 가진 지침을 바탕으로 답변을 작성합니다. 답변을 보내거나 기록을 변경하는 기능은 별도로 테스트해야 합니다.

그다음 쓸 만한 결과의 기준을 합의하세요. 초안은 질문에 답하고, 승인된 자료와 일치하며, 답을 바꿀 수 있는 조건을 빠뜨리지 않고, 근거가 된 자료를 밝혀야 합니다. 자료만으로 답할 수 없다면 초안이 그 사실을 알려야 합니다. 정보가 부족하다고 분명히 인정하는 것도 성공적인 결과일 수 있습니다.

규칙을 지어내거나, 답을 바꾸는 조건을 누락하거나, 잘못된 지침에 근거해 자신 있게 답하면 초안을 사용할 수 없습니다. 결과를 살펴보기 전에 이런 차이를 합의하세요. 그러지 않으면 유창한 답변에 의외로 쉽게 설득될 수 있습니다.

사람들이 실제로 할 질문을 시험하세요

답변 초안 사례에는 적어도 다음 상황을 포함하세요.

• 일반적인 질문. 지침에 명확한 답이 있습니다. 초안이 정확히 답하고 올바른 자료를 가리키나요?
• 모호한 질문. 두 절차 중 하나가 적용될 수 있습니다. 기능이 임의로 하나를 선택하지 않고, 판단에 필요한 정보를 되묻나요?
• 자료가 없는 경우. 승인된 지침이 요청 내용을 다루지 않습니다. 기능이 그 공백을 알리고 사람이 해결하도록 남겨 두나요?

이 사례들은 시작점입니다. 흔한 요청, 정보 부족, 표현이 까다로운 질문, 실수의 결과가 큰 사례 등 실제 업무의 다양한 상황에 맞춰 테스트를 구성하세요. 사용이 승인된 대표 데이터나 안전하게 준비한 사례를 쓰고, 승인되지 않은 서비스에 기밀 기록을 입력하지 마세요.

Microsoft의 평가 지침은 대표적인 상호작용과 어려운 사례를 권합니다. 관리자가 확인할 것은 직원에게 도움이 필요한 상황을 사례가 충분히 다루는지입니다. 일반 모델 벤치마크로는 해당 애플리케이션에 대한 답을 얻을 수 없습니다.

업무를 아는 사람이 결과를 판단하게 하세요

해당 업무에 익숙한 사람에게 합의한 기준에 따라 답변을 검토해 달라고 하세요. 왜 답변을 사용할 수 있는지, 틀렸는지, 확신할 수 없는지 설명할 수 있어야 합니다. 판단이 엇갈리거나 실수의 결과가 심각하다면 다른 사람에게도 검토를 맡기세요.

자발적으로 활용하는 NIST AI 위험 관리 프레임워크는 테스트 기록, 실제 도입 상황과 비슷한 조건, 관련 전문가의 참여를 권합니다. 무엇을 테스트했고 누가 확인했는지 묻는 데 참고할 수 있습니다. 다만 모든 기능에 적용되는 합격 점수를 제시하지는 않습니다.

평가 사례 중 일부는 기능을 개선하는 데 쓰는 사례와 분리해 두세요. 공급업체가 모든 테스트 질문에 맞춰 계속 조정한다면 익숙한 질문에 얼마나 잘 답하는지만 알 수 있습니다. 별도의 사례를 두면 조정 과정에서 다루지 않은 업무에 어떻게 대응하는지 더 잘 확인할 수 있습니다.

자동 채점은 결과를 정리하는 데 도움이 되지만, 채점 판단도 확인해야 합니다. 사람도 실수를 놓칠 수 있고, 다른 AI를 평가하는 AI도 틀릴 수 있습니다. 실제 답변과 점수의 근거를 확인하세요.

평균 점수 뒤에 있는 실패를 살펴보세요

종합 점수는 버전을 비교할 때 유용합니다. 여기에 더해 중요한 상황과 실수 유형별 결과도 살펴보세요. 일반적인 질문에는 잘 답하면서 출처가 없는 질문에는 답을 반복해서 지어낼 수 있습니다. 평균만 보면 해당 용도에 대해 내려야 할 판단을 놓칠 수 있습니다.

어떤 실패가 있었는지, 얼마나 심각했는지, 무엇이 아직 불확실한지 기록하세요. 예정된 사용을 막는 실패가 무엇인지 정하세요. 허용할 수 있는 오류 수준은 업무와 실수 이후의 결과에 따라 달라지며, 모든 기업에 통하는 비율은 없습니다.

기능이 작업도 수행한다면 연결된 시스템에서 실제로 어떤 일이 있었는지 확인하세요. 예를 들어 기록을 업데이트했다고 하면, 올바른 기록이 의도한 값으로 바뀌었는지 살펴보세요. Anthropic이 2026년 1월에 소개한 AI 에이전트 평가 방법은 소프트웨어가 작업을 수행할 때 최종 결과가 중요한 이유를 설명합니다. 작업이 끝났다는 메시지만으로는 성공을 확인할 수 없습니다.

출력 품질은 승인 과정의 한 부분입니다. 보안, 권한, 개인정보 보호와 전체 업무 흐름도 각각 적절히 확인해야 합니다. 답변 점수가 높다고 해서 이런 요소까지 제대로 작동한다고 볼 수는 없습니다.

구체적으로 출시 여부를 결정하세요

공급업체에 업무와 한계, 테스트 사례와 기대 결과, 검토자, 중요한 실패, 남아 있는 불확실성, 테스트한 버전을 간단히 기록해 달라고 하세요. 모델, 지침, 출처 자료, 연결된 소프트웨어가 결과에 영향을 준다면 그것도 포함하세요. 이 중 하나라도 바뀌면 어떤 검사를 다시 해야 할지 합의하세요.

이 근거를 바탕으로 다음 세 가지 중 하나를 결정해야 합니다.

• 제한적 사용 승인. 정해진 범위의 업무에 한해 결과가 사용을 뒷받침합니다. 직원들은 언제 검토하고, 중단하고, 기존 절차로 돌아갈지 알고 있습니다.
• 수정 후 재테스트. 구체적인 실패를 고쳐야 합니다. 어떤 사례를 다시 실행하고, 수정이 효과가 있는지 별도 사례로 어떻게 확인할지 정합니다.
• 출시 보류. 중요한 실패가 해결되지 않았거나, 계획한 사용을 뒷받침할 근거가 부족합니다.

범위를 제한한 시범 운영으로 실제 업무의 근거를 더할 수 있습니다. 참여자, 업무, 권한, 검토 방법, 대체 절차를 미리 정하고, 문제를 살피고 필요하면 운영을 멈출 담당자를 지정하세요. 소규모 시범 운영의 좋은 결과는 그 제한된 사용을 뒷받침할 뿐, 전반적인 신뢰성을 입증하지는 않습니다.

승인 논의를 마칠 때는 직원들이 무엇을 믿고 쓸 수 있는지, 어디서 사람이 판단해야 하는지, 어떤 일이 재테스트를 촉발하는지 알아야 합니다. 맞춤형 업무 애플리케이션에 AI 기능을 계획하고 있다면, 그 기능이 해야 할 일과 승인 전에 필요한 근거를 함께 논의할 수 있습니다.