아키텍처 양식

아키텍처 양식은 시스템을 어떤 덩어리로 나누고 어떻게 이을지를 규칙 몇 개로 정해 줍니다. 레이어드나 마이크로서비스가 이런 양식의 이름입니다. 양식을 고르면 시스템의 큰 모양이 먼저 정해집니다. 그 모양이 무엇을 쉽게 만들고 무엇을 어렵게 만들지도 함께 정해집니다.

쉽고 빠른 이해

아키텍처 양식은 시스템을 나누고 잇는 규칙 몇 개를 한 이름으로 묶어 줍니다. 레이어드라고 하면 「코드를 위아래 계층으로 나눈다. 위 계층은 바로 아래 계층만 부른다」가 한꺼번에 전해집니다.

규칙 없이 코드를 붙여 나가면 아무 코드나 아무 코드를 부르게 됩니다. 그러면 한 곳을 고칠 때 어디가 깨질지 알 수 없습니다. 구조를 설명할 때마다 그림을 처음부터 그려야 하기도 합니다.

1. 시스템을 무엇으로 나눌지 정합니다. 계층으로 나눌 수도 있습니다. 서비스로 나눌 수도 있습니다
2. 나눈 덩어리끼리 무엇으로 이을지 정합니다. 함수 호출이나 네트워크 요청이나 메시지입니다
3. 해서는 안 되는 연결을 정합니다. 양식의 성격은 대부분 이 금지에서 나옵니다

대가는 줄어드는 자유입니다. 금지된 연결이 가장 짧은 길일 때도 돌아가야 합니다. 시스템에 안 맞는 양식을 고르면 그 돌아가는 품이 날마다 듭니다.

그래서 며칠 쓰고 버릴 작은 코드에는 양식이 필요 없습니다. 코드가 자라고 사람이 늘어날수록 양식의 값이 커집니다.

상세

집을 지을 때 「한옥으로 짓자」고 정하면 설계도를 그리기 전에 많은 것이 정해집니다. 나무로 기둥을 세웁니다. 지붕에는 기와를 얹습니다. 한옥이라는 한 낱말이 수십 가지 결정을 대신 말해 줍니다.

소프트웨어 아키텍처는 시스템을 이루는 큰 덩어리와 그 덩어리들 사이의 관계를 말합니다. 아키텍처 양식은 그 덩어리와 관계를 어떤 모양으로 짤지 미리 정해 둔 규칙 묶음입니다. 영어 architectural style 을 옮긴 말이라 아키텍처 스타일이라고도 부릅니다.

양식의 이름은 팀 안에서 줄임말 노릇을 합니다. 「이 서비스는 레이어드로 갑니다」 한 문장이 코드를 어디에 둘지에 관한 규칙 여러 개를 한꺼번에 전합니다. 이름이 없으면 구조를 설명할 때마다 그림을 처음부터 그려야 합니다.

이 절은 먼저 양식 하나가 무엇을 정하는지 세 가지로 나눠 봅니다. 그다음 흔한 양식 다섯을 같은 세 칸에 넣어 견줍니다. 끝으로 여러 양식이 한 시스템 안에서 어떻게 겹치는지와 언제 양식을 고르는지를 봅니다.

양식이 정하는 세 가지

첫째는 시스템을 무엇으로 나누느냐입니다. 나눈 덩어리 하나를 구성 요소라고 부릅니다. 계층 하나, 서비스 하나, 데이터를 거르는 단계 하나가 모두 구성 요소가 될 수 있습니다. 이 낱말이 있어야 서로 다른 양식을 같은 말로 견줄 수 있습니다.

둘째는 덩어리끼리 무엇으로 잇느냐입니다. 같은 프로그램 안에서 함수를 부를 수 있습니다. 네트워크 너머로 요청을 보낼 수도 있습니다. 메시지를 남겨 두고 상대가 나중에 가져가게 할 수도 있습니다. 어느 연결을 쓰느냐에 따라 느려지는 곳과 깨지는 곳이 달라집니다.

셋째는 무엇을 하면 안 되느냐입니다. 이 금지를 제약이라고 부릅니다. 「아래 계층은 위 계층을 부르지 않는다」가 제약의 예입니다. 양식의 성격은 대부분 이 금지에서 나옵니다.

