3.2 아키텍처 스타일과 패턴

개요와 동기

아키텍처 스타일은 시스템을 조직하는 넓고 재사용 가능한 형태입니다. 어떻게 분해되는지, 부분들이 어떻게 소통하는지, 경계가 어디에 놓이는지입니다. 하나를 고르는 것은 대규모 조직이 내리는 가장 중대하고 가장 오해받는 결정 중 하나입니다. 선택이 팀, 도메인, 운영 현실의 실제 제약이 아니라 유행(“모두가 마이크로서비스를 하고 있다”)을 따르는 일이 너무 많습니다. 결국 두 가지 난장판 중 하나가 됩니다. 조직이 운영할 수 없는 분산 시스템, 또는 아무도 안전하게 바꿀 수 없는 엉킨 모놀리스입니다. 어느 쪽도 스타일의 잘못이 아닙니다. 둘 다 스타일을 상황에 맞추지 못한 데서 옵니다.

대규모 개발자 팀에서 스타일이 중요한 가장 큰 이유는 콘웨이의 법칙 때문입니다. 시스템의 구조는 그것을 만드는 조직의 의사소통 구조를 닮는 경향이 있습니다. 그래서 아키텍처 스타일은 조직 설계 결정이기도 합니다. 시스템을 서비스로 나누는 것은 사실 팀, 소유권, 호출 대기 책임을 나누는 결정입니다. 수백 명의 엔지니어가 있는 기업은 세밀한 서비스와 독립적 배포를 감당할 수 있고(흔히 필요로 하고), 그 독립성이 많은 팀이 서로 막지 않고 출시하는 방법이기 때문입니다. 같은 패턴을 작은 단일 팀에 강요하면 조직적 이점은 하나도 없이 운영 세금만 전부 물려받습니다.

정부와 기업 환경은 더 많은 제약을 쌓습니다. 긴 시스템 수명, 엄격한 변경 통제, 조달 주기, 굳어진 기록 시스템과의 통합, 감사 가능성입니다. 이는 경계를 명시적으로 하고 의존성을 쉽게 점검할 수 있게 하는 스타일을 선호합니다. 이 장은 주요 스타일을 개관합니다. 모놀리스에서 마이크로서비스, CQRS와 이벤트 소싱을 갖춘 이벤트 기반 아키텍처, 서비스 메시와 게이트웨이 패턴, 서버리스, 헥사고날 및 클린 아키텍처의 내부 규율입니다. 더 중요하게는, 각각이 맞는 때를 구별하도록 돕습니다.

함께 보기: 2.2장(소프트웨어 설계 원칙, 도메인 주도 설계 포함), 3.1장(아키텍처의 기본), 3.3장(분산 시스템).

핵심 원칙

스타일은 유행이 아니라 힘을 따릅니다. 기술이 인기 있다는 이유가 아니라 팀 규모, 도메인 복잡성, 부하, 운영 성숙도를 기준으로 고르십시오.
진짜 적은 배포 단위의 수가 아니라 결합도입니다. 잘 모듈화된 모놀리스가 분산된 큰 진흙 덩어리를 이깁니다.
분산은 독립성을 위해 치르는 비용입니다. 독립적 배포, 확장, 장애 격리의 가치가 네트워크 호출, 부분 실패, 서비스 간 데이터 일관성의 비용을 넘을 때만 나누십시오.
경계는 비즈니스 도메인을 따라야 합니다. 서비스와 모듈을 기술 계층이 아니라 바운디드 컨텍스트(각각 자체의 명시적 경계를 가진 독립적인 도메인 모델)에 맞추십시오.
바깥과 무관하게 안쪽을 잘 설계하십시오. 헥사고날/클린 계층화는 어떤 스타일에서든 비즈니스 로직을 프레임워크와 인프라로부터 독립적으로 유지합니다.
콘웨이의 법칙은 피할 수 없으니 활용하십시오. 팀 경계와 아키텍처를 함께 설계하십시오.
필요하다고 생각하는 것보다 단순하게 시작하십시오. 좋은 모듈러 모놀리스에서 서비스를 추출할 수 있지만, 성급한 마이크로서비스 난장판을 되돌리는 것은 훨씬 어렵습니다.

