Supabase란 무엇인가? Organization과 Project 구조부터 시작하기

Supabase를 처음 접하면 대시보드에 로그인하자마자 Organization과 Project라는 두 단어부터 마주하게 됩니다. 둘 다 낯선 용어인데다, 이름만 보면 어느 쪽이 더 큰 단위인지 헷갈리기 쉽습니다. Supabase가 어떤 서비스인지, Organization과 Project가 각각 무엇을 담당하는지, 처음 가입하면 어떤 구조가 생기는지, 첫 프로젝트를 만든 뒤 무엇을 확인해야 하는지를 차례로 짚습니다. 비용 비교나 조직을 나눌지 말지를 판단하는 기준은 Supabase Organization과 Project에서 따로 다뤘으므로, 여기서는 처음 시작하는 사람이 구조를 이해하는 데만 집중합니다.

Supabase란 무엇인가

Supabase는 애플리케이션의 백엔드를 직접 구축하지 않고도 쓸 수 있게 해 주는 플랫폼입니다. 핵심은 PostgreSQL 데이터베이스이고, 여기에 로그인·회원 관리(Auth), 파일 저장(Storage), 데이터를 읽고 쓰는 API, 실시간 갱신(Realtime), 서버 쪽 추가 로직(Edge Functions)까지 함께 제공합니다. 직접 서버를 빌리고 데이터베이스를 설치하고 로그인 로직을 코드로 짜는 대신, Supabase가 미리 구성해 둔 이 서비스들을 가져다 쓰는 방식입니다.

Project는 기본으로 “전용 Postgres 데이터베이스(A dedicated Postgres database)“와 Auth and user management, Storage를 포함하고, 그 외에 자동 생성 API, Edge Functions, Realtime API를 함께 제공합니다. 개인 메모 앱이든 예약 관리 시스템이든, 로그인하고 데이터를 저장하고 꺼내 쓰는 구조의 앱이라면 이 기능들로 대부분의 백엔드 작업을 대신할 수 있습니다.

Supabase로 무엇을 만들 수 있을까

할 일 관리 앱 하나를 예로 들면 각 기능이 실제로 어떤 역할을 하는지 쉽게 연결됩니다.

이 기능을 모두 써야 하는 것은 아닙니다. 로그인이 필요 없는 공개 데이터만 보여 주는 앱이라면 Auth 없이 데이터베이스와 API만으로도 충분하고, 실시간 동기화가 필요 없는 앱이라면 Realtime을 켜지 않아도 됩니다. Project를 만들면 이 기능들이 미리 준비되어 있을 뿐, 전부 강제로 써야 하는 것은 아닙니다. 필요한 기능만 골라 쓰고 나머지는 그대로 두면 되므로, 처음부터 모든 기능의 설정법을 익히고 시작할 필요도 없습니다.

Supabase Organization이란

Organization은 Project를 묶는 상위 단위입니다. 공식 정의는 “프로젝트를 묶는 방법(a way to group your projects)“이고, 조직마다 멤버 구성과 결제 설정을 다르게 둘 수 있습니다.

Organization이 맡는 역할은 다음과 같습니다.

• 여러 Project를 한곳에 묶기
• 팀원을 초대하고 역할(권한)을 관리하기
• 구독 플랜(Free, Pro, Team, Enterprise)을 설정하기
• 결제 수단과 청구서를 관리하기

Organization이라는 이름 때문에 법인이나 회사 단위로만 쓰는 것이라고 생각하기 쉽지만, 개인 개발자도 Organization을 씁니다. 실제로 Supabase에 가입하면 별도로 만들지 않아도 기본 Organization이 자동으로 생기고, 많은 개인 개발자는 이 기본 Organization 하나만 계속 씁니다. Organization을 “회사”로 해석할 필요는 없고, “내 프로젝트들을 담는 그릇” 정도로 받아들이면 충분합니다.

Organization과 Project의 관계

