Ch19 적절한 아키텍처 스타일의 선택

한 줄 정의

적절한 아키텍처 스타일은 도메인·아키텍처 특성·조직 상황·생태계 트렌드 의 트레이드오프를 분석한 결과로 결정되며, 단일 정답은 존재하지 않습니다.

쉽게 말하면

“마이크로서비스가 좋다”, “모놀리스가 옳다” 같은 정답을 외부에서 가져올 수 있다면 편하겠지만, 그런 단정은 가능하지 않습니다.

선택은 결국 상황에 따라 달라지는 것 입니다. 도메인 특성, 시스템이 요구하는 아키텍처 특성(확장성·탄력성 등), 데이터 구조, 배포 환경(클라우드 여부), 조직의 엔지니어링 관행, 심지어 인수합병 같은 외부 사건까지 모두 고려한 끝에 가장 덜 나쁜 트레이드오프 집합을 고르는 작업입니다.

이번 장에서 강조하는 핵심은 두 가지입니다. 첫째, 아키텍처 트렌드는 끊임없이 바뀌므로 시류를 이해하되 맹목적으로 따라가지는 말아야 합니다. 둘째, 도메인의 토폴로지와 아키텍처의 토폴로지를 일치시키는 동형성(isomorphism) 관점에서 사고해야 합니다.

왜 중요한가?

• 해결하는 문제: 아키텍트가 매일같이 등장하는 신규 스타일과 패러다임 속에서 길을 잃지 않고, 자신의 맥락에 맞는 선택을 내릴 수 있도록 사고 프레임을 제공합니다.
• 이게 없다면: “요즘 다들 마이크로서비스 한다더라” 같은 유행 추종 의사결정에 빠집니다. 결합도가 높은 보험 도메인을 마이크로서비스로 쪼개거나, 단순한 사내 도구를 분산 아키텍처로 과설계하는 식의 흔한 실패 패턴이 그 결과입니다.

핵심 내용

아키텍처 ‘유행’은 끊임없이 변한다

소프트웨어 업계가 선호하는 아키텍처 스타일은 시간이 흐르면서 다음 요인들에 따라 바뀝니다.

과거 경험에서 얻은 통찰

새 스타일은 보통 직전 세대의 고충점(pain point) 에 대한 반작용으로 등장합니다. 코드 재사용에 집착했던 시기를 거친 아키텍트들이 그 부정적 트레이드오프를 깨닫고 재사용의 의미를 재고하게 된 것이 한 예입니다. 즉, 새 스타일은 보통 이전 스타일에서 발견된 결함을 해결하려는 시도입니다.

생태계의 변화

쿠버네티스가 불과 몇 년 전만 해도 알려지지 않았다가 지금은 수많은 개발자의 일상이 된 것처럼, 생태계는 예측 불가능하게 변합니다. 미묘한 차이가 생태계를 근본부터 바꾸는 신호일 수 있어, “엄청난 신기능”만이 아니라 사소한 변화도 감지해야 합니다.

새로운 역량

새 도구가 아니라 새 패러다임 이 등장하기도 합니다. 도커 같은 컨테이너의 출현은 단순한 도구 교체를 넘어 아키텍트·도구·엔지니어링 관행 전반에 지각 변동을 일으켰습니다.

가속화

생태계는 변할 뿐 아니라 그 속도가 점점 빨라집니다. 새 도구 → 새 관행 → 새 설계와 역량의 순환이 더 짧아지고 있습니다. 생성형 AI(generative AI) 는 이 끊임없는 발전과 예측 불가능성의 대표 사례입니다.

도메인의 변화

비즈니스 자체가 진화하거나 인수합병으로 시스템 경계가 바뀝니다. 어제까지의 도메인 지도가 오늘 무효가 될 수 있습니다.

기술의 변화

수익에 직결되는 기술 변화에는 조직이 적극적으로 따라붙으려 합니다. 결제·보안·관측 같은 영역이 특히 그렇습니다.

외부 요인

