Supabase MCP 서버: Backend-as-a-Service가 Agent-as-a-Service로 진화하는 방법

Supabase는 Select 2026에서 MCP 서버 지원을 발표하며, 에이전트를 최상위 인프라 소비자(first-class infrastructure consumers)로 취급하는 최초의 주요 Backend-as-a-Service 플랫폼이 되었습니다. MCP 서버는 데이터베이스 설정, Edge Functions, 그리고 장시간 실행되는 컴퓨팅 작업을 툴 경계(tool boundaries)를 통해 노출합니다. 이제 에이전트는 대시보드를 건드리지 않고도 테이블을 프로비저닝하고, RLS 정책을 수정하며, 백엔드 서비스를 배포할 수 있습니다.

이는 프로비저닝 모델 자체를 변화시키기 때문에 중요합니다. 기존에는 인간 개발자가 UI를 클릭한 후 변경 사항을 레포지토리와 동기화하는 방식이었다면, 이제 에이전트가 코드베이스 내에서 직접 작동합니다. 스키마 정의는 SQL 파일로 존재하고, 설정 변경은 버전 관리 시스템으로 되돌아가며(flow back), 마이그레이션은 pg-delta에 의해 자동으로 계산됩니다.

인증 및 권한 경계 (Authentication and Authorization Boundaries)

MCP 서버는 두 가지의 뚜렷하게 구분되는 인증 흐름을 처리합니다:

에이전트가 시작하는 인프라 변경: 에이전트는 범위가 지정된(scoped) 프로젝트 API 키를 사용하여 인증합니다. 에이전트가 새 테이블을 프로비저닝하거나 RLS 정책을 수정할 때, 이는 CLI를 사용하는 인간 개발자와 동일한 역할 기반 접근 제어(role-based access control) 하에서 작동합니다. 차이점은 에이전트의 활동이 고유 식별자로 기록되어 감사 추적(audit trails) 상에서 에이전트가 시작한 변경과 인간이 시작한 변경을 분리한다는 것입니다.

사용자가 시작하는 에이전트 행동: 사용자의 에이전트(Claude, ChatGPT 또는 Cursor에서 실행됨)가 MCP 서버를 통해 앱과 상호 작용할 때, 해당 에이전트는 로그인된 사용자로서 인증합니다. MCP 서버는 웹 인터페이스의 사용자에게 적용되는 것과 동일한 RLS 정책 및 권한을 강제합니다. 즉, 에이전트는 사용자가 볼 수 있도록 허용된 내용만 보게 됩니다.

이러한 이중 경계 모델(dual-boundary model)은 흔한 실패 모드인 애플리케이션 레벨의 권한 우회로 인한 특권 상승(escalating privileges)을 방지합니다.

비용 가드레일 및 리소스 제한 (Cost Guardrails and Resource Limits)

Supabase의 MCP 구현은 자율 에이전트를 위해 설계된 지출 통제 기능을 도입했습니다:

• 쿼리 비용 추정(Query cost estimation): 쿼리를 실행하기 전에 MCP 서버는 컴퓨팅 유닛으로 예상 비용을 반환합니다. 에이전트는 진행할지, 아니면 먼저 쿼리를 최적화할지 결정할 수 있습니다.
• API 키별 호출 제한(Rate limits per API key): 각 프로젝트 API 키에는 설정 가능한 호출 제한이 있습니다. 여러 Edge Function을 실행하거나 무제한 쿼리를 실행하는 에이전트는 예상치 못한 요금이 발생하기 전에 이 제한에 도달하게 됩니다.
• 컴퓨팅 리소스 상한선(Compute resource caps): Supabase Compute 작업은 프로젝트 수준에서 최대 실행 시간 및 메모리 제한이 설정되어 있습니다. 에이전트는 명시적인 사용자 승인 없이는 이러한 상한을 초과하는 장기 실행 작업을 프로비저닝할 수 없습니다.

장기 실행 작업 및 상태 관리

Supabase Compute는 요청-응답 주기(request-response cycle)에 맞지 않는 작업을 처리합니다. 예를 들어, 대규모 문서 세트에 대한 임베딩 생성, 백그라운드 데이터 처리 또는 지속적으로 활성화되어야 하는 서비스 등이 해당됩니다. MCP 서버는 이러한 작업을 큐 추상화(queue abstraction)를 통해 노출합니다:

