회의실에서 가장 비싼 문장
“이 업무, AI로 자동화하면 빨라지지 않을까요?”
가장 자주 듣고 가장 위험한 제안이다. 틀려서가 아니라 한 단계를 건너뛰기 때문이다 — “그 업무는 왜 존재하는가, 그대로 존재해야 하는가?”
대부분의 자동화 제안은 현재 절차를 사실로 전제한다. 누군가 요청을 보내고, 담당자가 처리하고, 요청자가 상태를 다시 묻고, 담당자가 또 답한다. 이 흐름을 의심하지 않은 채 “답하는 부분을 AI가 대신하게 하자”를 올린다. 결과는 예측된다. 요청도 재확인도 줄지 않고, AI는 전달과 답변을 더 빠르게 반복할 뿐이며, 토큰 비용과 운영 고정비가 붙는다. 빨라졌지만 줄어든 것은 없다.
직접 과제를 굴려보며 가장 많이 본 실패가 이 모양이다. 봇은 잘 돌았고 요청은 그대로였다 — 일화가 아니라 패턴이다. AX 실패의 대부분은 기술 결함이 아니라 전략·거버넌스·변화관리에서 온다.1 더 결정적인 신호가 있다. 모델을 고르기 전에 엔드투엔드 워크플로를 먼저 재설계한 조직이, 그러지 않은 조직보다 재무 성과를 낸 비율이 더 높게 관찰됐다.2 반대로 다수 조직은 직무와 흐름을 손대지 않은 채 도구만 얹었다.3 단 이것은 상관이지 인과가 아니다. “재설계를 건너뛴 자동화는 성과를 내기 어려운 쪽에 몰려 있다”는 방향성이다.
정리하면 이렇다. 재설계 없이 자동화하면 비용은 늘고 성과는 안 난다. 재설계하고 자동화하면 같은 인원이 더 검증된 산출을 만든다. 이 장은 그 재설계를 회의에서 즉석 판정하는 도구 — 6분류 의사결정 트리 — 를 제공한다. 백서가 “워크플로 재설계가 중요하다”고 선언했다면, 이 장은 “후보가 6개 중 어디에 속하며 무엇을 먼저 확인하고 무엇을 만들지 말지”를 판정하게 한다.
핵심 관점: 자동화는 마지막 수단이 아니라 마지막 단계다
“재설계가 먼저”는 “자동화를 미루라”가 아니다. 자동화를 업무 재설계와 함께 쓰는 실행 수단으로 본다는 뜻이고, 차이는 순서에 있다.
재설계 없는 순서: 반복 발견 → 도구 제작 → 배포 → (효과 측정은 나중에)
재설계 우선 순서: 반복 발견 → 왜 반복되는가 진단 → 요청을 줄이거나 사용자가 직접 끝내게 할 수 있는가 → 남는 반복만 자동화 → 효과 측정
핵심 진단 질문은 하나다. “이 요청을, 요청 없이 끝내게 만들 수 있는가?”
반복 요청은 자동화 대상이 아니라 문제가 드러나는 신호다. 같은 질문이 반복되면 문서가 없거나 찾기 어렵다는 신호, 같은 신청이 반복되면 사용자가 직접 처리할 수 없게 막혀 있다는 신호, 같은 상태 확인이 반복되면 상태가 보이지 않는다는 신호다. 목표는 신호를 더 잘 처리하는 것이 아니라 신호가 생기는 원인을 없애는 것이다. 그래서 가장 좋은 자동화는 흔히 “자동화하지 않는 결정”이다 — FAQ 한 장, 셀프서비스 버튼 하나, 상태 조회 화면 하나가 봇 열 개보다 요청을 더 많이 없앤다. 던질 질문은 “얼마나 빨라지나”가 아니라 “이 요청을 없앨 수는 없나”다.
6분류 의사결정 트리
모든 반복 업무 후보는 자동화 여부를 묻기 전에 6개 분류 중 하나로 판정한다. 분류가 다르면 우선 조치도, 자동화 역할도, 성공 기준도 다르다. 분류를 건너뛰고 곧장 자동화로 가는 것이 가장 흔한 실패의 시작이다.
트리: 위에서부터 순서대로 묻는다
[반복 업무 후보]
│
▼
Q1. 같은 문의·보완 요청이 반복되는가?
(정보·안내·입력 누락이 원인)
├─ 예 ─────────────────────────────▶ A. 요청 축소형
└─ 아니오
│
▼
Q2. 담당 배정·승인 단계·처리 상태가
불명확해 반복 확인이 생기는가?
├─ 예 ─────────────────────────────▶ B. 업무 재설계형
└─ 아니오
│
▼
Q3. 요청의 원인이 제품·도구에
기능이 없어서인가?
├─ 예 ─────────────────────────────▶ C. 시스템 흡수형
└─ 아니오
│
▼
Q4. 법무·보안·권한·금전·대외 발송처럼
사람의 책임 판단이 반드시 필요한가?
├─ 예 ─────────────────────────────▶ D. 승인 보조형
└─ 아니오
│
▼
Q5. 문서 부재·최신성 부족·검색 실패로
같은 질문이 반복되는가?
├─ 예 ─────────────────────────────▶ E. 지식 정리형
└─ 아니오
│
▼
Q6. 입력·규칙·결과가 명확하고
예외가 낮으며 실패 복구가 쉬운가?
├─ 예 ─────────────────────────────▶ F. 자동 처리형
└─ 아니오 ─────────────────────────▶ 재설계 미완. 후보로 되돌려 원인 재진단순서에 의미가 있다. 자동 처리형(F)이 맨 아래인 것은 의도된 설계다. 곧장 자동화해도 좋은 업무는 다른 모든 가능성을 소거한 뒤에야 도달한다. 위쪽(A–E)은 재설계·정책·기능 개선이 먼저고, 후보를 직접 넣어보면 대부분 F가 아니라 A–C에 떨어진다.
B와 C는 가장 자주 헷갈린다. 가르는 질문은 하나다. 사람이 규칙(담당 기준·상태값·예외 기준)을 정하면 풀리는가? → B형. 제품·도구에 없는 기능을 새로 넣어야 풀리는가? → C형. B는 운영 리더가 시작하고 C는 제품·개발 백로그로 넘어간다. 둘을 섞으면 정책으로 풀 일을 개발로 키우거나(과잉), 개발로 풀 일을 사람 규칙으로 메우다 한계에 부딪힌다(과소).
6분류 요약표
| 분류 | 회의에서 들리는 증상 | 무엇이 원인인가 | 우선 조치(자동화보다 먼저) | 자동화의 역할 | 성공 기준 |
|---|---|---|---|---|---|
| A. 요청 축소형 | “이거 어디서 신청해요?”가 반복된다 | 정보·안내가 닿지 않음, 입력 누락 | 공지·FAQ·입력 양식·사전 검증 강화 | 문의 전 추천, 누락 점검, 안내 초안 | 문의 유입 감소율, 문의 전 자가 해결률 |
| B. 업무 재설계형 | “지금 누가 처리해요?”, “어느 단계예요?”가 반복된다 | 담당·승인·상태가 불명확 | 셀프서비스 범위·담당 기준·상태값·SLA 정의 | 직접 처리, 상태 추적, 예외 문의 큐 | 재확인 횟수 감소, 직접 완료 비율 |
| C. 시스템 흡수형 | “그건 시스템에 없어서 제가 대신 해드려요” | 제품·도구에 기능이 없음 | 관리자 기능·셀프서비스 기능·대시보드 개선 | 개선 전까지 보조, 개선 후 요청 감소 측정 | 운영 요청 감소율(기능 반영 후) |
| D. 승인 보조형 | “이건 제가 확인하고 책임져야 해요” | 사람의 책임 판단 필요 | 승인 기준·필수 증빙 표준화 | 체크리스트, 리스크 항목 추출, 승인 전 큐 | 반려율 감소, 누락 감소, 판단은 사람 유지 |
| E. 지식 정리형 | “그 문서 어디 있죠?”, “전에도 물어봤는데” | 문서 부재·노후·검색 실패 | 문서 오너·만료 기준·검색 인덱스 정리 | 문서 후보 탐지, 요약, 갱신 요청 | 반복 질문 감소, 문서 최신성 |
| F. 자동 처리형 | “매번 똑같이, 그냥 손이 많이 가요” | 반복은 본질적, 예외 낮음 | 표준 처리 규칙 정의 | 분류·생성·실행·로그 기록 | 처리량 증가, 단위비용, 예외 처리율 |
핵심은 오른쪽 세 열이다. A~E에서 자동화는 “사람을 대체하는 실행 주체”가 아니라 “재설계를 보조하는 도구”고, 오직 F에서만 실행 주체가 된다. 성공 기준도 달라 A는 요청이, B는 재확인이, F는 처리량이 변했는지를 본다. 분류를 정하지 않으면 무엇을 측정할지도 정할 수 없다(10장 증거 등급 참조).
단계별 적용: 후보 워크시트
후보 하나를 놓고 10개 질문에 순서대로 답한다. 이 워크시트가 6분류 판정과 다음 산출물(파일럿 PRD 전 단계)을 정의한다.
| # | 질문 | 답하지 못하면 |
|---|---|---|
| 1 | 이 요청은 왜 발생하는가? | 재설계 불가. 원인 진단부터 다시 |
| 2 | 사용자가 직접 해결할 수 없는 이유는 무엇인가? | 셀프서비스 가능성 미확인 |
| 3 | 요청 전에 보여줄 공지·FAQ·가이드·입력 검증이 있는가? | A형(요청 축소) 후보 |
| 4 | 사용자가 직접 처리·조회·신청할 수 없어 생기는 반복 확인인가? | B형(업무 재설계) 후보 |
| 5 | 담당자 기준이 불명확해 생기는 배정 업무인가? | B형 후보 |
| 6 | 시스템에 기능이 없어 운영자가 대신 처리하는가? | C형(시스템 흡수) 후보 |
| 7 | 승인·검수·책임 판단 때문에 사람이 반드시 봐야 하는가? | D형(승인 보조) 후보 |
| 8 | 자동화 없이 정책·양식·권한 설계로 처리량을 줄일 수 있는가? | 자동화는 아직 이르다 |
| 9 | 남는 반복 중 안전하게 자동화할 범위는 어디까지인가? | F형 적용 경계 미정 |
| 10 | 파일럿 성공 기준은 무엇인가?(처리량·리드타임·재확인 중) | 측정 불가. 파일럿 금지 |
10번에 답하지 못하면 파일럿을 열지 마라(6·8·10장 연결).
PRD 작성 전 통과 기준
분류가 확정되면 다음 중 하나로 방향을 정한 뒤 PRD/실행계획으로 넘어간다.
| 분류 | 통과 기준 | 다음 산출물 |
|---|---|---|
| 요청 축소(A) | 문의 전 해결 가능 유형이 상위 요청 중 일정 비중 이상 | FAQ·공지 추천 파일럿 |
| 업무 재설계(B) | 직접 처리 범위·담당 기준·상태값·예외 기준을 정의할 수 있음 | 셀프서비스·상태 조회 PRD |
| 시스템 흡수(C) | 반복 요청 원인이 제품·도구 기능 부족으로 확인됨 | 관리자 기능·대시보드 개선안 |
| 승인 보조(D) | 필수 증빙·승인 라인·반려 기준을 정리할 수 있음 | 승인 전 체크리스트 PRD |
| 지식 정리(E) | 반복 질문과 문서 공백을 연결할 수 있음 | 문서 갱신 큐 파일럿 |
| 자동 처리(F) | 입력·규칙·결과·예외 처리 기준이 명확함 | 자동 처리 PRD |
분류별 미니 판정: A~F를 회의에서 30초에 가른다
요약표만으로 부족할 때, 각 분류에서 먼저 확인할 것이다.
- A. 요청 축소형 — 직접 해결 가능한 요청 유형이 상위에 몇 개인가, 자가 처리 경계를 넘는 건 무엇인가.
- B. 업무 재설계형 — 상위 묶음을 직접 처리·승인 신청·예외 문의로 나눌 수 있는가, 상태값과 완료의 원천은 어디인가.
- C. 시스템 흡수형 — 빠진 기능이 무엇이고, 넣으면 요청이 실제로 사라지는가(측정 가능한가).
- D. 승인 보조형 — 필수 증빙·승인 라인·반려 기준을 글로 적을 수 있는가. 자동화는 승인 전 보조까지만, 최종 판단은 사람이 유지한다.
- E. 지식 정리형 — 반복 질문과 문서 공백을 연결할 수 있는가, 문서 오너와 만료 기준이 있는가.
- F. 자동 처리형 — 예외를 사람 검토 큐로 뺄 수 있는가, 실패 시 보류/원복으로 떨어지는가.
C와 E는 표에만 살아 있기 쉽지만 가장 큰 요청량이 여기 숨어 있다. 답을 빨리 만든다고 사라지지 않는다. 기능을 넣거나 문서를 세워야 사라진다.
“현재 절차를 그대로”라는 함정과 Anti-Slop 연결
F에 도달했다고 끝이 아니다. 마지막 함정은 사람의 협업 절차를 그대로 에이전트에 복제하는 것이다. “취합 → 전달 → 재확인” 3단계를 그대로 시키면, 한 번에 끝낼 일을 3단계로 쪼개 비용만 3배로 쓴다. 맡기면 생략 가능한 단계는 자동화 전에 먼저 제거한다.
여기서 6장(Anti-Slop 게이트)이 시작된다. 분류가 끝났다면 구현은 가벼운 것부터다.
- 이미 쓰는 협업 도구·기존 DB·BI 화면으로 해결되는가?
- Skill·MCP·스크립트·프롬프트 흐름으로 충분한가?
- 기존 서비스 관리 화면·승인 흐름에 얇게 붙일 수 있는가?
- 별도 풀스택 앱·대시보드가 정말 필요한가?
별도 화면을 만드는 것이 곧 AX가 아니다. Skill·MCP로 될 일을 풀스택 앱으로 키우면 비용 절감 과제가 운영 고정비로 바뀐다. 5장은 “무엇을 재설계할지”, 6장은 “그것을 만들지 말지”를 묻는 한 쌍이다.
흔한 실패모드
재설계를 건너뛴 자동화가 어떻게 무너지는지를 정리했다. 각 모드 끝의 레드플래그는 “이 말이 나오면 의심하라”는 회의용 판별구다.
1 — 절차 복제(Pave the cowpath). 신청서·승인 단계·확인 절차를 그대로 둔 채 답변만 AI로 바꾼다. 결과: 요청량 불변, 비용 증가. 레드플래그: “기존 프로세스는 유지하고 AI가 빠르게 처리합니다.” 차단: 진단 질문 + 워크시트 1·8번.
2 — 분류 생략. 후보를 “다 자동화 대상”으로 묶는다. 결과: A형인데 처리량만 보다가 요청은 그대로인 걸 놓침. 레드플래그: 모든 후보의 성공 기준이 “처리 시간 단축”으로 똑같다. 차단: 요약표 성공 기준 열.
3 — 신호 처리에 집착. 반복 요청을 더 잘 분류·라우팅하는 데 집중한다. 직접 굴려보며 분류 정확도를 끌어올리는 데 한 분기를 쓰고도 요청량은 한 건도 줄지 않았다. 정확도 KPI를 폐기하고 “요청량 자체”를 성공지표로 바꾼 뒤에야 설계가 제자리를 찾았다. 레드플래그: “요청 자동 분류 정확도 95% 달성”이 성과로 보고된다. 차단: “신호는 문제다, 처리 대상이 아니다” + 워크시트 2번.
4 — 승인 판단 자동화. D형에서 사람의 책임 판단까지 자동 실행한다. 결과: 사고 시 책임 소재 불명, 감사 비용 폭증. 레드플래그: 대외 발송·금전·권한 변경을 “사람 검토 없이” 자동화한다. 차단: D형은 승인 전 보조까지만 + 워크시트 7번.
5 — 풀스택 과잉. Skill·MCP로 될 일을 별도 앱으로 만든다. 결과: 운영 고정비 누적. 레드플래그: 파일럿 하나에 서버·배포·인증·모니터링이 붙는다. 차단: 6장 Anti-Slop 게이트.
6 — 측정 없는 파일럿. 기준선 없이 시작하고 끝나서 효과를 주장한다. 결과: 체감만 남고 확대 결정을 못 내림. 레드플래그: 워크시트 10번에 답이 없는 채로 착수한다. 차단: 워크시트 10번 = 파일럿 승인 조건(10·12장).
7 — C·E를 자동화로 덮기. 빠진 기능(C)이나 문서(E)가 원인인데 사람이 대신 답하는 부분만 자동화한다. 결과: 답은 빨라지지만 요청은 그대로. 레드플래그: “시스템에 없어서 매번 대신 해드린다”에 봇만 붙인다. 차단: 트리 Q3·Q5 + 미니 판정.
Before/After: 같은 업무, 두 갈래의 결정
예를 들어 한 채용 플랫폼 기업의 영업 운영 지원 조직을 보자. 영업 담당자들이 “내 건은 누가 처리하나요”, “어느 단계인가요”, “승인됐나요”를 운영 채널로 하루 수십 건 보낸다. 운영팀은 담당을 배정하고 상태를 확인해 답하고 다시 묻는 질문에 또 답한다. 같은 건에 대해 같은 사람이 오전과 오후에 두 번 묻는 일이 흔했고, 운영팀 입장에선 “방금 답해드렸는데”라는 말을 삼키며 다시 화면을 열어 확인하는 게 일과의 한 축이었다. 리더가 “AI로 자동화하자”고 제안한다.
갈래 A — 재설계를 건너뛴 자동화 (Before)
운영팀은 요청을 자동 분류하고 담당자를 추천하고 답변 초안을 만드는 봇에 풀스택 대시보드까지 붙인다. 한 분기 뒤: 봇은 잘 작동하지만 요청량은 줄지 않았다. 봇이 답해도 “확실하냐”고 다시 묻고, 초안 검토 단계가 하나 더 늘었으며 대시보드 운영 비용이 붙었다.
처음 가정이 틀어진 순간은 분류 정확도를 한참 끌어올린 뒤에 왔다. 정확도가 올라갈수록 요청도 줄 거라고 봤는데, 두 곡선이 따로 놀았다. 정확도 그래프는 우상향인데 요청량 그래프는 평평했다. 그제야 봇이 답한 건에 달린 “확실한가요?” 재질문을 세어보니, 사람이 답할 때와 같거나 오히려 늘어 있었다. 봇 답변이라는 사실 자체가 한 번 더 확인하게 만든 것이다 — 분류를 더 잘한다고 사라지는 종류의 요청이 아니었다.
막힌 지점은 따로 있었다. 분류기가 자꾸 헷갈리는 “애매한” 요청을 잡겠다고 규칙과 예시를 계속 덧붙였는데, 한 묶음을 잡으면 다른 묶음에서 새 오분류가 튀어나왔다. 두더지 잡기였다. 어느 시점부터는 새 예시를 넣을 때마다 “이걸 넣으면 저쪽이 깨지지 않나”를 먼저 걱정하게 됐고, 규칙 파일은 누구도 전체를 머릿속에 담지 못할 만큼 불어났다. 정작 가장 많이 오는 평범한 요청은 처음부터 잘 분류되고 있었고, 손이 가던 건 전체의 얇은 꼬리, 그마저도 분류가 맞든 틀리든 사람이 한 번 더 확인하는 종류였다. 손이 갈수록 정확도 소수점은 올라갔지만 그게 요청량으로 옮겨오지 않는다는 사실만 더 선명해졌다. 폐기 결정은 어느 회의에서 한 번에 내려진 게 아니라, “이 분류기를 한 단계 더 정교하게 만들면 무엇이 줄어드는가”라는 질문에 아무도 한 줄로 답하지 못한 채 같은 회의가 두세 번 반복됐을 때 굳어졌다. 빠르게 망한 게 아니라 천천히, 지표는 좋아지는데 목적은 멀어지는 방식으로 망했다 — 그래서 더 늦게 알아챘다. 정확도 KPI를 접고 “요청량 자체”로 성공지표를 바꾼 결정이 사실상 그동안 쌓은 분류 튜닝 자산의 상당 부분을 버리는 결정이었고, 그 비가역성 때문에 더 미뤄졌다. 경영진 보고는 “요청 분류를 자동화했습니다” — 무엇이 줄었는지 말할 수 없다.
갈래 B — 6분류 트리를 거친 재설계 (After)
리더가 후보를 트리에 넣는다. Q2(담당·상태 불명확)가 핵심이다. 담당 기준이 머릿속에만 있고 상태가 안 보여 반복 확인이 생긴다 → B형 판정. “상태 화면 자체가 제품에 없다”면 그 부분은 C형으로 갈라져 제품 백로그로.
우선 조치(자동화보다 먼저): ①요청 상위 묶음을 직접 처리·승인 신청·예외 문의로 분리, ②담당·예외 기준 문서화(머릿속 → 규칙), ③상태값 표준화(접수·배정·처리중·완료·보류), ④담당자가 직접 조회할 화면을 연다. 그다음에야 자동화 역할이 정해진다 — 상태 추적은 시스템이, 예외 문의만 사람에게. 구현은 기존 운영 도구에 얇게.
이 중 비가역 디테일은 ③ 상태값 표준화였다. 처음엔 “접수·처리중·완료” 세 칸이면 충분하다고 봤는데, 막상 과거 요청을 뒤져보니 “배정은 됐지만 아직 손 안 댄” 건과 “정보가 모자라 멈춘” 건이 둘 다 “처리중”에 뭉뚱그려져 있었고, 재확인 요청의 대부분이 정확히 그 두 회색지대에서 나왔다. 그래서 ‘배정’과 ‘보류’를 별도 상태로 갈라야 했는데, 한번 다섯 칸으로 정의해 운영 도구·문서·담당자 머릿속에 박히고 나면 되돌리기 어려웠다 — 상태값을 다시 줄이는 순간 이미 그 칸으로 처리하던 사람들의 손발이 어긋나기 때문이다. 그래서 상태 정의는 봇보다 먼저, 그리고 한 번에 제대로 못 박는 작업으로 다뤘다. 자동화는 그 위에 얇게 얹혔을 뿐, 자동화가 상태 체계를 만든 게 아니었다.
한 분기 뒤: 직접 처리 가능 유형의 상태 확인 요청이 크게 줄었다. 변화를 가장 먼저 체감한 건 지표가 아니라 운영팀의 손이었다 — 예전엔 운영 채널 알림이 뜨면 반사적으로 상태 화면부터 열었는데, 어느 순간부터 알림을 열어도 “이건 이미 본인이 화면에서 확인할 수 있는 건데 왜 물었지” 싶은 질문만 드물게 남았다. 남은 질문을 들여다보니 정말로 사람 판단이 필요한 예외, 즉 ‘보류’ 상태에 걸린 건들이었다. 운영팀은 답변이 아니라 예외 처리에 시간을 쓴다. 경영진 보고는 “재확인을 기준선 대비 대폭 줄였고 운영팀 시간을 예외 처리로 재배치했습니다” — 무엇이 줄었는지 비교로 말한다.
두 갈래의 차이 한 줄 요약
| 구분 | 갈래 A (건너뜀) | 갈래 B (재설계) |
|---|---|---|
| 분류 판정 | 없음 → 전부 자동화 | B형(일부 C형) 확정 |
| 우선 조치 | 봇 제작 | 상태값·담당 기준·셀프서비스 |
| 요청량 | 불변 | 크게 감소 |
| 운영팀 시간 | 검토 단계 추가 | 예외 처리로 재배치 |
| 구현 | 풀스택 앱(고정비↑) | 기존 도구에 얇게 |
| 경영 보고 | “자동화했다” | “재확인 줄였다”(기준선 대비) |
같은 업무, 같은 AI 역량에서 출발했다. 갈린 지점은 트리에 넣었는가, 건너뛰었는가다.
리더가 승인·요구할 신호
양쪽이 같이 쓰는 게이트다 — 승인자에게는 통과·반려 기준, 실무자에게는 미리 증명할 체크리스트. 거버넌스 세부는 17·19장 참조.
요구할 것 (없으면 검토 테이블에 올리지 않는다)
- 제안서에 6분류 판정 결과가 있는가. “A~F 중 무엇이며, 왜 그렇게 판정했는가”가 없으면 반려.
- “현재 절차를 그대로 빠르게”가 아니라 재설계 결과(요청 축소·담당 기준·상태값·셀프서비스 범위 중 무엇을 바꿨는가)가 적혀 있는가.
- 워크시트 10번 — 파일럿 성공 기준(처리량·리드타임·재확인)이 승인 조건으로 박혀 있는가. 측정 기준 없는 파일럿은 승인하지 않는다(10장 연결).
반려할 것
- 사람의 협업 절차를 단순 복제한 자동화(“취합 → 전달 → 재확인”을 그대로 에이전트에 옮긴 것).
- 분류 없이 “전부 자동화 대상”으로 묶은 포트폴리오.
- 반복 요청을 “더 잘 처리”하는 데만 집중하고 요청 자체를 줄이는 설계가 없는 제안.
- D형(승인 보조)에서 사람의 최종 판단을 자동 실행하려는 제안.
승인할 것
- 자동화 대신 정책·양식·권한 설계로 요청을 없애는 결정(때로는 “만들지 않는 것”이 최선의 AX다).
- 영역별로 다른 성공 기준(A는 요청 감소, F는 처리량 — 같은 잣대로 보지 않는다).
- C·E형에서 봇이 아니라 기능·문서를 먼저 세우는 결정.
이 장의 요약
- 자동화 전에 묻는다: “이 요청을 요청 없이 끝내게 만들 수 있는가?” 반복 요청은 처리 대상이 아니라 문제 신호다.
- 모든 후보를 6분류 트리(A 요청 축소 / B 업무 재설계 / C 시스템 흡수 / D 승인 보조 / E 지식 정리 / F 자동 처리)에 먼저 넣는다. F는 다른 가능성을 모두 소거한 뒤 도달하는 맨 아래다.
- B와 C는 한 질문으로 가른다: 사람이 규칙을 정하면 풀리는가(B), 제품에 기능을 넣어야 풀리는가(C). 분류마다 우선 조치·자동화 역할·성공 기준이 다르다.
- 10개 질문 워크시트로 분류를 확정한다. 10번(성공 기준)에 답 못하면 파일럿을 열지 않는다(10장 증거 등급).
- 재설계 후 구현은 가벼운 것부터(Skill·MCP·기존 도구 → 풀스택은 마지막). 사람 절차의 단순 복제는 금지(6장 Anti-Slop).
- C·E형은 봇으로 답을 빨리 만든다고 사라지지 않는다 — 기능을 넣거나 문서를 세워야 요청이 줄어든다.
- 결과를 가르는 것은 트리에 넣었는가다. 건너뛴 자동화는 “자동화했다”만, 거친 자동화는 “무엇이 줄었다”를 기준선 대비 비교로 말한다.