아키텍처 패턴

개요

주문 화면에서 수량 입력 칸의 변경 처리기가 입력 문자열을 숫자로 바꾸고, 재고보다 많으면 오류 라벨을 채우고, 아니면 합계를 계산해 합계 라벨에 쓰고 주문 버튼을 켠다고 하자. 주문 버튼의 클릭 처리기는 같은 재고 검사를 한 번 더 하고 DB에 주문을 저장한다. "재고보다 많이 주문할 수 없다"는 규칙 하나를 확인하려 해도 창을 띄우고 DB를 연결한 뒤 칸에 숫자를 넣어 봐야 한다. 입력 해석, 화면 갱신, 업무 규칙, 저장이 처리기 두 개에 섞여 있어서 어느 하나만 따로 실행하거나 바꿀 수 없다.

이 문서에서 아키텍처 패턴은 이런 코드를 화면 단위나 애플리케이션 단위로 나누는 방식에 붙은 이름이다. 각 패턴은 어떤 역할을 둘지, 사용자 입력과 화면 갱신이 어느 역할을 거쳐 흐를지, 소스 코드의 의존이 어느 방향을 향할지를 정한다. 프로그래밍 패턴 문서가 소개하는 GoF 디자인 패턴은 객체를 만들고 조립하고 협력시키는 방식을 다루므로 범위가 더 작다. 두 수준은 함께 쓰인다. 예를 들어 MVC에서 모델이 뷰에 변경을 알리는 부분은 옵서버 패턴이다.

아키텍처 패턴이 답하는 질문은 두 갈래다. 화면 하나 안에서 입력, 표시, 화면 규칙을 어떻게 나눌지는 UI 아키텍처 패턴이 다룬다. MVC, MVP, MVVM, MVU가 여기에 속하고 각각 별도 문서가 있다. 업무 규칙과 DB, 웹 프레임워크, 외부 서비스 같은 바깥 기술 사이의 경계와 의존 방향은 애플리케이션 구조 패턴이 다룬다. 계층형, 헥사고날, 오니언, 클린 아키텍처는 이 문서에서 짧게만 소개한다. 위 주문 화면이라면 재고 규칙을 처리기에서 떼어 내는 일은 앞의 질문이고, 그 규칙이 DB 코드를 직접 부르지 않게 하는 일은 뒤의 질문이다.

두 갈래는 한 프로그램 안에서 겹친다. Robert C. Martin은 클린 아키텍처 글에서 GUI의 MVC 구조 전체가 동심원의 안쪽에서 세 번째인 인터페이스 어댑터(interface adapters) 계층에 들어간다고 적었다.¹

UI 아키텍처 패턴 비교

네 패턴은 모두 화면 코드와 그 밖의 로직을 나누어 일부를 창 없이 시험할 수 있게 하는데, 시험할 수 있는 부분은 패턴마다 다르다. 패턴끼리는 사용자 입력을 누가 먼저 받는지, 바뀐 값이 어떤 경로로 화면에 도착하는지도 다르다.

그림은 UML 커뮤니케이션 다이어그램 네 개다. 각 패널은 사용자 입력 하나가 화면 갱신에 이르기까지 일으키는 메시지에 번호를 붙여 순서대로 보여 준다. 번호의 점은 호출 중첩을 나타내서, 1.1.2는 1.1을 처리하는 중에 보낸 두 번째 메시지다. 참여 객체 이름은 각 패턴 문서의 예제에서 가져왔고, Button, TextBlock, BindingExpression(WPF)과 Html(Elm)은 프레임워크 타입이다. MVVM 패널은 예제의 콘솔 Binder 대신 WPF처럼 바인딩 엔진이 있는 경우를 그렸다. 버튼은 명령 소스로서 바인딩된 명령의 Execute를 직접 부르고,² 바인딩(BindingExpression)은 PropertyChanged를 받아 화면 값을 고칠 때만 등장한다. MVU 패널의 Render(html)는 런타임이 새 화면을 반영하는 단계에 붙인 이름이다. 각 패턴의 클래스 다이어그램과 시퀀스 다이어그램은 개별 문서에 있다.

