본문 바로가기
MSA (Micro Service Architecture)/Legacy to Domain-Driven Platform

MSA Trend 2026

by kellis 2026. 6. 16.

개발자라면 한번쯤은 들어봤을 MSA - Microservice Architecture 

 

대략 2010년대 중반부터 업계를 휩쓴 이 개념은, "현대적인 서비스라면 당연히 가야 할 방향"처럼 여겨졌다.

그런데 2026년 현재, MSA에 조금 다른 분위기가 드러나고 있다. 업계 조사에서는 MSA를 도입했던 조직의 절반 가까이가 다시 통합하는 방향으로 돌아서고 있다는 데이터가 나오고 있고, "Modular Monolith"나 "Vertical Slice" 같은 키워드가 다시 주목받기 시작했다.

 

도대체 무슨 일이 있었던 걸까? MSA는 어디서 시작됐고, 왜 그렇게 빠르게 퍼졌으며, 지금은 왜 흔들리고 있는 걸까?

이 글에서는 그 흐름을 처음부터 차근차근 짚어보려 한다.

 

1. 시작은 모놀리스였다 — 그리고 그것이 문제가 됐다

 

1-1 모놀리스란 무엇인가

초창기 애플리케이션은 대부분 모놀리식 아키텍쳐(Monolithic Architecture)로 만들어졌다. 개념 자체는 단순하다. 

쇼핑몰 서비스 하나를 만든다고 가정해보자.

- 회원가입  - 상품조회  - 장바구니  - 결제  - 배송조회 ... 

 

이 모든 기능이

  • 하나의 코드 저장소에 담겨 있고,
  • 하나의 서버에서 실행되며,
  • 하나의 데이터베이스를 함께 사용한다.
  • 배포 역시 한 번에 전체를 올린다.

=> 이것이 바로 모놀리스이다.

 

처음에는 이것이 나쁜 구조가 아니었고, 장점이 많았다. 

팀이 작을 때는 모든 코드가 한 곳에 있으니 이해하기가 쉬웠고, 로컬 환경에서 그냥 실행하면 전체 서비스가 돌아가니 개발도 편하다. 로그도 다 한 곳에 모이며, 에러가 나도 어디에서 났는지 찾기가 상대적으로 간단하다. 

 

서버 규모가 작고, 5~10인 수준의 소규모 팀이라면 모놀리스는 충분히 좋은 선택이 될 수 있다. 

 

 

1-2 그런데 서비스가 커지기 시작했다.


문제는 서비스의 규모가 커지면서부터 시작되었다. 

사용자가 늘어나고, 기능이 추가되고, 팀 규모가 커지면서 모놀리스는 점차 감당하기 어려운 구조가 되어갔다. 

  • 배포가 두려워졌고 
    •  버튼색상하나만 바꿔도 전체 애플리케이션을 빌드하고 배포 -> 서비스 일시중단 
  • 특정 부분만 키울 수 없었고
    • 쇼핑몰에서 이벤트를 하면 상품 조회 트래픽이 폭발적으로 증가하는데 상품 조회만 서버 증량하는 것은 불가능
    • 전체 애플리케이션을 통째로 여러 대 서버에 복제 -> 비효율적이며 고비용 
  • 팀이 서로를 방해했으며
    • 개발자가 50명, 100명 늘어나면서 같은 코드베이스를 여러 팀이 동시에 건드림 -> 잦은 충돌, 상시 배포일정 조율
  • 한 곳의 버그가 전체를 죽였다
    • 서비스 일부의 문제가 전체 서비스 장애로 이어짐 

 

 

1-3 아마존의 지침

 

2000년대 초반, 이 문제를 가장 먼저, 극단적인 형태로 겪은 것이 아마존이었다. 

당시 Amazon의 코드베이스는 수천 명의 엔지니어가 함께 작업하는 거대한 모놀리스였다. 한 팀이 배포하려면 다른 모든 팀의 코드 변경이 없어야 했다. 서로가 서로의 발목을 잡는 구조와 같았다. 

 

제프 베조스는 이 문제를 해결하기 위해 유명한 지침을 내렸다.

