Railway 실전 가이드: 1인 개발자를 위한 가장 쉬운 배포 플랫폼

1인 개발자의 배포 딜레마

프론트엔드는 Vercel에 배포하면 된다. 무료고, GitHub에 푸시하면 자동으로 올라가고, 글로벌 CDN까지 붙어있다. 문제는 백엔드다.

Express API 서버를 어디에 올릴까? Discord 봇은? 5분마다 돌아야 하는 크론 잡은? AI 인터뷰 엔진처럼 WebSocket이나 SSE가 필요한 서버는?

선택지를 나열해보면:

Vercel: 서버리스만 지원. 상태를 유지하는 서버, 긴 연결, 백그라운드 워커는 어렵다.

Heroku: 2022년 무료 플랜 삭제 이후 기본 Dyno가 월 $7. 느리고, 콜드 스타트 있고, Docker 지원이 아쉽다.

Render: Heroku와 유사한 포지셔닝. 무료 플랜이 있지만 15분 비활성화 시 슬립 모드. 유료는 월 $7~.

Fly.io: Docker 기반, 글로벌 분산 배포. 설정이 복잡하고 fly.toml 파일 관리가 번거롭다.

AWS / GCP: 기능은 최강이지만 IAM, VPC, 보안그룹, 로드밸런서... 1인 개발자가 혼자 다 관리하기에는 오버킬이다.

Railway는 이 딜레마를 다른 각도에서 푼다. "개발자 경험(DX)을 Vercel 수준으로 끌어올린 풀스택 배포 플랫폼." 실제로 써보니 그 말이 맞다.

Railway가 뭔가

Railway는 2020년 런칭한 클라우드 배포 플랫폼이다. 핵심 철학은 단순하다: 인프라 설정을 최소화하고 코드에 집중하게 한다.

Nixpacks: Dockerfile 없이 자동 빌드

Railway의 가장 큰 차별점은 Nixpacks다. 레포를 연결하면 Railway가 코드를 분석해서 자동으로 빌드 환경을 잡아준다.

Node.js 프로젝트면 package.json의 start 스크립트를 찾아서 실행하고, Python이면 requirements.txt나 pyproject.toml을 보고 패키지를 설치한다. Go, Rust, Ruby, PHP, Java — 웬만한 언어는 다 지원한다.

# Dockerfile 없어도 된다. railway.json 없어도 된다.
# 그냥 레포 연결하면 끝.
git push origin main
# → Railway가 자동으로 빌드하고 배포

물론 Dockerfile을 직접 쓸 수도 있다. 더 세밀한 제어가 필요하거나, Nixpacks로 잡히지 않는 의존성이 있을 때는 Dockerfile을 레포 루트에 두면 Railway가 그걸 우선 사용한다.

GitHub 연동: 푸시하면 자동 배포

GitHub 레포를 연결하면 main 브랜치에 푸시할 때마다 자동으로 재배포된다. PR을 올리면 임시 환경(Preview Environment)을 만들어서 배포 결과를 미리 볼 수도 있다. Vercel에서 익숙한 그 경험이다.

데이터베이스도 한 곳에서

PostgreSQL, MySQL, MongoDB, Redis를 Railway 대시보드 안에서 바로 생성할 수 있다. 별도 서비스 가입 없이, 환경변수도 자동으로 연결된다. 소규모 프로젝트라면 Supabase나 PlanetScale 없이도 Railway 하나로 해결된다.

핵심 기능 4가지

1. 환경변수 관리

Railway의 환경변수 관리는 직관적이다. 대시보드에서 Key-Value로 추가하면 서비스에 즉시 반영된다. 재배포 없이 환경변수만 바꿔서 반영하는 것도 가능하다.

더 유용한 건 서비스 간 변수 참조다. 같은 프로젝트 내 다른 서비스의 변수를 ${{서비스명.변수명}} 형태로 참조할 수 있다. PostgreSQL 서비스의 DATABASE_URL을 API 서버에서 ${{Postgres.DATABASE_URL}}로 쓰는 식이다. 복사-붙여넣기 실수가 없어진다.

