우리 블로그 댓글 API, 이대로 괜찮을까 — Supabase 9월 업데이트 점검기
스코프드 토큰·트레이스 컨텍스트·logs.all 폐지. Supabase의 9월 변경 세 가지를, 이 블로그가 직접 만든 댓글 시스템 기준으로 하나씩 점검하고 고칠 것만 골라낸다.
이 블로그 글 아래엔 자체 댓글이 달려요.
남의 위젯을 붙인 게 아니라, 서버리스 함수가 Supabase에 직접 읽고 쓰는 구조로 직접 만든 거예요.
그래서 Supabase가 9월에 뭔가 바꿨다는 소식을 보고, 남 얘기로 흘리지 않고 “내 것부터 열어보자” 했어요.
변경은 세 가지였어요 — 스코프드 토큰, 트레이스 컨텍스트, 그리고 logs.all 폐지.
하나씩 “우리에게 해당되나”를 따져봤어요.
1. logs.all 폐지 — 우리는 안 씀
관리 API의 analytics/endpoints/logs.all 엔드포인트가 2026년 9월 23일자로 제거됐어요.
로그를 소스별 테이블로 따로 주던 걸, ClickHouse SQL로 한 테이블에 합친 logs 엔드포인트로 바꾼 거예요.
우리 저장소를 logs.all로 검색해봤어요.
한 군데도 안 걸렸어요.
우리 댓글 코드는 로그를 프로그램으로 긁는 일이 없거든요 — 볼 일 있으면 대시보드에서 눈으로 봐요.
영향 없음.
다만 이건 운이 좋았던 게 아니라, 애초에 안 건드린 덕이에요.
2. 트레이스 컨텍스트 — 우리 방식엔 자동으로 안 붙음
Supabase 클라이언트 라이브러리가 W3C 표준 트레이스 컨텍스트를 따르게 됐어요.
OpenTelemetry·Sentry·Datadog 같은 도구로 요청 하나가 어디서 얼마나 걸렸는지 이어 볼 수 있게 된 거예요.
그런데 우리는 이 혜택을 그냥은 못 받아요.
우리 댓글 코드는 @supabase/supabase-js SDK를 안 쓰고, fetch로 PostgREST를 직접 부르거든요.
의존성을 줄이려고 그렇게 짰는데, 그 대가로 SDK가 공짜로 주는 것들은 내가 손으로 해야 해요.
// 우리 방식 — SDK 없이 REST를 직접 부른다
const res = await fetch(`${url}/rest/v1/comments?${qs}`, {
headers: { apikey: key, Authorization: `Bearer ${key}` },
});트레이싱이 필요해지면 요청 헤더에 traceparent를 직접 심으면 돼요.
지금 이 블로그 규모엔 과해서 안 넣었지만, “SDK를 뺀 자리에 뭐가 비는지”를 알아둔 것만으로 점검값은 했어요.
3. 스코프드 토큰 — 여기서 착각할 뻔했다
제일 헷갈린 게 이거였어요.
”토큰 권한을 좁힐 수 있다니, 우리 댓글 키도 좁혀야 하나?”
아니었어요.
Supabase엔 성격이 다른 두 열쇠가 있어요.
service_role키 — 데이터 플레인. 테이블을 읽고 쓰는 열쇠. 우리 댓글 API가 쓰는 게 이거예요.- PAT(Personal Access Token) — 관리 플레인. 프로젝트를 만들고 지우고 설정을 바꾸는, 계정 전체를 쥔 열쇠.
스코프드 토큰이 좁혀주는 건 PAT 쪽이에요.
예전 PAT는 내 계정의 모든 조직·모든 프로젝트를, 앞으로 들어갈 것까지 통째로 열었어요.
그걸 CI나 스크립트, AI 에이전트에 쥐여주는 건 현관 열쇠를 택배기사에게 복사해주는 셈이었죠.
이제 “프로젝트 X만, 읽기만” 식으로 잘라 줄 수 있어요.
새어도 피해가 딱 준 만큼에서 멈추고요.
우리 댓글 API는 PAT를 안 써요.
그래서 이 변경도 코드엔 손댈 게 없었어요.
대신 두 열쇠를 헷갈리지 않는 것 자체가 이 점검의 진짜 수확이었어요.
그래서 우리가 할 일 (해결 체크리스트)
코드를 고칠 건 없었지만, “안 고쳐도 된다”를 확인하는 것도 점검이에요.
대신 대시보드에서 챙길 건 챙겼어요.
- PAT를 쓰는 곳이 있으면 스코프드로 교체. 배포·CI·에이전트에 물린 풀액세스 토큰이 있다면, 필요한 프로젝트·권한만 남기고 새로 발급해 갈아끼운다.
service_role키 위생 재확인. 이 키는 RLS를 통째로 우회하니, 함수(서버) 밖으로 절대 안 나가야 한다.PUBLIC_접두어 금지, 환경변수로만, 그리고 가끔 회전.- 최소 권한을 기본값으로. “일단 다 되는 키”의 편함이, 새는 날의 피해로 정확히 돌아온다.
logs.all·트레이스는 지금은 패스. 안 쓰니 안 고치고, 필요해지면 그때 붙인다.
퍼블리셔의 눈으로
퍼블리셔로 일할 땐 서버·DB·키는 늘 남의 영역이었어요.
화면까지가 내 몫이고, 그 뒤는 백엔드 팀의 방이었죠.
지금은 그 방 열쇠가 내 손에 있어요.
편하기만 한 건 아니에요 — 열쇠를 쥔 만큼, 그걸 어디에 두고 누구에게 복사해주는지가 다 내 책임이 됐거든요.
그래도 남의 서비스 업데이트 공지를 “내 것부터 열어보는” 습관이, 프론트만 보던 시절과 지금을 가르는 선인 것 같아요.
덜어낸 구조(SDK 없이 REST, 키는 서버에만)가 점검을 쉽게 만들어준다는 것도, 이번에 다시 확인했고요.
댓글