Supabase API 키 고르기: anon과 service_role, 가입부터 잠금 확인까지
한줄 요약: Supabase 프로젝트를 만들면 키가 여러 개 나옵니다. 성격은 두 종류입니다. 하나는 잠금 규칙(RLS)을 켜 두었다면 브라우저에 노출돼도 되는 키, 다른 하나는 그 규칙을 통째로 통과하는 키입니다. 이 글은 두 키를 구분하는 법과, 정말 잠겼는지 눈으로 확인하는 방법까지 다룹니다. 확인 없이 “에러가 안 났으니 됐다”고 넘어가는 것이 가장 흔한 사고입니다.
AI가 짜 준 코드에 키를 넣는 순간
AI에게 “데이터베이스에 저장해줘”라고 시키면 대개 Supabase를 붙여 줍니다. 여기까지는 잘 됩니다. 문제는 그다음입니다.
프로젝트를 만들고 설정 화면에 들어가면 키가 여러 개 나옵니다. AI가 준 코드에는 SUPABASE_KEY 자리가 하나뿐인데, 어느 걸 넣어야 하는지는 아무도 말해 주지 않습니다.
그래서 대부분 이렇게 합니다. 아무거나 넣어 보고 되는 걸 씁니다. 그리고 잘 됩니다. 잘 되는 게 문제입니다.
키는 네 개로 보이지만 성격은 둘입니다
| 키 이름 | 성격 | 브라우저에 넣어도 되나 |
|---|---|---|
publishable |
공개용 (새 이름) | RLS를 켰다면 네 |
anon |
공개용 (예전 이름) | RLS를 켰다면 네 |
secret |
만능 (새 이름) | 절대 안 됩니다 |
service_role |
만능 (예전 이름) | 절대 안 됩니다 |
Supabase가 이름을 바꿔 가는 중이라 네 개로 보입니다. 성격은 두 종류뿐입니다.
이해하기 쉬운 비유가 하나 있습니다.
- 공개용 키는 건물 현관 카드입니다. 로비까지는 들어옵니다. 그 안에서 어느 방을 열 수 있는지는 따로 정한 규칙이 정합니다. 그 규칙이 서두에서 말한 RLS입니다.
- 만능 키는 마스터 키입니다. 규칙을 전부 무시하고 모든 방을 엽니다.
공개용 키 (publishable, anon)
- 어디에 두나 브라우저, 앱 코드 화면 소스에 보여도 됩니다
- 권한 규칙이 정한 만큼만 로비까지만 들어오는 현관 카드
- 전제 RLS를 켜 두어야 합니다 안 켜면 그냥 전부 열립니다
규칙이 있을 때만 안전합니다
만능 키 (secret, service_role)
- 어디에 두나 서버, 비밀값 저장소 깃허브 Actions secrets 같은 곳
- 권한 전부 모든 방을 여는 마스터 키
- 전제 RLS가 있어도 통과합니다 규칙으로 막을 수 없습니다
브라우저에 넣으면 데이터가 전부 열립니다
1단계. 가입하고 프로젝트 만들기
- supabase.com에서 Start your project를 누릅니다.
- 깃허브 계정으로 로그인하는 방법이 가장 빠릅니다. 이메일로도 됩니다.
- 처음이면 조직(Organization)을 하나 만들라고 합니다. 프로젝트가 아니라 조직이 먼저입니다. 이름은 아무거나 괜찮고 나중에 바꿀 수 있습니다.
- 조직 안에서 New project를 누릅니다.
프로젝트를 만들 때 물어보는 것이 세 개입니다.
| 항목 | 무엇을 넣나 |
|---|---|
| 이름 | 나중에 바꿀 수 있습니다. 아무렇게나 |
| 리전 | 한국에서 쓸 거면 서울을 고르세요. 응답이 눈에 띄게 빠릅니다 |
| 데이터베이스 비밀번호 | 이 화면을 떠나면 다시 안 보여 줍니다. 지금 어디 적어 두세요 |
만들면 몇 분 기다립니다. 그동안 키를 찾으러 가면 “아직 없다”고 나올 수 있는데 고장이 아닙니다.
2단계. 설정 화면에서 API 키까지 가기
여기가 처음 하는 사람이 가장 오래 헤매는 구간입니다. 키가 어딘가에 있다는 것은 아는데 그 어딘가를 못 찾습니다.
- 프로젝트 화면 왼쪽 세로 아이콘 줄의 맨 아래 톱니바퀴를 누릅니다. 이것이 Settings입니다.
- 열린 왼쪽 목록에서 API Keys를 누릅니다.
화면에 적힌 영어 문장이 사실 답을 다 말해 줍니다.
| 화면 문구 | 뜻 |
|---|---|
| Publishable keys can be safely shared publicly | 이 키는 공개해도 됩니다 |
| This key is safe to use in a browser if you have enabled RLS | RLS를 켰다면 브라우저에 둬도 됩니다 |
| These API keys allow privileged access | 이 키는 특권 접근입니다. 서버에만 두세요 |
3단계. 예전 이름으로 된 키가 필요할 때
실습 코드나 예제가 anon, service_role이라는 이름을 쓰고 있다면 같은 화면의 Legacy anon, service_role API keys 탭에서 찾습니다.
이 화면의 설명 문구를 옮기면 이렇습니다.
| 키 | 화면이 말하는 것 |
|---|---|
anon (public) |
RLS를 켰다면 브라우저에서 안전합니다. 앞으로는 Publishable 키를 쓰라고 권합니다 |
service_role (secret) |
RLS를 우회할 수 있습니다. 절대 공개하지 마세요. 유출되면 즉시 새로 발급하라고 합니다 |
이름만 바뀌었고 역할은 같습니다. 코드가 요구하는 이름을 그대로 따르면 됩니다.
4단계. “잠갔다”를 어떻게 확인하나
여기가 이 글에서 가장 중요한 부분입니다.
테이블에 잠금(RLS)을 켜면 잠긴 것처럼 보입니다. 그런데 정말 잠겼는지는 직접 확인해야 합니다. 잠금이 걸렸을 때 오는 응답이 에러가 아니기 때문입니다.
기사 600건이 들어 있는 테이블에 잠금을 걸고, 같은 데이터를 세 갈래로 조회한 결과입니다. 정책은 “로그인한 사용자만 읽을 수 있다”로 두고 로그인하지 않은 접근에는 아무 정책도 주지 않았습니다.
| 어떤 키로, 어떤 상태로 조회했나 | 응답 | 보인 건수 |
|---|---|---|
만능 키 (service_role) |
정상 | 600건 |
공개용 키 (anon), 로그인 안 한 상태 |
정상 | 0건 |
공개용 키 (anon), 로그인한 상태 |
정상 | 600건 |
로그인하지 않은 조회가 “권한 없음” 에러를 주지 않습니다. 정상적으로 조회했고 결과는 0건이라고 옵니다.
이게 왜 문제냐면 화면에서는 두 상황이 똑같아 보입니다.
- 잠금이 제대로 걸려서 0건
- 데이터가 원래 없어서 0건
정리하면 만능 키로 본 건수와 공개용 키로 로그아웃 상태에서 본 건수를 비교합니다. 600건이 0건이 되는 것을 눈으로 봐야 잠긴 것입니다. “에러가 안 났으니 됐다”는 확인이 아닙니다.
잠금을 켜는 것 자체는 테이블마다 한 번 해 주면 되고, 절차는 Supabase 문서의 Row Level Security 항목에 있습니다. 이 글은 켠 다음 정말 켜졌는지 확인하는 방법을 다룹니다.
규칙을 열 때 한 번 더 생각할 것
잠금을 걸어 두면 아무것도 안 되니까, AI에게 “안 되는데 고쳐줘”라고 하면 규칙을 열어 줍니다. 그러면 됩니다. 그런데 무엇을 열었는지는 봐야 합니다.
연차 신청 화면을 만들면서 승인 기능까지 넣으려면 공개용 키에 수정 권한을 줘야 합니다. 그러면 이렇게 됩니다.
그리고 공개용 키는 브라우저 소스에 그대로 있습니다. 즉 그 페이지를 인터넷에 올리는 순간 아무나 승인 버튼을 누를 수 있는 상태가 됩니다.
답은 규칙을 더 정교하게 만드는 것이고, 그게 어려우면 인터넷에 올리지 않는 것입니다. 내 컴퓨터에서만 쓰는 도구도 충분히 쓸모가 있습니다.
이 글의 화면과 키 이름은 2026년 8월 24일에 확인했습니다. Supabase는 키 이름과 화면 구성을 바꾼 적이 있고 요금제 조건도 바뀝니다. 실제 화면이 다르면 Settings > API Keys에 적힌 영어 설명을 기준으로 판단하세요. 그 문장이 항상 최신입니다.
댓글