흔한 양식 다섯

아래 표는 흔히 쓰는 양식 다섯을 앞의 세 칸에 넣은 것입니다. 이벤트 주도 줄의 이벤트는 「주문이 들어왔다」처럼 이미 일어난 일을 알리는 메시지입니다.

다섯 줄이 모두 같은 세 물음에 답합니다. 양식의 성격을 가장 잘 드러내는 칸은 마지막 칸입니다. 잇는 방법이 비슷해도 제약이 다르면 다른 양식이 됩니다. 클라이언트-서버와 마이크로서비스는 둘 다 네트워크 요청으로 잇습니다. 그래도 제약이 서로 달라서 다른 양식입니다.

이벤트 주도 줄의 메시지 브로커는 이벤트를 받아 두었다가 받을 쪽에 나눠 주는 중간 프로그램입니다. 내는 쪽은 브로커에만 이벤트를 넘깁니다. 그래서 누가 받는지 몰라도 됩니다.

제약이 주는 성질

제약은 자유를 덜어 내는 대신 성질 하나를 줍니다. 레이어드로 짠 코드는 흔히 요청 받기 계층, 업무 규칙 계층, 저장 계층을 차례로 쌓습니다. 저장 계층은 누가 자기를 부르는지 모릅니다. 그래서 요청을 받는 방식을 바꿔도 저장 계층은 손대지 않아도 됩니다.

이벤트 주도도 같은 식입니다. 주문을 처리하는 코드는 이벤트를 브로커에 넘기면 제 일이 끝납니다. 결제와 배송은 그 이벤트를 각자 받아 처리합니다. 이벤트를 받는 쪽을 하나 더 붙여도 주문 코드는 바뀌지 않습니다.

이렇게 기능과 따로 「얼마나 잘 되나」를 재는 성질을 품질 속성이라고 부릅니다. 바꾸기 쉬움, 늘어난 요청을 버티는 확장성, 멈추지 않고 응답하는 가용성이 여기에 듭니다. 기능이 같아도 품질 속성은 양식에 따라 달라집니다.

같은 제약이 대가도 만듭니다. 레이어드에서 요청 받기 계층이 저장 계층의 값 하나만 필요해도 업무 규칙 계층을 거쳐야 합니다. 금지된 연결이 가장 짧은 길일 때도 돌아가야 한다는 뜻입니다.

이벤트 주도에서는 내는 쪽이 받는 쪽을 모릅니다. 그만큼 일 하나가 어디까지 처리됐는지 한 곳에서 보기 어렵습니다.

한 시스템에 겹치는 양식

양식 하나가 시스템 전체를 덮는 일은 드뭅니다. 크기가 다른 구성 요소마다 다른 양식을 씁니다. 아래 그림은 두 서비스로 나눈 시스템 하나에 양식 셋이 겹친 모양입니다.

flowchart TD
    subgraph OS["주문 서비스 · 안쪽은 레이어드"]
        O1["요청 받기 계층"] --> O2["업무 규칙 계층"] --> O3["저장 계층"]
    end
    subgraph DS["배송 서비스 · 안쪽은 레이어드"]
        D1["요청 받기 계층"] --> D2["업무 규칙 계층"] --> D3["저장 계층"]
    end
    OS -->|"주문 들어옴 이벤트 · 이벤트 주도"| MB["메시지 브로커"]
    MB --> DS

가장 큰 크기에서는 배포 단위를 정합니다. 배포 단위는 한 번에 함께 내보내는 코드 묶음입니다. 그림처럼 서비스마다 따로 배포하면 마이크로서비스입니다.

시스템 전체를 프로그램 하나로 배포하면 모놀리스입니다. 코드가 한 프로그램 안에 있으니 어느 코드든 다른 코드를 바로 부를 수 있습니다.

모듈러 모놀리스도 프로그램 하나로 배포합니다. 다른 점은 그 안을 기능별 모듈로 나눈다는 것입니다. 모듈끼리는 정해 둔 입구로만 부릅니다.

한 배포 단위의 안쪽은 또 다른 양식으로 나눕니다. 그림의 두 서비스는 안쪽을 레이어드로 짰습니다. 업무 규칙을 가운데 두고 데이터베이스 같은 바깥 기술을 둘레에 붙이는 헥사고날로 짤 수도 있습니다.

