인프라가 분산되고, CSP가 AI로 방향을 틀면서, 클라우드 생태계 전체가 근본적으로 재편되고 있습니다. 과거의 역할과 관계가 무너지고, 새로운 균형점을 찾아가는 중입니다.
하이퍼스케일러를 어떻게 정의해야 할까요? 10년 전이었다면 답은 명확했습니다.
인프라 제공자. 서버, 스토리지, 네트워크를 빌려주는 회사. 하지만 지금은 다릅니다.
그들은 세 가지 정체성을 동시에 가지고 있고, 그 우선순위는 갈수록 명확해지고 있습니다.
첫 번째 정체성은 AI 플랫폼 사업자입니다.
AWS Bedrock는 단순한 API가 아닙니다. Claude, Llama, Mistral 같은 다양한 LLM 중에서 선택하고, 자신의 데이터로 파인튜닝하고, RAG(Retrieval-Augmented Generation)로 기업 지식을 연결하고, 벡터 데이터베이스에 임베딩을 저장하고, 프롬프트를 관리하고, 가드레일로 출력을 제어하고, 전체 과정을 모니터링하는 완전한 AI 구축 플랫폼입니다.
Azure AI도 마찬가지입니다.
Azure OpenAI Service로 GPT-4를 기업 환경에 배포하고, Azure AI Studio로 전체 라이프사이클을 관리하고, Prompt Flow로 복잡한 AI 워크플로우를 구축합니다.
Google의 Vertex AI도 같은 방향입니다. Gemini 모델을 서빙하고, AI Platform으로 MLOps를 통합하고, Vector Search로 의미론적 검색을 제공합니다.
한번 이런 플랫폼에 들어오면 나가기 어렵습니다.
프롬프트는 플랫폼별로 최적화되고, 벡터 데이터베이스는 고유 형식으로 저장되며, 워크플로우는 플랫폼 API에 깊숙이 통합됩니다. 클라우드 락인보다 AI 플랫폼 락인이 훨씬 더 강력합니다.
EC2에서 돌리는 애플리케이션은 다른 클라우드로 옮길 수 있습니다. 하지만 Bedrock으로 구축한 AI 에이전트는? 거의 전면 재작성입니다.
두 번째 정체성은 칩 제조사입니다.
AWS는 Graviton 프로세서로 시작해서 이제 Trainium(훈련용), Inferentia(추론용) AI 칩까지 만듭니다. Google은 10년 넘게 TPU를 개발해왔습니다. Microsoft도 2023년 자체 AI 칩 Maia를 공개했습니다.
왜 그들은 칩을 직접 만들까요?
표면적으로는 NVIDIA 의존도를 줄이기 위해서입니다.
H100 GPU 한 장에 3만 달러, 대량 구매해도 NVIDIA가 가격과 공급을 통제합니다.
하지만 더 깊은 이유가 있습니다. 애플이 iPhone에 자체 칩을 넣은 것처럼, 하드웨어부터 소프트웨어까지 수직 통합하려는 전략입니다. 칩을 직접 설계하면, 자신들의 워크로드에 최적화할 수 있습니다.
AWS Lambda를 위한 칩, Bedrock을 위한 칩, 특정 AI 모델을 위한 칩. 범용 칩보다 훨씬 효율적입니다.
그리고 2025년이 되면서 이 자체 칩들의 비중이 늘고 있습니다.
AWS는 최근 2년간 신규 CPU 용량의 50% 이상을 Graviton 기반으로 배포하고 있으며, 상위 1000개 EC2 고객의 90% 이상이 Graviton을 사용하고 있습니다.
AI 훈련 쪽에서는 일부 내부 워크로드와 고객 워크로드를 Trainium으로 이전하며 비중을 늘려가고 있지만, 외부 리포트 기준으로는 대규모 AI 훈련의 상당 부분은 여전히 NVIDIA GPU가 담당하고 있습니다.
Google도 TPU 비중을 계속 늘립니다.
고객 입장에서는 특정 CSP의 자체 칩에 더 깊이 의존하게 되는 반면, CSP는 수직 통합을 통해 하드웨어부터 소프트웨어까지 통제력을 키우려는 방향으로 보입니다.
세 번째 정체성은 여전히 인프라 제공자입니다.
EC2는 계속 새로운 인스턴스 타입을 출시하고, Azure VM은 더 빠른 네트워킹을 제공하며, Google Compute Engine은 더 나은 가격 성능비를 자랑합니다. 데이터베이스도 개선되고, 스토리지도 더 저렴해지고, 네트워크도 더 빨라집니다.
하지만 이것은 전략적 우선순위가 아닙니다. 유지보수입니다.
기존 고객들이 계속 쓰고 있으니, 당연히 개선은 해야 합니다. 하지만 새로운 혁신은 여기에 집중되지 않습니다. 최근 re:Invent, Microsoft Build, Google Cloud Next 같은 주요 키노트에서 AI·LLM·자체 칩 관련 내용이 대부분의 시간을 차지하고, EC2·RDS 등 전통 인프라 개선 사항은 상대적으로 짧게 언급되는 것이 이를 보여줍니다.
이 세 정체성의 우선순위는 명확합니다.
AI 플랫폼이 첫 번째, 자체 칩이 두 번째, 전통적 인프라는 세 번째입니다.
기존 워크로드는 "당연히 계속 지원하지만, 우리의 미래는 AI에 있다"는 메시지입니다.
이런 변화 속에서 고객들은 어려운 선택에 직면했습니다. 세 가지 길이 있는데, 어느 것도 완벽하지 않습니다.
첫 번째 길은 CSP가 제시하는 AI의 길을 따라가는 것입니다.
AWS Bedrock에 AI 워크플로우를 구축하고, Azure OpenAI로 챗봇을 만들고, Vertex AI로 추천 시스템을 개발합니다. 이 길은 빠릅니다. 몇 주 안에 프로토타입을 만들 수 있고, 확장성도 보장됩니다. CSP가 인프라, 모델, 도구를 모두 제공하니 편합니다.
하지만 락인이 심각합니다.
Bedrock으로 구축한 에이전트를 Azure AI로 옮기려면? 프롬프트 체인, RAG 파이프라인, 벡터 검색, 가드레일 로직을 모두 다시 작성해야 합니다. 각 플랫폼의 API, 데이터 형식, 워크플로우 모델이 다르기 때문입니다. 상당 부분 재작성이 필요합니다. 클라우드 인프라 락인보다 AI 플랫폼 락인이 체감상 더 강하게 느껴질 수 있습니다.
그리고 비용은 예측할 수 없습니다.
AI API 가격이 얼마나 안정적일까요? 지금은 경쟁이 치열해서 가격이 내려가고 있지만, 시장이 안정화되면? OpenAI는 몇 년 사이에 가격을 여러 번 바꿨습니다. 토큰당 비용, 컨텍스트 윈도우 크기, 응답 속도 보장. 이 모든 것이 변수입니다. 지금 AI API에 전사 시스템을 올려놓으면, 3년 후 비용이 어떻게 될지 누가 알 수 있을까요?
두 번째 길은 기존 인프라를 그대로 유지하는 것입니다.
ERP는 계속 SAP에서 돌아가고, CRM은 Salesforce에 있고, 데이터베이스는 온프레미스 SQL Server에 남아 있습니다. 이 길은 안전합니다. 검증되었고, 안정적이며, 비용도 예측 가능합니다.
하지만 미래가 불확실합니다. 5년 후, 10년 후에도 이 시스템들이 경쟁력이 있을까요?
AI가 통합되지 않은 ERP로 어떻게 실시간 수요 예측을 할 수 있을까요? AI 없는 CRM으로 어떻게 고객 이탈을 사전에 감지할 수 있을까요? 경쟁사들이 AI로 무장하는 동안, 우리만 전통적인 시스템을 쓰고 있으면 뒤처집니다.
그리고 언젠가는 전환해야 합니다. 그때가 언제가 좋을까요? 지금 전환하면 리스크가 크지만 경쟁 우위를 얻을 수 있습니다. 나중에 전환하면 안전하지만 이미 시장을 놓칠 수 있습니다. 기다리다가 너무 늦으면, 급하게 전환하면서 더 큰 혼란을 겪을 수도 있습니다.
세 번째 길은 하이브리드로 분산하는 것입니다.
중요한 데이터는 온프레미스에 두고, AI 실험은 클라우드에서 하고, 엣지에서 실시간 추론을 처리합니다.
이론적으로는 가장 현실적인 선택처럼 보입니다.
각 워크로드를 최적의 위치에 배치하고, 리스크를 분산하고, 점진적으로 전환할 수 있습니다.
하지만 복잡도가 문제입니다.
온프레미스 데이터센터, AWS, Azure, 엣지 디바이스를 동시에 관리하려면 어떻게 해야 할까요?
네트워킹은 어떻게 구성해야 할까요? VPN? Direct Connect? 엣지와 클라우드 간 데이터 동기화는? 보안 정책은 각 환경마다 다르게 설정해야 합니다. IAM, 방화벽 규칙, 암호화 키 관리. 세 배의 복잡도입니다.
팀 규모도 문제입니다. 온프레미스를 관리하려면 전통적인 IT 인력이 필요하고, 클라우드를 운영하려면 DevOps 엔지니어가 필요하며, AI를 개발하려면 ML 엔지니어가 필요합니다. 각 분야의 전문가를 모두 확보할 수 있는 기업이 얼마나 될까요? 중소기업은 말할 것도 없고, 대기업도 쉽지 않습니다.
결국 완벽한 답은 없습니다.
AI를 따라가면 락인과 비용 리스크를, 기존을 유지하면 경쟁력 상실 리스크를, 하이브리드를 선택하면 복잡도 리스크를 감수해야 합니다.
어느 리스크를 선택하느냐의 문제입니다.
이 혼란과 복잡도 속에서 새로운 플레이어들이 기회를 찾고 있습니다.
MSP(Managed Service Provider)와 소프트웨어 벤더들입니다.
MSP는 번역자가 되었습니다.
AWS만 해도 200개가 넘는 서비스를 제공하고, 각 서비스마다 수백 페이지의 문서가 있습니다. IAM 정책은 JSON으로 작성해야 하고, VPC 서브넷 설계는 CIDR 블록을 이해해야 하며, Auto Scaling 정책은 CloudWatch 메트릭을 읽을 수 있어야 합니다. 이 모든 것을 이해하고 최적화할 시간이 기업에게 있을까요?
MSP는 고객의 비즈니스 요구사항을 듣고, 그것을 클라우드 아키텍처로 번역합니다.
"우리 이커머스 사이트는 11월 블랙프라이데이에 트래픽이 평소의 50배가 됩니다"라는 말을 듣고, "그러면 Auto Scaling Group을 이렇게 설정하고, Reserved Instance는 기본 용량만큼만 구매하고, 피크는 Spot Instance로 처리하면 비용을 40% 줄일 수 있습니다"라고 제안합니다.
이것이 MSP의 핵심 가치입니다. 기술을 비즈니스 언어로 번역하고, 수백 개의 선택지 중에서 고객에게 맞는 것을 찾아주고, 실제로 구현하고 운영까지 책임집니다.
고객은 "어떤 EC2 인스턴스 타입을 써야 하나"를 고민하는 대신, "우리 서비스가 빠르게 응답하는가"에만 집중할 수 있습니다.
MSP는 통합자이기도 합니다.
멀티클라우드, 하이브리드 환경을 단일 인터페이스로 관리하는 것은 쉽지 않습니다.
AWS Console, Azure Portal, Google Cloud Console을 매일 오가면서 각각의 모니터링, 로깅, 비용 관리를 따로 해야 합니다. 장애가 나면 어느 클라우드의 문제인지 먼저 찾아야 합니다.
MSP는 Terraform으로 인프라를 코드화해서 여러 클라우드를 일관되게 관리하고, Kubernetes로 애플리케이션을 플랫폼 중립적으로 배포하며, Datadog이나 New Relic 같은 통합 모니터링 도구로 모든 환경을 한눈에 볼 수 있게 해줍니다.
고객에게는 "어디에 있는지"보다 "잘 돌아가는지"가 중요합니다. MSP는 그것을 가능하게 합니다.
소프트웨어 벤더들은 플랫폼 중립성을 무기로 삼고 있습니다.
Databricks 예를 들어보겠습니다.
AWS, Azure, GCP 어디서든 같은 경험을 제공합니다. 노트북, 워크플로우, 데이터 파이프라인이 모두 동일합니다. 클라우드를 바꿔도 Databricks 코드는 그대로 돌아갑니다.
Snowflake도 마찬가지입니다. 데이터 웨어하우스를 어느 클라우드에 올리든, SQL 쿼리, 데이터 공유, 보안 정책이 일관됩니다.
MongoDB Atlas, Confluent Cloud, Elastic Cloud도 모두 멀티클라우드입니다.
고객에게 선택권을 주는 것입니다. "우리 제품을 쓰면, 언제든 클라우드를 바꿀 수 있습니다. 한 CSP에 종속되지 않아도 됩니다." 락인을 줄여주는 것이 그들의 가치 제안입니다.
물론 이것도 완전한 독립은 아닙니다.
Databricks는 결국 AWS S3나 Azure Blob Storage에 데이터를 저장하고, Snowflake도 클라우드 컴퓨팅을 씁니다. 완전히 클라우드에서 벗어날 수는 없습니다. 다만 한 겹의 추상화 레이어를 제공할 뿐입니다.
하지만 그 한 겹이 중요합니다. 직접 CSP API를 쓰는 것보다 이동 비용이 훨씬 낮기 때문입니다.
생태계는 혼란스럽지만, 서서히 새로운 균형을 찾아가고 있습니다.
CSP는 AI와 대규모 컴퓨팅에 집중합니다. 그들의 강점은 규모입니다.
수십만 개의 GPU를 하나의 클러스터로 묶고, 페타바이트급 데이터를 실시간으로 처리하고, 전 세계 수백 개 리전에서 일관된 서비스를 제공하는 것은 CSP만 할 수 있는 일입니다.
기존 인프라도 계속 제공하지만, 혁신의 초점은 AI입니다.
새로운 EC2 인스턴스보다 새로운 AI 칩에 투자하고, RDS 개선보다 Bedrock 기능 추가에 더 많은 엔지니어를 투입합니다.
기업들은 워크로드를 분류하고 전략적으로 배치하기 시작했습니다.
"모든 것을 클라우드에"라는 단순한 시대는 끝났습니다.
각 워크로드의 특성을 이해하고 최적의 위치를 찾습니다.
예측 가능하고 안정적인 워크로드는 온프레미스로 가져오고, 트래픽이 급변하는 워크로드는 클라우드에 두고, 지연 시간에 민감한 워크로드는 엣지로 내립니다.
클라우드 스마트(Cloud Smart)입니다.
MSP와 벤더는 복잡도를 관리하는 역할을 맡습니다.
분산된 환경을 운영하는 것은 어렵습니다. 온프레미스, 멀티클라우드, 엣지를 동시에 다루려면 전문성과 도구가 필요합니다. MSP는 이 복잡도를 줄여주고, 벤더는 플랫폼 중립적인 레이어를 제공합니다.
덕분에 고객은 인프라의 세부사항이 아니라 비즈니스 가치에 집중할 수 있습니다.
이것이 성숙한 클라우드 생태계의 모습입니다.
단일 플레이어의 지배가 아니라, 여러 플레이어가 각자의 강점을 살리며 협력하고 경쟁하는 구조입니다.
CSP는 규모와 혁신을, MSP는 전문성과 통합을, 벤더는 유연성과 중립성을 제공합니다.
고객은 이들 중에서 자신에게 맞는 조합을 선택합니다.
기술은 빠르게 발전합니다. 매년 새로운 프레임워크가 나오고, 새로운 아키텍처 패턴이 등장하며, 새로운 "베스트 프랙티스"가 선언됩니다. 하지만 전략 없이 기술만 쫓아가면 위험합니다.
클라우드 업계는 유행에 민감합니다. 그리고 유행은 빠르게 바뀝니다.
2010년대 초중반에는 "클라우드 퍼스트"가 정답처럼 보였습니다.
모든 것을 클라우드로 옮기는 것이 현대화이고 혁신이며 미래였습니다. 그래서 많은 기업이 ERP를 클라우드로 올렸습니다. 레거시 메인프레임 애플리케이션도 클라우드로 마이그레이션했습니다.
"온프레미스는 구시대 유물이다"라는 확신이 있었습니다.
결과는 어땠을까요? 비용이 폭등했습니다.
예측 가능한 워크로드를 온디맨드 가격으로 돌리니 온프레미스보다 훨씬 비싼 경우가 많았습니다.
성능도 저하됐습니다. 레이턴시가 중요한 트랜잭션 시스템을 수백 킬로미터 떨어진 데이터센터로 옮기니 응답 시간이 크게 늘어난 사례들이 보고되었습니다.
몇 년 뒤, 일부 대규모 고객들이 다시 온프레미스로 돌아왔습니다.
2010년대 중후반에는 "컨테이너와 마이크로서비스"가 유행했습니다.
모놀리틱 애플리케이션은 낡았고, 마이크로서비스로 쪼개는 것이 현대적인 아키텍처라고 했습니다.
Netflix가 대표적인 예입니다. 그래서 많은 기업이 단순한 CRUD 애플리케이션도 수십 개의 마이크로서비스로 재작성했습니다.
하지만 그 결과 운영 복잡도가 크게 올랐습니다.
서비스 3개짜리 모놀리식 앱은 한 명이 관리할 수 있었지만, 30개의 마이크로서비스는 팀이 필요했습니다.
서비스 간 통신, 분산 트랜잭션, 장애 전파, 로깅 집계 등 해결해야 할 문제가 너무 많았습니다.
그리고 Netflix 규모가 아니면 마이크로서비스의 복잡도가 얻는 이익보다 크다는 것을 깨달았습니다.
2020년대 초반에는 "서버리스"가 미래처럼 보였습니다.
서버를 관리하지 않아도 되니 그 혜택은 커보였습니다. 확장은 자동이고, 비용은 쓴 만큼만 냅니다. 그래서 많은 기업이 Lambda로 전환했습니다. EC2를 끄고, 모든 로직을 Lambda 함수로 옮겼습니다.
결과는? 콜드 스타트 지연이 문제였습니다. 함수가 몇 초 동안 응답하지 않는 경우가 생겼습니다. 디버깅이 어려웠습니다. 로컬에서 재현할 수 없는 버그들이 프로덕션에서만 발생했습니다. 그리고 비용이 예상보다 많이 나왔습니다. Lambda는 호출당 과금이라 트래픽이 많으면 EC2보다 비쌌습니다.
지금은 "AI 퍼스트"입니다.
모든 애플리케이션에 AI를 넣는 것이 경쟁력인 것처럼 보입니다. 챗봇에 LLM을 연결하고, 추천 시스템에 딥러닝을 적용하고, 고객 서비스에 AI 에이전트를 투입합니다. "AI 없는 서비스는 도태된다"는 분위기입니다.
하지만 진짜 물어야 할 질문은 이것입니다.
우리 고객이 진짜 원하는 것이 AI인가, 아니면 더 빠르고 정확한 서비스인가? 챗봇에 GPT-4를 연결하는 것이 목표인가, 아니면 고객 문의를 빠르게 해결하는 것이 목표인가? 때로는 잘 만든 FAQ와 검색 기능이 AI 챗봇보다 나을 수 있습니다. 비용도 적게 들고, 응답도 정확하며, 고객도 더 만족할 수 있습니다.
기술은 목적이 아닌 수단입니다. 하지만 유행을 쫓다 보면 이것을 잊기 쉽습니다.
그렇다면 어떻게 해야 할까요? 기술을 도입하기 전에 먼저 물어야 할 질문들이 있습니다.
첫 번째 질문은 "이 기술이 우리의 어떤 비즈니스 문제를 해결하는가?"입니다.
기술 자체가 목표가 되어서는 안 됩니다.
Kubernetes를 도입하는 이유가 "요즘 다들 쓰니까"가 되어서는 안 됩니다. 명확한 문제가 있어야 합니다.
예를 들어 "지금은 배포가 주 1회인데, 경쟁사는 하루에 여러 번 배포합니다. 우리도 배포 빈도를 높여야 시장 변화에 빠르게 대응할 수 있습니다"라는 문제가 있다면, Kubernetes가 답이 될 수 있습니다. 또는 "여러 클라우드에서 일관된 방식으로 배포해야 하는데, 각 클라우드마다 다른 도구를 쓰니 복잡합니다"라는 문제도 Kubernetes로 해결할 수 있습니다.
하지만 "그냥 컨테이너가 좋다고 들었어요"라면, Kubernetes는 과잉입니다.
단순히 서버 3대를 돌리는데 Kubernetes 클러스터를 구축하고, etcd를 관리하고, ingress controller를 설정하고, 네트워크 정책을 작성하는 것은 낭비입니다.
문제를 먼저 정의하고, 그 문제를 풀 수 있는 가장 단순한 해결책을 찾아야 합니다.
두 번째 질문은 "이 기술의 Total Cost of Ownership(TCO)은 얼마인가?"입니다.
기술의 비용은 라이선스나 클라우드 요금만이 아닙니다. 학습 비용, 운영 비용, 장애 대응 비용, 인력 채용 비용까지 포함해야 합니다.
Lambda 함수 하나는 싸 보입니다. 100만 요청에 20센트입니다. 하지만 1,000개의 Lambda 함수를 관리하고, CloudWatch Logs를 모니터링하고, 함수 간 의존성을 추적하고, 콜드 스타트 문제를 해결하고, 분산 트레이싱을 구현하는 비용은? 서버리스 전문가를 채용하거나 기존 팀을 교육해야 합니다.
이 모든 것을 합치면 EC2 몇 대 돌리는 것보다 비쌀 수 있습니다.
세 번째 질문은 "이 기술을 우리 조직이 감당할 수 있는가?"입니다.
기술은 사람이 운영합니다. 아무리 좋은 기술이라도, 우리 팀이 그것을 이해하고 다룰 수 있어야 합니다.
Kubernetes가 아무리 좋아도, 우리 팀이 YAML을 제대로 작성할 수 있어야 하고, 파드 네트워킹을 이해해야 하며, 장애가 났을 때 로그를 읽고 문제를 찾아낼 수 있어야 합니다.
역량이 안 되면 기술은 오히려 부담이 됩니다. 문제가 생겼을 때 아무도 고칠 수 없으면, 그 기술은 블랙박스가 됩니다.
네 번째 질문은 "이 기술이 5년 후에도 지원되는가?"입니다.
클라우드는 빠르게 변합니다. 서비스 종료(End of Life)도 흔합니다.
AWS도 QLDB, Honeycode, OpsWorks 등 여러 서비스를 종료하거나 신규 고객을 받지 않는 방향으로 전환했습니다. 트렌디한 기술일수록 위험합니다. 검증되지 않았고, 생태계가 약하며, 언제 버려질지 모릅니다.
2-3년 쓰다가 서비스 종료 통보를 받으면, 급하게 마이그레이션해야 합니다. 그때의 비용과 리스크는 누가 책임집니까?
이런 질문들에 답할 수 있어야 기술 도입이 전략적입니다.
그렇다고 신기술을 무조건 거부하라는 것은 아닙니다. 혁신은 필요합니다. 경쟁사가 새로운 기술로 더 빠르게 움직이는데, 우리만 낡은 기술을 고집하면 뒤처집니다. 다만 균형이 필요합니다.
1. 80/20 원칙을 적용해야 합니다.
핵심 워크로드의 80%는 검증된 기술로 안정적으로 운영하고, 나머지 20%로 새로운 기술을 실험합니다.
프로덕션 결제 시스템을 막 나온 베타 기술로 재작성하는 것은 위험합니다. 하지만 내부 도구나 새로운 사이드 프로젝트로 실험하는 것은 괜찮습니다. 작은 프로젝트로 시작하고, 배우고, 검증한 뒤에 점진적으로 확대하는 것입니다.
2. PoC(Proof of Concept)를 제대로 해야 합니다.
많은 기업이 PoC를 "일단 돌아가게만" 합니다. 데모용 데이터 10개로 잘 돌아가면 성공이라고 판단합니다. 하지만 진짜 PoC는 프로덕션 수준의 부하, 장애 상황, 운영 복잡도까지 테스트해야 합니다.
Lambda가 데모에서 잘 돌아간다고 해서 프로덕션에서도 잘 돌아간다는 보장은 없습니다.
초당 1,000 요청이 들어올 때는? 콜드 스타트가 100개 동시에 발생하면? VPC 내에서 RDS에 연결할 때 커넥션 풀은 어떻게 관리합니까? 이런 것들을 PoC 단계에서 테스트해야 합니다. 데모가 잘 돌아가는 것과 프로덕션에서 안정적으로 돌아가는 것은 완전히 다릅니다.
4. Exit 전략을 준비해야 합니다.
새로운 기술을 도입할 때, 항상 "이것이 실패하면 어떻게 되돌아갈 것인가?"를 계획해야 합니다.
롤백 계획, 대안 기술, 마이그레이션 경로 등 이런 것들을 사전에 준비하지 않으면 실패한 기술에 갇힙니다.
예를 들어 DynamoDB로 전환한다면, 관계형 데이터를 어떻게 NoSQL 스키마로 변환할지, 성능이 예상보다 안 나오면 어떻게 다시 RDS로 돌아올지를 미리 계획해야 합니다. "일단 옮기고 보자"는 위험합니다. 되돌아올 수 없는 다리를 건너는 것과 같습니다.
5. 팀의 역량을 먼저 키워야 합니다.
기술보다 사람이 먼저입니다. Kubernetes를 도입하기 전에 팀에 Kubernetes 전문가가 있습니까? 없다면 먼저 교육하거나 채용해야 합니다. 온라인 강의를 제공하고, 컨퍼런스 참석을 지원하고, 실험할 수 있는 개발 환경을 제공하세요.
기술을 먼저 도입하고 나중에 배우려고 하면, 프로덕션이 실험실이 됩니다.
고객이 그 실험의 피해자가 됩니다. 장애가 나도 고칠 수 없고, 성능이 안 나와도 최적화할 수 없고, 비용이 폭등해도 원인을 찾을 수 없습니다. 팀이 준비되기 전까지는 기다리는 것이 맞습니다.
9장의 마지막 화에서는 에필로그로, 클라우드의 미래를 전망하고 이 모든 논의를 정리하겠습니다.
우리는 무엇을 준비해야 할까요?