Architectural Styles - 12. 아키텍처 스타일 비교

아키텍처 스타일 비교 — 같은 요구, 다른 정답

한 스타트업이 주문 시스템을 설계한다고 하자. 요구사항은 명확하다 — 하루 10만 건 주문, 결제 연동, 재고 관리, 향후 확장 가능성. 이 요구사항을 놓고 열두 가지 스타일 중 어느 것을 고를까. 정답은 "그때그때 다르다"가 아니라 "주어진 품질 속성 우선순위에 따라 다르다"다. 같은 기능(주문 처리)이라도, 어느 품질 속성(확장성·단순성·독립 배포·강한 일관성)이 결정적인가에 따라 정답이 갈린다. 이 글은 지금까지 다룴 열한 가지 스타일을 같은 잣대로 비교하고, 선택의 기준을 정리한다.

비유로 감 잡기 — 집의 골조 선택

같은 "3가족이 사는 집"을 짓는다고 하자. 세 가지 옵션이 있다고 가정한다.

• 단독주택 한 채 — 모두가 한 지붕 아래 산다. 공간 효율 좋고 관리 단순. 한 가족의 수리가 다른 가족에게 영향 (모놀리스).
• 연립 3세대 — 세 가구가 벽을 공유하지만 각자 현관. 어느 정도 독립. 인접한 가구의 소음 차단은 어려움 (모듈형 모놀리스).
• 세 채의 단독 — 완전히 분리. 한 가족의 수리가 다른 가족에게 영향 없음. 하지만 땅·자재·관리 비용 3배 (마이크로서비스).

같은 요구(3가족 주거)에 세 가지 정답. 각각의 장단이 있고, 가족의 성향(소리에 민감한가, 비용에 민감한가, 독립이 중요한가)에 따라 선택이 갈린다. 아키텍처 스타일도 같다 — 같은 기능 요구에 여러 정답이 존재하며, 결정적인 품질 속성에 따라 선택이 갈린다.

비유의 한계 — 집 비유는 '물리적 구조'를 강조하지만, 소프트웨어 아키텍처는 논리적 구조. 또한 집은 한 번 짓기 어렵지만, 소프트웨어는 진화(Evolutionary Architecture)가 가능. 비유는 '되돌림 비용'에서 무너진다.

핵심 전제 — "모든 것은 트레이드오프"

Mark Richards와 Neal Ford가 (2020)에서 제1법칙으로 놓은 문장이 이 장의 출발점이다. "소프트웨어 아키텍처의 모든 것은 트레이드오프다". 어떤 스타일도 '항상 좋은' 정답이 아니다. 각 스타일은 특정 품질 속성을 강화하는 대신 다른 품질 속성을 희생한다. 이 장의 비교는 "어느 쪽이 더 좋은가"가 아니라 "어떤 상황에서 어느 쪽이 맞는가"를 묻는다.

스타일별 품질 속성 매트릭스

지금까지 다룬 열한 가지 스타일(마이크로커널·서버리스는 한 축으로 묶어 표시)을 주요 품질 속성 기준으로 비교한다. 평가는 상대적(다른 스타일 대비)이며, '높음/중간/낮음'은 그 스타일이 해당 속성을 자연스럽게 지원하는 정도다.

스타일	단순성	확장성	장애 격리	독립 배포	강한 일관성	도메인 응집	유연성
모놀리스 (단일)	높음	낮음	낮음	낮음	높음	중간	낮음
모듈형 모놀리스	높음	낮음	낮음	낮음	높음	높음	중간
계층형	높음	낮음	낮음	낮음	높음	낮음	낮음
헥사고날	중간	낮음	낮음	낮음	높음	높음	높음
클린/온니언	중간	낮음	낮음	낮음	높음	높음	높음
마이크로서비스	낮음	높음	높음	높음	낮음	높음	중간
이벤트 기반	낮음	높음	높음	중간	낮음	중간	중간
CQRS	낮음	높음(읽기)	중간	중간	낮음	중간	중간
이벤트 소싱	낮음	중간	중간	낮음	높음(축적)	높음	낮음
파이프라인	중간	높음	높음	중간	낮음	낮음	중간
마이크로커널/서버리스	중간	높음	높음	높음	낮음	낮음	높음