"모든 팀은 데이터와 기능을 서비스 인터페이스를 통해서만 노출해야 한다. 다른 방법으로 통신하는 것은 허용되지 않는다. 이 규칙을 지키지 않는 사람은 해고된다."

 

이 것이 MSA의 씨앗이었다. 

 

 

 

2. SOA라는 전임자가 있었다 — 이것은 왜 실패했나

 

2-1 MSA 이전의 시도, SOA

당연하게도 "서비스를 나누자" 라는 생각이 MSA에서 처음 나온 것은 아니다. 2000년대 중반, 

SOA (Service-Oriented Architecture) - 서비스 지향 아키텍처 라는 개념이 먼저 나타났다.

 

SOA의 핵심 아이디어는 MSA와 비슷하다. 큰 시스템을 여러 개의 서비스로 나누고, 각 서비스가 독립적으로 기능을 담당하게 하자는 것. 당시 꽤 많은 대기업들이 SOA를 도입하기 시작했다. 

 

2-2 SOA가 실패한 이유 - ESB라는 괴물 

 그러나 SOA에는 치명적인 문제가 있었다. ESB (Enterprise Service BUS) - 엔터프라이즈 서비스 버스 라는 개념때문이었다. 

쉽게 비유하자면,  

 

회사 내 여러 부서(서비스)가 서로 소통하려면 중간에 총무팀(ESB)를 거쳐야 한다고 가정해보자. 

영업팀이 회계팀에 전달할 내용이 있으면 총무팀에 전달하여야 하는 것이다. 

처음에는 정돈된 것처럼 보이지만, 부서가 늘어나면 늘어날수록 총무팀은 바빠지고 복잡해진다. 그리고 어느 순간 총무팀이 멈춰버리게 되면 회사 전체의 소통이 멈춘다. 

 

ESB는 서비스 간의 모든 통신을 담당해야했고, 각종 변환 로직과 비즈니스 규칙이 ESB에 집중되었다. 

ESB는 그 자체로 점점 복잡해지고 비대해졌다. 그리고 ESB에 장애가 나면 전체 시스템이 멈췄다. 

서비스를 나누려던 시도가 오히려 더 강한 중앙 의존성을 만들어 버린것이다.

 

MSA는 이 교훈을 흡수했다. 

"Smart Endpoints, Dumb Pipes"
"중앙 집중된 브로커는 필요없다. 서비스들이 직접 HTTP API로 서로 통신하면 된다.
파이프는 단순하게, 서비스 자체를 똑똑하게 만들어라"

 

 

 

 

3. MSA의 등장과 확산 — 넷플릭스가 불을 붙이다

 

3-1 넷플릭스의 사고 

MSA가 업계의 주류로 자리잡는 데에 가장 큰 계기를 제공한 곳이 바로 넷플릭스이다. 

2008년, 넷플릭스는 심각한 데이터베이스 장애를 겪었고, 이 장애로 인해 무려 3일 동안 DVD의 배송이 완전히 중단되었다. 

모놀리식 구조에서 DB 하나가 죽자, 전체 서비스가 마비된 것이다. 

 

넷플릭스는 이후 수년에 걸쳐 거대한 모놀리스를 하나씩 해체하기 시작했다.

AWS 클라우드로 이전하면서 각 기능들을 독립적인 서비스로 분리했고, 2012년, 넷플릭스는 하루 10억 건 이상의 API 호출을 처리하는 500개 이상의 마이크로서비스 기반 시스템을 완성했다.

 

이 과정에서 무엇보다 중요한 건, 넷플릭스가 이 과정에서 자체 개발한 도구들을 오픈소스로 공개했다는 점이다. 

 

  • Eureka : 서비스들이 서로를 찾을 수 있게 도와주는 서비스 디스커버리
  • Hystrix : 한 서비스의 장애가 다른 서비스로 번지지 않게 막아주는 서킷 브레이커
  • Zuul : 외부 요청을 적절한 서비스로 라우팅해주는 API 게이트웨이
  • Chaos Monkey : 의도적으로 서버를 죽이면서 시스템 복원력을 테스트하는 도구 

 

