스테이징을 없앨 때가 왔다: 프로덕션 테스트의 필요성
Source: Dev.to
Introduction
스테이징은 오랫동안 소프트웨어 개발에서 불가피한 악으로 여겨져 왔습니다. 한때 프로덕션에 배포하기 전에 변경 사항을 검증하는 기본 환경이었습니다. 하지만 최신 격리 방법과 온‑디맨드 샌드박스가 등장하면서 스테이징은 이점보다 부작용이 더 크게 되었습니다. 이제 스테이징 환경을 없앨 때입니다.
Why Staging Becomes a Bottleneck
- Shared queue: 많은 개발자가 코드를 병합하면 스테이징은 실제 버그가 아니라 충돌하는 변경 사항 때문에 테스트가 실패하는 병목 지점이 됩니다.
- Fidelity gap: 스테이징은 “프로덕션과 유사”하지만 실제 데이터 규모, 트래픽 패턴, IAM 정책과는 일치하지 않아 위험한 버그가 숨어 있을 수 있습니다.
- Velocity loss: 코드를 커밋하고, CI를 기다리고, 배포 슬롯을 기다리며, 긴 테스트 스위트를 실행하는 사이클이 흐름을 파괴합니다.
- Neglected maintenance: 팀은 종종 불안정한 빌드를 스테이징에 투입해 프로덕션과의 차이를 더욱 벌어지게 합니다.
The Outdated Assumption
전통적인 워크플로는 테스트가 환경 수준에서 격리되어야 한다고 가정합니다: 서비스의 새로운 버전을 테스트하려면 모든 종속성(카트, 사용자, 인증 등)과 함께 별도 환경에 배포해야 합니다. 이 가정은 이제 유효하지 않습니다.
Request‑Level Isolation: A New Model
전체 환경을 복제하는 대신, 변경 중인 서비스만을 띄웁니다. 쿠버네티스‑네이티브 플랫폼은 각 요청마다 온‑디맨드 샌드박스를 제공할 수 있습니다.
How It Works
- Sandbox creation: 새로운 서비스 버전이 격리된 샌드박스에서 실행됩니다.
- Header tagging: 테스트 요청에 고유 헤더가 태깅됩니다.
- Routing: 헤더를 통해 요청이 샌드박스된 서비스로 라우팅됩니다.
- Dependency calls: 샌드박스된 서비스가 종속 서비스에 호출할 때는 프로덕션의 안정적인 베이스라인 서비스로 라우팅됩니다.
- Isolation: 테스트 요청은 스택을 가로지르는 동안 격리된 상태를 유지하고, 다른 트래픽은 정상적으로 진행됩니다.
이 접근 방식은 높은 충실도의 테스트(실제 종속성, 실제 네트워크 정책)를 제공하면서 공유 환경의 단점—충돌, 대기열, 높은 비용—을 없앱니다.
Guardrails for Safe Production Testing
Strict Data Isolation
라우팅 헤더가 테스트 트래픽을 격리하고 모든 데이터베이스 쓰기를 별도의 테스트 데이터베이스로 전송합니다. 테스트 사용자는 오직 테스트 데이터와만 상호작용하며, 프로덕션 데이터는 손대지 않습니다.
Multitenancy & Network Controls
- VPN 제한을 통해 테스트 트래픽이 인증된 내부 네트워크에서만 발생하도록 합니다.
- 감사 로그가 모든 샌드박스 세션을 추적해 컴플라이언스를 보장합니다.
Request Routing & Blast‑Radius Control
샌드박스된 요청은 요청 수준에서 격리되어 동료 작업에 영향을 주지 않으며, 프로덕션 트래픽도 그대로 유지됩니다.
Progressive Rollout
샌드박스는 사전 프로덕션 검증을 담당하지만, 실제 사용자에게 배포할 때는 여전히 카나리 배포, 피처 플래그, 관측성을 활용해 안전하게 롤아웃합니다.
Frequently Asked Questions
How do you guarantee test traffic doesn’t corrupt production data?
테스트 쓰기는 일시적인 비프로덕션 데이터 스토어로 리다이렉트되며, 테스트가 끝나면 파기됩니다.
What about blast radius? Could a bad test DDoS a downstream service?
샌드박스는 회로 차단기와 네트워크 정책이 적용된 “섀도우” 배포입니다. 과도한 요청은 제한되고 격리됩니다.
Does this work for protocols like Kafka or gRPC?
격리 모델은 프로토콜에 구애받지 않습니다. 격리 헤더는 gRPC나 Kafka 메시지 헤더에 전달되어 샌드박스된 컨슈머가 고유 샌드박스 ID가 포함된 메시지만 처리하도록 합니다.
How are compliance and audit requirements met?
각 샌드박스는 특정 사용자와 풀‑리퀘스트/개발 세션에 연결됩니다. 모든 테스트 트래픽은 샌드박스 ID와 사용자 ID가 태깅되어, 공유 스테이징 환경보다 더 세밀한 감사 로그를 생성합니다.
Benefits and Real‑World Adoption
- Cost savings: 스테이징 환경을 유지하는 직접 인프라 비용을 없앱니다.
- Developer experience: 피드백 루프가 빨라지고 마찰이 감소합니다.
- Speed to market: 팀이 경쟁사보다 빠르게 반복하고 배포할 수 있습니다.
- Reliability: 높은 충실도의 테스트가 스테이징에서는 놓칠 수 있는 버그를 잡아냅니다.
DoorDash와 Uber와 같은 주요 클라우드‑네이티브 팀은 이미 프로덕션 테스트로 좌측 이동을 진행했으며, 상당한 인프라 비용 절감과 테스트 충실도 향상을 경험하고 있습니다.
Conclusion
스테이징 환경은 인프라를 복제하는 것이 공유 자원을 조정하는 것보다 어려웠던 시대의 산물입니다. 그 시대는 끝났습니다. 미래는 프로덕션을 더 잘 흉내 내는 것이 아니라, 견고한 가드레일을 갖춘 채 직접 프로덕션에서 테스트하는 것입니다. 스테이징 환경을 없애면 더 빠른 전달, 낮은 비용, 그리고 더 신뢰할 수 있는 코드를 얻을 수 있습니다.