CloudFormation을 6개월 정도 쓰다 보면 누구나 같은 벽에 부딪힌다. "Slack 채널을 자동 생성하고 싶은데 AWS::Slack::Channel이 없네", "GitHub Repo에 webhook을 등록하고 싶은데 CFN 리소스가 없네", "신규 출시된 AWS 서비스가 아직 CFN에서 지원 안 되네." 이 빈틈을 메우려고 2015년에 도입된 게 Custom Resource고, 그 위에 2021년 출시된 게 변경 사전 검증 메커니즘인 CloudFormation Hooks다. 두 도구는 표면적으로 다른 일을 하지만 본질적으로 같은 철학을 공유한다 — CloudFormation을 폐쇄된 리소스 집합에서 확장 가능한 워크플로 엔진으로 만든다는 것.
오늘은 Custom Resource Lambda의 ResponseURL이 왜 그렇게 설계됐는지, PhysicalResourceId가 라이프사이클의 키가 되는 이유, CDK Provider 프레임워크가 isComplete 패턴으로 장시간 작업을 어떻게 다루는지, CloudFormation Hooks가 OPA/Gatekeeper와 어떻게 닮았는지, 그리고 Change Set이 CI/CD에서 manual approval과 어떻게 결합되는지를 본다. 시험에서는 Custom Resource의 "응답 안 보내면 1시간 timeout" 같은 디테일이 자주 출제되므로 내부 동작을 정확히 알아둘 가치가 있다.