마이크로서비스, 정말 필요한가? 아마존이 알려준 불편한 진실

마이크로서비스는 요즘 개발자라면 한 번쯤 고민하는 단골 키워드입니다. "클라우드 네이티브 = 마이크로서비스"라는 등식이 너무 자연스럽게 받아들여지면서, 규모와 상관없이 일단 쪼개고 보는 팀도 많죠.

그런데 2023년, 이 흐름에 브레이크를 건 사건이 있었습니다. 바로 아마존 프라임 비디오가 핵심 시스템을 마이크로서비스에서 모놀리식 구조로 되돌리면서, 비용을 무려 90%나 줄였다는 사실을 공개한 거예요. 마이크로서비스 인프라를 파는 그 아마존이 말이죠.

이 글에서는:

• 마이크로서비스가 진짜 빛을 발하는 상황은 어디인지

• 왜 대형 기술 기업들조차 "다 마이크로서비스" 전략에서 후퇴하는지

• 대안으로 떠오르는 모듈러 모놀리식, SOA 같은 아키텍처

• 마이크로서비스가 아니어도 Docker를 활용해 깔끔하게 확장하는 방법

까지 한 번에 정리해보겠습니다. 마지막에는 "우리 서비스, 굳이 마이크로서비스여야 할까?"를 스스로 판단할 수 있도록 질문도 드릴게요.

마이크로서비스, 민첩함의 대가로 복잡성을 산다

마이크로서비스 설명은 늘 이렇게 시작합니다. "하나의 큰 덩어리(모놀리식) 대신, 작고 독립적인 여러 서비스를 만든다."

각 서비스는:

• 다른 언어와 기술 스택을 쓸 수 있고

• 별도 팀이 독립적으로 소유하고

• 자체적으로 배포하고

• 필요한 부분만 따로 스케일링 할 수 있죠.

이론만 보면 너무 멋집니다. 문제는, 이 "쪼개기"마다 경계가 생기고, 그 경계가 전부 잠재적인 장애 포인트가 된다는 점입니다.

모놀리식에서는 함수 호출 한 번이면 끝나는 일이, 마이크로서비스에서는 네트워크 요청으로 바뀝니다. 네트워크는 느리고, 실패하고, 가끔 이상한 데이터를 돌려줍니다.

서비스가 열 개, 스무 개, 백 개로 늘어나면:

• 버전 관리

• 스키마 진화

• 분산 트랜잭션

• 트레이싱과 로그 수집

• 복잡한 CI/CD 파이프라인

같은 것들을 얹어서 겨우 시스템이 돌아가게 만들게 됩니다.

이 복잡성은 단순한 "코드 쪼개기"가 아니라, "운영 난이도"를 한 단계 올려버리는 선택입니다. 넷플릭스처럼 말도 안 되게 큰 트래픽과 팀 규모를 가진 회사라면 이 복잡성을 감수할 이유가 있습니다. 하지만 대부분의 팀은 그 수준의 스케일이 아닙니다.

결국 중요한 질문은 하나입니다. "우리는 진짜로 서비스별 독립적인 확장과 배포가 꼭 필요한가?" 아니면 "멋있어 보이고 이력서에 좋아 보이니까" 선택하려는 건 아닌가요?

아마존, 트윌리오, 쇼피파이가 보여준 마이크로서비스 되돌리기

아이러니하게도, 마이크로서비스를 가장 잘 쓸 법한 대형 기술 기업들이 되려 모놀리식으로 회귀하는 사례가 늘고 있습니다.

아마존 프라임 비디오: 90% 비용 절감한 모놀리식 회귀

프라임 비디오의 비디오 품질 분석(VQA) 시스템은 처음에 "완벽한 서버리스 아키텍처"처럼 보였습니다. AWS Step Functions + Lambda + S3조합으로, 완전 분산형 워크플로를 구성했죠.

하지만 실제 운영에서는 처참했습니다. 예상 트래픽의 5%만 받아도 오케스트레이션 오버헤드 때문에 시스템이 비명을 질렀고, S3 사이에서 데이터를 이리저리 옮기는 비용이 실제 처리 비용보다 더 많이 나갔습니다.

