AI 에이전트 시대 클라우드는 왜 다시 불편해졌나 2026, VM·디스크·egress·exe.dev 체크표

2026년 4월 22일 David Crawshaw는 I am building a cloud라는 글에서 exe.dev를 만들고 있는 이유를 설명했다.

핵심은 꽤 세다.

클라우드가 불편한 이유는 UI가 구려서가 아니라, 기본 추상화의 모양이 틀렸다는 것이다.

이 문장은 AI 에이전트를 매일 쓰는 사람에게 그냥 인프라 철학 이야기가 아니다.

에이전트가 코드를 더 많이 만들수록, 그 코드를 어디서 돌릴지 문제가 더 자주 튀어나오기 때문이다.

로컬에서는 잘 된다.

작은 VPS에서도 된다.

그런데 클라우드로 옮기는 순간 VM, 디스크, 네트워크, 권한, 비용, 배포 방식이 한꺼번에 따라온다.

이때 에이전트가 도와주기는 한다.

AWS 콘솔을 대신 눌러주고, Terraform을 고쳐주고, 로그를 읽어준다.

하지만 추상화 자체가 복잡하면 에이전트도 그 복잡도를 같이 먹는다.

사람이 답답한 구조는 에이전트도 답답하다.

비싼 토큰으로 인프라 삽질 설명서를 읽고 있는 셈이다.

약간 슬프다.

치킨값으로 삽을 사는 기분이다.

이 글의 한 줄 답은 이렇다.

AI 에이전트 시대에는 더 많은 자동화보다 더 단순한 실행 공간이 먼저 필요하다.

그래서 exe.dev 같은 시도는 단순한 새 클라우드 뉴스가 아니라, 에이전트가 만든 소프트웨어를 어디에 살게 할 것인가라는 질문에 가깝다.

지금 결론

기존 클라우드는 대규모 팀과 표준화된 운영에는 강하다.

하지만 개인 개발자, 소규모 팀, AI 에이전트로 빠르게 만드는 작은 프로그램에는 자주 과하다.

문제는 기능이 부족해서가 아니다.

기능은 오히려 너무 많다.

문제는 작은 프로그램 하나를 돌리기 위해 알아야 하는 것이 너무 많다는 점이다.

VM 크기를 고른다.

디스크 타입을 고른다.

IOPS를 계산한다.

로드밸런서를 붙인다.

인증을 붙인다.

네트워크 비용을 본다.

로그와 모니터링을 붙인다.

안 쓰는 리소스가 남았는지 본다.

이 모든 과정은 사람에게도 피곤하지만, 에이전트에게도 피곤하다.

에이전트가 클라우드 API를 잘 다룰수록 생산성이 오른다는 말은 절반만 맞다.

나머지 절반은 클라우드 API가 굳이 어려운 일을 에이전트에게 떠넘기고 있다는 이야기다.

그래서 이 글에서는 세 가지를 본다.

첫째, 왜 VM 추상화가 작은 개발자에게 어색한가.

둘째, 왜 SSD 시대에도 원격 블록 스토리지와 egress 비용이 병목이 되는가.

셋째, exe.dev가 제안하는 CPU와 메모리를 먼저 사고, 그 위에 VM을 마음대로 띄우는 모델이 어떤 의미인지 본다.

이 글을 써먹을 상황

Claude Code, Codex, Cursor, Gemini CLI 같은 코딩 에이전트로 작은 앱을 자주 만든다.
배포보다 개발은 빨라졌는데, 운영 환경을 잡는 데 시간이 계속 샌다.
Vercel, Railway, Fly.io, Render, AWS, GCP, Hetzner 사이에서 매번 고민한다.
Docker Compose 하나면 될 일을 Kubernetes로 키우고 있는지 의심된다.
월 20달러짜리 프로젝트가 NAT, egress, managed DB 때문에 갑자기 비싸진 적이 있다.
AI가 만든 내부 도구를 안전하게 격리해서 돌릴 공간이 필요하다.
에이전트에게 프로덕션 자격 증명을 맡기는 게 찜찜하다.
로컬 개발 환경은 편한데, 클라우드로 옮기면 설정 파일이 늘어난다.
클라우드 비용을 줄이고 싶지만 베어메탈 운영까지 가기는 부담스럽다.
Kubernetes가 나쁜가, 내가 못 쓰는 건가 사이에서 흔들린다.

