PrepStack에 처음 게시되었습니다.

모두의 첫 번째 RAG (Retrieval-Augmented Generation) 파이프라인은 문서(documents), 청킹(chunk), 벡터 DB(vector DB), LLM이라는 동일한 네 가지 단계로 구성됩니다. 이는 오후 한나절 만에 시연은 가능하지만, 실제 운영 환경에서는 오래된 답변, 관계성 부재, 거버넌스 결여, 그리고 파편화된 정보로 모델이 추측하는 문제 등을 일으키며 조용히 당신을 배신합니다. 해결책은 더 큰 벡터 인덱스(vector index)를 구축하는 것이 아닙니다. '문서'를 저장하는 것을 멈추고 '지식'을 저장하기 시작하는 것입니다. 그것이 바로 개방형 지식 포맷 (Open Knowledge Format, OKF)입니다.

제목이 의도적으로 도발적이기 때문에 미리 명확히 해두자면, OKF가 임베딩 (embeddings)을 없애는 것은 아닙니다. 벡터는 여전히 검색 (recall) 역할을 수행합니다. OKF가 없애는 것은 바로 '맹목적인 청킹 (blind chunking)'입니다. 즉, 불투명한 문서를 문맥이 없는 파편으로 잘게 쪼개고, 코사인 유사도 (cosine similarity)가 의미를 다시 재구성해주기를 바라는 방식입니다. 멀티 테넌트 마케팅 분석 SaaS인 Mattrx (.NET 9 + Azure SQL + Python FastAPI AI 서비스)에서는 맹목적인 청킹을 OKF + 컨텍스트 엔진 (Context Engine)으로 교체함으로써, 어시스턴트의 환각 (hallucination) 발생률을 18%에서 3%로, 오래된 답변 발생률을 11%에서 1.5%로 낮추었습니다.

요약 (TL;DR)

차원	문서 → 청킹 → 벡터 DB (이전)	OKF + 컨텍스트 엔진 (이후)
지식의 단위	불투명한 텍스트 청크	타입이 지정되고 거버넌스가 적용된 지식 단위
...

재구축 후 결과:

• 지식 베이스가 약 11,000개의 OKF 단위 (Markdown + 메타데이터 + 관계 + API + 스키마 + 비즈니스 규칙)로 재구조화되었습니다.
• 환각 (Hallucination) 18% -> 3%; 충실도 (faithfulness) 0.96; 답변 관련성 (answer-relevance) 0.91.
• 호출당 컨텍스트 토큰 (Context tokens/call) 14k -> 3.5k — 구조화 덕분에 엔진이 모든 것이 아닌 '적절한' 것만을 연결할 수 있습니다.
• 오래된 답변 비율 11% -> 1.5% (valid_until + 메타데이터 신선도).
• 멀티홉 질문 (Multi-hop questions) 답변 불가 -> 답변 가능 (그래프 검색을 통해).
• 폐기된 계획 추천 반복 발생 -> 0 (비즈니스 규칙이 데이터로서 강제됨).

단 하나의 사고방식 전환: 청크(chunk)는 정체성도, 소유자도, 만료일도 없는 텍스트의 파편일 뿐입니다. 반면 OKF 단위는 컨텍스트 엔진(context engine)이 추론할 수 있는 관리되고(governed), 타입이 지정되며(typed), 연관된(related) 지식의 조각입니다. 텍스트를 인덱싱하는 것을 멈추십시오. 지식을 인덱싱하기 시작하십시오.

파트 1 — OKF 지식 베이스 (Knowledge Base)

1. 문서에서 지식 단위로. 청크에는 정체성이 없습니다. 누가 소유하는지, 언제 만료되는지, 무엇과 연관되는지 말할 수 없습니다. OKF의 원자 단위(atomic unit)는 Markdown 본문에 id, type, owner, version, valid_from / valid_until, visibility와 더불어 relationships, apis, schemas, business rules와 같은 구조화된 프론트매터(frontmatter)가 결합된 형태입니다. 본문은 여전히 임베딩(embedded)되지만, 엔진이 필터링하고 순위를 매기는 대상은 바로 이 메타데이터입니다. 단위에 valid_until이 지정되는 순간, 엔진은 만료된 지식에 근거하여 답변하는 것을 거부할 수 있으며, 이를 통해 구식 답변이 제공되는 비율을 **11% -> 1.5%**로 낮추었습니다.

2. 관계(Relationships)와 스키마(schemas): 지식 그래프 (Knowledge Graph). 청크는 고립된 섬과 같습니다. 벡터 유사도(vector similarity)는 연결된 텍스트가 아니라 비슷하게 들리는 텍스트를 찾아낼 뿐입니다. OKF는 관계(relates_to, supersedes, governed_by, depends_on)를 일급 객체(first-class)로 만들고, 구조화된 단위를 위한 스키마를 정의하여 코퍼스(corpus) 전체에 걸친 지식 그래프를 구축합니다. 그래프 검색(Graph retrieval)은 의미론적 시드(semantic seeds)에서 시작하여 이러한 관계(edges)를 따라 확장됩니다. 이를 통해 "Growth 고객이 사이클 중간에 요금제를 다운그레이드하면 어떻게 일할 계산(prorated)되나요?"(세 개의 문서에 걸쳐 있는 답변)와 같은 질문에 답할 수 있게 되었습니다. 벡터가 문을 찾는다면, 그래프는 건물 안을 걸어 다닙니다.

