AI 네이티브 지식 공학 방법론에 대한 요청

게시 2026/01/13

By BLUEBUG

72 분읽는 시간

Fanghua Yu의 제안에 대한 심층 분석 및 비판적 평가

서론: 방법론 없는 혁명의 시대

A Call for an AI-Native Knowledge Engineering Methodology

2025년의 마지막 날, Fanghua (Joshua) Yu는 생성 AI 시대의 지식 공학이 직면한 근본적인 문제를 제기했습니다. ChatGPT가 세상을 놀라게 한 지 3년이 지난 지금, 우리는 강력한 도구들을 손에 쥐었지만 정작 그것을 체계적으로 사용할 방법론은 갖추지 못했다는 것입니다. 이 글은 그의 제안을 심층적으로 분석하고, 2025년 말 현재의 최신 연구 동향과 함께 비판적으로 평가합니다.

1부: 현재 상황에 대한 진단

폭발적 성장과 방법론의 부재

저자가 지적하는 첫 번째 문제는 RAG(Retrieval-Augmented Generation) 기술의 폭발적 성장과 그에 따른 혼란입니다. 2024년 한 해에만 1,200편이 넘는 RAG 관련 논문이 발표되었고, 300개가 넘는 “xRAG”라는 이름의 변형들이 등장했습니다. 2025년 말까지 이 숫자는 3배로 증가했습니다. 이는 분명 활발한 연구 활동을 보여주지만, 동시에 표준화의 부재와 파편화를 의미하기도 합니다.

최신 동향을 보면 이 문제는 더욱 심화되고 있습니다. 2025년 들어 Microsoft는 LazyGraphRAG를 발표하여 기존 GraphRAG의 인덱싱 비용을 0.1%로 줄이면서도 쿼리 비용 대비 700배 더 효율적인 성능을 보여주었습니다. AWS는 2025년 3월 Amazon Bedrock GraphRAG를 정식 출시하여 Neptune Analytics와의 통합을 통해 기업 시장에 진입했습니다. 하지만 이러한 발전에도 불구하고, 각 시스템은 여전히 독자적인 스키마와 추출 방식을 사용하고 있습니다.

현재 상황을 데이터 엔지니어링의 역사와 비교해보면 그 심각성이 더 명확해집니다. 관계형 데이터베이스가 등장했을 때 우리는 정규화 이론과 SQL 표준을 가지고 있었습니다. 데이터 웨어하우스가 필요해졌을 때는 Kimball의 차원 모델링 방법론이 있었습니다. 하지만 지금 우리는 수백 개의 서로 다른 구현체를 가지고 있으면서도, 그것들을 어떻게 설계하고 구축하고 관리해야 하는지에 대한 공통된 언어조차 없습니다.

세 가지 핵심 문제

저자는 현재 상황의 문제를 세 가지로 정리합니다. 첫째는 재현성의 부재입니다. 서로 다른 엔티티 타입 어휘, 관계 분류 체계, 추출 프롬프트가 근본적으로 비교 불가능한 그래프를 생성합니다. 어떤 논문이 “최첨단” 결과를 보고할 때, 그 개선이 검색 알고리즘에서 온 것인지 추출 스키마에서 온 것인지 판단할 수 없는 경우가 많습니다.

이 문제는 2025년 현재 더욱 중요해지고 있습니다. NStarX의 2026-2030 RAG 전망 보고서에 따르면, 2025년 현재 RAG 배포의 30% 미만만이 출시 첫날부터 체계적인 평가를 포함하고 있으며, 이 비율을 2030년까지 60%로 높이는 것이 목표입니다. 하지만 평가 프레임워크 자체가 표준화되지 않은 상황에서 이는 쉽지 않은 과제입니다.

둘째는 상호운용성의 부재입니다. GraphRAG로 구축된 그래프는 HippoRAG에서 직접 사용할 수 없으며, 상당한 변환이 필요합니다. 지식 자산은 원래 구현에 종속되어 있습니다. 지식 그래프 구축에 투자한 조직들은 특정 도구에 의존하게 되며, 다른 접근 방식의 개선 사항을 채택할 수 없습니다. 이는 기업 관점에서 매우 심각한 문제입니다. 지식 그래프 시장이 2023년 16억 1천만 달러에서 2032년 50억 7천만 달러로 성장할 것으로 예상되는 상황에서, 벤더 종속성은 장기적인 투자 위험을 의미합니다.

셋째는 거버넌스가 사후적 고려사항이라는 점입니다. 출처 추적, 품질 지표, 라이프사이클 관리가 기껏해야 임시방편적입니다. 기업 배포에는 감사 추적, 버전 관리, 품질 검증이 필요하지만 현재 시스템은 이를 제대로 제공하지 못합니다. 무언가 잘못되었을 때, 예를 들어 환각된 엔티티가 하위 애플리케이션으로 전파될 때, 그것을 소스로 추적할 방법이 없는 경우가 많습니다.

이는 단순한 이론적 문제가 아닙니다. 2025년 Squirro의 보고서에 따르면, 지식 그래프 기반 생성 AI는 검색 정확도를 99%까지 끌어올릴 수 있지만, 이는 신중하게 큐레이팅된 분류 체계와 온톨로지가 전제될 때만 가능합니다. 규제 산업에서 잘못된 정보가 운영에 미치는 위험을 고려할 때, 거버넌스는 선택 사항이 아니라 필수입니다.

2부: Vector RAG에서 Graph RAG로의 진화

Vector RAG의 한계

