그래프 엔지니어링이란 무엇인가 — 「프롬프팅은 죽는다」의 출처를 쫓아보니

안녕하세요, 주식회사 TIMEWELL의 하마모토 류타입니다.

X에서 흘러온 게시물의 스크린샷을 봤습니다. Google Brain 설립에 관여한 앤드류 응(Andrew Ng)의 발언으로, 이렇게 적혀 있습니다. 「프롬프팅은 6개월 안에 죽는다. 루프와 그래프가 그것을 대체할 것이다.」 스탠퍼드에서의 2시간 강의에서, 라는 단서가 붙어 있습니다.

그래프는 저희의 핵심 기술이라, 솔직히 이건 아전인수하기 좋은 이야기입니다. 그래서 먼저 출처를 확인했습니다. 결과를 먼저 씁니다. 이 발언, 일차 자료에 닿지 못했습니다.

출처를 쫓았지만, 원천에 닿지 못했습니다

같은 취지의 게시물이 여러 계정에서 나오고 있습니다. 다만 나란히 놓고 보면 문구가 일치하지 않습니다.

「프롬프팅은 6개월 안에 죽는다. 뛰어난 AI 엔지니어는 이미 자기개선 루프를 만들고 있다.」 「프롬프팅은 6개월 안에 죽는다. 그래프가 그것을 대체한다.」 「3~6개월 안에 모두가 자기개선 루프를 쓰게 된다. 프롬프팅은 더 이상 없다.」

대체되는 대상이 게시물마다 루프이기도, 그래프이기도, 양쪽 다이기도 합니다. 같은 강의를 들은 사람들이 같은 발언을 인용한다면 이렇게 갈리기 어렵습니다. 전언 게임의 징후라고 봤습니다. 응 본인의 계정, DeepLearning.AI의 발신, 스탠퍼드 측의 공지를 확인했지만, 이 발언에 대응하는 일차 자료는 찾지 못했습니다¹.

여기는 신중하게 씁니다. 찾지 못한 것이 말하지 않았다는 증명은 아닙니다. 제가 찾을 수 있는 범위에 없었다, 그뿐입니다. 다만 확인되지 않은 것을 확인된 것처럼 인용하면, 그 뒤의 이야기가 전부 흔들립니다.

확인된 사실 쪽을 씁니다. DeepLearning.AI에는 「Agentic Knowledge Graph Construction」이라는 강좌가 실재합니다. Neo4j와의 공동 개발이며, 강사는 같은 회사의 Andreas Kollegger입니다. 앤드류 응은 이 강좌의 강사가 아닙니다². 내용은 Google의 Agent Development Kit을 사용해, 구조화 데이터와 비구조화 데이터에서 노드와 관계를 추출하는 복수의 에이전트를 설계하고, 제품 불량의 근본 원인을 찾아내는 지식그래프를 자동 구축하는 것입니다. 3시간 8분, 12개의 영상 강의².

응 본인의 주장으로 확인되는 것은 2024년에 정리한 에이전트형 워크플로의 네 가지 디자인 패턴입니다. Reflection(성찰), Tool use(도구 사용), Planning(계획), Multi-agent collaboration(복수 에이전트 협업)³.

즉 퍼지고 있는 한 문장의 진위는 차치하고, 그래프로 조립하는 흐름이 실재한다는 것은 확인할 수 있습니다. 여기서부터는 그 내용의 이야기입니다.

그래프 엔지니어링이란 무엇인가

한마디로 말하면, 데이터를 **노드(사물)**와 **엣지(관계)**로 설계하고, 관계 자체를 검색과 추론의 대상으로 삼는 설계 기법입니다.

일반적인 RAG를 떠올려 보십시오. 질문문을 벡터로 변환해 비슷한 텍스트를 찾아옵니다. 잘 만들어진 구조지만, 이 방식이 갖고 있지 않은 정보가 하나 있습니다. 문서끼리의 연결입니다.

예로 생각하는 편이 빠릅니다. 「A사의 모회사의, 또 그 모회사는 어디인가」라고 물었다고 합시다. 벡터 검색은 「모회사」라는 단어를 포함한 비슷한 문서를 돌려줍니다. 운이 좋으면 답이 적힌 문서에 걸리지만, A사에서 B사로, B사에서 C사로 두 단계 거슬러 올라가는 작업 자체는 유사도 계산 어디에도 포함되어 있지 않습니다. 비슷한지와 이어져 있는지는 다른 정보입니다.

그래프는 여기가 다릅니다. A사라는 노드에서 「모회사이다」라는 엣지를 따라 B사에 닿고, 한 번 더 따라가 C사에 닿는다. 답을 찾는 것이 아니라 조립하는 것입니다. 이 차이가 답을 얻을 수 있는지 없는지를 가르는 장면이 실무에는 꽤 있습니다.

작업의 중심은 스키마 설계입니다. 어떤 노드 유형을 둘 것인가(회사, 사람, 제품, 안건, 규정 조문), 어떤 관계 유형을 둘 것인가(출자한다, 공급한다, 승인했다, 참조하고 있다). 여기가 엉성하면 나중에 아무리 좋은 모델을 얹어도 답은 나오지 않습니다. 앞서의 강좌가 「에이전트에게 노드와 관계를 추출시킨다」를 주제로 삼은 것도, 이 설계와 추출이 가장 손이 많이 가는 부분이기 때문이라고 봅니다.

스키마를 건너뛰면 어떻게 되는가. 흔한 실패는 관계 유형을 「관련된다」 하나로 뭉뚱그리는 패턴입니다. A와 B가 관련되어 있다고만 기록하면, 출자한 것인지 공급한 것인지 단순히 같은 자료에 나온 것인지 구분되지 않습니다. 엣지에 의미가 없는 그래프는 결국 점의 집합과 다르지 않습니다. 뒤집어 말하면, 관계 유형을 제대로 나눈 순간부터 따라갈 수 있는 질문이 단번에 늘어납니다.

또 하나, 의외로 놓치기 쉬운 것이 시간입니다. 출자 관계도 공급 관계도 언제부터 언제까지의 이야기인지에 따라 답이 달라집니다. 엣지에 유효기간을 갖게 하지 않으면, 3년 전에 해소된 지분 관계로 오늘의 판단을 해버립니다. 과거 시점의 상태로 돌아가 확인하고 싶다는 요구는 나중에 반드시 나옵니다. 처음에 넣어 두는 편이 쌉니다.

「루프와 그래프」는 사실 다른 층의 이야기

퍼지고 있는 게시물이 헷갈리는 것은 루프와 그래프를 나란히 놓고 말하는 점입니다. 이 둘은 같은 층의 이야기가 아닙니다.

그래프는 지식의 구조 이야기입니다. 무엇과 무엇이 어떻게 이어져 있는지를 시스템이 갖고 있는 형식. 루프는 실행의 제어 이야기입니다. 한 번 출력하고 끝내지 않고, 결과를 평가해 다시 하는 흐름. 응의 네 패턴으로 말하면 Reflection이 루프 쪽, Planning이 그래프 쪽 발상에 가깝습니다³.

양쪽을 쓰는 설계는 당연히 있지만, 「프롬프트가 루프와 그래프로 대체된다」는 표현은 층이 다른 두 가지를 하나의 주어로 묶어버린 것입니다. 개인적으로는 프롬프트가 죽는 것이 아니라, 프롬프트가 놓이는 자리가 바뀐다는 이해가 구현에 가깝다고 느낍니다. 사람이 매번 채팅창에 긴 글을 치는 대신, 그래프의 구조와 루프의 제어가 그 역할의 대부분을 떠맡는다. 프롬프트 자체는 시스템 안쪽에 남습니다.

수출통제는 원래 그래프의 문제였습니다

여기서부터는 저희가 실제로 손을 대고 있는 영역입니다.