해결책은 놀라울 만큼 단순했습니다. "그냥 하나의 프로세스로 합쳐버리자." 즉, 모놀리식으로 되돌린 거죠.

결과는:

• 비용 90% 감소

• 성능 개선

• 운영 단순화

"분산형이 우리 케이스에서는 별 이득이 없다"는 것이 아마존 엔지니어들의 결론이었습니다.

Twilio Segment: 140개 마이크로서비스 → 하나의 빠른 모놀리식

세그먼트는 한때 140개가 넘는 마이크로서비스를 운영했습니다. 결과는 멋진 분산 아키텍처가 아니라, "불 끄기 전담 팀"이 필요한 혼돈에 가까웠습니다.

• 엔지니어 3명이 거의 상시 장애 대응만 하게 되고

• 테스트는 느려지고

• 배포는 복잡해지고

• 버그는 폭증하고

• 개발 속도는 바닥을 쳤습니다.

결국 선택한 해결책은 모든 서비스를 하나의 모놀리식으로 모으는 것. 그 이후:

• 1시간 걸리던 테스트가 밀리초 단위로 줄고

• 공통 라이브러리 개선 속도도 크게 증가했습니다.

"마이크로서비스가 우리를 더 빠르게 만들어줄 거라 생각했지만, 반대였다"는 고백이 인상적입니다.

Shopify: 하이프 대신 모듈러 모놀리식

쇼피파이는 280만 줄이 넘는 거대한 Ruby on Rails 코드베이스를 운영합니다. 그 규모에서 "마이크로서비스로 쪼개야 하는 거 아닌가?"라는 유혹은 당연히 있었겠죠.

하지만 그들은 의도적으로 "모듈러 모놀리식"을 선택했습니다.

• 하나의 코드베이스를 유지하되

• 내부를 명확한 모듈로 잘게 나누고

• 팀별로 모듈을 소유하게 하고

• 배포는 한 번에 같이 하는 방식입니다.

"마이크로서비스가 가져올 문제들이 우리에겐 더 크다"는 판단이었죠.

이 세 회사의 공통점은 단 하나입니다. "실제 요구사항을 기준으로 아키텍처를 선택했다"는 것. 트렌드가 아니라, 문제에 맞는 해결책을 택한 겁니다.

마이크로서비스에 제동 거는 전문가들의 솔직한 한마디

흥미로운 건, 대규모 시스템을 만들어본 실전형 아키텍트들이 마이크로서비스 열풍에 제법 비판적이라는 점입니다.

Ruby on Rails 창시자 DHH: "가장 달콤한 유혹"

Rails를 만든 데이비드 하이네마이어 한슨(DHH)은 오래전부터 "불필요한 복잡성"에 일관되게 반대해 왔습니다. 아마존 프라임 비디오 사례를 두고 그는 이렇게 말합니다.

• 마이크로서비스는 이론적으로는 우아하지만

• 실제로는 "가장 강력한 과도 설계의 유혹"이 될 수 있다

즉, 멋있어 보여서 시스템을 쓸데없이 복잡하게 만드는 대표 사례라는 이야기죠.

GitHub 전 CTO Jason Warner: "10%만 필요하다"

깃허브, Heroku, Canonical에서 규모 있는 시스템을 직접 운영했던 제이슨 워너는 훨씬 직설적입니다.

• "지난 10년간 가장 큰 아키텍처 실수 중 하나가 '풀 마이크로서비스'였다"

• "세상의 90% 회사는 그냥 모놀리식 + 메인 DB + 캐시 + 프록시로 충분하다"

인터넷 규모의 서비스를 운영했던 CTO가 이렇게 말합니다. 그러면 우리는 솔직히 되묻게 되죠. "우리 회사가 진짜 그 10% 안에 드나?"

GraphQL 공동 창시자 Nick Schrock: "하지 마라에 가깝다"