권장 사항

모듈러 모놀리스를 기본으로 하고, 증거가 있을 때 나눈다

대부분의 시스템을 강한 내부 모듈 경계를 가진 단일 배포 단위로 시작하십시오. 분명한 인터페이스, 다른 모듈의 데이터에 손대지 않기, 시행되는 의존성 규칙입니다. 단순한 트랜잭션, 쉬운 리팩터링, 배포하고 관측할 하나를 얻습니다. 구체적인 이유가 있을 때만 모듈을 자체 서비스로 나누십시오. 독자적으로 확장해야 하는 부분, 자기 주기로 배포해야 하는 팀, 격리해야 하는 장애 도메인, 나머지와 다른 기술 요구 사항입니다. 나눌 때는 바운디드 컨텍스트 선을 따라 나눠 각 서비스가 자기 데이터를 소유하고 안정적인 계약을 노출하게 하십시오.

마이크로서비스가 값을 하는 때를 안다

마이크로서비스는 독립적 배포 가능성, 독립적 확장, 장애 격리, 기술을 섞을 자유를 줍니다. 그 대가로 성숙한 CI/CD(지속적 통합과 지속적 전달), 자동화된 인프라, 분산 추적, 서비스 디스커버리, 호출 대기 문화를 요구합니다. 정직하게 물으십시오. 조직이 독립적으로 배포되는 수십 개의 서비스를 프로덕션에서 안정적으로 운영할 수 있습니까? 플랫폼과 운영 성숙도가 없다면, 마이크로서비스는 이점은 주지 못하고 장애 양상만 곱절로 늘립니다. 많은 조직은 작은 서비스 떼보다 주요 도메인에 맞춘 소수의 굵은 서비스로 가장 잘 해냅니다.

분리와 비동기가 값을 하는 곳에 이벤트 기반 아키텍처를 쓴다

이벤트 기반 아키텍처는 생산자가 누가 소비하는지 모른 채 사실을 내보내게 합니다. 느슨한 결합, 부하 급증에 대한 완충, 새 소비자를 쉽게 추가하는 방법을 줍니다. 워크플로가 자연스럽게 비동기적이고 반응적인 곳에 쓰십시오. CQRS(Command Query Responsibility Segregation)는 쓰기 모델을 하나 이상의 읽기 모델과 분리하여, 읽기와 쓰기의 부하나 모양이 크게 다를 때 도움이 됩니다. 이벤트 소싱은 현재 상태 대신 추가 전용 이벤트 로그로 상태를 저장하여 완벽한 감사 추적과 시간 여행을 줍니다. “이 값에 어떻게 도달했는가?”가 법적 질문인 금융과 정부에서 강력하지만, 이벤트 버전 관리, 프로젝션 재구축, 최종 일관성 추론에서 실제 복잡성을 더합니다. 기본으로가 아니라 의도적으로 손을 뻗으십시오.

많은 서비스를 관리하려고 게이트웨이, BFF, 메시 패턴을 적용한다

API 게이트웨이는 외부 클라이언트에게 단일 진입점을 주어 인증, 속도 제한, 라우팅, TLS(Transport Layer Security) 종단을 처리합니다. Backend-for-Frontend(BFF)는 각 클라이언트 유형(웹, 모바일, 파트너 API)에 맞춤 집계 계층을 주어, 부풀어 오른 만능 API를 피하게 합니다. 서비스 메시는 횡단 관심사(상호 TLS, 재시도, 타임아웃, 트래픽 이동, 텔레메트리)를 사이드카 인프라 계층으로 옮겨 애플리케이션 팀이 다시 구현하지 않아도 되게 합니다. 서비스 수가 이런 관심사를 서비스별로 처리하기 감당 못 할 만큼 되었을 때만 메시를 추가하십시오. 서비스가 몇 개뿐이라면 메시는 값어치보다 운영 무게가 큽니다.

