스타트업 인프라 뉴비의 현실적인 배포 전략 선택기 (Ansible → CodeDeploy)

현 상황 및 문제 파악

기존 배포는 Github Actions와 Ansible을 사용 중이었다. 당시에는 인프라 담당자가 따로 있었기때문에 문제없었지만 현재는 공백인 상태로 백엔드 개발만 하던 내가 인프라도 함께 담당하게 되었다. 그렇게 인프라 공부를 시작하게 되었고, 경험이 쌓일수록 현 배포 방식의 불안정하고 불편한 점들이 보이기 시작했다.
 
 

기존 배포 플로우

현재 배포 흐름을 파악하기 위해 Github Actions부터 차근차근 살펴보았다.

// workflows

name: 배포자동화

on:
  push:
    branches: ["main"]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3
      - name: 배포자동화 호출
        run: |
          curl -X POST -H 'API-KEY: ${{ secrets.DEPLOY_SERVER_KEY  }}' ${{ secrets.DEPLOY_SERVER_URL }}

 
음? 이게 전부였다. 어떠한 배포용 API 존재하고 이를 호출하는 구조였다.
secrets 값을 직접 확인할 수 없었기 때문에 모든 서버를 둘러보았고, 예상대로 별도의 배포용 프로젝트가 존재했다.

 
상위 폴더만 저 정도였고 a-dev-file, a-prod-file, b-prod-file 이런 식으로 서버마다 분리되어있었다.
해당 서버에서 ansible이 실행되고, EC2 인스턴스에 배포 되는 흐름으로 보였다.

 

문제점

• 별도의 배포 서버 존재
  • 서버 운영을 위한 추가 리소스 필요
  • 배포 흐름 파악하기 어려움 (프로젝트 구조 및 앤서블 사전 지식 필요)
• 불안정한 서버
  • 자동화△, 무중단 배포X, 롤백X, 로깅X
  • EC2 인스턴스의 동적 IP가 변경될 때마다 Ansible 설정 수정 필요
  • 배포 실패 시 서비스 중단 가능성 존재
  • 단일 서버 구조로 장애 발생 시 서비스 전체에 영향
• 팀원 모두 인프라 경험 부족

 
이 상태 그대로 운영하기에는 리스크가 컸다. 팀 내 논의 끝에 인프라를 새로 구성하기로 했고 두 개의 선택지가 있었다.

1. Ansible을 배워, 현 상태에서 확장하기
2. 다른 배포 방식으로 변경하기

 
Ansible을 꼭 사용해야하나? 의문이 계속 들었다. 일단 현재 팀 내에 Ansible을 사용할 줄 아는 사람이 없다. 뿐만 아니라 모두 인프라 초급 수준인데 이 상태에서 Ansible을 배운다고 해서 잘 사용하기 힘들 거 같았다. 후에 새로운 팀원이 들어올 때마다 매번 Ansible을 배우게 해야한다는 부담도 있었다.
 
이러한 이유로 새로운 배포 방식을 도입하기로 했다.
 
 

---

배포 방식 결정

고려한 조건

• 낮은 러닝 커브
• 최소한의 시간/인적 리소스 소요
• 빠르고 간편한 유지보수
• 자동화, 가용성 보장, 무중단 배포, 롤백, 로깅 등 안정성 확보
• 사용 중인 EC2 인스턴스 최대한 유지하기

누구나 빠르게 익힐 수 있고, 적용이 빠르고 간단하기를 원했다. 따라서 기존에 사용 중이던 AWS 서비스 중심으로 접근했다.
후보

• AWS Elastic Beanstalk
• AWS Elastic Container Service
• AWS CodeDeploy

 
 

선택: AWS CodeDeploy

결론적으로 CodeDeploy를 선택했다.

• EC2 인스턴스 기반의 배포 방식을 제공하고
• 배포 전략, 무중단 배포, 롤백, 로깅, 오토 스케일링 등의 기능을 지원하며
• 배포 과정이 자동화되어 있어 관리 포인트가 적고
• 적당한 러닝 커브, 참고할 레퍼런스가 많아 쉽게 익힐 수 있어

최소한의 리소스로 최대 효율을 가져올 수 있다는 점에서 현재 팀 상황에 가장 현실적이고 적합한 선택이라고 판단했다.
 

---

배포 전략?

