몇 달 전에 서버 두 대를 Linode와 DO에서 Hetzner로 옮겼는데, 비용을 비슷하게 크게 절감했음. 더 인상적이었던 점은 수십 개 사이트가 서로 다른 언어, 오래된 라이브러리, MySQL과 Redis까지 뒤엉킨 난장판 스택이었다는 점임. 그런데 Claude Code가 이걸 전부 옮겨줬고, 없는 라이브러리는 일부 코드를 다시 써가며 처리했음. 이제는 이런 복잡한 마이그레이션이 훨씬 쉬워져서, 앞으로는 사업자 간 이동성이 더 커질 것 같음
내 생각엔 사람들이 돈을 낸 건 마법 같은 컴퓨트가 아니라 10년치 붙여놓은 glue 코드를 안 건드리기 위해서였음. 그런데 에이전트가 그 glue를 먹어치우기 시작하면, 기존 사업자의 moat는 빠르게 얇아질 것 같음
솔직히 이건 Claude 광고 안에 Hetzner 광고가 또 들어간 느낌임. 대체 어디까지 중첩되는지 궁금해짐
모든 이야기를 꼭 AI 얘기로 가져갈 필요는 없다고 느낌
나도 Linode를 앞으로 몇 달 안에 떠날 예정임. 10년 넘게 썼고 고객도 많이 소개했는데, 가격을 계속 올려서 이제는 Hetzner 같은 곳에서 더 싸게 메모리 8배, 전용 NVMe, 전용 CPU를 받을 수 있음. 가상 서버의 쉬운 이전성 같은 장점은 조금 잃지만, 장애가 나더라도 Hetzner 지원은 늘 빠르고 유능했음
나도 Claude를 점점 더 DevOps에 쓰는 중임. 내가 가진 베어메탈 위에 Proxmox로 VM을 돌리는데, Claude가 여러 머신에 걸친 새 네트워크를 엄청 빠르게 최적화하고 구성해줘서 거의 동료나 잘 받는 sysadmin처럼 느껴짐
나는 AWS에서 Hetzner로 옮길 계획을 세우는 중임. Amazon은 경쟁사보다 때로는 20배 비싼 가격을 매기고, 좀 괜찮은 가격을 받으려면 장기 약정을 강요하며, 데이터 이전도 아주 비싸게 만들어둔 점이 너무 고객 적대적이라고 느낌. egress 요금으로 사람을 가둔다고 생각하겠지만, 사실은 한 부분만 경쟁사로 옮겨도 전체를 다 옮기게 만드는 압박으로 작동함. 그래도 나는 Amazon 전용 서비스 위에 플랫폼을 쌓지 않았기 때문에 이전이 조금은 쉬워진 편임
이 부분은 예전엔 맞았지만, 2024년 1월에 GCP가 egress 비용 면제 정책을 내면서 분위기가 바뀌었고, AWS도 몇 달 뒤 비슷한 정책을 맞춰냈음. 남으라고 설득하려는 건 아니고, 기술적으로는 waiver 요청이 가능하다는 점만 말하고 싶음. 실제로 어떤 범위까지 되는지는 나도 확실치 않고, AWS 문구를 보면 EU Data Act 영향도 있어 보였음
이런 글을 볼 때마다, 다들 이중화나 로드밸런서 같은 얘기는 잘 안 해서 의아함. 서버 한 대가 죽으면 여러 서비스가 같이 내려갈 수 있는데, 정말 이걸 괜찮다고 보는지 궁금함. 돈은 아꼈을지 몰라도 유지보수 시간과 미래의 골칫거리를 더 쓰게 될 수도 있음
이건 서비스 성격과 얼마나 중요한지에 따라 다르다고 봄. 서버 한 대가 10년 동안 굴러가며 그 기간에 1주~1개월 정도 다운되는 수준이면 충분히 받아들일 수 있는 경우가 많음. 소규모 비즈니스, 취미 사이트, 포럼, 블로그처럼 웹사이트가 핵심 업무가 아닌 곳은 짧은 다운타임이 큰 문제가 아닐 수 있음. 사실 이런 저트래픽 사이트의 긴 꼬리가 웹의 다수일 수도 있음. 모든 게 고가용성일 필요는 없고, 원하면 이런 사업자도 로드밸런서 같은 기능은 제공함
이런 글이 인기 있는 이유는 종종 요구사항과 해법의 불일치가 드러나기 때문이라고 봄. 취미 프로젝트나 작은 비즈니스에 엔터프라이즈급 아키텍처를 얹어 과설계한 경우라면, 가끔 하루쯤 다운돼도 괜찮아서 클라우드식 풀세팅이 꼭 필요하지 않을 수 있음. 다만 이번 글은 무중단 마이그레이션을 강조하면서, 정작 도착한 구조는 장애 허용성이 높지 않아 보인다는 점이 좀 묘했음. Hetzner 쪽에 약간만 구조를 더 얹어도 충분히 개선 가능했을 것 같음
많은 워크로드에는 그런 수준의 대비가 필요 없다고 봄. 그리고 단순함의 신뢰성을 과소평가하면 안 됨. 나는 오랫동안 Linux sysadmin으로 일했는데, 복잡한 시스템에서 보는 다운타임이 단순한 시스템보다 훨씬 많았음. 이론과 현실 사이 어딘가에서, 대부분의 경우 결국 단순한 쪽이 더 잘 버틴다는 인상을 받았음
공정하게 말하면, 원래도 DigitalOcean의 단일 VM을 쓰고 있었으니 클라우드 사업자의 장점을 크게 누리던 상황은 아니었다고 봄. 보통 이런 글은 클라우드에 잘못된 이유로 올라갔다가 물리적인 쪽으로 가는 게 맞는 경우와, 반대로 그렇게 옮기면 재앙이 되는 경우로 나뉘는데, 이번 건은 전자에 가까워 보임. DO에서 잘 돌던 구성이었다면 Hetzner에서도 적절한 DR 정책만 넣으면 충분히 괜찮을 듯함
아마 이 결정은 실제로 오랫동안 유지보수 지옥이나 미래의 골칫거리를 별로 겪어보지 않았던 경험 위에서 나온 것일 수도 있음
우리는 lithus.eu에서 여러 클라우드에서 Hetzner로 고객을 자주 옮겨봤음. 보통은 멀티서버, 때로는 멀티 AZ로 구성하고, Kubernetes로 워크로드를 분산해서 HA를 제공함. 단일 노드라면 Kubernetes가 과할 수 있지만, 노드가 여러 개면 훨씬 말이 됨. 백업은 Velero와 애플리케이션 레벨 백업을 함께 쓰고, 예를 들어 Postgres는 WAL 백업으로 PITR까지 가져감. 상태 데이터는 최소 두 노드에 두어 HA를 보장함. 성능 면에서도 베어메탈이 대체로 더 좋고, AWS 대비 응답 시간이 반으로 줄어드는 경우가 많았음. 이유는 가상화 자체보다도 NVMe, 낮은 네트워크 지연, 적은 cache contention 같은 주변 요소 덕분이라고 봄. 관련 내용은 예전에 쓴 HN 글에도 더 적어뒀음
나도 몇 년 전에 직접 측정해봤는데, 그 뒤로는 가상 서버를 다시 보지 않게 됐음. CPU 시간은 RAM처럼 예약되는 게 아니라서, 실제 하드웨어 대비 성능이 정말 별로였음. 측정 글도 참고할 만했음
k8s 배포는 옮겨 다니기가 정말 좋다고 느낌. 여러 클라우드의 관리형 서비스들에 비해 벤더 종속이 적음. 내 스택도 k8s, hosted Postgres, s3류 스토리지 정도라서, Postgres는 언제든 직접 호스팅할 수 있고 결국 핵심은 k8s와 s3 정도만 남음. Hetzner에도 s3 비슷한 게 있는 것 같긴 한데, 아직 안 봤고 100TB 옮기기는 꽤 큰 작업일 것 같음
참고로 HA는 high availability를 뜻함
글은 합리적이었는데 마지막에 이메일 달아둔 건 좀 홍보 문구처럼 보여서 아쉬웠음
이 글은 읽기가 꽤 힘들었음. Claude가 마이그레이션을 하고, 그다음 Claude가 쓴 보고서를 읽는 느낌이었음. LLM 덕분에 이렇게 절약했다면 그건 멋진 일인데, 글로 공개할 거면 최소한 퇴고해서 중복과 LLM식 서술은 정리했으면 좋겠음
원문을 안 읽는 사람이 많다는 건 알지만, 이번 글은 정말 고통스러운 수준으로 읽기 힘들었음
Hetzner는 조심해야 한다고 느낌. 예전엔 정말 좋아했지만 최근에 옮겨 나왔음. 우리 CI/CD 파이프라인에 쓰던 VM 약 30대를, 36달러 청구 분쟁 하나로 전부 내려버렸음. 은행 기록까지 포함해 전액 지급 증빙을 냈는데도 보려 하지 않았고, 긴급하게 연락하는 중에도 결국 접근을 모두 차단했음. 지금은 Scaleway로 옮겼음
고객 서비스가 의외로 적대적이라고 느낌. 그래도 나는 중요하지 않은 용도에는 아직 사용 중임
Hetzner의 청구 처리는 꽤 자동화되어 있지만, 보통 카드 결제가 실패해도 한 달 정도는 납부 유예를 주는 편이었음
몇 달 전 작은 SaaS 사이드 프로젝트용으로 AWS 대안을 찾다가, 비용 절감과 EU 클라우드 지원 차원에서 처음엔 Hetzner를 진지하게 봤음. 직접 해야 할 일이 많아도 감수할 생각이었는데, 결정적으로 IP 평판이 발목을 잡았음. 회사에서 쓰는 관리형 AWS 방화벽 규칙 중 하나가 Hetzner IP를 많이, 어쩌면 전부 막고 있었고, 내 업무용 노트북에서도 Hetzner IP에 호스팅된 사이트가 IT 정책 때문에 열리지 않았음. Cloudflare 같은 걸 쓰면 덜할 수는 있겠지만, DDoS 보호가 약하다는 얘기도 봤음. 결국 나는 EU 리전의 DO App Platform을 골랐고, 관리형 DB 옵션도 큰 장점이었음
경쟁사를 이런 식으로 막아버린다면 Amazon 입장에선 참 편리한 방식이겠다는 생각이 듦
어떤 방화벽 규칙을 말하는지는 모르겠지만, DO가 Hetzner보다 더 신뢰된다는 건 꽤 의외였음. 내가 스크래퍼나 해커를 볼 때는 DO ASN도 자주 보여서, 그쪽도 언젠가는 막힐 수 있다고 느낌
내 경험상 DO IP가 더 심각했음. 나도 바로 그 이유로 DO에서 옮겼음
나는 예전에 Tor 관련 스레드에 이 이슈를 쓴 적이 있음. Hetzner가 Tor 친화적이라서 IP 평판에 영향이 있을 수 있다고 추정했는데, 당시엔 평판 문제가 없다는 답도 있었음. 그런데 Tor Project 자료를 보니 Hetzner가 Tor 네트워크의 약 7%를 차지하는 듯해서, 이야기가 그만큼 단순하진 않아 보였음
아이러니하게도 나는 AWS와 Azure 차단만으로 봇 문제의 99%를 해결했음. 실제 사용자 피해는 0이었고, 그래서 아예 이 차단 기능만 서비스로 팔아볼까 생각 중임
이런 마이그레이션 경험을 공유한 점은 꽤 유익하고 고맙다고 느낌. 나는 DO와 Hetzner 비교를, DoorDash나 UberEats를 켜는 것과 직접 저녁을 만드는 것 사이의 트레이드오프처럼 봄. 비용 비율도 비슷한 느낌임. 나는 3대 클라우드와 온프렘을 다루지만, 자잘한 작업이나 PoC 테스트에는 여전히 DigitalOcean 콘솔로 감. 버튼 몇 번으로 서버나 버킷이 준비되고, sane default가 있고, 백업도 체크박스 하나로 붙는 식의 편의성은 시간값을 생각하면 분명 의미가 있음
무슨 뜻인지는 완전히 확신 못 하겠지만, Hetzner Console도 비슷하게 동작한다고 느낌
이 글에서 흥미로운 건 두 가지였음. 하나는 무중단 이전 절차 자체이고, 이건 범용적으로 참고할 만함. 다른 하나는 클라우드 인스턴스를 베어메탈로 바꾼 결정인데, 비용 절감과 함께 빠른 장애 전환과 백업 손실도 가격에 포함되어 있다고 봐야 함. 내가 한다면 200달러 정도 더 써서 hot spare를 하나 두고 며칠마다 주/대기를 바꿔가며 둘 다 정상 동작하는지 검증했을 것 같음. 비교적 적은 비용으로 치명적 장애 위험을 크게 줄일 수 있음
방금 설명한 건 사실 Hetzner Cloud가 이미 여러 해 동안 제공해온 경험과 거의 같음. 게다가 Hetzner Cloud API도 있어서, 버튼 클릭조차 없이 IaC로 전부 구성할 수 있음
내 경우엔 Hetzner 서버 위에 Coolify를 올려서 거의 원클릭 서비스 같은 경험을 얻고 있음
DB 백업을 어떻게 하는지 궁금했음. replica나 standby가 있는지, 아니면 그냥 시간 단위 백업 정도인지 알고 싶었음. 이런 단일 서버 구성에서는 SSD 같은 하드웨어 장애가 나면 앱이 바로 멈출 수 있고, 특히 SSD가 죽으면 다시 세팅하는 동안 몇 시간이나 며칠 다운될 수도 있다고 생각했음
Hetzner는 보통 하드웨어 서버를 2x 1TB SSD로 광고하고, 순용량 1TB를 위해 SW RAID1 구성을 강하게 권장함. 이미지 설치기도 기본이 그 방향임. 몇 년 뒤 첫 SSD가 죽더라도 모니터링이 잡아준다면 새 박스로 옮기거나, 중간 대안/replica를 쓰거나, 다른 디스크로 버티며 핫스왑을 받을 수 있음. 물론 물리 서버로 가면 클라우드의 이중화 일부를 잃게 되니, 절감액과 함께 위험 모델에 넣어 계산해야 함. 그리고 최소한 원격 저장소로 일일 백업조차 없으면 그건 무모하다고 봄. 이건 클라우드에서도 마찬가지이되, 설정은 더 쉬울 뿐임
그렇게 오래 다운돼도 아무도 크게 신경 안 쓸 수도 있음. 예를 들어 내 HOA 모바일 앱이 일주일 내려가 있어도 나는 별로 상관없음. 모든 것에 상시 가동이 필요한 건 아님
나도 같은 걱정을 했음. 이 글은 작성자가 충분히 고민하지 않고 공격적인 비용 절감만 본 느낌이었음. DigitalOcean VM은 아마 라이브 마이그레이션과 스냅샷을 지원했을 텐데, Hetzner에서도 그건 cloud 상품에서나 가능함. Hetzner 베어메탈에서는 디스크나 부품이 죽으면 그냥 죽는 것이고, 디스크 교체는 해주더라도 복구는 사용자가 처음부터 해야 함. Hetzner도 이 점을 여러 곳에서 분명히 밝히고 있음
내가 해본 것 중 가장 쉬웠던 건 MongoDB 쪽이었고, replication, sharding, failover가 매우 간단했음. 최근엔 PostgreSQL에서도 pg_auto_failover로 monitor 1대, primary 1대, replica 1대로 구성했는데, 설정과 함정을 좀 익히고 나니 이것도 꽤 쉬웠음. 내 경험상 무중단 이전도 가능했음
그들이 그런 트레이드오프를 받아들이겠다고 판단했다면, 그게 틀렸다고 단정할 수는 없다고 봄. 모든 앱이 24/7 가용성을 필요로 하진 않고, 대다수 웹사이트는 몇 시간 정도의 다운타임이 있어도 큰 타격이 없음. 비용 절감이 위험보다 크다면 충분히 합리적인 비즈니스 판단일 수 있음. 오히려 궁금한 건 그들이 어떤 백업·복구 전략을 갖고 있는지, 그리고 Hetzner로 옮기며 무엇이 바뀌었는지임
헤더에 들어간 밈 이미지는 내가 만든 것이었음. 이 글에 실었던 건데, 이렇게 두 번이나 쓰인 걸 보니 반가웠음
Hacker News 의견들
몇 달 전에 서버 두 대를 Linode와 DO에서 Hetzner로 옮겼는데, 비용을 비슷하게 크게 절감했음. 더 인상적이었던 점은 수십 개 사이트가 서로 다른 언어, 오래된 라이브러리, MySQL과 Redis까지 뒤엉킨 난장판 스택이었다는 점임. 그런데 Claude Code가 이걸 전부 옮겨줬고, 없는 라이브러리는 일부 코드를 다시 써가며 처리했음. 이제는 이런 복잡한 마이그레이션이 훨씬 쉬워져서, 앞으로는 사업자 간 이동성이 더 커질 것 같음
나는 AWS에서 Hetzner로 옮길 계획을 세우는 중임. Amazon은 경쟁사보다 때로는 20배 비싼 가격을 매기고, 좀 괜찮은 가격을 받으려면 장기 약정을 강요하며, 데이터 이전도 아주 비싸게 만들어둔 점이 너무 고객 적대적이라고 느낌. egress 요금으로 사람을 가둔다고 생각하겠지만, 사실은 한 부분만 경쟁사로 옮겨도 전체를 다 옮기게 만드는 압박으로 작동함. 그래도 나는 Amazon 전용 서비스 위에 플랫폼을 쌓지 않았기 때문에 이전이 조금은 쉬워진 편임
이런 글을 볼 때마다, 다들 이중화나 로드밸런서 같은 얘기는 잘 안 해서 의아함. 서버 한 대가 죽으면 여러 서비스가 같이 내려갈 수 있는데, 정말 이걸 괜찮다고 보는지 궁금함. 돈은 아꼈을지 몰라도 유지보수 시간과 미래의 골칫거리를 더 쓰게 될 수도 있음
우리는 lithus.eu에서 여러 클라우드에서 Hetzner로 고객을 자주 옮겨봤음. 보통은 멀티서버, 때로는 멀티 AZ로 구성하고, Kubernetes로 워크로드를 분산해서 HA를 제공함. 단일 노드라면 Kubernetes가 과할 수 있지만, 노드가 여러 개면 훨씬 말이 됨. 백업은 Velero와 애플리케이션 레벨 백업을 함께 쓰고, 예를 들어 Postgres는 WAL 백업으로 PITR까지 가져감. 상태 데이터는 최소 두 노드에 두어 HA를 보장함. 성능 면에서도 베어메탈이 대체로 더 좋고, AWS 대비 응답 시간이 반으로 줄어드는 경우가 많았음. 이유는 가상화 자체보다도 NVMe, 낮은 네트워크 지연, 적은 cache contention 같은 주변 요소 덕분이라고 봄. 관련 내용은 예전에 쓴 HN 글에도 더 적어뒀음
이 글은 읽기가 꽤 힘들었음. Claude가 마이그레이션을 하고, 그다음 Claude가 쓴 보고서를 읽는 느낌이었음. LLM 덕분에 이렇게 절약했다면 그건 멋진 일인데, 글로 공개할 거면 최소한 퇴고해서 중복과 LLM식 서술은 정리했으면 좋겠음
Hetzner는 조심해야 한다고 느낌. 예전엔 정말 좋아했지만 최근에 옮겨 나왔음. 우리 CI/CD 파이프라인에 쓰던 VM 약 30대를, 36달러 청구 분쟁 하나로 전부 내려버렸음. 은행 기록까지 포함해 전액 지급 증빙을 냈는데도 보려 하지 않았고, 긴급하게 연락하는 중에도 결국 접근을 모두 차단했음. 지금은 Scaleway로 옮겼음
몇 달 전 작은 SaaS 사이드 프로젝트용으로 AWS 대안을 찾다가, 비용 절감과 EU 클라우드 지원 차원에서 처음엔 Hetzner를 진지하게 봤음. 직접 해야 할 일이 많아도 감수할 생각이었는데, 결정적으로 IP 평판이 발목을 잡았음. 회사에서 쓰는 관리형 AWS 방화벽 규칙 중 하나가 Hetzner IP를 많이, 어쩌면 전부 막고 있었고, 내 업무용 노트북에서도 Hetzner IP에 호스팅된 사이트가 IT 정책 때문에 열리지 않았음. Cloudflare 같은 걸 쓰면 덜할 수는 있겠지만, DDoS 보호가 약하다는 얘기도 봤음. 결국 나는 EU 리전의 DO App Platform을 골랐고, 관리형 DB 옵션도 큰 장점이었음
이런 마이그레이션 경험을 공유한 점은 꽤 유익하고 고맙다고 느낌. 나는 DO와 Hetzner 비교를, DoorDash나 UberEats를 켜는 것과 직접 저녁을 만드는 것 사이의 트레이드오프처럼 봄. 비용 비율도 비슷한 느낌임. 나는 3대 클라우드와 온프렘을 다루지만, 자잘한 작업이나 PoC 테스트에는 여전히 DigitalOcean 콘솔로 감. 버튼 몇 번으로 서버나 버킷이 준비되고, sane default가 있고, 백업도 체크박스 하나로 붙는 식의 편의성은 시간값을 생각하면 분명 의미가 있음
DB 백업을 어떻게 하는지 궁금했음. replica나 standby가 있는지, 아니면 그냥 시간 단위 백업 정도인지 알고 싶었음. 이런 단일 서버 구성에서는 SSD 같은 하드웨어 장애가 나면 앱이 바로 멈출 수 있고, 특히 SSD가 죽으면 다시 세팅하는 동안 몇 시간이나 며칠 다운될 수도 있다고 생각했음
헤더에 들어간 밈 이미지는 내가 만든 것이었음. 이 글에 실었던 건데, 이렇게 두 번이나 쓰인 걸 보니 반가웠음