Claude Code + Supabase 보안 대응 방안 Q&A

Question

Claude Code + Supabase 보안 대응 방안 Q&A 목적 : Supabase 사용 시 보안 위험에 대한 전문가 조언 요청 출처 : dalgom.bami Threads 글 ( https://www.threads.com/@dalgom.bami/post/DOYjgEGEvOA?xmt=AQF0oN0fFrAEMy9AqIrJ1n__kxIwi7ImgsTyjVUTh2DH0g ) 안녕하세요, 강사님께서 가르쳐주신 Claude Code와 Supabase를 활용한 개발 워크플로우를 배워가면서 정말 큰 도움을 받고 있습니다. 특히 개발 속도 향상에 대해서는 정말 효과적이라고 느꼈습니다. 다만, 최근에 한 Threads 글을 접하면서 몇 가지 우려사항이 생겼습니다. 실제로 Supabase를 써보니 생기는 보안 위험성에 대해 경험담을 이야기하는 글이었는데, 그 내용이 저희가 배운 워크플로우와 직접적으로 연결되는 부분이 있어서 전문가인 강사님의 견해를 정중히 구해봅니다. 🚨 주요 우려사항 3가지 Q1. RLS(Row Level Security) 설정의 위험성 해당 글에서는 다음과 같은 문제를 지적했습니다: "여러 사용자가 엮여있는 복잡한 기능(예: 사용자 A가 사용자 B의 글에 좋아요) 의 경우, AI 코딩 도구는 복잡성을 피하기 위해 권한을 다 풀어버리는 경우 가 엄청 많았다." 실제 사례: - 비로그인 사용자도 다른 사람의 개인정보가 Response에 노출됨 - Network tab에서 확인 시 모든 데이터 조회 가능 - RLS가 제대로 설정되지 않아서 발생한 문제 질문: Claude Code(또는 다른 AI 도구)에게 Supabase 작업을 의뢰할 때, 복잡한 RLS 정책이 올바르게 설정되도록 강제할 수 있는 방법이 있을까요? 개발 단계에서 이러한 RLS 오설정을 미리 감지할 수 있는 검증 방법(테스트, 문서 체크 등)이 있을까요? 강사님께서 추천하시는 "올바른 RLS 지시사항"이 있을까요? 예를 들어, AI에게 요청할 때 구체적으로 어떻게 명시해야 보안 구멍이 최소화될까요? Q2. Migration 파일 관리와 AI의 한계 "RLS를 Dashboard UI에서 설정하면 코드로 추적 불가능하고, AI가 기존 설정을 파악하기 어렵다. Migration 파일로 관리해야 AI가 기존 설정을 이해할 수 있지만, 이것도 AI가 여러 버전의 Migration 파일을 읽고 이해해야 한다는 의미다. 결국 AI는 기존 설정을 완벽히 이해할 수 없어서 충돌하는 설정을 추가할 확률이 높다." 질문: Claude Code로 Supabase 작업을 할 때, Migration 파일의 버전 관리를 어떻게 해야 AI가 기존 설정을 명확하게 인식할 수 있을까요? 메모리 파일( CLAUDE.md )에 "현재 RLS 정책 요약" 또는 "Migration 히스토리 요약"을 저장해두는 것이 도움이 될까요? 강사님께서 추천하시는 최선의 관리 방식은 무엇일까요? Option A: Dashboard UI는 절대 쓰지 말고 항상 Migration 파일로만 관리? Option B: Dashboard에서 변경 후, 매번 SQL Export해서 Migration으로 변환? Option C: 다른 방식? Q3. Trigger & RPC 오남용으로 인한 유지보수 악화 "복잡한 기능을 구현할 때 AI는 점점 RLS, Trigger, RPC를 남발해서 유지보수가 아예 불가능할 정도의 코드, 기존 데이터가 손실될만한 코드를 무지성으로 찍어낸다." 질문: Claude Code에게 Supabase 작업을 의뢰할 때, Trigger와 RPC 사용을 적절히 제한하는 방법이 있을까요? 예를 들어, AI에게 미리 "RPC는 이 3가지 경우에만 사용하되, 그 외에는 절대 쓰지 말아달라"라고 명시할 수 있는 효과적인 프롬프트가 있을까요? 만약 AI가 불필요하게 Trigger/RPC를 추가했다고 판단되면, "이건 너무 복잡하니까 클라이언트에서 처리하자" 같은 명확한 지시사항이 도움이 될까요? Q4. 프로토타입 vs 실제 서비스 단계에서의 Supabase 사용 "PoC(프로토타입) 단계에서는 Supabase를 적극 활용해도 좋지만, 실제 서비스가 시작되고 사용자가 생기면 일반 백엔드 스택으로 migration해야 한다. 다행히 PostgreSQL 기반이라 마이그레이션이 비교적 쉽다." 질문: 강사님께서도 이 의견에 동의하시나요? 아니면 Supabase도 충분히 프로덕션 레벨의 보안을 유지할 수 있다고 생각하시나요? 만약 동의하신다면, 어느 정도 규모(DAU, 데이터 량, 기능 복잡도)에서 백엔드 스택으로 마이그레이션하는 것이 현실적일까요? 그 전환 지점까지 Supabase를 "안전하게" 사용하는 체크리스트가 있을까요? Q5. 개발자(Claude Code 사용자)가 반드시 알아야 할 백엔드 지식 질문: 강사님께서 생각하시는 "Supabase를 안전하게 쓰는 데 필수적인 최소한의 백엔드 지식"은 무엇일까요? 그 지식들을 Claude Code 사용자들이 미리 학습하도록 권장하시는 방법이 있을까요?   Q6. Claude Code + Supabase 안전 가이드라인 제안 위의 위험성들을 고려할 때, Claude Code 사용자들이 Supabase를 안전하게 사용할 수 있도록 하는 일종의 "체계화된 가이드라인"이 필요하다고 생각합니다. 제안 & 질문: 강사님께서 생각하시는 "Claude Code + Supabase 안전 개발 체크리스트"는 어떤 형태일까요? 예를 들어: □ 이 작업에 RLS가 필요한지 명확히 정의했는가? □ AI에게 요청할 때 RLS 정책을 구체적으로 명시했는가? □ Migration 파일로 저장했는가? □ 개발 환경에서 Network tab으로 데이터 노출 여부 확인했는가? □ Trigger/RPC 사용이 정말 필요한지 재검토했는가? 혹은 Supabase를 쓸 때만 따로 체크리스트를 가져야 할까요? 강사님께서 향후 강의에서 이런 부분을 더 강조하거나 추가 자료를 제공하실 계획이 있으신가요? 🙏 마무리 강사님의 강의를 통해 Claude Code의 강력함을 많이 배우고 있습니다. 다만 강한 도구일수록 신중하게 사용해야 한다는 것을 배웠고, 특히 백엔드와 보안 관련해서는 더욱 그렇다고 생각합니다. 다소 길고 상세한 질문들이지만, 강사님의 전문가적 관점에서의 조언을 진심으로 기다리고 있습니다. 감사합니다! 🙏