새 버전을 서버 100개에 배포했는데 90개는 정상이고 10개는 GPU 자리를 기다리고 있습니다. 이때 배포를 실패도 성공도 아닌 채로 계속 붙잡아 둘 것인지, 핵심 용량이 정상이라는 판단 아래 다음 작업을 진행할 것인지가 운영팀의 고민입니다. 아마존웹서비스(AWS)는 2026년 9월 4일 Amazon ECS 롤링 배포에 ‘Early Success Criteria’를 추가했습니다. 정상 작업의 비율을 정해 그 기준에 도달하면 배포를 성공으로 표시할 수 있는 기능입니다.
이 변화는 성공 기준을 느슨하게 만들자는 이야기가 아닙니다. 배포 완료와 서비스 전체 확장을 하나의 시각으로 묶던 방식을 나누자는 제안에 가깝습니다. 특히 GPU처럼 필요한 순간에 바로 확보하기 어려운 자원을 쓰는 AI 추론 서비스에서 의미가 큽니다.
배포 완료와 전체 확장의 분리
ECS에서 원하는 작업 수를 100개로 정하고 healthy percent를 90%로 설정했다고 가정해 보겠습니다. 새 리비전의 작업 90개가 실행되고 상태 검사까지 통과하면 ECS는 배포를 성공으로 처리합니다. 나머지 10개는 사라지는 것이 아니라 일반 서비스 스케일링 절차에서 계속 시작됩니다.
기존에는 목표 작업 전체가 준비될 때까지 배포 수명주기가 열려 있었습니다. 뒤에 기다리는 CI/CD 파이프라인이나 다음 배포도 함께 밀릴 수 있었습니다. 이제 운영팀은 사용자가 체감할 핵심 용량이 확보됐다는 판단과, 남은 용량을 채우는 작업을 분리할 수 있습니다.
희소한 GPU가 만든 긴 대기
일반 CPU 컨테이너는 비교적 빠르게 빈 자리를 찾지만, 특정 GPU 모델과 메모리 용량을 요구하는 작업은 상황이 다릅니다. 가용 영역에 필요한 장비가 부족하거나 노드를 새로 준비해야 하면 일부 작업만 오래 기다릴 수 있습니다. 정상 작업 90개로 트래픽을 감당할 수 있는데 마지막 10개 때문에 전체 배포가 멈춰 있는 장면이 생깁니다.
Early Success Criteria는 이 대기를 없애지 않습니다. 대기를 배포 실패로 취급할지, 확장 지연으로 관리할지를 운영자가 정하게 합니다. 따라서 기준 비율은 서비스의 여유 용량, 장애 시 트래픽 이동, 실제 GPU 확보 시간을 보고 정해야 합니다.
이전 버전을 치우는 두 방식
AWS는 이전 서비스 리비전을 정리하는 방식도 BLOCKING과 DEFERRED로 나눴습니다. BLOCKING은 예전 작업 정리가 끝날 때까지 성공 선언을 기다립니다. DEFERRED는 새 리비전이 기준을 넘으면 성공으로 표시하고, 연결이 길게 유지되는 예전 작업은 뒤에서 비동기로 비웁니다.
긴 연결이나 scale-in protection을 쓰는 서비스라면 DEFERRED가 파이프라인을 빨리 풀어줄 수 있습니다. 반대로 구버전과 신버전이 오래 함께 떠 있으면 비용과 관측 지표가 섞입니다. 어느 쪽이 좋은지는 속도보다 구버전을 얼마나 오래 허용할 수 있는지에 달렸습니다.
성공 표시 뒤에도 남는 감시
가장 중요한 한계는 성공 표시가 남은 작업의 성공을 보장하지 않는다는 점입니다. 90개에서 배포가 완료된 뒤 10개가 계속 뜨지 못하면, 배포 대시보드는 초록색이어도 서비스는 목표 용량에 못 미칩니다. 남은 작업의 pending 시간, 목표 대비 실제 작업 수, 오류율과 지연시간을 별도로 경보해야 합니다.
이 기능은 모든 AWS 상용 리전과 GovCloud에서 새 서비스와 기존 서비스에 적용할 수 있습니다. 빠른 배포는 결과이고, 핵심은 완료의 뜻을 운영 현실에 맞게 다시 정의한 데 있습니다. 기준을 낮추기 전에 “몇 퍼센트면 안전한가”를 숫자로 설명할 수 있어야 합니다.