여러 환경에 스키마를 배포하며 배운 점

제주 응답로그의 DDL(Database Definition Language)을 개발, 운영, 쇼핑몰 플랫폼 총 3개 환경에 반영 완료했고, 이 과정을 진행 상황 handoff 문서에 기록했다. 단순해 보이지만, 이것은 팀의 데이터 스키마 관리 및 배포 전략의 중요한 마일스톤이었다.

왜 여러 환경에 DDL을 배포하는가

응답로그 기능은 사용자의 모든 요청과 응답을 기록하는 핵심 기능이다. 때문에 그 스키마 정의는 단순히 개발 환경에서만 유지되면 안 되고, 실제 운영되는 모든 환경과 별도 서비스까지 일관되게 반영되어야 한다. 개발 환경에서만 새로운 스키마를 적용하고 운영 환경에 반영하지 않으면, 개발팀은 새로운 필드를 활용하는 코드를 짤 수 없다. 역으로 운영 환경에만 먼저 배포되면 개발 단계의 테스트가 제대로 진행될 수 없다.

더 중요한 건, 여러 환경이 각각 다른 팀이나 서비스에서 관리될 수 있다는 점이다. 개발 환경은 우리 팀이 매일 변경하지만, 운영 환경이나 쇼핑몰 플랫폼은 별도 운영 정책이 있을 수 있다. 때문에 각 환경에 DDL이 정확히 반영되었는지, 언제 반영되었는지를 명확히 기록하고 전파하는 과정이 필수다.

환경별 배포 현황과 옵션 전략

배포가 단순히 "스키마 적용"으로 끝나지 않는다는 걸 이번에 다시 느꼈다. 함께 배포되는 옵션과 플래그가 각 환경에서 어떻게 작동할지도 결정해야 한다는 뜻이다.

웰컴 OFF, 개발 전용 옵션 확정의 의미

이번에 함께 확정한 '웰컴 OFF' 옵션은 응답로그 기능 개발 초기에 불필요한 로깅을 일시적으로 비활성화할 수 있는 기능이었다. 개발 과정에서 기능을 여러 번 재시작하거나 테스트하면서 응답로그가 어마어마하게 쌓이는데, 이를 필터링하기 위함이었다.

그런데 개발이 어느 정도 진행되자, 이 옵션을 운영 환경까지 지원할지가 문제였다. 운영 환경에서는 모든 로그가 중요할 수 있으니, 임의로 로깅을 끄는 건 위험하다. 결국 이 옵션을 개발 환경 전용으로 확정하고, 운영 및 쇼핑몰 플랫폼에서는 배포 대상에서 제외하기로 했다.

이렇게 결정한 이유는:

• 개발 생산성 vs 운영 안정성의 트레이드오프: 개발자들이 빠르게 테스트할 수 있으면서도, 운영 시스템의 무결성을 보장할 수 있다
• 기능 flag 관리의 단순화: 모든 환경에서 동일한 코드를 실행하되, 환경에 따라 특정 플래그를 비활성화하는 패턴
• 나중의 삭제 용이성: 개발 전용이면 언제든 필요 없을 때 제거할 수 있다

문서화, 팀 협력의 시작

이 모든 변경을 handoff 문서에 기록한 것도 중요한 부분이다. "언제 어느 환경에 DDL을 배포했고, 어떤 옵션이 활성화되었으며, 누가 담당했는가"를 명확히 남겨야 다음 팀원이 이 작업을 이어받을 수 있다.

특히 쇼핑몰 플랫폼처럼 외부 팀이 운영하는 환경이라면, 문서가 없으면 커뮤니케이션 비용이 엄청나다. "웰컴 OFF를 우리는 개발 전용으로 했는데, 그쪽은 필요 없겠죠?"라고 일일이 물어봐야 한다. 하지만 문서에 명시되어 있으면, 그 의도와 근거가 명확해진다.

배운 점

이번 작업을 통해 느낀 건, 멀티 환경 배포의 핵심은 "기술적 배포"가 아니라 "결정과 소통"이라는 것이다. 스키마 자체는 결정되면 배포 자동화로 빠르게 처리할 수 있지만, 그 과정에서 어떤 옵션을 활성화할지, 어느 환경까지 지원할지 같은 결정이 필요하다. 그리고 그 결정들을 문서에 기록하고 팀과 공유하는 게 미래의 유지보수를 훨씬 수월하게 만든다.

또한, 개발 환경에서만 작동하는 옵션을 명확히 분리하는 것도 배웠다. "나중에 필요하면 추가하자"는 생각으로 모든 기능을 모든 환경에 넣었다가는, 나중에 비활성화하는 게 더 복잡해진다. 차라리 처음부터 "이건 개발 전용"이라고 선언하고, 운영 환경에는 그 코드 경로를 아예 배포하지 않는 게 낫다.

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

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 책상조명 쿠팡에서 보기 →

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