MSA 입문 (모놀리식, 분리, 통신)
클라우드 네이티브 아키텍처 이야기에서 가장 자주 등장하는 약어가 MSA다. 여기서 MSA란 Microservice Architecture의 줄임말로, 하나의 거대한 애플리케이션을 작은 단위의 독립된 서비스 묶음으로 분해해 운영하는 설계 양식을 가리킨다. 모놀리식(monolithic) 시대를 한 번 거쳐 본 조직일수록 MSA를 더 진지하게 고려하는 경향이 강하며, Netflix·Amazon·Coupang 같은 대규모 서비스가 모두 MSA로 전환한 이력이 그 흐름을 잘 보여 준다(출처: Martin Fowler — Microservices). 본 글은 MSA가 왜 등장했는지, 마이크로서비스 분리의 기준이 무엇인지, 그리고 서비스 간 통신과 운영 도전 과제는 무엇인지를 입문 수준에서 정리한다. 제가 학교 졸업 프로젝트에서 처음 모놀리식과 MSA를 섞어 써 본 경험이 있는데, 솔직히 그 전까지는 "MSA는 무조건 좋은 것"이라는 막연한 인상을 갖고 있다가 운영 비용을 직접 체감한 후로 "조직 규모와 도메인 복잡도가 일정 수준을 넘어야 의미가 있다"는 결론을 손끝으로 받아들였다.
MSA가 풀어 주는 모놀리식의 한계
모놀리식 아키텍처(Monolithic Architecture)란 모든 비즈니스 로직과 데이터 접근, 사용자 인터페이스가 하나의 코드베이스와 단일 배포 단위에 묶여 있는 전통적인 구조를 가리킨다. 학교에서 처음 만드는 토이 프로젝트는 거의 예외 없이 모놀리식이며, 이 구조의 강점은 시작이 단순하고 IDE 한 화면에서 모든 코드를 추적할 수 있다는 점이다. 다만 시스템이 커지면서 두 가지 한계가 명확히 드러난다. 첫째, 한 줄을 바꿔도 전체 애플리케이션을 다시 빌드·배포해야 한다. 둘째, 부하가 특정 영역에만 집중되더라도 시스템 전체를 함께 확장해야 한다.
MSA는 이 두 한계를 해결하는 분해 전략이다. 비즈니스 도메인을 작은 서비스 단위로 쪼개고, 각 서비스가 자기 데이터·자기 배포 파이프라인·자기 확장 단위를 갖게 만든다. 그 결과 사용자 서비스만 빠르게 배포할 수 있고, 트래픽이 몰리는 검색 서비스만 따로 10배로 확장할 수 있게 된다. 여기서 자기 데이터(Database per Service) 원칙이란 각 마이크로서비스가 다른 서비스의 데이터베이스에 직접 접근하지 않고 자신만의 저장소를 가지는 분리 원칙을 의미하며, MSA의 가장 본질적인 약속 중 하나이다.
또한 MSA는 조직의 자율성을 기술적으로 뒷받침한다. 각 팀이 한 마이크로서비스를 끝부터 끝까지(개발·배포·운영) 책임지는 흐름이 자연스럽게 자리 잡고, 팀별 기술 스택의 자유도가 올라간다. 솔직히 이건 예상 밖이었는데, 제가 인턴십에서 본 실제 운영 조직의 MSA 도입 동기는 기술적 이점보다 "팀 사이의 의사결정 충돌을 줄이기 위함"이 더 크다는 점이었다. 즉 MSA는 단순한 코드 분해가 아니라 조직 분해의 거울이며, 콘웨이 법칙이 가장 잘 드러나는 영역이기도 하다.
마이크로서비스 분리 기준 — DDD와 도메인 경계
MSA의 가장 어려운 작업은 "어디를 기준으로 서비스를 쪼갤 것인가"이다. 잘못 쪼개면 모놀리식보다도 운영이 어려워지는 분산 모놀리식(Distributed Monolith) 함정에 빠진다. 이 분리의 정답에 가장 가까운 도구가 도메인 주도 설계(Domain-Driven Design, DDD)이며, 그 핵심 개념인 바운디드 컨텍스트(Bounded Context)가 곧 마이크로서비스의 경계 후보가 된다. 여기서 바운디드 컨텍스트란 같은 용어와 모델이 같은 의미로 통용되는 도메인 영역의 경계를 가리킨다. 예컨대 "주문"이라는 단어가 결제 도메인과 배송 도메인에서 다른 의미로 쓰인다면 그 경계가 두 컨텍스트의 분리 후보가 된다.
분리 기준의 실용적 체크리스트는 다음 네 가지로 정리된다. 첫째, 한 서비스의 변경이 다른 서비스의 동시 배포를 강제하지 않는가. 둘째, 서비스의 데이터가 자기 안에서 닫혀 있는가. 셋째, 한 사용자 요청이 N개의 서비스 호출 체인을 만들지 않는가. 넷째, 팀 단위로 그 서비스를 끝까지 책임질 수 있는가. 이 네 가지 체크에 모두 답할 수 있을 때만 그 분리가 의미 있는 마이크로서비스 경계라고 평가할 수 있다(출처: AWS — Microservices on AWS).
또 한 가지 중요한 사실은 MSA는 "처음부터 모두 분리"가 아니라 "필요한 곳부터 점진적으로 분리"가 정답이라는 점이다. 마틴 파울러의 monolith-first 원칙이 이를 정리한 표현으로, 도메인 경계가 충분히 안정될 때까지는 모놀리식으로 시작하고, 운영하면서 명확해진 경계를 따라 한 조각씩 분리해 나가는 흐름을 권장한다. 제 경험상 학교 프로젝트에서 처음부터 7개 서비스를 만들어 본 적이 있는데, 졸업 발표 직전 결국 4개로 합치는 작업을 하면서 monolith-first 격언을 손끝으로 이해했다.
서비스 간 통신과 운영 도전 과제
서비스를 분리하는 순간 새로운 문제가 등장한다. 한 프로세스 안에서는 함수 호출 한 줄로 끝나던 작업이, 서비스 사이에서는 네트워크 호출과 직렬화·역직렬화·재시도·타임아웃이 얽힌 복잡한 흐름이 된다. 통신 방식은 크게 동기 호출(REST·gRPC)과 비동기 메시징(Kafka·RabbitMQ)으로 나뉘며, 일반적으로 사용자 요청 경로에는 동기, 부수적 처리에는 비동기를 조합하는 흐름이 권장된다.
# 한 사용자 요청의 흐름 예시
사용자 → API Gateway
→ User Service (REST 동기)
→ Order Service (REST 동기)
→ Payment Service (REST 동기, 결제 승인)
→ 메시지 큐 (배송·알림은 비동기)여기서 API Gateway란 외부 클라이언트가 마이크로서비스 묶음에 접근할 때 단일 진입점이 되어 인증·라우팅·요청 합치기 같은 횡단 관심사를 처리하는 게이트키퍼를 의미한다. 위 흐름에서 결제까지는 동기 호출로 사용자 응답을 빠르게 만들고, 배송·알림처럼 즉시 응답이 필요 없는 작업은 메시지 큐로 비동기 분리해 시스템 전체의 응답성을 유지한다. 이 두 통신 방식을 적절히 섞는 능력이 MSA 운영의 가장 큰 변수다.
운영 측면에서는 분산 추적(Distributed Tracing), 서비스 메시(Service Mesh), 서킷 브레이커(Circuit Breaker) 같은 새로운 도구가 필수가 된다. 분산 추적은 한 사용자 요청이 거치는 모든 서비스 호출을 하나의 ID로 묶어 추적하는 기법으로, OpenTelemetry가 사실상의 표준이다. 서비스 메시는 Istio·Linkerd 같은 사이드카 기반 도구로 모든 서비스 간 통신에 보안·재시도·로드밸런싱을 일관되게 끼워 넣는 인프라 계층이다. 서킷 브레이커는 한 서비스가 실패하기 시작하면 호출을 일시적으로 차단해 장애가 전체로 번지는 사태를 막는 패턴이다. 솔직히 제 경험상 학교 수준에서는 이 셋이 다 과한 인프라처럼 느껴지지만, 운영 환경에서 한 서비스의 장애가 다른 서비스를 줄줄이 무너뜨리는 사고를 한 번 보고 나면 그 가치가 비로소 와닿는다는 점을 인턴십에서 직접 체감했다. MSA는 결국 이런 운영 비용까지 함께 받아들이고 시작해야 의미가 있는 아키텍처라는 사실을 도입 전에 분명히 해 두는 일이 가장 안전한 출발이다.
메타 디스크립션: MSA가 모놀리식의 어떤 한계를 풀고, 도메인 주도 설계 기반의 분리 기준은 무엇이며, 서비스 간 통신과 운영 도전 과제(분산 추적·서비스 메시·서킷 브레이커)는 무엇인지 입문자 관점에서 정리합니다.