AWS로 잠깐 돌아갔다가 왜 떠났는지 다시 깨달은 개발자

• 글쓴이는 AWS 초창기부터 찐으로 밀었던 사람임

  • SQS, S3, EC2, SimpleDB가 막 나오던 시절부터 AWS를 옹호했고, 멜버른에서 첫 AWS 이벤트까지 직접 열었다고 함
  • 당시 클라우드는 진짜 혁명이었음. 스타트업이 데이터센터에 장비 깔 필요 없이 몇 분 만에 서버를 띄울 수 있었으니까

• 그런데 15년쯤 지나면서 AWS에 대한 애정이 조금씩 깨졌다고 함

  • 처음엔 사소한 불만처럼 보였는데, 어느 순간 “아, 이 관계는 끝났네”로 바뀌는 식이었다는 비유를 듦
  • 이 글은 단순한 장애 후기라기보다, 오래 쌓인 AWS 피로감이 계정 정지 사건 하나로 다시 폭발한 글에 가까움

• 글쓴이가 AWS에 질린 이유는 꽤 구체적임

  • AWS가 초창기 6년 동안 Python 같은 언어용 공식 클라이언트 라이브러리를 직접 만들지 않고 커뮤니티에 떠넘겼다는 점을 강하게 비판함
  • Python 2에서 Python 3로 넘어가는 것도 너무 오래 걸렸다고 봄
  • DynamoDB는 하루 써보고 75달러 청구서를 받았고, 비용뿐 아니라 시스템 자체도 최악이었다고 깜
  • 데이터 전송 비용도 핵심 불만임. 예전엔 egress가 GB당 20센트였고, 지금도 GB당 9센트 수준이라 너무 비싸다고 말함

• IAM은 글쓴이에게 AWS 복잡성의 상징 같은 존재임

  • 인증·인가를 세밀하게 다룰 수 있는 건 맞지만, 정책과 역할이 너무 복잡해서 깊게 파야 겨우 안전하게 쓸 수 있다고 봄
  • 더 큰 문제는 IAM만 복잡한 게 아니라는 점임. 한 번 복잡성이 보이면 AWS 전체가 그렇게 보이기 시작했다는 얘기
  • “직접 서버 운영은 복잡하니 AWS를 써야 한다”는 주장도, 정작 AWS 운영에 비싼 전문가 팀이 필요하다는 점을 가린다고 비판함

• Lambda도 처음엔 혹했지만, 나중엔 가장 후회한 선택 중 하나였다고 함

  • 확장성은 매력적으로 보였지만, 느린 시작 시간과 개발 복잡도를 감수할 만큼의 실질적 이득을 못 느꼈다고 함
  • AWS를 떠날 때 가장 제거하기 힘들었던 것도 Lambda였다고 함. 서버리스의 편의성이 곧 벤더 락인이 되는 전형적인 케이스

• AWS가 오픈소스 생태계를 다루는 방식도 강하게 비판함

  • Elasticsearch, Redis, MongoDB 같은 프로젝트가 만든 시장 위에 AWS가 OpenSearch, Valkey, DocumentDB 같은 호스팅 서비스를 얹었다는 주장임
  • 그 결과 SSPL, Elastic License, RSAL 같은 방어적 라이선스가 늘어났고, 목적은 일반 사용자를 막는 게 아니라 AWS가 고객 관계와 수익을 가져가는 걸 막는 쪽에 가까웠다고 봄

• 그렇게 AWS를 거의 다 떠났지만, 일부 서비스는 남겨뒀다고 함

  • Route53에 도메인, S3에 일부 백업, AWS WorkMail에 비즈니스 이메일을 남김
  • 문제는 최근 AWS WorkMail 종료 안내까지 받았다는 점. 이미 떠난 줄 알았는데, 남겨둔 서비스가 여전히 발목을 잡는 상황임

• 최근 다시 AWS에 들어간 이유는 딱 두 가지였음

  • AWS Bedrock에서 Claude/Anthropic이 얼마나 잘 도는지 확인하고 싶었음
  • 집에 있는 제일 빠른 머신이 20코어·32GB RAM이라, 192코어·1TB RAM 머신에서 자기 코드를 벤치마크해보고 싶었음

