run-llama가 liteparse라는 오픈소스 문서 파서를 공개했다. 하루 만에 680개의 별. 숫자만 보면 그저 또 하나의 인기 저장소지만, 만든 주체가 LlamaIndex 팀이라는 사실이 이 소식의 결을 바꾼다. 이들은 이미 LlamaParse라는 클라우드 파서 SaaS를 운영 중이다. 그런데도 굳이 Rust로 별도 오픈소스를 짠 건, 두 개의 다른 문제를 두 개의 다른 도구로 풀겠다는 명확한 분리다.
liteparse가 푸는 문제는 "파일 변환"이 아니라 "지식 추출"에 가깝다. PDF를 markdown으로 떨궈주는 도구는 이미 차고 넘친다. RAG를 운영해본 사람이라면 진짜 병목이 어디인지 안다. 표의 헤더-셀 관계가 깨지는 순간, 그 위에 얹은 임베딩이 숫자를 엉뚱하게 인용하기 시작한다. 헤딩 계층이 평탄화되면 청크 경계가 의미 단위로 잘리지 않는다. 본문과 사이드바가 섞이면 검색 품질이 무너진다. 파서 한 줄을 바꾸는 게 임베딩 모델을 업그레이드하는 것보다 빠를 때가 자주 있다.
Rust라는 선택은 운영팀에 보내는 신호다. 단일 바이너리로 떨어지면 Lambda 콜드스타트, 쿠버네티스 사이드카, 온프레미스 워커 어디에 얹어도 의존성 트리를 끌고 다니지 않는다. Python wheel 충돌과 glibc 버전 지옥에서 벗어난다는 것만으로도 인프라팀에는 큰 이득이다. 동시에 PyO3 바인딩을 붙이면 LlamaIndex 본체에서 그대로 호출 가능하다. 자기네 핫패스의 전처리 단계를 갈아끼우려는 의도가 읽힌다.
흥미로운 건 클라우드와 오픈소스의 역할 분담이다. LlamaParse는 멀티모달 LLM을 동원해 스캔본·차트·복잡한 레이아웃까지 정확도를 끌어올리는 쪽이다. liteparse는 텍스트 레이어가 있는 문서를 빠르게, 로컬에서, 외부로 한 줄도 내보내지 않고 처리하는 쪽이다. 금융·의료·법무처럼 데이터를 외부 API로 보낼 수 없는 도메인에는 이 분리가 답에 가깝다. 두 파서를 같은 회사가 들고 있다는 사실이 오히려 신뢰의 근거가 된다. 한쪽이 다른 쪽을 잠식하지 않도록 설계한 흔적이 보인다는 뜻이다.
물론 680 stars/day는 초기 신호일 뿐이다. 실제 정확도는 자기 데이터셋으로 돌려봐야 안다. 스캔 PDF는 여전히 OCR 파이프라인이 별도로 필요하고, 복잡한 다단 레이아웃에서는 클라우드 멀티모달 쪽이 앞선다. 그럼에도 이 프로젝트가 던지는 메시지는 분명하다. LLM 시대의 파서는 "파일을 텍스트로 바꾸는 도구"가 아니라 "문서에서 검색 가능한 지식을 끌어내는 전처리기"로 재정의되고 있다는 것.