[INFRA/DB] 롤백을 고려해 하위호환성을 갖춘 스키마 설계하기

📑 Table of Contents

📝 롤백을 고려하게 된 이유

🤔 스키마는 어떻게 롤백할 수 있지?

🙋 첫 시도, 롤백용 스크립트를 작성하기

🔍 스키마 롤백, 꼭 필요한가?
     ✅ flyway 를 사용함으로서 하게 된 오해
     ✅ SRE 원칙을 통한 깨달음

🚀 Expand and Contract 전략
     ✅ 예시로 이해해보기
     ✅ DDL 별 원칙

🚀 Flyway 설정 일부 변경

🚀 시드 데이터가 필요한 경우, R prefix 사용하기

---

📝 롤백을 고려하게 된 이유

지난 1개월하고도 몇주간의 프로젝트를 진행하는 상황에서, 우리는 잦은 요구사항의 변화를 겪게 됐다. 이에 따라 코드는 빠르게 변경이 이뤄졌고, 버그 픽스도 심심찮게 필요했다. 그러나 QA 를 하거나, 데모데이를 해야 하는 상황과 같이 빠르게 안정적인 서버 상태로 돌려야 하는 경우 당혹하기 일쑤였다. 

 

현재 실제 서비스 상황이 아님에도 이런 어려움을 겪는데, 실제 서비스 상황에서는 이전 버전으로 롤백에 사용자들이 일부 기능만이라도 사용할 수 있도록 해야 할 것 같다는 생각을 하게 됐다. 그러나 보니 자연스레 롤백의 필요성을 체감하고, 도입하게 됐다.

---

🤔 스키마는 어떻게 롤백할 수 있지?

서버의 롤백을 고려하고 나서, 가장 큰 의문이 들었던 지점은 스키마의 롤백이었다.

 

현재 우리는 스키마 마이그레이션 도구로 flyway 를 사용 중이다. 그렇기에 서버가 롤백된다면, 당연히 flyway 스크립트 역시도 롤백이 된다. flyway 자체에서는 롤백을 제공하지 않았다. 그러나 flyway 의 대체재인 Liquibase 에서는 롤백을 제공했기에 flyway 를 통해서도 롤백이 가능할까? 하는 의문을 품고 고민을 시작했다.

---

🙋 첫 시도, 롤백용 스크립트를 작성하기

처음에는 롤백용 스크립트를 작성하는 것을 선택했다.

 

롤백용 스크립트는 다른 경로에 두고, 롤백을 해야 할 때만 해당 경로를 활성화시켜 롤백용 스크립트가 동작하도록 하고자 했다.

src/main/resources/
db/migration/                    # 평시용  스크립트
V1__create_diary.sql

db/migration_emergency/          # 비상시용 보존 스크립트
V2__preserve_diary_for_rollback.sql

 

예를 들어, 위와 같이 경로를 구성하는 것이다. 

• 평상시 정상 동작 상황 : /db/migration 만을 활성화
• 롤백 필요 시 상황 : /db/migration_emergency 까지 인식되도록 하여 롤백을 반영

그러나 이러한 방식에 대해 다음과 같은 우려가 있었다.

 

1. 속도가 너무 느리다.

현재 방식대로라면, 비상시용 보존 스크립트를 포함하도록 액션을 돌려야 한다. 이를 위해 재배포가 필요하기에 장애 발생 시 사용자가 대기해야 하는 시간이 길다.

 

2. 개발자가 수동으로 관여해야 하는 부분이 너무 크다.

개발자는 스키마가 변경될 때마다 이로 인해 발생할 수 있는 상황이 무엇인지 모든 것들을 고려해 롤백 스크립트를 짜야 한다. 이는 세심하고 복잡한 작업이기에 자동화할 수도 없고, 개발자가 수동으로 관여해야 한다는 것이 위험도가 높다는 생각을 했다.

 

그래서 해당 방식에 대한 확신이 들지 않아, 계속해서 고민 했다.

---

🔍 스키마 롤백, 꼭 필요한가?

 

✅ flyway 를 사용함으로서 하게 된 오해

flyway 를 사용하고 있었기에, 스키마의 변경 지점이 결국에는 서버의 버전 업데이트 시점과 동일했다. 그래서 우리는 서버의 버전이 롤백 될 때, 당연스럽게도 스키마 역시도 롤백되어야 한다고 생각했다.

