🚨 문제 상황 발생

• 발생 시각: 손님 챗봇 백엔드(/api/chat) 헬스 체크 중
• 현상: RLS 정책을 anon 대상으로 빠짐없이 만들었는데도, 챗봇이 conversations에 대화를 저장하려 하면 permission denied가 발생. 챗봇 응답 자체는 나오지만(에러 격리 설계) DB 적재가 전부 실패하고 X-Conversation-Id 헤더도 안 내려옴.

🔍 원인 파악 및 시도

1. 에러 로그 및 분석

code: 42501
message: permission denied for table conversations
hint: GRANT SELECT, INSERT ON public.conversations TO anon;

• 42501 = 권한 부족. 테이블이 없을 때 뜨는 42P01이 아니므로 테이블은 존재하나 anon role에 권한이 없는 상황.
• 핵심 단서는 hint: GRANT ... TO anon. RLS 정책이 아니라 테이블 레벨 GRANT를 요구하고 있었다.

2. 가설 및 시도 과정

• 가설 1: 마이그레이션이 원격에 적용 안 됐나? → 아니다. 테이블·시드·RLS 정책 모두 db push로 적용됐고 대시보드에서 확인됨. 테이블이 존재(42P01 아님)하는 것도 이를 뒷받침.
• 가설 2: RLS 정책이 잘못됐나? → 정책은 정상. anon에 select/insert를 with check/using으로 열어둠. 그런데도 막힘.
• 결론: RLS 정책과 별개로 테이블 레벨 GRANT가 빠져 있었다. Postgres 권한은 GRANT(테이블 레벨)와 RLS Policy(행 레벨) 두 층이고, 둘은 AND 관계라 GRANT가 없으면 정책을 볼 것도 없이 바깥문에서 막힌다. Supabase가 보통 anon/authenticated에 기본 GRANT를 자동 부여해서 평소엔 의식하지 못했던 부분이 드러난 것.

✅ 최종 해결 방안

1. 해결 코드

-- 새 마이그레이션: grant_anon_access
-- RLS 정책과 별개로 테이블 레벨 GRANT를 anon에 부여
grant select, insert on conversations to anon;
grant select, insert on messages to anon;
grant select on products to anon;
-- insights는 GRANT/정책 모두 주지 않음 → 셀러 전용 차단 유지

• 이미 적용된 customer_rls 마이그레이션은 건드리지 않고, GRANT만 담은 새 마이그레이션을 추가해 supabase db push.

2. 해결 방법 요약

• 원인은 RLS 정책 누락이 아니라 테이블 레벨 GRANT 누락.
• GRANT를 별도 마이그레이션으로 추가(대시보드 직접 grant 대신) → DB 재생성 시에도 권한이 따라오도록 재현 가능하게.
• 적용 후 conversations/messages insert·select, products select 모두 통과. 챗봇이 실제 시드 상품을 인용하고, X-Conversation-Id 헤더 왕복도 정상 동작.

💡 오늘의 교훈

• Postgres 테이블 권한은 GRANT(테이블 레벨) + RLS Policy(행 레벨) 두 층이고 AND 관계다. RLS 정책을 아무리 정교하게 짜도 GRANT가 없으면 막힌다.
• permission denied (42501)가 뜨고 테이블은 분명 존재한다면, RLS 정책부터 의심하기 전에 테이블 GRANT를 먼저 확인하자. 에러 hint에 GRANT ... TO {role}이 보이면 거의 확정.
• Supabase는 기본 GRANT를 자동 부여하는 경우가 많아 평소엔 안 보이지만, 그게 없으면 두 층의 존재가 드러난다. 권한은 코드(마이그레이션)로 명시해 재현 가능하게 둘 것.