전환 로드맵 (As-Is → To-Be)

지금 모습(As-Is)과 가고 싶은 모습(To-Be)을 관점별로 나란히 적으면 그 차이(갭)가 드러납니다. 갭을 변화 과제로 바꾸고 단기·중기·장기 로드맵에 놓으면 전환 계획이 됩니다. 이 도구는 "무엇을 잘못했나"가 아니라 "어디로 갈까"를 묻는 설계형 도구예요. 목표에서 벗어난 일을 바로잡는 거라면 문제 분석(As-Is/To-Be 갭 → 5 Whys)이 맞습니다.

🎯 무엇을, 어떤 모습에서 어떤 모습으로

전환 주제

무엇을 바꾸려는지 한 줄 — 조직·사업·프로세스 이름까지

목표 시점

To-Be 가 완성되어 있어야 할 때

현재 모습 (As-Is)

지금 실제로 어떤 모습인지 — 잘잘못이 아니라 출발점입니다. 숫자가 있으면 더 좋습니다

목표 모습 (To-Be)

그날 아침 출근해 로그인하면 보이는 장면처럼 — 숫자와 시점이 들어가야 나중에 "됐다/안 됐다"를 말할 수 있습니다

🧩 구현할 기능 최소 3가지 · 더 필요하면 ＋로 추가

목표 모습(To-Be)에 닿으려면 무엇을 만들어야 하나요? 사용자가 체감하는 단위로 하나씩 — "SSO 로그인", "자동 배포 파이프라인"처럼 이름 + 한 줄 설명

이 한 쌍이 전환의 뼈대입니다. 관점별로 쪼개 갭을 찾고 과제·로드맵까지 만들려면 →

↔ 관점별 현재 모습 · 목표 모습 · 갭

관점은 "고객·제품·프로세스·조직·수익·기술" 여섯 개가 기본이고 이름을 바꾸거나 더할 수 있습니다. 갭은 동사로 — "없다"가 아니라 "~을 만들어야 한다"로 적으면 그대로 과제가 됩니다. 갭 크기는 바꾸는 데 드는 힘의 크기입니다.

🔍 설계 점검

🧱 변화 과제0

과제 하나 = 갭 하나를 메우는 일. 담당이 없는 과제는 아무도 안 합니다. 선행 조건은 "이게 끝나야 시작할 수 있다"입니다.

🛤 이행 로드맵 — 단계 이름·기간은 눌러서 고칩니다

📄 완성된 전환 로드맵

💡 잘 쓰는 요령 (단순)

현재 모습은 숫자로. "장애가 잦다"보다 "월 3건, 복구 평균 4시간"이 출발점을 분명하게 합니다.
목표 모습은 장면과 시점으로. "클라우드 전환"이 아니라 "2027년 6월, 주 2회 자동 배포, 장애 월 0.5건". 숫자가 없으면 점검에 경고가 뜹니다.
구현할 기능은 사용자가 체감하는 단위로. "백엔드 개선"이 아니라 "SSO 로그인", "주 2회 자동 배포"처럼. 세 가지가 안 나오면 목표 모습이 아직 흐린 것입니다.
한 쌍이 분명해지면 고급으로. 같은 문장을 고객·제품·프로세스·조직·수익·기술 여섯 관점으로 쪼개면 갭이 보이고, 갭이 과제가 됩니다.

💡 잘 쓰는 요령

목표 모습은 사진처럼. "클라우드 전환"이 아니라 "주 2회 자동 배포, 장애 월 0.5건, 어디서나 SSO 로그인"처럼 그날의 장면과 숫자로 적습니다. 숫자가 없으면 점검에 경고가 뜹니다.
현재 모습은 냉정하게, 그러나 비난 없이. 설계형 전환에서 As-Is는 잘못이 아니라 출발점입니다. 그래서 여기엔 5 Whys가 없습니다.
갭이 크다고 과제가 커야 하는 건 아닙니다. 큰 갭일수록 1단계에 "작게 시작해 보는 일"(베타·파일럿)을 넣어야 2단계가 열립니다.
1단계가 비어 있으면 로드맵이 아니라 소원 목록입니다. 첫 3개월에 할 일이 반드시 있어야 합니다.
목표 모습의 숫자(배포 횟수·장애 건수·복구 시간)는 KPI 대시보드로 옮겨 추적하고, 수익·비용 관점의 갭(서버 유지비 vs 구독료)은 BEP 분석이나 NPV로 숫자를 확인하세요.