재생성에 안전한 스키마 진화로 예측 가능한 마이그레이션 만들기

재생성된 백엔드에서 스키마 변경이 위험하게 느껴지는 이유

시각적 모델에서 백엔드를 재생성할 때 데이터베이스 변경은 스웨터의 실을 당기는 것처럼 느껴집니다. Data Designer에서 필드를 수정하고 재생성을 누르면 단순히 테이블만 바꾸는 것이 아닙니다. 생성된 API, 검증 규칙, 앱이 데이터를 읽고 쓰는 쿼리까지 바뀝니다.

대부분의 문제는 새 코드가 빌드되지 않아서 발생하는 것이 아닙니다. 많은 노코드 플랫폼(예: AppMaster, 실제 Go 코드를 생성하는 플랫폼)은 매번 깔끔한 프로젝트를 생성할 수 있습니다. 실제 위험은 운영 데이터가 이미 존재하며, 그것이 자동으로 당신의 새 아이디어에 맞게 변형되지 않는다는 점입니다.

사람들이 처음으로 알아차리는 두 가지 실패는 단순합니다:

• 읽기 실패: 컬럼이 이동했거나 타입이 바뀌었거나 쿼리가 존재하지 않는 값을 기대해서 앱이 레코드를 불러오지 못합니다.
• 쓰기 실패: 제약조건, 필수 필드, 형식이 바뀌어 새 레코드나 업데이트가 실패합니다. 기존 클라이언트는 여전히 옛 형태로 보냅니다.

두 경우 모두 실제 사용자가 마주칠 때까지 숨겨질 수 있어 고통스럽습니다. 스테이징 DB는 비어 있거나 새로 채워져 있을 수 있으므로 모든 것이 정상처럼 보입니다. 운영 환경에는 널(null)이 있거나 오래된 enum 문자열, 새 규칙이 생기기 전에 생성된 행 같은 엣지 케이스가 있습니다.

이것이 재생성 안전한 스키마 진화가 중요한 이유입니다. 목표는 백엔드 코드가 완전히 재생성되더라도 각 변경이 안전하도록 해서 기존 레코드가 유효하고 새 레코드도 계속 생성될 수 있게 하는 것입니다.

“예측 가능한 마이그레이션”은 배포 전에 네 가지 질문에 답할 수 있다는 의미입니다: 데이터베이스에서 무엇이 바뀌는가, 기존 행에 무슨 일이 발생할 것인가, 롤아웃 중 어떤 버전의 앱이 동작할 수 있는가, 예상치 못한 문제가 생기면 어떻게 롤백할 것인가.

간단한 모델: 스키마, 마이그레이션, 재생성된 코드

플랫폼이 백엔드를 재생성할 수 있을 때, 머릿속에서 세 가지를 분리해 생각하면 도움이 됩니다: 데이터베이스 스키마, 이를 변경하는 마이그레이션 단계, 그리고 운영에 이미 존재하는 실데이터(런타임 데이터). 이들을 혼동하면 변경이 예측 불가능하게 느껴집니다.

재생성을 “최신 모델로부터 애플리케이션 코드를 재구성하는 것”으로 생각하세요. AppMaster 같은 도구에서는 이 재생성이 작업 중 여러 번 일어납니다: 필드를 조정하고, 비즈니스 로직을 수정하고, 엔드포인트를 추가하고, 재생성하고, 테스트하고, 반복합니다. 재생성은 잦습니다. 운영 데이터베이스는 그렇지 않아야 합니다.

간단한 모델은 다음과 같습니다.

• 스키마: 데이터베이스 테이블, 컬럼, 인덱스, 제약조건의 구조입니다. 데이터베이스가 기대하는 형태입니다.
• 마이그레이션: 스키마를 한 버전에서 다음 버전으로 옮기는 순서화된 반복 가능한 단계(때로는 데이터 이동도 포함). 각 환경에서 실행하는 것입니다.
• 런타임 데이터: 사용자와 프로세스가 생성한 실제 레코드입니다. 변경 전, 중, 후 모두 유효해야 합니다.

재생성된 코드는 “현재 스키마와 통신하는 현재 앱”으로 취급해야 합니다. 마이그레이션은 스키마와 런타임 데이터를 코드 변경에 맞춰 정렬해 주는 다리입니다.

