일로와 워커·실시간 서버 배포, 무엇을 선택해야 할까?

웹 인프라2026년 7월 29일글: 홍서진, Duolabs12분 읽기aws-lightsail background-worker blog container-hosting illowa model-openai-gpt-5.5 technical-note websocket

Next.js 서비스의 웹 화면과 API는 Vercel에 올릴 수 있지만, 모든 프로세스를 같은 방식으로 배포할 수 있는 것은 아닙니다. WebSocket 연결을 오래 유지하는 실시간 서버와 큐를 계속 확인하는 백그라운드 워커는 일반적인 웹 요청과 실행 방식이 다릅니다.

이 글에서는 일로와처럼 웹·모바일 API, 실시간 메시지, 이미지 변환, 번역 작업을 함께 가진 초기 서비스가 워커와 실시간 서버를 어디에 배포하면 좋은지 살펴봅니다. 실제 내부 서버 주소와 계정 정보는 제외하고, 비슷한 구조의 서비스를 준비하는 팀이 참고할 수 있도록 일반화했습니다.

가격과 제공 사양은 2026년 7월 기준입니다. 부가세와 환율, 지역별 초과 전송 비용은 별도입니다.

먼저 결론부터

현재 구조를 크게 바꾸지 않고 한국 사용자와 서울 데이터베이스에 가까이 배포하려면 AWS Lightsail 서울 리전의 Linux 인스턴스가 가장 균형이 좋습니다.

단계	권장 사양	월 비용
테스트·초기 운영	2 vCPU, 메모리 2GB, SSD 60GB	12달러
안정적인 초기 운영	2 vCPU, 메모리 4GB, SSD 80GB	24달러

여기서 말하는 Lightsail은 관리형 Container Service가 아니라 Linux 가상 서버입니다. 서버에 Docker와 Docker Compose를 설치하고 실시간 서버와 워커 컨테이너만 실행하는 방식입니다.

Lightsail 인스턴스 사양과 가격
Lightsail 지원 리전

왜 별도 상시 서버가 필요한가

웹 요청은 사용자가 호출할 때 실행되고 응답이 끝나면 자원을 반납할 수 있습니다. 반면 실시간 서버와 워커는 다음 특성이 있습니다.

WebSocket 연결을 계속 유지한다.
Redis Pub/Sub 메시지를 기다린다.
작업 큐를 주기적으로 확인한다.
이미지 리사이즈처럼 순간적으로 CPU와 메모리를 많이 쓰는 작업이 있다.
만료 처리와 데이터 정리처럼 사용자의 요청과 무관한 작업이 있다.

이런 프로세스는 항상 실행되는 작은 컨테이너에 두면 이해하기 쉽습니다. 웹과 API는 Vercel의 자동 확장을 활용하고, 장시간 실행되는 프로세스만 별도 서버가 담당합니다.

2GB로 시작해도 되는 이유

초기 실시간 서버는 연결을 유지하는 동안 CPU를 많이 사용하지 않습니다. 메시지 본문과 상태가 PostgreSQL과 Redis에 있고 서버가 전달 역할에 집중한다면 동시 연결 수가 수십에서 수백인 단계에서는 작은 인스턴스로 시작할 수 있습니다.

이미지 워커도 한 번에 처리하는 작업 수를 제한하고 순차적으로 변환한다면 2GB에서 운영할 수 있습니다. 데이터베이스, Redis, AI 모델을 같은 서버에서 실행하지 않는다는 전제입니다.

다음 조건에서는 처음부터 4GB를 선택하는 편이 안전합니다.

GIF나 고해상도 이미지를 자주 변환한다.
이미지 작업과 번역 작업이 동시에 몰릴 수 있다.
운영자가 메모리 부족 재시작을 최소화해야 한다.
같은 서버에 모니터링 에이전트와 배포 도구도 함께 실행한다.

월 12달러 차이로 메모리를 두 배 확보할 수 있으므로, 실제 사용자가 있는 운영 환경이라면 4GB도 과한 선택은 아닙니다.

언제 4GB로 올려야 하는가

사용자 수만 보고 서버를 올리기보다 다음 지표를 확인하는 편이 정확합니다.

컨테이너가 OOMKilled 상태로 재시작되는가
메모리 사용률이 장시간 70~80%를 넘는가
이미지 처리 시간이 계속 늘어나는가
작업 큐가 줄지 않고 쌓이는가
WebSocket 재연결이나 응답 지연이 증가하는가
서버의 load average가 사용 가능한 CPU 수에 자주 접근하는가

이미지 처리량만 증가한다면 서버 전체를 키우기 전에 이미지 워커를 별도 인스턴스로 분리하는 방법도 있습니다. 단, 하나만 실행해야 하는 작업이라면 복제 수를 무작정 늘리기보다 작업 선점과 멱등성을 먼저 보장해야 합니다.

Lightsail Container Service보다 Linux 인스턴스가 나은 이유

이름만 보면 Lightsail Container Service가 더 자연스러워 보이지만, 작은 상시 프로세스 두 개를 운영할 때는 Linux 인스턴스가 더 경제적입니다.

Lightsail Container Service는 메모리 2GB, 1 vCPU인 Medium 노드가 월 40달러입니다. 반면 Linux 인스턴스는 메모리 2GB와 2 vCPU 구성이 월 12달러이고, 메모리 4GB 구성도 월 24달러입니다.

관리형 Container Service는 빌드와 배포가 편하지만, 이미 Docker Compose 구성이 있고 작은 팀이 한 대의 서버를 관리할 수 있다면 가격 차이를 정당화하기 어렵습니다.

Amazon Lightsail 요금표

대안 1: Render

서버 운영을 거의 하지 않고 Git 저장소를 연결해 바로 배포하고 싶다면 Render가 편합니다.

