1과목 — 전사아키텍처 이해

10문항 / 20 %. 공식 출제 범위는 셋이다.

전사아키텍처 개요   정의 · 프레임워크 · 참조모델 · 프로세스
전사아키텍처 구축   방향 수립 · 정보 구성 정의 · 정보 구축
전사아키텍처 관리·활용

가장 추상적인 과목이라 용어를 외우면 헷갈리고 구조를 잡으면 쉬워진다.

1부 · 전사아키텍처 개요

1. EA는 무엇을 해결하는가

부서마다 필요한 시스템을 각자 만들면 이런 일이 벌어진다.

영업부   고객관리 시스템   고객번호 = CUST0001
고객센터 상담 시스템       고객번호 = 20250001
물류부   배송 시스템       고객번호 = C-1

같은 고객인데 셋을 이을 방법이 없다. 통합하려면 매핑 표를 만들어야 하고, 어느 것이 진짜인지 아무도 모른다. 게다가 세 시스템이 각각 고객 정보를 저장하느라 같은 투자를 세 번 했다.

전사아키텍처(EA) — 조직의 업무·데이터·응용·기술을 전사 관점에서 정렬하여 현재 상태를 파악하고 목표 상태로 이행하는 것을 지속적으로 관리하는 체계.

시험이 반복해서 확인하는 것은 이 정의의 두 부분이다.

핵심어	무슨 뜻인가	자주 나오는 함정
전사 관점	개별 시스템이 아니라 조직 전체	"개별 시스템의 코드 품질 측정"은 EA가 아니다
지속 관리	한 번 만들고 끝이 아님	ISP처럼 특정 시점의 계획이 아니다

1.1 EA 도입 배경

· 정보시스템의 중복 투자
· 시스템 간 연계 곤란
· 업무 변화에 대한 대응 지연
· 정보화 투자 효과 측정 불가
· IT 자산 현황 파악 불가

1.2 기대 효과

효과	내용
중복 투자 방지	기존 자산과 대조해 겹치는 사업 식별
상호운용성 확보	표준과 연계 구조 정렬
변화 대응력 향상	영향도 분석으로 파급 범위 파악
의사결정 지원	근거 있는 정보화 예산 심의
IT 자산 가시화	무엇이 어디에 있는지 파악

2. 네 개의 아키텍처 도메인

EA는 조직을 네 층으로 나누어 본다. 위에서 아래로 갈수록 구체적이다.

다이어그램 로딩 중…

어느 도메인의 일인지 묻는 문제가 과목을 가로질러 나온다.

항목	도메인
데이터 모델, 표준 사전, 주제 영역 정의서, 데이터 흐름도	DA
서버 랙 배치도, 네트워크 구성도, 전원 계통, 회선 대역폭	TA
결재 라인, 조직도, 업무 절차, 업무 기능 분해도	BA
시스템 인터페이스 목록, 화면 목록, 프로그램 목록	AA

DAsP는 DA 자격이므로 "이건 DA가 아니라 TA다" 를 고르게 하는 문제가 특히 자주 나온다.

3. EA의 구성 요소

규칙 / 내용물 / 운영 방법 / 도구 로 기억하면 섞이지 않는다.

구성 요소	무엇인가	예
EA 정책	지켜야 할 규칙	EA 원칙, 지침, 표준
EA 정보	관리 대상 내용물	산출물, 참조모델, 메타데이터
EA 관리 체계	운영하는 방법	조직, 역할, 프로세스, 성숙도 관리
EAMS	담는 도구	EA 관리 시스템

3.1 EA 원칙

판단이 갈릴 때 기준이 되는 문장이다. EA 구축의 가장 앞 단계에서 정한다.

· 데이터는 자산이다
· 데이터는 공유한다
· 데이터는 한 곳에서 관리하고 여러 곳에서 활용한다
· 표준을 우선 적용한다
· 정보시스템은 업무 요구에 기반한다

원칙이 없으면 사업마다 다른 판단이 내려진다.

3.2 EAMS — EA 관리 시스템

한다      산출물 등록 · 조회 · 검색
          버전과 변경 이력 관리
          산출물 간 연관 관계 추적 (영향도 분석)
          표준 준수 여부 점검
          현행·목표 아키텍처 비교

안 한다   소스 코드 정적 분석
          시스템 성능 튜닝
          산출물 자동 작성
          업무 요구사항 도출

마지막 둘이 특히 잘 나온다. 도구는 사람이 넣은 것을 관리할 뿐 스스로 만들어 내지 못한다.

4. EA 프레임워크

4.1 Zachman Framework

EA 산출물을 행렬로 정리하는 방식이다. 1987년 John Zachman이 제안했고 이후 모든 EA 프레임워크의 원형이 되었다.

          What      How       Where     Who       When      Why
          (데이터)   (기능)    (위치)     (사람)    (시간)    (동기)
