프론트엔드에서 직접 DB에 쿼리를 날리는 코드를 발견했습니다. 또 다른 팀의 마이크로서비스가 우리 팀의 DB 테이블을 직접 읽고 있습니다. 아무도 스키마를 함부로 바꿀 수 없는 상황이 됩니다. DB가 아키텍처의 어디에 위치해야 하는지, 어느 계층만 접근해야 하는지 이해하지 못하면 이런 결합 문제가 시스템 전체로 퍼집니다.

확대

3-Tier 아키텍처: DB는 비즈니스 계층만 접근한다

3-Tier 아키텍처는 소프트웨어를 세 개의 독립적인 계층으로 나누는 가장 보편적인 패턴입니다. 프론트엔드 코드에서 SELECT * FROM users WHERE id = ?를 직접 날리거나, 반대로 DB가 UI 로직을 포함하면 보안 구멍이 생기고 코드 변경이 전체 스택에 파급됩니다. 3-Tier는 각 계층이 자신의 역할만 담당하도록 강제해 이 문제를 근본적으로 차단합니다.

확대

각 계층의 역할에서 핵심은 DB 접근 경로입니다. 프레젠테이션 계층은 DB와 직접 통신하지 않고, 비즈니스 로직 계층만이 SQL을 실행하고 결과를 가공합니다. 데이터 계층은 오직 비즈니스 계층만 접근합니다. 프론트엔드가 DB에 직접 쿼리를 날리는 구조는 보안과 유지보수 관점에서 심각한 문제를 만듭니다.

MSA에서의 DB-per-Service 패턴

마이크로서비스 아키텍처(MSA)에서는 각 서비스가 자신만의 데이터베이스를 소유합니다. DB가 서비스 내부에 캡슐화되는 것이 핵심입니다. User Service와 Order Service가 같은 PostgreSQL을 공유하면, users 테이블에 컬럼을 추가할 때 Order Service 코드도 함께 수정·배포해야 합니다. MSA가 약속하는 독립 배포가 불가능해지는 것입니다. DB-per-Service는 이 결합을 근본적으로 끊습니다.

확대

DB-per-Service 패턴의 핵심 장점은 세 가지입니다. 첫째, 독립적 배포—User Service의 스키마를 변경해도 Order Service에 영향이 없습니다. 둘째, 기술 선택 자유—제품 카탈로그는 MongoDB, 주문은 PostgreSQL, 세션은 Redis를 선택할 수 있습니다. 셋째, 독립적 스케일링—주문 서비스의 DB만 따로 스케일 아웃할 수 있습니다.

공유 DB 패턴의 문제점

MSA에서 여러 서비스가 하나의 DB를 공유하면(위 그림 아래쪽) DB가 서비스 간 강한 결합의 원인이 됩니다.

Order Service가 users 테이블을 직접 JOIN하면, users 테이블의 컬럼 이름을 바꿀 때 Order Service도 함께 수정해야 합니다. 스키마 변경 시 모든 관련 서비스를 동시에 배포해야 하고, 공유 DB가 다운되면 모든 서비스가 동시에 장애를 겪습니다.

실무 팁: MSA 초기에는 공유 DB로 시작해서 서비스가 안정되면 분리하는 "Strangler Fig" 전략을 쓰는 경우도 많습니다. 처음부터 완벽한 분리를 강요하면 오히려 개발 속도가 느려질 수 있습니다.

API Gateway 패턴과 DB

MSA에서 클라이언트는 각 서비스에 직접 접근하지 않고 API Gateway를 거칩니다.

Client → API Gateway → User Service    → Users DB
                    → Order Service   → Orders DB
                    → Product Service → Products DB

API Gateway는 라우팅, 인증, 속도 제한을 담당하며 DB에는 직접 접근하지 않습니다. 여러 서비스의 데이터를 조합해야 할 때는 API Gateway가 각 서비스를 호출해 결과를 합칩니다(Backend for Frontend 패턴).

대시보드용 집계 쿼리가 느려서 인덱스를 추가했는데, 오히려 주문 생성 API의 INSERT가 느려졌습니다. 읽기와 쓰기가 같은 DB에 있어서 최적화 방향이 서로 충돌합니다. CQRS는 이 문제를 쓰기 모델과 읽기 모델을 분리해서 각각 독립적으로 최적화하는 패턴으로 해결합니다.

확대

CQRS란 무엇인가

CQRS(Command Query Responsibility Segregation)는 데이터를 **변경하는 Command(명령)**와 데이터를 **조회하는 Query(질의)**의 처리 경로를 완전히 분리하는 패턴입니다. 2010년 Greg Young이 체계화했으며, 현재는 대형 서비스에서 보편적으로 사용됩니다. 주문 목록 API가 매번 users, orders, order_items, products를 JOIN하는 무거운 쿼리를 실행하는데 쓰기는 드물고 읽기가 폭발적으로 많은 상황을 생각해보세요. 정규화된 단일 DB 하나로는 한계가 옵니다. CQRS는 읽기와 쓰기 경로를 아예 다른 DB로 분리해 이 문제를 해결합니다.

