먼저 결론
30초 요약
출발점을 재고, 실제 완료까지 보고, 다음 결정을 정합니다.
실제 흐름업무 접수→AI 처리→사람 승인→실제 완료→자동화 전과 비교
| 용어 | 쉬운 뜻 |
|---|---|
| KPI | 파일럿이 나아졌는지 판단하려고 계속 확인하는 핵심 숫자 |
| 기준선 | 자동화하기 전 같은 업무를 같은 방식으로 잰 출발점 |
| 수정률 | AI 결과를 사람이 고친 업무의 비율 |
| 예외 처리율 | 자동 경로를 벗어나 사람이나 별도 절차로 넘어간 비율 |
- 목표값보다 정의가 먼저입니다. 한 건의 시작과 종료, 수정, 오류, 승인, 예외가 무엇인지 먼저 합의해야 합니다.
- 자동화 전 기준선을 같은 이벤트로 측정하세요. 수작업 기간에는 엑셀로 재고 파일럿 기간에는 시스템 로그를 쓰면, 측정 방식의 차이가 개선처럼 보일 수 있습니다.
- 처리시간은 평균 하나로 보지 마세요. 전체 경과시간과 실제 작업시간을 나누고 중앙값과 상위 지연 구간을 함께 봐야 합니다.
- 수정률과 오류율은 다릅니다. 표현을 다듬은 수정과 사실·정책·필드 값을 바로잡은 오류 수정을 분리해야 합니다.
- 승인 대기는 자동화의 성능이 아니라 운영 설계의 성능일 수 있습니다. AI 생성이 빨라도 승인 대기열이 길어지면 전체 완료시간은 줄지 않습니다.
- 예외는 실패로만 취급하지 마세요. 위험한 건을 사람에게 정확히 넘기는 것은 의도된 통제일 수 있습니다. 다만 과도한 예외는 자동화 범위나 입력 품질이 맞지 않는 신호입니다.
- 성공·중단·확장 기준은 파일럿 전에 정하세요. 결과를 본 뒤 기준을 바꾸면 좋은 수치만 선택하기 쉽습니다.
- 보편적인 성공 수치는 없습니다. 기준선 대비 최소 실질 개선폭과 업무별 품질·안전 한계를 책임자가 정해야 합니다.
KPI를 정하기 전에 측정 단위를 고정한다
가장 먼저 정할 것은 “무엇을 한 건으로 셀 것인가”입니다. 이메일 한 통, 신청서 한 장, 신청 한 건, 문서 묶음 하나는 서로 다른 단위입니다. 한 고객 요청이 세 번 재접수되었을 때 세 건으로 셀지 한 건의 재작업으로 셀지도 정해야 합니다.
파일럿 시작 전에 다음 여섯 항목을 데이터 사전에 적으세요.
| 항목 | 결정할 내용 | 잘못 정의했을 때 생기는 문제 |
|---|---|---|
업무 건(case) |
한 건의 고유 ID와 묶음 기준 | 분모가 기간마다 달라짐 |
| 대상 모집단 | 자동화가 처리하도록 허용된 건 | 어려운 건을 제외하고 성공률을 부풀릴 수 있음 |
| 시작 이벤트 | 접수, 작업 시작, AI 호출 중 무엇인지 | 대기시간이 빠지거나 중복됨 |
| 종료 이벤트 | 초안 생성, 승인, 실행, 고객 통지 중 무엇인지 | 부분 자동화를 완료로 오해함 |
| 정상 완료 | 업무상 필요한 결과가 확정된 상태 | 기술 호출 성공을 업무 성공으로 집계함 |
| 재개·재작업 | 완료 후 다시 열린 건의 처리 방식 | 사후 오류가 KPI에서 사라짐 |
같은 KPI 이름이라도 업무 단위가 다르면 비교할 수 없습니다. 예를 들어 신청서 “필드 정확도”와 신청 “건별 무수정 통과율”은 다른 질문에 답합니다. 전자는 어떤 항목이 자주 틀리는지 보여주고, 후자는 담당자가 한 건을 그대로 승인할 수 있는지 보여줍니다.
핵심 KPI 5개의 정의와 계산식
아래 계산식은 출발점입니다. 각 조직은 분자·분모, 제외 규칙, 업무시간 계산 방식, 오류 등급을 파일럿 전에 확정해야 합니다.
1. 처리시간: 한 건이 실제로 끝나는 데 얼마나 걸렸는가
처리시간은 적어도 두 가지로 나눠야 합니다.
전체 처리 경과시간(lead time)
건별 전체 처리시간 = 업무 완료 시각 - 업무 접수 시각
고객이나 다음 부서가 체감하는 시간입니다. 대기, AI 처리, 사람 검토, 승인, 재시도, 예외 처리까지 포함합니다.
실제 작업시간(touch time)
건별 실제 작업시간
= AI 실행 구간의 합 + 사람 작업 구간의 합
업무를 실제로 처리한 시간입니다. 대기열에 머문 시간은 별도로 봅니다. 사람 작업시간은 review_started와 review_ended처럼 시작·종료 이벤트가 있어야 계산할 수 있습니다. 화면을 열어 둔 채 다른 일을 하는 시간을 어떻게 처리할지도 규칙으로 정해야 합니다.
기준선 대비 변화율
처리시간 변화율
= (파일럿 처리시간 - 기준선 처리시간) / 기준선 처리시간 × 100
음수이면 단축, 양수이면 증가입니다. 보고서에서 부호가 혼동된다면 “단축률”을 별도로 정의할 수 있습니다.
처리시간 단축률
= (기준선 처리시간 - 파일럿 처리시간) / 기준선 처리시간 × 100
평균만 표시하면 일부 장기 지연 건이 전체 모습을 왜곡하거나, 반대로 다수의 빠른 건이 심각한 꼬리 지연을 가릴 수 있습니다. 건수, 중앙값, 90번째 백분위수(P90)를 함께 표시하세요. 여기서 P90은 “관찰된 건의 90%가 이 시간 이하에 끝났다”는 뜻이지 성공 기준 자체가 아닙니다.
Morrow 해석: AI 호출시간만 줄고 전체 처리시간이 줄지 않았다면 자동화 실패라기보다 승인, 시스템 입력, 예외 복귀 등 다른 병목이 드러난 것일 수 있습니다. 모델 교체 전에 구간별 시간을 확인해야 합니다.
2. 수정률: AI 결과를 사람이 얼마나 자주, 얼마나 많이 고쳤는가
수정률은 검토 여부와 수정의 크기를 함께 봐야 합니다.
건별 수정률
건별 수정률
= 사람이 하나 이상 수정한 AI 결과 건수 / 사람이 검토한 AI 결과 건수 × 100
분모는 “AI가 생성한 모든 건”이 아니라 실제로 사람이 검토를 끝낸 건으로 두는 편이 해석하기 쉽습니다. 검토하지 않은 건을 무수정으로 세면 수정률이 인위적으로 낮아집니다.
필드 수정률 — 정형 추출·입력 업무
필드 수정률
= 사람이 바꾼 필드 수 / 사람이 검토한 전체 필드 수 × 100
수정량 — 문서·텍스트 초안 업무
수정량 = 추가·삭제·대체된 단위 수
단위는 문자, 단어, 문장, 항목 중 업무에 맞게 고정합니다. 단순 편집 거리만으로는 의미가 큰 한 번의 숫자 수정과 사소한 문체 수정을 구분하기 어렵습니다. 따라서 수정 사유를 함께 기록합니다.
style: 표현·어조·형식factual: 사실·수치·고유명사policy: 사내 정책·승인 조건missing: 필요한 정보 누락unsupported: 근거 없는 내용routing: 잘못된 담당자·분류privacy_or_security: 민감정보·권한 관련 수정
수정률이 높아도 모든 수정이 오류인 것은 아닙니다. 회사 문체를 맞춘 편집과 계좌번호를 바로잡은 수정은 위험도가 다릅니다. 반대로 수정률이 낮더라도 검토자가 오류를 놓쳤다면 품질이 좋다는 뜻이 아닙니다.
3. 오류: 완료 결과가 업무 기준을 위반했는가
오류는 “AI가 마음에 들지 않는 결과”가 아니라 미리 정의한 정답, 정책, 스키마, 업무 규칙 또는 검증 절차를 위반한 결과여야 합니다.
검토 시 발견 오류율
검토 시 오류율
= 승인 전에 오류가 확인된 건수 / 검토 완료 건수 × 100
유출 오류율(escaped error rate)
유출 오류율
= 승인·실행 후 오류가 확인된 건수 / 승인·실행 완료 건수 × 100
재작업률
재작업률
= 완료 후 다시 열린 건수 / 완료 건수 × 100
세 지표를 분리하는 이유가 있습니다. 승인 전에 잡힌 오류는 검토 통제가 작동했다는 뜻일 수 있지만, 동시에 검토 비용이 크다는 뜻일 수 있습니다. 승인 후 발견된 오류는 고객, 재무, 규제 또는 운영 영향으로 이어질 수 있어 별도 관리가 필요합니다.
오류율에는 반드시 심각도를 붙이세요.
| 등급 설계 질문 | 업무별 예시를 정할 때 확인할 내용 |
|---|---|
| 치명적 | 법·안전·금전·권한·민감정보에 회복하기 어려운 영향을 주는가? |
| 중대 | 고객 또는 핵심 시스템에 영향을 주며 즉시 복구가 필요한가? |
| 경미 | 내부에서 쉽게 발견·수정되며 외부 영향이 제한적인가? |
위 표는 등급의 보편적 정의가 아니라 분류 질문입니다. 실제 등급과 허용 한계는 법무, 보안, 업무 책임자가 확정해야 합니다. 기술 오류도 업무 오류와 분리합니다.
- 기술 오류: 타임아웃, API 실패, 파싱 실패, 인증 실패
- 업무 오류: 잘못된 값, 누락, 정책 위반, 잘못된 실행
- 통제 오류: 승인 우회, 로그 누락, 권한 초과, 복구 실패
기술 호출이 성공해도 업무 결과가 틀릴 수 있고, AI 결과가 맞아도 승인 기록이 없으면 통제 관점에서는 실패일 수 있습니다.
4. 승인 지연: 검토 요청이 결정될 때까지 얼마나 기다렸는가
건별 승인 지연
= 승인 결정 시각 - 승인 요청 시각
승인 지연도 중앙값과 P90을 함께 봅니다. 업무시간 밖의 시간을 포함할지, 휴일·야간을 제외할지는 기준선과 파일럿에 동일하게 적용해야 합니다.
승인이 여러 단계라면 단계별로 계산합니다.
단계별 승인 지연 = 해당 단계 결정 시각 - 해당 단계 요청 시각
총 승인 지연 = 모든 승인 단계 지연의 합
추가로 다음을 표시하면 병목을 찾기 쉽습니다.
- 승인자·팀별 대기시간
- 승인 요청이 몰리는 시간대
- 재할당 횟수
- 반려 후 재요청 횟수
- 근거 부족으로 보류된 건수
- 승인 만료 또는 SLA 초과 건수
AI가 초안을 만드는 데 걸리는 시간이 짧아져도 승인 요청량이 한꺼번에 늘면 대기열이 길어질 수 있습니다. 그러므로 “AI 응답 속도”와 “업무 완료 속도”를 같은 것으로 보고하지 않습니다.
5. 예외: 자동 경로를 벗어나 사람이나 별도 절차로 넘어간 비율
예외율
= 예외 경로로 전환된 건수 / 자동화 대상 건수 × 100
여기서 분모는 전체 접수 건이 아니라 파일럿 규칙상 자동화 대상이었던 건입니다. 애초에 제외된 고위험 업무를 실패로 세지 말고, 반대로 처리하기 어려운 건을 대상 모집단에서 사후 제외하지도 마세요.
예외는 원인별로 나눕니다.
- 입력 누락·손상
- 지원하지 않는 문서 형식
- 낮은 신뢰도 또는 검증 실패
- 정책 충돌
- 민감정보·권한 문제
- 외부 시스템 장애
- 승인자 판단 필요
- 신규·미분류 예외
예외 처리가 끝날 때까지의 시간도 측정합니다.
예외 해결시간 = 예외 해결 시각 - 예외 발생 시각
Morrow 해석: 의도된 예외 전환은 안전장치입니다. 예외율을 무조건 낮추면 시스템이 확신하지 못하는 건까지 자동 실행하도록 압박할 수 있습니다. 목표는 “예외 0”이 아니라, 위험한 건은 빠짐없이 분리하고 반복 예외는 원인별로 줄이며 사람 대기열을 감당 가능한 상태로 유지하는 것입니다.
다섯 KPI는 따로 보지 말고 연결해서 읽는다
한 지표만 최적화하면 다른 곳에 비용이 생길 수 있습니다.
| 관찰된 조합 | 가능한 해석 | 다음 확인 |
|---|---|---|
| AI 실행시간 감소, 전체 처리시간 동일 | 승인·대기·시스템 입력 병목 | 단계별 시간과 대기열 |
| 수정률 감소, 유출 오류 증가 | 검토가 약해졌거나 오류를 놓침 | 사후 샘플 감사와 오류 심각도 |
| 오류율 감소, 예외율 급증 | 어려운 건을 모두 사람에게 넘김 | 예외 원인과 대상 범위 |
| 예외율 감소, 중대 오류 증가 | 안전 경계가 너무 느슨함 | 전환 규칙과 신뢰도 검증 |
| 처리시간 감소, 재작업 증가 | 완료를 너무 일찍 선언 | 종료 이벤트와 재개 기준 |
| 평균 개선, P90 악화 | 일부 복잡 건이 장기 지연 | 업무 복잡도별 분포 |
이 표는 진단 가설이지 자동 판정 규칙이 아닙니다. 실제 원인은 건별 로그와 현업 인터뷰로 확인해야 합니다. GOV.UK 서비스 매뉴얼도 거래형 서비스의 성과를 볼 때 성과 지표만이 아니라 사용자 조사와 여러 데이터 원천을 함께 사용하라고 안내합니다.[s1]
기준선은 자동화 전 업무를 같은 방식으로 측정한 값이다
기준선이 없으면 파일럿 결과는 “전보다 좋아 보인다”는 인상에 머뭅니다. 기준선은 과거 보고서의 평균 하나를 가져오는 것이 아니라, 파일럿과 비교 가능한 업무를 같은 정의와 이벤트로 측정한 분포입니다.
기준선 수집의 7가지 원칙
- 같은 업무 범위를 사용합니다. 자동화 대상과 수작업 기준선의 문서 유형, 채널, 고객군, 복잡도를 맞춥니다.
- 같은 시작·종료 정의를 사용합니다. 기준선은 접수부터 완료까지인데 파일럿은 AI 결과 생성까지만 재면 안 됩니다.
- 정상 건과 예외 건을 모두 남깁니다. 쉬운 건만 기준선 또는 파일럿에 포함하지 않습니다.
- 업무 주기를 포함합니다. 월말, 정산일, 캠페인, 휴가처럼 물량과 인력이 달라지는 주기를 고려합니다.
- 건수와 분포를 공개합니다. 평균 외에 중앙값, P90, 최소·최대 또는 사분위 범위를 보고합니다.
- 구성 차이를 분할합니다. 문서 유형, 난이도, 팀, 채널, 언어, 고객군 등 사전에 정한 세그먼트별로 봅니다.
- 측정 누락률을 기록합니다. 이벤트가 빠진 건을 조용히 제외하지 말고 별도 표시합니다.
과거 로그가 없다면
자동화 개발보다 먼저 짧은 수작업 계측 기간을 운영합니다. 담당자가 다음 버튼 또는 상태 변경만 남기도록 최소화할 수 있습니다.
접수 → 작업 시작 → 검토/입력 완료 → 승인 요청 → 승인/반려 → 최종 완료 → 재개
과거 데이터가 불완전하다면 그 사실과 결측 비율을 문서화합니다. 회상 설문으로 “보통 몇 분”이라고 받은 값은 참고 자료일 수 있지만, 자동 이벤트 로그와 같은 정밀도의 기준선으로 다루면 안 됩니다.
전후 비교가 곧 자동화 효과를 증명하는 것은 아니다
기준선 기간과 파일럿 기간 사이에 물량, 인력 숙련도, 정책, 입력 양식이 바뀌면 KPI 변화에는 그 영향도 섞입니다. 가능하면 같은 기간에 유사한 건을 기존 방식으로 처리하는 비교군을 두거나, 단계적으로 적용해 차이를 살펴봅니다. 비교군을 둘 수 없다면 “자동화 때문에 개선되었다”고 단정하지 말고, 함께 바뀐 조건을 제한사항에 적습니다.
NIST AI RMF Playbook의 MEASURE 기능은 AI 위험을 평가할 적절한 방법과 지표를 정하고 적용하며, 배포 후에도 평가와 모니터링을 지속하는 방향을 제시합니다.[s2] 이 원칙을 업무 자동화 파일럿에 적용하면, 출시 직전 일회성 정확도 테스트만으로 끝내지 않고 운영 데이터에서 성능과 위험을 계속 확인해야 한다는 뜻입니다. 이는 Morrow의 실무적 적용 해석이며 NIST가 이 글의 다섯 KPI나 임계값을 정해 준 것은 아닙니다.
계측 이벤트: KPI는 대시보드가 아니라 로그에서 시작된다
대시보드는 원본 이벤트를 계산해 보여주는 화면입니다. 이벤트가 없거나 의미가 바뀌면 차트는 정확해 보이지만 비교할 수 없습니다.
최소 이벤트 목록
| 이벤트 이름 | 발생 시점 | 주요 KPI |
|---|---|---|
case_received |
업무가 접수됨 | 전체 처리시간 |
work_started |
사람 또는 자동화가 처리 시작 | 대기·실제 작업시간 |
ai_invoked |
AI 요청 시작 | AI 구간 시간·호출 실패 |
ai_output_ready |
검토 가능한 결과 생성 | AI 구간 시간 |
review_started |
사람이 검토 시작 | 검토 대기·작업시간 |
output_edited |
사람이 결과 수정 | 수정률·수정 사유 |
review_completed |
사람 검토 종료 | 수정률 분모 |
approval_requested |
승인 대기열에 진입 | 승인 지연 |
approval_decided |
승인·반려·보류 결정 | 승인 지연·결과 |
execution_started |
시스템 반영 시작 | 실행 구간 시간 |
execution_completed |
반영 성공 | 정상 완료 후보 |
execution_failed |
반영 실패 | 기술·통제 오류 |
exception_raised |
예외 경로로 전환 | 예외율·원인 |
exception_resolved |
예외 처리 종료 | 예외 해결시간 |
case_closed |
업무상 최종 완료 | 전체 처리시간 |
case_reopened |
완료 후 재작업 시작 | 재작업·유출 오류 |
업무에 필요하지 않은 이벤트를 억지로 모두 구현할 필요는 없습니다. 다만 각 KPI의 시작과 종료가 되는 이벤트는 반드시 있어야 합니다.
이벤트마다 남길 필드
event_id 이벤트 중복 제거용 ID
case_id 업무 건 연결 ID
event_name 이벤트 종류
event_time 원천 시스템에서 실제 발생한 시각
observed_time 수집 시스템이 관찰한 시각
actor_type human | ai | system
actor_id 최소 권한으로 관리되는 작업자 식별자
workflow_version 자동화 흐름 버전
model_version 사용 모델·배포 버전
input_type 문서·요청 유형
complexity_segment 사전에 정의한 난이도 구간
decision approve | reject | hold 등
edit_reason 수정 사유 코드
error_code 오류 유형
severity 업무별 오류 심각도
exception_reason 예외 원인 코드
parent_event_id 재시도·수정·후속 이벤트 연결
OpenTelemetry의 공식 로그 데이터 모델은 이벤트 발생 시각인 Timestamp, 수집 시스템이 관찰한 ObservedTimestamp, 요청을 잇는 TraceId와 SpanId, 이벤트 종류를 식별하는 EventName, 추가 맥락을 담는 Attributes 등을 구분합니다.[s3] Morrow는 이 구조를 그대로 도입해야 한다고 주장하지 않습니다. 다만 여러 시스템을 통과하는 자동화에서 발생 시각과 관찰 시각, 건 연결 ID, 이벤트 유형, 추가 속성을 분리하는 설계는 지연과 누락을 추적하는 데 유용합니다.
로그에 원문 전체를 남기는 것이 정답은 아니다
계측을 위해 개인정보, 고객 문서, 프롬프트와 결과 전문을 무기한 저장하면 새로운 위험이 생깁니다. 다음을 별도로 결정하세요.
- 어떤 필드가 KPI 계산에 실제로 필요한가
- 원문 대신 해시, 문서 ID, 분류 코드로 충분한가
- 누가 로그를 조회할 수 있는가
- 보존 기간과 삭제 절차는 무엇인가
- 민감정보 마스킹은 어디에서 수행하는가
- 모델 개선용 데이터와 감사 로그를 분리할 것인가
- 작업자 식별자를 가명화할 수 있는가
“측정 가능성”은 “모든 내용을 저장할 권리”를 뜻하지 않습니다. 개인정보, 노동 모니터링, 보안, 기록 보존 의무는 조직의 법무·보안 정책에 따라 검토해야 합니다.
반드시 확인할 데이터 품질 지표
KPI 옆에 계측 자체의 품질을 표시합니다.
이벤트 완전성
= 필수 이벤트가 모두 존재하는 건수 / 대상 건수 × 100
연결 가능률
= 동일 case_id로 전 구간을 연결할 수 있는 건수 / 대상 건수 × 100
중복 이벤트율
= 중복으로 판정된 이벤트 수 / 수집 이벤트 수 × 100
필수 이벤트가 빠진 건을 제외하고 처리시간을 계산하면, 실패하거나 오래 걸린 건이 대시보드에서 사라질 수 있습니다. 결측 건은 제외 사유와 건수를 함께 보고하세요.
실무용 대시보드 표
대시보드의 첫 화면은 화려한 차트보다 의사결정에 필요한 열을 갖춘 표가 낫습니다. 아래 [입력] 칸은 보편적인 권장 수치가 아닙니다. 업무 책임자가 기준선과 위험 한계를 바탕으로 채우는 자리입니다.
| KPI | 정의·집계 | 기준선 | 파일럿 현재 | 목표 또는 허용 한계 | 상태 | 세그먼트·주의 |
|---|---|---|---|---|---|---|
| 완료 건수 | case_closed 고유 건 |
[입력] | [자동 집계] | 최소 관찰량 [입력] | 대기/충족 | 대상·제외 건수 병기 |
| 전체 처리시간 | 접수→최종 완료, 중앙값/P90 | [입력] | [자동 집계] | 기준선 대비 최소 실질 개선폭 [입력] | 개선/유지/악화 | 업무시간 규칙 고정 |
| 사람 작업시간 | 사람 작업 구간 합 | [입력] | [자동 집계] | [입력] | 개선/유지/악화 | 방치 시간 처리 규칙 |
| 건별 수정률 | 수정 건/검토 완료 건 | [입력] | [자동 집계] | 허용 범위 [입력] | 통과/재검토 | 수정 사유별 분리 |
| 검토 시 오류율 | 승인 전 오류 건/검토 건 | [입력] | [자동 집계] | 심각도별 한계 [입력] | 통과/중단 | 경미·중대·치명적 |
| 유출 오류율 | 승인 후 오류 건/실행 건 | [입력] | [자동 집계] | 심각도별 한계 [입력] | 통과/중단 | 재작업과 연결 |
| 승인 지연 | 요청→결정, 중앙값/P90 | [입력] | [자동 집계] | 업무 SLA 기반 [입력] | 통과/병목 | 승인자·시간대별 |
| 예외율 | 예외 전환 건/자동화 대상 건 | [입력] | [자동 집계] | 원인별 예상 범위 [입력] | 정상/재설계 | 안전 예외와 실패 분리 |
| 예외 해결시간 | 발생→해결, 중앙값/P90 | [입력] | [자동 집계] | 운영 수용 한계 [입력] | 통과/병목 | 대기열 용량 확인 |
| 이벤트 완전성 | 필수 이벤트 완비 건/대상 건 | [입력] | [자동 집계] | 계측 신뢰 한계 [입력] | 신뢰/판단 보류 | 결측 건수 병기 |
| 비용/건 | 모델·도구·사람·재작업 비용/완료 건 | [입력] | [자동 집계] | 사업성 한계 [입력] | 통과/재검토 | 고정비 포함 규칙 |
대시보드에 꼭 넣을 필터
- 기준선 / 파일럿
- 자동 처리 / 사람 처리 / 예외 처리
- 입력 유형과 채널
- 난이도 또는 위험 등급
- 팀과 승인 단계
- 워크플로 버전, 모델 버전
- 정상 완료 / 반려 / 재작업
- 일·주·업무 주기
전체 평균만 보면 특정 문서 유형이나 팀에서 발생하는 악화를 놓칠 수 있습니다. 확장 여부는 전체 지표뿐 아니라 중요한 세그먼트의 안전 한계도 통과했는지 보고 결정합니다.
성공·중단·확장 기준은 어떻게 설정해야 하나
인터넷에서 본 “정확도 몇 퍼센트”, “시간 절감 몇 퍼센트”를 그대로 가져오지 마세요. 같은 숫자라도 계약서 금액 추출, 사내 회의록 초안, 고객 환불 실행의 오류 비용은 전혀 다릅니다.
1단계: 업무 목적과 손실을 한 문장으로 적는다
예:
목적: 신청서 검토자가 반복 입력에 쓰는 시간을 줄이되,
승인 후 고객·재무 시스템으로 잘못된 값이 넘어가는 위험은
현재 수작업 수준보다 악화시키지 않는다.
목적에는 속도만 아니라 지켜야 할 품질과 위험을 함께 넣습니다.
2단계: 기준선 분포와 현재 의무를 확인한다
- 현재 중앙값·P90 처리시간
- 현재 수정, 오류, 재작업, 예외
- 계약상 처리시간 또는 내부 SLA
- 법률·보안·감사 요구
- 한 번의 오류가 만드는 복구 비용과 외부 영향
- 팀이 감당할 수 있는 승인·예외 대기열
공개 벤치마크보다 이 정보가 임계값 설정에 더 직접적입니다.
3단계: 최소 실질 개선폭을 정한다
“숫자가 조금 좋아지면 성공”이 아니라, 개발·운영·검토·변경 비용을 고려했을 때 의미가 있는 개선폭을 업무 소유자가 정합니다. 이를 표에 [최소 실질 개선폭]으로 기록합니다.
통계적으로 차이가 보이는 것과 사업적으로 의미가 있는 것은 다릅니다. 처리 건수가 매우 많으면 작은 차이도 통계적으로 두드러질 수 있지만 실제 비용 절감은 미미할 수 있습니다. 반대로 표본이 적으면 큰 차이가 보여도 우연일 수 있습니다. 데이터 분석 담당자가 있다면 사전에 검정 방법과 필요한 관찰량을 정하고, 없다면 최소한 충분한 업무 주기와 주요 예외 유형을 관찰했는지 공개하세요.
4단계: 품질·안전 가드레일을 먼저 정한다
다음 사건은 평균 KPI와 별도로 관리합니다.
- 승인 없는 외부 발송·결제·삭제·권한 변경
- 민감정보 노출 또는 권한 밖 접근
- 복구할 수 없는 시스템 변경
- 법률·안전·재무상 중대한 잘못된 판단
- 감사 로그 누락이나 승인 기록 위변조
- 같은 중대 오류의 반복
어떤 사건을 한 번만 발생해도 중단할지, 조사 중 일시 정지할지, 제한된 범위에서 수정할지는 업무 책임자·보안·법무가 사전에 정해야 합니다. 모든 업무에 일률적으로 “치명적 오류 0건” 같은 문구를 붙이는 대신, 무엇이 치명적인지와 허용 여부를 업무별로 명시하는 것이 핵심입니다. 일부 업무는 성격상 무관용 기준이 필요할 수 있지만 그것 역시 해당 업무의 위험 판단에서 나와야 합니다.
5단계: 관찰량과 기간을 정한다
“30일이 지났으니 성공”이 아니라 다음 조건을 충족해야 합니다.
- 사전에 정한 최소 대상 건수를 처리했는가
- 평시와 피크 기간을 모두 관찰했는가
- 중요한 문서·고객·업무 유형이 포함되었는가
- 알려진 주요 예외를 실제로 검증했는가
- 워크플로와 모델 버전이 중간에 크게 바뀌지 않았는가
- 바뀌었다면 버전별 결과를 분리했는가
보편적인 최소 건수는 제시할 수 없습니다. 오류가 드물지만 손실이 큰 업무는 더 긴 관찰과 별도 안전 검증이 필요할 수 있습니다.
6단계: 의사결정 표를 파일럿 전에 승인한다
| 결정 | 사전 조건을 정하는 방법 |
|---|---|
| 성공 | 핵심 효율 지표가 최소 실질 개선폭을 충족하고 모든 품질·안전 가드레일을 통과 |
| 수정 후 계속 | 안전 가드레일은 통과했지만 병목·수정·예외 원인이 특정되어 제한된 변경으로 검증 가능 |
| 중단 | 사전 정의한 중단 사건 발생, 통제 불능, 복구 실패, 계측 불신으로 안전 판단 불가 |
| 확장 | 성공 조건에 더해 업무 주기·세그먼트·운영 인수·모니터링·복구 준비가 완료 |
| 판단 보류 | 관찰량 부족, 구성 차이, 이벤트 누락, 버전 혼합 때문에 결론을 낼 수 없음 |
“판단 보류”는 실패가 아닙니다. 신뢰할 수 없는 데이터로 성공을 선언하는 것보다 정직한 결론입니다.
30/60/90일 리뷰: 날짜가 아니라 질문을 바꾼다
아래 30/60/90일 구조는 보편적 표준이 아니라 리뷰 리듬의 예시입니다. 업무 위험과 처리량에 따라 더 짧게 또는 길게 조정하세요.
30일 리뷰: 정의와 계측을 검증한다
목표는 성과 홍보가 아니라 “이 숫자를 믿을 수 있는가”를 확인하는 것입니다.
- 대상 업무와 제외 조건이 문서화되었는가
- 기준선과 파일럿의 시작·종료 이벤트가 같은가
case_id로 전 구간을 연결할 수 있는가- 누락·중복·시간대 오류가 있는가
- 수정 사유, 오류 심각도, 예외 원인이 일관되게 분류되는가
- 민감정보를 과도하게 로그에 저장하지 않는가
- 승인 우회와 복구 실패를 탐지할 수 있는가
- 기준선과 파일럿의 업무 구성이 비교 가능한가
30일 결정: 계측 신뢰도가 부족하면 성과 판단을 미루고 로그를 고칩니다. 안전 사건이 발생했다면 사전 중단 절차를 따릅니다.
60일 리뷰: 병목과 실패 유형을 진단한다
- 전체 처리시간과 실제 작업시간은 각각 어떻게 변했는가
- AI 단계에서 줄어든 시간이 승인 대기로 이동하지 않았는가
- 수정률이 높은 입력 유형과 수정 사유는 무엇인가
- 오류는 어느 단계에서 발견되는가
- 예외는 의도된 안전 전환인가, 입력·연동 실패인가
- 담당자별 편차가 교육, 규칙 해석, 업무 난이도 때문인가
- 모델·프롬프트·워크플로 버전 변경이 결과에 영향을 주었는가
- 예외 대기열과 승인자의 업무량은 감당 가능한가
60일 결정: 원인이 특정되고 가드레일을 침해하지 않는다면 범위를 넓히기보다 한 가지 변경만 적용해 다시 측정합니다. 여러 요소를 동시에 바꾸면 무엇이 효과를 냈는지 알기 어렵습니다.
90일 리뷰: 성공·중단·확장을 결정한다
- 최소 관찰량과 주요 업무 주기를 채웠는가
- 핵심 효율 KPI가 사전 합의한 최소 실질 개선폭을 충족했는가
- 심각도별 품질·안전 한계를 모두 통과했는가
- 평균뿐 아니라 P90과 중요 세그먼트도 악화되지 않았는가
- 승인·예외·재작업을 포함한 건당 비용이 수용 가능한가
- 현업이 대시보드, 수동 전환, 복구 절차를 실제로 사용할 수 있는가
- 운영 책임자, 모니터링 주기, 변경 승인 절차가 정해졌는가
- 확장할 다음 범위가 현재 파일럿과 충분히 유사한가
90일 결정: 성공해도 전사 확대가 자동으로 따라오지 않습니다. 유사한 입력과 위험 구조를 가진 다음 범위로 단계적으로 확장하고, 범위가 달라지면 새 기준선과 임계값을 정합니다.
복사해서 쓰는 KPI 정의서
[업무]
업무 이름:
업무 소유자:
한 건의 정의:
자동화 대상:
사전 제외 대상:
시작 이벤트:
종료 이벤트:
재개·재작업 정의:
[기준선]
수집 기간과 업무 주기:
대상 건수 / 제외 건수 / 결측 건수:
중앙값 / P90 처리시간:
수정률과 수정 사유:
심각도별 오류와 유출 오류:
승인 지연:
예외율과 해결시간:
건당 비용:
[목표]
최소 실질 개선폭:
유지해야 할 품질 한계:
즉시 중단 사건:
판단 가능한 최소 관찰량:
중요 세그먼트:
[계측]
필수 이벤트:
필수 필드:
시간대·업무시간 규칙:
로그 보존·접근·마스킹:
워크플로/모델 버전 기록:
결측·중복 처리 규칙:
[리뷰]
30일 계측 검토 책임자:
60일 병목 검토 책임자:
90일 의사결정권자:
성공 / 수정 / 중단 / 확장 승인 방식:
자주 묻는 질문
AI 자동화 파일럿에서 가장 중요한 KPI 하나만 고르면 무엇인가요?
업무마다 다릅니다. 고객이 완료를 기다리는 업무라면 전체 처리시간이 핵심일 수 있고, 금액이나 권한을 다루는 업무라면 유출 오류와 통제 오류가 우선일 수 있습니다. 한 지표만 고르기보다 핵심 성과 지표 하나와 품질·안전 가드레일을 함께 정하세요.
처리시간은 평균으로 보면 안 되나요?
평균도 참고할 수 있지만 단독으로 쓰지 않는 편이 좋습니다. 일부 장기 지연과 다수의 빠른 건을 함께 이해하려면 건수, 중앙값, P90을 같이 표시하세요. 업무시간 포함 방식도 기준선과 파일럿에 동일해야 합니다.
사람이 문장 하나라도 바꾸면 수정 건인가요?
건별 수정률에서는 그렇게 정의할 수 있습니다. 다만 의미 있는 해석을 위해 문체·형식 수정과 사실·정책·누락·민감정보 수정을 분리하세요. 정형 업무라면 건별 수정률과 필드 수정률을 함께 보는 것이 유용합니다.
예외율이 높으면 파일럿 실패인가요?
반드시 그렇지는 않습니다. 위험하거나 지원하지 않는 건을 사람에게 넘기는 것이 설계 목적이라면 정상적인 통제입니다. 다만 어떤 원인이 예외를 만들었는지, 자동화 대상 정의가 적절한지, 사람 대기열이 감당 가능한지를 확인해야 합니다.
정확도 목표를 업계 평균으로 정하면 안 되나요?
공개 수치를 참고할 수는 있지만 그대로 성공 기준으로 쓰면 안 됩니다. 데이터, 정답 정의, 업무 단위, 오류 비용, 검토 방식이 다르면 같은 정확도도 의미가 달라집니다. 내부 기준선과 업무상 허용 한계를 우선하세요.
파일럿 중 모델이나 프롬프트를 바꿔도 되나요?
안전 문제를 고치기 위해 바꿀 수 있습니다. 다만 변경 시점, 이유, 워크플로·모델·프롬프트 버전을 기록하고 결과를 버전별로 나눠 보세요. 여러 요소를 동시에 바꾸면 개선 원인을 특정하기 어렵습니다.
데이터가 적으면 90일 뒤에도 결론을 내야 하나요?
아닙니다. 중요한 예외와 업무 주기를 충분히 관찰하지 못했다면 “판단 보류”가 올바른 결론입니다. 기간을 채운 사실보다 판단 가능한 데이터가 있는지가 중요합니다.
대시보드만 만들면 계측이 끝난 것인가요?
아닙니다. 원본 이벤트의 정의, 누락·중복 처리, 시간대, 버전, 접근 권한이 먼저입니다. 대시보드는 그 결과를 계산해 보여줄 뿐입니다. 필수 이벤트가 빠진 비율도 KPI와 함께 표시하세요.
파일럿을 시작하기 전에 기준선부터 만드세요
Morrow의 무료 업무 자동화 자가진단은 후보 업무의 반복성, 입력·출력, 예외, 승인, 데이터 민감도, 복구 가능성을 먼저 점검하도록 돕습니다.
진단 후 파일럿을 설계한다면 다음 세 가지를 준비하세요.
- 자동화 전 업무 건의 시작·종료·수정·오류·승인·예외 기록
- 업무 책임자가 승인한 성공·중단·확장 조건
- 사람 승인과 원래 방식으로의 복귀 절차
기준선 수집, 이벤트 설계, 대시보드 정의가 필요한 경우 자가진단 결과를 바탕으로 Morrow 파일럿 설계 상담을 요청할 수 있습니다. 이 글의 계산식과 표는 진단 도구이며 특정 성과나 투자수익을 보장하지 않습니다.
파일럿 대상 선정이 먼저라면 중소기업 AI 에이전트 첫 자동화 가이드를 함께 읽어보세요.
출처와 사용 범위 보기
출처
- [s1] GOV.UK Service Manual / Performance analysis community, 「Measuring the success of your service」. https://www.gov.uk/service-manual/measuring-success/measuring-the-success-of-your-service (접근일: 2026-07-12)
- [s2] National Institute of Standards and Technology (NIST) AI Resource Center, 「AI RMF Playbook — Measure」. https://airc.nist.gov/airmf-resources/playbook/measure/ (접근일: 2026-07-12)
- [s3] OpenTelemetry, 「Logs Data Model」. https://opentelemetry.io/docs/specs/otel/logs/data-model/ (접근일: 2026-07-12)
- [s4] National Institute of Standards and Technology (NIST), 「AI Risk Management Framework」. https://www.nist.gov/itl/ai-risk-management-framework (접근일: 2026-07-12)
- [s5] Google People + AI Research, 「People + AI Guidebook」. https://pair.withgoogle.com/guidebook-v2/ (접근일: 2026-07-12)
출처 사용 메모와 한계
- GOV.UK 자료는 측정 방법을 서비스 목적에 맞추고 성과 지표 외에 사용자 조사와 여러 데이터 원천을 함께 보라는 원칙의 근거로 사용했습니다.[s1]
- NIST AI RMF와 Playbook은 위험 측정 방법·지표 선정과 지속적인 평가·모니터링의 공식 지침으로 참고했습니다.[s2][s4] NIST 페이지에는 AI RMF가 업데이트 중이며 Playbook도 이후 갱신될 예정이라는 안내가 있으므로 공식 페이지의 이후 업데이트 여부도 함께 확인해야 합니다.
- OpenTelemetry는 로그 필드와 이벤트 연결 방식의 공식 기술 규격 근거로 사용했습니다.[s3] 이 규격이 Morrow의 KPI 정의나 업무별 임계값을 규정하는 것은 아닙니다.
- Google PAIR Guidebook은 인간 중심 AI 설계의 공식 실무 자료라는 맥락에서 검토했습니다.[s5] 본문 계산식과 임계값의 근거로 사용하지 않았습니다.
- 본문의 KPI 계산식, 이벤트 이름, 대시보드, 30/60/90일 리뷰 구조는 위 원칙을 업무 자동화 파일럿에 적용한 Morrow의 실무 제안입니다. 법적 기준, 산업 표준, 보편적 성공 수치로 제시하지 않습니다.
- 이 글에는 고객 성과, 독립 검증되지 않은 공급사 성공률, 보편적인 시간 절감률·정확도 목표를 넣지 않았습니다.