루프는 죽은 게 아니라 강등됐다 — Graph Engineering이라는 이름의 두 갈래 실체

#25에서 loop engineering을 다룰 때 이렇게 정리했었다. “처음 들으면 또 에이전트 마케팅 신조어인가 싶다. 절반은 맞다. 그런데 까보면 절반은 진짜로 새로운 얘기가 들어 있다.” 한 달 만에 그 다음 이름이 왔다. Graph engineering. prompt engineering, context engineering, loop engineering에 이은 네 번째 이름표고, 7월 중순 X에서 한바탕 유행을 탔다.

이번에도 같은 질문으로 시작하자. 이름을 걷어내면 뭐가 남는가. 미리 답하면 — 남는 게 있는데, 하나가 아니라 둘이다. 같은 이름이 서로 다른 두 실체를 가리키며 쓰이고 있고, 그 둘을 구분하지 않으면 이 용어를 둘러싼 글의 절반은 무슨 얘긴지 알 수 없게 된다.

이름의 계보 — 루프에서 그래프로

용어가 유행하기 2주 전, Josh Simmons가 7월 초에 쓴 글이 출발점이다. 논지는 이렇다. 에이전트 개발의 기본형은 지금까지 “루프 속의 모델”이었다 — while 루프 하나에 도구를 쥐여주고 끝날 때까지 돌리는 것. 그런데 루프에는 구조적 한계가 있다. 한 번에 하나만 실행하는 스케줄러라서, 본질적으로 병렬인 작업까지 전부 직렬로 세운다. 파일 다섯 개를 검토하는 데 서로 읽을 필요가 없다면 그건 다섯 개의 독립된 작업인데, 루프는 그걸 한 줄로 세워놓고 차례를 기다리게 한다.

그래서 명시적인 방향 그래프로 넘어가자는 게 그의 제안이다. 노드는 작업 단위(모델 호출, 함수, 검색, 그리고 사람도 노드다), 엣지는 한 노드의 출력이 다른 노드의 입력으로 흐르는 의존 관계. 인용할 만한 문장이 하나 있다. “루프는 죽은 게 아니다. 강등됐다. 노드 안에서 모델은 여전히 늘 돌던 루프를 돈다. Graph engineering은 노드 사이에서 일어나는 일의 기술이다.”

LangChain은 3주 뒤 “3 Years of Graph Engineering”이라는 글로 응수했다. 우리가 LangGraph로 3년째 하던 게 그거라는 얘기인데, 유행어에 숟가락 얹기라고 넘기기엔 3년 치 교훈이 실질적이다. 첫째, 프로덕션 에이전트 그래프는 DAG가 아니라 순환 그래프다. 재시도, 사람의 개입, 수정 루프가 있어야 하므로 순환이 필수다. 둘째, “루프는 방향 있는 순환 그래프일 뿐”이라는 것 — 루프와 그래프는 대립하는 게 아니라 루프가 그래프의 특수한 경우다. Simmons의 “강등” 표현과 정확히 같은 지점에 다른 길로 도착한 셈이다.

