Stage Web 제거 및 Preview 배포 전략 논의

[manNomi]

배경

현재 별도로 운영 중인 Stage Web이 실제 검수 과정에서 꼭 필요한지 논의하고 싶습니다.

기존에는 Stage Web에서 Stage API를 연결해 기능을 검수했지만 개별 변경사항은 PR Preview에서도 확인할 수 있어 상시 Stage Web이 배포 구조의 복잡도만 높이는 것은 아닌지 의견이 나왔습니다.

다만 Preview에서 API 연동 테스트를 진행하려면 Stage API가 Preview 도메인의 요청을 허용해야 합니다. 테스트용 목데이터를 만들거나 별도의 API 요청 검수가 필요한 경우에는 기존 Stage Web을 유지하는 편이 나을 수도 있습니다.

제안하는 방향

PR별 Preview를 용도에 따라 두 환경으로 나누는 방안을 생각하고 있습니다.

• Stage API를 바라보는 Preview
• Production API를 바라보는 Preview
• 필요할 때 특정 라벨을 붙이면 Stage 배포를 실행하는 방식
• Stage API에서는 Preview 도메인에 필요한 CORS 정책을 적용

이 구성이 가능하다면 상시 Stage Web은 제거하고 필요한 시점에만 Stage 환경을 생성하거나 배포할 수 있을 것 같습니다.

논의가 필요한 사항

1. API 연동 검수를 PR Preview만으로 충분히 대체할 수 있을까요?
2. Preview에서 Stage API를 호출할 때 CORS와 인증 설정을 어떤 방식으로 관리하는 것이 좋을까요?
3. Production API를 바라보는 Preview에서 쓰기 요청이나 테스트 데이터가 운영 환경에 영향을 주지 않도록 어떻게 제한해야 할까요?
4. 특정 라벨을 기준으로 Stage 배포를 실행하는 방식이 현재 배포 흐름에 적합할까요?
5. 추가 요구사항이나 목데이터 기반 API 테스트를 고려하면 상시 Stage Web을 유지할 필요가 있을까요?
6. Next.js의 SSR이 필요한 페이지를 S3 기반 Stage 환경에서 운영할 수 있을까요? S3에는 정적 결과물만 배포하고 SSR 실행은 별도의 런타임으로 분리해야 하는지도 확인이 필요합니다.

결정하고 싶은 내용

• 상시 Stage Web을 유지할지 제거할지
• Preview별 API 연결 정책
• Stage 배포를 실행하는 조건과 운영 방식
• SSR이 포함된 경우 Stage 인프라 구성

관련 경험이나 더 단순한 구성에 대한 의견 부탁드립니다.