2026년의 벤더 발표문을 나란히 놓고 보면 낯선 이름들이 눈에 띕니다. 마이크로소프트는 Foundry IQ를 “기업 데이터를 위한 관리형 지식 계층”이라고 정의하고, AWS는 7월 가이드의 제목을 “온톨로지, 기호 추론, 가상 지식 그래프를 이용한 에이전틱 AI용 시맨틱 레이어”로 달았습니다.

Snowflake는 Horizon Context 발표 글을 “AI, BI, 앱을 위한 거버넌스가 적용된 컨텍스트 레이어”로 잡았고, Forrester는 같은 영역을 아예 context layer라 부릅니다.

이렇게 이름은 회사마다 다릅니다. 마이크로소프트 회사 안에서도 가장 위에 있는 이름은 ‘knowledge layer’가 아니라 ‘intelligence layer’이고, knowledge layer라 불리는 Foundry IQ는 그 아래 구성요소 중 하나입니다. Fabric IQ의 온톨로지 문서는 한 페이지 안에서 같은 대상을 “시맨틱 레이어”, “공유 컨텍스트 레이어”, “비즈니스 컨텍스트 레이어” 세 가지로 부르기도 합니다.

이번 글은 어느 한 벤더의 정의를 보는 게 아니라, 이 회사들이 서로 다른 이름으로 풀고 있는 문제가 무엇인지를 살펴보려고 합니다.

Microsoft·AWS·Snowflake·Forrester 네 벤더가 같은 영역을 각각 intelligence layer, Semantic Layer, Context Layer, context layer로 다르게 부른다는 비교 카드 — <출처: 작가, 각 사 공식 문서 기반 재구성>

RAG를 만들어 놓고도 생기는 문제들

1) 검색에 성공했다고 정답을 아는 건 아니다

작년 할루시네이션 논문 리뷰에서 “이론상 RAG가 할루시네이션을 더 줄이려면 Vector보다는 ‘유사한게 아니라 명확하고 확실하게 검색되는 것’이 더 도움을 줄 수 있다”라고 리뷰했었습니다.

이젠 여기에 하나 덧붙여, “정확히 찾는다”와 “찾은 것 중 무엇을 믿는다”는 다른 계층의 문제인 것 같습니다. 앞은 검색의 일이고, 뒤는 검색 관련도를 올리는 것만으로는 풀리지 않는 일입니다.

2) 검색은 이미 한참 발전했지만, 그래도 남는 문제가 있습니다

이 글에서 다루는 문제가 검색이 아직 부족해서 생기는 문제라고 오해하기 쉬운데, 그렇지 않습니다. 검색 자체는 RAG보다 훨씬 오래된 분야입니다. 웹 검색과 포털 검색, 자연어 검색, 그 밑의 검색 엔진까지 이미 다 있었고, RAG는 그 검색 결과를 LLM에 넣어 주는 데서 시작했습니다.

물론 그건 나이브 RAG 얘기고 요즘 검색은 다르긴 합니다. Self-RAG는 검색을 할지 말지를 모델이 판단하게 만들었고, CRAG는 가벼운 평가기를 앞에 두고 검색 결과를 Correct / Incorrect / Ambiguous로 나눈 뒤 조건부로 웹 검색까지 확장합니다.

Microsoft가 8월 31일 갱신한 문서에서 새 검색 기능인 agentic retrieval을 어떻게 정의했는지 보면 방향이 보입니다. “검색 증강 생성(RAG) 패턴과 에이전트 간 워크플로를 위한 것이다”고요. 이름은 새로 지었지만 RAG를 밀어내는 기능이 아니라, RAG 안에서 검색 단계를 더 잘하게 만드는 기능이라고 스스로 못을 박아 둔 겁니다.

3) Agent가 오자 문제의 크기가 달라졌습니다

사람이 검색 결과를 직접 보던 시절엔 이상하면 “사람이” 멈췄습니다. 반년 전 정책 문서가 위에 올라와도 날짜를 보고 “이건 옛날 거네” 하고 넘기고, 남의 팀 문서가 섞여 나와도 “이건 내가 볼 게 아닌데” 하고 닫습니다.

자율 에이전트는 그 판단을 대신하기로 한 쪽이라, 검수를 사람이 해 준다는 전제를 둘 수 없습니다. 옛날 문서를 거르는 일도, 봐서는 안 될 문서를 거르는 일도 시스템이 맡아야 합니다. 그래서 벤더들이 먼저 손댄 게 권한입니다. 검색이 끝난 뒤 사람이 거르던 것을 검색쪽으로 밀어 넣기 시작했습니다.

Foundry IQ 문서는 질의 시점에 권한을 강제한다고 설명하는데, ACL을 동기화하고 민감도 레이블을 확인한 뒤 “호출자의 Microsoft Entra 신원으로 질의를 실행”하고 답변에 출처를 붙입니다.