재생성이 판을 바꾸는 이유

재생성을 자주 하면 자연스럽게 많은 작은 스키마 수정을 하게 됩니다. 그 자체로는 정상입니다. 위험은 이러한 수정이 하위 호환성을 깨뜨리거나 마이그레이션이 결정론적이지 않을 때 나타납니다.

이를 관리하는 실용적 방법은 재생성에 안전한 스키마 진화를 작고 되돌릴 수 있는 단계들의 연속으로 계획하는 것입니다. 한 번에 큰 전환을 하기보다 오래된 코드와 새로운 코드 경로가 짧은 기간 동안 함께 동작하도록 제어된 이동을 수행하세요.

예를 들어 라이브 API에서 사용하는 컬럼 이름을 바꾸려면 즉시 이름을 바꾸지 마세요. 먼저 새 컬럼을 추가하고, 둘 다 쓰도록 하며, 기존 행을 백필한 뒤 읽기를 새 컬럼으로 전환하세요. 그 다음에야 오래된 컬럼을 제거합니다. 각 단계는 테스트하기 쉽고 문제가 생기면 데이터 손상 없이 일시 중지할 수 있습니다.

이런 사고 방식은 재생성이 매일 일어나더라도 마이그레이션을 예측 가능하게 합니다.

스키마 변경 종류와 어떤 것이 운영을 깨뜨리는가

백엔드가 최신 스키마에서 재생성되면 코드는 보통 데이터베이스가 지금 그 스키마와 일치한다고 가정합니다. 그래서 재생성 안전한 스키마 진화는 “데이터베이스를 변경할 수 있는가?”보다 “변경을 롤아웃하는 동안 오래된 데이터와 오래된 요청이 견딜 수 있는가?”에 더 가깝습니다.

어떤 변경은 기존 행이나 쿼리를 무효화하지 않아 본질적으로 안전합니다. 다른 변경은 데이터의 의미를 바꾸거나 실행 중인 앱이 여전히 기대하는 것을 제거해 운영 사고로 이어집니다.

낮은 위험, 보통 안전(추가적 변경)

추가적 변경은 기존 데이터와 공존할 수 있어 가장 쉽게 배포할 수 있습니다.

• 아직 아무것도 의존하지 않는 새 테이블.
• 기본값이 필요 없는 새 nullable 컬럼.
• 끝에서 끝으로 선택적인 새 API 필드.

예: users 테이블에 nullable인 middle_name 컬럼을 추가하는 것은 보통 안전합니다. 기존 행은 유효하고, 재생성된 코드는 값이 있을 때 읽을 수 있으며, 오래된 행은 단순히 NULL을 가집니다.

중간 위험(의미 변경)

이 변경은 기술적으로는 “작동”하지만 동작이 깨질 수 있습니다. 재생성은 검증, 생성된 모델, 비즈니스 로직 가정을 업데이트하므로 주의 깊은 조정이 필요합니다.

이름 변경은 전형적인 함정입니다: phone을 mobile_phone으로 바꾸면 재생성된 코드는 더 이상 phone을 읽지 않을 수 있는데 운영에는 데이터가 그대로 남아 있을 수 있습니다. 단위(예: 가격을 달러에서 센트로 저장) 변경은 코드보다 데이터가 먼저 바뀌거나 그 반대일 때 계산을 조용히 망칠 수 있습니다.

Enum도 예리한 부분입니다. Enum을 좁히면(값 제거) 기존 행이 무효화될 수 있습니다. 확장하는 것은(값 추가) 보통 안전하지만 모든 코드 경로가 새 값을 처리할 수 있어야 합니다.

실용적 접근은 의미 변경을 “새로 추가 → 백필 → 전환 → 나중에 제거”로 처리하는 것입니다.

높은 위험(파괴적 변경)

파괴적 변경은 플랫폼이 코드를 재생성해 옛 형태를 더 이상 기대하지 않을 때 운영을 즉시 깨뜨리는 경우가 많습니다.

컬럼 삭제, 테이블 삭제, nullable을 not-null로 바꾸는 것은 어떤 요청이 그 값을 넣지 않자마자 쓰기 실패를 유발할 수 있습니다. “모든 행에 이미 있다”고 생각하더라도 다음 엣지 케이스나 백그라운드 잡이 반증할 수 있습니다.

