로드맵 전체 그림

이 장에서 배우는 것 과제 하나가 아이디어에서 프로덕션까지 가는 4단계, 각 단계의 산출물, 그리고 다음 단계로 넘어가도 되는지 판단하는 기준.

왜 절차가 필요한가

과제를 골랐으면 그냥 만들면 되지 않나 싶습니다. 그런데 절차 없이 진행하면 전형적으로 이렇게 됩니다.

text

"청구서 입력 자동화하자" → 바로 개발 시작→ 3주 뒤: "그런데 거래처마다 양식이 다른데요?"→ 2주 더: "예외 케이스가 40%나 되네요"→ 1개월 뒤: "이 정도면 사람이 하는 게 낫겠는데요"

만들다가 알게 된 것들입니다. 만들기 전에 알았으면 방향을 바꿨거나 범위를 좁혔을 것입니다.

로드맵의 목적은 비싼 것을 만들기 전에 싼 것으로 확인하는 순서를 만드는 것입니다.

4단계

graph TD
  P1["Phase 1<br/>문제 정의"] --> P2["Phase 2<br/>데이터 · 시스템 진단"]
  P2 --> P3["Phase 3<br/>POC 설계 · 실행"]
  P3 --> P4["Phase 4<br/>프로덕션 배포"]
  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개월이 나옵니다. 우선순위에서 "첫 과제는 3개월 안에 결과가 나와야 한다"고 한 게 이 계산입니다.

이 로드맵과 하이퍼 애자일의 관계

헷갈리기 쉬워서 먼저 정리합니다.

	다루는 것	언제
AX 로드맵	조직이 AI를 도입하는 절차	과제 하나를 시작해서 정착시킬 때
하이퍼 애자일	도입한 뒤 매일 일하는 방식	Phase 3~4에서 실제로 만들 때

	누가 읽나
AX 로드맵	도입을 결정·추진하는 사람
하이퍼 애자일	만드는 조직을 이끄는 사람

둘 다 읽을 필요는 없습니다. 추진 담당이라면 이 로드맵만으로 충분하고, 하이퍼 애자일은 개발 조직이 실제로 만들기 시작할 때 그쪽에서 읽으면 됩니다.

로드맵이 큰 틀이고, 그 안의 Phase 3~4에서 실제로 무언가를 만들기 시작할 때 하이퍼 애자일 방법론이 들어옵니다.

자주 하는 오해

"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 — 문제 정의