사람이 마지막 안전장치였던 구조에서 사람을 빼면, 그 안전장치를 시스템 어딘가에 다시 만들어 넣어야 합니다. 그래서 문제의 크기가 달라집니다. 예전에는 검색이 잘 되느냐만 보면 됐는데, 이제는 찾아온 문서가 지금 맞는 값인지, 이 사람이 봐도 되는 문서인지, 어디서 온 것인지까지 시스템이 답해야 합니다.

검색이 잘 돌아간 다음에 남는 네 가지 문제

Snowflake가 8월 17일 사내 컨텍스트 레이어를 만든 경험을 공개했는데, 자체 진단 문장이 인상적입니다. “병목은 한 번도 데이터였던 적이 없다”라고 쓰고, “병목은 컨텍스트였다”고 합니다. (규모는 2025년 7월 한 달에 400명 넘는 사내 사용자가 5,400건 이상을 질의)

이를 정합성, 최신성, 권한, 그리고 출처 네 가지로 나눠 살펴보겠습니다.

질문에서 검색, 관련 문서까지는 잘 되지만 그 다음 정합성·최신성·권한·출처 네 문제가 남는다는 다이어그램, 하단에 병목은 데이터가 아니라 컨텍스트였다는 문구 — <출처: 작가>

1) 같은 것을 서로 다르게 부릅니다

Snowflake 글이 드는 사례는 “활성 고객이란 무엇인가?”라는 질문 하나입니다. 어떤 팀은 credits_consumed > 0 and account_type != ‘TRIAL’로 세고, 어떤 팀은 리전 조건 없이 COUNT(DISTINCT account_id)로 셉니다.

둘 다 SQL은 잘 돌아가고, 둘 다 “active customer 수”라는 결과로 나오지만, 두 숫자는 다릅니다. Microsoft도 Fabric IQ 문서에서 같은 진단을 합니다. “조직이 데이터를 다루는 방식은 여전히 ‘의미’보다는, 기계 처리를 위해 설계된 테이블과 스키마 같은 구조에 머물러 있다”

이건 AI 때문에 생긴 문제가 아닙니다. LLM 이전에도 있었고, LLM 이후 컨텍스트의 중요성이 커지면서 다시 화두가 됐을 뿐이죠. 이게 얼마나 오래된 문제인지는 빅테크 엔지니어링 블로그를 거슬러 올라가 보면 바로 나옵니다.

Uber는 2020년 Databook 글에서 “각기 다른 메타데이터 시스템을 사용하면서 통합된 관점이 사라졌고, 같은 작업이 반복되는 비효율도 생겼다” 라고 썼습니다. LinkedIn은 그보다 4년 앞선 2016년 글에서 같은 표현이 문맥에 따라 다른 뜻이 되는 문제를 지식 그래프의 핵심 난제로 꼽았습니다. Pinterest는 2020년 글에서 동일성 판단을 끝까지 자동화하지 못했다고 인정하고요.

Pinterest가 말한 동일성 판단은 “이 둘이 같은 것을 가리키는가”를 기계가 정하는 일입니다. 저는 그 판단의 가장 작은 시작점부터 잡았습니다. 조사가 특히 문제였습니다. 사용자가 “XX시트가”라고 물으면 색인에 들어 있는 원형 토큰 “XX시트”를 못 찾아서 시스템이 “찾지 못했다”고 답하는 경우가 있었습니다. 검색 엔진이나 임베딩이 잘못된 것도 아니었습니다.

1차 해결은 질의 쪽 접두사 확장이었습니다. 질의 토큰 말미 한두 글자를 잘라내고 와일드카드를 붙이는 방식인데 이걸로 “XX시트가”는 잡혔습니다. 그런데 접두사만으로는 두 글자 조사가 안 잡혔고, 색인 쪽 문장에 조사가 붙은 방향은 여전히 실패했습니다.

그래서 2차 해결로 한글 bigram 분절을 색인과 질의 양쪽에 넣었습니다. bigram이 접두사 확장을 대체한 건 아닙니다. 세 글자 이상 원형 토큰은 여전히 접두사 확장이 잡고, 접두사 확장이 놓치는 경우를 bigram이 메우는 식으로 둘을 병행하게 했습니다.

같은 토큰의 조사 변형을 색인에서 놓치던 AS-IS와 접두사 확장·bigram 분절을 병행해 찾아내는 TO-BE 검색 처리 과정 비교 다이어그램 — <출처: 작가>

왜 bigram일까요? 두 글자 단위로 쪼개면 조사가 앞뒤 어디에 붙어도 원형 토큰의 bigram이 살아남기 때문입니다. 예를 들어 색인 문장에는 “연차는”이 있고 사용자는 “연차가”라고 물으면, 둘 다 “연차”라는 bigram을 갖고 있습니다.

정합성이 어렵다고 하면 보통 온톨로지나 엔티티 해소 같은 큰 얘기부터 떠올리는데, 그 전에 이 부분부터 잡는 게 좋습니다.

