온프레미스에서 AWS로, 어떻게 옮길까?
원문: AWS Cloud Practitioner Essentials — Module 9: Migration and Innovation
출처: AWS E-Learning / Compiled by Kenneth Leung (2020)
한 줄 요약: 클라우드 마이그레이션은 “누가, 무엇을, 어떻게 옮길 것인가”를 체계적으로 정리하는 과정이며, AWS는 이를 위한 프레임워크(CAF), 전략(6R’s), 물리 장비(Snow Family)까지 제공한다.
클라우드로 옮기려면, 먼저 누구와 이야기해야 할까? — AWS CAF
이미 온프레미스에서 운영 중인 시스템이 있다면, 클라우드 전환은 단순히 서버를 옮기는 기술적 작업이 아니다. 재무팀은 비용 구조가 어떻게 바뀌는지 알아야 하고, HR은 새로운 역할에 맞는 인재를 채용해야 하며, 보안팀은 기존 통제 체계를 클라우드에 맞게 재설계해야 한다. 이 모든 이해관계자를 한 방향으로 정렬해주는 도구가 바로 AWS Cloud Adoption Framework(AWS CAF)다.
AWS CAF는 마이그레이션에 필요한 가이드를 6개의 관점(Perspective)으로 나눈다. 크게 비즈니스 역량(Business, People, Governance)과 기술 역량(Platform, Security, Operations) 두 축으로 구분된다.
비즈니스 역량 — 왜, 누구와 옮길 것인가
| 관점 | 핵심 질문 | 주요 역할 |
|---|---|---|
| Business | IT 투자가 비즈니스 성과와 연결되는가? | 비즈니스 매니저, 재무 매니저, 전략 담당자 |
| People | 조직 구조와 역할, 필요한 스킬은 준비되었는가? | HR, 인력 관리자, 피플 매니저 |
| Governance | IT 전략이 비즈니스 전략과 정렬되어 있는가? | CIO, 프로그램 매니저, 엔터프라이즈 아키텍트 |
Business 관점은 클라우드 전환의 비즈니스 케이스를 만드는 데 집중한다. “왜 옮겨야 하는가”에 대한 답이다. People 관점은 조직 변화 관리를 다룬다. 새로운 기술에 맞는 교육, 채용, 조직 개편이 여기에 해당한다. Governance 관점은 IT와 비즈니스의 전략적 정렬을 담당하며, 클라우드 투자의 성과를 측정하고 리스크를 최소화하는 역할을 한다.
기술 역량 — 무엇을, 어떻게 옮길 것인가
| 관점 | 핵심 질문 | 주요 역할 |
|---|---|---|
| Platform | 클라우드 위에서 어떤 아키텍처로 구현할 것인가? | CTO, IT 매니저, 솔루션 아키텍트 |
| Security | 보안 목표(가시성, 감사, 통제, 민첩성)를 충족하는가? | CISO, IT 보안 매니저, IT 보안 분석가 |
| Operations | 일상 운영을 어떻게 수행하고 복구할 것인가? | IT 운영 매니저, IT 지원 매니저 |
Platform 관점은 온프레미스 워크로드를 클라우드로 옮기기 위한 아키텍처 원칙과 패턴을 다룬다. Security 관점은 보안 통제와 권한 체계를 클라우드 환경에 맞게 재구성하는 것이고, Operations 관점은 클라우드 환경에서의 일상 운영 절차와 프로세스 변경을 정의한다.
결국 AWS CAF가 말하는 것은 명확하다. 클라우드 전환은 기술팀만의 일이 아니라, 조직 전체가 함께 움직여야 하는 프로젝트라는 것이다.
옮기는 방법도 여섯 가지나 된다 — 마이그레이션 6R’s
기존 환경에 있는 애플리케이션을 클라우드로 옮길 때, 모든 앱을 같은 방식으로 옮기는 것은 비효율적이다. 시간, 비용, 우선순위, 중요도에 따라 6가지 전략(6R’s) 중 적합한 것을 선택한다.
| 전략 | 별칭 | 설명 | 적합한 상황 |
|---|---|---|---|
| Rehosting | Lift-and-shift | 애플리케이션을 변경 없이 그대로 옮긴다 | 대규모 레거시 마이그레이션을 빠르게 진행해야 할 때 |
| Replatforming | Lift, tinker, and shift | 핵심 코드는 그대로 두고, 일부 클라우드 최적화를 적용한다 | 코드 변경 없이 성능 이점을 얻고 싶을 때 (예: MySQL → RDS MySQL, Aurora) |
| Refactoring | Re-architecting | 클라우드 네이티브 기능을 활용해 아키텍처를 재설계한다 | 기존 환경에서 달성하기 어려운 기능, 확장성, 성능이 필요할 때 |
| Repurchasing | — | 기존 라이선스를 SaaS 모델로 교체한다 | 레거시 소프트웨어를 버리고 새 출발할 때 (예: 자체 CRM → Salesforce) |
| Retaining | — | 현재 환경에 그대로 둔다 | 곧 폐기될 앱이거나, 대규모 리팩토링이 선행되어야 하는 경우 |
| Retiring | — | 더 이상 필요 없는 애플리케이션을 폐기한다 | 이미 대체된 앱이나 사용하지 않는 앱 (전체의 10~20%에 해당) |
Rehosting은 가장 빠르고 단순하지만, 클라우드의 이점을 최대한 누리기는 어렵다. 반대로 Refactoring은 클라우드 네이티브의 장점을 가장 많이 살릴 수 있지만, 초기 비용과 인력 투자가 가장 크다. 그리고 간과하기 쉬운 Retiring — 실제로 기업 애플리케이션 포트폴리오의 10~20%는 이미 쓰지 않거나 대체된 상태라고 한다. 마이그레이션을 기회 삼아 이런 앱들을 정리하면 비용과 노력을 상당히 절약할 수 있다.
인터넷으로 옮기기엔 너무 많다면? — AWS Snow Family
데이터를 AWS로 옮기는 가장 일반적인 방법은 인터넷이나 Direct Connect를 이용하는 것이다. 하지만 데이터가 수십 테라바이트, 페타바이트 단위가 되면 이야기가 달라진다. 전용 1Gbps 회선으로 1페타바이트를 전송하면 이론적으로 약 100일이 걸리고, 실제로는 그보다 더 오래 걸린다.
이런 상황을 위해 AWS는 물리적 장비를 보내준다. 데이터를 장비에 담아서 AWS로 배송하면, AWS가 직접 업로드해주는 방식이다. 이것이 AWS Snow Family다.
| 장비 | 저장 용량 | 컴퓨팅 | 특징 |
|---|---|---|---|
| Snowcone | 8 TB | 2 CPUs, 4 GB 메모리 | 소형·견고. 분석 데이터, 영상, 백업 등 테라바이트 단위 전송에 적합 |
| Snowball Edge Storage Optimized | 80 TB HDD + 1 TB SSD | 40 vCPUs, 80 GiB 메모리 | 대규모 데이터 마이그레이션과 반복 전송 워크플로에 적합 |
| Snowball Edge Compute Optimized | 42 TB HDD + 7.68 TB NVMe SSD | 52 vCPUs, 208 GiB 메모리, GPU(선택) | ML, 영상 분석 등 원격지에서 강력한 컴퓨팅이 필요할 때 |
| Snowmobile | 100 PB | — | 45피트 컨테이너 트럭. 엑사바이트 규모 전송용 |
Snow Family의 모든 장비는 256비트 암호화가 자동 적용되며, 하드웨어와 소프트웨어 모두 암호학적 서명이 되어 있다. 암호화 키는 고객이 소유하고 관리하며, AWS Key Management Service(KMS)를 통해 키를 생성할 수도 있다.
Snowball Edge 장비는 단순한 저장 장치가 아니다. 현장에 연결하면 AWS Lambda 함수, EC2 호환 인스턴스, IoT Greengrass까지 실행할 수 있다. 인터넷이 불안정한 원격지에서 IoT 데이터 수집, 영상 압축, 산업 신호 처리 같은 작업을 현장에서 바로 처리할 수 있다는 뜻이다.
Snowmobile은 말 그대로 트럭이다. 45피트 길이의 강화 컨테이너로, 방수·온도 조절·화재 진압·GPS 추적은 물론 24시간 영상 감시와 전담 보안팀, 호위 차량까지 동반한다.
클라우드 위에서 무엇을 할 수 있을까? — 혁신 서비스
마이그레이션이 끝나면 그 다음은 혁신이다. AWS에서 새로운 가능성을 탐색할 때 중요한 것은 세 가지 질문이다: 지금 상태는 어떤가, 원하는 상태는 무엇인가, 해결하려는 문제는 무엇인가.
| 분야 | 서비스 | 설명 |
|---|---|---|
| 서버리스 | AWS Lambda | 서버 관리 없이 코드를 실행. 프로비저닝, 유지보수, 가용성을 AWS가 처리 |
| AI | Amazon Transcribe | 음성을 텍스트로 변환 |
| AI | Amazon Comprehend | 텍스트에서 패턴과 인사이트를 발견 |
| AI | Amazon Fraud Detector | 온라인 사기 활동을 탐지 |
| AI | Amazon Lex | 음성·텍스트 기반 챗봇 구축 (Alexa의 핵심 기술) |
| ML | Amazon SageMaker | ML 모델을 빠르게 빌드, 훈련, 배포. PhD 수준의 전문성 없이도 사용 가능 |
| ML | Amazon A2I | ML 사용 사례에 대한 사람 리뷰 워크플로 제공 (콘텐츠 검수, 문서 텍스트 추출 등) |
| ML | Amazon Textract | 문서에서 텍스트와 데이터를 추출 |
| IoT | AWS IoT | 전 세계 연결 장치 간 통신 지원 |
| 위성 | AWS Ground Station | 자체 위성 인프라 없이 위성 시간만 필요한 만큼 사용 |
서버리스는 개발자가 서버 운영 대신 핵심 제품에 집중할 수 있게 해준다. AI·ML 서비스는 복잡한 인프라 구축 없이 음성 인식, 텍스트 분석, 사기 탐지, 모델 훈련까지 가능하게 한다. AWS DeepRacer처럼 강화 학습(reinforcement learning)을 레이싱 환경에서 실험해볼 수 있는 서비스도 있다.
핵심 정리 — 이것만 기억하자
| 질문 | 답 |
|---|---|
| AWS CAF란? | 클라우드 전환 시 조직 전체의 역할과 책임을 6개 관점으로 정리한 프레임워크 |
| CAF의 비즈니스 역량 관점은? | Business, People, Governance |
| CAF의 기술 역량 관점은? | Platform, Security, Operations |
| 마이그레이션 6R’s는? | Rehost, Replatform, Refactor, Repurchase, Retain, Retire |
| Snow Family는 왜 필요한가? | 인터넷으로 옮기기엔 너무 큰 데이터를 물리적 장비로 전송하기 위해 |
| Snowmobile의 용량은? | 100 PB (45피트 컨테이너 트럭) |
마무리
클라우드 마이그레이션의 핵심은 결국 “모든 것을 한 번에, 한 가지 방법으로 옮길 필요는 없다”는 것이다. 어떤 앱은 그대로 들어올리고, 어떤 앱은 재설계하고, 어떤 앱은 과감히 폐기한다. 데이터가 너무 크면 트럭이 와서 실어간다. 이 유연함은 클라우드 전환에만 해당하는 이야기가 아니다. 변화를 맞이할 때 가장 중요한 것은 하나의 정답을 찾는 것이 아니라, 상황에 맞는 여러 선택지를 갖추는 것이다.