cloud-migration

레거시 아키텍처에서 Cloudflare One으로의 전환 (새 탭에서 열림)

전통적인 VPN 중심의 레거시 아키텍처에서 제로 트러스트(Zero Trust) 및 SASE 아키텍처로 전환하는 과정은 '빅뱅' 방식의 일괄 마이그레이션이 수반하는 가동 중단 위험 때문에 많은 기업에 큰 부담이 됩니다. Cloudflare와 CDW는 이러한 위험을 줄이기 위해 모든 애플리케이션을 복잡도에 따라 계층화하고, 레거시 앱을 현대적인 보안 계층으로 감싸는 단계적 방법론을 제시합니다. 결과적으로 기업은 서비스 중단 없이 보안 부채를 해결하고, 신원 및 기기 상태 기반의 정교한 보안 태세를 구축할 수 있습니다. ### 단계별 방법론을 통한 마이그레이션 함정 회피 단순히 네트워크 연결 방식만 바꾸는 '리프트 앤 시프트(Lift and Shift)' 방식은 복잡한 애플리케이션 간의 상호 의존성을 간과하여 대규모 장애를 초래할 수 있습니다. * **리스크 기반 계층화:** 모든 애플리케이션을 기술적 복잡도에 따라 분류하고, 현대적인 앱부터 우선 이동하여 동력을 확보한 뒤 복잡한 레거시 시스템을 나중에 제어된 환경에서 전환합니다. * **실패 사례 분석:** 500개 이상의 앱을 한꺼번에 이전하려다 서비스 중단을 겪은 공공 부문 사례를 교훈 삼아, 마이그레이션을 단순 연결 교체가 아닌 '애플리케이션 현대화 프로젝트'로 취급합니다. * **보안 내재화:** 마이그레이션 전략 수립 단계부터 보안 요구사항을 기초 아키텍처에 포함하여, 사후에 보안을 덧붙이는 방식에서 벗어납니다. ### Cloudflare Access와 Tunnel을 활용한 레거시 현대화 레거시 애플리케이션의 코드를 수정하지 않고도 Cloudflare Access를 통해 제로 트러스트 모델을 적용하여 보안 수준을 높일 수 있습니다. * **VPN 경계 대체:** 특정 네트워크 세그먼트 전체에 권한을 주는 VPN 대신, 신원과 기기 상태를 기반으로 모든 개별 요청을 평가하는 모델로 전환합니다. * **Cloudflare Tunnel 활용:** 외부 노출 없이 내부에서 외부로 나가는(Outbound-only) 연결을 생성하여, 레거시 앱에 공인 IP 주소를 부여하지 않고도 안전하게 외부에 노출할 수 있습니다. * **보안 래핑(Wrapping):** 자체 MFA(다요소 인증) 기능이 없는 구형 앱에 SSO 및 하드웨어 기반 MFA를 강제 적용하며, 데이터가 서버에 도달하기 전 엣지(Edge) 단에서 보안 정책을 검증합니다. ### 마이그레이션 전 아키텍처 감사 및 준비 사항 안정적인 전환을 위해 IT 리더는 파일럿 프로젝트 이전에 환경의 기술적 호환성을 철저히 점검해야 합니다. * **ID 제공업체 및 종속성 맵핑:** Okta와 같은 페더레이션 ID 제공업체 활용 여부를 확인하고, 백엔드 데이터베이스나 API 호출 관계를 문서화하여 서비스 단절을 방지합니다. * **전략과 실행 그룹의 분리(Firebreak):** 보안 표준을 설정하는 전략 그룹과 효율성을 중시하는 실행 그룹을 분리하여, 배포 속도 때문에 보안 요건이 무시되지 않도록 합니다. * **세션 지속성 테스트:** 셀룰러 타워 전환 시에도 세션이 유지되어야 하는 앱을 식별하고, Cloudflare의 PMTUD(Dynamic Path MTU Discovery) 기술을 통해 안정적인 연결을 보장합니다. ### 애플리케이션 유형별 마이그레이션 전략 전환에 소요되는 시간과 노력을 기준으로 애플리케이션을 세 가지 티어로 분류하여 현실적인 일정을 수립합니다. * **Tier 0 (SaaS):** 현대적인 인증 프로토콜을 지원하는 앱으로, 클라이언트리스 프록시를 통해 1~3시간 내외로 빠르게 전환 가능합니다. * **Tier 1 (내부 웹 앱):** 현대적 웹 프로토콜을 사용하는 내부 앱으로, Cloudflare Tunnel을 활용해 3~6시간 정도 소요됩니다. * **Tier 2 (비 웹 및 Thick-Client):** 특정 포트나 프로토콜 지원이 필요한 앱으로, Cloudflare One Client와 Tunnel을 병행 배포해야 하며 앱당 4~8시간이 소요됩니다. 성공적인 제로 트러스트 전환을 위해서는 속도보다 **'가시성'과 '단계적 접근'**이 중요합니다. 레거시 시스템을 한꺼번에 교체하려 하기보다, Cloudflare의 엣지 보안 계층으로 기존 앱을 보호하면서 점진적으로 현대화해 나가는 것이 운영 안정성을 확보하는 최선의 방법입니다.

