아키텍처 정보 구성과 리포지터리

핵심 요약

아키텍처 정보를 구축하려면 먼저 무엇을 관리하고 어떻게 연결할지 정해야 한다. 업무 기능, 데이터, 애플리케이션, 기술 등의 객체와 속성·관계·식별 규칙을 메타모델로 정의하고, 산출물은 이 객체를 서로 다른 관점으로 표현한다. 리포지터리는 승인된 객체와 관계, 상태와 이력을 유지하여 중복 식별과 영향 분석을 지원한다.

학습 목표

• 아키텍처 정보 구성 정의와 개별 산출물 작성의 차이를 설명한다.
• 메타모델의 객체·속성·관계·제약을 사례로 구분한다.
• 리포지터리, 문서 보관함, EA 관리 시스템의 차이를 판정한다.
• 식별자·소유자·상태·버전·기준일이 영향 분석에 필요한 이유를 설명한다.

1. 개념 설명

1.1 아키텍처 정보 구성 정의

EA 목적과 활용 시나리오에 맞춰 관리할 정보의 종류, 계층, 상세 수준, 표현 산출물, 관계와 관리 속성을 정하는 단계이다. 모든 가능한 정보를 수집하는 것이 아니라 어떤 의사결정 질문에 답할지를 기준으로 구성한다.

1.2 메타모델

메타모델은 아키텍처를 기술할 객체 유형과 관계의 규칙이다.

• 객체 유형: 업무 기능, 조직, 데이터 주제, 애플리케이션, 인터페이스, 기술 서비스 등
• 속성: 이름, 설명, 소유자, 중요도, 상태, 기준일 등
• 관계: 조직이 업무 기능을 수행함, 업무 기능이 데이터를 사용함, 애플리케이션이 기능을 지원함 등
• 제약: 필수 관계, 허용 관계, 다중성, 상태 전이 조건 등

메타모델은 실제 고객 시스템의 구조가 아니라 고객 시스템을 포함한 아키텍처 정보를 어떤 종류와 관계로 관리할지 정한 모델이다.

1.3 산출물과 객체

목록, 관계도, 매트릭스, 원칙서 등 산출물은 리포지터리 객체를 표현하는 방식이다. 같은 애플리케이션이 여러 산출물에 나타나더라도 동일 식별자를 공유해야 중복 등록과 불일치를 줄일 수 있다.

1.4 리포지터리

아키텍처 객체, 속성, 관계, 버전과 이력을 구조적으로 저장하는 기반이다. 파일 첨부 기능도 가질 수 있지만 핵심은 객체 간 관계를 질의하고 영향 범위를 추적할 수 있다는 점이다. 리포지터리를 운영하는 워크플로·검색·품질 점검 도구는 82600008의 관리 시스템과 연결된다.

2. 정보 구성의 핵심 요소

3. 정보 구축 흐름

활용 질문 정의
  예: 특정 업무 기능을 지원하는 애플리케이션과 사용 데이터는?
        ↓
객체·관계·필수 속성 설계
        ↓
식별·명명·계층·상태 규칙 정의
        ↓
현행 정보 수집·중복 식별·관계 연결
        ↓
목표·전환 정보 구축 및 교차 검토
        ↓
승인된 버전을 리포지터리 기준선으로 설정

정보를 수집한 후에 객체 규칙을 정하면 부서별 목록이 서로 다른 단위로 들어와 통합 비용이 커진다. 반대로 메타모델을 지나치게 세밀하게 만든 뒤 실제 활용 질문을 확인하지 않으면 입력 부담만 증가한다.

4. 관계 기반 영향 분석 사례

리포지터리에 다음 관계가 등록되어 있다고 가정한다.

[주문처리 업무 기능]
   ├─ uses → [고객 데이터]
   ├─ uses → [주문 데이터]
   └─ supported by → [주문 애플리케이션]
                              └─ hosted on → [레거시 플랫폼]

레거시 플랫폼 종료를 검토할 때 파일 목록만 있으면 영향받는 업무와 데이터를 수작업으로 찾아야 한다. 관계 기반 리포지터리에서는 플랫폼→애플리케이션→업무 기능·데이터 경로를 따라 영향 후보를 조회할 수 있다. 다만 관계의 기준일과 최신성이 낮으면 조회 결과도 신뢰할 수 없으므로 소유자와 검증일을 함께 관리한다.

5. 비교와 구분

시험 판단 포인트

• 정보 구성 정의는 관리할 객체·속성·관계·계층·산출물·관리 규칙을 정하는 활동이다.
• 메타모델은 아키텍처 대상 자체가 아니라 그 대상을 표현할 유형과 관계 규칙이다.
• 리포지터리의 핵심은 파일 보관보다 동일 객체 식별과 관계·버전 관리이다.
• 영향 분석에는 객체 관계뿐 아니라 기준일·소유자·상태의 신뢰성이 필요하다.
• 메타모델의 상세도는 실제 활용 질문과 관리 비용을 함께 고려해 결정한다.

자주 틀리는 부분

• 산출물 파일 수가 많으면 아키텍처 정보가 잘 구성되었다고 판단하지 않는다.
• 같은 객체가 여러 산출물에 나타날 때 별도 객체로 중복 등록하지 않는다.
• 리포지터리와 이를 운영하는 관리 시스템을 완전히 같은 개념으로 보지 않는다.
• 관계가 등록되어 있다는 사실만으로 최신성과 정확성이 보장된다고 보지 않는다.