Heroku의 종말 — Railway vs Render vs Fly.io: 2026년, 다음은 어디로?

Railway vs Render vs Fly.io 선택은 세 가지 다른 철학으로 귀결됩니다. Railway는 사용량 기반의 단순함을 제공하고, Render는 관리형 프로덕션 인프라를 제공하며, Fly.io는 완벽한 Docker 제어를 갖춘 글로벌 엣지 배포를 제공합니다. Heroku가 2026년 초 유지 보수 엔지니어링으로 전환한다고 발표한 이후—새로운 기능 없음, 새로운 엔터프라이즈 계약 없음—수천 명의 개발자가 새로운 터전을 찾고 있습니다. 이 글에서는 네 가지 트래픽 수준에서의 실제 비용, 나란히 비교한 배포 설정, 그리고 회사 단계별 프레임워크를 통해 세 플랫폼을 모두 비교하므로, 이제 비교 글을 읽는 것을 멈추고 실제로 제품을 출시할 수 있습니다.

한눈에 보는 Railway vs Render vs Fly.io

각 카테고리를 자세히 살펴보기 전에 30초 요약 버전입니다.

핵심 요약: Railway는 코드에서 URL까지 가는 가장 빠른 길입니다. Render는 프로덕션 등급의 Postgres와 예측 가능한 청구서가 필요할 때 이동하는 곳입니다. Fly.io는 사용자가 대륙을 가로지르고 Docker에 익숙할 때 선택하는 곳입니다. 각 카테고리를 자세히 살펴보겠습니다.

가격은 실제로 어떻게 작동하나요?

가격은 Reddit과 Hacker News의 모든 배포 플랫폼 스레드에서 가장 중요한 요소이며, 세 플랫폼의 청구 방식은 서로 완전히 다릅니다.

Railway: 초 단위 결제의 단순함

Railway는 CPU와 메모리에 대해 초 단위로 청구합니다. 컴퓨팅 요율은 $0.00000772/vCPU-초, 메모리는 $0.00000386/GB-초입니다. 송신 트래픽(Egress)은 $0.05/GB입니다. 앱이 소비한 만큼만 정확히 지불하며, 그 이상은 없습니다. Hobby 플랜은 지출 한도로 작용하는 구독료로 월 $5이며, Pro 플랜은 리소스 제한 없이 좌석당 월 $20입니다.

단점이 있다면 무료 티어가 더 이상 없다는 것입니다. Railway는 2023년에 이를 제거하고 일회성 $5 체험 크레딧으로 대체했습니다.

Render: 고정 요금제의 예측 가능성

Render는 서비스당 고정 월별 가격을 사용합니다. Starter 웹 서비스는 월 $7, Standard는 월 $25, Pro 티어는 최대 월 $450입니다. 관리형 Postgres는 기본 티어의 경우 월 $6부터 시작합니다. 대부분의 플랜에는 송신 트래픽 비용이 포함되어 있습니다.

무료 티어가 존재하지만 확실한 trade-off가 있습니다. 서비스는 15분 동안 비활성 상태이면 다운되며, 그 후 첫 번째 요청은 30~60초가 소요됩니다. 산발적인 트래픽이 발생하는 취미용 프로젝트의 경우 이는 고통스러울 수 있습니다.

Fly.io: 학습 곡선이 있는 사용량 기반

Fly.io는 Machines 청구 모델을 사용하여 VM-초 단위로 청구합니다. 256MB RAM이 탑재된 shared-cpu-1x는 24시간 연중무휴로 실행할 경우 월 약 $2.02입니다. 볼륨 비용은 월 $0.15/GB입니다. 북미와 유럽의 송신 트래픽은 $0.02/GB로 저렴하지만, 아프리카와 인도에서는 $0.12/GB로 급증합니다. 기본적인 취미용 사용을 커버하는 레거시 월 $5 무료 허용량이 있습니다.

개발자들의 일반적인 불만 사항은 무엇일까요? Fly.io 가격 예측에는 "스프레드시트가 필요하다"는 점입니다. 구성 요소별 청구(Machines + 볼륨 + 송신 트래픽 + IP)는 첫 번째 청구서를 받을 때까지 명확하지 않은 방식으로 누적됩니다.

실제 월별 비용: 동일한 앱, 세 가지 플랫폼

