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

• 기존 클라우드 추상화는 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 같은 과제도 남아 있음
• 동시에 데이터센터에 직접 컴퓨터를 랙킹하는 단계로 다시 돌아가, 네트워크 연결 방식까지 포함한 소프트웨어 스택 전 층을 다시 검토하고 있음
• 최종 목표는 실제로 쓰고 싶은 클라우드를 만드는 데 있음