健適文化(켄테쿠분카)라는 회사를 운영하고 있습니다. 사내 문서가 어지럽게 흩어져 있어 검색할 수 없거나, AI에게 물어봐도 제대로 된 답변이 돌아오지 않는 등의 과제에 대해, 회사의 지식 베이스(Knowledge Base)를 처음부터 구축하는 것을 돕고 있습니다. 이 기사는 그 과정에서 얻은 지견을 정리한 것입니다.

먼저 결론부터

사내 문서를 벡터 DB(Vector DB)에 집어넣고 RAG를 구축했는데도 정밀도가 나오지 않는 문제의 원인은 '넣는 방식'에 있습니다. 가공되지 않은 문서를 그대로 전달하는 것이 아니라, LLM이 소화할 수 있는 입도(Granularity)까지 단계적으로 가공한 뒤 전달해야 합니다. Anthropic이 컨텍스트 엔지니어링 (Context Engineering)의 맥락에서 progressive disclosure라고 부르는 설계 사상이며, Karpathy 씨가 제창하는 LLM Wiki도 Pinecone의 Nexus도, 끝까지 파고들면 이곳으로 수렴합니다.

실제로 자신의 클라우드 스토리지(약 20만 파일)에서 테스트해 본 결과, 체감 수준에서 검색 정밀도가 크게 향상되었습니다.

이 기사에서 다루는 내용

왜 '그냥 집어넣기만 해서는' 정밀도가 나오지 않는가

사내 문서를 벡터 DB에 넣고 RAG를 구축했는데도 제대로 된 답변이 돌아오지 않는 경험, 다들 한 번쯤 해보지 않으셨나요? 저 역시 그랬습니다.

원인은 대개 넣을 문서의 선택 문제가 아니라, 넣는 방식에 있습니다. 흔히 발생하는 실패 패턴을 살펴보겠습니다.

긴 문서를 그대로 투입하는 케이스. 예를 들어 다음과 같은 청크(Chunk)가 생성됩니다.

제3장 시스템 설계
3.1 개요
본 시스템은 전장에서 언급한 요건에 기반하여...

'전장에서 언급한 요건'이 무엇인지 이 청크만으로는 알 수 없습니다. 문맥 의존적인 표현이 그대로 남아 있기 때문입니다.

반대로 너무 잘게 나누는 케이스도 있습니다.

- 인증에는 JWT를 사용한다

이것만 추출하면 어떤 시스템의, 어느 엔드포인트(Endpoint)의 인증인지 정보가 사라집니다.

또 하나 까다로운 것은 동일한 개념이 여러 문서에 흩어져 있는 패턴입니다. 배포 절차가 5개의 파일에 분산되어 있어, 어떤 것이 최신인지 모르는 상태로 벡터 DB에 들어가 있는 경우입니다. 이는 LLM이 모순된 정보를 수집하게 만드는 원인이 됩니다.

Karpathy 씨의 LLM Wiki라는 사고방식

Andrej Karpathy 씨가 2026년 4월 GitHub Gist에 공개한 LLM Wiki라는 설계 패턴이 있습니다. LLM에는 LLM을 위한 정보 전달 방식이 따로 있다는 생각을 구체적인 메커니즘으로 구현한 것입니다.

인간을 위한 문서는 앞에서부터 순서대로 읽는 것을 가정하고 작성됩니다. '전장에서 언급한 바와 같이', '위의 요건에 기반하여'와 같은 표현이 당연하게 등장합니다. 읽는 사람이 문맥을 알고 있다는 전제가 깔려 있기 때문입니다.

LLM은 그렇지 않습니다. 문서를 청크(Chunk)라는 파편으로 나누어 처리합니다. 앞뒤의 연결은 기본적으로 상실됩니다. 따라서 어떤 청크를 단독으로 추출하더라도 의미가 통하도록 작성되어 있지 않다면, 검색에서 올바른 파편을 찾아내더라도 답변의 정밀도는 올라가지 않습니다.

3층 아키텍처 (Three-layer Architecture)

Karpathy 씨가 제안하는 것은 가공되지 않은 문서를 그대로 검색 대상으로 삼는 것이 아니라, 일단 LLM에게 읽혀서 '컴파일(Compile)'하고, 정리된 Wiki 페이지 군으로 유지하는 구조입니다. 그의 Gist에 공개된 설계에서는 세 개의 층으로 나뉩니다.

