CI/CD 시스템에서 AWS 자격 증명을 안전하게 다루는 일은 지난 10년간 거의 모든 DevOps 팀의 만성 두통이었다. IAM User access key를 GitHub Secrets에 박아두는 패턴은 익숙하지만, 그 익숙함이 곧 사고의 근원이다. Snyk가 2022년에 발표한 보고서에 따르면 GitHub 공개 저장소에서 발견된 AWS access key는 한 해 동안 1만 건이 넘었다. Capital One의 2019년 사고도, 2023년 Twitter의 내부 키 유출도, 그 근본 원인은 같다 — "한 번 발급되어 누가 어디에 복사했는지 모르는 정적 자격 증명".
OIDC 페더레이션은 이 문제를 근본적으로 다른 방향에서 해결한다. 자격 증명을 발급하지 않는다. 대신 GitHub이 매 워크플로 실행마다 자기 정체를 증명하는 단기 JWT를 만들어주고, AWS STS가 그걸 검증해 1시간짜리 임시 자격 증명을 발급한다. 정적 키 자체가 존재하지 않으니 누출될 키도 없다.
오늘은 이 메커니즘이 어떻게 동작하는지, IAM Trust Policy의 어떤 조건이 보안을 결정하는지, GitHub Environments와 어떻게 결합해 이중 방어를 만드는지, 그리고 Self-hosted Runner / CodeBuild와 어떤 trade-off가 있는지를 정리한다.