구조를 그림으로 보면 더 분명합니다. 아래는 개념을 설명하기 위한 예시 구조이며, 실제 계정의 프로젝트 이름이나 개수를 나타낸 것은 아닙니다.

반드시 구분해야 할 점은 다음과 같습니다.

• Organization: 팀·결제·플랜을 관리하는 단위
• Project: 실제 앱의 백엔드 리소스(Postgres, Auth, Storage, API 등)를 가진 단위
• 하나의 Organization 아래 여러 Project를 둘 수 있습니다.
• Project마다 데이터베이스와 Auth, Storage가 따로 생깁니다. 한 Project의 사용자나 데이터가 다른 Project로 자동 공유되지 않습니다.
• Organization은 플랜을 하나만 가지므로, 같은 Organization에 속한 Project는 모두 같은 플랜(Free, Pro, Team, Enterprise 중 하나)의 적용을 받습니다. Organization마다 청구도 따로 이뤄집니다.

Organization은 왜 필요한가

세 가지 상황으로 나눠 보면 Organization을 몇 개 둬야 할지 감이 잡힙니다.

혼자 앱 하나를 운영하는 경우

기본으로 생긴 Organization 하나에 Project 하나만 있으면 됩니다. 가장 단순한 구성이고, 대부분의 입문자는 이 상태에서 시작합니다.

서로 다른 앱 두 개를 운영하는 경우

기존 Organization에 Project를 하나 더 추가하면 됩니다. 두 앱은 각자 독립된 데이터베이스와 Auth를 가지므로, 한쪽 앱의 사용자 정보가 다른 쪽에 섞이지 않습니다. Organization을 새로 만들 필요는 없습니다.

고객사나 다른 팀과 함께 작업하는 경우

결제를 따로 받아야 하거나, 팀마다 접근 권한을 분리해야 한다면 별도 Organization이 유리할 수 있습니다. 다만 이 판단에는 비용과 프로젝트 이전 조건 같은 더 자세한 기준이 필요하므로 여기서는 짚기만 하고, 자세한 비교는 Supabase Free vs Pro로 넘깁니다.

Organization 안의 역할(멤버 권한)

여러 사람이 같은 Organization에서 작업한다면 역할 구분이 필요합니다. Supabase의 Organization 역할은 다섯 가지입니다.

Read-Only라고 해서 모든 값이 가려지는 것은 아닙니다. 공식 권한표에는 Read-Only 역할도 Edge Functions의 Secrets는 조회할 수 있다는 각주가 있습니다. 다만 API 키(service key, anon key)와 JWT Secret 조회, 데이터베이스 암호 재설정은 Read-Only에게 막혀 있습니다. 협업자에게 Read-Only를 줄 때도 Edge Functions Secrets에 민감한 값을 넣어 두지 않았는지 함께 확인하는 것이 안전합니다.

Organization 수준에서 준 역할은 지금 있는 Project뿐 아니라 앞으로 새로 만들 Project에도 똑같이 적용됩니다. 특정 Project에만 권한을 주고 싶다면 Team·Enterprise 플랜에서만 쓸 수 있는 프로젝트 범위 역할이 따로 있습니다. 혼자 개발한다면 본인이 Owner 하나로 충분하고, 역할 구분은 팀원을 초대하는 시점에 고려하면 됩니다.

외주 개발자나 일부 기능만 맡기는 협업자를 들일 때는 Developer 역할이 쓸모가 있습니다. Developer는 Organization 설정은 읽기만 할 수 있지만 Project 안의 테이블을 만들고 데이터를 다루는 실무는 그대로 할 수 있어서, 결제 정보나 조직 설정 권한을 넘기지 않고도 실제 작업을 맡길 수 있는 구성이 됩니다. Owner·Administrator처럼 결제와 설정까지 바꿀 수 있는 역할은 꼭 필요한 사람에게만 주는 것이 안전합니다.

처음 Supabase를 시작하는 방법