not-null 변경을 해야 한다면 단계별로 하세요: 먼저 컬럼을 nullable로 추가하고 백필한 뒤 앱 로직을 갱신해 항상 값을 설정하게 하고, 그 다음에 not-null을 강제합니다.

성능과 안전 변경(쓰기 차단 가능)

인덱스와 제약은 “데이터 모양” 변경은 아니지만 다운타임을 초래할 수 있습니다. 큰 테이블에서 인덱스를 생성하거나 고유 제약을 추가하면 쓰기를 잠글 수 있어 타임아웃이 발생할 수 있습니다. PostgreSQL에서는 온라인 친화적 방법으로 더 안전하게 수행되는 작업이 있지만 핵심은 타이밍입니다: 트래픽이 적은 시간에 수행하고 스테이징 복사본에서 소요 시간을 측정하세요.

생각보다 주의가 필요한 변경이 있으면 다음을 계획하세요:

• 호환성을 유지하는 두 단계 롤아웃(먼저 스키마, 그다음 코드 또는 그 반대).
• 배치로 실행하는 백필.
• 명확한 롤백 경로(재생성된 백엔드가 일찍 라이브될 경우 어떻게 할지).
• 데이터가 새 규칙과 일치함을 증명하는 검증 쿼리.
• “오래된 필드 나중에 제거” 티켓을 만들어 정리 작업이 같은 배포에서 발생하지 않게 할 것.

AppMaster 같은 플랫폼을 사용한다면 가장 안전한 사고방식은: 오래된 데이터가 오늘도 버틸 수 있는 변경을 먼저 배포하고, 시스템이 이미 적응한 후에 규칙을 강화하는 것입니다.

재생성 안전 변경을 위한 원칙

재생성된 백엔드는 스키마 변경이 운영의 오래된 행과 맞지 않을 때 문제가 됩니다. 재생성 안전한 스키마 진화의 목표는 간단합니다: 데이터베이스와 재생성된 코드가 서로를 따라잡는 동안 앱이 계속 작동하도록 작고 예측 가능한 단계로 변경을 유지하는 것입니다.

기본은 “확장 → 마이그레이션 → 수축”

의미 있는 변경을 항상 세 단계로 처리하세요. 먼저 스키마를 확장해 오래된 코드와 새 코드가 동시에 동작하도록 합니다. 다음에 데이터를 마이그레이션합니다. 마지막으로 오래된 컬럼, 기본값, 제약을 제거합니다.

실용 규칙: “새 구조”와 “파괴적 정리”를 동일한 배포에 결합하지 마세요.

일정 기간 동안 오래된 형태와 새 형태를 모두 지원하세요

다음과 같은 기간이 있을 것이라고 가정하세요:

• 일부 레코드는 새 필드를 가지고 있고 일부는 그렇지 않다.
• 일부 앱 인스턴스는 오래된 코드를 실행하고 일부는 재생성된 코드를 실행한다.
• 백그라운드 잡, 임포트, 모바일 클라이언트는 지연될 수 있다.

이 기간 동안 두 형태가 모두 유효하도록 데이터베이스를 설계하세요. 이는 Data Designer에서 모델을 업데이트하고 Go 백엔드를 재생성하는 플랫폼에서는 더 중요합니다.

쓰기보다 먼저 읽기 호환성을 확보하세요

먼저 새 코드가 오래된 데이터를 안전하게 읽을 수 있게 만드세요. 그다음에 쓰기 경로를 전환해 새 데이터 모양을 생성하게 하세요.

예: 하나의 status 필드를 status + status_reason으로 분리할 경우, 먼저 status_reason이 없을 때도 처리할 수 있는 코드를 배포하세요. 그 이후에 status_reason을 쓰기 시작합니다.

부분적이거나 알 수 없는 데이터에 대해 결정하세요

enum, non-null 컬럼, 더 엄격한 제약을 추가할 때 값이 누락되거나 예상 밖일 때 어떻게 처리할지 미리 결정하세요:

• 임시로 null을 허용한 뒤 백필하기
• 의미를 바꾸지 않는 안전한 기본값 설정
• 읽기 오류를 피하기 위해 “unknown” 값 유지

이렇게 하면 조용한 데이터 손상(잘못된 기본값)과 심각한 실패(새 제약이 오래된 행을 거부함)를 방지할 수 있습니다.

