마이크로서비스 도입 판단 가이드 — 구조와 넷플릭스·아마존·국내 금융권이 실제로 택한 방식

MSA로 가야 하는가라는 질문에는 정답이 하나로 정해져 있지 않다. 같은 마이크로서비스 아키텍처를 선택하고도 넷플릭스와 아마존, 국내 금융권이 실제로 걸어간 길은 서로 달랐다. 그 전에 이 아키텍처가 어떤 구조로 서 있고 무엇을 대가로 요구하는지부터 짚어야 판단이 선다.

기본 골격

MSA는 대체로 3계층으로 구성된다. Front-end Tier는 사용자 인터페이스를 담당하며 SPA나 모바일 앱 형태로 백엔드와 API로 통신한다. Middle Tier는 독립적인 마이크로서비스들이 모여 핵심 비즈니스 로직을 처리하는 층이고, Back-end Tier는 데이터 저장을 맡는데 서비스마다 다른 데이터베이스 기술을 쓰는 폴리글랏 퍼시스턴스(Polyglot Persistence)가 여기서 특징적으로 나타난다.

⤢✕

서비스가 스스로 서 있기 위한 조건

각 서비스는 특정 비즈니스 기능에 집중하고 독립적으로 개발·배포·확장되며, 필요하면 자체 데이터 저장소를 갖는다. 서비스 간 의존성은 인터페이스를 통한 통신으로 최소화해서, 한 서비스의 내부 구현이 바뀌어도 다른 서비스가 흔들리지 않는 느슨한 결합을 유지한다. 이렇게 독립된 서비스들을 다양하게 조합하면 새로운 비즈니스 기능을 재사용성 있게 만들 수 있고, 필요에 따라 서비스를 추가하거나 빼기도 쉬워진다. 서비스마다 최적의 기술을 고를 수 있는 폴리글랏 특성 덕분에 팀별 자율성도 커지고, 새 기술을 들이는 문턱도 낮아진다.

진입점 하나로 묶는 API Gateway

클라이언트가 수십 개 서비스를 일일이 상대하지 않도록, API Gateway가 단일 접점 역할을 한다.

⤢✕

요청을 적절한 서비스로 라우팅하고, 인스턴스 간 부하를 분산하며, 인증·인가를 중앙에서 처리하고, 여러 서비스의 응답을 클라이언트가 쓰기 좋은 형태로 조합하고, 과도한 요청은 속도 제한으로 걸러낸다. 각 마이크로서비스 자체는 단일 책임 원칙 아래 비즈니스 기능 하나에 집중하고, 서비스 팀이 설계부터 운영까지 자율적으로 책임지며, REST나 gRPC 같은 표준 프로토콜로 서로 통신한다.

데이터베이스는 서비스마다 다르게

서비스마다 다른 데이터베이스 기술을 골라 쓰는 폴리글랏 퍼시스턴스는 각 서비스가 자기 데이터를 완전히 자율적으로 관리하게 해준다.

⤢✕

관계형 DB, NoSQL, 캐시, 검색엔진을 워크로드 특성에 맞게 섞어 쓸 수 있는 대신, 서비스 간 데이터를 조인하듯 즉시 맞춰볼 수는 없다는 걸 받아들여야 한다 — 대부분의 MSA 설계는 강한 일관성 대신 최종 일관성(Eventual Consistency)을 전제로 한다.

서비스 간 통신은 HTTP/REST와 JSON이 가장 보편적이고, 즉시 응답이 필요 없는 흐름은 Kafka·RabbitMQ 같은 메시지 큐로 비동기 이벤트 발행·구독 모델을 쓴다. 서비스 수가 늘어나면 Istio·Linkerd 같은 서비스 메시가 이 통신 계층 자체를 관리하는 역할을 맡는다.

모놀리식과 견주면

특성	모놀리식	마이크로서비스
개발 복잡성	초기에 낮음	초기에 높음
배포	전체 시스템 배포	서비스별 독립 배포
확장성	전체 시스템 확장	서비스별 확장 가능
장애 영향	전체 시스템에 영향	일부 서비스에 제한
기술 다양성	제한적	서비스별 다양한 기술 사용 가능
팀 구조	기능별 팀	서비스별 크로스펑셔널 팀

⤢✕

SOA와 견주면

특성	SOA	MSA
서비스 크기	더 크고 포괄적	작고 집중적
통신 방식	ESB 중심, SOAP 위주	직접 통신, REST/메시징
데이터 저장소	주로 공유	서비스별 독립
통합 중심점	ESB	API Gateway, 서비스 메시
목표	시스템 통합	민첩한 개발과 배포
거버넌스	중앙화 경향	분산 거버넌스

⤢✕