2. Private Networking

같은 Railway 프로젝트 내 서비스들은 Private Network로 연결된다. 인터넷을 거치지 않고 내부 네트워크로 통신하기 때문에 빠르고 안전하다.

API 서버 → DB, API 서버 → Redis, 워커 → 메시지 큐 같은 내부 통신은 전부 Private Networking으로 처리하면 된다. AWS에서 VPC 설정하는 것과 같은 효과인데, 설정할 게 아무것도 없다.

3. Cron Jobs

Railway에서 Cron Job을 추가하는 건 세 줄짜리 설정이다. 서비스 설정에서 Cron 스케줄을 입력하면 끝이다.

0 9 * * *   # 매일 오전 9시 실행
*/5 * * * * # 5분마다 실행
0 0 * * 1   # 매주 월요일 자정

별도 Cron 서비스(GitHub Actions, Cloud Scheduler 등)를 쓰지 않아도 된다. 애플리케이션 코드 안에 스케줄러를 내장하고 Railway에서 환경변수로 켜고 끄는 패턴도 잘 동작한다.

4. Railway CLI

Railway의 진짜 매력은 CLI다.

# 설치
npm install -g @railway/cli

# 로그인
railway login

# 프로젝트 초기화 (기존 프로젝트 연결)
railway init

# 즉시 배포
railway up

# 환경변수 설정
railway variables set KEY=VALUE

# 로그 보기
railway logs

# 원격 서비스에 명령 실행
railway run npm run migrate

railway up은 현재 디렉토리를 그대로 Railway에 올린다. GitHub 연동 없이도 로컬에서 바로 배포할 수 있다. 급하게 픽스를 올려야 할 때 유용하다.

railway run은 원격 환경변수를 그대로 주입해서 로컬 명령을 실행한다. DB 마이그레이션을 Railway 환경변수로 돌리거나, 일회성 스크립트를 실행할 때 쓴다.

railway logs --service cofounder-agent --json | jq '.message'

실전 사용 사례: Agentic30

실제로 Agentic30 프로젝트에서 Railway를 어떻게 쓰는지 공유한다.

Agentic30는 Turborepo 기반 모노레포다. 여러 앱이 하나의 레포에 같이 있다:

• apps/web — Next.js 앱 → Cloudflare Workers 배포
• apps/cofounder-agent — Express + Discord Bot + AI 인터뷰 엔진 → Railway 배포
• apps/mcp-server — MCP 도구 서버 → Railway 배포

cofounder-agent는 SSE 스트리밍, Discord Gateway 연결, 백그라운드 크론 스케줄러가 있는 서버다. 서버리스로는 운영이 불가능하고, 상시 실행되어야 한다. Railway가 딱 맞는 선택이었다.

배포 플로우

# 1. Turborepo로 서비스만 pruning
turbo prune agentic30-cofounder-agent --docker --out-dir out

# 2. Dockerfile과 railway.toml 복사
cp apps/cofounder-agent/Dockerfile out/
cp apps/cofounder-agent/railway.toml out/

# 3. Railway에 배포
cd out && railway up --detach --service cofounder-agent

turbo prune --docker는 특정 서비스와 그 의존성만 추려서 별도 디렉토리에 복사한다. 전체 모노레포를 Railway에 올리는 게 아니라, 필요한 것만 올린다. 빌드가 빠르고 이미지 크기도 작아진다.

railway.toml

Railway는 railway.toml 파일로 배포 설정을 관리한다.

[build]
builder = "DOCKERFILE"
dockerfilePath = "Dockerfile"

[deploy]
startCommand = "node dist/index.js"
healthcheckPath = "/health"
healthcheckTimeout = 30
restartPolicyType = "ON_FAILURE"
restartPolicyMaxRetries = 3