분산 시스템에서 발생하는 문제를 줄이기 위해 GraphQL을 만든 닉 슈록 역시, 마이크로서비스에 아주 회의적입니다.

• "근본적으로, 그리고 재앙적으로 나쁜 아이디어"

• "몇 년 전 조직 구조와 요구사항에 맞춰 나뉜 서비스들을 영원히 떠안게 된다"

결국 마이크로서비스는 기술 문제만이 아니라, "조직 구조와 과거의 결정을 반영한 영구적인 짐"이 될 수 있다고 경고합니다.

Uber, Kelsey Hightower도 방향 전환 중

• 우버는 수천 개의 마이크로서비스 운영 경험 끝에, 일부를 "매크로 서비스(적당히 큰 서비스)"로 합치는 중입니다.

• 쿠버네티스를 대표하는 인물인 켈시 하이타워 역시, "단순 성능만 따지면 모놀리식이 마이크로서비스보다 빠를 수밖에 없다"고 지적했죠.

분산 시스템을 누구보다 잘 아는 사람들이, 한목소리로 말합니다. "정말 필요할 때만, 조심해서 쓰라."

마이크로서비스의 숨은 비용: 운영, 개발, 데이터, 테스트

마이크로서비스의 어려움은 코드 자체보다 "복잡성의 총합"에서 나옵니다. 눈에 잘 안 보이는 비용이라, 시작할 땐 과소평가하기 쉽죠.

운영 비용: 함수 호출이 네트워크로 바뀌는 순간

모놀리식에서는 함수 호출 한 번으로 끝나던 일이, 마이크로서비스에서는 다음을 거칩니다.

• 네트워크 전송

• 로드밸런서

• 서비스 메시

• 인증/인가 레이어

여기에 더해:

• 서비스 디스커버리

• 분산 트레이싱

• 중앙 로그 수집

• 복잡한 모니터링

같은 것들을 모두 갖춰야 합니다.

서비스 간 호출이 늘어날수록:

• 네트워크 비용이 눈덩이처럼 불어나고

• 중복 데이터 때문에 저장 비용도 늘며

• 장애 지점이 폭발적으로 증가합니다.

프라임 비디오 사례처럼, "실제 처리"보다 "서비스 사이를 오가는 데이터 이동 비용"이 더 비싼 상황도 흔합니다.

개발 생산성: "코드 짜는 것보다 조율이 더 힘들다"

Stack Overflow에서는 이를 "마이크로서비스의 거대한 문제"라고 표현했습니다. 분산 상태 때문에, 개발자는 항상 다음을 걱정해야 합니다.

• 부분 실패를 가정한 방어적 코드

• 여러 서비스에 걸친 변경사항

• 여러 저장소와 팀을 오가는 조율

• 버전 호환성과 점진적 롤아웃

모놀리식에서는 컴파일러가 잡아줄 타입 오류를, 마이크로서비스에서는 프로덕션에서 장애로 알게 되는 일도 많습니다.

테스트와 배포: 느려지고, 깨지기 쉬운 세상

모놀리식은:

• 모든 기능이 한 프로세스 안에 있으니

• 통합 테스트와 E2E 테스트도 한 번에, 빠르게 돌릴 수 있습니다.

반면 마이크로서비스는:

• 프로덕션과 비슷한 스테이징 환경을 따로 구성해야 하고

• 여러 서비스를 동시에 띄운 뒤

• 네트워크를 포함한 통합 테스트를 돌려야 합니다.

이 테스트는:

• 느리고

• 깨지기 쉽고

• 인프라 비용도 많이 듭니다.

배포도 문제입니다.

• A 서비스는 B의 v2.1에 맞춰 개발했는데

• 운영에는 이미 v2.2가 떠 있거나

• 일부 인스턴스만 다른 버전이 돌아가는 상황이 생기죠.

이런 "부분 배포 상태"에서 장애가 났을 때, 원인을 찾고 되돌리는 건 상상 이상으로 어렵습니다.

데이터 일관성: 분산 트랜잭션의 악몽

