Supabase는 좋은 제품입니다. 저는 이에 대해 긍정적으로 글을 쓴 적도 있고, 기존 Supabase 데이터베이스 위에서 AI 에이전트를 실행하는 방법을 보여준 적도 있으며, 이 사실은 오늘 변하지 않습니다.

하지만 Supabase에 없는 기능들의 목록이 있습니다. "더 못하는 것"이 아니라, 아예 "없는" 것들입니다. 저는 이 목록을 기능 매트릭스(feature matrix) 형태로 작성하는 대신, 단 하나의 프롬프트로 완전한 CRM을 구축하는 AI 에이전트와의 대화 속에서 그 모든 항목이 사용되는 과정을 영상으로 기록했습니다.

프롬프트는 단 한 단락이었습니다: crm6라는 이름의 앱을 생성할 것 — 세 개의 테이블을 가진 데이터베이스, CRUD 웹 API, 연락처로 이메일을 보낼 수 있는 기능, 그리고 전체 API가 "guest" 역할의 사용자에게만 제한되는 현대적인 프런트엔드(frontend). Magic의 MCP 서버를 통해 연결된 에이전트인 Claude가 나머지를 수행했습니다. 이 글은 에이전트가 무엇을 구축했는지 살펴보고, 각 단계에서 Supabase가 제공하지 않는 어떤 기능을 활용했는지 지적합니다.

구축된 내용

• 외래 키(foreign keys), 기본값(defaults), 시드 데이터(seed data)를 포함한 contacts, deals, activities 세 개의 테이블을 가진 SQLite 데이터베이스.
• 16개의 HTTP 엔드포인트(endpoints): 모든 테이블에 대한 전체 GET/POST/PUT/DELETE 및 레코드 수 확인 기능, 그리고 이메일 전송 엔드포인트 — 이 모든 것은 "guest" 역할로 제한됩니다.
• ID로 연락처를 조회하고 플랫폼의 SMTP 통합을 통해 이메일을 발송하는 이메일 발송 기능.
• 설계된 프런트엔드(frontend) — Magic의 내장 인증(auth)을 통한 JWT 로그인, 파이프라인 차트가 포함된 KPI 대시보드, 이메일 작성기가 포함된 검색 가능한 연락처, 드래그 앤 드롭 방식의 deals 칸반(kanban), 그리고 활동(activities) 목록.

직접 작성한 백엔드 코드: 0줄. CRUD 레이어는 crudifier에 의해 생성되었습니다 — 12개의 선언적 호출(declarative calls)과 722줄의 생성된 Hyperlambda로 구성되며, 각 호출은 1초 미만의 매우 빠른 시간 내에 반환됩니다. 이메일 전송 엔드포인트(send-email endpoint)는 평이한 영어 프롬프트로부터 측정 결과 7.6초 만에 생성되었습니다. 한 줄씩 직접 작성된 유일한 부분은 프런트엔드(frontend)였으며, 이 또한 에이전트가 작성했습니다.

빌드 과정 시청하기

이제 목록을 살펴보겠습니다.

1. 스스로 생성되는 백엔드

Supabase는 PostgREST를 제공합니다. 이는 스키마(schema)를 일반적인 REST 방식으로 반영(reflection)해 주는 도구입니다. 이는 진정으로 유용하지만, 그것이 한계이기도 합니다. 테이블 투영(table projection)이 아닌 엔드포인트가 필요한 순간 — 예를 들어 "이 연락처의 이메일 주소를 조회하여 메시지를 보내고, 연락처가 존재하지 않으면 오류를 발생시켜라"와 같은 기능 — 당신은 TypeScript를 사용하여 직접 에지 함수(edge function)를 작성하고, 자체적인 에러 핸들링(error handling)을 구현하며, 직접 배포해야 합니다.

Magic에서 에이전트는 단 한 문장의 영어로 해당 엔드포인트를 설명했고, Hyperlambda Generator가 이를 생성하고 저장한 뒤, 다른 모든 것과 마찬가지로 역할 기반 권한 제어(role-gated)를 적용하여 7.6초 만에 네트워크에 배포했습니다. 백엔드는 단순히 스키마의 반영이 아닙니다. 의도(intent)로부터 생성된, 커스터마이징 가능한 코드입니다.

2. 에이전트가 코딩으로 우회할 수 없는 접근 제어

이것은 구조적인 문제이며, 이 영상이 가능했던 근본적인 이유입니다.

