pulumi awsx vs aws 비교: 무엇을 언제 쓸까

pulumi awsx vs aws를 고민하고 있다면, 결론부터 말씀드리면 두 패키지는 서로를 대체하는 경쟁 관계가 아니라 층위가 다른 도구입니다. aws는 AWS 리소스를 하나씩 그대로 정의하는 기반 패키지이고, awsx는 그 위에서 자주 쓰는 조합을 합리적인 기본값과 함께 묶어 주는 컴포넌트 모음이에요. 그래서 대부분의 운영 환경에서는 aws를 기준으로 삼고, 반복되는 패턴에만 awsx를 얹는 방식이 가장 안전합니다.

한눈에 보기

pulumi-aws(문서에서 AWS Classic이라고 부르는 패키지)는 Terraform AWS 프로바이더를 브리지한 패키지입니다. 그래서 Terraform에서 보던 리소스 타입과 인자 이름이 거의 그대로 대응되고, AWS 서비스 커버리지가 넓습니다. 대신 VPC와 서브넷, 라우팅 테이블, 보안 그룹, 로드 밸런서, ECS 서비스까지 직접 나열해야 하므로 코드가 길어지기 쉽습니다.

awsx(AWS Crosswalk)는 이 pulumi-aws 위에 올라가는 컴포넌트 라이브러리입니다. awsx.ec2.Vpc, awsx.lb.ApplicationLoadBalancer, awsx.ecs.Cluster, awsx.ecs.FargateService처럼 자주 쓰는 조합을 하나의 컴포넌트로 묶어 주고, 서브넷 배치나 보안 그룹 연결 같은 잡일을 대신 처리합니다. 즉 awsx는 aws를 감싸는 상위 계층이지, aws를 몰라도 되는 별도의 세계가 아닙니다.

정리하면 선택의 문제가 아니라 배치의 문제입니다. 아래에서 두 패키지의 관계를 먼저 이해하고, 그다음 상황별로 어디에 무엇을 쓸지 정리하겠습니다.

비교 표

항목	aws (AWS Classic)	awsx (AWS Crosswalk)
성격	Terraform AWS 프로바이더 기반 브리지 패키지	aws 위에 올라가는 컴포넌트 라이브러리
추상화 수준	리소스 단위, 인자를 그대로 노출	용도 단위, 조합을 미리 구성
커버리지	AWS 서비스 전반을 넓게 다룸	자주 쓰는 패턴 중심으로 범위가 한정됨
기본값	대부분 명시적으로 지정해야 함	합리적인 기본값이 미리 들어 있음
코드 분량	같은 구성을 만들 때 상대적으로 길어짐	표준 구성에서 짧고 읽기 쉬움
세밀한 제어	모든 인자를 직접 다룰 수 있음	노출된 옵션 밖은 하위 리소스로 내려가야 함
디버깅	리소스 하나하나가 그대로 보임	컴포넌트 내부 리소스를 따라가며 확인해야 함
적합한 대상	규제 대응, 세밀한 튜닝, 기존 인프라 이관	신규 서비스의 표준 구성, 빠른 프로토타이핑

두 패키지의 관계 이해하기

가장 중요한 사실은 awsx가 만드는 리소스도 결국 aws 리소스라는 점입니다. awsx의 VPC 컴포넌트를 쓰면 내부적으로 aws.ec2.Vpc, aws.ec2.Subnet, aws.ec2.RouteTable 같은 리소스가 생성되고, 이들은 모두 같은 스택 상태에 기록됩니다. 그래서 두 패키지를 한 프로그램에서 함께 import 해도 상태 관리나 배포 방식이 갈라지지 않습니다.

또 하나 중요한 점은 탈출구가 열려 있다는 것입니다. awsx 컴포넌트는 보통 자신이 만든 하위 리소스와 식별자를 속성으로 노출합니다. 예를 들어 VPC 컴포넌트에서 VPC 식별자나 서브넷 식별자를 꺼내 aws 리소스에 그대로 넘길 수 있습니다. 즉 awsx로 뼈대를 잡고, 컴포넌트가 노출하지 않는 세부 설정이 필요한 부분만 aws 리소스로 내려가서 채우는 혼합 방식이 자연스럽게 가능합니다.