MVC와 MVVM은 둘 다 변경 알림으로 화면을 고치지만 알림을 받는 쪽이 다르다. Smalltalk-80 MVC에서는 뷰가 모델의 의존 객체로 등록되어 모델이 바뀌면 update 메시지를 받는다.³ MVVM에서는 ViewModel이 보내는 PropertyChanged를 바인딩 엔진이 받아 뷰를 고친다.⁴ MVP의 Passive View는 알림 대신 프레젠터의 명시적 호출로 화면을 고치므로, 뷰와 모델 사이에 어느 방향으로도 의존이 없다.⁵ MVU에서는 모델의 속성 변경을 구독하는 대신, 메시지를 업데이트에 보내 새 모델을 계산한다. 상태가 바뀌는 경로가 업데이트 하나뿐이고, 화면은 새 모델이 나올 때마다 뷰 함수로 다시 계산된다.⁶

연혁

네 UI 패턴 문서의 연혁과 애플리케이션 구조 패턴의 주요 글을 합쳐 오래된 순서로 놓았다. 출처 열의 링크가 각 행의 근거다.

MVP와 MVVM은 앞선 패턴을 고치거나 특수화하며 나왔다. Potel은 MVP를 Smalltalk MVC를 일반화한 프로그래밍 모델로 소개했고, 프레젠터를 고전 Smalltalk 컨트롤러의 기능을 애플리케이션 수준으로 끌어올린 것으로 설명했다.⁷ Dolphin Smalltalk 팀이 보기에 MVC는 애플리케이션 모델과 뷰를 간접적으로만 연결했고, Windows 기본 컨트롤은 이미 컨트롤러 기능 대부분을 갖고 있었다. 그래서 팀은 동료가 알려 준 Taligent의 MVP를 채택했다.⁸ Fowler는 Presentation Model이 VisualWorks Smalltalk 사용자에게 Application Model로 알려져 있다고 적었고, 나중에 덧붙인 주에서 이 패턴이 점점 MVVM이라는 이름으로 알려지고 있다고 했다.⁹ Gossman은 MVVM을 디자이너가 XAML 같은 선언형 언어로 뷰를 만드는 환경에 맞춘 MVC의 변형으로 설명했고,¹⁰ Smith는 MVVM을 WPF와 Silverlight에 맞춘 Presentation Model의 특수화로 보았다.¹¹ MVU 쪽에서는 Redux 문서가 Elm의 updater가 Redux의 리듀서와 같은 역할을 한다고 설명하고,¹² Elm 가이드는 Redux 같은 프로젝트가 The Elm Architecture에서 영감을 받았다고 적는다.⁶

애플리케이션 구조 패턴도 서로를 언급한다. Palermo는 헥사고날 아키텍처와 오니언 아키텍처가 인프라를 바깥으로 빼고 어댑터 코드를 써서 인프라와 강하게 결합하지 않게 한다는 전제를 공유한다고 썼다.¹³ Martin의 2012년 글은 헥사고날, 오니언을 비롯한 여러 아키텍처를 나열하고, 세부는 달라도 모두 관심사 분리라는 같은 목적을 가지며 소프트웨어를 계층으로 나눠 이를 이룬다고 정리했다.¹

애플리케이션 구조 패턴

아래 네 패턴은 화면 하나보다 큰 애플리케이션 전체를 나누며, 모두 업무 규칙(도메인)이 DB, 웹 프레임워크, UI 같은 바깥 기술에 의존하는지를 묻는다.

계층형 아키텍처

계층형 아키텍처(layered architecture)는 프로그램을 표현(UI), 도메인 로직, 데이터 접근 같은 계층으로 나눈다. Fowler의 설명으로는 의존이 대체로 위에서 아래로 흘러, 표현 계층은 도메인에, 도메인은 데이터 원본에 의존한다. 그가 꼽은 이 분리의 가장 큰 이점은 세 주제를 비교적 따로 생각할 수 있어 주의의 범위가 줄어드는 데 있다. 그는 도메인이 데이터 원본에 의존하지 않도록 둘 사이에 매퍼를 두는 변형을 흔히 헥사고날 아키텍처라고 부른다고 덧붙였다.¹⁴ 그의 2002년 책 Patterns of Enterprise Application Architecture도 엔터프라이즈 애플리케이션을 계층으로 나누는 법을 주요 주제로 다룬다.¹⁵

헥사고날 아키텍처 (포트와 어댑터)

