법률 데이터는 일반적인 문서 검색과 조금 다릅니다.

한 번에 끝나는 평면적인 문서가 아니라,

법률 -> 장 -> 절 -> 조문으로 이어지는 계층 구조가 있고
조문끼리 서로 인용하고
같은 질의에서도 “비슷한 문장”만 찾는 것이 아니라 주변 맥락까지 함께 꺼내야 하는 경우가 많습니다

그래서 법률 검색에서 중요한 것은 단순한 벡터 검색 속도 하나가 아닙니다. 실제로는 세 가지가 함께 맞아야 합니다.

조문을 벡터로 저장했을 때 얼마나 작아지는가
top-k 유사도 검색이 얼마나 빠른가
검색 이후 계층/인용 관계와 본문을 붙여도 충분히 빠른가

이번 글은 그 질문에 답하기 위해 만든 법률형 벤치마크 결과를 정리한 기록입니다.

이 글이 시스템/성능 관점의 기록이라면, retrieval quality 관점의 다음 문제는 hierarchy-aware retrieval에서 이어집니다.

어떤 워크로드를 기준으로 봤나

이번 테스트는 완전히 추상적인 랜덤 벡터 벤치가 아니라, 한국 법률 코퍼스를 흉내 낸 스트레스 테스트를 기준으로 삼았습니다.

시나리오는 다음과 같습니다.

임베딩 차원: 1024d
조문 본문 길이: 대략 500B ~ 5KB
계층 구조: 법률 -> 장 -> 절 -> 조문
관계 그래프: HAS_CHILD, FOLLOWS, 조문 간 교차 인용/관련 관계
검색 패턴: 벡터 검색만이 아니라 graph_search + 조상 복원 + 인접 조문 + 본문 조회

먼저, 얼마나 작아지나

법률 데이터를 Vector DB화할 때 가장 먼저 드는 질문은 “그래서 저장 공간이 얼마나 늘거나 줄어드나?”입니다.

여기서는 벡터 payload만 따로 계산해 봤습니다. 즉:

포함: 벡터 본체
포함: SQ8에서 필요한 per-vector scale
제외: HNSW 그래프
제외: metadata
제외: 본문 저장소
제외: edge/CSR 인덱스

1024차원 기준으로 벡터 하나를 저장하는 데 필요한 공간은 대략 이렇습니다.

포맷	벡터 1개당 크기	설명
`F32`	`4096B`	1024차원 x 4바이트
`SQ8`	`1028B`	1024차원 x 1바이트 + scale 4바이트
절감률	약 `4x`	`F32` 대비

이걸 법률 벤치 규모에 맞춰 보면:

규모	조문 수	F32	SQ8	차이
단일 대형 법률	500	약 `2.05MB`	약 `0.51MB`	약 `1.54MB` 절감
10개 법률 코퍼스	5,000	약 `20.48MB`	약 `5.14MB`	약 `15.34MB` 절감

즉 법률 데이터처럼 조문 수가 쌓일수록, SQ8의 4배 압축은 꽤 직접적인 차이로 돌아옵니다.

중요한 점은 이 압축이 “메모리만 아끼는 장식”이 아니라는 것입니다. 실제 검색 속도까지 같이 좋아졌다는 점이 핵심입니다.

단일 법률 하나를 넣고 검색하면

첫 번째 시나리오는 대형 법률 하나를 통째로 넣는 경우였습니다.

구성:

조문 500개
내부 참조 edge 300개
각 조문은 약 2KB 수준의 한국어 텍스트

결과는 다음과 같았습니다.

작업	측정값
조문 500개 + edge 300개 ingest	`262.24ms`
`graph_search` top-10	`144us`
`graph_search` top-50	`221us`
상위 10개 결과의 `get_ancestors`	`11us`
상위 10개 결과의 `FOLLOWS` 조회	`2us`
상위 10개 결과의 본문 batch 조회	`9us`
검색 + 조상 + 인접 조문 + 본문 전체 파이프라인	`172us`
법률 하나 전체 삭제 (`delete_by_prefix`)	`32.74ms`

