현재 여러 클라우드 데이터베이스 서비스가 스냅샷에서 몇 초 만에 만들 수 있는 브랜치를 제공합니다. 대개 copy-on-write 방식이라 브랜치는 변경되지 않은 페이지를 부모와 공유합니다. 개발자는 브랜치로 마이그레이션을 테스트하거나, 운영 환경과 같은 형태의 데이터로 기능을 실행해 보거나, 풀 리퀘스트마다 별도 데이터베이스를 둡니다.
브랜치는 격리 문제를 해결합니다. 두 사람이 서로 방해하지 않고 같은 스키마를 변경할 수 있고, 잘못된 마이그레이션은 브랜치와 함께 버리면 됩니다. 하지만 브랜치 안의 데이터에 무엇을 했고 왜 했는지는 브랜치에 기록되지 않습니다.
데이터베이스 브랜칭은 데이터 버전 관리와 어떻게 다른가요?
- 브랜치는 변경을 위해 만든 작업용 사본입니다. 데이터 버전 관리에서 말하는 버전은 다시 돌아가 비교할 수 있도록 이름을 붙인 상태입니다.
- 브랜칭은 데이터베이스 엔진 안에서 이루어집니다. 버전 관리는 데이터가 저장된 위치와 관계없이 데이터셋, 파일, 프로젝트 수준에서 할 수 있습니다.
- AI 업무에서는 ‘어느 사본인가’뿐 아니라 ‘어떤 준비 단계와 평가 조건이 이 결과를 만들었는가’를 물어야 합니다. 브랜치만으로는 이 질문에 답할 수 없습니다.
AI 업무에서 데이터베이스 브랜칭은 어디서 문제가 되나요?
한 팀이 웨어하우스를 브랜치로 나누고, 그 브랜치에서 학습 세트를 준비해 모델을 학습시킨 뒤 좋은 결과를 보고합니다. 한 달 뒤 브랜치는 사라졌고 메인 데이터베이스도 이미 바뀌었습니다. 어떤 행을 제외했는지, 어떤 코드를 매핑했는지, 어떤 평가 분할을 썼는지 아무도 말하지 못합니다. 결과는 남았지만 그 결과에 이른 경로는 남지 않았습니다.
해결책은 사본만이 아니라 준비 과정 자체를 기록으로 남기는 것입니다. Syntitan에서는 원본 Dataset을 그대로 두고, 각 Use Case를 사본인 Project Version 1에서 시작하며, 준비 결과를 새 Version으로 기록합니다. 이 Version에 평가 조건과 실행 결과를 연결하는 Execution Trace는 개발 중입니다. 브랜치는 작업할 공간을 주고, Version은 두 번째 실행이나 감사의 출발점이 되는 기록을 남깁니다.
Model migration: freeze the data version에서는 같은 원칙을 모델 전환에 적용한 사례를 다루고, 데이터 계보에서는 테이블 사이의 경로를 기록하는 방법을 설명합니다.