기준: SAP-C02 시험 가이드오류 제보
Week 6은 클라우드 마이그레이션의 전 과정을 다뤘다. 의사결정 프레임워크인 7R(Day 31), 서버 이전의 표준 도구 MGN과 DRS(Day 32), DB 이전의 과학 DMS+SCT(Day 33), 생태계를 완성하는 가속 도구들(Day 34). 이 네 일자의 내용이 SAP-C02 도메인 3(마이그레이션·현대화, 20%)의 핵심이다.
도메인 3의 전형적인 패턴은 "긴 시나리오에 여러 도구가 등장하고, 각 도구의 역할을 정확히 구분해야 정답을 고를 수 있는" 유형이다. 오늘은 각 개념의 핵심을 결정 트리로 압축하고, 복합 시나리오 12문항으로 실전 감각을 완성한다.
7R은 암기 문제가 아니라 시나리오 분류 문제다. 각 R의 "진입 조건"을 결정 트리로 이해해야 한다.
질문 1: 이 시스템을 계속 쓸 이유가 있는가?
NO → Retire (폐기)
YES → 다음
질문 2: AWS 이전 자체의 ROI가 없거나 규제상 온프레가 필수인가?
YES → Retain (그대로 유지)
NO → 다음
질문 3: VMware vCenter를 그대로 유지해야 하는가?
YES → Relocate (VMware Cloud on AWS)
NO → 다음
질문 4: 코드 변경 없이 빠르게 이전이 최우선인가?
YES → Rehost (lift-and-shift, MGN)
NO → 다음
질문 5: DB 엔진 교체나 OS 변경(최소 코드 수정)인가?
YES → Replatform (DMS+SCT, MGN)
NO → 다음
질문 6: SaaS 제품으로 전환하는 것이 더 합리적인가?
YES → Repurchase (Salesforce, ServiceNow 등)
NO → 다음
질문 7: 아키텍처 자체를 마이크로서비스/서버리스로 재설계하는가?
YES → Refactor/Re-architect (A2C, Refactor Spaces, Lambda 재개발)
⚠️ 핵심 구분: Replatform과 Refactor의 경계.
- Replatform: 코드는 그대로, 인프라 레이어 일부만 교체. "Oracle → Aurora(코드 미수정)", "EC2 기반 앱 → ECS(Dockerize만)"
- Refactor: 코드도 변경, 아키텍처 재설계. "모놀리식 → Lambda+DynamoDB", "REST API → 이벤트 드리븐 아키텍처" 경계 사례: "Oracle → Aurora PostgreSQL로 이전 시 PL/SQL 일부를 PostgreSQL 함수로 변환" → SCT가 자동 변환하더라도 코드 변환이 일어나므로 엄밀히는 Replatform(인프라+일부 코드). SAP 시험은 주로 코드 변경 여부로 구분한다.
| 시나리오 | 도구 조합 | 이유 |
|---|---|---|
| 서버 전체 빠른 이전 | MGN | 블록 레벨 복제, Cutover 수분 |
| DB 동종 엔진 이전 (MySQL→Aurora MySQL) | DMS only | 스키마 변환 불필요 |
| DB 이종 엔진 이전 (Oracle→Aurora PG) | DMS + SCT | 스키마·코드 변환 필요 |
| SQL Server T-SQL 호환 최소 변경 | Babelfish + MGN | T-SQL 그대로 사용 |
| .NET Framework → .NET Core 포팅 | Porting Assistant | 코드 호환성 분석·변환 |
| Java/.NET 앱 → 컨테이너화 | App2Container (A2C) | Dockerfile·ECS task def 자동 생성 |
| VMware vCenter 그대로 AWS로 | VMware Cloud on AWS | vCenter API 유지, Relocate |
| 온프레 서버를 AWS DR로 보호 | DRS | 상시 복제 + Failback |
| 마이그레이션 후 DR 역방향 | DRS | DR 리전 EC2 → 온프레 복제 |
| 모놀리식 → 마이크로서비스 점진 전환 | Refactor Spaces | Strangler Fig 트래픽 라우팅 |
| EoS Windows 2003/2008 앱 호환성 | EMP | 호환성 패키지 래핑 |
| Windows Server App → 현대 Windows | EMP + MGN | 호환성 + 이전 |
| 대용량 데이터 오프라인 이전 | Snow Family | 인터넷 대역폭 부족 시 |
| 파일/오브젝트 스토리지 이전 | DataSync | NFS, SMB, S3, EFS |
마이그레이션에서 데이터 정합성(Consistency)은 선택이 아니라 필수다. ACID(Atomicity, Consistency, Isolation, Durability) 특성을 가진 OLTP DB에서는 마이그레이션 중 열린 트랜잭션이 어떻게 처리되는지가 핵심이다. DMS는 DB 엔진의 트랜잭션 로그(Oracle Redo Log, MySQL binlog, SQL Server CDC, PostgreSQL WAL)를 읽어 트랜잭션 단위로 변경을 캡처한다. MGN의 블록 레벨 복제는 트랜잭션 경계를 인식하지 못하기 때문에 DB는 DMS로 이전하는 것이 Best Practice다.
엔진이 같은가?
MySQL → Aurora MySQL → DMS만
PostgreSQL → Aurora PostgreSQL → DMS만
Oracle → RDS Oracle → DMS만
엔진이 다른가?
Oracle → Aurora PostgreSQL → SCT(스키마) + DMS(데이터)
SQL Server → Aurora PostgreSQL → SCT + DMS
MongoDB → DynamoDB → DMS (NoSQL→NoSQL, SCT 불필요)
SQL Server → Aurora MySQL Babelfish → Babelfish(T-SQL 호환 레이어)
동종이지만 버전이 많이 다른가?
MySQL 5.6 → Aurora MySQL 3.x(MySQL 8.0 호환) →
DMS만으로 이전하되, 문자열 함수·시스템 변수 변경 사항을 사전 테스트
SCT(Schema Conversion Tool)는 이종 엔진 간 스키마를 자동 변환하지만, 변환률은 완전하지 않다.
SCT Assessment Report 예시:
자동 변환 가능: 75%
수동 수정 필요: 20% (복잡한 PL/SQL 함수, 패키지 의존성)
지원 불가: 5% (DB 전용 기능, 커스텀 C 확장)
실무 교훈:
- SCT 변환률이 낮을수록 Refactor 비용이 증가
- Oracle의 오라클 전용 힌트, DB 링크, 파티셔닝이 많으면 변환 어려움
- 사전 SCT Assessment 실행으로 공수 예측
🔍 더 깊이: DMS CDC의 최소 다운타임 마이그레이션 패턴. Full Load만 쓰면 대용량 DB에서 다운타임이 길어진다. Full Load + CDC를 조합하면: (1) Full Load로 기존 데이터를 이전(원본 운영 중), (2) Full Load 완료 후 CDC로 변경분만 계속 적용, (3) Lag이 수 초로 줄어들면 앱 중단 → 마지막 CDC 반영 → 전환. 이 패턴으로 수 TB DB도 다운타임 수분 이내로 이전 가능하다. SAP 시험에서 "최소 다운타임 DB 마이그레이션"은 항상 DMS Full Load + CDC 패턴이다.
이전 대상이 "서버 전체(OS + 앱 + 미들웨어)"인가?
YES → MGN
이전 대상이 "DB 데이터"인가?
YES → DMS (동종) 또는 DMS+SCT (이종)
DB 서버를 MGN으로 이전해도 되는가?
기술적으로 가능하지만 Best Practice 아님.
이유: 복제 중 열린 트랜잭션 → 데이터 불일관성 가능
권장: 앱 서버 → MGN, DB → DMS
두 가지 모두 필요한 경우:
앱 서버 700대 → MGN (병렬)
Oracle DB 100대 → SCT+DMS (병렬)
→ Migration Hub Orchestrator로 Wave 조율
A2C는 Java, .NET(IIS) 기반 앱을 분석해 Docker 이미지와 ECS/EKS 배포 아티팩트를 자동 생성한다.
A2C 작동 순서:
1. Discover (앱 분석)
$ app2container discover --target-container-id app-001
└── 실행 중인 앱 프로세스, 포트, 의존성, 환경 변수 분석
2. Extract (추출)
$ app2container extract --application-id java-app:1234
└── 앱 파일, 설정, 런타임 환경을 tar 패키지로 추출
3. Containerize (컨테이너화)
$ app2container containerize --application-id java-app:1234
└── Dockerfile 생성, Docker 이미지 빌드, ECR push
└── ECS Task Definition 또는 EKS Helm Chart 생성
4. Generate Pipeline (CI/CD 파이프라인)
$ app2container generate app-deployment \
--application-id java-app:1234 \
--deploy-target ecs
└── CodePipeline + CodeBuild 파이프라인 CloudFormation 생성
A2C의 한계. 국내 한 SI 회사가 레거시 Java EE 앱(JBoss 4.2 기반)을 A2C로 컨테이너화했을 때, JBoss 4.2의 특정 JMX 설정과 EJB 원격 호출이 컨테이너 환경에서 동작하지 않았다. A2C는 앱을 "그대로" 컨테이너에 넣는 것이지, 컨테이너 친화적으로 만들어주지는 않는다. 서버 상태를 파일에 저장하는 레거시 앱, JVM 힙 설정이 컨테이너 메모리와 충돌하는 케이스가 대표적 A2C 이후 추가 작업 대상이다.
마이그레이션 도구 Day 34에서 다룬 컨테이너화 이후 "어디에 배포하는가"의 선택이다.
| 항목 | EKS Anywhere | AWS Outposts |
|---|---|---|
| 하드웨어 | 고객 소유 서버 (VMware, Bare Metal) | AWS가 설계·배송한 랙 |
| 컨트롤 플레인 | 온프레미스에서 직접 운영 | AWS가 관리 |
| AWS 서비스 통합 | 제한적 (EKS Connector로 일부 통합) | EC2, EBS, S3, RDS 등 대부분 통합 |
| 적합 상황 | 기존 온프레 인프라 재사용, AWS 의존도 최소화 | AWS 관리형 서비스가 온프레에 필요한 경우 |
| 데이터 주권 | ✅ 데이터가 온프레에서 처리 | ✅ 데이터가 고객 시설에서 처리 |
| 가격 | EKS 라이선스 비용 | Outposts 하드웨어 임차 비용 (월 수백만~수천만 원) |
🎯 시나리오 분류:
- "기존 온프레미스 서버에 쿠버네티스를 배포하고 AWS 콘솔에서 통합 관리하고 싶다" → EKS Anywhere
- "병원 내부에서 환자 데이터가 절대 외부로 나가면 안 되지만 RDS를 쓰고 싶다" → Outposts
- "규제상 데이터를 국내 데이터센터에서만 처리해야 하는 금융권" → Outposts 또는 EKS Anywhere (규제 상세에 따라)
엔터프라이즈 마이그레이션의 end-to-end 파이프라인을 한 그림으로 정리한다.
[Phase 1: Discover & Assess]
ADS (Application Discovery Service)
└── Agentless Collector (VMware 환경)
└── Discovery Agent (물리 서버, 다른 클라우드)
└── 인벤토리: CPU, 메모리, 디스크, 네트워크 의존성
DMS Fleet Advisor
└── DB 서버 특화 인벤토리
└── 스키마 복잡도, 변환 가능성 평가
Migration Evaluator
└── On-Demand vs Savings Plans 비교
└── 5년 TCO 절감 예측
Migration Hub Strategy Recommendations
└── 서버별 7R 자동 권장 (Refactor/Replatform/Rehost...)
[Phase 2: Plan & Mobilize]
MAP (Migration Acceleration Program)
└── AWS 파트너 + 자금 지원 + 교육
└── Assess → Mobilize → Migrate 3단계
Migration Hub
└── 모든 마이그레이션 진행 상황 통합 추적
[Phase 3: Migrate]
서버 이전:
MGN (Rehost → EC2) + DRS (상시 DR)
DB 이전:
DMS + SCT (이종) 또는 DMS (동종)
DataSync (파일/오브젝트 스토리지)
Snow Family (대용량 오프라인)
컨테이너화:
App2Container (Java, .NET)
Porting Assistant (.NET Core 포팅)
EMP (EoS Windows)
[Phase 4: Modernize]
Refactor Spaces (점진적 마이크로서비스 분리)
EKS / ECS (컨테이너 오케스트레이션)
Lambda / EventBridge (서버리스 이벤트 드리븐)
Serverless Application Model (SAM)
[Phase 5: Optimize]
Compute Optimizer (Right-Sizing)
Savings Plans / Reserved Instances (비용 약정)
Trusted Advisor (전반 권장)
Well-Architected Tool (6 Pillar 검토)
| 비교 쌍 | A | B | 차이 기준 |
|---|---|---|---|
| MGN vs DMS | 서버 전체(OS+앱) | DB 데이터만 | 이전 단위 |
| MGN vs DRS | 1회 마이그레이션 | 상시 DR + Failback | 목적 |
| 동종 DMS vs 이종 SCT+DMS | 스키마 변환 불필요 | SCT로 변환 필요 | 엔진 호환성 |
| A2C vs Porting Assistant | OS 그대로 컨테이너 | 코드를 .NET Core로 포팅 | 코드 변경 유무 |
| ADS vs Migration Evaluator | 기술 인벤토리 | 재무 TCO | 분석 차원 |
| ADS Agentless vs Agent | VMware 전용, 무설치 | 모든 OS, 설치 필요 | 환경 |
| Migration Hub vs MAP | 추적 도구 | 자금·컨설팅 프로그램 | 도구 vs 프로그램 |
| Relocate vs Rehost | VMware 그대로 | OS·앱 그대로 EC2 | 하이퍼바이저 유지 |
| Refactor vs Replatform | 코드+아키텍처 재설계 | 코드 없이 인프라 교체 | 코드 변경 여부 |
| DRS vs MGN | 지속 DR (RPO 수초) | 1회 마이그레이션 | 마이그 vs 상시 DR |
| Babelfish vs SCT+DMS | T-SQL 호환 레이어 | 완전 변환 후 이식성 | 변경 최소 vs 완전 이식 |
| EKS Anywhere vs Outposts | 고객 하드웨어 재사용 | AWS 관리형 하드웨어 | 하드웨어 소유 |
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
한 대형 유통회사가 800대 물리 서버(앱 서버 700대 + Oracle DB 서버 100대)를 6개월 안에 AWS로 이전해야 한다. Oracle을 Aurora PostgreSQL로 교체하고, 앱 서버는 빠르게 EC2로 이전한다. 가장 적합한 도구 조합은?
문제 2
ADS가 3,000대 서버 중 500대가 CPU 평균 < 3%, 트래픽 없음, 마지막 로그인 2년 전임을 발견했다. 나머지 2,500대는 활성 워크로드다. 500대에 적용해야 하는 7R 전략은?
문제 3
한 금융회사가 SQL Server 위의 .NET Framework 4.6 앱을 코드 변경 최소화로 AWS 이전 + SQL Server 라이선스 제거를 원한다. 개발 인력이 부족해 대규모 코드 재작성은 불가하다. 가장 현실적인 조합은?
문제 4
전사 마이그레이션 프로젝트 킥오프. 임원진이 "5년 TCO 절감 얼마?"를 묻고, 팀이 "서버별 어느 R을 적용?"을 묻는다. 두 요구를 모두 충족하는 AWS 서비스 조합은?
문제 5
VMware Cloud on AWS(Relocate)로 500대 VM을 이전한 후 6개월 경과. VMware 라이선스 비용이 여전히 높다. 다음 단계는?
문제 6
대형 모놀리식 Java 앱(200만 라인)을 마이크로서비스로 전환 중이다. 기존 모놀리식을 운영하면서 새 주문 관리 모듈을 먼저 마이크로서비스로 개발하고, 주문 API 트래픽의 일부를 새 서비스로 점진적으로 전환하고 싶다. 어떤 서비스가 라우팅 자동화를 관리하는가?
문제 7
1,000대 VMware VM의 CPU·메모리 사용률과 서버 간 TCP 의존성을 수집해 Wave를 설계하려 한다. vCenter 환경이므로 에이전트 설치 없이 진행하고 싶다. 어떤 도구를 쓰는가?
문제 8
MySQL 5.7 → Aurora MySQL 2.x(MySQL 5.7 호환) 마이그레이션을 한다. 스토어드 프로시저가 100개 있다. DMS와 SCT 중 무엇이 필요한가?
문제 9
마이그레이션 담당자가 MGN 150대, DMS 30개, 파트너 도구 20대를 동시 진행 중이다. 각 서버의 "Discovery → Ready → Testing → Cutover Complete" 상태와 Wave별 진행률을 한 콘솔에서 관리하고, Wave 간 의존성에 따른 자동화도 원한다. 어떤 서비스를 쓰는가?
문제 10
마이그레이션 완료 후 EC2 인스턴스들이 원본 서버 사양 기준으로 과잉 프로비저닝됐을 가능성이 있다. CPU 사용률이 평균 15%, 메모리는 40% 수준이다. 인스턴스 타입 변경을 권장받으려 한다. 어떤 서비스를 사용하는가?
문제 11
한 회사가 온프레미스에서 AWS로 마이그레이션을 완료했다. 이제 온프레미스 데이터센터가 남아있고 이것을 AWS 서비스의 DR 사이트로 활용하고 싶다. 어떤 구성이 가능한가?
문제 12
한 회사가 Well-Architected 마이그레이션 리뷰를 받았다. "도메인 3: 마이그레이션·현대화에서 DB 마이그레이션 중 다운타임을 최소화하는 설계가 누락됐다"는 지적을 받았다. Oracle DB 10TB를 Aurora PostgreSQL로 이전하면서 다운타임을 2시간 이내로 맞추는 Best Practice 설계는?