AWS Transform 마이그레이션 분석 프롬프트

요약

AWS Transform은 애플리케이션·서버·메인프레임 마이그레이션 작업을 자동화하고, 일부 코드를 변환하거나 마이그레이션 단계를 지원하는 AWS 서비스군입니다. 다만 AWS Transform 자체가 전체 마이그레이션 계획, 비용 산정, 보안 검증, 운영 전환까지 자동으로 완료해 주는 것은 아닙니다.

실무에서는 다음 서비스를 함께 사용하는 것이 일반적입니다.

• AWS Transform: 변환·현대화·마이그레이션 작업 자동화
• AWS Application Discovery Service: 서버, 프로세스, 네트워크 정보 수집
• AWS Migration Hub: 애플리케이션 단위 마이그레이션 추적
• AWS Migration Evaluator: 비용 및 적정 사이징 분석
• AWS Migration Hub Strategy Recommendations: 마이그레이션 전략 제안
• AWS Prescriptive Guidance: 패턴과 구현 가이드 제공

1. 마이그레이션 전 고려사항

1) 비즈니스 범위

먼저 기술보다 비즈니스 목표를 명확히 해야 합니다.

• 데이터센터 종료가 목표인지
• 운영비 절감이 목표인지
• 데이터센터 계약 만료에 따른 이전인지
• 애플리케이션 현대화가 목표인지
• 장애 복구 및 가용성 향상이 목표인지
• 출시 속도와 개발 생산성 개선이 목표인지

목표에 따라 적합한 전략이 달라집니다.

• Rehost: 그대로 이전
• Replatform: 일부 관리형 서비스로 변경
• Refactor: 구조적 재설계
• Repurchase: SaaS 등으로 교체
• Retain: 당분간 유지
• Retire: 폐기

AWS Transform이 변환을 지원하더라도 모든 애플리케이션을 자동으로 현대화할 수 있는 것은 아닙니다.

2) 애플리케이션 및 인프라 인벤토리

다음 정보를 확보해야 합니다.

• 서버, 운영체제, 미들웨어
• CPU·메모리·스토리지 사용량
• 실행 중인 프로세스
• 애플리케이션 간 호출 관계
• 데이터베이스 및 파일 공유
• 배치 작업 및 스케줄러
• 외부 시스템 연계
• 방화벽 및 네트워크 흐름
• 인증·권한·암호화 방식
• 라이선스와 상용 소프트웨어 제약
• RTO, RPO 및 업무 중요도

인벤토리가 부정확하면 Transform의 분석 결과와 마이그레이션 계획도 부정확해집니다.

3) 의존성 분석

특히 다음 의존성을 별도로 확인해야 합니다.

• 애플리케이션 간 호출
• 서버 간 TCP/UDP 통신
• 데이터베이스 연결
• 파일 시스템 및 공유 스토리지
• Active Directory 또는 LDAP
• DNS, NTP, SMTP
• 외부 API 및 파트너 시스템
• 배치 순서
• 인증서와 비밀정보
• 라이선스 서버
• 하드코딩된 IP 주소와 호스트명

AWS Transform 또는 Discovery 도구가 수집한 의존성은 관측된 트래픽과 설정에 기반합니다. 실행되지 않는 배치, 간헐적인 통신, 문서화되지 않은 수작업은 누락될 수 있습니다.

4) AWS 기반 준비 상태

마이그레이션 전에 다음 기반을 먼저 설계해야 합니다.

• AWS Organizations 및 계정 구조
• Landing Zone
• IAM 및 권한 모델
• VPC, 서브넷, 라우팅
• Direct Connect 또는 VPN
• 로그·모니터링·감사 체계
• 백업 및 재해복구
• 보안 기준과 가드레일
• 태깅 및 비용 배부 정책
• 운영 책임 모델
• 서비스 쿼터 및 리전 선택

AWS Transform은 이런 기반을 자동으로 대신 설계하지 않습니다.

5) 보안과 데이터 보호

다음 항목은 사전에 검토해야 합니다.

• 소스 코드에 비밀번호나 API 키가 포함되어 있는지
• 개인정보·금융정보·의료정보가 포함되는지
• AWS Transform에 제공되는 데이터의 저장·처리 위치
• IAM 최소 권한
• KMS 암호화
• CloudTrail 및 감사 로그
• 규제 및 데이터 주권
• 개발·검증·운영 환경 분리
• 서드파티 코드와 라이선스의 처리 방식

소스 코드나 구성 파일을 분석 도구에 전달할 때는 비밀정보 제거와 접근 권한 검토가 필수입니다.

2. AWS Transform 사용 전후 비교

구분	사용 전	사용 후
인벤토리	스프레드시트와 수작업 조사	자동 수집 및 중앙 추적
의존성	담당자 지식과 문서에 의존	관측된 통신·구성 기반 분석
변환	수작업 코드 수정	지원 범위 내 자동 변환 및 제안
테스트	개별 팀이 별도 수행	변환 결과 검증과 반복 작업 자동화 가능
계획	서버 단위 중심	애플리케이션·웨이브 단위 계획
운영	기존 방식 유지	AWS 모니터링·보안·자동화와 통합
리스크	누락된 의존성 가능성 높음	발견 가능성은 향상되지만 완전한 보장은 아님

3. AWS Transform이 생성할 수 있는 결과물

기능과 대상 플랫폼에 따라 다르지만 일반적으로 다음 유형의 결과물을 기대할 수 있습니다.

평가 및 인벤토리 결과