2) 최신성은 선택이 아니라 필수

Atlassian은 Rovo 검색에서 신선도를 최종 수정 시각으로 판정하되 그 기준이 제품마다 다르다고 설명합니다. “최신성은 가장 최근 업데이트 시점을 기준으로 결정되며, 제품마다 월, 주, 일 단위로 서로 다르게 적용된다”

더 깊이 들어가면 색인 자체의 지연이 있습니다. Glean 제품 문서를 보면, 변경은 웹훅으로 받아 보통 “1~5분” 안에 처리하고 웹훅이 놓친 변경은 24시간 주기 증분 크롤러가 수집합니다. 크롤 대상은 “콘텐츠, 연결된 권한, 활동 메타데이터” 세 가지입니다. 권한도 콘텐츠와 똑같이 동기화 대상이라는 뜻이고, 전파가 늦어지면 권한도 그만큼 낡은 채로 남습니다.

제 경우엔 옛날 문서가 결과에 섞여 들어오고, “비슷하다”는 이유만으로 상위에 랭킹되는 문제가 있었습니다. 임베딩 유사도는 시간을 모릅니다. 본문에 “2026-01”과 “2026-07”이 글자로만 적혀 있으면 벡터 위에서는 거의 같은 값이 되니까요. 그래서 날짜는 임베딩에 맡기지 않고 검색 조건과 랭킹용 메타데이터로 따로 뺐습니다.

그리고 질의에 담긴 시간 의도를 먼저 셋으로 나눕니다.

as_of: “2026년 7월”, “상반기”처럼 시점이 박힌 질의. 이때만 시작과 끝이 정해진 UTC 범위로 결정론적으로 풀어 검색 전에 하드 필터로 겁니다.
recency: “최근”, “요즘”처럼 최신을 묻지만 정확한 범위를 알 수 없는 질의. 하드 필터를 걸지 않습니다.
agnostic: 시간과 무관한 질의. 마찬가지로 범위 없음.

세 경우 모두 요청이 들어온 시각을 검색 쪽에 같이 넘기는 일을 공통으로 합니다.

그 시각을 기준으로 프롬프트에 오늘 날짜를 적어 주고, 그 시각보다 뒤에 발행된 문서는 결과에서 뺍니다. 모델은 오늘이 며칠인지 모르고, 날짜 라이브러리가 알아서 잡는 “지금”도 서버 시계와 시간대에 따라 달라질 수 있습니다.

그래서 날짜 계산만큼은 요청 시각을 받아 코드에서 직접 하기로 했습니다. 그리고 as_of로 분류됐는데 표현을 해석하지 못하면 필터 없이 통과시키는 폴백을 뒀습니다. 시간 조건을 잘못 걸어서 있는 문서를 못 찾는 쪽이 더 나쁘다고 봤기 때문입니다.

질의의 시간 의도를 as_of·recency·agnostic 셋으로 판정해 as_of만 하드 필터를 걸고 나머지는 범위 없이 통과시키는 날짜 처리 구조도 — <출처: 작가>

3) 권한 확인은 검색 뒤가 아니라 앞에서

“권한 확인은 항상 검색 뒤가 아니라 검색 앞에서 이뤄져야 한다” Microsoft ISE 팀이 4월에 쓴 글에서 못 박은 문장입니다. 이유도 같은 글에 있는데, SharePoint는 계층적이고 상속되는 권한 체계를 제공하지만, “Blob Storage, 검색 인덱스, LLM 검색 계층과 같은 후속 시스템은 SharePoint의 접근 제어 목록(ACL)을 자체적으로 해석하지 못한다” 때문입니다.

Microsoft는 Copilot 배포 지침에서 배포 전에 할 일의 첫 번째로 “과도하게 부여된 공유 권한 바로잡기(Remediate oversharing)”를 둡니다. AI가 권한을 잘 지켜도 그 권한 자체가 원래 엉망이면 소용이 없다는 이야기죠.

앞 절에서 권한에도 크롤 지연이 있다고 했는데, 그래서 색인된 권한만 믿지 않는 구조가 나옵니다. Atlassian은 같은 글에서 리랭킹이 끝난 뒤 원 제품에 한 번 더 확인한다고 밝힙니다. “재랭킹이 끝난 뒤, 원본 퍼스트파티 또는 서드파티 제품을 기준으로 한 번 더 권한 검증을 수행”

저도 만들면서 같은 결론을 내렸습니다. 검색 단계에서부터 그 사람이 볼 수 있는 문서만 후보에 올라와야지, 다 찾아 놓고 답변 직전에 걸러내는 구조는 늦습니다.

검색 뒤에 권한을 거르면 답변이 늦다는 상단 흐름과, 질문에 호출자 신원을 같이 넘겨 검색 앞에서 볼 수 있는 문서만 대상으로 거르는 하단 흐름을 대비한 다이어그램, Microsoft ISE·Atlassian Rovo·Foundry IQ 사례 포함 — <출처: 작가, Microsoft ISE 블로그, Atlassian 엔지니어링 블로그, Microsoft Learn 문서 기반 재구성>