그러나 사실 다시 생각해보면 반드시 서버가 롤백된다고 해서 스키마까지 롤백될 필요는 없다. 서버에서 새로운 기능이 추가되거나, 기능이 변경됨에 따라 스키마가 변경되는 건 당연한 일이다. 그러나 서버가 업데이트 되는 시점과 반드시 맞물려서 데이터베이스 스키마를 업데이트할 필요는 없다는 것이다.

이에 대해 실무자들과 코치진들에게도 여쭤본 결과, 서비스가 버전업될 때 반드시 스키마가 동시에 업데이트 될 필요는 없다는 이야기를 많이 들었다. 주로 버전업 전에 미리 중요한 테이블은 만들어 두고, 필요 없는 것은 추후에 드랍하는 전략을 선택하며 주로 자동보다는 수동으로 처리한다는 것을 알게 됐다. 이는 내가 flyway 를 사용하며 서버를 업데이트 할 때 동시에 데이터베이스 스키마를 업데이트 하고 있기에 하게 된 고정관념에 가까웠던 것 같다.

 

또한, 만약 flyway 를 통해 애플리케이션의 시점과 완벽히 맞물려 데이터베이스 스키마를 롤백해야 한다면 고려해야 하는 것들이 너무 많다. 예를 들어, 롤백 이전에 생긴 데이터베이스 스키마에 알맞게 데이터가 이미 존재한다면 롤백하고 난 뒤에 해당 데이터들은 어떻게 할 것인가? 이미 컬럼이 DROP 된 상태여서 새로운 버전에서는 해당 컬럼이 모두 null 인데 이전 버전에서는 해당 컬럼의 값이 반드시 필요하다면 어떻게 대응할 것인가?

 

✅ SRE 원칙을 통한 깨달음

Google 에서 내세우는 SRE 원칙에서는 가장 중시하는 것이 ‘가용성’이다. 시스템은 무조건적으로 완벽할 수 없으니, 장애를 어느 정도는 허용하되 사용자가 납득할 수 있는 수준의 가용성을 제공해야 한다는 것이다. 무조건 속도가 중요하다는 것이라기보다는, 사전에 정의된 SLO(SLO/SLI) 범위 안에서라면 정합성을 일정 부분 양보하고, 그 대신 릴리즈 속도를 유지할 수 있다는 조건부 허용에 가깝다.

 

이는 주로 개발 속도와 관련된 원칙이긴 했지만, 간접적으로 다음과 같은 생각이 들었다. 데이터베이스 자체의 완벽한 정합성과 버저닝을 모든 상황에서 보장하기보다는, 일부 장애를 허용하더라도 빠른 복구와 사용자 가용성 확보에 집중하는 것이 현실적으로 더 중요하다는 것이다.

 

그래서 어떻게 하면

1. 롤백이 아니면서도

2. 서버의 버전에 대응할 수 있는 전략이 있을까 고민하기 시작했다.

---

🚀 Expand and Contract 전략

✅ 예시로 이해해보기

Expand and Contract 전략은 간단히 설명하자면, 모든 버전에 대응할 수 있도록 스키마를 구성해두고 추후 안정적이게 됐을 때 스키마를 확정짓게 되는 것이다. 이에 대해 여러 데이터베이스를 두는 전략도 존재하지만, 나는 하나의 데이터베이스만을 토대로 설명해보겠다.

 

예를 들어, 새로운 컬럼을 추가해야 하는 상황을 가정해보자.

원래는 블로그를 서비스하는 테이블에서 게시글을 의미하는 Post 라는 테이블이 있었다고 가정해보자.

 

V1.0.0 에서는 Post 에 created_at 이 없었으나, V1.0.1 에서는 created_at 을 만들었고 이에 대한 로직 역시 구상을 했다.

CREATE TABLE post (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    title VARCHAR(255) NOT NULL,
    content TEXT,
    created_at TIMESTAMP NOT NULL
);

 

현재 V1.0.1 에 맞춰 테이블이 위와 같이 구성되어 있었으나, 오류가 발생해 V1.0.0 으로 버전을 되돌렸다. 그리고 사용자는 Post 를 하나 더 등록한다.

 

그러면 이 때 바로 오류가 나게 된다. 왜냐하면, V1.0.0 시점에서는 created_at 이 존재하지 않았기에 created_at 이 NULL 로 들어가기 때문이다.

