방향 수립과 전사 범위 정의

핵심 요약

방향 수립은 곧바로 현행 모델을 작성하는 단계가 아니다. 조직이 왜 EA를 추진하는지, 어떤 의사결정을 개선할지, 어느 조직·업무·데이터·시스템을 어느 수준까지 다룰지, 누가 승인하고 수행할지를 먼저 정한다. 이 합의가 불명확하면 뒤의 정보 구축 범위와 품질 기준이 흔들린다.

학습 목표

• 전략·현안에서 아키텍처 비전과 목표를 도출하는 흐름을 설명한다.
• 비전·목표·원칙·범위·추진 계획의 차이를 구분한다.
• 좋은 아키텍처 원칙의 구성과 예외 처리 기준을 판정한다.
• 전사 범위 정의서와 추진 체계의 필수 항목을 사례에 적용한다.

1. 개념 설명

1.1 변화 동인과 아키텍처 비전

변화 동인은 경영 전략, 신규 사업, 합병, 규제, 비용 구조, 기술 노후화, 데이터 활용 요구 등 EA 추진의 원인이다. 비전은 이러한 동인을 반영해 조직이 어떤 아키텍처 능력과 상태를 지향하는지 간결하게 제시한다.

1.2 목표와 성공 기준

목표는 비전을 측정 가능한 결과로 구체화한다. 예를 들어 ‘고객 데이터 공유 강화’보다 ‘핵심 고객 식별 기준을 통합하고 채널 간 중복 데이터를 감소시킨다’처럼 대상과 결과가 분명해야 한다. 성공 지표는 후속 성과 평가와 연결하되 근거 없는 출제 비중이나 수치를 정답으로 고정하지 않는다.

1.3 아키텍처 원칙

반복되는 설계·투자 선택을 일관되게 하기 위한 상위 판단 기준이다. 원칙은 보통 명칭, 명확한 선언, 적용 이유, 기대 효과, 적용 결과와 예외 조건으로 구성한다. ‘최신 기술 사용’처럼 선택 기준이 모호하거나 상충 원칙의 우선순위가 없는 문장은 실효성이 낮다.

1.4 범위와 상세도

범위는 조직·법인·지역·업무 기능·데이터·애플리케이션·기술, 기준 시점, 외부 경계를 명시한다. 상세도는 의사결정 목적에 필요한 수준으로 정한다. 범위가 같아도 위험이 큰 영역은 상세하게, 안정된 영역은 요약 수준으로 다룰 수 있다.

1.5 추진 체계와 계획

의사결정자, 아키텍처 책임자, 도메인 담당자, 현업·프로젝트 참여자, 검토·승인 역할을 정한다. 구축 일정, 조사 방법, 품질 기준, 도구, 커뮤니케이션, 위험과 산출물 계획도 포함한다. 데이터아키텍트의 세부 역량은 별도 신규 단원 후보로 분리한다.

2. 방향 수립 산출물

3. 방향 수립 절차

1. 경영 전략과 대내외 변화 동인을 수집한다.
2. 현행 문제와 기대 효과를 이해관계자별로 정리한다.
3. EA 비전, 목표, 성공 기준을 정의한다.
4. 원칙 후보를 만들고 상충·예외를 검토한다.
5. 조직·업무·정보기술의 포함·제외 범위와 상세도를 정한다.
6. 추진 조직의 권한·책임과 의사결정 경로를 확정한다.
7. 정보 구축·검토·승인·전환 계획과 위험을 수립한다.
8. 주요 이해관계자의 합의를 받아 착수 기준선으로 설정한다.

방향 수립 중 모든 현행 정보를 완성하려고 하면 착수 단계가 지연된다. 대신 범위와 우선 조사 영역을 정할 만큼의 사전 진단을 수행한다.

4. 원칙 판별 사례

다음 두 원칙 후보를 비교한다.

• 후보 A: “모든 시스템은 최신 기술을 사용한다.”
• 후보 B: “공통 고객 식별은 승인된 전사 식별 기준을 우선 적용한다. 법규 또는 외부 기관 제약으로 예외가 필요한 경우 데이터 책임자의 영향 검토와 승인 후 매핑 규칙을 등록한다.”

후보 B는 대상, 우선 기준, 예외 사유, 승인과 후속 조치를 판정할 수 있다. 후보 A는 ‘최신’의 기준과 업무 효과, 예외가 불명확해 프로젝트별로 다른 해석을 낳는다.

5. 비교와 구분

시험 판단 포인트

• 방향 수립은 변화 동인→비전·목표→원칙→범위→추진 체계·계획의 논리로 연결된다.
• 아키텍처 원칙은 선언뿐 아니라 근거, 영향, 예외 조건을 가져야 판단에 사용할 수 있다.
• 범위에는 포함 대상뿐 아니라 제외 대상, 경계, 기준 시점과 상세도를 명시한다.
• 승인 권한과 실무 수행 책임을 구분해야 한다.
• 현행 모델 완성은 방향 수립의 목적이 아니며 후속 정보 구축에서 수행한다.

자주 틀리는 부분

• 비전, 목표, 원칙을 모두 같은 상위 문구로 보지 않는다.
• 전사 범위를 모든 대상을 동일 상세도로 분석한다는 뜻으로 해석하지 않는다.
• 아키텍처 원칙을 제품명이나 단기 프로젝트 일정으로 작성하지 않는다.
• 관리 도구 선정만으로 방향 수립이 완료되었다고 판단하지 않는다.