규모가 있는 회사라면 SSO에서 넘어오는 신원 정보를 기준으로 테이블 스키마 같은 데이터 소스 단위의 접근 제한을 걸어야 하고, 프롬프트에 가드레일을 적는 데서 그치지 말고, 요청이 모델에 닿기 전에 코드가 강제로 거르는 하드룰로 박아 둬야 합니다. 누가 어떤 테이블을 볼 수 있는지는 모델이 아니라 코드가 판단해야 합니다.

4) 출처, 그리고 출처가 없을 때

Uber는 사내 온콜 코파일럿을 만들면서 벡터 DB 검색 결과마다 sub-context 절과 그 소스 URL을 명시적으로 함께 넣었다고 밝혔습니다. 같은 회사가 2025년에는 에이전틱 RAG로 바꾼 뒤 수용 가능한 답변 비율이 상대적으로 27% 늘고 잘못된 조언이 상대적으로 60% 줄었다고 자체 측정 결과를 발표했습니다. 절대값이 아닌 상대 개선치이고, 대상은 보안, 프라이버시 정책 문서 40여 건에 골든 질의 100여 건입니다. 평가자는 내부 전문가고요.

여기서부터는 출처를 어떻게 붙이느냐가 아니라, 출처가 없을 때 답을 할지 말지의 문제입니다.

저는 이 규칙을 좀 극단적으로 적용해, 검색 결과가 없으면 LLM을 아예 호출하지 않고 “찾지 못했다”를 반환하게 했습니다. 그럴듯한 문장을 만들어 볼 기회 자체를 주지 않는 겁니다. 다만 “찾지 못했다”를 판정하는 것 자체가 생각보다 어렵습니다. 검색 엔진은 원래 유사한 것을 최대한 긁어모은 뒤 정말 아무것도 없을 때만 없다고 말하는 쪽으로 만들어져 있습니다. 그게 검색 엔진 바닥의 오랜 규칙이라, 없다는 답을 자신 있게 내놓으려면 어디까지를 찾은 것으로 칠지 기준이 먼저 있어야 합니다.

그리고 이 규칙을 평가 지표에 박아 넣었습니다. 골든셋에 함정 질문을 섞어 두고, 함정 질문은 “찾지 못했다”를 반환해야 정답으로 채점합니다. 모른다고 답해야 점수가 오르는 항목을 만들어 둔 셈인데, 이렇게 안 해 두면 정확도를 올리려는 모든 튜닝이 일단 뭐라도 답하자는 방향으로 흐를 수도 있었습니다. 모른다고 답하는 쪽에 점수를 주자는 발상은 앞서 인용한 할루시네이션 논문 리뷰의 영향이기도 합니다.

2026년, 회사들은 ‘검색 다음에 남는 문제’를 뭐라고 부르나

1) 이름은 다 다르고, 표준은 없습니다

앞의 문제들을 각 회사가 어떻게 부르는지 원문 표현 그대로 모아 봤습니다.

Microsoft IQ: 최상위 계층. “기업 AI를 위한 통합 지능 계층”이고 구성은 Work IQ / Fabric IQ / Foundry IQ / Web IQ 넷입니다.
Foundry IQ: 그 아래 항목이고 “기업 데이터를 위한 관리형 지식 계층”으로 정의됩니다. 색인과 검색 인프라는 Azure AI Search가 맡습니다.
AWS: 최상위 용어가 Semantic Layer이고 Knowledge Layer는 그 안의 여러 층 가운데 하나입니다. ontology(T-Box)를 인스턴스 데이터(A-Box)에 적용해 데이터를 지식으로 바꾸는 DIKW의 knowledge tier라고 설명합니다.
Snowflake: 정의되는 용어는 semantic layer와 semantic view입니다. 사내 블로그 제목에는 “사내 컨텍스트 레이어”가 있지만 본문에서 context layer가 정의되지는 않습니다.
Databricks: Unity Catalog semantics. 카탈로그 데이터 위에 표준 지표와 용어, 조직 구조를 정의하는 도구 모음이라고 쓰고, semantic layer나 knowledge layer라는 표현은 이 문서에서도, 핵심 구현을 설명하는 metric views 문서에서도 쓰지 않습니다.
그 밖에: Glean은 콘텐츠, 사람, 활동을 잇는 라 부르고, Palantir는 를 “조직을 위한 운영 계층”으로 정의하면서 actions와 functions 같은 실행 요소까지 범위에 넣습니다. 애널리스트인 는 context layer라 부르고요.

제품 자체를 knowledge layer라고 정의하는 곳은 Microsoft Foundry IQ 한 곳이고, AWS는 Knowledge Layer를 제품명이 아니라 참조 아키텍처 안의 계층 이름으로 씁니다. 아직 “업계 표준 용어”라고 부르기는 어려운 상태로 보입니다.

