🛠️ 왜 데이터베이스 공유가 '악취나는 아키텍처'로 여겨질까?

"데이터베이스 공유 자체가 항상 악취나는 아키텍처는 아니다." 특히 CQRS 패턴에서 읽기(Read-Only) DB를 공유하는 것은 일반적으로 권장되는 패턴이다.

그렇다면 왜 "DB 공유는 나쁘다"라는 이야기가 자주 나올까? 여기에는 몇 가지 핵심 원인이 있다.

---

📚 1. 데이터베이스 공유가 악취로 여겨지는 이유

✅ 1.1 서비스 간 높은 결합도 (Tight Coupling)

• 여러 서비스가 동일한 데이터베이스 스키마를 공유할 때, 한 서비스의 변경이 다른 서비스에 예상치 못한 영향을 미칠 수 있음.
• 예를 들어, A 서비스가 테이블 구조를 변경하면, B 서비스가 이를 인지하지 못하고 장애가 발생할 수 있음.

예시:

• 서비스 A: 테이블에 새로운 필드를 추가
• 서비스 B: 기존 스키마를 가정하고 쿼리를 실행 → 오류 발생

---

✅ 1.2 스키마 진화 (Schema Evolution)의 어려움

• 여러 서비스가 같은 DB를 공유하면 스키마 진화(변경)가 어려워짐.
• 서비스마다 필요한 데이터 구조가 다를 수 있는데, 이를 공통 스키마로 관리하려고 하면 복잡도가 급증.

예시:

• 서비스 A는 users 테이블에 새로운 필드(is_active)를 추가.
• 서비스 B는 이 필드를 지원하지 않고 계속 오류 발생.

---

✅ 1.3 단일 장애 지점 (Single Point of Failure)

• 모든 서비스가 같은 DB에 의존하면, 데이터베이스에 문제가 발생할 경우 전체 시스템이 다운될 위험이 있음.
• 데이터베이스에 과도한 부하가 발생하면, 모든 서비스의 성능이 저하됨.

예시:

• 서비스 A가 과도한 트래픽을 발생시켜 DB 연결을 모두 점유.
• 서비스 B는 정상적으로 데이터베이스에 접근할 수 없음.

---

✅ 1.4 트랜잭션 경합 (Transaction Contention)

• 여러 서비스가 동일한 테이블에 동시에 쓰기(Write) 연산을 수행하려고 할 때, 트랜잭션 경합(Deadlock)이 발생할 수 있음.
• 이는 성능 저하로 이어짐.

예시:

• 서비스 A와 서비스 B가 같은 테이블에 동시에 Update를 시도.
• 데이터 잠금(Locking)이 발생하여 병목 현상 발생.

---

✅ 1.5 책임 분리 원칙 위반 (Separation of Concerns)

• MSA(Microservices Architecture)에서는 각 서비스가 자신의 데이터베이스를 소유해야 한다는 원칙이 존재.
• 데이터베이스를 공유하면 각 서비스의 책임 영역이 모호해지고 변경이 어려워짐.

예시:

• 서비스 A는 주문(Order) 데이터를 관리.
• 서비스 B는 결제(Payment) 데이터를 관리.
• 하나의 orders 테이블을 공유하면서 서로 변경을 가할 경우, 책임 분리가 모호해짐.

---

🚀 2. CQRS에서 조회(Read-Only) DB 공유가 허용되는 이유

✅ 2.1 Read-Only 접근 보장

• Query 서비스는 조회 전용(Read-Only)으로만 동작하기 때문에 스키마 변경이나 트랜잭션 경합 문제가 발생하지 않음.

✅ 2.2 데이터 복제

• Kafka나 Change Data Capture(CDC) 패턴을 사용해 Command DB → Query DB로 데이터를 복제함.
• 이로 인해 Command DB와 Query DB가 독립적으로 운영될 수 있음.

✅ 2.3 일관된 데이터 조회

• 여러 Query 서비스가 동일한 조회용 DB를 사용하면 데이터 일관성(Consistency)이 유지됨.

핵심 포인트:

• 조회 전용(Read-Only) DB는 여러 서비스가 공유할 수 있다.
• 하지만 쓰기(Write) 작업은 절대 허용되지 않아야 한다.

---

🛡️ 3. 올바른 DB 공유 패턴

✅ 3.1 공유를 피해야 할 경우

• Command DB (쓰기/트랜잭션 DB)는 공유하지 않아야 한다.
• 서비스 간 데이터베이스 스키마가 서로 다른 요구사항을 가지는 경우.

✅ 3.2 공유해도 되는 경우

• Query DB (읽기 전용 DB)는 여러 서비스가 공유할 수 있다.
• Kafka나 CDC를 통해 데이터가 동기화되는 구조일 경우.

---

📊 4. 정리: 악취가 나는 아키텍처와 허용되는 아키텍처

유형	설명	허용 여부
Command DB 공유	여러 서비스가 동일한 Command DB를 사용	❌ 금지
Query DB 공유 (Read-Only)	여러 서비스가 동일한 조회 전용 DB를 사용	✅ 허용
단일 테이블을 읽기/쓰기 혼합 사용	여러 서비스가 동일 테이블을 읽기/쓰기	❌ 금지

---

🧠 5. 핵심 정리

1. 공유 자체가 문제는 아니다:

   • 문제가 되는 것은 쓰기(Write) DB를 여러 서비스가 공유할 때 발생하는 결합도와 트랜잭션 문제이다.

2. 조회(Read-Only) DB 공유는 허용된다:

   • Kafka, CDC를 통해 데이터를 복제한 후, 읽기 전용으로만 접근하는 경우는 괜찮다.

3. 책임 분리:

   • 각 서비스는 자신만의 Command DB를 가져야 한다.
   • Query DB는 필요에 따라 여러 서비스가 공유할 수 있다.

4. Kafka의 역할:

   • Command DB의 변경사항을 Kafka를 통해 Query DB로 전달.
   • 비동기적 데이터 복제를 통해 데이터 일관성을 유지.

---

📝 6. 권장 아키텍처

[Command Service (Spring Boot)] → [Command DB]
       │
       ▼
[Kafka (Event Stream)]
       │              │
       ▼              ▼
[Query Service A]   [Query Service B]
       │              │
       ▼              ▼
[Query DB (공유)]

• Command Service는 Command DB에 쓰기 전용.
• Query Service는 Query DB에서 읽기 전용으로 데이터 조회.
• Kafka가 이벤트 스트림을 통해 Command DB의 변경사항을 Query DB로 전달.

---

🚦 7. 결론

• DB 공유가 악취로 여겨지는 이유: 주로 Command DB의 공유로 인한 높은 결합도, 스키마 관리 문제, 트랜잭션 경합 때문이다.
• CQRS에서는 Query DB를 공유하는 것이 가능하며 오히려 효율적일 수 있다.
• 중요한 것은 명확한 책임 분리와 Read-Only 원칙 준수이다.