저자는 벡터 기반 RAG 시스템이 상당한 채택을 달성했지만 근본적인 한계를 보인다고 지적합니다. 첫째, 평면적 검색은 모든 청크를 독립적으로 처리하여 문서 구조와 청크 간 관계를 놓칩니다. 둘째, 단일 홉 추론은 한 단계로 컨텍스트를 가져오기 때문에 여러 소스에 걸친 추론이 필요한 질문에 어려움을 겪습니다. 셋째, 엔티티 단편화로 인해 문서 전체에 언급된 동일한 엔티티가 통합되지 않아 불완전한 컨텍스트가 생성됩니다. 넷째, 전역적 관점의 부재로 지역적 유사성은 제공하지만 코퍼스 전체의 주제나 종합은 제공하지 못합니다.

2025년 현재, 이러한 한계는 실제 기업 배포에서 더욱 명확해지고 있습니다. Makebot의 분석에 따르면, 표준 LLM은 최근 이벤트나 업데이트된 정책에 대한 쿼리에서 30-50%의 정확도만 보이는 반면, RAG 시스템은 95-99%의 정확도를 달성합니다. 하지만 이는 단순한 사실 검색에 국한되며, 복잡한 추론이 필요한 질문에서는 여전히 한계를 보입니다.

Graph RAG의 약속과 현실

Graph RAG는 이러한 한계를 해결하기 위해 지식을 타입이 지정된 관계로 연결된 엔티티로 조직합니다. 저자가 인용한 결과는 인상적입니다. Microsoft의 GraphRAG는 전역 요약 작업에서 30-70%의 개선을 보였고, HippoRAG는 다중 홉 질의응답 벤치마크에서 최첨단 성능을 달성했으며, RAPTOR는 계층적 요약이 문서 전체 이해를 향상시킨다는 것을 보여주었습니다.

하지만 2025년 말 현재의 실제 배포 경험은 좀 더 복잡한 그림을 그립니다. 2025년 연구들에 따르면, 지식 그래프 추출은 기본 RAG보다 3-5배 더 많은 비용이 들며 도메인별 튜닝이 필요합니다. Microsoft의 LazyGraphRAG가 이 문제를 부분적으로 해결했지만, 여전히 도메인 전문성과 프롬프트 엔지니어링에 대한 상당한 투자가 필요합니다.

Salfati Group의 2025년 분석은 Graph RAG의 비즈니스 케이스를 명확히 합니다. 규제 산업에서 환각과 다중 홉 추론 불능은 프로덕션 배포를 막는 주요 장벽입니다. Graph RAG는 이러한 특정 비즈니스 문제를 해결합니다. 지식 그래프는 사실적 제약으로 작용하여 LLM이 두 개의 관련 없는 개념 사이에 연결을 강제하는 것을 방지합니다. 시스템이 명시적 관계(엣지)를 순회하기 때문에 추론 경로를 시각화할 수 있으며, 감사자는 “모델이 관계 C를 통해 엔티티 A를 엔티티 B에 연결했기 때문에 이 답변을 선택했다”는 것을 볼 수 있습니다.

생성적 지식 시스템의 출현

저자가 강조하는 중요한 통찰은 현대 지식 그래프가 생성 AI에 의해 소비될 뿐만 아니라 점점 더 생성 AI에 의해 구축된다는 것입니다. LLM 기반 추출은 비구조화된 텍스트에서 직접 엔티티, 관계, 이벤트, 주장을 확률적 신뢰도와 증거 범위와 함께 생성합니다. 비전-언어 모델은 이미지, 다이어그램, 표, 스캔 문서를 그래프 연결된 사실로 파싱합니다. 임베딩 모델은 유사성 기반 검색과 클러스터링을 가능하게 합니다. 생성적 요약은 청크에서 커뮤니티까지 계층적 추상화를 구축합니다. 신경망 링크 예측은 단일 소스가 명시적으로 언급하지 않는 관계를 추론합니다.

이러한 양방향 통합, 즉 생성 모델에 의해 구축되고 생성 애플리케이션을 제공하는 그래프는 새로운 범주의 시스템을 만듭니다. 이것들은 LLM이 추가된 전통적인 지식 그래프가 아닙니다. 구축, 서빙, 평가, 운영 모두가 모델 매개적이고 확률적인 프로세스를 포함하는 생성적 지식 시스템입니다.

2025년 Timbr.ai의 분석은 이를 더욱 명확히 합니다. 전통적인 RAG는 텍스트를 검색하지만, GraphRAG는 데이터에 대해 추론합니다. 구조화된 데이터베이스에 대한 접근 없이 전통적인 RAG는 숫자 사실, 관계, 실제 컨텍스트 사이의 “점을 연결”하는 데 어려움을 겪습니다. 한 글로벌 소매업체의 데이터 설계자는 이렇게 말했습니다. “우리 RAG 파이프라인은 감정을 요약할 수 있었지만 판매 데이터를 고객 리뷰와 연결할 수 없었습니다. 구조화된 정보와 비구조화된 정보를 연결할 방법이 필요했습니다.”

3부: 기존 패러다임이 실패하는 이유

관계형 모델링의 한계

저자는 기존 데이터 모델링 접근 방식이 이 격차를 메울 수 있는지 묻고, 그 어느 것도 맞지 않는다고 결론짓습니다. 관계형 모델링은 구조화된 입력과 결정론적 변환을 가정합니다. 데이터베이스에 없는 것은 거짓이라는 폐쇄 세계 가정은 지식 그래프의 개방 세계 특성과 근본적으로 충돌합니다. 지식 그래프에서 정보의 부재는 불확실성을 의미하지 부정을 의미하지 않습니다. 그리고 비구조화된 텍스트에서의 확률적 추출에 대한 어휘가 없습니다.

이는 단순히 이론적인 차이가 아닙니다. 관계형 데이터베이스는 ACID 속성(원자성, 일관성, 격리성, 내구성)을 보장하도록 설계되었습니다. 모든 트랜잭션은 성공하거나 실패하며, 중간 상태는 없습니다. 반면 LLM 기반 추출은 본질적으로 확률적입니다. 동일한 입력이 주어져도 다른 실행에서 약간 다른 엔티티 세트를 추출할 수 있습니다. 신뢰도 점수는 0과 1 사이의 연속값입니다. 관계형 모델은 이러한 불확실성을 모델링할 수 있는 기본 메커니즘이 없습니다.