2) 그런데 의미 규격에는 모이기 시작했습니다

이름은 제각각이지만, 지표와 온톨로지를 적는 형식만큼은 한 규격으로 모이기 시작했습니다. 저는 이름 싸움보다 이쪽이 중요하다고 봅니다.

2025년 9월 Snowflake, Salesforce, dbt Labs 등 17개사가 Open Semantic Interchange를 출범시켰습니다. 목표는 “공통의, 벤더 중립적인 시맨틱 모델 규격”이고, 문제 진단은 “도구마다 비즈니스 지표와 메타데이터를 다르게 해석한다.”입니다.

11월엔 AWS, Informatica, JPMC 등이 합류해 26곳이 됐고, 2026년 7월 8일 이 이니셔티브가 Apache 인큐베이터에 받아들여져 Apache Ossie (Incubating)로 이름을 바꿨습니다. 참여 규모는 “50개 이상의 조직”이고, 아직 최상위 프로젝트가 아닌 인큐베이팅 단계입니다.

범위도 정확히 해 두면, Ossie는 “시맨틱 레이어와 온톨로지 양쪽을 위한 개방 규격”, 곧 지표, 차원, 관계와 비즈니스 규칙을 적는 형식이지 검색이나 권한, 최신성까지 묶는 규격은 아닙니다.

이름은 아직 회사마다 다르지만 규격은 하나로 모이고 있습니다. 경쟁사들이 지표와 온톨로지를 적는 형식까지 맞추기로 했다는 건, 검색 다음에 생기는 문제, 적어도 그중 정합성만큼은 다들 같은 문제로 보고 같은 방향으로 풀고 있다는 뜻으로 보입니다.

3) 그럼 RAG라는 말은 사라진 건가?

Microsoft의 agentic retrieval 문서는 이 기능을 RAG 패턴을 위한 것으로 정의하고, 문서 설명문도 “더 나은 RAG와 에이전트 워크플로를 위해”입니다. 더 눈에 띄는 건, 이번에 원문을 확인한 여섯 곳의 2025년 9월 이후 신규 제품과 객체 이름에 RAG가 하나도 붙지 않았다는 점입니다.

knowledge base, knowledge source, agentic retrieval, Horizon Context, Unity Catalog semantics, Enterprise Graph(2025년 9월 발표), Knowledge Layer, Context Engine이 그 목록입니다.

사견으로, 적어도 이번에 본 벤더들의 최근 제품명에서는 RAG보다 knowledge, context, semantic이 앞에 나옵니다. RAG가 사라진 게 아니라 구현 기법 쪽으로 내려가고 있는 것으로 보입니다.

LlamaIndex는 2025년 5월에 “RAG는 죽었다, 에이전틱 검색이여 영원하라”라는 제목의 글을 올렸는데, 제목은 죽음을 말하고 결론은 검색이 더 중요해졌다는 쪽이었습니다. (프레임워크 벤더의 마케팅 언어라는 점은 감안해야 합니다.)

4) 그래서 이 글에서 말하는 Knowledge Layer는?

AI가 여러 지식원 위에서 의미, 관계, 검색, 권한, 출처, 최신성을 함께 고려해 지식을 사용할 수 있게 해 주는 중간 계층이라는 아키텍처 관점입니다. 특정 제품이나 구현(기술) 이름이 아니라 역할 이름으로 쓰는 셈입니다.

AWS 기준으로 문서 청킹과 벡터 검색은 Data Layer 소관이고 Knowledge Layer가 아닌데, Microsoft는 chunking과 임베딩을 Foundry IQ의 능력으로 열거합니다. 두 회사가 같은 단어를 써도 가리키는 범위가 다르고, 부분적으로만 겹칩니다.

그래서 Knowledge Layer는 무엇으로 되어 있나?

1) 실제 구현은 하나의 제품이 아니라 조립식입니다

AWS 가이드에서 Knowledge Layer의 내부를 열어 보면 완제품 하나가 아니라 네 덩어리를 조립한 구조입니다.

Virtual Knowledge Graph 서비스는 원본을 옮기지 않고 그래프처럼 질의하게 해 주고, Neptune은 ontology와 인스턴스 데이터를 저장합니다. 추론기와 규칙을 처리하는 Symbolic Reasoning 서비스, 지표 정의를 담는 Metric Store가 나머지 둘입니다.

그러니까 “Knowledge Layer를 도입한다”는 문장은 실제로는 “이 중에 우리한테 필요한 걸 고른다”에 가깝습니다. 사견으로, AWS 목록의 중심에 Neptune 같은 자사 서비스가 놓여 있는 건 이 참조 아키텍처가 곧 판매 구성이기도 하다는 뜻이라, 목록을 그대로 따라 사기보다 우리 문제에 맞는 부품만 고르는 게 맞다고 봅니다.