3-2 .MSA에 이름이 붙다 - Martin Fowler 

2014년 3월, 소프트웨어 아키텍쳐 분야의 권위자인 Martin Fowler와 James Lewis가 Microservices라는 제목의 글을 게재했다. 

이 글은 마이크로서비스 아키텍처의 개념을 명확히 정의하고, 그 특징과 장단점을 체계적으로 설명한 최초의 공식문서였다. 

 

이는 전세계 개발자들의 필독서가 되었으며, 막연하게 "서비스를 나누는것"으로만 알려져 있던 개념이 드디어 이름과 정의를 얻게 되었다. 

같은 해, MSA를 현실적으로 구현하는 데 필요한 도구들도 쏟아져 나왔다. 

 

  • Docker : 서비스를 컨테이너화하여 어디에서나 동일하게 실행가능하도록 만들어줌
  • Kubernetes : Google의 컨테이너 오케스트레이션 플랫폼. 수십, 수백개 컨테이너를 자동 관리
  • Spring Boot : Java 기반 마이크로서비스를 빠르게 만들 수 있는 프레임워크

 

MSA가 말이 되는 시대가 본격적으로 열린 것이다. 

 

 

 

 

4. MSA의 전성기 — 쪼개지 않으면 뒤쳐진다

2015년부터 2020년대 초반까지, MSA는 소프트웨어 업계에서 거의 종교적인 지위를 얻었다. 

 

4-1 MSA가 내건 약속들 

MSA가 그토록 매력적으로 여겨진 데에는 아래와 같은 약속들이 실제로 설득력 있었기 때문이다. 

 

  • 독립배포 (Independent Deployment)
    • 각 서비스들을 독립적으로 배포할 수 있다. 배포주기가 빨라지고, 배포에 대한 두려움 감소
  • 독립 스케일링(Independent Scaling)
    • 트래픽이 특정 서비스에 몰린다면, 해당 서비스만 늘리면 된다. 훨씬 효율적이고 비용 감소
  • 기술 선택의 자유 (Technology Diversity)
    • 각 서비스가 가장 적합한 기술 스택을 선택할 수 있다. 실시간 처리가 필요한 서비스, 대용량 데이터 분석이 필요한 서비스, 고성능 서비스 등등. 데이터베이스도 서비스마다 다르게 선택할 수 있다. 
  • 팀 자율성 (Team Autonomy)
    • 서비스 단위로 팀이 나뉘어, 각 팀이 자신의 서비스를 온전히 소유하고 책임진다. 이는 Conway's Law (시스템의 구조는 그것을 만든 조직의 소통 구조를 닮는다) 법칙을 의도적으로 활용하는 전략이기도 했다. 

 

Uber, Spotify, Twitter, Airbnb 같은 실리콘밸리의 상징적인 기업들이 MSA를 도입하고 그 성과를 공유했다.

 "저 기업들이 저렇게 하니까, 우리도 저렇게 해야 현대적인 기업이다"는 분위기가 업계 전반에 빠르게 퍼졌다.

 

 

 

 

5. 균열이 시작되다 — MSA가 만들어낸 문제들

많은 팀들이 MSA를 도입하고 나서야 깨달았다. "MSA가 해결해준 문제보다, MSA가 새로 만들어낸 문제가 더 많다.

 

5-1 운영 복잡도의 폭발

모놀리스에 MSA로 전환하는 건, 단순히 코드를 나누는게 아니다. 운영해야할 모든 것이 서비스 수만큼 곱해진다.

 

하나의 서비스는 그냥 실행되는 것처럼 보이지만, 실제로는 굉장히 많은 것들이 필요하다.

 

  • 코드를 빌드하고 배포하는 CI/CD 파이프라인,
  • 외부에 노출되면 안되는 비밀 정보를 관리하는 시크릿 관리,
  • 이상이 생기면 알림을 보내는 모니터링과 알럿,
  • 무슨 일이 일어나고 있는지 추적하는 로그와 메트릭,
  • 누가 이 서비스에 접근할 수 있는지 정하는 권한 관리,
  • 데이터가 날아가지 않게 하는 백업

 