이 표를 읽는 요령 — 한 열(품질 속성)에서 높음인 스타일이 그 속성을 중시할 때 후보. 동시에 다른 열에서 희생되는 속성이 있는지 확인. 예를 들어 '확장성'에서 마이크로서비스가 높지만, '강한 일관성'에서 낮음. 두 속성이 다 중요하면 갈등이 생기고, 어느 쪽을 우선할지가 결정이 된다.

같은 요구, 다른 스타일 — 주문 시스템 사례

구체적으로, 앞서 본 주문 시스템을 다섯 가지 상황에 따라 다르게 설계해 본다. 같은 '주문 처리'지만 품질 속성 우선순위가 다르면 정답이 갈린다.

상황 A: 초기 스타트업, 팀 5명, 일일 1만 건

결정적 속성: 단순성, 빠른 출시. 확장성은 미래의 문제.

→ 모놀리스 (또는 모듈형 모놀리스). 한 팀, 한 배포, 한 DB가 가장 빠른 출시를 가능하게 한다. Newman이 "모놀리스 먼저"를 권하는 정확한 상황. 모듈형으로 가면 미래 추출(05편)까지 대비.

상황 B: 성장기, 팀 3개, 일일 100만 건, 부하 편차 큼

결정적 속성: 확장성, 독립 배포, 장애 격리. 결제 서비스만 트래픽 폭증.

→ 마이크로서비스. 결제 서비스만 별도로 확장 가능. 세 팀이 각자 담당 서비스를 독립 배포. 단, 분산의 비용(관측성·데이터 일관성)을 감당할 CI/CD 인프라가 전제.

상황 C: 금융 핀테크, 강한 일관성이 비즈니스 핵심

결정적 속성: 강한 일관성, 감사 로그. 확장성은 그 다음.

→ 모놀리스 또는 모듈형 모놀리스 + 이벤트 소싱. 마이크로서비스의 최종 일관성은 위험. 단일 트랜잭션으로 원장 일관성 보장. 이벤트 소싱으로 감사 로그 추가. 읽기가 많으면 CQRS 결합.

상황 D: 분석 중심, 읽기 99%, 다양한 쿼리

결정적 속성: 읽기 확장성, 쿼리 유연성.

→ CQRS. 쓰기는 RDB 정규화, 읽기는 Elasticsearch 또는 OLAP 큐브. 읽기 100배 확장, 다양한 쿼리 패턴 지원. 쓰기/읽기 비대칭이 뚜렷한 CQRS의 정확한 적합 사례.

상황 E: IoT 데이터 처리, 다단계 변환

결정적 속성: 파이프라인 확장성, 장애 격리, 단계별 독립 확장.

→ 파이프라인 (Kafka + 마이크로서비스). 센서 데이터 수집 → 정제 → 풍부화 → 분석 → 알림의 다단계 흐름. 각 단계를 Kafka 토픽으로 연결. 한 단계 장애가 다른 단계에 전파되지 않게 버퍼 역할.

이 다섯 상황은 모두 '주문 처리' 또는 '데이터 처리'라는 같은 출발이지만, 정답이 전혀 다르다. 각각의 정답은 품질 속성 우선순위에서 자연스럽게 나온다.

스타일 선택의 7가지 기준

Richards-Ford와 Sam Newman의 저서에서 공통적으로 등장하는 선택 기준을 정리한다. 아래 결정 흐름도는 가장 결정적인 질문부터 순차적으로 묻는 형태다. 한 질문의 답이 명확하면 다음 질문으로 갈 필요 없이 그 스타일이 후보가 된다.

flowchart TD
    Q1{도메인이 다단계<br/>데이터 처리 흐름인가?} -->|예| PL[파이프라인]
    Q1 -->|아니오| Q2{확장이 풍부한<br/>단일 제품인가?<br/>IDE, 브라우저, 빌드 도구}
    Q2 -->|예| MK[마이크로커널]
    Q2 -->|아니오| Q3{강한 일관성 +<br/>감사 로그가 핵심인가?<br/>금융, 의료}
    Q3 -->|예| ES[모놀리스 +<br/>이벤트 소싱]
    Q3 -->|아니오| Q4{읽기 비중이<br/>압도적인가?<br/>1000:1 이상}
    Q4 -->|예| CQ[CQRS]
    Q4 -->|아니오| Q5{팀이 여럿이고<br/>독립 배포가 필요한가?}
    Q5 -->|예| Q6{관측성·CI/CD 인프라가<br/>성숙했는가?}
    Q6 -->|예| MS[마이크로서비스 +<br/>이벤트 기반]
    Q6 -->|아니오| MM[모듈형 모놀리스]
    Q5 -->|아니오| Q7{도메인 규칙이<br/>풍부한가?}
    Q7 -->|예| HEX[헥사고날 / 클린]
    Q7 -->|아니오| MON[모놀리스 / 계층형]