healthcheckPath를 설정하면 Railway가 헬스체크를 통과할 때까지 기존 서비스를 유지한다. 무중단 배포가 자동으로 된다.

Dockerfile 패턴 (Non-root 필수)

Railway에서 Claude Agent SDK를 사용할 때 주의할 점이 있다. Agent SDK는 root 유저에서 실행을 거부한다. Dockerfile에 반드시 non-root 유저를 설정해야 한다.

FROM oven/bun:1 AS builder
WORKDIR /app
COPY bun.lock package.json ./
RUN bun install --frozen-lockfile
COPY . .
RUN bun run build

FROM node:22-slim AS production
# non-root 유저 생성 (Agent SDK 필수)
RUN useradd -m appuser
WORKDIR /app
COPY --from=builder --chown=appuser:appuser /app/dist ./dist
COPY --from=builder --chown=appuser:appuser /app/node_modules ./node_modules
USER appuser
CMD ["node", "dist/index.js"]

Monorepo에서 Railway 배포하는 법

모노레포를 Railway에 배포하는 방법은 크게 두 가지다.

방법 1: Root Directory 설정

Railway 서비스 설정에서 "Root Directory"를 apps/cofounder-agent로 지정한다. Railway가 그 디렉토리를 기준으로 빌드한다. 단순한 경우에 잘 동작하지만, 모노레포 내 공유 패키지(packages/shared 등)를 사용할 때는 한계가 있다.

방법 2: Turbo Prune (권장)

앞서 설명한 turbo prune --docker 패턴이다. 공유 패키지 의존성까지 포함해서 독립 실행 가능한 서브셋을 만들어준다.

CI/CD로 자동화할 때는 GitHub Actions에서 이렇게 처리한다:

- name: Prune monorepo
  run: turbo prune agentic30-cofounder-agent --docker --out-dir out

- name: Copy deployment files
  run: |
    cp apps/cofounder-agent/Dockerfile out/
    cp apps/cofounder-agent/railway.toml out/

- name: Deploy to Railway
  working-directory: out
  run: railway up --detach --service cofounder-agent
  env:
    RAILWAY_TOKEN: ${{ secrets.RAILWAY_TOKEN }}

RAILWAY_TOKEN은 Railway 대시보드의 Account Settings > Tokens에서 발급받는다. GitHub Secrets에 저장하면 CI에서 자동으로 배포된다.

가격 비교: 실제로 얼마나 드나

Railway 가격 구조는 크게 두 가지다:

Hobby 플랜: $5/월 크레딧 포함. 사용량이 크레딧 이내면 추가 요금 없음. 초과 시 사용량만큼 청구.

Pro 플랜: $20/월. 팀 기능, 더 많은 리소스, SLA 보장.

사용량 과금은 CPU, 메모리, 네트워크 기준이다. 소규모 서비스 기준으로:

Hobby 플랜 $5 크레딧으로 간단한 API 서버 하나는 거의 무료로 운영할 수 있다.

경쟁사와 비교

Render ($7/월~): Railway와 유사한 포지셔닝. 무료 플랜이 있지만 15분 비활성화 시 슬립. 유료는 Railway보다 약간 비싸고, CLI 경험이 아쉽다.

Fly.io (사용량 과금): 글로벌 분산 배포가 강점. fly.toml 설정이 Railway보다 복잡하고, 학습 곡선이 있다. 고급 사용자에게 더 맞는 플랫폼.

Heroku ($7/월~): 안정적이고 오래된 플랫폼이지만, 2022년 무료 플랜 삭제 이후 가격 대비 경쟁력이 약해졌다. 같은 비용에 Railway가 더 나은 DX를 제공한다.

AWS ECS/EC2: 기능은 최강이지만 설정 복잡도가 너무 높다. 스케일이 커지면 AWS로 마이그레이션하는 게 맞지만, 초기 단계에서는 오버킬이다.

