242. 전사 아키텍처 (EA) 수립 절차 및 현황-목표 아키텍처

핵심 인사이트

본질: EA(Enterprise Architecture — 전사 아키텍처)는 조직의 비즈니스·데이터·애플리케이션·기술 아키텍처를 통합하는 프레임워크로, IT 투자의 일관성·표준성·연계성을 확보하는 청사진(Blueprint)이다.

가치: EA는 각 부서가 독립적으로 IT를 구축할 때 발생하는 중복 투자, 상호운용성 문제, 데이터 사일로를 사전에 방지하고, 신규 시스템 도입 시 전사 표준 준수 여부를 체계적으로 검증한다.

판단 포인트: EA의 성숙도는 '아키텍처 원칙 준수 메커니즘'에 달려 있다. 원칙을 문서화했어도 신규 프로젝트 승인 시 EA 검토가 없다면 EA는 유명무실해진다.

Ⅰ. 개요 및 필요성

EA(Enterprise Architecture)는 1987년 John Zachman이 제안한 개념으로, 조직의 구조와 IT 자산을 통합적으로 관리하는 방법론이다. 한국에서는 전자정부법 제51조와 'EA 수립·관리 지침(행안부)'에 의해 중앙부처·지자체의 EA 수립이 의무화되어 있다.

EA가 없는 조직은 IT 자산이 부서별로 분산되어 전체 그림을 알 수 없고, 새로운 시스템 도입 시 기존 시스템과의 충돌·중복 투자가 발생한다. EA는 이 문제를 해결하기 위해 현황 아키텍처(Baseline Architecture)와 목표 아키텍처(Target Architecture) 사이의 전환 계획(Transition Plan)을 제공한다.

공공기관의 경우 EA 수립 결과물은 예산 심의 및 정보화 사업 추진 시 필수 참조 문서로 활용된다. 민간에서는 SAP ERP 고도화, 클라우드 전환, 디지털 전환 추진 시 EA를 기반으로 아키텍처 의사결정을 진행한다.

📢 섹션 요약 비유: EA는 '도시 건축 허가 시스템'이다. 신축 건물(새 IT 시스템)은 반드시 도시 마스터플랜(EA)에 맞게 설계되어야 하며, 아니면 허가(IT 예산 승인)가 나지 않는다.

Ⅱ. 아키텍처 및 핵심 원리

EA 4대 영역(Viewpoint)

영역	명칭	내용
BA	Business Architecture (비즈니스 아키텍처)	조직 목표, 업무 프로세스, 조직 구조
DA	Data Architecture (데이터 아키텍처)	데이터 모델, 데이터 흐름, 마스터 데이터
AA	Application Architecture (애플리케이션 아키텍처)	애플리케이션 목록, 인터페이스, 기능 분류
TA	Technology Architecture (기술 아키텍처)	인프라, 플랫폼, 보안, 네트워크 표준

┌──────────────────────────────────────────────────────────────────┐
│                    EA 4대 영역 계층 구조                          │
│                                                                   │
│  ┌────────────────────────────────────────────────────────────┐  │
│  │  BA (비즈니스 아키텍처)                                    │  │
│  │  전략 목표 ─ 핵심 업무 프로세스 ─ 조직 역할              │  │
│  └──────────────────────────┬─────────────────────────────────┘  │
│                              │ 지원                               │
│  ┌────────────────────────────▼─────────────────────────────────┐ │
│  │  AA (애플리케이션 아키텍처)                                  │ │
│  │  ERP ─ CRM ─ SCM ─ 그룹웨어 ─ 포털 ─ 모바일                │ │
│  │  ◀─────── 인터페이스/통합 레이어 (EAI/ESB/API) ──────────▶  │ │
│  └──────────────┬──────────────────────────┬────────────────────┘ │
│                 │ 사용                      │ 사용                  │
│  ┌──────────────▼────────────┐  ┌───────────▼──────────────────┐  │
│  │  DA (데이터 아키텍처)     │  │  TA (기술 아키텍처)           │  │
│  │  MDM ─ DW ─ 데이터 표준  │  │  서버/스토리지/NW/보안/클라우드│  │
│  └───────────────────────────┘  └──────────────────────────────┘  │
└──────────────────────────────────────────────────────────────────┘

EA 수립 절차 (6단계)

단계	내용
1. 준비	EA 수립 범위 확정, 원칙·비전 수립
2. 현황(Baseline) 파악	현재 BA/DA/AA/TA 목록화
3. 목표(Target) 설계	미래 아키텍처 설계, 갭 분석
4. 전환 계획 수립	Migration Plan, 우선순위 결정
5. EA 저장소 구축	EA Repository (EAMS — EA Management System)
6. 거버넌스 운영	아키텍처 검토 위원회, 원칙 준수 모니터링

📢 섹션 요약 비유: EA는 '레고 설명서'다. 각각의 블록(시스템)이 어떻게 연결되는지 설명서(EA)가 있어야 전체 조립(통합 IT 환경)이 의도대로 완성된다.

Ⅲ. 비교 및 연결

