왜 우리는 환경마다 다른 배포 전략을 선택했을까?

 

신규 서비스를 배포하는 과정에서, 각 환경에서 사용 중인 배포 방식을 다시 점검하게 되었다.
현재 개발 환경에서는 dev, perf, stg를 용도별로 분리하여 사용하고 있으며, 이 중 dev와 perf / stg 간에는 배포 방식에 명확한 차이가 존재한다.

 

본 글에서는 왜 환경에 따라 서로 다른 배포 전략을 선택했는지, 그리고 그 선택이 어떤 목적을 반영하고 있는지를 정리해보고자 한다.

 

환경별 배포의 목적

환경별 배포 전략을 이해하기 위해서는, 각 환경이 가지는 목적을 먼저 살펴볼 필요가 있다.

• Dev 환경은 빠른 실험과 반복적인 변경을 통해 기능을 검증하는 것이 목적이다.
• Stg / Perf 환경은 운영 환경과 최대한 유사한 조건에서 시스템을 검증하는 것이 목표이다.

이처럼 환경별로 추구하는 가치가 다르기 때문에, 동일한 배포 방식을 적용하기보다는 목적에 부합하는 서로 다른 CD 전략을 선택하게 되었을 것이다.

 

 

배포의 출발점: 컨테이너 이미지 저장소 (ECR)

모든 환경에서 공통적으로 사용하는 배포의 출발점은 컨테이너 이미지이다.
이미지는 AWS ECR(Elastic Container Registry) 을 통해 관리하고 있다.

 

ECR은 Docker 이미지를 저장하고 관리하는 AWS의 컨테이너 레지스트리 서비스로,
GitHub Actions를 이용한 CI 파이프라인이 완료되면 빌드 결과물은 항상 ECR에 저장된다.

 

즉, 환경별 배포 전략의 차이는 이미지 생성 이후 단계에서 발생한다.

 

 

Dev 환경 배포의 핵심: CloudFormation

Dev 환경에서는 CloudFormation을 중심으로 배포가 이루어진다.

 

CloudFormation은 AWS 리소스를 코드로 정의하고, 정의된 상태와 실제 인프라 상태를 일치시키는 IaC(Infrastructure as Code) 서비스이다.
AWS 공식 문서에서는 CloudFormation을 다음과 같이 설명한다.

“Create and update AWS resources in an orderly and predictable fashion.”

 

Dev 환경에서는 이 설계도를 기준으로 필요한 인프라를 포함해 전체 스택을 생성하거나 갱신하는 방식으로 배포를 진행한다.

 

 

Dev 환경에서 컨테이너 실행 구조: ECS와 ASG

컨테이너 실행은 ECS(Elastic Container Service) 를 통해 이루어진다.

 

ECS는 컨테이너를 실행하고 관리하는 서비스로, 다음과 같은 구성 요소를 기반으로 동작한다.

• Task Definition: 컨테이너 실행에 대한 정의
• Service: 실행할 Task의 개수 및 유지 정책 관리

한편, ECS 자체는 물리적인 서버를 제공하지 않는다.
실제로 컨테이너는 ASG(Auto Scaling Group) 가 관리하는 EC2 인스턴스 위에서 실행된다.

 

구조를 단순화하면 다음과 같다.

ASG (EC2 여러 대)
 └─ ECS Cluster
     └─ ECS Service
         └─ ECS Task (Container)

 

 

요청 흐름: ALB와 Listener Rule

외부 요청의 진입점은 ALB(Application Load Balancer) 이다.

 

하나의 ALB에는 여러 서비스가 연결될 수 있으며,
이때 Listener Rule이 요청을 어떤 서비스로 전달할지를 결정한다.

 

Listener Rule은 요청의 Host, Path 등의 조건을 기준으로
어떤 Target Group(ECS Service)으로 트래픽을 라우팅할지 정의하는 규칙이다.

 

예를 들어,
search.dev.kurly.services 로 들어온 요청을 특정 ECS 서비스로 전달하는 방식이다.

 

 

Dev 환경에서 CloudFormation을 사용하는 이유

Dev 환경의 배포 목표는 다음과 같이 정리할 수 있다.

빠르고 자유롭게, 인프라까지 포함하여 배포한다.

 

이를 위해 Dev 환경에서는 다음 리소스를 모두 CloudFormation을 통해 자동으로 생성·관리한다.

• ECS Service
• Target Group
• ALB Listener Rule
• Route53 도메인

인프라 변경에 대한 제약을 최소화함으로써,
개발 과정에서의 실험과 수정이 빠르게 이루어질 수 있도록 설계되어 있다.

 

 

Stg / Perf 환경 배포의 핵심: CodeDeploy

Stg / Perf 환경에서는 CodeDeploy를 중심으로 배포가 이루어진다.

 

CodeDeploy는 이미 존재하는 서비스에 대해 새 버전의 애플리케이션을 안전하게 교체해주는 배포 관리 서비스이다.
Dev 환경과의 가장 큰 차이점은 인프라를 새로 생성하지 않고 애플리케이션만 교체한다는 점이다.

 

이 방식은 다음과 같은 목적을 가진다.

• 운영 환경과 최대한 동일한 조건에서 검증
• 배포 중복 방지
• 실패 시 즉각적인 중단 및 롤백 가능

즉, Stg / Perf 환경은 안정성과 운영 재현성을 최우선 가치로 삼고 있다.

 

 

왜 환경별로 배포 전략을 나누었을까

결국 환경별 배포 전략의 차이는 환경마다 지켜야 할 가치가 다르기 때문이다.

• Dev 환경은 속도와 자율성을 중시하고
• Stg / Perf 환경은 안정성과 운영 환경과의 일관성을 중시한다

각 환경의 목적에 맞는 도구와 전략을 선택함으로써,
전체 배포 프로세스의 효율성과 안정성을 동시에 확보할 수 있었다.

 

이 글이 환경별로 서로 다른 CD 전략을 사용하는 이유를 이해하는 데
하나의 실무적인 참고 자료가 되기를 바란다.