MSA에서 DB를 서비스별로 나누는 이유

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를 나누는 것은 단순한 기술 선택이라기보다, 서비스 간 책임과 경계를 명확히 하기 위한 설계 방식이라고 볼 수 있습니다.