← 목록으로
기타 2026.03.13 ✍️ 허영현

ERD 설계 및 Flyway 기반 DB 형상 관리

ERD 설계 및 Flyway 기반 DB 형상 관리

ERD 설계 및 Flyway 기반 DB 형상 관리

1. 핵심 도메인: 회원, 상품, 구독 및 과금

📌 도메인 개요 

우리 서비스의 근간이 되는 통신 상품 카탈로그와 고객의 가입(구독), 과금 상태를 관리하는 핵심 ERD입니다.

💡 주요 설계 포인트

2. 고객 상담 및 키워드 분석

📌 도메인 개요 

고객의 문의 내역(CS)을 기록하고, 상담 텍스트에서 비즈니스 키워드를 추출하여 분석하는 NLP 파이프라인의 결과물이 저장되는 ERD입니다.

💡 주요 설계 포인트

3. 고객 페르소나 및 추천

📌 도메인 개요 

고객의 행동 데이터를 수집하고 이를 바탕으로 페르소나(성향)를 도출한 뒤, 맞춤형 상품을 추천해 주는 분석/추천 도메인입니다.

💡 주요 설계 포인트

4. 마케팅 및 인증

📌 도메인 개요 

고객의 쿠폰 혜택, 최근 조회 이력 관리, 그리고 보안(로그인)과 관련된 부가 기능을 담당하는 ERD입니다.

💡 주요 설계 포인트

5. 시스템 배치 및 마이그레이션 메타

📌 도메인 개요 

비즈니스 로직이 아닌, 시스템의 안정적인 운영과 데이터베이스 형상 관리를 위해 프레임워크가 사용하는 메타데이터(Metadata) 테이블입니다.

💡 주요 설계 포인트

Spring DB Migration Tool

1. 배경

현재 우리 프로젝트는 하나의 PostgreSQL 인스턴스 내에서 4개의 스키마(Core, Reco, Analytics, Notification)를 논리적으로 분리하여 사용하는 구조

⇒ 개발 및 운영 단계에서 다음과 같은 문제점이 예상되어, 명확한 DB 형상 관리 도구가 필요

1) 데이터 증발 리스크

JPA의 ddl-auto: update는 편리하지만, 운영 중인 데이터의 안전성을 보장하지 못함

(예: NOT NULL 제약 추가 시 기존 데이터 충돌로 인한 테이블 Drop 위험)

2) 협업 간 스키마 불일치

팀원 A가 로컬 DB를 수정하고 코드를 푸시했을 때, 팀원 B의 로컬 환경에서 DB 에러가 발생하여 개발 흐름이 끊기는 현상이 잦음 → “내 컴퓨터에선 되는데?” 방지

3) jOOQ 코드 생성 의존성

jOOQ는 DB 스키마를 기반으로 자바 코드를 생성하므로, 소스 코드보다 DB 스키마가 먼저 확정되고 관리되어야 함

2. 후보군 비교

JPA(Hibernate DDL), Liquibase, Flyway 세 가지 검토

구분 1. JPA (ddl-auto) 2. Liquibase 3. Flyway
방식 Java 엔티티 코드 기반 자동 생성 XML, YAML, JSON 등 DSL 사용 순수 SQL 파일 (.sql)
장점 초기 세팅이 빠르고 간편함 DB 벤더가 바뀌어도 호환 가능 (추상화) 러닝커브가 없음 (SQL만 알면 됨)
단점 데이터 보존 불가, 세밀한 제어 불가능 XML/YAML 작성 번거로움, 문법 학습 필요 DB를 바꾸면 SQL을 다시 짜야 함
평가 ❌ 프로토타입용, 운영 불가 ⚠️ 7주 프로젝트에 과한 스펙 ✅ 우리 프로젝트에 최적

3. 결정

우리 프로젝트는 Flyway를 공식 DB 마이그레이션 도구로 채택

4. 상세 선정 근거

1) “운영 데이터 보호”가 최우선