1. 에이전트가 작업 정의(코드, 종속성, 리소스 요구 사항)를 제출합니다.

2. MCP 서버는 작업 ID와 예상 시작 시간을 반환합니다.

3. 작업이 완료되면 에이전트는 결과를 가져오거나 오류 로그를 확인합니다.

이는 전통적인 작업 큐의 폴링 오버헤드(polling overhead)를 방지합니다. 에이전트는 작업을 제출할 때 웹훅 URL을 등록할 수 있으며, 작업이 완료되면 Supabase가 결과에 대해 POST 요청을 보냅니다. 만약 에이전트가 공개 엔드포인트가 없는 샌드박스 환경에서 실행되는 경우, 지수 백오프(exponential backoff)를 사용한 폴링으로 대체됩니다.

스키마 마이그레이션 충돌

에이전트가 기존 프로덕션 데이터와 충돌하는 스키마 마이그레이션을 생성할 때, MCP 서버는 다음을 보여주는 상세한 차이점(diff)을 반환합니다:

• 어떤 열이나 제약 조건이 삭제될지
• 몇 개의 행에 영향을 미칠지
• 해당 마이그레이션이 안전하게 롤백(rolled back)될 수 있는지 여부

이를 바탕으로 에이전트는 다음 중 하나를 결정할 수 있습니다:

• 마이그레이션을 수정하여 기존 데이터 보존
• 파괴적인 변경에 대한 인간의 승인 요청
• 중단하고 다른 접근 방식 시도

실제 충돌 감지 작동 방식은 다음과 같습니다:

-- Agent가 생성한 마이그레이션
ALTER TABLE users DROP COLUMN legacy_id;

...

에이전트는 마이그레이션이 실행되기 전에 이 응답을 받아 우발적인 데이터 손실을 방지합니다.

Docker 없이 로컬 개발

Supabase의 로컬 개발 스택은 이제 네이티브 프로세스로 실행되어, 에이전트 기반 워크플로우의 핵심 문제를 해결했습니다. Claude Code, Codex, Perplexity Computer 및 대부분의 CI 러너는 Docker 데몬을 가지고 있지 않습니다. 따라서 에이전트는 컨테이너 인프라가 필요하지 않은 상태에서 로컬 Supabase 인스턴스를 띄우고, 스키마 변경 사항을 테스트하고, 이를 해제할 수 있습니다.

각 디렉토리는 자체 스택을 가지므로, 에이전트는 두 개의 스키마 변경 사항을 나란히 테스트하고 작동하는 것을 유지할 수 있습니다. 이는 인프라 수준에서 A/B 테스트를 가능하게 합니다: 에이전트는 서로 다른 인덱싱 전략을 가진 두 개의 로컬 데이터베이스를 프로비저닝하고, 동일한 쿼리 워크로드를 양쪽에 실행한 다음, 더 빠른 스키마를 선택합니다.

감사 로그 및 롤백 워크플로우

Supabase는 감사 로그에서 에이전트가 시작한 변경과 인간이 시작한 변경을 구분합니다. 각 로그 항목에는 다음 정보가 포함됩니다:

• 행위자 유형 (human, agent 또는 system)
• 에이전트 식별자 (어떤 API 키 또는 MCP 세션)
• 변경 유형 (스키마, 설정, 데이터)
• 롤백 가능 여부 (변경 사항을 되돌릴 수 있는지 여부)

에이전트가 파괴적인 변경을 수행할 때, 롤백 워크플로우는 인간의 승인을 필요로 합니다. 에이전트는 롤백을 요청할 수 있지만, 사람이 변경 사항을 검토하고 확인하기 전까지는 실행되지 않습니다.

배포 형태

MCP 서버는 기존 Supabase API 게이트웨이에 사이드카(sidecar) 형태로 실행됩니다. 동일한 인증 계층과 데이터베이스 연결 풀을 공유하지만, 자체적인 속도 제한 및 로깅 파이프라인을 가집니다. 이는 에이전트 트래픽을 사용자 트래픽으로부터 격리하여, 에이전트의 통제 불능 쿼리가 최종 사용자 성능에 영향을 미치는 것을 방지합니다.

