- 마이크로서비스는 하나의 애플리케이션을 여러 개의 작은 독립 서비스로 나누고, 이들이 네트워크를 통해 서로 통신하도록 만든 아키텍처입니다.
- 각 서비스는 결제, 검색, 알림처럼 하나의 기능만 담당하기 때문에, 팀별로 개별 업데이트, 배포, 확장이 가능합니다.
- 마이크로서비스는 큰 제품이 빠르게 진화하고 안정적으로 운영되도록 도와주지만 복잡도가 높아지므로, 모든 작은 프로젝트에 적합한 선택은 아닙니다.
마이크로서비스란?
마이크로서비스(Microservices)는 하나의 애플리케이션을 여러 개의 작은 독립 서비스로 만들어 운영하는 소프트웨어 설계 방식입니다. 각 서비스는 한 가지 일에만 집중합니다. 예를 들어 결제 처리, 사용자 계정 관리, 알림 발송 같은 식이죠. 그리고 이 서비스들은 보통 API를 통해 네트워크로 서로 대화합니다.
반대 개념은 모놀리식(monolith)입니다. 모놀리식 구조에서는 모든 기능이 하나의 큰 프로그램 안에 들어 있고, 함께 배포됩니다. 마이크로서비스에서는 각 기능을 따로 개발하고, 따로 배포하고, 따로 확장할 수 있습니다.
자주 사용되는 마이크로서비스 아키텍처(microservices architecture)라는 표현은, 이 방식이 단순히 "작은 서비스"가 아니라 코드, 팀, 인프라까지 함께 재구성하는 하나의 운영 방식임을 강조하기 위해 사용됩니다.
일상의 비유로 이해하기
번화한 푸드코트를 떠올려 보세요.
전통적인 모놀리식 앱은 마치 "피자, 초밥, 햄버거, 커피"를 하나의 주방에서 전부 만드는 거대한 식당과 같습니다. 커피 머신이 고장 나면 가게 전체가 느려지고, 메뉴를 새로 디자인하려면 직원 전원을 동시에 재교육해야 합니다.
마이크로서비스 앱은 푸드코트 그 자체와 비슷합니다. 각 매장은 작은 독립 식당입니다. 한 곳은 피자만, 한 곳은 초밥만, 한 곳은 커피만 만듭니다. 같은 통로(네트워크)를 공유하지만, 주방, 직원, 운영 시간은 각자 관리합니다. 초밥 가게가 잠시 리모델링을 해도 피자 가게는 계속 영업합니다. 어느 가게가 인기를 끌면 그 가게에만 직원을 더 투입할 수 있습니다. 푸드코트 전체를 확장할 필요가 없죠.
왜 중요한가요?
마이크로서비스가 중요한 이유는, 팀과 코드베이스가 커질수록 소프트웨어 제품의 변화 속도를 유지하기 위해서입니다. 큰 앱을 여러 작은 서비스로 나누면 작업과 리스크도 함께 분산됩니다.
주요 장점은 다음과 같습니다.
- 독립 배포: 각 팀이 자기 서비스만 따로 업데이트해 출시할 수 있습니다. 거대한 합동 릴리스를 매번 맞출 필요가 없죠.
- 선택적 확장: 예를 들어 검색 서비스만 부하가 크다면, 전체 앱이 아니라 그 서비스만 확장하면 됩니다.
- 기술 유연성: 한 서비스는 파이썬, 다른 서비스는 Go, 또 다른 서비스는 Node.js처럼 작업에 맞는 언어를 자유롭게 선택할 수 있습니다.
- 장애 격리: 알림 서비스의 버그가 전체 제품을 멈추게 만들 가능성을 줄여 줍니다.
- 빠른 온보딩: 새 개발자가 거대한 코드베이스 전체가 아니라, 잘 정의된 한 서비스부터 익힐 수 있습니다.
다만 트레이드오프도 분명합니다. 마이크로서비스는 강력하지만 그만큼 복잡합니다. 초기 단계의 작은 제품은 단순한 모놀리식으로 시작하는 편이 더 빠르고 안전한 경우가 많습니다.
작동 방식
전형적인 마이크로서비스 시스템은 몇 가지 핵심 요소로 구성됩니다. 온라인 쇼핑몰을 예로 들어 보겠습니다.
- 서비스 경계 설정. 제품을 비즈니스 기능별로 나눕니다. 예: 상품 카탈로그, 장바구니, 결제, 배송, 알림, 리뷰 서비스 등.
- API와 메시지 통신. 서비스들은 HTTP API, gRPC, 메시지 큐 등을 사용해 서로 통신합니다. 장바구니 서비스는 상품 서비스에 가격을 요청하고, 주문이 들어오면 이벤트를 발행하는 식이죠.
- 서비스별 데이터베이스. 각 서비스는 보통 자신의 데이터를 직접 소유합니다. 주문 서비스의 DB와 사용자 계정 DB가 분리되어 있어, 각자 독립적으로 진화할 수 있습니다.
- 컨테이너와 오케스트레이션. 서비스는 보통 컨테이너(주로 Docker)로 패키징되고, Kubernetes 같은 오케스트레이션 플랫폼 위에서 자동으로 배포, 확장, 재시작됩니다.
- 관측 가능성과 보안. 움직이는 부품이 많기 때문에 중앙화된 로깅, 메트릭, 분산 추적, 인증을 구축해 전체 시스템 상태를 한눈에 볼 수 있게 합니다.
잘 설계된 마이크로서비스는 작은 프로그램들이 매끄럽게 협력하는 것처럼 느껴집니다. 반대로 잘못 설계하면 모놀리식보다 더 디버깅하기 어려운 "분산된 진흙 덩어리"가 될 수도 있습니다. 그래서 많은 팀이 처음에는 깔끔한 모놀리식으로 시작하고, 명확한 이유가 생겼을 때 마이크로서비스로 분리합니다.
자주 볼 수 있는 예시
| 제품 영역 | 대표 마이크로서비스 예시 | 분리한 이유 |
|---|---|---|
| 이커머스 사이트 | 카탈로그, 장바구니, 결제, 배송, 리뷰 | 각자 다른 속도로 성장하고 확장됨 |
| 스트리밍 서비스 | 사용자 계정, 추천, 재생, 결제 | 추천은 연산 부담, 결제는 안정성이 중요 |
| 차량 호출 앱 | 지도, 매칭, 결제, 기사 채팅, 평점 | 실시간 매칭과 결제는 요구사항이 매우 다름 |
| 모바일 뱅킹 | 계좌, 카드, 송금, 사기 탐지, 알림 | 보안과 규제 준수를 위해 강한 분리 필요 |
| SaaS 제품 | 인증, 결제, 핵심 기능, 리포팅 | 팀별로 서로 다른 영역을 소유 |
많은 유명한 제품, 특히 대형 스트리밍 서비스나 대형 온라인 쇼핑몰은 자신의 백엔드를 수백, 때로는 수천 개의 마이크로서비스 집합으로 공개적으로 설명합니다.
핵심 정리
마이크로서비스는 하나의 큰 프로그램 대신, 작고 독립적인 여러 서비스의 집합으로 소프트웨어를 만드는 방식입니다. 각 서비스는 한 가지 기능만 담당하고, API와 메시지를 통해 서로 협력합니다. 이 방식은 큰 제품이 더 빠르게 출시되고, 일부만 따로 확장할 수 있게 하며, 장애가 한 곳에 머물도록 도와줍니다. 단, 운영 복잡도는 늘어납니다.
대부분의 작은 프로젝트는 여전히 깔끔한 모놀리식으로 시작하는 것이 좋습니다. 하지만 제품, 팀, 트래픽이 하나의 코드베이스로 감당하기 버거운 단계에 들어서면, 마이크로서비스는 시스템 건강을 유지하면서 확장하기 위한 강력한 도구가 됩니다.
관련 용어
- API — 마이크로서비스끼리, 그리고 클라이언트 앱과 통신할 때 사용하는 통로입니다.
- 클라우드 컴퓨팅(Cloud Computing) — 대부분의 마이크로서비스가 실제로 실행되는 인프라 계층입니다.
- 데브옵스(DevOps) — 많은 작은 서비스를 안정적으로 배포하고 운영하기 위한 문화와 도구입니다.
- 컨테이너(Container) — 대부분의 마이크로서비스가 패키징되는 단위(주로 Docker)입니다.
- 모놀리식(Monolith) — 마이크로서비스와 자주 비교되는, 전통적인 단일 코드베이스 구조입니다.
출처
- Martin Fowler — "Microservices": 마이크로서비스 스타일과 트레이드오프를 정의하는 데 큰 영향을 준 글. (https://martinfowler.com/articles/microservices.html)
- AWS — Microservices on AWS: 클라우드에서 마이크로서비스를 운영하기 위한 패턴, 도구, 레퍼런스 아키텍처 문서. (https://aws.amazon.com/microservices/)
- Microsoft Learn — Microservices architecture style: 마이크로서비스 시스템의 설계, 배포, 운영을 위한 실용 가이드. (https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices)