이 기사에 대하여

2026년 7월 19일, X에 다음과 같은 제목의 기사가 게시되었습니다.

Graph Engineering replaced RAG at Microsoft, Stanford and Anthropic. Here's how it works.

(Graph Engineering은 Microsoft, Stanford, Anthropic에서 RAG를 대체했다. 그 메커니즘을 해설한다)

120만 회 조회되었습니다. 커버 이미지에는 「Claude Code」라고 적힌 터미널 창 안에 지식 그래프(Knowledge Graph)가 그려져 있고, 중앙에는 Anthropic의 로고, 주변에는 Stanford, Anthropic, Microsoft 3사의 로고가 나열되어 있으며, 「Why they moved beyond RAG」라고 적혀 있습니다.

이 기사에서는 이 주장이 사실인지 1차 정보로 확인합니다.

결론부터 말씀드리겠습니다.

3사는 「그래프」라는 동일한 길로 간 것이 아니라, 3가지의 서로 다른 방향으로 가고 있습니다.

그리고 Anthropic이 실제로 선택한 것은 그래프가 아니라 grep입니다.

그리고 검증의 부산물로서, **「질문의 종류에 따라 올바른 검색 아키텍처(Search Architecture)는 다르다」**는, 실무에서 그대로 사용할 수 있는 정리가 도출됩니다. 그 부분이 본론입니다.

제1부 — Anthropic이 선택한 것은 grep였다

본인이 그렇게 말하고 있습니다

Claude Code의 제작자이자 Anthropic에서 Claude Code를 이끄는 Boris Cherny 씨의 발언입니다. 여러 독립적인 미디어가 동일한 발언을 인용하고 있습니다.

초기 버전의 Claude Code는 RAG와 로컬 벡터 DB(Vector DB)를 사용하고 있었으나,

agentic search가 더 잘 작동한다는 것을 곧바로 알게 되었다. 게다가 단순하며, 보안(Security)·프라이버시(Privacy)·정보의 최신성·신뢰성에 관한 동일한 문제를 안고 있지 않다.

나아가 Latent Space의 팟캐스트에서는 더 깊이 있는 표현을 사용했습니다. agentic search는 RAG를 「by a lot (큰 차이로)」 능가했으며, 그것은 「surprising (놀라운)」 일이었다고 말입니다. 시도해 보았으나 실패한 사례로 로컬 벡터 DB, 모델에 의한 재귀적 인덱싱(Recursive Indexing) 등이 언급되었습니다.

agentic search란 무엇인가

Cherny 씨의 설명은 다음과 같습니다.

에이전트(Agent)에게 필요한 만큼의 검색 사이클로 정보를 찾게 하는 것.

glob나 grep와 같은 일반적인 코드 검색 도구를 사용하여.

즉 내용은 다음과 같습니다.

glob (파일명으로 찾기)
grep (내용의 문자열로 찾기)
파일 읽기
...

이 기사를 쓰고 있는 저 자신의 도구 구성으로도 확인할 수 있습니다. 제가 가지고 있는 검색 계열 도구는 Grep (ripgrep의 래퍼), Glob, Read입니다. 임베딩(Embedding)을 만드는 도구도, 인덱스를 조회하는 도구도, 그래프 DB에 접속하는 도구도 없습니다.

커버 이미지가 「Claude Code」 창 안에 그래프를 그리고 있는 것은 구현 내용과 일치하지 않습니다.

왜 grep이 승리했는가

이유가 정리되어 있으며, 이는 코드 검색에 국한되지 않는 시사점을 줍니다.

마지막 한 점이 은근히 큽니다. 인덱스 측에 기교를 쌓아두면 모델의 진보에 따른 혜택을 받기 어려워집니다.

그리고 Anthropic은 RAG 자체도 개량하고 있습니다

또 하나, 주장과 맞지 않는 사실이 있습니다.