각 단계마다 롤백 스토리를 가지세요

확장 단계에서는 롤백이 가장 쉽습니다. 되돌려야 할 경우 오래된 코드는 확장된 스키마에서도 작동해야 합니다. 어떤 것을 롤백할지(코드만인지, 코드와 마이그레이션 모두인지)를 적어두고 파괴적 변경은 확신이 서기 전까지 피하세요.

단계별: 재생성을 견디는 변경 계획

재생성된 백엔드는 관대하지 않습니다: 스키마와 생성된 코드가 불일치하면 운영이 먼저 이를 찾아냅니다. 가장 안전한 접근은 모든 변경을 작고 되돌릴 수 있는 롤아웃으로 간주하는 것입니다. 노코드 도구로 빌드하더라도 마찬가지입니다.

먼저 의도를 평범한 언어로 적고 현재 데이터가 어떤지 적어보세요. 프로덕션에서 실제 3~5개의 행을 골라 비어 있는 값, 오래된 형식, 놀라운 기본값 같은 지저분한 부분을 기록하세요. 이렇게 하면 실제 데이터가 만족하지 못할 완벽한 새 필드를 설계하는 실수를 피할 수 있습니다.

다음은 AppMaster가 Data Designer 모델에서 Go 백엔드를 재생성할 때처럼 재생성 플랫폼에서 잘 작동하는 실용적 순서입니다:

1. 먼저 확장하고 대체하지 마세요. 새 컬럼이나 테이블을 추가할 때는 추가 방식으로 하세요. 새 필드는 처음에 nullable로 두거나 안전한 기본값을 주세요. 새 관계를 도입할 때는 채워질 때까지 외래키를 비워둘 수 있게 하세요.

2. 아무것도 제거하지 않고 확장된 스키마를 배포하세요. 오래된 코드가 계속 작동하는 동안 데이터베이스 변경을 배포하세요. 목표는 오래된 코드가 옛 컬럼에 계속 쓰더라도 DB가 이를 수락하는 것입니다.

3. 제어된 잡으로 백필하세요. 새 필드를 배치 프로세스로 채우되 모니터링하고 재실행할 수 있게 하세요. 멱등(idempotent)으로 만드세요(두 번 실행해도 데이터가 망가지지 않음). 테이블이 크면 점진적으로 진행하고 업데이트된 행 수를 기록하세요.

4. 먼저 읽기를 전환하고 폴백을 두세요. 재생성된 로직이 새 필드를 우선 읽되 새 데이터가 없으면 오래된 필드로 폴백하도록 하세요. 읽기가 안정된 후에야 쓰기를 새 필드로 전환하세요.

5. 마지막에 정리하세요. 확신(및 롤백 계획)이 서면 오래된 필드를 제거하고 제약을 강화하세요: NOT NULL 설정, 고유 제약 추가, 외래키 강제 등.

구체적 예: 자유 텍스트 status 컬럼을 statuses 테이블을 가리키는 status_id로 교체하려면, status_id를 nullable로 추가하고 기존 텍스트에서 백필한 뒤 앱을 업데이트해 status_id를 우선 읽고 null일 때 status로 폴백하게 하세요. 그 다음 status를 삭제하고 status_id를 필수로 만드세요. 이 과정은 각 단계에서 DB가 호환되므로 재생성 안전합니다.

재사용 가능한 실무 패턴

백엔드가 재생성될 때 작은 스키마 수정이 API, 검증 규칙, UI 폼까지 파급됩니다. 재생성 안전한 스키마 진화의 목표는 새 코드가 빠르게 롤아웃되더라도 오래된 데이터가 유효하도록 변경하는 것입니다.

패턴 1: 비파괴적 이름 변경

직접 이름을 바꾸는 것은 위험합니다. 안전한 접근은 이름 변경을 짧은 마이그레이션 기간으로 처리하는 것입니다.

• 새 컬럼(예: customer_phone)을 추가하고 기존 컬럼(phone)을 유지하세요.
• 저장 시 두 필드에 모두 쓰는 이중 쓰기(dual-write)를 구현하세요.
• 기존 행을 백필해 customer_phone을 채우세요.
• 커버리지가 충분해지면 읽기를 새 컬럼으로 전환하세요.
• 나중 릴리스에서 오래된 컬럼을 삭제하세요.