차원 모델링의 부적합성

차원 모델링, 즉 데이터 웨어하우징을 혁신한 Kimball 방법론은 구조화된 사실과 차원에 대한 분석 쿼리를 최적화합니다. 비즈니스 인텔리전스에 대한 우리의 생각을 변화시켰습니다. 하지만 그래프 순회, 신경망 추론, AI 워크로드의 다중 모달적이고 생성적인 특성을 다루지 않습니다. 패턴이 전이되지 않습니다.

Kimball의 스타 스키마와 스노우플레이크 스키마는 “어떤 제품이 어떤 지역에서 어떤 기간 동안 얼마나 팔렸는가?”와 같은 질문에 답하도록 설계되었습니다. 이는 집계 가능한 메트릭(판매액, 수량)과 잘 정의된 계층(시간, 지리, 제품 카테고리)이 있는 세계입니다. 반면 Graph RAG가 답하려는 질문은 “이 연구 논문에서 제시된 주장과 모순되는 증거는 무엇인가?” 또는 “이 법률 문서 모음에서 나타나는 주요 주제는 무엇인가?”와 같습니다. 이러한 질문은 엔티티 간의 복잡한 관계를 탐색하고, 여러 문서에 걸쳐 패턴을 식별하고, 단일 소스가 명시하지 않은 연결을 추론해야 합니다.

온톨로지 공학의 괴리

온톨로지 공학(OWL, RDFS, 설명 논리)은 형식 논리와 자동화된 추론을 통해 의미론적 엄격성을 제공합니다. 이것은 전통적인 지식 표현 접근 방식이며, 타입 계층과 제약 명세에서 실질적인 가치를 제공합니다. 하지만 온톨로지 개발에는 전문 지식이 필요하고, 도구가 ML 파이프라인과 분리되어 있으며, 형식 논리 제약은 신경 추출기의 확률적이고 근사적인 출력과 종종 충돌합니다. 엄격한 온톨로지 검증은 대부분의 LLM 추출 사실을 거부할 것입니다.

2024-2025년의 온톨로지 공학 연구는 흥미로운 발전을 보여줍니다. 2024년 arXiv에 발표된 연구는 LLM을 사용하여 온톨로지 공학을 가속화하는 방법을 탐구했습니다. MOMo(Modular Ontology Modeling)와 같은 접근 방식은 모듈식 온톨로지 개발을 위한 방법론을 제공하며, LLM이 온톨로지 디자인 패턴을 생성하는 데 사용될 수 있음을 보여주었습니다. 하지만 이러한 접근 방식도 여전히 인간 온톨로지 엔지니어와 도메인 전문가의 상당한 개입을 필요로 합니다.

OWL 2는 OWL 1의 표현력 한계를 극복하기 위해 개발되었으며, 더 복잡한 활동과 관계를 모델링할 수 있게 해줍니다. RDFS는 기본적인 온톨로지 기능을 최소한의 복잡성으로 제공하며, SKOS는 더 단순한 계층 구조를 위해 사용됩니다. 하지만 이 모든 도구들은 근본적으로 확정적이고 논리적인 세계관을 가정합니다. LLM이 “이 엔티티는 아마도 Person 타입일 것이고 신뢰도는 0.87입니다”라고 말할 때, 전통적인 온톨로지 프레임워크는 이를 어떻게 처리해야 할지 모릅니다.

더 근본적인 문제는 도구와 워크플로우의 격차입니다. 온톨로지 엔지니어는 Protégé와 같은 전문 도구를 사용하고 OWL/RDF 직렬화 형식으로 작업합니다. ML 엔지니어는 Python, PyTorch, Hugging Face Transformers를 사용합니다. 이 두 세계를 연결하는 것은 쉽지 않으며, 대부분의 조직은 둘 중 하나를 선택해야 합니다. 온톨로지의 의미론적 엄격성을 선택하면 ML 파이프라인의 유연성과 속도를 포기해야 하고, ML 접근 방식을 선택하면 형식 검증과 추론 기능을 포기해야 합니다.

4부: AI 네이티브 방법론이 제공해야 할 것

저자는 생성적 지식 시스템을 위한 방법론이 제공해야 할 일곱 가지 핵심 요구사항을 제시합니다. 이 각각을 2025년 현재의 관점에서 평가해보겠습니다.

1. 범용적이고 모듈식인 아키텍처

방법론은 구현의 유연성을 허용하면서 기존 시스템 전반의 공통 패턴을 포착하는 구성 가능한 데이터 모델을 정의해야 합니다. 생성적 지식 시스템이 필요로 하는 기본 레이어(문서 표현, 엔티티 및 관계 추출, 계층적 조직, 의미론적 기반)를 식별하고 그것들이 서로 어떻게 관련되는지 명시해야 합니다.

중요한 것은 아키텍처가 모듈식이어야 한다는 점입니다. 시스템은 요구사항에 따라 하위 집합을 채택할 수 있어야 합니다. 모든 애플리케이션이 완전한 온톨로지 추론을 필요로 하는 것은 아닙니다. 일부는 엔티티 인식과 함께 문서 검색만 필요합니다. 방법론은 전부 아니면 전무를 강요하지 않고 이 스펙트럼을 지원해야 합니다.

2025년 현재, 우리는 이 방향으로의 일부 움직임을 보고 있습니다. Microsoft의 GraphRAG는 모듈식 아키텍처를 채택하여 다양한 추출, 임베딩, 요약 전략을 플러그인할 수 있게 합니다. LangChain과 LlamaIndex 같은 프레임워크는 구성 가능한 RAG 파이프라인을 제공합니다. 하지만 이것들은 여전히 구현 수준의 유연성이지 개념 수준의 표준화는 아닙니다. 각 시스템은 여전히 자체 용어와 추상화를 가지고 있습니다.

