[Cloud] 기존 인프라를 Pulumi로 전환하기: 마이그레이션 전략 및 체크리스트

목차

• Pulumi, 왜 도입해야 할까요? IaC 전환의 필요성
• 기존 인프라 Pulumi 마이그레이션 전략 및 체크리스트
• 1. 사전 준비 및 환경 설정 (Pre-requisites & Setup)
• 2. 리소스 임포트 전략 (Resource Import Strategy)
• 3. 코드 리팩토링 및 모듈화 (Code Refactoring & Modularization)
• 4. 테스트 및 검증 (Testing & Validation)
• ⚠️ Pulumi 마이그레이션 시 주의사항 및 삽질 경험
• 마이그레이션 완료 후 검증 및 관리
• 마이그레이션을 마치며: Pulumi와 함께 성장하기

안녕하세요, 13년차의 서버실 운영자입니다. 오늘은 많은 인프라 엔지니어분들이 한 번쯤 고민해봤을 주제, 기존 인프라를 Pulumi(풀루미)로 전환하는 마이그레이션 전략에 대해 이야기해보려고 해요.

혹시 지금도 수동으로 서버를 만들고, 설정 변경할 때마다 손으로 클릭하거나 스크립트를 돌리고 계신가요? 처음엔 괜찮았는데, 인프라가 커질수록 관리하기 너무 힘들잖아요. 저도 그랬거든요. 예전에는 직접 하나하나 다 세팅했었는데, 시간이 지나니 너무 비효율적이라는 걸 깨달았어요. 그러다 IaC(Infrastructure as Code, 코드형 인프라)에 관심을 가지게 되었고, 특히 Pulumi를 접하면서 기존 인프라를 코드로 관리하는 것에 매력을 느꼈습니다. 기존 인프라를 Pulumi로 마이그레이션(Migration)하는 과정이 쉽지는 않았지만, 그만큼 얻는 것이 많았기에 제 경험을 공유하고 싶었어요.

이 글을 통해 여러분의 Pulumi 도입과 IaC 전환에 도움이 될 만한 실질적인 전략과 마이그레이션 체크리스트를 함께 살펴보겠습니다. 삽질했던 경험도 솔직하게 풀어낼 테니, 비슷한 고민을 하고 계신다면 분명 도움이 될 거예요. 자, 그럼 시작해볼까요?

수동으로 관리되는 복잡한 인프라와 Pulumi로 코드화되어 정돈된 인프라의 개념적인 비교 다이어그램입니다.

Pulumi, 왜 도입해야 할까요? IaC 전환의 필요성

우선, Pulumi가 정확히 무엇이고 왜 우리가 굳이 기존 인프라를 Pulumi로 전환(Pulumi Migration)해야 하는지 간단하게 짚고 넘어가 볼까요?

Pulumi(풀루미)는 Python, TypeScript, Go, C# 같은 익숙한 프로그래밍 언어로 클라우드 인프라를 코드로 정의하고 배포할 수 있는 IaC(Infrastructure as Code, 코드형 인프라) 도구예요. 쉽게 말해, AWS EC2 인스턴스나 S3 버킷 같은 리소스들을 CLI(Command Line Interface)나 콘솔에서 직접 만드는 게 아니라, Python 스크립트처럼 코드로 작성해서 관리하는 거죠.

제가 처음 Pulumi를 써봤을 때 가장 인상 깊었던 건, 기존 프로그래밍 언어의 강점을 그대로 가져온다는 점이었어요. 조건문, 반복문, 함수 같은 일반적인 프로그래밍 로직을 인프라 코드에 적용할 수 있으니 훨씬 유연하고 강력하게 인프라를 관리할 수 있더라고요. Terraform(테라폼)도 훌륭한 IaC 도구지만, HCL(HashiCorp Configuration Language)이라는 자체 언어를 배워야 했거든요. Pulumi는 제가 이미 아는 언어로 인프라를 다룰 수 있다는 게 정말 큰 장점이었어요.

