Supabase Pipelines Public Alpha는 분석 기능을 “프로덕션 DB 바깥”으로 빼라는 신호다

• 카테고리: web_app_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 대시보드와 리포트가 느려질 때, 우리는 인덱스를 더 붙일 것인가 아니면 데이터 흐름을 분리할 것인가?
• 핵심 출처:
  • Supabase Pipelines is now in Public Alpha - 게시일: 2026-07-21, 확인일: 2026-07-23
  • Database Replication - Supabase Docs - 문서, 확인일: 2026-07-23
  • Introducing Supabase Pipelines - 게시일: 2026-06-24, 확인일: 2026-07-23
  • PostgreSQL Logical Replication - PostgreSQL 18 문서, 확인일: 2026-07-23
  • Developer Update - July 2026 - 게시일: 2026-07-09, 확인일: 2026-07-23

1. 왜 지금 봐야 하나

Supabase가 2026년 7월 21일 Supabase Pipelines Public Alpha를 공개했다. 핵심은 Supabase Postgres의 데이터를 외부 분석 시스템으로 near real-time 복제하는 관리형 CDC(change data capture) 파이프라인이다. 첫 공개 목적지는 Google BigQuery이고, ClickHouse, Snowflake, DuckLake는 요청 폼을 통해 확장 후보로 열어두었다.

이번 발표에서 웹앱 개발자가 봐야 할 포인트는 “BigQuery 연동이 생겼다”가 아니다. 더 중요한 변화는 운영 DB와 분석 DB의 책임을 분리하는 기능이 Supabase 대시보드 안으로 들어왔다는 점이다.

작은 웹앱은 처음에 모든 것을 같은 Postgres에서 처리한다.

• 사용자 화면을 위한 select
• 관리자 페이지의 통계 카드
• 매출/전환율 리포트
• 제품팀의 임시 SQL
• AI 에이전트가 만든 분석 쿼리
• cron이 매일 돌리는 집계 작업

처음에는 괜찮다. 하지만 데이터가 쌓이면 분석 쿼리는 운영 쿼리와 성격이 달라진다. 운영 쿼리는 보통 “한 사용자, 한 주문, 한 세션”을 빠르게 읽고 쓴다. 분석 쿼리는 많은 행을 스캔하고, 묶고, 조인하고, 다시 계산한다. 같은 DB에서 둘이 경쟁하면 느린 대시보드가 아니라 느린 제품이 된다.

오늘의 핵심 문장: 분석 기능은 화면 하나가 아니라 데이터 이동 계약이다. 운영 Postgres가 모든 질문에 직접 답하게 만들지 말고, 어떤 데이터가 어떤 지연과 보장으로 분석 시스템에 복제되는지 설계해야 한다.

2. 핵심 개념

이번 글의 핵심 개념은 CDC 기반 분석 분리다.

CDC는 데이터베이스 변경을 애플리케이션 코드에서 이벤트로 직접 발행하는 대신, DB가 남기는 변경 로그를 읽어 다른 시스템에 전달하는 방식이다. Supabase 문서와 블로그 설명을 합치면 Pipelines는 다음 흐름으로 동작한다.

1. 복제할 Postgres 테이블을 고른다.
2. 기존 행을 먼저 initial sync로 복사한다.
3. 이후 변경은 Postgres logical replication을 통해 읽는다.
4. insert, update, delete, truncate 같은 변경을 배치로 목적지에 쓴다.
5. 목적지 시스템에서는 분석 쿼리, BI, 리포트, 노트북 작업을 수행한다.

PostgreSQL 문서가 설명하는 logical replication은 publication/subscription 모델이다. publisher 쪽에서 어떤 데이터를 내보낼지 publication으로 정하고, subscriber가 그것을 구독해 초기 스냅샷을 받은 뒤 이후 변경을 순서대로 적용한다. Supabase Pipelines는 이 원리를 개발자가 직접 운영하지 않아도 되도록 관리형 제품으로 감싼 것이다.

여기서 중요한 설계 언어는 세 가지다.

Supabase의 Public Alpha 발표에서 가장 큰 추가점은 지원되는 스키마 변경을 감지해 목적지에 자동 적용하는 기능이다. 발표에 따르면 현재는 컬럼 추가, 제거, 이름 변경, nullability/default 변경을 지원하며, 더 넓은 type change와 table-level 변경은 계속 확장 중이다. 따라서 “자동 스키마 동기화가 있으니 마이그레이션을 아무렇게나 해도 된다”가 아니라, “지원되는 변경과 수동 처리가 필요한 변경을 구분해야 한다”가 맞다.

3. 최신 이슈와 연결

이번 릴리스에서 확인한 사실은 다음과 같다.

