MSA는 어떻게 탄생했는가?

(MSA 입문서로 유명한 Building Microservices)

시작하기 앞서서...

내 홈페이지 MAKONEA도 MSA로 구축되어 있고,

외주 프로젝트에서도 “Microservices 아키텍처로 만들어 달라”는 요구가 점점 늘고 있다.

지금은 마치 “당연히 이렇게 해야 한다”는 분위기가 형성된 개념이지만, 처음부터 그런 것은 아니었다.

이 글에서는 MSA가 왜 등장했는지,

어떤 문제를 해결하기 위해 선택되었는지를

역사적 맥락 속에서 추적해보려 한다.

기술적 선택은 언제나 이전 기술의 한계와 실패 위에서 등장한다.

MSA를 제대로 이해하려면,

그 이전에는 무엇이 있었고, 그 방식이 왜 부족했는지를 먼저 살펴봐야 한다.

(전통적인 3-tier 모놀리스 아키텍쳐 이미지¹)

1. 모놀리스

많은 웹 애플리케이션은 전통적으로 3-tier 구조로 설계된다.

프레젠테이션 계층이 화면을 담당하고, 비즈니스 로직 계층이 규칙과 처리를 담당하며, 데이터 계층이 저장과 조회를 담당한다.

어떤 조직이 시스템을 설계하면,
그 시스템의 구조는 결국 그 조직의 커뮤니케이션 구조를 반영하게 된다.

— Melvin Conway, “How Do Committees Invent?”

여기서 한 가지 더 중요한 점이 있다.

왜 하필 3-tier 구조가 이렇게 널리 퍼졌을까?

Sam Newman은 『Building Microservices』에서 이 질문에 대해 Conway’s Law를 인용하며 설명한다.

시스템의 구조는 그것을 만든 조직의 커뮤니케이션 구조를 반영한다.

과거 IT 조직은 데이터베이스 팀, 백엔드 개발 팀, 프론트엔드 개발 팀처럼
기술 역량 중심으로 구성되어 있었다.

3-tier 아키텍처는 이 조직 구조를 그대로 반영한 결과다.

즉 3-tier는 기술적으로 “정답”이어서가 아니라,
당시 조직 구조에 최적화된 설계였다.

여기서 중요한 점이 하나 있다. 이 계층 분리는 논리적 분리지, 배포 단위의 분리가 아니다.

코드를 아무리 우아하게 3-tier로 쪼개고 디자인 패턴을 발라봤자, 빌드 버튼을 누르면 하나의 바이너리로 묶이고 하나의 프로세스 위에서 돈다. 이것이 모놀리스(Monolith)다. 그리스어로 '하나의(mono)' + '돌(lith)', 한 덩어리로 된 거대한 구조물이다.

모놀리스의 문제는 "구조가 없다"가 아니다. 내부 구조는 잘 정리되어 있을 수 있다. 문제는 변경, 배포, 확장, 장애의 경계가 모두 하나의 애플리케이션 단위에 묶인다는 점이다.

그리고 이 묶임은 작을 때는 오히려 강점이다.

네트워크 레이턴시는 0에 수렴한다. 모듈 간 연결이 네트워크 호출이 아니라 메모리 함수 호출이기 때문이다. 분산 트랜잭션을 고민할 필요 없이 단일 DB에서 완벽한 데이터 일관성을 보장받는다. 코드 흐름을 한 곳에서 추적할 수 있다. 초기 제품, 작은 팀, 빠른 검증 단계에서는 이 단순성이 가장 큰 장점이다.

MSA 전도사들(부트캠프와 유튜버들)은 처음부터 모든 것을 잘게 쪼개라고 유혹하지만, 비즈니스 생존도 검증 안 된 상태에서 네트워크 파티션과 인프라 복잡도를 끌어안는 것은 자살 행위다.

상식적으로 유저가 없는데 굳이 더 복잡하게 할 이유가 있는가? 전혀 없다. 외양간에 소가 한 마리도 없는데 외양간을 복잡하게 할 이유가 없다.

MSA를 이해할 때 가장 먼저 버려야 할 오해는 "모놀리스는 낡고 나쁜 구조"라는 생각이다. 모놀리스는 실패한 아키텍처가 아니다. 시스템이 특정 규모를 넘어서면서 비용 구조가 바뀌는 아키텍처다.

그 비용이 올라가는 지점은 세 가지다.

