Web Apps를 VPS에 배포하는 것이 이렇게 간단해야 합니다

Source: Dev.to

위 링크에 있는 글의 내용을 제공해 주시면, 해당 텍스트를 한국어로 번역해 드리겠습니다. (코드 블록, URL 및 마크다운 형식은 그대로 유지됩니다.)

왜 VPS에 배포하는 것이 여전히 복잡하게 느껴지는가

나는 서버를 좋아한다— “토요일에 nginx를 손수 튜닝하고 싶다”는 의미가 아니라, “이 6달러짜리 VPS가 내 사이드 프로젝트 절반 정도를 돌릴 수 있을 것 같다”는 의미다.
많은 소규모·중간 규모 웹 앱에서 실제 애플리케이션 자체가 어려운 부분은 아니다; 주변 작업들이 문제다:

• 애플리케이션 빌드
• 서버에 올리기
• 요청을 끊기지 않게 시작하기
• HTTPS 설정
• 무작위 .env 파일에 비밀이 노출되지 않게 하기
• SSH로 로그를 뒤지는 대신 로그 보기
• 로컬 개발 환경을 프로덕션과 비슷하게 만들어 쿠키와 OAuth가 이상하게 동작하지 않게 하기

이것들은 불가능한 것이 아니라, 작은 작업들의 집합일 뿐이다. 바로 그 작업들이 내가 Tako를 만들기 시작한 이유다.

Tako 소개

Tako는 배포를 다음과 같이 간단하게 느끼게 하는 것을 목표로 합니다:

tako init
tako deploy

두 명령이 마법이라서가 아니라, 대부분의 앱은 HTTP를 제공하기 전에 맞춤형 인프라스트럭처 논문이 필요하지 않기 때문입니다.

Tako는 CLI와 작은 서버 런타임을 제공합니다. 서버를 VPS에 한 번 설치하고, 로컬에 그 서버를 추가한 다음, 프로젝트 디렉터리에서 배포합니다.

배포 흐름

이 흐름은 의도적으로 단순합니다:

1. 로컬에서 빌드
2. 출력을 패키징
3. SSH/SFTP를 통해 업로드
4. 서버에서 압축 해제
5. 새 버전을 시작
6. 먼저 기존 버전을 중단하지 않고 트래픽을 전환

레지스트리 없음. 이미지 푸시 없음. 쿠버네티스 객체 그래프 없음. 새벽 1시의 “이 컨테이너 레이어는 어디서 왔지?” 같은 순간도 없습니다.

런타임 및 프록시 모델

Tako는 여러분의 앱을 일반 프로세스로 실행합니다. JavaScript 및 TypeScript 앱의 경우 작은 tako.sh SDK가 제공됩니다. 앱은 바인딩한 포트를 보고함으로써 Tako에게 준비가 되었음을 알리고, 그 이후에 서버 프록시가 안전하게 트래픽을 라우팅할 수 있습니다.

프로덕션 환경에서:

• 앱 인스턴스는 할당된 포트에서 127.0.0.1에 바인딩됩니다.
• Tako의 프록시가 앞에 위치하여 퍼블릭 라우트를 처리하고, 정상적인 인스턴스에만 요청을 전달합니다.

장점

• 롤링 배포 시 기존 인스턴스를 제거하기 전에 새 인스턴스를 시작할 수 있습니다.
• 트래픽이 적은 앱은 스케일‑투‑제로를 선택할 수 있습니다.
• 로그와 상태가 실제 Tako가 시작한 프로세스에 연결됩니다.
• 앱은 퍼블릭 포트나 호스트명을 알 필요가 없습니다.

구성

구성도 별다른 흥미를 끌 필요가 없습니다:

name = "my-app"
runtime = "bun"
preset = "tanstack-start"

[build]
run = "bun run build"

[envs.production]
route = "my-app.example.com"
servers = ["main"]

필요할 때 사용할 수 있는 더 많은 옵션이 있습니다(다중 환경, 서버, 빌드 단계, 릴리스 명령, 비밀, 스케일 설정 등), 하지만 기본 형태는 단순히 “여기에 내 앱이 있고, 여기서 실행되어야 합니다.” 입니다.

로컬 개발

대부분의 배포 도구는 프로덕션 단계에서 멈추고, 포트가 뒤섞인 상황을 남깁니다:

• http://localhost:3000
• http://localhost:5173
• http://localhost:8787

보안 쿠키, OAuth 콜백, 서비스 워커, 두 번째 앱, 혹은 웹훅 터널이 필요할 때, 로컬 설정은 갑자기 자체적인 특성을 갖게 됩니다.

tako dev는 로컬 앱을 실제 앱처럼 느끼게 하려고 합니다:

tako dev

앱에 HTTPS, DNS, 로컬 프록시가 포함된 .test 도메인을 부여합니다. 포트를 기억하는 대신 다음과 같은 주소를 엽니다:

https://my-app.test/

목표는 화려해지는 것이 아니라, 로컬 개발이 프로덕션과 멀어지게 만드는 작은 불편함들을 없애는 것입니다.

Docker가 더 적합할 때

• 앱에 무거운 OS 수준 격리가 필요하다면, 컨테이너가 더 나은 답이 될 수 있습니다.
• 팀에 이미 작동하는 컨테이너 파이프라인이 있다면, 재미로 그것을 버리지 않는 것이 좋습니다.
• 서로 관련 없는 여러 스택을 이상한 시스템 패키지와 함께 실행하고 있다면, Docker는 합리적인 경계가 됩니다.

Tako는 더 의견이 강합니다: Bun, Node, Go와 같은 일반적인 웹 앱 런타임에 집중하고, 그 경로를 빠르고 안정적으로 만들려고 합니다. 그 트레이드오프가 바로 핵심입니다.

시작하기

프로젝트는 오픈 소스입니다. 문서는 여기에서 확인하세요:

빠른 설치

curl -fsSL https://tako.sh/install.sh | sh
tako init
tako dev

서버에 배포

sudo sh -c "$(curl -fsSL https://tako.sh/install-server.sh)"
tako servers add 
tako deploy