동일한 스택이 각 플랫폼에서 실제로 얼마나 드는지 확인해 보겠습니다. 이는 게시된 요율을 기반으로 한 추정치이며, 트래픽 패턴과 리소스 소비량에 따라 달라질 수 있습니다.

몇 가지 눈에 띄는 점이 있습니다. Railway와 Fly.io는 실제 소비량만큼만 지불하기 때문에 거의 모든 티어에서 더 저렴합니다. Render의 고정 요금제 모델은 사용 여부와 관계없이 예약된 용량에 대해 비용을 지불한다는 의미이지만, 새벽 3시에 놀라운 청구서를 받지 않아도 된다는 장점도 있습니다.

규모가 커지면 Fly.io의 $0.02/GB 송신 트래픽 비용은 Railway의 $0.05/GB보다 의미 있는 우위를 제공합니다. 앱이 많은 정적 자산이나 API 응답을 제공하는 경우, 송신 트래픽 비용은 조용히 가장 큰 비용 항목이 될 수 있습니다.

판결: 규모 측면에서 순수 비용은 Fly.io가 승리합니다. 사용한 만큼 지불하는 단순함은 Railway가 승리합니다. 예측 가능한 청구는 Render가 승리합니다. 다음 달 비용을 항상 정확히 알 수 있습니다.

개발자 경험(DX) 및 배포 워크플로우

DX는 두 번째로 중요한 요소이며, 이러한 플랫폼들이 일상적으로 가장 다르게 느껴지는 부분입니다.

첫 배포: Git Push vs CLI vs Docker

Railway는 저장소에서 실행 중인 앱으로 가는 가장 빠른 길을 genuinely 제공합니다. GitHub 저장소를 연결하고 푸시하면 Railway가 Railpack(현재 유지 보수 모드인 Nixpacks의 후속작)을 사용하여 런타임을 자동 감지합니다. Dockerfile, 구성 파일, 빌드 명령어가 필요 없습니다. 또는 터미널에서 railway up을 실행하면 몇 초 만에 배포됩니다.

Render도 마찬가지로 간단합니다. GitHub를 연결하고 브랜치를 선택하면 Render의 네이티브 빌드팩이 나머지를 처리합니다. 네이티브 CLI가 없으며 모든 작업은 대시보드나 API를 통해 수행됩니다. GUI 워크플로를 선호하는 개발자에게는 괜찮지만, CLI 우선 개발자에게는 공백입니다.

Fly.io는 flyctl과 실질적으로 Dockerfile이 필요합니다. 커뮤니티 빌드팩이 존재하지만, 대부분의 Fly.io 사용자는 제어를 위해 자체 Dockerfile을 작성하게 됩니다. 학습 곡선은 더 steep하지만, 보상으로는 컨테이너에서 정확히 무엇이 실행되고 있는지 이해하게 됩니다.

Railpack, Nixpacks 및 Dockerfile이 컨테이너 빌드 시스템 선택으로서 어떻게 비교되는지에 대한 자세한 내용은 전용 게시물에서 다루었습니다.

나란히 비교한 배포 설정

세 플랫폼 모두에 배포된 동일한 Node.js 앱입니다. 이것이 매일 느끼게 될 실제적인 차이점입니다.

Fly.io, fly.toml:

app = "my-node-app"
primary_region = "iad"

[build]
  dockerfile = "Dockerfile"

[deploy]
  release_command = "npx prisma migrate deploy"

[http_service]
  internal_port = 3000
  force_https = true
  auto_stop_machines = "stop"
  auto_start_machines = true
  min_machines_running = 0

Render, render.yaml:

services:
  - type: web
    runtime: node
    name: my-node-app
    plan: starter
    buildCommand: npm install && npm run build
    startCommand: npm start
    envVars:
      - key: NODE_ENV
        value: production
    autoDeploy: true

Railway, railway.json (선택 사항, Railpack이 대부분의 설정을 자동 감지):

{
  "$schema": "https://railway.com/railway.schema.json",
  "build": {
    "builder": "railpack"
  },
  "deploy": {
    "startCommand": "npm start",
    "healthcheckPath": "/health",
    "restartPolicyType": "ON_FAILURE"
  }
}