초기 RAG, 이른바 Naive RAG는 쿼리(Query)가 발생할 때마다 생문서를 검색하여 그 자리에서 답변을 합성하는 구성이었습니다. 2023년 이후 Self-RAG나 CRAG와 같은 자기 수정형, Anthropic의 Contextual Retrieval처럼 청크에 문맥을 부여하여 검색 실패율을 최대 67%까지 줄이는 수법 등 RAG 자체도 크게 진화하고 있습니다. 다만, 이러한 Advanced RAG에서도 쿼리 시점에 검색 및 해석하는 구조는 변하지 않습니다. LLM Wiki는 이 부분을 근본적으로 바꿉니다. 소스를 추가하는 시점에 지식을 구조화하고, 상호 링크된 페이지 군으로 축적합니다. 답변은 이미 정리된 지식 위에 구축되므로, 같은 질문을 반복해도 매번 처음부터 다시 찾을 필요가 없습니다. 지식이 쌓여가는 메커니즘입니다.

ingest / query / lint의 세 가지 작업

운용은 ingest, query, lint의 세 가지 작업으로 이루어집니다.

ingest는 새로운 소스를 가져오는 작업으로, LLM이 문서를 읽고 요약 페이지를 만들며, 관련 엔티티(Entity) 페이지를 업데이트하고 인덱스(Index)에 추가합니다. 하나의 소스가 10~15개의 페이지에 영향을 미치기도 합니다. query는 Wiki 내의 페이지를 검색하여 답변을 합성하는 작업으로, 참조 출처를 명시하며 답을 반환합니다. lint는 정기적인 유지보수로, 모순 탐지, 오래된 기술 내용 확인, 고립된 페이지 발견 등을 LLM에게 맡깁니다.

Pinecone Nexus도 같은 방향을 가리키고 있다

이러한 문제는 Pinecone이 최근 공개한 블로그 게시물에서도 지적되었습니다. 그들의 주장은 명쾌합니다. 모델을 개선하더라도 에이전트(Agent)가 똑똑해지지는 않으며, 지식을 전달하는 방식을 바꿔야 한다는 것입니다.

Pinecone이 발표한 Nexus라는 메커니즘에서는 쿼리(Query) 시점에 문서를 검색하는 것이 아니라, 사전에 소스 데이터를 "컴파일(Compile)"하여 태스크 특화형 아티팩트(Artifact)로 준비합니다. 에이전트가 받는 것은 가공되지 않은 생(Raw) 문서가 아니라, 타입(Type)이 지정되고 출처가 명시되었으며 태스크에 맞춰 구조화된 지식입니다. 에이전트 측은 KnowQL이라는 선언적 쿼리 언어를 통해 아티팩트를 가져옵니다. Karpathy 씨의 gist와는 구현 레이어가 다르지만, "검색할 때마다 매번 생 문서를 해석하게 하는 것은 낭비다"라는 근본적인 생각은 같습니다.

실전에서 효과를 본 두 가지 원칙

이러한 실패 패턴과 그 배경을 바탕으로, 실전 속에서 도달한 설계 원칙이 있습니다. 청크(Chunk)의 자기 완결성(단독으로 의미가 통하는 것)은 전제 조건이며, 그 너머에서 차이를 만든 것은 다음 두 가지였습니다.

원칙 1: 입도(Granularity)의 통일

한 청크에는 하나의 개념만 넣습니다. 로그인 처리 개요와 비밀번호 재설정 사양을 같은 청크에 넣으면, 검색에서 한쪽을 목표로 호출했을 때 다른 쪽이 노이즈(Noise)가 됩니다. 기준은 청크당 약 200~400 토큰 정도입니다.

원칙 2: 문맥의 명시

청크의 서두에 무엇에 관한 것인지, 어떤 시스템의 것인지, 어느 시점의 정보인지를 적어둡니다.

[대상: 수발주 API v2] 인증 사양
이 API는 Bearer 토큰 인증을 사용한다 (2024년 3월 이후 사양).
토큰 유효 기간은 24시간. 리프레시 엔드포인트는 /auth/refresh.

정리 작업 자체를 LLM에게 시키기

실전에서 가장 효과적이었던 것은 이 정리 작업 자체를 LLM에게 시키는 것이었습니다.

Google Drive, Notion, Confluence 등에 흩어져 있는 기존 문서들을 LLM에게 전달하여 지식 베이스(Knowledge Base)용으로 재구성하게 합니다. Karpathy 씨의 ingest 작업을 간이 형태로 재현하는 방식입니다. 프롬프트는 다음과 같은 형태가 됩니다.

다음 문서를 LLM이 검색 및 참조하기 쉬운 지식 베이스용으로 재구성해 주세요.
조건:
- 각 청크는 200~400 토큰 정도
...

사람이 하는 것보다 빠르고 품질도 안정적입니다.

실제로 해본 결과

자신의 클라우드 스토리지에서 실제로 테스트해 보았습니다. 약 20만 개의 파일로, 흔히 말하는 "어질러진 스토리지" 그 자체였습니다. 폴더 구조는 일단 존재하지만 형식적으로만 남아 있고, 같은 내용의 파일이 여러 버전으로 존재합니다. 업무 메모와 개인적인 조사 내용, 프로젝트 자료가 혼재되어 있으며, 명명 규칙(Naming Convention)도 없어 열어보지 않으면 내용을 알 수 없습니다. 몇 년 동안 손대지 않은 오래된 파일도 대량으로 남아 있습니다. 짐작 가는 분들이 많으실 것입니다.