AWS와 Microsoft가 각각 Virtual Knowledge Graph·Neptune·Symbolic Reasoning·Metric Store, knowledge base·knowledge source·agentic retrieval·질의 시점 권한 강제로 나열한 Knowledge Layer 구성요소 비교표 — <출처: 작가, AWS Prescriptive Guidance 및 Microsoft Learn 문서 기반 재구성>

2) Vector DB도, Knowledge Graph도, Ontology도 그 자체로는 아닙니다

“온톨로지를 도입했으니 지식 계층이 생겼다!” 가 가장 흔한 오해인 것 같은데, W3C의 OWL 2 정의를 보면, ontology는 “세계의 어떤 부분에 대한 정밀한 서술문의 집합”으로 정의되고 구성은 classes, properties, individuals, data values입니다.

검색도, 권한도, 실행도 이 정의 안에 없습니다.

Microsoft가 역할을 나눠 쓴 문장도 이 구분을 보여 줍니다. “온톨로지는 무엇이 왜 연결되는지를 선언하고, 그래프는 그 연결을 저장하고 순회한다.” 그래프 쪽 대표 사례인 GraphRAG도 정확히 쓰면 문제를 해결했다기보다 해결을 제안하고 입증을 시도한 쪽이고요.

3) MCP로 다 연결하면 되는 것 아닌가요?

MCP 스펙이 스스로 뭐라고 말하는지 먼저 보겠습니다. (2026년 7월 28일 개정판 기준)

자기 정의: “LLM 애플리케이션과 외부 데이터 소스, 도구를 매끄럽게 통합하게 해 주는 개방형 프로토콜”
아키텍처: “MCP는 무상태 프로토콜이다. 모든 요청은 자기완결적이며 프로토콜 버전과 기능 정보를 스스로 지닌다.” 2025년 11월판까지는 “상태를 가진 세션 프로토콜(a stateful session protocol)”이었는데, 이번 개정에서 initialize 핸드셰이크와 세션을 걷어내고 무상태로 바꿨습니다.
Resources: “사용자나 AI 모델이 쓸 컨텍스트와 데이터”. URI로 식별되고 “텍스트 또는 바이너리 데이터를 담을 수 있는” 형태로 전달됩니다.
범위 열거: Base Protocol에 서버 기능 Resources / Prompts / Tools, 클라이언트 기능 Elicitation, 그리고 설정과 진행률, 취소, 오류 보고 같은 부가 유틸리티. 예전에 있던 Sampling과 Roots, 로깅은 이번 개정에서 deprecated로 내려갔고, Tasks 같은 것은 코어 밖의 확장으로 빠졌습니다. 설계 원칙은 여전히 “코어 프로토콜은 최소한의 필수 기능만 제공한다.”입니다.

스펙이 규정하는 범위는 연결입니다. 다만 MCP 스펙에도 Security and Trust & Safety 절은 있어서, “MCP는 신뢰를 안 다룬다”고 쓰면 틀립니다. 그 절이 다루는 건 사용자 동의와 도구 안전성 쪽입니다. 규모로는 이미 표준이라 불러도 될 만합니다. 2024년 11월 공개 뒤 2025년 12월 Linux Foundation 산하 재단에 기부됐고, 그 시점에 활성 공개 서버가 1만 개를 넘었다고 하니까요.

제가 쓴 글에서 “MCP는 연결 표준이지 검색 품질 표준이 아닙니다. 검색이 구리면 MCP로 연결해도 구리다.”라고 썼는데요. 지금은 검색 품질만이 아니라 앞에서 본 정합성, 최신성, 권한, 출처의 우선순위까지도 이 스펙이 정해 주지는 않습니다.

그래서 저는 그 규칙을 MCP 서버 코드 안에 직접 넣었습니다. 밖으로 내놓은 도구는 위키 검색과 문서 가져오기 둘뿐입니다.

어려웠던 건 이 서버를 호출하는 쪽이 사람이 아니라 LLM 에이전트라는 점이었습니다. 사람이 쓰는 화면이면 입력값은 폼이 제한해 주고, 이상한 결과가 와도 사람이 알아채고 넘깁니다. 에이전트는 다릅니다. 호출 인자를 스스로 지어서 넘기고, 서버가 돌려준 문서 내용을 그대로 다음 판단의 재료로 씁니다. 그래서 값이 엉뚱하게 들어올 수 있고, 문서 안에 적힌 문장을 자기한테 내린 지시로 착각할 수도 있습니다. 그런 일이 생겨도 서버 쪽에서 막히도록 규칙을 코드에 넣어야 했습니다.