Supabase의 보안 모델은 행 단위 보안(row-level security, RLS)입니다. 이는 앱과 테이블마다 직접 작성해야 하는 SQL 정책(policies)입니다. AI 에이전트가 애플리케이션 코드를 생성할 때, 생성된 모든 쿼리(query)와 모든 함수는 이러한 정책을 정확히 준수해야 합니다. 게다가 이러한 정책을 우회할 수 있는 서비스 역할 키(service-role key)가 환경 변수에 그대로 놓여 있습니다. 보안 경계가 생성된 코드 내부에 존재한다는 것은, 매번 코드를 생성할 때마다 보안 설정을 잘못할 수 있는 새로운 위험 요소가 발생함을 의미합니다.

Magic은 실행 시점(execution time), 즉 런타임(runtime)에서 액세스를 강제합니다. 이 빌드의 모든 엔드포인트(endpoint)는 "guest" 역할(role)이 필요함을 선언하며, 이 확인 절차는 모든 엔드포인트 로직이 실행되기 전에 수행됩니다. 즉, 에이전트가 생성한 코드가 이를 누락할 수 있는 선택권 자체가 없습니다. 빌드 후, CRUD 레이어와 이메일 엔드포인트를 대상으로 익명 요청을 보낸 결과, 매번 401(access denied, 액세스 거부) 응답이 반환되었습니다.

Magic-auth login — the JWT ticket comes from the platform, not from hand-rolled auth code

이것이 바로 이 플랫폼에서는 에이전트에게 운영(production) 자격 증명(credentials)을 넘겨주고 그것이 작동하는 것을 지켜볼 수 있는 이유입니다. 프롬프트(prompt)가 아니라 플랫폼이 해당 자격 증명이 무엇을 할 수 있는지 결정합니다. Supabase에는 이와 대등한 기능이 없습니다. 이는 그들의 엔지니어들이 능력이 없어서가 아니라, 그들의 아키텍처(architecture)가 권한 부여(authorization)를 애플리케이션 내부에 두기 때문이며, 현재의 애플리케이션은 확률론적인 저자(probabilistic author)에 의해 작성되고 있기 때문입니다.

3. 네이티브 MCP 서버

영상 속의 모든 일은 단 하나의 MCP 연결을 통해 이루어집니다. 데이터베이스 생성, 엔드포인트 생성, 파일 업로드, 결과 검증까지 — 에이전트는 사용자가 Claude를 통해 자신의 Magic cloudlet과 대화할 때 사용하는 것과 동일한 도구 인터페이스를 통해 플랫폼을 운영합니다.

Supabase는 개발 워크플로(workflow)를 위한 추가 기능(add-on)으로 MCP를 제공합니다. Magic의 MCP 서버는 곧 플랫폼 그 자체입니다. 모든 기능은 인증된 사용자의 역할(role)로 범위가 제한되며, 에이전트는 기존 도구가 적합하지 않을 때 스스로 새로운 도구를 생성할 수 있습니다. 영상에서 "통합(integration)" 단계가 없는 이유는 통합할 대상이 없기 때문입니다.

4. 플랫폼 프리미티브로서의 이메일

CRM은 연락처로 이메일을 보냅니다. Supabase에서 이 기능은 엣지 함수(edge function), 제3자 메일 API, 관리해야 할 API 키, 그리고 영구적으로 직접 소유해야 하는 재시도 로직(retry logic)을 의미합니다. Magic에서는 SMTP가 플랫폼 수준에서 한 번만 설정되며, 생성된 엔드포인트는 단순히 전송만 합니다. 애플리케이션 내에 메일 제공업체 자격 증명이 존재하지 않기 때문에, 에이전트는 메일 제공업체 자격 증명을 본 적조차 없습니다.

Composing an email to a contact — one guest-gated endpoint, zero mail-provider plumbing

5. 웹 서버 (A web server)

영상 속의 프론트엔드 (Frontend)는 API를 제공하는 것과 동일한 시스템에 의해 서빙됩니다. 에이전트는 HTML, CSS, JavaScript 세 개의 파일을 플랫폼의 파일 시스템 (File system)에 작성했으며, 이 파일들은 작성되는 즉시 해당 URL에서 라이브 상태가 되었습니다. Vercel도, Netlify도, 웹사이트인 척하는 스토리지 버킷 (Storage bucket)도, 프론트엔드 호스트와 백엔드 호스트 간의 CORS 설정도 필요하지 않습니다. 호스트가 단 하나뿐이기 때문입니다.

The deals kanban — drag a card between stages and the deal updates through the guest-gated API

