# 마이크로서비스는 왜 실패했는가: 모듈러 모놀리스로의 회귀

# 마이크로서비스는 왜 실패했는가: 모듈러 모놀리스로의 회귀  마이크로서비스는 확장성의 해법이 아니라 복잡성의 이전이었다. 분산 시스템의 본질적 어려움과 조직의 현실 사이 괴리가 드러나면서, 산업은 모듈러 모놀리스라는 절충안으로 향하고 있다. 이는 기술적 후퇴가 아닌, 아키텍처 선택에 대한 성숙한 사유의 결과다. ## 환상의 붕괴: 마이크로서비스가 약속한 것들  마이크로서비스 아키텍처는 2010년대 중반, 모놀리스의 한계를 극복할 해법으로 등장했다. Netflix와 Amazon의 성공 사례는 설득력 있는 서사를 제공했다. 독립적 배포, 기술 스택의 자유, 팀 자율성, 그리고 무엇보다 '무한한 확장성'이라는 약속. 이 약속들은 논리적으로 타당해 보였다. 하지만 약속과 현실 사이에는 본질적 간극이 존재했다. 마이크로서비스는 문제를 해결하지 않았다. 단지 문제의 위치를 이동시켰을 뿐이다. 모놀리스에서 단일 프로세스 내부의 복잡성으로 존재하던 문제가, 마이크로서비스에서는 네트워크 경계를 넘나드는 분산 시스템의 복잡성으로 변환되었다. 대부분의 조직은 후자가 전자보다 훨씬 다루기 어렵다는 사실을 뒤늦게 깨달았다. 문제는 아키텍처 자체의 결함이 아니었다. 마이크로서비스를 필요로 하지 않는 맥락에서 마이크로서비스를 선택했다는 점, 그리고 그 선택이 가져올 복잡성을 과소평가했다는 점이 본질이었다.  ## 실패의 해부학: 세 가지 구조적 모순 ### 분산 시스템의 본질적 어려움 마이크로서비스는 필연적으로 분산 시스템이다. 분산 시스템은 네트워크 지연, 부분 장애, 데이터 일관성이라는 세 가지 근본적 문제를 내포한다. 모놀리스에서는 메서드 호출로 끝나던 작업이, 마이크로서비스에서는 HTTP 요청, 재시도 로직, 타임아웃 처리, 서킷 브레이커 패턴을 요구한다.  Segment의 사례는 이를 명확히 보여준다. 그들은 2017년 마이크로서비스 아키텍처를 모놀리스로 재통합했다. 이유는 단순했다. 분산 트랜잭션의 복잡성이 얻는 이점을 압도했기 때문이다. 여러 서비스에 걸친 데이터 일관성 유지는 이론적으로는 Saga 패턴이나 2PC(2-Phase Commit)로 해결 가능하지만, 실무에서는 디버깅 불가능한 엣지 케이스와 보상 트랜잭션 로직의 폭발적 증가를 의미했다. 네트워크는 신뢰할 수 없다. 이는 분산 시스템 설계의 제1원칙이다. 그러나 대부분의 조직은 이 원칙을 코드로 구현하는 데 필요한 엔지니어링 역량을 과대평가했다.  ### 운영 복잡성의 기하급수적 증가 서비스가 N개로 늘어나면, 운영 복잡성은 N²에 비례해 증가한다. 각 서비스는 독립적인 배포 파이프라인, 모니터링 대시보드, 로깅 시스템, 장애 알림을 요구한다. 10개의 서비스는 단순히 10개의 배포가 아니라, 서비스 간 상호작용을 추적해야 할 90개의 잠재적 장애 지점을 의미한다. Shopify의 엔지니어링 팀은 2019년 블로그 포스트에서 이를 고백했다. 마이크로서비스 도입 초기, 그들은 배포 속도 향상을 기대했다. 실제로는 배포 조율의 오버헤드가 속도 향상을 상쇄했다. 서비스 A의 API 변경은 서비스 B, C, D의 동시 배포를 요구했고, 이는 결국 모놀리스보다 느린 릴리스 주기로 이어졌다. 분산 추적(distributed tracing)은 이 문제의 해법으로 제시되지만, 이 역시 새로운 복잡성의 층을 추가할 뿐이다. Jaeger나 Zipkin 같은 도구를 도입하면 요청 흐름을 시각화할 수 있지만, 그 시각화를 해석하고 장애 지점을 식별하는 것은 여전히 인간의 몫이다. 대부분의 팀은 이를 위한 전문 인력을 보유하지 못했다.  ### 조직 구조와 아키텍처의 불일치 Conway의 법칙은 "시스템 설계는 조직의 커뮤니케이션 구조를 닮는다"고 말한다. 역으로, 마이크로서비스는 조직이 이미 분산되어 있을 때 작동한다. Amazon이나 Netflix처럼 수백 개의 독립적 팀이 존재하고, 각 팀이 명확한 비즈니스 도메인을 소유할 때 마이크로서비스는 조직 구조와 일치한다. 그러나 10~50명 규모의 엔지니어링 조직에서 마이크로서비스를 도입하면, 인위적 경계가 생성된다. 한 명의 개발자가 여러 서비스를 담당하거나, 한 기능 구현을 위해 세 개 서비스의 코드를 동시에 수정해야 하는 상황이 발생한다. 이는 마이크로서비스의 핵심 가치인 팀 자율성을 무효화한다. Etsy는 2018년 기술 블로그에서 이를 명시적으로 인정했다. 그들의 조직 크기에서 마이크로서비스는 커뮤니케이션 오버헤드를 증가시켰고, 결정 속도를 저하시켰다. 모놀리스로 회귀한 후, 팀 간 조율 비용이 감소하고 기능 개발 속도가 회복되었다. ## 모듈러 모놀리스: 절충의 지혜 모듈러 모놀리스는 타협이 아니라 원칙의 재발견이다. 단일 배포 단위(모놀리스)의 운영 단순성과, 명확한 모듈 경계(마이크로서비스의 이상)를 결합한 아키텍처다. 핵심은 물리적 분리 대신 논리적 분리에 의존한다는 점이다. ### 경계의 강제: 컴파일 타임 보장 모듈러 모놀리스에서 모듈 간 경계는 패키지 구조, 접근 제어자, 의존성 규칙으로 강제된다. Java의 경우 `module-info.java`를 통해 모듈 간 의존성을 명시적으로 선언하고, 허용되지 않은 접근을 컴파일 타임에 차단할 수 있다. 이는 마이크로서비스의 네트워크 경계가 제공하는 격리를 코드 레벨에서 재현한다. Shopify는 이를 위해 `packwerk`라는 도구를 개발했다. Ruby 코드베이스에서 패키지 간 의존성을 정의하고, 위반 사항을 CI에서 검증한다. 결과적으로 마이크로서비스 없이도 모듈 간 계약을 강제할 수 있게 되었다. 이는 런타임 장애 대신 컴파일 타임 오류로 문제를 전환시킨다. ### 운영의 단순성: 단일 배포, 단일 데이터베이스 모듈러 모놀리스는 단일 프로세스로 실행된다. 배포 파이프라인이 하나, 로그 파일이 하나, 모니터링 대상이 하나다. 분산 추적 대신 스택 트레이스로 문제를 진단할 수 있고, 트랜잭션은 ACID 보장을 그대로 활용한다. 데이터베이스 역시 단일 인스턴스를 유지할 수 있다. 마이크로서비스에서 각 서비스가 독립적 데이터베이스를 가져야 한다는 원칙은, 실제로는 데이터 일관성 문제의 근원이었다. 모듈러 모놀리스는 스키마 레벨에서 모듈을 분리하되(예: PostgreSQL의 schema 기능), 필요시 JOIN과 트랜잭션을 사용할 수 있는 여지를 남긴다. ### 점진적 진화: 필요할 때 분리하라 모듈러 모놀리스의 가장 큰 장점은 미래의 선택지를 열어둔다는 점이다. 특정 모듈이 정말로 독립적 확장을 필요로 할 때, 그 모듈만 별도 서비스로 추출할 수 있다. 명확한 모듈 경계는 이 추출 과정을 기계적으로 만든다. Basecamp는 이 전략을 명시적으로 채택했다. 그들의 모놀리스는 명확히 정의된 모듈로 구성되어 있으며, 트래픽이 급증하는 특정 기능만 별도 서비스로 분리했다. 이는 "처음부터 모든 것을 마이크로서비스로"라는 접근보다 훨씬 낮은 위험으로 확장성을 확보하는 방법이었다. ## 선택의 기준: 언제 무엇을 선택할 것인가 아키텍처 선택은 기술적 우월성의 문제가 아니라 맥락 적합성의 문제다. 마이크로서비스는 잘못된 아키텍처가 아니다. 잘못된 맥락에서 적용되었을 뿐이다. ### 마이크로서비스가 정당화되는 조건 첫째, 조직이 이미 수십 개 이상의 독립적 팀으로 구성되어 있고, 각 팀이 명확한 비즈니스 도메인을 소유할 때. 둘째, 서비스 간 트래픽 패턴이 극단적으로 비대칭적이어서, 특정 서비스만 독립적으로 확장해야 할 때. 셋째, 분산 시스템 운영에 필요한 전문 인력과 도구 체계를 갖췄을 때. Amazon이나 Netflix는 이 세 조건을 모두 충족한다. 그들에게 마이크로서비스는 필연이었다. 하지만 대부분의 조직은 이 중 어느 하나도 충족하지 못한다. ### 모듈러 모놀리스가 적합한 조건 대부분의 경우, 모듈러 모놀리스가 합리적 출발점이다. 팀 크기가 100명 이하이고, 트래픽이 단일 인스턴스로 처리 가능하며, 비즈니스 도메인 경계가 아직 명확히 정립되지 않았다면, 모듈러 모놀리스는 최소한의 복잡성으로 최대한의 유연성을 제공한다. 핵심은 모듈 경계를 강제하는 메커니즘을 초기부터 구축하는 것이다. 이는 미래에 마이크로서비스로 전환할 가능성을 열어두면서도, 당장의 운영 복잡성을 회피할 수 있게 한다. ## 성숙한 사유의 결과 마이크로서비스에서 모듈러 모놀리스로의 전환은 기술적 퇴보가 아니다. 이는 산업이 유행에서 원칙으로 회귀하는 과정이다. 아키텍처는 문제를 해결하는 도구이지, 그 자체로 목적이 아니다. Segment, Shopify, Etsy의 회귀 사례는 실패의 고백이 아니라 학습의 증거다. 그들은 자신의 맥락에서 무엇이 작동하는지 발견했고, 이전 선택을 수정할 용기를 가졌다. 이것이 엔지니어링의 본질이다. 결국 중요한 것은 아키텍처의 이름이 아니라, 그 아키텍처가 조직의 현실과 비즈니스 요구에 얼마나 정렬되는가다. 모듈러 모놀리스는 이 정렬을 더 적은 비용으로 달성할 수 있는 경로를 제시한다. 그리고 그것으로 충분하다.