우리는 나쁜 AI 시스템을 만들지 않았습니다.

우리는 그저 그들에게 망가진 지식 지도를 주었을 뿐입니다.

지금 모든 이들이 AI 에이전트(AI agents)를 구축하고 있습니다.

데모는 엄청납니다:

• "내 회의 일정을 예약해줘."
• "내 매출을 분석해줘."
• "근본 원인을 찾아줘."

그러다 실제 기업에 이를 배포하면...

…불확실성 위에 확신을 가지고 환각(hallucination)을 일으키기 시작합니다.

모델이 나쁘기 때문이 아닙니다.

검색(retrieval)이 근본적으로 망가져 있기 때문입니다.

⚡ 요약 (TL;DR)

현재의 RAG:

유사해 보이는 것을 찾음

OKF:

실제로 연관된 것을 연결함

이 차이가 모든 것을 바꿉니다.

진짜 문제

이렇게 질문해 보세요:

"월간 활성 매출(Monthly Active Revenue)은 어떻게 계산되나요?"

그러면 다음과 같은 결과가 나옵니다:

• 대시보드 문서
• 온보딩 가이드
• 오래된 Confluence 페이지
• 무작위 SQL 파일

기술적으로 틀린 것은 없습니다.

하지만 무엇도 진정으로 맞지는 않습니다.

왜냐하면 검색(retrieval)이 다음을 기반으로 하기 때문입니다:

의미(meaning)가 아닌, 의미론적 유사성(semantic similarity)

RAG를 하나의 다이어그램으로 표현하면

Question
  ↓
Embedding
...

단순합니다.

하지만 위험할 정도로 불완전합니다.

왜냐하면:

시스템은 관계(relationships)를 전혀 이해하지 못하기 때문입니다.

오직 벡터 공간(vector space)에서의 근접성(proximity)만 따질 뿐입니다.

청킹(Chunking)의 함정

이 사례를 봅시다:

Revenue = Payments - Refunds

이제 이를 쪼개보겠습니다:

• 청크 1 → 공식
• 청크 2 → 환불 규칙
• 청크 3 → 예외 사항

이제 시스템은 파편들로부터 진실을 다시 조립해야 합니다.

때로는 작동합니다.

때로는 조용히 실패합니다.

그래서 우리는 다음과 같이 임시방편(patch)을 마련합니다:

• 더 많은 중첩(overlap)
• 더 많은 검색(retrieval)
• 더 많은 재순위화(reranking)
• 더 많은 에이전트(agents)
• 더 많은 연산(compute)

우리는 검색(retrieval)을 고친 것이 아닙니다.

그저 더 비싸게 만들었을 뿐입니다.

숨겨진 비용

검색(retrieval)이 확률적(probabilistic)일 때…

우리는 인프라로 이를 보완합니다.

Query
 → Vector Search
 → BM25
...

작동은 합니다.

하지만 이는 결여된 개념인 다음을 과잉 설계(overengineering)하는 것처럼 느껴집니다:

구조(structure)

OKF의 등장

다음과 같이 묻는 대신:

"무엇이 유사해 보이는가?"

OKF는 이렇게 묻습니다:

"무엇이 실제로 연결되어 있는가?"

이것이 전체 모델을 바꿉니다.

검색이 아닌 Wikipedia처럼 생각하라

Wikipedia가 유용한 이유는 문서(articles) 때문이 아닙니다.

링크(links) 때문입니다.

Newton
 → Calculus
 → Leibniz
...

지식을 _검색(retrieve)_하는 것이 아닙니다.

지식을 _탐색(navigate)_하는 것입니다.

문서(Documents) vs 지식 그래프(Knowledge Graph)

과거의 세계:

Revenue.pdf
Orders.pdf
Refunds.pdf

새로운 세계:

Revenue
 ├─ depends on Orders
 ├─ subtracts Refunds
...

추측은 없습니다.

추론(inference)도 없습니다.

오직 구조(structure)뿐입니다.

실제 사례

질문:

“어제 왜 매출이 감소했나요?”

RAG:

• 로그(logs)
• 대시보드(dashboards)
• 문서(docs)
• 장애 기록(incidents)

그다음 LLM이 인과관계를 추측합니다.

OKF 방식의 구조:

Revenue
 → Payment Service
 → Failed Transactions
...

이제 시스템은 추측하지 않습니다.

시스템은 탐색(traverse)합니다.

이것이 단순한 그래프 데이터베이스(Graph Database)인가요?

아닙니다.

하지만 서로 연관되어 있습니다.

Neo4j, Amazon Neptune, TigerGraph와 같은 그래프 데이터베이스는 관계를 효율적으로 저장하고 쿼리(query)합니다.

하지만 OKF는 다릅니다.

그래프 DB vs OKF

그래프 데이터베이스:

“관계를 어떻게 저장할 것인가?”

OKF:

“어떤 시스템이라도 이해할 수 있도록 관계를 어떻게 정의할 것인가?”

하나는 인프라(infrastructure)입니다.

다른 하나는 지식 표준(knowledge standard)입니다.

이렇게 생각해 보세요:

• HTML → 구조(structure)
• 브라우저(Browser) → 렌더러(renderer)
• 그래프 DB → 저장소(storage)

OKF는 **구조 계층(structure layer)**에 위치합니다.

이것이 중요한 이유

오늘날 기업의 지식은 파편화되어 있습니다:

• 문서(docs)
• 코드(code)
• API
• 대시보드(dashboards)
• 스프레드시트(spreadsheets)

우리는 AI가 확률(probability)을 사용하여 이를 통합하도록 강제합니다.

하지만 구조가 결여되면 확률은 무너집니다.

진짜 병목 현상(Bottleneck)

모델의 크기 문제가 아닙니다.

컨텍스트 윈도우(context windows) 문제도 아닙니다.

에이전트(agents) 문제도 아닙니다.

바로 이것입니다:

우리는 시스템에 지식이 어떻게 연결되는지 가르친 적이 없습니다.

마지막 생각

우리는 수년간 지능(intelligence)을 업그레이드하는 데 시간을 보냈습니다.

어쩌면 다음 도약은 구조(structure)를 업그레이드하는 것일지도 모릅니다.

세상에서 가장 똑똑한 모델이라 할지라도, 기록되지 않은 연결 고리는 따라갈 수 없기 때문입니다.

AI가 뇌라면...

OKF는 신경계(nervous system)가 될지도 모릅니다.

그리고 그것은 모든 것을 바꿀 것입니다.

AI 시스템, 검색 파이프라인(retrieval pipelines), 그리고 지식 인프라(knowledge infrastructure)를 구축하는 개발자분들과 언제든 소통할 준비가 되어 있습니다.

💼 LinkedIn: https://www.linkedin.com/in/kartikbuttan
💻 GitHub: https://github.com/kartik1112
🌐 Portfolio: https://kartik1112.github.io