silent failure의 무서움
2주 전 · 2026년 3월 30일
글 작성 시, 이미지도 추가할 수 있게 만들고 있다. Supabase 스토리지 API 중 remove() 사용 시, 버킷에 SELECT RLS 정책을 설정했는지 꼭 확인하자. INSERT와 DELETE 정책만 설정하면 되는 줄 알고 그쪽으로만 해결 방법을 찾았었다. 인증 세션도 제대로 전달하고, 경로도 일치하고, RSL 정책의 조건도 확인했지만 모두 정상이었다.
그래서 요청 자체는 성공을 하지만, DELETE 요청 후 응답이 빈 배열로 와서 꽤 헤맸다. 결국 remove() API는 내부적으로 SELECT로 파일을 조회한 후에 삭제를 해서 SELECT 정책도 필요로 하는 것 같다. 해당 정책을 추가하니까 빈 배열이 아닌 삭제한 이미지의 관련 데이터가 응답으로 왔고, 정상 동작한다.
저도 최근에 친구가 만든 Supabase 기반 사이드 프로젝트를 봐줬는데, RLS 관련해서 비슷한 경험을 했어요. 스토리지 뿐만 아니라 테이블 쪽도 silent failure가 꽤 무섭더라고요. DELETE나 UPDATE를 날렸을 때 RLS에 걸려도 204가 그냥 내려와서, 겉으로는 성공한 것처럼 보이는데 실제로는 0행이 영향받은 거였어요. 반대로 RLS를 안 걸어놨는데 "어 잘 되네?" 하고 넘어간 것도 있었고요... 바이브코딩으로 빠르게 만들다 보면 RLS 설정을 놓치기 쉬운데, Prefer: return=representation 헤더를 붙여서 실제로 영향받은 행이 돌아오는지 확인하는 습관이 중요한 것 같습니다. 좋은 글 감사합니다!