수출통제의 거래처 스크리닝은 본질적으로 그래프의 문제입니다. 비유가 아니라, 제도가 그런 형태를 하고 있습니다.

가장 알기 쉬운 것이 미국 BIS의 50% 규칙입니다. 명단에 오른 사업자가 직접 50% 이상 보유하는 자회사만이 아니라, 피지배 관계를 합산해 판단합니다. 즉 눈앞의 거래처가 규제 대상이 아니어도, 주주를 거슬러 올라간 곳에 규제 대상이 있으면 영향이 미칩니다. 이것은 주주의 엣지를 따라가 도달 가능한지를 조사하는 작업 그 자체입니다. 한국 수출자 관점의 정리는 BIS 50% 규칙과 한국 수출자에 두었습니다.

실질적 소유자의 특정도 같은 구조입니다. 법인 뒤에 있는 자연인까지 거슬러 올라가므로 여러 층을 올라가게 됩니다. 우려거래자 확인의 실무는 우려거래자 스크리닝 가이드에 정리했습니다.

둘 다 문서의 유사도 검색으로는 원리적으로 풀리지 않습니다. 「이 회사는 위험한가요」라고 물어 비슷한 문서를 돌려받아도, 자본의 연쇄는 따라갈 수 없습니다. 엣지를 따라가는 수밖에 없습니다.

저희 수출통제 AI 에이전트 TRAFEED가 지식그래프를 기반으로 하는 것은 이 때문입니다. 논문 9,000만 건, 특허 1억 건, 연구자 30만 명을 포함한 2억 건 이상의 지식그래프를 갖고 있으며, 거래처의 우려도를 5초 만에 가시화합니다. 오카야마대학과의 공동 실증에서 과거 심사 데이터 약 3만 건을 사용해 AI 판정 정확도 95% 이상을 확인했습니다(자체 조사). 일본 특허 제7862062호를 취득했고, 20개 이상 조직에서 사용되고 있습니다. 다만 일본 외환법상 최종 판정을 하는 것은 귀사의 수출관리 책임자입니다. 출력은 판정의 근거 자료로 사용해 주십시오. 제도상 움직일 수 없는 선입니다.

사내 지식도, 원래는 이어져 있습니다

수출통제는 극단적인 예로 보일지 모릅니다. 하지만 사내 문서도 같습니다.

어떤 사양서는 어느 안건의 것이고, 어느 고객에 묶여 있고, 누가 썼고, 어떤 리뷰를 통과했고, 어떤 불량 보고로 이어졌는가. 쓰인 시점에는 전부 이어져 있던 정보입니다. 그것을 폴더에 넣고 벡터화한 순간, 선이 사라집니다. 비슷한 문서는 나오지만, 「이 불량과 같은 원인의 안건이 과거에 있었는가」에는 답하지 못합니다.

제조업 고객과 이야기하다 보면 가장 많은 것이 이 형태의 고민입니다. 「같은 불량을 5년 전에 다른 사업부가 해결한 것 같다.」 담당자는 그렇게 느끼는데 검색에서는 나오지 않습니다. 당시의 보고서는 남아 있지만, 그 보고서와 지금의 안건을 잇는 선이 어디에도 기록되어 있지 않기 때문입니다. 사람이 그만두는 동시에 선이 사라진다, 는 표현을 들은 적도 있습니다.

ZEROCK에서 GraphRAG를 채택한 것은 이 선을 남기기 위해서입니다. 일본 국내 AWS 서버에서 돌리고, 누가 어떤 지식에 접근할 수 있는지를 통제한 위에, 관계를 따라갈 수 있는 형태로 갖는다. 접근 통제와 그래프는 궁합이 좋아서, 누가 어떤 노드를 봐도 되는지를 엣지 쪽에서 표현할 수 있습니다. 부서도 권한도 결국은 관계이기 때문입니다.

오늘부터 해볼 수 있는 것

긴 이야기가 되었지만, 시작하는 방법은 수수합니다. 두 가지를 듭니다.

