나는 클라우드를 만들고 있어요

• 기존 클라우드 추상화는 CPU·메모리·디스크를 원하는 방식으로 조합해 쓰기 어렵게 만들고, VM과 PaaS 모두 일반 컴퓨터보다 더 많은 제약을 만듦
• 원격 블록 스토리지와 높은 egress 비용은 HDD 시절 전제에 묶인 구조를 유지한 채 SSD와 현대 네트워크 환경에서 성능과 비용 문제를 더 크게 키움
• Kubernetes는 다루기 어려운 클라우드 API 위를 덮어 주지만, 잘못된 기본 추상화 자체를 바꾸지 못해 VM·디스크·네트워크의 한계를 그대로 안고 감
• agents로 소프트웨어와 실행 수요가 늘어날수록 사적인 실행 공간, 쉬운 공유, 낮은 운영 오버헤드가 더 중요해지고, 기존 클라우드의 구조적 병목도 함께 더 커짐
• exe.dev는 CPU와 메모리를 먼저 확보한 뒤 그 위에서 VM을 직접 실행하게 하고, TLS proxy·인증 proxy·로컬 NVMe·비동기 복제·anycast 기반 배치를 결합해 실제로 쓰고 싶은 클라우드에 가까워지려 함

---

왜 새 클라우드를 다시 만드는가

• 기존 클라우드 추상화가 컴퓨터를 원하는 방식으로 쓰기 어렵게 만들고 있어, 새 회사를 시작한 직접적인 이유가 됨
• 컴퓨터 자체는 좋지만 오늘날의 클라우드는 거의 모든 제품에서 제약이 반복되고, 문제의 핵심도 단순한 UX나 API 설계 실수보다 기본 구성 단위의 형태에 더 가까움
• VM은 CPU와 메모리에 묶인 개별 인스턴스로 제공되는데, 원하는 형태는 CPU·메모리·디스크 자원을 먼저 확보한 뒤 그 위에 필요한 수만큼 VM을 올리는 구조에 가까움
  • Linux VM은 다른 Linux의 cgroup 안에서 도는 프로세스인데도, 현재 클라우드에서는 이를 쉽게 다루기 어려움
  • 이를 우회하려면 gVisor나 중첩 가상화를 단일 클라우드 VM 위에 올려야 하고, 성능 손해와 함께 최소한 reverse proxy 운영까지 직접 떠안게 됨
• PaaS도 이 문제를 해결하지 못하고, 오히려 일반 컴퓨터보다 덜 강력한 공급자 종속 추상화를 강요함
  • 컴퓨트 공급자마다 새로운 개발 방식을 배워야 함
  • 프로젝트를 어느 정도 진행한 뒤에야, 일반 컴퓨터에서는 쉬운 작업이 플랫폼 깊숙한 제한 때문에 거의 불가능하다는 점이 드러나기도 함
  • 여러 번 “이번엔 된다” 싶다가도 반쯤 구현된 추상화에 막히는 일이 반복됨

디스크와 네트워크에서 드러나는 구조적 한계

• 디스크에서는 클라우드 사업자가 원격 블록 스토리지나 그보다 더 제한적이고 느린 S3 같은 방식을 선호하는데, 이는 HDD 시절에는 어느 정도 합리적이었음
  • 원격 스토리지는 순차 읽기·쓰기에서 큰 손해가 없고, HDD의 랜덤 seek가 10ms 수준이어서 이더넷 연결의 1ms RTT는 감수할 만한 비용이었음
  • 공급자 입장에서는 표준 인스턴스 유형에서 한 축을 제거할 수 있어 운영이 쉬워짐
• 하지만 SSD로 전환되며 이 가정이 깨짐
  • seek 시간은 10ms에서 20마이크로초로 줄어듦
  • 원격 블록 시스템의 네트워크 RTT는 개선됐지만, IOPS 오버헤드는 HDD 시절 10% 수준에서 SSD 시대에는 10배 이상으로 커짐
  • EC2에서 200k IOPS 구성을 하려면 설정도 복잡하고 월 1만 달러를 내야 하는데, MacBook은 500k IOPS를 제공함
• 네트워크 기술 자체는 충분히 좋지만, egress 비용과 사업 구조가 사용성을 막는 방향으로 작동함
  • hyperscaler 네트워크는 뛰어나지만 비용이 매우 높고 다른 벤더와의 연동도 불편하게 만듦
  • 클라우드 사업자의 egress 단가는 일반 데이터센터에 서버를 랙킹할 때보다 GB당 10배 수준으로 제시됨
  • 사용량이 어느 정도만 올라가도 이 배수는 더 나빠짐
  • 월 수천만 달러를 쓰는 고객은 더 좋은 가격을 받을 수 있지만, 월 수십 달러나 수백 달러 규모 프로젝트에는 맞지 않음
  • 이 구간에서는 무엇을 만들더라도 저렴하게 운영하기 어렵게 막힘

Kubernetes와 API가 문제를 덮지만 해결하지는 못함

