우리 글로벌 앱마켓 서비스는 VM 위에서 동작한다. 이 환경에 Packer와 Terraform으로 IaC 기반 CI/CD를 도입해 그동안 수동으로 해 오던 인프라 구성을 코드로 옮겼다. 그 과정을 정리한다.
문제 — 인프라 구성과 배포 소스의 불일치
클라우드 인프라와 서비스 프로그램을 서로 다른 수동 절차로 빌드·배포하면서 인프라 구성과 배포 소스 사이에 불일치가 발생했다. 환경을 추가하거나 복구할 때는 엔지니어가 포털에서 설정을 다시 입력해야 했고, 로컬·개발·QA·상용 환경의 차이로 동일한 소스에서도 실행 결과가 달라지는 경우가 있었다.
"자동으로 다시 만들 수 없고, 환경마다 손으로 관리해야 하는 인프라"를 없애기로 했다. 도구는 사내 표준이던 Jenkins(CI/CD 실행)와 Bitbucket(형상관리), 그리고 Packer·Terraform이었다. IaC도 따지고 보면 소스코드라 코드로 관리하고 그 코드로 파이프라인을 실행하는 게 핵심이었다.
CI — Packer 골든 이미지, 그리고 Base/Service 분리
CI에는 Packer를 도입했다. 단일 소스 구성에서 여러 환경에 동일한 머신 이미지를 쓸 수 있게 되면서 환경 불일치 문제가 크게 줄었고, 수동 빌드 과정의 인적 사고도 예방됐다.
공통 환경을 담은 BaseImage와 그 위에 서비스를 올리는 ServiceImage도 분리했다. 공통 구성을 BaseImage에서 관리하자 ServiceImage 간 환경 차이가 줄었고, 더 자주 실행되는 ServiceImage 빌드 시간도 짧아졌다. 표준 환경과 서비스별 구성의 책임 범위를 명확히 나눈 것이다.
효과는 숫자로도 분명했다.
| 구분 | 도입 전 | 도입 후 |
|---|---|---|
| 이미지 빌드 프로세스 | 5회 이상(수동) | 1회 (BaseImage 빌드 시 2회) |
| 총 작업 시간 | 약 35분 | 약 10분 (ServiceImage 기준) |
소스 빌드 → 실행 파일 적재 → 임시 VM 구성 → 파일 배치 → VM 이미지 빌드·갤러리 적재로 이어지던 수동 5단계가 CI 프로젝트 한 번 실행으로 자동화됐다.
CD — Terraform과 Canary 배포
CD에는 Terraform을 도입했다. 기존에는 엔지니어가 포털에서 VMSS 구성을 직접 변경했지만, 이후에는 프로비저닝 설정을 코드로 관리하고 plan을 검토한 뒤 scale in/out을 적용하도록 바꿨다.
배포 전략도 바꿨다. 전통적인 Blue/Green 대신 Canary 방식을 채택해 불필요한 리소스 생성을 줄이고 배포 시간을 단축했다.
돌아보며
수동으로 관리하던 인프라 구성을 코드로 옮기면서 변경 절차와 환경별 설정을 저장소에서 비교할 수 있게 됐다. 이미지 빌드 시간도 약 35분에서 10분으로 줄었다.
이 작업으로 두 가지 원칙이 자리를 잡았다. 하나는 "인프라도 소스코드처럼 관리한다", 다른 하나는 "공통 토대(Base)와 서비스(Service)를 분리한다"는 것이다. 인프라가 앞으로 어떤 형태로 바뀌더라도 이 둘은 계속 들고 갈 생각이다.
참고