엔터프라이즈 AWS 환경에서 가장 흔한 구조는 "Tooling 계정 하나 + 여러 Spoke 계정"이다. 개발, 스테이징, 프로덕션이 각각 별도 계정에 있고, 파이프라인은 중앙 Tooling 계정에서 실행된다. 이 구조는 보안 격리(Prod 계정에 개발자 콘솔 접근 없음), 비용 분리(각 계정별 청구), 폭발 반경 제한(Prod 계정의 침해가 Dev에 영향 없음)을 동시에 달성한다.
문제는 이 구조가 파이프라인 엔지니어에게 상당한 IAM/S3/KMS 설정을 요구한다는 점이다. 잘못 설정하면 "S3는 되는데 복호화가 안 된다", "AssumeRole이 안 된다", "배포는 됐는데 권한이 너무 넓다" 같은 문제가 생긴다. 오늘은 이 설정의 정확한 구조와 각 요소가 왜 필요한지를 파악한다.
💡 관련 이론: AWS의 보안 모델에서 계정(Account)은 가장 강력한 격리 경계다. IAM Policy는 같은 계정 내 Principal이 무엇을 할 수 있는지 정의하지만, 계정 경계를 넘는 행동에는 반드시 양방향 신뢰가 필요하다. A 계정의 Principal이 B 계정 리소스에 접근하려면 (1) A 계정 IAM Policy에서 해당 행동을 허용하고, (2) B 계정 리소스 정책에서 A 계정 Principal을 허용해야 한다—두 조건이 모두 AND로 충족되어야 한다. 이것이 Cross-Account의 근본 원리이며, 이 구조를 이해하지 못하면 4종 권한 체인 중 어느 하나를 빠뜨리게 된다.