이 글은 AWS를 쓰지 말자는 글이 아니다.

GCP나 Azure가 나쁘다는 글도 아니다.

대형 클라우드는 여전히 필요하다.

규모가 크고, 컴플라이언스가 중요하고, 조직 표준이 잡혀 있고, 운영팀이 따로 있으면 강력하다.

다만 모든 프로그램이 그 정도의 무게를 필요로 하지는 않는다.

AI 에이전트가 작은 프로그램을 더 많이 만들수록, 더 가벼운 실행 공간의 수요는 커진다.

이 지점에서 exe.dev의 문제 제기가 재미있어진다.

왜 기존 클라우드가 다시 불편해졌나

David Crawshaw의 글은 개인적인 고백처럼 시작하지만, 내용은 꽤 구체적이다.

그는 컴퓨터를 좋아한다고 말한다.

서버도 좋아하고, Linux VM도 좋아하고, API로 움직이는 VM이라면 더 좋아해야 정상이라고 말한다.

그런데 오늘날의 클라우드는 좋아하기 어렵다고 한다.

이 불편함은 콘솔 UI나 문서 품질만의 문제가 아니다.

글에서 반복되는 표현은 wrong shape다.

기본 구성 단위의 모양이 맞지 않는다는 뜻이다.

대표적인 예가 VM이다.

현재 클라우드는 보통 VM을 CPU와 메모리가 묶인 인스턴스로 판다.

사용자는 2 vCPU 4GB, 4 vCPU 16GB 같은 패키지를 고른다.

그 위에 무엇을 얼마나 띄울지는 클라우드가 정한 인스턴스 경계 안에서 움직인다.

하지만 개발자가 원하는 모델은 종종 다르다.

CPU와 메모리와 디스크를 먼저 확보하고, 그 안에서 VM을 여러 개 쪼개 쓰고 싶다.

작은 실험 VM을 여러 개 띄웠다가 지우고 싶다.

한 VM은 idle 상태로 두고, 다른 VM만 잠깐 세게 돌리고 싶다.

로컬 컴퓨터에서 프로세스를 여럿 띄우듯이, 클라우드에서도 실행 공간을 더 자연스럽게 나누고 싶다.

기존 클라우드에서는 이걸 하려면 nested virtualization, gVisor, reverse proxy, 네트워크 설정을 직접 떠안게 된다.

즉 컴퓨터를 쓰고 싶은데, 컴퓨터를 다시 만드는 일부터 시작한다.

이게 개발자를 지치게 만든다.

AI 에이전트도 여기서 같이 지친다.

VM 추상화가 에이전트에게도 문제인 이유

에이전트가 코드를 만들 때 제일 편한 환경은 익숙한 컴퓨터다.

파일시스템이 있고, 셸이 있고, 포트가 열리고, 로그를 볼 수 있고, 프로세스를 죽였다 다시 띄울 수 있는 환경이다.

이 환경은 대단한 게 아니다.

그냥 개발자가 매일 쓰는 Linux 머신에 가깝다.

그런데 현대 PaaS는 이 익숙함을 종종 숨긴다.

빌드팩을 배워야 한다.

서버리스 함수의 제한을 알아야 한다.

파일시스템이 영속적인지 확인해야 한다.

백그라운드 작업이 살아남는지 봐야 한다.

포트와 인증, 배포 단계를 공급자 방식으로 다시 배운다.

사람이 직접 하면 귀찮은 정도다.

에이전트가 하면 더 미묘하다.

에이전트는 문서를 읽고 맞춰줄 수 있다.

하지만 그 과정에서 컨텍스트를 쓴다.

클라우드별 예외를 읽는다.

실패 로그를 해석한다.

다시 명령을 바꾼다.

결국 본래 만들려던 제품보다, 배포 환경을 맞추는 데 더 많은 추론을 쓴다.

이게 Crawshaw가 말한 핵심 중 하나다.