Anthropic은 2024년 9월에 「Contextual Retrieval」이라는 기법을 공개했습니다. 이는 RAG를 버리는 것이 아니라 개량하는 것으로, 각 청크(Chunk)에 임베딩(Embedding) 전 문맥을 부여함으로써 **검색 실패를 49% 감소(리랭킹(Reranking) 병용 시 67% 감소)**시켰다고 보고되었습니다.

즉, Anthropic의 입장은 "RAG는 죽었다"가 아닙니다. 용도에 따라 도구를 바꾸고 있을 뿐입니다.

코드베이스 탐색 (Claude Code) → agentic search
문서의 지식 베이스 검색 → RAG. 단, 문맥을 추가하여 정밀도를 높임

제2부 — Microsoft의 GraphRAG는 「RAG의 일종」입니다

이름이 그렇게 말하고 있습니다

Microsoft의 GraphRAG는 실재합니다. Microsoft Research의 성과로, 2024년 7월에 GitHub에 공개되었습니다. 다만, 그 공식 문서의 첫 문장은 다음과 같습니다.

GraphRAG는,

Retrieval Augmented Generation (RAG)에 대한 구조화된 계층적 접근 방식이다. 단순한 시맨틱 검색 (Semantic Search) 접근 방식과는 대조적이다.

GitHub 리포지토리의 설명도 "a modular graph-based Retrieval-Augmented Generation (RAG) system"입니다.

대체하는 것이 아닙니다. RAG의 한 형태입니다. 이름에 RAG가 들어가 있습니다.

그렇다면 무엇을 위해 만들어졌는가

이 부분이 기술적으로 가장 흥미로운 대목입니다. GraphRAG는 "RAG보다 전반적으로 우수한" 것이 아니라, 베이스라인(Baseline) RAG가 원리적으로 답할 수 없는 종류의 질문을 위해 만들어졌습니다.

Microsoft Research의 논문 제목이 그것을 나타냅니다 — "From Local to Global: A Graph RAG Approach to Query-Focused Summarization".

베이스라인 RAG가 잘하는 것:
"이 제품의 반품 정책은?"
→ 해당 부분을 가져오면 답할 수 있음 (검색 태스크)
...

논문에서는 다음과 같이 설명합니다. RAG는 "데이터셋 전체를 향한 **글로벌한 질문 (Global Query)**에는 실패한다. 이는 본질적으로 검색 태스크가 아니라 query-focused summarization 태스크이기 때문이다."

GraphRAG의 메커니즘

수행하는 작업은 명쾌합니다.

① 문서를 분할한다
② LLM으로 전문을 처리하여 엔티티(Entity)와 관계를 추출하고
지식 그래프 (Knowledge Graph)를 만든다
...

핵심은 ④의 사전 생성입니다. "어떤 질문이 올지 사전에 알지 못하더라도, 데이터셋의 조망을 제공할 수 있는" 구조를 미리 만들어 두는 것입니다.

그리고 대가가 따릅니다

GraphRAG의 GitHub 리포지토리에는 경고가 명시되어 있습니다.

⚠️ 경고: GraphRAG의 인덱싱(Indexing) 작업은 고비용 작업이 될 수 있다. 프로세스와 비용을 이해하기 위해 문서를 모두 읽고, 작은 규모로 시작할 것.

Microsoft Research 자체의 총평도 솔직합니다.

특정 유스케이스에 대한 GraphRAG의 적합성은, 구조화된 지식 표현·기성 커뮤니티 요약·글로벌 쿼리 대응의 이점이

그래프 인덱스 구축을 위한 선불 비용을 상회하는지에 달려 있다.

즉, 저울질입니다. 무조건 좋은 것은 아닙니다.

한 가지 더, 정확히 적어두어야 할 점

GitHub 리포지토리에 다음과 같이 적혀 있습니다.

제공되는 코드는 데모로서 기능하는 것이며,

Microsoft가 공식적으로 지원하는 제공물이 아니다.