2. 형식적 연산자 의미론

생성적 지식 시스템은 다양한 연산자를 사용합니다: 청킹, 추출, 임베딩, 요약 등. 이러한 연산자는 근본적으로 다른 특성을 가집니다. 일부는 결정론적이고, 일부는 생성적이며, 일부는 임베딩 기반입니다. 방법론은 명시적 타입 시그니처, 구성 규칙, 출처 요구사항과 함께 이러한 연산자를 분류하고 형식화해야 합니다.

이는 매우 중요한 제안입니다. 현재 대부분의 RAG 시스템은 연산자를 블랙박스로 취급합니다. “이 LLM에 이 프롬프트로 엔티티를 추출하라”고 말하지만, 그 연산의 속성(멱등성, 결정성, 비용, 지연시간)을 명시적으로 모델링하지 않습니다. 결과적으로 쿼리 계획, 캐싱, 비용 최적화가 어렵습니다.

함수형 프로그래밍의 타입 시스템에서 영감을 얻을 수 있습니다. Haskell에서 함수는 타입 시그니처를 가지며(예: extract :: Text -> [Entity]), 부작용을 타입 시스템에서 추적할 수 있습니다(예: IO 모나드). 비슷하게, RAG 연산자는 형식적 시그니처를 가질 수 있습니다:

chunk: deterministic
  input: Document
  output: [TextChunk]
  properties: idempotent, cacheable

extract_entities: generative
  input: TextChunk, Prompt, Model
  output: [Entity × Confidence]
  properties: non-deterministic, model-dependent, cost O(tokens)

embed: embedding-based
  input: Text, EmbeddingModel
  output: Vector[d]
  properties: deterministic-per-model-version, model-dependent

이러한 형식화는 재현성 테스트, 비용 모델링, 연산자 특성에 기반한 캐시 정책 설계를 가능하게 합니다. 2025년 현재 이러한 수준의 형식화를 제공하는 RAG 프레임워크는 없지만, 그 필요성은 점점 더 명확해지고 있습니다.

3. 라이프사이클 커버리지

지식은 정적이지 않습니다. 코퍼스가 진화하고, 모델이 개선되고, 요구사항이 변경되고, 오류가 발견됩니다. 방법론은 발견, 구축, 보강, 서빙, 거버넌스를 포괄하는 완전한 라이프사이클을 정의해야 합니다. 각 단계는 명시적인 입력, 출력, 연산자, 품질 게이트가 필요합니다.

이는 현재 실무에서 가장 많이 간과되는 측면입니다. 대부분의 RAG 구현은 “한 번 구축하고 실행”하는 접근 방식을 취합니다. 코퍼스가 업데이트될 때, 모델이 개선될 때, 또는 오류가 발견될 때 무엇을 해야 하는지에 대한 명확한 프로세스가 없습니다. 소프트웨어 엔지니어링에서 우리는 CI/CD 파이프라인, 버전 관리, 롤백 전략을 가지고 있습니다. 지식 그래프는 왜 이러한 것들을 가지지 않을까요?

2025년 연구에서 이 문제를 인식하기 시작했습니다. RAGAS와 같은 평가 프레임워크는 RAG 시스템의 지속적인 품질 모니터링을 가능하게 합니다. 하지만 이는 전체 라이프사이클의 한 부분일 뿐입니다. 우리는 여전히 스키마 진화, 데이터 마이그레이션, 백워드 호환성에 대한 표준화된 접근 방식이 필요합니다.

4. 생성 프로세스에 대한 네이티브 지원

전통적인 데이터 모델링과 달리, 이 방법론은 생성 AI를 외부 도구가 아닌 일급 참여자로 취급해야 합니다. 이는 신뢰도와 불확실성을 예외가 아닌 고유 속성으로 모델링하고, 모델 출처를 추적하고, 수정될 수 있는 확률적 엣지와 주장을 지원하고, 모델과 코퍼스가 진화함에 따라 지속적인 평가를 가능하게 하는 것을 의미합니다.

이는 패러다임의 근본적인 전환입니다. 전통적인 데이터베이스에서 데이터는 참이거나 거짓입니다. ETL 프로세스는 결정론적입니다. 반면 LLM 기반 추출에서 모든 사실에는 신뢰도 점수가 있습니다. 동일한 문서가 다른 모델이나 다른 프롬프트로 처리되면 다른 엔티티 세트를 생성할 수 있습니다. 이러한 불확실성을 포용하고 관리하는 것이 AI 네이티브 방법론의 핵심입니다.

Squirro의 2025년 분석은 이를 명확히 합니다. GraphRAG가 지식 그래프를 사용하여 관계를 해석할 때, 검색 정확도를 99%까지 높일 수 있습니다. 하지만 이는 신중하게 큐레이팅된 분류 체계와 온톨로지가 전제될 때만 가능합니다. 즉, 확률적 추출과 결정론적 검증 사이의 균형이 필요합니다.

5. 설계에 의한 출처 및 거버넌스

기업 맥락에서 무언가가 어디서 왔는지 아는 것은 그것이 무엇인지 아는 것만큼 중요합니다. 방법론은 추출 출처가 사실을 소스 문서, 범위, 모델과 연결하는 방법, 파생 출처가 추론된 사실을 입력으로 추적하는 방법, 시간적 출처가 사실이 언제 추출, 수정 또는 폐기되었는지 기록하는 방법, 신뢰도 점수가 어떻게 할당, 보정 및 전파되는지 명시해야 합니다.