SOA가 ESB라는 중앙 허브를 통해 서비스를 통합하는 쪽이었다면, MSA는 그 허브를 걷어내고 서비스끼리 직접, 혹은 API Gateway·서비스 메시를 거쳐 말을 섞는다.

실제로 어떻게 갔는가 — 서로 다른 경로

넷플릭스는 2008년 단일 모놀리식 시스템에서 전환을 시작해, 지금은 수백 개의 마이크로서비스를 운영하며 서비스별 독립 배포로 매일 수백 번 배포한다. 이 정도 배포 빈도를 감당하려고 일부러 장애를 주입해 시스템의 복원력을 검증하는 카오스 엔지니어링을 도입했다.

아마존은 초기 모놀리식에서 전환하면서 "Two Pizza Team" — 한 팀이 피자 두 판으로 해결될 만큼 작은 규모여야 한다는 조직 원칙을 함께 들여왔다. 서비스 자율성을 극대화하는 이 접근은 이후 AWS 기반 서비스 개발 방식에도 영향을 미쳤다.

국내 금융권은 앞의 두 사례와 결이 다르다. 레거시 뱅킹 시스템을 한 번에 갈아엎지 않고 점진적으로 전환하는데, 모바일뱅킹·핀테크 같은 신규 서비스부터 MSA를 적용하고 코어 뱅킹은 안정성을 이유로 부분적으로만 전환하며, API Gateway를 중심에 둔 구조를 채택한다. 세 사례 모두 MSA를 택했지만, 얼마나 빠르게 어디까지 갈아엎을지는 조직의 리스크 허용도에 따라 완전히 다른 답을 냈다.

도입 전에 따져야 할 점

서비스 경계를 어디에 긋느냐가 가장 먼저다. 도메인 주도 설계(DDD) 방법론으로 비즈니스 기능 중심의 경계를 식별하는 게 성공의 핵심으로 꼽힌다. 둘째는 분산 시스템 자체가 안고 오는 복잡성이다 — 네트워크 지연과 부분 장애에 대응하려면 서킷 브레이커·재시도·타임아웃 같은 복원력 패턴이 필요하고, 분산 트랜잭션 문제도 별도로 풀어야 한다. 셋째는 데이터 일관성이다. 서비스마다 DB가 나뉘면 트랜잭션 관리가 복잡해지므로 SAGA 패턴이나 이벤트 소싱 같은 분산 트랜잭션 패턴을 쓸지, 최종 일관성 모델을 받아들일지 결정해야 한다. 넷째는 운영 복잡성이다. 서비스 수만큼 늘어나는 모니터링 대상을 감당하려면 로그 집중화·추적과 배포 자동화가 사실상 필수가 된다. 다섯째는 조직 변화다. 기술 중심 팀에서 기능 중심 팀으로 재구성하고 DevOps 문화를 들여오는 것 자체가 MSA 도입의 일부다.

갖춰야 할 도구 지형

컨테이너 계층에서는 Docker로 서비스를 패키징하고 격리하며, Kubernetes로 오케스트레이션하고, Helm으로 Kubernetes 패키지를 관리한다. API 관리는 Spring Cloud Gateway·Netflix Zuul 같은 게이트웨이, Swagger·OpenAPI 같은 문서화 표준, Kong·Apigee 같은 관리 플랫폼이 맡는다. 서비스 탐색 영역에는 Netflix Eureka·Consul 같은 서비스 레지스트리, Spring Cloud Config 같은 중앙화된 설정 관리, etcd 같은 분산 키-값 저장소가 쓰인다. 복원력 패턴은 Netflix Hystrix나 Resilience4j 같은 장애 허용 라이브러리, Istio 같은 서비스 메시가 구현체 역할을 하고, 모니터링은 Prometheus로 메트릭을 모으고 Grafana로 시각화하며 ELK 스택으로 로그를 분석하고 Jaeger·Zipkin으로 분산 추적을 한다.

선택은 아키텍처 취향이 아니다

MSA는 독립적인 서비스 단위로 쪼갬으로써 개발·배포·확장의 유연성을 얻고 비즈니스 변화에 빠르게 대응하게 해주지만, 그 대가로 분산 시스템의 복잡성과 데이터 일관성 관리, 운영 오버헤드를 떠안는다. 만능 해결책이 아니라는 뜻이다. 넷플릭스처럼 극단적인 자동화로 가든, 아마존처럼 조직 구조부터 바꾸든, 국내 금융권처럼 신규 서비스에만 먼저 적용하든 — 어느 정도까지 갈지는 조직의 규모와 복잡도, 기술적 성숙도에 맞춰 판단할 문제이고, 결국 기술만이 아니라 조직 문화와 개발 프로세스, 운영 방식이 함께 바뀌어야 하는 여정이다.