그럼 왜 IaC로 전환(IaC 전환)해야 할까요? 기존 인프라가 잘 돌아가고 있는데 굳이 건드려야 하나 싶을 수도 있어요. 하지만 IaC는 다음과 같은 명확한 이점을 제공합니다.

• 일관성(Consistency): 코드로 정의되니 휴먼 에러가 줄어들고, 항상 동일한 환경을 배포할 수 있어요.
• 반복 가능성(Repeatability): 개발, 스테이징, 프로덕션 환경을 똑같이 빠르게 구축할 수 있습니다.
• 버전 관리(Version Control): Git(깃) 같은 VCS(Version Control System)로 인프라 변경 이력을 추적하고, 필요하면 롤백(Rollback)도 가능해져요.
• 협업(Collaboration): 여러 엔지니어가 함께 인프라를 정의하고 검토할 수 있습니다.
• 재사용성(Reusability): 공통 모듈을 만들어 인프라 배포 시간을 단축할 수 있죠.

이런 장점들 때문에 기존 인프라를 인프라 코드화하는 건 이제 선택이 아닌 필수가 되어가고 있어요.

기존 인프라 Pulumi 마이그레이션 전략 및 체크리스트

자, 이제 본론으로 들어와서, 기존에 수동으로 구축된 인프라를 Pulumi로 마이그레이션(Migration)하는 구체적인 전략과 제가 직접 겪으면서 만들어 본 체크리스트(Checklist)를 공유해 드릴게요. 한 번에 모든 걸 바꾸려고 하면 대혼란이 올 수 있으니, 점진적인 접근이 중요합니다.

1. 사전 준비 및 환경 설정 (Pre-requisites & Setup)

가장 먼저 Pulumi를 사용할 환경을 구축해야겠죠? 제 경험상 이 단계에서 꼼꼼하게 준비해야 나중에 삽질을 줄일 수 있더라고요.

1. Pulumi CLI 설치: 운영체제에 맞는 Pulumi CLI를 설치합니다.

   curl -fsSL https://get.pulumi.com | sh

2. 클라우드 프로바이더 인증 설정: AWS, Azure, GCP 등 여러분이 사용하는 클라우드에 Pulumi가 접근할 수 있도록 인증 정보를 설정해야 합니다. 예를 들어 AWS의 경우, ~/.aws/credentials 파일이나 환경 변수를 통해 설정하죠.
3. 프로젝트 생성 및 초기화: Pulumi 프로젝트를 생성하고 사용할 언어를 선택합니다. 저는 주로 TypeScript나 Python을 사용하는데, 여기서는 Python을 예시로 들어볼게요.

   mkdir my-pulumi-infra
   cd my-pulumi-infra
   pulumi new python

   이 명령어를 실행하면 기본 템플릿 파일들이 생성됩니다.
4. 백엔드 상태 저장소 결정: Pulumi는 인프라의 상태(State)를 관리하는데, 이 상태 파일을 어디에 저장할지 결정해야 합니다. 기본적으로 Pulumi Service(클라우드)에 저장되지만, AWS S3나 Azure Blob Storage 같은 자체 스토리지를 사용할 수도 있습니다. 프로덕션 환경에서는 자체 스토리지를 권장해요.

2. 리소스 임포트 전략 (Resource Import Strategy)

기존 인프라를 Pulumi로 가져오는 가장 중요한 단계입니다. Pulumi는 이미 존재하는 리소스를 코드로 임포트(Import)하는 기능을 제공하는데, 이게 정말 유용하더라고요. 수동으로 하나하나 코드를 작성하는 것보다 훨씬 빠르고 정확합니다.

제가 해보니, 한 번에 모든 리소스를 임포트하는 것보다는 작은 단위로 쪼개서 임포트하는 것이 훨씬 안전하고 관리하기 편했습니다. 예를 들어 VPC(Virtual Private Cloud), 서브넷(Subnet), 보안 그룹(Security Group)부터 먼저 임포트하고, 그다음에 EC2 인스턴스, RDS(Relational Database Service) 데이터베이스 순으로 진행하는 식이죠.

