# Phase 4 — 프로덕션 배포
> **이 장에서 배우는 것**
> 확대 단계에서 실제로 해야 하는 네 가지, 그리고 배포 후 3~6개월에 조용히
> 무너지는 것을 막는 법.
## 이 단계의 목적
> **검증된 솔루션을 전사적으로 확장하고 지속적인 개선 체계를 구축합니다.**
"확장"에 방점이 찍히기 쉬운데, 실제로 어려운 건 뒤쪽 **"지속적인 개선 체계"**
입니다.
> **확대는 권한을 넓히는 것이 아니라 정착시키는 것입니다.**
POC에서 잘 되던 것이 전사 확대 후 조용히 안 쓰이게 되는 일이 매우 흔합니다.
POC에는 있었지만 확대에는 없던 것 때문입니다 — **관심**입니다. POC 기간에는
누군가 매일 들여다보지만, 확대 후에는 아무도 안 봅니다.
## 네 가지 활동
### 1. 프로덕션 환경 구성 & 배포
POC 환경과 다른 점을 챙깁니다.
| 항목 | POC | 프로덕션 |
|---|---|---|
| 대상 범위 | 거래처 5곳 | 80곳 |
| 예외 처리 | 사람이 전부 | 자동 분기 필요 |
| 장애 시 | 담당자가 알아서 | **대체 절차 필요** |
| 접근 권한 | 담당자 1명 | 팀 전체, 역할별 |
**"장애 시" 줄이 핵심입니다.** 시스템이 멈췄을 때 업무가 멈추면 안 됩니다.
사람이 처리하는 대체 경로가 준비돼 있어야 합니다.
### 2. 사용자 교육 & 온보딩
POC는 한 명이 썼고 이제 열 명이 씁니다. **그 아홉 명은 맥락을 모릅니다.**
교육에 반드시 들어가야 하는 것:
| 내용 | 왜 |
|---|---|
| 무엇을 대신해주는가 | 기대를 맞춤 |
| **무엇은 안 해주는가** | 오해로 인한 사고 방지 |
| 틀렸을 때 어떻게 아나 | 확인 지점 |
| 이상하면 누구에게 | 방치 방지 |
두 번째가 특히 중요합니다. "다 알아서 해준다"고 오해하면 확인 없이 넘어갑니다.
### 3. 모니터링 & 알림 설정
**무엇을 보고 있을지**를 정합니다.
```
매일 자동 집계:
처리 건수 / 사람 개입 건수 / 오류 건수 / 평균 처리 시간
알림을 보낼 조건:
- 오류율이 평소의 2배를 넘으면
- 사람 개입 비율이 30%를 넘으면
- 처리 건수가 평소의 절반 이하면 (= 사람들이 안 쓰고 있음)
```
**세 번째 알림이 중요합니다.** 오류는 눈에 띄지만 **안 쓰는 건 조용합니다.**
사용량이 떨어지는 걸 알림으로 잡아야 합니다.
### 4. 지속적 개선 프로세스 수립
정해두지 않으면 아무도 안 합니다.
| 주기 | 무엇을 |
|---|---|
| 매주 | 오류 건 검토, 반복되는 패턴 찾기 |
| 매월 | 지표 리뷰. Phase 1 숫자와 비교 |
| 분기 | 범위 확대 검토 (예외를 자동화 대상에 편입) |
## 산출물
> **운영 매뉴얼 & KPI 대시보드**
### 운영 매뉴얼에 들어갈 것
```
1. 이 시스템이 하는 일 / 안 하는 일
2. 정상 동작 확인법
3. 자주 나오는 문제와 대처
4. 장애 시 대체 절차 ← 반드시
5. 담당자 연락처와 에스컬레이션 경로
```
### KPI 대시보드
Phase 1의 숫자가 **계속 보이는 곳**에 있어야 합니다. 보고서에만 있으면 3개월 뒤
아무도 안 봅니다.
## 게이트 — 이 단계가 끝났다고 하려면
> **사람 손 없이 굴러가고, 지표가 대시보드에 남는가?**
"담당자가 매일 확인해야 돌아간다"면 아직 끝난 게 아닙니다.
## 배포 후 3~6개월이 진짜 시험대
이 기간에 흔히 벌어지는 일들입니다.
| 시점 | 벌어지는 일 | 대비 |
|---|---|---|
| 1개월 | 예상 못 한 예외 발생 | 매주 검토로 잡음 |
| 2~3개월 | 초기 관심 식음 | 자동 알림이 대신 봄 |
| 3~4개월 | 업무 변경으로 안 맞게 됨 | 월간 리뷰에서 발견 |
| 6개월 | 담당자 교체 | 운영 매뉴얼이 있어야 |
**마지막 줄이 가장 자주 놓치는 부분입니다.** 만든 사람이 떠나면 아무도 못 고치는
상태가 되고, 그러면 조용히 사용이 줄어듭니다.
## 그리고 다시 Phase 1로
```mermaid
graph TD
A["Phase 4 배포 완료"] --> B["운영하며 데이터가 쌓임"]
B --> C["새로운 개선점이 보임"]
C --> D["Phase 1: 다음 과제 정의"]
D --> E["이번엔 더 빠름
기준선·경험·신뢰가 있음"]
```
첫 과제를 끝낸 조직은 두 번째가 훨씬 빠릅니다. 측정하는 법을 알고, 누구와
일해야 하는지 알고, 무엇보다 **된다는 걸 아는** 상태이기 때문입니다.
## 자주 하는 오해
### "POC가 잘 됐으니 그냥 전사에 열어주면 되지 않나?"
그게 정확히 가장 흔한 실패입니다. POC에는 있고 확대에는 없는 것들이 있습니다 —
교육, 모니터링, 대체 절차, 개선 주기. 이걸 안 갖추면 3~6개월 뒤 조용히
안 쓰이게 됩니다.
### "모니터링까지 만들면 배보다 배꼽 아닌가?"
모니터링이 없으면 **효과를 계속 증명할 수 없습니다.** 그러면 다음 과제 예산도
못 받습니다. 대시보드 하나가 다음 과제를 여는 열쇠입니다.
---
## 확인
**1. "확대는 권한을 넓히는 게 아니라 정착시키는 것"이라는 말의 뜻은?**
답
전사에 접근 권한만 열어주는 것으로는 부족하다는 뜻입니다. 교육, 모니터링, 장애 시
대체 절차, 개선 주기가 함께 가야 하고, 이게 없으면 3~6개월 뒤 조용히 안 쓰이게
됩니다.
**2. "처리 건수가 평소의 절반 이하" 알림이 왜 필요합니까?**
답
**안 쓰는 건 조용하기 때문**입니다. 오류는 눈에 띄지만 사용 중단은 아무 신호가
없습니다. 사용량 하락을 알림으로 잡아야 초기에 원인을 찾을 수 있습니다.
**3. 6개월 뒤 담당자가 교체되면 무엇이 문제가 됩니까?**
답
만든 사람이 떠나면 **아무도 못 고치는 상태**가 되고, 문제가 생겨도 방치되어
조용히 사용이 줄어듭니다. 운영 매뉴얼(하는 일/안 하는 일, 대처법, 대체 절차,
에스컬레이션 경로)이 이걸 막습니다.
---
배포했으면 효과를 증명해야 합니다. 대부분이 여기서 막힙니다 →
[성과 측정과 보고](/guide/ax-measurement)