• Bedrock 테스트 결과는 별로였다고 함

  • Claude Code 기준으로 동작은 하지만 더 느렸고, Anthropic 구독을 직접 쓰는 것보다 훨씬 비쌌다고 평가함
  • 프라이버시가 꼭 필요한 조직이라면 의미가 있겠지만, 본인은 다시 Bedrock을 쓸 생각이 없다고 함

• 더 큰 사건은 EC2 Spot 인스턴스 테스트 중 터짐

  • 192코어 머신을 띄워 3시간 정도 테스트하던 중 AWS에서 “계정 보안 침해 의심” 메일이 옴
  • 거의 dormant 상태였던 계정이 갑자기 비싼 컴퓨팅 리소스를 쓰니 보안 알람이 울린 것으로 보임
  • 글쓴이도 이 감지 자체는 이해한다고 함. 문제는 그다음 처리였음

• AWS 지원 대응은 글쓴이를 완전히 질리게 만든 지점임

  • 프리미엄 지원을 쓰지 않아서 24시간 답변을 기다려야 했고, 실제로는 3일이 지나도 응답이 없었다고 함
  • AWS 포럼에 글을 올린 뒤에야 “메일 지시사항을 다 수행하고 웹 대신 채팅을 써라”는 조언을 받음
  • 비밀번호 변경, 액세스 토큰 제거, 청구서 확인 등을 다 했고, 채팅 연결까지 30분 기다린 뒤 담당자와 대화함
  • 담당자는 내부 팀에 넘기겠다고 했지만, 24시간이 더 지나도 계정은 풀리지 않았고 “기다려라”는 답만 받음

• 글 작성 시점 기준으로 계정 제한 4일째였음

  • 글쓴이는 여전히 큰 머신에서 테스트를 하고 싶지만, 이제는 quota 요청까지 해야 할까 봐 걱정하는 상황
  • 더 심각한 건 비즈니스 이메일 시스템이 계속 죽어 있다는 점임
  • 결국 Route53, WorkMail까지 완전히 빼고 다시는 AWS로 돌아오지 않겠다고 결론냄

• 한국 개발자 입장에서 이 글의 포인트는 “AWS 싫다”가 아니라 “운영 리스크를 어디에 묶어둘 거냐”임

  • AWS가 나쁘다기보다, 복잡한 클라우드 계정 하나에 메일·도메인·백업·실험용 고가 리소스를 같이 얹으면 장애 반경이 커짐
  • 특히 작은 회사나 1인 개발자는 프리미엄 지원을 안 쓰는 경우가 많아서, 계정 제한 같은 이벤트가 터졌을 때 복구 시간이 비즈니스 리스크가 될 수 있음
  • 클라우드 비용 최적화만큼이나 계정 분리, 권한 분리, 핵심 서비스 분산도 진지하게 봐야 함

---

기술 맥락

• 이 글에서 실제 기술 선택은 “AWS에 핵심 운영 요소를 얼마나 남겨둘 것인가”에 가까워요. 글쓴이는 컴퓨팅은 떠났지만 Route53, S3 백업, WorkMail은 남겨뒀고, 바로 그 잔여 의존성이 계정 제한 때 비즈니스 이메일 중단으로 이어졌거든요.

• AWS IAM이나 보안 감지는 원래 계정을 보호하려고 있는 장치예요. dormant 계정에서 갑자기 192코어·1TB RAM 같은 고가 리소스가 켜지면 이상 징후로 보는 게 맞지만, 문제는 그 조치가 WorkMail 같은 별도 업무 시스템까지 같이 묶어버렸다는 점이에요.

• Lambda와 Bedrock 얘기는 벤더 락인의 다른 얼굴이에요. Lambda는 애플리케이션 구조를 AWS 실행 모델에 맞추게 만들고, Bedrock은 모델 호출을 AWS 과금·권한·지원 체계 안으로 넣어요. 편해 보이지만 나중에 빠져나올 때 비용이 생기는 구조죠.

• 그래서 실무적으로는 계정 분리와 서비스 분리가 중요해요. 실험용 고가 컴퓨팅, 회사 이메일, 도메인, 백업을 한 계정에 몰아두면 보안 이벤트 하나가 여러 운영 레이어를 같이 흔들 수 있거든요. 이 글이 과격하게 들려도, 장애 반경을 줄이라는 메시지는 꽤 현실적이에요.