무료 티어로 운영하다 사라진 DB를 Neon으로 옮기기까지

지금까지는 orbithall을 어떻게 만들었는지 다뤘다. 이번에는 어디에 올려 어떻게 운영했는지를 다룬다. 무료 인프라로 첫 배포를 하고, 쓰던 DB가 사라져 옮기기까지의 이야기다. 마지막 에이전틱 코딩 노트에는 코딩 에이전트인 Claude Code와 오랜만에 다시 연 프로젝트를 어떻게 이어 갔는지 적는다.

첫 배포: Render와 Supabase

기획과 개발에서는 서비스로서 제공할 수 있는 사양을 의도했지만, 사용처가 나 한 사람뿐인 초기 단계에서 비용을 들일 만큼의 욕심이 있던 프로젝트는 아니었다. 그래서 처음부터 무료로 쓸 수 있는 조합을 골랐다.

구성	서비스	무료 조건
API 서버	Render (싱가포르)	15분 동안 요청이 없으면 잠듦
DB	Supabase (서울)	1주일 동안 쓰지 않으면 일시 정지, 저장 공간 500MB

Railway는 30일 체험만 무료였고, Fly.io는 무료 플랜이 없었다. Supabase는 표준 PostgreSQL이라 나중에 옮기더라도 접속 주소(DATABASE_URL)만 바꾸면 된다는 점이 좋았다.

Render는 main 브랜치에 코드가 들어오면 Docker 이미지를 새로 빌드해 배포한다. 2편에서 다룬 것처럼 컨테이너가 시작할 때 마이그레이션이 적용되니, 배포 과정에서 DB 스키마를 따로 챙길 일이 없다.

무료 티어의 조건들

무료에는 조건이 붙는다. Render 무료 서버는 15분 동안 요청이 없으면 잠들고, 잠든 뒤의 첫 요청은 서버가 깨어나느라 수십 초가 걸린다. 블로그 독자가 댓글창을 열었는데 한참 빈 화면만 보게 되는 셈이다. 그래서 Better Stack이라는 모니터링 도구로 서버의 헬스체크 주소를 주기적으로 호출해, 잠들 틈을 주지 않도록 했다.

Supabase도 같은 방식으로 버텨 보려 했다. DB까지 조회하는 헬스체크(/health/db)를 따로 만들어 주기적으로 호출했지만, Supabase는 이 정도 접속을 프로젝트를 쓰고 있다는 활동으로 인정해 주지 않았다.

그러다 한동안 orbithall에 손을 놓았다. 그사이 Supabase는 오래 쓰지 않은 프로젝트를 정리했고, DB가 통째로 사라졌다. 다행히 쌓인 댓글이 거의 없어서 잃은 것은 많지 않았다.

이전: 비용을 알아보고, 무료로 타협

다시 작업을 시작하면서 처음엔 무료에서 벗어날 생각이었다. 컨테이너에 볼륨을 붙여 DB와 백엔드를 한곳에서 돌리려 했다. 그런데 Cloudflare에 정적 사이트를 올리는 것처럼 프런트엔드 인프라를 쓰는 것과 달리, 백엔드 인프라는 비용이 꽤 들었다. 막상 금액을 보니 다시 무료 티어로 타협하고 싶어졌다.

그렇게 고른 곳이 Neon이다. 역시 표준 PostgreSQL이라 코드는 접속 주소만 바꾸면 됐고, Neon 전용 SDK나 도구는 쓰지 않았다. 결제 수단을 등록하지 않아서, 무료 한도를 넘으면 요금이 나가는 대신 쓰기나 연산이 멈춘다. 모르는 사이 비용이 나가는 것보다 멈추는 쪽이 낫다고 봤다. 리전은 Render와 같은 싱가포르로 맞췄다.

옮길 데이터가 없었으니 새 DB에서 새로 시작했다. 블로그에 심어 둔 사이트 API 키는 그대로 다시 등록해서, 블로그 코드는 바꾸지 않아도 됐다.

Neon의 새 DB는 PostgreSQL 18이었다. 운영 DB를 로컬에 맞춰 16으로 다시 만드는 대신, 로컬 개발 환경을 18로 올렸다. 더 나은 버전이 나왔다면 도입을 고민해야 한다고 생각한다. 오래된 것은 그것대로 잠재적인 위험을 안고 있고, (새것도 마찬가지지만, 검증을 거친) 새것은 오래된 것보다 낫다는 주의이기 때문이다.

돌아보면 이번 이전도 결국, 비용을 내고 백엔드 인프라를 직접 쓰는 시점을 미룬 유예에 가깝다. 사용처가 늘어나거나 무료 조건이 다시 바뀌면, 그때는 비용을 들이는 쪽을 진지하게 검토하게 될 것 같다.

에이전틱 코딩 노트

오랜만에 다시 연 프로젝트를 이어 가는 데 에이전트의 도움이 컸다. 다시 시작하며 던진 첫 질문이 "배포도 했던가?"였다. 에이전트가 저장소와 배포 기록, 설정을 훑어 지금 상태를 정리해 주니, 몇 달 전의 기억을 금방 되찾을 수 있었다. 사람의 기억을 보조해 주는 느낌이었다.

대신 처음 겪는 일도 있었다. 예전 작업을 함께한 에이전트와의 대화 기록이 남아 있지 않았다. Claude Code는 기본 설정에서 오래된 대화 기록을 정리하는데, 그전까지는 늘 이어서 작업해 왔기 때문에 기록이 사라질 만큼 오래 쉰 적이 없었다. 대화는 사라졌지만, 1편에서 이야기한 작업 문서와 결정 기록은 저장소에 그대로 남아 있었다.

Neon 콘솔은 에이전트에게 설정을 맡기라며 npm 패키지로 된 도구를 권했지만 쓰지 않았다. 요즘 많은 서비스가 AI 기능을 들여와 가치를 주려 하는데, 이 기능은 들이는 것 대비 얻는 게 분명하지 않았다. 게다가 이런 도구는 대부분 TypeScript와 JavaScript를 중심으로 만들어져 있어서, Go로 만든 이 프로젝트와는 잘 맞지 않았다.

대신 이번 이전에서 정한 기준은 에이전트의 메모리에 남겨 두었다. 개인 프로젝트에는 월 과금을 고려하지 않고, 과금 대신 멈추는 무료 플랜을 선호하며, 벤더 전용 도구 대신 표준 인터페이스만 쓴다는 것이다. 다음에 인프라를 고를 때 에이전트가 같은 기준에서 출발하도록 하기 위해서다.

다음 편에서는 시리즈를 마무리하며 앞으로 만들어 갈 기능들과, 에이전트와 일하는 방식이 어떻게 달라졌는지를 돌아본다.

저장소

• API 서버: june20516/orbithall