편해진 건 맞는데, 이거 그냥 믿어도 되는 걸까?
요즘 Supabase로 프로젝트 시작하면
AI 코딩 에이전트부터 켜는 분들 많죠.
테이블 만들어줘
로그인 유저 기준으로 데이터 나눠줘
RLS도 알아서 넣어줘
말로 시키면 코드가 바로 나옵니다.
솔직히 너무 편해요.
근데 쓰다 보면 한 번쯤 이런 생각이 들지 않나요.
이 구조… 진짜 괜찮은 건가?
내가 뭘 놓치고 있는 건 아닐까?
운영 들어가면 터지는 거 아니야?
이 글은 바로 그 지점에서 시작합니다.
AI로 Supabase Postgres 설계해도 되냐가 아니라
어떻게 설계해야 안 터지느냐에 대한 이야기예요.
Supabase가 최근 공개한
Supabase Postgres는
이 질문에 꽤 정직한 답을 주고 있습니다.
1. 먼저 용어부터 정리하고 갑니다
Supabase
Supabase는
데이터베이스, 로그인, 파일 저장 같은
백엔드 기능을 한 번에 제공하는 서비스예요.
기획자 관점에서 보면
“백엔드 걱정 덜어주는 도구”라고 보면 됩니다.
Postgres
Postgres는
Supabase Postgres 안에서 실제 데이터를 저장하는 데이터베이스입니다.
엑셀로 비유하면
Supabase는 프로그램이고
Postgres는 그 안의 시트 구조예요.
문제는 이 Postgres가
기능도 많고, 규칙도 많고,
운영에서만 터지는 함정도 많다는 점입니다.
AI 코딩 에이전트
ChatGPT, Cursor, Copilot 같은
코드 짜주는 AI를 통틀어 부르는 말이에요.
중요한 포인트 하나만 기억하면 됩니다.
AI는
코드를 써주는 존재지
결과를 책임지는 존재는 아닙니다.
2. AI가 Postgres 설계를 잘 못하는 이유
AI가 멍청해서가 아닙니다.
오히려 너무 똑똑해서 문제예요.
AI는 이렇게 생각합니다.
“일단 돌아가면 되지 않나?”
근데 실서비스에서는
“돌아간다”. 와…
“안 터진다”는 완전히 다른 이야기입니다.
Postgres는
실제 운영하면서 겪은 사고들이
수십 년 쌓여서 만들어진 시스템이에요.
- 인덱스 하나 잘못 잡아서 서비스 느려지고
- 보안 설정 하나 빠져서 데이터가 새고
- 마이그레이션 한 번 잘못해서 서비스 멈추고
AI는 이런 경험을 직접 겪어본 적이 없습니다.
그래서 Supabase Postgres는
AI를 막는 대신
AI에게 기준을 주는 방법을 택했습니다.
그게 바로 Postgres Best Practices입니다.
3. Best Practices는 “사람용 설명서”가 아닙니다
이건 중요합니다.
Supabase가 만든 Best Practices는
사람 읽으라고 만든 문서가 아닙니다.
Supabase Postgres는 AI가 참고하라고 만든 규칙집이에요.
각 규칙은 이런 구조로 되어 있습니다.
- 이게 왜 중요한지
- 안 지키면 어떤 문제가 생기는지
- 잘못된 예
- 올바른 예
AI가 코드를 생성할 때
“훈련 데이터에서 비슷한 거 찾기”가 아니라
이 규칙을 기준으로 판단하게 만드는 구조입니다.
그래서 이걸 적용한 AI는
겉보기만 멀쩡한 코드가 아니라
운영 기준을 고려한 설계를 하게 됩니다.
4. 여기서 가장 중요한 개념, RLS
RLS가 뭐냐면요
RLS는 Row Level Security의 약자입니다.
말 그대로
데이터 한 줄 한 줄마다
이 사람이 봐도 되는지 검사하는 규칙이에요.
예를 들어 이런 상황입니다.
- 유저 A 로그인
- 주문 목록 조회
- 자기 주문만 보여야 함
이걸 실수하면
다른 사람 주문까지 다 보이게 됩니다.
AI가 자주 하는 실수
AI는 종종 이렇게 말합니다.
“어플에서 필터링하면 되지 않나요?”
겉으로는 문제 없어 보이죠.
근데 버그 하나 나면
모든 데이터가 그대로 노출됩니다.
그래서 Supabase Postgres는 단호합니다.
보안은
어플이 아니라
데이터베이스에서 강제하라
이게 RLS입니다.
5. Supabase RLS 예제가 무서운 이유
Supabase Postgres가 공개한 RLS 예제를 보면
굉장히 철저합니다.
- 테이블에 RLS를 켜고
- 정책을 명확히 만들고
- 관리자도 우회 못 하게 막습니다
이건 개발자 취향 문제가 아닙니다.
AI가 실수해도 사고 안 나게 만들기 위한 설계예요.
기획자 관점에서 보면 이 차이입니다.
“AI 한 줄 실수로
우리 서비스 데이터가 공개될 수 있느냐, 없느냐”
RLS는 그 경계선입니다.
클로드 코드 스킬 마켓 skillsmp.com, 12만 개 스킬을 공짜로 쓴다고요?
6. 실제로는 이렇게 설계합니다
비개발자도 따라 할 수 있는 AI 설계 예시
이제 제일 궁금한 부분이죠.
그래서
AI랑 실제로는 어떻게 대화하냐는 겁니다.
상황 가정
아주 흔한 서비스입니다.
- 로그인한 유저가 있음
- 유저는 글을 작성함
- 자기 글만 보고, 수정, 삭제 가능해야 함
이걸 AI에게 이렇게 말하면 안 됩니다.
“글 테이블 만들어줘”
이러면
겉보기엔 되는데
보안 기준은 빠질 확률이 큽니다.
1단계. 역할부터 정합니다
이렇게 말하세요.
“Supabase에서 운영할 실서비스야.
Postgres 기반이고,
Row Level Security를 기본으로 설계해줘.”
이 한 문장으로
AI의 태도가 달라집니다.
2단계. 구조를 사람 말로 설명합니다
“유저는 로그인하고
각 유저는 여러 개의 글을 가질 수 있어.
유저는 자기 글만 조회, 수정, 삭제할 수 있어.”
코드 용어 몰라도 됩니다.
AI가 그걸 코드로 바꾸는 역할입니다.
3단계. 이 질문은 꼭 던지세요
“이 구조에서
RLS 정책은 어떻게 설계해야 해?
Supabase auth 기준으로 설명해줘.”
이 질문 하나로
AI 답변 수준이 확 달라집니다.
4단계. 좋은 답변의 공통점
잘 된 경우 AI는 이렇게 답합니다.
- 글 테이블에 user_id 포함
- 로그인 유저 기준으로 접근 제한
- 테이블에 RLS 활성화
- 자기 데이터만 접근 가능
비개발자는 이렇게 이해하면 됩니다.
“이 데이터는
누가 봐도 주인이 정해져 있고
DB에서 그걸 강제로 막는구나”
5단계. 리뷰 질문을 한 번 더 던집니다
“이 설계에서
운영 중에 실수하기 쉬운 포인트는 뭐야?”
이 질문이
AI를 ‘리뷰 모드’로 바꿉니다.
이게 바로
Supabase Postgres가 작동하는 순간입니다.
6. MCP 서버와 Best Practices를 같이 써야 하는 이유
Supabase Postgres MCP 서버는
AI가 실제 프로젝트에 직접 접근하게 해줍니다.
테이블 만들고
구조 바꾸고
정책까지 손댈 수 있습니다.
즉,
AI가 실제 서비스 구조를 만질 수 있는 손을 갖게 됩니다.
여기서 규칙이 없으면 어떻게 될까요?
시키는 대로 다 합니다.
위험한 줄 몰라도요.
그래서 Supabase는 말합니다.
MCP는 손이고
Best Practices는 머리다
둘은 세트입니다.
7. 비개발자는 여기까지만 알면 됩니다
코드를 직접 짤 필요 없습니다.
근데 이 정도는 알고 있어야 합니다.
- RLS는 필수다
- “어플에서 처리”는 위험할 수 있다
- AI가 짠 설계도 리뷰가 필요하다
- 빠른 개발과 안전한 운영은 다르다
이걸 알면
AI에게 던지는 질문이 달라집니다.
그리고 질문이 달라지면
결과도 달라집니다.
8. 자주 나오는 질문 정리
Q. 비개발자인데 AI로 DB 설계해도 괜찮을까요
가능합니다.
다만 자동이라고 생각하면 안 됩니다.
AI는 도구고,
판단은 사람 몫입니다.
Q. Supabase 쓰면 보안은 자동으로 안전한가요
아닙니다.
기본은 안전하지만
설계를 잘못하면 그대로 위험해집니다.
그래서 RLS가 중요합니다.
Q. 이걸 다 이해해야 하나요
전부 이해할 필요는 없습니다.
다만 이런 개념이 있다는 건 알아야
AI가 이상한 방향으로 가는 걸 막을 수 있습니다.
AI로 Postgres 설계하는 시대는
이미 시작됐습니다.
이제 중요한 건
개발자냐 아니냐가 아니라,
AI에게 기준을 줄 수 있느냐입니다.
Supabase가 공개한 Best Practices는
어렵게 만들기 위한 게 아니라,
사고 나지 않게 쓰기 위한 장치입니다.
모르고 맡기면 위험하고,
알고 쓰면 정말 강력합니다.
9. 여러분은 어떻게 쓰고 있나요?
AI에게
“알아서 해줘”라고 맡기고 있나요,
아니면
“이건 이렇게 해야 하지?”라고 묻고 있나요.
경험 있으면 댓글로 공유해 주세요.