1. Supabase 공식 사이트(supabase.com)에 접속합니다.
2. GitHub 계정 등으로 가입하거나 로그인합니다.
3. 로그인하면 기본 Organization이 자동으로 준비되어 있습니다. 필요하면 이 화면에서 Organization을 추가로 만들 수도 있습니다.
4. 대시보드에서 새 프로젝트 만들기를 선택합니다.
5. 프로젝트 이름을 정합니다.
6. 프로젝트에 쓸 데이터베이스 암호와 리전(서버 위치) 등 화면에 표시되는 필수 항목을 입력합니다. 리전은 사용자와 가까운 위치를 고르는 것이 응답 속도에 유리하고, 기존 프로젝트의 리전을 제자리에서 바꾸는 기능은 없으므로 신중하게 고릅니다.
7. 생성을 누르면 몇 분 안에 프로젝트가 준비됩니다.
8. 프로젝트 대시보드에서 Database·Auth·Storage·API 같은 메뉴를 찾아 둘러봅니다.

데이터베이스 암호처럼 입력해야 하는 민감한 값은 글이나 스크린샷에 그대로 노출하지 않아야 하므로, 위 화면은 입력 전 빈 상태만 보여줍니다. 실제로 입력할 때는 화면에 표시되는 안내를 그대로 따르면 됩니다.

프로젝트를 만든 뒤 무엇을 확인할까

프로젝트가 만들어지면 다음을 확인할 수 있습니다.

• 프로젝트 URL: 이 프로젝트의 API를 호출할 때 쓰는 고유 주소입니다.
• 공개용 키와 비밀 키: Supabase는 공개용으로 쓰는 Publishable key와 서버에서만 쓰는 Secret key라는 새 키 유형을 쓰고 있습니다. 긴 JWT 문자열이던 예전의 anon 키(공개용)·service_role 키(서버 전용)와 달리, 새 키는 짧은 문자열(sb_publishable_..., sb_secret_...)입니다. anon·service_role은 레거시 키로 남아 있고, Supabase는 2026년 말까지 이 레거시 키를 단계적으로 폐지할 예정입니다. 공개 키는 앱 코드에 들어가도 괜찮도록 설계돼 있지만, 비밀 키는 절대 브라우저나 클라이언트 코드에 넣으면 안 됩니다.

공개 키와 비밀 키는 데이터베이스 안에서 서로 다른 Postgres 역할로 연결됩니다. 로그인하지 않은 상태로 공개 키를 쓰면 anon 역할, 로그인한 사용자가 공개 키를 쓰면 authenticated 역할이 되고, 비밀 키는 모든 RLS 정책을 우회하는 service_role 역할로 연결됩니다(테이블 자체의 권한이 없으면 비밀 키로도 오류가 날 수 있습니다). 비밀 키는 브라우저 요청의 User-Agent 헤더로도 걸러지지만, 이 차단에만 기대지 말고 애초에 서버 환경 변수 밖으로 내보내지 않는 것이 원칙입니다.

• Database 화면: 테이블을 만들고 데이터를 확인하는 화면입니다.
• Auth 화면: 가입한 사용자 목록과 로그인 설정을 관리합니다.
• Storage 화면: 업로드된 파일을 버킷 단위로 관리합니다.

각 Project의 이 설정과 데이터는 서로 독립적입니다. Project A에서 만든 테이블이나 가입한 사용자가 Project B에 나타나는 일은 없습니다. 프로젝트를 여러 개 만들수록 “이 작업을 지금 어느 프로젝트에서 하고 있는지”를 놓치지 않는 것이 중요합니다.

리전은 왜 신중하게 골라야 할까

프로젝트를 만들 때 고르는 리전은 Supabase 서버가 실제로 돌아가는 물리적 위치입니다. 사용자와 서버 사이의 거리가 멀수록 요청마다 왕복 지연이 늘어나므로, 한국 사용자 대상 서비스라면 가까운 아시아 리전을 고르는 것이 응답 속도에 유리합니다.