에이전트가 고전적 클라우드 추상화에 맞추느라 컨텍스트를 쓰면, 실제 문제 해결에 쓸 컨텍스트가 줄어든다.

AI 시대의 클라우드는 에이전트에게 더 많은 API를 주는 방향만으로는 부족하다.

에이전트가 덜 생각해도 되는 환경이어야 한다.

사람에게 단순한 환경이 에이전트에게도 단순하다.

이건 생각보다 중요한 기준이다.

디스크 문제: HDD 시대의 전제가 SSD 시대에 남아 있다

글에서 가장 선명한 숫자는 디스크 이야기에서 나온다.

원격 블록 스토리지는 HDD 시대에는 합리적이었다.

HDD의 랜덤 seek는 10ms 수준이었다.

그 상황에서는 1ms 정도의 네트워크 RTT가 큰 문제로 보이지 않았다.

순차 읽기와 쓰기에서는 버퍼링을 잘하면 손해도 줄일 수 있었다.

클라우드 사업자 입장에서도 장점이 있었다.

인스턴스 타입에서 디스크라는 축을 분리할 수 있다.

컴퓨트와 스토리지를 독립적으로 운영할 수 있다.

문제는 SSD 이후다.

SSD의 seek time은 글에서 20마이크로초 수준으로 언급된다.

이러면 네트워크를 한 번 타는 비용이 훨씬 크게 보인다.

HDD 시대에는 10% 정도로 보이던 오버헤드가 SSD 시대에는 10배 이상으로 커질 수 있다는 주장이다.

글은 EC2에서 200k IOPS 구성을 하려면 복잡하고 월 1만 달러 수준의 비용이 든다고 비교한다.

반면 MacBook은 500k IOPS를 낸다고 말한다.

이 비교가 완전히 apples-to-apples는 아니다.

노트북과 클라우드 스토리지는 내구성, 복제, 장애 대응 모델이 다르다.

그래도 메시지는 강하다.

개발자가 체감하는 로컬 디스크의 기본 성능과, 클라우드에서 합리적 가격으로 얻는 디스크 성능 사이의 간극이 너무 크다는 것이다.

AI 에이전트가 만든 작은 앱도 결국 상태를 저장한다.

SQLite를 쓰든, Postgres를 쓰든, 파일을 저장하든, 캐시를 쓰든 디스크는 필요하다.

이때 디스크가 느리거나 비싸면 구조가 바뀐다.

로컬 파일 하나면 될 일을 managed DB로 보낸다.

간단한 단일 머신 앱이 분산 시스템이 된다.

분산 시스템이 되면 운영은 바로 진지해진다.

진지함이 늘면 재미가 줄어든다.

개발자 건강에 좋지 않다.

egress 비용은 작은 프로젝트의 숨은 벽이다

네트워크도 비슷하다.

대형 클라우드의 네트워크 품질은 좋다.

문제는 가격과 사업 구조다.

Crawshaw는 표준 클라우드 egress 비용이 일반 데이터센터에서 서버를 랙킹할 때보다 GB당 10배 수준이라고 말한다.

대형 고객은 협상으로 가격을 낮출 수 있다.

월 수천만 달러를 쓰는 고객은 다른 세계의 가격표를 받는다.

하지만 월 수십 달러나 수백 달러 규모의 개인 프로젝트는 그렇지 않다.

여기서 문제가 생긴다.

작은 프로젝트는 클라우드의 고정비와 과금 항목을 견디기 어렵다.

처음에는 무료 티어로 시작한다.

그다음에는 스토리지 비용이 붙는다.

그다음에는 egress가 붙는다.

그다음에는 managed DB와 로그, NAT gateway, 백업, 모니터링이 붙는다.

어느 순간 앱보다 청구서가 더 성숙해진다.

아주 건방진 청구서다.

AI 에이전트 시대에는 이런 작은 프로젝트가 더 많아진다.

내부 도구, 개인 자동화, 고객별 맞춤 앱, 일회성 분석 서버, 임시 데모가 계속 생긴다.

각각은 작지만 전체 수는 늘어난다.

이런 앱이 모두 hyperscaler의 복잡한 과금 구조 위에 올라가면, 개발 속도는 빨라졌는데 운영 비용은 더 이해하기 어려워질 수 있다.