이 흐름도는 정답이 아니라 출발점이다. 현실의 시스템은 이 질문들이 서로 얽히고, 하나의 시스템 안에 여러 스타일이 섞이기도 한다. 하지만 "가장 결정적인 질문부터" 묻는 습관이 스타일 선택을 구조적으로 만든다.

1. 도메인 복잡도

도메인이 단순한 CRUD면 계층형으로 충분. 도메인 규칙이 풍부하고 애그리거트가 중심이면 헥사고날·클린. 도메인이 여러 하위 도메인으로 쪼개지면 마이크로서비스 후보.

2. 팀 구조 (Conway)

팀이 하나면 모놀리스가 자연스럽. 여러 팀이 독립 작업해야 하면 마이크로서비스. Conway의 법칙을 거스르면 분산 모놀리스(06편)가 된다.

3. 트래픽 패턴

일관된 트래픽이면 모놀리스도 감당. 극단적 피크·부하 편차가 크면 마이크로서비스(서비스별 확장). 읽기 비중이 압도적이면 CQRS. 스트리밍/배치가 주면 파이프라인.

4. 일관성 요구

강한 일관성(ACID)이 비즈니스 핵심이면 모놀리스 또는 이벤트 소싱(축적 기반). 최종 일관성이 감내 가능하면 마이크로서비스·이벤트 기반.

5. 변경 주기

도메인이 자주 바뀌면 진화적 아키텍처(모듈형 모놀리스 → 추출 경로). 핵심은 안정적이고 확장이 자주 추가되면 마이크로커널.

6. 인프라 성숙도

CI/CD·관측성·분산 추적이 성숙해야 마이크로서비스·서버리스. 인프라가 미성숙하면 모놀리스. "마이크로서비스를 도입하면 인프라를 키울 수 있다"는 순서가 아니라 "인프라가 먼저 성숙해야 마이크로서비스가 가치를 낸다"가 맞다.

7. 도메인 이해도

도메인을 깊이 이해해 경계를 그을 수 있어야 마이크로서비스. 도메인이 아직 불명확하면 모놀리스에서 시작해 이해가 깊어지면 추출 (Fowler의 "MonolithFirst").

결정 매트릭스 — 한눈에 보는 선택 가이드

이 기준들을 한 표로 정리한다. "이 조건이 결정적이면 → 이 스타일이 후보"의 형태.

결정적 조건	추천 스타일	이유
단순성·빠른 출시·한 팀	모놀리스 (또는 모듈형)	진입 장벽 최소, 단일 배포
도메인 규칙 풍부, 도메인 보호 핵심	헥사고날 / 클린	의존성 역전으로 도메인 격리
여러 팀, 독립 배포, 부하 편차	마이크로서비스	서비스별 독립 확장·배포
강한 일관성 + 감사 로그	이벤트 소싱 (단일 모놀리스)	ACID + 이벤트 로그
읽기 압도적, 다양한 쿼리	CQRS	읽기 모델 독자적 최적화
이벤트 흐름, 느슨한 결합	이벤트 기반	장애 격리, 비동기 처리
다단계 데이터 처리	파이프라인	단계별 독립 확장
확장이 풍부한 제품 (IDE 등)	마이크로커널	코어 최소, 플러그인 다양
단발성 이벤트 처리, 벤더 인프라 활용	서버리스 FaaS	운영 부담 최소

이 표를 쓰는 요령 — 한 요구사항에서 여러 조건이 동시에 결정적일 수 있다. 그땐 우선순위를 매기고 가장 높은 것을 따른다. 모순되면(예: 강한 일관성 + 독립 배포) 둘 중 하나를 타협해야 한다 — 그게 아키텍처 결정의 본질이다.

혼합 스타일 — 현실은 단일 스타일이 아니다

실제 시스템은 단일 스타일이 아니라 여러 스타일의 조합인 경우가 대부분이다. 예시:

