Neon이 백엔드 플랫폼으로 — branch가 DB를 넘어 스토리지·compute로 번지다

한 줄 요약

2026-05-28, Neon(네온)이 “우리는 앱과 agent를 위한 boring backend를 만든다"는 글을 내고 같은 주 changelog로 세 가지 신규 서비스를 예고했다. PostgreSQL 한 제품으로 출발한 회사가, 자기 핵심 무기인 branch를 데이터베이스 밖으로 끌고 나가 스토리지·compute·AI 라우팅까지 같은 모델로 묶기 시작했다.

세 서비스는 오브젝트 스토리지(Object Storage), 서버리스 compute(Compute), AI Gateway다. 셋 다 아직 “coming soon"이지만 방향은 분명하다 — Neon은 더 이상 자기를 “서버리스 PostgreSQL"로만 규정하지 않는다. PostgreSQL 30년 산업사 글에서 정리한 “클라우드 베어의 시대” 흐름이, 이번에는 PostgreSQL 회사 한 곳이 백엔드 플랫폼으로 몸집을 키우는 형태로 다시 나타났다.

무엇을 발표했나

발표를 사실 단위로 끊어 정리한다. 1차 출처는 Neon 공식 블로그(Bryan Clark, VP Product)와 changelog다.

세 신규 서비스를 묶는 한 문장은 Neon이 직접 말한다 — 모든 서비스가 “instant, branchable, serverless"다. branch가 DB만의 기능이 아니라 플랫폼 전체의 기본 동작이 된다는 선언이다.

AI Gateway 쪽에는 숫자 하나가 붙는다. Neon은 이 Gateway가 “Databricks에서 월 125조 토큰을 처리하는 같은 인프라 위에 올라간다”고 적었다. 2025년 5월 Databricks(데이터브릭스)가 Neon을 인수한 뒤, 모회사의 운영 규모를 그대로 끌어쓰는 자리다.

branch가 무엇이길래 — 출발점부터

이 발표를 이해하려면 Neon의 branch가 어떻게 동작하는지부터 짚어야 한다. 일반적인 PostgreSQL 호스팅에서 “테스트용 사본"을 만들려면 pg_dump로 받아 다른 인스턴스에 복원하거나, 스냅샷에서 새 볼륨을 띄운다. 데이터가 클수록 시간과 비용이 선형으로 늘어난다.

Neon의 branch는 다르다. storage 계층에서 copy-on-write로 동작한다. branch를 만드는 순간 데이터를 복사하지 않고, 부모 branch의 WAL 히스토리 특정 시점을 가리키는 메타데이터 포인터만 만든다. 페이지는 수정될 때 비로소 branch 쪽에 따로 기록된다. 그래서 branch 생성은 데이터 크기와 무관하게 O(1)이고, 1초 안에 끝난다.

