AWS 서비스 포트폴리오 재편: 클라우드 전략의 변화와 대응

AWS가 2025년 10월 29일, 20개 이상의 서비스와 기능에 대한 중요한 라이프사이클 변경을 발표했습니다. 이는 단순히 몇몇 서비스를 정리하는 것을 넘어, AWS의 장기적인 클라우드 전략 변화를 시사하는 매우 중요한 사건입니다. 저의 10년 이상 IT 인프라 실무 경험에 비춰볼 때, 이러한 대규모 포트폴리오 재편은 기업들이 클라우드 인프라를 설계하고 운영하는 방식에 큰 영향을 미칠 것입니다. 이제는 클라우드 서비스를 무조건적으로 수용하기보다, 그 서비스의 생명 주기와 전략적 가치를 면밀히 평가해야 하는 시대가 도래했습니다.

대규모 서비스 라이프사이클 변경의 배경

AWS의 이번 결정은 2024년 7월과 10월에 AWS CodeCommit, AWS App Mesh 등 일부 관리형 서비스의 신규 고객 접속 중단 발표 이후 두 번째 대규모 재편입니다. 이는 저조한 채택률을 보인 솔루션을 정리하고, 핵심 서비스에 엔지니어링 역량을 집중하려는 전략적 움직임으로 해석됩니다. 클라우드 시장이 성숙함에 따라 무작정 서비스 수를 늘리기보다, 실질적인 비즈니스 가치를 창출하는 소수 정예 서비스에 집중하겠다는 의지가 엿보입니다. 이처럼 클라우드 벤더의 포트폴리오 최적화는 앞으로도 계속될 중요한 트렌드입니다.

세 가지 라이프사이클 카테고리와 주요 영향 서비스

AWS는 이번에 서비스를 세 가지 라이프사이클 카테고리로 분류했습니다.

첫째, ‘Maintenance(유지보수)’ 단계로 전환되는 서비스들은 2025년 11월 7일부터 신규 고객에게는 제공되지 않습니다. 기존 고객은 대안 마련을 위한 유예 기간을 두면서 계속 사용할 수 있습니다. 여기에는 Amazon Glacier(오리지널 독립형 볼트 기반 서비스)가 포함되는데, 이는 API 통합의 일환으로 S3 Glacier 스토리지 클래스는 여전히 유효합니다. 이 경우, 기능적인 서비스 종료라기보다는 사용 편의성을 위한 통합으로 보는 것이 타당합니다.

S3 Object Lambda는 표준 Lambda 기능으로 대체되는 등, 핵심 기능이 더 나은 방식으로 통합되는 사례도 있습니다. 또한, Amazon CodeCatalyst처럼 출시 후 조용한 행보를 보였던 개발자 도구들도 이 단계에 포함되어 저조한 초기 도입률이 재편의 주요 원인임을 보여줍니다. AWS Mainframe Modernization Service는 그 기능이 AWS Transform이라는 새로운 통합 서비스로 흡수될 예정입니다. AWS Systems Manager – Change Manager와 Incident Manager 역시 이 유지보수 단계로 전환되며, 기존 고객은 계속 사용하지만 신규 프로젝트에서는 다른 대안을 찾아야 합니다.

둘째, ‘Sunset(단계적 중단)’ 단계의 서비스들은 즉시 마이그레이션 계획을 시작해야 합니다. 운영 및 지원 종료일은 향후 12개월 이내에 발표될 예정입니다. 대표적으로 Amazon FinSpace(2021년 출시), Amazon Lookout for Equipment, 그리고 AWS IoT Greengrass v1이 있습니다. 특히 Greengrass v1의 경우, 필드에 배포된 V1 인스턴스를 운영 중인 고객은 V2로의 업데이트라는 실질적인 운영 부담에 직면하게 됩니다. 이는 IoT 환경에서 디바이스 업데이트의 복잡성을 고려할 때, 상당한 시간과 리소스가 소요될 수 있는 문제입니다.

셋째, ‘End of Support(지원 종료)’ 단계인 AWS Mainframe Modernization App Testing 서비스는 이미 2025년 10월 7일부로 지원이 종료되었습니다. 이 서비스는 2024년 6월에 정식 출시되었으므로, 출시 후 불과 1년 만에 종료된 셈입니다. 이는 빠르게 변화하는 클라우드 환경에서 서비스 생명 주기가 얼마나 짧을 수 있는지를 여실히 보여줍니다. 이러한 사례는 새로운 AWS 서비스 중단 리스크를 최소화하기 위해 신중한 서비스 선택이 필요하다는 점을 강조합니다.

IT 인프라 아키텍트의 관점과 실무적 시사점

