한 줄의 주장에 검증 단위를 붙입니다
제안 단계의 숫자는 내부 검토에 필요한 질문의 출발점입니다. 응답 문장이 맞는 비율, 실제 업무가 완료된 비율, 사람이 편집하지 않은 비율은 서로 다른 의사결정을 돕습니다. 담당자가 바뀐 뒤에도 기준을 적용할 수 있게 어떤 숫자가 어떤 업무와 증거를 가리키는지 맞춰 둡니다. NIST의 생성형 AI 프로파일은 같은 맥락에서 공급사 실사와 운영 중 모니터링, 배포 전에 검증 가능한 방법으로 역량을 시험하는 활동을 제안합니다.
정확도 95%라는 문장에서는 무엇을 한 건으로 쳤는지 알 수 없습니다. 한 문의에서 항목 다섯 개를 뽑고 그중 하나가 틀리면 업무 전체가 사람에게 돌아갈 수 있습니다. 필드 단위 점수가 높아도 업무 단위로 자동 완료할 수 있는 비율은 낮아집니다. 양식을 분류하고 누락을 안내하는 기능이라면 올바른 분류, 고지 여부, 업무 상태의 갱신을 따로 판단할 수도 있습니다.
업무 책임자와 공급사가 우선 맞춰야 할 것은 입력에서 종료까지의 경계입니다. 예를 들어 계약 문의 한 건을 승인된 지식으로 안내하고 응대 내용을 상담 원장에 남기는 일을 가정합니다. 결과가 맞는 답변을 작성했는지, 원장에 올바른 상담 건으로 기록했는지, 정책상 상담원 이관이 필요한 입력에서 실제로 이관 기록이 만들어졌는지 각각 판단합니다. 이관은 안전하게 처리된 업무의 성공 조건이 될 수 있습니다. 자동 완료율을 계산할 때는 사람에게 넘긴 건을 별도 집계합니다. Anthropic의 에이전트 평가 방법[1]은 대화 기록과 환경에서 확인되는 최종 결과를 구분합니다.
분모는 자격을 갖춘 입력부터 고정합니다. 업무 정책상 서비스 범위 밖인 요청과, 범위 안이지만 누락·이관·타임아웃이 발생한 요청을 다른 코드로 표시합니다. 공급사가 지원하지 않겠다고 정한 입력도 공통 업무 집합에 포함돼 있다면 운영 범위의 차이로 남겨야 합니다. 집계 시 어떤 상태를 시험 성공, 실패, 미실행, 사람이 처리한 건으로 분류했는지 사례별 ID로 추적할 수 있어야 합니다.
가상 제안서 두 장을 같은 표에 올리면
업체 A는 정확도 95%를 제시하면서 평가에 포함한 80건 중 76건의 답이 맞다고 설명합니다. 자료를 보니 접수한 100건 중 복잡한 20건은 사람에게 넘겨 점수에 들어가지 않았고, 맞다고 본 76건 가운데 12건은 상담원이 발송 전에 의미 있는 수정이나 재입력을 했습니다. 업체 B는 자동 완료율 70%를 제시하면서 접수 100건 중 70건이 사람 없이 끝났다고 답했습니다. B의 숫자는 완료된 70건 답변과 업무 기록이 모두 맞았는지 알려 주지 않습니다. 가상 수치는 방법을 설명하는 예시입니다.
| 제안서 문구 | 분모와 확인된 사실 | 공통 비교에 더 필요한 증거 |
|---|---|---|
| A 정확도 95% | 채점 대상 80건 중 76건의 답안 적합. 최초 접수는 100건 | 제외 20건의 유형, 편집 전·후 판정, 최종 업무 원장의 상태 |
| A 수정 없이 맞은 비율 | 적합한 76건에서 편집 12건을 빼면 64건. 접수 100건 대비 64%의 수정 없는 적합 답변 | 64건에서 외부 상태까지 검증했는지. 이관이 필요했던 건을 어떻게 처리했는지 |
| B 자동 완료율 70% | 접수 100건 중 사람 없이 70건 종료 | 70건의 결과 정확성, 중대한 권한 위반, 잘못된 자동 처리, 나머지 30건의 종료 상태 |
여기서 A의 64%를 B의 70%와 바로 순위에 올리면 또 다른 지표를 비교하게 됩니다. A의 64건은 답변에 관한 계산입니다. B의 70건은 사람 개입과 업무 종료에 관한 수치입니다. 공통 시험에서 접수 대상 100건을 공급사마다 동일하게 주고, 승인 근거와 업무 원장으로 확인한 정상 완료, 의미 있는 편집, 사람 이관, 오류와 차단을 같은 기준으로 집계해야 합니다. 수정의 범위도 미리 맞춥니다. 줄바꿈 정리와 금액·수신자·결론 교체를 별도 기록하면 어떤 조작이 업무 위험과 비용에 연결되는지 확인할 수도 있습니다.
공급사가 스스로 골라 시연한 100건은 기능을 설명하는 데 쓸 수 있습니다. 실제 후보를 비교할 때는 발주 조직이 대표 업무·경계 사례·오류 경로를 구성하고 시연에 사용한 예시가 최종 시험과 겹치는지 확인합니다. 같은 표본에 같은 설정으로 반복 실행할 때는 고유 업무 수와 실제 실행 횟수를 구분합니다. 한 업무를 열 번 반복한 결과는 열 종류의 업무가 검증됐다는 뜻이 아닙니다.
요구사항에서 승인까지 이어지는 근거 — 요구사항과 테스트, 결함 조치와 승인 기록을 연결해 같은 기준으로 품질을 판단합니다.
공급사마다 똑같이 묻는 12문항
구매 담당은 답변 양식을 공통으로 보내고, 업무 담당이 기대 결과를 승인하며 기술 담당이 재현과 버전 근거를 검토합니다. 답을 받는 첫날 제출할 수 없는 부분이 있으면 예정된 시험, 제출자와 기한을 기록합니다. 최종 인수 판단에는 실제 관측값을 사용합니다.
- 어떤 업무 한 건을 성공으로 보나요? 시작점, 마지막 업무 상태, 사용자 응답과 실제 상태의 확인 방법을 사례 하나로 설명해 주세요.
- 공개한 지표에 무엇이 들어갔나요? 전체 접수, 평가 자격, 실제 실행, 실패, 사람 이관과 제외 건수를 같은 실행의 식별자로 연결해 주세요.
- 사람이 어느 단계에서 개입했나요? 입력 수정, 초안 검토, 재시도, 도구 실행과 승인 여부를 표시해 주세요. 공급사 측의 후처리도 포함해 주세요.
- 기대 결과를 누가 어떤 근거로 만들었나요? 발주 조직에서 확인할 수 있는 규정과 계약, 버전 및 정책 책임자를 제시해 주세요.
- 평가 사례는 개발·최종 확인에 어떻게 쓰였나요? 공급사 튜닝용 예시의 범위와 별도로 보유한 인수 표본, 노출 및 유사 중복 점검 방법을 알려 주세요.
- 제안 결과를 다시 만들려면 어떤 구성이 필요한가요? 앱 빌드, 모델과 파라미터, 프롬프트, 자료·인덱스, 연동 도구, 실행 권한과 판정 규칙의 식별자를 주세요.
- 위험한 예외는 어떻게 차단하고 확인하나요? 권한 부족, 근거 부재, 오래된 문서, 외부 타임아웃과 위험한 요청에서 실제 실행과 업무 상태가 어떻게 되는지 보여 주세요.
- 업무 한 건의 비용은 어디까지 포함하나요? 모델, 검색, 저장, 연동, 반복 실행과 사람 검토 비용을 같은 사용량 시나리오에서 설명해 주세요.
- 모델이나 검색 구성이 바뀌면 누가 알려 주고 누가 승인하나요? 예정된 변경과 예고 없는 의존성 변경을 각각 다루고, 영향 분석·재시험·복귀 절차를 보여 주세요.
- 장애 때 누가 무엇을 끝까지 처리하나요? 첫 응답, 위험 기능 중단, 공급자 이관, 처리 결과의 대사, 사용자 안내와 정상 재개의 책임을 구분해 주세요.
- 내부 팀이 유지하거나 종료할 때 무엇을 가져갈 수 있나요? 입력·출력 데이터, 평가 근거·설정·문서 상태·권한 매핑의 이동 범위, 제한과 복구 또는 삭제 증거를 보여 주세요.
- 지금 증거가 없거나 시연 환경과 운영이 다른 부분은 무엇인가요? 환경 차이, 증거 미제출, 미실행, 알려진 결함, 운영 제한을 따로 적고 담당자와 판정 일정을 지정해 주세요.
측정은 사용량 시나리오 하나에서 끝나지 않습니다. 운영팀은 평일 보통량과 몰리는 날의 양, 검토 담당자가 처리할 수 있는 수, 업무별 지연 한도를 제시할 수도 있습니다. 공급사는 같은 요청 분포에서 검색과 도구 호출의 재시도를 얼마나 허용할지, 요금에 포함되는 작업은 무엇인지 설명합니다. 계산 범위에서 제외한 실패 작업도 실제 지출이나 검토 시간을 유발할 수도 있습니다. 구매 담당이 운영 과정 전체의 비용을 비교하도록 합의한 입력 수와 종료 수를 함께 넘깁니다.
인수 시험은 인력과 도구가 바뀌어도 다시 돌릴 수 있어야 합니다
업무 집합을 만들 때 채널, 업무 타입, 사용자의 역할, 문서와 권한의 시점, 실제 결과의 확인 방법을 고릅니다. 대표 표본은 흔한 정상 흐름을 보여주고, 별도의 위험 사례는 동작을 멈춰야 할 경계를 확인합니다. 두 표본을 섞으면 자주 쓰는 경로의 지표와 차단 조건의 실패가 평균값에 함께 묻힙니다. 발주 조직이 사용할 수 있는 익명화 또는 합성 평가 입력을 준비하고 이미 공급사에 준 샘플은 최종 평가 집합에서 분리합니다. 기술·업무 담당의 의견이 다르면 기대 결과의 합의일과 과정부터 남깁니다.
| 확인할 제안 | 인수 전에 받을 증거 | 시험 및 인수 기준 예시 |
|---|---|---|
| 상품 정책에 근거해 안내 | 정책 문서 ID·버전·효력일, 답변과 인용, 없는 근거의 처리 | 올바른 판본에서 조건을 설명하고 근거가 없을 때 보류·이관하는지 |
| 승인된 항목만 변경 | 권한 매핑, 도구·승인 기록, 시험 전후 업무 원장 | 승인 담당자, 대상·금액·수신자가 일치하고 금지 입력에서 변경이 없는지 |
| 고객 업무를 자동 완료 | 공통 업무별 원본·정제 입력, 편집·재시도·완료 기록 | 사람 개입의 정의와 분모를 지키고 최종 상태를 검사해 수치를 재현할 수 있는지 |
| 운영 중 같은 품질 유지 | 구성 목록, 변경 통지와 승인, 표본·회귀 시험과 이전 구성의 복귀 조건 | 모델 또는 문서 변경을 만들고 기존 증거 중 무엇을 다시 평가하는지 확인 |
| 정해진 비용과 지연 | 건수·입력 크기·재시도·검토 시간의 가정과 실제 실행 계수 | 평균과 함께 업무별 비용, 지연과 적체, 비용 한도 도달 시 우회 확인 |
| 공급사 없이 운영·전환 가능 | 평가셋과 근거 참조, 데이터를 내보낸 결과, 설정 명세, 계정 인수 목록 | 내부 운영자가 내보낸 자료로 별도 테스트 환경에서 합의한 시험을 수행하는지 |
규정이 바뀌는 업무에서는 구성 버전을 모델명으로만 기록하지 않습니다. 모델 버전이나 공급자가 제공하는 식별자, 프롬프트 해시, 문서 스냅샷, 검색 설정, 도구 파라미터, 접근 정책 및 평가 기준을 실행 ID에 연결합니다. 공급자의 모델 식별자가 고정되지 않는다면 관측된 모델과 날짜, 공급자가 통지할 수 있는 변경 범위, 그 뒤에 돌릴 시험을 정합니다. 감지 근거가 제한적인 환경에서는 대표 업무의 결과 변화와 재검증 책임을 운영 조건으로 만듭니다. Google Cloud의 생성형 AI 운영 지침[2]은 운영 입력의 변화 관측과 실제 출력의 지속 평가를 함께 다룹니다.
인수 시 가지고 있을 평가셋에는 사례 ID, 데이터 출처, 담당자와 승인된 사용 범위, 적용 정책 및 기대 결과 버전이 들어갑니다. 학습이나 프롬프트 튜닝에 사용해도 되는 입력과 검수 담당자만 열 수 있는 입력은 권한을 분리합니다. 내부 팀이 유지해야 할 항목은 샘플 파일로 취급하지 말고 테스트를 다시 실행할 자료와 방법을 받아 봅니다. 반출이 제한된 자료는 조직이 관리하는 대체 데이터와 검사 규칙으로 재현 가능 여부를 합의합니다.
모델 교체와 자료 갱신을 인수 때 한 번씩 실행합니다
가상 규정이 개정됐다고 가정하고 시험 환경의 문서 버전과 효력 시각을 바꿉니다. 공급사는 인덱스 갱신과 확인 기준을 보여 주고, 업무 담당은 신규 규정과 아직 유효한 예외가 올바르게 조회되는지 판정합니다. 다음으로 모델이나 도구 설정을 바꾸고 같은 사례를 실행해 이전 증거의 적용 범위가 어느 지점에서 바뀌는지 봅니다. 인수 목록의 설정 항목 하나를 실제로 변경해 보는 일을 통해 문서 명세와 권한, 내부 팀의 접근 및 운영 책임을 함께 확인할 수도 있습니다.
운영팀이 먼저 알림을 받더라도 공급사만 실행 환경에 접근하는 구조라면 위험 기능 차단, 원인 조사와 고객 영향 정리에 시간이 걸립니다. 서비스 수준 합의에서 첫 응답 시간과 작업 완화 또는 복구 조건을 따로 확인합니다. 글의 MSP 장애 대응 책임의 비교 기준처럼 책임을 티켓 접수에서 실제 변경 및 검증까지 행동 단위로 정할 수도 있습니다. 빌드와 배포, 기본 권한, 백업 등 범용 항목은 소프트웨어 인수 검수 기준에 함께 연결합니다.
인수 승인 회의에는 구성 ID에 연결한 공통 시험 결과, 인수할 운영 자료, 예외 및 미검증 목록을 올립니다. 위험한 실행의 차단이 증명되지 않았거나 핵심 업무가 미실행이면 해당 기능은 제한하거나 인수를 보류합니다. 조건부 운영이 가능하다면 어느 역할의 어떤 기능까지 열 것인지, 담당자·기한·재시험 조건·종료 기준을 적습니다. 공급사가 구성을 수정하고 같은 판정을 다시 받고자 할 때는 바뀐 근거의 범위에 맞춰 재실행합니다.