확대

Command 모델: 쓰기에 최적화

Write DB는 데이터 무결성에 집중합니다. 정규화된 구조로 외래키와 제약조건을 엄격하게 적용합니다. Command는 CreateOrder, UpdateOrderStatus, CancelOrder처럼 의도를 명확히 표현하는 이름을 사용합니다.

CREATE TABLE orders (
    id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id     UUID NOT NULL REFERENCES users(id),
    status      VARCHAR(20) NOT NULL DEFAULT 'pending',
    created_at  TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE TABLE order_items (
    id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    order_id    UUID NOT NULL REFERENCES orders(id),
    product_id  UUID NOT NULL REFERENCES products(id),
    quantity    INT NOT NULL CHECK (quantity > 0),
    unit_price  NUMERIC(10, 2) NOT NULL
);

실행 완료 또는 조회 결과가 표시됩니다.

Query 모델: 읽기에 최적화

Read DB는 조회 성능에 집중합니다. 정규화를 포기하고 조회에 필요한 데이터를 미리 합쳐 놓습니다. 이 구조에서는 복잡한 JOIN 없이 단순 SELECT 한 번으로 주문 목록 화면을 구성할 수 있습니다.

CREATE TABLE order_summary_view (
    order_id        UUID PRIMARY KEY,
    user_name       VARCHAR(100),
    user_email      VARCHAR(255),
    status          VARCHAR(20),
    total_amount    NUMERIC(10, 2),
    item_count      INT,
    product_names   TEXT[],
    created_at      TIMESTAMPTZ
);

Write DB에서 Read DB로 데이터 동기화

두 DB를 동기화하는 방식은 크게 세 가지입니다.

이벤트 기반 동기화는 Write DB에서 변경이 발생하면 이벤트를 발행하고 Event Bus를 거쳐 Read DB를 업데이트합니다. 가장 유연하고 권장되는 방식입니다.

PostgreSQL Logical Replication은 DB 수준에서 변경 내용을 스트리밍합니다. Publisher(Write DB)와 Subscriber(Read DB)를 아래와 같이 설정합니다.

CREATE PUBLICATION orders_pub FOR TABLE orders, order_items;

CREATE SUBSCRIPTION orders_sub
    CONNECTION 'host=write-db ...'
    PUBLICATION orders_pub;

Materialized View는 단일 DB 내에서 조회용 스냅샷을 주기적으로 갱신합니다. 별도 인프라 없이 시작하기 좋은 방식입니다.

CREATE MATERIALIZED VIEW order_summary AS
SELECT
    o.id AS order_id,
    u.name AS user_name,
    u.email AS user_email,
    o.status,
    SUM(oi.quantity * oi.unit_price) AS total_amount,
    COUNT(oi.id) AS item_count,
    o.created_at
FROM orders o
JOIN users u ON o.user_id = u.id
LEFT JOIN order_items oi ON o.id = oi.order_id
GROUP BY o.id, u.name, u.email, o.status, o.created_at;

REFRESH MATERIALIZED VIEW CONCURRENTLY order_summary;

CQRS를 언제 적용해야 하는가

CQRS는 강력하지만 복잡성을 크게 높입니다. 다음 기준으로 적용 여부를 판단하세요.

채용공고에서 "CQRS/Event Sourcing 경험 우대", "Read Replica 운영 경험", "MSA 환경에서 데이터 정합성 관리 경험" 같은 표현이 보이면 이 패턴들을 이해하고 있음을 보여줄 수 있어야 합니다.

CQRS와 Read Replica는 읽기 부하를 떼어내 독립 스케일링을 가능하게 하지만, 함께 딸려오는 것이 있습니다 — 시간차입니다. 쓰기는 Write DB/Primary에, 읽기는 Read DB/Replica에 도착하는데, 그 둘을 잇는 동기화(복제)는 대개 비동기라 지연(replication lag)이 존재합니다.

• 동기 복제는 지연을 없애지만 쓰기 응답이 느려지고 가용성 비용이 큽니다. 그래서 실무 대부분은 비동기를 쓰고, 그 결과 방금 커밋한 데이터가 Read 쪽엔 아직 없을 수 있습니다(stale read).
• 이로 인한 두 함정: read-your-writes(내가 쓴 걸 바로 못 읽음), monotonic reads(새로고침마다 값이 앞뒤로 튐).
• 설계로 다루기: '쓰고 바로 읽어야 하는' 요청은 Primary로 라우팅, 복제 지연을 모니터링해 임계 초과 시 Read 라우팅을 일시 차단, 어디까지 오래된 데이터를 허용할지(staleness 경계)를 요구사항으로 명시.

즉 CQRS·복제 분리는 '강한 일관성'을 결과적 일관성으로 바꾸는 대신 성능을 얻는 거래입니다. 그 거래 조건을 모른 채 도입하면, 성능은 좋아졌는데 '가끔 데이터가 안 보인다'는 버그 리포트에 시달리게 됩니다.