서버리스를 정직하게 저울질한다

서비스형 함수(FaaS)와 관리형 서버리스 플랫폼은 서버 관리를 덜어 주고, 0까지 확장하며, 사용량 기준으로 청구하므로 급증하거나, 이벤트 기반이거나, 기저 부하가 낮은 워크로드와 작은 팀에 좋습니다. 트레이드오프는 실제입니다. 콜드 스타트 지연, 실행 시간과 자원 한계, 더 어려운 로컬 테스트, 가능한 벤더 종속, 지속적으로 높은 용량에서는 프로비저닝된 인프라를 넘을 수 있는 비용입니다. 경제성과 운영 단순성이 분명히 이기는 곳에 서버리스를 쓰십시오. 열정 때문에 꾸준하고 처리량이 높은 핵심 시스템을 밀어 넣지 마십시오.

모든 서비스 안에서 비즈니스 로직을 깨끗하게 유지한다

바깥 스타일이 무엇이든 헥사고날(포트와 어댑터) 또는 클린 아키텍처로 안쪽을 깨끗이 유지하십시오. 비즈니스 규칙은 중심에 두고 추상에만 의존하게 하며, 프레임워크, 데이터베이스, 메시징은 교체 가능한 어댑터로 가장자리에 둡니다. 이는 소중한 도메인 로직이 인프라 없이 테스트되고 기술 변화를 넘어 이식 가능하게 유지합니다. 여러 세대의 프레임워크보다 오래 살 장수하는 정부와 기업 시스템에 결정적인 이점입니다.

장단점

스타일	가장 알맞은 때	장점	단점
모듈러 모놀리스	대부분의 시스템, 특히 초기	단순한 운영. 쉬운 트랜잭션과 리팩터링	단일 배포 단위. 하나로 확장. 침식 위험
마이크로서비스	많은 팀, 높은 규모, 성숙한 플랫폼	독립적 배포/확장. 장애 격리	분산 복잡성. 데이터 일관성. 높은 운영 비용
이벤트 기반 / CQRS / 이벤트 소싱	비동기 워크플로, 감사 요구, 갈라지는 읽기/쓰기	느슨한 결합. 감사 가능성. 확장 가능한 읽기	최종 일관성. 이벤트 버전 관리. 더 어려운 디버깅
서버리스	급증하거나 기저가 낮은 이벤트 기반 작업	서버 관리 없음. 0까지 확장. 사용량 과금	콜드 스타트. 한계. 종속. 높은 지속 부하의 비용

되풀이되는 주제는 운영적, 인지적 복잡성으로 유연성과 독립성을 산다는 것입니다. 분산 및 이벤트 기반 스타일은 단일 호출 스택과 단일 트랜잭션의 단순함을 내주고 독립적으로 확장하고, 배포하고, 실패하는 능력을 얻습니다. 이 거래는 규모와 성숙한 플랫폼이 있을 때 값을 합니다. 없으면 파멸적입니다. 내부 규율(헥사고날/클린)은 거의 항상 값을 합니다. 비용이 적게 들고 나중에 스타일을 바꿀 선택지를 열어 두기 때문입니다.

팀과 논의할 질문

