웹 인프라7분
Vercel 재배포 직후 500: 재배포 탓인지 값 탓인지 가르는 순서
운영에 올릴 새 커밋은 없었습니다. main 과 develop 이 같은 커밋이었고, 마지막 운영 배포는 그 커밋이 올라간 지 4분 뒤에 만들어져 있었습니다. 그래도 한 번 다시 올려 두자고 해서 vercel redeploy 로 같은 배포를 다시 만들었습니다. 2분 만에 Ready 가 떴고 도메인에 붙었습니다.
운영에 올릴 새 커밋은 없었습니다. main 과 develop 이 같은 커밋이었고, 마지막 운영 배포는 그 커밋이 올라간 지 4분 뒤에 만들어져 있었습니다. 그래도 한 번 다시 올려 두자고 해서 vercel redeploy 로 같은 배포를 다시 만들었습니다. 2분 만에 Ready 가 떴고 도메인에 붙었습니다.
환경변수의 정본을 볼트로 옮기는 작업이었습니다. 값을 한곳에 모으고, 거기서 배포처로 밀고, 어긋나면 대조로 잡는 구조입니다. 마지막 단계가 운영이었습니다.
Vercel 서울 리전에서 도는 Next.js 앱에 붙일 관리형 Postgres 를 고르는 중이었습니다. 처음에는 두 서비스의 가격표를 나란히 놓고 비교하면 끝날 일이라고 생각했습니다. 실제로는 가격이 아니라, 나중에 되돌릴 수 없는 것들에서 갈렸습니다.
Supabase와 Neon을 처음 보면 둘 다 관리형 PostgreSQL 서비스처럼 보입니다. 실제로 두 서비스 모두 표준 PostgreSQL 연결 방식과 SQL 생태계를 활용합니다. 그래서 기능표만 훑으면 가격과 무료 용량 정도만 비교하게 됩니다.
운영 중인 서비스의 데이터베이스를 온프레미스에서 Supabase로 옮기는 중입니다. 지난번에 1단계로 앱을 무상태화했고, 이번이 2단계인 스키마 복제입니다. 프로젝트를 만들고 접속 문자열을 받아 prisma migrate deploy 한 줄 돌리면 끝나는 일이라고 생각했습니다. 그 전에 빈 데이터베이스에 한 번 리허설을…
저는 이전 계획표에 번역과 이미지 변환을 기존 서버 유지로 적어뒀습니다. 둘 다 백그라운드 작업이니 상시 실행되는 서버가 필요할 것이라고 생각했습니다.
무료 티어에서 걸린 문제들을 Pro 요금제로 올리면 몇 개가 사라질까. 세어보니 용량 문제는 전부 지워졌는데 블로커는 오히려 하나 늘었다. 돈으로 사는 것과 못 사는 것의 경계에 대한 기록.
잘 돌아가던 개인 프로젝트를 Vercel과 Supabase 무료 티어로 옮길 수 있을지 검토했다. 요금제 한도표부터 보는 대신 코드를 먼저 읽었고, 진짜 제약은 숫자가 아니라 실행 모델 쪽에 있었다.
Supabase를 처음 접하면 관리형 PostgreSQL 서비스로 이해하기 쉽습니다. 실제로 PostgreSQL은 Supabase의 중심이지만, 전체 제품은 데이터베이스보다 훨씬 넓은 범위를 다룹니다.
온프레미스에서 서비스를 운영하면 애플리케이션, 데이터베이스, Redis, WebSocket 서버와 백그라운드 워커를 한 네트워크 안에 둘 수 있습니다. 프로세스를 계속 띄워두기도 쉽습니다. setInterval로 10초마다 데이터베이스를 확인하는 코드도 일단은 잘 동작합니다.
백업이 성공했다는 알림은 데이터를 되살릴 수 있다는 보증이 아니다. 파일이 손상됐거나, 필요한 암호화 키가 없거나, 복구 순서를 아무도 모르면 백업은 있어도 업무를 재개할 수 없다. 사내 시스템의 백업 설계는 저장 횟수보다 복구 목표와 복원 시험에서 시작해야 한다.
사내 시스템은 직원 수가 적다고 해서 항상 가볍지 않다. 20명이 쓰는 문서 변환 시스템은 100명이 쓰는 단순 결재 시스템보다 더 많은 CPU와 저장 공간을 요구할 수 있다. 그래서 배포 구조는 인원수보다 동시 접속, 요청 시간, 파일 크기, 실시간 연결 수, 장애 허용 시간을 기준으로 정해야 한다.
웹과 모바일 앱을 함께 제공하는 서비스를 배포할 때는 화면을 올리는 비용만 계산해서는 안 됩니다. 데이터베이스, 캐시, 실시간 통신, 백그라운드 작업, 이미지 저장소까지 포함해야 실제 운영비에 가까워집니다.
사내 시스템을 만들 때 가장 자주 나오는 질문 중 하나는 "직원 수가 늘어나면 서버 비용도 같은 비율로 늘어나는가"입니다. Vercel과 Supabase 조합에서는 직원 수보다 배포를 관리하는 개발자 수, 동시에 발생하는 요청, 데이터베이스 쿼리와 배치 작업이 비용에 더 큰 영향을 줍니다.
사내 시스템을 새로 만들 때 인프라를 처음부터 크게 잡아야 할지 고민하게 됩니다. 특히 Supabase Pro를 검토하면 Micro와 Small의 월 비용 차이는 크지 않지만, 어떤 기준으로 선택해야 하는지는 가격표만 보고 판단하기 어렵습니다.
온프레미스 Docker로 돌아가던 서비스를 Vercel + Supabase로 옮기는 중이었습니다.