Notion의 벡터 검색은 탁월하다. 그들의 다음 문제는 더 어렵다.
“Notion에서의 벡터 검색 2년”을 읽고 — 그리고 그것이 다음에 무엇이 올지에 대해 예측하는 것
Notion은 2년간의 벡터 검색 인프라를 다룬 엔지니어링 포스트를 공개했다. 나는 진심 어린 감탄과 강한 기시감을 느끼며 읽었다. 그들이 설명하는 거의 모든 이슈, 실행한 마이그레이션, 구축한 우회책은 빅데이터 역사 속의 사례와 밀접하게 대응된다. 빅데이터는 장기적 아키텍처로 수렴하는 데 대략 15년이 걸렸다.
내가 가장 인상 깊게 본 것은 단지 실행의 품질만이 아니었다. 더 완전한 아키텍처라면 제품 엔지니어링이 아니라 인프라에 있어야 할 플랫폼 수준의 문제에 얼마나 많은 노력이 들어갔는가였다.
그들의 다음 엔지니어링 포스트 제목을 추측해야 한다면, 아마 “임베딩 모델 업그레이드에 6개월을 쓴 방법.”일지도 모른다. 또는 “다운타임 없이 1억 개의 워크스페이스를 새로운 벡터 공간으로 마이그레이션한 방법.” 또는 “Notion AI에 지속 가능한 메모리를 제공하기 위해 오프라인 컨텍스트 엔지니어링을 구축한 방법.”
지금까지 해결된 모든 것은 1장이다. 2장은 더 어렵다.
Notion이 구축한 것
이 이야기는 2023년 11월에 시작된다. Notion은 AI Q&A를 출시했고, 거의 즉시 수백만 개 워크스페이스의 대기자 명단이 쌓였다. 그들의 벡터 데이터베이스는 pod 클러스터에서 실행되고 있었다 — 스토리지와 컴퓨트가 함께 묶여 있고, 워크스페이스 ID 기준으로 샤딩되어 있었다. 한 달도 안 되어 용량 한계에 가까워지고 있었다.
라이브 트래픽 중에 리샤딩하는 대신, 그들은 실용적인 길을 택했다. generation ID로 태그된 새로운 인덱스 클러스터를 띄우고, 신규 워크스페이스를 새 generation으로 라우팅하며, 기존 워크스페이스는 그대로 둔 것이다. Spark와 Airflow 튜닝과 결합해, 그들은 4개월 만에 대기자 명단을 해소했다. 일일 온보딩 용량은 600배 증가했다.
압박 속의 깔끔한 엔지니어링이었다. 비용은 2년 동안 따라다니게 될 다중 generation 라우팅 로직이었다.
그다음 두 차례의 주요 마이그레이션이 있었다:
2024년 5월 — pod 아키텍처에서 서버리스로. 스토리지와 컴퓨트가 분리되었다. 비용은 즉시 50% 감소했고, generation 라우팅 복잡성도 함께 사라졌다 — 용량이 더 이상 사전에 계획해야 하는 유한한 자원이 아니게 되었기 때문이다.
2024년 말부터 2025년 초까지 — 그들의 서버리스 제공업체에서 turbopuffer로. 데이터가 벤더의 독점 스토리지 시스템에 저장되어 있었기 때문에, 전환에는 전체 재인덱싱이 필요했다. 그들은 이 기회를 활용해 임베딩 모델도 업그레이드했다.
2025년 중반: 그들은 Page State를 출시했다. 모든 텍스트 span은 xxHash(64-bit)로 해시되어 DynamoDB에 저장된다. 페이지가 업데이트되면, 시스템은 재임베딩 여부를 결정하기 전에 해시를 비교한다. 메타데이터만 변경된 경우에는 벡터를 다시 계산하지 않고 벡터 데이터베이스를 직접 패치한다.
얼마 지나지 않아 임베딩 생성은 Spark + external API에서 Ray via Anyscale 기반의 자체 호스팅 모델로 옮겨갔다. CPU 전처리와 GPU 추론이 이제 하나의 파이프라인에서 실행되며, 시스템 간 S3 핸드오프가 제거되었다.
2년. 다섯 번의 큰 베팅. 비용은 정점 대비 90% 감소. 진정으로 인상적인 여정이다.
이것은 빅데이터가 이미 들려준 이야기다
각 단계마다 나는 주석을 달고 싶어졌다: 빅데이터 생태계는 이것을 [연도]에 해결했다. 이는 우연이 아니다. 같은 제약은 같은 아키텍처적 움직임을 낳는다.
1. 스토리지-컴퓨트 분리와 서버리스: 존재가 아니라 작업에 비용 지불하기
Notion의 두 차례 비용 마이그레이션 — pod 클러스터에서 서버리스로, 그리고 객체 스토리지 기반 서버리스 설정으로 — 는 하나의 아키텍처적 움직임으로 읽을 수 있다. 인프라가 존재하는 데 비용을 지불하는 것을 멈추고 실제 작업에 비용을 지불하기 시작하는 것이다. 워크스페이스가 활발히 쿼리되고 있든 몇 주 동안 유휴 상태였든, 이전 모델은 클러스터를 계속 실행하고 과금되게 했다.
이렇게 보면 핵심 변화는 스토리지와 컴퓨팅의 분리입니다. 인덱스는 객체 스토리지에 있고, 콜드 컬렉션은 컴퓨팅을 거의 보유하지 않으며, 핫 컬렉션은 필요할 때 로드되고, 지출은 실제 사용량을 훨씬 더 밀접하게 추적합니다. 빅데이터에서 이것은 단순한 HDFS에서 S3로의 교체가 아니었습니다. 스토리지-컴퓨팅 통합에서 스토리지-컴퓨팅 분리로의 더 광범위한 이동이었습니다.
순서가 중요했습니다. 먼저, 독립적 확장이 탄력성과 용량 계획의 고통을 해결했고, 그다음 일시적 컴퓨팅과 영구 객체 스토리지가 사용 비용을 줄였습니다. Hadoop의 기본 배포는 데이터 지역성을 위해 스토리지와 컴퓨팅을 함께 배치했기 때문에 독립적 확장이 어려웠습니다. 데이터가 S3로 이동한 뒤에는 Spark 클러스터가 작업별로 생성되고 이후 종료될 수 있었으며, 스토리지는 영구적으로 유지되었습니다.
트레이드오프 또한 구조적입니다. 객체 스토리지 접근은 콜드 스타트 지연 시간의 하한선을 만듭니다. 여러 GET 요청, 역직렬화, 인덱스 재구성이 필요하기 때문입니다. 이는 매개변수 튜닝 문제라기보다 스토리지 물리학의 문제에 가깝습니다. 대부분의 워크스페이스가 드물게 쿼리되는 Notion의 현재 워크로드에서는 좋은 트레이드오프입니다. 하지만 AI 사용이 심화되면서 두 가지 한계는 무시하기 더 어려워집니다. 지속적으로 높은 쿼리량을 가진 대형 테넌트, 그리고 사용자가 콜드 워크스페이스로 돌아와 꼬리 지연 시간이 사용자에게 드러나는 경우입니다. 그 시점에서는 단일 계층 S3 네이티브 캐싱만으로는 충분하지 않은 경우가 많으며, 웜 데이터를 로컬 SSD에 유지하는 것이 실질적으로 더 중요해집니다.
2. Lambda Architecture: 실시간은 필요이고, 단편화는 비용이다
Notion의 인덱싱 시스템은 두 경로로 실행됩니다. 대규모 백필을 위한 오프라인 Spark 파이프라인과 실시간 업데이트를 위한 Kafka 컨슈머입니다. 이는 전형적인 Lambda 설정입니다.
데이터 신선도를 중요하게 생각한다면 이 설계는 자연스러운 출발점입니다. 문제는 이후에 벌어지는 일입니다. 동일한 로직이 여러 시스템에 퍼지기 시작하고, 팀은 경로 간 일관성을 유지하는 데 더 많은 시간을 쓰게 됩니다.
Notion의 경우, 그 분리는 이제 Spark, Kafka 컨슈머, Page State용 DynamoDB, 임베딩용 Ray, 그리고 별도의 서빙 계층에 걸쳐 있습니다.
각 컴포넌트는 제 역할을 하고 있습니다. 숨겨진 세금은 통합 표면입니다.
- 더 많은 글루 코드
- 더 많은 상태 전달
- 오프라인과 온라인 동작 간 드리프트 가능성 증가
이 중 많은 부분은 서빙을 위한 폐쇄형 스토리지 때문에 증폭됩니다. 제공업체 마이그레이션은 전체 재인덱싱을 의미합니다. 부분 업데이트 지원은 외부 추적 테이블을 의미합니다. 오프라인 개선은 또 다른 동기화 단계가 완료되기 전까지 온라인 검색에 도움이 되지 않습니다.
Kappa의 핵심은 단순합니다. 하나의 처리 모델입니다. 더 강한 형태는 One Engine입니다. 배치와 스트리밍을 서로 붙여놓은 두 시스템이 아니라, 하나의 시스템이 가진 두 가지 모드로 보는 것입니다.
바로 이 지점에 Lakebase가 들어맞습니다. Lakebase는 이 One Engine 아이디어를 lake-native 기반으로 가져와 OLTP/OLAP 간극을 연결함으로써, 실시간 업데이트, 온라인 서빙, 오프라인 처리가 단일 테이블에서 실행되도록 합니다.
3. 빠진 계층: 벡터 연산을 위한 선언적 인터페이스
Spark + 외부 임베딩 API에서 통합 Ray 파이프라인으로의 이동은 올바른 선택입니다 — S3를 통해 통신하던 두 시스템을 단일 컴퓨팅 그래프로 축소하는 것은 실제적인 단순화이며, 예상되는 90% 이상의 임베딩 비용 절감은 진정한 아키텍처 개선을 반영합니다. 하지만 이는 인프라 배선 수준에서의 단순화이고, 여전히 빠져 있는 것은 의미론적 수준의 단순화입니다.
Hadoop 시대에는 데이터로 무언가를 하려면 MapReduce 작업을 작성해야 했습니다. Mapper와 Reducer의 수명주기, 셔플이 어떻게 동작하는지, 실패를 어떻게 처리하는지, 단계를 어떻게 연결하는지 이해해야 했습니다. Hive는 선언적 계층을 추가했습니다. SQL로 원하는 결과를 표현하면, 시스템이 그것을 MapReduce 실행으로 바꾸는 방법을 알아서 결정합니다. 그 변화는 단지 작업을 더 빠르게 만든 것이 아니었습니다. 애초에 누가 데이터로 작업할 수 있는지를 바꾸었고, 새로운 데이터 작업의 엔지니어링 비용을 분산 시스템을 작성하는 비용보다 쿼리를 작성하는 비용에 훨씬 더 가깝게 만들었습니다.
하지만 벡터 및 비정형 데이터에는 아직 이 계층이 없습니다.
- 모델 학습 실행 전에 10억 개 벡터 코퍼스를 중복 제거하려면, Spark 잡을 작성하고, 적절한 거리 계산 연산자를 선택하고, 출력 형식을 관리하며, 결과를 서빙 계층이 있는 곳으로 다시 전달하는 방법을 알아내야 합니다.
- 수억 개 문서 전반에서 하나의 임베딩 모델을 더 새로운 모델로 업그레이드하려면, 백필 파이프라인을 구축하고, 전환 기간 동안 기존 임베딩과 새 임베딩이 공존하도록 관리하며, 이후 정리 작업을 해야 합니다 — 그리고 이 과정은 일상적인 작업이라기보다 수개월짜리 엔지니어링 프로젝트입니다.
- 세션 전반에 걸쳐 압축된 사용자 메모리를 유지하려면, 압축 로직을 설계하고, 버전 관리된 쓰기를 관리하며, 출력을 검색 경로에 수작업으로 연결해야 합니다. 이 모든 것은 데이터 작업이라기보다 시스템 엔지니어링 프로젝트입니다.
선언형에 해당하는 방식은 의도를 표현하는 것입니다 — "cosine tolerance 0.05로 이 컬렉션을 중복 제거하고 결과를 다시 쓰기", "이 새 모델을 사용해 임베딩 백필하기", "90일이 지난 상호작용 이력을 밀집 메모리 표현으로 압축하기" — 그리고 시스템이 실행 계획, 리소스 관리, 일관성을 처리하게 하는 것입니다. 바로 그 계층이 Context Engineering을 매번 맞춤형 엔지니어링 프로젝트가 아니라 규모 있게 다룰 수 있게 만듭니다. 그리고 이는 서빙 백엔드와 관계없이 현재 벡터 인프라 스택에는 여전히 대체로 빠져 있습니다.
| Notion의 결정 | 아키텍처 패턴 |
|---|---|
| Pod 클러스터 → 서버리스 → 객체 스토리지 기반 서버리스 | 스토리지-컴퓨트 분리: 벡터 인덱스에 적용된 라이프사이클 분리 |
| 이중 경로 인덱싱 + Page State + generation routing | 실시간 우선 Lambda 설계: 빠른 최신성, 그러나 온라인/오프라인 경로 전반의 동기화 비용 증가 |
| Spark + S3 핸드오프 → Ray | 시스템 간 I/O 축소 — 하지만 그 위의 선언형 인터페이스 계층은 여전히 없음 |
빅데이터는 스토리지, 컴퓨트, 처리 의미론이 깔끔하게 분리되고 조합 가능한 아키텍처로 수렴하는 데 15년이 걸렸습니다. Notion은 그 대부분의 과정을 2년 만에 거쳤고, 이는 진정으로 인상적입니다. 아직 자리 잡지 못한 부분은 다음 2년을 구축하는 비용을 훨씬 더 낮춰줄 바로 그 요소입니다.
하지만 이것은 1장에 불과합니다
Notion이 해결한 모든 것은 하나의 AI 기능을 위한 인프라입니다.
이 모든 엔지니어링 — generation routing, provider migration, Page State, Ray 컴퓨트 통합 — 은 AI Q&A가 잘, 저렴하게, 안정적으로 동작하도록 만들기 위해 존재합니다. 그들은 그것을 해냈습니다. 이 하나의 기능을 위한 인프라는 이제 성숙했습니다. Notion은 AI 기능 하나만 출시하지 않을 것입니다.
그들의 다음 엔지니어링 포스트에서 예상하는 세 가지 문제
문제 1: 규모가 커질 때 서버리스 + 콜드/핫 분리의 한계
Notion의 현재 선택은 현재 워크로드에 좋은 절충안입니다: 수백만 개의 워크스페이스, 그중 대부분은 드물게 쿼리되며, S3 네이티브 경제성이 강하게 작동하는 환경입니다. 한계는 여기서 성능 상한이 조정 가능한 소프트웨어 노브보다 객체 스토리지 동작에 의해 더 많이 결정된다는 점입니다.
S3의 첫 바이트 지연 시간은 종종 10-100ms 범위에 있습니다. 콜드 인덱스는 쿼리 가능해지기 전에 여러 GET 요청과 역직렬화가 필요할 수 있습니다. 프로덕션에서 콜드 쿼리 p99는 수초 범위에 이를 수 있습니다. 이는 보통 모델 문제가 아니라 인덱스 워밍업 문제입니다.
주요 고충 지점은 예측 가능합니다.
- 첫째, 높고 지속적인 쿼리 볼륨을 가진 대형 테넌트는 단일 계층 캐싱의 한계를 느끼기 시작합니다.
- 둘째, 콜드 워크스페이스로 돌아오는 사용자는 눈에 띄는 지연 시간 급증을 경험할 수 있습니다. 다중 계층 캐싱(메모리 + 로컬 SSD + 객체 스토리지)은 단일 계층 설계로는 보통 바꿀 수 없는 방식으로 이 꼬리 지연의 형태를 바꿉니다.
청구 모델도 팀들을 놀라게 할 수 있습니다. 쿼리 워크로드가 아니라 namespace 크기 기준으로 과금되기 때문에, 개별 쿼리가 작은 하위 집합만 스캔하더라도 큰 워크스페이스는 비싸 보일 수 있습니다. 편향된 멀티테넌트 분포에서는 비용이 쿼리 수준의 직관과 어긋날 수 있습니다.
필터 recall은 ANN-plus-post-filter 접근 방식의 또 다른 잠재적 문제입니다. 필터가 좁을 때 — 페이지 유형, 협업자, 시간 범위 — 후보 풀이 너무 작아져 recall이 떨어질 수 있습니다. Notion이 필터링된 AI 검색 경로를 더 추가할수록, 이 트레이드오프는 더 자주 드러나는 경향이 있습니다.
따라서 그렇습니다, 현재의 트레이드오프는 좋습니다. 한계도 명확할 뿐입니다: 대형 테넌트와 cold-query latency가 첫 균열이 됩니다.
문제 2: 실시간/오프라인 분리는 계속 더 비싸지고 있습니다
Notion의 현재 스택: 오프라인 배치 처리를 위한 Spark + Airflow, 실시간 업데이트를 위한 Kafka consumers, 임베딩을 위한 Ray, 쿼리를 위한 Turbopuffer. 네 개의 시스템이 각자 맡은 일을 잘 수행하며, 모두 동일한 기본 데이터 — 사용자의 페이지 콘텐츠 — 위에서 동작합니다.
이것은 전형적인 형태의 데이터 사일로 구조입니다. 동일한 원본 데이터가 서로 다른 시스템에 의해 여러 view로 유지되고, 이를 동기화하는 책임은 애플리케이션 계층 로직에 있습니다. Page State의 xxHash + DynamoDB는 배치 처리 view와 실시간 view 간의 일관성을 유지하기 위해 정확히 존재합니다. 그 로직은 올바르지만, 그 복잡도는 AI 기능의 수에 선형적으로 비례해 증가합니다 — 새로운 기능이 추가될 때마다 실시간 경로와 오프라인 경로 전반에서 유지해야 하는 또 다른 동기화 로직 세트가 추가됩니다.
더 깊은 문제는 다음과 같습니다: 오프라인 처리는 동기화 단계 없이는 온라인 서빙을 직접 개선할 수 없습니다. Notion의 오프라인 파이프라인이 워크스페이스 내 문서들 사이의 강한 의미적 관계를 발견하더라도, 그 결과가 온라인 쿼리 로직이 읽을 수 있는 어딘가에 쓰이기 전까지는 AI Q&A 검색을 개선할 수 없습니다. 그 사이에는 시스템 경계가 있고, 거기에는 지연 시간과 일관성 리스크가 따릅니다.
이것이 데이터 플라이휠을 돌리기 어렵게 만드는 이유입니다: 온라인 사용에서 생성된 신호는 양방향으로 시스템 경계를 넘지 않고서는 오프라인 모델을 지속적으로 개선할 수 없습니다.
아키텍처적 해답은 OneData입니다: 온라인 서빙과 오프라인 처리가 동일한 기본 테이블을 공유합니다. 동기화해야 할 여러 view도 없고, 애플리케이션 계층의 일관성 로직도 없습니다. 하나의 Iceberg 테이블, 서로 다른 컴퓨트 모드, 같은 위치를 읽고 쓰는 구조입니다. 오프라인 계층은 온라인 계층을 더 똑똑하게 만들고, 온라인 계층은 오프라인 계층이 처리할 신호를 생성합니다. 플라이휠은 하나의 기반 위에서 작동합니다.
문제 3: 오프라인 컨텍스트 엔지니어링 — 진짜 해자가 만들어지는 곳
오늘날의 Notion AI: 사용자가 질문을 합니다 → 관련 chunk를 실시간으로 검색합니다 → LLM에 전달합니다 → 답변을 반환합니다. 이 파이프라인의 품질 상한은 인덱스에 무엇이 들어 있는지에 의해 결정됩니다.
오프라인 컨텍스트 엔지니어링이 메우는 격차는 쿼리 시점의 검색 품질이 아닙니다 — 쿼리가 도착하기 전에 무엇을 구축해 두었는지의 품질입니다.
Memory. Notion AI와의 모든 대화에는 신호가 담겨 있습니다: 사용자가 무엇에 관심이 있는지, 어떻게 일하는지, 어떤 지식이 그들에게 중요한지. 그 신호를 벡터화하고 검색 가능한 사용자 memory로 구성하는 것은 간단합니다. 유지하는 것은 그렇지 않습니다: 오래된 memory는 압축이 필요하고(6개월 전의 대화는 더 밀도 높은 표현이 되어야 합니다), stale memory는 업데이트가 필요하며(새 콘텐츠가 이전 기록과 모순될 때), 관련 memory는 계층적으로 구성되어야 합니다. 이 모든 것은 벡터 데이터에 대한 지속적인 오프라인 배치 처리입니다. 쿼리 시점에는 할 수 없습니다.
사전 계산된 지식 그래프. 매번 “이 쿼리와 관련된 문서는 무엇인가”를 새로 검색하는 대신, 오프라인 처리를 통해 워크스페이스의 의미론적 토폴로지 모델을 구축할 수 있습니다 — 어떤 문서들이 같은 개념을 다루는지, 어떤 의사결정에 의존성이 있는지, 아이디어가 시간에 따라 어떻게 진화해 왔는지. 그 모델은 AI가 이미 갖고 있는 컨텍스트가 되므로, 처음부터 새로 검색하는 것이 아니라 워크스페이스에 대한 이해를 바탕으로 추론하게 됩니다.
데이터 플라이휠. 어떤 검색 결과가 사용되었나요? 만족스러운 답변 없이 계속 반복되는 질문은 무엇인가요? 서로 다른 쿼리에서 반복적으로 참조되는 문서는 무엇인가요? 이러한 신호들은 오프라인에서 처리되어 검색을 지속적으로 조정할 수 있습니다 — 청킹 전략을 조정하고, 계속 관련성이 입증되는 지식을 부각하며, 사각지대를 식별합니다. 신호를 벡터 계층의 개선으로 변환하는 인프라가 있을 때에만 플라이휠은 돌아갑니다. 그렇지 않다면 그 신호들은 로그 파일 속 바이트에 불과합니다.
Notion은 존재하는 가장 흥미로운 AI 데이터셋 중 하나를 보유하고 있습니다: 수천만 개의 워크스페이스 전반에 걸쳐 의도적으로 조직된 구조화된 지식입니다. 이는 놀라운 원재료입니다. 하지만 데이터 해자는 데이터를 보유한다고 구축되는 것이 아니라 — 데이터를 지속적으로 역량으로 전환하는 인프라를 보유함으로써 구축됩니다. 그들의 현재 벡터 인프라는 온라인 서빙을 위해 설계되어 있습니다. 메모리 유지관리, 지식 그래프 사전 계산, 신호 처리 플라이휠 — 이는 현재 아키텍처에서 자연스러운 자리를 갖지 못하는 대규모 배치 문제입니다.
Lakebase 포지셔닝
이 시점에서 패턴은 명확합니다. 다음 병목은 단일 쿼리 엔진 결정이 아닙니다. 그것은 실시간 서빙과 오프라인 처리 사이의 간극입니다.
Vector Lakebase는 그 다리로 포지셔닝됩니다:
OLTP와 OLAP를 위한 하나의 통합 플랫폼: 실시간 서빙, 반복적 발견, 배치 분석이 동일한 레이크 네이티브 데이터 기반과 하나의 단일 진실 공급원 위에서 실행됩니다.
이중 경로 동기화 대신 하나의 증분 흐름. 변경 캡처, 재임베딩, 재인덱싱은 애플리케이션 글루 코드가 아니라 데이터 계층의 기능이 됩니다.
오프라인 인텔리전스가 온라인에 도달하는 하나의 장소. 메모리 압축, 백필, 품질 신호가 동일한 테이블에 다시 기록되고 서빙을 직접 개선합니다.
그것이 실질적인 Chapter 2입니다: 단순히 더 나은 검색이 아니라, 벡터 데이터를 위한 통합 운영 모델입니다.
Vector Lakebase는 기존 데이터 레이크 위에서 통합 벡터 저장, 처리, 서빙을 제공하는 Zilliz Cloud의 Chapter 2에 대한 해답입니다. 마이그레이션은 필요 없습니다. 계속 지켜봐 주세요.
계속 읽기
Introducing Loon: A New Storage Engine for Vector Data That Never Stops Changing
Loon is a new storage engine for Milvus 3.0 and Zilliz Vector Lakebase, built to manage evolving vector datasets with ColumnGroups, row ID alignment, and Manifests.
Introducing Zilliz Cloud Global Cluster: Region-Level Resilience for Mission-Critical AI
Zilliz Cloud Global Cluster delivers multi-region resilience, automatic failover, and fast global AI search with built-in security and compliance.
Context Engineering Strategies for AI Agents: A Developer’s Guide
Learn practical context engineering strategies for AI agents. Explore frameworks, tools, and techniques to improve reliability, efficiency, and cost.