재미있는 사실 하나. Anthropic의 공식 자료들 — Building Effective AI Agents의 orchestrator-workers 패턴, 멀티에이전트 리서치 시스템 회고, Claude Code의 workflow 기능 문서 — 는 팬아웃, 의존 관계, 병렬 실행, 검증 노드까지 이 그래프 개념을 전부 구현하고 있으면서 “graph”라는 단어를 한 번도 쓰지 않는다. 이름은 만든 쪽이 아니라 커뮤니티가 붙였다. 하네스 때(#35)와 같은 패턴이다. 실천이 먼저 퍼지고, 이름이 나중에 도착한다.

같은 이름, 두 갈래

여기까지는 제어 흐름의 그래프다. 그런데 이 용어로 검색을 해보면 전혀 다른 얘기를 하는 글들이 절반쯤 섞여 나온다. 지식 그래프 — 엔티티를 노드로, 관계를 엣지로 저장해서 에이전트가 순회하게 하는 데이터의 그래프 말이다. TrueFoundry의 엔터프라이즈 가이드가 이 구분을 제일 깔끔하게 그었다. “지식 그래프는 시스템이 아는 것을 구조화하고, graph engineering은 시스템이 누구인지를 구조화한다.”

두 갈래는 도구도 스킬셋도 다르다. 하나씩 보자.

갈래 1 — 일의 모양을 그리는 그래프

오케스트레이션 그래프 쪽에서 진지한 글들이 수렴하는 원칙은 하나로 요약된다. 판단은 모델이, 라우팅은 코드가. 어떤 티켓인지 분류하는 건 모델의 일이지만, 분류 결과에 따라 어느 경로로 보낼지는 코드의 if문이어야 한다. 흐름 제어까지 모델에 맡기면 “에이전트가 검증 단계를 건너뛰기로 했다” 같은 창발적 사고가 생기고, 코드로 내리면 같은 입력에 같은 경로가 보장된다.

그래프가 실제로 사주는 건 넓이다. Anthropic의 멀티에이전트 리서치 시스템 회고가 수치를 공개했는데, 병렬 서브에이전트 구조가 단일 에이전트 대비 성능을 90.2% 끌어올렸고 토큰은 15배를 썼다. 넓이는 돈으로 사는 것이고, 그 돈이 아까우면 애초에 일이 쪼개지는지부터 물어야 한다. 각 단계가 이전 단계의 결과 전체를 읽어야 하는 일이라면 그래프로 펼쳐도 같은 답이 더 비싸게 나올 뿐이다. 그래서 이 갈래의 첫 번째 기술은 도구 도입이 아니라 가짜 엣지 지우기다. “A 하고 나서 B”라고 써놓은 파이프라인에서 B가 A의 출력을 실제로 읽는지 확인하고, 안 읽으면 그 순서는 그냥 타이핑한 순서일 뿐이니 병렬로 푼다.

검증 노드에 대한 경고도 공통적이다. Louis Bouchard의 정리에서 제일 뼈 있는 문장 — “에이전트가 에이전트를 검증하는 그래프는 극도로 정돈된 헛소리를 만들 수 있다.” 검증자를 만드는 자신과 분리하는 건 기본이고, 증거의 일부는 시스템 바깥에서 와야 한다. 실제로 돌아간 테스트, 실제로 도착한 응답 같은 것. 모델끼리 서로 채점하는 그래프는 합의를 만들지 사실을 만들지 않는다.

도구는 이미 손에 있다. LangGraph는 월 6,500만 다운로드 규모가 됐고, Claude Code는 workflow 기능으로 이 패턴(팬아웃, 파이프라인, 스키마 검증된 노드 출력)을 프리미티브로 내장했다. 진입 장벽은 도구가 아니라, 자기 시스템을 상자와 화살표로 그려본 적이 있느냐다.

갈래 2 — 아는 것을 담는 그래프

두 번째 갈래의 문제의식은 #25에서 공유 메모리를 다룰 때 이미 반쯤 나왔다. 에이전트가 세션 안에서 알게 된 것은 컨텍스트 윈도우와 함께 사라진다. 벡터 검색으로 저장해두면 “비슷한 텍스트”는 다시 찾을 수 있지만, 문서 세 개에 흩어진 사실을 이어야 답이 나오는 질문은 유사도 검색이 못 잇는다. A가 B의 자회사고 B가 C와 계약했다는 걸 각각 아는 것과, “A와 C의 관계는?“에 답하는 것 사이에는 순회할 구조가 필요하다.

이 갈래에서 제일 좋은 입문 자료는 Anthropic 공식 쿡북의 지식 그래프 구축 가이드다. 파이프라인은 다섯 단계 — 추출, 해소, 조립, 요약, 질의. 설계에서 배울 게 두 가지 있다. 하나는 비용 계층화. 문서마다 돌려야 하는 대량 작업인 추출은 Haiku에게, 판단이 필요한 엔티티 해소·요약·추론은 Sonnet에게 맡긴다. 해소 단계가 이 파이프라인의 급소인데, “Edwin Aldrin”과 “Buzz Aldrin”처럼 글자가 하나도 안 겹치는 두 이름을 문자열 유사도가 아니라 각 엔티티에 붙여둔 한 줄 설명의 문맥으로 병합한다. 다른 하나는 정직한 평가. 이 가이드는 자기 파이프라인의 성적을 숨기지 않는다 — 정밀도 1.00, 재현율 0.55. 지어내는 건 없지만 절반 가까이 놓친다는 뜻이고, “프롬프트를 고치고 점수를 다시 재는 루프가 데모를 프로덕션으로 만든다”고 명시한다. 벤더 튜토리얼이 자기 재현율 55%를 적어두는 건 흔한 일이 아니다.

메모리로 쓰려면 시간 축이 하나 더 필요하다. 사실은 바뀐다 — 주소가 바뀌고 계약이 갱신되고 담당자가 떠난다. 이 문제를 정면으로 설계한 게 Zep의 Graphiti(GitHub 29k 스타)다. 모든 사실에 유효 기간을 붙이는 bi-temporal 모델 — 그 사실이 세상에서 참이었던 시간과 시스템이 그걸 알게 된 시간을 분리해서 기록하고, 모순되는 정보가 오면 덮어쓰는 대신 이전 사실을 무효 처리해 이력을 남긴다. “지난주 시점에 우리가 뭘 알고 있었나”를 물을 수 있는 메모리는 감사가 필요한 도메인에서 벡터 스토어가 못 주는 것을 준다.

비용 얘기를 안 할 수 없다. 이 동네가 오래 못 떴던 이유가 비용이었기 때문이다. 초기 GraphRAG는 인덱싱 시점에 코퍼스 전체를 LLM에 통과시켜서, 2024년 초 기준 5GB 문서 인덱싱에 수만 달러가 들었다는 보고가 있었다. 그 뒤 18개월 동안 Microsoft의 LazyGraphRAG를 비롯한 후속 연구들이 방향을 뒤집었다 — 인덱싱은 싸게 만들고, 비싼 사고는 질문이 실제로 들어온 쿼리 타임으로 미룬다. 인덱싱 비용이 기존의 0.1% 수준으로 떨어졌고, 이 구조 전환이 도입 계산 자체를 바꿔놨다. “그래프 RAG는 비싸서 못 쓴다”는 통념은 2024년의 답이다.

그렇다고 모두에게 필요한 건 아니다. 체계적으로 비교한 연구의 결론이 오히려 절제돼 있다 — 단일 홉 사실 검색에서는 벡터 검색이 그래프보다 낫거나 같은 경우가 많다. 그래프가 값을 하는 조건은 대체로 네 가지로 정리된다. 질의에 멀티홉이 실제로 있는가, 검색 경로를 설명해야 하는가(규제·감사), 데이터가 본질적으로 관계형인가(조직도, 공급망, 금융 네트워크), 코퍼스 전체를 종합하는 질문을 받는가. 넷 다 아니면 벡터와 리랭커로 끝내는 게 맞다. #41에서 “벡터를 어디에 넣을까”의 답이 Postgres로 수렴하는 걸 봤다면, 이번 질문은 그 다음이다 — 벡터로 안 되는 질문이 내 워크로드에 진짜 있는가.

실전: 어디서부터 만져볼까

오케스트레이션 쪽은 도구를 새로 들일 필요가 없다. 지금 쓰는 에이전트 도구에 이미 프리미티브가 있다(Claude Code workflows, LangGraph). 시작은 그리기다. 내 파이프라인을 상자와 화살표로 그리고, 화살표마다 “뒤 단계가 앞 단계의 출력을 실제로 읽나”를 묻고, 안 읽는 화살표를 지운다. 대부분의 직렬 파이프라인에는 이런 가짜 화살표가 두세 개씩 있고, 지우는 것만으로 병렬화 여지가 드러난다. 그 다음이 검증 노드인데, 만드는 노드와 검증하는 노드를 분리하고 검증의 근거 하나는 반드시 시스템 바깥(테스트 실행, 실제 API 응답)에서 가져온다.

지식·메모리 쪽은 사다리가 있다. 개념을 만져보는 데는 MCP 공식 memory 서버가 제일 싸다 — 엔티티·관계·관찰 세 개념을 로컬 JSONL 파일에 저장하는 수백 줄짜리 최소 구현이라 지식 그래프 메모리의 교본으로 읽기 좋다. 진지하게 만들 거면 공식 쿡북 파이프라인을 자기 문서로 돌려보는 게 다음 계단이다. 추출은 Batch API(50% 할인)와 프롬프트 캐싱을 걸면 비용이 절반 아래로 내려가고, 저장은 처음부터 그래프 DB를 들일 필요 없이 Postgres 테이블 세 개(entities, relations, aliases)면 수십만 엣지까지 간다. 사실의 시간 변화가 중요해지는 시점에 Graphiti를, 인프라를 안 늘리고 싶으면 pgvector와 Apache AGE를 한 Postgres에 얹는 단일 엔진 구성을 본다.

순서만 지키면 된다. 그래프를 만들고 싶어서 만드는 게 아니라, 벡터가 못 잇는 질문이 실제로 쌓인 다음에 만든다. 이 갈래의 진지한 실무자들이 공통으로 다는 단서이기도 하다 — 대개는 단순한 검색이면, 대개는 단순한 루프면 충분하다.

관전 포인트

용어가 살아남을지는 모르겠다. 어차피 다음 이름표가 또 올 거다. 남는 건 이름이 아니라 #35에서 하네스를 두고 했던 얘기와 같은 구조다 — 모델은 갈아타도 일의 모양을 그린 그래프와 쌓아둔 지식 그래프는 남는 자산이다.

지켜볼 지점은 두 갈래가 만나는 자리다. 오케스트레이션 그래프의 워커들이 알아낸 것을 메모리 그래프에 쓰고, 다음 날의 루프가 거기서 이어받는 구조 — 두 갈래가 각자 성숙한 지금, 연결 부위가 다음 격전지가 될 가능성이 높다. 다만 그 앞에 미성숙한 것도 둘 있다. 에이전트 메모리 벤치마크는 벤더들끼리 측정 방법론을 두고 공개 설전을 벌일 만큼 아직 흔들리고, 최근 서베이가 지적하듯 메모리를 쌓는 연구에 비해 낡은 사실을 버리는 연구는 공백에 가깝다. 영원히 자라기만 하는 그래프는 자산이 아니라 부채가 된다.

오늘 할 수 있는 건 하나다. 자기 시스템을 상자와 화살표로 그려보는 것. 데이터가 흐르지 않는 화살표를 세어보면, 도구를 하나도 안 바꾸고 지울 수 있는 대기 시간이 보통 거기서 나온다.