분산된 배포 환경을 공통 플랫폼으로 전환

왜 바꿔야 했는가

스쿼드별로 제품을 개발하고 운영하기 위해 서비스를 나누고, 각 서비스의 staging과 production 환경도 분리했습니다. 이 경계는 배포와 소유권을 명확하게 했지만, 서비스가 늘면서 Elastic Beanstalk 환경이 서비스와 단계마다 중복됐습니다.

각 환경은 Auto Scaling Group, ALB, 모니터링과 배포 설정을 반복해서 가지고 있었습니다. 트래픽이 크지 않은 서비스도 환경 단위의 최소 자원을 유지해야 했고, 같은 종류의 설정과 장애 지점을 여러 곳에서 관리해야 했습니다. 목표는 환경 분리를 없애는 것이 아니라, 서비스별 독립성을 유지하면서 반복되는 실행 자원과 네트워크 계층을 줄이는 것이었습니다.

무엇을 확인했는가

비용과 관리 문제는 팀 논의에서 출발했고, 제가 공통 기반 구축을 제안하고 맡았습니다. 서비스별 트래픽, 배포 방식, CPU·메모리 요구량과 외부 통신 조건을 비교했습니다.

일반 API와 달리 문서 처리 Worker는 CPU와 메모리 사용량이 컸습니다. 모든 workload를 같은 인스턴스 풀에 넣으면 고부하 작업이 일반 서비스의 자원을 잠식할 수 있었기 때문에, 공통화할 범위와 격리할 범위를 함께 설계해야 했습니다.

어떤 선택을 했는가

staging용과 production용 ECS/EC2 클러스터를 각각 구축하고 각 클러스터에 공용 ALB를 두었습니다. 서비스별로 ECS Service, Task Definition과 Target Group을 분리했으며, Terraform 모듈은 네트워크·클러스터·용량 공급자·서비스·비밀값·배포 설정을 반복해서 사용할 수 있도록 구성했습니다. 공통 기반은 중앙에서 관리하지만 서비스별 task와 배포 단위는 유지해 각 담당자가 독립적으로 변경할 수 있도록 했습니다.

고부하 Worker에는 다른 인스턴스 유형을 사용하는 전용 Auto Scaling Group과 Capacity Provider를 구성했습니다. 배포는 헬스체크와 Connection Draining을 이용한 롤링 방식으로 정리하고, 문제가 생기면 이전 task와 라우팅으로 돌아갈 수 있게 했습니다.

어떻게 전환하고 검증했는가

공통 플랫폼 전체와 Terraform 모듈을 직접 설계·구현하고 운영 도구, 콘텐츠 제작 서비스와 학습 콘텐츠 서비스 등 대표 서비스와 Worker를 먼저 이전했습니다. staging에서 task 기동, 헬스체크, DB 연결, secret 주입, 외부 API 접근과 로그 수집을 확인한 뒤 production으로 확대했습니다.

대표 서비스에서 이전 절차를 검증한 뒤 서비스 추가 방법, 배포·롤백과 이전 현황을 문서화했습니다. 나머지 서비스는 각 담당자가 같은 기반을 사용해 이전할 수 있도록 구조와 가이드를 공유했습니다.

이후 무엇이 달라졌는가

서비스별 staging·production 분리와 배포 독립성은 유지하면서, 여러 환경에 반복되던 ALB와 실행 자원을 공통 운영 기반으로 모았습니다. 약 5분 내 무중단 롤링 배포 기준을 만들었고, 다른 개발자가 가이드만 보고 신규 서비스를 추가할 수 있게 됐습니다.

공통 기반과 대표 서비스·Worker의 이전은 제가 직접 수행했고, 나머지 서비스 이전은 각 담당자가 나눠 진행했습니다. 비용 감소는 실제로 확인했지만 전환 전후를 같은 기준으로 정밀 측정하지 않았으므로, 설계 당시의 40~50% 예상치를 실제 절감 성과로 사용하지 않습니다.

다시 한다면

전환 전에 환경별 비용, 유휴율, 배포 시간과 장애 빈도를 같은 기준으로 저장해 구조 개선과 운영 효과를 함께 비교하겠습니다. 공통 플랫폼의 변경이 여러 서비스에 미치는 영향을 줄이기 위해 모듈 버전과 업그레이드 절차도 더 일찍 명시하겠습니다.

서비스 소유권과 공통 기반의 경계, workload별 격리 기준, 단계별 롤백 조건과 팀원이 재사용할 수 있는 가이드를 초기 설계부터 같은 산출물로 준비한다는 원칙은 유지할 것입니다.