Pinterest가 자체 Terraform 실행 엔진을 만든 이유
대규모 클라우드 인프라를 운영하는 조직에서 Terraform은 사실상 표준 IaC(Infrastructure as Code) 도구로 자리잡았다. 하지만 팀 규모가 커지고 AWS 리소스가 수백, 수천 개로 늘어날수록 "누가, 언제, 어떤 변경을 적용했는가"를 추적하고 통제하는 일은 점점 복잡해진다. Pinterest는 이 문제를 해결하기 위해 **Resource Provisioner Pipeline(RPP)**이라는 자체 Terraform 실행 엔진을 구축했다.
기존의 일반적인 접근 방식에서는 개발자나 인프라 엔지니어가 로컬 환경이나 CI 파이프라인에서 직접 terraform apply를 실행하는 경우가 많다. 이 방식은 운영 초기에는 편리하지만, 권한이 과도하게 부여된 IAM 역할이 사용되거나, 변경 사항이 충분한 검토 없이 프로덕션에 반영되는 위험이 내재되어 있다.
RPP의 핵심 설계 원칙: 최소 권한과 이중 검토
RPP가 도입한 가장 중요한 두 가지 원칙은 **최소 권한 원칙(Least-Privilege Access)**과 **이중 검토(Dual-Control Review)**다.
최소 권한 원칙을 강제한다는 것은, 파이프라인이 특정 리소스 변경에 필요한 최소한의 IAM 권한만을 동적으로 획득하도록 설계되었다는 의미다. 엔지니어 개인이 넓은 범위의 권한을 가진 자격증명을 직접 다루는 구조를 제거함으로써, 자격증명 노출이나 실수로 인한 광범위한 피해를 원천적으로 차단한다.
이중 검토는 인프라 변경이 단 한 명의 승인만으로 프로덕션에 반영될 수 없도록 강제하는 장치다. GitHub Actions 워크플로우와 통합된 중앙집중형 파이프라인 내에서, 변경 요청은 반드시 복수의 검토자를 거쳐야 실행 단계로 진입한다. 이는 금융권에서 흔히 요구되는 4-eyes principle을 인프라 레벨에서 구현한 것과 같다.
# GitHub Actions 워크플로우 예시 (개념적 구조)
jobs:
terraform-plan:
runs-on: ubuntu-latest
steps:
- name: Assume Scoped IAM Role
uses: aws-actions/configure-aws-credentials@v2
with:
role-to-assume: arn:aws:iam::ACCOUNT_ID:role/rpp-scoped-role
terraform-apply:
needs: [terraform-plan, dual-review-gate]
if: ${{ needs.dual-review-gate.outputs.approved == 'true' }}
runs-on: ubuntu-latest
중앙집중형 파이프라인이 가져오는 실무적 이점
RPP처럼 중앙집중형 실행 엔진을 도입하면 단순한 보안 강화 이상의 운영 효과가 발생한다.
- 감사 추적(Audit Trail) 일원화: 모든
plan과apply실행 기록이 단일 파이프라인을 통해 남기 때문에, 컴플라이언스 감사나 장애 원인 분석 시 변경 이력 조회가 단순해진다. - 드리프트 방지: 로컬에서의 임의
apply실행이 구조적으로 차단되므로, 실제 인프라 상태와 코드 상태가 괴리되는 configuration drift 문제를 줄일 수 있다. - 온보딩 일관성: 새로운 팀원이 합류해도 동일한 파이프라인을 통해 인프라를 다루기 때문에, 개인별 환경 차이로 인한 사고 위험이 낮아진다.
- 정책 코드화: 어떤 리소스 유형에 어떤 태그가 필수인지, 특정 리전 외 배포를 금지하는 등의 조직 정책을 파이프라인 레벨에서 코드로 강제할 수 있다.
4년차 이상의 백엔드 엔지니어라면 서비스 코드 품질만큼 인프라 변경 프로세스의 신뢰성에도 책임감을 가져야 한다. 특히 AWS 리소스가 팀 단위로 분산 관리되는 조직에서는, RPP와 같은 중앙 파이프라인 도입이 보안 사고와 운영 부채를 동시에 줄이는 현실적인 해법이 된다.
정리
- Pinterest의 RPP는 최소 권한 원칙과 이중 검토를 파이프라인 레벨에서 강제하여, 대규모 AWS 인프라 변경의 보안 가드레일을 구현했다.
- GitHub Actions와 통합된 중앙집중형 실행 엔진은 감사 추적 일원화, configuration drift 방지, 정책 코드화라는 운영 이점을 함께 제공한다.
- 로컬
terraform apply를 허용하는 분산 관리 구조는 팀 규모 확장 시 보안·운영 리스크가 급격히 높아지므로, 파이프라인을 통한 통제 구조로의 전환을 적극 검토할 필요가 있다.