Kubernetes는 처음엔 웹앱 컨테이너 몇 개 돌리기엔 괜찮아 보여도, 곧 SDN을 얹고 온갖 서비스가 붙으면서 걷잡을 수 없이 비대해지곤 함
클러스터를 "최적화"하고 "하드닝"할수록 클라우드 비용, 장애, 다운타임, 디버깅 노력까지 전부 2~3배로 불어났음
결국 그런 DevOps 관성을 버리고 클러스터를 없앤 뒤, Debian 단일 VM에 방화벽 켜고 Kamal로 Docker 배포했더니 인프라 안정성과 신뢰성이 가장 좋아졌고 비용도 크게 내려감
대부분의 비즈니스 앱은 수백~수천 사용자 규모라 큰 VM 하나면 충분한 경우가 많고, Google 같은 클라우드가 하드웨어 장애는 처리해주니 필요할 때만 두 번째 VM을 띄워 Cloudflare에서 IP만 바꿔도 됨
웹앱 컨테이너 몇 개 돌리려고 Kubernetes를 쓰는 것부터 이미 방향이 잘못된 경우가 많음
너무 작은 규모에도 k8s를 들이대는 일이 흔하고, 그런 식이면 애초에 k8s가 필요한 스케일이 아닌 듯함
Kubernetes는 거의 어떤 배포 아키텍처도 만들 수 있는 저수준 primitive를 제공하지만, 그걸 직접 다루려면 YAML과 씨름해야 해서 너무 번거로움
그래서 흔한 배포 패턴을 단순화하는 상위 레이어가 필요하고, Knative가 그런 예시임
기반 primitive를 전부 노출하려 드는 해법은 결국 Kubernetes만큼 복잡해질 수밖에 없음
내가 만든 https://github.com/openrundev/openrun은 팀용 내부 웹앱 배포를 선언형으로 처리하고, SAML/OAuth와 RBAC도 붙으며 Docker 단일 머신과 Kubernetes 둘 다 지원함
이건 k8s 문제라기보다 조직 문제에 더 가까워 보임
과하게 복잡하고 디버깅하기 어렵고 돈 많이 드는 사고방식은 VM에서도 그대로 재현될 수 있음
다만 지금은 단일 Debian VM이 그들의 정책 레이더 밖에 있어서 자유로운 것뿐일 수 있음
누군가 끼어들기 시작하면 HA, 롤아웃/롤백, 3~5대 VM, 가상 네트워크 정책, 보안 스캐너 4개, 로그 프로세서 2개, watchdog, 네트워크 모니터, mTLS, 트래픽 가시성 장비까지 줄줄이 붙이려 들 가능성이 큼
대부분의 앱에는 단일 VM이 가장 실용적이지만, 마음 편하게 운영하려면 최소 2대는 두는 편을 선호함
한 대 더 있으면 업그레이드나 변경 작업 중 장애가 나도 덜 불안함
내가 만드는 https://github.com/psviderski/uncloud는 Kamal에서 영감을 받아 멀티머신 구성을 단일 VM만큼 단순하게 만들고, zero-config WireGuard 오버레이와 표준 Docker Compose로 여러 VM에 배포함
오케스트레이터나 control plane 복잡도 없이 시작은 1대에서 하고, 필요할 때 클라우드 VM과 온프렘을 섞어 확장할 수 있음
나는 오히려 k8s가 Win95 이후 최고 수준으로 잘 만든 소프트웨어라고 느낌
프로덕션에서 써봤을 때 매 순간 좋았고, 컴퓨팅 자체를 다시 정의한 수준처럼 보였음
그래서 이렇게까지 싫어하는 쪽의 관점을 내가 놓치고 있는 듯함
OP는 Tailscale 공동창업자 중 한 명이라 맥락상 더 흥미로움
전통적인 Cloud 1.0 회사들이 VM 기본값으로 3000 IOPS 정도를 주면서도 노트북은 50만 IOPS가 나오는 현실을 짚은 건 정확해 보임
비전은 정말 좋고 내가 딱 타깃 고객 같기도 한데, 결국 성공이 커질수록 이상보다 수익 압박이 앞서는 익숙한 경로로 갈까 봐 걱정됨
클라우드 가격은 비용 기반이 아닌 경우가 많고, 특히 고객이 깊게 묶인 뒤에만 크게 늘어나는 bandwidth나 NAT gateway 같은 항목에서 강하게 이익을 남기도록 설계되곤 함
OP도 이런 구조를 모를 리는 없다고 봄
OpenStack cloud를 운영해봤는데, 호스트 로컬 NVMe를 VM에 직접 붙이는 방식의 IO 성능은 정말 압도적임
다만 그 스토리지는 기본적으로 ephemeral이고, 중복성도 충분치 않음
RAID1으로 하드웨어 장애를 줄일 수는 있어도 붙일 수 있는 NVMe 수가 줄고, 호스트의 RAM/CPU 같은 다른 문제로 VM을 옮겨야 할 때도 깔끔한 방법이 없음
결국 이런 VM은 거의 베어메탈처럼 취급해야 하고, 데이터베이스 복제 같은 애플리케이션 레이어 중복화가 필요함
Azure는 자기들이 원할 때 VM을 옮기고 ephemeral 데이터를 날릴 수 있다고 가정해야 하지만, OpenStack에서는 필요 시 VM을 꺼두고 로컬 블록 레벨 마이그레이션으로 다른 호스트에 NVMe 데이터까지 복사할 수 있었음
그래도 호스트가 크래시하면 그 VM은 호스트가 살아날 때까지 내려가 있는 구조라 앱 레벨 이중화가 전제돼야 했음
직접 fio로 테스트해봤는데 저가형 플랜에서 Hetzner와 DigitalOcean 둘 다 대략 3900 IOPS, 15MB/s, 평균 2.1ms 수준이었음
하지만 99.9퍼센타일 지연은 Hetzner가 약 5ms, DO는 약 18ms였고 최대 지연은 Hetzner 7ms 대 DO 85ms로 차이가 꽤 큼
순차 dd에서는 Hetzner가 1.9GB/s, DO가 850MB/s였음
가격도 Hetzner는 4유로인데 DO 인스턴스는 18달러라 차이가 큼
많은 클라우드 벤더가 IOPS와 bandwidth에서 엄청난 값을 받음
글 다 읽기 전에 썼는데, 마침 OP도 정확히 그 둘을 집어 말하고 있었음
VM 기본값이 정말 3000 IOPS 수준이라면, 클라우드 사업자가 일부러 사용자를 S3 같은 독점 스토리지와 마이크로서비스 구조로 밀어 넣는 건가 싶어짐
단순한 서버조차 머신 내부 DB를 쓰기 어렵게 만들어 lock-in을 유도하는 셈일 수 있음
가격이 비용 기반이 아니라는 건 Business 101에 가까움
물건 하나 만드는 데 X가 드니 1.y*X로 Y 가격을 정한다는 식은 실제 시장 가격 책정과 거리가 멂
bottom-up보다 top-down이 더 현실적임
AI를 둘러싼 논쟁이 극단으로 갈리는 것처럼 Kubernetes도 똑같이 양극화되어 보임
몇 년간 다양한 크기의 클러스터를 운영했지만, 장애 원인이 k8s 자체였던 적은 한 번도 없었음
한 번은 한 시간짜리 완전 정전급 장애가 있었는데, k8s를 싫어하던 쪽은 전부 그 "망할 k8s 시스템" 탓으로 돌리려 했음
실제 원인은 특정 상황에서 서비스가 순식간에 수만 개 포트를 열어 자체 DOS를 일으킨 것이었음
k8s가 미래의 전부라고 보지도 않고 쓰레기라고 보지도 않으며, 진짜 필요할 때는 좋은 시스템이라고 생각함
Kubernetes에 대한 불만은 대체로 두 가지로 수렴함
하나는 배울 게 너무 복잡한데 내 문제엔 필요 없고 기존 배포 방식으로 충분하다는 쪽이고, 다른 하나는 베어메탈보다 비용/에너지 효율이 낮다는 쪽임
대개 둘은 같이 감
이런 양극화는 점점 더 많은 주제에 적용되는 듯함
적당히 중립적이거나 무관심한 입장이 오히려 드물어지고 있고, 미국 정치도 바로 떠오름
이해하지 못하는 대상을 탓하기는 늘 쉬움
나도 k8s는 잘 모르고 staff engineer가 pod와 cluster 얘기하면 눈이 풀리지만, 우리 팀에는 잘 맞고 실제로 돌아감
망치만 가진 사람에겐 모든 게 못처럼 보이고, 도끼를 든 사람은 왜 다들 망치로 나무를 패려 하는지 의아해함
심지어 도끼가 맞는 일인데 망치 든 사람에게 일자리를 빼앗기는 상황이면 망치를 미워하기도 쉬워짐
결국 다 추상화 수준의 문제이고, 그 추상화를 올바르게 쓰느냐가 핵심임
k8s는 많은 사용 사례에서 best practice가 어느 정도 정리돼 있지만, LLM 쪽은 아직 무엇이 best practice인지조차 잘 모름
이 글은 k8s 자체를 까기보다, cloud라는 근본 문제를 k8s라는 립스틱으로는 해결할 수 없다는 쪽에 더 가까워 보임
VM이 CPU/메모리에 묶인 형태라 일이 아니라 시간에 비용을 내게 된다는 지적에 강하게 공감함
그래서 저렴한 Hetzner 경매 서버를 하나 사서, 내가 만든 self-hostable Firecracker orchestrator 위에 올려 쓰고 있음 https://github.com/sahil-shubham/bhatti, https://bhatti.sh
원하는 건 하드웨어를 사서 VM을 마음껏 쪼개 쓰고, 프로비저닝이나 라이프사이클은 신경 쓰지 않는 것이었음
유휴 VM은 메모리 상태를 디스크에 스냅샷하고 RAM을 전부 반환하니, 하드웨어는 내 것이고 VM은 disposable하며 놀고 있을 때 비용이 거의 없음
특히 memory-state snapshot이 생기면 모든 게 재개 가능해진다는 점이 생각보다 훨씬 강력했음
로그인된 Chromium 상태를 스냅샷해두고 필요할 때 세션 복제본을 즉시 띄울 수 있고, 에이전트는 샌드박스 안에서 일하며 preview 환경용 docker compose도 거기서 돌림
아무것도 안 돌 때 서버는 사실상 idle이고, 월 100달러짜리 박스 하나가 이걸 다 처리함
처음 보기엔 꽤 흥미로움
문서는 충실하고 유용하지만, 상당 부분이 AI가 쓴 티가 나서 조금 더 간결했으면 좋겠음
그래도 "design decisions" 섹션은 특히 좋았고, 거기서 새로 배운 것도 있었음
아직이라면 Show HN에도 올려볼 만함
샌드박스는 구체적으로 무엇을 쓰는지 궁금함
Bhatti 정말 멋져 보임
Bhatti라는 이름도 아주 좋음
이미 쓰이지 않는 소프트웨어가 넘쳐나는데, 왜 코드를 더 많이 찍어내는 것에 집착하는지 잘 모르겠음
앱스토어만 봐도 아무도 안 쓰는 소프트웨어가 한가득임
LLM의 더 명백한 용도는 소프트웨어를 더 많이 만드는 게 아니라 더 나은 소프트웨어를 만드는 쪽이어야 한다고 봄
코드 생성 일변도에서 벗어나 다른 방향으로 초점이 옮겨가길 바라고, LLM이 더 좋은 코드를 쓰게 도와줄 수 있는 방법은 많음
우리가 소프트웨어를 너무 전통적인 방식으로만 보고 있는 듯함
정교하게 만들고 유지보수하고 업데이트하는 결정론적 시스템이라는 그림은 여전히 남겠지만, AI는 이미 사용자의 컴퓨터 상호작용 방식을 바꾸고 있음
그 결과 훨씬 더 일회용에 가까운 소프트웨어가 생겨날 것 같음
지금은 아직 "AI가 엔지니어의 소프트웨어 작성에 어떻게 도움을 줄까" 단계지만, 점점 "엔지니어가 AI가 더 잘 소프트웨어를 쓰게 하려면 무엇을 할까"로 이동하는 중이라 봄
그러면 소프트웨어가 무엇인지, 컴퓨터 상호작용을 어떻게 만들어야 하는지에 대한 관점이 완전히 다른 새로운 엔지니어 집단이 들어올 것임
때로는 better가 곧 내 특수한 사용 사례에 딱 맞게 customized되었다는 뜻이기도 함
앱스토어에 한 번도 올라오지 않을 맞춤형 소프트웨어가 굉장히 많아질 듯함
그건 Jevons paradox의 정확한 뜻은 아님
소프트웨어 생산 단가가 내려갔는데도 수요 증가가 절감 효과를 압도해서 총지출이 오르는 상황이어야 Jevons paradox라고 할 수 있음
이 개념은 가격 변화에 수요량이 크게 반응하는, 즉 수요 탄력성이 큰 시장에서 성립함
나는 오히려 그 방향이 이상적이라 봄
게임을 빼면, 수백만~수십억 명이 쓰는 단일 소프트웨어를 만드는 게 얼마나 이상한 방식이었는지 나중엔 돌아보게 될 것 같음
이제 사람들은 엇갈린 우선순위나 왜곡된 수익모델에 덜 휘둘리고, 자신이 진짜 원하는 일을 정확히 해주는 소프트웨어를 만들 수 있게 됨
그런 소프트웨어가 정의상 더 고품질이라고도 볼 수 있음
최근 소프트웨어 패러다임은 SaaS였고, 큰 capex를 고객 전체에 분산하고 opex는 구독으로 회수하는 구조였음
그래서 양쪽 모두 비용과 매출 예측이 쉬워졌지만, 핵심은 가능한 한 최대한 범용적인 소프트웨어를 만드는 데 있었음
그 결과 일부 사용자에게만 중요한 UX나 기능은 계속 잘려나감 Vibe coding과 LLM 가속 개발은 이걸 뒤집을 수 있음
이제 모두가 자기 필요와 선호에 맞춘 커스텀 소프트웨어를 감당할 수 있게 되고, Salesforce 고객 15만 명이 같은 CRM을 쓰는 대신 15만 개의 맞춤형 CRM을 쓰는 세상을 상상할 수 있음
소프트웨어 확장 여지는 지금 엄청나게 큼
소프트웨어 비대화 사이클를 이해하지 못하면 계속 같은 실수를 반복하게 됨
lean software에서 시작해, 사용자 요구 기능이 쌓이고, 점점 bloated mess가 되고, 다시 더 작은 리라이트가 필요해지고, 또 lean software로 돌아가는 식임
사실 루프보다는 나선형에 가까움
리부트는 대개 망하거나, 아니면 뭔가 핵심을 제대로 맞춰서 기존 강자를 위협할 정도로 전진함
해법은 사람마다 각자에게 맞춘 별도 소프트웨어를 만드는 것일 수도 있음
DevOps를 이력서 채우기, 과도한 복잡성의 원흉처럼 깎아내리는 시선은 스타트업 사고방식에 더 가깝다고 느낌
작은 회사에선 DevOps 한 사람이 인프라를 다 맡기도 하겠지만, 특히 금융권에서는 실제로 방향을 쥐는 쪽이 플랫폼 엔지니어링 MD들인 경우가 많음
이들은 소프트웨어 엔지니어들을 수많은 작은 그룹으로 쪼개고, 각 팀이 자기 repo, 자기 배포, 자기 모든 것을 통제하길 바라며, microservices가 그 권한을 준다고 믿음
장담하건대 DevOps 쪽은 복잡성을 싫어함
밤과 주말에 호출되는 쪽이 바로 그들이고, 늘 "인프라 문제"라는 전제로 시작되기 때문임
배포 로그는 로그 집계 시스템에 다 들어가 있는데도, 정작 개발자가 자기 배포 문제를 직접 로그 보고 해결하는 건 드물고 곧바로 Incident가 됨
이제 마이크로서비스도 지난 유행으로 봐야 하지 않나 싶음
exe.dev는 좋게 봤고, LLM 개발 흐름을 매끄럽게 하면서도 루트 권한이 있는 Linux 머신 유연성을 제공하는 쪽엔 분명 기회가 있다고 봄
그런데 "반쯤 구현되고 반쯤 생각된 추상화에 계속 배신당했다"는 문장을 읽으니, 역설적으로 그게 바로 내가 Tailscale에서 느낀 경험이기도 함
네트워킹을 쉽게 해준다더니 배터리는 왜 이렇게 빨리 닳는지, 방화벽 규칙은 다른 도구와 충돌하게 왜 바꿔놓는지, 버그 트래커는 왜 조용한지 결국 내부 구현을 내가 이해해야 하는 상황이 됨
그래서 "No thank you"가 나오게 됨
그 "No thank you"가 exe.dev를 향한 말로 읽히지 않았길 바람
그 서비스 자체는 정말 멋져 보임
Tailscale ACL을 내 용도에 맞게 구성하기 어려운 이유가, 주소 공간이 아니라 디바이스 정체성 기준의 규칙을 사실상 지원하지 않는 것처럼 보이기 때문임
라우터 ACL을 짜는 게 아니라 peer-to-peer 네트워크 계층을 구성하려는 건데, 그 지점이 아쉬움
나는 그냥 Hetzner를 씀
클라우드 회사들이 제공하는 건 전부 너무 비싸고, 내가 직접 돌리는 Postgres HA와 백업은 10년 동안 무중단으로 운영됐는데도 RDS나 CloudSQL 프로덕션 비용의 10분의 1 정도였음
Grafana에서 수집한 메트릭으로 인스턴스를 직접 오토스케일하고, webhook 기반 autoscaler도 아주 단순하게 잘 돌아가며 한 번도 문제를 일으키지 않았음
그래서 이제 왜 GCP나 AWS를 써야 하는지 잘 모르겠음
서비스는 전부 HA고 백업도 매일 아주 잘 됨
25년 전에 User-Mode Linux가 막 뜨던 시절 호스팅 회사를 창업했었음
그때 목표는 유연성이 가장 큰 dedicated server 경험을 그대로 싸게 재현하는 것이었고, UML이 그걸 가능하게 해줬음
그런데 2010년대 내내 나는 개발자 대다수가 편의 조금 때문에 스택의 모든 조각을 계량 과금당하는 방식을 택하지는 않을 거라고 완전히 잘못 짐작했음
요즘 20대 소프트웨어 엔지니어도 eBay에서 산 서버와 라우터로 고트래픽 웹앱 플랫폼을 꾸릴 줄 아는지 궁금함
나도 작년에 그렇게 해서 50PiB+ 데이터스토어를 만들었고, 중대형 프로젝트에서 이런 방식이 얼마나 쓰이는지 진심으로 궁금함
Hetzner는 물리적 번거로움을 많이 걷어내면서도 경제적 이점을 거의 그대로 주는데, 왜 호스팅 세계의 왕이 아니라 2021년 기준 매출 3억6700만 유로 수준에 머무는지 의아함
dedicated server 다발을 다루는 지식이 그렇게까지 비전문화돼서 사람들이 이 정도 큰 절감을 외면한다고 믿기 어렵기도 함
기업은 사내 서버 관리와 운영을 줄이려고 cloud services를 사고, 결국 적합한 인력을 뽑는 비용과의 트레이드오프로 판단함
다만 맞는 사람을 구할 수 있다면 직접 운영하는 편이 훨씬 싸질 수 있다는 건 맞음
예전엔 개인 프로젝트에도 Heroku나 Render 같은 플랫폼을 자주 썼지만, 요즘은 Linux 서버 하나에 Docker Compose와 Cron만 둠
매분 cron이 docker pull로 최신 이미지를 받고, 새 버전이 있을 때만 docker up -d로 교체함
앞단엔 HTTPS용으로 caddy를 두고, 이렇게 몇 년째 아주 싸고 안정적으로 굴러감
요즘은 베어메탈 서버에 SSH로 들어가서 Claude에게 Postgres 세팅하라고 시키면 끝나는 수준이기도 함
처음부터 5배 빠른 서버를 감당할 수 있으니 굳이 오토스케일링이 필요 없을 때도 많음
대안은 이미 많고, 나는 https://shellbox.dev를 만들었음
exe와 달리 쓴 만큼만 과금하고 scale-to-zero가 되며, SSH로 즉시 VM을 띄울 수 있음
일반 Linux라서 VSCode와 Zed remote도 지원하고, nested virtualization도 가능함
투자하고 싶다면 500만 달러만 있어도 괜찮음
며칠 전엔 browser 기반 codeserver, zellij browser mode, syncthing, ssh, pi agent, wireguard를 조합해서 꽤 안정적인 환경을 즉흥적으로 만들었음
외부에 노출된 포트는 없고, 모든 웹 프론트엔드는 비밀번호로 보호됨
공개할 생각은 없고, TV 뒤 개인 Raspberry Pi에서 돌리는 내 격리 개발 환경임
비용도 사실상 들지 않음
서비스도 잘 되길 바람
서비스는 깔끔해 보이지만, 웹사이트 정보만으로는 신뢰하기엔 부족함
실제 기반 인프라가 어디 있는지, 어떤 보안 보장을 받는지 등이 명확하지 않아 워크로드를 맡기기 어려움
Hacker News 의견들
Kubernetes는 처음엔 웹앱 컨테이너 몇 개 돌리기엔 괜찮아 보여도, 곧 SDN을 얹고 온갖 서비스가 붙으면서 걷잡을 수 없이 비대해지곤 함
클러스터를 "최적화"하고 "하드닝"할수록 클라우드 비용, 장애, 다운타임, 디버깅 노력까지 전부 2~3배로 불어났음
결국 그런 DevOps 관성을 버리고 클러스터를 없앤 뒤, Debian 단일 VM에 방화벽 켜고 Kamal로 Docker 배포했더니 인프라 안정성과 신뢰성이 가장 좋아졌고 비용도 크게 내려감
대부분의 비즈니스 앱은 수백~수천 사용자 규모라 큰 VM 하나면 충분한 경우가 많고, Google 같은 클라우드가 하드웨어 장애는 처리해주니 필요할 때만 두 번째 VM을 띄워 Cloudflare에서 IP만 바꿔도 됨
너무 작은 규모에도 k8s를 들이대는 일이 흔하고, 그런 식이면 애초에 k8s가 필요한 스케일이 아닌 듯함
그래서 흔한 배포 패턴을 단순화하는 상위 레이어가 필요하고, Knative가 그런 예시임
기반 primitive를 전부 노출하려 드는 해법은 결국 Kubernetes만큼 복잡해질 수밖에 없음
내가 만든 https://github.com/openrundev/openrun은 팀용 내부 웹앱 배포를 선언형으로 처리하고, SAML/OAuth와 RBAC도 붙으며 Docker 단일 머신과 Kubernetes 둘 다 지원함
과하게 복잡하고 디버깅하기 어렵고 돈 많이 드는 사고방식은 VM에서도 그대로 재현될 수 있음
다만 지금은 단일 Debian VM이 그들의 정책 레이더 밖에 있어서 자유로운 것뿐일 수 있음
누군가 끼어들기 시작하면 HA, 롤아웃/롤백, 3~5대 VM, 가상 네트워크 정책, 보안 스캐너 4개, 로그 프로세서 2개, watchdog, 네트워크 모니터, mTLS, 트래픽 가시성 장비까지 줄줄이 붙이려 들 가능성이 큼
한 대 더 있으면 업그레이드나 변경 작업 중 장애가 나도 덜 불안함
내가 만드는 https://github.com/psviderski/uncloud는 Kamal에서 영감을 받아 멀티머신 구성을 단일 VM만큼 단순하게 만들고, zero-config WireGuard 오버레이와 표준 Docker Compose로 여러 VM에 배포함
오케스트레이터나 control plane 복잡도 없이 시작은 1대에서 하고, 필요할 때 클라우드 VM과 온프렘을 섞어 확장할 수 있음
프로덕션에서 써봤을 때 매 순간 좋았고, 컴퓨팅 자체를 다시 정의한 수준처럼 보였음
그래서 이렇게까지 싫어하는 쪽의 관점을 내가 놓치고 있는 듯함
OP는 Tailscale 공동창업자 중 한 명이라 맥락상 더 흥미로움
전통적인 Cloud 1.0 회사들이 VM 기본값으로 3000 IOPS 정도를 주면서도 노트북은 50만 IOPS가 나오는 현실을 짚은 건 정확해 보임
비전은 정말 좋고 내가 딱 타깃 고객 같기도 한데, 결국 성공이 커질수록 이상보다 수익 압박이 앞서는 익숙한 경로로 갈까 봐 걱정됨
클라우드 가격은 비용 기반이 아닌 경우가 많고, 특히 고객이 깊게 묶인 뒤에만 크게 늘어나는 bandwidth나 NAT gateway 같은 항목에서 강하게 이익을 남기도록 설계되곤 함
OP도 이런 구조를 모를 리는 없다고 봄
다만 그 스토리지는 기본적으로 ephemeral이고, 중복성도 충분치 않음
RAID1으로 하드웨어 장애를 줄일 수는 있어도 붙일 수 있는 NVMe 수가 줄고, 호스트의 RAM/CPU 같은 다른 문제로 VM을 옮겨야 할 때도 깔끔한 방법이 없음
결국 이런 VM은 거의 베어메탈처럼 취급해야 하고, 데이터베이스 복제 같은 애플리케이션 레이어 중복화가 필요함
Azure는 자기들이 원할 때 VM을 옮기고 ephemeral 데이터를 날릴 수 있다고 가정해야 하지만, OpenStack에서는 필요 시 VM을 꺼두고 로컬 블록 레벨 마이그레이션으로 다른 호스트에 NVMe 데이터까지 복사할 수 있었음
그래도 호스트가 크래시하면 그 VM은 호스트가 살아날 때까지 내려가 있는 구조라 앱 레벨 이중화가 전제돼야 했음
하지만 99.9퍼센타일 지연은 Hetzner가 약 5ms, DO는 약 18ms였고 최대 지연은 Hetzner 7ms 대 DO 85ms로 차이가 꽤 큼
순차 dd에서는 Hetzner가 1.9GB/s, DO가 850MB/s였음
가격도 Hetzner는 4유로인데 DO 인스턴스는 18달러라 차이가 큼
글 다 읽기 전에 썼는데, 마침 OP도 정확히 그 둘을 집어 말하고 있었음
단순한 서버조차 머신 내부 DB를 쓰기 어렵게 만들어 lock-in을 유도하는 셈일 수 있음
물건 하나 만드는 데 X가 드니 1.y*X로 Y 가격을 정한다는 식은 실제 시장 가격 책정과 거리가 멂
bottom-up보다 top-down이 더 현실적임
AI를 둘러싼 논쟁이 극단으로 갈리는 것처럼 Kubernetes도 똑같이 양극화되어 보임
몇 년간 다양한 크기의 클러스터를 운영했지만, 장애 원인이 k8s 자체였던 적은 한 번도 없었음
한 번은 한 시간짜리 완전 정전급 장애가 있었는데, k8s를 싫어하던 쪽은 전부 그 "망할 k8s 시스템" 탓으로 돌리려 했음
실제 원인은 특정 상황에서 서비스가 순식간에 수만 개 포트를 열어 자체 DOS를 일으킨 것이었음
k8s가 미래의 전부라고 보지도 않고 쓰레기라고 보지도 않으며, 진짜 필요할 때는 좋은 시스템이라고 생각함
하나는 배울 게 너무 복잡한데 내 문제엔 필요 없고 기존 배포 방식으로 충분하다는 쪽이고, 다른 하나는 베어메탈보다 비용/에너지 효율이 낮다는 쪽임
대개 둘은 같이 감
적당히 중립적이거나 무관심한 입장이 오히려 드물어지고 있고, 미국 정치도 바로 떠오름
나도 k8s는 잘 모르고 staff engineer가 pod와 cluster 얘기하면 눈이 풀리지만, 우리 팀에는 잘 맞고 실제로 돌아감
망치만 가진 사람에겐 모든 게 못처럼 보이고, 도끼를 든 사람은 왜 다들 망치로 나무를 패려 하는지 의아해함
심지어 도끼가 맞는 일인데 망치 든 사람에게 일자리를 빼앗기는 상황이면 망치를 미워하기도 쉬워짐
k8s는 많은 사용 사례에서 best practice가 어느 정도 정리돼 있지만, LLM 쪽은 아직 무엇이 best practice인지조차 잘 모름
VM이 CPU/메모리에 묶인 형태라 일이 아니라 시간에 비용을 내게 된다는 지적에 강하게 공감함
그래서 저렴한 Hetzner 경매 서버를 하나 사서, 내가 만든 self-hostable Firecracker orchestrator 위에 올려 쓰고 있음
https://github.com/sahil-shubham/bhatti, https://bhatti.sh
원하는 건 하드웨어를 사서 VM을 마음껏 쪼개 쓰고, 프로비저닝이나 라이프사이클은 신경 쓰지 않는 것이었음
유휴 VM은 메모리 상태를 디스크에 스냅샷하고 RAM을 전부 반환하니, 하드웨어는 내 것이고 VM은 disposable하며 놀고 있을 때 비용이 거의 없음
특히 memory-state snapshot이 생기면 모든 게 재개 가능해진다는 점이 생각보다 훨씬 강력했음
로그인된 Chromium 상태를 스냅샷해두고 필요할 때 세션 복제본을 즉시 띄울 수 있고, 에이전트는 샌드박스 안에서 일하며 preview 환경용 docker compose도 거기서 돌림
아무것도 안 돌 때 서버는 사실상 idle이고, 월 100달러짜리 박스 하나가 이걸 다 처리함
자세한 내용은 https://shellbox.dev/blog/race-to-the-bottom.html에 정리해둠
문서는 충실하고 유용하지만, 상당 부분이 AI가 쓴 티가 나서 조금 더 간결했으면 좋겠음
그래도 "design decisions" 섹션은 특히 좋았고, 거기서 새로 배운 것도 있었음
아직이라면 Show HN에도 올려볼 만함
이미 쓰이지 않는 소프트웨어가 넘쳐나는데, 왜 코드를 더 많이 찍어내는 것에 집착하는지 잘 모르겠음
앱스토어만 봐도 아무도 안 쓰는 소프트웨어가 한가득임
LLM의 더 명백한 용도는 소프트웨어를 더 많이 만드는 게 아니라 더 나은 소프트웨어를 만드는 쪽이어야 한다고 봄
코드 생성 일변도에서 벗어나 다른 방향으로 초점이 옮겨가길 바라고, LLM이 더 좋은 코드를 쓰게 도와줄 수 있는 방법은 많음
정교하게 만들고 유지보수하고 업데이트하는 결정론적 시스템이라는 그림은 여전히 남겠지만, AI는 이미 사용자의 컴퓨터 상호작용 방식을 바꾸고 있음
그 결과 훨씬 더 일회용에 가까운 소프트웨어가 생겨날 것 같음
지금은 아직 "AI가 엔지니어의 소프트웨어 작성에 어떻게 도움을 줄까" 단계지만, 점점 "엔지니어가 AI가 더 잘 소프트웨어를 쓰게 하려면 무엇을 할까"로 이동하는 중이라 봄
그러면 소프트웨어가 무엇인지, 컴퓨터 상호작용을 어떻게 만들어야 하는지에 대한 관점이 완전히 다른 새로운 엔지니어 집단이 들어올 것임
앱스토어에 한 번도 올라오지 않을 맞춤형 소프트웨어가 굉장히 많아질 듯함
소프트웨어 생산 단가가 내려갔는데도 수요 증가가 절감 효과를 압도해서 총지출이 오르는 상황이어야 Jevons paradox라고 할 수 있음
이 개념은 가격 변화에 수요량이 크게 반응하는, 즉 수요 탄력성이 큰 시장에서 성립함
게임을 빼면, 수백만~수십억 명이 쓰는 단일 소프트웨어를 만드는 게 얼마나 이상한 방식이었는지 나중엔 돌아보게 될 것 같음
이제 사람들은 엇갈린 우선순위나 왜곡된 수익모델에 덜 휘둘리고, 자신이 진짜 원하는 일을 정확히 해주는 소프트웨어를 만들 수 있게 됨
그런 소프트웨어가 정의상 더 고품질이라고도 볼 수 있음
그래서 양쪽 모두 비용과 매출 예측이 쉬워졌지만, 핵심은 가능한 한 최대한 범용적인 소프트웨어를 만드는 데 있었음
그 결과 일부 사용자에게만 중요한 UX나 기능은 계속 잘려나감
Vibe coding과 LLM 가속 개발은 이걸 뒤집을 수 있음
이제 모두가 자기 필요와 선호에 맞춘 커스텀 소프트웨어를 감당할 수 있게 되고, Salesforce 고객 15만 명이 같은 CRM을 쓰는 대신 15만 개의 맞춤형 CRM을 쓰는 세상을 상상할 수 있음
소프트웨어 확장 여지는 지금 엄청나게 큼
소프트웨어 비대화 사이클를 이해하지 못하면 계속 같은 실수를 반복하게 됨
lean software에서 시작해, 사용자 요구 기능이 쌓이고, 점점 bloated mess가 되고, 다시 더 작은 리라이트가 필요해지고, 또 lean software로 돌아가는 식임
리부트는 대개 망하거나, 아니면 뭔가 핵심을 제대로 맞춰서 기존 강자를 위협할 정도로 전진함
DevOps를 이력서 채우기, 과도한 복잡성의 원흉처럼 깎아내리는 시선은 스타트업 사고방식에 더 가깝다고 느낌
작은 회사에선 DevOps 한 사람이 인프라를 다 맡기도 하겠지만, 특히 금융권에서는 실제로 방향을 쥐는 쪽이 플랫폼 엔지니어링 MD들인 경우가 많음
이들은 소프트웨어 엔지니어들을 수많은 작은 그룹으로 쪼개고, 각 팀이 자기 repo, 자기 배포, 자기 모든 것을 통제하길 바라며, microservices가 그 권한을 준다고 믿음
장담하건대 DevOps 쪽은 복잡성을 싫어함
밤과 주말에 호출되는 쪽이 바로 그들이고, 늘 "인프라 문제"라는 전제로 시작되기 때문임
배포 로그는 로그 집계 시스템에 다 들어가 있는데도, 정작 개발자가 자기 배포 문제를 직접 로그 보고 해결하는 건 드물고 곧바로 Incident가 됨
이제 마이크로서비스도 지난 유행으로 봐야 하지 않나 싶음
exe.dev는 좋게 봤고, LLM 개발 흐름을 매끄럽게 하면서도 루트 권한이 있는 Linux 머신 유연성을 제공하는 쪽엔 분명 기회가 있다고 봄
그런데 "반쯤 구현되고 반쯤 생각된 추상화에 계속 배신당했다"는 문장을 읽으니, 역설적으로 그게 바로 내가 Tailscale에서 느낀 경험이기도 함
네트워킹을 쉽게 해준다더니 배터리는 왜 이렇게 빨리 닳는지, 방화벽 규칙은 다른 도구와 충돌하게 왜 바꿔놓는지, 버그 트래커는 왜 조용한지 결국 내부 구현을 내가 이해해야 하는 상황이 됨
그래서 "No thank you"가 나오게 됨
그 서비스 자체는 정말 멋져 보임
라우터 ACL을 짜는 게 아니라 peer-to-peer 네트워크 계층을 구성하려는 건데, 그 지점이 아쉬움
나는 그냥 Hetzner를 씀
클라우드 회사들이 제공하는 건 전부 너무 비싸고, 내가 직접 돌리는 Postgres HA와 백업은 10년 동안 무중단으로 운영됐는데도 RDS나 CloudSQL 프로덕션 비용의 10분의 1 정도였음
Grafana에서 수집한 메트릭으로 인스턴스를 직접 오토스케일하고, webhook 기반 autoscaler도 아주 단순하게 잘 돌아가며 한 번도 문제를 일으키지 않았음
그래서 이제 왜 GCP나 AWS를 써야 하는지 잘 모르겠음
서비스는 전부 HA고 백업도 매일 아주 잘 됨
그때 목표는 유연성이 가장 큰 dedicated server 경험을 그대로 싸게 재현하는 것이었고, UML이 그걸 가능하게 해줬음
그런데 2010년대 내내 나는 개발자 대다수가 편의 조금 때문에 스택의 모든 조각을 계량 과금당하는 방식을 택하지는 않을 거라고 완전히 잘못 짐작했음
요즘 20대 소프트웨어 엔지니어도 eBay에서 산 서버와 라우터로 고트래픽 웹앱 플랫폼을 꾸릴 줄 아는지 궁금함
나도 작년에 그렇게 해서 50PiB+ 데이터스토어를 만들었고, 중대형 프로젝트에서 이런 방식이 얼마나 쓰이는지 진심으로 궁금함
Hetzner는 물리적 번거로움을 많이 걷어내면서도 경제적 이점을 거의 그대로 주는데, 왜 호스팅 세계의 왕이 아니라 2021년 기준 매출 3억6700만 유로 수준에 머무는지 의아함
dedicated server 다발을 다루는 지식이 그렇게까지 비전문화돼서 사람들이 이 정도 큰 절감을 외면한다고 믿기 어렵기도 함
다만 맞는 사람을 구할 수 있다면 직접 운영하는 편이 훨씬 싸질 수 있다는 건 맞음
매분 cron이 docker pull로 최신 이미지를 받고, 새 버전이 있을 때만 docker up -d로 교체함
앞단엔 HTTPS용으로 caddy를 두고, 이렇게 몇 년째 아주 싸고 안정적으로 굴러감
비슷한 철학의 영국 기반 업체처럼 보였고, 아직 써보진 않았지만 다음 VPS 후보로 계정은 만들어둠
처음부터 5배 빠른 서버를 감당할 수 있으니 굳이 오토스케일링이 필요 없을 때도 많음
대안은 이미 많고, 나는 https://shellbox.dev를 만들었음
exe와 달리 쓴 만큼만 과금하고 scale-to-zero가 되며, SSH로 즉시 VM을 띄울 수 있음
일반 Linux라서 VSCode와 Zed remote도 지원하고, nested virtualization도 가능함
투자하고 싶다면 500만 달러만 있어도 괜찮음
외부에 노출된 포트는 없고, 모든 웹 프론트엔드는 비밀번호로 보호됨
공개할 생각은 없고, TV 뒤 개인 Raspberry Pi에서 돌리는 내 격리 개발 환경임
비용도 사실상 들지 않음
서비스도 잘 되길 바람
실제 기반 인프라가 어디 있는지, 어떤 보안 보장을 받는지 등이 명확하지 않아 워크로드를 맡기기 어려움