기준: SAP-C02 시험 가이드오류 제보
마이그레이션 프로젝트에서 "이전"은 전체 여정의 절반도 안 된다. 나머지 절반은 무엇을 이전할지 결정하는 Discovery, 얼마나 드는지 파악하는 TCO 분석, 조직 전체가 안전하게 이전하는 Landing Zone 구축, 이전 중 상태를 추적하는 대시보드다. AWS는 이 각 단계를 지원하는 전문 도구와 프로그램을 제공한다.
오늘은 Day 26-28에서 본 7R·MGN·DMS 외에 마이그레이션 생태계를 완성하는 도구들을 다룬다. App2Container(컨테이너화), Porting Assistant(코드 포팅), Migration Hub(통합 추적), MAP(자금 프로그램), Refactor Spaces(점진적 모놀리식 분해). 특히 비슷해 보이는 도구들 간의 경계를 정확히 구분하는 것이 Pro 시험의 핵심이다.
App2Container는 현재 실행 중인 Java 또는 .NET IIS 앱을 소스 코드 없이 Docker 이미지로 변환하는 AWS CLI 도구다.
기존에 EC2나 온프레미스에서 돌아가는 레거시 앱을 컨테이너로 옮기려면 보통 두 가지 방법이 있었다. (1) 소스 코드를 받아 Dockerfile을 직접 작성하거나, (2) VM 스냅샷을 가져오거나. 둘 다 복잡하고 시간이 걸렸다. A2C는 실행 중인 프로세스를 분석해 의존성, 환경 변수, 포트, 파일 마운트를 자동 추출해 Dockerfile을 만들어준다.
| 기술 스택 | 지원 |
|---|---|
| Java + Tomcat | ✅ |
| Java + JBoss | ✅ |
| Java + WebSphere | ✅ |
| Java + WebLogic | ✅ |
| .NET Framework + IIS (Windows Container) | ✅ |
| Python Flask/Django | ❌ (A2C 미지원, 직접 컨테이너화) |
| Node.js | ❌ |
⚠️ 함정: A2C는 앱만 컨테이너화한다. DB(MySQL, Oracle 등)는 A2C 대상이 아니다. "Tomcat 앱을 EKS로 이전하려 한다" → A2C로 앱 컨테이너화 + DMS로 DB 별도 이전.
⚠️ 함정 2: .NET Framework 앱을 A2C로 컨테이너화하면 Windows Container가 만들어진다. Linux Container로 바꾸려면 .NET Core(현재 .NET 8)로 포팅이 필요하고, 그 작업을 도와주는 것이 Porting Assistant다.
1. init ─── A2C 초기화, IAM/리전 설정
2. inventory ─── 실행 중인 앱 발견·ID 부여
(PID, 포트, 클래스패스, 바인드 마운트)
3. analyze ─── 의존성 심층 분석
(외부 호출, 환경 변수, 정적 리소스)
4. extract ─── 컨테이너화할 아티팩트 추출
(WAR/JAR, DLL, 설정 파일)
5. containerize ── Dockerfile 자동 생성 + 이미지 빌드 + ECR push
6. generate ─── ECS Task Definition / EKS Deployment YAML / App Runner 설정 생성
Dockerfiledocker-compose.yml (로컬 테스트용)ecs-task-def.json (ECS 배포)deployment.yaml (EKS 배포)CloudFormation Template (인프라 포함)컨테이너화 시 다음 사이드카를 자동 주입할 수 있다:
컨테이너는 프로세스 격리를 위해 Linux Namespaces(PID, Network, Mount, IPC, UTS)와 cgroups(CPU·메모리 자원 제한)를 활용한다. A2C는 현재 실행 중인 프로세스의 Namespace 정보와 환경을 분석해 동일한 환경을 컨테이너 이미지로 재현한다. 이론적으로 OS가 제공하는 것과 동일한 격리를 Docker로 복제하는 것이다.
A2C와 혼동되기 쉬운 도구. 결정적 차이:
| App2Container | Porting Assistant | |
|---|---|---|
| 역할 | 현재 OS에서 컨테이너로 패키징 | .NET Framework → .NET 코드 자체 변환 |
| 코드 변경 | 없음 | 있음 (API·NuGet 패키지 교체) |
| 결과물 | Docker 이미지 | 코드 분석 리포트 + 일부 자동 마이그레이션 |
| 사용 시점 | OS 그대로 유지하며 컨테이너화 | .NET Core/8로 현대화하려 할 때 |
Porting Assistant의 동작:
.NET Framework와 .NET Core(현재 .NET 8)의 분리. .NET Framework는 Windows 전용, .NET Core는 크로스 플랫폼(Linux/macOS/Windows). 2016년 Microsoft가 .NET Core를 오픈소스로 출시하면서 AWS에서 Linux 컨테이너로 .NET 앱을 실행하는 길이 열렸다. 하지만 .NET Framework API(Windows Registry, COM, WCF 일부)는 .NET Core에서 지원하지 않아 포팅 과정에서 코드 변경이 필요하다. Porting Assistant는 이 갭을 식별해준다.
Windows Server 2003(2015년 EoS), Windows Server 2008(2020년 EoS) 등 더 이상 MS 보안 패치를 받지 못하는 OS 위에서 레거시 앱이 동작하는 경우가 있다. 그냥 EC2 Windows 2019로 올리면 앱이 동작하지 않을 수 있다.
EMP는 이런 레거시 앱에 호환성 패키지(Compatibility Shim)를 적용해 새로운 Windows 버전에서도 동작하도록 만든다. MGN으로 EC2로 이전한 후 EMP 패키지를 적용하는 조합이 표준이다.
| 시나리오 | 솔루션 |
|---|---|
| Win 2008 앱을 Win 2019로 바꾸고 싶다 | EMP + MGN |
| Win 2008 앱을 Linux 컨테이너로 | Porting Assistant (코드 포팅 먼저) |
| Win 2008 .NET Framework 앱을 AWS ECS로 | A2C (Windows Container) |
Migration Hub는 마이그레이션 도구가 아니라 통합 추적 대시보드다. MGN, DMS, ADS, 파트너 도구들의 진행 상황을 한 콘솔에서 본다.
진행 상황 트래킹: 서버·앱별로 "Discovery → Not Ready → Ready → Testing → Cutover Complete" 상태 관리.
홈 리전(Home Region): Migration Hub는 모든 데이터를 하나의 리전에 저장한다. 최초 설정 후 변경 불가. 전사 마이그레이션 거버넌스 관점에서 하나의 권위 있는 리전을 선택해야 한다.
Strategy Recommendations: 서버 인벤토리와 소스 코드 분석을 토대로 7R 중 어떤 R을 권장하는지 자동 제안한다. A2C·Porting Assistant·MGN 등과 연동해 구체적인 도구까지 권장.
Migration Hub Orchestrator (2022~): 마이그레이션 단계별 워크플로우를 자동화한다. 예: "ADS 발견 → Wave 승인 → MGN 에이전트 설치 → Test Launch 승인 → Cutover → 검증"을 Orchestrator가 단계별로 실행하고 승인 게이트를 관리.
2023년 Deutsche Bank의 대규모 마이그레이션. Deutsche Bank는 5,000대 이상 서버를 AWS로 이전하는 과정에서 Migration Hub Orchestrator를 사용해 Wave 관리와 승인 프로세스를 자동화했다. 금융 규제 요구에 따라 각 Wave Cutover 전 IT 위험 관리팀의 승인 게이트를 Orchestrator에 구성했다. 교훈: 대규모 마이그레이션에서 Orchestrator의 승인 워크플로우는 거버넌스와 감사 추적을 동시에 해결한다.
ADS는 마이그레이션의 전제 조건이다. "무엇이 어디에 있는지" 모르고는 7R 결정도 Wave 설계도 불가능하다.
Agentless Collector (VMware vCenter):
Discovery Agent (Linux/Windows 설치):
| 항목 | Agentless Collector | Discovery Agent |
|---|---|---|
| 설치 방법 | vCenter 가상 어플라이언스 | 각 OS에 에이전트 |
| 의존성 맵 | 제한적 (네트워크 레벨) | 상세 (TCP 연결, 프로세스) |
| vCenter 의존 | 필수 | 불필요 |
| 물리 서버 지원 | ❌ | ✅ |
수집 데이터는 S3에 저장되어 Amazon Athena에서 SQL 쿼리 가능. 이를 통해 "특정 Oracle 버전이 설치된 서버 목록", "특정 포트로 통신하는 서버 쌍" 같은 분석이 가능하다.
ADS가 기술 인벤토리라면, Migration Evaluator는 재무 인벤토리다.
주요 기능:
Migration Evaluator vs AWS Pricing Calculator:
Refactor Spaces는 모놀리식 앱을 마이크로서비스로 점진적으로 전환하는 Strangler Fig 패턴을 AWS 매니지드 서비스로 제공한다.
모놀리식을 한 번에 마이크로서비스로 바꾸는 "빅뱅 Refactor"는 수년의 개발 기간과 높은 리스크를 수반한다. Strangler Fig는 기존 모놀리식을 계속 운영하면서, 새 기능은 마이크로서비스로 개발하고 점진적으로 기존 기능을 교체한다.
Refactor Spaces는 API Gateway, VPC Link, Route 53 자원을 자동 구성해 라우팅 계층을 만든다.
클라이언트
│
▼
API Gateway (Refactor Spaces 관리)
├── /api/orders/* → 새 마이크로서비스 (Lambda + DynamoDB)
├── /api/products/* → 새 마이크로서비스 (ECS)
└── /* → 기존 모놀리식 (ALB → EC2)
신규 기능을 마이크로서비스로 개발하면 Refactor Spaces에 라우팅 규칙을 추가한다. 점진적으로 모놀리식의 엔드포인트가 새 서비스로 교체되고, 결국 모놀리식으로 향하는 트래픽이 없어지면 모놀리식을 폐기한다.
Refactor Spaces vs 직접 API Gateway 구성:
Martin Fowler의 Strangler Fig Application (2004). 레거시 시스템의 기능을 하나씩 새로운 서비스로 교체할 때, 원래 시스템이 여전히 실행되지만 점점 더 적은 기능을 처리하도록 하는 패턴이다. "교살(Strangler)"이라는 이름이 불편하게 들릴 수 있지만, 이는 기존 나무를 감싸 결국 대체하는 열대 무화과나무에서 온 비유다. 소프트웨어 현대화에서 가장 현실적이고 안전한 전략으로 널리 채택되었다.
시험에서 나오는 모든 시나리오를 아래 매핑으로 판단한다.
| 시나리오 | 도구 | 근거 |
|---|---|---|
| VM/서버 인벤토리 자동 수집 | ADS | 기술 인벤토리 |
| VMware vCenter 무에이전트 발견 | ADS Agentless Collector | vCenter 통합 |
| 5년 TCO 비교 리포트 | Migration Evaluator | 재무 분석 |
| VM → EC2 Rehost (lift-and-shift) | MGN | 블록 레벨 복제 |
| Oracle/SQL Server → Aurora | DMS + SCT | 이종 DB 마이그 |
| MySQL → RDS MySQL | DMS만 | 동종 DB 마이그 |
| SQL Server → Aurora (코드 변경 최소) | Babelfish | TDS 호환 |
| Java(Tomcat/JBoss) → ECS/EKS 컨테이너 | App2Container | Java 컨테이너화 |
| .NET IIS → ECS/EKS 컨테이너 | App2Container | .NET IIS 컨테이너화 |
| .NET Framework → .NET Core 포팅 | Porting Assistant | 코드 포팅 분석 |
| Win 2003/2008 EoS AWS 이전 | EMP + MGN | 호환성 패키지 |
| 모놀리식 → 마이크로서비스 점진 교체 | Refactor Spaces | Strangler Fig |
| 전사 마이그레이션 통합 대시보드 | Migration Hub | 진행률 트래킹 |
| 7R 자동 권장 | Migration Hub Strategy Recommendations | AI 기반 권장 |
| 마이그레이션 단계별 자동화·승인 | Migration Hub Orchestrator | 워크플로우 |
| 전사 자금·컨설팅·파트너 프로그램 | MAP | 3단계 프로그램 |
🎯 시나리오: "온프레 데이터센터에 3,000대 서버가 있다. IT 팀이 현재 어떤 앱이 어디서 실행 중인지 모른다. 서버 인벤토리와 DB 복잡도를 모두 파악하고, 임원에게 5년 TCO 리포트를 제출한 뒤 전사 마이그레이션 자금을 지원받고 싶다." → ADS(인벤토리) + Fleet Advisor(DB 복잡도) + Migration Evaluator(TCO) + MAP(자금·프로그램).
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
온프레미스에서 JBoss 위에 Java EE 앱이 운영 중이다. EKS로 이전하려 하며, 앱 코드를 수정하지 않고 컨테이너 이미지와 EKS 매니페스트를 자동 생성하고 싶다. 가장 적합한 도구는?
문제 2
회사가 .NET Framework 4.7 IIS 앱을 Linux ECS에서 실행하려 한다. 현재는 Windows에서만 돌아간다. 먼저 무엇을 해야 하는가?
문제 3
회사의 마이그레이션 팀이 MGN(EC2 이전), DMS(DB 이전), 파트너 도구(파일서버 이전)를 동시에 진행 중이다. 임원이 "전체 진행 상황을 한 화면에서 보고 싶다"고 요구한다. 어떤 서비스를 사용하는가?
문제 4
거대 모놀리식 Java 앱을 마이크로서비스로 전환하려 한다. 한 번에 재설계하는 것은 리스크가 너무 높다. 기존 모놀리식을 유지하면서 새 기능부터 마이크로서비스로 개발하고 점진적으로 교체하려 한다. 어떤 서비스가 이 라우팅 관리를 매니지드로 제공하는가?
문제 5
1,500대 VMware vCenter 환경 서버의 CPU·메모리·네트워크 의존성을 에이전트 없이 수집하려 한다. 어떤 도구가 적합한가?
문제 6
임원진이 "AWS로 이전하면 5년간 얼마를 절약하는가"를 알고 싶다. 현재 온프레 인프라 비용(하드웨어, 전기, 인건비, 라이선스)과 AWS 이전 후 예상 비용을 비교한 리포트가 필요하다. 어떤 도구를 사용하는가?
문제 7
회사가 2,000대 서버를 24개월에 이전하는 전사 프로젝트를 시작했다. AWS 파트너의 마이그레이션 전문가 지원, AWS 마이그레이션 크레딧, Mobilize 단계의 Landing Zone 구축 지원을 원한다. 어떤 것이 이 모든 것을 제공하는가?