Supabase AI 에이전트 플러그인: 데이터베이스 변경은 이제 “권한 계약”부터 설계해야 한다
AI 코딩 에이전트가 프론트엔드 컴포넌트를 고치는 것과 데이터베이스 스키마를 고치는 것은 위험의 단위가 다르다. 버튼 문구를 잘못 바꾸면 되돌리면 되지만, RLS 정책, trigger, function, extension, migration 순서를 잘못 건드리면 운영 데이터와 권한 경계가 바로 흔들린다. Supabase의 2026년 6월 개발자 업데이트는 그래서 단순한 제품 발표보다 더 중요하다. AI coding agent plugin, ChatGPT app, MCP server, temporary token-based database access, pg-delta가 한 방향을 가리킨다. 데이터베이스 작업도 이제 에이전트가 도울 수 있지만, 그 전에 권한과 검증 계약을 설계해야 한다.
Database agent operating contract
데이터베이스 에이전트의 핵심은 자연어 SQL 실행이 아니다. 개발 브랜치, 좁은 MCP 권한, 임시 토큰, migration diff, RLS 검토, 사람 승인까지 묶은 운영 계약이다.
무슨 일이 있었나
Supabase는 2026년 6월 개발자 업데이트에서 AI coding agent용 Supabase Plugin을 공개했다. 이 plugin은 Supabase MCP server와 agent skills를 한 번에 묶어 Claude Code, Cursor, Codex, Gemini CLI 같은 환경에서 Supabase 프로젝트를 다루게 한다. 공식 문서에 따르면 에이전트는 데이터베이스 조회, migration 관리, Edge Functions 배포, Supabase와 Postgres best practices 참조 같은 작업을 도구 표면으로 사용할 수 있다.
이미 2026년 5월에는 Supabase가 ChatGPT의 공식 app으로 들어갔다. 공식 블로그는 ChatGPT 안에서 SQL 실행, schema 수정, Edge Function 배포, branch 관리, migration 적용, 실시간 로그 확인, 문서 검색까지 할 수 있다고 설명한다. 즉 “IDE 안의 코딩 에이전트”와 “대화형 운영 콘솔”이 모두 Supabase 프로젝트에 접근하는 경로가 생긴 셈이다.
여기에 6월 업데이트는 temporary token-based database access preview와 pg-delta 흐름을 함께 언급했다. temporary token은 개발자에게 비밀번호 없이 특정 database role과 만료 기간을 가진 직접 DB 접근을 주는 방향이고, pg-delta는 table, column, RLS policy, function, trigger, index, extension 등 Postgres 객체의 schema diff를 다루는 엔진으로 소개됐다. 이 네 가지를 따로 보면 기능 목록이지만, 함께 보면 데이터베이스 에이전트 시대의 운영면이 보인다.
왜 개발팀에 중요한가
첫 번째 변화는 권한 부여의 단위다. 예전에는 에이전트에게 Supabase 프로젝트를 알려준다는 말이 대개 service role key나 PAT를 어디에 넣을지의 문제로 흘렀다. 이제는 MCP server가 project_ref, read_only=true, feature groups 같은 범위 축소 옵션을 제공하고, temporary token preview는 role과 expiry를 명시하는 쪽으로 간다. 이것은 에이전트 접근을 “비밀값 공유”가 아니라 “시간 제한이 있는 역할 계약”으로 다루게 만든다.
두 번째 변화는 migration 품질이다. 자연어로 “이 테이블에 컬럼을 추가해줘”라고 요청하는 것은 쉽지만, 실제 운영에서는 기존 데이터 backfill, RLS policy, generated TypeScript types, Edge Function 의존성, index 비용, rollback 가능성까지 봐야 한다. Supabase plugin이 MCP server와 skills를 함께 제공한다는 점은 중요하다. 도구 호출만 있으면 위험하고, 절차 지식만 있으면 검증이 약하다. 둘을 함께 써야 “무엇을 할 수 있는가”와 “어떤 순서로 해야 하는가”가 맞물린다.
세 번째 변화는 데이터베이스 변경의 리뷰 표면이다. pg-delta가 지향하는 schema diff는 에이전트가 만든 변경을 사람이 리뷰하기 쉬운 형태로 바꾸는 데 의미가 있다. 단순 SQL 한 덩어리보다 Postgres 객체 단위 diff가 있으면 “이 trigger가 바뀌었는지”, “RLS policy가 새 테이블에 맞게 붙었는지”, “extension 변경이 포함됐는지”를 PR에서 질문할 수 있다.
커뮤니티와 실무 신호
Supabase의 6월 업데이트는 funding, Multigres, Passkey, ChatGPT app, AI coding agent plugin, temporary token, pg-delta, tracing, RLS Tester까지 많은 항목을 한 번에 묶었다. 여기서 실무자가 주목해야 할 신호는 “AI가 DB를 대신 관리한다”는 과장이 아니라, Supabase가 AI 도구 연결을 제품 표면과 보안 표면 양쪽에서 동시에 다루기 시작했다는 점이다.
MCP 문서의 보안 섹션은 특히 보수적이다. production data에 직접 연결하지 말 것, 고객에게 MCP server를 제공하지 말 것, 가능하면 read-only mode와 project scoping을 쓸 것, branching으로 안전한 변경 환경을 만들 것, feature groups로 attack surface를 줄일 것을 권한다. 이것은 마케팅 문구가 아니라, 실제 팀이 에이전트 도입 정책으로 옮겨 적을 수 있는 기준이다.
개발자 커뮤니티의 관심도 권한과 검증 쪽으로 모인다. ChatGPT app처럼 강한 도구 표면이 나오면 사람들은 “무엇까지 자동화할 수 있나”보다 “실수하면 어디까지 실행되는가”를 묻는다. Supabase가 temporary token과 schema diff 흐름을 같이 밀고 있는 이유도 여기에 있다. 에이전트의 생산성은 승인 가능한 diff와 취소 가능한 권한이 있을 때만 조직 안으로 들어온다.
개발·운영 영향
첫째, 로컬 개발과 운영 DB 사이에 명확한 차단선을 두어야 한다. Supabase MCP 문서는 개발·테스트 목적을 기본으로 보고, production data 연결은 피하라고 말한다. 실제 팀에서는 별도 Supabase project, branch, seed data, obfuscated fixture를 마련하고, 에이전트가 그 안에서만 schema와 query를 실험하도록 해야 한다.
둘째, migration PR의 체크리스트가 넓어진다. 예전에는 migration SQL과 타입 생성 정도를 봤다면, 이제는 어떤 agent가 어떤 tool call을 했는지, SQL 결과에 prompt injection 가능성이 있는지, RLS Tester나 advisors로 확인했는지, logs와 tracing으로 영향 범위를 보았는지까지 기록해야 한다. 에이전트가 한 작업일수록 사람이 읽을 수 있는 근거가 더 필요하다.
셋째, 데이터 접근 정책이 짧아진다. temporary token preview가 보여주는 방향은 장기 비밀번호나 공유 계정이 아니라 만료되는 직접 접근이다. 에이전트와 계약직 개발자, CI 작업, 일회성 분석 세션을 모두 같은 원칙으로 묶을 수 있다. 필요한 role, 필요한 project, 필요한 기간만 열고 끝나면 닫는 방식이다.
넷째, ChatGPT app과 IDE plugin을 같은 정책으로 봐야 한다. 하나는 대화형 운영 창처럼 보이고, 다른 하나는 코딩 도구처럼 보이지만 둘 다 Supabase API, SQL, branch, migration, logs에 접근할 수 있다. 보안팀이나 플랫폼팀 입장에서는 “어느 앱인가”보다 “어떤 project, 어떤 role, 어떤 tool group, 어떤 승인 절차인가”가 더 중요하다.
지금 할 일
가장 먼저 해야 할 일은 production 연결 금지 정책을 문서화하는 것이다. MCP 설정 예시, allowed project list, seed data 규칙, 민감정보 masking 규칙을 AGENTS.md나 내부 runbook에 넣는다. 에이전트가 Supabase를 다룰 수 있다면, 에이전트가 읽는 첫 문서도 Supabase 권한 정책이어야 한다.
두 번째는 read-only 기본값이다. 조회와 설명, 타입 생성, 문서 검색은 넓게 열어도 되지만 execute_sql, apply_migration, branch merge, Edge Function deploy는 별도 승인 단계로 분리한다. MCP feature groups를 좁히고, project scope를 고정하고, write 작업은 브랜치에서 먼저 실행한다.
세 번째는 migration diff를 리뷰 가능한 산출물로 남기는 것이다. 에이전트가 만든 SQL을 바로 적용하지 말고, migration 파일과 schema diff, generated types, RLS policy 변경 목록, rollback 메모를 PR에 붙인다. pg-delta 같은 schema diff 흐름은 이 리뷰 표면을 더 촘촘하게 만드는 방향으로 봐야 한다.
리스크와 반론
물론 모든 팀이 지금 바로 Supabase agent plugin을 설치해야 하는 것은 아니다. 작은 프로젝트나 읽기 전용 분석 작업은 기존 CLI와 dashboard만으로 충분할 수 있다. AI 도구가 팀의 승인 문화를 우회한다면 생산성보다 사고 가능성이 커진다. 특히 production data, 고객 개인정보, 결제·권한 테이블, secret이 섞인 logs는 에이전트 연결 전에 별도 격리가 필요하다.
반대로 “위험하니 전부 금지”도 오래 버티기 어렵다. 개발자는 이미 로컬에서 여러 에이전트 도구를 쓰고 있고, 데이터베이스 변경은 프론트엔드 코드보다 더 많은 맥락을 요구한다. 올바른 결론은 금지가 아니라 좁은 권한, 짧은 수명, branch-first, diff-first, human approval-first다. Supabase의 6월 흐름은 이 운영 모델을 제품 기능으로 끌어내고 있다.
운영 통제 표
Supabase 에이전트 도입 체크리스트
• 운영 DB가 아니라 개발/브랜치 프로젝트에 먼저 연결한다.
• project_ref, read_only=true, feature groups로 MCP 도구 범위를 줄인다.
• ChatGPT app이나 MCP가 실행할 SQL은 사람이 승인하고 migration 파일로 남긴다.
• temporary token은 역할과 만료를 정해 발급하고, 프로젝트 권한 해제 시 함께 끊기는지 확인한다.
• RLS, extension, function, trigger, generated TypeScript types를 PR 체크리스트에 넣는다.