서비스 사이를 잇는 방식도 양식입니다. 주문 서비스가 「주문 들어옴」 이벤트를 내면 배송 서비스가 받아 갑니다. 이 둘 사이는 이벤트 주도입니다. 한 시스템을 두고 마이크로서비스이자 레이어드이자 이벤트 주도라고 말해도 모순이 아닌 까닭입니다.

디자인 패턴과 다루는 크기

아키텍처 양식과 자주 헷갈리는 말이 디자인 패턴입니다. 디자인 패턴은 클래스 몇 개 사이에서 되풀이되는 문제를 푸는 이름 붙은 해법입니다. 양식은 시스템 전체의 모양을 정합니다. 둘은 다루는 크기가 다릅니다.

아키텍처 패턴이라는 말도 있습니다. 양식과 거의 같은 뜻으로 섞어 쓰는 경우가 많습니다. 둘을 구별해 쓰는 사람들은 양식을 모양 전체의 규칙으로 봅니다. 아키텍처 패턴은 문제 하나에 대한 해법으로 봅니다. 그래서 같은 레이어드가 양식으로도, 패턴으로도 불립니다.

양식을 고르는 때

먼저 이 시스템에 무엇이 가장 중요한지 정합니다. 기능을 자주 바꿔야 하는지 봅니다. 요청이 갑자기 몰리는지, 팀 여럿이 따로 배포해야 하는지도 봅니다. 그 품질 속성을 주는 제약을 가진 양식을 고릅니다.

시스템에 안 맞는 양식을 고르면 제약을 돌아가는 품이 날마다 듭니다. 데이터를 넣고 꺼내기만 하는 작은 기능을 서비스 여럿으로 쪼개면 네트워크 호출만 늘어납니다.

양식이 늘 필요한 것도 아닙니다. 한 사람이 며칠 쓰고 버릴 스크립트라면 규칙을 세우는 품이 얻는 것보다 큽니다. 코드가 자라고 사람이 늘어날수록 양식의 값이 커집니다.

어떤 양식도 따르지 않고 자란 구조를 흔히 큰 진흙 공(Big Ball of Mud)이라고 부릅니다. 아무 덩어리가 아무 덩어리를 부르는 상태입니다. 이렇게 되면 한 곳을 고칠 때 어디가 깨질지 미리 알 수 없습니다.

양식의 이름만 따르고 제약을 안 지키는 경우도 있습니다. 서비스를 여럿으로 나눴는데 모두 한 데이터베이스를 같이 쓰면 마이크로서비스의 제약을 어긴 것입니다. 이런 구조를 분산 모놀리스라고 부릅니다. 따로 배포한다는 이점은 사라집니다. 네트워크 호출의 비용은 남습니다.

관련 항목

아키텍처 양식이 속하는 상위 분류

소프트웨어 아키텍처 · 시스템 설계 · 소프트웨어 설계 · 소프트웨어 공학

아키텍처 양식의 하위 종류

레이어드 · 헥사고날 · 클린 아키텍처 · 파이프-필터 · 클라이언트-서버 · 이벤트 주도 · 발행-구독 · 마이크로서비스 · 모놀리스 · 모듈러 모놀리스 · 서비스 지향 아키텍처 · 마이크로커널 · REST · 서버리스 · CQRS · 피어 투 피어

아키텍처 양식을 이루는 요소

컴포넌트 · 커넥터 · 인터페이스 · 계층 · 메시지 브로커 · 이벤트

아키텍처 양식이 겨냥하는 품질 속성

품질 속성 · 결합도 · 응집도 · 관심사 분리 · 확장성 · 가용성 · 바꾸기 쉬움 · 성능

아키텍처 양식과 크기가 다른 설계 개념

디자인 패턴 · 아키텍처 패턴 · 참조 아키텍처 · 프레임워크

양식을 어긴 구조를 가리키는 이름

큰 진흙 공 · 분산 모놀리스 · 순환 의존 · 신 객체 · 기술 부채

아키텍처 양식을 기록하는 문서 형식

아키텍처 결정 기록 · 아키텍처 기술 · C4 모델 · 4+1 뷰