AWS Transform Azure .NET 변환: 자동 변환과 수동 이전 범위 구분

Quick Answer
Azure .NET 앱을 AWS로 옮길 때 자동 변환되는 코드와 사람이 맡을 이전 작업을 어떻게 나누나요?
AWS Transform의 Azure .NET 자동 변환 범위는 지원 서비스의 SDK 호출과 애플리케이션 코드입니다. 클라우드 인프라 이전은 포함되지 않으며, 코드가 바뀌었다고 데이터·권한·운영 서비스까지 이전된 것은 아닙니다. Azure Functions·Blob Storage·Queue Storage 변환은 정식 제공 범위이고 Cosmos DB→DynamoDB는 프리뷰입니다. 평가 보고서·현대화 계획과 TODO·stub·Next Steps를 확인해 남은 업무를 나눠야 합니다.
Reading Guide
이 글에서 해결할 문제
- 이런 분께
- Azure .NET 이전의 자동화 범위와 수동 업무를 나눠 일정·견적을 잡으려는 개발 리드·기획자
- 읽고 나면
- 평가·계획·diff·남은 작업을 대조하고 코드·인프라·데이터·권한별 담당 업무와 완료 증거를 정할 수 있습니다.
- 다루는 범위
- 공식 지원 범위 분석·로컬 합성 객체 파일 3개의 해시 기준값입니다. AWS 변환·배포·데이터 이전·권한 검증은 미실행입니다.
- 직접 확인
- 앱 적격 조건·서비스별 정식 제공과 프리뷰·사용 경험·리전을 확인합니다.
- 평가·현대화 계획·diff·TODO·stub·Next Steps에서 남은 업무를 분류합니다.
- 코드·인프라·데이터·접근 권한의 완료 증거와 담당자를 각각 기록합니다.
필요한 곳부터 보기: 서비스별 변환 범위 · 평가 보고서 확인 · 네 가지 완료 기준 · TODO·남은 작업 검토
자동 변환 대상은 네 가지이며 Cosmos DB는 프리뷰입니다
AWS는 2026년 10월 16일 AWS Transform의 Azure SDK→AWS SDK 애플리케이션 코드 변환 정식 제공을 발표했습니다. 발표는 아래 세 서비스와 Cosmos DB 프리뷰를 구분합니다. 정식 제공이라는 제목만 읽고 네 가지 모두 같은 상태라고 판단하지 마세요. AWS 정식 제공 발표
| Azure 코드 | 대응 AWS 코드 | 발표 시점 상태 |
|---|---|---|
| Azure Functions | AWS Lambda | 정식 제공 범위 |
| Azure Blob Storage | Amazon S3 | 정식 제공 범위 |
| Azure Queue Storage | Amazon SQS | 정식 제공 범위 |
| Azure Cosmos DB | Amazon DynamoDB | 프리뷰 |
공식 변환 문서의 SDK 대응에는 Azure.Storage.Blobs → Amazon.S3, Azure.Storage.Queues → Amazon.SQS, Microsoft.Azure.Cosmos → Amazon.DynamoDBv2가 제시돼 있습니다. 이는 코드 변환 대상에 관한 설명입니다. 실제 버킷·큐·테이블 생성이나 기존 데이터 복사를 완료했다는 증거로 사용할 수는 없습니다. Azure 서비스별 코드 변환 범위
Azure Repos 연결과 Azure 서비스 코드 변환은 다른 기능입니다
Azure Repos는 소스가 보관된 저장소이고, Azure Functions·Blob Storage 등은 앱이 실행 중에 사용하는 서비스입니다. 저장소 연결이 성공했다는 사실만으로 앱의 Azure 서비스 호출까지 변환됐다고 판단할 수 없습니다.
AWS는 이미 2025년 8월 26일 Azure DevOps Repos와 Azure Artifacts의 NuGet 패키지 연결 지원을 발표했습니다. 이번 2026년 10월 소식은 지원 Azure 서비스의 코드를 AWS 서비스 코드로 바꾸는 기능입니다. 이전 자료를 찾을 때도 저장소 연결 안내인지 서비스 코드 변환 안내인지 먼저 구분하세요. 기존 Azure Repos·Artifacts 연결 발표
대상 앱·사용 경험·리전 조건을 먼저 기록하세요
Azure 변환 문서는 조건에 맞는 modern .NET 애플리케이션을 대상으로 설명합니다. AWS Transform for .NET 전체 지원표에는 .NET 8·.NET 10 등으로의 현대화가 안내돼 있지만, 그 일반 지원표가 모든 Azure SDK 호출의 변환을 보장하지는 않습니다. 앱의 프레임워크·프로젝트 유형·NuGet 의존성과 실제 Azure 사용 부분을 평가해야 합니다. .NET 현대화 지원 조건·제한
웹·Visual Studio 등 현재 이용하는 경험과 도구 버전도 남깁니다. 사용 경험에 따라 제공되는 에이전트와 검토 절차가 다를 수 있습니다. 예를 들어 공식 사전 점검 문서는 새 .NET 대화형 에이전트의 IDE·MCP 제공과 웹 콘솔 제공 상태를 구분합니다. 사용 중인 화면에서 해당 변환 옵션이 실제로 제안되는지 확인하세요. 변환 전 경험·도구·검증 계획 점검
10월 16일 발표가 안내한 지원 리전은 버지니아 북부, 뭄바이, 도쿄, 서울, 시드니, 캐나다 중부, 프랑크푸르트, 런던의 8개입니다. 이는 발표 시점의 서비스 제공 지역입니다. 실제 계정의 접근·작업 생성 조건과 앱을 운영할 대상 리전은 별도로 확인해야 합니다.
1. 평가 보고서에서 변환 대상을 먼저 고르기
AWS Transform은 제출된 소스에서 Azure SDK 사용을 식별하고 평가 보고서와 modernization plan에 변환 선택지를 제시합니다. 일정을 잡기 전에는 “저장소가 몇 개인가”에 더해 어떤 프로젝트·서비스 호출이 대상인지 살펴보세요.
공식 평가 문서는 프레임워크와 업그레이드 경로, 솔루션 구조·복잡도, 공용·사설 NuGet, DB 연결·ORM 패턴 등을 분석 항목으로 설명합니다. 내려받은 평가 보고서를 기준으로 누락 의존성과 변환 가능 범위를 확인할 수 있습니다. 평가 보고서의 분석 항목
- 앱의 프로젝트·프레임워크와 변환 대상 Azure 서비스 호출을 연결합니다.
- 사설 NuGet 등 아직 해결되지 않은 의존성을 별도 작업으로 표시합니다.
- Cosmos DB가 있다면 프리뷰 경로를 검토할 담당자와 시험 범위를 정합니다.
- 이번에 바꾸지 않을 서비스와 자동 변환 대상이 아닌 부분을 구분합니다.
평가 보고서의 진행률은 운영 이전 완료율과 구분하고, 발견된 미지원 부분을 수동 업무에 포함합니다.
2. 계획에서 변환할 코드와 보류할 코드를 조정하기
modernization plan은 실행 전에 검토하는 작업 범위입니다. 웹 계획 문서에는 저장소 의존 순서, 변환 전후 패키지·버전, 프로젝트 유형별 전략·위험을 다룬다고 안내돼 있습니다. 채팅·계획 편집·수정본 업로드·steering document로 요구를 전달할 수 있습니다. 현대화 계획 검토·수정
Azure 코드 변환 자체도 일부 또는 전체를 제외하도록 지시할 수 있습니다. 이미 사람이 맡아 바꾸는 모듈이 있다면 그 경계를 계획에 명시하세요. 지원 가능하다는 사실과 이번 작업에 포함하기로 결정했다는 사실을 나눠 기록하면 중복 작업을 줄일 수 있습니다.
팀의 작업 기록에는 소스 커밋·포함 프로젝트·변환 서비스·제외 사유와 담당자를 남깁니다.
3. 변환 diff와 TODO·stub·Next Steps를 함께 검토하기
공식 Azure 변환 문서는 대응 AWS 코드로 바꾸지 못한 부분을 TODO 주석, stub 코드 또는 생성된 Next Steps 문서에 표시한다고 설명합니다. 소스가 바뀐 파일만 세지 말고, 남겨진 동작과 후속 과제를 함께 확인해야 합니다.
Visual Studio 변환 설명에는 변경 파일·패키지·API와 실패한 부분, 빌드 오류·로그를 포함한 보고서 및 diff 검토가 안내돼 있습니다. Next Steps는 후속 작업을 위한 산출물입니다. 내려받은 문서가 있다는 사실과 그 안의 과제를 해결했다는 사실을 구분하세요. 변환 보고서·diff·Next Steps 확인
편집부는 남은 항목마다 위치 → 미완료 동작 → 영향받는 업무 → 담당자 → 완료 증거를 연결할 것을 권합니다. 예를 들어 처리되지 않은 저장 호출이 있다면 “TODO 1개”보다 “첨부파일 저장이 아직 검증되지 않음”으로 적는 편이 출시 판단에 도움이 됩니다. 이 예시는 실제 변환 로그가 아닙니다.
코드·인프라·데이터·권한은 각각 완료를 판정합니다
공식 문서는 이번 기능이 애플리케이션 코드만 변환하며 클라우드 인프라 이전을 처리하지 않는다고 명시합니다. 이 범위를 기준으로 편집부는 아래 네 가지 완료 기준을 제안합니다. 표는 AWS의 자동 실행 목록이 아니라 팀이 따로 검증할 작업 구분입니다.
| 영역 | 완료 증거로 남길 내용 | 별도로 정할 담당 업무 |
|---|---|---|
| 코드 | 검토한 diff, 목표 환경 빌드·테스트, TODO·stub 처리 결과 | 개발자가 변환·제외 부분과 실제 동작 확인 |
| 인프라 | 실제 AWS 리소스·배포 설정·연결 경로와 실행 결과 | 플랫폼 담당자가 생성·배포·네트워크 구성 |
| 데이터 | 선정한 데이터의 이전 전후 내용·개수·주요 조회 결과 대조 | 데이터 담당자가 복사·차이 조사·전환 시점 설계 |
| 접근 권한 | 운영 실행 주체의 필요한 작업 성공과 불필요한 접근 거부 확인 | 보안·운영 담당자가 권한·인증·환경 설정 검토 |
예를 들어 “코드 diff 검토 완료, 테스트 미실행, S3 리소스 미준비, 데이터 미복사”라면 코드 검토 단계까지 끝난 것입니다. 이를 “이전 완료”로 묶어 표시하면 배포 이후의 누락을 발견하기 어렵습니다. 완료 증거가 없는 칸은 미확인으로 남기세요.
파일 접수 앱의 데이터 대조에 쓸 합성 파일 3개
설명용 앱을 Azure Functions가 파일을 받아 Blob Storage에 저장하고 Queue Storage에 후속 작업을 넣는 구성으로 가정합니다. 대응 후보는 Lambda·S3·SQS이며 실제 선택은 평가·계획에서 확인해야 합니다. 이 앱을 변환·배포한 사례는 아닙니다.
개인정보 없는 합성 객체 파일 ZIP을 준비하고 로컬에서 전체 파일의 SHA-256을 계산했습니다. 원본과 이전 후 내려받은 파일을 대조할 때 같은 파일명·크기·해시로 연결할 수 있습니다.
| 실제 합성 파일 | 바이트 수 | 시험에서 확인할 내용 |
|---|---|---|
| sample-한글.txt | 17 | 한글 이름과 UTF-8 본문·줄바꿈 보존 |
| empty.bin | 0 | 빈 객체와 객체 누락을 구분 |
| sample.json | 58 | 한글·이모지·null을 포함한 파일 바이트 보존 |
cd synthetic-object-fixtures
shasum -a 256 sample-한글.txt empty.bin sample.json
세 파일의 실제 크기·전체 SHA-256 기준값과 비교하세요. ZIP에는 사용 범위를 적은 README와 같은 manifest가 들어 있습니다. 이는 로컬 시험 데이터 준비 결과이며 클라우드 업로드·자동 변환·데이터 이전 성공 기록은 아닙니다.
S3의 ETag나 multipart composite checksum을 이 전체 파일 SHA-256과 같은 값으로 가정하지 마세요. 서버 측 checksum을 사용할 때도 알고리즘·checksum 유형·표현 방식을 맞춰야 합니다. S3의 전체·composite checksum과 ETag 구분
이 파일 대조는 Blob→S3 객체의 내용 확인에 쓰는 한 가지 기준입니다. 목록에서 빠진 객체·추가 객체·권한과 후속 작업 완료는 별도로 확인합니다. Cosmos DB→DynamoDB 문서 변환은 키·필드·주요 조회 결과 기준을 따로 정해야 합니다.
자동 변환·수동 이전 범위 기록표에 파일 대조, 업로드·읽기와 큐 후속 처리 결과를 각각 남기세요. 데이터가 같다는 결과와 앱의 전체 업무가 정상이라는 결과를 구분할 수 있습니다.
견적은 변환 작업과 운영 이전 작업을 나눠 잡으세요
서비스 대응표는 자동화 후보를 고르는 기준입니다. 실제 일정은 사설 패키지 해결, 미지원 코드, 인프라 준비, 데이터 대조와 업무 회귀 검증까지 나눠 산정해야 합니다. 작은 앱의 결과를 얻기 전에는 자동 변환률이나 이전 기간 단축 수치를 제시할 근거가 없습니다.
비용도 선택한 Transform 기능·실행 경로와 운영 리소스를 구분합니다. 공식 요금표는 무료·유료 기능을 나누며, Transform 출력으로 생성하거나 계속 사용하는 AWS 리소스는 표준 요금에 따라 별도 청구된다고 안내합니다. 계정의 실제 조건·사용량과 대상 서비스 비용은 견적 시점에 다시 확인하세요. AWS Transform 요금·별도 리소스 비용
변환 후 테스트·배포·운영 승인 경계는 AI 에이전트 CI/CD의 검증·승인 설계와 연결해 정할 수 있습니다. 코드 리뷰, 실제 환경 검증과 운영 전환 승인을 별도 결과로 남기세요.
자주 묻는 질문
코드 변환을 하면 Azure 데이터도 옮겨지나요?
공식 지원 범위는 애플리케이션 코드 변환입니다. 코드 변환 결과만으로 데이터 복사·정합성 확인이 완료됐다고 판단할 수 없습니다. 데이터 이전과 실제 조회·쓰기 검증을 별도 작업으로 관리하세요.
모든 Azure SDK 호출을 변환하나요?
공식 문서에 나열된 특정 서비스만 대상입니다. Functions·Blob Storage·Queue Storage와 Cosmos DB 프리뷰를 구분하고, 각 앱의 적격 조건과 실제 선택된 변환 범위를 평가 보고서·현대화 계획에서 확인해야 합니다.
지원하지 않는 코드와 남은 작업은 어디서 확인하나요?
TODO 주석·stub 코드·Next Steps를 확인하고 변환 보고서·diff·빌드 결과와 대조합니다. 미완료 동작별 담당자와 확인할 증거를 정한 뒤 실제 실행 결과로 완료를 판정하세요.
이번 글의 확인 범위와 갱신할 항목
2026년 10월 18일 AWS의 10월 16일 발표와 공식 변환·평가·계획·.NET 지원·요금 문서를 대조했습니다. 이 글은 공식 지원 범위 분석입니다. 실제 AWS 계정에서 앱 변환·리소스 배포·데이터 이전·권한 검증을 실행하지 않았으며, 평가 보고서나 성공 diff를 직접 확보한 것처럼 제시하지 않았습니다.
변환 서비스·지원 .NET 조건·Cosmos DB 프리뷰·리전·요금이 바뀌면 해당 설명을 갱신합니다. 실제 이전 사례를 추가할 때는 고객 정보 없는 최소 앱, 사용 버전·커밋, 변환 보고서·diff·Next Steps와 빌드·동작·데이터 대조 결과를 함께 공개해야 합니다.
Evidence & Limitations
근거·검증 범위·업데이트 기록
확인한 근거
AWS Transform Azure-to-AWS 코드 변환 정식 제공 발표를 기준으로 핵심 사실을 확인하고, 사실과 편집부 해석을 구분했습니다.
경험 정보와 한계
직접 사용 후기나 자체 성능 시험이 아닌 공개 원문·공식 문서 기반 분석입니다. 실제 화면과 기능은 계정·기기·배포 시점에 따라 다를 수 있습니다.
게시·수정 기록
최초 게시 2026-10-18T14:12:21+09:00 · 최종 수정 2026. 10. 18.
Blob→S3 대조에 쓸 합성 파일·크기·SHA-256 기준값과 다운로드를 추가했습니다. 전체 파일 해시·S3 ETag·composite checksum의 차이를 명시했습니다.
전문 검토 영역
IT 매거진 편집부가 AI·소프트웨어·개발·모바일·보안·테크 비즈니스 관점에서 구성하고 팩트체크 데스크가 출처와 표현을 검토했습니다.
검증에 사용한 주요 공식 자료
- 10월 16일 코드 변환 정식 제공·서비스별 상태·8개 리전
- Azure 변환 적격 조건·SDK 대응·코드만 변환·TODO·stub·Next Steps
- 2025년 8월 Azure Repos·Artifacts 연결 지원 발표
- .NET 전체 현대화 지원 버전·유형·제한
- 변환 전 경험·도구·검증 계획·후속 작업
- 평가 보고서의 프레임워크·NuGet·DB·구조 분석
- modernization plan·패키지 전후 대응·전략·수정 방법
- IDE 변환 보고서·diff·빌드 오류·Next Steps 산출물
- Transform 기능별 요금과 AWS 리소스 별도 청구
- S3의 전체·composite checksum과 ETag·데이터 무결성 확인
Related Articles
이 주제를 더 깊게 읽어보세요
현재 기사와 연결되는 배경·기술·시장 분석을 골라 바로 이동할 수 있습니다.


