프레임워크의 관점과 산출물 체계

핵심 요약

프레임워크는 어떤 이해관계자의 어떤 관심사를 어떤 표현 규칙과 산출물로 다룰지 정한다. 동일한 대상을 업무·데이터·애플리케이션·기술 도메인과 개념·논리·물리 수준 등 여러 축에서 바라볼 수 있으므로, 각 산출물의 목적과 관계를 명확히 해야 한다. 특정 프레임워크의 칸이나 문서 이름을 그대로 외우는 것보다 관점·뷰·산출물·메타모델의 관계를 판정하는 능력이 중요하다.

학습 목표

• 프레임워크의 구성요소와 도입 목적을 설명한다.
• 이해관계자, 관심사, 관점, 뷰, 산출물의 관계를 구분한다.
• 도메인 축과 추상화 수준 축을 혼동하지 않는다.
• 조직 목적에 맞게 산출물을 조정하되 필수 관계와 추적성을 보존하는 기준을 적용한다.

1. 개념 설명

1.1 아키텍처 프레임워크

아키텍처를 개발·표현·관리·활용하기 위한 개념, 분류 축, 방법, 역할, 산출물, 관계 규칙의 체계이다. 프레임워크는 누가 무엇을 왜 보아야 하는지와 그 정보를 어떤 형식으로 표현할지를 정해 복잡성을 통제한다.

1.2 이해관계자와 관심사

이해관계자는 아키텍처로 영향을 받거나 의사결정 책임을 가진 사람·조직이다. 관심사는 비용, 규제 준수, 업무 연속성, 데이터 일관성, 성능, 구현 가능성처럼 이해관계자가 확인하려는 문제이다. 같은 구조라도 경영자는 투자와 위험을, 설계자는 관계와 제약을 다른 깊이로 본다.

1.3 관점·뷰·산출물

• 관점(viewpoint): 특정 관심사를 표현하기 위한 규칙·표기·모델 종류를 정하는 방식이다.
• 뷰(view): 정해진 관점을 적용하여 실제 대상 시스템이나 조직을 표현한 결과이다.
• 산출물(artifact/deliverable): 모델, 목록, 매트릭스, 원칙서, 보고서 등 관리·검토 가능한 결과물이다.

용어 사용은 프레임워크마다 다를 수 있으므로 시험에서는 문맥을 확인한다. 다만 ‘관점은 표현 규칙’, ‘뷰는 그 규칙으로 만든 실제 표현’이라는 구분은 유용하다.

1.4 메타모델

메타모델은 관리할 아키텍처 객체의 종류, 속성, 관계와 제약을 정의한다. 예를 들어 업무 기능이 어떤 애플리케이션에 의해 지원되고 어떤 데이터를 사용하는지 연결 규칙을 정한다. 산출물 형식만 정하고 메타모델 관계를 정의하지 않으면 영향 분석이 어렵다.

2. 분류 축과 산출물 체계

아키텍처 정보는 보통 여러 축으로 분류한다. 축은 서로 대체 관계가 아니다.

예를 들어 ‘목표 데이터 아키텍처의 논리 수준에서 업무 책임자가 검토할 뷰’처럼 여러 축이 결합될 수 있다. ‘데이터’는 도메인이고 ‘논리’는 상세 수준이므로 둘을 같은 축의 선택지로 보아서는 안 된다.

3. 산출물 조정 원칙

프레임워크를 조직에 적용할 때 모든 산출물을 기계적으로 만드는 것은 바람직하지 않다. 다음 기준으로 조정한다.

1. 의사결정 목적과 이해관계자의 관심사를 먼저 확정한다.
2. 필요한 도메인·상세 수준·시간 상태를 선택한다.
3. 핵심 객체와 관계를 메타모델로 정의한다.
4. 각 산출물의 소유자, 갱신 주기, 승인 기준을 정한다.
5. 삭제하거나 간소화한 산출물이 필수 관계·추적성을 훼손하지 않는지 검토한다.

산출물을 줄이는 것과 정보를 누락하는 것은 다르다. 예를 들어 별도 목록을 만들지 않더라도 리포지터리의 객체와 관계로 동일한 질문에 답할 수 있다면 표현 방식만 조정한 것이다.

4. 관점 선택 사례

사례: 핵심 결제 시스템의 교체 여부를 심의한다.

• 경영 관점: 사업 위험, 투자 규모, 전환 효과, 규제 영향
• 업무 관점: 결제 기능과 책임, 예외 처리, 서비스 중단 허용 범위
• 데이터 관점: 거래 데이터의 권위 원천, 이관, 보존, 품질 규칙
• 애플리케이션 관점: 기능 배치, 인터페이스, 중복 기능
• 기술 관점: 성능·가용성·보안·운영 플랫폼

경영자에게 물리 서버 구성만 제시하거나, 기술 설계자에게 투자 효과 요약만 제시하면 관심사와 뷰가 맞지 않는다. 여러 뷰에서 같은 결제 시스템과 요구를 식별자로 연결해야 상충 여부를 찾을 수 있다.

5. 비교와 구분

시험 판단 포인트

• 프레임워크는 분류표만이 아니라 방법·역할·산출물·관계 규칙을 포함하는 체계이다.
• 관점은 관심사를 표현하는 규칙이고, 뷰는 그 관점을 특정 대상에 적용한 표현이다.
• 도메인·추상화 수준·시간 상태는 서로 다른 분류 축이다.
• 산출물 간 객체 식별과 관계가 있어야 교차 검토와 영향 분석이 가능하다.
• 조직 목적에 맞춘 산출물 조정은 가능하지만 핵심 정보와 추적성을 없애서는 안 된다.

자주 틀리는 부분

• 특정 프레임워크의 모든 산출물을 모든 조직에 동일하게 적용해야 한다고 단정하지 않는다.
• 이해관계자와 관심사를 같은 개념으로 보지 않는다.
• 관점, 뷰, 산출물을 모두 문서라는 이유로 같은 말로 처리하지 않는다.
• 업무·데이터·애플리케이션·기술 도메인을 추상화 수준과 동일 축으로 배열하지 않는다.