이 모든 것이 서비스 하나당 필요하다. 서비스가 10개면 이 모든 작업이 10배, 30개면 30배다.

 

 

5-2 분산 시스템의 악몽

 MSA에서 가장 과소평가됐던 문제가 바로 이 것이다.

 

모놀리스에서 회원 정보를 조회하는 건 단순한 함수 호출이다. 빠르고 실패할 이유가 없다. 

MSA에서 같은 작업은 네트워크 호출이 된다. 주문 서비스가 회원 서비스에 HTTP 요청을 보내고 응답을 기다린다. 

 

그런데 네트워크는 기본적으로 믿을 수 없는, 언제든 실패할 수 있고 느려질 수 있는 매체다. 여기서 문제가 시작된다. 

주문을 처리하는 데 

 

주문 서비스 → 회원 서비스 → 재고 서비스 → 결제 서비스 → 배송 서비스 

 

순으로 호출이 이어진다고 생각해보자. 

각 호출에서 50ms씩 지연이 생기면, 총 200ms가 쌓인다. 그리고 이 중 하나라도 실패하면 전체 흐름이 깨진다.

 

더 심각한 문제는 분산 트랜잭션이다.

모놀리스에서는 데이터베이스 트랜잭션 하나로 "주문생성" + "재고차감" + "결제처리" 를 원자적으로 처리할 수 있다. 

하나라도 실패하면 전부 롤백되니 간단한 처리였다. 

 

MSA에서는 각 서비스가 별도의 데이터베이스를 갖고 있으니, 트랜잭션으로 묶을 수 없다. 

대신 Saga 패턴같은 복잡한 보상 트랜잭션을 직접 구현해야 한다. 

결제는 됐는데 재고 차감이 실패했다면, 결제를 직접 취소하는 로직을 따로 만들어야 한다. 

구현도 복잡하고 디버깅은 더 복잡하다. 

 

2024년 DZone이 발표한 연구에 따르면, 마이크로서비스 환경의 팀이 모듈러 모놀리스 대비 디버깅에 평균 35% 더 많은 시간을 쏟는 것으로 나타났다. 

서비스 A에서 요청이 시작되어 B,C,D를 거쳐 오류가 났다면, 어디서 문제가 생겼는지 추적하는 것 자체가 거대한 작업이다. 

 

 

5-3 클라우드 비용의 현실

서비스가 10개면 서버도 적어도 10개 이상이 필요하다. 각 서비스마다 고가용성을 위해 최소 2-3개 인스턴스를 띄우면, 30개 서버가 24시간 돌아가고 있는 것이다. 

 

모놀리스 시절에는 서버 몇 대로 처리하던 것을, MSA로 가면서 수십 대의 서버와 각종 관리형 서비스들이 필요해진다. 

 

클라우드 청구서가 기하급수적으로 늘어난다.

 

2026년 현재, 전 세계 기업들이 클라우드 비용 최적화(FinOps)를 심각하게 고민하기 시작했고, 아키텍처를 결정할때 비용이 핵심 변수로 떠올랐다. 

 

 

5-4 팀 규모의 불일치

MSA의 "팀 자율성"이라는 장점은 전제 조건이 있다.

 

팀이 충분히 커야 한다.

 

넷플릭스나 아마존처럼 서비스 하나당 수십 명 규모의 수 팀이 붙을 수 있는 조직이라면 MSA가 실제로 잘 작동한다. 각 팀이 자신의 서비스를 온전히 책임지고 운영할 수 있기 때문이다. 

 

그러나 만약 개발자가 15명인 스타트업이 12개의 마이크로 서비스를 운영한다면 ? 

한명의 개발자가 여러 서비스를 동시에 담당해야한다. 

 

서비스 간 의존성이 생기게 되면 "자율성"은 사라지고 오히려 더 많은 조율이 필요해진다. 

 

실제로 15명의 개발자가 12개 마이크로서비스를 관리하던 한 스타트업은 8개월만에 생산성이 60% 하락했고, 시니어 엔지니어 3명이 좌절감에 팀을 떠났다는 사례가 보고된 바 있다. 

 

