Connect AI to Billions of Legal Documents — Simon Eskildsen, turbopuffer & Jacob Lauritzen, Legora

한 줄 핵심

Legora는 수십억 개의 법률 문서를 다루는 검색을 위해 인프라를 여러 번 갈아엎은 끝에, 프로젝트별·지역별·규제별 격리와 낮은 지연시간을 동시에 만족하는 turbopuffer 중심 구조로 정착했다.

시간별 요약

1. 0:00
   Legora가 하는 일과 두 가지 법률 검색 Legora는 계약 검토, 신규 계약 작성, 법률 리서치, 협업을 한 플랫폼에서 처리하는 법률용 AI 협업 도구다. 검색은 프로젝트 단위로 닫힌 문서 집합을 찾는 방식과, 판례·법령·규정 전체를 가로지르는 깊은 리서치 방식의 두 축으로 나뉜다.
2. 2:32
   하나의 검색 클러스터에서 지역별 분리로 처음에는 모든 검색과 인덱싱을 단일 Elasticsearch 클러스터와 단일 blob 저장소에 올렸고, 이후 미국·유럽·아시아태평양처럼 데이터 처리 지역 요건이 생기자 지역별로 Elasticsearch를 복제하는 구조로 바뀌었다. 이 방식은 단순하지만 운영 부담이 커지고 중복 구성이 늘어나는 한계가 있었다.
3. 4:00
   기업이 말하는 물리적 격리의 의미 대형 은행과 초대형 로펌은 데이터에 대한 완전한 물리적 격리와 고객 관리형 암호화 키를 요구한다. 즉, 각 고객의 데이터를 별도 DB처럼 취급하고, 고객이 키를 회수하면 복호화가 불가능해야 한다.
4. 4:48
   검색을 이미 쓰던 데이터베이스로 이동 기존에 OLTP용으로 쓰던 Postgress에 검색까지 얹기 위해 PG vector와 disk 기반의 TS vector를 사용했고, 문서 청크 테이블을 4,000개 파티션으로 극단적으로 분할해 프로젝트 키를 분산했다. 운영 시스템을 하나로 줄인 장점은 있었지만, 검색 성능과 비용 측면의 한계가 곧 드러났다.
5. 5:38
   뜨거운 프로젝트와 차가운 프로젝트가 캐시를 흔든 문제 자주 조회되는 프로젝트와 거의 조회되지 않는 프로젝트가 같은 파티션에 섞이면서 파티션 크기가 커지고, 조회 때마다 Postgress 캐시가 계속 밀려났다. 그 결과 검색과 적재의 P99가 100 milliseconds 수준에서 20 seconds까지 치솟아 사용자 경험이 크게 악화됐다.
6. 6:40
   프로젝트마다 namespace를 두며 해결한 것 turbopuffer로 옮긴 뒤에는 프로젝트별로 하나의 namespace를 두는 방식으로 바꿨고, 그 결과 BM25 기반의 검색 품질과 응답 지연이 크게 개선됐다. 하나의 turbopuffer 클러스터만 운영하면 되어 관리가 단순해졌고, 사용되지 않는 프로젝트는 blob에 둔 채로 둘 수 있어 비용도 줄었다.
7. 7:56
   객체 저장소로 직접 쓰기 turbopuffer는 쓰기 시 디스크 복제나 Paxos 없이 바로 S3 같은 object storage에 기록하는 구조를 택한다. 대신 읽기 성능을 지키기 위해 write-ahead log와 백그라운드 인덱싱을 사용하고, 조회는 memory cache, NVME SSD cache, object storage 순으로 최소 왕복 횟수로 처리한다.
8. 9:58
   암호화의 단위를 namespace로 두는 이유 namespace를 분리 단위로 삼으면 테이블마다 다른 키로 암호화하고, 버킷도 고객별로 나눌 수 있어 규제 산업의 격리 요구를 자연스럽게 만족한다. Legora는 SSD cache를 암호화해야 하는 상황에서 아예 disk cache를 꺼도 성능이 충분히 나와, 멀티테넌시와 데이터 분리를 더 깔끔하게 유지할 수 있었다.
9. 12:07
   법률 리서치와 100억 개 벡터 법률 리서치는 수십억~100억 개 벡터를 향해 가는 초대형 코퍼스를 다루며, 질의가 fan-out으로 여러 하위 질의로 늘어나 QPS가 급등할 수 있다. 법은 계층성, 시계열적 유효성, 예외 규정이 얽힌 구조라서, 관할권별 namespace 분리와 느린 cold blob 조회를 허용하는 설계가 잘 맞는다.
10. 14:25
    메모리 계층으로 데이터를 퍼뜨리는 방식 자주 조회되는 데이터는 메모리 쪽에, 덜 자주 쓰는 데이터는 더 아래 계층에 두는 것이 turbopuffer의 핵심 철학이다. 데이터가 어느 메모리 계층에 있어야 하는지를 조절해 round trip, 지연시간, 비용의 균형을 맞춘다.
11. 15:30
    객체 저장소에서 그래프보다 트리가 유리한 이유 벡터 검색을 graph로 구현하면 object storage나 디스크처럼 높은 지연의 저장소에서 노드 탐색마다 비용이 커진다. turbopuffer는 벡터를 클러스터의 클러스터로 묶어 tree 구조로 조직함으로써, 상위 centroid는 메모리 가까이에 두고 실제 데이터는 SSD에 두는 더 싼 방식으로 검색한다.
12. 17:45
    풀텍스트 검색이 실제로 동작하는 방식 풀텍스트 검색은 각 토큰을 해시맵 키로 두고, 그 값에 문서 ID 집합을 저장한 뒤 교집합을 계산하는 방식으로 동작한다. 검색 비용의 핵심은 round trip과 메모리 대역폭을 줄이는 것이며, 규모가 커질수록 풀텍스트 검색은 벡터 검색보다 더 복잡하고 비싸질 수 있다.

실무 인사이트

• 법률·금융처럼 규제가 강한 도메인에서는 검색 아키텍처를 성능보다 먼저 데이터 격리 단위로 설계해야 운영이 오래 간다.
• 프로젝트·관할권·테넌트 같은 자연스러운 경계가 있다면, 이를 namespace 단위로 그대로 모델링하는 것이 캐시 thrash와 권한 복잡도를 줄이는 가장 실용적인 방법이다.
• 대규모 검색 시스템의 병목은 단순 인덱싱보다도 저장 계층별 round trip과 캐시 배치에 있으므로, 읽기 패턴이 섞이는 구조를 먼저 의심해야 한다.