MSA에서 서비스 경계를 어떻게 나누어야 할까

마이크로서비스 설계에서 가장 어려운 문제

마이크로서비스 아키텍처(MSA)를 도입할 때 많은 팀이 먼저 고민하는 것은 기술이다.

• 어떤 언어를 사용할 것인가
• 어떤 프레임워크를 사용할 것인가
• 어떤 인프라를 사용할 것인가

하지만 실제로 MSA에서 가장 어려운 문제는 따로 있다.

바로 서비스 경계(Service Boundary)를 어떻게 나누느냐다.

서비스 경계를 잘못 설계하면 다음과 같은 문제가 발생한다.

• 서비스 간 강한 결합
• 데이터 의존성 증가
• 복잡한 API 호출 구조
• 분산 모놀리스 발생

즉 MSA의 성공 여부는 기술 스택이 아니라
서비스 경계 설계에 달려 있다.

---

1. 기능이 아니라 도메인 기준으로 나눈다

많은 시스템이 처음 MSA를 도입할 때 다음 방식으로 서비스를 나눈다.

User Service
Order Service
Payment Service

 

겉보기에는 합리적인 구조처럼 보이지만
실제로는 다음 문제가 발생할 수 있다.

예를 들어 주문 생성 과정에서 다음 작업이 필요하다.

• 사용자 검증
• 주문 생성
• 결제 처리
• 재고 확인

이 경우 서비스 간 호출이 계속 이어진다.

Order Service
→ User Service
→ Payment Service
→ Inventory Service

 

서비스 간 의존성이 높아지면
시스템 복잡성이 크게 증가한다.

그래서 MSA에서는 도메인 중심 설계(DDD) 기반으로 경계를 나누는 것이 일반적이다.

---

2. 서비스는 자신의 데이터를 소유해야 한다

MSA 설계에서 중요한 원칙 중 하나는 데이터 소유권(Data Ownership)이다.

각 서비스는 자신의 데이터베이스를 가져야 한다.

예를 들어 다음과 같은 구조다.

Auth Service
→ users DB

Order Service
→ orders DB

Inventory Service
→ inventory DB

 

이 구조에서는 다른 서비스가 데이터를 직접 접근하지 않는다.

대신 다음 방식으로 통신한다.

• API 호출
• 이벤트 메시지

이 원칙을 지키지 않으면
서비스는 분리되어 있어도 데이터 계층에서는 하나의 시스템이 된다.

---

3. 변경 가능성을 기준으로 경계를 나눈다

좋은 서비스 경계는 변경 가능성(Change Frequency)을 기준으로 나누기도 한다.

즉 함께 변경되는 기능은 같은 서비스에 두는 것이 좋다.

예를 들어 다음 기능을 생각해 보자.

• 사용자 인증
• 사용자 프로필 관리
• 사용자 권한 관리

이 기능들은 대부분 함께 변경된다.

따라서 다음 구조가 더 적합하다.

Auth Service
→ 인증
→ 프로필
→ 권한

 

반대로 서로 독립적으로 변경되는 기능은
다른 서비스로 분리하는 것이 좋다.

---

4. 서비스 간 의존성을 최소화한다

좋은 MSA 구조는 서비스 간 의존성이 낮다.

예를 들어 다음 구조는 좋지 않다.

Service A
→ Service B
→ Service C
→ Service D

 

이 구조에서는 하나의 장애가
연쇄적으로 전체 시스템에 영향을 줄 수 있다.

가능하면 서비스는 자율적으로 동작해야 한다.

즉 다음 구조가 더 안정적이다.

Service A
Service B
Service C

 

필요할 경우 이벤트나 메시지 기반으로 연결한다.

---

5. 팀 구조도 고려해야 한다

마이크로서비스 설계는 기술 문제만이 아니다.

조직 구조와도 깊이 연결되어 있다.

이를 설명하는 유명한 원칙이 있다.

Conway's Law

 

즉

시스템 구조는 조직 구조를 반영한다

 

예를 들어 팀이 다음처럼 나뉘어 있다면

• 인증 팀
• 주문 팀
• 검색 팀

서비스 구조도 비슷하게 나누는 것이 자연스럽다.

이렇게 하면 각 팀이 자신의 서비스를 독립적으로 개발하고 운영할 수 있다.

---

좋은 서비스 경계의 특징

좋은 서비스 경계는 다음 특징을 가진다.

• 도메인 중심으로 분리되어 있다
• 데이터 소유권이 명확하다
• 서비스 간 의존성이 낮다
• 독립적인 배포가 가능하다
• 팀 구조와 잘 맞는다

이 기준을 만족하면
MSA는 실제로 확장성과 유연성을 제공하는 구조가 된다.

---

정리

MSA에서 가장 중요한 설계 요소는 서비스 개수가 아니다.

서비스를 얼마나 많이 나누느냐보다
어디에서 경계를 나누느냐가 훨씬 중요하다.

좋은 서비스 경계는 다음 기준으로 설계된다.

기준설명

도메인 중심 설계	기능이 아니라 비즈니스 영역 기준
데이터 소유권	서비스별 DB
변경 가능성	함께 변경되는 기능
의존성 최소화	서비스 독립성
팀 구조	Conway's Law

마이크로서비스 아키텍처의 핵심은
많은 서비스가 아니라 올바른 경계 설계다.