Ruby on Rails의 창시자로 유명한 DHH는 이 현상을 이렇게 표현했다.

"마이크로서비스는 작은 팀이 '크게 생각하고 있다'고 착각하게 만든다. 실제로는 전혀 움직이지 못하게 만들면서."

 

 

 

 

6. 업계의 반성 — 되돌아가는 사례들

 

6-1 Amazon Prime Video의 고백

2023년, MSA를 처음 대중화하는 데 기여했던 Amazon이 일부 시스템을 모놀리스로 되돌렸다는 사실이 공개되었다.

Amazon Prime Video의 Video Quality Analysis 팀은 영상 품질을 실시간으로 분석하는 시스템을 여러 마이크로서비스로 구성해서 운영하고 있었다. 그런데 이 구조를 단일 프로세스 모놀리스로 전환하자 놀라운 결과가 나왔다. 

 

인프라 비용이 90% 절감되었고, 스케일링 성능은 오히려 향상됐다.

 

Amzon이 직접 "마이크로서비스가 우리 케이스에는 맞지 않았다"고 인정한 것이다. 이 사례는 업계에 큰 파장을 일으켰다. 

 

 

6-2 Twillo Segment의 반성문

데이터 수집 플랫폼 Twillo Segment도 공개적으로 자신들의 실수를 인정했다.

 

Segment는 한때 140개 이상의 마이크로서비스를 운영하고 있었다. 그런데 어느 순간 깨달았다. 풀타임 엔지니어 3명이 대부분의 시간을 새 기능을 만드는 것이 아니라, 마이크로서비스 간 문제를 해결하는 데 쓰고 있었다. 

 

배포 파이프라인 관리 , 서비스 간 통신 오류 , 데이터 불일치 ... => 끝없는 소방 작업이었다. 

 

결국 Segment는 이 140개 이상의 서비스를 하나의 모놀리스로 통합했다. 그리고 그 후 개발 생산성이 크게 향상됐다고 밝혔다.

 

 

6-3 숫자로 보는 회귀

CNCF(Cloud Native Computing Foundation)가 2025년에 발표한 설문결과는 이 흐름이 업계 전반에 걸쳐 나타나고 있음을 보여준다.

 

> 마이크로 서비스를 도입했던 조직 중 42%가 일부 서비스를 다시 더 큰 단위로 통합했다고 응답했다.

> 주요 이유 : 디버깅 복잡도, 운영 오버헤드, 네트워크 레이턴시로 인한 사용자 경험 저하 

 

서비스 메시(Service Mesh) ㅡ마이크로서비스간 통신을 관리해주는 인프라 레이어ㅡ 의 채택률도 2023년 3분기 18%에서 8%로 급락했다. 복잡한 MSA 인프라를 더 이상 쌓아 올리지 않겠다는 신호였다. 

 

Martin Fowler는 이 현상을 "Microservices Premium(마이크로서비스 프리미엄)" 이라는 개념으로 설명했다. 분산 아키텍처를 선택하면 반드시 치러야 하는 생산성 비용이 있으며, 이 비용이 MSA의 이점을 실제로 넘어서는 경우가 많다는 것이다.

"대부분의 팀은 Google 규모의 문제를 갖고 있지 않지만, Google 규모의 운영 비용을 지불하고 있었다."

 

 

 

 

 

7. 2026년 현재 — 세 가지 흐름의 부상

 

7-1 Modular Monolith - 모놀리스의 재발견

가장 강하게 부상하고 있는 흐름이다. 핵심 아이디어는 생각보다 단순하다

"배표는 하나로 하되, 내부 구조는 엄격하게 나눈다."

 

모놀리식 아키텍처의 운영 편의성은 가져가면서, 동시에 스파게티 코드가 되는 것을 막는 방식이다. 

구체적으로는 이런 규칙들이 적용된다. 

  • 회원 모듈, 주문 모듈, 결제 모듈은 각각 명확한 경계를 갖는다.
  • 다른 모듈의 데이터베이스 테이블에 직접 접근하는 것은 금지. 반드시 공개된 인터페이스를 통해서만 통신한다.
  • 모듈 간 의존성 방향을 강제로 관리한다.

 

