AI 서비스 운영 지표(KPI) 설계
실제 사용 흐름을 기준으로 품질, 안전, 비용, 신뢰성을 함께 관리하는 AI 서비스 운영 지표 설계법입니다.
Summary
AI 서비스의 KPI는 응답 속도나 모델 점수 하나로 충분하지 않습니다. 사용자가 일을 끝냈는지, 중요한 오류가 얼마나 발생했는지, 그 대가가 예산 안에 드는지, 문제가 생겼을 때 원인을 재현할 수 있는지를 함께 봐야 합니다.
OpenAI의 평가 가이드는 배포 전후에 실제 작업을 대표하는 데이터셋과 명확한 성공 기준을 만들 것을 권합니다. Anthropic의 프롬프트 안내 역시 원하는 결과를 먼저 정하고, 프롬프트뿐 아니라 모델·도구·시스템 설계까지 함께 점검하라고 설명합니다. 이 문서는 그 원칙을 운영 대시보드와 의사결정에 연결합니다.
When to Use
- 파일럿을 실제 사용자에게 열기 전, 최소 관측 범위를 정할 때
- 운영 중인 AI 기능의 품질 저하나 비용 상승 원인을 찾을 때
- 모델·프롬프트·도구를 바꾸기 전후의 영향을 비교할 때
- 주간 운영 회의에서 무엇을 유지·중단·개선할지 결정할 때
먼저 정할 것
KPI를 만들기 전에 아래 네 가지를 한 문장씩 합의합니다.
| 질문 | 합의 예시 |
|---|---|
| 사용자가 끝내려는 일은 무엇인가 | 문의 내용을 확인하고 다음 처리 단계를 정한다 |
| 실패하면 누가 어떤 피해를 보는가 | 잘못된 안내는 고객과 상담원 모두에게 비용을 만든다 |
| 사람이 반드시 확인해야 하는 구간은 어디인가 | 환불·계약·개인정보 관련 답변은 발송 전 검토한다 |
| 성공을 무엇으로 판정하는가 | 필요한 근거와 다음 행동을 포함한 답변이 검토 기준을 통과한다 |
“응답이 자연스럽다”처럼 측정할 수 없는 목표는 운영 기준이 될 수 없습니다. 대상 사용자, 작업 유형, 허용할 수 없는 오류, 검토 방법을 함께 적어야 합니다.
1. 운영 이벤트를 먼저 남긴다
대시보드는 데이터가 있어야 작동합니다. 요청마다 다음 정보를 연결 가능한 식별자로 남기되, 원문과 개인정보는 정책에 맞게 최소화합니다.
| 범주 | 최소 이벤트 |
|---|---|
| 요청 | 작업 유형, 사용자 또는 세션 식별자, 시작·종료 시각, 제품·프롬프트·모델 버전 |
| 실행 | 사용한 도구, 재시도, 실패 코드, 입력·출력 토큰 또는 해당 공급자의 사용량 단위 |
| 결과 | 완료·중단·사람에게 넘김 여부, 사용자의 수정·재질문·피드백 |
| 평가 | 평가 데이터셋 ID, 기준별 판정, 판정자, 근거 링크, 검토 일시 |
원문 프롬프트와 모델 출력은 무조건 오래 보관하지 않습니다. 보관 목적, 접근 권한, 마스킹, 보존 기간을 서비스 정책으로 정하고 테스트용 데이터와 운영 데이터를 분리합니다.
2. 네 가지 관점으로 본다
작업 완료와 사용성
사용자가 실제로 일을 마쳤는지를 우선 지표로 둡니다.
| 지표 | 계산 또는 확인 방법 | 해석 |
|---|---|---|
| 작업 완료율 | 완료한 흐름 ÷ 시작한 흐름 | 낮아지면 UX, 도구, 품질을 함께 조사 |
| 재질문·수정률 | 같은 작업에서 추가 요청 또는 수정한 비율 | 높다고 항상 나쁜 것은 아니며, 작업 난이도와 함께 봄 |
| 사람 연결률 | 사람 검토·상담으로 넘긴 건수 ÷ 전체 | 안전장치인지 품질 실패인지 표본 검토로 구분 |
| 사용자 피드백 | 긍정·부정 반응과 자유 의견 | 표본 수와 수집 위치를 함께 기록 |
품질과 안전
정확도 하나로 판단하지 말고 서비스에 맞는 기준을 나눕니다. 예를 들어 근거 기반 답변은 근거 정확성, 질문 적합성, 필수 정보 누락, 위험한 안내를 따로 판정합니다.
| 지표 | 운영 방법 |
|---|---|
| 기준별 통과율 | 대표 작업 묶음에서 기준별 통과 건수와 실패 근거를 기록 |
| 치명 오류 건수 | 법률·의료·금전·개인정보 등 미리 정의한 오류를 별도 분류 |
| 실패 재현율 | 같은 입력과 버전으로 문제를 다시 확인할 수 있는 비율 |
| 평가 일치도 | 자동 판정과 사람 판정이 얼마나 같은지 표본으로 교정 |
LLM을 판정자로 쓸 수는 있지만, 그 결과를 정답으로 취급하지 않습니다. 초기에는 사람 판정이 끝난 표본으로 기준을 조정하고, 고위험 오류는 사람이 최종 확인합니다.
신뢰성과 속도
속도 목표는 제품 기대치에서 정합니다. 내부 분석 도구와 실시간 고객 대화는 허용 시간이 다릅니다.
| 지표 | 확인 방법 |
|---|---|
| 단계별 지연 시간 | 모델 호출, 검색, 도구 실행, 화면 표시를 분리해 측정 |
| 성공·실패·재시도율 | 상태 코드와 실패 유형을 함께 기록 |
| 가용성 | 사용자가 실제로 작업을 시작하고 끝낼 수 있었는지로 계산 |
| 폴백 성공률 | 제한·장애 때 대체 모델, 큐, 사람 연결이 정상 동작했는지 확인 |
백분위 지연 시간은 유용하지만, 모든 서비스에 같은 초 단위 기준을 적용하지 않습니다. 사용자 약속과 실제 기준선을 함께 표시해 추세와 변화를 봅니다.
비용과 가치
요금표와 한도는 공급자·모델·계정 상태에 따라 바뀝니다. 문서에 특정 모델명이나 단가를 고정하지 말고, 배포 전 해당 공급자의 가격·한도 페이지를 확인합니다.
| 지표 | 계산 방법 |
|---|---|
| 완료 작업당 비용 | AI·검색·도구·인프라 비용 ÷ 완료 작업 수 |
| 실패 작업 비용 | 완료하지 못한 요청에 소비한 비용과 재시도 비용 |
| 도구 호출 비용 | 외부 API, 브라우저 자동화, 검색 등 부가 비용을 모델 비용과 분리 |
| 예산 소진 예상일 | 현재 일별 추세와 승인된 예산으로 계산 |
비용을 낮추기 위해 품질과 안전을 훼손하지 않습니다. 비용 변경은 동일한 평가 세트와 트래픽 조건에서 품질·완료율과 함께 비교합니다.
3. 목표는 절대 수치가 아니라 기준선에서 시작한다
처음부터 “정확도 90%” 같은 숫자를 정하면 팀이 측정하기 쉬운 것만 최적화할 수 있습니다. 다음 순서로 목표를 만듭니다.
- 대표 작업을 20~50개 정도 모으고, 위험·빈도·난이도로 나눕니다.
- 현재 버전의 결과를 사람 기준으로 판정해 기준선을 만듭니다.
- 출시 가능한 최소 조건과 중단해야 할 치명 오류를 합의합니다.
- 개선 실험은 한 번에 모델, 프롬프트, 도구, UX를 모두 바꾸지 않습니다.
- 새 버전이 기준선보다 나아졌는지와 어떤 작업에서 나빠졌는지를 함께 보고 배포를 결정합니다.
4. 알림은 행동과 연결한다
알림은 많을수록 좋은 것이 아닙니다. 수신자가 바로 실행할 수 있는 조건만 만듭니다.
| 신호 | 예시 대응 |
|---|---|
| 치명 오류 또는 정책 위반 | 영향 범위를 막고, 해당 버전·도구·데이터를 격리한 뒤 사람 검토 |
| 완료율 급락 또는 실패율 증가 | 최근 배포, 공급자 상태, 외부 도구, 입력 분포를 차례로 확인 |
| 품질 기준 미달 | 실패 사례를 묶어 모델·프롬프트·검색·UX 중 원인을 분류 |
| 비용 급증 | 재시도, 긴 입력, 도구 루프, 모델 라우팅, 비정상 트래픽을 확인 |
임계값은 고정값보다 최근 기준선과 서비스 약속의 차이로 정합니다. 알림마다 담당자, 첫 확인 시간, 되돌릴 수 있는 조치, 사후 기록 위치를 적어 둡니다.
5. 주간 운영 검토 템플릿
| 항목 | 이번 주에 확인할 내용 |
|---|---|
| 사용자 | 가장 많이 완료·중단한 작업, 반복되는 피드백 |
| 품질 | 기준별 실패 상위 사례, 치명 오류 여부, 평가 일치도 |
| 신뢰성 | 실패 원인별 추이, 가장 느린 단계, 폴백 동작 |
| 비용 | 완료 작업당 비용, 비용 이상 징후, 예산 전망 |
| 변경 | 배포한 모델·프롬프트·도구·데이터 버전과 영향 |
| 결정 | 유지·개선·중단할 항목, 담당자, 재검토 시점 |
Checklist
- 사용자가 끝내려는 작업과 실패의 피해를 문장으로 정의했다.
- 제품·프롬프트·모델·도구 버전을 요청 이벤트와 연결했다.
- 고위험 오류와 사람 검토 조건을 별도로 정했다.
- 자동 평가 결과를 사람 판정 표본으로 교정한다.
- 공급자 가격·한도는 배포 시점의 공식 문서로 다시 확인한다.
- 지표 변화가 발생했을 때 담당자와 대응 순서가 정해져 있다.