모놀리식은 하나의 데이터베이스 트랜잭션으로:

• 모두 성공하거나

• 모두 실패하게 만들 수 있습니다.

마이크로서비스는:

• 각 서비스가 독립된 데이터 저장소를 갖게 되면서

• "분산 트랜잭션", "사가 패턴", "보상 트랜잭션" 같은 복잡한 패턴을 도입하게 됩니다.

여기서부터:

• "결제가 됐는데 주문 상태는 안 바뀌는" 식의 이상한 상태가 나타나고

• 어느 서비스의 데이터가 진짜인지 헷갈리기 시작합니다.

연구 결과에서도, 마이크로서비스의 가장 큰 고통은:

• 데이터 중복

• 정합성 보장

• 트랜잭션 복잡성

세 가지로 모아집니다.

이 모든 복잡성은 서로 얽히면서 기하급수적으로 커집니다. 그래서 정말 중요한 질문은 이것입니다.

"우리가 얻는 이점이, 이 모든 복잡성을 감수할 만큼 큰가?"

마이크로서비스 말고, 더 현명한 선택지들

"그럼 답은 모놀리식 vs 마이크로서비스 둘 중 하나인가요?" 다행히 그렇지는 않습니다. 더 현실적인 중간 지점들이 있어요.

모듈러 모놀리식: 구조는 쪼개되, 배포는 하나로

모듈러 모놀리식은 이렇게 생각하면 쉽습니다.

• "코드는 모듈 단위로 강하게 분리"

• "하지만 실행은 하나의 애플리케이션으로"

각 모듈은:

• 명확한 API를 가지고

• 다른 모듈에 직접 접근하지 않고

• 잘 정의된 경계를 유지합니다.

마이크로서비스와 비슷하게 "도메인별 경계"를 가지지만, 통신은 HTTP가 아니라, 같은 프로세스 안의 함수 호출입니다.

이 방식의 장점은 명확합니다.

• 운영 단순화: 배포 단위는 하나, 구조는 여러 개

• 일관성: 여전히 하나의 트랜잭션으로 ACID 보장

• 디버깅: 시스템 전체를 한 번에 추적 가능

• 성능: 네트워크 대신 메모리 호출

Shopify, Facebook처럼 거대한 트래픽을 가진 서비스들도 이런 구조를 사용해 큰 규모를 소화하고 있습니다. Spring, Django, Laravel, Rails 등 주요 프레임워크도 점점 모듈러 모놀리식을 쉽게 만들 수 있도록 발전하고 있습니다.

SOA(Service-Oriented Architecture): 덩어리를 조금만 크게 자르기

SOA는 마이크로서비스보다 "조금 더 굵직하게" 서비스를 자르는 접근입니다.

예를 들어:

• 마이크로서비스: 인증, 프로필, 알림을 각각 서비스로 분리

• SOA: 이 세 가지를 "사용자 서비스" 하나로 묶음

이렇게 하면:

• 도메인 기준으로는 분리되어 있고

• 서비스 단위도 몇 개 안 되고

• 조율과 배포, 테스트가 상대적으로 쉬워집니다.

SOA는:

• 도메인에 맞는 "적당한 크기"의 서비스

• 필요한 도메인만 선택적으로 스케일링

• 과도한 쪼개기에 따른 오버헤드 방지

라는 현실적인 장점을 제공합니다.

대형 은행, 항공사 같은 엔터프라이즈 시스템에서 이미 수십 년 검증된 방식이기도 합니다.

결론적으로 대부분의 경우:

• 스타트업/일반 웹 서비스: 모듈러 모놀리식

• 대규모 엔터프라이즈: SOA 또는 매크로 서비스

정도가 훨씬 현실적이고, 팀 생산성도 높습니다.

마이크로서비스가 아니어도 Docker는 여전히 최고다

마이크로서비스 얘기에서 종종 나오는 오해 중 하나가 있습니다. "도커 = 마이크로서비스용 툴"이라는 인식이죠.

