1편에서 12개 단계의 장벽 지도를 그렸다. 운영(82점), 배포(76점)에 이어 BE 개발(DB)이 74점으로 3위를 차지했다. "스키마 변경 추적의 어려움"이라고 짧게 적었는데, 이번 편은 그 한 줄을 풀어낸다.
Git이 해결한 것
2005년 리눅스 토르발스가 Git을 내놓으면서, 소프트웨어 개발에서 가장 골치 아팠던 문제 하나가 사라졌다. "어제 코드로 되돌리고 싶다"는 소원이 git revert 한 줄로 실현됐다. 20년이 지난 지금, 코드 변경은 커밋으로 기록되고 브랜치로 격리되고 PR로 검수된다. AI 에이전트가 파일을 수정해도 같은 흐름 안에 있다. 잘못 만들면 되돌리면 그만이다.
이 단순한 사실이 Agentic SDLC를 코드 영역에서는 비교적 안전하게 만든다. 1편 장벽 지도에서 FE 개발(25점)과 BE 개발 일반(38점)이 낮은 이유도 여기 있다. 롤백이 가능하니 두렵지 않다.
DB가 다른 이유
DB 스키마는 텍스트(SQL 파일)지만, DB 상태는 텍스트가 아니다. 이 차이가 전부다.
ALTER TABLE users ADD COLUMN avatar_url TEXT;이 SQL을 파일에 저장할 수 있다. 하지만 한 번 실행하고 나면, DB는 새로운 상태가 된다. Git에서 이 파일을 삭제해도 avatar_url 컬럼은 사라지지 않는다. 되돌리려면 DB 상태 레벨에서 ALTER TABLE users DROP COLUMN avatar_url을 실행해야 한다. 그리고 이미 그 컬럼에 데이터가 쌓였다면, 삭제는 데이터 손실이다.
세 가지가 얽혀 있다. 실행 순서(테이블이 먼저 있어야 컬럼을 추가할 수 있다), 이미 있는 데이터(기존 행이 새 컬럼의 기본값을 받아야 한다), 단방향성(빠른 추가와 달리 삭제는 신중해야 한다). 이 세 가지가 동시에 걸리는 영역이 AI 에이전트의 "되돌릴 수 없는 행동" 중 가장 조용하게 발생하는 유형이다.
1편의 DataTalks.Club 사례를 떠올려 보자. Claude Code가 Terraform으로 인프라 전체를 destroy했을 때 RDS DB도 함께 사라졌다. 코드는 Git에 있었지만, 2.5년치 데이터는 어디에도 없었다 (Tom's Hardware 보도).
Schema-as-Code: 20년 전에 나온 답
2003년 마틴 파울러와 프라모드 사달라게가 이 문제의 해법을 정리했다. "Evolutionary Database Design"이라는 이름으로 알려진 패턴인데, 핵심은 단순하다. DB 스키마 변경도 코드처럼 번호 붙은 파일로 관리하라 (마틴 파울러 원문).
migrations/
V001__create_users.sql
V002__add_avatar_url.sql
V003__add_index_email.sql각 파일은 UP(적용)과 DOWN(롤백) 쌍을 갖는다. 마이그레이션 도구는 어디까지 적용됐는지 내부 테이블에 기록해 두고, 다음 번에는 아직 실행 안 된 파일만 골라 순서대로 실행한다. git log가 코드 이력을 보여주는 것처럼, 마이그레이션 도구는 스키마 이력을 보여준다.
생태계별로 검증된 OSS 도구들이 있다.
| 도구 | 생태계 | 특징 |
|---|---|---|
| Flyway | SQL 기반 (언어 무관) | 20년 역사, 가장 넓은 DB 지원 |
| Liquibase | Java, XML/YAML/SQL | 엔터프라이즈 환경, 크로스 DB |
| Alembic | Python / SQLAlchemy | Python 생태계 표준 |
| golang-migrate | Go | 단순함, CLI 친화 |
| Goose | Go | go embed로 바이너리 내장 가능 |
| Prisma Migrate | Node.js / TypeScript | ORM 통합, 자동 마이그레이션 생성 |
도구 선택은 언어 생태계를 따라가면 대부분 해결된다. Python이면 Alembic, Go면 golang-migrate나 Goose, Node.js면 Prisma Migrate. 언어와 무관하게 순수 SQL만 쓰고 싶다면 Flyway가 가장 안정적이다.
Agentic SDLC에 연결하는 세 규칙
Schema-as-Code 자체는 오래된 패턴이다. 새로운 건 AI 에이전트와 연결하는 규칙이다.
규칙 1 — 마이그레이션 파일 동반 생성. AI 에이전트가 ORM 모델이나 스키마 참조 코드를 수정할 때, 반드시 대응하는 마이그레이션 파일도 함께 생성해야 한다. AGENTS.md나 CLAUDE.md에 이 규칙을 명시해 두면 에이전트가 빠뜨리지 않는다 (AGENTS.md 표준, Anthropic CLAUDE.md 문서).
규칙 2 — CI 강제. 스키마 변경 코드가 포함된 PR에 마이그레이션 파일이 없으면 빌드를 실패시킨다. 에이전트가 규칙을 잊어버리더라도 파이프라인이 잡아낸다.
규칙 3 — 마이그레이션 파일은 사람이 검수한다. AI가 생성했더라도, 이 파일만큼은 자동 승인 대상에서 제외한다. 한 번 실행된 마이그레이션은 되돌리기 어렵다. 그러니 실행 전에 잡아야 한다.
Expand-Contract: 운영 중 스키마를 바꾸는 패턴
운영 DB에서 컬럼 삭제나 타입 변경을 해야 할 때는 "한 번에 바꾸면 안 된다"는 원칙이 있다. Expand-Contract 패턴이다.
- Expand(확장): 새 컬럼을 추가하고, 애플리케이션이 구/신 컬럼을 모두 쓰도록 코드를 배포한다.
- Contract(수축): 구 컬럼을 참조하는 코드가 모두 사라진 뒤, 구 컬럼을 삭제한다.
두 단계로 나뉘기 때문에, 배포 중 롤백이 필요한 순간에도 구 컬럼이 살아 있다. 다운타임 없이 스키마를 바꿀 수 있는 이유다.
AI 에이전트는 "단번에" 처리하려는 경향이 있다. 컬럼을 바꾸라는 요청을 받으면 ALTER TABLE 하나로 끝내려 한다. AGENTS.md에 "컬럼 삭제나 타입 변경 시 Expand-Contract 패턴을 따른다"는 규칙을 넣어 두면, 에이전트가 두 단계 PR을 나눠서 만든다.
그래도 남는 것들
Schema-as-Code와 세 가지 규칙이 BE-DB 장벽을 완전히 없애지는 않는다. 멀티 테넌트 환경에서 수천 개 스키마를 동시에 마이그레이션하거나, 샤딩된 DB의 일관성을 보장하거나, 대용량 테이블에서 인덱스를 추가할 때 나타나는 잠금 문제는 별도의 설계가 필요하다 (Prisma 데이터베이스 마이그레이션 가이드).
하지만 이 경우들은 "AI 에이전트가 처음부터 잘못 만든" 문제가 아니다. 숙련된 백엔드 엔지니어도 주의를 기울이는 영역이다. Agentic SDLC에서 AI에게 이 영역을 위임할 때는, 사람이 먼저 패턴을 정해 두고 에이전트는 그 패턴을 따르게 하는 방식이 현실적이다.
3편에서는 이 모든 것을 묶어서 실제로 어떻게 4주 안에 시작하는지를 다룬다.