# 로드맵 전체 그림
> **이 장에서 배우는 것**
> 과제 하나가 아이디어에서 프로덕션까지 가는 4단계, 각 단계의 산출물, 그리고
> **다음 단계로 넘어가도 되는지 판단하는 기준**.
## 왜 절차가 필요한가
과제를 골랐으면 그냥 만들면 되지 않나 싶습니다. 그런데 절차 없이 진행하면
전형적으로 이렇게 됩니다.
```
"청구서 입력 자동화하자" → 바로 개발 시작
→ 3주 뒤: "그런데 거래처마다 양식이 다른데요?"
→ 2주 더: "예외 케이스가 40%나 되네요"
→ 1개월 뒤: "이 정도면 사람이 하는 게 낫겠는데요"
```
**만들다가 알게 된 것들**입니다. 만들기 전에 알았으면 방향을 바꿨거나 범위를
좁혔을 것입니다.
로드맵의 목적은 **비싼 것을 만들기 전에 싼 것으로 확인하는 순서**를 만드는
것입니다.
## 4단계
```mermaid
graph TD
P1["Phase 1
문제 정의"] --> P2["Phase 2
데이터 · 시스템 진단"]
P2 --> P3["Phase 3
POC 설계 · 실행"]
P3 --> P4["Phase 4
프로덕션 배포"]
P3 -.->|"효과 미검증"| P1
P4 --> P1
```
두 개의 점선이 중요합니다.
- **Phase 3 → Phase 1 (되돌아감)**: POC에서 효과가 확인 안 되면 **되돌아가는 것이
정상입니다.** 검증되지 않은 것을 확장하는 게 가장 비싼 실수입니다.
- **Phase 4 → Phase 1 (다시 돌기)**: 배포는 끝이 아니라 다음 과제의 출발점입니다.
## 각 단계가 답하는 질문
| 단계 | 핵심 질문 | 산출물 |
|---|---|---|
| 1. 문제 정의 | 무엇이 아픈가, **얼마나** 아픈가 | AI 도입 적합 업무 리스트 & ROI 예측 리포트 |
| 2. 진단 | **만들 수 있는가** | 시스템 아키텍처 & 데이터 플로우 다이어그램 |
| 3. POC | **정말 효과가 있는가** | POC 결과 보고서 & 스케일업 권고안 |
| 4. 배포 | **계속 굴러가는가** | 운영 매뉴얼 & KPI 대시보드 |
## 게이트 — 다음으로 넘어가도 되는지
각 단계 끝에는 **넘어가도 되는지 판단하는 기준**이 있습니다. 이걸 안 두면 단계가
형식이 됩니다 — 문서만 만들고 그냥 다음으로 갑니다.
| 게이트 | 통과 조건 | 안 통과면 |
|---|---|---|
| 1 → 2 | 후보 업무마다 **현재 걸리는 시간·비용 숫자**가 있다 | 숫자부터 수집 |
| 2 → 3 | 필요한 데이터에 **실제로 접근할 수 있음**을 확인했다 | 접근 문제부터 해결 |
| 3 → 4 | Phase 1의 숫자가 **실제로 움직였고**, 사용자가 계속 쓰고 있다 | 되돌아가서 재설계 |
| 4 → 다음 | 사람 손 없이 굴러가고, 지표가 대시보드에 남는다 | 운영 체계 보완 |
### 게이트를 지키지 않으면
각 게이트를 건너뛰었을 때 **어디서 터지는지**가 정해져 있습니다.
| 건너뛴 게이트 | 터지는 시점 |
|---|---|
| 1 → 2 (숫자 없이) | 마지막에. 효과를 증명 못 해 확대 예산이 안 나옴 |
| 2 → 3 (접근 확인 없이) | POC 중간에. "그 데이터는 못 가져옵니다" |
| 3 → 4 (효과 미검증) | 전사 확대 후. 큰 비용을 쓴 뒤에 실패를 확인 |
| 4 (운영 체계 없이) | 3~6개월 뒤. 조용히 안 쓰게 됨 |
**아래로 갈수록 비싸집니다.** 게이트의 목적은 **싸게 실패하는 것**입니다.
## 각 단계에 걸리는 시간
과제 규모에 따라 다르지만 대략의 감은 이렇습니다.
| 단계 | 소요 | 비고 |
|---|---|---|
| 1. 문제 정의 | 1~2주 | 길어지면 대개 후보가 너무 많은 것 |
| 2. 진단 | 1~3주 | 데이터 접근 권한 문제로 늘어남 |
| 3. POC | 3~6주 | **여기가 핵심.** 짧을수록 좋음 |
| 4. 배포 | 2~4주 | 교육과 모니터링 설정 포함 |
첫 과제 기준으로 **2~3개월**이 나옵니다. [우선순위](/guide/ax-sequencing)에서
"첫 과제는 3개월 안에 결과가 나와야 한다"고 한 게 이 계산입니다.
## 이 로드맵과 하이퍼 애자일의 관계
헷갈리기 쉬워서 먼저 정리합니다.
| | 다루는 것 | 언제 |
|---|---|---|
| **AX 로드맵** | 조직이 AI를 **도입하는 절차** | 과제 하나를 시작해서 정착시킬 때 |
| **하이퍼 애자일** | 도입한 뒤 **매일 일하는 방식** | Phase 3~4에서 실제로 만들 때 |
| | 누가 읽나 |
|---|---|
| **AX 로드맵** | 도입을 결정·추진하는 사람 |
| **하이퍼 애자일** | 만드는 조직을 이끄는 사람 |
> **둘 다 읽을 필요는 없습니다.** 추진 담당이라면 이 로드맵만으로 충분하고,
> 하이퍼 애자일은 개발 조직이 실제로 만들기 시작할 때 그쪽에서 읽으면 됩니다.
로드맵이 큰 틀이고, 그 안의 Phase 3~4에서 실제로 무언가를 만들기 시작할 때
[하이퍼 애자일](/guide/ha-agile-limits) 방법론이 들어옵니다.
## 자주 하는 오해
### "4단계가 너무 무겁지 않나? 작은 과제인데"
단계는 그대로 두되 **각 단계를 짧게** 하면 됩니다. 작은 과제라면 Phase 1이 반나절,
Phase 2가 하루일 수 있습니다. 중요한 건 **순서와 게이트**이지 문서 분량이
아닙니다.
건너뛰어도 되는 단계는 없습니다. 특히 Phase 1의 "현재 값 기록"은 반나절이면
끝나는데 안 하면 나중에 전체가 증명 불가가 됩니다.
### "POC가 성공했는데 왜 바로 확대하면 안 되나?"
확대해도 됩니다. Phase 4가 그 확대입니다. 다만 Phase 4에 **교육, 모니터링, 개선
체계**가 들어 있는데 이걸 건너뛰고 "그냥 전사에 열어주면" 3~6개월 뒤에 조용히
안 쓰게 됩니다. 확대는 "권한을 넓히는 것"이 아니라 "**정착시키는 것**"입니다.
---
## 확인
**1. Phase 3에서 효과가 확인되지 않으면 무엇이 정상적인 행동입니까?**
답
**Phase 1로 되돌아가는 것**입니다. 검증되지 않은 것을 확장하는 게 가장 비싼
실수입니다. POC의 목적은 성공시키는 게 아니라 **확대해도 되는지 판정하는 것**
입니다.
**2. 게이트를 두는 목적을 한마디로 말하면?**
답
**싸게 실패하는 것**입니다. 게이트를 건너뛸수록 문제가 나중에, 더 비싼 시점에
터집니다. 데이터 접근 확인을 안 하면 POC 중간에 막히고, 효과 검증을 안 하면
전사 확대 후에 실패를 확인하게 됩니다.
**3. 작은 과제에서도 4단계를 다 거쳐야 합니까?**
답
네, 다만 **각 단계를 짧게** 합니다. Phase 1이 반나절일 수 있습니다. 중요한 건
순서와 게이트이지 문서 분량이 아닙니다. 특히 Phase 1의 현재 값 기록은 반나절이면
되는데 빠뜨리면 전체가 증명 불가가 됩니다.
---
이제 각 단계를 하나씩 봅니다 → [Phase 1 — 문제 정의](/guide/ax-phase1-problem)