처음 Beanstalk 콘솔에서 "Deployment policy"를 골라야 할 때 다섯 개 선택지가 동등해 보인다. All at once, Rolling, Rolling with additional batch, Immutable, Blue-Green. 이름은 비슷한데 운영자의 새벽잠과 회사 카드값을 결정하는 차이가 그 안에 들어 있다. 어떤 걸 고르냐에 따라 5분 다운타임이 생기기도 하고, 30분짜리 배포가 비용 2배로 돌기도 하고, 알람 한 번에 즉시 롤백되기도 한다.
이 글에서는 Beanstalk이라는 PaaS가 왜 EC2/ALB/ASG를 굳이 고객 계정에 만들어주는 방식으로 설계됐는지부터 시작해, 다섯 정책의 trade-off를 시간·비용·다운타임·롤백 4축으로 본다. 시험을 위한 표 암기가 아니라 "이번 릴리스에 어떤 정책이 맞는가"를 운영자처럼 결정할 수 있는 감각을 얹는 것이 목표다.
Beanstalk을 단순히 "Heroku의 AWS 버전"으로 이해하면 절반만 본 것이다. 2011년 1월 출시 당시 AWS는 이미 EC2·RDS·ELB·SQS를 따로 팔고 있었고, 개발자들은 "이걸 일일이 콘솔에서 클릭해 묶는 게 너무 힘들다"고 불평했다. Heroku(2007)와 Google App Engine(2008)이 PaaS 시장을 휩쓸던 시기였다