Figma에서의 속도 탐 (새 탭에서 열림)

피그마(Figma)는 기존 EC2 기반의 레거시 인프라가 성장을 저해하자, 개발자 생산성과 시스템 확장성을 확보하기 위해 쿠버네티스(Kubernetes, K8s) 전환을 결정했습니다. 이들은 단순한 인프라 교체를 넘어 내부 추상화 도구를 통한 '골든 패스(Golden Path)'를 구축함으로써 1년 미만이라는 짧은 기간 내에 주요 핵심 서비스를 성공적으로 이전했습니다. 결과적으로 인프라 운영의 복잡성을 낮추면서도 대규모 트래픽을 효율적으로 수용할 수 있는 현대적인 컴퓨팅 환경을 마련했습니다. ### 기존 인프라의 한계와 전환 배경 * 기존의 Chef와 Puppet 기반 EC2 환경은 배포 속도가 느리고 수동 설정이 많아 급격한 사용자 증가에 따른 스케일링 대응에 한계가 있었습니다. * 인프라 팀이 모든 프로비저닝 요청의 병목지점이 되면서 개발팀의 자율성이 저하되고, 환경 간 일관성을 유지하기 어려운 문제가 발생했습니다. * 애플리케이션의 이식성을 높이고 리소스 효율성을 극대화하기 위해 컨테이너 중심의 관리 체계로의 패러다임 전환이 필수적이었습니다. ### 개발자 경험 중심의 추상화 레이어 구축 * 개발자가 쿠버네티스의 복잡한 YAML 명세나 `kubectl` 명령어를 직접 학습하지 않아도 되도록 내부 플랫폼 인터페이스를 설계했습니다. * 표준화된 서비스 정의와 배포 프로세스를 제공하는 내부 도구를 통해, 개발자는 몇 가지 설정만으로도 보안과 모니터링이 적용된 인프라를 즉시 할당받을 수 있게 되었습니다. * 이러한 '추상화'는 인프라 팀이 하부 구조를 변경하더라도 상위의 개발자 워크플로우에는 영향을 주지 않는 유연성을 제공했습니다. ### 점진적 마이그레이션과 안정성 확보 전략 * '빅뱅' 방식의 전환 대신, 기존 EC2 서비스와 새로운 K8s 서비스를 병행 운영하며 트래픽을 단계적으로 전환하는 방식을 채택했습니다. * 실제 트래픽을 복제하여 새로운 환경의 안정성을 미리 검증하는 '섀도우 트래픽(Shadow Traffic)' 테스트를 통해 마이그레이션 시 발생할 수 있는 리스크를 사전에 차단했습니다. * 전환 과정에서의 데이터 정합성 유지와 네트워크 지연 시간을 최소화하기 위해 서비스 메쉬 및 전용 커넥터를 활용하여 두 환경 간의 통신을 최적화했습니다. 대규모 인프라 마이그레이션의 성공은 단순히 기술적 스택을 바꾸는 것이 아니라, 개발자의 진입 장벽을 낮추는 내부 플랫폼 설계에 달려 있습니다. 복잡한 기술적 세부 사항을 추상화하고 점진적인 검증 절차를 거치는 전략은 서비스 중단 없이 대규모 시스템을 현대화하려는 조직에게 훌륭한 본보기가 됩니다.