MSA 구조를 공부하다 보면 “서비스별로 DB를 분리해야 한다”는 이야기를 자주 보게 됩니다.
처음에는 단순히 데이터를 물리적으로 나누기 위한 것처럼 보일 수 있습니다.
하지만 DB를 나누는 가장 큰 목적은 단순한 데이터 분리보다 서비스 간 책임 경계를 명확히 하는 것에 가깝습니다.
테이블만 나누는 경우
하나의 DB 안에 여러 서비스의 테이블을 함께 두는 방식도 가능합니다.
예를 들어 다음과 같은 구조입니다.
app_db
├── users
├── products
├── orders
└── payments
이 구조에서는 데이터가 테이블 단위로 분리되어 있습니다.
user-service는 users 테이블을 사용하고, product-service는 products 테이블을 사용하도록 규칙을 정할 수 있습니다.
user-service → users 테이블 사용
product-service → products 테이블 사용
order-service → orders 테이블 사용
하지만 문제는 규칙상 분리되어 있을 뿐, 기술적으로는 다른 서비스의 테이블에도 접근할 수 있다는 점입니다.
예를 들어 user-service는 원칙적으로 users 테이블만 조회해야 합니다.
하지만 같은 DB 안에 products 테이블이 있다면, 마음만 먹으면 다음과 같이 다른 서비스의 테이블을 직접 조회할 수 있습니다.
user-service → products 테이블 직접 조회 가능
이렇게 되면 서비스 간 경계가 흐려집니다.
처음에는 편의를 위해 직접 조회할 수 있지만, 시간이 지나면 서비스 간 의존성이 강하게 생깁니다.
그 결과 특정 테이블 구조를 변경할 때 다른 서비스까지 영향을 받을 수 있습니다.
DB를 서비스별로 나누는 경우
반면 서비스별로 DB를 분리하면 각 서비스는 자신이 소유한 DB에만 접근하게 됩니다.
user-service
└── user_db
└── users
product-service
└── product_db
└── products
order-service
└── order_db
└── orders
이 구조에서는 user-service가 product_db의 테이블을 직접 조회할 수 없습니다.
user-service → user_db만 접근
product-service → product_db만 접근
order-service → order_db만 접근
즉, 서비스마다 자신이 책임지는 데이터만 직접 다룰 수 있습니다.
다른 서비스의 데이터가 필요하다면 DB를 직접 조회하는 것이 아니라, 해당 서비스의 API를 통해 요청해야 합니다.
예를 들어 주문 서비스가 사용자 정보가 필요하다면 users 테이블을 직접 조회하는 것이 아니라 user-service에 요청하는 방식입니다.
order-service
→ user-service API 호출
→ 사용자 정보 조회
이렇게 하면 데이터의 소유권이 명확해집니다.
핵심 차이
테이블 분리와 DB 분리의 차이는 단순히 저장 위치의 차이가 아닙니다.
핵심은 서비스가 다른 서비스의 데이터를 직접 참조할 수 있느냐 없느냐입니다.
| 구분 | 테이블만 분리 | DB까지 분리 |
|---|---|---|
| 데이터 분리 | 테이블 단위로 분리 | DB 단위로 분리 |
| 다른 서비스 데이터 접근 | 가능 | 기본적으로 불가능 |
| 책임 경계 | 약함 | 강함 |
| 서비스 간 결합도 | 높아질 수 있음 | 낮게 유지 가능 |
| 데이터 소유권 | 흐려질 수 있음 | 명확함 |
왜 책임 분리가 중요한가?
MSA에서는 각 서비스가 독립적으로 개발, 배포, 운영될 수 있어야 합니다.
그런데 여러 서비스가 같은 DB를 공유하면서 서로의 테이블을 직접 참조하면, 실제로는 서비스가 분리되어 있어도 데이터 계층에서 강하게 연결됩니다.
예를 들어 product-service의 테이블 구조가 변경되었는데, user-service가 몰래 해당 테이블을 조회하고 있었다면 user-service에도 문제가 발생할 수 있습니다.
product-service의 products 테이블 구조 변경
→ user-service에서 직접 조회하던 쿼리 실패
→ 예상하지 못한 장애 발생
이런 상황을 막기 위해 서비스별 DB 분리를 사용합니다.
DB를 분리하면 각 서비스는 자신의 데이터 구조를 더 자유롭게 변경할 수 있고, 다른 서비스는 API 계약을 통해서만 데이터를 사용하게 됩니다.
정리
DB를 서비스별로 나누는 이유는 단순히 데이터를 따로 저장하기 위해서만은 아닙니다.
가장 큰 목적은 서비스별 책임을 분리하고, 다른 서비스의 데이터에 직접 접근하지 못하도록 경계를 만드는 것입니다.
하나의 DB 안에서 테이블만 나누면 데이터는 분리되어 보이지만, 각 서비스가 다른 서비스의 테이블을 직접 참조할 수 있습니다.
반면 DB를 나누면 각 서비스는 자신이 소유한 DB에만 접근하게 되고, 다른 서비스의 데이터가 필요할 때는 API를 통해 요청해야 합니다.
결국 서비스별 DB 분리는 다음 목적을 가집니다.
서비스별 데이터 소유권 명확화
서비스 간 직접 DB 참조 방지
책임 경계 강화
서비스 간 결합도 감소
독립적인 변경과 배포 가능성 확보
MSA에서 DB를 나누는 것은 단순한 기술 선택이라기보다, 서비스 간 책임과 경계를 명확히 하기 위한 설계 방식이라고 볼 수 있습니다.