배포 결합도. 로그인 버그 하나를 고쳐도 주문 모듈 전체를 재배포해야 한다. 배포 한 번의 위험 범위가 전체 시스템이다. 배포 주기가 길어지고, 길어진 주기는 더 큰 변경을 한 번에 묶어 배포하게 만들고, 그러면 위험이 더 커진다. 악순환이다.

스케일링 결합도. 트래픽이 상품 조회에 몰려도 결제 서버까지 함께 스케일아웃해야 한다. 모든 기능이 같은 프로세스에 있기 때문에, 실제로 부하가 걸리는 컴포넌트만 선택적으로 확장할 방법이 없다.

팀 결합도. 팀이 커지면 코드베이스 한 군데를 모두가 건드린다. 머지 충돌, 빌드 대기, "누가 이 코드 건드렸어?" 문제가 일상이 된다. 팀이 커질수록 코드베이스 하나로 협업하는 비용이 기하급수적으로 늘어난다.

비즈니스 생존도 검증 안 된 상태에서 이 세 가지 문제가 아직 없다면, 모놀리스가 맞는 선택이다.

MSA는 이 비용이 실제로 감당하기 어려워진 시점에 꺼내는 카드다.

2. SOA - 첫 번째 시도, 그리고 실패

모놀리스의 한계에 대한 첫 번째 공식적인 시도 SOA(Service-Oriented Architecture)였다.

Mark Richards 역시 SOA를 “크고, 비싸고, 복잡하며, 구현까지 너무 오래 걸리는 아키텍처”였다고 평가한다.

2000년대 초 엔터프라이즈 진영이 주도한 이 움직임의 핵심 아이디어는 단순했다.

시스템을 서비스로 나누고, 그 서비스들이 표준화된 인터페이스로 통신하게 하라.

좋은 방향이었다. 문제는 구현 방식이었다.

당시 SOA는 실제로 산업 전반을 휩쓸었다.
많은 기업들이 재사용성과 조직 간 협업을 개선하기 위해 이 아키텍처를 도입했다.

하지만 결과는 기대와 달랐다.

설계와 구현에 지나치게 많은 시간이 들었고,
구조는 복잡해졌으며,
비용은 크게 증가했다.

결국 많은 프로젝트가 실패로 이어졌고,
SOA는 점점 산업에서 외면받기 시작했다.

Mark Richards의 표현을 빌리면,
SOA는 “크고, 비싸고, 복잡하며, 구현까지 너무 오래 걸리는 아키텍처”였다.
이 지점이 중요하다.

문제는 아이디어가 아니라,
그 아이디어를 구현하는 방식이었다.

SOA의 표준 스택은 SOAP(Simple Object Access Protocol), WSDL(Web Services Description Language), 그리고 ESB(Enterprise Service Bus)로 이루어졌다. 이론상 ESB는 서비스 간 통신을 중앙에서 조율하는 지능형 미들웨어였다. 라우팅, 변환, 오케스트레이션을 한 곳에서 처리한다는 개념이었다.

실제로는 달랐다.

ESB가 비즈니스 로직과 라우팅 규칙을 무분별하게 흡수하며 비대해질수록, 개별 서비스들은 ESB에 강하게 종속되었다. 이른바 '스마트 파이프, 덤 엔드포인트(Smart pipes, dumb endpoints)'의 함정에 빠진 것이다. 서비스 자체의 응집도는 무너졌고, 시스템의 제어권은 다시 중앙으로 집중되었다. 분산 시스템을 만들겠다며 모놀리스를 쪼갰지만, 결국 ESB라는 이름의 거대한 '단일 장애점(SPOF, Single Point of Failure)'을 중앙에 다시 세운 꼴이 되었다.

SOAP와 WSDL은 XML 스키마 지옥이었다. 서비스 하나를 추가하려면 WSDL을 작성하고, 스텁을 생성하고, 양쪽 계약을 맞추는 데 며칠이 걸렸다. "서비스를 쉽게 추가할 수 있어야 한다"는 SOA의 약속과 현실의 간극이 컸다.

SOA의 실패는 기술보다 철학의 실패였다. 서비스를 나눴지만 결합도를 실질적으로 낮추지 못했고, 복잡성을 줄이려다 ESB라는 새로운 복잡성을 만들었다.

마이크로서비스 진영은 다른 접근을 택한다. “스마트 엔드포인트, 덤 파이프”다.

