그래프 엔지니어링

🏷️ 정보 LLM 에이전트

2026년 "그래프 엔지니어링"이라는 용어는 완전히 다른 두 갈래의 의미로 사용됩니다. 하나는 Neo4j나 FalkorDB 같은 그래프 데이터베이스, Graph RAG, 엔티티 추출 파이프라인을 다루는 세계입니다. 다른 하나는 멀티에이전트 시스템에서 에이전트, 라우터, 휴먼 체크포인트를 노드로 놓고 위임과 통신을 엣지로 설계하는 세계입니다. 둘 다 스스로를 "그래프 엔지니어링"이라고 부릅니다. 이거 참 헷갈리네요. 하나는 LLM이 다룰 지식을 그래프로 구조화해야 한다는 요구에서 나왔고, 다른 하나는 LLM 에이전트 여럿을 조직으로 구조화해야 한다는 요구에서 나왔습니다.

지식을 그래프로 만드는 비용

Graph RAG는 문서에서 엔티티와 관계를 뽑아 그래프로 구성한 뒤, 검색 단계에서 벡터 유사도 대신 그래프 순회로 컨텍스트를 모으는 방식입니다. Microsoft GraphRAG가 이 구조를 대중화시켰지만, 프로덕션에 올려보면 초기 데모와는 다른 문제가 나옵니다. 엔티티 추출을 LLM에 맡기면 정확도는 높지만 대규모 문서 전체를 처리할 때 GPU 비용이 누적되고, 그래프를 자주 갱신해야 하는 도메인에서는 재계산 주기가 늦어집니다.

엔티티 해상도(entity resolution)가 특히 민감한 지점입니다. 두 문서에서 언급된 "김철수"가 같은 사람인지, 그래프 안에서 노드를 정확히 하나로 합칠 수 있는지가 이후 모든 순회 결과를 좌우합니다. 해상도가 낮으면 오류가 한 단계씩 전파되면서 다단계 순회 결과가 통째로 틀어집니다.

비용을 줄이는 방향으로 나온 접근 중 하나가 LLM 대신 고전 NLP를 쓰는 것입니다. 한 연구에서는 SpaCy 기반 의존성 파싱으로 문장에서 직접 삼중항(subject-relation-object)을 추출하는 파이프라인을 제시했는데, LLM 기반 추출 대비 정확도의 94퍼센트를 유지하면서(61.87퍼센트 대 65.83퍼센트) GPU 호출 자체를 없앴습니다. 검색 단계에서는 그래프 기반 1홉 순회와 벡터 유사도를 상호 순위 융합(Reciprocal Rank Fusion)으로 합쳐, 밀집 검색 단독 대비 최대 15퍼센트의 개선을 보였습니다. 정확도를 약간 내주고 확장성과 갱신 주기를 얻는 트레이드오프입니다. 엔터프라이즈 환경에서는 이 트레이드오프를 어느 지점에서 끊을지가 실제 설계 의사결정이 됩니다.

순회 방식의 전환

그래프를 어떻게 구축하느냐 밑에는 그래프를 어떻게 저장하고 순회하느냐가 있습니다. Neo4j를 포함한 대부분의 그래프 데이터베이스는 노드가 이웃 노드를 가리키는 포인터를 하나씩 따라가는 방식으로 순회합니다. FalkorDB는 이 방식 자체를 바꿉니다. 그래프를 희소 인접 행렬(sparse adjacency matrix)로 표현하고, GraphBLAS라는 희소 행렬 연산 표준 API를 통해 순회를 행렬 곱셈으로 처리합니다.

포인터를 하나씩 따라가는 대신 CPU 코어 전반에 걸쳐 병렬로 행렬 연산을 수행하는 셈입니다. FalkorDB 측이 공개한 벤치마크에서는 Neo4j 대비 최대 496배 빠른 지연시간과 6배 나은 메모리 효율을 보고합니다. 자체 벤치마크라 그대로 받아들이기보다는 참고치로 보는 게 맞지만, 방향성 자체는 뚜렷합니다. 그래프 순회를 선형대수 문제로 재정의하면 GPU·SIMD 최적화가 그대로 얹힙니다. FalkorDB는 RedisGraph가 2023년 단종된 뒤 그 자리를 이어받았고, 2026년 들어 C에서 Rust로 재작성됐습니다. GraphRAG가 요구하는 그래프 갱신·순회 빈도가 늘어날수록, 밑단 엔진의 순회 방식이 병목이 될 수밖에 없다는 걸 보여주는 사례입니다.

조직을 그래프로 설계하기

같은 시기, 완전히 다른 문제에서도 "그래프"가 등장했습니다. 멀티에이전트 시스템이 늘면서 에이전트 하나의 행동 루프를 최적화하는 것만으로는 부족하다는 게 드러났습니다. 여러 에이전트가 서로 위임하고 통신하는 구조 자체를 설계해야 하는 문제가 남습니다.