Railway의 구성은 선택 사항이며, Railpack이 package.json에서 빌드를 파악한다는 점에 주목하세요. Fly.io의 fly.toml은 가장 많은 제어권(배포 전략, 릴리스 명령, scale-to-zero 설정)을 제공하지만 가장 많은 지식을 요구합니다. Render의 render.yaml은 중간에 위치합니다. Docker 전문 지식 없이 선언적 인프라-as-code를 제공합니다.

판결: 개발자 경험은 Railway가 승리합니다. 배포가 가장 빠르고, CLI가 가장 우수하며, 필수 구성이 제로입니다. Render는 대시보드 워크플로를 선호하는 팀에게 근소한 차이로 2위입니다. Fly.io는 제어권을 위해 DX를 희생하며, Docker가 제공하는 것이 필요한 경우에만 가치가 있습니다.

데이터베이스 및 관리형 서비스

데이터베이스 선택은 컴퓨팅 선택보다 더 중요할 수 있습니다. 플랫폼들이 크게 갈라지는 지점입니다.

관리형 Postgres: 실제 차이점

Render는 단연코 가장 강력한 데이터베이스 스토리를 가지고 있습니다. 그들의 관리형 Postgres에는 모든 유료 인스턴스에 시점 복구(PITR), 더 큰 티어의 읽기 복제본, 휴식 상태 AES-256 암호화, 자동 백업, 느린 쿼리 로그 및 자동 스토리지 확장이 포함됩니다. 이는 재현하는 데 상당한 DevOps 시간이 소요되는 프로덕션 등급의 인프라입니다.

Railway는 시작하기 매우 간단한 컨테이너화된 Postgres를 제공합니다. 버튼을 클릭하면 연결 문자열이 생성됩니다. 하지만 PITR, 읽기 복제본 및 심층 관리 기능이 부족합니다. 사이드 프로젝트와 초기 단계 앱에는 완벽하게 적합합니다. 그러나 실제 고객 데이터를 처리하는 프로덕션 워크로드의 경우 PITR 부재는 의미 있는 위험입니다.

Fly.io는 완전히 다른 접근 방식을 취합니다. Fly Postgres가 존재하지만 Fly.io는 이것이 관리형 데이터베이스가 아님을 명시합니다. "Postgres가 메모리 또는 디스크 공간 부족으로 충돌하면 복구하기 위해 약간의 작업을 수행해야 합니다." 그들은 이에 대한 지원을 제공할 수 없습니다. 대부분의 숙련된 Fly.io 사용자는 Neon, Supabase 또는 PlanetScale과 같은 외부 관리형 데이터베이스와 함께 사용합니다.

Redis, Cron 및 기타 모든 것

판결: 데이터베이스 중심 애플리케이션에는 Render가 승리합니다. 앱의 데이터 계층이 중요하다면(그리고 거의 항상 그렇습니다), Render의 관리형 Postgres는 진정한 프로덕션 이점입니다. Railway는 DB 기능이 덜 중요한 빠른 반복에 가장 적합합니다. Fly.io 사용자는 외부 관리형 데이터베이스를 위한 예산을 책정해야 합니다.

확장 및 글로벌 배포

Fly.io의 더 steep한 학습 곡선을 정당화하는 부분입니다.

멀티 리전: Fly.io의 엣지 네트워크

Fly.io는 북미, 유럽, 아시아 태평양, 남미 및 아프리카를 아우르는 18개 리전에서 컨테이너를 실행합니다. 앱은 대부분의 인구 밀집 지역에서 20ms 미만의 지연 시간으로 사용자 근처에서 실행됩니다. 단일 명령어로 여러 리전에 배포할 수 있으며, 이는 Fly.io의 핵심 가치 제안입니다.

Render는 4개 리전(오리건, 프랑크푸르트, 싱가포르, 오하이오)을 제공합니다. 각 서비스는 하나의 리전에 고정됩니다. 사용자가 대부분 한 지역에 있다면 충분합니다. 하지만 사용자가 글로벌이라면 선택한 리전에서 먼 사용자에게 100-200ms의 지연 시간을 추가하게 됩니다.

Railway도 약 4개 리전을 보유하고 있으며 확장 중이지만, 멀티 리전 배포는 주요 초점이 아닙니다. Railway는 지리적 분포보다는 단순함을 최적화합니다.

Scale-to-Zero: 앱을 사용하지 않을 때 실제로 발생하는 일