애플리케이션은 가능한 한 느슨하게 결합되면서도, 각 서비스는 높은 응집도를 유지하도록 설계된다. -Martin Fowler²

이 실패의 교훈이 이후 MSA의 반면교사가 된다. MSA가 "스마트 엔드포인트, 덤 파이프(Smart endpoints, dumb pipes)"를 핵심 원칙으로 내세우는 이유가 바로 여기에 있다.

3. Amazon의 전환점 - 2002년 Bezos Mandate

SOA가 엔터프라이즈 진영에서 실패를 향해 달려가던 2002년, Amazon 내부에서 역사적인 메일이 하나가 돌았다.

(Steve Yegge이 공개한 아마존 내부 지침 회고³)

오늘날 "Bezos Mandate" 또는 "Bezos API Memo"로 불리는 내부 지침이다. 핵심 내용은 다음과 같다.

1. -모든 팀은 데이터와 기능을 서비스 인터페이스를 통해 노출해야 한다.

2. -팀은 이 인터페이스를 통해서만 통신해야 한다.

3. -다른 통신 방식은 허용하지 않는다. 직접 링킹, 직접 DB 읽기, 공유 메모리 모델 없음.

4. -어떤 기술을 사용하든 상관없다. HTTP, Corba, Pubsub, 뭐든.

5. -예외 없음.

6. -이걸 안 지키면 해고다.

이 규칙이 중요한 이유는 기술 스택이 아니라 강제력에 있다.

당시 Amazon은 거대한 모놀리식 시스템 위에서 성장하고 있었다.
팀들은 서로의 데이터베이스를 직접 읽고,
내부 API 없이 라이브러리를 직접 연결하는 방식으로 기능을 붙였다.

Bezos Mandate는 이 연결 방식을 끊어냈다.

모든 기능을 API 뒤에 두고,
팀 간 통신을 네트워크 기반 서비스 인터페이스로 강제했다.

처음에는 내부 결합도를 줄이기 위한 규칙이었다.
하지만 이 변화는 Amazon이 자기 내부 기능을 “서비스”로 사고하게 만드는 계기가 됐다.

Yegge의 표현처럼,
이후 Amazon은 모든 설계를 services-first 방식으로 바라보는 조직으로 바뀌었다.

그 연장선에서 인프라 기능 역시 API로 제공 가능한 서비스가 되었고,
2006년 S3와 EC2 출시로 이어지는 AWS의 토대가 마련됐다.

모놀리스를 부수기 위해 만든 내부 규칙이,
결과적으로 클라우드 컴퓨팅 시대의 중요한 기반 중 하나가 된 것이다.

4. Netflix - 혼돈으로 만든 탄력성

2008년 Netflix는 심각한 데이터베이스 손상 사고를 겪었다.

(넷플릭스의 회고글⁴)

Netflix는 2016년 회고 글에서, 2008년 데이터베이스 손상 사고로 3일 동안 DVD 배송이 중단됐고,

이 사건이 7년에 걸친 AWS 마이그레이션의 출발점이 됐다고 설명한다.

3일 동안 DVD 배송이 멈췄다. 이 사건은 Netflix 엔지니어링 팀에게 두 가지를 각인시켰다.

첫째, 중앙화된 단일 시스템은 하나의 장애가 전체 서비스를 중단시킬 수 있다.
둘째, 장애는 예방할 수 없다. 장애 속에서도 살아남는 시스템을 만들어야 한다.

2009년 Netflix는 데이터센터에서 AWS로의 마이그레이션을 시작했다. 단순한 인프라 이전이 아니었다. 모놀리식 시스템을 수백 개의 마이크로서비스로 분해하는 7년짜리 여정이었다.

이 과정에서 Netflix는 몇 가지 핵심 도구를 만들었다.

월요일, Netflix는 “Chaos Monkey”라는 소프트웨어를 오픈소스로 공개했다.
이 도구는 스트리밍 서비스를 구성하는 가상 머신들을 무작위로 종료시키는 프로그램으로,
서비스가 일상적으로 겪게 되는 작은 장애들을 시뮬레이션하기 위한 것이다.
즉, 누구나 이 도구를 사용하거나, 심지어 소스 코드를 수정해서 활용할 수도 있다는 뜻이다. -- Wired, “Netflix Abuses Amazon With Monkeys. Now You Can Too”, 2012 ⁵

