목차
- 들어가며: 아키텍처라는 보이지 않는 도시를 그리는 법
- 아키텍처 프레임워크는 왜 필요한가?
- Philippe Kruchten의 4+1 뷰 모델 (4+1 View Model)
- John Zachman의 자크만 프레임워크 (Zachman Framework)
- The Open Group의 TOGAF (The Open Group Architecture Framework)
- Simon Brown의 C4 모델 (C4 Model)
- 어떤 프레임워크를 선택해야 할까?
- 결론: 프레임워크는 목적지가 아닌 나침반이다
- 한 문장 요약
- 태그
들어가며: 아키텍처라는 보이지 않는 도시를 그리는 법
훌륭한 소프트웨어 아키텍처는 잘 계획된 도시와 같습니다. 도로, 상하수도, 전기망, 주거 지역, 상업 지역이 보이지 않는 곳에서 질서정연하게 작동하며 도시의 삶을 지탱하는 것처럼, 소프트웨어의 구성 요소, 데이터 흐름, 기술 정책 등도 시스템의 안정성과 확장성을 좌우하는 핵심적인 기반 시설입니다. 하지만 이 보이지 않는 도시를 어떻게 설계하고, 건축가, 토목 기사, 시민 등 다양한 이해관계자들에게 어떻게 설명할 수 있을까요? 바로 이때 필요한 것이 ‘아키텍처 프레임워크’라는 도시 계획의 원칙이자 청사진입니다. 🏙️
소프트웨어 아키텍처 프레임워크는 복잡하고 추상적인 아키텍처를 바라보는 다양한 ‘시점(Viewpoint)’을 정의하고, 각 시점에서 무엇을 그려야 하는지를 알려주는 일종의 가이드라인입니다. 개발자는 코드의 구조를, 프로젝트 관리자는 개발 일정을, 최종 사용자는 시스템의 기능을 궁금해합니다. 프레임워크는 이처럼 각기 다른 관심사를 가진 이해관계자들에게 맞춤형 지도를 제공하여, 모두가 시스템의 전체 그림에 대해 동일한 이해를 갖도록 돕는 강력한 의사소통 도구입니다.
이 글에서는 소프트웨어 공학의 역사 속에서 중요한 역할을 해온 대표적인 4가지 아키텍처 프레임워크인 4+1 뷰 모델, 자크만 프레임워크, TOGAF, C4 모델을 깊이 있게 탐구해 보겠습니다. 각 프레임워크의 철학과 구조, 장단점을 비교하며 어떤 상황에서 어떤 청사진이 가장 효과적인지 알아보겠습니다.
아키텍처 프레임워크는 왜 필요한가?
프레임워크 없이 아키텍처를 설계하는 것은 나침반 없이 항해하는 것과 같습니다. 아키텍트는 자신의 경험에만 의존하게 되고, 그 결과물은 다른 사람들이 이해하기 어려운 주관적인 그림이 될 수 있습니다. 프레임워크는 다음과 같은 명확한 이점을 제공합니다.
- 의사소통의 표준화: 아키텍처를 표현하는 공통된 용어와 다이어그램을 제공하여 이해관계자 간의 오해를 줄입니다.
- 설계의 완전성 보장: 시스템의 다양한 측면(구조, 행위, 데이터, 배포 등)을 체계적으로 검토하도록 유도하여 중요한 설계 요소가 누락되는 것을 방지합니다.
- 의사결정의 근거 마련: 아키텍처에 대한 결정을 문서화하고 추적할 수 있는 틀을 제공하여, 왜 그런 설계가 선택되었는지 명확한 근거를 남깁니다.
- 재사용성 및 일관성: 조직 내에서 표준 프레임워크를 사용하면, 여러 프로젝트에 걸쳐 일관된 품질의 아키텍처를 유지하고 설계 자산을 재사용하기 용이합니다.
Philippe Kruchten의 4+1 뷰 모델 (4+1 View Model)
4+1 뷰 모델은 1995년 필립 크루chten이 제안한, 아마도 가장 널리 알려지고 실용적인 아키텍처 프레임워크일 것입니다. 이 모델의 핵심은 서로 다른 이해관계자의 관점(View)에 따라 시스템을 4개의 주요 뷰와 1개의 보조 뷰로 나누어 설명하는 것입니다.
4개의 주요 뷰
- 논리 뷰 (Logical View): 최종 사용자의 관점에서 시스템이 어떤 기능을 제공하는지에 초점을 맞춥니다. 주로 클래스 다이어그램이나 객체 다이어그램을 사용하여 시스템의 기능적 요구사항을 표현하며, 시스템 분석가나 설계자가 주된 독자입니다.
- 프로세스 뷰 (Process View): 시스템의 동적인 측면, 즉 여러 프로세스나 스레드가 어떻게 동시에 실행되고 상호작용하는지를 보여줍니다. 시퀀스 다이어그램이나 활동 다이어그램을 사용하여 성능, 확장성, 동시성 같은 비기능적 요구사항을 다루며, 시스템 통합 전문가가 관심을 갖습니다.
- 구현 뷰 (Implementation View): 개발자의 관점에서 소스 코드와 바이너리가 어떻게 구성되고 관리되는지를 설명합니다. 컴포넌트 다이어그램이나 패키지 다이어그램을 사용하여 소프트웨어 모듈의 구성과 의존 관계를 보여주며, 개발 관리자가 주된 독자입니다.
- 배포 뷰 (Deployment View): 시스템이 어떤 물리적인 하드웨어(서버, 네트워크 장비 등)에 어떻게 설치되고 배포되는지를 보여줍니다. 배포 다이어그램을 사용하여 시스템의 물리적 토폴로지, 통신, 설치 등을 다루며, 시스템 엔지니어나 운영자가 관심을 갖습니다.
+1 유스케이스 뷰 (Use Case View)
유스케이스 뷰는 이 4개의 뷰를 하나로 묶고 검증하는 중심 역할을 합니다. 주요 유스케이스 시나리오 몇 개를 선정하고, 이 시나리오가 4개의 뷰를 모두 관통하며 어떻게 실현되는지를 보여줌으로써 아키텍처의 일관성과 완전성을 검증합니다. 이 뷰는 아키텍처의 존재 이유를 설명하는 가장 중요한 뷰이며, 모든 이해관계자가 아키텍처를 이해하는 출발점이 됩니다.
4+1 뷰 모델은 비교적 단순하고 실용적이어서, 대부분의 소프트웨어 개발 프로젝트에 쉽게 적용할 수 있다는 큰 장점이 있습니다.
John Zachman의 자크만 프레임워크 (Zachman Framework)
자크만 프레임워크는 1987년 존 자크만이 IBM에서 제안한 엔터프라이즈 아키텍처(EA)를 위한 프레임워크입니다. 소프트웨어 시스템뿐만 아니라, 비즈니스 프로세스, 조직 구조를 포함하는 기업 전체의 정보를 체계적으로 분류하고 조망하기 위한 존재론적(Ontological) 분류 체계에 가깝습니다.
이 프레임워크는 6개의 질문(What, How, Where, Who, When, Why)을 가로축으로 하고, 5개의 관점(Scope, Business Model, System Model, Technology Model, Detailed Representations)을 세로축으로 하는 6×5 매트릭스, 즉 30개의 셀로 구성됩니다.
- 가로축 (질문): 무엇(데이터), 어떻게(기능), 어디서(네트워크), 누가(사람), 언제(시간), 왜(동기)라는 기본적인 질문을 나타냅니다.
- 세로축 (관점): 계획가(Scope), 소유자(Business), 설계자(System), 구축자(Technology), 구현가(Detailed) 등 기업 내 다른 역할을 맡은 사람들의 관점을 나타냅니다.
각 셀은 특정 질문과 특정 관점의 교차점으로, 해당 셀에 맞는 아키텍처 산출물(예: 데이터 모델, 프로세스 흐름도 등)을 채워 넣도록 되어 있습니다. 예를 들어, ‘What’ 열과 ‘System Model’ 행이 만나는 셀에는 시스템 설계 관점에서의 논리적 데이터 모델이 위치하게 됩니다.
자크만 프레임워크의 강점은 기업의 모든 정보 자산을 체계적이고 빠짐없이 분류하고 문서화할 수 있다는 점입니다. 하지만 ‘무엇을’ 채워야 하는지에 대한 분류 틀만 제공할 뿐, ‘어떻게’ 설계하고 개발해야 하는지에 대한 구체적인 프로세스나 방법론은 제시하지 않는다는 한계가 있습니다. 따라서 방법론이라기보다는 분류 체계 또는 청사진의 청사진으로 이해하는 것이 적절합니다.
The Open Group의 TOGAF (The Open Group Architecture Framework)
TOGAF는 The Open Group이라는 표준화 컨소시엄이 개발하고 유지하는 엔터프라이즈 아키텍처 개발을 위한 상세한 방법론이자 프레임워크입니다. 자크만 프레임워크가 ‘무엇’에 대한 정적인 분류 틀이라면, TOGAF는 ‘어떻게’ 아키텍처를 개발하고 관리할 것인지에 대한 동적인 프로세스를 제공합니다.
TOGAF의 핵심은 ADM(Architecture Development Method)이라는 반복적인 아키텍처 개발 프로세스입니다. ADM은 예비 단계부터 시작하여 비전, 비즈니스, 정보 시스템(데이터, 애플리케이션), 기술 아키텍처를 차례로 정의하고, 기회와 솔루션을 도출하여 구현 거버넌스 및 변경 관리로 이어지는 순환적인 라이프사이클을 제시합니다.
TOGAF는 크게 4가지 주요 아키텍처 도메인을 다룹니다.
- 비즈니스 아키텍처 (Business Architecture): 비즈니스 전략, 거버넌스, 조직 구조 및 주요 비즈니스 프로세스를 정의합니다.
- 데이터 아키텍처 (Data Architecture): 조직의 논리적, 물리적 데이터 자산과 데이터 관리 자원의 구조를 설명합니다.
- 애플리케이션 아키텍처 (Application Architecture): 배포할 애플리케이션 시스템의 청사진과 애플리케이션 간의 상호작용 관계를 정의합니다.
- 기술 아키텍처 (Technology Architecture): 비즈니스, 데이터, 애플리케이션 서비스를 지원하는 데 필요한 논리적 소프트웨어 및 하드웨어 인프라를 설명합니다.
TOGAF는 대규모 조직에서 전사적 아키텍처를 체계적으로 수립하고 관리하기 위한 포괄적이고 상세한 가이드를 제공한다는 점에서 매우 강력합니다. 하지만 그만큼 복잡하고 방대하여, 중소규모 프로젝트에 적용하기에는 다소 무겁고 과할 수 있다는 평가를 받기도 합니다.
Simon Brown의 C4 모델 (C4 Model)
C4 모델은 최근 애자일 개발 환경에서 주목받고 있는, 소프트웨어 아키텍처를 시각화하기 위한 간결하고 실용적인 접근법입니다. 사이먼 브라운이 제안한 이 모델은 아키텍처 다이어그램을 마치 구글 맵처럼 확대/축소(Zoom in/out)하며 볼 수 있도록 4가지 다른 추상화 수준으로 나누어 설명합니다.
- 레벨 1: 시스템 컨텍스트 (System Context): 가장 높은 수준의 뷰로, 우리가 만들 시스템을 하나의 검은 상자로 보고, 이 시스템과 상호작용하는 외부 사용자나 다른 외부 시스템과의 관계를 보여줍니다. 비기술적인 사람도 쉽게 이해할 수 있는 전체적인 그림입니다.
- 레벨 2: 컨테이너 (Containers): 시스템 내부로 한 단계 들어가서, 시스템이 어떤 컨테이너들로 구성되어 있는지 보여줍니다. 여기서 컨테이너는 웹 애플리케이션, 모바일 앱, 데이터베이스, 파일 시스템 등 독립적으로 실행되거나 배포될 수 있는 단위를 의미합니다.
- 레벨 3: 컴포넌트 (Components): 컨테이너 내부로 다시 한 단계 들어가서, 각 컨테이너가 어떤 컴포넌트들로 구성되어 있는지 보여줍니다. 컴포넌트는 관련된 기능들을 묶어놓은 코드의 그룹(예: 컨트롤러, 서비스, 리포지토리)을 의미하며, 주로 인터페이스 뒤에 캡슐화됩니다.
- 레벨 4: 코드 (Code): 가장 낮은 수준의 뷰로, 각 컴포넌트의 내부 구현을 보여주는 UML 클래스 다이어그램이나 ERD 등을 의미합니다. C4 모델은 이 레벨은 필요할 때만 선택적으로 작성할 것을 권장합니다.
C4 모델은 개발자를 위한 실용적인 다이어그램을 만드는 데 초점을 맞추고 있으며, 복잡한 UML 표기법 대신 간단한 상자와 선, 텍스트만으로 명확한 아키텍처 문서를 만들 수 있도록 돕습니다. 애자일 환경에서 아키텍처를 지속적으로 문서화하고 공유하는 데 매우 효과적입니다.
어떤 프레임워크를 선택해야 할까?
네 가지 프레임워크는 각각의 철학과 목적이 다르므로, 상황에 맞는 선택이 중요합니다.
- 4+1 뷰 모델: 대부분의 단일 소프트웨어 시스템 개발 프로젝트에 적용하기 좋은 실용적이고 균형 잡힌 프레임워크입니다.
- 자크만 프레임워크: 기업의 정보 자산을 전체적으로 조망하고 분류하고자 할 때 유용한 강력한 분류 체계입니다.
- TOGAF: 대기업이나 정부 기관에서 전사적 아키텍처(EA)를 수립하고 관리하기 위한 포괄적인 프로세스와 방법론이 필요할 때 적합합니다.
- C4 모델: 애자일 개발팀이 소프트웨어 아키텍처를 쉽고 명확하게 시각화하고, 지속적으로 문서를 관리하고자 할 때 매우 효과적입니다.
결론: 프레임워크는 목적지가 아닌 나침반이다
소프트웨어 아키텍처 프레임워크는 모든 것을 해결해 주는 만병통치약이 아닙니다. 프레임워크를 맹목적으로 따르는 것은 오히려 불필요한 문서 작업과 경직된 설계를 낳을 수 있습니다. 중요한 것은 각 프레임워크가 제공하는 ‘관점’과 ‘사고의 틀’을 이해하고, 우리 프로젝트의 특성과 조직의 문화에 맞게 현명하게 취사선택하여 활용하는 것입니다.
4+1 뷰 모델의 다각적인 시점, 자크만의 체계적인 분류, TOGAF의 거버넌스 프로세스, C4의 실용적인 시각화 등 이 위대한 청사진들이 제공하는 지혜를 나침반 삼아, 우리는 보이지 않는 소프트웨어라는 도시를 더 체계적이고 견고하게, 그리고 모든 사람이 이해할 수 있도록 만들어 나갈 수 있을 것입니다. 🧭