소프트웨어 공학 100 주제 시리즈의 23번째 글이다. (카테고리: 설계와 아키텍처)

한 줄 요약

Philippe Kruchten 의 4+1 뷰 모델(1995)은 아키텍처를 논리·프로세스·개발·물리 네 개의 뷰로 나눠 그리고, 몇 개의 핵심 시나리오(+1) 로 네 뷰가 함께 동작함을 보이고 검증하는 방법이다. 핵심은 “한 장의 그림에 모든 것을 담으려 하지 말라” 는 것이다.

왜 필요한가

Kruchten 은 논문 서두에서 흔한 아키텍처 그림을 이렇게 비판한다. 박스는 실행 중인 프로그램인가, 소스 코드 덩어리인가, 물리 컴퓨터인가, 기능의 논리적 묶음인가? 화살표는 컴파일 의존인가, 제어 흐름인가, 데이터 흐름인가? “대개는 이 모든 것이 조금씩 섞여 있다.”

이런 그림은 누구에게도 정확한 답을 주지 못한다. 성능을 걱정하는 통합 담당자는 스레드와 프로세스를 알아야 하는데 그림에는 클래스 이름이 있다. 빌드를 나누려는 개발 리드는 패키지 의존을 알아야 하는데 그림에는 서버 대수가 있다. 4+1 은 이 문제를 이해관계자별로 관심사를 분리해서 푼다. SE100 #022 에서 본 ISO/IEC/IEEE 42010 의 관점·뷰 개념보다 5년 앞선, 같은 발상의 실무판이다.

핵심 개념

원전

Philippe Kruchten, “The 4+1 View Model of architecture”, IEEE Software 12(6), 42–50, 1995년 11월. 저자가 당시 Rational Software 에 있었고, 논문의 예제는 PABX(사설 전화 교환기)와 항공 관제 시스템을 단순화한 것이다. 공개된 원고 사본은 UBC 사본에서 읽을 수 있다.

논문은 Perry 와 Wolf 의 공식을 Boehm 이 수정한 형태로 인용하며 시작한다.

Software architecture = { Elements, Forms, Rationale/Constraints }

그리고 이 공식을 각 뷰에 독립적으로 적용한다. 뷰마다 쓸 요소(컴포넌트, 컨테이너, 커넥터)를 정하고, 잘 동작하는 형태와 패턴을 잡고, 근거와 제약을 요구사항에 연결한다. 뷰마다 다른 아키텍처 스타일을 고를 수 있으므로 한 시스템에 여러 스타일이 공존할 수 있다.

다섯 개의 뷰

            최종 사용자                        프로그래머
            (기능)                            (소프트웨어 관리)
        ┌──────────────┐               ┌──────────────┐
        │  논리 뷰      │               │  개발 뷰      │
        └──────────────┘               └──────────────┘
                        ┌────────────┐
                        │ 시나리오(+1) │
                        └────────────┘
        ┌──────────────┐               ┌──────────────┐
        │  프로세스 뷰   │               │  물리 뷰      │
        └──────────────┘               └──────────────┘
            통합 담당자                        시스템 엔지니어
            (성능, 확장성)                     (토폴로지, 통신)

논문의 그림 1을 옮긴 것이다. 각 뷰의 목적은 다음과 같다.

뷰 무엇을 보여 주나 주 이해관계자 원 논문의 표기
논리(logical) 기능 요구사항. 문제 영역의 핵심 추상화(객체·클래스) 최종 사용자 Booch 표기 기반 클래스 다이어그램, 상태 다이어그램. 데이터 중심이면 E-R
프로세스(process) 동시성과 동기화. 태스크·프로세스, 분산, 성능·가용성 통합 담당자 프로세스·태스크와 통신 메커니즘 표기
개발(development) 개발 환경에서의 정적 구성. 모듈·서브시스템·레이어 프로그래머, 관리자 모듈·서브시스템 다이어그램
물리(physical) 소프트웨어를 하드웨어에 매핑. 분산 측면 시스템 엔지니어 노드·네트워크 배치도
시나리오(+1) 네 뷰가 함께 동작함을 보이는 중요 유스케이스 모두 객체 시나리오·상호작용 다이어그램

