묶음 상품 시리즈 초기 데이터를 버전 관리하기 시작하다

요즘 들어 자주 마주치는 패턴이 있는데, 개발 초기 단계에서 데이터베이스 seed 파일이 git 추적 대상이 아니다가 나중에 "어? 이 데이터는 어디서 나온 거지?" 하는 상황이다. 이번 커밋은 묶음 상품 확장 기능(expansion)과 관련된 초기화 데이터를 드디어 버전 관리에 넣은 작업인데, 생각보다 이런 결정이 팀 전체에 미치는 영향이 꽤 크다.

왜 seed 데이터를 추적해야 했나

초기 데이터는 보통 처리가 애매한데, 로컬 개발 환경에서 수동으로 만들거나 스크립트로 한 번 생성한 후 파일로 저장하고 .gitignore에 넣어두는 경우가 많다. 하지만 이 방식은 몇 가지 문제를 낳는다.

먼저 신입 개발자나 새로운 팀원이 온보딩할 때다. 로컬 dev 환경을 구성하려면 이 seed 데이터가 필요한데, 어디서 나온 것인지, 어떤 값들을 입력해야 하는지 문서에만 의존하게 된다. "db/seed 를 손으로 넣으세요" 같은 말은 실질적으로 도움이 못 된다. CI/CD 환경에서도 마찬가지다. 테스트 DB를 초기화할 때 이 데이터가 없으면 의도한 테스트 시나리오를 돌릴 수 없다.

둘째, 데이터의 일관성이 보장되지 않는다. 누군가는 로컬에서 수정했지만 파일로 반영하지 않았다든지, 다른 사람의 버전과 다르다든지 하는 일이 생긴다. 특히 초기 데이터에 검증 로직이 포함되어 있거나 특정 비즈니스 규칙을 따라야 할 때 이 불일치는 헷갈리는 버그의 원인이 된다.

12개의 검증된 series와 그 의미

이번 커밋에서 "12 verified series"라고 표현한 것은 단순히 개수 문제가 아니다. 이건 누군가가 이 12개의 묶음 상품 카테고리를 직접 확인하고, 각각 정상 동작하는지 테스트했다는 뜻이다.

• 검증 프로세스: 시리즈별로 필요한 필드(예: 상품명, 활성화 상태, 정렬 순서 등)가 완전한가?
• 데이터 무결성: seed에 들어갈 값들이 비즈니스 요구사항을 정확히 반영하고 있는가?
• 재현성: 같은 seed를 어디서든 실행하면 같은 결과가 나오는가?

이 12개의 series는 향후 팀에서 "신뢰할 수 있는 기본 테스트 데이터"가 된다. 새 기능을 만들 때 이 seed를 깔고 시작하면, 최소한 기본 시나리오는 일관되게 테스트할 수 있다.

구체적 변화

팀 차원의 impact

이런 작은 결정이 실제로는 여러 흐름을 바꾼다.

• 배포 자동화: staging/production 환경에서도 이 seed를 기반으로 초기 상태를 맞출 수 있다. 특히 새로운 카테고리가 추가되거나 확장될 때, 일관된 마이그레이션 경로를 갖춘다.
• 코드 리뷰: 이 기능 관련 PR을 검토할 때 "예상되는 데이터 상태"가 명확해진다. 리뷰어도 같은 12개 series를 염두에 두고 검토할 수 있다.
• 온보딩: 다음에 신입이 오면, "clone 받고 이 seed 실행하면 된다"라고 명확히 말할 수 있다.

다음은 문서화

파일 자체가 SQL이므로 어느 정도 자명하지만, 왜 이 12개를 선택했는지, 각 series의 목적이 뭔지는 별도 주석이나 README 에 남기는 게 좋다. "왜 이 데이터가 여기 있는가"를 모르면, 나중에 누군가는 이 값들을 "오래된 테스트용 쓰레기"로 착각할 수 있다.

untracked 파일을 버전 관리에 넣을 때는 단순히 "이 파일이 중요하니까"라는 것만으로는 부족하다. 팀 전체가 이 데이터를 어떻게 유지하고, 언제 수정하고, 새로운 series가 추가되면 어떻게 처리할지 합의하는 것이 중요하다. 특히 seed 데이터는 코드처럼 빠르게 변하지는 않지만, 한 번 고정되면 여러 시스템이 그것에 의존하게 되니까.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.