이 방식은 Data Designer에서 스키마를 업데이트해 Go 백엔드를 재생성하는 환경에서 잘 작동합니다. 이중 쓰기는 두 세대의 코드를 동시에 만족시킵니다.

패턴 2: 하나의 필드를 둘로 분리

full_name을 first_name과 last_name으로 분리하는 것은 유사하지만 백필이 더 까다롭습니다. 원본 필드를 완전히 제거하기 전까지는 full_name을 유지하세요.

실용 규칙: 파싱에 실패하면 전체 문자열을 last_name에 저장하고 검토용 플래그를 세우는 등 명확한 폴백을 두세요.

패턴 3: 필드를 필수로 만들기

nullable을 required로 바꾸는 것은 전형적인 운영 문제를 일으킵니다. 안전한 순서는 백필 먼저, 강제는 나중입니다.

백필은 기계적으로(기본값 설정) 하거나 비즈니스적으로(사용자에게 자료 입력 요청) 할 수 있습니다. 데이터가 완전해진 후에만 NOT NULL과 검증을 추가하세요. 재생성된 백엔드가 자동으로 더 엄격한 검증을 추가할 수 있으니 이 순서가 놀라운 실패를 예방합니다.

패턴 4: enum을 안전하게 변경하기

enum 변경은 오래된 코드가 오래된 값을 보낼 때 깨집니다. 전환 기간에는 둘 다 허용하세요. "pending"을 "queued"로 바꿀 때는 둘 다 유효하게 두고 로직에서 매핑하세요. 모든 클라이언트가 오래된 값을 보내지 않는 것을 확인한 뒤 제거합니다.

한 번의 릴리스에 변경을 밀어붙여야 한다면 영향을 줄일 방법:

• 새 필드를 추가하되 오래된 필드를 남겨두세요.
• 삽입이 계속 작동하도록 DB 기본값 사용.
• 코드를 관대하게 만들어 새 필드를 우선 읽고 오래된 필드로 폴백하도록 함.
• 일시적인 매핑 레이어 추가(옛 값 입력 → 새 값 저장).

이 패턴들은 재생성으로 코드 동작이 빠르게 바뀌어도 마이그레이션을 예측 가능하게 유지합니다.

놀라움을 초래하는 흔한 실수

가장 큰 놀라움은 사람들이 코드 재생성을 마법의 리셋 버튼처럼 다루는 것입니다. 재생성된 백엔드는 애플리케이션 코드를 깔끔하게 유지하지만 운영 데이터베이스는 여전히 어제의 데이터를 가지고 있습니다. 재생성 안전한 스키마 진화는 새로 생성될 코드와 테이블에 여전히 남아 있는 오래된 레코드 둘 다를 계획하는 것입니다.

흔한 함정 중 하나는 플랫폼이 “마이그레이션을 알아서 해줄 것”이라고 가정하는 것입니다. 예를 들어 AppMaster에서는 Data Designer 모델을 업데이트해 Go 백엔드를 재생성할 수 있지만, 플랫폼이 실제 고객 데이터를 어떻게 변환해야 할지 추측하지는 않습니다. 새로 필요한 필드를 추가하면 기존 행에 값을 채우는 명확한 계획이 필요합니다.

다른 놀라움은 필드를 너무 일찍 삭제하거나 이름을 바꾸는 것입니다. 메인 UI에서 사용되지 않는 것처럼 보여도 보고서, 예약된 내보내기, 웹훅 핸들러, 혹은 드물게 열어 보는 관리자 화면에서 여전히 읽히고 있을 수 있습니다. 테스트에서는 안전해 보여도 운영에서 한 번이라도 참조되는 경로가 남아 있으면 실패합니다.

늦은 밤 롤백을 초래하는 다섯 가지 실수:

• 스키마를 변경하고 코드를 재생성했지만 오래된 행을 유효하게 만드는 데이터 마이그레이션을 작성하거나 검증하지 않음.
• 모든 리더와 라이터가 업데이트·배포되기 전에 컬럼을 이름 변경하거나 삭제함.
• 큰 테이블을 백필하면서 소요 시간을 확인하지 않아 다른 쓰기를 막음.
• 새 제약(NOT NULL, UNIQUE, foreign key)을 먼저 추가하고 나중에 레거시 데이터가 이를 깨뜨림을 발견함.
• 백그라운드 잡, 내보내기, 보고서가 여전히 오래된 필드를 읽고 있다는 것을 잊음.

