소프트웨어 아키텍처 패턴

아키텍처 패턴이란

아키텍처 패턴은 시스템의 큰 덩어리를 어떻게 나누고, 덩어리끼리 어떻게 대화하게 할지에 대한 검증된 틀이다. 클래스 수준의 디자인 패턴보다 한 단계 위에서 시스템 전체의 모양을 정한다.

패턴은 정답이 아니라 트레이드오프의 묶음이다. 어떤 패턴이든 무언가를 쉽게 만드는 대신 다른 무언가를 어렵게 만든다.

여섯 가지 패턴 비교

마이크로서비스는 마이크로서비스 아키텍처에서 자세히 다룬다.

클라우드 아키텍처 스타일

위 표가 코드와 모듈의 모양이라면, 클라우드 쪽에서는 배포 단위와 통신 방식까지 묶어 「아키텍처 스타일」이라 부른다. 스타일은 특정 기술을 요구하지 않지만 잘 맞는 기술은 있다(마이크로서비스와 컨테이너처럼).

N계층: 논리 층과 물리 티어

N계층에서 층(layer) 은 책임을 나누는 논리 단위이고, 티어(tier) 는 따로 떨어진 기계에서 도는 물리 단위다. 위층은 아래층을 쓰지만 반대 방향은 안 된다. 층마다 티어를 따로 둘 필요는 없어 여러 층이 한 티어에 함께 살 수 있다. 티어를 물리적으로 떼면 따로 늘리고 한 티어의 장애를 가둘 수 있지만, 티어 사이 네트워크 왕복만큼 지연이 붙는다. 티어끼리는 직접 호출하거나 비동기 메시지로 잇는다.

티어를 나누면 가용성이 오르고, 티어 경계가 방화벽처럼 동작해 보안이 좋아지며, 티어마다 따로 늘리고 다른 사람이 관리할 수 있다. 대신 전체 복잡도와 티어 수만큼의 지연, 티어마다의 장비 비용이 늘고 티어 사이 네트워크 보안 관리가 어려워진다. DBMS의 1·2·3계층 구조는 데이터베이스 모델에 있다.

헥사고날 아키텍처의 모양

flowchart TB
  rest["REST 어댑터"] --> inp
  cli["CLI 어댑터"] --> inp
  subgraph core["도메인 핵심 (프레임워크·DB를 모른다)"]
    inp["입력 포트(유스케이스)"]
    out["출력 포트(저장소 인터페이스)"]
    inp ~~~ out
  end
  out --- pg["PostgreSQL 어댑터"]
  out --- pay["외부 결제 API 어댑터"]

• 의존 방향은 항상 안쪽(도메인)을 향한다. 어댑터가 포트를 구현하고, 도메인은 구체 기술을 모른다.
• DB를 바꾸거나 테스트용 가짜 저장소를 끼울 때 어댑터만 갈아 끼운다.
• 클린 아키텍처, 어니언 아키텍처도 "도메인을 중심에 두고 의존을 안쪽으로"라는 같은 생각을 다르게 그린 것이다. 도메인 모델을 어떻게 짜는지는 도메인 주도 설계에 있다.

계층형과 헥사고날의 차이

스타일을 가르는 축: 구성 요소와 커넥터

위의 패턴 이름은 사람마다 다른 뜻으로 쓴다. 이름 대신 구성 요소끼리 제어와 데이터를 어떻게 주고받나로 스타일을 가르면 비교가 정확해진다(Shaw·Clements의 분류, 1997).

이 축으로 다섯 계열이 나온다. 실제 시스템은 순수형으로 나오지 않고 섞인다. 순수형을 알아야 혼합형을 설명하고, 쓸데없는 섞임을 걷어 낼 수 있다.

어떻게 고르나

문제의 모양에서 시작하는 경험칙이 있다.

• 변경이 어디서 자주 일어나는지를 본다. 외부 연동이 자주 바뀌면 헥사고날, 기능이 계속 붙으면 플러그인, 팀과 배포 단위를 나눠야 하면 마이크로서비스다.
• 처음에는 단순한 계층형 모놀리스로 시작하고, 경계가 분명해진 뒤에 나누는 편이 대개 싸다.
• 한 시스템이 여러 패턴을 섞는다. 마이크로서비스 각각의 내부는 계층형이나 헥사고날이고, 서비스 사이는 이벤트 기반일 수 있다.

정리

• 아키텍처 패턴은 시스템을 나누는 큰 틀이고, 패턴마다 얻는 것과 잃는 것이 있다.
• 계층형은 빠르게 만들기 좋지만 규칙이 무너지면 엉킨다. 이벤트 기반은 결합을 줄이지만 추적이 어렵다.
• 헥사고날은 도메인을 중심에 두고 외부를 포트와 어댑터로 떼어 내 교체와 테스트를 쉽게 한다.
• 변경이 일어나는 방향에 맞춰 패턴을 고르고, 필요해질 때 나눈다.

관련 노트: 마이크로서비스 아키텍처, 도메인 주도 설계, GoF 디자인 패턴, 웹 확장성의 구성 요소, 프론트엔드 MV* 아키텍처의 흐름