라이선스 비용, 공급업체 정책, 규제 같은 간접 요인이 의외로 큰 결정 압력을 만듭니다. 만족스럽게 쓰던 도구의 라이선스가 비싸지면 다른 대안으로 옮길 수밖에 없습니다.

트렌드를 이해해야 하는 이유

아키텍트가 트렌드를 따라야 하기 때문이 아니라, 언제 따르고 언제 예외를 둘지 현명하게 결정하기 위해서입니다.

결정의 기준들

스타일 선택은 다음 요인들을 충분히 이해한 뒤에 시도해야 합니다.

도메인

비즈니스 도메인의 핵심 측면, 특히 운영 아키텍처 특성에 영향을 주는 측면을 이해해야 합니다. 도메인 전문가일 필요는 없지만 주요 측면은 전체적으로 파악하고 있어야 하며, 부족한 부분은 비즈니스 분석가 등 다른 전문가의 도움으로 채울 수 있습니다.

구조적 결정에 영향을 미치는 아키텍처 특성

스타일 선택의 핵심 활동은 아키텍처 특성 분석(architectural characteristics analysis) 입니다. 도메인과 외부 요인이 요구하는 특성을 식별하고 어떤 스타일이 그 특성들을 잘 지원하는지 본질적으로 평가해야 합니다.

거의 모든 도메인은 어떤 범용 스타일로도 구현할 수 있습니다. 범용(generic) 이라는 말은 결국 다목적이라는 뜻입니다. 따라서 진정한 차별화 지점은 “어떤 도메인이냐”가 아니라 그 도메인이 요구하는 아키텍처 특성들을 얼마나 잘 지원하느냐 에 있습니다.

데이터 아키텍처

데이터 아키텍처는 별도 전문 분야이므로 별도 협업이 필요합니다. 다만 아키텍트는 주어진 데이터 설계가 아키텍처 설계에 미칠 영향을 이해해야 합니다. 특히 신규 시스템이 레거시 데이터 아키텍처 와 상호작용해야 하는 경우 더 그렇습니다. 새 마이크로서비스를 설계하면서 30년 된 메인프레임 DB와 통신해야 하는 상황이 흔한 예입니다.

클라우드 배포

요즘 아키텍처는 클라우드가 종착지인 경우가 많고, 온프레미스용 설계와 클라우드용 설계의 트레이드오프는 사뭇 다릅니다. 데이터 저장량과 이동량(상당한 비용 발생 가능)을 파악해야 합니다.

또한 클라우드는 정교한 기능이 시간이 지나면 일상재(commodity) 로 변하는 좋은 예입니다. 10년 전만 해도 마법처럼 보였던 고탄력성·고확장성 시스템이, 이제는 클라우드 제공업체의 구성 매개변수 변경만으로 동일한 결과를 얻을 수 있습니다.

조직 요인

특정 클라우드 공급업체의 비용 문제로 이상적 설계를 채택할 수 없거나, 회사가 인수합병을 계획 중이라는 사실 때문에 개방형 솔루션·통합 아키텍처 쪽으로 마음이 기울 수 있습니다.

프로세스·팀·운영상 관심사에 관한 지식

조직이 애자일 엔지니어링 관행에 익숙하지 않다면 그런 관행을 잘 따라야 성공하는 스타일(마이크로서비스 등)은 적용하기 어렵습니다. 즉, 스타일 선택은 기술적 적합성뿐 아니라 조직의 역량 적합성 까지 평가해야 합니다.

도메인/아키텍처 동형성

아키텍처 동형성(isomorphism) 은 아키텍처의 전반적인 형태, 즉 토폴로지 내에서 구성요소들이 서로 어떻게 의존하는지를 나타냅니다. 어원은 그리스어 isos(같다) + morph(형태)로, “집합 원소들 사이의 관계를 보존하는 사상(mapping)“입니다.

같은 모놀리스라도 계층형과 모듈형의 동형성은 명확히 다릅니다.

graph LR
    subgraph 모듈형["모듈형 모놀리스"]
        direction LR
        D1[주문]
        D2[결제]
        D3[배송]
        D4[재고]
    end
    subgraph 계층형["계층형 모놀리스"]
        direction TB
        L1[표현 계층]
        L2[비즈니스 계층]
        L3[영속성 계층]
        L1 --- L2
        L2 --- L3
    end
    모듈형 ~~~ 계층형