이는 하루 대부분 대기 상태인 취미용 프로젝트와 내부 도구에 매우 중요합니다.

Fly.io Machines는 진정한 scale-to-zero를 지원합니다. fly.toml에서 auto_stop_machines = "stop"을 설정하면 트래픽이 없을 때 Fly Proxy가 Machine을 중지합니다. 다음 들어오는 요청은 콜드 스타트를 트리거하며, 앱의 부팅 시간에 따라 일반적으로 300ms-2초가 소요됩니다. 이는 명시적으로 scale-to-zero로 확장되지 않는 지표 기반 자동 확장과 구별되는 HTTP 기반 자동 확장입니다.

Render의 무료 티어는 15분 동안 비활성 상태이면 다운되며 30-60초의 콜드 스타트가 발생합니다. 유료 플랜은 계속 실행되며, Render는 유료 인스턴스에서 scale-to-zero를 지원하지 않습니다(최소 인스턴스 수는 항상 1).

Railway는 scale-to-zero를 제공하지 않습니다. 유료 플랜에서 서비스가 계속 실행되므로 일관된 성능을 제공하지만 유휴 기간 동안에도 일관된 청구가 발생합니다.

부하 하의 자동 확장

판결: 글로벌 배포와 scale-to-zero에서는 Fly.io가 압승입니다. 사용자가 여러 대륙에 걸쳐 있거나 진정한 scale-to-zero 경제성이 필요한 경우, 여기서 유일한 현실적인 옵션은 Fly.io입니다. Render는 예측 가능한 동작을 갖춘 간단한 자동 확장에서 승리합니다. Railway는 인프라에 대해 전혀 생각하지 않아도 되는 제로 구성 확장에서 승리합니다.

팀 기능, CI/CD 및 협업

다른 Railway vs Render vs Fly.io 비교 글에서는 다루지 않지만, 솔로 개발자 단계를 넘어서면 매우 중요한 섹션입니다.

팀 역할 및 액세스 제어

Railway는 Pro 플랜에서 역할 기반 액세스를 지원하는 팀 워크스페이스를 지원합니다. PR 환경은 standout 기능입니다. 모든 풀 리퀘스트는 PR이 병합되거나 닫힐 때 자동 삭제되는 임시 환경을 얻습니다. 또한 모노레포를 위한 Focused PR 환경을 지원합니다. 전체 환경 RBAC는 Enterprise 전용입니다.

Render는 모든 풀 리퀘스트에 대해 전체 인프라 복사본(데이터베이스 포함)을 생성하는 PR 미리보기 환경을 제공합니다. previewPlan 설정으로 비용을 제어하고 expireAfterDays로 미리보기를 자동 만료시킬 수 있습니다. 이는 Professional 워크스페이스가 필요합니다.

Fly.io는 팀 관리를 위한 Organizations를 가지고 있지만, 미리보기 환경은 수동 설정이 필요하며 내장된 PR 통합이 없습니다. Fly.io를 사용하는 대부분의 팀은 GitHub Actions를 통해 이를 연결합니다.

미리보기 환경 및 CI/CD 파이프라인

판결: 팀에게는 Render가 승리합니다. 전체 데이터베이스 복사본이 포함된 네이티브 PR 미리보기 환경은 빠르게 출시하는 스타트업에게 킬러 기능입니다. Railway는 자동 관리되는 PR 환경으로 근소한 차이로 2위입니다. Fly.io는 팀 워크플로를 위해 가장 많은 접착 작업(glue work)이 필요합니다.

Techsy가 스타트업의 스택 선택을 돕는 방법

우리는 수십 개의 스타트업이 바로 이 결정을 내리는 것을 도와왔으며, 답은 결코 "그냥 X를 사용하세요"처럼 단순하지 않습니다.

우리의 접근 방식은 네 가지 질문으로 시작합니다. 데이터 계층은 어떻게 구성되어 있나요? 사용자는 지리적으로 어디에 있나요? 팀의 Docker 경험은 얼마나 되나요? 그리고 월간 인프라 예산은 얼마인가요? 답은 놀랍도록 깔끔하게 이 세 가지 플랫폼 중 하나로 매핑됩니다.