Supabase Storage는 파일을 보관합니다. 그것은 웹 루트 (Web root)가 아니며, Supabase는 여러분의 웹 서버가 되고 싶어 하지 않습니다. Magic은 데이터베이스 (Database), API, 인증 (Auth), 메일 (Mail), 그리고 프론트엔드 호스트 (Frontend host)가 하나로 합쳐진 배포 가능한 단위 (Deployable unit)입니다. 이것이 바로 단 한 번의 대화 속에서 에이전트가 이 모든 것을 배포할 수 있게 해주는 핵심입니다.

6. 쌓이면 무서운 사소한 것들 (The boring ones that add up)

• 티켓 로테이션 (Ticket rotation) 기능이 내장된 JWT 인증 (JWT auth) — 프론트엔드는 플랫폼의 인증 엔드포인트 (Auth endpoint)를 통해 로그인하며, 10분 단위로 티켓을 갱신합니다. 이 빌드 과정 어디에도 별도의 인증 라이브러리 (Auth library)는 설치되지 않았습니다.
• 작업 스케줄링 (Task scheduling), 로깅 (Logging), 그리고 서버 측 파일 시스템 (Server-side file system) — 영상에서 비중 있게 다뤄지지는 않았지만, 에이전트가 어떤 작업을 위해서도 플랫폼을 벗어날 필요가 없었던 이유입니다.
• MIT 라이선스, 단일 컨테이너 (One container), 제한 없는 기능 — 영상에 등장하는 전체 스택은 오픈 소스 (Open-source) 제품입니다. 여러분의 배포 환경보다 데모를 더 멋지게 만들기 위해 호스팅 전용으로만 제공되는 기능은 없습니다.

Contacts with search, status badges, and per-row actions — generated CRUD underneath

Magic에는 있지만 Supabase에는 없는 것

공정함은 양날의 검이며, 이 목록은 사실입니다: Postgres 복제 (replication)를 넘어서는 실시간 구독 (realtime subscriptions), Postgres 확장 (extension) 생태계의 깊이, 세상의 모든 프레임워크를 위한 클라이언트 SDK, 그리고 당신이 가질 모든 질문에 이미 답이 마련되어 있을 만큼 충분히 큰 커뮤니티까지 말이죠. 만약 당신의 제품이 실시간으로 업데이트되는 Postgres 데이터를 중심으로 구축되었고, 팀의 개발 속도 (velocity)가 해당 생태계에서 나온다면 Supabase는 여전히 올바른 선택입니다. 저는 비교 기사에서도 그렇게 말했으며, 그 의견은 여전히 유효합니다.

하지만 그 어떤 것도 영상이 보여주는 격차를 메우지는 못합니다. 그것들은 Supabase를 더 나은 데이터베이스 플랫폼으로 만들 뿐입니다. AI 에이전트가 엔드 투 엔드 (end-to-end)로 안전하게 운영할 수 있는 시스템으로 만들어주지는 않습니다.

핵심 요점

2026년의 흥미로운 질문은 더 이상 "어떤 백엔드가 더 나은 대시보드를 가지고 있는가"가 아닙니다. 질문은 이것입니다: 당신 팀의 다음 개발자가 프롬프트(prompt)를 가진 에이전트일 때, 그 에이전트가 실제로 무엇을 할 수 있는가 — 그리고 무엇이 에이전트가 하지 말아야 할 일을 하지 못하도록 막는가?

이번 빌드에서 그 답은 '모든 것'과 '런타임 (runtime)'이었습니다. 단 한 단락의 의도(intent)만으로 데이터베이스, 16개의 역할 보안 (role-secured) 엔드포인트, 이메일 발송, 그리고 설계된 작동 가능한 프런트엔드까지 구축되었습니다. 이때 모든 작업은 에이전트가 생성(generation)을 통해 우회할 수 없는 실행 시간 RBAC (Role-Based Access Control, 역할 기반 액세스 제어)에 의해 제한되었습니다. 생성(generation), 강제 실행(enforcement), MCP, 메일, 그리고 호스팅이 하나의 셀프 호스팅 (self-hosted) 및 MIT 라이선스 단위로 결합된 이 조합 — 이것이 바로 Supabase에는 없는 모든 것을 갖춘 시스템입니다.

Magic은 github.com/polterguy/magic에서 오픈 소스로 제공되며, 문서는 docs.ainiro.io에서, 직접 실행하고 싶지 않다면 호스팅된 클라우드렛 (cloudlets)은 ainiro.io에서 확인할 수 있습니다.

이 기사는 원래 hyperlambda.dev에 게시되었습니다.