반대 방향은 비용이 큽니다. aws로 세밀하게 만든 리소스를 나중에 awsx 컴포넌트로 교체하면, 컴포넌트가 기대하는 이름과 구성이 달라 리소스 교체가 발생할 수 있습니다. 그래서 방향은 "aws가 바닥, awsx가 그 위"라는 순서로 잡는 것이 좋습니다.

단계별로 선택하고 적용하는 방법

첫 단계는 요구사항을 리소스 목록이 아니라 제약 조건으로 정리하는 것입니다. 규제나 감사 요구로 서브넷 CIDR, 라우팅, 암호화 설정을 하나하나 문서화해야 한다면 aws를 기본으로 잡습니다. 반대로 "ECS에 컨테이너 올리고 앞단에 ALB 붙이기"처럼 목적이 분명하고 구성이 표준적이라면 awsx가 적합합니다.

두 번째 단계는 패키지를 함께 설치하고 역할을 나누는 것입니다. 프로그램에서 aws는 세밀한 제어가 필요한 리소스에, awsx는 표준 조합에 배분합니다. 예를 들어 네트워크와 ECS 클러스터, 로드 밸런서는 awsx로 만들고, 특수한 IAM 정책이나 WAF, DNS 레코드는 aws로 직접 정의하는 식입니다.

세 번째 단계는 스택을 환경별로 분리하는 것입니다. 개발 스택은 awsx 기본값으로 빠르게 띄우고, 운영 스택은 같은 코드에서 옵션만 조여 가는 방식이 관리하기 쉽습니다. 이때 환경별 차이는 코드 분기가 아니라 설정값으로 빼 두어야 합니다.

네 번째 단계는 pulumi preview로 실제 생성될 리소스 목록을 확인하는 것입니다. awsx는 컴포넌트 하나가 여러 리소스를 만들기 때문에, 프리뷰에서 어떤 리소스가 몇 개 생기는지, 교체(replace)가 표시되는지 반드시 확인해야 합니다. 특히 운영 스택에서는 교체 표시가 곧 다운타임 후보입니다.

다섯 번째 단계는 점진적 도입입니다. 기존에 aws로 작성한 코드가 있다면 한 번에 갈아엎지 말고, 새로 추가하는 서비스나 반복되는 패턴부터 awsx로 옮깁니다. 리소스 이름이나 별칭(alias) 전략을 미리 정해 두면 교체 없이 옮길 여지가 생깁니다.

상황별 선택 기준

상황	권장 방향	이유
신규 서비스의 표준 웹 구성	awsx 우선, 필요 부분만 aws	VPC·ALB·ECS 조합을 짧게 유지할 수 있음
Terraform 코드를 그대로 옮기는 작업	aws 우선	리소스 타입과 인자가 거의 일대일로 대응됨
보안·감사 요구가 강한 환경	aws 우선	모든 인자를 명시적으로 남길 수 있음
여러 팀이 같은 네트워크를 공유	네트워크는 aws, 워크로드는 awsx	공유 자원은 변경 이력을 촘촘히 남기는 편이 안전
빠른 검증용 임시 환경	awsx	기본값으로 빠르게 띄우고 버리기 쉬움

한 가지 덧붙이면, AWS 네이티브 API를 그대로 쓰는 별도 패키지도 존재합니다. 이름이 비슷해 헷갈리기 쉬운데, 이 패키지는 리소스 모델과 인자 체계가 aws와 다르므로 같은 기준으로 비교하지 않는 편이 좋습니다. 팀에서 이미 쓰는 패키지가 무엇인지부터 확인하세요.

주의할 점

가장 흔한 실수는 awsx의 기본값을 "공짜"라고 생각하는 것입니다. 기본값은 편의를 위한 것이지 비용이나 보안 요구까지 자동으로 맞춰 주지 않습니다. NAT 게이트웨이 구성, 가용 영역 배치, 로그 보존 같은 항목은 옵션으로 조정하고, 운영 스택에서는 명시적으로 값을 지정하는 편이 좋습니다.

두 번째는 커버리지 착각입니다. awsx는 모든 AWS 서비스를 감싸지 않습니다. 컴포넌트가 없는 영역은 자연스럽게 aws로 내려가야 하므로, 프로젝트 초기에 "이 서비스는 어느 쪽으로 다룰 것인가"를 표로 정리해 두면 나중에 혼란이 줄어듭니다.