• 서버 및 애플리케이션 목록
• 운영체제와 런타임 정보
• 사용량 및 구성 정보
• 마이그레이션 대상 분류
• 마이그레이션 준비도
• 변환 가능성 또는 예상 난이도
• 예외 및 수동 조치가 필요한 항목

의존성 관련 결과

• 애플리케이션 간 관계
• 서버 간 네트워크 흐름
• 데이터베이스 연결
• 포트와 프로토콜
• 통신량 또는 관측 빈도
• 애플리케이션 그룹 후보
• 마이그레이션 웨이브 구성에 필요한 관계 정보

다만 “전체 의존성 그래프가 자동으로 완성된다”고 보면 안 됩니다. 다음은 누락될 가능성이 있습니다.

• 분석 기간에 실행되지 않은 통신
• 월간·분기별 배치
• 수작업 운영 절차
• 문서에만 존재하는 논리적 의존성
• 외부 파트너 시스템
• 라이선스 또는 계약상의 의존성

따라서 네트워크 흐름 분석 결과, 애플리케이션 담당자 인터뷰, CMDB, 소스 코드 분석, 배치 스케줄 검토를 함께 사용해야 합니다.

변환 결과

지원되는 대상에 따라 다음을 생성할 수 있습니다.

• 변환된 소스 코드
• 변경 내역 또는 변환 요약
• 컴파일·빌드 오류 목록
• 자동 변환이 불가능한 코드 목록
• 수작업 수정 지점
• 테스트 결과
• 변환 전후 비교 정보

자동 변환 결과는 운영 배포 전에 반드시 코드 리뷰, 보안 검사, 성능 시험, 회귀 테스트를 수행해야 합니다.

4. 마이그레이션 후 고려사항

기술 검증

• 기능 및 회귀 테스트
• 성능·부하 테스트
• 장애 복구 테스트
• 데이터 정합성 검증
• 배치 처리 시간 검증
• 네트워크 지연 검증
• 라이선스 동작 검증
• 보안 취약점 검사

운영 전환

• CloudWatch 모니터링
• 중앙 로그와 추적성
• 알람 및 온콜 체계
• 운영 Runbook
• 장애 대응 절차
• 백업 복구 절차
• 패치 및 취약점 관리
• 비용 알람 및 예산 통제

Well-Architected 관점

AWS Well-Architected Framework의 여섯 개 필러를 기준으로 검증하는 것이 좋습니다.

• 운영 우수성: 배포·모니터링·장애 대응 자동화
• 보안성: IAM, 암호화, 네트워크 통제, 감사
• 안정성: 다중 AZ, 백업, 복구, 용량 관리
• 성능 효율성: 적정 사이징, 캐시, 데이터베이스 최적화
• 비용 최적화: 사용량 기반 비용, 예약·Savings Plans, 미사용 리소스
• 지속 가능성: 자원 효율, 자동 중지, 적정 용량

마이그레이션 직후에는 단순히 “AWS에서 실행된다”는 기준이 아니라, 기존 환경보다 운영성과 보안성이 개선되었는지 확인해야 합니다.

5. 권장 실행 순서

단계 1: Discovery

서버, 애플리케이션, 데이터베이스, 통신 흐름과 업무 중요도를 수집합니다.

단계 2: Assessment

각 애플리케이션을 다음 기준으로 분류합니다.

• 마이그레이션 가능 여부
• 적합한 전략
• 난이도
• 업무 영향도
• 의존성
• 예상 비용
• 예상 다운타임
• 수동 작업량

단계 3: Pilot

업무 영향이 낮고 의존성이 단순한 애플리케이션을 선택합니다.

• 테스트 환경 변환
• 데이터 복제
• 애플리케이션 테스트
• 성능 비교
• 롤백 시험
• 운영팀 인수인계

단계 4: Wave Migration

의존성이 있는 애플리케이션을 그룹으로 묶어 순차적으로 이전합니다.

• 공통 기반 서비스
• 데이터베이스
• 백엔드 서비스
• API 및 미들웨어
• 프런트엔드
• 배치 및 외부 연계

단계 5: Cutover 및 Hypercare

전환 이후 일정 기간 집중 모니터링합니다.

• 오류율
• 응답 시간
• 데이터 지연
• 사용자 문의
• 비용 변동
• 배치 성공률
• 장애 및 롤백 가능성

단계 6: 최적화

안정화 후 다음을 수행합니다.

• 인스턴스 및 데이터베이스 적정 사이징
• 관리형 서비스 전환
• 자동 확장
• 비용 최적화
• 보안 기준 강화
• 운영 자동화
• 불필요한 리소스 제거

결론

AWS Transform은 인벤토리, 의존성 파악, 코드·구성 변환, 반복적인 마이그레이션 작업을 줄이는 데 유용합니다. 보고서와 의존성 정보도 생성할 수 있지만, 결과는 대상 서비스와 분석 범위에 따라 달라지며 완전한 시스템 의존성 문서로 간주해서는 안 됩니다.

가장 안전한 방식은 다음과 같습니다.

1. AWS Transform으로 자동 분석과 변환 수행
2. Application Discovery와 네트워크 흐름으로 의존성 보완
3. 담당자 인터뷰와 배치·외부 연계 검증
4. Migration Hub에서 애플리케이션 웨이브 관리
5. Well-Architected Review로 보안·안정성·비용 검증
6. 파일럿 후 단계적 전환

즉, AWS Transform은 “마이그레이션을 자동으로 완료하는 도구”라기보다 “분석과 변환 작업을 가속하는 도구”로 보는 것이 정확합니다.