• Supabase Pipelines는 Public Alpha로 전환되었다.
• 첫 managed destination은 Google BigQuery다.
• BigQuery destination은 insert, update, delete, truncate를 지원하고, schema change는 제한적인 beta로 표시되어 있다.
• Pipelines는 Supabase ETL이라는 Rust 기반 오픈소스 CDC 엔진 위에서 동작한다.
• Supabase 문서는 Pipelines가 public alpha이며 기능과 동작이 바뀔 수 있다고 명시한다.
• Managed Pipelines는 AWS eu-central-1에서 실행되며, 지연을 줄이려면 목적지 리소스를 가능한 가까운 곳에 두라고 권한다.
• Supabase의 2026년 7월 Developer Update도 Realtime, GraphQL, self-hosted Docker, logs, agent integration처럼 “개발 편의”와 “운영 경계”가 동시에 움직이고 있음을 보여준다.

여기서 가장 실용적인 연결점은 Realtime과 Pipelines를 헷갈리지 않는 것이다.

Supabase Realtime은 브라우저나 모바일 앱에 변경을 보내 사용자 경험을 즉시 바꾸기 위한 도구다. 채팅 메시지, 협업 커서, 알림 배지, 라이브 상태가 여기에 가깝다. 반면 Pipelines는 분석 목적지에 신뢰 가능한 복사본을 유지하기 위한 도구다. 대시보드, BI, 장기 리포트, 추천 모델용 feature table, 고객 성공팀용 운영 리포트가 여기에 가깝다.

둘 다 “Postgres 변경을 읽는다”는 점 때문에 비슷해 보이지만 실패 조건은 다르다.

이 구분을 못 하면 웹앱은 이상한 모양이 된다. 라이브 UX를 만들겠다고 분석 파이프라인을 붙이거나, 매출 리포트를 만들겠다고 클라이언트 Realtime 이벤트를 저장하기 시작한다. 둘 다 장기적으로 운영 비용을 만든다.

4. 개발자 관점 해석

웹앱 개발자가 이 릴리스를 보며 가져가야 할 관점은 “분석 기능도 제품 기능처럼 계약을 가져야 한다”는 것이다.

첫째, OLTP와 OLAP를 분리해서 생각해야 한다.

운영 Postgres는 사용자의 현재 행동을 처리하는 곳이다. 로그인, 주문, 권한 확인, 피드 로딩, 댓글 작성처럼 제품이 즉시 반응해야 하는 요청이 여기에 있다. 반면 분석 시스템은 많은 데이터를 훑고 패턴을 찾는 곳이다. 이 둘을 같은 DB에서 처리할 수는 있지만, 같은 우선순위로 보면 장애가 난다.

둘째, 복제는 백업이 아니다.

Pipelines가 BigQuery로 데이터를 보낸다고 해서 그것이 운영 DB 복구 전략을 대체하지 않는다. 분석 목적지에는 스키마 변환, 지연, destination-specific 타입 제약, 삭제/수정 적용 방식이 있을 수 있다. 백업/복구는 별도의 목표이고, CDC 파이프라인은 분석과 통합을 위한 데이터 이동이다.

셋째, at-least-once 전달은 중복 가능성을 포함한다.

Supabase 발표는 Pipelines가 at-least-once delivery를 제공한다고 설명한다. 이는 “변경을 적어도 한 번 전달하려고 한다”는 뜻이지 “항상 정확히 한 번만 반영된다”는 뜻이 아니다. 분석 쿼리나 downstream job은 primary key, event id, updated_at, LSN 같은 기준으로 중복과 재처리를 견딜 수 있어야 한다.

넷째, 스키마 마이그레이션은 앱 코드만의 일이 아니다.

컬럼 하나를 바꾸면 TypeScript 타입, API 응답, RLS 정책, Edge Function, 관리자 화면뿐 아니라 분석 목적지의 테이블도 영향을 받는다. Public Alpha의 schema change support는 이 부담을 줄여주지만, 아직 제한이 있다. 따라서 마이그레이션 PR에는 “Pipelines 영향” 체크가 들어가야 한다.

다섯째, AI 에이전트에게 분석 쿼리를 맡길수록 경계가 더 필요하다.

AI 코딩 에이전트가 “전환율 대시보드 만들어줘”라는 요청을 받으면 운영 DB에 큰 집계 쿼리를 바로 추가할 수 있다. 작은 데이터에서는 성공처럼 보이지만, 제품이 커지면 위험하다. 에이전트 지침에는 “운영 경로에 분석 쿼리를 추가하기 전에 read replica, materialized view, Pipelines/warehouse 분리 여부를 검토하라”는 규칙이 필요하다.

5. 내 프로젝트에 적용할 체크포인트

아래 질문에 “모른다”가 많다면, 분석 기능이 아직 데이터 이동 계약 없이 자라고 있을 가능성이 높다.