이 선택이 신중해야 하는 이유는 되돌리기가 어렵기 때문입니다. 기존 프로젝트의 리전을 제자리에서 바꾸거나, 조직 간 Project Transfer로 리전을 바꾸는 방법은 없습니다. 리전을 바꾸려면 원하는 리전에 새 프로젝트를 만들고 그 프로젝트로 데이터를 마이그레이션하는 방법뿐입니다. 개발 초기에 아무 리전이나 고르고 넘어갔다가 서비스를 열 때쯤 문제를 깨닫는 경우가 있으므로, 테스트용 프로젝트라도 실제 서비스할 지역을 염두에 두고 리전을 고르는 습관을 들이는 편이 낫습니다.

앱 코드와 연결하기

프로젝트가 준비되면 실제 앱 코드에서 이 프로젝트에 접속해야 합니다. Supabase는 JavaScript(React, Next.js 등), Flutter, Swift를 비롯한 여러 언어·프레임워크별 공식 클라이언트 라이브러리를 제공하고, 각 조합마다 시작 가이드를 따로 두고 있습니다. 어떤 언어를 쓰든 기본 흐름은 같습니다.

1. 해당 언어의 Supabase 클라이언트 라이브러리를 설치합니다.
2. 프로젝트 URL과 공개 키(Publishable key, 레거시 anon)로 클라이언트를 초기화합니다.
3. 이 클라이언트로 데이터베이스 읽기·쓰기, 로그인, 파일 업로드 같은 기능을 호출합니다.

이 세 단계만 보면 간단해 보이지만, 2단계에서 쓰는 키가 공개 키인지 비밀 키인지를 혼동하지 않는 것이 중요합니다. 프런트엔드 코드(브라우저에서 실행되는 코드)에는 반드시 공개 키만 넣어야 하고, 비밀 키는 프런트엔드 코드가 아니라 서버 환경 변수에만 둡니다. 이 구분을 처음부터 지키면 이후 보안 사고를 상당 부분 예방할 수 있습니다. 어떤 프레임워크를 쓰든 이 세 단계와 두 키의 구분은 똑같이 적용되므로, 다른 언어로 옮겨 가더라도 새로 익혀야 할 개념은 아닙니다.

첫 프로젝트에서 반드시 알아야 할 보안

프로젝트를 만들었다고 데이터가 저절로 안전해지는 것은 아닙니다. 로그인(Auth)은 “누가 요청했는지”를 확인할 뿐이고, “그 사람이 어떤 데이터를 볼 수 있는지”는 데이터베이스가 따로 정해야 합니다. 이 역할을 하는 것이 Row Level Security(RLS)입니다.

RLS는 “데이터베이스 안에서 실행되는 세밀한 권한 규칙”입니다. 노출된 스키마에 있는 테이블에 RLS가 꺼져 있으면 그 테이블에 권한이 있는 어떤 역할이든 읽고 쓸 수 있고, RLS를 켜고 정책을 만들기 전까지는 공개 키로 API를 호출해도 데이터에 접근할 수 없습니다. 즉 RLS는 켜 두기만 해도 기본적으로 더 안전한 쪽으로 동작합니다.

입문 단계에서 기억해 둘 것은 세 가지입니다. 테이블을 만들면 RLS를 켜는 것을 기본값으로 생각하고, 공개 키(Publishable key, 레거시 anon)는 RLS 정책의 적용을 받으므로 클라이언트 코드에 넣어도 되지만, 비밀 키(Secret key, 레거시 service_role)는 모든 RLS를 우회하므로 서버 코드 밖으로 절대 내보내면 안 됩니다. 실제로 RLS 정책을 작성하고 검증하는 절차는 Supabase RLS 보안 가이드로 넘깁니다.

Supabase는 무료로 사용할 수 있을까

