CloudFormation으로 Lambda 하나를 띄워본 사람은 알 것이다. 함수 한 개를 만들려고 AWS::Lambda::Function, AWS::IAM::Role, AWS::IAM::Policy, AWS::Lambda::Permission, AWS::Lambda::EventSourceMapping, AWS::ApiGateway::* 6종 세트가 줄줄이 따라온다. 단순한 "주문 조회 API" 하나가 200줄짜리 YAML이 된다. 이 보일러플레이트의 무게가 2016년 AWS re:Invent에서 SAM(Serverless Application Model)이라는 이름으로 정식 발표된 배경이다. SAM은 새로운 IaC 도구가 아니다. CloudFormation의 Transform(매크로) 위에 얹은 서버리스 친화 DSL이고, 배포 시점에 평범한 CloudFormation으로 풀어진다.
오늘은 SAM이 왜 CloudFormation의 한 줄(Transform:) 위에 설계됐는지, sam local의 Docker 에뮬레이션이 실제로 어디까지 신뢰할 수 있는지, sam sync의 hotswap이 프로덕션에서 왜 위험한지를 본다. DOP 시험에서 SAM은 단독으로 묻기보다 "CodePipeline + CodeDeploy + Lambda Canary"의 한 가운데 끼어 출제되므로, 도구의 내부 동작을 알아두면 5~10문제가 한꺼번에 풀린다.