Neon 백엔드 플랫폼 확장
짧게 먼저
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입니다.
| 서비스 | 상태 | 한 줄 정의 | 핵심 성질 |
|---|---|---|---|
| Database | 출시됨 | 서버리스 PostgreSQL | branch/서버리스의 출발점 |
| Auth | 출시됨 | 내장 인증 | 백엔드 기본 블록 |
| Data API | 출시됨 | REST/HTTP 접근 | 코드 없이 데이터 노출 |
| Object Storage | coming soon | DB와 함께 branch되는 S3 호환 스토리지 | DB/파일 상태를 branch마다 동기화 |
| Compute | coming soon | DB 옆에 붙는 서버리스 compute | 인프라 관리 없이 함께 확장 |
| AI Gateway | coming soon | 모델 라우팅, 로깅, 비용 통제 | Databricks 인프라 위에 구동 |
세 신규 서비스를 묶는 한 문장은 Neon이 직접 말합니다. 모든 서비스가 "instant, branchable, serverless"라는 것입니다. branch가 DB만의 기능이 아니라 플랫폼 전체의 기본 동작이 된다는 선언입니다.
AI Gateway 쪽에는 숫자 하나가 붙습니다. Neon은 이 Gateway가 "Databricks에서 월 125조 토큰을 처리하는 같은 인프라 위에 올라간다"고 적었습니다. 2025년 5월 Databricks(데이터브릭스)가 Neon을 인수한 뒤, 모회사의 운영 규모를 그대로 끌어쓰는 자리입니다.
1초 만에 끝나는 branch의 원리
이 발표를 이해하려면 Neon의 branch가 어떻게 동작하는지부터 짚어야 합니다. 일반적인 PostgreSQL 호스팅에서 "테스트용 사본"을 만들려면 pg_dump로 받아 다른 인스턴스에 복원하거나, 스냅샷에서 새 볼륨을 띄웁니다. 데이터가 클수록 시간과 비용이 선형으로 늘어납니다.
Neon의 branch는 다릅니다. storage 계층에서 copy-on-write로 동작합니다. branch를 만드는 순간 데이터를 복사하지 않고, 부모 branch의 WAL 히스토리 특정 시점을 가리키는 메타데이터 포인터만 만듭니다. 페이지는 수정될 때 비로소 branch 쪽에 따로 기록됩니다. 그래서 branch 생성은 데이터 크기와 무관하게 O(1)이고, 1초 안에 끝납니다.
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 옆에 배치되는 서버리스" 형태로 같이 따라옵니다.
같은 copy-on-write 사고를 백엔드 기본 블록 전체로 넓힌 것입니다. DB 한 줄만 격리하던 환경이, 이제 파일과 연산까지 통째로 격리되는 환경으로 넓어집니다.
직접 굴리는 조합과 갈리는 지점
운영자 시각에서 차이를 표로 정리합니다. 비교 대상은 "직접 굴리는 PostgreSQL + 별도 오브젝트 스토리지 + 별도 워커"의 전통 조합입니다.
| 항목 | 전통 PG 호스팅 조합 | Neon 백엔드 플랫폼 |
|---|---|---|
| DB 사본 생성 | pg_dump/스냅샷, 크기에 비례 | branch, 1초/O(1) |
| 스토리지 격리 | 버킷 수동 분리/복사 | DB와 함께 자동 branch |
| compute 격리 | 별도 인스턴스 프로비저닝 | DB 옆 서버리스 자동 |
| AI 모델 호출 | 직접 연동/자체 비용 추적 | Gateway가 라우팅, 로깅, 비용 통제 |
| 환경 단위 | DB, 스토리지, compute 각각 | branch 하나로 묶음 |
| 통합 책임 | 운영자가 봉합 | 플랫폼이 봉합 |
전통 조합은 각 계층을 운영자가 직접 잇습니다. 그만큼 통제권은 크지만, 환경 하나를 새로 깔 때마다 손이 많이 갑니다. 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은 자기를 서버리스 PostgreSQL로 규정했고 branch는 DB 안에만 있었습니다. 이번 발표 이후 그 회사는 백엔드 플랫폼을 지향하고, branch 범위는 스토리지와 compute까지 넓어지며, AI는 pgvector 같은 DB 내부 기능이 아니라 Gateway로 분리/외부화됩니다. 운영자 관점에서 보면 DB 한 계층에 대한 의존이 백엔드 여러 계층에 대한 의존으로 커집니다.
정리하면 Neon은 branch를 데이터베이스 밖으로 끌고 나갔습니다. 스토리지와 compute가 DB와 함께 갈라지면 환경 하나를 통째로 격리하는 일이 명령 한 줄로 끝나는데, 이건 운영자에게 편의이자 결합입니다. 봉합 비용을 플랫폼에 넘기는 대신 계층 선택의 자유를 일부 내줍니다.
다만 세 서비스가 아직 예고 단계라는 점은 잊지 말아야 해요. 방향은 분명하지만 가용성, 요금, SLA는 아직이에요.