--- title: "AWS로 잠깐 돌아갔다가 왜 떠났는지 다시 깨달은 개발자" published: 2026-05-09T08:37:41.000Z canonical: https://jeff.news/article/2574 --- # AWS로 잠깐 돌아갔다가 왜 떠났는지 다시 깨달은 개발자 초기 AWS 전도사였던 개발자가 오랜만에 AWS에 접속했다가 계정 제한과 느린 지원 때문에 비즈니스 이메일까지 멈춘 경험을 공유했다. 글의 핵심은 AWS가 여전히 강력한 플랫폼이지만, 복잡한 과금·IAM·락인·지원 구조가 작은 팀이나 개인 개발자에게 꽤 큰 운영 리스크가 될 수 있다는 점이다. - 글쓴이는 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센트 수준이라 너무 비싸다고 말함 > [!IMPORTANT] > 글쓴이가 특히 강조하는 건 AWS 비용이 단순히 “비싸다”가 아니라, 어디서 비용이 터질지 예측하기 어렵다는 점임. 데이터 이동, 내부 전송, 중복 과금 같은 함정까지 알아야 하니 운영 난도가 확 올라감. - 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 상태였던 계정이 갑자기 비싼 컴퓨팅 리소스를 쓰니 보안 알람이 울린 것으로 보임 - 글쓴이도 이 감지 자체는 이해한다고 함. 문제는 그다음 처리였음 > [!WARNING] > 계정 제한이 걸리자 새 리소스를 못 만드는 수준을 넘어 AWS WorkMail까지 멈췄고, 비즈니스 이메일 수신도 안 됐다고 함. 클라우드 계정 하나가 메일·도메인·컴퓨팅을 동시에 잡고 있으면 장애 범위가 생각보다 크게 번질 수 있음. - 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 과금·권한·지원 체계 안으로 넣어요. 편해 보이지만 나중에 빠져나올 때 비용이 생기는 구조죠. - 그래서 실무적으로는 계정 분리와 서비스 분리가 중요해요. 실험용 고가 컴퓨팅, 회사 이메일, 도메인, 백업을 한 계정에 몰아두면 보안 이벤트 하나가 여러 운영 레이어를 같이 흔들 수 있거든요. 이 글이 과격하게 들려도, 장애 반경을 줄이라는 메시지는 꽤 현실적이에요. ## 핵심 포인트 - 초기 AWS 팬이었던 필자는 복잡한 과금, IAM, Lambda 락인, 오픈소스 서비스 복제 문제 때문에 AWS를 떠났다고 말함 - AWS Bedrock에서 Claude를 테스트했지만 Anthropic 구독보다 훨씬 비싸고 느리다고 평가함 - 192코어·1TB RAM EC2 Spot 인스턴스를 테스트하던 중 계정 보안 경고가 발생했고, 계정 제한으로 WorkMail까지 중단됨 - 프리미엄 지원이 없으면 계정 제한 해제 같은 중요한 문제도 며칠씩 지연될 수 있다는 점이 드러남 ## 인사이트 AWS는 ‘필요하면 뭐든 켤 수 있는 플랫폼’이지만, 그만큼 계정·권한·과금·지원이 서비스의 단일 장애점이 되기도 함. 특히 이메일, 도메인, 백업처럼 조용히 굴러가야 하는 인프라를 한 클라우드 계정에 묶어두는 게 얼마나 위험한지 보여주는 사례다.