블로그 발행 파이프라인 저장소 분리

블로그 발행 기능을 기존 메인 저장소에서 분리하여 별도의 사이드 저장소로 옮기는 작업을 마무리했다. 동시에 개발 환경의 초기화 스크립트도 함께 수정해서 새 저장소 구조를 반영하도록 했다.

왜 저장소를 분리하는가

시스템이 커질수록 한 곳에 모든 기능을 둬서는 관리가 어려워진다. 특히 블로그 발행 같은 도메인은:

• 팀 소유권 분명화: 특정 팀이 책임지고 관리할 수 있게 경계를 명확히 하는 게 중요하다.
• 배포 독립성: 핵심 서비스와 무관하게 독립적으로 배포하고 롤백할 수 있어야 한다.
• 마이그레이션 용이성: 기존 로직은 유지하면서 점진적으로 새 저장소로 옮길 수 있다.

내가 경험한 비슷한 상황들을 보면, 이렇게 "side" 또는 "satellite" 저장소를 별도로 두는 패턴은:
- 신입이 온보딩할 때도 복잡도가 낮아진다.
- 긴급 핫픽스가 필요할 때 영향 범위를 최소화할 수 있다.
- 다른 팀과의 협업 시 인터페이스가 명확해진다.

초기화 스크립트와 함께 수정한 이유

bulk_seed.py는 로컬/스테이징 환경에서 데이터베이스를 초기화하는 스크립트다. 새 저장소 구조가 추가되면, 당연히 이 시드 로직도 업데이트해야 한다.

이런 초기화 스크립트가 중요한 이유:

변경은 간단하지만 중요한 원칙을 담고 있다:

✓ 새 모듈을 추가했다면, 시드 로직도 함께 업데이트
✓ 로컬 dev 환경과 프로덕션의 데이터 구조가 대칭
✓ PR 리뷰 시 "초기화 스크립트도 봤나?"가 체크리스트 항목

회고: 아키텍처 결정의 trade-off

저장소 분리 결정을 내릴 때 여러 각도를 고민했다:

1. 메인 저장소 유지 vs. 분리
2. 유지: 단순하고, 모든 것이 한곳에 있다.

3. 분리: 복잡도가 올라가지만 장기적 유지보수가 수월하다.
   → 팀이 커지고 배포 빈도가 높아지면 분리가 필수다.

4. 마이그레이션 방식

5. 일괄 이전: 위험하지만 빠르다.

6. 점진적 분리: 느리지만 롤백 경로가 있다.
   → "side REPOS"라는 별칭으로 기존 코드와 공존하는 방식을 택했다.

7. 초기화 로직의 복잡도

8. 별도 스크립트 분산: 관리 지점이 많아진다.
9. 통합 스크립트에 로직 추가: 한곳에서 관리되지만 테스트 케이스가 늘어난다.

신규 팀원들이 "이미지 다운로드 안 되네" 같은 문제로 물어올 때, 원인이 대개 초기화 단계에서 빠진 데이터라는 걸 경험했다. 그래서 이 변경은 단순한 기술 결정이 아니라, 팀 경험도 함께 개선하는 작업이라고 본다. 초기화 스크립트 한 줄이 누군가의 30분 디버깅 시간을 아낄 수 있으니까.

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

• 사무의자 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

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