EA 수립·관리·활용의 순환

핵심 요약

EA 프로세스는 한 번의 구축 프로젝트로 끝나지 않는다. 전략과 변화 동인을 반영해 방향을 정하고, 현행·목표·전환 정보를 구축·승인한 뒤, 투자·설계·운영 의사결정에 활용하고 변화 결과를 다시 아키텍처에 반영한다. 각 단계는 고정된 일방향 폭포식 절차가 아니라 검토 결과에 따라 반복될 수 있다.

학습 목표

• EA 생명주기의 주요 활동과 입력·출력을 연결한다.
• EA 프로세스와 개별 정보시스템 개발 생명주기를 구분한다.
• 기준선 승인, 변경 통제, 활용 결과의 피드백이 필요한 이유를 설명한다.
• EA 프로세스 단원과 관리 체계·관리 시스템 단원의 경계를 판정한다.

1. 개념 설명

1.1 방향 수립

전략, 규제, 기술 변화, 현행 문제를 분석해 EA의 목적·범위·원칙·추진 방식을 정한다. 무엇을 만들지보다 어떤 의사결정에 사용할지가 먼저 명확해야 한다.

1.2 아키텍처 정보 구축

정보 구성과 메타모델을 정한 뒤 현행을 조사하고 목표·전환 구조와 이행 과제를 개발한다. 도메인 간 객체와 관계를 일관되게 식별하며 검토 가능한 근거를 남긴다.

1.3 승인과 기준선

검토·합의된 아키텍처를 기준선으로 설정하면 이후 변경을 비교·통제할 기준이 생긴다. 기준선은 영구 고정 문서가 아니라 승인된 특정 버전이다.

1.4 활용

사업 기획, 예산·투자 심의, 프로젝트 착수, 설계 준수 검토, 자산 정비, 영향 분석, 전환 로드맵 관리 등에 아키텍처를 사용한다. 활용하지 않는 정보는 갱신 우선순위와 상세도를 재검토해야 한다.

1.5 변경과 지속 개선

전략·업무·시스템 변화 또는 활용 과정에서 발견된 오류를 영향 분석하고 승인 후 기준선에 반영한다. 활용 성과와 운영 문제는 다음 방향 수립과 정보 구성 개선의 입력이 된다.

2. 순환 구조와 산출물

[방향 수립]
목적·범위·원칙·추진계획
       ↓
[정보 구축]
현행·목표·전환·로드맵
       ↓
[검토·승인/기준선]
합의된 아키텍처 버전
       ↓
[활용]
투자·설계·운영·영향 분석
       ↓
[변경·성과 평가]
변경 결과·준수 결과·개선 과제
       └───────────────↺ 방향·정보 구성에 피드백

3. 프로세스 적용 원칙

• 반복성: 목표 설계 중 현행 누락이 발견되면 현행 조사로 돌아갈 수 있다.
• 추적성: 전략·원칙·요구와 목표 구조, 이행 과제가 연결되어야 한다.
• 기준선 통제: 승인 전 작업본과 승인된 버전을 구분한다.
• 활용 우선: 단순 최신성보다 의사결정 가치가 높은 정보를 우선 관리한다.
• 성과 피드백: 표준 준수, 중복 제거, 전환 진척, 의사결정 시간 등 결과를 다음 주기에 반영한다.

변경 요청의 접수·승인 역할이나 관리 시스템 기능은 82600008에서 더 자세히 다루며, 이 단원에서는 순환 속에서 변경이 어디에 위치하고 무엇과 연결되는지를 중심으로 본다.

4. 실패 사례 진단

사례 A: 구축 후 미활용 아키텍처 산출물을 완료했지만 투자 심의 양식과 프로젝트 검토 절차에 연결하지 않았다. 정보가 활용되지 않아 갱신 동기도 사라진다.

사례 B: 무통제 갱신 프로젝트 담당자가 리포지터리 목표 구조를 승인 없이 수정했다. 어느 버전이 의사결정 기준인지 알 수 없고, 기존 로드맵과 불일치가 발생한다.

사례 C: 성과 없는 최신화 모든 객체를 매월 갱신하지만 어떤 의사결정에도 사용하지 않는다. 활용 시나리오와 정보 상세도를 재설계해야 한다.

세 사례는 각각 활용 연계, 기준선 통제, 성과 피드백이 빠진 경우이다.

5. 비교와 구분

시험 판단 포인트

• EA 프로세스는 방향 수립→정보 구축→승인·기준선→활용→변경·개선의 순환이다.
• 기준선은 승인된 특정 버전이며 변경 불가능한 영구 문서가 아니다.
• EA 활용은 투자·설계·운영 의사결정과 연결되어야 한다.
• 단계는 필요에 따라 반복되며 후속 검토가 앞 단계 수정의 근거가 될 수 있다.
• EA 생명주기와 개별 시스템 개발 생명주기, 관리 도구 기능을 구분한다.

자주 틀리는 부분

• EA 구축 완료를 EA 운영과 동일시하지 않는다.
• 모든 정보의 잦은 갱신 자체를 활용 성과로 판단하지 않는다.
• 기준선 설정을 이후 변경 금지로 오해하지 않는다.
• 프로젝트 개발 절차를 그대로 EA 전사 프로세스로 대체하지 않는다.