Huny's Dev Blog
huny.dev
"그냥 컴퓨터"가 필요할 때: exe.dev가 제안하는 인프라의 미래

"그냥 컴퓨터"가 필요할 때: exe.dev가 제안하는 인프라의 미래

복잡한 클라우드 설정과 인프라 관리에서 벗어나고 싶다면, exe.dev는 하나의 해답이 된다. 이 글에서는 SSH만으로 인프라를 제어하는 새로운 접근 방식과 API 키 없는 LLM 게이트웨이, 그리고 서버리스 대신 ‘그냥 컴퓨터’로 돌아가는 Serverful 철학까지, exe.dev가 제안하는 단순한 인프라의 미래를 정리했다. 개발자가 다시 비즈니스 로직에 집중할 수 있도록 만드는 인프라, 그 본질을 살펴본다.

Hun Jang
Hun Jang Apr 13, 2026

개요

현대 소프트웨어 개발 환경은 지나치게 복잡해졌다. 간단한 서비스를 하나 띄우기 위해서도 클라우드 콘솔, IAM 설정, Terraform, 컨테이너 오케스트레이션 등 수많은 레이어를 거쳐야 한다.

하지만 본질적으로 개발자가 원했던 것은 훨씬 단순하다.

인터넷에 연결되어 있고, 꺼지지 않으며, 바로 사용할 수 있는 리눅스 컴퓨터 한 대.

exe.dev는 이 단순한 요구를 정면으로 해결하려는 접근이다. 인프라를 다시 “컴퓨터”로 되돌리는 시도라고 볼 수 있다.

exe.dev - ssh exe.dev
Build apps or SSH into a persistent Linux VM. ssh exe.dev.
icon

https://exe.dev

1. SSH가 곧 API가 되는 구조

기존 클라우드 환경에서는 REST API, SDK, 인증 토큰 등을 이해해야 인프라를 제어할 수 있다.

exe.dev는 이 과정을 완전히 제거한다.

인프라 API 자체가 SSH이다.

별도의 인증 토큰이나 SDK 없이, 익숙한 SSH 명령만으로 인프라를 제어할 수 있다.

이 방식은 단순한 편의성을 넘어서, 인프라를 “도구”가 아닌 “환경”으로 느끼게 만든다.

2. API 키 없는 LLM 게이트웨이

AI 기능을 붙일 때 가장 번거로운 부분은 API 키 관리이다.

특히 서버 환경에서는 키 유출 리스크까지 고려해야 한다.

exe.dev는 이 문제를 VM 내부 기능으로 해결한다.

특징

  • API 키 불필요
  • 내부 게이트웨이로 바로 호출 가능
  • OpenAI, Anthropic 등 다양한 모델 지원
  • 토큰 비용 마크업 없음

애플리케이션은 단순히 내부 엔드포인트만 호출하면 된다.

키 관리, 보안 처리, 환경 변수 설정이 모두 사라진다.

3. Serverless가 아닌 Serverful

최근 트렌드는 Serverless지만, 실제 개발에서는 다음과 같은 문제가 있다.

  • 상태 관리가 어렵다
  • 디버깅이 불편하다
  • 로컬 환경과 괴리가 크다

exe.dev는 반대로 Serverful 모델을 선택한다.

핵심 특징

  • 영구 디스크 제공
  • 일반 파일 시스템 사용 가능
  • SQLite 바로 사용 가능
  • 로그를 로컬 파일로 저장 가능

즉, 기존 리눅스 서버와 동일한 개발 경험을 제공한다.

복잡한 분산 시스템 대신 단일 VM 기반의 단순한 구조를 지향한다.

이 접근은 “Frugal Monolith”라는 개념과 맞닿아 있다.

4. 인증을 프록시로 위임

웹 서비스에서 인증은 항상 반복되는 작업이다.

  • 회원가입
  • 비밀번호 해싱
  • 세션 관리
  • 계정 복구

exe.dev는 이 모든 과정을 프록시 레이어에서 처리한다.

동작 방식

  • 사용자가 인증되면 프록시가 헤더를 주입
  • 애플리케이션은 헤더만 읽으면 됨

공유 기능

구글 문서처럼 간단하게 접근 권한을 제어할 수 있다.

애플리케이션 레벨에서 인증 로직을 거의 작성하지 않아도 된다.

5. 2초 만에 생성되는 VM

exe.dev는 VM 생성 속도에서도 차별점을 가진다.

  • 평균 생성 시간 약 2초
  • 컨테이너 이미지를 블록 디바이스로 직접 연결
  • 즉시 실행 가능한 환경 제공

활용 방식

  • 실험용 샌드박스
  • 빠른 프로토타이핑
  • ephemeral 개발 환경

아이디어 → 실행까지의 시간이 극단적으로 짧아진다.

6. 글로벌 리전 기반 실행

VM은 여러 리전에서 생성할 수 있다.

  • LAX (로스앤젤레스)
  • TYO (도쿄)
  • FRA (프랑크푸르트)

지연 시간을 고려하여 가까운 리전을 선택하면 된다.

특히 한국에서는 TYO 리전이 실질적인 기본 선택지에 가깝다.

결론: 인프라를 다시 "컴퓨터"로

exe.dev는 복잡한 클라우드 추상화를 줄이고, 인프라를 다시 단순한 형태로 되돌린다.

핵심은 다음과 같다.

  • SSH = API
  • VM = 기본 단위
  • 파일 시스템 = 그대로 사용
  • 인증 = 프록시 위임
  • AI = 내장 게이트웨이

이 구조는 개발자가 인프라 설정이 아니라, 비즈니스 로직에 집중하게 만든다.

마치며

지금까지의 인프라는 점점 더 많은 레이어를 쌓아 올리는 방향으로 발전해왔다.

exe.dev는 그 흐름을 뒤집고, 본질적인 형태로 돌아가려는 시도이다.

새로운 프로젝트를 시작할 때 선택지는 두 가지다.

  • 복잡한 클라우드 설정으로 시작할 것인가
  • 아니면 ssh exe.dev new 한 줄로 시작할 것인가

개발 생산성의 관점에서 보면, 이 선택은 생각보다 큰 차이를 만든다.

추천 글