배포 전략에도 다양한 방법이 있었다. 단순 기존 서버를 내리고 새 버전으로 재배포 하는 빅뱅 배포부터, 흔히 들어온 블루/그린 배포 그 외에도 롤링 배포, 카나리 배포 등이 있었다. 해당 영상을 참고 했다.
 
기존 배포 전략은 사실상 빅뱅 배포에 가까웠다. 특히 개발 서버는 단일 서버에 새 코드를 올리는 방식이었고 배포에 실패하면 SSH 접속으로 수동 배포하는 경우도 있었다. 한 번은 개발 서버 QA 도중 간단한 수정사항이라 생각하고 배포했는데 메모리 이슈로 서버가 다운된 적이 있다. 당연히 서비스 자체가 죽어버렸고 QA도 중단될 수밖에 없었다. 지금 돌아보면 너무 위험했고, 실 운영 환경에서는 사용되어서는 안될 전략이었다.
 
안정적인 개발을 위해 좋은 설계와 아키텍처가 필요한 것처럼, 안정적인 운영을 위해서는 적합한 배포 전략이 중요했다.
 
 

선택: Blue/Green 전략

CodeDeploy는 In-place와 블루/그린, 두 가지 방식을 제공한다. 각자의 장점이 다르고 둘 다 필요한 부분들이라 고민이 많았다.
따라서 다음과 같은 기준을 두고 비교해봤다.

1. 비용
   • B/G: 새로운 인스턴스(Green)를 생성해야하므로 추가 인프라 비용 발생
   • In-place: 기존 인스턴스 그대로 사용하므로 별도의 인프라 비용이 들지않음
2. 구현 난이도
   • In-place: 상대적으로 설정 요소가 적음
   • B/G: ASG, 로드밸런서 등 구성 요소가 많음 → 이에 대한 이해도 필요, 관리 포인트 증가
3. 가용성 및 안정성
   • In-place: 기존 인스턴스에 재배포 하는 방식으로 다운타임 발생 가능성 존재
     • 로드밸런싱 설정 및 롤링 전략으로 무중단 배포를 구성할 수는 있지만 안정성이 떨어짐
   • B/G: 고가용성, 무중단 배포, 빠른 롤백 지원
4. 확장성(오토 스케일링)
   • In-place: 가능은 하나, 위험 요소 존재
     • 배포 도중 AS가 진행될 경우, 기존 인스턴스와 새로운 인스턴스 간에 싱크 문제 가능성 존재
   • B/G: 비교적 안정적
     • 블루와 그린이 독립적인 환경으로 구성되어, 그린에서만 AS 진행
     • CodeDeploy가 자동으로 AS를 구성하기 때문에(ASG 템플릿 기반) 관리 포인트 줄어듦

	In-Place	Blue/Green
비용	추가 비용 X	추가 비용 발생
구현 난이도	낮음	높음
가용성 및 안정성	낮음	높음
확장성(오토 스케일링)	위험 요소 존재	안정적

 
 
안정적인 구조를 최우선으로 고려 했고 블루/그린 방식으로 결정했다. 또한 자동화 된 부분이 많고 롤백, 모니터링 등을 기본적으로 제공하고 있어 초기 설정만 제대로 해주면 이후 운영 부담이 적을 거라 기대했다.
 
계획 중인 배포 플로우는 다음과 같다.

 

---

회고

개발에 정답은 없다는 걸 다시 한 번 느꼈다. 인프라 뉴비로써 내가 직접 배포 방식과 전략을 선택한다는 것에 부담이 컸었다. ‘좋은 인프라는 최적화된 비용과 성능’ 고정관념처럼 박혀있었고, 아무것도 모르는 내가 이걸 해낼 수 있을까 막막하기만 했다.

걱정은 뒤로한 채로 현 상황부터 되짚어보기 시작했다. 내가 실제 뭘 불편해했었고 뭘 필요로 해왔는지 곰곰이 생각해봤고, 우리 팀에 당장 필요한 건 안정적인 구조와 간단한 운영 체계였다. 현 구조에서는 비용/성능 최적화가 크게 의미 없는 일이었다.
 
이론적인 정답을 따라가기보다는, 지금 가장 필요한게 무엇이고 선택할 수 있는 최선이 무엇일지 고민하는게 더 중요했다. 지금의 결정이 적절한 선택인지는 실제로 구축해봐야 알겠지만 그때는 또 그때의 최선책을 찾아가는게 개발자의 숙명 아닐까..