pulumi aws native provider 이해와 선택 기준

pulumi aws native provider는 AWS Cloud Control API와 CloudFormation 리소스 스키마를 기반으로 AWS 리소스를 Pulumi 코드로 관리하는 선택지입니다. 기존 AWS provider를 무조건 대체하는 도구가 아니라, 리소스 커버리지와 생태계 성숙도를 비교해 선택해야 합니다. 이 글은 두 provider의 차이와 도입 절차, 운영 시 주의할 점을 정리해요.

한눈에 보기

AWS Native provider는 CloudFormation 스키마와 가까운 리소스 모델을 원할 때 검토할 수 있습니다. 반면 기존 AWS provider는 Pulumi 사용자에게 익숙한 리소스 모델과 풍부한 예제, 고수준 편의 기능을 제공하는 성숙한 선택지입니다.

핵심 판단 기준은 다음과 같아요.

새로 추가된 AWS 리소스를 빠르게 실험해야 한다면 AWS Native provider의 지원 범위를 먼저 확인합니다.
이미 기존 AWS provider로 운영 중인 스택이 크다면 무리한 전면 전환보다 신규 리소스나 별도 스택부터 검토합니다.
두 provider는 리소스 타입과 속성 구조가 달라서 같은 리소스를 한 스택에서 중복 관리하지 않도록 경계를 정해야 합니다.
마이그레이션은 코드 변환 작업이 아니라 상태와 운영 책임을 옮기는 작업으로 다뤄야 합니다.

AWS Native provider란 무엇인가요?

Pulumi의 AWS Native provider는 AWS Cloud Control API를 기반으로 AWS 리소스를 노출합니다. Cloud Control API는 AWS 리소스를 일관된 방식으로 생성·조회·수정·삭제할 수 있게 해주는 AWS의 인터페이스이고, Pulumi는 이 위에서 동작하는 provider를 제공합니다. 공식 레지스트리에서는 AWS Native provider를 CloudFormation 리소스 스키마에서 생성된 Pulumi SDK로 설명합니다.

이 구조 때문에 AWS Native provider의 리소스 정의는 CloudFormation의 속성 이름과 구조를 따르는 경우가 많습니다. 예를 들어 기존 AWS provider에서 익숙하게 쓰던 리소스 타입과 AWS Native provider의 리소스 타입은 이름부터 다를 수 있습니다. 같은 AWS 서비스라도 코드에서 참조하는 패키지와 속성 이름이 달라지는 것이죠.

Pulumi 코드에서는 aws-native 패키지로 시작하는 리소스 타입을 사용합니다. 기존 AWS provider가 aws 패키지로 시작하는 것과 구분됩니다. 따라서 기존 코드를 기계적으로 문자열 치환하는 방식은 위험하고, 리소스 단위로 속성과 출력값을 비교해야 합니다.

AWS Native provider의 장점은 CloudFormation 스키마와 Cloud Control API가 다루는 범위 안에서 AWS 리소스를 비교적 직접적으로 표현할 수 있다는 점입니다. 반대로 Cloud Control API가 지원하지 않는 리소스는 AWS Native provider로 관리할 수 없거나 제약이 생길 수 있습니다. 이 점이 기존 AWS provider와의 가장 중요한 차이입니다.

기존 AWS provider와 비교

항목	AWS Native provider	기존 AWS provider
기반	AWS Cloud Control API와 CloudFormation 리소스 스키마	Pulumi AWS provider의 기존 리소스 모델
리소스 표면	CloudFormation 속성 이름과 구조를 따르는 경우가 많음	Pulumi 사용자에게 익숙한 리소스와 옵션
신규 기능 반영	Cloud Control API가 지원하는 범위에서 비교적 빠르게 노출	provider 릴리스에 따라 반영
고수준 편의 기능	상대적으로 단순한 편	상대적으로 풍부한 편
생태계와 예제	상대적으로 적은 편	상대적으로 많은 편
적합한 경우	CloudFormation 스키마 중심의 정의, 신규 리소스 실험	기존 코드 유지, 안정적인 운영, 익숙한 패턴

