178. AS-IS (현재 상태) / TO-BE (미래 상태) 분석

핵심 인사이트 (3줄 요약)

본질: AS-IS (현재 상태) / TO-BE (미래 상태) 분석은 현재 업무·시스템·데이터·조직의 실제 모습을 파악하고, 목표 상태를 정의한 뒤, 그 사이의 차이(Gap)를 이행 과제로 바꾸는 변화 설계 기법이다.

가치: 단순한 현행 조사나 미래 청사진 그리기를 넘어서, 왜 바꿔야 하는지와 무엇을 바꿔야 하는지를 같은 프레임에서 연결해 요구사항과 로드맵의 품질을 높인다.

판단 포인트: AS-IS만 보면 문제 목록에 머물고, TO-BE만 보면 공상도에 그치기 쉬우므로, 측정 가능한 기준과 전환 계획까지 포함해야 실무에서 실행 가능한 분석이 된다.

Ⅰ. 개요 및 필요성

AS-IS / TO-BE 분석은 현재 상태를 있는 그대로 파악하고, 목표 상태를 설계한 뒤, 두 상태 사이의 간극을 관리 가능한 변화 항목으로 바꾸는 분석 프레임이다. 요구공학, 업무 프로세스 재설계 (Business Process Reengineering, BPR), 정보화 전략계획, 시스템 고도화 프로젝트의 초반부에서 가장 자주 쓰인다. 핵심은 "문제가 있으니 바꾸자"가 아니라, 무엇이 현재의 병목인지, 바뀐 뒤 어떤 모습이어야 하는지, 그 차이를 어떻게 메울지를 구조화하는 데 있다.

이 기법이 필요한 이유는 프로젝트 실패가 기능 부족보다도 현실 오해와 목표 불명확성에서 자주 시작되기 때문이다. 현재 프로세스를 제대로 이해하지 못하면 잘못된 자동화를 만들고, 목표 상태를 구체화하지 못하면 팀마다 서로 다른 그림을 보고 움직인다. 결국 AS-IS / TO-BE 분석은 기술 문서 작성 이전에, 이해관계자 사이의 공통 언어를 만드는 작업이라고 볼 수 있다.

아래 그림은 이 분석이 단순한 "현재 vs 미래" 비교가 아니라, 변화 경로를 함께 설계하는 구조임을 보여 준다.

┌────────────────────────────────────────────────────────────────────┐
│ AS-IS  ->  GAP  ->  TO-BE                                         │
├────────────────────────────────────────────────────────────────────┤
│ current process   : what is really happening now?                 │
│ current pain      : delay / error / duplicate work                │
│ target capability : what must be different?                       │
│ transition items  : process / system / data / organization tasks  │
└────────────────────────────────────────────────────────────────────┘

즉 이 분석의 목적은 "예쁜 미래 그림"을 그리는 데 있지 않다. 현재의 사실을 기준선으로 잡고, 목표 상태를 검증 가능하게 정의하며, 그 사이의 변화 비용을 보이게 하는 것이 진짜 목적이다.

📢 섹션 요약 비유: AS-IS / TO-BE 분석은 여행을 떠나기 전 "지금 내가 어디에 있는지"와 "어디로 갈지"를 먼저 지도에 표시한 뒤, 그 사이에 어떤 길과 준비물이 필요한지 적는 일과 같다. 출발점이나 목적지 중 하나라도 모르면 좋은 여행 계획이 나올 수 없다.

Ⅱ. 아키텍처 및 핵심 원리

좋은 AS-IS / TO-BE 분석은 보통 현재 파악 → 문제 진단 → 목표 설계 → Gap 분석 → 이행 로드맵 순서로 진행된다. 여기서 중요한 점은 현재와 미래를 단순히 서술하는 것이 아니라, 같은 비교 축 위에 올려 놓아야 한다는 것이다. 프로세스, 데이터, 애플리케이션, 조직 역할, 핵심성과지표 (Key Performance Indicator, KPI) 같은 축을 통일해야 변화 항목이 선명하게 드러난다.