CREATE TABLE post (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    title VARCHAR(255) NOT NULL,
    content TEXT,
    created_at TIMESTAMP NULL -- 1. NULL 허용
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP -- 2. default 값 정의
);

 

이에 대한 해결 방안은 created_at 에 NULL 을 허용하는 것이다. 이렇게 되면, 당연하게도 V1.0.0 에서도 Post 등록이 정상적으로 이뤄진다. 혹은, 기본값을 정의해 NOT NULL 임을 유지하면서도 NULL 인 경우에는 기본값이 들어가도록 대응할 수도 있다.

 

이것이 바로 EXPAND 단계에 해당한다. 하위호환성을 지켜서 데이터베이스 스키마를 정의하는 것이다.

 

created_at 이 로직 상 정말 중요한 정보라면, NULL 을 허용하고 두는 것이 안전할까? 아닐 것이다. 

 

그렇기에 우선적으로 코드 레벨 상에서 잘 막아둬야 한다. 또한, 추후 버그 픽스를 통해 탄생한 V1.0.2 이 어느 정도 안정화가 된다면 이 때 가서는 created_at 에 대해 NOT NULL 로 정의를 바꿔둬야 한다. 이가 Contract 단계에 해당한다.

✅ DDL 별 원칙

1. ADD COLUMN

ALTER TABLE post
  ADD COLUMN subtitle VARCHAR(255) NULL;

 

컬럼을 추가하게 되는 경우,

 

1. NULL 을 허용하거나

2. DEFAULT 를 정의해야 한다.

 

또한 추후 CONTRACT 단계에서는 NOT NULL 이도록 수정하면 된다.

 

2. MODIFY COLUMN

 

2-1. 크기 제한 관련 변경

ALTER TABLE post
  MODIFY COLUMN title VARCHAR(500) NOT NULL;

 

만약 위와 같이 글자 수 제한을 늘린다면, 그대로 해도 된다. 그러나 줄이는 경우에는 수동으로 하거나 버전 구동 확인을 거친 뒤 반영해야 한다.

 

2-2. 컬럼명 / 타입 변경

-- Expand: 새 컬럼 추가
ALTER TABLE member ADD COLUMN display_name VARCHAR(100) NULL;

-- 데이터 백필: 기존 nickname 값을 새 컬럼으로 복사
UPDATE member
SET display_name = nickname
WHERE display_name IS NULL;

-- Contract: 구 컬럼 제거 후 새 컬럼을 본래 이름으로 교체
ALTER TABLE member DROP COLUMN nickname;
ALTER TABLE member CHANGE COLUMN display_name nickname VARCHAR(100) NOT NULL;

 

만약 기존에는 nickname 이라고 되어있던 컬럼을 display_name 이라고 바꾸고 싶다고 가정해보자. 이런 경우에는, 기존의 컬럼은 그대로 두고 변경하고자 하는 새로운 이름을 사용해 컬럼을 추가해주면 된다.

 

또한, 기존의 nickname 이었던 값들을 모두 display_name 으로 이전해주면 된다. 추후 CONTRACT 단계에서는 기존의 컬럼을 드랍하고 컬럼명을 변경해주면 된다. 타입 변경의 경우도 비슷하게 진행해주면 된다.

 

3. DROP

 

특정 테이블이나 컬럼을 드랍해야 하는 경우에는, 현재 서버의 버전이 완전히 안정화가 되었다고 판단이 이뤄지는 경우에만 진행한다.

 

4. UNIQUE / CHECK 제약

 

최대한 애플리케이션 레벨에서 촘촘하게 검증을 하도록 구성을 하고, CONTRACT 단계에서만 제약을 추가한다.

 

5. FK 추가

ALTER TABLE post ADD COLUMN author_id BIGINT NULL;

-- 백필·정합 점검 후
ALTER TABLE post 
  ADD CONSTRAINT fk_post_author FOREIGN KEY (author_id) REFERENCES member(id);

 

처음에 애플리케이션 레벨에서 구상을 할 때에는 간접 참조를 통해 구성을 하고, 추후 해당 서버 버전이 안정화가 됐을 때 위와 같이 스키마 변경을 통해 처리한다.

---

🚀 Flyway 설정 일부 변경

내가 제시한 Expand and Contract 를 실현하기 위해서는, Flyway 설정을 일부 바꿔주어야 한다.