Free 플랜은 “시작하고 플랫폼을 둘러보는 것을 돕는” 성격의 플랜이고, 기본으로 무료 프로젝트 2개를 제공합니다. 여기서 흔히 오해하는 부분이 있는데, 이 2개 한도는 Organization마다 적용되는 것이 아니라 “Owner 또는 Administrator로 속한 모든 Organization을 합친 사람 기준”으로 적용됩니다. 같은 Organization 안에 Owner나 Administrator가 여러 명이라면 그 멤버들의 무료 프로젝트 사용량도 함께 합산되므로, 다른 멤버가 이미 한도를 다 썼다면 그 Organization에서 새 무료 프로젝트를 만들 수 없습니다. Organization을 새로 하나 더 만든다고 무료 프로젝트를 더 쓸 수 있게 되는 것도 아닙니다.

활동이 부족한 Free 프로젝트는 일시 중지될 수 있습니다. 지난 1주일 동안 데이터베이스 사용이 충분하지 않으면 중지되는 방식이라, 활동이 있는 프로젝트라면 1주일이 지났다고 바로 중지되지는 않습니다. 일시 중지된 프로젝트는 이 2개 한도에 포함되지 않고, 대시보드에서 다시 활성화할 수 있습니다.

Free와 Pro의 세부 한도, 프로젝트를 추가할 때 늘어나는 컴퓨트 비용 계산은 앞서 링크한 글들에 이미 있으므로 가격표를 다시 싣지 않습니다. “무료로 시작할 수 있고, 프로젝트가 늘거나 기능이 더 필요해지면 그때 Pro를 검토한다”는 정도로 이해하고 시작하면 충분합니다.

Supabase를 쓰기 전 알아둘 한계

Supabase를 쓴다고 백엔드 개발이 전부 자동으로 끝나는 것은 아닙니다. 몇 가지 책임은 여전히 개발자에게 남아 있습니다.

• 어떤 테이블을 만들고 어떤 관계로 연결할지는 직접 설계해야 합니다.
• RLS 정책처럼 접근 권한을 세밀하게 제어하는 설정은 직접 작성해야 합니다. 꺼 둔 채로 서비스를 운영하면 노출된 스키마의 그 테이블에 권한이 있는 역할이면 누구든 읽고 쓸 수 있는 상태가 됩니다.
• 프로젝트가 늘어날수록 어느 프로젝트에 어떤 설정을 했는지 관리가 복잡해집니다.
• Supabase라는 외부 서비스에 백엔드를 맡기는 것이므로, 서비스 자체의 운영 정책이나 요금 변경에 영향을 받을 수 있습니다.
• 공개 키와 비밀 키를 혼동해서 쓰면 보안 사고로 이어질 수 있으므로, 어떤 코드가 브라우저에서 실행되고 어떤 코드가 서버에서만 실행되는지 먼저 구분해 두어야 합니다.

마무리 정리

• Supabase는 PostgreSQL을 중심으로 Auth·Storage·API·Realtime·Edge Functions를 함께 제공하는 백엔드 플랫폼입니다.
• Organization은 Project를 묶고 팀·결제·플랜을 관리하는 단위이고, Project는 Postgres·Auth·Storage 같은 실제 리소스를 가진 단위입니다. 하나의 Organization 아래 여러 Project를 둘 수 있습니다.
• 가입하면 기본 Organization이 자동으로 생깁니다. 혼자 쓴다면 이 안에 Project만 추가하면 되고, Organization을 새로 나누는 것은 결제나 권한을 분리해야 할 때의 선택입니다.
• Free 플랜의 무료 프로젝트 2개 한도는 Organization이 아니라 Owner·Administrator로 속한 모든 Organization을 합친 사람 기준이라는 점을 기억해야 합니다.
• 테이블을 만들면 RLS를 켜는 것을 기본으로 생각하고, 비밀 키는 클라이언트 코드에 절대 넣지 않으며, 프로젝트를 처음 만들 때 고르는 리전은 제자리에서 바꿀 수 없으므로 테스트용이라도 실제 서비스할 지역을 염두에 두고 고릅니다.