JPA의 update 옵션은 기존 데이터가 있는 상태에서 구조를 변경할 때 매우 취약 예를 들어 User 테이블에 필수값(NOT NULL)인 nickname 컬럼을 추가하는 경우

2) PostgreSQL 특화 기능(JSONB, Multi-Schema)의 제약 없는 활용

우리 프로젝트는 추천 시스템의 페르소나 태그 저장을 위해 PostgreSQL의 JSONB 타입 사용, 스키마를 명시적으로 분리

→ 이를 구현하기 위해 Flyway가 필수적인 이유는 다음과 같음

2-1. JSONB 및 GIN Index 성능 최적화

2-2. 멀티 스키마(Multi-Schema) 및 권한 관리(DCL)의 용이성

3) 짧은 프로젝트 기간과 낮은 러닝커브

총 7주라는 짧은 개발 기간 동안, 팀원들이 Liquibase의 XML/YAML 문법을 새로 익히는 것은 비효율적 Flyway는 백엔드 개발자라면 누구나 아는 표준 SQL을 사용하므로, 도입 즉시 모든 팀원이 스크립트를 작성하고 리뷰 가능

4) jOOQ와의 파이프라인 일치

분석/추천 모듈은 복잡한 통계 쿼리를 위해 jOOQ를 사용

5. 리퀴베이스 (+ 버린 이유)

1. 리퀴베이스(Liquibase)란?

Flyway가 SQL을 그대로 쓰는 거라면, 리퀴베이스는 XML, YAML, JSON 같은 별도의 문법으로 DB를 정의

🆚 코드 비교

상황: member 테이블 만들기

Flyway (SQL 그대로)

-- V1__create_member.sql
CREATE TABLE member (
    id BIGINT PRIMARY KEY,
    name VARCHAR(255)
);

Liquibase (XML 방식)

<changeSet id="1" author="dba">
    <createTable tableName="member">
        <column name="id" type="BIGINT">
            <constraints primaryKey="true"/>
        </column>
        <column name="name" type="VARCHAR(255)"/>
    </createTable>
</changeSet>

리퀴베이스는 코드가 훨씬 길고 복잡

2. 리퀴베이스의 장점 (근데 왜 쓰는 거야?)

이렇게 복잡한데도 쓰는 이유는 DB 독립성 때문

즉, “우리 회사는 고객사마다 DB를 다르게 써요(어디는 오라클, 어디는 MySQL)” 하는 솔루션 회사에서는 리퀴베이스 추천

3. 우리 프로젝트에서 리퀴베이스를 버린 이유 (탈락 사유)

❌ 이유 1: 우리는 ‘PostgreSQL’ 하나만 판다.

우리는 지금 돈 아끼려고 AWS RDS(PostgreSQL) 딱 하나만 씀, 나중에 오라클로 바꿀 계획 없음

❌ 이유 2: PostgreSQL의 ‘특수 기능(JSONB)’ 쓰기 힘들다.

우리는 추천 시스템 때문에 JSONB 타입이나 Partial Index 같은 PostgreSQL 전용 기능을 써야함 리퀴베이스는 “모든 DB에서 되는 기능”을 위주로 만들어져 있어서, 이런 특수 기능을 쓰려면 설정이 엄청 복잡하거나 결국 SQL을 직접 써야함

Flyway는 그냥 SQL에 jsonb라고 적으면 끝

❌ 이유 3: 7주라는 시간 제한 (생산성)

4. 결론

리퀴베이스는 여러 종류의 DB를 동시에 지원해야 할 때 좋은 도구 하지만 우리는 PostgreSQL의 기능을 100% 활용해야 하고, 개발 속도가 중요 굳이 XML 문법을 새로 배우는 비용을 치르지 말고, 익숙한 **SQL(Flyway)**로 가자

📎 참고 자료 (참고한 블로그 등)

데이터 베이스 형상관리(Migration)툴 비교 Flyway vs Liquibase

[SpringBoot] 데이터베이스 마이그레이션 툴 Flyway 도입기

##ERD #DB #형상관리 #Flyway #마이그레이션