우리는 AWS Amplify GraphQL 백엔드를 CDK로 (재작성 없이) 마이그레이션한 방법
Source: Dev.to
우리는 비즈니스 로직을 다시 작성하지 않고 Amplify에서 CDK로 이동했으며, 그 이유와 배운 점을 공유합니다.
Note: 이 글은 Amplify를 반대하는 글이 아닙니다. Amplify가 빛을 발하는 부분과 확장이 멈추는 부분을 이해하는 데 관한 것입니다.
Amplify가 잘 작동할 때
- 프로젝트 초기에 있습니다.
- 빠르고 스키마 기반 개발을 원합니다.
- Amplify가 관리하는 CloudFormation에 만족합니다.
- 세밀한 IAM이나 맞춤 파이프라인이 필요하지 않습니다.
우리는 시작 단계에서 바로 Amplify를 이렇게 사용했습니다. @model, @auth와 같은 디렉티브와 연결을 사용하여 Amplify가 다음을 생성했습니다:
- AppSync GraphQL API
- DynamoDB 테이블
- VTL 리졸버
- IAM 역할
- Lambda 데이터 소스(필요한 경우)
오랫동안 이것은 완벽하게 작동했습니다.
결국 마주하게 된 문제들
백엔드가 성장함에 따라 몇몇 문제들은 점점 무시하기 어려워졌습니다.
1. 제한된 제어와 가시성
Amplify는 많은 인프라를 추상화합니다:
- IAM 권한이 자동으로 생성됩니다.
- CloudFormation 스택이 숨겨져 있습니다.
- 리소스 명명이 불투명합니다.
이로 인해:
- 코드 리뷰가 더 어려워집니다
- 보안 리뷰가 고통스러워집니다
- 배포 디버깅이 어려워집니다
2. 어려운 다중 환경 및 플랫폼 통합
우리는 다음을 원했습니다:
- 명시적인 dev / staging / prod 환경
- 기존 CDK 기반 플랫폼과의 통합
- 예측 가능한 차이점 및 롤백
Amplify의 CLI 기반 워크플로우는 이러한 요구사항에 잘 맞지 않았습니다.
3. 강제적인 CloudFormation 확장 제한
AWS CloudFormation은 스택당 500개의 리소스라는 강제 제한을 적용합니다.
Amplify는 대부분의 GraphQL 백엔드를 하나(또는 매우 적은 수)의 스택에 배포합니다. 스키마가 커짐에 따라 생성된 리소스 수가 빠르게 해당 제한에 다가갑니다:
- 리졸버
- 함수
- IAM 역할 및 정책
- DynamoDB 테이블 및 GSI
500 리소스 제한에 근접하면:
- 배포가 취약해집니다
- 새로운 모델이나 리졸버를 추가하면 실패할 수 있습니다
- Amplify는 생성된 스택을 분할하거나 리팩터링할 수 있는 지원 방법을 제공하지 않습니다
그 시점에서 백엔드 진화는 사실상 중단됩니다.
Why We Didn’t Rewrite Everything
By the time we hit these limits we already had:
- A large GraphQL schema
- Custom VTL resolvers
- Lambda‑based business logic
- Production data in DynamoDB
A full rewrite would have been:
- Risky
- Time‑consuming
- Unnecessary
Instead we asked a different question:
What if Amplify was only used to generate the initial artifacts — and not to own the backend forever?
마이그레이션 단계
Step 1 – Amplify를 스캐폴딩 도구로 한 번만 사용
Amplify를 컴파일러처럼 다루고, CDK는 배포 엔진이 됩니다.
Amplify가 생성한 내용:
schema.graphql.vtl리졸버 템플릿- 빌드 산출물:
build/cloudformation-template.jsonbuild/stacks/*.jsonbuild/resolvers/*.vtl
- 리졸버에 내장된 인증 로직
이 단계에서는 Amplify가 제 역할을 잘 수행했습니다.
Step 2 – 지속 가능한 자산 추출
Amplify 백엔드 출력에서 지속 가능하고 가치 있는 것만 남겼습니다:
- GraphQL 스키마
- 리졸버 템플릿
- 테이블 정의
- 인증 규칙 및 로직
보관하지 않은 항목:
- Amplify CLI 파일
- Amplify Console 설정
- 자동 생성된 CloudFormation 스택
이들은 구현 세부 사항이며, 아키텍처가 아닙니다.
Step 3 – AWS CDK에서 명시적으로 재구축
Amplify가 생성한 각 리소스를 CDK에서 명시적으로 재구현했습니다. 이제 CDK가 담당합니다:
- AppSync API + 데이터 소스
- 함수 구성
- 파이프라인 리졸버
- IAM 역할 / 정책
- DynamoDB 테이블 (선택 사항)
- Lambda 데이터 소스 (선택 사항)
Amplify 스택을 직접 배포하는 대신, 의도를 CDK 코드로 추출하고 거기서 재배포했습니다. 이를 통해 Amplify “매직”을 제거하고 동작을 예측 가능하게 만들었습니다.
Step 4 – 백엔드를 여러 CDK 스택으로 분할
Amplify의 단일 스택과 달리, CDK를 사용하면:
- AppSync, DynamoDB, Lambda, IAM을 별도 스택으로 분리
- 리소스 경계 제어
- CloudFormation의 500‑리소스 제한을 완전히 회피
이 한 가지 변경만으로 장기적인 확장성 위험을 크게 줄였습니다.
Step 5 – 설정 기반, 환경 인식 설계
CLI 기반 설정을 다음으로 교체했습니다:
- YAML 기반 설정 파일
- 환경별 정의 (
dev,staging,prod) - 결정론적 네이밍
이제 cdk diff를 통해 검토 가능한 차이를 확인할 수 있습니다:
cdk diff -c env=staging
cdk deploy -c env=stagingCDK가 유일한 진실의 원천이 되었습니다.
Step 6 – Amplify 완전 제거
동등성을 확인한 후:
- Amplify 프로젝트 삭제
- Amplify Console 연결 해제
amplify push사용 중단
그 시점부터:
- 인프라 변경은 코드 리뷰를 거침
- 배포는 예측 가능함
- 스택 제한에 의해 더 이상 확장이 제한되지 않음
우리가 배운 것
- Amplify는 스캐폴딩에 탁월합니다.
- 대규모, 장기 운영 백엔드를 위해 설계된 것이 아닙니다.
- CloudFormation 500‑리소스 제한은 실제 제약입니다.
- 전체 재작성보다 마이그레이션이 더 안전합니다.
- 명시적인 CDK 소유권은 규모가 커질수록 빠르게 효과를 발휘합니다.
전체 설정을 원하나요?
우리는 이 접근 방식을 재사용 가능한 번들로 패키징했으며, 다음을 포함합니다:
- 프로덕션 수준의 CDK AppSync 백엔드
- 설정 기반 리졸버 및 Lambda 구현
- 예시 CI/CD 파이프라인
문제가 발생하면 자유롭게 이슈를 열거나 PR을 제출하세요!
bda wiring
- 마이그레이션 체크리스트 및 얻은 교훈
- 실제 사례 (장난감 데모가 아님)
👉 Gumroad:
Final Thoughts
This migration wasn’t about rejecting Amplify. It was about using the right tool at the right stage.
- Amplify helped us move fast early.
- CDK helped us move safely at scale.
If you’re approaching the same limits, there is a clean exit — without a rewrite.