인식한 상황
기존에는 Dev 서버를 지인 또는 지인의 지인을 통해 테스트 환경으로 활용했고, 이후 이를 스토어에 실제 배포하여 전혀 모르는 사용자에게까지 노출하려 할 때, 다음과 같은 문제가 우려되었다.
개발 중인 기능 노출 위험성: 완성되지 않은 기능이 배포 환경에 그대로 반영될 수 있어 사용자 경험에 악영향을 줄 수 있다.
안정성 부족: 새로운 기능 추가 시 기존 기능에 오류가 발생할 가능성이 있고, 이를 사용자에게 바로 노출하는 것은 위험하다.
검증 환경 부재: Local 테스트 외에 실제 서버 환경에서 충분한 테스트를 수행하기 어려워 생산성 저하 및 예측 불가능한 문제 발생 가능성이 있다.
해결 과정
이제는 개발(Dev), 스테이징(Staging), 프로덕션(Production) 환경을 명확히 분리하는 전략이 필요하다고 느껴졌다.
환경 분리를 통한 안정성 확보
환경별 독립적인 네트워크 구성
단일 네트워크에서 Dev, Staging, Prod 서버를 모두 올리는 대신, 클라우드 제공사의 Private Network 기능을 활용하여 각 환경을 별도의 네트워크로 분리했다.
단일 Nginx 로드 밸런서를 통한 라우팅
Nginx를 활용해 모든 요청을 수신한 뒤, 요청 도메인 및 서브도메인(dev, staging, production)에 따라 각 환경별 Private Network 내 API 서버로 트래픽을 라우팅한다.
예(실제 배포중이라서 이상한 주소로 넣음)
https://api.example.com→ Production 서버https://dev.example.com→ Dev 서버https://staging.example.com→ Staging 서버
환경별 독립된 API 서버 컨테이너 배포
각 환경에 대해 독립된 API 서버 컨테이너를 구성하고, 환경별 설정·데이터를 분리했다.
이로써 Dev에서 실험 중인 기능이 Prod 환경에 영향을 주지 않고, Staging 환경에서 충분한 테스트를 거친 뒤 안정화된 기능만 Prod에 반영하는 순환 구조를 갖추었다.
배포 파이프라인 개선
Github Actions + Bastion Host
Private Network에 직접 접근하기 어려운 상황을 해결하기 위해 Bastion Host(점프 서버)를 두어 배포 파이프라인을 개선했다. Github Actions에서 Bastion Host로 SSH 접속한 뒤 내부적으로 Private Network에 위치한 API 서버에 접근하여 배포하는 전략을 사용했다.
이를 통해 외부에서 직접 Private Network로 접근할 필요 없이 안전하게 서버를 업데이트할 수 있었다.
로깅 및 모니터링 환경 개선
Sentry를 통한 로깅 인프라 구성
환경을 분리한 뒤 각 환경에서 발생하는 오류를 중앙화된 로깅 시스템에서 쉽게 모니터링할 필요가 있었다.
Sentry를 도입하여 환경별 오류 발생 시 바로 알림을 받을 수 있도록 설정했다.
Discord 알림을 연계하여 오류가 발생할 경우 실시간으로 팀에 통보되도록 함으로써 신속한 대응이 가능해졌다.
결과
이후에는 Staging 환경에서 충분한 테스트를 거쳐 안정화된 기능만 Prod 환경에 반영함으로써 사용자에게 안정적 서비스 제공이 가능해졌다. 또한, 우리가 실험적으로 하고 싶었던 기능을 Dev 환경에서 자유롭게 기능을 실험한 뒤, Staging을 거쳐 Prod에 배포하므로 기능 추가 시 발생할 수 있는 리스크를 사전에 줄일 수 있었다.
마지막으로 Sentry를 통한 중앙화된 로깅, Discord 알림 연계를 통해 오류 대응 속도가 빨라지고, 원인 파악도 용이해졌다. (와 진짜 알림 오는 거 너무 사기…)