"Microsoft가 RAG를 대체했다"라는 주장과의 거리감은 여기서 측정할 수 있습니다. Microsoft는 지금도 Azure AI Search 등을 통해 벡터 검색 (Vector Search)을 주력으로 제공하고 있습니다.

제3부 — Stanford가 한 것은 「아직 어렵다」는 증명입니다

세 번째 회사입니다. 여기가 주장과 가장 어긋나는 부분입니다.

STaRK — 벤치마크이지, 승리 선언이 아니다

Stanford CS(Jure Leskovec 교수 그룹 외)와 Amazon에 의한 STaRK(NeurIPS 2024)는 텍스트와 관계 정보가 혼합된 **반구조화된 지식 베이스 (semi-structured knowledge base)**에 대한 검색 벤치마크입니다. 제품 검색, 학술 논문 검색, 정밀 의료의 3개 영역을 다룹니다.

그리고 그 결론은 이것입니다.

우리의 실험은 STaRK가

현재의 검색 시스템 및 LLM 시스템에 중대한 과제를 제시하고 있으며, 더 능력 있는 검색 시스템을 구축할 필요성을 보여주고 있음을 나타낸다.

즉, Stanford의 공헌은 "그래프로 해결했다"가 아니라, "이것은 어렵고, 아직 해결되지 않았다"를 측정 가능하게 만든 것입니다.

RAGNET — "RAG를 확장했다"라고 적혀 있다

또 다른 Stanford 관련 연구(Sinha, Halal, Pondoc, Potts, Kiela, 2025)의 요지에는 다음과 같이 적혀 있습니다.

GraphRAG에서의 최근 연구는 그래프로부터 데이터를 검색하도록 **RAG를 확장(extended RAG)**해 왔으며, 그래프 구조가 전달하는 정보의 풍부함과 간결함으로부터 이득을 얻어 왔다.

extended RAG — 확장입니다. replaced(대체)가 아닙니다.

나아가 이 논문이 다루고 있는 문제는 실무적으로 중요합니다. 많은 그래프 검색 기법은 "어느 노드와 어느 경로를 택하는 것이 정답인가"라는 교사 라벨 (teacher label)을 필요로 하지만, 실제 기업에서는 최종적인 답만이 손에 쥐어져 있습니다. 따라서 그 약교사 설정 (weakly supervised setting)에서 학습하는 기법을 제안한다는 내용입니다.

요컨대 Stanford의 논문은 그래프 검색의 실운용 난이도에 맞서 싸우고 있는 측입니다.

제4부 — 3사를 나란히 놓으면

1차 정보로 확인한 실태를 하나의 표로 정리합니다.

세 개의 열이 어디 하나 일치하지 않습니다. "그래프 엔지니어링이 3사에서 RAG를 대체했다"라는 문장은 이 세 가지를 하나로 뭉뚱그려 놓은 것입니다.

특히 Anthropic은 그래프와는 반대 방향(인덱스를 가지지 않음, 구조를 사전에 만들지 않음)으로 가고 있습니다.

제5부 — 실무에서 어떻게 선택할 것인가

여기가 본론입니다. 검증 결과로 나오는 것은 "어느 것이 승리인가"가 아니라, 질문의 형태가 도구를 결정한다는 정리입니다.

판단의 축을 하나로 좁힌다면, 이것입니다.

답이 "어딘가 한 곳"에 있는가, 아니면 "전체의 형태"에 있는가.

전자라면 검색(Search)만으로 충분합니다. 후자라면, 사전에 구조를 구축할 가치가 생깁니다. 그리고 선불 비용(Upfront cost)을 몇 번의 질문을 통해 회수할 수 있는가가 그래프(Graph)를 도입할지 여부를 결정하는 분기점입니다.

제6부 — 왜 이런 주장이 퍼지는가

마지막으로, 기술적인 부분이 아닌 측면에 대해서도 언급해 두겠습니다. 이 게시물이 퍼져나가는 방식에는 재현 가능한 패턴이 있습니다.

