실시간 통역툴 서버로 Fly.io를 고를 때 따질 것

실시간 통역툴의 서버를 고를 때 가장 먼저 눈에 들어오는 숫자는 월 사용료다. 그러나 음성 스트림이 수분간 이어지는 서비스에서는 저렴한 VM보다 연결 유지, 피크 동시성, 배포 자동화가 더 중요하다. Fly.io는 이 조건을 어디까지 충족할까. Cloudflare나 Hostinger보다 나은 선택일까.

하루 호출 수보다 피크 동시 통화가 서버 크기를 결정한다

하루 호출 수와 통화 지속 시간만으로 평균 동시 통화를 계산할 수 있지만, 이는 피크 용량을 보여주지 않는다. 하지만 상담 수요가 특정 시간에 몰리면 실제 필요한 용량은 이 평균보다 훨씬 커진다.

Fly.io는 요청 수나 연결 수를 기준으로 Machine별 동시성 한도를 설정한다. fly.toml의 soft_limit은 새 Machine을 깨울 시점을 정하고 hard_limit은 더 받을 수 없는 상한을 만든다. 공식 문서는 부하 테스트로 지연이 급증하는 구간을 찾은 뒤 두 값을 정하라고 권한다. (fly.io)

통역툴은 일반 웹 API와 측정법도 다르다. 짧은 HTTP 요청이라면 초당 요청 수를 보면 된다. WebSocket 기반 음성 통화에서는 연결 하나가 메모리와 소켓을 계속 점유하므로 통화 시작 수, 최대 동시 연결, 한 연결의 메모리, 재접속 비율을 함께 기록해야 한다.

실사용자들 사이에서도 작은 인스턴스의 표기상 CPU만 보고 다른 서비스와 성능이 같다고 판단하면 안 된다는 반응이 있다. 저렴한 구성이 매력적이지만 실제 음성 샘플로 부하를 걸어야 안전하다는 조언도 반복된다.

Fly.io의 강점은 초 단위 과금보다 배포 단순화에 있다

Fly.io Machines는 실행 중인 자원을 초 단위로 계산한다. 공식 가격표에서 가장 작은 shared CPU 구성은 지역에 따라 월 2달러 안팎부터 시작한다. 정지 상태에서는 CPU와 RAM 요금 대신 rootfs 비용이 남는다. 볼륨과 외부 전송량은 별도로 청구된다. (fly.io)

auto_stop_machines와 auto_start_machines를 켜면 유휴 Machine을 멈췄다가 요청이 올 때 다시 시작할 수 있다. 다만 실시간 통역은 첫 음성이 즉시 들어오므로 콜드 스타트가 사용자 경험을 해칠 수 있다. 운영 환경에서는 주 사용 지역에 min_machines_running = 1을 두고 추가 Machine만 자동으로 깨우는 편이 현실적이다. (fly.io)

관리하기 편했다는 현장 의견도 이 구조와 연결된다. 서버에 접속해 프로세스를 다시 띄우는 대신 fly deploy, fly logs, fly scale로 배포와 조정을 처리할 수 있다. 직접 VPS를 운영할 때 필요한 Nginx, 방화벽, 인증서 갱신 작업도 줄어든다.

Flask 프로토타입은 Dockerfile과 fly.toml로 옮긴다

배포에는 애플리케이션 코드, 의존성 정의, Dockerfile, fly.toml을 준비한다. main.py에는 음성 업로드나 세션 생성 API를 두고 /healthz는 외부 모델을 호출하지 않은 채 서버 상태만 반환하도록 만든다. API 키는 코드나 이미지에 넣지 않고 fly secrets set으로 주입한다. (fly.io)

개발용 Flask 서버를 그대로 공개하면 안 된다. requirements.txt에 Flask와 Gunicorn을 넣고 Dockerfile의 실행 명령은 gunicorn --bind 0.0.0.0:8080 src.main:app처럼 WSGI 애플리케이션을 가리키게 한다. Gunicorn은 Flask 같은 WSGI 앱을 여러 worker로 실행할 수 있다. (docs.gunicorn.org)

