Hacker News 의견
  • AWS는 너무 비쌈. 완전히 AWS 위에 시스템을 올릴 이유가 생각보다 드묾. 예전엔 다들 베어메탈 서버 직접 돌릴 줄 알았는데, 이제는 그걸 잊은 듯함. 우리 팀은 730일 넘게 99.993% 가용성을 유지했고, 최근 AWS 리전 장애도 피해갔음. Cloudflare로 DDoS 방어를 하긴 하지만, DNS나 인그레스 관리가 풀타임 일이 되는 건 이해함. 하지만 마이크로서비스 몇 개와 DB 정도는 직접 돌려도 충분함. AWS는 대부분의 회사에 과금이 과함

    • AWS의 진짜 문제는 직원들의 AWS 종속화임. AWS 인증 따고, AWS Well Architected Framework에 맞춰야 한다는 분위기 속에서 스스로 생각하지 않게 됨. AWS의 락인 서비스는 일부러 싸게 보이게 가격을 책정하지만, 결국 더 깊이 묶이게 됨. 예를 들어 PostgreSQL을 DynamoDB로 옮기면 단기적으로는 절약 같지만, 장기적으로는 AWS 의존이 커짐
    • 온프레미스는 싸지만 전문 인력 확보가 어려움. 단순한 제품엔 잘 맞지만, 복잡한 시스템은 오히려 인건비와 운영 리스크가 커짐. AWS/Azure/GCP가 완벽하진 않지만, 요즘은 온프레미스 전문가가 너무 희귀함
    • AWS를 비판하면 이상하게 반발하는 사람들이 많음. Reddit에서도 비슷한 현상이 있음. 마치 누군가 돈 받고 AWS를 옹호하는 것처럼 느껴짐
    • 셀프호스팅 성공담엔 확증편향이 있음. 서버 직접 운영은 초기엔 좋아 보이지만, 1년쯤 지나면 문서와 실제 설정이 달라지고, 담당자가 퇴사하면 혼란이 커짐. 결국 많은 스타트업이 다시 AWS로 돌아감. 이런 실패담은 잘 공유되지 않음
    • 베어메탈을 잘 돌리려면 숙련된 엔지니어가 필요함. 신입이나 컨설팅 회사 출신 “클라우드 전문가”로는 어려움
  • 초창기 클라우드는 단순하고 가성비 좋은 서비스로 시작했지만, 지금은 200개 넘는 복잡한 서비스로 뒤엉켜 있음. 관리 안 하면 요금이 폭증함

    • 사실 AWS는 처음부터 “싸다”가 아니라 “빠르게 확장할 수 있다”가 핵심이었음. 2010년대 초엔 비쌌지만 유연성이 장점이었음. 지금도 성능 대비 가격은 여전히 비쌈. 서버 관리 기본기만 있으면 전용 서버가 훨씬 나음
    • AWS는 이제 200개 넘는 서비스로 과잉 확장됨. 기본 기능에 집중해야 함
    • AWS 콘솔에 들어갈 때마다 복잡함과 피로감이 밀려옴. 너무 비대함
    • AWS 서비스마다 가성비 편차가 큼. 특히 오래된 핵심 서비스들은 여전히 가치가 있음
  • AWS의 진짜 기능은 (1) 조직 확장과 권력 구조를 가능하게 함, (2) CapEx 대신 OpEx로 회계 처리 가능함, (3) 무능한 인사 구조를 감춤. 예전엔 5~10명으로 데이터센터를 돌릴 수 있었지만, 이제는 3000명짜리 DevOps 조직이 생김

    • OpEx vs CapEx 차이가 왜 중요한지 모르겠음. 결국 돈은 돈 아닌가?
    • 클라우드는 초기 스타트업엔 유용함. 용량 계획 걱정 없이 빠르게 성장 가능함. 하지만 성장률이 낮은 회사가 계속 클라우드에 머무르면 비효율적임
    • 온프레미스는 커스텀화가 심해 인력 교체가 어려움. 반면 AWS 인력은 어디서나 구할 수 있음
    • 숙련된 시스템 관리자는 실제로 구하기 어렵고 비쌈. 싸게 하려다 백업이 2년째 안 된 경우도 봄
  • 이 성공의 핵심은 24/7 일정한 부하임. 대부분의 회사도 사실상 비슷한 패턴임

    • 사실 초기에 단일 랙, 단일 데이터센터로 시작한 게 운이 좋았음. 신뢰성 비용을 미리 안 냈기 때문임
    • 관련 글: One Big Server
    • AWS는 종종 “재고 없음”이라며 예약 인스턴스를 강요함. 결국 상시 운영 비용과 비슷해짐
    • Hetzner 같은 곳은 AWS보다 10배 싸게 같은 성능을 제공함. 클라우드의 “탄력성”은 과장된 신화임
  • 탄력성 vs 기저 부하가 핵심임. 데이터 수집처럼 트래픽이 폭발적으로 몰릴 때만 클라우드가 유리함. 대부분의 경우엔 베어메탈이 낫음

  • 2010년대엔 하드웨어와 네트워크가 느렸지만, 지금은 CPU 성능과 효율이 수백 배 향상됨. 예전 64대 서버가 지금은 1대면 충분함. 앞으로는 100:1 비율까지 갈 것임. 이런 상황에서 클라우드의 장점은 점점 줄어듦

  • 아마존 직원으로서 보기에, Kubernetes 자체 관리는 너무 위험함. etcd 같은 구성요소는 불안정하고, 직접 패치까지 해야 했음. 글에서 말하는 셀프호스팅은 리스크가 과소평가됨

    • 다른 하이퍼스케일러에서도 Kubernetes 관리 실패로 큰 장애를 겪음. Microk8s처럼 단일 랙용 간단한 대안이 나음. 관련 글: Microk8s 6 Months Later
    • 복잡한 환경은 어디서든 어렵고, 결국 전문가가 필요함. AWS도 마찬가지로 쉽지 않음. 클라우드 장애가 나도 세상은 계속 돌아감
    • k3 같은 경량 버전은 훨씬 단순함
    • Kubernetes는 필요할 때만 써야 함. 기본값으로 쓰면 시간과 돈 낭비임
  • 많은 스타트업은 AWS 요금이 너무 비싸서 존재조차 못 했을 것임. 예를 들어 GeoIP 무료 다운로드(링크) 같은 건 불가능했을 것임. 클라우드는 느리고, 디스크 지연과 CPU 과밀이 심함. 월 1만 달러 이하에서는 괜찮지만, 그 이상이면 베어메탈이 훨씬 효율적임

    • 클라우드의 느린 성능에 익숙해져 이상한 적응 현상이 생김. 항상 베어메탈 기준으로 비교해야 함
  • 내가 일하던 회사도 트래픽이 적었는데 AWS로 옮기려 했음. 이유는 단순했음 — 이력서에 AWS를 넣고 싶어서였음. 개발자뿐 아니라 경영진도 마찬가지였음. “AWS 마이그레이션 리드”가 경력에 좋아 보였기 때문임. 결국 회사는 매각되고 사무실은 비었음. 이제는 “AWS에서 벗어났다”가 새로운 경력 포인트가 될지도 모름

    • 개발자들이 AWS를 원하면, 다음 세대는 AWS밖에 모르게 됨. 논의가 편향됨
    • 결국 결정은 리더십의 의지에 달림
  • 결국 중요한 건 무엇을 하려는가

    • 내부용 데이터 중심 웹사이트라면 서버랙 하나면 충분함
    • 불규칙하고 캐시 불가능한 대규모 트래픽이라면 클라우드가 유리함
    • DNS나 인그레스가 복잡하면 하이브리드 접근이 좋음
    • 데이터 규모가 커질수록 클라우드의 장기 감가상각 구조가 유리해짐