단계	핵심 질문	대표 산출물
범위 정의	무엇을 어디까지 바꿀 것인가?	대상 업무, 이해관계자, 분석 범위
AS-IS 파악	현재는 실제로 어떻게 돌아가는가?	현행 프로세스 맵, 시스템 구성도, 현행 KPI
문제 진단	병목과 오류의 근본 원인은 무엇인가?	Pain Point, 원인 분석, 제약 조건
TO-BE 설계	목표 상태는 어떤 능력을 가져야 하는가?	목표 프로세스, 목표 아키텍처, 목표 KPI
Gap 분석	둘 사이에 무엇이 비어 있는가?	기능·데이터·조직·정책 Gap 목록
이행 계획	어떤 순서와 우선순위로 바꿀 것인가?	로드맵, 과제 정의, 릴리스 계획

다음 표는 같은 대상 업무를 여러 층위에서 비교하는 방식을 예시로 보여 준다.

┌────────────────────────────────────────────────────────────────────┐
│ Four-layer gap matrix                                              │
├────────────────────────────────────────────────────────────────────┤
│ Layer    AS-IS                Gap               TO-BE              │
│ Process  manual approval      3-day delay       workflow engine    │
│ Data     duplicate master     inconsistency     single source      │
│ System   silo applications    re-entry work     API integration    │
│ Org      unclear owner        handoff conflict   RACI clarified     │
└────────────────────────────────────────────────────────────────────┘

이런 구조를 잡아 두면 TO-BE가 공허한 이상론으로 흐르지 않는다. 예를 들어 "결재를 실시간으로 바꾼다"는 목표가 있다면, 프로세스만 바꾸는 것으로는 부족하고 데이터 표준화, 인터페이스, 권한 체계, 역할 책임까지 같이 바뀌어야 함이 드러난다. 그래서 AS-IS / TO-BE 분석은 단순한 인터뷰 정리가 아니라, 변화를 시스템적으로 분해하는 설계 도구다.

또한 분석 모델링에는 BPMN (Business Process Model and Notation), 업무 흐름도, 시스템 컨텍스트 다이어그램, 서비스 청사진 같은 시각화 도구가 자주 활용된다. 중요한 것은 표기법 그 자체보다, 현재와 미래를 같은 언어로 비교 가능하게 표현하는 것이다.

📢 섹션 요약 비유: 이 분석은 낡은 집을 리모델링할 때 지금의 방 배치, 배관, 전기선을 먼저 확인하고, 새 집 구조도와 나란히 놓고 비교하는 과정과 같다. 벽만 예쁘게 다시 칠한다고 집이 좋아지는 것이 아니라, 배선과 배관까지 함께 바꿔야 진짜 달라진다.

Ⅲ. 비교 및 연결

AS-IS / TO-BE 분석은 흔히 현행 조사, Gap 분석, 요구사항 정의와 섞여 쓰이지만 역할은 서로 다르다. AS-IS는 현실을 설명하고, TO-BE는 목표를 정의하며, Gap 분석은 둘을 연결하고, 요구사항은 실제 구현 항목으로 구체화한다. 이 경계를 분명히 해야 각 산출물이 중복되지 않고 살아난다.

관점	AS-IS (현재 상태)	TO-BE (미래 상태)	Gap / 전환 관점
주된 질문	지금 실제로 어떻게 돌아가는가?	무엇이 달라져야 하는가?	무엇을 바꾸면 도달하는가?
초점	사실, 현행 제약, 문제	목표 능력, 원칙, 성과	과제, 우선순위, 이행 순서
위험	문제만 나열하고 끝날 수 있음	희망사항만 남을 수 있음	실행 가능한 단위로 못 쪼개면 공회전
연결 산출물	프로세스 맵, 현행 시스템 목록	목표 프로세스, 목표 아키텍처	과제 정의서, 요구사항, 로드맵