1. 임포트할 리소스 식별: 마이그레이션할 인프라 리스트를 작성하고, 어떤 순서로 임포트할지 우선순위를 정합니다. 의존성(Dependency)이 낮은 리소스부터 시작하는 게 좋아요.
2. 임포트 대상 리소스 ID 확인: 클라우드 콘솔이나 CLI에서 각 리소스의 ID(또는 ARN)를 확인합니다. 이 ID는 임포트 명령에 필요해요.
3. Pulumi 임포트 코드 작성 및 실행: Pulumi는 pulumi import 명령어를 통해 기존 리소스를 가져올 수 있습니다.

# my_pulumi_infra/__main__.py 에 임포트할 리소스 코드를 먼저 작성합니다.
import pulumi_aws as aws

# 이 리소스는 아직 실제 AWS에 존재하지 않습니다.
# 임포트를 위해 임시로 코드를 작성하고, 실제 리소스 ID를 지정해야 합니다.
my_vpc = aws.ec2.Vpc("my-existing-vpc",
    cidr_block="10.0.0.0/16",
    # 기타 속성들은 실제 VPC의 속성과 일치시켜야 합니다.
    # 예를 들어, tags={ "Name": "my-existing-vpc" } 등
)

# 임포트 명령 실행 예시 (터미널에서)
# pulumi import aws:ec2/vpc:Vpc my-existing-vpc vpc-xxxxxxxxxxxxxxxxx
# 여기서 'vpc-xxxxxxxxxxxxxxxxx'는 실제 AWS VPC의 ID입니다.

pulumi import 명령을 실행하면 Pulumi가 해당 리소스의 현재 상태를 읽어와서 __main__.py 파일에 코드를 생성해 줍니다. 이 코드를 기반으로 Pulumi 스택(Stack)과 클라우드 리소스 간의 상태가 동기화되는 거죠. 이 과정에서 diff(차이점)를 잘 확인하는 게 중요해요.

Pulumi CLI를 이용해 기존 클라우드 리소스를 코드로 임포트하는 과정의 흐름을 보여주는 플로우차트입니다.

3. 코드 리팩토링 및 모듈화 (Code Refactoring & Modularization)

임포트된 코드는 보통 원시적인 형태입니다. 이걸 그대로 사용하는 것보다는 리팩토링(Refactoring)하고 모듈화(Modularization)하는 과정이 꼭 필요해요.

1. 하드코딩된 값 제거: IP 주소, 리소스 이름 등 하드코딩된 값들을 pulumi.Config나 변수로 분리하여 유연성을 높입니다.
2. 재사용 가능한 모듈 생성: VPC, 네트워크 구성, 공통 보안 그룹 등 여러 스택에서 재사용될 수 있는 부분은 별도의 모듈(예: Python 파일)로 분리합니다. 이렇게 하면 코드가 훨씬 깔끔해지고 유지보수가 쉬워집니다.

   # modules/network.py 예시
   import pulumi_aws as aws
   
   def create_vpc(name: str, cidr_block: str):
       vpc = aws.ec2.Vpc(name, cidr_block=cidr_block)
       # 서브넷, 인터넷 게이트웨이 등 추가 생성 로직
       return vpc
   
   # my_pulumi_infra/__main__.py 에서 사용
   # from .modules import network
   # my_vpc = network.create_vpc("my-app-vpc", "10.0.0.0/16")
   

3. Pulumi 컴포넌트 리소스 활용: 복잡한 인프라 패턴을 추상화하고 싶다면 Pulumi 컴포넌트 리소스(Component Resources)를 직접 만들어 사용하는 것도 좋은 방법입니다. 여러 개의 기본 리소스를 하나의 논리적인 단위로 묶을 수 있거든요.

4. 테스트 및 검증 (Testing & Validation)

코드 리팩토링 후에는 반드시 테스트(Testing)를 거쳐야 합니다. 특히 기존에 잘 운영되던 서비스에 영향을 주면 안 되니까요.