결론: 1인 개발자나 소규모 팀이 빠르게 서비스를 올려야 한다면 Railway가 가성비 최고다. Render보다 싸고, Heroku보다 좋고, Fly.io보다 쉽다.

Railway를 쓰면서 알게 된 것들

헬스체크는 필수로 설정하라

railway.toml에 healthcheckPath를 설정하지 않으면 새 버전 배포 시 이전 서비스가 즉시 내려간다. 헬스체크를 설정하면 새 버전이 정상 응답할 때까지 기존 버전을 유지한다. Express에서는 /health 엔드포인트 하나 만들어두면 된다.

app.get('/health', (req, res) => {
  res.json({ status: 'ok', timestamp: new Date().toISOString() });
});

환경변수 변경은 즉시 반영

Railway에서 환경변수를 바꾸면 자동으로 재배포가 트리거된다. 이게 편할 때도 있지만 불편할 때도 있다. 여러 환경변수를 한 번에 바꿔야 할 때는 CLI를 쓰면 배포를 한 번만 트리거할 수 있다.

# 여러 변수를 한 번에 설정 (재배포 한 번만)
railway variables set KEY1=VAL1 KEY2=VAL2 KEY3=VAL3

로그는 최근 7일만

Railway의 무료/Hobby 플랜에서는 로그 보존 기간이 7일이다. 장기 로그가 필요하면 외부 로그 서비스(Logtail, Datadog 등)로 전송해야 한다.

// pino 같은 로거를 쓰면 외부 전송이 쉽다
import pino from 'pino';
const logger = pino({
  transport: {
    target: 'pino-logtail',
    options: { sourceToken: process.env.LOGTAIL_TOKEN }
  }
});

슬립 모드 없음

Render 무료 플랜의 15분 슬립 문제가 Railway에는 없다. Hobby 플랜부터 상시 실행이다. Discord 봇이나 크론 잡처럼 항상 떠있어야 하는 서비스에는 결정적인 차이다.

이런 경우에 Railway를 써라

Railway가 특히 잘 맞는 상황:

상시 실행 서버가 필요할 때: Discord 봇, WebSocket 서버, SSE 스트리밍 서버, 백그라운드 워커. 서버리스로는 안 되는 것들.

Dockerize된 앱을 빠르게 올릴 때: Dockerfile이 있으면 그냥 railway up으로 끝난다. AWS ECR/ECS 설정에 쏟는 시간이 없어진다.

크론 잡을 간단히 관리할 때: 별도 크론 서비스 없이 Railway 서비스 설정에서 스케줄을 붙여두면 된다.

모노레포에서 여러 서비스를 한 대시보드에서 볼 때: 같은 프로젝트에 올리면 환경변수 공유, Private Networking, 통합 로그 뷰어를 쓸 수 있다.

MVP를 빠르게 올려야 할 때: 인프라 설정에 시간 쓰지 말고 코드에 집중. railway up 한 줄로 올라간다.

결론

1인 개발자에게 배포 플랫폼을 고르는 기준은 단순하다. 얼마나 빨리 올라가고, 얼마나 안 신경 써도 되는가.

Railway는 그 두 가지에서 현존하는 플랫폼 중 가장 잘 만들어진 도구다. Vercel이 프론트엔드 배포의 표준이 된 것처럼, Railway는 백엔드 배포에서 그 포지션을 점점 굳혀가고 있다.

Heroku를 쓰고 있다면 Railway로 마이그레이션을 고려해볼 만하다. 더 싸고, CLI가 훨씬 낫고, Docker 지원이 자연스럽다.

AWS로 가야 하나 고민 중이라면 — 아직이다. 월 MAU 수만 명을 넘기 전까지는 Railway에서 충분히 운영할 수 있다. 그 시점에 AWS로 넘어가도 늦지 않는다.

지금 당장 백엔드 서버 올릴 곳을 찾고 있다면, Railway 계정 만들고 railway up 한 번 해보자. 10분이면 서버가 인터넷에 올라가 있다.