Claude Code로 MVP DB 설계, 어디까지 먼저 정해야 하나

Claude Code가 테이블과 API를 몇 분 만에 만들면서 오래된 질문이 더 날카로워졌다. MVP의 DB는 처음부터 완성해야 할까, 아니면 배포 뒤 고쳐도 될까. 답은 설계량보다 어떤 결정을 되돌릴 수 있게 만들었는지에 달려 있다.

처음부터 고정할 것은 테이블 수가 아니라 데이터의 약속이다

정규화는 과잉설계와 같은 말이 아니다. IBM은 정규화가 중복과 삽입·수정·삭제 이상을 줄여 데이터 무결성을 지킨다고 설명한다. PostgreSQL도 기본키와 `UNIQUE`, `FOREIGN KEY`를 관계 규칙을 표현하는 수단으로 권한다.

MVP라도 사용자 식별자, 소유권, 중복 허용 여부, 삭제 시 관계는 먼저 정해야 한다. “한 사용자는 게시물마다 한 번만 투표한다”면 애플리케이션 검사만 두지 않는다. `UNIQUE(user_id, post_id)`처럼 DB가 약속을 강제해야 새 코드 경로가 생겨도 규칙이 남는다.

반대로 아직 등장하지 않은 관리자 체계나 미래의 요금제를 테이블로 선점할 이유는 약하다. 클코단 논의에서도 처음부터 완벽한 구조를 만들려다 기능 검증이 늦어진다는 의견이 많았다. 정규화 원칙은 유지한다. 다만 확인되지 않은 제품 가정까지 모델링하지 않는 구분이 필요하다.

Claude Code에는 완성 스키마보다 변경 단위를 맡긴다

첫 프롬프트부터 전체 ERD를 요구하면 모델은 빈칸을 그럴듯한 가정으로 채우기 쉽다. 먼저 `claude --permission-mode plan`으로 저장소와 현재 스키마를 읽게 한다. Anthropic 문서에 따르면 Plan Mode는 계획을 승인하기 전까지 편집을 막는다.

입력에는 사용자 이야기 하나, 기존 스키마, 지켜야 할 불변식, 예상 조회만 넣는다. 산출물은 “최종 스키마”가 아니라 작은 migration 파일, 애플리케이션 변경, 검증 명령으로 제한한다. 예를 들면 `주문에 배송 메모를 추가하되 기존 행과 구버전 앱이 계속 작동해야 한다`처럼 요청한다.

그다음 Claude Code가 만든 SQL을 사람이 읽는다. 타입, 기본값, null 허용, 인덱스, RLS, 데이터 손실 구문을 확인한 뒤 로컬에서 적용한다. 써본 사람들 사이에서는 migration 파일만 생성하게 하고 운영 반영은 직접 승인한다는 반응이 반복된다.

빠른 반복은 migration과 seed가 있을 때만 안전하다

Supabase의 공식 흐름은 구체적이다. `supabase migration new`로 SQL 파일을 만들고 `supabase db reset`으로 전체 이력을 로컬에 다시 적용한다. `supabase/seed.sql`까지 두면 매번 같은 시험 데이터로 시작할 수 있다.

UI에서 바꿨다면 `supabase db diff`로 SQL을 뽑고 내용을 검토한다. 원격 변경이 먼저 생겼다면 `db pull`로 이력을 맞춘 뒤 다시 reset한다. 이렇게 만든 migration과 애플리케이션 코드를 같은 커밋에 넣어야 다른 환경에서도 변화 순서가 재현된다.

Prisma는 더 빠른 실험 경로를 따로 둔다. 공식 문서는 `prisma db push`가 migration 파일이나 변경 이력을 만들지 않으므로 로컬 프로토타입에 적합하다고 밝힌다. 데이터 보존과 환경 간 재현이 필요해지는 순간 Prisma Migrate로 넘어가야 한다.

DORA는 작은 변경이 이해와 복구에 유리하다고 설명한다. DB 스크립트도 애플리케이션 코드처럼 버전 관리하는 팀이 지속적 전달에 유리하다고 정리했다. 방에서 말한 “만들고 고친다”는 태도는 이 장치가 있을 때 공학적 반복이 된다. 기록 없이 운영 스키마를 계속 만지는 일은 iteration이 아니라 drift다.

운영 중인 컬럼은 한 번에 이름을 바꾸지 않는다

배포 전 DB라면 갈아엎는 비용이 작다. 실제 데이터와 구버전 앱이 붙은 뒤에는 같은 변경이 달라진다. Liquibase가 설명하는 Expand-Contract는 이 경계를 세 단계로 나눈다.

먼저 새 컬럼을 nullable로 추가한다. 이어 새 코드가 이전 컬럼과 새 컬럼을 함께 쓰게 하고 기존 데이터를 backfill한다. 모든 읽기 경로가 새 컬럼으로 옮겨간 사실을 확인한 뒤에만 이전 컬럼을 제거한다.

한 번의 rename보다 느리다. 대신 롤링 배포 중 신·구 코드가 함께 실행돼도 버틸 수 있다. Martin Fowler와 Pramod Sadalage의 진화적 DB 설계도 작은 migration을 강조한다. 스키마·데이터·접근 코드를 함께 바꾸고 적용을 자동화하는 방식이다. “나중에 갈아엎기”는 이 순서를 생략한다는 허가가 아니다.

AI가 빨라질수록 되돌리는 경계는 더 분명해야 한다

Claude Code의 체크포인트는 파일 편집을 되감지만 Bash 명령으로 바뀐 파일이나 외부 DB는 추적하지 않는다. Anthropic은 체크포인트가 Git을 대체하지 않는다고 명시한다. `/rewind`가 있으니 운영 migration도 되돌릴 수 있다는 기대는 위험하다.

도구 쪽은 더 가까워지고 있다. Redgate는 2026년 7월 Flyway 13.0에 MCP server를 추가했다. 이 서버로 AI agent가 개발 단계 명령을 호출한다. 실행 연결이 편해져도 migration의 의미와 데이터 보존 여부까지 자동 승인되는 것은 아니다.

개인 개발자와 작은 팀에는 거대한 설계 문서보다 짧은 안전 루프가 현실적이다. 불변식만 제약조건으로 고정하고 Claude Code에는 한 기능의 migration과 테스트만 맡긴다. 로컬 reset과 seed를 통과한 작은 변경만 배포한다. 파괴적 변경은 Expand-Contract로 늦춘다.

처음부터 완벽해야 하는 것은 스키마가 아니다. 다음 변경을 작게 만들고 실제 데이터가 생긴 뒤에도 검증할 수 있는 경로가 먼저 완성돼야 한다.