결과적으로 RAG의 히트율(Hit rate)은 그대로 밀어 넣었을 때와 비교해 체감상 크게 향상되었습니다. "그 파일이 어디 있더라" 하며 찾아 헤매는 시간이 거의 사라졌습니다. 유료 검색 서비스를 구독하는 것보다 저렴하게, 자신의 용도에 맞는 형태로 구현할 수 있었습니다.

단, "체감상 향상되었다"는 정량적인 평가가 아닙니다. 본래는 RAGAS나 DeepEval 같은 프레임워크를 사용하여 faithfulness(충실도)나 context precision(문맥 정밀도)을 측정해야 합니다. 30~50문항 정도의 골든 세트(Golden Set)를 준비하여 평가 기반을 먼저 구축하는 것이 올바른 순서이며, 이는 향후 과제로 남아 있습니다.

흔한 오해

ChromaDB나 Pinecone을 사용하면 해결될 것이라는 기대가 있지만, 벡터 DB(Vector DB)에 하이브리드 검색(Hybrid Search)이나 리랭킹(Reranking) 기능이 아무리 잘 갖춰져 있어도, 입력하는 청크(Chunk)의 질이 낮으면 정확도를 낼 수 없습니다. Pinecone 스스로가 Nexus를 통해 "벡터 DB 위에 지식을 추가로 컴파일하는 층이 필요하다"라고 말하기 시작한 것은 상징적입니다. Nexus는 벡터 DB를 대체하는 것이 아니라, 그 위에 올라가는 부가적인(additive) 층으로서 설계되었습니다.

문서가 많을수록 좋다는 오해도 있습니다. 오히려 오래된 정보, 중복, 모순이 정확도를 떨어뜨립니다. 정리하여 불필요한 것을 깎아내는 것이야말로 정확도 향상의 핵심입니다.

한 번 만들면 끝나는 것도 아닙니다. 문서가 업데이트될 때마다 그에 대응하는 청크도 업데이트하는 메커니즘이 필요합니다. 지식 베이스(Knowledge Base)는 계속해서 운용하는 것입니다. Karpathy 씨의 설계에 린트(lint) 작업이 포함되어 있는 것도, 방치하면 열화된다는 전제에 기반하고 있기 때문입니다.

이 접근 방식의 한계

이렇게까지 써놓고 말하기 조심스럽지만, 유일한 방법은 없습니다.

LLM Wiki에도 약점은 있습니다. LLM이 Wiki 페이지를 생성하는 이상, 사실과 다른 기술이 섞여 들어갈 가능성은 사라지지 않습니다. 까다로운 점은, 한 번 Wiki에 기록된 오류가 후속되는 인제스트(ingest)나 쿼리(query) 과정에서 "올바른 지식"으로 참조되어 정착되어 버린다는 것입니다. 일반적인 RAG라면 할루시네이션(Hallucination)이 채팅 응답 단계에서 종료되지만, LLM Wiki에서는 지식 베이스 자체가 오염됩니다. 린트(lint)로 검출할 수 있는 경우도 있지만, 린트를 실행하는 것 또한 LLM이기 때문에 동일한 종류의 오류는 놓치기 쉽습니다.

비용 문제도 있습니다. 하나의 소스를 인제스트(ingest)할 때마다 1015페이지가 업데이트되므로, 50편의 논문을 가져오면 100200회의 API 호출이 발생합니다. 개인의 지식 베이스라면 허용 범위 내이지만, 기업 규모에서 지속적으로 돌리게 되면 토큰 소비가 눈덩이처럼 불어납니다. Wiki가 수백 페이지로 성장하면 LLM이 전체를 조망할 수 없게 되어, 페이지 간의 미묘한 관련성을 포착하지 못하게 되는 벽도 존재합니다.

다만, 이는 설계를 통해 완화할 수 있습니다. 비용에 대해서는, 인제스트(ingest)의 영향 범위를 도메인별로 샤딩(sharding)함으로써 1회의 인제스트가 건드리는 페이지 수를 제어할 수 있습니다. 모든 페이지를 매번 스캔할 필요 없이, index.md의 카테고리 정보를 바탕으로 관련 도메인만을 업데이트 대상으로 삼으면 100200회가 2030회로 줄어듭니다. 컨텍스트 윈도우(Context Window)의 벽에 대해서는, Wiki 자체를 계층화하는 방법을 쓸 수 있습니다. 각 도메인에 요약 페이지를 두고, 쿼리 시에는 먼저 요약층을 검색하여 관련 도메인을 특정하고, 해당 도메인 내의 상세 페이지만을 컨텍스트에 넣는 방식입니다. Wiki가 1,000페이지가 되어도 1회의 쿼리에서 참조하는 것은 20~30페이지로 압축할 수 있습니다. 요컨대, Wiki 내부에도 점진적 공개(progressive disclosure) 구조를 만드는 것입니다.