• 마이크로서비스 아키텍처의 한 서비스가 헥사고날 — 외부 시스템 통합용 서비스는 포트-어댑터가 자연스럽다.
• 모놀리스 내부에 파이프라인 — 모놀리스 안의 데이터 처리 서브시스템이 파이프라인 형태.
• 마이크로서비스 + 이벤트 소싱 + CQRS — 결제 서비스는 이벤트 소싱으로 원장 관리, 읽기는 CQRS로 분리. 흔한 패턴.
• 서버리스 + 이벤트 기반 — Lambda 함수들이 이벤트 브로커(SQS, EventBridge)로 연결. FaaS 형태의 이벤트 기반 아키텍처.

이런 혼합은 자연스럽다. 스타일은 '전체 시스템'뿐 아니라 '서브 시스템'에도 적용된다. 한 시스템 안에서 여러 스타일이 공존하는 게 일반적이다.

진화적 아키텍처 — 스타일은 고정이 아니다

Neal Ford, Rebecca Parsons, Patrick Kua가 (2017)에서 강조하듯, 아키텍처는 요구사항 변화에 따라 진화한다. 처음엔 모놀리스로 시작해, 성장하면 모듈형으로 정비하고, 더 성장하면 일부 모듈을 마이크로서비스로 추출한다. 한 스타일에서 다른 스타일로의 전환은 비용이 크지만(되돌림 비용이 높은 결정, 01편 참조), 불가능하지는 않다.

이 진화를 가능하게 하는 건 — 각 단계에서 '다음 단계로의 선택지를 열어두는' 설계다. 모놀리스 단계에서 모듈 경계를 강제(모듈형 모놀리스)하면, 나중에 한 모듈을 서비스로 추출하는 비용이 줄어든다. 헥사고날로 도메인을 격리하면, 나중에 DB를 바꾸거나 진입점을 추가하는 비용이 줄어든다. "지금의 선택이 미래의 선택지를 어떻게 제한하거나 열어주는가"를 묻는 것이 진화적 아키텍처의 핵심이다.

이 영역을 마치며

architectural-styles의 열두 편을 통해 본 것 — 아키텍처 스타일은 "정답"이 아니라 "주어진 품질 속성 우선순위에 따른 합리적 선택"의 모음이다. 같은 기능 요구에 여러 스타일이 답이 될 수 있고, 어느 쪽이 맞는지는 그 시스템이 처한 상황(팀 규모·트래픽·도메인 복잡도·일관성 요구·인프라 성숙도)에 따라 갈린다.

다음 영역(04-distributed-systems)은 이 중 마이크로서비스·이벤트 기반·CQRS·이벤트 소싱이 전제하는 '분산'이라는 축을 깊이 파고든다. CAP·PACELC, 일관성 모델, 합의, 파티셔닝·복제, 분산 트랜잭션, 멱등성 등 — 분산을 선택했을 때 직면하는 근본적 trade-off를 다룬다. 그리고 05-ddd-and-patterns는 "도메인을 어떻게 자를까"라는 또 다른 축을 다룬다. 두 영역 모두 styles에서 다룬 스타일들의 기저 가정(분산·도메인 경계)을 더 깊이 파고드는 내용이다.

아키텍처 작업의 핵심은 "무엇을 포기했나"를 명시적으로 만드는 것이다. 각 스타일이 무엇을 얻고 무엇을 포기하는지를 명확히 알 때, 주어진 상황에 맞는 선택이 가능해진다. 열한 편의 스타일 비교가 그 선택의 지도가 되기를.

---

참고

• Richards, Ford — (O'Reilly, 2020), 아키텍처 스타일 결정 매트릭스 장 — 접근 2026-07-20
• Newman — (2nd ed, O'Reilly, 2021), Ch.1 (언제 마이크로서비스인가)·Ch.3 (분해 기준)
• Ford, Parsons, Kua — (O'Reilly, 2017), 진화적 아키텍처 원칙
• Fowler, Lewis — "Microservices" (martinfowler.com, 2014) — 접근 2026-07-20
• Bass, Clements, Kazman — (4th ed, Addison-Wesley, 2021), 아키텍처 스타일 비교 장
• Richards — "Software Architecture Patterns" (O'Reilly report, 2015) — 접근 2026-07-20