몇 가지 세부가 실무에 유용하다.

  • 프로세스 뷰는 주요 태스크(아키텍처 요소로서 고유하게 다뤄지는 것)와 부수 태스크(버퍼링, 타임아웃 같은 구현상 이유로 생기는 것)를 구분한다. 아키텍처 문서에는 전자만 그린다.
  • 개발 뷰에 대해 논문은 서브시스템을 4~6개 정도의 레이어로 나누고, 서브시스템은 같은 레이어나 아래 레이어에만 의존할 수 있다는 규칙을 권한다. 레이어드 아키텍처의 설계 규칙 그대로다(레이어드 아키텍처).
  • 논리 뷰와 개발 뷰는 일대일이 아니다. 논문의 예에서 “외부 인터페이스—게이트웨이” 라는 논리 범주의 구현은 통신 프로토콜(레이어 1 이하), 일반 게이트웨이 메커니즘(레이어 2), 개별 게이트웨이(레이어 5)로 여러 레이어에 흩어진다. 이 불일치가 바로 뷰를 따로 그려야 하는 이유다.

“+1” 의 의미

논문은 시나리오 뷰를 다른 뷰와 중복(redundant) 된다고 명시한다. 그래서 4 가 아니라 “+1” 이다. 그런데도 두 가지 목적이 있다.

  1. 발견의 동력: 아키텍처 설계 중에 요소를 찾아내는 수단. 시나리오를 객체와 연산의 쌍으로 “대본화(scripting)” 하면 필요한 추상화, 프로세스, 서브시스템이 드러난다.
  2. 검증과 설명: 설계가 끝난 뒤 종이 위에서, 그리고 아키텍처 프로토타입 테스트의 출발점으로서 네 뷰가 정합한지 확인한다.

시나리오 주도 반복 과정

논문은 선형적인 아키텍처 설계 단계를 비판하고 반복 과정을 제안한다. 요약하면 다음과 같다.

시작:
  위험과 중요도로 소수의 시나리오 선택
  허수아비(strawman) 아키텍처를 세움
  시나리오를 대본화 → 주요 추상화 발견 → 네 청사진에 배치
  구현·테스트·측정 → 결함 발견, 교훈 기록
반복:
  위험 재평가, 시나리오 추가
  새 시나리오를 기존 아키텍처에 대본화 → 새 요소나 큰 변경 발견
  네 청사진 갱신, 구현(아키텍처 프로토타입) 업그레이드
  가능하면 실제 환경에서 부하 측정
  다섯 청사진 전부를 검토해 단순화·재사용 기회 탐색
  설계 지침과 근거 갱신

여기서 프로토타입은 버리는 탐색용이 아니라 점차 실제 시스템이 되는 진화형 프로토타입이다. 논문은 두세 번 반복하면 새 주요 추상화·서브시스템·인터페이스가 더 나오지 않는 안정 상태에 이르기를 기대한다고 적는다.

맞춤(tailoring)

모든 시스템에 다섯 뷰가 필요한 것은 아니다. 논문은 프로세서가 하나뿐이면 물리 뷰를, 프로세스가 하나뿐이면 프로세스 뷰를 생략할 수 있고, 아주 작은 시스템에서는 논리 뷰와 개발 뷰가 거의 같아 따로 그릴 필요가 없을 수도 있다고 말한다. 시나리오만은 어떤 경우에도 유용하다.

예제: 사내 주문 시스템을 4+1 로

뷰 이 시스템에서 답할 질문 산출물
논리 주문, 결제, 재고는 어떤 개념이고 어떤 규칙으로 엮이나 도메인 클래스 다이어그램(핵심 집합체만)
프로세스 주문 API 와 결제 워커는 같은 프로세스인가, 큐로 연결되나, 동시 주문 시 재고 경합은 어디서 막나 프로세스·스레드·큐 다이어그램
개발 모듈은 order-api, order-domain, payment-adapter 로 나뉘고 의존 방향은 패키지 다이어그램 + 의존 규칙
물리 각 프로세스는 어느 노드(파드)에 몇 개 뜨나, DB 와 브로커는 어디 있나 배포 다이어그램
시나리오 “재고 1개 남은 상품에 동시 주문 2건” 시퀀스 다이어그램, 네 뷰의 요소를 모두 관통

