Staging을 없앨 때가 왔다: Production에서 Testing의 필요성

발행: (2025년 12월 5일 오전 01:02 GMT+9)
9 min read
원문: Dev.to

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have the text, I’ll translate it into Korean while preserving the original formatting, markdown, and any code blocks or URLs.

Introduction

스테이징은 오랫동안 소프트웨어 개발에서 불가피한 악으로 여겨져 왔습니다. 한때는 변경 사항이 프로덕션에 도달하기 전에 검증하는 데 필수적인 환경이었습니다. 그러나 최신 격리 방법과 온‑디맨드 샌드박스가 등장하면서 스테이징은 이점보다 부담이 되었습니다. 이제 스테이징 환경을 없앨 때입니다.

왜 스테이징이 병목이 되는가

  • 공유 큐: 많은 개발자가 코드를 병합하면, 스테이징은 실제 버그가 아니라 충돌하는 변경으로 인해 테스트가 실패하는 경쟁 지점이 된다.
  • 정밀도 격차: 스테이징은 “프로덕션‑유사”하지만 실제 데이터 규모, 트래픽 패턴, IAM 정책과는 일치하지 않아 위험한 버그가 숨겨질 수 있다.
  • 속도 손실: 코드를 커밋하고 CI를 기다리며, 배포 슬롯을 기다리고, 긴 테스트 스위트를 실행하는 사이클이 흐름 상태를 파괴한다.
  • 무시된 유지보수: 팀은 종종 불안정한 빌드를 스테이징에 투입하여 프로덕션과의 차이를 더욱 벌린다.

구시대적 가정

전통적인 워크플로는 테스트가 환경 수준에서 격리되어야 한다고 가정합니다: 서비스의 새로운 버전을 테스트하려면, 해당 서비스를 모든 종속성(카트, 사용자, 인증 등)과 함께 별도의 환경에 배포합니다. 이 가정은 더 이상 유효하지 않습니다.

Request‑Level Isolation: A New Model

전체 환경을 복제하는 대신, 변경 중인 서비스만 띄웁니다. Kubernetes‑네이티브 플랫폼은 각 요청에 대해 온‑디맨드 샌드박스를 제공할 수 있습니다.

How It Works

  1. Sandbox creation: 새로운 서비스 버전이 격리된 샌드박스에서 시작됩니다.
  2. Header tagging: 테스트 요청에 고유 헤더가 태깅됩니다.
  3. Routing: 헤더가 요청을 샌드박스된 서비스로 라우팅합니다.
  4. Dependency calls: 샌드박스된 서비스가 의존 서비스에 호출할 경우, 해당 호출은 프로덕션의 안정적인 베이스라인 서비스로 다시 라우팅됩니다.
  5. Isolation: 테스트 요청은 스택을 통과하는 동안 격리된 상태를 유지하고, 다른 모든 트래픽은 정상적으로 진행됩니다.

이 접근 방식은 실제 의존성 및 실제 네트워크 정책을 사용한 고충실도 테스트를 제공하면서, 공유 환경의 단점(충돌, 대기열) 없이 비용을 크게 낮출 수 있습니다.

Source:

안전한 프로덕션 테스트를 위한 가드레일

엄격한 데이터 격리

라우팅 헤더가 테스트 트래픽을 격리하고 모든 데이터베이스 쓰기를 별도의 테스트 데이터베이스로 전달합니다. 테스트 사용자는 테스트 데이터와만 상호작용하며, 프로덕션 데이터는 손대지 않습니다.

멀티테넌시 및 네트워크 제어

  • VPN 제한을 통해 테스트 트래픽이 허가된 내부 네트워크에서만 발생하도록 보장합니다.
  • 감사 로그가 모든 샌드박스 세션을 추적하여 규정 준수를 지원합니다.

요청 라우팅 및 블라스트‑반경 제어

샌드박스된 요청은 요청 수준에서 격리되어 동료 작업에 영향을 주지 않으며, 프로덕션 트래픽도 영향을 받지 않게 합니다.

점진적 롤아웃

샌드박스는 사전 프로덕션 검증을 수행하지만, 실제 사용자에게 안전하게 배포하기 위해 카나리 배포, 피처 플래그, 관측성을 여전히 활용합니다.

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와 사용자 신원으로 태그되어, 공유 스테이징 환경보다 더 세분화된 감사 로그를 생성합니다.

혜택 및 실제 적용

  • 비용 절감: 스테이징 환경을 유지하는 직접적인 인프라 비용을 없앱니다.
  • 개발자 경험: 피드백 루프를 빠르게 하고 마찰을 줄입니다.
  • 시장 출시 속도: 팀이 경쟁사보다 더 빠르게 반복하고 배포할 수 있습니다.
  • 신뢰성: 고충실도 테스트가 스테이징에서는 놓칠 수 있는 버그를 잡아냅니다.

DoorDash와 Uber와 같은 유명한 클라우드 네이티브 팀들은 이미 프로덕션에서 테스트하는 방식으로 왼쪽으로 이동했으며, 상당한 인프라 비용 절감과 테스트 충실도 향상을 실현했습니다.

결론

스테이징 환경은 인프라를 복제하는 것이 공유 리소스를 조정하는 것보다 어려웠던 시대의 산물입니다. 그 시대는 끝나가고 있습니다. 미래는 프로덕션의 더 나은 근사치를 만드는 것이 아니라, 견고한 가드레일을 갖춘 채 프로덕션에서 직접 테스트하는 것입니다. 스테이징 환경을 없애면 더 빠른 배포, 비용 절감, 그리고 더 신뢰할 수 있는 코드를 구현할 수 있습니다.

Back to Blog

관련 글

더 보기 »

Enterprise Teams 제품 제한이 10배 이상 증가

새로운 제한 사항 - 이제 기업당 최대 2,500개의 enterprise 팀을 생성할 수 있으며, 이는 기존 100개에서 증가한 수치입니다. - 각 enterprise 팀은 이제 최대 5,000명의 사용자를 포함할 수 있습니다.