1. 실재하는 로고로 권위를 빌려온다

커버 이미지에는 Stanford, Anthropic, Microsoft의 실제 로고가 나란히 배치되어 있습니다. 세 회사 모두 실제로 무언가를 수행하고 있기 때문에(GraphRAG, STaRK, agentic search), 완전히 날조된 것은 아닙니다. 문제는 서로 다른 내용들을 하나의 주장 근거로 묶어버렸다는 점입니다.

2. 같은 단어가 다른 것을 지칭한다

"Graph Engineering"이라는 용어는 이 8일 후(7월 27일)에도 다른 인물이 다른 의미로 사용하며 22만 회 노출되었습니다. 그쪽의 내용은 **에이전트(Agent)의 병렬 구성 토폴로지(Topology)**에 관한 이야기로, 노드(Node) = 에이전트입니다. 이 게시물의 "Graph Engineering"은 지식 그래프(Knowledge Graph)를 통한 검색이며, 노드(Node) = 지식입니다.

같은 간판을 걸고 있지만, 내용은 다릅니다. 용어가 정의되기도 전에 도달률(Reach)을 위해 사용되고 있는 상태이므로, 이를 발견하면 "어느 의미인가"를 확인해야 합니다.

3. 독자들은 꽤 눈치채고 있다

이 게시물에 달린 답글 중 가장 반응이 많았던 것은 "Stop writing articles with ai"였습니다. 다른 답글로는 "Karpathy의 obsidian wiki 이야기와 무엇이 다른가?", 또 다른 하나는 "GraphRAG without a graph database"라고 재정의하는 것이었습니다.

조회수는 도달률의 지표이지, 정확성의 지표가 아닙니다.

검증할 수 없었던 점

정직하게 적어둡니다.

저는 원문 기사의 본문을 읽지 못했습니다. X(구 트위터)의 장문 게시물은 로그인이 필요하며, 기사 본문을 가져오려고 시도했을 당시에는 접근할 수 없었습니다.

이 글에서 검증한 것은 제목의 주장과 커버 이미지입니다. 이 두 가지는 단독으로 검증이 가능하며, 그곳에 제시된 "Anthropic에서 RAG가 그래프로 대체되었다"는 사실과 다릅니다. 다만 본문은 더 신중하게 작성되었을 가능성은 남아 있습니다 (예를 들어 본문에서는 "대체했다"가 아니라 "다른 접근 방식을 취했다"라고 썼을 수도 있습니다).

반면, 이 글에서 제시한 세 회사의 실태는 모두 1차 정보 및 본인의 발언을 통해 확인을 마쳤습니다.

요약

"RAG는 끝났다"라는 말을 보게 된다면, 되물어야 할 질문은 하나입니다.

어떤 질문에 답하기 위한 이야기인가요?

참고

• Sprytix @Sprytixl — "Graph Engineering이 Microsoft, Stanford, Anthropic의 RAG를 대체했다. 작동 방식은 다음과 같다." (2026년 7월 19일, 본문 미독)
• Anthropic — AI 시스템에서의 Contextual Retrieval (2024년 9월 19일)
• Microsoft Research — GraphRAG 공식 문서 / GitHub
• Microsoft Research — From Local to Global: Query-Focused Summarization을 위한 Graph RAG 접근 방식 (2024년 4월)
• Microsoft Research — 복잡한 데이터 탐색을 위한 새로운 도구 GraphRAG, 현재 GitHub에서 이용 가능 (2024년 7월 2일)
• Stanford — STaRK: 텍스트 및 관계형 지식 베이스(Knowledge Bases)에서의 LLM Retrieval 벤치마킹 (NeurIPS 2024, arXiv)
• Stanford — RAGNET: Neural Graph Retrieval을 위한 End-to-end Training (2025)
• Boris Cherny 씨의 발언에 대하여 — Latent Space 팟캐스트 및 여러 미디어 인용

Discussion