이 시나리오가 말해주는 것은 꽤 단순합니다.

단일 법률 규모에서는 “벡터 검색이 빠른가?”보다 “벡터 검색 뒤에 붙는 구조 탐색과 본문 조회까지 합쳐도 빠른가?”가 더 중요합니다. 이번 측정에서는 그 전체 파이프라인이 172us 수준이었습니다.

법률이 10개로 늘어나면

두 번째 시나리오는 더 현실적인 작은 코퍼스입니다.

구성:

법률 10개
법률당 조문 500개
총 조문 5,000개
법률 간 교차 참조 포함

결과는 다음과 같았습니다.

작업	측정값
5,000 조문 + cross-reference ingest	`1.96s`
`graph_search` top-10	`499us`
전체 retrieval pipeline	`508us`
법률 1개 삭제 (`delete_by_prefix`)	`27.69ms`
삭제 후 `graph_search` top-10	`579us`
법률 1개 재주입	`219.15ms`

흥미로운 점은 검색만 빠른 것이 아니라, “법률 하나를 뺐다가 다시 넣는” 운영 작업도 가볍다는 것입니다.

왜 SQ8이 중요했나

여기서 다시 포맷 이야기로 돌아가야 합니다.

법률 데이터를 Vector DB화한다고 해도, 결국 기본값으로 어떤 저장 포맷을 쓰느냐가 성능과 비용을 거의 다 결정합니다.

우리는 F32, SQ1, SQ4, SQ8, 그리고 실험적인 TQ4까지 비교했고, 최종적으로는 SQ8을 새 컬렉션의 기본값으로 보는 쪽으로 정리했습니다.

그 이유는 법률 데이터 같은 워크로드에서 특히 명확합니다.

F32는 단순하지만 크다
SQ1은 지나치게 공격적이라 기본값으로 쓰기 어렵다
SQ4는 작지만 1M에서는 너무 많은 성능을 내준다
SQ8은 압축, 속도, 품질 사이의 균형이 가장 좋다

포맷별 상세 비교는 FAISS에서 SQ8까지에서 볼 수 있습니다.

이번 벤치가 말해주는 것

1. 법률 데이터는 충분히 Vector DB화할 만하다

조문 500개, 5,000개 수준에서는 ingest와 검색, 구조 탐색, 본문 조회까지 포함한 전체 파이프라인이 매우 짧은 시간 안에 끝났습니다.

2. 압축은 실제 비용과 성능에 바로 연결된다

SQ8은 단순히 예쁜 압축률 표를 만드는 포맷이 아닙니다. 법률처럼 조문이 쌓이는 데이터에서는 저장 공간을 4배 줄이면서도 검색 성능을 충분히 유지할 수 있는 실용적인 선택지였습니다.

3. 운영 관점에서도 다루기 쉽다

법률 하나를 prefix로 삭제하고 다시 넣는 흐름이 짧은 시간 안에 끝난다는 점은, 실제 개정 반영이나 재색인 운영에서도 의미가 큽니다.

최종 요약

법률 데이터를 Vector DB로 만들면 무엇이 달라지느냐는 질문에 대한 짧은 답은 이렇습니다.

조문 단위로 잘게 쪼개도 검색이 충분히 빠르다
계층 구조와 인용 관계까지 함께 다뤄도 파이프라인이 짧다
SQ8을 쓰면 벡터 저장 공간을 약 4배 줄일 수 있다
지금 기준으로는 SQ8이 법률형 워크로드에서도 가장 현실적인 기본 포맷이다

한 문장으로 줄이면:

법률 데이터의 Vector DB화는 “가능한가”의 문제가 아니라, 이제는 “어떤 포맷이 가장 실용적인가”의 문제에 가깝습니다.