이 분석은 다른 기법과도 밀접하게 연결된다. 업무 프로세스 재설계 (BPR)는 TO-BE 중심의 급진적 변화 관점을 더하고, SWOT 분석이나 3C/4C 분석은 왜 그 TO-BE가 필요한지에 대한 사업적 근거를 보강한다. 또한 도메인 분석, 비즈니스 케이스, 투자대비효과 (Return on Investment, ROI) 산정과 연결하면 "좋아 보이는 변화"가 아니라 "왜 이 변화가 우선인지"까지 설명할 수 있다.

중요한 경계도 있다. AS-IS / TO-BE 분석은 단순 화면 비교서가 아니며, 경쟁사 기능 리스트를 베껴 적는 작업도 아니다. 현재 조직의 제약과 미래 운영 방식이 반영되지 않으면, TO-BE는 현실과 분리된 슬로건이 된다. 반대로 현재 문제만 자세히 적고 목표 상태를 추상적으로 남기면, 프로젝트는 "문제는 알지만 방향은 모르는" 상태에 머문다.

📢 섹션 요약 비유: AS-IS는 오늘의 성적표, TO-BE는 목표 대학, Gap 분석은 공부 계획표와 같다. 셋 중 하나만 있어서는 진학 전략이 완성되지 않는다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 이 분석을 얼마나 깊게 할지부터 판단해야 한다. 단순 화면 개선 수준의 작은 프로젝트라면 특정 업무 흐름만 좁게 보면 되지만, 여러 부서와 시스템이 얽힌 전사 고도화라면 프로세스·데이터·조직·정책까지 함께 다뤄야 한다. 범위를 잘못 잡으면 분석이 과도하게 무거워지거나, 반대로 핵심 병목을 놓친 채 표면만 고치게 된다.

예를 들어 "결재가 너무 느리다"는 문제를 다룬다고 하자. AS-IS 조사에서 수기 승인, 중복 입력, 승인자 부재, 마스터 데이터 불일치가 함께 드러났다면, TO-BE는 단순 전자결재 도입으로 끝나지 않는다. 모바일 승인, 권한 체계 정비, 기준정보 통합, 인터페이스 자동화까지 포함해야 실제 성과가 난다. 즉 TO-BE는 기능 목록이 아니라 운영 방식의 재설계여야 한다.

아래 의사결정 흐름은 분석 범위와 깊이를 정할 때 자주 쓰는 질문을 정리한 것이다.

┌────────────────────────────────────────────────────────────────────┐
│ Deciding the depth of AS-IS / TO-BE analysis                       │
├────────────────────────────────────────────────────────────────────┤
│ is the problem limited to one task or one screen?                  │
│   ├─ yes -> narrow process-level analysis                          │
│   └─ no                                                            │
│        ├─ data / org / policy also affected? -> cross-domain study │
│        ├─ multiple systems involved? -> architecture-level gap     │
│        └─ rollout needed by phases? -> roadmap by release waves    │
└────────────────────────────────────────────────────────────────────┘

실무 판단 기준

현재 상태를 수치로 표현했는가? 처리시간, 오류율, 재입력 횟수 등 기준선이 있어야 변화 효과를 검증할 수 있다.
TO-BE가 측정 가능하게 정의되었는가? "좋아진다"가 아니라 "결재 3일 → 4시간"처럼 써야 한다.
변화 범위에 데이터·조직·정책이 포함되는가? 시스템만 바꾸면 해결되지 않는 경우가 많다.
이행 우선순위가 있는가? 한 번에 모든 것을 바꾸려 하면 실행력이 떨어진다.

안티패턴

현행 인터뷰만 잔뜩 하고 문제의 구조화를 하지 않는 것
TO-BE를 기술 유행어 나열로 채우고 운영 가능성을 검증하지 않는 것
"나쁜 현재 프로세스"를 그대로 전산화하는 것
조직 역할과 데이터 정비를 빼고 화면 요구사항만 남기는 것
📢 섹션 요약 비유: AS-IS / TO-BE 분석을 잘못하면 낡은 집의 문제를 모르고 새 벽지부터 고르는 것과 같다. 보기에는 새집 같아도 물 새는 배관이 그대로면 곧 다시 뜯어야 한다.