이 구조를 잘 유지하면, 나중에 "이 모듈은 정말 독립적인 서비스로 분리할 필요가 생겼다" 싶을 때 비교적 쉽게 마이크로서비스로 추출할 수 있다. 처음부터 MSA로 시작하는 것보다 훨씬 안전한 접근이다.

 

대표적인 사례가 Shopify다. 글로벌 이커머스 플랫폼 Shopify는 대규모 Rails 기반 모놀리스를 지금도 운영하고 있다. 이것을 MSA로 전환하지 않고, 대신 내부를 모듈 단위로 정리하는 방식을 택했다. 

수백만 개의 상점을 처리하는 Shopify가 모놀리스로 잘 운여오디고 있다는 사실은, 모놀리스 = 낡은 방식이라는 선입견을 깨는 좋은 예다. 

"먼저 잘 설계된 모놀리스를 만들어라. MSA는 그 다음이다."

 

 

7-2 Vertical Slice Architecture - 레이어를 버리고 기능으로 묶는다.

이것은 서비스 분리 방식보다는, 코드 내부 구조에 관한 이야기다.

 

전통적인 방식은 레이어드 아키텍처(Layered Architecture)다. 코드를 역할에 따라 계층으로 나눈다. 

  • Controller 레이어 - 요청을 받는다
  • Service 레이어 - 비즈니스 로직을 처리한다
  • Repository 레이어 - 데이터베이스와 통신한다

처음에는 정돈된 것처럼 보이지만, 기능 하나를 추가하거나 수정하려면 모든 레이어를 손봐야한다는 문제가 있다. 

"주문 생성에 상품 재고 확인 로직 추가"라는 작업 하나를 위해, Controller, Service, Repository를 모두 수정하고, 경우에 따라 DTO(데이터 전달 객체)까지 손대야 한다. 

 

Vertical Slice Architecture는 이 구조를 뒤집는다. 레이어가 아니라 기능(Feature) 단위로 코드를 묶는 것이다. 

 

 

[ 기존 레이어드 구조 ]
/Controllers
   OrderController.cs
   UserController.cs
/Services
   OrderService.cs
   UserService.cs
/Repositories
   OrderRepository.cs
   UserRepository.cs

→ "주문 생성" 기능을 수정하려면 모든 폴더를 다 건드려야 함

[ Vertical Slice 구조 ]
/Features
   /CreateOrder
      CreateOrderHandler.cs      ← 요청 처리
      CreateOrderValidator.cs     ← 유효성 검사
      CreateOrderDto.cs             ← 데이터 구조
   /CancelOrder
      CancelOrderHandler.cs
    ...

→ "주문 생성"  기능을 수정하려면 /Features/CreateOrder 폴더만 건드리면 됨

 

 

이 구조의 장점은 명확하다.

 

기능 하나를 변경할때, 그 기능과 관련된 코드만 건드리면 된다. 다른 기능에 영향을 줄 가능성이 크게 줄어든다. 새로운 팀원이 "주문 생성"  기능을 이해하고 싶다면, 해당 폴더만 열어보면 된다. 

 

이 개념은 소프트웨어 아키텍트 Jimmy Bogard가 적극적으로 전파해 주목받기 시작했고, CQRS(명령과 조회의 분리) 패턴과 함께 자주 사용된다. 

 

 

7-3 Domain-Driven Design (DDD)의 재조명 - 경계를 먼저 그려라

MSA 실패 사례들을 들여다보면, 흥미로운 패턴이 발견된다. 기술적인 실패가 아닌 경우가 많다는 것이다.

 

Kubernetes 설정 문제도, Docker 이슈도 아니었다. 가장 많은 실패의 원인은 "서비스를 잘못된 기준으로 쪼갰다" 는 것이었다.

예를 들어, 쇼핑몰에서 "상품"이라는 개념은 어디에나 등장한다.

 

상품 등록, 상품 조회, 장바구니에 담기, 주문하기, 리뷰쓰기...

 

