Cloud Adoption Framework(CAF) 실전 도입기: 한국 기업이 놓치기 쉬운 포인트

작성자:



Azure Cloud Adoption Framework 기업 클라우드 전략
Photo by NASA on Unsplash

Cloud Adoption Framework(이하 CAF)는 Microsoft가 제공하는 Azure 클라우드 도입 방법론입니다. 전 세계 수천 개 기업이 CAF를 따라 클라우드를 도입하지만, 막상 한국 기업 환경에 적용하려고 하면 공식 문서만으로는 해결되지 않는 갭이 많습니다. 이번 글에서는 실제 금융·보험 기업에서 CAF를 적용하면서 겪은 한국 특유의 이슈들을 공유합니다.

CAF 개요

CAF는 크게 6개 단계로 구성됩니다.

  • Strategy: 비즈니스 동인과 목표 정의
  • Plan: 도입 계획 수립, 스킬 갭 분석
  • Ready: 랜딩존 구축, 초기 환경 준비
  • Adopt: 워크로드 마이그레이션 및 혁신
  • Govern: 거버넌스 정책 수립 및 준수
  • Manage: 운영 관리 체계 구축

한국 기업 도입 시 주의할 5가지 포인트

1. 리전 선택 — Korea Central vs Japan East

공식 문서에서는 “주 리전(Primary) + 페어 리전(Paired)” 조합을 권장합니다. 한국의 페어는 Korea Central ↔ Korea South입니다. 하지만 실제 프로젝트에서는 다음 이슈가 발생합니다.

  • Korea South의 서비스 격차: Korea Central보다 지원 서비스가 적음. 특정 PaaS는 사용 불가
  • 데이터 주권 이슈: 금융 감독 당국은 데이터의 국내 보관을 요구. Japan East로 DR 구성은 감독 승인 필요
  • 지연 시간: Japan East와 Korea Central 간 RTT는 약 30~40ms. 싱크로너스 복제에는 불리

실무 해결책:

  • Tier 1 서비스: Korea Central + Korea South (비용 감수)
  • Tier 2 서비스: Korea Central 단독 + GRS 백업
  • 글로벌 서비스: Korea Central + Japan East (컴플라이언스 검토 후)

2. 네트워크 설계 — 망 분리 규정과의 충돌

한국 금융권의 전자금융감독규정은 업무망과 인터넷망의 물리적 분리를 요구합니다. Azure 같은 퍼블릭 클라우드를 도입할 때 이 규정을 어떻게 충족시킬지가 가장 큰 숙제입니다.

실무에서 검토한 접근법:

  • ExpressRoute를 통한 전용선 연결
  • Private Link로 모든 PaaS 서비스 내부망 접근
  • Azure Firewall + UDR로 인터넷 경로 완전 차단
  • 감독 당국의 중요도 등급별 배포 승인 절차 준수

3. 관리 그룹(Management Group) 구조 설계

CAF 공식 예시는 주로 글로벌 다국적 기업 기준입니다. 한국 중견·대기업 구조에 맞게 재설계해야 합니다.

한국 기업 현실에 맞는 예시 구조:

  • Root Management Group
    • Platform (공통 인프라)
      • Identity, Management, Connectivity
    • Landing Zones (업무 워크로드)
      • Corp (내부 시스템), Online (고객 서비스)
    • Sandbox (개발자 자유 환경)
    • Decommissioned (정리 중)
클라우드 거버넌스 기업 아키텍처 설계
Photo by Luke Chesser on Unsplash

4. Policy 적용 — 과도한 제한이 만드는 부작용

CAF는 보안과 컴플라이언스를 위해 Azure Policy를 적극 활용하도록 권장합니다. 하지만 처음부터 너무 많은 정책을 Deny 모드로 적용하면 개발자들이 아무것도 할 수 없는 상황이 발생합니다.

단계적 적용 전략:

  • Phase 1: 모든 정책을 Audit 모드로 적용. 위반 현황 파악
  • Phase 2: 핵심 보안 정책만 Deny로 전환 (퍼블릭 IP 금지, 특정 SKU 제한 등)
  • Phase 3: 점진적으로 Deny 범위 확대. 예외 프로세스 병행

5. 비용 관리 — 부서별 Chargeback 구현

한국 기업의 예산 편성 방식은 부서별·사업부별로 세분화되어 있습니다. CAF에서 제시하는 Tag 기반 Cost Allocation만으로는 부족합니다.

실무에서 구축한 구조:

  • Subscription 단위를 사업부별로 분리 (Billing 단위)
  • Resource Group 단위를 서비스별로 분리
  • Tag 체계: cost-center, environment, owner, project-code
  • Azure Cost Management API로 매월 자동 Chargeback 리포트 생성

한국 기업 도입 순서 권장안

1단계: Strategy & Plan (1~2개월)

  • 임원진 설득 자료 준비 (ROI 계산, 경쟁사 벤치마크)
  • 레거시 시스템 자산 조사
  • 마이그레이션 후보 워크로드 선정

2단계: Ready (2~3개월)

  • 구독 구조 설계 및 생성
  • 관리 그룹 계층 구성
  • 랜딩존 배포 (Bicep 또는 Terraform)
  • ExpressRoute 또는 VPN 연결

3단계: Adopt — Pilot (2~3개월)

  • 비즈니스 영향이 적은 워크로드 1~2개 선정
  • 마이그레이션 및 검증
  • 운영 가이드 작성

4단계: Adopt — Scale (6개월 이상)

  • 본격적인 마이그레이션 확대
  • DevOps·SRE 팀 구축
  • 지속적 최적화

흔히 하는 실수

  • Ready 단계 생략: 랜딩존 없이 바로 워크로드 배포. 나중에 모두 재배포 필요
  • Tag 설계 부족: 비용 분석이 불가능해짐
  • 거버넌스 후행: 모든 리소스가 배포된 후 정책 적용 시 충돌 대량 발생
  • 사내 스킬 갭 무시: 인프라 팀의 재교육 없이 CAF 적용은 실패

마무리

CAF는 참고 프레임워크이지 절대적 정답이 아닙니다. 한국 기업 환경에서는 감독 규제, 조직 구조, 개발 문화를 반영한 커스터마이징이 필수입니다. 공식 문서를 맹신하지 말고, 내 조직에 맞게 취사선택하세요.

댓글 남기기