간단한 시나리오: phone을 mobile_number로 바꾸고 NOT NULL을 추가한 뒤 재생성하면 앱 화면은 작동하지만 오래된 CSV 내보내기가 여전히 phone을 선택하고 수천 개의 existing 레코드에 mobile_number가 NULL일 수 있습니다. 보통의 해결책은 단계적 변경: 새 컬럼 추가 → 둘 다 쓰기 → 안전하게 백필 → 제약 강화 및 오래된 필드 제거.

더 안전한 마이그레이션을 위한 사전 배포 체크리스트

백엔드가 재생성되면 코드는 빠르게 바뀔 수 있지만 운영 데이터는 놀라움을 용납하지 않습니다. 스키마 변경을 배포하기 전에 짧은 “이것이 안전하게 실패할 수 있는가?” 점검을 하세요. 재생성 안전한 스키마 진화를 지루하게 만드는 것이 목표입니다(그게 바로 안전한 상태입니다).

대부분의 문제를 잡아내는 5가지 점검

• 백필 규모와 속도: 얼마나 많은 기존 행을 업데이트해야 하는지(또는 다시 써야 하는지) 추정하고 운영에서 소요 시간을 계산하세요. 작은 DB에서 괜찮던 백필이 실제 데이터에서는 몇 시간 걸릴 수 있습니다.
• 락과 다운타임 위험: 변경이 쓰기를 막을 수 있는지 확인하세요. 큰 테이블 변경이나 타입 변경은 쓰기 잠금을 오래 유지할 수 있습니다. 차단 가능성이 있으면 안전한 롤아웃을 계획하세요(먼저 새 컬럼 추가 → 나중에 백필 → 마지막에 코드 전환).
• 옛 코드 vs 새 스키마 호환성: 배포나 롤백 중에 옛 백엔드가 새 스키마에 대해 잠깐 실행될 수 있다고 가정하세요. 이전 버전이 크래시 없이 읽고 쓸 수 있는가? 아니라면 두 단계 릴리스가 필요합니다.
• 기본값과 null 동작: 새 컬럼에 대해 기존 레코드는 NULL이 될지 기본값이 필요한지 결정하세요. 특히 플래그, 상태 필드, 타임스탬프는 누락값을 정상으로 처리하도록 로직을 확인하세요.
• 모니터링 신호: 배포 후 주시할 정확한 알람을 고르세요: 오류율(API 실패), DB 느린 쿼리, 큐/잡 실패, 주요 사용자 액션(결제, 로그인, 폼 제출) 등. 검증 오류 급증 같은 “조용한” 버그도 감시하세요.

간단한 예

orders 테이블에 새 필수 필드 status를 추가한다면 한 번에 “NOT NULL, 기본값 없음”으로 밀어붙이지 마세요. 먼저 nullable로 추가하고 새 행에 대한 기본값을 주고, 재생성된 코드가 결손된 상태를 처리하도록 한 뒤 백필하고 마지막으로 제약을 강화하세요.

AppMaster에서는 이 사고방식이 특히 유용합니다. 백엔드를 자주 재생성할 수 있기 때문에 각 스키마 변경을 쉬운 롤백이 가능한 작은 릴리스로 다루면 마이그레이션은 예측 가능해집니다.

예시: 운영 앱을 기존 레코드를 깨뜨리지 않고 진화시키기

예를 들어 상담팀에서 티켓에 우선순위를 자유 텍스트 필드 priority로 태깅한다고 합시다(예: “high”, “urgent”, “HIGH”, “p1”). 이를 엄격한 enum으로 바꿔 보고서와 라우팅 규칙이 추측하지 않게 만들고 싶습니다.

안전한 방법은 운영 레코드를 유효하게 유지하면서 백엔드를 재생성하는 두 번의 릴리스입니다.

릴리스 1: 확장, 둘 다 쓰기, 백필

먼저 아무것도 제거하지 않고 스키마를 확장하세요. priority_enum 같은 새 enum 필드를 추가하고, 기존 priority_text 필드는 유지합니다.