분산 아키텍처도 마찬가지입니다.

graph LR
    subgraph 모놀리스["모놀리스"]
        direction TB
        M1[ ]
        M2[ ]
    end
    subgraph 분산["분산"]
        direction LR
        S1[ ] --- S2[ ]
        S2 --- S3[ ]
        S3 --- S4[ ]
        S1 --- S4[ ]
    end
    모놀리스 ~~~ 분산

동형성 관점의 매칭과 미스매치

도메인 토폴로지와 아키텍처 토폴로지가 잘 맞는 경우와 안 맞는 경우가 있습니다.

도메인 특성	잘 맞는 스타일	이유
맞춤성(customizability) 필요	마이크로커널	사용자 정의 기능을 플러그인으로 설계
개별 연산 다수 수행	공간 기반	다수의 개별 처리기 제공
의미론적 결합이 큰 도메인 (예: 다중 페이지 보험 양식)	분산보다는 서비스 기반	의도적으로 결합된 아키텍처가 적합
확장성이 매우 높은 시스템	마이크로서비스/공간 기반	거대한 모놀리스로는 동시 사용자 지원 어려움
결합도가 높은 코드베이스	모놀리스 계열	분산으로 쪼개면 통신 비용·복잡도 폭증

핵심은 도메인의 결합 양상과 아키텍처의 결합 양상을 일치시키는 것 입니다. 의미론적 결합이 큰 도메인을 마이크로서비스로 쪼개려는 시도는 동형성 미스매치의 전형입니다.

아키텍트가 결정해야 할 사항들

위 요인들을 고려한 끝에 정리해야 할 결정 사항은 다음과 같습니다.

모놀리스 대 분산

시스템 전체에 하나의 아키텍처 특성 집합으로 충분한가, 아니면 부분마다 다른 특성이 필요한가? 단일 집합이면 모놀리스, 서로 다른 집합이 필요하면 분산이 후보가 됩니다. 이 결정에는 아키텍처 퀀텀 개념이 핵심 도구가 됩니다.

데이터는 어디에 둘 것인가

모놀리스에서는 보통 관계형 DB 하나로 끝나지만, 분산에서는 어떤 서비스가 어떤 데이터를 영속화할지를 결정해야 합니다. 이를 위해 작업흐름과 데이터 흐름을 함께 설계해야 하며, 더 나은 조합을 찾기 위해 설계를 반복하는 것을 두려워하지 말아야 합니다.

서비스 간 통신은 동기적인가, 비동기인가

기본적으로 동기 통신이 설계·구현·디버깅이 쉬우므로 동기를 기본으로, 필요할 때만 비동기 를 사용하는 것이 권장됩니다. 비동기는 성능·규모 면에서 이점이 있지만 데이터 동기화·교착 상태·경쟁 조건·디버깅에서 많은 골칫거리를 유발합니다.

통신 방식의 기본 원칙

기본적으로 동기적 통신을 사용하고, 필요할 때만 비동기 통신을 사용하라.

설계 과정의 산출물

설계 과정의 결과물은 크게 세 가지입니다.

1. 선택된 아키텍처 스타일과 관련 혼합 스타일을 포함한 아키텍처 토폴로지
2. 설계 부분에 대한 아키텍처적 결정 기록(ADR)
3. 중요한 원칙과 운영 아키텍처 특성을 보호하는 아키텍처 적합성 함수

이 중 ADR 작성에 가장 많은 노력이 들어갑니다.

모놀리스 사례 연구: 실리콘 샌드위치

제5장의 실리콘 샌드위치 카타에서는 단일 퀀텀으로 충분하다고 판단했습니다. 예산이 적고 애플리케이션이 비교적 단순했기 때문입니다. 이를 두 가지 모놀리스 스타일로 구체화한 사례입니다.

모듈형 모놀리스 구현

도메인 중심 컴포넌트들을 단일 DB와 함께 구축해 단일 퀀텀으로 배포합니다.