Pinecone Nexus와 같은 컴파일형 접근 방식 또한 이제 막 등장했을 뿐, 아직 실적이 쌓인 단계는 아닙니다.

애초에 문서의 규모가 작다면 이러한 메커니즘을 구축할 필요조차 없을지도 모릅니다. 2026년 현재, Claude Opus 4.6이나 Gemini 3.1 Pro는 100만 토큰 이상의 컨텍스트 윈도우(Context Window)를 가지고 있습니다. 10만 토큰 이하의 문서 세트라면, 롱 컨텍스트 모델(Long-context model)에 그대로 전문을 전달하는 것이 RAG를 구축하는 것보다 빠르고 저렴할 수 있습니다. LLM Wiki나 RAG를 검토하기 전에, 먼저 롱 컨텍스트로 충분한지를 테스트해 볼 가치가 있습니다.

결국, 유일한 정답은 없다. 하지만 공통점은 보인다

다만, 잘 작동하는 기법들에는 공통점이 있습니다. Karpathy 씨의 LLM Wiki는 가공되지 않은 문서를 raw 층에 두고, 거기서 Wiki 페이지를 생성하며, 쿼리 시에는 Wiki만을 참조하는 3층 구조입니다. Pinecone Nexus는 소스 데이터를 사전에 컴파일하여 태스크 특화 아티팩트(artifact)로 만들고, 에이전트에게는 아티팩트(artifact)만을 전달합니다. 방식은 다르지만, 몇 가지 원칙을 공유하고 있습니다.

하나는 쿼리(query) 시점에 매번 가공되지 않은 문서(raw document)를 해석하게 하는 것이 아니라, 수집(ingestion) 시점에 지식을 컴파일(compile)해 두는 것. 또 다른 하나는 LLM에 전달하는 지식에 타입(type)·출처·구조를 부여하는 것입니다. Anthropic이 컨텍스트 엔지니어링 (context engineering) 블로그 게시물에서 언급한 점진적 공개 (progressive disclosure)도 같은 방향을 가리키고 있습니다. 에이전트가 모든 정보를 한꺼번에 컨텍스트 (context)에 채워 넣는 것이 아니라, 필요한 정보를 필요한 타이밍에 단계적으로 취득하여 이해를 계층별로 (layer by layer) 구축해 나가는 방식입니다.

도구나 기법에 유일한 정답은 없습니다. 하지만 설계 사상에는 정답이 있다고 생각합니다. 도메인 지식이 어떤 성질을 가지고 있는지 이해하는 것. 초기 단계에 평가 기반을 구축하는 것. 그리고 필요 최소한의 복잡성에서 시작하여 단계적으로 키워나가는 것. 이 세 가지입니다. 규모의 차이는 'LLM Wiki를 사용할 수 없는 이유'가 아니라 'Wiki 내부의 계층 설계(hierarchy design)를 바꿔야 하는 이유'일 뿐입니다. 20만 개의 파일로 이루어진 개인 저장소라면 단일 index.md로 운영할 수 있지만, 수백만 건의 기업 문서라면 도메인별 서브 Wiki로 분할하고 횡단 검색을 위한 메타 인덱스 (meta-index)를 배치해야 합니다. Karpathy 씨의 설계는 Markdown 파일과 LLM만으로 동작하기 때문에, 이러한 종류의 구조 변경을 저비용으로 시도할 수 있습니다.

유행하는 아키텍처 (architecture)를 쫓기보다, 이 순서를 지키는 것이 훨씬 확실합니다.

참고 자료

• Andrej Karpathy 「Deep Dive into LLMs like ChatGPT」 (LLM의 메커니즘 전체상)

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f - Pinecone 「Pinecone Nexus: The Knowledge Engine for Agents」

https://www.pinecone.io/blog/knowledge-infrastructure-for-agents/ - Pinecone 「Better Models Won't Save Your Agent」

https://www.pinecone.io/blog/introducing-nexus-knowledge-engine/ - Anthropic 「Effective context engineering for AI agents」 (progressive disclosure의 출처)

이 글에서 작성한 지식 베이스 (knowledge base) 구축을 자사에서 하고 싶지만 손이 닿지 않는 분들께. 켄테키 문화(健適文化)에서는 어질러진 Google Drive나 Notion을 정리하여, AI가 사용할 수 있는 형태의 지식 베이스로 만드는 일을 하고 있습니다. 상담은 𝕏의 DM 혹은 홈페이지의 폼을 통해 기다리고 있겠습니다.

Discussion