Chaos Monkey. 프로덕션 환경에서 임의로 인스턴스를 종료하는 자동화 도구. "장애를 견딜 수 있는 시스템인지 확인하는 가장 좋은 방법은 실제로 장애를 일으켜 보는 것"이라는 아이디어에서 출발했다. Chaos Monkey의 존재 자체가 엔지니어들로 하여금 장애를 전제한 코드를 짜게 만들었다.

Eureka. 서비스 레지스트리. 수백 개의 서비스 인스턴스가 동적으로 뜨고 내려가는 환경에서 각 서비스가 서로를 어떻게 찾는가의 문제를 해결했다.

(Hystrix를 소개하는 Netflix 블로그⁶)

Hystrix. 서킷 브레이커 라이브러리. 의존 서비스가 느려지거나 죽었을 때 해당 서비스를 향한 요청을 빠르게 실패(Fail Fast)시켜 전체 시스템으로 장애가 전파되는 것을 막는다.

Netflix는 이것들을 2012년에 오픈소스로 공개했다. Netflix OSS라고 불리는 이 묶음은 당시 "마이크로서비스를 실제로 운영하는 방법"의 레퍼런스 구현이 됐다. Netflix가 만들어낸 패턴들이 이후 MSA의 표준 어휘가 됐다.

5. "Microservices" - 이름이 붙던 날

Netflix, eBay, Amazon, LinkedIn, Google - 대규모 시스템을 운영하는 조직들이 서로 다른 이름으로 비슷한 방식으로 시스템을 분해하고 있었다. 이 패턴에 이름이 필요했다.

2011년 5월, 이탈리아 베니스 근처에 모인 소프트웨어 아키텍트들은 각자 발전시켜 온 새로운 아키텍처 패턴을 공유하며 이를 'microservice'라 부르기 시작했다.⁷ 이후 2012년 James Lewis가 컨퍼런스에서 이를 공식적으로 발표하고, 2014년 Martin Fowler와 함께 작성한 아티클을 통해 이 개념이 산업의 표준 언어로 굳어지게 되었다.

• 단일 책임을 가진 작은 서비스들의 집합

• 프로세스로 격리되고 HTTP API 같은 경량 메커니즘으로 통신

• 각 서비스가 독립적으로 배포 가능

• 다른 서비스와 다른 언어, 다른 데이터 저장소를 가질 수 있음 (Polyglot)

• 중앙화된 오케스트레이션보다 각 서비스의 자율성 우선

주목할 점은 이 글이 MSA를 "발명"한 것이 아니라는 사실이다. Amazon, Netflix, eBay는 이미 이 패턴을 수년째 운영하고 있었다. Fowler와 Lewis의 기여는 산업에 공통 언어를 부여한 것이다. 이름이 붙자 커뮤니티가 형성됐고, 패턴이 빠르게 확산됐다.

같은 2011년, Heroku의 Adam Wiggins가 12-Factor App⁸ 방법론을 발표했다. 클라우드 환경에서 SaaS를 만들 때 지켜야 할 12가지 원칙이다.

코드베이스, 의존성, 설정, 백킹 서비스, 무상태 프로세스 등, 이 원칙들은 MSA가 실제로 작동하기 위한 운영 기반을 명시했다.

6. 컨테이너 혁명 - 인프라가 따라왔다

MSA를 개념으로 이해하는 것과 실제로 운영하는 것 사이에는 큰 간극이 있었다. 수백 개의 서비스를 배포하고, 격리하고, 버전 관리하는 것은 기존 인프라로는 너무 복잡하고 비쌌다.

2013년, Docker가 이 문제를 해결했다.

"Hey everyone... I'm Solomon, I work at dotCloud[00:08]... we've been working on open sourcing that [Linux containers] and we haven't shown it to anyone[02:06]... this is actually the first time we show anything outside of the dotCloud office so it's probably going to blow up on me.[02:11]" - Solomon Hykes,

"The future of Linux Containers" (PyCon 2013 Lightning Talk)⁹

안녕하세요 여러분... 저는 dotCloud에서 일하는 솔로몬입니다[00:08]... 우리는 리눅스 컨테이너를 오픈소스로 만드는 작업을 해왔고... 아직 아무에게도 보여준 적이 없습니다[02:06]... dotCloud 사무실 밖에서 무언가를 보여드리는 것은 이번이 처음이라 아마 폭망할지도 모르겠네요.[02:11]

-Solomon Hykes