다음 서비스를 나누기 전에, 그것을 소유할 팀도 나눌 것이며, 누가 그럴 권한을 갖습니까? 콘웨이의 법칙에 따르면 서비스 경계는 사실 팀 경계이므로, 조직도가 뒷받침하지 않는 분리는 분산된 모놀리스를 낳습니다. 배포 단위는 둘인데 릴리스 열차는 하나이고 호출 대기도 공유합니다. 큰 기업에서 팀을 재편할 권한은 대개 보고 체계, 재무, 인사 같은 엔지니어링 위에 있으며, 그래서 아키텍처와 조직 설계를 함께 결정해야 합니다. 논의에 증거를 가져오십시오. 제안된 서비스에 처음부터 끝까지 소유하고, 자체 호출 대기를 꾸리고, 자기 주기로 배포할 수 있는 팀이 있습니까? 답이 아니라면 팀에 재원을 대거나 그 기능을 모놀리스의 모듈로 유지하십시오. 소유권을 나누지 않고 코드를 나누면 분산의 모든 비용을 사고 독립성은 하나도 얻지 못합니다.
오늘 서비스를 각각 독립적으로 배포할 수 있습니까, 아니면 몰래 보조를 맞춰 출시합니까? 분산된 모놀리스는 이 장에서 가장 나쁜 결과입니다. 네트워크 호출, 부분 실패, 서비스 간 데이터 일관성의 비용을 치르면서도 다른 것 없이 하나를 릴리스할 수 없습니다. 눈에 띄는 징후는 공유 데이터베이스, 조율된 업그레이드를 강제하는 공유 라이브러리, 전체 자산을 함께 돌려야 하는 통합 테스트입니다. 큰 팀에서 이는 조용히 처리량을 막습니다. 다이어그램은 독립성을 보여 주는데도 모든 팀이 하나의 릴리스 뒤에 줄을 서기 때문입니다. 최근 변경 하나를 골라 안전하려면 몇 개의 서비스가 함께 배포되어야 했는지 세어 보십시오. 단일 기능에 닿은 변경에 그 수가 하나보다 크다면 경계가 잘못된 것입니다. 해법은 대개 서비스를 더 추가하는 것이 아니라 각 서비스에 자기 데이터와 안정적이고 버전 관리되는 계약을 주는 것입니다.
기존 서비스 분리 중 어느 것이 더는 값을 하지 않으며, 다시 통합하겠습니까? 이 장에서 가장 고급 습관은 스타일 결정을 되돌릴 수 있는 것으로 다루는 것입니다. 동인이 나타나면 추출하고, 동인이 사라지면 다시 합치십시오. 대부분의 조직은 나누기만 해서, 오케스트레이션과 네트워크 오버헤드가 각 서비스가 하는 일을 압도할 때까지 나노서비스와 수다스러운 엔티티 서비스가 쌓입니다. 항상 함께 배포되거나, 비즈니스 기능이 아니라 데이터베이스 테이블 때문에 존재하거나, 네트워크 홉이 이제 요청 지연을 지배하는 서비스를 찾으십시오. 인원과 예산이 정밀 조사받는 기업과 정부 자산에서, 얇은 서비스 둘을 하나의 굵은 서비스로 다시 접는 것은 실패의 인정이 아니라 정당하고 비용을 줄이는 조치입니다. 재통합을 추출만큼 공개적으로 테이블에 올리고, 둘을 같은 증거로 결정하십시오.
플랫폼과 호출 대기 성숙도가 제안하는 스타일을 실제로 뒷받침하며, 확정하기 전에 구체적인 간극을 말할 수 있습니까? 마이크로서비스, 메시, 이벤트 기반 백본은 성숙한 CI/CD, 분산 추적, 서비스 디스커버리, 부분 실패를 추론할 수 있는 호출 대기 문화 위에서만 이점을 줍니다. 큰 조직은 아키텍처 포럼에서 목표 스타일을 정하고, 수십 개 서비스가 이미 프로덕션에 있고 모든 인시던트 진단에 몇 시간이 걸린 뒤에야 빠진 플랫폼을 발견하는 경향이 있습니다. 독립적 배포와 확장의 매력을 새벽 3시에 누가 운영하는가라는 냉정한 질문과 저울질하십시오. 팀이 병렬로 출시하게 해 방출하는 같은 분리가 각 팀이 이해해야 하는 장애 양상도 곱절로 늘립니다. 논의에 정직한 현황을 가져오십시오. 현재 배포 빈도, 평균 복구 시간, 서비스 경계를 가로지르는 추적이 있는지, 한 팀이 현실적으로 운영할 수 있는 서비스 수입니다. 기업과 정부 환경에서는 없는 플랫폼 기능의 조달과 채용 리드 타임을 더하십시오. 재원을 대지 않은 메시와 플랫폼 팀을 가정하는 스타일은 지원할 수 없는 자산을 운영하겠다는 계획이기 때문입니다.
도메인의 어느 부분에서 완전한 이벤트 소싱 감사 추적이 편의가 아닌 법적 필수이며, 누가 결정할 권한이 있습니까? 이벤트 소싱과 CQRS는 완벽하게 재구성 가능한 이력과 스스로 확장하는 읽기 모델을 주지만, 시스템 수명 내내 이벤트 버전 관리, 프로젝션 재구축, 최종 일관성 추론의 비용을 치르게 합니다. 감사 추적이 필요 없던 도메인에 적용하면 그 복잡성은 순수한 세금이고, “이 값에 어떻게 도달했는가?”가 법적 질문인 도메인에서 빠뜨리면 그 부재는 컴플라이언스 실패입니다. 상충하는 고려는 한쪽에 감사 가능성과 질의 확장성, 다른 쪽에 디버깅의 어려움과 개발자의 인지 부하이므로, 결정은 패턴에 가장 열광하는 사람이 아니라 규제 의무와 운영 부담을 모두 이해하는 사람들에게 속합니다. 구체적인 법적 또는 계약상의 보존과 재구성 요구, 예상 이벤트 양, 버전 관리와 프로젝션 작업의 정직한 추정을 가져오십시오. 수년 뒤 결정을 재구성하는 것이 법정 의무일 수 있는 금융, 세무, 정부에서는 주어진 바운디드 컨텍스트가 불변 이벤트 로그를 요구하는지 아닌지를 승인하는 책임 소유자를 지명하십시오.
모듈러 모놀리스가 침식되지 않아 나중의 추출이 계속 싸게 유지되도록 어떻게 하며, 무엇이 경계를 시행합니까? 모듈러 모놀리스로 시작하는 논거 전체는 깨끗한 내부 경계가 나중의 서비스 추출을 감당할 만하게 한다는 약속에 달려 있지만, 그 경계는 마감이 한 모듈을 다른 모듈의 데이터에 손대도록 유혹하는 순간 조용히 썩습니다. 기여자가 많은 큰 팀에서는 선의와 코드 리뷰만으로 선을 지킬 수 없습니다. 시행 메커니즘이 없으면 모놀리스는 이 스타일이 피하려던 큰 진흙 덩어리가 조용히 됩니다. 시행되는 의존성 규칙과 모듈 인터페이스의 마찰을, 몇 년 뒤 어떤 경계도 실재하지 않고 모든 추출이 공유 상태를 푸는 일임을 발견하는 비용과 저울질하십시오. 증거를 가져오십시오. 모듈 경계가 빌드 도구, 정적 분석, 패키지 구조로 시행됩니까, 아니면 최근 여섯 번의 병합이 무시한 문서화된 관례일 뿐입니까? 엄격한 변경 통제와 여러 세대의 프레임워크를 견뎌야 하는 오래 사는 기업과 정부 시스템에서는 경계 시행을 감사 가능한 통제로 다뤄, 나중에 분산할 선택지가 아직 가지고 있다고 가정하는 것이 아니라 실제로 보존한 것이 되게 하십시오.