표에서 중요한 것은 우열이 아니라 적합성입니다. AWS Native provider가 항상 더 낫거나 기존 AWS provider가 항상 더 안전한 것이 아닙니다. 현재 스택의 리소스 종류, 팀이 익숙한 속성 이름, 배포 자동화와 정책 검사 방식에 따라 선택이 달라집니다.

특히 기존 AWS provider에는 Pulumi 생태계에서 오래 사용된 예제와 패턴이 많습니다. AWS Native provider는 상대적으로 새로운 편이므로, 운영에 필요한 리소스가 실제로 지원되는지 먼저 확인하는 절차가 필요합니다.

도입 전 확인할 선택 기준

첫째, 리소스 커버리지를 확인해야 합니다. 운영 중인 AWS 리소스가 AWS Native provider에서 제공되는지, 제공된다면 필요한 속성이 모두 노출되는지 확인합니다. CloudFormation 스키마에 없는 동작이나 Cloud Control API가 지원하지 않는 리소스는 별도 provider나 다른 자동화 수단이 필요할 수 있습니다.

둘째, 속성 이름과 출력값을 비교해야 합니다. 기존 AWS provider의 리소스와 AWS Native provider의 리소스는 이름이 비슷해도 속성 구조가 다를 수 있습니다. 보안 그룹, IAM 정책, 태그, 암호화 설정처럼 운영 정책과 맞닿은 속성은 특히 꼼꼼히 비교해야 합니다.

셋째, 상태 관리 주체를 정해야 합니다. 같은 AWS 리소스를 기존 AWS provider와 AWS Native provider가 동시에 관리하면 배포할 때마다 서로 다른 속성을 덮어쓰는 문제가 생길 수 있습니다. 리소스별로 어느 provider가 책임지는지 명확히 나누는 것이 안전합니다.

넷째, 팀의 운영 경험을 고려해야 합니다. 기존 AWS provider에 익숙한 팀이라면 AWS Native provider 도입은 단순한 패키지 교체가 아니라 새로운 리소스 모델 학습에 가깝습니다. 반대로 CloudFormation 스키마에 익숙한 팀이라면 AWS Native provider가 더 자연스럽게 느껴질 수 있습니다.

단계별 도입 방법

현재 스택의 리소스 인벤토리를 만듭니다. 어떤 리소스를 기존 AWS provider가 관리하는지, 출력값을 다른 스택이 참조하는지, 배포 정책이 어디에 걸려 있는지 정리합니다.
별도의 샌드박스 스택에서 AWS Native provider를 추가합니다. 운영 스택을 바로 바꾸지 않고, 리전과 자격 증명, 상태 백엔드가 정상적으로 동작하는지 먼저 확인합니다.
작은 리소스부터 AWS Native provider로 정의해 봅니다. 버킷이나 로그 그룹처럼 경계가 명확한 리소스로 시작하면 속성 차이와 출력값 차이를 비교하기 쉽습니다.
pulumi preview로 변경 계획을 확인합니다. 기존 리소스를 교체하려는 계획이 나오는지, 삭제와 재생성이 필요한지 반드시 확인해야 합니다.
기존 리소스를 AWS Native provider로 가져오는 실험은 운영 스택과 분리합니다. 가져오기 후에는 실제 AWS 설정과 Pulumi 상태가 일치하는지 확인하고, 불필요한 교체가 없는지 검토합니다.
마이그레이션 범위를 정합니다. 신규 리소스만 AWS Native provider로 만들지, 기존 리소스 일부를 옮길지, 두 provider를 스택 단위로 나눌지 결정합니다. 한 번에 전체를 옮기는 방식은 피하는 편이 좋습니다.

상황별 선택 가이드

신규 서비스를 작은 단위로 시작하고 CloudFormation 스키마에 익숙하다면 AWS Native provider를 먼저 검토할 수 있습니다. 리소스 정의가 CloudFormation과 가까워서 속성을 이해하기 쉽고, Cloud Control API가 지원하는 신규 리소스를 실험하기에도 적합합니다.