세 번째는 리소스 교체 위험입니다. awsx 컴포넌트를 쓰다가 동일한 기능을 aws 리소스로 직접 구현하면, 같은 역할을 하는 리소스가 새 이름으로 생기면서 기존 리소스가 삭제될 수 있습니다. 반대로 aws로 만든 리소스를 awsx로 감싸는 경우도 마찬가지입니다. 전환 전에는 반드시 프리뷰에서 교체 여부를 확인하고, 필요한 경우 별칭이나 가져오기(import)를 검토하세요.

네 번째는 버전 고정입니다. 컴포넌트 라이브러리는 기본값이 바뀔 수 있으므로, 언어별 패키지 매니저에서 버전을 고정하고 업그레이드는 별도 작업으로 분리하는 편이 안전합니다. 업그레이드 후에는 프리뷰 결과를 이전과 비교해 예상치 못한 교체가 없는지 확인합니다.

다섯 번째는 상태 관리입니다. 두 패키지를 함께 써도 상태 백엔드는 하나입니다. 스택 단위로 권한과 잠금을 나누고, 운영 스택은 승인 절차를 거쳐 배포하도록 파이프라인을 구성해 두면 컴포넌트 사용 여부와 무관하게 사고를 줄일 수 있습니다.

자주 묻는 질문

awsx만으로 모든 AWS 리소스를 정의할 수 있나요?

그렇지 않습니다. awsx는 자주 쓰는 패턴을 묶은 컴포넌트 모음이라 커버 범위가 한정되어 있어요. 컴포넌트가 없는 서비스는 aws 패키지로 직접 정의해야 하며, 실무에서는 두 패키지를 함께 쓰는 구성이 일반적입니다.

aws와 awsx를 한 프로그램에서 같이 써도 되나요?

가능합니다. awsx는 aws를 기반으로 동작하고 두 패키지의 리소스가 같은 스택 상태에 기록되기 때문입니다. 오히려 표준 구성은 awsx로, 세밀한 제어가 필요한 부분은 aws로 나누는 혼합 방식이 유지보수에 유리한 경우가 많습니다.

awsx로 만든 리소스를 나중에 aws로 바꾸면 재생성이 일어나나요?

구성에 따라 다르지만 교체가 발생할 수 있습니다. 같은 역할을 하는 리소스를 다른 이름과 다른 구성으로 새로 정의하면 기존 리소스가 삭제 대상이 될 수 있으므로, 전환 전에 프리뷰로 교체 여부를 확인하고 별칭이나 가져오기를 함께 검토해야 합니다.

awsx를 쓰면 세밀한 설정을 포기해야 하나요?

그렇지 않습니다. 컴포넌트가 노출하는 옵션으로 조정할 수 있고, 노출되지 않는 부분은 하위 리소스에 접근해 aws 리소스로 보완할 수 있습니다. 다만 보완한 부분은 컴포넌트 기본값과 충돌하지 않는지 문서로 확인하는 습관이 필요합니다.

팀에 처음 도입한다면 어느 쪽부터 시작하는 것이 좋나요?

기존 인프라를 이관하는 팀이라면 aws부터 시작하는 편이 안전합니다. 반대로 새 서비스를 빠르게 만들어야 하는 팀이라면 awsx로 표준 구성을 잡고, 운영 요구가 구체화되는 지점에서 aws로 내려가는 순서가 현실적입니다.

출처

Pulumi AWS Classic 패키지 레퍼런스: https://www.pulumi.com/docs/reference/pkg/aws/
Pulumi AWSx 패키지 레퍼런스: https://www.pulumi.com/docs/reference/pkg/awsx/
Pulumi Registry AWSx 패키지 페이지: https://www.pulumi.com/registry/packages/awsx/
Pulumi 스택 개념 문서: https://www.pulumi.com/docs/iac/concepts/stacks/

배포 파이프라인과 스택 운영까지 함께 정리해 두고 싶다면, 스택과 상태 관리 개념을 다루는 운영 글을 함께 읽어 보시길 권합니다. 프리뷰 결과를 승인 게이트로 삼는 방식은 awsx와 aws를 함께 쓰는 구성에서도 동일하게 적용되므로, 패키지 선택과 별개로 팀의 배포 절차를 한 번 점검해 보세요. 관련 내용은 Pulumi 공식 문서의 스택 개념 정리(https://www.pulumi.com/docs/iac/concepts/stacks/)에서 확인할 수 있습니다.