분야별 관점

스타트업. 단일 모듈러 모놀리스를 기본으로 하고 마이크로서비스의 끌림에 저항하십시오. 가장 희소한 자원이 엔지니어링 주의이고, 서비스 떼는 제품-시장 적합성 전에는 감당할 수 없는 운영 세금이기 때문입니다. 나중에 추출할 수 있도록 깨끗한 모듈 경계를 유지하고, 0까지 확장과 사용량 과금이 급증하고 기저가 낮은 부하에 맞는 곳에는 서버리스를 쓰십시오. 구체적 동인이 나타날 때만, 예컨대 급증하는 알림 발송기 하나만 나누고 그보다 일찍 나누지 마십시오.

소기업. 플랫폼 팀도 빠듯한 예산도 없으니 관리형 플랫폼 위의 모놀리스나 소수의 굵은 서비스를 선호하고, 메시, 추적, 서비스 디스커버리를 직접 만들기보다 호스팅된 인프라를 사십시오. 서버를 아예 운영하지 않는 방법으로 서버리스와 관리형 데이터베이스를 저울질하고, 운영 부담을 짊어질 사람이 없는 분산 설계를 경계하십시오. 맞는 아키텍처는 한두 사람이 실제로 배포하고, 관측하고, 복구할 수 있는 것입니다.