첫째, 종이에 스키마를 그려 보기. 자사 업무에 등장하는 「사물」을 다섯 개, 그것들 사이의 「관계」를 다섯 개 적어 봅니다. 회사, 제품, 안건, 사람, 규정. 출자한다, 공급한다, 승인한다, 참조한다, 위반한다. 이것만으로도 지금 갖고 있는 데이터의 어디에 관계가 기록되어 있지 않은지가 보입니다. 대개의 회사에서 관계는 메일과 회의와 누군가의 머릿속에만 있을 것입니다.

둘째, 「관계」를 묻는 질문을 열 개 만들어 지금의 검색에 던져 보기. 「이 부품을 쓰는 제품을 전부 내놓아라」 「이 고객과 같은 업계에서 비슷한 불량이 난 안건은」 「이 거래처의 주주를 거슬러 올라간 곳에 규제 대상이 있는가」. 답하지 못한 질문이, 그래프가 필요한 자리입니다.

서두의 인용으로 돌아갑니다. 저는 그 한 문장을 뒷받침하지 못했습니다. 그래도 그래프로 조립한다는 이야기 자체는 진짜라고 봅니다. 화제가 된 한 문장을 의심하는 것과, 그 너머에 있는 기술을 평가하는 것은 양립합니다. 오히려 컴플라이언스 영역에서 제품을 내는 회사로서는 둘 다 해야 합니다. 뒷받침되지 않은 이야기를 근거로 설계를 바꾸는 것이야말로 가장 나쁜 방식입니다.

사내 지식을 그래프로 다시 갖는 이야기도, 수출통제를 그래프로 조립하는 이야기도, 구체적인 상황을 들려주시는 편이 빠릅니다. 개별 상담으로 연락 주십시오.

---

Footnotes

1. 본 기사에서 검증 대상으로 삼은, 프롬프팅이 6개월 안에 죽는다는 취지의 게시물은 2026년 7월부터 8월에 걸쳐 여러 계정에서 확산되고 있으나, 대체되는 대상이 「self-improving loops」인 것, 「graphs」인 것, 양쪽을 드는 것이 혼재하여 문구가 일치하지 않는다. 본 기사 집필 시점(2026년 8월 9일)에 앤드류 응 본인의 계정, DeepLearning.AI의 발신, 스탠퍼드대학 측의 공지 어디에서도 이 발언에 대응하는 일차 자료를 확인할 수 없었다. 발언이 존재하지 않는다는 증명이 아니라, 확인할 수 없었다는 사실의 기재이다. 확산원 게시물은 인게이지먼트 목적의 전재가 포함되어 있어 개별 URL은 싣지 않는다. ↩

2. DeepLearning.AI 「Agentic Knowledge Graph Construction」. Neo4j와 공동 개발한 강좌로, 강사는 같은 회사 Lead for GenAI Innovation인 Andreas Kollegger. Google의 Agent Development Kit(ADK), Cypher, Neo4j를 사용해 구조화 데이터와 비구조화 데이터에서 노드와 관계를 추출하는 복수 에이전트 시스템을 설계하고, 제품 불량의 근본 원인을 찾아내는 지식그래프를 구축한다. 난이도 Intermediate, 소요 3시간 8분, 영상 강의 12개, 코드 예제 8개, 채점 과제 1개. 앤드류 응은 본 강좌의 강사가 아니다. https://www.deeplearning.ai/courses/agentic-knowledge-graph-construction/ 같은 목록에는 이 밖에 Andreas Kollegger 강사의 「Knowledge Graphs for RAG」, 앤드류 응 강사의 「Agentic AI」가 있다 https://www.deeplearning.ai/courses ↩ ↩²

3. 앤드류 응이 2024년 3월 자신의 계정에서 제시한 에이전트형 워크플로의 네 가지 디자인 패턴(Reflection, Tool use, Planning, Multi-agent collaboration). https://x.com/AndrewYNg/status/1773393357022298617 ↩ ↩²