이미 기존 AWS provider로 운영 중인 스택이 크고, 다른 팀이 출력값을 참조하거나 배포 정책이 복잡하게 얽혀 있다면 기존 provider를 유지하는 편이 안전합니다. 전환 비용보다 운영 중단 위험이 더 클 수 있기 때문입니다.

신규 AWS 기능을 빠르게 써야 하는 경우에는 AWS Native provider의 지원 여부를 확인합니다. 다만 지원된다는 사실과 운영에 필요한 모든 속성이 제공된다는 사실은 다를 수 있으므로, 공식 레지스트리에서 리소스와 속성을 직접 확인해야 합니다.

두 provider를 함께 써야 한다면 스택 경계를 나누는 방식이 좋습니다. 네트워크와 공통 정책은 기존 provider가 관리하고, 신규 실험 리소스는 AWS Native provider 스택이 관리하는 식으로 책임을 분리합니다. 같은 리소스를 양쪽에서 관리하지 않도록 주의해야 합니다.

주의할 점

AWS Native provider는 기존 AWS provider의 단순한 상위 호환이 아닙니다. 리소스 타입, 속성 이름, 출력값, 일부 동작이 다를 수 있으므로 기존 코드를 그대로 옮기면 예상하지 못한 교체가 발생할 수 있습니다.

Cloud Control API가 지원하는 범위 밖의 리소스는 AWS Native provider로 관리할 수 없습니다. 운영에 꼭 필요한 리소스가 있다면 대체 수단을 먼저 정하고, provider를 섞을 때 상태 충돌이 없도록 해야 합니다.

리소스의 이름 자동 생성이나 고수준 편의 기능을 많이 사용하는 스택은 기존 AWS provider가 더 편할 수 있습니다. AWS Native provider로 옮길 때는 이름과 태그, 정책이 그대로 유지되는지 확인해야 합니다.

배포 전에는 항상 변경 계획을 확인해야 합니다. 특히 삭제와 재생성이 필요한 변경은 데이터 손실로 이어질 수 있으므로, 운영 환경에서는 별도 승인 절차와 백업 계획을 함께 두는 것이 좋습니다.

자주 묻는 질문

AWS Native provider는 기존 AWS provider를 대체하나요?

대체제라기보다 선택지입니다. 기존 AWS provider는 성숙한 리소스 모델과 풍부한 예제를 제공하고, AWS Native provider는 Cloud Control API와 CloudFormation 스키마에 가까운 접근을 제공합니다. 따라서 스택의 규모와 리소스 지원 범위를 보고 선택해야 합니다.

어떤 경우 AWS Native provider를 먼저 검토하면 좋나요?

CloudFormation 스키마와 비슷한 속성 정의가 필요하거나, Cloud Control API가 지원하는 신규 리소스를 빠르게 실험하고 싶을 때 검토할 수 있습니다. 다만 운영에 필요한 리소스와 속성이 모두 제공되는지 공식 문서에서 먼저 확인해야 합니다.

두 provider를 한 스택에서 함께 쓸 수 있나요?

기술적으로는 provider를 함께 구성할 수 있지만, 같은 리소스를 양쪽에서 관리하지 않도록 경계를 정해야 합니다. 리소스 소유권이 불명확하면 배포할 때마다 설정이 덮어써질 수 있으므로 스택이나 리소스 단위로 책임을 분리하는 편이 안전합니다.

마이그레이션은 한 번에 하는 것이 좋나요?

한 번에 전체를 옮기는 방식은 권장되지 않습니다. 작은 리소스부터 별도 스택에서 검증하고, 변경 계획과 상태를 확인한 뒤 범위를 넓히는 방식이 운영 위험을 줄이는 데 도움이 됩니다.

출처

관련 운영 글은 Pulumi 스택 상태와 배포 운영 체크리스트에서 상태 백엔드와 배포 경계를 이어서 점검해 볼 수 있습니다.