대기업. 진짜 문제는 많은 팀과 콘웨이의 법칙입니다. 굵은 서비스를 바운디드 컨텍스트와 팀 소유권에 맞추고, 분산을 안전하게 하는 플랫폼(CI/CD, 추적, 메시, 서비스 디스커버리)에 의도적으로 투자하십시오. 그룹들이 다시 발명하는 것을 멈추도록 게이트웨이, BFF, 내부 클린 아키텍처 패턴을 표준화하고, 추출과 재통합을 지역적 선호가 아니라 증거 기반 포트폴리오 결정으로 다스리십시오. 모든 분리의 운영 비용을 명시적으로 예산에 넣으십시오. 규모에서 분산된 모놀리스 실패는 비싸고 풀기 느리기 때문입니다.

정부. 긴 시스템 수명, 엄격한 변경 통제, 조달 주기, 감사 가능성이 선택을 형성합니다. 명시적이고 점검 가능한 경계와 벤더 및 프레임워크 세대를 넘어 오래가는 계약을 가진 스타일을 선호하십시오. 이벤트 소싱은 시민에게 영향을 주는 결정을 재구성하는 것이 법정 의무인 곳에서 복잡성만큼 값을 하므로, 핵심 원장에 의도적으로 쓰고, 예산마다 바뀌는 규칙을 격리하도록 모든 서비스 안에 클린 아키텍처를 유지하십시오. 독점 서버리스나 벤더 플랫폼에서의 이식성과 탈출을 사후 생각이 아니라 조달 요구 사항으로 다루십시오.

사례

스타트업. 일정 관리 제품을 만드는 네 명 규모의 스타트업은 경쟁사가 블로그에 쓴 탓에 마이크로서비스로 시작해야 한다는 압박을 느끼지만 저항합니다. 하나의 배포 가능 단위 안에 별도 모듈로 분명한 내부 경계(일정, 청구, 알림)를 가진 단일 모듈러 모놀리스를 출시하여, 엔지니어 한 명이 전체를 로컬에서 돌릴 수 있고 릴리스는 한 번의 푸시입니다. 제품이 견인력을 얻으면서, 급증하는 부하에서 이메일과 SMS로 퍼져 나가는 알림 발송기만 자체 서비스로 분리됩니다. 아직 제품-시장 적합성을 찾는 동안 열두 개 서비스의 운영 세금은 하나도 물려받지 않습니다.

대기업. 한 대형 전자상거래 회사는 모듈러 모놀리스로 시작합니다. 트래픽이 늘고 팀이 늘면서, 부하가 가장 높고 가장 독립적으로 진화하는 도메인(카탈로그, 장바구니, 결제, 검색)을 각자 자기 데이터를 소유한 별도 서비스로 빼냅니다. 결제는 이벤트를 내보내고, 재고, 풀필먼트, 분석이 이벤트 백본으로 소비하므로 새 소비자(사기 탐지, 로열티)가 결제를 건드리지 않고 붙을 수 있습니다. API 게이트웨이가 인증과 속도 제한을 처리하고, BFF가 모바일용 페이로드를 맞춥니다. 나머지 트래픽이 낮은 도메인은 모놀리스에 남아 불필요한 파편화를 피합니다.

정부. 한 세무 당국이 핵심 원장에 이벤트 소싱으로 평가 플랫폼을 만듭니다. 납세자의 납부 의무에 대한 모든 변경이 수년간 재구성 가능하고 법적으로 감사 가능해야 하기 때문입니다. 명령(신고서 제출, 납부 적용, 조정 발행)이 불변 이벤트를 만들고, 읽기 모델이 담당자와 시민을 위한 현재 잔액을 투영합니다. CQRS는 공개 질의 쪽이 쓰기 쪽을 위험에 빠뜨리지 않고 성수기 신고 시즌에 스스로 확장하게 합니다. 내부적으로 각 서비스는 클린 아키텍처를 따라, 예산마다 바뀌는 평가 규칙이 영속성과 메시징 기술로부터 격리되어 유지됩니다.