이 모든 곳에 "상품"이 있다. 그런데 각 맥락에서 "상품"이 의미하는 것은 조금씩 다르다. 

상품 등록의 맥락에서는 이름, 가격, 재고, 카테고리가 중요하고, 

배송 맥락에서는 무게와 크기가 중요하고, 

리뷰 맥락에서는 평점과 후기가 중요하다. 

 

이것을 모두 하나의 "상품 서비스"로 묶으면, 이 서비스가 너무 많은 역할을 담당하게 된다. 반대로, 세부 기능마다 별도 서비스를 만들면 서비스 수가 폭발적으로 늘어난다. 

 

Domain-Driven Design(도메인 주도 설계, DDD)은 이 문제를 해결하기 위해 Bounded Context(경계 컨텍스트)라는 개념을 제시한다.

"이 서비스에서 '상품'은 이런 의미다"라고 명확히 경계를 그어, 각 컨텍스트 안에서는 일관된 모델을 사용하는 것이다. 

 

DDD는 MSA보다 훨씬 오래된 개념이지만, MSA의 실패 원인 분석이 활발해지면서 다시 주목받고 있다. 

"어떻게 나눌 것인가(MSA vs 모놀리스)"보다, "어디에서 나눌 것인가(경계를 어떻게 그을 것인가)"가 더 중요한 질문이라는 인식이 퍼지고 있다. 

 

모듈러 모놀리스든, MSA든, 도메인 경계를 먼저 올바르게 설계하지 않으면 어느 아키텍처를 택해도 결국 같은 문제에 부딪힌다. 

 

 

 

 

8. 결론 — MSA는 나쁜 게 아니라, 맥락이 필요하다

 

2026년 현재, 업계의 인식은 이렇게 정리되고 있다.

 

과거의 관점 현재의 관점
MSA = 현대 아키텍쳐의 정답 MSA는 도구, 맥락에 따라 선택하는 것
무조건 쪼개는 것이 선진적 Modular Monolith 로 시작, 필요할 때 분리
레이어드 아키텍처가 기본값 Vertical Slice가 유력한 대안으로 부상
기술 기준으로 서비스 분리 도메인 경게 기준으로 분리 (DDD)
스케일 = 기술적 성숙도 지속가능성과 비용 효율이 핵심 기준

 

MSA가 틀렸던 게 아니다. 넷플릭스처럼 하루에 수억 번의 스트리밍 요청을 처리하고, 아마존처럼 수천 명의 엔지니어가 동시에 개발하는 조직에서 MSA는 실제로 필요한 해법이다. 그 규모에서는 MSA의 복잡성을 감당할 수 있고, 그 복잡성보다 더 큰 이점이 있다. 

 

문제는 "저 회사가 MSA를 쓰니까 우리도 MSA여야 한다" 는 생각이었다. 우리 팀은 10명인데, 넷플릭스의 아키텍처를 따라 하는 것이 맞는가? 우리 서비스는 하루 방문자가 1만 명인데, 아마존의 인프라를 흉내 내는 게 맞는가?

 

아키텍처의 성숙은 "얼마나 많이 쪼갰는가"로 측정되지 않는다. "우리 팀의 규모와 서비스의 특성에 맞는 선택을 했는가" 로 측정된다.

 

 

 

 

** 출처 

 

 

 

Microservices

Defining the microservices architectural style by describing their nine common characteristics

martinfowler.com

 

 

bliki: Microservice Premium

The microservice architectural style is useful for handling complex systems, but brings its own complexity so should not be used for simpler environments.

martinfowler.com

 

 

Entertainment

Amazon produces and delivers to customers world-class entertainment via Prime Video, Amazon MGM Studios, MGM+, Amazon Music, Audible, Wondery, Amazon Games, and Twitch. Amazon’s entertainment properties empower millions of customers around the world to e

www.aboutamazon.com

 

 

Goodbye Microservices

Discover Twilio’s shift to a single powerful service! Learn cloud communication trends, customer success stories, and how to build scalable apps. Join now!

www.twilio.com

 

 

 

댓글

티스토리툴바