그래서 egress는 단순 비용 항목이 아니다.

작은 소프트웨어가 얼마나 마음 편하게 배포될 수 있는지를 가르는 장벽이다.

Kubernetes는 문제인가, 증상인가

이 글에서 Kubernetes를 읽는 방식은 중요하다.

그냥 Kubernetes 싫다가 아니다.

Crawshaw는 Kubernetes를 클라우드 API의 고통을 덮어주는 시도로 본다.

즉 Kubernetes는 원인이라기보다 증상에 가깝다.

클라우드별 API가 다르고, VM과 디스크와 네트워크 추상화가 까다로우니, 그 위에 이식 가능한 공통 층을 올린 것이다.

문제는 그 공통 층이 근본 추상화를 바꾸지는 못한다는 점이다.

VM은 여전히 어렵다.

디스크는 여전히 느린 원격 블록 장치에 묶이기 쉽다.

네트워크는 여전히 비용과 사설 연결, 벤더 경계에 갇힌다.

Kubernetes는 대형 조직에는 훌륭한 운영 언어가 될 수 있다.

배포 표준이 필요하고, 여러 팀이 같은 control plane을 쓰고, 서비스 디스커버리와 롤아웃과 스케줄링을 통일해야 한다면 값이 있다.

하지만 작은 앱 하나를 돌리는 사람에게는 너무 많은 단어를 요구한다.

Pod, Deployment, Service, Ingress, ConfigMap, Secret, PVC, StorageClass를 알아야 한다.

앱은 hello인데 인프라는 면접관처럼 군다.

이때 문제는 Kubernetes가 나빠서가 아니다.

작은 문제에 너무 큰 운영 문법이 붙는다는 점이다.

AI 에이전트가 도와줘도 이 무게는 사라지지 않는다.

오히려 에이전트가 YAML을 더 빨리 만들면서 복잡도가 더 빨리 늘 수 있다.

그래서 질문은 Kubernetes를 쓸까 말까보다 먼저 와야 한다.

내 앱은 정말 클러스터가 필요한가.

아니면 좋은 단일 머신과 단순한 배포, 명확한 백업이면 충분한가.

이 질문을 먼저 해야 한다.

에이전트 시대에는 소프트웨어 총량이 늘어난다

exe.dev 글에서 가장 중요한 시대 인식은 agents다.

코드 작성 비용이 내려가면 소프트웨어 수요는 줄지 않고 늘어난다.

여기서 Jevons paradox를 언급한다.

효율이 좋아지면 소비가 줄 것 같지만, 오히려 사용량이 늘어나는 현상이다.

AI 코딩 에이전트도 비슷하다.

앱 하나 만드는 시간이 줄면, 우리는 앱을 덜 만들까.

아마 아니다.

더 많이 만든다.

팀 내부 도구를 만든다.

개인 자동화를 만든다.

블로그 운영 스크립트를 만든다.

데이터 수집기를 만든다.

고객별 작은 대시보드를 만든다.

하루 쓰고 버릴 분석 앱도 만든다.

문제는 소프트웨어를 만드는 비용만 내려가면 안 된다는 점이다.

실행하는 비용도 내려가야 한다.

공유하는 비용도 내려가야 한다.

격리하는 비용도 내려가야 한다.

끄고 다시 켜는 비용도 내려가야 한다.

에이전트 시대에는 코드 생성보다 코드가 살 집이 더 자주 병목이 된다.

이게 exe.dev가 재미있는 이유다.

AI를 위한 완전히 새로운 마법 상자를 만들자는 방향이 아니다.

오히려 개발자가 이미 아는 컴퓨터에 가깝게 돌아가자는 방향이다.

SSH, Linux, VM, 로컬 디스크, 프록시, 인증, 가까운 리전.

에이전트가 잘 쓰는 것도 결국 이런 익숙한 환경이라는 판단이다.

그 판단은 꽤 설득력 있다.

exe.dev가 제안하는 모델

exe.dev는 개별 VM을 하나씩 사는 모델을 다르게 본다.

공개 글 기준으로 핵심은 CPU와 메모리를 먼저 받고, 그 위에 원하는 VM을 실행한다는 구조다.