이는 선택적 추가가 아니라 기초 인프라입니다. 규제 산업(금융, 의료, 법률)에서 AI 시스템의 결정을 설명할 수 있어야 합니다. EU AI Act와 같은 새로운 규제는 고위험 AI 시스템에 대한 투명성과 설명 가능성을 요구합니다. 출처 추적 없이는 이러한 요구사항을 충족할 수 없습니다.

2025년 Graph RAG 구현들은 이를 인식하고 있습니다. Microsoft GraphRAG는 각 추출된 엔티티를 원본 텍스트 범위에 연결합니다. AWS Bedrock GraphRAG는 Neptune Analytics와의 통합을 통해 출처 추적을 제공합니다. 하지만 이러한 기능이 표준화된 방식으로 구현되지 않으면, 시스템 간 감사 추적을 비교하거나 통합하는 것이 여전히 어렵습니다.

6. 구현 독립성

조직은 그래프 데이터베이스, 벡터 스토어, 데이터 인프라에 기존 투자를 가지고 있습니다. 특정 기술 선택을 강제하는 방법론은 채택 장벽에 직면할 것입니다. 형식화는 스토리지 백엔드에 대해 추상화해야 하며, 라벨링된 속성 그래프, RDF 스토어, 그래프 확장이 있는 관계형 데이터베이스, 하이브리드 아키텍처를 지원해야 합니다.

이는 실용적으로 매우 중요한 요구사항입니다. 2023년 지식 그래프 시장 규모가 16억 1천만 달러이고 2032년까지 50억 7천만 달러로 성장할 것으로 예상되는 상황에서, 조직들은 이미 상당한 인프라 투자를 했습니다. 일부는 Neo4j를 사용하고, 일부는 Amazon Neptune을 사용하며, 일부는 PostgreSQL의 그래프 확장을 사용합니다. 방법론이 하나의 특정 플랫폼을 요구한다면, 채택이 제한될 것입니다.

좋은 소식은 이미 일부 수렴이 일어나고 있다는 것입니다. Property Graph와 RDF 사이의 상호 운용성을 위한 표준(예: W3C의 RDF/SPARQL)이 개발되고 있습니다. GQL(Graph Query Language)은 ISO 표준으로 개발 중이며, SQL과 유사한 방식으로 그래프 쿼리를 표준화하려고 합니다. 하지만 이러한 표준들은 여전히 쿼리 레벨에 초점을 맞추고 있으며, 생성적 지식 시스템의 전체 라이프사이클을 다루지 않습니다.

7. 지식과 운영의 분리

쿼리 시간 관심사(캐싱, 세션 관리, 응답 버전 관리, 성능 최적화)는 실제 요구사항입니다. 하지만 지식 모델을 오염시켜서는 안 됩니다. 방법론은 운영 관심사를 지식 표현에서 명확히 분리하여 일관된 지식 레이어를 유지하면서 다양한 배포 패턴을 가능하게 해야 합니다.

이는 소프트웨어 엔지니어링의 관심사 분리 원칙의 적용입니다. MVC(Model-View-Controller) 패턴이 데이터 모델을 사용자 인터페이스에서 분리하는 것처럼, AI 네이티브 방법론은 지식 모델을 쿼리 최적화에서 분리해야 합니다. 지식 그래프는 도메인의 사실과 관계를 나타내야 하며, “이 쿼리는 자주 실행되므로 미리 계산되어야 한다”와 같은 운영 고려사항을 포함해서는 안 됩니다.

2025년 현재 대부분의 RAG 시스템은 이러한 분리를 잘 수행하지 못합니다. 벡터 인덱스, 캐시 정책, 쿼리 최적화 힌트가 종종 지식 모델 자체에 직접 내장됩니다. 이는 지식 모델을 특정 쿼리 패턴과 성능 특성에 결합시켜 진화를 어렵게 만듭니다.

5부: GenKM 제안에 대한 비판적 평가

제안의 강점

저자가 제시하는 문제 진단은 정확하고 시의적절합니다. RAG 기술의 폭발적 성장과 방법론의 부재 사이의 격차는 실제 문제이며, 기업 배포를 방해하고 있습니다. 2025년 현재 McKinsey 보고서에 따르면 조직의 71%가 정기적으로 생성 AI를 사용한다고 보고하지만, EBIT의 5% 이상을 생성 AI에 귀속시키는 조직은 17%에 불과합니다. 데모와 실제 프로덕션 가치 사이의 격차를 보여주는 것입니다.

일곱 가지 요구사항은 포괄적이고 사려 깊습니다. 형식적 연산자 의미론, 라이프사이클 커버리지, 설계에 의한 출처 추적은 모두 현재 실무에서 간과되는 중요한 측면입니다. 기존 패러다임(관계형 모델링, 차원 모델링, 온톨로지 공학)이 왜 적합하지 않은지에 대한 분석도 설득력 있습니다.

역사적 유추도 적절합니다. Kimball의 차원 모델링이 데이터 웨어하우징 산업을 가능하게 했듯이, AI 네이티브 지식 시스템도 자체 방법론이 필요합니다. 도구의 존재가 자동으로 모범 사례를 만들어내지 않으며, 표준화 없이는 각 조직이 바퀴를 재발명해야 합니다.

잠재적 과제와 한계

하지만 GenKM 제안에는 몇 가지 잠재적 과제와 한계가 있습니다. 첫째, 복잡성과 채택 사이의 긴장입니다. 방법론이 충분히 포괄적이려면 복잡해질 수밖에 없지만, 너무 복잡하면 채택이 어려워집니다. Kimball 방법론이 성공한 이유 중 하나는 상대적인 단순성과 실용성이었습니다. GenKM이 유사한 균형을 달성할 수 있을까요?