Solomon Hykes가 PyCon 2013에서 5분짜리 데모로 Docker를 소개했을 때, 많은 사람들이 "이게 뭔지는 모르겠는데 중요한 것 같다"는 반응을 보였다. 컨테이너라는 개념 자체는 새것이 아니었다. Linux의 cgroups와 namespaces는 이미 존재했다. Docker의 혁신은 컨테이너를 개발자가 실제로 쓸 수 있는 도구로 만든 것이었다.

Docker 이후 MSA의 각 서비스를 독립적인 컨테이너로 패키징하는 것이 가능해졌다. 의존성을 이미지 안에 격리하고, 동일한 이미지를 개발 환경과 프로덕션 환경에서 동일하게 실행할 수 있었다.

그러자 다음 문제가 나타났다. 수백 개의 컨테이너를 어떻게 관리하는가.

2014년 Google이 Kubernetes를 발표했다.

We present a summary of the Borg system architecture and features, important design decisions, a quantitative analysis of some of its policy decisions, and a qualitative examination of lessons learned from a decade of operational experience with it.

우리는 Borg 시스템 아키텍처와 특징, 중요한 설계 결정, 일부 정책 결정에 대한 정량적 분석, 그리고 10년간의 운영 경험에서 얻은 교훈에 대한 정성적 검토를 제시합니다.

참조: Large-scale cluster management at Google with Borg (2015)¹⁰

구글은 이미 10여 년 전부터 매주 수십억 개의 컨테이너를 구동하고 관리하는 내부 시스템 'Borg(보그)'를 운영하고 있었다.

쿠버네티스는 바로 이 Borg의 유산이다.

Docker와 Kubernetes의 조합은 MSA를 실행 가능한 것으로 만들었다. 이전에는 Netflix 규모의 인프라 팀이 있어야 가능했던 것들을 작은 팀도 할 수 있게 됐다.

여담: 이름에 숨겨진 메타포와 영미권의 말장난

쿠버네티스(Kubernetes)라는 단어 자체는 고대 그리스어로 '조타수(Helmsman)' 또는 '선장'을 뜻한다. 여기에는 구글의 엄청난 세계관과 은유가 숨어 있다.

Docker의 로고를 떠올려 보면 '컨테이너(화물)를 싣고 바다를 헤엄치는 고래(선박)'이다. 쿠버네티스는 이 바다에 둥둥 떠다니는 수백, 수천 개의 컨테이너 박스(Docker)들이 엉키지 않고 올바른 목적지로 가도록 전체 선단을 지휘하는 조타수 역할을 하겠다는 의미이다. (실제로 공식 로고도 파란색 '배의 조타륜(Steering Wheel)' 모양이다.)

보통 Kubernetes는 'k8s'라고도 불리는데, 'K'와 's' 사이에 정확히 8개의 알파벳(u-b-e-r-n-e-t-e)이 들어있기 때문에 이를 확 줄여서 부르는 것이다. 영어권에서는 보통 "케이-에이츠(K-eights)"라고 발음한다.

사실 이런 축약 방식은 IT 업계의 꽤 오래된 관행인 '숫자어(Numeronym)' 패턴이다. 긴 단어를 매번 타이핑하기 귀찮으니 첫 글자와 끝 글자만 남기고 중간을 숫자로 퉁치는 식이다.

• i18n: internationalization (국제화) → i + 18글자 + n

• a11y: accessibility (접근성) → a + 11글자 + y

• o11y: observability (관찰 가능성) → o + 11글자 + y

다만, 가벼운 로컬/엣지용으로 널리 쓰이는 K3s는 약어가 아니다. K3s를 처음 만든 Rancher Labs(현재 SUSE)의 개발자들은 "쿠버네티스의 메모리 풋프린트와 바이너리 크기를 정확히 절반으로 줄인 버전을 만들자!"라는 목표를 세웠다.

10글자(Kubernetes)의 절반은 5글자이고, 이 5글자를 아까의 숫자어 규칙대로 압축하면? K + 3글자 + s = k3s가 된다는 기적의 논리를 가지고 있다.

이래서 영미권이 아닌 개발자들은 개발이 참 어렵다.

7. 현재 - 다음 문제들

MSA가 확산되면서 새로운 문제들이 전면에 나타났다.

관찰 가능성(Observability). 요청 하나가 10개 서비스를 거쳐 처리될 때, 어느 서비스에서 지연이 발생했는지 어떻게 알 수 있는가. 단일 프로세스에서는 스택 트레이스 하나로 보이던 것이 MSA에서는 서비스 경계마다 흔적이 끊긴다. 분산 트레이싱(Jaeger, Zipkin, OpenTelemetry)이 이 문제를 해결하기 위한 도구들이다.

