AWS의 신혼여행은 끝났다: 클라우드 복잡성과 벤더 종속성에 관한 사례 연구

많은 초기 도입자들에게 Amazon Web Services (AWS)는 혁명 그 자체였습니다. 물리적 데이터 센터의 오버헤드 없이 몇 분 만에 서버, 스토리지, 큐를 생성할 수 있는 능력은 스타트업과 독립 개발자들에게 게임 체인저였습니다. 하지만 일부 사용자들에게 클라우드 거물과의 관계는 악화되었습니다.

빠른 확장성과 편리함이라는 신혼여행 단계로 시작된 관계는 종종 "billing footguns(결제 오류 유발 요소)", 불투명한 보안 프로토콜, 그리고 압도적인 수준의 관리 오버헤드로 특징지어지는 복잡하고 적대적인 관계로 진화합니다. 이러한 변화는 단순히 비용의 문제가 아닙니다. 관리형 서비스의 편리함과 인프라 소유의 자율성 사이의 근본적인 긴장 관계에 관한 것입니다.

신뢰의 침식: 팬에서 회의론자로

한동안 AWS를 떠났다가 다시 돌아오는 것은 많은 개발자들이 왜 떠나는지를 상기시키는 냉혹한 현실을 보여줍니다. "진정한 신봉자"에서 회의론자로의 전환은 대개 점진적으로 일어납니다. Python 3의 느린 도입이나 커뮤니티 기반 클라이언트 라이브러리에 대한 의존성과 같은 사소한 불편함에서 시작하여, 플랫폼의 복잡성이 이점이 아닌 부담이 되었다는 깨달음에 이르게 됩니다.

장기 사용자들의 경험에서 몇 가지 반복되는 고충이 나타납니다:

• 복잡성의 함정: IAM (Identity and Access Management)과 같은 서비스는 극도로 복잡하다고 자주 언급됩니다. 일부는 기업 규모에 위한 세밀한 보안이 필요하다고 주장하지만, 많은 이들에게는 이를 관리하기 위해 전담 전문가 팀이 필요한 과도한 엔지니어링처럼 느껴집니다.
• 불투명한 결제: "교묘하게 복잡한 결제"는 흔한 불만 사항입니다. 사용자들은 동일한 시스템 내의 데이터 이동에 대한 비용, 이중 또는 삼중 결제, 그리고 악명 높은 데이터 송출(egress) 비용(역사적으로 기가바이트당 약 9센트)에 대해 보고합니다.
• 관리형 서비스의 역설: AWS Lambda와 같은 서비스는 확장성과 유지보수 제로를 약속하지만, 심각한 벤더 종속성을 유발할 수 있습니다. 서버리스 아키텍처에서 벗어나 이전하는 데 필요한 노력은 전통적인 웹 서버를 유지 관리하는 노력보다 훨씬 더 큰 경우가 많습니다.

"보안 침해" 악몽

클라우드 경험의 가장 생생한 예는 계정 정지의 임의적인 성격입니다. 한 기록된 사례에서는, 연구를 위해 갑자기 고성능 EC2 인스턴스를 생성한 휴면 계정이 "보안 침해 의심"으로 플래그가 지정되었습니다.

이로 인해 연쇄적인 실패가 발생했습니다: 비즈니스 이메일(WorkMail)이 차단되었고, 지원팀의 응답은 며칠 동안 지연되었습니다. 이는 클라우드 모델의 치명적인 취약점을 강조합니다: 핵심 인프라를 단일 제공업체에 아웃소싱할 때, 단 한 번의 자동화된 보안 플래그가 비즈니스 운영 전체를 마비시킬 수 있습니다.

클라우드 vs. 베어 메탈: 거대한 논쟁

커뮤니티는 "클라우드"가 여전히 대부분에게 적합한 선택인지에 대해 여전히 의견이 갈립니다.

클라우드를 옹호하는 입장

일부 개발자들은 복잡성이 핵심 서비스의 신뢰성과 성숙도에 대한 공정한 트레이드오프라고 주장합니다.

"AWS의 핵심 서비스 세트는 여전히 놀랍습니다: EC2, S3, IAM, EKS, Route53, RDS 등등... 다른 제공업체가 이 서비스들을 대체할 수 있는 멋진 새로운 기능을 시도할 때마다, AWS의 서비스들이 얼마나 성숙하고 다듬어졌는지 깨닫게 됩니다."

다른 이들은 소규모 프로젝트의 경우, Lambda와 같은 서버리스 옵션이 프리 티어(free tier) 범위 내에 있다면 가장 저렴한 VPS보다 더 저렴할 수 있다고 지합니다.

셀프 호스팅 및 코로케이션을 옹호하는 입장

반대로, "리패트리에이션(repatriation, 인프라 복귀)" 운동이 커지고 있습니다. 워크로드를 온프레미스 서버나 코로케이션 센터로 다시 옮기는 움직임입니다. 주요 논거는 경제적 및 성능 기반입니다:

• 비용 효율성: 사용자들은 관리형 서비스(GCP의 Datastore나 AWS의 ElastiCache 같은)를 전용 하드웨어에서 직접 관리하는 Postgres, Mongo, Redis로 교결체함으로써 월간 결제 금액을 수천 달러에서 수백 달러로 줄였다고 보고합니다.
• 성능: 일부 개발자들은 클라우드 CPU가 느리게 느껴질 수 있으며, EBS (Elastic Block Store) 볼륨이 고성능 워크로드에 대해 수용할 수 없는 지연 시간을 유중합니다.
• 자율성: 클라우드를 벗어나는 것은 임의의 계정 정지지의 위험과 클라우드 제공업체가 오픈소스 프로젝트를 클로닝하는 "포식적" 성격(예: OpenSearch와 DocumentDB의 생성)을 제거합니다. iguring out the path of least resistance

결론: 최소한의 저항이 드는 길을 선택하기

클라우드의 매력은 "최소한의 저항이 드는 길"이라는 편리함에 있습니다. 하지만 원문 포스트의 저자가자가 suggests, 그 길은 함정으로 이어질 수 있습니다. 데이터를 "무료"로 추출하는 것의 어려움이나, 덜 완성된 서비스들의 방대한 생태계를 관리하는 복잡성 때문에, 편리함의 비용은 종종 자율성과 정신 건강에 대한 숨겨진 세금으로 돌아옵니다.

현대적인 개발자에게 목표는 클라우드로부터의 완전한 탈출이 아닌, 전략적 다각화입니다: S3를 백업용으로 사용하거나 Route53를 DNS용으로 사용하는 것처럼 클라우드가 가장 잘하는 데 사용하되, 핵심 컴퓨팅 및 데이터는 자신이 진정으로 제어어할 수 있는 인프라에 두는 것입니다.