1. Dry Run (pulumi preview): pulumi preview 명령어를 통해 실제 변경 사항이 어떻게 적용될지 미리 확인합니다. 이 단계에서 예상치 못한 변경이 없는지 꼼꼼하게 검토해야 합니다. ⚠️
2. Staging 환경 배포: 프로덕션 환경에 바로 적용하기보다는, 최대한 프로덕션과 유사한 스테이징(Staging) 환경에 먼저 배포해보고 문제가 없는지 철저히 검증합니다.
3. 서비스 영향도 최소화: 마이그레이션 중 서비스 중단이 불가피하다면, 다운타임(Downtime)을 최소화할 수 있는 전략(예: Blue/Green Deployment, Canary Deployment)을 고려해야 합니다.

⚠️ Pulumi 마이그레이션 시 주의사항 및 삽질 경험

제가 13년간 인프라를 만져보면서 느낀 건데, 항상 계획대로만 되는 건 아니더라고요. Pulumi 마이그레이션(Migration) 과정에서도 예상치 못한 문제들이 발생했습니다. 몇 가지 주의사항(Caveats)과 제가 삽질(Troubleshooting)했던 경험을 공유해 드릴게요.

• 상태 불일치 (State Drift): 가장 흔한 문제 중 하나입니다. Pulumi가 관리하는 코드 상태와 실제 클라우드 리소스 상태가 달라지는 경우죠. 예를 들어, Pulumi 코드를 배포한 후에 누군가 수동으로 AWS 콘솔에서 보안 그룹 설정을 변경했다면, 다음 pulumi up 실행 시 Pulumi는 이 변경 사항을 되돌리려고 할 수 있습니다. 이걸 막으려면 Pulumi가 관리하는 리소스는 절대로 수동으로 변경하지 않도록 팀원들과 약속해야 합니다. 만약 상태 불일치가 발생하면, pulumi refresh 명령으로 현재 클라우드 상태를 읽어와 Pulumi 스택 상태를 업데이트하거나, pulumi state delete 후 다시 임포트하는 등의 방법을 사용해야 합니다.
• 의존성 문제 (Dependency Issues): 리소스 간의 의존성을 Pulumi가 정확히 파악하지 못해서 배포 순서가 꼬이는 경우가 가끔 있었습니다. 특히 복잡한 네트워크 구성에서 이런 문제가 발생하더라고요. 이럴 때는 depends_on 옵션을 명시적으로 사용해서 의존성을 지정해 주면 해결할 수 있습니다.

  my_resource_b = aws.some.ResourceB("my-resource-b",
      # ...
      opts=pulumi.ResourceOptions(depends_on=[my_resource_a])
  )
  

• 기존 리소스 삭제 위험: pulumi import를 잘못 사용하거나, 임포트 후 코드를 수정하는 과정에서 기존 리소스가 삭제될 수 있다는 경고를 보지 못하고 진행했던 적이 있어요. 😱 항상 pulumi preview 결과를 꼼꼼히 확인하고, 삭제(Delete) 또는 교체(Replace) 작업이 있다면 다시 한번 심사숙고해야 합니다. 특히 프로덕션 환경에서는 더욱 조심해야겠죠.
• 권한 문제: Pulumi CLI를 실행하는 계정이 필요한 클라우드 리소스에 대한 모든 권한을 가지고 있지 않아 배포가 실패하는 경우가 많았습니다. 특히 IAM(Identity and Access Management) 정책이 복잡할 때 자주 발생하더라고요. 최소한의 권한(Least Privilege) 원칙은 중요하지만, 마이그레이션 초기에는 필요한 권한을 충분히 부여하고, 안정화된 후에 점진적으로 줄여나가는 전략도 고려해 볼 만합니다.

이런 삽질들을 겪으면서 Pulumi 마이그레이션(Pulumi Migration)은 기술적인 부분만큼이나 프로세스(Process)와 팀원 간의 소통(Communication)이 중요하다는 걸 깨달았습니다. 항상 변경 사항을 공유하고, 리뷰하는 과정을 거치는 것이 중요해요.

