Supabase 서버 이전 비용 100만 원, 데이터만 옮기면 끝날까

Supabase 프로젝트를 다른 서버로 옮기고 100만 원을 받았다면, 그 금액은 비싼 걸까. 답은 이전 대상이 PostgreSQL 데이터인지, 로그인과 파일까지 포함한 서비스 전체인지에 달려 있다. 실제 작업 순서와 실패 시 책임을 나눠 견적의 경계를 살펴봤다.

먼저 ‘서버 이전’의 목적지를 구분해야 한다

커뮤니티에서는 기존 개발 견적보다 훨씬 적은 100만 원을 받고 AI의 도움으로 이전했다는 경험이 공유됐다. 일부는 덤프를 옮기는 작업치고는 큰 금액이라고 봤다. 다른 쪽에서는 데이터가 어긋났을 때 이를 고치는 시간까지 감안해야 한다고 봤다. 어느 의견도 이전 범위가 정해지기 전에는 단가의 근거가 되기 어렵다.

목적지가 일반 PostgreSQL이라면 데이터베이스를 복원한 뒤에도 앱이 사용하던 Supabase 기능을 따로 살펴봐야 한다. Supabase 공식 Docker 구성은 PostgreSQL 외에 Auth, REST API, Realtime, Storage, Edge Runtime 등을 함께 운영한다. PostgreSQL 컨테이너 하나를 띄우는 일과 Supabase 전체를 자체 호스팅하는 일은 다르다. (supabase.com)

예를 들어 앱이 SQL로 데이터만 읽는다면 데이터베이스 이전에 가까울 수 있다. 브라우저에서 Supabase 인증, 파일 URL, 실시간 구독을 사용한다면 연결 지점도 바뀐다. 견적서에서 말하는 ‘완료’가 어느 상태를 가리키는지부터 달라진다.

데이터베이스는 세 파일로 내보내고 시험 복원한다

방에서 제안된 첫 단계는 데이터를 검토한 뒤 로컬 Docker PostgreSQL로 옮겨보는 방식이었다. 시험 복원은 유용하지만, 운영 목적지가 일반 PostgreSQL인지 자체 호스팅 Supabase인지 먼저 결정해야 한다. 두 환경의 기본 스키마와 서비스 구성이 같다고 가정할 수 없기 때문이다.

자체 호스팅 Supabase로 옮긴다면 공식 가이드에 구체적인 순서가 나와 있다. 관리형 프로젝트의 연결 정보를 확보하고 Supabase CLI로 역할 roles.sql, 구조 schema.sql, 데이터 data.sql을 각각 만든다. 새 Docker 인스턴스에서 필요한 확장을 확인한 다음 psql로 세 파일을 순서대로 복원한다. 가이드는 단일 트랜잭션과 오류 시 중단 옵션을 사용하고, 복원 뒤 주요 테이블의 행 수와 확장을 확인한다. (supabase.com)

내보내기 도구도 확인해야 한다. Supabase CLI의 기본 db dump에는 데이터와 사용자 정의 역할이 들어 있지 않아 별도 옵션이 필요하다. 공식 가이드는 CLI가 Supabase 내부 객체를 걸러낸다고 설명한다. 원본 데이터베이스에 pg_dump를 곧바로 실행하면 복원 중 권한 오류가 날 수 있다. (supabase.com)

시험 결과물은 ‘명령이 성공했다’는 기록만으로는 부족하다. 핵심 테이블의 행 수와 사용 중인 확장, 로그인에 필요한 데이터가 목적지에 있는지를 기록해야 한다. 관리형 환경과 자체 호스팅 환경의 버전 차이로 복원 SQL이 실패할 수도 있다. 공식 문서 역시 운영 이전에 테스트 인스턴스에서 호환성을 확인하라고 권한다. (supabase.com)

파일과 인증을 빼면 같은 서비스가 아니다

Supabase 백업에는 Storage 객체의 실제 파일이 포함되지 않는다. 데이터베이스에 파일 관련 메타데이터가 있어도 파일 자체는 별도로 옮겨야 한다. Supabase의 자체 호스팅 이전 가이드는 Edge Functions 복사 역시 데이터베이스 복원 범위 밖으로 둔다. (supabase.com)

파일을 쓰는 프로젝트라면 버킷과 객체 이전을 작업 목록에 넣어야 한다. Supabase가 안내하는 방법은 목적지에 버킷을 준비하고 S3 프로토콜을 통해 rclone으로 객체를 복사하는 것이다. 파일을 내려받아 자체 호스팅 서버의 Storage 폴더에 그대로 놓는 방식은 지원되는 이전 절차가 아니다. 복사 후에는 양쪽의 객체 수와 크기를 비교하고 실제 파일을 열어 확인한다. (supabase.com)

인증 데이터도 행 수만 맞는다고 끝나지 않는다. 공식 문서에 따르면 auth.users는 데이터베이스 덤프에 포함될 수 있다. 그러나 관리형 프로젝트와 새 인스턴스의 JWT 비밀값이 다르면 기존 토큰은 유효하지 않다. 사용자는 다시 로그인해야 한다. 소셜 로그인 설정, 이메일 발송 설정, 리디렉션 주소도 별도로 맞춰야 한다. (supabase.com)

그래서 ‘사용자 데이터 이전 완료’와 ‘사용자가 평소처럼 로그인 가능’은 서로 다른 검수 항목이다.

100만 원에 포함할 검증은 어디까지인가

가격을 가르는 부분은 복사 명령보다 전환 계획일 수 있다. 쓰기가 계속 발생하는 서비스를 한 시점의 덤프로 옮긴다면 추출 후 생긴 변경분을 어떻게 처리할지 정해야 한다. 점검 시간 동안 쓰기를 멈출지, 변경분을 다시 동기화할지, 문제가 생기면 어느 시점으로 돌아갈지 합의해야 한다. 이 계획 없이 구 서버 연결만 끊으면 데이터가 빠질 위험이 있다.

전환 전에는 주요 화면의 읽기·쓰기, 파일 접근, 로그인, 권한을 새 환경에서 시험해야 한다. 특히 RLS는 테이블 접근 권한과 행별 정책을 함께 확인해야 한다. Supabase 문서는 노출된 스키마의 테이블에 RLS를 설정하고 허용·거부 동작을 테스트하도록 안내한다. 반대로 일반 PostgreSQL만 남기는 이전이라면 앱의 API와 인증을 누가 대체할지도 결정해야 한다. (supabase.com)

직접 이전한 사람들 사이에서도 데이터베이스 밖의 기능을 하나씩 확인해야 한다는 반응이 있다. 자체 호스팅으로 운영비를 줄이더라도 업데이트와 백업을 직접 맡아야 하는 부담이 있다는 의견도 나온다. 이런 반응이 특정 프로젝트의 비용을 증명하지는 않지만, 검수 항목을 정할 때 참고할 만하다.

100만 원의 적정성은 이전 범위에 따라 달라진다. 다만 작은 프로젝트의 일회성 데이터 복원과 인증·Storage·전환·복구 대응을 포함한 이전에 같은 가격표를 붙일 수는 없다. 개인 개발자나 작은 팀이 외주 범위를 적을 때도 ‘무엇을 옮긴다’보다 ‘무엇이 정상 작동해야 완료인가’를 기준으로 삼아야 분쟁을 줄일 수 있다. 이번 비용 논쟁에서 남는 질문은 금액 자체보다 이전 후 장애까지 누가 언제 책임지기로 했느냐이다.