# 실제 코드는 아니고, 사내 시스템의 MCP 도구 처리 규칙을 흐름만 남겨 재구성한 의사코드# 전체 보안 설계가 아니라 MCP 서버가 책임지는 입력 통제의 일부만 단순화한 것def wiki_fetch(doc_id, char_offset=0, limit=None):    limit = clamp(limit or LIMIT_DEFAULT, 1, LIMIT_MAX)   # 호출하는 에이전트가 아무 값이나 넘길 수 있으니 서버가 범위를 강제    body = load(doc_id)    if char_offset > len(body):        # 빈 응답을 "내용 없음"으로 오해하지 않도록 범위 초과를 명시적으로 알린다        return error(f"char_offset {char_offset:,}이 본문 길이({len(body):,}자) 범위를 벗어난다")    body = sanitize(body)              # 1. 정화: 원천 문서를 지시로 오독하지 않게    body = truncate(body, MAX_FETCH)   # 2. 자르기: 최대 길이는 실제로 넘어가는 결과 기준이어야 컨텍스트 예산이 지켜진다    return wrap_with_boundary(body)    # 3. 경계 태그

예를 들어, 에이전트가 한 번에 가져갈 글자 수(limit)는 에이전트가 아무 값이나 만들어 넘길 수 있으니, 서버가 최소 1에서 최대치 사이로 강제로 맞춥니다. 코드의 clamp가 그 일을 합니다.

본문을 자를 때의 최대 길이도 서버가 마지막에 내보내는 결과 기준으로 잡습니다. 에이전트가 한 번에 읽을 수 있는 양(컨텍스트 창)은 정해져 있어서, 문서 하나가 그 안을 다 차지하면 질문과 지시, 다른 검색 결과가 밀려나고 비용도 그만큼 늘어납니다. 그래서 도구 하나가 내보내는 글자 수에 상한을 두는데, 그 상한은 정화와 경계 태그를 거쳐 실제로 에이전트에 넘어가는 결과 기준이어야 지켜집니다. 빈 응답 대신 오류 문구를 돌려주는 것도 같은 이유인데, 에이전트가 빈 응답을 “내용이 없다”로 읽어 버리면 그 다음 판단이 통째로 틀어지니까요.

정리하면 MCP는 연결까지만 책임집니다. 어떤 문서를 얼마나, 어떤 순서로, 어떤 검사를 거쳐 에이전트에 내보낼지는 프로토콜이 아니라 서버를 만드는 사람이 정해야 했습니다.

Knowledge Layer라고 그래프나 온톨로지부터 필요한 건 아닙니다

1) ‘그래프만 세팅하면 강력한 컨텍스트가 생긴다’는 근거는 생각보다 약합니다

GraphRAG-Bench 논문은 첫 번째 관찰로 “단순 사실 검색 과제에서는 기본 RAG가 GraphRAG와 비슷하거나 더 낫다.”를 답니다.

다른 체계적 평가 논문의 결론은 한 문장입니다. “RAG와 GraphRAG는 한쪽이 일관되게 이기기보다 서로 보완적인 양상을 보인다.”

같은 논문이 비용도 적어 뒀는데, 인덱싱 구축 시간이 커뮤니티 기반 GraphRAG 5,560초 대 일반 RAG 135초였습니다. 평가 방법을 뒤집어 본 연구는 기존 GraphRAG 평가에 “두 가지 치명적 결함, 즉 무관한 질문과 평가 편향”이 있고, 편향을 빼고 재면 이득이 훨씬 온건해진다고 합니다.

그렇다고 “그래프는 소용없다”는 뜻은 아닙니다. 지금까지 보고된 이득 가운데 상당수가 평가 방법 때문에 부풀려졌다는 비판이지, 조건이 맞으면 그래프가 이깁니다. 통신 규격 문서처럼 좁고 밀도 높은 도메인에서는 GraphRAG가 앞섰다는 결과도 있습니다. 가장 최근 논문은 에이전틱 검색이 “성능 격차를 좁힌다.”고 하면서도, “그럼에도 복잡한 다단계 추론에서는 GraphRAG가 여전히 유리하다.”고 덧붙입니다. 격차를 좁힌 것이지 없앤 게 아닙니다.

그래프를 도입하고 나서가 더 어렵다는 이야기도 많습니다. 온톨로지스트 Kurt Cagle과 Chloe Shannon은 “실패한 지식 그래프의 수가 성공한 것의 수를 훨씬 넘어선다.”라고 썼는데요.

이들이 든 실패 유형 중 눈에 띄는 게 “컨텍스트 창 쑤셔 넣기”입니다. 지식 그래프를 AI에 붙이라는 조언을 너무 곧이곧대로 받아들여, 그래프의 큰 덩어리를 통째로 LLM 컨텍스트 창에 밀어 넣고 토큰 비용만 키우는 경우를 말합니다. 두 사람은 그래프를 미리 다 퍼 주지 말고 AI가 필요한 정보만 그때그때 질의하게 하라고 권합니다.

2) 그래서 언제 넘어가야 할까요?

진부하지만 답은 “기술이 아니라 회사가 준비돼 있느냐” 입니다. 데이터 일을 10년 가까이 하고 지금은 미디어테크 회사에서 데이터 조직을 이끄는 Tomas Peluritis가 쓴 글에서, 기반 없이 semantic layer를 올리면 “그럴싸한 채팅 화면을 단, 아주 자신만만한 오답 기계”가 된다고 합니다. 여기서 말하는 기반은 합의된 지표 정의, 문서화된 규칙, 소유권, 테스트, 접근 정책입니다.