Ⅴ. 기대효과 및 결론

AS-IS / TO-BE 분석을 제대로 수행하면 프로젝트는 막연한 개선 활동이 아니라, 현실 기반의 변화 프로그램이 된다. 현재 문제를 사실로 정리하고, 목표 상태를 합의 가능한 언어로 정의하며, Gap을 과제로 전환하면 요구사항 누락과 우선순위 혼선을 줄일 수 있다. 특히 여러 부서가 참여하는 프로젝트에서는 "누가 무엇을 왜 바꿔야 하는가"를 공통 기준으로 맞춘다는 점이 크다.

물론 이 분석도 한계는 있다. AS-IS가 부정확하면 잘못된 현실을 기준으로 삼게 되고, TO-BE가 정치적 구호나 이상론으로 흐르면 실행력을 잃는다. 또한 전환 비용과 변화 저항을 과소평가하면, 문서상으로는 완벽해 보여도 현장 정착에 실패할 수 있다. 그래서 이 기법은 한 번의 문서 작성이 아니라, 프로젝트가 진행되며 계속 검증·갱신해야 하는 살아 있는 기준선으로 다뤄야 한다.

정리하면 AS-IS / TO-BE 분석은 현재 문제를 목표 변화와 연결하는 다리다. 기억할 핵심은 분명하다. 현실 파악, 목표 정의, Gap 설계, 이행 우선순위가 모두 이어질 때 비로소 실행 가능한 요구사항과 로드맵이 나온다는 점이다.

📢 섹션 요약 비유: 이 분석은 강 건너편에 다리를 놓는 설계와 같다. 지금 서 있는 강둑도 정확히 알아야 하고, 건너편 어디에 닿을지도 정해야 하며, 그 사이에 어떤 기둥을 세울지도 계산해야 실제로 건널 수 있다.

📌 관련 개념 맵

개념	연결 포인트
AS-IS (현재 상태)	현행 업무·시스템·데이터·조직의 사실 기반 기준선이다
TO-BE (미래 상태)	달성하려는 목표 운영 방식과 구조를 정의한다
Gap 분석 (Gap Analysis)	현재와 미래 사이의 차이를 과제 단위로 분해한다
BPMN (Business Process Model and Notation)	현행·목표 프로세스를 같은 언어로 비교할 때 자주 쓰는 표기법이다
BPR (Business Process Reengineering)	TO-BE 중심의 급진적 프로세스 혁신과 연결된다
KPI (Key Performance Indicator)	변화 효과를 측정 가능한 수치로 검증하게 해 준다
로드맵 (Roadmap)	Gap을 실제 실행 순서와 우선순위로 바꾸는 산출물이다

📈 관련 키워드 및 발전 흐름도

observe current operations
        │
        ▼
AS-IS baseline
        │
        ▼
target capability design
        │
        ▼
TO-BE model
        │
        ▼
gap analysis
        │
        ├──────────────▶ prioritized requirements
        └──────────────▶ transition roadmap and change management

이 흐름도는 AS-IS / TO-BE 분석이 단순 비교표가 아니라, 요구사항 정의와 변화관리 계획으로 이어지는 상위 설계 프레임이라는 점을 보여 준다.

👶 어린이를 위한 3줄 비유 설명

AS-IS는 지금 내 방이 얼마나 어지러운지 보는 것이고, TO-BE는 방을 어떻게 바꾸고 싶은지 그리는 그림이에요.
둘을 비교해 보면 책꽂이를 어디에 두고 무엇을 먼저 치워야 하는지 알 수 있어요.
그래서 컴퓨터 프로젝트도 지금 모습과 원하는 모습을 같이 봐야 제대로 바꿀 수 있어요.