운영 DB 부하

• 관리자 대시보드가 production Postgres를 직접 스캔하는가?
• count(*), group by, 넓은 기간의 join이 사용자 요청 경로에서 실행되는가?
• 느린 쿼리 로그에서 제품 API와 분석 API를 구분해 보고 있는가?
• 분석 쿼리를 위해 만든 인덱스가 쓰기 성능이나 저장 비용을 악화시키고 있지는 않은가?

데이터 복제 범위

• 모든 테이블을 복제해야 하는가, 아니면 events, orders, subscriptions처럼 일부만 충분한가?
• 개인정보/민감정보 컬럼을 분석 목적지로 보내도 되는가?
• RLS로 보호하던 데이터가 warehouse에서는 어떤 권한 모델로 보호되는가?
• 삭제 요청, 계정 탈퇴, 보존 기간 정책이 목적지에도 반영되는가?

지연과 정확도

• 대시보드가 몇 초 지연되어도 되는가?
• 결제/정산처럼 더 강한 정확도가 필요한 리포트와 일반 제품 분석을 나누었는가?
• at-least-once 전달로 인한 중복 가능성을 쿼리에서 제거할 키가 있는가?
• initial sync 중에도 사용자가 보는 수치가 일관되게 설명되는가?

스키마 변경

• 컬럼 추가/삭제/rename이 분석 쿼리와 BI 차트를 깨뜨릴 수 있는가?
• 마이그레이션 PR에 “Pipelines 지원 schema change인지” 확인란이 있는가?
• 목적지별 타입 제약을 알고 있는가?
• 실패한 schema change를 수동으로 복구하는 절차가 있는가?

운영 관측

• replication lag를 어디서 확인하는가?
• pipeline stop/restart/delete 권한은 누구에게 있는가?
• 목적지 쓰기 실패, quota, 네트워크 지연을 어떻게 알림으로 받을 것인가?
• Supabase 문서가 권하는 region 고려사항을 목적지 선택에 반영했는가?

6. 오늘 10분 액션

오늘 바로 할 수 있는 작은 실험은 “분석 쿼리 분류표”를 만드는 것이다.

1. 최근 7일 동안 관리자/리포트/cron에서 실행되는 SQL 5개를 고른다.
2. 각 쿼리를 아래 표로 분류한다.

3. “운영 Postgres에서 꼭 실시간으로 답해야 하는 쿼리”와 “분석 목적지로 보내도 되는 쿼리”를 나눈다.
4. AI 에이전트나 팀 문서에 다음 규칙을 추가한다.

분석/리포트/대시보드 기능을 만들 때는 production Postgres에 대규모 집계 쿼리를 바로 추가하지 않는다.
먼저 쿼리의 지연 허용치, 스캔 범위, 개인정보 포함 여부, CDC/warehouse 분리 가능성을 기록한다.
Supabase Pipelines, read replica, materialized view 중 어떤 경계가 맞는지 선택한 뒤 구현한다.

이 10분만 해도 “DB가 느리다”는 막연한 문제가 “어떤 쿼리를 어디서 실행해야 하는가”라는 설계 문제로 바뀐다.

7. 더 볼 자료

• Supabase Pipelines Public Alpha 글은 현재 지원 범위와 제한을 확인하기 좋다.
• Supabase Database Replication 문서는 read replica, Pipelines, manual replication의 차이를 정리한다.
• Supabase ETL 소개 글은 publication, replication slot, initial sync, destination 개념을 이해하는 데 도움이 된다.
• PostgreSQL logical replication 문서는 publication/subscription 모델과 초기 스냅샷 이후 변경 적용 방식을 원리 수준에서 설명한다.
• Supabase July 2026 Developer Update는 Realtime binary payload, pg_graphql introspection 기본 비활성화, self-hosted Auth URL 변경처럼 운영 경계가 계속 바뀌고 있음을 보여준다.

중복 회피 메모

로컬 content/generated와 Supabase 최근 web_app_dev 글을 확인했다. 최근 글은 Next.js 월간 보안 릴리스와 패치 윈도우, Next.js SWC WASM/lockfile 배포 계약, React Router Web Streams 런타임 계약, TypeScript 7 빌드 계약, Next.js 에이전트 검증 루프, pg_graphql introspection, PostgREST JWT kid, Supabase Auth URL 라우팅, Hono 서버리스 어댑터를 다뤘다. 2026-06-13 글에서 Supabase Realtime과 ETL을 비교한 적은 있지만, 이번 글은 새로 공개된 Supabase Pipelines Public Alpha와 schema change support, BigQuery 목적지, logical replication 기반 CDC를 바탕으로 분석 기능을 production Postgres 바깥으로 분리하는 데이터 이동 계약에 집중한다.