비즈니스 사례: 동기, ROI, TCO

스타일 선택에 걸린 돈은 막대합니다. 결정을 되돌리는 데 비용이 많이 들기 때문입니다. 마이크로서비스를 너무 일찍 채택하면 플랫폼 구축, 중복된 인프라, 분산 디버깅, 더 무거운 운영 부담으로 총소유비용이 부풀며, 이 비용은 시스템 수명 내내 남습니다. 진짜로 과부하된 모놀리스를 나누기를 거부하면 전달 처리량에 상한을 겁니다. 팀들이 공유 릴리스 뒤에 줄을 서고, 모든 변경이 시스템 전체를 위험에 빠뜨립니다. ROI 대화는 사실 운영 지출을 조직의 필요에 맞추는 것입니다.

리더십에게는 기술이 아니라 처리량과 위험의 언어로 논거를 세우십시오. 독립적 배포 가능성은 더 많은 팀이 병렬로 출시하고 리드 타임이 짧아짐을 뜻하며, 측정 가능한 비즈니스 속도입니다. 장애 격리는 전체 장애가 줄고 영향 범위가 작아짐을 뜻하며, 측정 가능한 가용성과 평판 보호입니다. 그러나 각 스타일이 요구하는 플랫폼 투자에도 똑같이 정직하십시오. 메시, 추적, CI/CD 성숙도는 선택적 추가물이 아니라 전제 조건이며, 그 비용은 TCO에 속합니다. 많은 조직에게 가장 싼 길은 지금은 잘 모듈화된 모놀리스이고, 나중의 추출을 싸게 만드는 깨끗한 내부 경계입니다. 그러면 필요하기 전에 비용을 치르지 않고 분산할 선택권을 삽니다.

안티패턴과 함정

분산된 모놀리스. 함께 배포해야 하고 데이터베이스를 공유하는 서비스. 분산의 모든 비용에 독립성은 없습니다.
나노서비스. 오케스트레이션과 네트워크 오버헤드가 하는 일을 압도할 만큼 잘게 쪼개진 서비스.
플랫폼 없는 마이크로서비스. CI/CD, 추적, 호출 대기 성숙도가 있기 전에 나누는 것. 장애 양상이 곱절이 됩니다.
엔티티 서비스. 비즈니스 기능이 아니라 데이터베이스 테이블(“사용자 서비스”, “주문 서비스”)로 나눠, 모든 연산에 수다스러운 서비스 간 호출을 강제하는 것.
어디서나 이벤트 소싱. 감사 추적이 필요 없는 도메인에 적용해 아무 이득 없이 복잡성 세금을 내는 것.
모놀리스로서의 게이트웨이. API 게이트웨이에 비즈니스 로직을 넣어 중앙 병목을 다시 만드는 것.
프레임워크에 결합된 핵심. 비즈니스 로직이 웹이나 ORM(객체-관계 매핑) 프레임워크와 얽혀 테스트와 기술 변경이 모두 고통스러워지는 것.

성숙도 모델