둘째, 기술 변화의 속도입니다. 2022년 ChatGPT 출시 이후 3년 동안 RAG 기술은 급격히 진화했습니다. 2024년 초 표준으로 여겨진 접근 방식이 2025년 말에는 구식이 되었습니다. 이러한 빠른 변화 속에서 안정적인 방법론을 어떻게 정의할 수 있을까요? 방법론이 너무 구체적이면 빠르게 구식이 될 위험이 있고, 너무 추상적이면 실질적인 지침을 제공하지 못할 수 있습니다.

셋째, 확률성과 형식화 사이의 긴장입니다. LLM의 본질적인 비결정성은 전통적인 형식 방법과 충돌합니다. 저자는 이를 인식하고 “생성 프로세스에 대한 네이티브 지원”을 요구하지만, 구체적인 해결책은 명확하지 않습니다. 확률적 논리, fuzzy sets, 베이지안 네트워크 등 다양한 접근 방식이 가능하지만, 어느 것도 완벽한 해답은 아닙니다.

넷째, 거버넌스와 민첩성 사이의 균형입니다. 출처 추적, 품질 게이트, 버전 관리는 중요하지만 개발 속도를 늦출 수 있습니다. 스타트업이나 연구 환경에서는 엄격한 거버넌스보다 빠른 실험이 더 중요할 수 있습니다. 방법론이 다양한 조직 맥락과 성숙도 수준을 어떻게 수용할 수 있을까요?

다섯째, 표준화의 정치경제학입니다. 기술 표준은 종종 시장 지배력을 반영합니다. SQL이 표준이 된 것은 순수하게 기술적 장점 때문만이 아니라 IBM과 Oracle의 시장 지배력 때문이기도 했습니다. GraphRAG 공간에서 Microsoft, AWS, Google은 각각 자체 구현을 가지고 있습니다. 이들이 공통 표준에 합의할 동기가 있을까요? 아니면 각각 자체 “표준”을 밀어붙일까요?

2025년 현실과의 비교

2025년 말 현재, 우리는 저자가 식별한 문제들이 실제로 나타나는 것을 보고 있습니다. 재현성은 여전히 주요 과제입니다. 2025년 GraphRAG on Technical Documents 연구는 지식 그래프 스키마가 성능에 미치는 영향을 보여주었지만, 표준화된 스키마 설계 방법론은 없습니다.

상호운용성도 제한적입니다. Microsoft GraphRAG, AWS Bedrock GraphRAG, Neo4j의 GraphRAG 솔루션은 각각 다른 API, 다른 스키마, 다른 쿼리 언어를 사용합니다. 한 플랫폼에서 다른 플랫폼으로 마이그레이션하려면 상당한 재작업이 필요합니다.

하지만 일부 수렴의 조짐도 있습니다. RAGAS와 같은 평가 프레임워크는 다양한 RAG 시스템에서 사용할 수 있는 표준화된 메트릭을 제공하기 시작했습니다. LangChain과 LlamaIndex 같은 프레임워크는 사실상의 표준으로 부상하고 있습니다. ISO GQL(Graph Query Language) 표준은 개발 중입니다.

또한 시장의 성숙도가 높아지고 있습니다. 지식 그래프 시장이 2024년 11억 8천만 달러에서 2025년 14억 8천만 달러로 성장하면서, 기업들은 장난감 프로토타입을 넘어 프로덕션 시스템을 요구하고 있습니다. NStarX의 보고서에 따르면, 2026-2030년까지 RAG는 “지식 런타임”으로 진화할 것으로 예상됩니다. 이는 검색, 검증, 추론, 접근 제어, 감사 추적을 통합된 운영으로 관리하는 오케스트레이션 레이어입니다.

6부: 향후 방향과 실천적 함의

단기적 조치 (2026-2027)

저자의 제안이 완전히 실현되려면 시간이 걸릴 것입니다. 하지만 단기적으로 조직과 연구 커뮤니티가 취할 수 있는 실천적 조치들이 있습니다.

조직 수준에서:

첫째, 성능 베이스라인을 수립해야 합니다. RAGAS와 같은 프레임워크를 즉시 구현하여 현재 시스템의 성능을 이해해야 합니다. 측정할 수 없는 것은 개선할 수 없습니다.

둘째, 다중 프레임워크 접근 방식을 채택해야 합니다. 확장 가능한 자동화된 평가(LLM-as-Judge)와 대상화된 인간 검토(도메인 전문가)를 결합하여 포괄적인 품질 보증을 해야 합니다.

셋째, 평가를 MLOps 사이클의 핵심 부분으로 만들어야 합니다. RAG 벤치마킹을 CI/CD 파이프라인에 통합하여 프로덕션에 도달하기 전에 회귀를 포착해야 합니다.

넷째, 품질 문화를 조성해야 합니다. 데이터 과학자, 엔지니어, 비즈니스 도메인 전문가 간의 교차 기능 협업을 평가 프레임워크의 설계와 검토에서 보장해야 합니다.

연구 커뮤니티 수준에서:

첫째, 벤치마크 데이터셋과 평가 프로토콜을 표준화해야 합니다. BEIR, MTEB와 같은 이니셔티브를 Graph RAG로 확장해야 합니다. 다중 홉 추론, 전역 요약, 시간적 추론 등 Graph RAG의 고유한 능력을 평가하는 벤치마크가 필요합니다.

둘째, 스키마 설계 패턴을 문서화하고 공유해야 합니다. 소프트웨어 엔지니어링의 디자인 패턴처럼, Graph RAG에도 반복 가능한 스키마 패턴이 필요합니다. 예를 들어, “문서-섹션-청크 계층”, “엔티티-이벤트-주장 모델” 등의 패턴을 코드화할 수 있습니다.

셋째, 출처 추적과 설명 가능성에 대한 표준을 개발해야 합니다. W3C PROV(Provenance) 온톨로지와 같은 기존 작업을 기반으로 LLM 기반 추출에 적합하게 확장해야 합니다.

중기적 전망 (2028-2029)