DDD(도메인 주도 설계)의 유비쿼터스 언어(Ubiquitous Language), 그러니까 한 팀이 같은 단어를 같은 뜻으로 쓰자는 약속을 먼저 세우는 게 이 기반의 첫 줄일 겁니다. 그게 없으면 온톨로지 도구를 들여와도 서로 다른 뜻을 정교하게 저장하는 일밖에 안 된다고 봅니다.

저자가 보는 진짜 위험은 환각이 아니라, 오해석이라고 합니다. 환각은 모델이 없는 사실을 지어내는 것이고, 오해석은 데이터는 진짜인데 질문을 잘못 알아듣고 답하는 것입니다. 앞의 활성 고객 예로 돌아가면, 있지도 않은 고객 수를 만들어 내면 환각이고, 무료 체험 계정까지 넣어 센 숫자를 “활성 고객 수”라고 정확히 계산해 주면 오해석입니다. 숫자 자체는 틀린 데가 없으니 받아 보는 사람은 잘못된 줄도 모르고, 검수를 해도 뭐가 틀렸는지 바로 알아보기 힘듭니다.

정리하면, 판단 기준은 이 정도인 것 같습니다. 코퍼스가 하나고 권한 구조가 단순하고 질의응답만 한다면, 잘 설계한 RAG로 충분합니다.

반대로 여러 소스를 붙여야 하고 같은 대상의 정합성, 관계, 권한, 출처, 최신성이 반복해서 문제가 된다면 그때부터는 검색기를 더 튜닝해서 안 풀립니다.

코퍼스 개수·권한 구조·정합성 최신성 출처 문제 반복 여부 세 기준으로 잘 설계한 RAG로 충분한지 검색기 튜닝으로 안 풀리는 지식 설계가 필요한지 가르는 판단 흐름도 — <출처: 작가>

마치며: RAG 다음이 Knowledge Layer라는 말은 RAG의 죽음이 아닙니다

RAG 원논문 공저자인 Douwe Kiela는 인터뷰에서 “MCP는 그저 프로토콜일 뿐이다. MCP를 써도 결국 하고 있는 건 RAG다.”라고 말했습니다.

RAG라는 이름을 만든 사람이 “이름만 바뀌었다”고 말하는 셈이라 무게가 있습니다. 다만 두 가지는 같이 봐야 합니다. Kiela도 RAG 제품을 파는 회사의 대표이고, 그가 비판한 대상은 MCP와 context engineering이지 knowledge layer가 아닙니다.

제가 보기엔 RAG가 죽은 게 아니라, 시스템 전체를 부르던 이름 자리에서 내려와 그 안에서 쓰는 기술 방법론 중 하나가 된 것에 가깝습니다. 검색은 사라지지 않고, 그 위에 의미, 권한, 출처, 시간을 다루는 층이 얹힌 형태요.

다시 처음 질문으로 돌아가 보겠습니다. 이 회사들이 서로 다른 이름으로 풀고 있는 문제는 하나였습니다. 검색이 찾아온 것을 조직의 지식으로 쓰려면, 같은 대상을 같은 것으로 세고(정합성), 지금 유효한 값을 고르고(최신성), 볼 수 있는 사람에게만 보여 주고(권한), 어디서 왔는지 밝혀야(출처) 한다는 것입니다. 관련 문서를 잘 찾아주는 문제와는 다른 문제입니다.

Microsoft는 이걸 knowledge layer로, AWS는 Semantic Layer 안의 한 층으로, Snowflake는 context layer로 부르지만, 검색 위에 이 네 가지를 얹는다는 점은 같습니다.

검색은 어떤 문서를 가져올지를 정하고, 지식 계층은 가져온 문서를 믿어도 되는지, 지금 값이 맞는지, 이 사람이 봐도 되는지, 어디서 온 것인지를 정합니다.

지금 당장 시작한다면, 온톨로지와 같은 기술적 방법론보다는 앞의 네 가지를 각각 한 줄로 적어 보는 게 어떨까요?

정의가 갈리는 지표가 무엇인지, 어떤 소스가 며칠 지연되는지, 권한 판정이 검색 앞인지 뒤인지, 답변에 출처가 붙는지요. 적어 보고 볼 것은 네 가지 중 몇 개가 문제냐가 아니라, 검색 결과가 맞아도 잘못된 판단이나 행동으로 이어지는 일이 반복되느냐입니다. 그게 반복된다면 그때가 검색을 더 튜닝하는 대신 지식 설계 쪽을 볼 시점인 것 같습니다.

<출처>

벤더 공식 문서

표준 규격 문서

벤더 블로그와 발표

기업 엔지니어링 블로그

논문

이 글은 AI의 도움을 받아 작성했습니다.