사용자는 VM 하나의 크기를 계속 고르는 대신, 자신에게 주어진 자원 안에서 여러 VM을 나눠 쓸 수 있다.

또한 새 VM을 인터넷에 바로 노출하지 않도록 TLS proxy와 authentication proxy를 처리한다.

디스크는 로컬 NVMe를 쓰고, 블록은 머신 밖으로 비동기 복제한다고 설명한다.

여러 지역에 머신을 둘 수 있고, anycast 네트워크 뒤에서 낮은 지연 진입점을 제공하려 한다.

2025년 12월 Meet exe.dev, modern VMs 글에서는 SSH 기반 API, private by default, share links, agent-friendly sandbox 같은 방향도 설명했다.

2026년 4월 22일 Series A 발표에서는 총 3,500만 달러 펀딩을 언급하며, 개발자를 위한 새 클라우드 인프라를 만들겠다고 했다.

이걸 아주 단순하게 번역하면 이렇다.

개발자와 에이전트가 익숙한 컴퓨터를 바로 쓰게 하자.

작은 VM을 많이 만들 수 있게 하자.

인증과 TLS와 공유는 기본으로 처리하자.

디스크는 로컬처럼 빠르게 쓰되, 복제는 플랫폼이 챙기자.

여기서 중요한 건 아직 모든 문제가 해결됐다는 뜻이 아니라는 점이다.

정적 IP, 과거 디스크 스냅샷 접근 UX, 실제 가격, 장애 복구 모델, 대규모 워크로드에서의 성능은 계속 봐야 한다.

초기 클라우드 서비스는 늘 아름다운 철학과 못생긴 엣지 케이스를 같이 가진다.

그래도 방향은 분명하다.

AI 에이전트에게 더 많은 추상화를 주는 대신, 더 컴퓨터다운 실행 공간을 주자는 것이다.

비교표로 보면 더 선명하다

기준	전통적 대형 클라우드	PaaS·서버리스	Kubernetes	exe.dev식 modern VM 방향
기본 단위	인스턴스, managed service	앱, 함수, 빌드팩	클러스터 리소스	자원 풀 위의 VM
개발자 체감	강력하지만 복잡함	시작은 쉽지만 제약 존재	표준화되지만 무거움	익숙한 Linux 머신에 가까움
에이전트 친화성	API는 많지만 문맥 부담 큼	공급자별 예외가 많음	YAML과 운영 문법 필요	SSH와 파일시스템 중심
디스크	원격 블록 중심	플랫폼 제약 큼	PVC와 StorageClass 필요	로컬 NVMe + 비동기 복제 지향
네트워크	강력하지만 egress 비용 부담	단순하지만 제약 존재	유연하지만 운영 난도 큼	TLS/auth proxy 기본 제공 지향
적합한 규모	기업, 대형 서비스	표준 웹앱, 빠른 MVP	다팀 운영, 복잡한 서비스	개인, 소규모 팀, 에이전트 sandbox
리스크	비용과 설정 복잡도	lock-in과 숨은 제한	과한 운영 무게	초기 서비스 안정성과 생태계 부족

이 표에서 exe.dev가 무조건 이긴다는 결론을 내리면 안 된다.

그건 너무 빠르다.

대형 클라우드는 이미 검증된 장애 대응, 리전, IAM, 컴플라이언스, 데이터 서비스가 있다.

PaaS는 여전히 빠른 배포에 강하다.

Kubernetes는 팀 표준화와 대규모 운영에서 값이 있다.

exe.dev식 접근은 다른 빈칸을 노린다.

작은 프로그램을 많이 만들고, 에이전트가 자주 들어오고, 실행 환경은 일반 컴퓨터처럼 이해하고 싶은 구간이다.

이 구간은 2026년에 꽤 커질 수 있다.

실전 판단 체크표

작은 앱을 어디에 올릴지 고를 때는 아래 순서로 보면 덜 꼬인다.

