현행·목표·전환 아키텍처

핵심 요약

현행 아키텍처는 단순 자산 목록이 아니라 현재 업무와 정보기술 구조, 관계, 문제, 제약을 기준 시점에 맞춰 표현한 기준선이다. 목표 아키텍처는 전략과 원칙을 충족할 지향 구조이며, 전환 아키텍처는 목표에 한 번에 도달하기 어려울 때 일정 시점에 운영 가능한 중간 상태를 정의한다. 이행 계획은 전환 상태를 만들 과제의 순서·책임·의존성·완료 기준을 관리한다.

학습 목표

• 현행·목표·전환 아키텍처와 이행 계획의 목적과 산출물을 구분한다.
• 현행과 목표의 차이를 갭으로 식별하고 실행 과제로 전환하는 흐름을 설명한다.
• 전환 아키텍처와 단순 프로젝트 일정표의 차이를 사례로 판정한다.
• 선행관계·위험·자원·업무 연속성을 고려한 전환 로드맵을 읽는다.

1. 개념 설명

1.1 현행 아키텍처

특정 기준 시점의 업무 기능, 데이터, 애플리케이션, 기술 구조와 관계를 사실에 근거해 나타낸다. 문제점뿐 아니라 재사용 가능한 자산, 계약·규제·운영 제약도 포함한다. 현행을 부정확하게 단순화하면 잘못된 갭과 과제가 도출된다.

1.2 목표 아키텍처

경영 전략, 변화 요구, 아키텍처 원칙을 충족하기 위해 지향하는 구조이다. 목표는 단순한 최신 기술 목록이 아니라 업무 능력과 데이터·애플리케이션·기술의 관계가 어떻게 달라지는지를 표현해야 한다. 목표 시점과 성공 기준이 있어야 한다.

1.3 전환 아키텍처

현행에서 목표로 이동하는 과정에 둘 이상의 중요한 중간 운영 상태가 필요할 때 정의한다. 일부 레거시와 신규 구조가 공존하거나, 조직·데이터·시스템 전환 시점이 다른 경우에 유용하다. 전환 아키텍처는 ‘언젠가 바꾼다’는 계획이 아니라 해당 시점에 실제 운영 가능한 구조이다.

1.4 이행 계획

갭을 해소할 프로그램·프로젝트·변경 과제를 묶어 우선순위, 선행관계, 책임자, 자원, 위험, 마일스톤과 완료 기준을 정의한다. 아키텍처 상태를 설명하는 전환 아키텍처와 실행 활동을 관리하는 이행 계획은 연계되지만 같은 산출물은 아니다.

2. 산출물의 연결 구조

현행 기준선 ──비교──> 목표 아키텍처
     │                    │
     └────── 갭 목록 ─────┘
                  ↓
        이행 과제·의존성·우선순위
                  ↓
       전환 아키텍처 1 → 전환 아키텍처 2
                  ↓
             목표 상태 도달

3. 갭 분석과 전환 설계 절차

1. 현행의 기준 시점과 신뢰 가능한 출처를 확정한다.
2. 목표 시점과 목표 원칙·성공 기준을 정의한다.
3. 업무·데이터·애플리케이션·기술별 차이를 식별하고 원인을 구분한다.
4. 갭을 해소할 과제를 도출하고 중복·의존성·제약을 분석한다.
5. 한 번에 전환할 수 없는 경우 중간 운영 상태를 설계한다.
6. 과제 우선순위, 책임자, 자원, 위험, 완료 기준을 로드맵에 배치한다.
7. 각 전환 상태가 다음 상태와 목표에 추적되는지 검토한다.

갭은 ‘현행에 없는 것’만을 뜻하지 않는다. 목표에서 제거해야 할 현행 요소, 목표 수준에 미달한 요소, 관계나 책임이 바뀌어야 하는 요소도 갭이 된다.

4. 전환 사례

상황: 세 개 고객 시스템을 하나로 통합하려 하지만, 규제 보고 시스템은 18개월 동안 기존 고객번호를 요구한다.

적절한 전환 설계

• 전환 1: 통합 고객 식별자를 도입하되 기존 고객번호와 매핑을 유지한다.
• 전환 2: 내부 채널은 통합 식별자를 기본으로 사용하고 규제 보고에는 변환 서비스를 적용한다.
• 목표: 규제 시스템 개편 후 기존 번호 의존성을 제거한다.

이 경우 ‘통합 고객 시스템 구축’이라는 프로젝트 일정만으로는 중간 데이터 구조와 공존 규칙을 알 수 없다. 전환 아키텍처에는 어느 식별자가 권위 있는지, 동기화 책임과 오류 처리, 전환 종료 조건이 표현되어야 한다.

5. 비교와 구분

시험 판단 포인트

• 현행은 현재 상태의 기준선, 목표는 지향 구조, 전환은 중간 운영 가능한 아키텍처이다.
• 전환 아키텍처는 이행 계획과 연계되지만 상태 구조와 실행 활동이라는 차이가 있다.
• 갭에는 신규 도입뿐 아니라 제거·개선·관계 변경·책임 변경이 포함될 수 있다.
• 목표 구조만 있고 선행관계·위험·완료 기준이 없으면 실행 가능한 로드맵이 아니다.
• 중간 상태에서 업무 연속성과 데이터 정합성이 유지되는지 확인해야 한다.

자주 틀리는 부분

• 현행 아키텍처를 문제점 목록이나 자산 목록 중 하나로만 보지 않는다.
• 목표 아키텍처를 특정 제품 도입안과 동일시하지 않는다.
• 전환 아키텍처를 단순한 일정·프로젝트 목록으로 보지 않는다.
• 모든 갭을 한 번에 제거하는 계획이 항상 최선이라고 판단하지 않는다.