계획자     │         │         │         │         │         │
소유자     │         │         │         │         │         │
설계자     │  ← 각 칸이 하나의 산출물 ←    │         │         │
개발자     │         │         │         │         │         │
계약자     │         │         │         │         │         │

행 = 관점(누가 보는가)     위로 갈수록 추상적, 아래로 갈수록 구체적
열 = 관심사(무엇을 보는가)  6하원칙

빠진 관점이나 관심사를 한눈에 찾을 수 있다는 것이 매트릭스 방식의 핵심 효용이다.

4.2 TOGAF ADM

The Open Group이 만든 프레임워크이며, 그 안의 ADM(Architecture Development Method) 이 구축 절차를 정의한다.

예비 단계
  ↓
A. 아키텍처 비전
  ↓
B. 업무 아키텍처
  ↓
C. 정보시스템 아키텍처 (데이터 · 응용)
  ↓
D. 기술 아키텍처
  ↓
E. 기회와 해결책
  ↓
F. 이행 계획
  ↓
G. 이행 거버넌스
  ↓
H. 변경 관리  ──→ (다시 A 로)

세부 단계 이름을 외우기보다 순환한다는 점이 중요하다. H에서 A로 돌아가는 것이 "EA는 지속 관리 체계" 라는 정의와 이어진다.

4.3 산출물의 세 수준

Zachman의 행을 단순화하면 데이터 아키텍처에서 쓰는 세 수준이 된다.

수준	누구를 위한 것	담는 내용
개념	경영진·기획	주제 영역, 핵심 엔터티, 큰 관계
논리	현업·설계자	엔터티, 속성, 관계, 식별자
물리	개발·운영	테이블, 컬럼, 인덱스, 저장 구조

4과목에서 다시 나오므로 여기서 확실히 잡아 두면 두 번 이득이다.

5. EA 참조모델 (RM)

기관마다 제각각 분류하면 비교가 불가능하다. 그래서 공통 분류 체계를 미리 정해 둔 것이 참조모델이다.

참조모델	무엇을 분류하는가
PRM 성과 참조모델	성과 지표
BRM 업무 참조모델	업무 기능
DRM 데이터 참조모델	데이터의 분류·구조·교환
SRM 서비스 참조모델	응용 서비스 컴포넌트
TRM 기술 참조모델	기술 요소

앞 글자가 도메인과 대응한다 — Business, Data, Service, Technology. 여기에 성과(Performance)가 더해진 형태다.

5.1 DRM — 데이터 참조모델

DAsP에서 가장 중요한 참조모델이다. 세 가지를 분류한다.

데이터 분류    어떤 주제 영역으로 나눌 것인가
데이터 구조    어떤 엔터티·속성으로 표현할 것인가
데이터 교환    어떤 형식으로 주고받을 것인가

참조모델을 쓰는 이유 — 기관 간 아키텍처 정보를 비교·공유하기 위해서다. 각 기관이 자기 분류 체계를 쓰면 통계도 중복 투자 식별도 불가능해진다.

2부 · 전사아키텍처 구축

다이어그램 로딩 중…

6. EA 방향 수립

· EA 도입 목적과 기대 효과를 정의한다
· EA 원칙을 수립한다
· EA 적용 범위를 정한다 (어느 조직, 어느 업무까지)
· 추진 조직과 역할을 정한다
· 추진 일정과 단계를 수립한다

7. EA 정보 구성 정의

무엇을 만들지 정하는 단계다. 실제로 만드는 것은 다음 단계다.

· 아키텍처 매트릭스를 설계한다 (관점 × 관심사)
· 각 칸에 어떤 산출물을 둘지 목록을 확정한다
· 산출물의 작성 수준과 상세도를 정한다
· 참조모델을 선정하거나 정의한다
· 메타데이터 정의서를 작성한다

2단계와 3단계의 구분이 순서 문제로 자주 나온다. "무엇을 만들지 정하는 것" 과 "만드는 것" 은 다른 단계다.

8. EA 정보 구축

8.1 현행 아키텍처 (As-Is)

· 현재 업무 기능과 프로세스
· 현재 데이터 구조와 표준
· 현재 응용 시스템과 연계 현황
· 현재 기술 인프라

8.2 목표 아키텍처 (To-Be)

· 개선된 업무 구조
· 통합·표준화된 데이터 구조
· 재편된 응용 시스템 구성
· 목표 기술 인프라

8.3 왜 As-Is를 그리는가

As-Is 파악  →  To-Be 설계  →  차이(Gap) 도출  →  이행 과제 수립
                                  ↑
                        As-Is 없으면 여기가 비어 버린다

이행 계획은 차이에서 나온다. 현재를 모르면 무엇을 바꿔야 할지 알 수 없다.

3부 · 전사아키텍처 관리 및 활용

9. EA 관리 체계

9.1 조직과 역할