사용자 에이전트에게 자체 MCP 서버를 노출하려는 앱의 경우, Supabase는 배포 템플릿을 제공합니다:

1. 도구를 Edge Functions로 정의합니다.
2. 인증(OAuth, API 키 또는 Supabase Auth)을 구성합니다.
3. MCP 서버를 앱 데이터베이스와 동일한 프로젝트에 배포합니다.
4. 사용자는 앱에 사용하는 것과 동일한 자격 증명을 사용하여 에이전트를 인증합니다.

MCP 서버는 앱의 RLS(Row Level Security) 정책을 상속받으므로, 사용자의 에이전트는 해당 사용자가 볼 수 있도록 허용된 데이터만 접근할 수 있습니다.

발생 가능성이 높은 실패 모드 (Likely Failure Modes)

비용 폭주 (Cost runaway): 조정되지 않은 재시도 로직을 가진 에이전트가 값비싼 쿼리를 반복적으로 실행하여 비용을 급증시킬 수 있습니다. 속도 제한(rate limits)이 도움이 되지만, 만능은 아닙니다. 에이전트 API 키 사용량을 모니터링하고 예상치 못한 급증에 대한 알림을 설정해야 합니다.

스키마 드리프트 (Schema drift): 에이전트가 로컬에서 스키마를 수정했지만 마이그레이션이 프로덕션 환경에서 실패하는 경우, 로컬 및 프로덕션 스키마가 달라지게 됩니다. 에이전트는 이러한 변화(drift)를 감지하고 로컬 변경 사항을 롤백하거나 마이그레이션을 수정해야 합니다.

웹훅 전송 실패 (Webhook delivery failures): 에이전트가 장기 실행 작업에 대한 웹훅을 등록했지만, 웹훅 엔드포인트가 다운되면 에이전트는 결과를 받지 못합니다. 대안은 폴링(polling)이지만, 에이전트는 이 경우를 명시적으로 처리해야 합니다.

권한 상승 (Permission escalation): 에이전트의 API 키에 너무 광범위한 권한이 있는 경우, 자신이 건드려서는 안 되는 리소스를 수정할 수 있습니다. 범위가 지정된(scoped) API 키를 사용하고 감사 로그(audit logs)에서 에이전트 활동을 정기적으로 검토해야 합니다.

기술적 판단 (Technical Verdict)

Supabase의 MCP 서버를 사용하는 경우:

• 사용자 개입 없이 백엔드 인프라를 프로비저닝하고 수정하도록 하려는 경우
• 자율 에이전트를 위해 설계된 비용 제어 및 속도 제한이 필요한 경우
• 사용자의 에이전트가 사용자 권한 내의 데이터와 상호 작용해야 하는 앱을 구축하는 경우
• 샌드박스 또는 Docker를 사용하지 않는 환경에서 작동하는 로컬 개발 환경이 필요한 경우

다음과 같은 경우에는 피할 것:

• 에이전트가 실행하는 모든 데이터베이스 쿼리에 대한 세밀한 제어(MCP 추상화는 일부 세부 사항을 숨깁니다)가 필요합니다.
• 컴플라이언스 요구사항으로 인해 자율적인 스키마 변경이 금지됩니다.
• 에이전트의 동작을 모니터링하고 예상치 못한 리소스 사용에 대한 알림을 설정할 준비가 되어 있지 않습니다.
• 앱의 권한 부여 모델(authorization model)이 RLS 정책만으로는 표현하기에는 너무 복잡합니다.

진정한 테스트는 팀이 프로덕션 환경을 망가뜨리지 않으면서 에이전트에게 인프라 변경을 맡길 수 있는지를 여부입니다. 강력한 테스트 및 롤백 워크플로우를 갖추고 있다면, Supabase의 MCP 서버는 수동으로 리소스를 할당하는 병목 현상을 제거합니다. 그렇지 않다면, 에이전트는 그저 더 빠르게 문제를 일으킬 뿐입니다.

소스 링크

• Supabase Select 2026 발표