질문	예	추천 방향
상태 저장이 필요한가	SQLite, 파일 업로드, 캐시	persistent VM 또는 managed DB 검토
트래픽이 예측 가능한가	내부 도구, 작은 SaaS	단일 VM + 백업부터 검토
전 세계 지연 시간이 중요한가	글로벌 사용자 앱	CDN, anycast, 리전 전략 필요
팀 표준이 이미 Kubernetes인가	회사 플랫폼팀 존재	기존 표준을 따르는 편이 안전
AI 에이전트가 직접 작업하나	코드 수정, 서버 접속, 로그 확인	sandbox VM 분리 필요
비용 상한이 낮은가	월 20~100달러	egress와 managed service 비용 먼저 확인
규제·감사가 중요한가	금융, 의료, 개인정보	대형 클라우드와 감사 로그 우선
하루 쓰고 버릴 앱인가	실험, 데모, 분석	빠른 VM clone 또는 ephemeral 환경 검토

내 기준은 이렇다.

고객 데이터와 돈이 걸린 서비스는 검증된 클라우드와 managed service를 먼저 본다.

내부 도구와 개인 자동화는 단일 VM 또는 가벼운 PaaS부터 본다.

AI 에이전트가 코드를 만지는 실험은 프로덕션과 분리된 VM을 먼저 만든다.

복잡한 배포 플랫폼은 필요해질 때까지 미룬다.

미루는 것도 기술이다.

괜히 빨리 성숙해지면 운영비도 같이 어른이 된다.

통장은 아직 청소년인데 청구서만 장성하면 곤란하다.

TECHTAEK식 운영 메모

이 글을 내 작업 흐름에 붙인다면, 바로 제품을 갈아타는 글로 쓰지는 않겠다.

먼저 테스트 시나리오를 만든다.

1번은 AI 에이전트용 sandbox VM이다.

Claude Code나 Codex가 들어가서 코드를 고치고 테스트할 수 있는 격리 공간을 만든다.

프로덕션 자격 증명은 넣지 않는다.

2번은 작은 내부 웹앱이다.

SQLite 또는 Postgres 한 개, Docker Compose, Caddy 정도로 끝나는 앱을 올린다.

배포 시간, 장애 복구, 로그 확인, 백업 복원 시간을 재본다.

3번은 비용 비교다.

같은 앱을 기존 VPS, PaaS, 대형 클라우드, exe.dev식 VM에 올렸을 때 월 고정비와 egress 비용을 비교한다.

4번은 에이전트 조작성이다.

에이전트에게 “로그 보고 원인 찾아서 수정해줘”를 시킨다.

어느 환경에서 문맥 설명이 가장 적게 필요한지 본다.

5번은 실패 복구다.

VM을 망가뜨렸을 때 이전 상태로 얼마나 빨리 돌아오는지 본다.

AI 에이전트 시대의 인프라는 잘 돌아갈 때보다 에이전트가 망쳤을 때가 더 중요하다.

이게 진짜 운영 포인트다.

흔한 실수

첫 번째 실수는 새 클라우드가 나왔다고 바로 프로덕션을 옮기는 것이다.

초기 서비스는 철학보다 운영 디테일에서 판단해야 한다.

가격표, 백업, 장애 공지, 보안 모델, 지원 속도를 봐야 한다.

두 번째 실수는 Kubernetes를 악역으로 만드는 것이다.

Kubernetes는 많은 조직에서 실제로 문제를 푼다.

다만 모든 앱에 필요한 것은 아니다.

도구를 싫어하기보다 적용 범위를 줄이는 게 더 실용적이다.

세 번째 실수는 egress를 나중에 보는 것이다.

작은 서비스도 파일, 이미지, 로그, 백업이 붙으면 네트워크 비용이 올라간다.

무료처럼 보이는 구조가 어느 순간 비싸질 수 있다.

네 번째 실수는 에이전트에게 클라우드 권한을 통째로 주는 것이다.

에이전트는 도움을 주지만 실수도 한다.

프로덕션 DB 삭제 권한을 가진 에이전트는 생산성 도구가 아니라 긴장감 유발 장치다.

그 장치는 카페인보다 세다.

다섯 번째 실수는 로컬 디스크와 클라우드 디스크를 같은 감각으로 보는 것이다.

성능, 내구성, 복제, 백업, 지연 시간은 모두 다르다.

