Siemens 아키텍처 뷰로 설계와 구현을 연결하는 방법

하나의 설계를 서로 다른 질문에 답하게 만드는 뷰

아키텍처 문서가 비즈니스 기능, 코드 구조, 배포 환경을 한 장에 모두 담으려 하면 읽는 사람마다 필요한 정보를 찾기 어려워진다. Siemens 아키텍처 뷰는 시스템을 개념적 아키텍처, 모듈, 코드, 실행 관점으로 나누어 이 문제를 다룬다.

각 뷰는 시스템의 다른 측면을 보여 준다. 동시에 서로 연결되어야 한다. 기능 영역이 모듈로 구현되고, 모듈이 코드 구조에 반영되며, 코드 컴포넌트가 런타임 인스턴스로 배포되는 흐름이 문서에서 추적되어야 한다.

비즈니스 기능과 시스템 경계를 먼저 그리는 개념적 뷰

개념적 아키텍처 뷰는 주요 기능 요소와 그 상호작용을 높은 수준에서 표현한다. 비즈니스 도메인의 핵심 추상화, 정보 흐름, 시스템 경계를 드러내고 기본 구성 원칙과 설계 결정을 문서화하는 데 쓴다.

이 뷰에서는 주요 기능 영역, 서브시스템과 컴포넌트, 정보 흐름, 시스템 경계를 다룬다. 경영진이나 제품 관리자처럼 구현 세부사항보다 시스템의 전체 모습을 먼저 이해해야 하는 이해관계자에게 적합하다. 핵심 설계 결정과 트레이드오프를 공유하고 아키텍처의 방향을 정하는 역할도 맡는다.

대규모 전자상거래 플랫폼이라면 다음과 같이 주문, 제품, 결제, 재고와 외부 연계의 관계를 표현할 수 있다.

⤢✕

모듈 구조에서 의존성과 인터페이스를 드러낸다

모듈 뷰는 소프트웨어의 정적 구조를 대상으로 한다. 모듈화와 계층화, 분해 원칙을 정하고 모듈·패키지·클래스 사이의 의존성 및 인터페이스를 문서화한다.

개발 팀은 이 뷰를 통해 코드를 어떤 단위로 나누고 어떤 의존성을 허용할지 판단할 수 있다. 유지보수성과 확장성을 고려한 구조 최적화에도 직접 연결된다.

전자상거래 시스템의 계층과 비즈니스 모듈은 다음과 같이 표현할 수 있다.

⤢✕

구현 저장소와 빌드 단위를 다루는 코드 뷰

코드 뷰는 실제 구현의 물리적 구조를 설명한다. 소스 코드가 파일, 디렉터리, 패키지로 어떻게 배치되는지와 라이브러리·프레임워크·개발 환경·빌드 스크립트 및 설정을 다룬다. 빌드 과정과 배포 방식도 이 관점에서 문서화한다.

이 뷰는 개발자에게 코드 구성 규칙을 구체적으로 전달하고, 새 팀원이 프로젝트 구조를 파악하는 일을 돕는다. 배포와 빌드 프로세스를 표준화할 때도 기준점이 된다.

마이크로서비스 기반 시스템에서는 서비스 모듈, 공통 라이브러리, 도구와 스크립트, 각 서비스 내부의 소스·테스트·설정 구조를 다음처럼 나타낼 수 있다.

⤢✕

런타임 상호작용은 실행 뷰에서 확인한다

실행 뷰는 시스템이 실행되는 동안의 동작을 설명한다. 프로세스와 스레드, 런타임 의존성, 동기·비동기 통신 패턴, 배포 토폴로지를 대상으로 하며 성능, 확장성, 가용성을 함께 고려한다.

이 관점은 배포 전략과 인프라 요구사항을 정의하고, 장애 시나리오와 복구 전략을 검토하는 데 쓰인다. 설계 단계에서 실행 환경의 제약을 확인할 수 있다는 점도 중요하다.

클라우드 기반 마이크로서비스 시스템의 실행 관계는 다음과 같이 표현할 수 있다.

⤢✕

뷰 사이의 매핑이 문서의 신뢰도를 만든다

이 모델의 핵심은 뷰를 개별 산출물로 남기는 데 있지 않다. 개념적 뷰의 서브시스템은 모듈 뷰의 모듈 집합으로 구현되고, 모듈은 코드 뷰의 패키지와 클래스로 매핑된다. 코드 뷰의 컴포넌트는 실행 뷰에서 런타임 인스턴스로 배포된다.

⤢✕

이 연결이 유지되면 요구사항이나 설계 결정이 바뀌었을 때 영향 범위를 따라갈 수 있다. 반대로 한 뷰만 갱신하면 문서는 남아 있어도 설계의 현재 상태를 설명하지 못하게 된다.

시스템 성격에 따라 뷰를 적용하는 방식

금융 서비스 시스템에서는 개념적 뷰로 계좌 관리, 거래 처리, 보고서 생성 같은 주요 비즈니스 기능을 정의할 수 있다. 모듈 뷰에는 계층화된 아키텍처와 DDD(Domain-Driven Design) 패턴을 적용하고, 코드 뷰에서는 마이크로서비스 기반 코드 구조와 CI/CD 파이프라인을 다룬다. 실행 뷰는 고가용성을 위한 클러스터링 및 데이터베이스 샤딩 전략을 표현한다.

통신사 고객 관리 시스템에서는 고객 관리, 청구, 서비스 프로비저닝 영역을 개념적 뷰에서 식별한다. 모듈 뷰는 플러그인 기반 아키텍처로 확장성을 확보하는 구조가 될 수 있으며, 코드 뷰에는 멀티테넌트 지원을 위한 패키지 구조와 설정을 담는다. 실행 뷰는 지역별 데이터 센터 분산 배포 및 재해 복구 전략을 대상으로 한다.

아키텍처 문서를 구축할 때의 순서

먼저 이해관계자를 식별하고 비즈니스 목표와 기술적 제약을 파악한다. 성능, 보안, 확장성과 같은 품질 속성의 우선순위도 이 단계에서 정한다.

그다음 주요 서브시스템과 컴포넌트를 식별해 개념적 아키텍처를 수립하고, 컴포넌트 간 상호작용과 정보 흐름을 정의한다. 이를 바탕으로 모듈화 전략, 의존성 관리 방안, 인터페이스와 계약을 설계한다.

구현 단계에서는 코드 구성 규칙과 네이밍 컨벤션을 정하고 빌드·패키징 전략을 수립한다. 이어 배포 토폴로지와 인프라 요구사항을 정의하며 성능, 확장성, 가용성 전략을 반영한다. 마지막으로 각 뷰를 문서화하고 뷰 간 일관성과 추적성을 검증한다.

모든 관심사를 이 구조만으로 담을 수는 없다

Siemens 아키텍처 뷰만으로는 도메인 특화 관점을 충분히 표현하지 못할 수 있다. 복잡한 시스템의 모든 측면을 이 구조에 맞추기 어렵고, 이해관계자별로 특화된 뷰를 제공하는 데도 한계가 있다.

필요하다면 보안 뷰나 데이터 뷰를 추가할 수 있다. 각 뷰 안에서는 다양한 다이어그램과 표현 방식을 활용하고, SEI 뷰 모델이나 ISO/IEC 42010 같은 다른 아키텍처 프레임워크와 통합하는 방법도 고려할 수 있다.