서비스 메시(Service Mesh). 서비스 수가 많아지면 서비스 간 통신 정책(암호화, 재시도, 타임아웃, 서킷 브레이커)을 각 서비스마다 구현하는 것이 비효율적이다. Istio, Envoy, Linkerd는 이 로직을 사이드카 프록시로 분리해 서비스 코드 바깥에서 처리한다.

분산 모놀리스(Distributed Monolith). MSA의 가장 흔한 함정이다. 서비스를 여러 개로 나눴는데 서비스들이 서로를 동기적으로 긴 체인으로 호출하면 — A가 B를 호출하고, B가 C를 호출하고, C가 D를 호출하고 — 사실상 하나의 요청이 모든 서비스를 직렬로 통과한다. 한 서비스가 느려지면 체인 전체가 멈춘다. 모놀리스를 분산 환경으로 옮겼을 뿐, 결합도는 전혀 낮아지지 않은 것이다.

이 함정이 중요한 이유는 MSA의 핵심 목표인 "독립 배포"와 "독립 스케일링"이 모두 서비스 경계의 올바른 설정에 달려 있기 때문이다. 경계를 잘못 잡으면 분산의 복잡성만 얻고 이점은 없다.

여기서 중요한 점은, MSA를 단순히 “더 좋은 아키텍처”로 보면 안 된다는 것이다.
모놀리스 -> SOA -> MSA로 이어지는 흐름은
더 나은 정답을 찾아가는 과정이 아니라,

각 단계마다 다른 종류의 복잡성을 선택하는 과정이다.

프로그래밍이란 본질적으로 선택 가능한 상태 공간을 줄이는 일이다.
아키텍처 또한 마찬가지다. 코드 한 줄을 적을때마다 자유도를 제한하며 그것이 우리의 요구와 얼마나 일치하는지 그 제한을 해 나가는 과정이 프로그래밍이다.

모놀리스는 배포와 스케일의 자유도를 포기하는 대신 단순성을 얻었고,
SOA는 서비스 분리를 시도했지만 중앙화된 제어를 선택했다.
MSA는 중앙화를 포기하는 대신 운영 복잡성을 감수했다.

즉 MSA는 “더 좋은 구조”가 아니라,
다른 종류의 제약을 선택한 결과다.

마치며 - 역사에서 읽히는 패턴

MSA의 역사를 한 문장으로 요약하면 이렇다.

모놀리스의 결합도 문제에서 시작해, SOA의 과도한 중앙화를 피하면서, 클라우드와 컨테이너 인프라 위에서 실용적인 형태로 안착한 아키텍처.

역사에서 읽히는 패턴이 있다.

각 계층은 이전 계층의 문제를 해결하면서 새로운 문제를 만들었다. 기술 진화는 항상 이 방식으로 움직인다.

따라서 누군가 "우리도 MSA로 가야 할까요?"라고 묻는다면, 그것은 질문이 틀렸다. 아키텍처에 무조건적인 정답이나 은환탄(Silver Bullet)은 존재하지 않는다.

올바른 질문은 이것이다. "우리의 현재 비즈니스 규모와 조직 구조가, MSA가 요구하는 거대한 '운영 복잡성'이라는 청구서를 지불할 만큼 배포와 스케일링의 자유도가 절실한 상태인가?"

외양간에 소가 한 마리도 없다면 모놀리스의 단순성이 정답이다. 하지만 트래픽과 개발 조직이 폭발적으로 성장하여 기존의 결합도를 감당할 수 없는 임계점에 도달했다면, 그때는 기꺼이 컨테이너와 분산 시스템의 복잡성을 선택해야 한다.

결국 시스템 아키텍처를 설계한다는 것은 완벽한 구조를 찾는 여정이 아니다. 지금 우리 조직이 감당할 수 있는, 혹은 감당해야만 하는 '고통의 종류'를 현명하게 선택하는 일일 뿐이다.

하지만 인간은 늘 잘못된 선택을 반복한다.

문제가 없는데도 있어 보인다는 이유로 MSA를 도입하고,
문제가 명확한데도 익숙하다는 이유로 모놀리스를 유지한다.

기술은 선택의 문제지만,
대부분의 실패는 선택이 아니라 판단에서 나온다.