SQLite가 로컬에서는 천재처럼 보여도 원격 파일시스템 위에서는 갑자기 표정이 안 좋아질 수 있다.

FAQ

AWS, GCP, Azure를 이제 안 써도 된다는 뜻인가?

아니다.

대형 클라우드는 여전히 강력하다.

특히 조직 표준, IAM, 감사, 보안 인증, 데이터 서비스, 글로벌 인프라가 필요하면 대형 클라우드를 쓰는 편이 안전하다.

이 글의 포인트는 모든 앱이 그 무게를 필요로 하지는 않는다는 것이다.

작은 앱과 에이전트 sandbox에는 더 단순한 선택지가 필요하다.

exe.dev를 지금 바로 써야 하나?

바로 프로덕션 이전부터 할 필요는 없다.

먼저 실험용으로 보는 게 맞다.

AI 에이전트가 들어가서 코드를 수정하는 격리 VM, 내부 도구, 작은 데모 앱부터 테스트하는 편이 좋다.

가격, 장애 대응, 백업 복원, 지원 속도는 실제로 확인해야 한다.

Kubernetes는 결국 버려질까?

그렇게 보기는 어렵다.

Kubernetes는 대형 조직의 공통 운영 언어로 이미 깊게 들어가 있다.

다만 작은 앱과 개인 자동화에는 과한 경우가 많다.

앞으로는 모든 것을 Kubernetes로보다 필요한 곳만 Kubernetes로가 더 자연스러워질 가능성이 크다.

AI 에이전트가 있으면 인프라 복잡도는 자동으로 해결되지 않나?

일부는 해결된다.

에이전트는 문서를 읽고 명령을 실행하고 로그를 분석할 수 있다.

하지만 복잡한 추상화 자체가 사라지는 것은 아니다.

오히려 에이전트가 복잡도를 빠르게 생성할 수도 있다.

그래서 단순한 실행 환경과 제한된 권한이 더 중요해진다.

단일 VM으로 충분한 서비스는 어떤 서비스인가?

초기 SaaS, 내부 관리자 도구, 개인 자동화, 작은 대시보드, 읽기 중심 API, 트래픽이 예측 가능한 서비스는 단일 VM으로 충분한 경우가 많다.

물론 백업과 모니터링은 필요하다.

하지만 처음부터 클러스터와 마이크로서비스로 갈 이유는 없다.

대부분의 작은 서비스는 먼저 단순하게 살아남는 것이 중요하다.

AI 에이전트용 sandbox는 왜 따로 필요할까?

에이전트는 빠르게 파일을 바꾸고 명령을 실행한다.

이 능력은 좋지만, 프로덕션 권한과 섞이면 위험하다.

격리된 VM을 주면 에이전트가 마음껏 시도해도 피해 범위를 줄일 수 있다.

실패를 안전하게 만들면 자동화의 속도를 더 과감하게 쓸 수 있다.

출처

마무리 판단

이 글의 핵심은 exe.dev가 당장 AWS를 이긴다는 이야기가 아니다.

그건 너무 성급하다.

진짜 핵심은 AI 에이전트가 소프트웨어 생산량을 늘릴수록, 실행 환경의 단순함이 더 중요해진다는 점이다.

우리는 지금 코드를 더 빨리 쓰는 방법을 많이 이야기한다.

하지만 곧 더 자주 물어야 할 질문은 이쪽일 수 있다.

그 코드는 어디서 안전하게 돌릴 것인가.

누가 접근할 수 있는가.

디스크는 얼마나 빠르고, 백업은 어떻게 되는가.

네트워크 비용은 어디서 튀는가.

에이전트가 망쳤을 때 어떻게 되돌릴 것인가.

클라우드는 더 화려해질 수도 있다.

하지만 에이전트 시대에 더 필요한 것은 어쩌면 반대다.

덜 화려하고, 더 컴퓨터다운 실행 공간.

개발자와 에이전트가 같이 이해할 수 있는 공간.

그 방향에서 exe.dev는 꽤 볼 만한 신호다.

아직 답은 아니다.

하지만 질문은 좋다.

좋은 질문은 종종 좋은 인프라보다 먼저 온다.