Render는 Web Service에서 WebSocket을 지원하고 연결에 고정 최대 시간을 두지 않습니다. Background Worker도 별도 서비스 유형으로 제공하므로 실시간 서버와 워커를 역할에 맞게 나눌 수 있습니다.

다만 현재 아시아 리전은 싱가포르입니다. PostgreSQL을 서울에 두었다면 워커가 데이터베이스에 접근할 때 리전 간 지연이 추가됩니다. 실시간 서버와 데이터베이스의 왕복이 많은 구조라면 배포 편의와 지연 사이에서 판단해야 합니다.

비용은 Starter 512MB가 월 7달러, Standard 2GB가 월 25달러 수준입니다. 실시간 서버는 Starter, 이미지 워커는 Standard로 구성하면 월 32달러 정도에서 시작합니다.

Render WebSocket
Render Background Worker
Render 리전
Render 인스턴스 가격 안내

대안 2: Railway

Railway는 하나의 저장소에서 시작 명령만 다르게 지정해 실시간 서버와 워커를 빠르게 배포하기 좋습니다. 사용량 기반 과금이라 테스트 단계에서는 부담이 작지만, 항상 실행되는 프로세스는 메모리와 CPU 사용 시간이 계속 누적됩니다.

현재 Railway의 아시아 리전은 싱가포르입니다. 요금은 메모리 1GB당 월 10달러, vCPU 1개당 월 20달러를 기준으로 계산하며 Pro 플랜은 월 20달러입니다. Pro 기본료는 사용량에 반영되지만 자원 사용이 늘면 추가 과금됩니다.

비용을 고정하고 싶은 팀보다는 배포 편의와 빠른 실험이 중요한 팀에 더 잘 맞습니다.

Railway 요금
Railway 리전

대안 3: Google Cloud Run

서울 리전과 관리형 실행 환경을 함께 원한다면 Google Cloud Run도 선택할 수 있습니다.

실시간 서버는 Cloud Run Service, 계속 실행되는 워커는 Cloud Run Worker Pool로 나눌 수 있습니다. 서울 리전인 asia-northeast3도 Worker Pool을 지원합니다.

다만 Cloud Run의 WebSocket은 장시간 HTTP 요청으로 취급됩니다. 요청 제한 시간을 최대 60분으로 설정할 수 있고, 시간이 지나면 클라이언트가 다시 연결해야 합니다. WebSocket 연결이 열려 있는 인스턴스는 활성 인스턴스로 계산되어 비용이 발생합니다.

현재 코드가 영구 연결을 전제로 한다면 재접속, 상태 복구, 실행 포트, 헬스 체크를 Cloud Run 방식에 맞게 조정해야 합니다. 운영 자동화와 확장이 중요해지는 시점에는 좋은 선택이지만, 초기에는 Lightsail보다 구성과 비용 계산이 복잡합니다.

Cloud Run WebSocket
Cloud Run Worker Pool

선택 기준 한눈에 보기

선택지	장점	주의할 점	적합한 상황
AWS Lightsail 서울	낮은 고정비, 서울 리전, Docker Compose 유지	서버 패치와 모니터링 필요	현재 구조를 작게 시작할 때
Render 싱가포르	WebSocket과 Worker 관리가 편함	서울 DB와 리전 간 지연	서버 운영을 최소화할 때
Railway 싱가포르	빠른 배포와 간단한 설정	사용량 비용 예측이 상대적으로 어려움	프로토타입과 빠른 실험
Cloud Run 서울	관리형 확장, 서울 리전	WebSocket 재접속과 구조 변경 필요	트래픽 증가와 자동화가 중요할 때

운영 전 점검 목록

Lightsail을 선택한다면 다음 항목을 함께 준비해야 합니다.

사용자 서비스 트래픽에는 HTTPS와 WSS용 443 포트만 공개한다.
SSH는 접근 가능한 IP를 제한하고 키 인증만 사용한다.
워커 컨테이너에는 공개 포트를 만들지 않는다.
데이터베이스와 Redis 연결에는 TLS를 사용한다.
비밀값은 이미지에 포함하지 않고 배포 환경에서 주입한다.
컨테이너 재시작 정책과 헬스 체크를 설정한다.
Docker 로그 크기와 보관 개수를 제한한다.
자동 스냅샷과 외부 상태 모니터링을 설정한다.
CPU, 메모리, 재시작 횟수, 작업 큐 길이에 알림을 건다.
배포 실패 시 이전 이미지로 돌아갈 절차를 준비한다.

한 대의 Lightsail 서버는 단일 장애 지점입니다. 초기 서비스에는 비용 대비 합리적이지만, 실시간 기능이 매출이나 핵심 업무에 직접 연결되면 두 인스턴스와 로드 밸런서 또는 관리형 플랫폼으로 이전해야 합니다.

듀오랩스가 보는 관점

초기 서비스의 배포 플랫폼은 가장 기능이 많은 제품보다 현재 코드와 운영 역량에 잘 맞는 제품을 선택하는 편이 좋습니다.

일로와 정도의 초기 규모라면 AWS Lightsail 서울 2GB에서 시작하고, 이미지 처리와 메모리 지표를 본 뒤 4GB로 올리는 방법이 현실적입니다. 장애 대응보다 관리 편의가 더 중요하다면 Render, 서울 리전과 관리형 확장이 필요해지는 시점에는 Cloud Run을 검토할 수 있습니다.

핵심은 처음부터 완벽한 플랫폼을 고르는 일이 아닙니다. 워커와 실시간 서버를 데이터베이스에서 분리하고, 다시 배포할 수 있게 만들고, 확장 시점을 판단할 지표를 확보하는 것이 먼저입니다.