graph TB
    UI[사용자 인터페이스]
    subgraph App["단일 배포 단위"]
        Override[Override<br/>레시피·재고·판촉행사·위치]
        Purchase[Purchase<br/>주문·결제]
        Promotion[Promotion<br/>공통·매장별]
        MakeOrder[MakeOrder<br/>제품]
        Deliver[Deliver<br/>주소]
        ManageInv[ManageInventory<br/>공통·매장별]
        Recipes[Recipes<br/>공통·매장별]
        Location[Location<br/>공통·매장별]
    end
    DB[(데이터베이스)]
    UI --- App
    App --- DB

식별된 각 도메인이 하나의 컴포넌트로 표현되고 단일 관계형 DB를 공유합니다. 시간과 자원이 충분하다면 테이블도 도메인 컴포넌트와 동일한 방식으로 분리해두면 좋습니다. 그래야 향후 분산 아키텍처로 마이그레이션하기가 훨씬 쉬워집니다.

모듈형 모놀리스에는 커스터마이징을 위한 장치가 없으므로, 도메인 설계의 일부로 Override 종단점을 만들어 개별 커스터마이징을 처리합니다. 모든 도메인 컴포넌트의 모든 커스터마이징 가능 기능이 Override 컴포넌트를 참조하도록 보장해야 합니다(이 부분은 아키텍처 적합성 함수를 적용하기에 안성맞춤입니다).

마이크로커널 구현

마이크로커널은 고도의 맞춤성 요구를 도메인/아키텍처 동형성 관점에서 잘 풀어냅니다.

graph TB
    subgraph Clients
        iOS
        Android[안드로이드]
        Web[웹]
    end
    API[API 계층<br/>BFF 어댑터들]
    subgraph Core["코어 시스템"]
        Common[Common<br/>레시피·재고·판촉행사·위치]
        Purchase[Purchase<br/>주문·결제]
        Local[Local<br/>레시피·재고·판촉행사·위치]
        Deliver[Deliver<br/>주소]
    end
    DB1[(공통 DB)]
    DB2[(매장별 DB)]
    Clients --- API
    API --- Core
    Common --- DB1
    Local --- DB2

설계의 두 가지 핵심 특징입니다.

• 플러그인 분리: 공통적인 것들은 단일 플러그인 집합과 그에 상응하는 DB로, 매장별 플러그인은 각자 자체 데이터를 가집니다. 플러그인끼리 결합될 필요가 없으므로 분리된 상태를 유지할 수 있습니다.
• 얇은 마이크로커널 어댑터(API 계층): 프런트엔드용 백엔드(Backends for Frontends, BFF) 패턴에 해당합니다. iOS용 BFF, 안드로이드용 BFF, 웹용 BFF가 각각 백엔드 출력을 받아 자기 클라이언트에 맞게 데이터 형식·페이지네이션·지연 시간을 변환합니다. 이렇게 하면 풍부한 사용자 경험을 만들면서도 새 기기 추가 시 새 BFF만 붙이면 됩니다(마이크로커널 스타일의 장점).

내부 통신은 그냥 동기 통신을 씁니다. 극단적인 성능·탄력성 요구가 없기 때문입니다.

분산 사례 연구: 고잉, 고잉, 곤(GGG)

제8장의 GGG 카타는 부분별로 서로 다른 특성을 요구합니다. 예를 들어 경매사(auctioneer) 와 입찰자(bidder) 는 가용성·확장성 요구가 서로 다릅니다.

GGG는 규모·탄력성·성능 등 다루기 까다로운 운영 특성에 대담한 기대치가 명시되어 있습니다. 이를 충족하려면 커스텀화를 높은 세분도와 자유도로 지원하는 패턴이 필요합니다. 후보는 저수준 이벤트 주도 아키텍처 와 마이크로서비스 두 가지인데, 마이크로서비스가 운영 특성 간 편차를 더 잘 지원합니다.

순수 이벤트 주도 아키텍처가 후보에서 빠진 이유