Node.js와 PostgreSQL로 구축하는 전형적인 초기 단계 SaaS 팀의 경우, 우리는 일반적으로 속도를 위해 Railway에서 시작한 다음, PITR이 포함된 프로덕션 Postgres와 예측 가능한 청구가 필요할 때 Render로 마이그레이션하는 것을 권장합니다. 실시간 또는 지연 시간 민감 제품(멀티플레이어 게임, 금융 대시보드, 협업 편집기)을 구축하는 팀은 종종 외부 관리형 데이터베이스와 함께 Fly.io로 바로 이동합니다.

또한 우리는 마이그레이션 자체도 처리합니다. 환경 변수 재구성, CI/CD 파이프라인 설정 및 제로 다운타임 데이터베이스 전송을 보장합니다. 이는 팀이 주말을 보내야 하는 작업이지만, 우리는 수십 번 해봤기 때문에 몇 시간 만에 완료합니다.

배포 플랫폼 선택 또는 마이그레이션에 도움이 필요하신가요? 무료 아키텍처 검토 받기, 스택을 평가하고 가장 적합한 것을 권장해 드립니다.

귀하의 단계에 맞는 플랫폼은 무엇인가요?

"어떤 것이 최고인가"라고 묻는 것을 멈추고 "지금 내가 있는 곳에서 어떤 것이 최고인가"라고 묻기 시작하세요.

대부분의 팀이 따르는 승격 경로는 다음과 같습니다. 인프라에 대해 생각하기 싫고 빠르게 반복할 때는 Railway에서 시작하세요. 프로덕션 Postgres, 미리보기 환경이 필요하고 팀이 성장하면 Render로 이동하세요. 전 세계적으로 지연 시간이 중요하거나 단일 리전 배포를 넘어섰을 때 Fly.io로 이동하세요.

각 이동의 주요 트리거는 무엇일까요? PITR이나 읽기 복제본이 필요하다고 느끼면 Render로 이동할 때입니다. 아시아나 유럽의 사용자와 앱이 더 가까웠으면 좋겠다고 느끼면 Fly.io로 이동할 때입니다.

AI 기능이 로드맵에 있다면, 그것은 우리의 전문 분야입니다. Techsy의 AI 통합 팀은 LLM 시스템을 프로토타입에서 프로덕션으로 가져갑니다.

자주 묻는 질문

Railway가 Render보다 나은가요?

프로토타이핑과 사이드 프로젝트의 경우, 예. 빠르게 반복할 때 Railway의 사용량 기반 가격과 즉시 배포 기능이 더 나은 선택입니다. 실제 고객 데이터가 있는 프로덕션 SaaS의 경우, PITR이 포함된 Render의 관리형 Postgres와 예측 가능한 청구가 더 강력한 선택입니다. 전적으로 귀하의 단계에 달려 있습니다.

Railway, Render, Fly.io 중 어느 것이 더 저렴한가요?

취미용 사용에는 Railway가 가장 저렴합니다(소비한 만큼만 지불). Fly.io는 $0.02/GB 송신 트래픽 덕분에 규모 확대 시 가장 저렴합니다. Render는 절대 금액으로는 가장 비싸지만 가장 예측 가능하며, 놀라운 청구서가 없습니다. 네 가지 트래픽 수준에서의 실제 추정치는 위의 가격표를 확인하세요.

Railway에 무료 티어가 있나요?

아니요. Railway는 2023년에 무료 티어를 제거했습니다. 새 계정은 일회성 $5 체험 크레딧을 받습니다. 그 후에는 사용량 기반 청구가 추가된 월 $5 Hobby 플랜이 있습니다. Render는 여전히 제한된 무료 티어(콜드 스타트 포함)를 제공하며, Fly.io는 월 $5의 무료 허용량을 포함합니다.

Render의 콜드 스타트 문제는 무엇인가요?

Render의 무료 티어 서비스는 15분 동안 비활성 상태이면 다운됩니다. 다운 후 첫 번째 요청은 응답하는 데 30-60초가 걸리며, 이는 사용자 대상 앱에는 용납될 수 없습니다. 유료 플랜(월 $7 이상)은 계속 실행되며 이 문제가 없습니다.

Fly.io 가격은 어떻게 작동하나요?