중기적으로는 더 구조적인 변화가 예상됩니다.

산업 컨소시엄과 표준 기구의 역할이 중요해질 것입니다. ISO, W3C, 또는 새로운 기구가 Graph RAG와 생성적 지식 시스템을 위한 표준을 개발할 가능성이 있습니다. 금융, 의료, 법률과 같은 규제 산업은 도메인별 컨소시엄을 형성하여 공유 지식 그래프와 온톨로지를 유지할 수 있습니다.

RAG-as-a-Service가 기업 성숙도에 도달할 것입니다. 99.9% SLA, 내장된 규제 준수, 상호 운용성 표준을 갖춘 관리형 서비스가 등장할 것입니다. 이는 1990년대 데이터베이스가 인프라로 추상화된 것과 유사한 과정입니다.

제로 트러스트 아키텍처가 RAG 배포의 필수 요소가 될 것입니다. 출처 추적, 접근 제어, 감사 추적이 단순한 추가 기능이 아니라 핵심 설계 원칙이 될 것입니다.

수직 통합 솔루션이 나타날 것입니다. 규제 산업(의료, 금융, 법률)을 위한 사전 구축된 지식 런타임이 시장의 50% 이상을 차지할 것입니다. 이러한 솔루션은 도메인별 온톨로지, 규제 요구사항, 모범 사례를 사전 통합하여 가치 창출 시간을 1개월 미만으로 단축할 것입니다.

장기적 비전 (2030 이후)

장기적으로는 더욱 근본적인 변화가 예상됩니다.

AI 기반 지식 큐레이션이 자동화될 것입니다. 자동화된 소스 평가, 엔티티 검증, 관계 발견이 표준이 될 것입니다. 인간의 역할은 직접적인 큐레이션에서 감독과 검증으로 이동할 것입니다.

RAG 인프라가 보이지 않게 될 것입니다. 데이터베이스가 1990년대에 개발 플랫폼에 추상화된 것처럼, RAG 기능이 개발 도구에 내장될 것입니다. 개발자는 낮은 수준의 벡터 검색이나 그래프 순회 대신 높은 수준의 지식 쿼리를 작성할 것입니다.

엣지 배포가 지연 시간에 민감하고 프라이버시가 중요한 애플리케이션(의료 기기, 산업 장비)을 위해 일반화될 것입니다. 온디바이스 RAG는 중앙 집중식 클라우드 서비스에 의존하지 않고 실시간 의사 결정을 가능하게 할 것입니다.

양자 내성 암호화가 민감한 지식 베이스의 표준이 될 것입니다. 양자 컴퓨팅의 위협에 대비하여 장기적인 지식 자산을 보호할 것입니다.

7부: 나의 의견과 평가

GenKM 제안의 가치

저는 저자의 제안이 시의적절하고 중요하다고 생각합니다. RAG 기술의 폭발적 성장과 방법론의 부재 사이의 격차는 실제 문제이며, 이를 해결하지 않으면 기술의 잠재력을 완전히 실현할 수 없을 것입니다. 특히 다음 측면에서 제안이 가치 있습니다.

문제 진단의 정확성: 재현성, 상호운용성, 거버넌스 부재에 대한 지적은 정확합니다. 2025년 현재 실제 기업 배포에서 이러한 문제들이 명확히 드러나고 있습니다.

역사적 맥락의 적절성: Kimball 방법론과의 비교는 설득력 있습니다. 데이터 웨어하우징이 방법론을 통해 성숙했듯이, AI 네이티브 지식 시스템도 그럴 필요가 있습니다.

포괄적 요구사항: 일곱 가지 요구사항은 잘 생각되었으며 현재 실무의 격차를 정확히 포착합니다. 특히 형식적 연산자 의미론과 설계에 의한 출처 추적은 현재 대부분의 RAG 시스템이 간과하는 중요한 측면입니다.

주요 우려사항

하지만 몇 가지 우려사항도 있습니다.

첫째, 실행의 어려움입니다. 방법론을 제안하는 것과 그것을 널리 채택되게 만드는 것은 다릅니다. Kimball 방법론이 성공한 이유는 실용적이고 접근 가능했기 때문입니다. GenKM이 유사한 특성을 가질 수 있을까요? 저자는 이후 글에서 GenKG 형식론, 4단계 아키텍처, 연산자 대수, 라이프사이클 프레임워크를 상세히 설명하겠다고 했지만, 이것들이 실무자들이 실제로 사용할 수 있을 만큼 접근 가능할지는 불확실합니다.

둘째, 기술 변화의 속도입니다. AI 분야는 매우 빠르게 변화하고 있습니다. 오늘 정의한 방법론이 내년에도 관련성이 있을까요? 방법론은 충분히 추상적이어야 기술 변화에 견딜 수 있지만, 동시에 충분히 구체적이어야 실질적인 지침을 제공할 수 있습니다. 이 균형을 찾는 것은 어렵습니다.

셋째, 거버넌스 오버헤드입니다. 엄격한 출처 추적, 버전 관리, 품질 게이트는 개발 속도를 늦출 수 있습니다. 규제 산업에서는 이것이 필수이지만, 스타트업이나 연구 환경에서는 과도한 부담이 될 수 있습니다. 방법론이 다양한 맥락에 적응할 수 있어야 하는데, 이는 쉽지 않습니다.

넷째, 확률성과 형식화의 긴장입니다. LLM은 본질적으로 확률적입니다. 전통적인 형식 방법(온톨로지, 설명 논리)은 확정적입니다. 이 둘을 어떻게 조화시킬 것인가? 저자는 “생성 프로세스에 대한 네이티브 지원”을 요구하지만, 구체적인 메커니즘은 명확하지 않습니다. Fuzzy logic, 확률적 논리, 베이지안 네트워크 등 다양한 접근 방식이 가능하지만, 어느 것도 완벽한 해답은 아닙니다.