1단계: 시작. 스타일이 유행이나 우연으로 선택됩니다. 엉킨 모놀리스 하나이거나 우발적인 분산 난장판이 있고, 경계는 도메인이 아니라 기술 계층이나 역사를 따르며, 분리는 무언가 깨질 때 반응적으로 일어납니다.
2단계: 발전. 일부 팀이 모놀리스 안에 의도적 모듈 경계를 긋거나 몇 개의 굵은 서비스를 세우고, 일부 횡단 관심사는 일관되게 처리됩니다. 실천은 고르지 않습니다. 한 그룹은 서비스를 바운디드 컨텍스트에 맞추는데 다른 그룹은 여전히 데이터베이스 테이블로 나누고, 추출은 즉흥적으로 남습니다.
3단계: 표준화. 문서화된 접근이 조직 전체에서 시행됩니다. 서비스는 바운디드 컨텍스트에 맞추고 자기 데이터를 소유하며, 적절한 곳에 게이트웨이와 BFF 패턴을 쓰고, 내부 클린 또는 헥사고날 계층화가 표준이며, 모든 분리에 명시된 동인이 필요합니다. 모듈 경계는 관례만이 아니라 도구로 시행됩니다.
4단계: 관리. 스타일 결정이 기준선에 대해 측정되고 통제됩니다. 서비스별 배포 빈도와 리드 타임, 평균 복구 시간, 전형적 변경에 함께 배포해야 하는 서비스 수, 네트워크 홉 지연을 추적하고, 각 분리의 비용을 그것이 사려던 독립성과 비교합니다. 선호가 아니라 증거가 경계의 존속을 결정하고, 분산된 모놀리스로의 표류는 장애가 아니라 지표로 잡힙니다.
5단계: 오케스트레이션. 아키텍처가 조직 설계와 통합되어 지속적으로 적응합니다. 성숙한 플랫폼(CI/CD, 추적, 정당화되는 곳의 메시)이 분산과 재통합을 모두 싸게 만들고, 팀들은 동인이 나타나면 일상적으로 추출하고 사라지면 서비스를 다시 접으며, 스타일 선택은 팀 토폴로지, 부하, 위험 그림이 전체 자산에 걸쳐 이동함에 따라 재균형됩니다.

논의를 위한 아이디어

시스템의 어디에서 모놀리스가 실제로 강점이고, 어디에서 진짜 병목입니까?
다음 서비스 추출을 정당화할 구체적 동인은 무엇이며, 만들기 전에 이름 붙일 수 있습니까?
조직에 마이크로서비스가 요구하는 운영 성숙도가 있습니까? 무엇이 빠져 있습니까?
도메인의 어느 부분에서 완전한 이벤트 소싱 감사 추적이 법적 또는 비즈니스 필수이고, 어디에서 있으면 좋은 정도입니까?
현재 서비스 경계가 팀 경계를 얼마나 잘 반영하며, 그 정렬이 돕고 있습니까 해치고 있습니까?
내년에 웹 프레임워크나 데이터베이스를 바꿔야 한다면 비즈니스 로직의 얼마를 다시 써야 합니까?

핵심 요점

아키텍처 스타일은 유행이 아니라 실제 힘(팀 규모, 도메인, 부하, 운영 성숙도)에서 고르십시오.
모듈러 모놀리스가 대부분의 시스템에 맞는 기본입니다. 구체적 동인이 있고 바운디드 컨텍스트 선을 따를 때만 서비스를 추출하십시오.
마이크로서비스는 운영적, 인지적 복잡성을 독립적 배포, 확장, 장애 격리와 맞바꾸며, 성숙한 플랫폼이 필요합니다.
이벤트 기반, CQRS, 이벤트 소싱은 최종 일관성과 버전 관리 복잡성을 대가로 분리와 감사 가능성을 제공합니다. 의도적으로 채택하십시오.
게이트웨이, BFF, 메시는 많은 서비스의 자산을 길들이지만 무게를 더합니다. 그 전이 아니라 규모가 요구할 때 도입하십시오.
소중한 비즈니스 로직이 테스트 가능하고 기술 변화를 넘어 오래가도록 모든 서비스 안에 헥사고날/클린 아키텍처를 적용하십시오.

참고 문헌과 더 읽을거리

Sam Newman, Building Microservices and Monolith to Microservices
Chris Richardson, Microservices Patterns
Eric Evans, Domain-Driven Design
Vaughn Vernon, Implementing Domain-Driven Design
Robert C. Martin, Clean Architecture
Alistair Cockburn, “Hexagonal Architecture (Ports and Adapters)”
Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns
Martin Fowler, Patterns of Enterprise Application Architecture (and articles on CQRS and Event Sourcing)
Matthew Skelton and Manuel Pais, Team Topologies