Alistair Cockburn의 Ports and Adapters 패턴(다른 이름 Hexagonal Architecture)은 애플리케이션을 사용자, 다른 프로그램, 자동 테스트, 배치 스크립트 어느 쪽에서든 똑같이 구동할 수 있게 하고, 실제 장치와 DB 없이도 개발하고 시험할 수 있게 하는 것을 목적으로 한다. 애플리케이션은 포트(port, 대화의 목적에 따라 정한 API)로 바깥과 통신하고, 바깥 장치마다 있는 어댑터가 그 API와 장치의 신호를 서로 바꾼다. 애플리케이션은 입력 장치의 성격을 모르며, Cockburn은 안쪽에 속한 코드가 바깥쪽으로 새어 나가지 않아야 한다는 규칙을 둔다. 그는 이 패턴을 어댑터 패턴의 특정한 쓰임이라고 설명했다.¹⁶

오니언 아키텍처

Jeffrey Palermo는 2008년 연재 글에서 오니언 아키텍처(Onion Architecture)를 제안했다. 가운데에 도메인 모델이 있고, 그 바로 바깥 층에 객체를 저장하고 꺼내는 리포지토리 인터페이스가 있으며(리포지토리 패턴), 가장 바깥에 UI, 인프라, 테스트가 있다. 코드는 더 안쪽 층에만 의존할 수 있고 바깥 층에는 의존할 수 없다. 즉 모든 결합이 중심을 향한다.¹³ Palermo는 각 층이 아래층과 인프라에 결합하는 전통적인 계층형과의 차이를 이 방향으로 설명했고, 안쪽 층이 인터페이스를 정의하고 바깥 층이 구현한다는 점을 주요 원칙으로 꼽았다.¹³¹⁷

클린 아키텍처

Robert C. Martin의 2012년 글 "The Clean Architecture"는 헥사고날, 오니언 등 여러 아키텍처를 하나의 실행 가능한 생각으로 합치려 한 그림을 제시했다. 동심원은 안쪽부터 엔티티(entities), 유스케이스(use cases), 인터페이스 어댑터, 프레임워크와 드라이버이고, 의존 규칙(Dependency Rule)은 소스 코드 의존이 안쪽으로만 향할 수 있다는 것이다. 유스케이스가 바깥의 프레젠터에 결과를 넘겨야 할 때는 안쪽 원에 둔 인터페이스(출력 포트)를 부르고 프레젠터가 그것을 구현하게 해, 제어 흐름과 반대 방향으로 의존을 둔다.¹ 같은 제목의 책은 2017년 Prentice Hall에서 나왔다.¹⁸

고르는 기준

UI 패턴은 쓰는 UI 기술이 먼저 정해 주는 경우가 많다. WPF처럼 데이터 바인딩을 중심으로 만든 프레임워크에서는 MVVM이 도구 지원을 받기 쉽고,¹⁹ Elm의 표준 브라우저 프로그램 API는 모델·뷰·업데이트를 연결하는 구조를 제공한다.¹² 아래 표는 문제가 보일 때 먼저 읽을 문서를 고르는 안내다.

남용 신호

• 입력 칸 두 개짜리 폼에 MVVM을 얹고 ViewModel, 명령 클래스, 바인딩 설정을 모두 만든다. Gossman도 단순한 UI에는 MVVM이 과할 수 있다고 적었다.²⁰

• 규칙이 거의 없는 화면마다 뷰 인터페이스, 뷰 구현, 프레젠터를 만든다. Esposito는 MVP가 애플리케이션 코드의 복잡도를 높인다고 적었다.²¹

• 입력 하나, 출력 하나인 화면을 모델, 뷰, 컨트롤러 세 클래스로 나눈다.

• 상태가 거의 없는 화면에 메시지 목록과 런타임 루프를 만든다.

• CRUD 화면 몇 개짜리 프로그램에 엔티티, 유스케이스, 인터페이스 어댑터, 프레임워크 네 겹을 그대로 쌓는다. Palermo는 오니언 아키텍처가 작은 웹사이트에는 맞지 않는다고 했고,¹³ Martin도 원이 꼭 네 개일 필요는 없다고 적었다.¹

• DB를 바꿀 계획이 없는데 교체를 이유로 저장소 앞에 포트와 어댑터를 여러 겹 둔다. Fowler는 데이터 접근 교체가 데이터 계층을 나누는 이유로 자주 거론되지만 실제로 교체했다는 이야기는 드물게 듣는다고 적었다.¹⁴

같이 보기

• MVC 패턴

• MVP 패턴

• MVVM 패턴

• MVU 패턴

• 프로그래밍 패턴

• 옵서버 패턴

• 어댑터 패턴

• 리포지토리 패턴