실제로는 정반대에 가깝습니다. Docker는 아키텍처와 상관없이 쓸 수 있는 "배포·실행 환경 표준화 도구"에 가깝습니다.

모놀리식이어도, SOA여도, REST API든, 이벤트 기반이든, Docker의 장점은 그대로입니다.

• 개발 환경과 운영 환경을 동일하게 유지

• 의존성 지옥에서 해방

• 간편한 배포, 롤백, 스케일링

• 애플리케이션을 호스트 시스템으로부터 격리

마이크로서비스를 안 써도, 컨테이너를 여러 개 띄워서 모놀리식을 수평 확장할 수 있습니다. 트래픽이 늘어나면, 그저 컨테이너를 더 띄우면 됩니다.

마이크로소프트도 "모놀리식을 컨테이너로 감싸는 것만으로도, VM 기반보다 훨씬 쉽게 확장 가능하다"고 가이드에서 강조합니다. Twilio Segment도 "도커화한 모놀리식은 컨테이너를 늘리고 줄이는 방식으로 아주 쉽게 수평 확장할 수 있다"고 정리했죠.

DevOps 관점에서도:

• 로그 수집

• 모니터링

• 장애 대응

을 한 덩어리 애플리케이션에 대해 하는 것이, 수십 개의 서비스를 동시에 관리하는 것보다 훨씬 단순합니다.

정리하자면:

• 마이크로서비스를 쓰든 말든, Docker는 여전히 유용하고

• 오히려 모놀리식 + Docker 조합이

• "단순함 + 확장성"을 동시에 잡는 좋은 선택지인 경우가 많습니다.

시사점: 레몬 자르는데 굳이 장검을 꺼낼 필요는 없다

마지막으로 제일 중요한 질문을 던져볼게요.

"우리 서비스, 정말 마이크로서비스가 아니면 안 되나요?"

대부분의 팀은:

• 구글만큼의 장애 허용 요구도도 없고

• 아마존만큼의 쓰기 트래픽도 없고

• 링크드인처럼 초당 수십억 이벤트를 처리하지도 않습니다.

그렇다면, 우리가 진짜로 필요한 건:

• 적당히 잘 설계된 모듈러 모놀리식이거나

• 도메인 기준으로 적당히 쪼갠 SOA/매크로 서비스

• 그리고 Docker 같은 도구로 배포와 확장을 단순화하는 것

일 가능성이 아주 높습니다.

아이에게는 아파트 단지에서 타고 놀 3단 기어 자전거면 충분한데, 21단 기어 + 서스펜션 + 온갖 레버가 달린 산악용 자전거를 사주는 것과 비슷합니다. 겉보기에는 멋있지만, 고장 나고, 손 볼 곳만 늘어나죠.

마이크로서비스를 버리자는 얘기가 아닙니다. "내 문제를 해결하는 가장 단순한 구조"를 먼저 찾자는 이야기입니다.

• 팀 규모가 크고

• 도메인 경계가 명확하고

• 각 도메인이 확실히 다른 확장/배포 패턴을 갖고

• 조직적으로도 서비스별 소유권을 감당할 수 있다면

그때 비로소 마이크로서비스를 서서히 도입해도 늦지 않습니다.

그 전까지는 이렇게 자문해보세요.

• 지금 당장, 구조를 단순하게 유지하면 안 되는 이유가 뭘까?

• 우리가 진짜로 겪고 있는 문제는 "분산"으로만 풀 수 있는 문제인가?

• 모듈러 모놀리식 + Docker로는 정말 해결이 불가능한가?

유행이 아니라, 우리 비즈니스 요구사항이 아키텍처를 결정해야 합니다. 마이크로서비스를 "당연한 기본값"으로 두는 순간, 복잡성의 비용은 고스란히 우리 팀이 떠안게 됩니다.

그래서 다시 묻겠습니다. 당신이 원하는 건 "마이크로서비스를 쓰는 회사"인가요, 아니면 "문제를 잘 해결하는 제품을 만드는 팀"인가요?

출처 및 참고 : You Want Microservices—But Do You Need Them? | Docker