서버 / 클라우드 소식 · 2026년 10월 19일 · CAT_000019
AWS Transform Azure→AWS 코드 변환 정식 출시: .NET 지원 범위와 이전 한계
AWS Transform이 공개한 Azure→AWS .NET 애플리케이션 코드 변환의 지원 서비스, Cosmos DB 프리뷰, 데이터·인프라 이전의 한계, 국내 실무 도입 체크리스트를 정리했습니다.
AWS Transform, 10월 16일 무엇이 출시됐나
2026년 10월 16일 AWS는 Azure SDK를 사용하는 클라우드 네이티브 .NET 애플리케이션 코드를 AWS SDK에 맞게 변경하는 AWS Transform 기능을 정식 발표했다. AWS Transform Azure AWS 코드 변환은 Azure에서 돌아가던 모든 시스템을 클릭 한 번으로 이전한다는 뜻이 아니다. 변환 대상은 지원 조건에 맞는 최신 .NET 애플리케이션의 소스 코드이며, 실제 데이터와 인프라 이전은 별도 프로젝트다.
AWS Transform .NET 현대화 에이전트는 제출한 소스 안에서 Azure 관련 서비스 코드를 찾아 평가 보고서와 변환 계획을 제안한다. 사용자가 대상을 조정하고 코드 변환을 실행하도록 안내하며, AWS는 변경이 생성된 코드에 반영됐는지 점검한다고 설명한다. 다만 검증한다는 표현을 실제 서비스 동작이나 보안성을 완전히 보장한다는 의미로 확대하면 안 된다.
AWS Transform 서울 리전 지원은 이번 기능의 발표 당시 가용 리전 여덟 곳에 서울(ap-northeast-2)이 포함됐다는 의미다. 다른 AWS Transform 기능까지 서울에서 동일하게 제공된다고 일반화할 수 없다. 최신 리전 문서는 계정과 기능을 실제 실행하기 전에 다시 확인해야 한다.
서비스별 지원 관계: GA와 프리뷰를 구분하자
Azure Functions Lambda 변환은 Azure Functions 기반 서버리스 함수 코드를 AWS Lambda 함수 코드로 재작성한다. 런타임, 바인딩, 인증, 트리거 동작 등 주변 조건은 애플리케이션별 재점검이 필요하며 자동 변환만으로 운영 환경 전환이 끝나는 것은 아니다.
Azure Blob Storage S3 변환은 Azure.Storage.Blobs SDK 사용 코드를 Amazon.S3 SDK 호출로 바꾸는 지원이다. 마찬가지로 Azure Queue Storage SQS 변환은 Azure.Storage.Queues 호출을 Amazon.SQS SDK 호출로 바꾸는 기능이다. 이는 API와 사용 방식의 차이를 반영하는 코드 작업이고, 기존 객체나 메시지를 물리적으로 옮기는 데이터 이동 작업과는 구분된다.
Azure Cosmos DB DynamoDB 프리뷰는 별도 주의가 필요하다. Cosmos DB SDK 호출을 DynamoDB SDK로 변환하는 기능은 발표 당시 프리뷰이며, 나머지 정식 출시 항목과 같은 수준의 일반 제공으로 표현해서는 안 된다. 데이터 모델, 쿼리 방식, 처리량 및 트랜잭션 차이에 대한 설계 검토는 여전히 필요하다.
이러한 AWS SDK Azure SDK 마이그레이션 기능은 공식 문서에 열거된 특정 Azure 서비스에 한정된다. 지원 목록 밖 SDK 또는 애플리케이션 기능은 개별 조사, 수동 수정, 다른 변환 도구가 필요할 수 있다.
Azure AWS 마이그레이션과 코드 자동 변환의 경계
Azure AWS 마이그레이션 프로젝트는 애플리케이션 코드, 네트워크, IAM 및 비밀정보, 컴퓨팅과 스토리지 리소스, 데이터 이전, 운영 절차 등 여러 영역으로 나뉜다. AWS Transform이 이번에 제공한 클라우드 코드 자동 변환은 이 중 애플리케이션 소스의 서비스 SDK 사용 부분을 지원하는 기능이다.
Azure AWS 데이터 마이그레이션 차이는 특히 중요하다. Blob Storage 코드를 S3 SDK로 바꿨다고 해서 컨테이너의 모든 객체가 S3 버킷으로 복제되지는 않는다. Cosmos DB 호출을 DynamoDB 대상으로 변환하더라도 원본 레코드가 자동으로 이전되거나 인덱스와 데이터 모델이 자동 최적화되는 것은 아니다.
따라서 운영 마이그레이션 계획에는 데이터 복제·검증, 대상 인프라 프로비저닝, 접근 통제, 네트워크 설계, 장애 복구, 롤백, 컷오버 작업을 별도로 기록해야 한다. 이번 기능을 인프라와 데이터까지 포함하는 완전 자동 클라우드 이전 도구라고 소개하는 것은 부정확하다.
평가와 현대화 계획, 실패한 코드 처리 방법
AWS Transform modernization plan은 소스 분석 결과를 바탕으로 어떤 Azure 서비스 코드를 변환할지 안내하는 계획이다. 팀은 SDK 호출과 변환 대상, 남은 리스크를 검토한 다음 계획을 수정할 수 있다. 에이전트 채팅 또는 계획 수정을 통해 AWS Transform 코드 변환 제외 대상을 지정하거나 일부 서비스를 대상으로 유지할 수도 있다.
AWS Transform 변환 실패 TODO는 공식 문서에서 설명하는 확인 신호다. 호환되는 AWS 코드로 전환되지 않은 부분은 TODO 주석, 임시 스텁, Next Steps 마크다운 파일 등으로 남을 수 있다. 이런 표시를 발견하면 성공 결과로 간주하지 않고 기능별로 해결 계획을 세운다.
코드가 생성된 후에는 먼저 빌드 및 패키지 호환성을 확인하고, SDK 인증·권한·오류 처리를 검토한다. 단위 및 통합 테스트, 외부 시스템 연동 검사, 데이터 일관성 검증, 부하와 비용 측정, 보안 점검은 실제 소스와 계정 환경에서 따로 수행해야 한다. 평가 보고서가 모두 통과했다고 운영 안정성을 보장할 수는 없다.
국내 개발팀을 위한 AWS Transform 도입 체크리스트
AWS Transform 도입 체크리스트의 출발점은 대상 애플리케이션 식별이다. 먼저 최신 .NET 기반인지, Azure Functions·Blob·Queue·Cosmos DB 관련 SDK를 어느 버전으로 사용하는지, 외부 패키지와 사내 공통 라이브러리가 호환되는지 점검한다. 대상 프로젝트에서 직접 호출이 없는 서비스나 지원되지 않는 프레임워크가 있다면 변환 범위를 축소하거나 별도 개발을 계획한다.
다음은 계정·보안·지역 및 운영 검토다. 서울 리전의 해당 기능 제공 여부를 최신 문서에서 재확인하고, 조직의 소스 코드 반출·접근 통제 규정과 분석 권한을 검토한다. AWS Transform 사용 비용과 AWS 서비스 운영 비용, 데이터 전송 및 병행운영 비용은 성격이 다르므로 견적 없이 총비용이나 절감률을 확정하면 안 된다.
마지막으로 실제 소스의 평가 결과를 기준으로 변환 대상과 제외 대상을 문서화하고 작은 비핵심 서비스에서 먼저 검증한다. 개발·보안·플랫폼·데이터 팀이 모두 승인한 뒤 데이터 마이그레이션 및 인프라 배포 계획과 연결해 확대하는 것이 합리적이다. 이 글은 실제 AWS 계정에서 변환 작업을 실행한 체험기가 아니라 공식 발표·가이드를 바탕으로 작성한 실무 분석이다.
자주 묻는 질문
모든 Azure 애플리케이션을 자동 이전하나요?
아닙니다. 공식적으로 지원되는 최신 .NET 애플리케이션의 일부 Azure 서비스 코드가 대상이고, 데이터와 인프라 이전은 별도입니다.
Cosmos DB 코드 변환도 정식 출시인가요?
아닙니다. 발표 당시 Cosmos DB→DynamoDB 부분은 프리뷰입니다.
서울에서 사용할 수 있나요?
2026년 10월 발표 당시 해당 AWS Transform 기능의 지원 리전에 서울이 포함됐습니다. 실제 사용 전 기능별 가용성을 확인해야 합니다.
변환 후 테스트가 필요하나요?
필요합니다. 빌드·기능·데이터·권한·보안·성능 검증은 실제 환경에서 별도로 수행해야 합니다.
출처·검증 기준
- AWS — AWS Transform announces Azure-to-AWS cloud-native code conversion
- AWS — Convert cloud-native code to AWS services
- AWS — Supported Regions for AWS Transform
- AWS — AWS Transform change log
2026년 10월 19일 기준 공식 발표와 문서에 근거했습니다. 고객별 요금·호환성과 실제 전환 성공률은 검증하지 않았습니다.