역할	하는 일
EA 총괄 책임자	방향 결정, 의사결정
EA 관리자	산출물 관리, 변경 통제
도메인 아키텍트	BA/DA/AA/TA 각 영역 설계
현업 담당자	업무 정보 제공, 검토

9.2 EA 관리 프로세스

변경 요청 접수  →  영향도 분석  →  심의·승인  →  산출물 갱신  →  공유

영향도 분석이 승인보다 먼저라는 점이 순서 문제로 나온다. 얼마나 영향을 주는지 모르는 상태로는 승인 판단을 할 수 없다.

9.3 EA 성숙도 모형

조직의 EA 수준을 단계로 측정한다.

1  초기      개별적 · 산발적. 전사 관점 없음
2  기본      일부 영역에 EA 도입. 표준 일부 존재
3  관리      전사 범위 EA 수립. 관리 프로세스 운영
4  최적화    EA를 의사결정에 실제 활용. 측정과 개선
5  혁신      EA가 경영 전략과 연계되어 지속 진화

측정하는 목적 — 등급 자체가 아니라 다음에 무엇을 할지 찾기 위해서다. 현재 수준을 알아야 개선 과제가 나온다. "등급을 올려 홍보하기 위해" 같은 보기는 오답이다.

10. EA 활용

활용	어떻게 쓰는가
중복 투자 방지	신규 사업의 기능·데이터를 기존 자산 목록과 대조
정보화 예산 심의	EA 정보를 근거로 사업의 타당성과 우선순위 판단
변화 영향도 분석	하나를 바꿀 때 연관 산출물을 추적해 파급 범위 파악
상호운용성 확보	표준과 연계 구조를 정렬해 데이터 교환 가능하게 함
IT 자산 관리	무엇이 어디에 있고 누가 쓰는지 파악

10.1 중복 투자 식별 방법

무엇을 대조하는가가 핵심이다.

✓  신규 사업의 기능·데이터를 기존 자산 목록과 대조
✗  사업 담당자의 소속 부서 확인
✗  예산 규모만 비교
✗  제안서의 분량 비교

같은 부서가 다른 기능을, 다른 부서가 같은 기능을 제안할 수 있으므로 소속으로는 판단할 수 없다.

10.2 상호운용성

자주 헷갈리는 용어다. 서로 다른 시스템이 데이터를 주고받으며 함께 동작하는 능력을 말한다.

상호운용성 ✓   두 시스템이 같은 고객번호 체계를 써서 데이터를 교환할 수 있다
상호운용성 ✗   화면이 일관되고 쓰기 편하다 (사용성)
상호운용성 ✗   접속자가 늘어도 빠르다 (확장성)
상호운용성 ✗   혼자서도 잘 돈다 (오히려 반대)

11. EA vs ISP — 가장 많이 나오는 비교

두 개념을 섞어 놓은 보기가 매 회 등장한다.

	EA	ISP
성격	지속 관리 체계	특정 시점의 계획 수립
기간	계속 갱신	한 번 수립하고 종료
산출물	아키텍처 정보 (현행·목표)	정보화 전략 계획서
관계	서로 독립적. ISP가 EA 정보를 활용할 수 있음

자주 나오는 오답 네 가지를 미리 알아 둔다.

✗  ISP 는 EA 의 하위 산출물이다              → 독립적인 활동이다
✗  EA 와 ISP 는 동일한 활동이다              → 성격이 다르다
✗  ISP 를 수립하면 EA 는 필요 없다           → ISP 는 시간이 지나면 낡는다
✗  EA 가 있으면 ISP 를 세울 수 없다          → 함께 쓸 수 있다

12. 한 줄 정리

물음	답
EA는 무엇인가	조직 전체를 하나의 구조로 보고 지속 관리하는 체계
도메인 넷	업무 BA · 데이터 DA · 응용 AA · 기술 TA
구성 요소	정책(규칙) · 정보(내용물) · 관리 체계(운영) · EAMS(도구)
EAMS가 안 하는 일	코드 분석 · 성능 튜닝 · 산출물 자동 작성 · 요건 도출
Zachman	관점(행) × 관심사(열) 매트릭스. 빈칸 발견에 강함
TOGAF ADM	A~H 순환 절차. 끝나면 다시 돌아옴
참조모델 5종	PRM · BRM · DRM · SRM · TRM
DRM이 분류하는 것	데이터 분류 · 구조 · 교환
구축 절차	방향 수립 → 정보 구성 정의 → 정보 구축
2단계 vs 3단계	무엇을 만들지 정함 vs 실제로 만듦
As-Is를 그리는 이유	To-Be와의 차이가 곧 이행 과제
성숙도를 재는 이유	등급이 아니라 다음 개선 과제
중복 투자 식별 방법	기능·데이터를 기존 자산과 대조
상호운용성	서로 다른 시스템이 데이터를 주고받으며 함께 동작
EA vs ISP	지속 체계 vs 특정 시점 계획. 서로 독립