순수 이벤트 주도는 보통 아키텍처 특성이 아니라 오케스트레이션 vs 코레오그래피 통신 방식에 따라 컴포넌트를 분리합니다. 즉, 분리 기준 자체가 GGG가 요구하는 “특성별 편차”와 어긋납니다.

마이크로서비스는 본질적으로 높은 확장성을 제공하지만 과도한 오케스트레이션이나 데이터 분리 등으로 성능 문제를 일으킬 수 있으므로 설계 시 보완 방법을 고민해야 합니다.

식별된 서비스

서비스	역할	특이사항
Bid Capture	온라인 입찰자 입력을 비동기로 Bid Tracker에 전송	통로 역할이라 영속성 불필요
Bid Streamer	입찰 내역을 온라인 참가자에게 다시 스트리밍	고성능 읽기 전용
Bid Tracker	Auctioneer Capture와 Bid Capture의 입찰을 통합·정렬	들어오는 연결은 모두 비동기, 메시지 대기열을 버퍼로 사용
Auctioneer Capture	경매사를 위한 입찰 캡처	Bid Capture와 아키텍처 특성이 달라 분리
Auction Session	개별 경매의 작업흐름 관리
Payment	결제 정보 처리(서드파티)
Video Capture	라이브 경매 동영상 스트림 캡처
Video Streamer	경매 동영상을 입찰자에게 스트리밍

통신 방식

비동기 통신을 선택한 이유는 서비스마다 다른 운영 아키텍처 특성을 수용 하기 위함입니다. 예를 들어 Payment 서비스가 결제 하나에 500ms가 걸리는데 경매가 동시에 종료되면, 동기 통신은 시간만료(timeout) 등 안정성 문제를 일으킵니다. 메시지 대기열은 아키텍처에서 중요하지만 취약한 부분에 안정성을 더해줍니다.

식별된 다섯 개의 퀀텀

graph TB
    subgraph Q1["퀀텀 1: 결제"]
        Payment
    end
    subgraph Q2["퀀텀 2: 경매 진행"]
        AuctionSession[Auction Session]
        AuctioneerCapture[Auctioneer Capture]
        BidTracker[Bid Tracker]
    end
    subgraph Q3["퀀텀 3: 입찰자"]
        BidCapture[Bid Capture]
    end
    subgraph Q4["퀀텀 4: 입찰자 스트리밍"]
        VideoCapture[Video Capture]
        VideoStreamer[Video Streamer]
    end
    subgraph Q5["퀀텀 5: 입찰 추적"]
        BidStreamer[Bid Streamer]
    end

시스템 서비스들은 결제, 경매 진행, 입찰자, 입찰자 스트리밍, 입찰 추적의 다섯 가지 퀀텀으로 구분됩니다. 각 서비스를 감싼 상자가 여러 개 겹쳐 있는 것은 다중 인스턴스로 실행될 수 있음을 나타냅니다.

컴포넌트 설계 단계에서의 퀀텀 분석 덕분에 서비스·데이터·통신 경계를 더 쉽게 식별할 수 있었습니다.

이 설계는 "정답"이 아니다

이것이 GGG의 유일한 설계도, 최선의 설계도 아닙니다. 단지 ‘가장 덜 나쁜’ 트레이드오프들의 집합 일 뿐입니다. 이 아키텍처는 마이크로서비스 패턴 위에서 이벤트와 메시지를 현명하게 사용해 범용 아키텍처 패턴의 장점을 최대한 활용하고, 향후 개발과 확장을 위한 토대를 마련합니다.

비교 / 트레이드오프

모놀리스 vs 분산 결정 트리(요약)

flowchart TD
    Start[스타일 선택 시작] --> Q1{단일 아키텍처<br/>특성 집합으로 충분?}
    Q1 -->|Yes| Q2{커스터마이징 필요?}
    Q1 -->|No| Q3{도메인 결합도<br/>높은가?}
    Q2 -->|Yes| MK[마이크로커널]
    Q2 -->|No| Q4{도메인 분리<br/>명확?}
    Q4 -->|Yes| MM[모듈형 모놀리스]
    Q4 -->|No| L[계층형]
    Q3 -->|Yes| SB[서비스 기반]
    Q3 -->|No| Q5{운영 특성<br/>편차 큼?}
    Q5 -->|Yes| MS[마이크로서비스]
    Q5 -->|No| EDA[이벤트 주도]