시나리오 하나가 네 뷰를 검증하는 방식은 이렇다. 동시 주문 시나리오를 따라가면 논리 뷰에서는 재고 차감 규칙이, 프로세스 뷰에서는 두 요청이 어느 시점에 경합하는지가, 개발 뷰에서는 그 규칙이 어느 모듈에 있는지가, 물리 뷰에서는 두 요청이 서로 다른 파드에 도착할 수 있다는 사실이 드러난다. 어느 뷰에서도 답이 안 나오면 그 칸이 설계의 빈틈이다.

문서 구성에 대해 논문은 산출물을 두 개로 제안한다. 4+1 구조를 따르는 소프트웨어 아키텍처 문서와, 아키텍처 무결성을 지키기 위해 반드시 존중해야 할 중요 설계 결정을 담는 소프트웨어 설계 지침이다. 후자는 오늘날의 ADR(SE100 #025) 과 역할이 겹친다.

흔한 오해와 함정

  • “4+1 은 UML 다이어그램 다섯 장이다.” 원 논문은 Booch 표기와 Rational Rose 를 썼지만 “다른 표기와 도구를 써도 된다” 고 명시한다. 모델의 핵심은 관심사 분리이지 표기가 아니다.
  • “뷰 다섯 개를 다 그려야 완성이다.” 논문 스스로 맞춤을 권한다. 쓸모없는 뷰는 생략한다.
  • “시나리오는 요구사항 문서의 유스케이스를 복사하면 된다.” 아키텍처 시나리오는 위험과 중요도로 골라낸 소수다. 모든 유스케이스를 넣으면 검증 도구가 아니라 또 하나의 요구사항 문서가 된다.
  • “개발 뷰 = 논리 뷰의 패키지 버전.” 둘은 일대일이 아니다. 팀 구성, 코드 규모, 재사용, 릴리스 정책 같은 제약이 개발 뷰를 바꾼다.
  • “한 번 그리면 끝.” 논문의 과정은 반복이다. 측정 결과로 청사진을 계속 갱신하지 않으면 문서는 곧 실제와 어긋난다.

확인 문제

  1. Kruchten 이 단일 다이어그램의 문제로 지적한 것은 무엇인가?
  2. 시나리오 뷰를 “+1” 이라 부르는 이유와, 그럼에도 필요한 두 가지 목적은?
  3. 프로세서가 하나이고 프로세스도 하나인 작은 도구라면 어떤 뷰를 생략할 수 있는가?
  4. 논리 뷰의 한 범주가 개발 뷰의 여러 레이어에 흩어지는 것은 설계 오류인가?
  5. 4+1 과 ISO/IEC/IEEE 42010 의 관계를 한 문장으로 설명하라.

풀이

  1. 박스와 화살표가 무엇을 뜻하는지(프로그램인지 코드인지 컴퓨터인지, 의존인지 제어 흐름인지 데이터 흐름인지)가 섞여 있어, 한 장이 표현할 수 있는 것보다 많은 것을 담으려 한다는 점.
  2. 다른 네 뷰와 내용이 중복되기 때문이다. 목적은 설계 중 아키텍처 요소를 발견하는 동력, 그리고 설계 후 네 뷰를 검증·설명하고 프로토타입 테스트의 출발점이 되는 것.
  3. 물리 뷰와 프로세스 뷰. 아주 작다면 논리 뷰와 개발 뷰를 합칠 수도 있다. 시나리오는 남긴다.
  4. 아니다. 논리적 구분과 개발상의 구성은 서로 다른 관심사를 따르므로 일대일이 아닐 수 있다. 오히려 그 차이를 명시하는 것이 뷰를 분리하는 목적이다.
  5. 4+1 은 42010 이 말하는 “관심사별 관점과 뷰” 를 미리 정해 둔 구체적 관점 묶음의 하나로 볼 수 있다.

더 읽을거리 (References)