• 클라우드 API는 다루기 고통스럽고, Kubernetes는 그 위를 덮어 엔지니어가 받는 고통을 줄이는 방향에서 등장함
• 그러나 VM은 클라우드가 중첩 가상화를 직접 떠넘기는 구조라 Kubernetes 위에서도 여전히 다루기 어려움
• 디스크도 Kubernetes 설계 당시 Google 쪽에서 쓸 만한 원격 블록 장치가 사실상 없었고, 오늘날 공통 패턴을 겨우 맞춰도 결국 느린 저장소에 묶이기 쉬움
• 네트워크 역시 쉽게 열어주면 인접한 오픈 데이터센터의 일부 시스템을 private link로 붙여 클라우드 비용의 0 하나를 지울 수 있게 되므로, 쉽게 만들 유인이 적음
• Kubernetes를 단순한 가짜 일거리로 치부하기보다, 이식 가능하고 usable한 클라우드를 만들려는 불가능한 문제에 맞선 산물로 봄
• 근본적으로 잘못된 클라우드 추상화 위에 새로운 추상화를 올리는 방식으로는 해결할 수 없고, Kubernetes를 좋게 만드는 일도 결국 한계가 뚜렷함
• 이런 불편한 클라우드와 함께 지낸 시간이 15년에 이르렀고, 그동안은 불쾌한 소프트웨어 스택의 다른 부분처럼 참고 최소한만 접촉하는 방식으로 버텨 옴

지금이 고쳐야 할 시점

• 지금이 전환점인 이유는 agents가 등장했기 때문임
• Jevons paradox처럼 코드 작성이 쉬워질수록 전체 소프트웨어 양은 더 늘어나고, 일과 취미 양쪽에서 각자가 더 많은 프로그램을 쓰게 됨
• 그렇게 늘어나는 프로그램을 돌리려면 사적인 실행 공간, 쉬운 공유, 작은 운영 오버헤드가 필요함
• 소프트웨어 총량이 늘수록, 예전에는 성가신 수준이던 클라우드 문제가 훨씬 더 큰 병목으로 커짐
  • 더 많은 컴퓨트가 필요하고 관리도 더 쉬워져야 함
  • agents는 AWS API를 대신 조작하는 데는 도움이 되지만, 자격 증명을 맡겨야 하고 때로는 프로덕션 DB를 삭제할 수도 있음
  • 무엇보다 agents도 기존 클라우드 추상화의 근본적 한계에서는 사람과 같은 벽에 부딪힘
  • 필요 이상으로 많은 토큰을 쓰게 되고 결과도 기대보다 나빠짐
  • agent의 context window가 고전적 클라우드를 억지로 맞추는 데 쓰일수록, 실제 문제 해결에 쓸 여지가 줄어듦

exe.dev가 먼저 고치기 시작한 부분

• exe.dev에서 먼저 출시한 것은 VM 자원 격리 문제에 대한 해법임
• 개별 VM을 프로비저닝하는 대신 CPU와 메모리를 먼저 받고, 그 위에서 원하는 VM을 직접 실행하는 구조를 제공함
• 새 VM을 인터넷에 그대로 노출하고 싶지 않다는 전제 아래, TLS proxy와 인증 proxy를 함께 처리함
• 디스크는 로컬 NVMe를 쓰고, 블록은 머신 밖으로 비동기 복제함
• 전 세계 여러 지역에 머신을 둘 수 있게 해 가까운 위치에서 실행되도록 함
• 머신은 anycast 네트워크 뒤에 배치되어 전 세계 사용자에게 낮은 지연의 진입점을 제공함
  • 이 기반 위에서 곧 새로운 기능도 더 만들 수 있게 설계함
• 아직 만들 것이 많이 남아 있음
  • 정적 IP 같은 비교적 분명한 항목이 남아 있음
  • 자동으로 생성되는 과거 디스크 스냅샷에 접근하는 UX 같은 과제도 남아 있음
• 동시에 데이터센터에 직접 컴퓨터를 랙킹하는 단계로 다시 돌아가, 네트워크 연결 방식까지 포함한 소프트웨어 스택 전 층을 다시 검토하고 있음
• 최종 목표는 실제로 쓰고 싶은 클라우드를 만드는 데 있음

[unsure4000]

탈퇴 기능이 안보이는데 찾으신분 있나요?

[xguru]

이제 와서 왜? 싶다가..
작성자가 Tailscale 공동창업자인것 보고 왠지 응원하고 싶어짐
잘 만들어주세요!

[carnoxen]

드래그 앤 드롭 만으로 서비스끼리 연결할 수 있으면 좋겠네요

[GN⁺]

Hacker News 의견들

• 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달러짜리 박스 하나가 이걸 다 처리함

  • Hetzner 경매 인스턴스 위 VM이라는 접근은 shellbox도 동일함
    자세한 내용은 https://shellbox.dev/blog/race-to-the-bottom.html에 정리해둠
  • 처음 보기엔 꽤 흥미로움
    문서는 충실하고 유용하지만, 상당 부분이 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를 두고, 이렇게 몇 년째 아주 싸고 안정적으로 굴러감
  • 나도 Hetzner를 쓰지만, 어제 https://www.mythic-beasts.com/도 봤음
    비슷한 철학의 영국 기반 업체처럼 보였고, 아직 써보진 않았지만 다음 VPS 후보로 계정은 만들어둠
  • 요즘은 베어메탈 서버에 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에서 돌리는 내 격리 개발 환경임
    비용도 사실상 들지 않음
    서비스도 잘 되길 바람
  • 서비스는 깔끔해 보이지만, 웹사이트 정보만으로는 신뢰하기엔 부족함
    실제 기반 인프라가 어디 있는지, 어떤 보안 보장을 받는지 등이 명확하지 않아 워크로드를 맡기기 어려움