Fly.io는 Machines에 대해 VM-초 단위, 볼륨에 대해 GB/월 단위, 송신 트래픽에 대해 GB 단위로 청구합니다. 256MB RAM이 탑재된 기본 shared-cpu-1x VM은 24시간 연중무휴로 실행할 경우 월 약 $2.02입니다. 복잡성은 각 구성 요소를 별도로 청구한다는 점에서 비롯됩니다. VM, 영구 스토리지, IPv4 주소 및 대역폭 모두 고유한 요율을 가지고 있습니다. 개발자들의 일반적인 불만 사항은 월별 비용 예측에 "스프레드시트가 필요하다"는 점입니다.

Railway는 프로덕션 트래픽을 처리할 수 있나요?

예, Railway는 프로덕션 워크로드를 처리하며 많은 스타트업이 이를 사용하고 있습니다. 주요 제한 사항은 컨테이너화된 데이터베이스입니다. PITR 없음, 읽기 복제본 없음, 자동 페일오버 없음. 프로덕션 Postgres의 경우, 컴퓨팅에는 Railway를 사용하고 외부 관리형 데이터베이스(Neon 또는 Supabase 등)를 사용하거나, Render를 고려하세요.

2026년 최고의 Heroku 대체제는 무엇인가요?

Render는 가장 가까운 Heroku 대체제입니다. 관리형 서비스, 고정 요금제 청구 및 유사한 개발자 경험을 제공합니다. Railway는 소규모 프로젝트에 더 단순하고 저렴합니다. Fly.io는 더 많은 제어권과 글로벌 도달 범위를 제공하지만 Docker 지식이 필요합니다. Heroku가 2026년 2월 유지 보수 엔지니어링으로 전환한 이후, 세 플랫폼 모두 마이그레이션하는 팀들로부터 채택이 증가했습니다.

Node.js용 Railway vs Render?

둘 다 Node.js를 잘 처리합니다. Railway는 Railpack의 자동 런타임 감지 덕분에 배포가 더 빠릅니다. 저장소를 푸시하면 빌드를 파악합니다. Render는 구성이 조금 더 필요하지만 프로토타입 단계를 넘어서면 더 나은 프로덕션 인프라를 제공합니다. Postgres가 포함된 Node.js API의 경우, Railway는 더 빠르게 실행되게 하고; Render는 더 안전하게 실행되게 합니다.

Fly.io는 관리형 데이터베이스를 지원하나요?

Fly Postgres가 존재하지만 Fly.io는 이것이 관리형 데이터베이스가 아님을 명시합니다. Postgres가 메모리 또는 디스크 문제로 충돌하면 복구는 사용자의 책임입니다. 데이터베이스 지원을 제공할 수 없습니다. Fly.io 인프라에서 관리형 Postgres를 사용하기 위해 대부분의 팀은 Fly.io 컴퓨팅과 함께 Neon, Supabase 또는 PlanetScale을 사용합니다.

Railway, Render, Fly.io 간에 마이그레이션할 수 있나요?

예. 세 플랫폼 모두 Docker 이미지 또는 Git 저장소에서 배포하므로 애플리케이션 코드는 변경되지 않습니다. 마이그레이션 작업에는 환경 변수 재구성, 데이터베이스 이동(내보내기/가져오기),カスタム 도메인 및 DNS 업데이트, CI/CD 파이프라인 조정이 포함됩니다. 소규모 프로젝트에는 주말을, 프로덕션 데이터와 여러 서비스가 있는 프로젝트에는 스프린트를 예산으로 잡으세요.

최종 판결: Railway vs Render vs Fly.io

빌딩 중일 때는 Railway로 시작하세요. 성장할 때는 Render로 이동하세요. 글로벌로 확장할 때는 Fly.io를 선택하세요. 이는 변명이 아니라 진정으로 최고의 조언입니다. 각 플랫폼은 회사 성장의 특정 단계에서 지배적입니다.

세 플랫폼 모두 반응이 빠른 커뮤니티를 갖춘 견고하고 활발히 개발 중인 플랫폼입니다. 최악의 결정은 출시할 수 있을 때 몇 주 동안 평가하는 데 시간을 보내는 것입니다. 현재 단계와 일치하는 것을 선택하고, 앱을 배포한 후, 필요가 변경되면 6개월 후에 다시 검토하세요.

출처

• Railway 가격
• Render 가격
• Fly.io 가격
• Render 관리형 Postgres 문서
• Fly Postgres, 알아야 할 사항
• Fly.io 리전 참조
• Heroku: Heroku 업데이트 (2026년 2월)