그다음 새로 생성되거나 수정되는 티켓이 두 필드 모두에 쓰이도록 로직을 업데이트하세요. AppMaster 같은 노코드 도구에서는 Data Designer 모델과 Business Process를 조정해 입력을 enum에 매핑하고 원본 텍스트도 저장하면 됩니다.

그다음 소규모 배치로 기존 티켓을 백필하세요. 흔한 텍스트 값을 enum에 매핑합니다(예: "p1"와 "urgent" → urgent, "HIGH" → high). 알 수 없는 값은 일시적으로 medium에 매핑하고 검토합니다.

사용자가 보는 화면은 이상적으로는 변하지 않습니다. UI는 동일한 우선순위 컨트롤을 유지하되 백그라운드에서 새 enum을 채웁니다. 백필이 진행되면 리포트는 즉시 enum을 사용할 수 있습니다.

릴리스 2: 수축 및 오래된 경로 제거

확신이 들면 읽기를 priority_enum만 사용하도록 전환하고 필터와 대시보드를 업데이트한 뒤 나중 마이그레이션에서 priority_text를 제거하세요.

릴리스 2 이전에 소규모 샘플로 검증하세요:

• 서로 다른 팀과 생성 시기를 아우르는 티켓 20~50개를 고르세요.
• 표시된 우선순위와 저장된 enum 값을 비교하세요.
• enum 값별 집계를 확인해 medium이 과도하게 많은지 같은 이상치를 찾아보세요.

문제가 발생하면 릴백은 간단합니다. 릴리스 1이 오래된 필드를 남겼으므로 릴리스 1 로직을 재배포하고 UI를 다시 priority_text로 읽게 한 뒤 매핑을 고치고 백필을 다시 실행하면 됩니다.

다음 단계: 스키마 진화를 반복 가능한 습관으로 만들기

예측 가능한 마이그레이션을 원한다면 스키마 변경을 작은 프로젝트로 다루세요. 목표는 간단합니다: 모든 변경은 설명하기 쉽고 리허설하기 쉬우며 우발적으로 깨뜨리기 어려워야 합니다.

시각적 데이터 모델은 배포 전에 영향을 가시화하므로 유용합니다. 테이블, 관계, 필드 타입을 한 곳에서 보면 스크립트에서는 놓치기 쉬운 것들(예: 안전한 기본값이 없는 필수 필드, 오래된 레코드를 고아로 만드는 관계 등)을 발견할 수 있습니다. “누가 이것에 의존하나?” 점검을 하세요: API, 화면, 리포트, 백그라운드 잡.

이미 사용 중인 필드를 변경해야 할 때는 짧은 전환 기간과 중복 필드를 선호하세요. 예: phone_raw를 유지하면서 phone_e164를 추가하고 1~2개 릴리스 동안 유지하세요. 전환 기간 동안 비즈니스 로직은 새 필드가 있으면 우선 읽고 없으면 오래된 필드로 폴백하게 하고, 쓰기는 둘 다 하세요. 완전한 백필을 확인한 후 오래된 필드를 제거하세요.

환경 규율은 좋은 의도를 안전한 릴리스로 바꾸는 요소입니다. dev, staging, production을 정렬하되 동일하다고 여기지 마세요.

• Dev: 재생성 후 백엔드가 깨끗하게 시작되고 기본 흐름이 작동하는지 확인하세요.
• Staging: 프로덕션과 유사한 데이터로 전체 마이그레이션 계획을 실행하고 주요 쿼리, 리포트, 임포트를 검증하세요.
• Production: 롤백 계획, 명확한 모니터링, 통과해야 할 소수의 체크를 갖춘 상태에서 배포하세요.

마이그레이션 계획을 짧더라도 문서화하세요. 무엇이 변경되는지, 순서, 백필 방법, 검증 방법, 롤백 방법을 포함하세요. 그런 다음 실제 프로덕션에 닿기 전에 테스트 환경에서 엔드 투 엔드로 실행하세요.

AppMaster를 사용한다면 Data Designer를 활용해 모델을 시각적으로 검토하고 재생성이 업데이트된 스키마와 백엔드 코드를 일관되게 유지하게 하세요. 예측 가능하게 유지하는 습관은 마이그레이션을 명시적으로 만드는 것입니다: 빠르게 반복할 수 있지만 각 변경은 기존 운영 데이터를 위한 계획된 경로를 가지게 됩니다.