TrueFoundry 등이 정리한 이 갈래의 정의는 이렇습니다. 노드는 에이전트, 결정론적 함수, 라우터, 조인(join), 도구, 휴먼 체크포인트처럼 이질적인 요소들이고, 엣지는 그 사이의 통신과 위임입니다. 지식 그래프가 데이터 구조(엔티티, 관계)를 설계하는 것이라면, 이쪽은 시스템 구조(역할, 책임, 메시지 경로)를 설계하는 것입니다. explainx.ai는 이를 "루프의 그래프"라고 부릅니다. 각 에이전트가 자기 루프를 돌리고, 그 루프들이 의존 관계로 서로 엮인 조직 전체가 그래프라는 뜻입니다.

노드마다 신원이 필요한 이유

조직을 그래프로 놓고 보면 실제로 프로덕션에서 막히는 지점은 거버넌스입니다. 노드가 20개, 30개로 늘어나면 어떤 노드가 어떤 도구에 접근할 수 있는지, 비용이 어디서 새는지, 실패가 어느 엣지에서 발생했는지를 추적할 방법이 있어야 합니다. TrueFoundry가 제시하는 방식은 노드마다 고유한 신원을 부여하는 것입니다.

Authorization: Bearer <node-specific-virtual-account-token>
X-TFY-METADATA: {
  "graph_id": "release-review",
  "run_id": "run-8f31",
  "node_id": "security-reviewer"
}

이 메타데이터가 모델·도구 호출마다 함께 전파되면 노드 단위로 비용과 지연시간을 분리해 볼 수 있고, 팀·테넌트별 예산 규칙을 걸 수 있고, 민감한 작업 앞에 승인 체크포인트를 놓을 수 있습니다. 정리하면 프로덕션에 올리기 위한 요구사항은 이렇습니다.

모든 호출자(노드)의 신원을 해결할 수 있어야 한다
게이트웨이 호출마다 graph_id, run_id, node_id가 안정적으로 따라와야 한다
오케스트레이터가 실제 작업 그래프를 기록해야 한다
오케스트레이션 추적과 게이트웨이의 비용·지연시간 로그가 서로 상관관계를 지을 수 있어야 한다
그래프·노드 단위로 예산 규칙을 걸 수 있어야 한다
민감한 도구 작업 앞에는 명시적 승인 체크포인트가 있어야 한다
모델을 바꿀 때 가상 라우팅으로 그 변경을 노드 로직에서 격리해야 한다

이 목록이 낯설지 않다면, 마이크로서비스 관측가능성(observability)에서 이미 봤던 요구사항들이기 때문입니다. 다른 점은 호출하는 주체가 결정론적 서비스가 아니라 자율적으로 판단하는 LLM 에이전트라는 것뿐입니다.

두 그래프가 닮은 이유

지식 그래프 축과 조직 그래프 축은 서로 참고하지 않지만 같은 이유로 그래프라는 자료구조를 택했습니다. 트리나 파이프라인으로는 표현할 수 없는 다대다 관계, 순환, 동적 재배선이 둘 다에서 필요했기 때문입니다. 지식 그래프에서는 한 엔티티가 여러 문서, 여러 관계에 동시에 걸쳐 있고, 조직 그래프에서는 한 작업이 여러 에이전트를 오가며 재시도되고 팬아웃됩니다. 둘 다 순회 비용, 최신성 유지, 오류 전파라는 같은 종류의 문제를 각자의 언어로 다시 겪고 있습니다. 엔티티 해상도가 틀리면 지식 그래프의 다단계 순회가 통째로 틀어지듯, 노드 신원 추적이 빠지면 조직 그래프의 실패 지점을 찾을 수 없습니다.

지금은 이 두 축을 다루는 사람들이 서로 다른 콘퍼런스, 다른 블로그, 다른 도구 생태계에 있습니다. 하지만 에이전트가 GraphRAG로 지식 그래프를 조회하면서 동시에 자기 자신도 더 큰 조직 그래프 안의 노드로 움직이는 시스템은 이미 나오고 있습니다. 이 경우 두 그래프는 별개 레이어가 아니라 한 시스템 안에서 서로를 참조하는 두 층이 됩니다. "그래프 엔지니어링"이라는 이름을 어느 쪽이 가져가느냐보다, 두 축의 거버넌스 요구사항(신원, 예산, 추적)이 결국 하나의 스택으로 합쳐질 가능성이 더 큰 이야기라고 봅니다.

참고: Graph Engineering for Multi-Agent Systems, Towards Practical GraphRAG, FalkorDB Graph Database Guide, Graph Engineering: Wire Multi-Agent Orgs After Loops