대안적 관점: 상향식 vs 하향식

저자의 접근 방식은 본질적으로 하향식입니다. 포괄적인 방법론을 정의하고 실무자들이 그것을 채택하기를 기대합니다. 하지만 기술 표준은 종종 상향식으로 발전합니다. SQL은 위원회가 설계한 것이 아니라 다양한 구현(IBM의 SEQUEL, Oracle 등)에서 발전하여 나중에 표준화되었습니다. REST API도 Roy Fielding의 박사 논문에서 기술된 후 실무에서 유기적으로 채택되었습니다.

GraphRAG에도 비슷한 과정이 일어날 수 있습니다. Microsoft GraphRAG, AWS Bedrock GraphRAG, Neo4j의 솔루션, 다양한 오픈소스 구현들이 각자의 접근 방식을 시도하고 있습니다. 시간이 지나면서 가장 효과적인 패턴이 부상하고, 커뮤니티가 사실상의 표준으로 수렴할 수 있습니다. 그러면 공식 표준 기구가 이를 코드화할 수 있습니다.

이 관점에서, GenKM의 가장 큰 가치는 완전한 방법론을 제공하는 것이 아니라 대화를 시작하는 것일 수 있습니다. 무엇이 필요한지, 어떤 문제를 해결해야 하는지, 어떤 원칙이 중요한지에 대한 명확한 설명을 제공함으로써, 커뮤니티가 솔루션을 개발하도록 촉진할 수 있습니다.

실무적 권장사항

조직들이 GenKM과 같은 포괄적인 방법론을 기다리는 동안, 지금 바로 취할 수 있는 실무적 조치들이 있습니다.

1. 평가부터 시작하세요. 현재 시스템의 성능을 측정하지 못하면 개선할 수 없습니다. RAGAS, ARES 또는 다른 평가 프레임워크를 즉시 구현하세요. 정확도, 관련성, 신실성(faithfulness)을 추적하세요.

2. 출처를 문서화하세요. 모든 추출된 사실을 원본 소스에 연결하세요. 어떤 모델이, 어떤 프롬프트로, 언제 추출했는지 기록하세요. 이는 디버깅, 감사, 규제 준수에 필수적입니다.

3. 버전 관리를 구현하세요. 지식 그래프를 코드처럼 취급하세요. Git 또는 유사한 시스템으로 버전을 관리하세요. 스키마 변경을 추적하고, 필요시 롤백할 수 있도록 하세요.

4. 점진적으로 시작하세요. 전체 기업 지식을 한 번에 그래프로 만들려고 하지 마세요. 잘 정의된 작은 문제로 시작하세요. 학습하고, 반복하고, 확장하세요.

5. 도메인 전문가를 참여시키세요. ML 엔지니어만으로는 충분하지 않습니다. 도메인 전문가가 스키마 설계, 엔티티 타입 정의, 추출 검증에 참여해야 합니다.

6. 상호운용성을 고려하세요. 특정 벤더에 너무 깊이 종속되지 마세요. 가능한 한 오픈 표준(RDF, OWL, GQL)을 사용하세요. 마이그레이션 경로를 고려하세요.

결론: 여정의 시작

Fanghua Yu의 글은 AI 네이티브 지식 공학을 위한 방법론의 필요성을 설득력 있게 주장합니다. 재현성, 상호운용성, 거버넌스 부재에 대한 그의 진단은 정확하며, 2025년 현재 실제 기업 배포에서 명확히 드러나고 있습니다. 일곱 가지 요구사항은 포괄적이고 사려 깊으며, 현재 실무의 중요한 격차를 포착합니다.

하지만 방법론을 제안하는 것과 그것을 널리 채택되게 만드는 것은 다릅니다. GenKM의 성공은 실무자들에게 얼마나 접근 가능하고 유용한지, 빠르게 변화하는 기술 환경에 얼마나 잘 적응하는지, 다양한 조직 맥락의 요구를 얼마나 균형 있게 맞추는지에 달려 있을 것입니다.

나는 GenKM의 가장 큰 가치가 완전한 방법론을 제공하는 것보다 대화를 시작하는 것에 있다고 생각합니다. 무엇이 필요한지, 어떤 문제를 해결해야 하는지, 어떤 원칙이 중요한지에 대한 명확한 설명을 제공함으로써, 연구 커뮤니티와 실무 커뮤니티가 솔루션을 개발하도록 촉진할 수 있습니다.

2025년이 끝나가는 지금, 우리는 생성 AI와 지식 그래프의 융합이라는 흥미진진한 여정의 초기 단계에 있습니다. 도구는 빠르게 발전하고 있습니다. Microsoft의 LazyGraphRAG는 비용을 극적으로 줄였고, AWS Bedrock GraphRAG는 기업 시장에 진입했으며, 새로운 평가 프레임워크와 벤치마크가 등장하고 있습니다.

하지만 진정한 도전은 기술적이지 않습니다. 커뮤니티로서, 우리가 공통 언어, 공유된 원칙, 재사용 가능한 패턴에 합의할 수 있는지입니다. 도구만으로는 충분하지 않습니다. 방법론이 필요합니다. 그리고 그 방법론의 개발은 이제 막 시작되었습니다.

저자가 다음 글에서 GenKG 형식론, 4단계 아키텍처, 연산자 대수, 라이프사이클 프레임워크를 어떻게 구체화하는지 보는 것은 흥미로울 것입니다. 하지만 그것이 성공하든 실패하든, 이 대화를 시작한 것만으로도 가치가 있습니다. AI 네이티브 지식 시스템은 프로토타입에서 인프라로 발전할 자격이 있습니다. 그리고 그 여정은 이런 어려운 질문들을 던지는 것에서 시작됩니다.

작성 일자: 2026-01-13

AI, RAG