Andrew Stuart의 짧은 회고록은 단순한 불만이 아니었다. 그것은 2006년 S3가 세상에 처음 등장한 이래 20년간 우리가 클라우드와 맺어온 관계의 압축본이다. 이 글은 그 회고를 출발점으로, '클라우드'라는 개념이 어디서 왔는지, 왜 그토록 강력했는지, 그리고 왜 2026년의 지금 우리는 다시 그 관계를 재정의하고 있는지를 따라간다.
2026년 5월의 어느 날, 멜버른에 사는 한 개발자가 자신의 블로그에 짧은 글을 올렸다. 제목은 단호하다 — "I returned to AWS — and was reminded HARD why I left.".
글쓴이의 이름은 Andrew Stuart. 그는 호주에서 AWS 첫 사용자 모임을 직접 만든 사람 중 하나다. 2010년대 초, 모두가 "클라우드? 그게 뭐예요?"라고 묻던 시절에 그는 멜버른에서 AWS 미트업을 조직했고, 컨퍼런스를 열었으며, 회의적인 기업 IT 담당자들에게 "AWS의 미래"를 설파하던 사람이었다. 한국식으로 표현하자면 — 개국공신 중 한 명이었다.
그런 그가 글을 시작하는 문장은 이렇다.
"I was in love with AWS for 15 years. Then I gradually fell out of love. Then last week, I returned for one quick test, and AWS itself reminded me — brutally — why I left." (나는 15년간 AWS를 사랑했다. 점점 식어갔다. 지난주, 짧은 테스트 하나 하려고 돌아갔다. 그리고 AWS는 — 거칠게 — 내가 왜 떠났는지 다시 일깨워주었다.)
그는 단지 Claude를 Bedrock에서 한 번 돌려보고, 고성능 인스턴스에서 벤치마크 코드 하나를 돌려보려 했을 뿐이다. 그런데 로그인 직후 "보안 알림"이 떴고, 계정이 즉시 정지되었다. 그의 비즈니스 이메일(AWS WorkMail)이 함께 잠겼고, 며칠 동안 지원팀은 답이 없었다.
이 사건은 그를 다시 한번 확신시켰다 — 떠난 것은 옳은 결정이었다.
이 글은 단순한 한 사람의 불평이 아니다. 그가 나열한 항목들 — DynamoDB의 청구서 충격, 이그레스 비용, IAM의 복잡성, Lambda의 무용함, 오픈소스 약탈, 계정 정지 — 은 클라우드 컴퓨팅이 지난 20년 동안 만들어온 모든 약속과 모든 그늘의 압축본이다.
그래서 이 글에서는 그의 회고를 출발점으로, 시간을 거꾸로 거슬러 올라가 본다. "클라우드"라는 단어는 어디서 왔는가? 왜 그것은 그렇게 강력했는가? 왜 우리는 이제 다시 그 관계를 재정의하고 있는가?
준비됐다면, 시간 여행을 떠나보자.
지금 30대 후반 이상의 개발자라면, 한때 "서버"라는 단어가 무엇을 의미했는지 기억할 것이다.
그것은 물리적인 쇳덩어리였다. 회사 뒷방의 작은 서버실, 윙윙거리는 팬, 깜빡이는 LED, 케이블이 뱀처럼 엉킨 랙. 새 서비스를 출시하려면 누군가는 견적을 받고, 누군가는 PO를 끊고, 누군가는 6주를 기다려 박스를 받았다. 박스를 열고, 데이터센터로 차를 몰고 가서, 랙에 끼우고, 케이블을 연결하고, OS를 설치하고, 펌웨어를 업그레이드하고… 그러면 비로소 코드를 올릴 수 있었다.
하루에 사용자가 갑자기 10배 늘면? 축하한다, 다시 6주를 기다리면 된다. 그러는 동안 당신의 서비스는 죽는다.
이 세계관이 무너지기 시작한 것은 — 의외로 — 온라인 서점 때문이었다.
2003년 말, 아마존 내부에서는 자기들이 직접 만들고 있던 거대한 분산 인프라가 일종의 보편적 가치를 가질 수 있다는 자각이 일었다. 책을 팔든, 음악을 팔든, 비행기를 팔든 — 모든 인터넷 서비스가 결국 똑같은 세 가지를 필요로 한다는 사실이었다:
당시 아마존 글로벌 서비스 부문의 SVP였던 Andy Jassy(현재 아마존 CEO)는 한 페이지짜리 비전 문서를 썼다. 그리고 Jeff Bezos에게 가서, 사내에서 듣기에는 매우 공격적인 요청을 했다 — 57명을 새로 뽑겠습니다.
Jassy의 머릿속에는 한 가지 이미지가 있었다. 그것은 그가 인터뷰에서 여러 번 인용한 표현이다:
"기숙사 방에 있는 대학생이 세계 최대 기업들과 똑같은 인프라에, 똑같은 가격으로 접근할 수 있다면 어떨까?"
이 비전은 그 당시로서는 거의 공상과학에 가까웠다. 하지만 2003년 12월, Chris Pinkham과 Benjamin Black이라는 두 엔지니어가 다른 트랙에서 비슷한 결론을 담은 내부 문서를 발표했다. "우리는 우리 자신의 컴퓨팅 인프라를 완전히 표준화·자동화하고, 그것을 웹 서비스로 제공해야 한다."
두 줄기가 합쳐졌다. 그리고 2006년 봄이 왔다.
2006년 3월 14일, Amazon은 보도자료 한 장과 함께 조용히 S3 (Simple Storage Service)를 공개했다. 가격은 기가바이트당 한 달 15센트. 1GB를 미국 어디든 보내는 데 20센트. 가입은 신용카드만 있으면 끝.
당시 이게 얼마나 충격이었는지 가늠하기 어렵다. 비교 대상을 만들어 보자:
| 항목 | 2006년 이전 | S3 출시 직후 |
|---|---|---|
| 저장 시작까지 걸리는 시간 | 6주 (PO, 견적, 발주, 설치) | 5분 (카드 등록 → API 호출) |
| 최소 약정 | 수천 달러 단위 박스 구입 | $0 (사용한 만큼만) |
| 장애 대응 | 본인이 디스크 갈러 감 | 아마존이 알아서 함 |
| 스케일 | 예측해서 미리 사야 함 | 무한 (보이지 않게 늘어남) |
5개월 뒤인 8월에는 EC2(Elastic Compute Cloud)가 베타로 풀렸다. 가상 서버 하나가 시간당 10센트. 필요하면 1초 만에 켜지고, 끄면 즉시 청구가 멈춘다.
그리고 세 번째 다리 — 데이터베이스가 이어졌다. 2007년 10월, Werner Vogels의 팀이 SOSP 학회에서 한 편의 논문을 발표한다.
논문 제목은 "Dynamo: Amazon's Highly Available Key-value Store". 저자 명단에는 DeCandia, Hastorun, Jampani, Kakulapati, Lakshman, Pilchin, Sivasubramanian, Vosshall, 그리고 마지막에 Werner Vogels — 아마존 CTO — 의 이름이 적혀 있었다.
이 논문이 풀고자 한 문제는 한 문장으로 요약된다:
"수억 명이 동시에 쓰는 아마존 쇼핑 카트가 절대 — 절대로 — 사라지면 안 된다."
전통적인 관계형 DB는 일관성(consistency)을 위해 가용성(availability)을 일부 희생한다. 마스터가 죽으면 잠시 멈춘다. 큰 트랜잭션이 충돌하면 잠시 기다린다. 보통의 서비스에서는 그게 합리적이다. 그러나 쇼핑 카트는 그럴 수 없다. 사용자가 "장바구니에 담기"를 눌렀는데 DB 마스터가 죽었다는 이유로 실패하면, 그날 매출이 사라진다.
Dynamo의 답은 충격적일 만큼 단순한 원칙이었다: "가용성을 최우선으로 한다. 일관성은 나중에 — 결국엔 — 맞춰진다."
이 사상이 바로 그 유명한 "Eventual Consistency(최종 일관성)"다.
이 논문은 분산 시스템 학계와 산업계 양쪽을 흔들었다. Cassandra, Riak, Voldemort 같은 후속 시스템들이 Dynamo의 아이디어 — consistent hashing, vector clocks, gossip protocol, sloppy quorum — 를 그대로 가져갔다. 그리고 그 위에서 결국 DynamoDB라는 매니지드 서비스가 2012년에 등장했다.
S3, EC2, DynamoDB. 저장, 연산, DB. Andy Jassy의 비전 문서가 적었던 세 다리가 완성된 것이다.
2006년에 AWS가 등장했지만, "클라우드 컴퓨팅"이라는 단어가 정확히 무엇을 의미하는지는 아직 모호했다. 어떤 사람은 그것을 "그냥 호스팅 업체"라고 불렀고, 어떤 사람은 "외주된 데이터센터"라고 불렀다.
이 모호함에 마침표를 찍은 것은 — 의외로 학교였다.
2009년 2월 10일, UC 버클리 EECS 학과는 기술 보고서 한 편을 공개한다. 제목은 "Above the Clouds: A Berkeley View of Cloud Computing", 보고서 번호는 UCB/EECS-2009-28이다.
저자는 Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz, Andy Konwinski, Gunho Lee, David Patterson(컴퓨터 아키텍처의 살아있는 교과서, 튜링상 수상자), Ariel Rabkin, Ion Stoica(Spark·Mesos 창시자, Databricks 공동 창업자), 그리고 Matei Zaharia(Spark의 아버지). 이 한 페이지에 미래 클라우드와 빅데이터 업계 절반이 적혀 있다.
이 보고서가 한 일은 두 가지였다.
첫째, "클라우드 컴퓨팅"을 학술적으로 정의했다. 그들의 정의는 단순하고 강력하다:
"Cloud Computing은 (1) 인터넷을 통해 제공되는 서비스로서의 애플리케이션과 (2) 그 서비스를 제공하는 데이터센터의 하드웨어·시스템 소프트웨어 둘 다를 가리킨다."
둘째, 클라우드의 본질적 새로움 세 가지를 짚었다:
이 세 가지 — 무한 자원, 무 약정, 종량제 — 가 클라우드 컴퓨팅을 "그냥 호스팅"과 구분짓는 본질적 특성이다. 이 정의는 16년이 지난 지금까지도 그대로 통한다.
이 보고서가 진정으로 무서운 점은, 그들이 클라우드 채택의 10가지 장애물을 미리 짚어두었다는 것이다. 2009년에 쓴 글인데 — 2026년에 읽어도 거의 모든 항목이 그대로 살아있다.
| 버클리가 짚은 장애물 (2009) | 2026년 현재 |
|---|---|
| 1. 서비스 가용성 | S3, US-East-1 장애 매해 헤드라인 |
| 2. 데이터 락인(Data Lock-In) | ⚠️ 이번 글의 주제 |
| 3. 데이터 기밀성·감사 가능성 | GDPR, Data Act, 미국 CLOUD Act 갈등 |
| 4. 데이터 전송 병목(Egress) | ⚠️ 이번 글의 주제 |
| 5. 성능 예측 불가 | noisy neighbor 문제는 여전히 존재 |
| 6. 확장 가능한 스토리지 | 이건 해결됨 (S3, GCS) |
| 7. 분산 시스템 디버깅 | OpenTelemetry, 옵저버빌리티 산업 탄생 |
| 8. 빠른 스케일링 | Serverless, Fluid Compute로 거의 해결 |
| 9. 명성 공유의 함정 (다른 사용자의 악행이 IP 차단 유발) | 여전히 가끔 일어남 |
| 10. 소프트웨어 라이선스 | ⚠️ Elasticsearch, Redis, MongoDB 전쟁 |
Andrew Stuart의 글이 다루는 거의 모든 문제가 이 표에 있다. 16년 전에 학자들이 이미 예언했고, 16년 동안 풀리지 않았다.
이제 그 풀리지 않은 문제들을 하나씩 들여다보자.
Stuart의 글에서 가장 감정이 격해지는 대목은 DynamoDB 청구서도, 이그레스 비용도 아니다. 그가 정말로 윤리적이라며 비난하는 것은 — AWS가 오픈소스 프로젝트들을 어떻게 다루는가이다. 그가 인용한 세 가지 이름이 있다:
이 세 가지는 단지 우연히 비슷한 이름의 다른 제품이 아니다. 이들은 모두 원래 오픈소스로 만들어진 데이터베이스의 코드를 클라우드 회사가 가져다가, 자체 서비스로 포장해 판매하고, 원작자에게는 거의 한 푼도 돌려주지 않는다는 비난을 받는 — 클라우드 시대의 가장 큰 윤리적 분쟁의 결과물이다.
이 이야기의 가장 오래되고 가장 격렬한 버전은 Elasticsearch다.
Elasticsearch는 이스라엘 개발자 Shay Banon이 2010년에 만든 검색 엔진이다. Apache Lucene 위에 분산 처리 레이어를 얹은 이 도구는 Apache 2.0 라이선스로 풀려, 전 세계 검색 인프라의 사실상 표준이 되었다. Netflix, Wikipedia, 셀 수 없는 회사들이 ES를 사용했다. Shay Banon은 Elastic NV라는 회사를 차렸고, 클라우드 호스팅 서비스인 Elastic Cloud로 수익을 냈다.
문제가 시작된 것은 2015년이다. AWS가 "Amazon Elasticsearch Service"라는 이름으로 매니지드 ES를 출시한 것이다.
Banon의 입장에서 이것은 두 겹의 상처였다.
2021년 1월 14일, Shay Banon은 폭탄선언을 한다. "Elasticsearch와 Kibana는 더 이상 Apache 2.0이 아니다." 대신 두 가지 새 라이선스 중 하나를 골라야 한다 — SSPL(Server Side Public License) 또는 ELv2(Elastic License 2.0). 둘 다 핵심 조항이 똑같다: "이 소프트웨어를 매니지드 서비스로 제공하려면, 그 서비스 전체 코드를 공개하라." AWS 같은 회사를 정조준한 것이다.
AWS의 반격은 빨랐다. 고작 3개월 뒤, AWS는 OpenSearch를 발표한다. Elasticsearch 7.10.2를 포크(fork)한 것이다. 라이선스: Apache 2.0. 거버넌스: 처음에는 AWS, 나중에 Linux Foundation으로 이관.
이 라이선스 전쟁은 4년을 끌었다. 그리고 2024년 9월, 놀라운 반전이 일어났다. Elastic이 AGPLv3를 추가하며 다시 오픈소스로 돌아왔다. Shay Banon은 블로그에서 "풍경이 바뀌었다. AWS와의 관계도 달라졌다. 이제는 다시 오픈소스로 돌아갈 수 있다"고 썼다.
이긴 사람은 누구일까? 그건 보는 사람마다 다르다. 하지만 한 가지는 분명하다 — 이 전쟁은 모든 사람에게 비쌌다.
같은 일이 거의 토씨 하나 안 틀리고 Redis에서 반복됐다.
Redis는 2009년 Salvatore Sanfilippo가 만든 인메모리 키-값 스토어다. 캐시, 큐, 세션 스토어, 리더보드 — 사실상 모든 웹 서비스의 두 번째 다리. BSD 라이선스의 가장 사랑받는 오픈소스 중 하나였다.
그리고 AWS의 ElastiCache, GCP의 Memorystore, Azure의 Cache for Redis가 모두 Redis 코드를 매니지드로 제공해 거대한 매출을 올렸다. Redis Inc.는 늘 다음 단계의 압박을 받았다.
2024년 3월, Redis Inc.가 결단을 내린다. "BSD를 버리고 SSPL+RSALv2로 간다." Elasticsearch가 3년 전에 했던 것과 거의 동일한 결정.
이번에는 AWS가 더 빨랐다. 단 11일 만에 — 정확히는 4월 1일, 만우절에 — Linux Foundation이 Valkey를 발표한다. Redis 7.2.4를 포크한 BSD 라이선스 프로젝트. 후원 기업: AWS, Google Cloud, Oracle, Ericsson, Snap.
흥미로운 점은 — 이번에는 커뮤니티의 분위기가 달랐다. Valkey는 출시 몇 주 만에 50개 이상의 기업, 150명 이상의 개인 컨트리뷰터, 1000개 이상의 커밋을 모았다. Redis 라이선스 변경에 대한 반발은 광범위했고, Valkey는 일종의 "구원자"로 환영받았다.
그리고 2025년, Redis Inc.도 결국 백기를 들었다 — AGPLv3를 추가하며 사실상 다시 오픈소스로 돌아왔다.
세 번째 이야기는 조금 더 미묘하다. MongoDB는 일찍이 2018년에 SSPL을 만들었다(SSPL 자체가 MongoDB가 만든 라이선스다). AWS의 매니지드 MongoDB 서비스를 막기 위한 목적이 명확했다.
AWS의 대응은 다른 두 케이스와 달랐다. 코드를 포크하는 대신, MongoDB API와 호환되는 별도의 데이터베이스를 만들었다 — 이것이 DocumentDB다. 내부 엔진은 PostgreSQL 기반인 것으로 알려져 있고, MongoDB의 와이어 프로토콜을 받아들여 마치 MongoDB처럼 보이게 한다.
MongoDB CEO Dev Ittycheria는 "호환성이라는 가면을 쓴 모방"이라며 비판했지만, 라이선스적으로는 깔끔하다. 코드를 가져간 게 아니기 때문이다.
이 세 가지 사건의 패턴은 같다:
Stuart가 "포식적(predatory)"이라고 표현한 것이 이 패턴이다. 그의 분노는 단지 개인적인 것이 아니다. 그는 호주의 한 작은 컨퍼런스에서, "이런 식으로 가면 누가 오픈소스에 투자하겠습니까? 결국 그 코드는 클라우드 사업자의 것이 되는데."라고 일찍부터 말해 왔다.
반대편의 논리도 있다. AWS 입장에서는 "Apache 2.0으로 풀어둔 코드를, 라이선스가 허용하는 대로 가져다 쓰는데 뭐가 문제냐"라고 말한다. 법적으로 틀린 말이 아니다. 그리고 OpenSearch, Valkey 같은 포크는 사실 그 자체로 다시 오픈소스이고, Linux Foundation 거버넌스로 운영된다.
이것은 윤리와 법, 기여와 착취, 자유와 종속의 회색지대에서 벌어지는 — 클라우드 시대의 가장 큰 정치적 문제 중 하나다.
Stuart가 두 번째로 길게 비난한 항목은 데이터 이그레스(egress) 비용이다. 그가 인용한 숫자는 "기가바이트당 9~12센트"인데, 실제로 AWS의 공식 가격을 보면 미국에서 인터넷으로 나가는 데이터는 시작이 9센트/GB이고, 양에 따라 5센트까지 떨어진다.
이 숫자는 — 2026년 기준으로 — 사실상 강도다.
먼저 단어부터 분명히 하자. 클라우드에서 "이그레스(egress)"는 데이터가 클라우드 데이터센터 밖으로 나가는 트래픽을 가리킨다. 반대로 인그레스(ingress)는 들어오는 트래픽이다.
대부분의 클라우드는 인그레스는 무료, 이그레스는 비싼 구조다. 그 이유는 표면적으로는 "대역폭 비용"이지만, 업계의 컨센서스는 분명하다 — 이그레스 가격은 원가의 수십 배에서 100배 이상이다.
CDN 전문 회사 Cloudflare의 추산에 따르면, AWS의 이그레스 단가는 자체 대역폭 원가의 약 80배다. 즉 거의 모든 이그레스 비용은 — 운영 비용을 회수하기 위해서가 아니라 — 다른 목적으로 책정되어 있다.
이 "다른 목적"이 무엇인지에 대한 가장 유명한 분석은 클라우드 경제학자 Corey Quinn의 표현이다:
"이그레스 요금은 라우터 운영 비용이 아니다. 그것은 고객을 떠나지 못하게 하기 위한 가격이다."
이그레스 비용은 클라우드 비즈니스에서 vendor lock-in의 가장 강력한 무기다. 한번 페타바이트(PB) 단위의 데이터를 S3에 쌓아두면, 그것을 다른 클라우드로 옮기는 비용이 — 단지 이전 비용만으로도 — 수십만 달러를 쉽게 넘긴다.
예를 들어보자. 어떤 회사가 S3에 500TB의 데이터를 보관한다고 가정하자. 이것은 결코 큰 양이 아니다 — 중견 사진 공유 서비스나 의료 영상 회사 정도면 평범한 규모다. 이 데이터를 GCP나 자사 데이터센터로 옮기려면:
이게 한 번만 발생하는 일회성 비용이라면 — 그래도 견딜 수 있다. 그러나 현실의 워크로드는 매일 이그레스를 발생시킨다. 모바일 앱이 사진을 다운로드할 때마다, CDN이 캐시를 채울 때마다, 분석 파이프라인이 다른 리전으로 데이터를 옮길 때마다.
대형 SaaS 회사의 클라우드 청구서에서 이그레스 비용이 컴퓨트 비용을 추월하는 경우가 드물지 않다. 이것은 농담이 아니라, 클라우드 업계의 공공연한 비밀이다.
이 상황이 영원할 수는 없었다. 2024년 1월 11일, EU Data Act가 발효된다. 이 법은 여러 조항을 담고 있지만 — 클라우드 업계에 가장 큰 영향을 준 것은 Chapter VI이다.
핵심 요지는 단 두 줄로 요약된다:
클라우드 사업자는 고객이 다른 사업자로 전환할 수 있도록 모든 "효과적 전환의 장애물"을 제거해야 한다. 여기에는 데이터 이전 비용도 포함된다.
2024년 3월 5일, AWS는 "이그레스 면제" 정책을 발표한다. 단, 조건이 있다: "AWS를 완전히 떠나는 경우에만", 그리고 "신청서를 내고 승인을 받아야" 한다. Google Cloud는 일주일 앞서 동일한 정책을 냈고, Azure도 곧 따라왔다.
이것은 큰 진전인가? 그렇기도 하고 아니기도 하다. Corey Quinn의 평가:
"이건 거의 전부 광고 목적이다. 이그레스 요금은 떠날 때가 아니라 — 평소 영업하면서 고객들에게 콘텐츠를 보낼 때 아프게 다가오는 것이다."
다시 말해, "떠나는 길은 공짜로 열어줬으니, 일상적인 사용에서는 계속 빨아먹겠다"는 것이다. 그래도 이것은 16년 전 버클리 보고서가 짚었던 장애물 #2: Data Lock-in의 정면 도전이라는 점에서 의미가 있다.
AWS는 2025년 9월 한 발 더 나아갔다. 새로운 티어드 이그레스(tiered egress) 모델이 도입됐다. 한 계정 전체의 월간 이그레스를 합산하여, 양에 따라 단가가 단계적으로 떨어지는 구조다. 또한 무료 한도가 1GB에서 100GB로 100배 늘었다. 작은 개발자나 스타트업에는 사실상 이그레스가 사라진 셈이다.
그러나 — 핵심 가격 수준은 여전히 원가의 수십 배다. 그리고 거대 기업의 페타바이트 단위 이그레스는 여전히 수십만 달러를 의미한다. 호텔 캘리포니아는 조금 친절해졌지만, 여전히 호텔 캘리포니아다.
Stuart는 "AWS의 IAM이 hideously complex(끔찍하게 복잡하다)"고 표현했다. 이 표현은 과장이 아니다.
IAM(Identity and Access Management)의 존재 이유부터 이야기하자.
당신이 작은 스타트업이고, AWS 계정에 개발자 두 명이 있다고 하자. "그냥 둘 다 admin 줘"라고 하면 끝난다. 그런데 회사가 커진다. 백엔드, 프론트엔드, ML, 데이터, 보안, 회계, 외주, 인턴, 마케팅… 50명이 됐다.
이제 다음을 결정해야 한다:
이 문제를 한 시스템에 욱여넣은 것이 IAM이다. 그리고 — 슬프게도 — 그것은 풀기 어려운 문제다. 어렵다기보다 본질적으로 복잡한 문제다.
AWS IAM은 다섯 가지 직교 차원을 동시에 다룬다:
여기에 추가로 조건(Condition) 키 — 시간, IP, MFA 사용 여부, 태그 — 이 붙는다. 정책 하나에 JSON 200줄이 흔하다.
AWS의 디자인 결정은 — 강력함을 위해 — 단순함을 포기한 쪽이다. Google Cloud의 IAM이 상대적으로 더 단순하고, Hashicorp나 Tailscale 같은 회사는 의도적으로 role-based가 아닌 attribute-based 또는 tag-based 접근을 채택한다.
문제는, IAM이 한번 잘못 설정되면 보안 사고의 95%가 여기서 시작한다는 점이다. 2019년 Capital One 해킹은 SSRF + 잘못 구성된 IAM Role 조합으로 1억 명의 카드 정보를 유출시켰다. 사람들은 IAM이 어렵다고 욕하지만, 잘 설계된 IAM은 보안의 최후 방어선이다.
이것이 IAM의 비극이다. 올바르게 쓰면 강력하고, 잘못 쓰면 재앙이고, 평균적으로 쓰기에는 너무 복잡하다.
코어닷투데이의 AWS IAM 심층 가이드에서 이 부분을 좀 더 다룬다. 핵심만 정리하자면 — Stuart가 "복잡하다"고 한 것은 불평이라기보다 사실 묘사다.
Stuart는 한 줄로 일축한다: "Lambda offers no genuine benefit over traditional servers." — 람다는 전통적인 서버에 비해 진정한 이점이 없다.
이 말은 너무 강하다. 그러나 강한 만큼 — 부분적으로는 사실이다.
AWS Lambda는 2014년 re:Invent에서 발표됐다. 그 약속은 매혹적이었다:
Lambda는 두 종류의 사용 사례에 매우 강하다:
반대로 Lambda가 약한 곳도 분명하다:
그래서 Stuart의 "no genuine benefit"은 그가 "전통적 서버를 들여다보고 운영할 줄 아는 사람"이라는 전제에서 나온 말이다. 그런 사람에게는 Lambda가 가져다주는 추상화가 자유라기보다 족쇄다 — 코드가 어디서 어떻게 도는지 모르는 상태가, 어떤 사람들에게는 자유고, 어떤 사람들에게는 공포다.
흥미로운 건, 2026년 시점에서 Vercel이 Edge Functions을 폐기하고 "Fluid Compute"로 대체했다는 것이다. Cloudflare Workers를 비롯한 경쟁 진영들이 비슷한 방향으로 가고 있다.
Fluid Compute의 핵심 아이디어는 단순하다: "하나의 함수 인스턴스를 여러 요청이 공유한다." 전통적 Lambda가 요청 = 인스턴스였다면, Fluid는 인스턴스 = 여러 요청을 다루는 미니 서버다. 콜드 스타트가 크게 줄고, 메모리 효율이 좋아지고, 가격 경쟁력도 생긴다.
AWS도 이 방향을 따라가고 있다. Lambda SnapStart, Provisioned Concurrency, Lambda Streaming Response 등이 그 답이다. 2014년의 Lambda와 2026년의 Lambda는 본질적으로 다른 제품에 가깝다.
Stuart의 비판은 — 2014년 첫 출시 시점이라면 너무 가혹했고, 2026년 시점에서는 너무 단순화됐다. 진실은 그 사이 어딘가에 있다.
자, 이제 우리는 Stuart의 글로 돌아간다. 모든 배경 지식을 갖춘 채로.
Stuart는 자기 글에서 사건을 짧게 묘사한다. 그는 — 호기심에서, 혹은 글감을 위해 — AWS Bedrock에서 Claude를 한 번 돌려보고, 고성능 EC2 인스턴스에서 벤치마크 코드 하나를 돌려보려 했다. 그것뿐이다. 신용카드는 등록되어 있고, 계정은 활성 상태였고, MFA도 켜져 있었다.
로그인하고 몇 시간 안에 — "보안 알림(security alert)" 이메일이 왔다. 계정이 즉시 정지되었다. 그 결과:
이건 Stuart 혼자에게 일어난 일이 아니다. 비슷한 패턴의 사고는 Reddit r/aws, Hacker News, Twitter에서 거의 매달 보고된다. 가장 흔한 시나리오들:
AWS Bedrock의 공식 문서에는 다음과 같이 적혀 있다:
"AWS는 Amazon Bedrock에 대한 자동 abuse-detection 메커니즘을 운영합니다. 정책 위반이 의심되는 경우 AWS는 사용 정보를 요청할 수 있으며, 응답하지 않거나, 정책을 따르지 않거나, 따를 수 없는 경우 — AWS는 Amazon Bedrock에 대한 액세스를 정지할 수 있습니다."
문제는 — 이 문구는 합리적으로 들리지만, 실제로 정지된 사용자에게는 자동화된 메일 한 통과 며칠의 침묵이 따른다는 점이다.
Stuart의 사례에서 가장 시사적인 부분은, 그가 AWS WorkMail로 비즈니스 이메일을 운영하고 있었고, Route 53으로 도메인 DNS를 관리하고 있었다는 것이다. 그래서 AWS 계정이 정지되자 — 그의 회사 이메일과 도메인까지 함께 잠겼다.
이것은 클라우드 시대에 새롭게 등장한 위험이다. 우리는 클라우드를 인프라로만 사용하는 것이 아니라, 신원(identity), 통신(email), 결제(billing), 도메인(DNS)까지 한 사업자에게 통합시켜 왔다. 한 곳이 막히면, 우리의 디지털 존재 전체가 함께 막히는 구조다.
여기서 교훈은 명확하다:
이것은 단지 Stuart 같은 사람에게만 적용되는 이야기가 아니다. 2021년 Facebook 6시간 장애 때, 페이스북 직원들은 사옥에 들어갈 수가 없었다 — 사원증 인증 시스템조차 페이스북 내부 인프라에 의존하고 있었기 때문이다. 모든 달걀을 한 바구니에라는 격언은, 클라우드에 가장 잔혹하게 적용된다.
이렇게 길게 비판을 늘어놓고 보면, "AWS는 끝났는가?"라는 질문이 자연스럽다. 답은 단호히 "아니오"다.
2026년 1분기 AWS의 매출은 115억 달러 수준이며, 클라우드 시장 점유율 1위를 굳건히 유지하고 있다. 영업이익률은 30%대다. 어떤 비교의 기준에서도, AWS는 클라우드의 표준이자 거인이다.
그러나 — 풍경은 분명히 변하고 있다. 몇 가지 흐름을 짚어보자.
2024–2026년의 가장 큰 인프라 사건은 — 단연 생성형 AI다. 그리고 이 새 시장에서 AWS는 처음으로 명백한 추격자 입장에 섰다. 추론은 OpenAI/Anthropic의 자체 인프라, Microsoft Azure (OpenAI 통합), Google Cloud (Gemini, TPU), 그리고 최근에는 CoreWeave, Lambda Labs, Modal 같은 GPU 전문 클라우드들로 분산된다.
AWS는 Bedrock으로 응전한다. Anthropic Claude, AI21 Jurassic, Cohere, Meta Llama, Mistral, 그리고 자체 모델 Titan/Nova를 한 API에서 호출하게 한다. 가격은 매니지드 추론으로서는 합리적이고, 보안 통합은 강력하다. 그러나 — Stuart의 사례가 보여주듯이 — Bedrock 사용 자체가 abuse-detection의 표적이 되기도 한다.
또 다른 흐름은 정치적이다. 유럽은 GDPR과 Data Act, 그리고 GAIA-X 프로젝트로 "유럽적 클라우드"를 시도한다. 인도는 자체 데이터 거주(data residency) 규제를 강화한다. 중국은 사실상 별개의 클라우드 생태계(Alibaba Cloud, Tencent Cloud, Huawei Cloud)를 운영한다. 한국도 공공 클라우드 보안 인증(CSAP) 체계로 사실상의 데이터 거주 정책을 운영한다.
이 흐름 속에서 단일 클라우드 의존은 — 기술적 위험뿐 아니라 — 지정학적 위험이 된다. 코어닷투데이의 멀티 클라우드 전략 가이드에서 이 부분을 자세히 다룬다.
세 번째 흐름은 Cloudflare, Fly.io, Vercel, Deno Deploy 같은 회사들이다. 이들은 "거대한 중앙 데이터센터"가 아니라, 전 세계 수백 개 지점에 작은 워커들을 배치해, 사용자에게 가장 가까운 곳에서 코드를 실행한다. 콜드 스타트 5ms, 이그레스 거의 무료, 글로벌 분산이 디폴트.
Cloudflare Workers와 R2는 이그레스 비용이 0이라는 정책을 명시한다. R2의 가격 모델은 — S3 가격에서 이그레스만 뺀 것이다. 이 한 가지 차이가 얼마나 많은 작은 회사들의 비용 구조를 바꾸었는지는 산업 내에서 공공연한 비밀이다.
AWS도 가만히 있지 않는다. 2024년 이그레스 면제, 2025년 티어드 이그레스, SCP 정책 단순화, Bedrock Guardrails를 통한 안전 통제 — 모두 비판에 대한 응답이다.
2026년 5월 AWS re:Invent의 공식 슬로건이 무엇이냐 하면 — "You can choose." "당신은 선택할 수 있습니다." Andy Jassy 시대의 "Move fast, lock in" 분위기에서, 어떤 의미에서는 "Stay if you want"로 톤이 바뀌고 있다.
이것이 진심인지, 마케팅인지는 시간이 말해줄 것이다. 그러나 적어도 화법은 분명히 바뀌었다.
길었다. 이제 정리하자. Stuart의 글이 우리에게 주는 — 그리고 16년 전 버클리 보고서가 미리 짚어둔 — 교훈을, 2026년 개발자/CTO의 관점으로 압축하면 다음과 같다.
| 원칙 | 왜 | 어떻게 |
|---|---|---|
| 도메인은 분리하라 | 주 클라우드가 잠기면 도메인도 같이 잠긴다 | Namecheap, Cloudflare Registrar, Gandi 등 별도 등록 |
| 비즈니스 이메일은 분리하라 | 이메일이 잠기면 모든 비밀번호 복구가 불가 | Google Workspace, Fastmail 등 별도 운영 |
| 핵심 데이터의 백업은 다른 클라우드에 | 이그레스가 무서워도 한번 옮겨두면 보험이 된다 | Backblaze B2, Cloudflare R2 등 cold storage |
| 벤더 종속을 의식적으로 평가하라 | 편의를 위한 매니지드 서비스가 종속을 만든다 | Postgres → RDS는 OK, DynamoDB → 이전 어려움 |
| IaC와 GitOps를 기본으로 | "어떻게 만들어졌는지" 모르는 인프라는 옮길 수 없다 | Terraform/Pulumi + Git 이력 보존 |
| 이그레스를 비용 모델에 포함하라 | 숨어있는 가장 큰 비용 | CDN 활용, R2/B2로 정적 콘텐츠 분리 |
| 비상시 연락 채널을 확보하라 | 지원팀이 답이 없을 때 트위터/링크드인이 가장 빠르다 | AWS Heroes, 지역 커뮤니티 매니저 연락처 확보 |
Stuart의 글이 인상적인 이유는, 그것이 분노의 글이 아니기 때문이다. 그는 AWS를 사랑했다. 15년간 자신의 무료 시간을 들여 AWS 미트업을 조직했다. 어느 누구보다 AWS의 장점을 잘 안다.
그래서 그의 글은 사랑하는 사람과 헤어진 사람의 회고처럼 읽힌다. 무엇이 좋았는지, 무엇이 변했는지, 무엇이 변하지 않았는지. 그리고 결국 떠나는 이유.
20년 전 Andy Jassy의 비전은 진짜였다. "기숙사 방의 대학생이 세계 최대 기업과 같은 인프라를 쓴다"는 그의 약속은 실현됐다. 한국의 수많은 스타트업이 그 약속의 직접적 수혜자다. 코어닷투데이도, 이 글을 읽는 당신의 회사도, 어떤 형태로든 그 비전 위에 서 있다.
그러나 비전은 시간이 흐르면 — 모든 비전이 그렇듯 — 현실의 비즈니스가 된다. 비즈니스는 매출과 점유율과 회계연도 단위로 작동한다. 대학생 한 명의 자유에서 시작한 것이, 수십 년 묶인 페타바이트의 데이터로 끝날 수도 있다.
2026년의 우리에게 주어진 책임은 단순하다. 클라우드를 사랑하되, 종속되지 말 것. 매니지드 서비스의 편의를 누리되, 언제든 떠날 수 있는 형태로 인프라를 설계할 것. AI라는 새로운 거대 컴퓨팅 시대가, 똑같은 lock-in 함정의 새 버전이 되지 않도록 — 지금 결정해야 할 것이다.
Stuart의 글이 끝나는 문장은 이렇다.
"I'm fully out now. Domain, email, infrastructure — gone. And I sleep better." ("나는 이제 완전히 떠났다. 도메인, 이메일, 인프라 — 다 옮겼다. 그리고 더 잘 잔다.")
당신이 떠나든 머무르든, 그것은 당신의 선택이다. 그러나 선택할 수 있는 상태로 인프라를 유지하는 것 — 그것이 클라우드와 함께 살아가는 가장 어른스러운 자세다.