마이그레이션 완료 후 검증 및 관리

성공적으로 Pulumi 마이그레이션(Pulumi Migration)을 마쳤다면, 이제 모든 것이 제대로 작동하는지 검증(Validation)해야 합니다. 그리고 앞으로 Pulumi로 관리되는 인프라를 어떻게 운영할지에 대한 계획도 세워야겠죠?

1. Pulumi 스택 상태 확인: pulumi stack ls, pulumi stack select <stack_name>, pulumi stack output 명령어를 통해 현재 스택의 상태와 배포된 리소스 정보를 확인합니다.
2. 클라우드 리소스 확인: 실제 클라우드 콘솔이나 CLI에서 Pulumi가 배포한 리소스들이 의도한 대로 생성되고 설정되었는지 다시 한번 확인합니다. 불필요한 리소스가 남아있지는 않은지도 확인해야 해요.
3. 모니터링 연동: 기존에 사용하던 모니터링 시스템(예: Prometheus, Grafana, CloudWatch)과 Pulumi로 배포된 리소스들이 제대로 연동되어 데이터를 수집하고 있는지 확인합니다.
4. CI/CD 파이프라인 구축: Pulumi 코드를 Git 저장소에 올리고, CI/CD(Continuous Integration/Continuous Delivery) 파이프라인을 구축하여 코드 변경 시 자동으로 pulumi preview, pulumi up이 실행되도록 자동화하는 것이 좋습니다. 제가 직접 해보니, 이렇게 자동화했을 때 인프라 배포 속도와 안정성이 엄청나게 향상되더라고요.

Pulumi를 통해 배포 및 관리되는 클라우드 리소스들의 현황을 한눈에 볼 수 있는 가상의 대시보드 화면입니다.

마이그레이션을 마치며: Pulumi와 함께 성장하기

지금까지 기존 인프라를 Pulumi로 전환(Pulumi 마이그레이션)하는 전략과 제가 겪었던 경험들을 공유해 드렸습니다. 처음에는 낯선 IaC 도구와 씨름하는 것이 쉽지 않게 느껴질 수 있어요. 저도 처음엔 기존 스크립트나 수동 작업에 익숙해서 '이걸 언제 다 코드로 바꾸나' 막막했었거든요. 하지만 한 번 전환하고 나니, 인프라 관리가 훨씬 수월해지고, 개발 생산성(Developer Productivity)도 눈에 띄게 좋아지는 걸 체감할 수 있었습니다.

Pulumi 도입(Pulumi 도입)은 단순히 도구 하나를 바꾸는 것을 넘어, 인프라를 바라보는 관점을 바꾸는 중요한 과정이라고 생각합니다. 코드로 인프라를 정의하고 관리함으로써, 우리는 더 예측 가능하고, 안정적이며, 확장 가능한 시스템을 구축할 수 있게 되죠. 인프라 코드화의 여정은 계속될 거예요.

이 글이 여러분의 Pulumi 마이그레이션(Pulumi 마이그레이션) 여정에 작은 도움이 되었기를 바랍니다. 다음번에는 Pulumi의 고급 기능이나 특정 클라우드 서비스 연동에 대해 더 깊이 파고들어 보는 시간을 가져볼게요. 혹시 궁금한 점이나 공유하고 싶은 삽질 경험이 있다면 언제든지 댓글로 남겨주세요! 저도 배우는 게 많을 겁니다. 🎉

Pulumi 로고와 함께 IaC, DevOps, 자동화, 클라우드 관리 등의 핵심 개념을 시각적으로 요약한 인포그래픽입니다.

📚 함께 읽으면 좋은 글

• Jenkins 빌드 실패 디버깅: 흔한 문제와 해결 전략 5가지
• Cloudflare Workers & R2 비용 최적화: 숨겨진 과금 피하는 실전 전략
• GitHub Actions 비용 폭탄 방지: 불필요한 과금 줄이는 실전 전략