이번 AWS의 발표는 IT 인프라 아키텍트들에게 중요한 경고 메시지를 던집니다. Corey Quinn은 이번 대규모 서비스 정리를 “썩은 과일”을 솎아내는 과정으로 비유하며, AWS가 핵심 제품에 집중하여 고객에게 더 나은 경험을 제공하려는 노력이라고 평가했습니다. 그의 지적처럼, 너무 많은 서비스가 무분별하게 출시되면서 생긴 혼란을 정리하는 과정으로 볼 수 있습니다. 제가 실제 클라우드 환경을 설계하면서 느꼈던 점은, 특정 기능 하나 때문에 복잡한 파이프라인을 구성하기보다, 표준적이고 널리 사용되는 핵심 서비스 조합을 선택하는 것이 장기적인 안정성과 유지보수 측면에서 훨씬 유리하다는 것입니다.

Benjamen Pyle이 언급했듯이 “제품의 핵심 기능을 주변 서비스에 구축하지 말라”는 조언은 매우 현실적입니다. 엣지 컴퓨팅 영역의 Snowball Edge Compute Optimized 및 Storage Optimized 서비스처럼, 기존 사용자는 계속 이용할 수 있지만 신규 프로젝트에서는 대안을 모색해야 하는 경우가 발생합니다. 이는 아키텍처 설계 시 해당 서비스의 대중성과 커뮤니티 지원, 그리고 장기적인 로드맵을 면밀히 검토해야 함을 의미합니다. 단순히 ‘새로운 기능’이 있다는 이유만으로 검증되지 않은 서비스에 의존하는 것은 미래의 기술 부채로 이어질 수 있습니다. 핵심 AWS 서비스 중단 사태를 피하기 위해서는 서비스 선택 시 신중한 접근이 필수적입니다.

클라우드 인프라 운영 및 마이그레이션 전략

이번 서비스 재편은 기업들에게 클라우드 인프라 운영의 유연성과 AWS 마이그레이션 역량의 중요성을 다시 한번 상기시킵니다. AWS는 고객들이 필요한 전환을 할 수 있도록 포괄적인 마이그레이션 가이드와 지원팀을 제공한다고 밝혔습니다. 하지만 실제 마이그레이션은 단순히 가이드라인을 따르는 것을 넘어, 기존 시스템의 복잡성, 데이터 의존성, 그리고 비즈니스 연속성 확보 등 다양한 변수를 고려해야 합니다. 특히 Greengrass v1처럼 물리적 디바이스에 배포된 경우, 원격 업데이트 프로세스 설계와 테스트는 상당한 시간과 자원을 요구할 수 있습니다.

클라우드 환경에서 서비스를 설계하고 운영할 때는 항상 대체 가능한 아키텍처를 염두에 두어야 합니다. 예를 들어, 특정 관리형 서비스에 과도하게 의존하기보다는, 오픈 소스 기반의 컨테이너 기술(Kubernetes 등)이나 서버리스 함수(Lambda)와 같이 유연하게 확장 및 교체 가능한 요소를 적극적으로 활용하는 것이 좋습니다. 이러한 접근 방식은 벤더 종속성을 줄이고, 향후 예상치 못한 서비스 변경에도 빠르게 대응할 수 있는 강력한 클라우드 아키텍처를 구축하는 데 기여합니다. 지속적인 기술 트렌드 파악과 아키텍처 리팩토링 계획은 이제 선택이 아닌 필수가 된 셈입니다. 이번 AWS 포트폴리오 최적화는 우리에게 중요한 숙제를 던져주고 있습니다.

변화하는 AWS 클라우드 환경, 현명한 대응 전략이 필요합니다

AWS의 대규모 서비스 포트폴리오 재편은 클라우드 서비스 제공자들도 끊임없이 변화하고 진화한다는 것을 보여줍니다. 이는 기업들이 클라우드 인프라를 계획하고 운영할 때, 단기적인 효율성뿐만 아니라 장기적인 안정성과 유연성을 최우선으로 고려해야 함을 의미합니다. 저의 실무 경험상, 특정 서비스의 기능만을 쫓기보다는 핵심 서비스의 견고함과 발전 가능성을 보고 선택하는 것이 중요합니다. 이번 사태를 통해 얻을 수 있는 가장 큰 교훈은, 견고한 클라우드 전략을 수립하고, 기술 스택을 주기적으로 점검하며, 마이그레이션 플랜을 미리 준비하는 것이 중요하다는 것입니다. 급변하는 클라우드 세상에서 지속적인 학습과 유연한 사고만이 성공적인 IT 인프라를 위한 길입니다.

참고: AWS Culls Portfolio: Over 20 Services Shift to Maintenance or Sunset – InfoQ, 2025