3. API와 비즈니스 규칙 (Business rules): 데이터로서의 실시간 데이터와 거버넌스. "우리의 요금제는 Starter, Growth, Scale입니다..."와 같은 스냅샷은 카탈로그가 변경되는 날 바로 틀린 정보가 되며, 문단 속에 적힌 규칙은 모델이 무시할 수 있는 제안에 불과합니다. OKF 단위는 API를 참조하며(관리되는 도구 계층을 통해 쿼리 시점에 해결됨), 이를 통해 답변이 현재 카탈로그를 반영하도록 합니다. 또한 엔진이 제약 조건으로 주입하는 비즈니스 규칙 단위(enforcement: hard)와 연결됩니다. "폐기된 요금제를 추천함"이라는 문제는 반복되는 불만 사항에서 0으로 줄어들었습니다.

Part 2 — 컨텍스트 엔진 (The Context Engine)

OKF가 지식이 _저장(stored)_되는 방식이라면, 컨텍스트 엔진 (Context Engine)은 지식이 프롬프트 (prompt)가 되는 방식입니다.

4. 검색 (Retrieval): 하이브리드 (hybrid) + 벡터 (vector) + 그래프 (graph). Top-k 코사인 유사도 (cosine similarity)는 하나의 신호일 뿐입니다. 이는 정확한 용어 일치(캠페인 ID, 에러 코드 등)나 유사하지는 않지만 연관된 단위들을 놓칠 수 있습니다. 엔진은 재현율 (recall)을 위해 하이브리드 검색 (hybrid search) (BM25 + 벡터), 뉘앙스를 위한 벡터 검색 (vector retrieval), 그리고 연결된 단위들을 위한 **그래프 검색 (graph retrieval)**을 실행합니다. 이 모든 과정은 테넌트 범위 (tenant-scoped)로 제한되며 현재 유효한 단위들로 필터링됩니다 (onlyValid: true, 메타데이터가 보안 및 품질 작업을 무료로 수행). 이러한 조합이 **18% -> 3%**의 환각 (hallucination) 감소와 0.96의 충실도 (faithfulness)를 달성한 핵심입니다.

5. 메모리 (Memory), 도구 호출 (tool calls), 프롬프트 조립 (prompt assembly). 메모리는 이미 알려진 정보를 제공하고, 도구 호출은 OKF 단위가 참조하는 실시간 데이터를 가져오며, 프롬프트 조립은 엄격한 토큰 예산 (token budget) 내에서 우선순위 순서에 따라 — 제약 사항 우선 (절대 생략 불가), 그다음 메모리, 그다음 순위가 매겨진 지식, 마지막으로 실시간 데이터 — 모든 것을 패키징합니다. 이 순서는 설계 결정 사항입니다. 예산 압박이 발생하더라도 답변의 준수성을 유지하는 규칙은 절대 조용히 누락되어서는 안 됩니다. 이것이 정확도가 _향상_되면서도 컨텍스트가 3.5k 토큰 (14k에서 감소) 수준을 유지할 수 있는 비결입니다.

OKF를 도입하지 말아야 할 때

이것은 구조에 대한 투자입니다. 구조가 존재하고 중요한 곳에 투자하십시오. 규모가 작거나 정적인 코퍼스 (corpus), 진정으로 비정형화된 지식, 작성 주체가 없는 경우(부패한 메타데이터는 없는 것보다 못합니다), 또는 일반적인 하이브리드 RAG + 교차 인코더 재순위화 (cross-encoder rerank)를 완벽히 구현하기 전에는 건너뛰십시오 (OKF는 첫 번째 단계가 아니라 다음 단계입니다). 그리고 한꺼번에 모든 것을 바꾸려 하지 마십시오. 가치가 높고 변화가 잦은 도메인부터 먼저 전환하십시오 (우리는 빌링을 시작으로 제품, 그 다음 런북 (runbooks) 순으로 진행했습니다). 나머지 긴 꼬리 (long tail) 영역은 일반적인 청크 (chunks)로 남겨두십시오.

그리고 제목에 대한 솔직한 프레임워크를 말씀드리자면: OKF는 임베딩 (embeddings)을 대체하지 않습니다. 벡터 검색은 여전히 재현율을 수행하며 컨텍스트 엔진 내부에 존재합니다. OKF는 _맹목적인 청킹 (blind chunking)_을 대체하며, 그래프 임베딩만으로는 제공할 수 없는 구조, 거버넌스 (governance), 그리고 관계성을 추가합니다. 만약 누군가 당신에게 "벡터의 시대는 끝났다"라고 말한다면, 그냥 떠나십시오.

지속해 나가야 할 모델

문서(Documents)는 당신이 가진 것이고, 지식(Knowledge)은 모델이 필요로 하는 것입니다. 모든 단위에 고유한 ID와 소유자, 그리고 만료일을 부여하고; 관계성은 명시적으로 모델링하며 (그래프가 벡터로는 구조적으로 답변할 수 없는 다단계 질문에 답합니다); 규칙을 산문(prose)이 아닌 데이터로 인코딩하십시오.

👉 **전체 기사 — 완전한 OKF 포맷, C# 레코드 및 그래프/검색/조립 코드, 엔드투엔드 쿼리 워크스루, 마이그레이션 체크리스트, 그리고