spring:
  flyway:
    enabled: true
    baseline-on-migrate: true
    validate-on-migrate: true
    locations: classpath:db/migration
    clean-disabled: true
    ignore-migration-patterns: *:future // 추가해줘야 함 💥

 

현재 내가 의도한 롤백 시 스키마의 변경 시나리오는 다음과 같다.

1. v1 애플리케이션 배포 -> flyway 에 v1 에 해당하는 스크립트 모두 적용됨
2. v2 애플리케이션 배포 -> flyway 에 v2 에 해당하는 스크립트 모두 적용됨
3. v1 으로 롤백 -> v2 에 해당하는 스크립트가 이미 DB 에 적용됐는데, 애플리케이션 코드 상에 없기에 오류 발생 가능 💥

 

따라서, 특정 패턴인 스키마를 무시한다는 설정인 ignore-migration-patterns 를 추가했다.

 

*:future 라는 옵션을 통해 DB 에는 이미 적용이 됐으나 애플리케이션에는 없는, 즉 미래의 스크립트가 적용되었더라도 오류가 나지 않도록 했다.

 

https://github.com/woowacourse-teams/2025-mul-kkam/pull/696

[BE][chore]: flyway 구동 시 애플리케이션에 새로운 버전이 없더라도 구동하도록 설정 변경 by Jin409 ·

---

🚀 시드 데이터가 필요한 경우, R prefix 사용하기

해당 패턴을 고려해 구현을 하던 와중에, 초기값을 넣어야 하는 경우는 어떻게 대응해야 하는지 의문이 생겼다.

 

기존에 사용하던 스크립트들은 모두 스키마의 버전을 명시하기 위해 사용했기 때문에, 데이터를 삽입해야 하는 경우에도 flyway 를 통해 정의하는 것은 적절치 않다는 생각이 들어 고민을 시작했다. 처음에는 data.sql 에 정의해야 하나 싶었는데, 여기에는 버저닝이 존재하지 않으니 애매하다는 생각이 들었다.

 

그러던 와중, flyway 에는 V 를 사용한 버전을 명시하는 prefix 이외에도 R 이라는 prefix 역시 존재하는 것을 알게 됐다. 이는 버전을 위한 prefix 가 아니라 Repeatable, 즉 반복 가능한 스크립트인 것이다.

• V prefix 가 붙은 스크립트들이 모두 실행된 뒤 실행되며
• 버전이 아니라 파일명 자체로 구분되고
• 체크섬을 통해 변경이 있는 경우에는 재실행이 되지만, 이가 아닌 경우에는 재실행이 되지 않는다.

예를 들어 image 라는 테이블에 시드 데이터를 넣어야 했다고 가정해보자.

• V1 에서는 image 라는 테이블 자체가 없었고,
• V2 로 버전업해서 image 에 데이터를 넣었다가
• V1 으로 롤백한 뒤 (데이터베이스에는 변경 없음. 즉, 이미 기본 데이터 들어가 있음)
• V2.0.1 로 재배포 해서 다시 R__add_image_seed.sql 가 포함된다고 하더라도, 이미 데이터베이스 상에 반영되어 있으며 체크섬이 달라지지 않은 이상 재반영되지 않기 때문에 문제가 발생하지 않는 것이다.

 

https://github.com/woowacourse-teams/2025-mul-kkam/pull/679#discussion_r2312891363

[BE][chore]: 롤백을 고려하여 DDL 설계 수정 by Jin409 · Pull Request #679 · woowacourse-teams/2025-mul-kkam

 

---

📝 참고 자료

http://cloudinsight.net/cloud/sre/

SRE 에 대한 이해 - 클라우드 인사이트

https://www.prisma.io/dataguide/types/relational/expand-and-contract-pattern

Using the expand and contract pattern | Prisma's Data Guide

https://www.tim-wellhausen.de/papers/ExpandAndContract/ExpandAndContract.html

Expand and Contract - A Pattern to Apply Breaking Changes to Persistent Data with Zero Downtime

https://russell-seo.tistory.com/5

Flyway(DB Migration) 도입기

https://documentation.red-gate.com/fd/flyway-repeatable-sql-migration-prefix-setting-277579026.html

Flyway Repeatable SQL Migration Prefix Setting - Redgate Flyway - Product Documentation