flowchart TD
    PARENT["부모 branch
(공유 페이지)"]
    PTR["새 branch = 포인터"]
    READ["읽기: 부모 공유"]
    WRITE["쓰기 발생"]
    COW["수정 페이지만
branch에 기록"]
    ISO["부모와 격리"]

    PARENT --> PTR
    PTR --> READ
    PTR --> WRITE
    WRITE --> COW
    COW --> ISO

Neon은 이 branch가 하루에 수천만 개씩 생성된다고 밝혔다. 사람이 만드는 양이 아니다. CI에서 PR마다, agent가 작업마다 격리된 환경을 띄웠다 지우는 패턴이 깔려 있다는 뜻이다. branch를 “만들고 쓰고 버리는” 일회성 자원으로 보는 시각이 이미 자리 잡았다.

branch가 DB 밖으로 나간다는 것의 의미

여기서 이번 발표의 핵심이 나온다. branch가 데이터베이스 안에만 있으면 반쪽짜리다. 현실의 애플리케이션은 DB만으로 돌지 않는다 — 업로드된 파일이 오브젝트 스토리지에 있고, 백그라운드 작업이 compute에서 돌고, AI 기능이 외부 모델을 호출한다. DB만 branch되고 나머지가 production을 공유하면, 격리는 깨진다.

예를 들어 보자. 결제 영수증 PDF를 S3에 올리는 기능을 고치는 중이라고 하자. DB는 branch로 격리했는데 스토리지는 production 버킷을 그대로 쓴다면, 테스트로 만든 가짜 영수증이 실제 버킷에 섞인다. compute도 마찬가지다 — branch DB를 바라봐야 할 워커가 production 큐를 집어 들면 격리가 무의미해진다.

Neon의 답은 단순하다. branch를 만들 때 DB뿐 아니라 스토리지·compute가 함께 갈라지게 한다. 오브젝트 스토리지는 “DB와 함께 branch되어 모든 branch에서 데이터와 스토리지가 동기 상태를 유지"하고, compute는 “DB 옆에 배치되는 서버리스” 형태로 같이 따라온다.

flowchart TD
    BR["branch 생성"]
    DB["DB branch"]
    OBJ["스토리지 branch"]
    CMP["compute branch"]
    ENV["격리된 백엔드 환경"]
    USE["agent·CI·개발자"]

    BR --> DB
    BR --> OBJ
    BR --> CMP
    DB --> ENV
    OBJ --> ENV
    CMP --> ENV
    ENV --> USE

같은 copy-on-write 사고를 백엔드 기본 블록 전체에 적용한 셈이다. DB 한 줄만 격리하던 환경이, 이제 파일·연산까지 통째로 격리되는 환경으로 넓어진다.

전통 PostgreSQL 호스팅과 무엇이 다른가

운영자 시각에서 차이를 표로 정리한다. 비교 대상은 “직접 굴리는 PostgreSQL + 별도 오브젝트 스토리지 + 별도 워커"의 전통 조합이다.

전통 조합은 각 계층을 운영자가 직접 잇는다. 그만큼 통제권은 크지만, 환경 하나를 새로 깔 때마다 손이 많이 간다. Neon은 그 봉합을 플랫폼이 가져가는 대신, 계층 선택의 자유를 줄인다. 어느 쪽이 맞는지는 워크로드가 정한다 — 여기에는 분명한 lock-in 비용이 따른다.

운영자가 따져야 할 자리

플랫폼이 편의를 가져가면 그만큼 묶이는 비용이 생긴다. 운영자 관점에서 짚을 지점을 추린다.

• lock-in의 폭이 넓어진다. DB만 Neon에 둘 때와, 스토리지·compute·AI 라우팅까지 둘 때의 이탈 비용은 다르다. branch가 묶어 주는 편의가 클수록, 빠져나올 때 풀어야 할 매듭도 많아진다. PostgreSQL 30년 글에서 인용한 Christophe Pettus(크리스토프 페투스)의 한 줄 — “이미 쓰는 데이터 플랫폼이 선택을 대신했다” — 이 그대로 적용된다.
• AI Gateway는 표준 PostgreSQL 영역 밖이다. 모델 라우팅·비용 통제는 PostgreSQL 호환성과 무관한 독자 기능이다. 이 자리는 pg_dump나 logical replication으로 옮겨지지 않는다. 의존하기 전에 대체 경로를 먼저 확인해야 한다.
• 세 서비스 모두 아직 예고 단계라는 점도 무게를 둔다. 운영 결정은 정식 출시·SLA·요금이 공개된 다음에 내려도 늦지 않다. 발표 시점에 확정된 것은 방향이지 가용성이 아니다.
• AI Gateway가 모회사 인프라 위에 올라간다는 점은 규모의 강점이자 결합의 신호다. Neon Serverless PostgreSQL과 Databricks Lakebase(레이크베이스)가 같은 엔진을 공유한다는 구조도 함께 본다.

산업사 흐름에서 본 위치

PostgreSQL 30년 글은 2025년을 “클라우드 베어의 시대"로 불렀다. Databricks가 Neon을, Snowflake(스노우플레이크)가 Crunchy Data(크런치 데이터)를 가져간 분기다. 그 글의 진단은 “AI agent를 위한 PostgreSQL"이었다 — Neon의 branch 모델이 agent가 매 작업마다 격리된 DB를 띄우기에 맞는다는 이유였다.

이번 발표는 그 진단의 다음 장이다. Neon은 “agent를 위한 PostgreSQL"에서 “agent를 위한 백엔드 전체"로 범위를 넓혔다. 발표 글의 표현을 빌리면 “agent-native cloud는 마법보다 boring한 기본기 — 신원·권한·로그·롤백·비용 통제 — 가 먼저 필요하다”. DB 회사가 백엔드 플랫폼을 지향할 때 내거는 명분이 바로 이 자리다.

이 흐름은 Neon만의 것이 아니다. Supabase(수파베이스)는 처음부터 PostgreSQL + 인증 + 스토리지 + 함수를 한 묶음으로 팔아 온 회사다. Neon이 늦게 같은 무대로 올라온 셈이지만, 무기가 다르다 — Neon은 자기 고유의 branch 모델을 백엔드 전 계층에 바르는 방식으로 차별화를 시도한다. PostgreSQL을 코어로 둔 회사들이 “DB 벤더"에서 “백엔드 플랫폼"으로 수렴하는 큰 그림은 같다.

정리

Neon은 자기 핵심 무기인 branch를 데이터베이스 밖으로 끌고 나갔다. 스토리지·compute가 DB와 함께 갈라지면, 환경 하나를 통째로 격리하는 일이 명령 한 줄로 끝난다. 운영자에게 이건 편의이자 결합이다 — 봉합 비용을 플랫폼에 넘기는 대신, 계층 선택의 자유를 일부 내준다.

세 서비스가 아직 예고 단계라는 점은 잊지 말아야 한다. 방향은 분명하지만 가용성·요금·SLA는 아직이다. 그래도 신호 자체는 또렷하다 — PostgreSQL 회사가 DB를 넘어 백엔드 전체로 가는 길에, branch라는 무기를 그대로 들고 들어선다.

참고

• We’re building the boring backend for apps and agents — Neon, 2026-05-28
• Changelog May 29, 2026 — Neon
• Instantly Copy TB-Size Datasets: The Magic of Copy-on-Write — Neon
• Practical Guide to Database Branching — Neon
• Neon Storage: Bottomless, Branchable
• 본 블로그 — PostgreSQL 30년: 클라우드 베어의 시대