Hacker News가 다시 조명한 production RAG의 현실, local model로 451GB를 다루는 법

Hacker News는 Andros Fenollosa의 긴 회고 글을 다시 끌어올렸다. 많은 architecture demo보다 production RAG 뒤의 덜 화려한 engineering 작업을 훨씬 솔직하게 보여주기 때문이다. 프로젝트의 시작은 단순했다. 거의 10년에 걸친 회사 문서, OrcaFlex simulation 파일, 각종 기술 산출물을 대상으로 질문에 답할 수 있는 local-LLM assistant를 만드는 일이었다. 하지만 실제 과정은 깔끔한 framework tutorial이 아니었다. 451GB 규모의 heterogeneous data를 memory, storage, budget을 무너뜨리지 않고 searchable하게 만드는 다단계 작업이었다.

왜 이 글이 반응을 얻었나

Fenollosa는 RAG prototype에서 실제 deployment로 넘어가 본 사람이라면 익숙한 패턴을 적나라하게 설명한다. 초기 stack인 Ollama와 LlamaIndex는 toy experiment에서는 잘 작동했다. 하지만 실제 기업 문서 환경에서는 바로 한계를 드러냈다. video, simulation, backup, CSV, malformed document가 pipeline을 RAM exhaustion으로 몰아넣었다. 이후 가치 없는 file type을 걸러내고 office 문서를 plain text로 변환하자 indexing 대상이 54% 줄었고, 그제야 불가능해 보였던 첫 단계가 관리 가능한 수준으로 바뀌었다.

결과를 바꾼 전환점

가장 큰 architectural pivot은 기본 JSON 기반 indexing 흐름을 버리고 SQLite 위에 ChromaDB를 얹은 뒤, 문서를 한 번에 150개씩 batch 처리하는 방식으로 바꾼 점이었다. 이 변화 덕분에 중단된 작업을 재개하고 checkpoint를 유지하며, 깨지기 쉬운 monolith 대신 하나의 SQLite 기반 artifact로 vector store를 백업할 수 있었다. 하지만 software path를 정리한 뒤에도 throughput 문제는 남았다. laptop GPU만으로는 충분하지 않았다. 최종 indexing은 NVIDIA RTX 4000 SFF Ada가 장착된 임대 머신으로 옮겨졌고, 약 2주에서 3주에 걸쳐 738,470개의 vector와 54GB 크기의 ChromaDB index를 만들었다.

HN 독자들이 이 글에 반응한 이유는 RAG를 prompt 문제가 아니라 data pipeline 문제로 다시 위치시키기 때문이다. 최종 시스템은 빠르고 유용했지만, 그 전에 document triage, batch processing, checkpointing, monitoring, storage separation이 먼저 해결돼야 했다. 원본 파일은 Azure Blob Storage에 SAS link 형태로 남겨 두고, vector index와 local model만 더 작은 production 머신에 유지한 것도 같은 맥락이다. conference demo가 자주 생략하는 부분이 바로 여기다. 이 글은 reliable retrieval이 clever prompt phrasing보다 disciplined ingestion, failure tolerance, 그리고 지루하지만 중요한 운영 결정에 더 크게 의존한다는 점을 분명히 보여준다.