두 사례의 핵심 차이

관점	실리콘 샌드위치	고잉, 고잉, 곤(GGG)
단일 특성 집합	충분 → 모놀리스	부족 → 분산
핵심 요구	단순함·낮은 비용·맞춤성	규모·탄력성·성능, 서비스별 편차
통신	동기	비동기
데이터	단일/이중 RDB	서비스별 분리
결과	모듈형 모놀리스 또는 마이크로커널	마이크로서비스 5개 퀀텀

내 생각

동형성이 가장 강력한 도구

이번 장의 이론들 중 도메인/아키텍처 동형성 이 실무에서 가장 자주 써먹게 되는 사고 도구라고 봅니다. “이 도메인을 마이크로서비스로 쪼갤 수 있는가?”라는 질문은 실은 “이 도메인의 결합 양상이 분산 아키텍처의 결합 양상과 동형인가?”라는 질문이고, 후자로 바꿔 묻는 순간 답이 명확해지는 경우가 많습니다.

다중 페이지 보험 양식 같은 의미론적 결합이 큰 도메인을 본 적이 있다면, “이건 마이크로서비스로 쪼개면 DB 트랜잭션·페이지 간 상태 공유에서 비용이 폭발하겠다”는 직관이 자연스럽게 나옵니다. 동형성 개념은 그 직관을 명시적 언어로 만들어 줍니다.

”모놀리스부터 시작하라”는 격언의 근거

마틴 파울러의 “모놀리스 우선(Monolith First)” 주장이 이 장의 결정 기준과 잘 맞아떨어집니다. 초기 도메인 경계가 불확실한 상황에서 모듈형 모놀리스로 시작해 도메인이 안정화되면 분산으로 마이그레이션하는 전략은, 실제로 “테이블도 도메인별로 분리해두면 마이그레이션이 쉬워진다”는 책의 조언과 정확히 같은 맥락입니다.

스타트업 초기에 마이크로서비스로 시작했다가 도메인 경계가 자주 바뀌면서 서비스 통합·재분리를 반복하는 케이스를 종종 봅니다. 이때의 비용을 동형성 관점에서 보면 “도메인이 아직 안 굳었는데 분산 토폴로지로 박제했기 때문”이라고 설명할 수 있습니다.

”가장 덜 나쁜” 트레이드오프

GGG 사례의 결론 문장 “최선의 설계가 아니라 가장 덜 나쁜 트레이드오프들의 집합”이 이 책 전체의 본질을 압축합니다. 아키텍처 설계는 이상을 추구하는 일이 아니라 여러 나쁜 옵션 중 덜 나쁜 것을 고르는 일 이고, 그 선택을 ADR로 명시적으로 기록해 미래의 자신과 팀이 이유를 추적할 수 있게 만드는 일입니다.

더 알아볼 것

• Ch20 아키텍처 패턴 — 스타일 선택 후 적용할 패턴들
• Ch21 ADR(아키텍처적 결정 기록) — 산출물 중 가장 노력이 많이 드는 부분
• Ch22 위험 분석·리스크스토밍 — 선택한 스타일의 리스크 평가
• BFF(Backends for Frontends) 패턴 심화
• 모놀리스 → 마이크로서비스 마이그레이션 전략(Strangler Fig 패턴)

관련 개념

• 아키텍처 퀀텀 — 모놀리스/분산 결정의 핵심 도구
• 모듈형 모놀리스 — 사례 1의 모놀리스 옵션
• 마이크로커널 — 사례 1의 커스터마이징 옵션
• 이벤트 주도 아키텍처 — 사례 2에서 후보로 검토
• 마이크로서비스 — 사례 2의 최종 선택
• 아키텍처 특성 식별(실리콘 샌드위치 카타)
• 컴포넌트 기반 사고(GGG 카타)

출처

• 『소프트웨어 아키텍처 The Basics』 19장 적절한 아키텍처 스타일의 선택