웹 인프라26분
온프레미스 Next.js 서비스를 Vercel과 Supabase로 옮기기
온프레미스에서 서비스를 운영하면 애플리케이션, 데이터베이스, Redis, WebSocket 서버와 백그라운드 워커를 한 네트워크 안에 둘 수 있습니다. 프로세스를 계속 띄워두기도 쉽습니다. setInterval로 10초마다 데이터베이스를 확인하는 코드도 일단은 잘 동작합니다.
온프레미스에서 서비스를 운영하면 애플리케이션, 데이터베이스, Redis, WebSocket 서버와 백그라운드 워커를 한 네트워크 안에 둘 수 있습니다. 프로세스를 계속 띄워두기도 쉽습니다. setInterval로 10초마다 데이터베이스를 확인하는 코드도 일단은 잘 동작합니다.
쇼핑몰은 보기 좋은 상품 페이지 하나로 완성되지 않습니다. 상품 옵션, 재고, 결제, 취소·교환·반품, 배송, 회원, 쿠폰, 정산과 고객 문의가 연결되어야 합니다. 그래서 쇼핑몰 플랫폼은 디자인보다 판매 후 운영 흐름을 먼저 비교해야 합니다.
회사 홈페이지를 만들 때 반드시 Next.js 같은 개발 프레임워크가 필요한 것은 아닙니다. 회사 소개, 서비스 설명, 구축 사례와 문의 접수가 중심이라면 홈페이지 빌더나 CMS가 더 빠르고 운영하기 쉬울 수 있습니다.
웹사이트를 만들 때 자주 듣는 이름으로 Vercel, Cloudflare Pages, Netlify가 있습니다. 여기에 AWS나 직접 관리하는 서버까지 더하면 선택지가 너무 많아 보입니다. 하지만 먼저 구분할 것이 있습니다. 이들은 완성된 홈페이지를 만들어 주는 서비스가 아니라, 개발자가 작성한 코드를 빌드하고 실행하는…
GitHub에 커밋을 푸시하면 자동으로 서비스가 배포됩니다. 겉으로 보면 GitHub Actions의 Self-hosted Runner와 Vercel은 똑같아 보입니다.
코드를 수정하고 로컬에서 잘 동작하는 것까지 확인했습니다. 이제 아래처럼 GitHub에 올립니다.
웹사이트는 화면과 기능이 완성됐다고 바로 공개할 수 있는 상태가 되는 것은 아닙니다. 실제 사용자가 느끼는 속도, HTTP 보안 헤더, HTTPS 설정, 키보드 접근성, 구조화 데이터, DNS 설정은 서로 다른 문제입니다.
랜딩페이지를 만들 때도 백엔드가 필요하다고 생각하는 경우가 있다. 반대로 로그인, 예약, 결제와 파일 업로드가 있는 서비스를 단순 홈페이지처럼 구성하려는 경우도 있다.
한 애플리케이션을 여러 회사가 함께 사용하는 SaaS에서는 로그인보다 테넌트 경계가 더 중요하다. 사용자가 정상적으로 로그인했더라도 다른 회사의 계약, 직원, 파일, 검색 결과를 볼 수 있다면 인증은 성공했지만 데이터 격리는 실패한 것이다.
사내 시스템은 외부 고객 서비스보다 사용자가 적다는 이유로 공개 전 점검이 짧아지기 쉽다. 하지만 결재, 계약, 인사, 회계처럼 업무의 기준이 되는 시스템은 한 번의 권한 오류나 데이터 손실도 실제 업무 중단으로 이어진다.
사내 시스템의 좋은 아키텍처는 가장 큰 서버나 가장 복잡한 기술 조합이 아니다. 현재 업무를 무리 없이 지원하고, 문제가 생겼을 때 되돌릴 수 있으며, 사용자가 늘면 필요한 부분만 확장할 수 있는 구조다.
월 10달러 안팎의 VPS를 보면 Vercel, Supabase 같은 관리형 서비스를 합친 것보다 훨씬 저렴해 보인다. 실제로 안정적인 부하가 있고 서버를 운영할 사람이 있다면 VPS가 경제적일 수 있다. 하지만 인스턴스 가격만 비교하면 백업, 저장 공간, 전송량, 보안 패치, 장애 대응 시간이 빠진다.
클라우드 비용은 서버 한 대의 월정액처럼 움직이지 않는다. 트래픽, 함수 실행 시간, DB 용량, 로그, 파일 전송, 실시간 연결이 각각 늘어난다. 작은 코드 실수나 공개된 API 키 하나가 짧은 시간에 사용량을 키울 수도 있다.
빠른 롤백은 사람이 명령어를 빨리 입력하는 능력이 아니다. 이전 버전이 무엇인지 알고, 같은 산출물을 다시 실행할 수 있고, DB가 이전 코드와 호환되도록 미리 설계한 결과다. 준비 없이 배포한 뒤 5분 안에 되돌리겠다는 목표는 지키기 어렵다.
브라우저가 파일을 애플리케이션 서버에 보내고, 서버가 다시 객체 저장소로 전달하는 방식은 이해하기 쉽다. 하지만 파일이 커지면 서버는 같은 데이터를 두 번 전송하고, 메모리와 실행 시간을 오래 점유한다. 서버리스 환경의 본문 크기 제한에도 걸리기 쉽다.
보고서 생성, 대량 메일, 이미지 변환, 외부 API 수집을 일반 API 요청 안에서 끝내려 하면 처음에는 단순해 보인다. 하지만 실행 시간이 길어질수록 브라우저, 프록시, 서버리스 함수 중 하나가 먼저 연결을 끊을 가능성이 커진다. 사용자가 다시 누르면 같은 작업이 중복 실행되기도 한다.
실시간 기능이 필요하다는 말은 요구사항이 아니다. 사용자가 몇 초 늦게 봐도 되는지, 서버에서 브라우저로만 보내면 되는지, 양쪽이 계속 메시지를 주고받아야 하는지부터 정해야 한다. 이 질문에 답하면 Polling, SSE, WebSocket, Supabase Realtime 중 선택이 쉬워진다.
모든 장애를 미리 예측할 수는 없다. 대신 사용자가 먼저 알려 주기 전에 이상을 발견하고, 원인을 좁힐 자료를 남기고, 같은 장애가 반복되지 않게 만들 수는 있다. 소규모 서비스의 모니터링은 비싼 도구보다 적은 수의 정확한 신호에서 시작하는 편이 낫다.
백업이 성공했다는 알림은 데이터를 되살릴 수 있다는 보증이 아니다. 파일이 손상됐거나, 필요한 암호화 키가 없거나, 복구 순서를 아무도 모르면 백업은 있어도 업무를 재개할 수 없다. 사내 시스템의 백업 설계는 저장 횟수보다 복구 목표와 복원 시험에서 시작해야 한다.
VPS를 만들면 몇 분 안에 공인 IP가 생기고 인터넷에서 접속할 수 있다. 편리하지만 그 순간부터 자동 스캔과 로그인 시도의 대상이 된다. 애플리케이션을 올리기 전에 운영체제와 접속 경로부터 잠그는 이유다.