현황 아키텍처 vs 목표 아키텍처 비교

항목	현황(Baseline)	목표(Target)
목적	현재 IT 자산 현황 파악	미래 IT 아키텍처 설계
내용	현재 시스템 목록·연계·문제점	개선 아키텍처·신기술 도입
산출물	현황 다이어그램, 인벤토리	목표 다이어그램, 표준
활용	Gap 분석 기반	신규 사업 검토 기준

주요 EA 프레임워크 비교

프레임워크	특징	활용 영역
Zachman Framework	6×6 매트릭스, 관점별 분류	개념적 분류 도구
TOGAF ADM	아키텍처 개발 방법론 (8단계 사이클)	실무 수립 방법론
FEA(Federal EA)	미국 연방정부 EA	공공기관 참조
NAF(NATO Architecture Framework)	국방 아키텍처	국방 IT
K-EA(한국형 EA)	행안부 지침 기반	국내 공공기관

📢 섹션 요약 비유: EA 프레임워크는 '건축 설계 양식'이다. 같은 건물도 미국 설계 기준(FEA), 유럽 기준(TOGAF), 한국 기준(K-EA)에 따라 작성 형식이 다르지만, 건물의 구조는 같다.

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

EA 거버넌스 체계

아키텍처 검토 위원회(ARB — Architecture Review Board)

신규 IT 프로젝트 착수 전 EA 준수 여부 검토
아키텍처 예외(Exception) 처리 절차 관리
CTO 또는 EA 총괄 아키텍트 주관

EA 원칙(Architecture Principles) 예시

"모든 데이터는 단일 출처(Single Source of Truth)에서 관리된다."
"신규 시스템은 재사용 가능한 공통 서비스를 우선 활용한다."
"모든 인터페이스는 표준 API(RESTful)를 사용한다."

EAMS(EA Management System) 구성 요소

구성	역할
아키텍처 저장소(Repository)	BA/DA/AA/TA 산출물 저장·관리
연계 분석 도구	애플리케이션 간 인터페이스 시각화
변경 이력 관리	아키텍처 버전 관리
대시보드	아키텍처 준수율, 노후화 현황 시각화

📢 섹션 요약 비유: ARB는 '도시 건축심의위원회'다. 새 건물(신규 IT)이 도시 규획(EA 원칙)에 맞는지 심의하고, 위반 시 설계 변경을 요구한다.

Ⅴ. 기대효과 및 결론

EA를 통해 조직은 IT 자산의 전체 그림을 확보하고, 중복 투자를 방지하며, 신기술 도입 시 충격(Impact)을 사전에 분석할 수 있다. Gartner에 따르면 EA를 운영하는 조직은 IT 프로젝트 성공률이 25% 이상 높고, 운영 비용이 15~20% 절감된다.

한국 공공기관은 'EA Portal(eakorea.go.kr)'을 통해 범정부 EA 표준을 공유하며, 정보화 사업 예산 심의 시 EA 점검표 제출이 의무화되어 있다. 민간에서는 클라우드 전환 로드맵, MSA(Microservice Architecture) 전환 설계의 기반으로 EA를 활용한다.

기술사 시험에서는 EA의 4대 영역과 현황-목표 아키텍처 전환 방법론, TOGAF ADM 사이클, EA 거버넌스 구조를 이해하고 실제 조직 맥락에서 적용 시나리오를 제시하는 능력이 요구된다.

📢 섹션 요약 비유: EA는 '회사 IT의 GPS 지도'다. GPS 지도가 없으면 어디 있는지(현황)도, 어디로 가야 하는지(목표)도 모르고, 다른 차(부서)와 충돌(중복 투자)이 날 수 있다.

📌 관련 개념 맵

개념	설명	연관 키워드
EA(Enterprise Architecture)	전사 아키텍처 청사진	BA, DA, AA, TA
현황 아키텍처(Baseline)	현재 IT 자산 및 구조	인벤토리, Gap 분석
목표 아키텍처(Target)	미래 IT 구조 및 표준	로드맵, 전환 계획
ARB(Architecture Review Board)	신규 IT 아키텍처 준수 검토 위원회	거버넌스, 원칙
EAMS	EA 관리 시스템·저장소	버전 관리, 대시보드
TOGAF	EA 개발 방법론 프레임워크	ADM, 아키텍처 도메인
Zachman Framework	6×6 EA 분류 매트릭스	What, How, Where, Who, When, Why

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

EA는 '놀이공원 지도'다. 지도가 있어야 어디에 롤러코스터(중요 시스템)가 있고, 어떻게 가야 하는지(인터페이스)를 알 수 있다.
현황 아키텍처는 '현재 내 방 배치'고, 목표 아키텍처는 '인테리어 리모델링 후 계획'이다. 어떻게 바꿀지(전환 계획) 정해야 공사를 시작할 수 있다.
ARB는 '가구 배치 확인하는 집주인'이다. 새 가구(새 시스템)를 들여놓기 전에 다른 가구(기존 시스템)와 겹치지 않는지, 방(표준)에 맞는지 확인한다.