프로젝트 루트에서 fly launch를 실행하면 소스와 Dockerfile을 감지해 fly.toml을 만든다. 내부 포트를 8080으로 맞춘 다음 health check와 동시성 제한을 추가한다. 비밀값을 등록하고 fly deploy를 실행하면 이미지 빌드에 이어 배포가 진행된다. Fly.io는 Python과 Flask 프로젝트를 CLI에서 감지하는 절차를 공식 지원한다. (fly.io)

음성을 WebSocket으로 계속 전달한다면 Flask 구성만 고집할 이유는 없다. ASGI 기반 서버를 쓰거나 통화 세션을 맡는 스트리밍 프로세스와 관리용 HTTP API를 분리할 수 있다. 클라이언트에는 ping, 재접속, 세션 복구 로직도 넣어야 한다. 장시간 연결은 배포나 프록시 교체 과정에서 끊길 수 있기 때문이다.

Cloudflare와 Hostinger는 비용 구조보다 실행 모델이 다르다

Cloudflare Workers는 전 세계 엣지에서 자동으로 확장되며 유료 플랜은 월 5달러부터 시작한다. HTTP 요청은 클라이언트가 연결된 동안 장시간 스트리밍할 수 있지만 메모리와 CPU 실행 한도가 있다. 일반 Python 서버와 같은 파일시스템이나 프로세스 환경이 필요하다면 Workers만으로 옮기기 어렵다. (developers.cloudflare.com)

Cloudflare Containers는 이런 간극을 줄인다. 유료 Workers 계정에서 컨테이너 이미지를 실행하고 유휴 시 잠들게 할 수 있다. 다만 Worker가 컨테이너 인스턴스를 제어하는 구조이므로 기존 Flask 컨테이너를 빠르게 옮기는 작업은 Fly.io가 더 단순할 수 있다. (664332ed.previews.developers.cloudflare.com)

Hostinger VPS는 정해진 월 비용으로 CPU와 RAM을 확보한다. 가장 작은 공식 상품도 4GB RAM을 제공하지만 장기 계약 할인과 갱신 가격은 구분해야 한다. Flask를 운영하려면 가상환경, Gunicorn, systemd, Nginx, 방화벽을 직접 설정해야 한다. (hostinger.com)

트래픽이 일정하고 서버 관리에 익숙하면 VPS가 예측하기 쉽다. 빠른 반복 배포와 지역 확장이 필요하면 Fly.io가 유리하다. 가벼운 중계 로직을 엣지에서 실행하려면 Workers가 알맞다. Linux 런타임이 필요하다면 Containers까지 비교해야 한다.

통역툴의 큰 비용은 VM 밖에서 발생할 수 있다

운영 사례에서는 상당한 호출량을 처리하면서 월 약 10만 엔이 들었다는 경험이 나왔다. 다만 이 금액에는 사용 모델, 음성 채널 수, 전사 방식, 합성 분량이 드러나지 않았다. 공식 단가와 직접 비교할 수 없는 현장값으로 봐야 한다.

Google Cloud Speech-to-Text는 처리한 음성 시간을 초 단위로 합산하며 표준 구간 가격은 분당 0.016달러로 안내한다. Deepgram도 스트리밍 음성을 분 단위로 과금한다. OpenAI Realtime API처럼 음성 입출력을 하나의 실시간 세션으로 처리하는 방식도 있다. (cloud.google.com)

비용표에는 Machine 요금만 적으면 안 된다. 통화별 STT 입력 시간, 번역 토큰, TTS 문자량, 저장 용량, 외부 전송량을 나눠야 한다. 여기에 평균과 최대 동시 통화, 실패 후 재시도 비용을 붙이면 아키텍처별 차이가 드러난다.

Fly.io를 선택할 근거는 가장 싼 VM이라는 문구가 아니다. 음성 파이프라인을 컨테이너로 빠르게 반복하고 실제 피크에 맞춰 동시성을 직접 조절할 수 있다는 점이 통역툴과 더 잘 맞는다.