LangGraph와 함께한 그래프 엔지니어링 3년
TMThttps://www.langchain.com/blog/3-years-of-graph-engineering-with-langgraph
'그래프 엔지니어링(graph engineering)'이라는 말이 이번 주말, 이 트윗을 계기로 떠올랐습니다.
프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링, 루프 엔지니어링에 이어 X의 AI 콘텐츠 공장에서 나온 최신 용어입니다. 이런 용어들을 유행어라고 부르고 싶어지고 실제로 맞는 말이기도 하지만, 이런 말이 생겨나고 퍼지는 데는 이유가 있습니다. 개발자들이 마주하는 실제 과제와 설계상의 결정을 담아내고 있기 때문입니다.
결국 목표는 LLM의 힘을 활용해 우리에게 유용한 일을 시키는 것입니다. 프롬프트를 쓰든 에이전트, 루프, 그래프를 쓰든 그것은 구현 세부 사항일 뿐입니다. 이렇게 많은 용어가 존재하는 이유는 LLM에게 일을 시키는 것이 어렵기 때문입니다. LLM은 견고하지도 결정론적이지도 않은 새로운 유형의 소프트웨어이고, 우리는 이를 제대로 작동시키려고 끊임없이 새로운 전략을 시도합니다. 그리고 이 새로운 전략들이 새로운 유행어를 낳습니다.
유행어 논란은 접어 두더라도, 에이전트 시스템을 그래프로 표현하는 것('그래프 엔지니어링')은 LLM의 힘을 활용하는 매우 합리적인 방법입니다. 구체적으로는, 시스템이 어떻게 동작해야 하는지에 대한 개발자의 사전 지식을 더 제한된 경로에 심어 넣을 수 있어 LLM의 판단에만 의존하지 않게 됩니다. 더 풀어서 말하면, 에이전트가 특정 경로를 따르길 원할 때 동작을 더 촘촘하게 통제할 수 있습니다.
이런 직관에서 출발해 3년 전, 이런 유형의 에이전트 시스템 구축을 돕는 프레임워크로 LangGraph를 만들었습니다. 오늘날 LangGraph는 월 6,500만 회 이상 다운로드되며, 스타트업과 대기업 모두가 사용하고 있습니다.
수많은 다른 에이전트 프레임워크 사이에서 LangGraph가 인기를 얻은 이유는, 결정론적 경로와 에이전트적 단계 사이에서 균형을 잘 잡았기 때문입니다.
에이전트 시스템을 그래프로 만들어 온 지난 몇 년간 배운 것들을 소개합니다.
에이전트를 그래프로 모델링하기
그래프는 에이전트가 따르는 워크플로를 구체적으로 정의하는 방법을 제공합니다.
LangGraph에서 노드는 일을 수행합니다. 노드는 결정론적 코드일 수도 있고, 단일 LLM 호출, 도구 호출, 또는 자체 내부 루프를 가진 완전한 에이전트일 수도 있습니다.
엣지는 다음에 무엇이 일어날지 정의합니다. 어떤 엣지는 결정론적이고, 어떤 엣지는 노드의 결과나 현재 상태, 외부 신호에 따라 달라지는 조건부입니다.
이를 상태 기계(state machine)로 생각해도 됩니다. 그래프는 워크플로, 그 안을 흐르는 상태, 단계 사이의 전이를 정의합니다.
에이전트를 그래프로 표현해야 할 때
실제 에이전트 워크플로에는 예측 가능한 구조가 있는 경우가 많습니다. 고객 지원 에이전트는 답변하거나 상위 담당자에게 넘기기 전에 문제를 분류하고, 코딩 에이전트는 변경을 제안하기 전에 저장소를 살펴보고, 컴플라이언스 워크플로는 외부로 향하는 작업을 실행하기 전에 승인을 받아야 합니다.
그래프를 쓰면 그 구조를 직접 코드에 담을 수 있습니다. 유효한 경로는 무엇인지, 모델이 선택권을 갖는 지점은 어디인지, 그리고 모델이 매번 옳은 판단을 내리길 바라는 대신 시스템이 결정론적 동작을 강제해야 하는 지점은 어디인지를 말입니다.
시스템을 그래프로 표현한다는 것은 이 시스템이 어떻게 동작해야 하는지에 대한 세상 지식을 코드에 새기는 일입니다. 프롬프트가 여러분의 에이전트를 범용 ChatGPT와 구분 짓는 도메인 지식을 담고 있듯, 이런 "인지 아키텍처"도 같은 역할을 할 수 있습니다.
검색에 세 개의 서브에이전트를 쓰는 지식 베이스 에이전트를 예로 들어 보겠습니다. 코드·이슈·풀 리퀘스트를 담당하는 GitHub 에이전트, 내부 문서와 위키를 담당하는 Notion 에이전트, 관련 스레드를 담당하는 Slack 에이전트입니다. 워크플로는 분류, 검색, 종합이라는 세 개의 고정된 단계로 이루어집니다.
그 결과 코드와 모델의 추론이 함께 일하게 됩니다. 모델은 가치를 더하는 곳에서만 추론하고 나머지는 코드가 처리하므로, 에이전트는 더 저렴하고 더 빠르고 더 예측 가능해집니다.
그래프를 쓰지 말아야 할 때
어떤 작업은 본질적으로 더 에이전트적이어서, 결정론적 경로에 억지로 끼워 넣는 것은 잘못된 선택입니다. 이런 경우에는 시스템을 그래프로 표현하기보다 그냥 에이전트 하네스(Deep Agents 같은)를 쓰는 편이 낫습니다.
범용 딥 리서치가 좋은 예입니다. 리서치 에이전트는 계획, 위임, 검색, 읽기, 종합을 미리 못 박아 두기 어려운 방식으로 수행해야 합니다. 우리도 초기 딥 리서치는 미리 정의한 LangGraph 워크플로 위에 만들었다가, 이후 더 에이전트적인 핵심 루프로 옮겼습니다. 널리 쓰이는 딥 리서치 구현체인 GPT Researcher도 같은 길을 택해 그래프 형태의 멀티 에이전트 파이프라인을 Deep Agents로 교체했습니다. 계획, 위임, 컨텍스트 관리가 그래프에 하드코딩되는 대신 하네스 안에서 자연스럽게 이루어지도록 한 것입니다.
LangGraph를 만들며 배운 것
지난 3년간 그래프 기반 에이전트를 만들어 왔습니다. 그동안 배운 것은 다음과 같습니다.
첫째, 에이전트 그래프는 대개 DAG가 아닙니다.
프로덕션 에이전트에는 순환이 필요합니다. 실패한 도구 호출을 재시도하고, 빠진 정보를 사용자에게 묻고, 검증 후 답변을 고치고, 충분한 컨텍스트가 쌓일 때까지 도구를 반복 호출하고, 사람의 입력을 기다렸다가 재개하는 일이 모두 순환입니다. 루프는 에이전트 시스템의 핵심 요소이므로, 에이전트 그래프는 DAG가 아닐 가능성이 높습니다.
둘째, 루프는 단순한 그래프입니다.
루프 엔지니어링은 그래프의 대안이라기보다 그래프의 단순한 형태입니다. David Khourshid의 표현을 빌리면, 루프는 그저 방향이 있는 순환 그래프일 뿐입니다. 실제로 단순한 에이전트 루프에 기반한 LangChain 프레임워크도 LangGraph 위에 만들어져 있습니다.
셋째, 동적 전이가 중요합니다.
모든 엣지를 항상 미리 정의하고 싶은 것은 아닙니다. 때로는 노드가 실행 시점에 작업을 얼마나 만들지 결정합니다. 맵리듀스(map-reduce)가 고전적인 사례입니다. 입력을 조각으로 나누고, 각 조각을 워커에 보내고, 결과를 합칩니다. 워커 수는 입력에 따라 달라지므로 미리 알 수 없습니다.
LangGraph는 이를 Send로 처리합니다. 노드가 모든 전이를 정적으로 정의하지 않고도 하나 이상의 하류 노드로 작업을 동적으로 보낼 수 있습니다.
이것이 중요한 이유는, 쓸모 있는 에이전트 시스템은 이미 아는 구조와 실행 시점의 가변성을 섞어 쓰기 때문입니다. 리서치가 여러 갈래로 퍼졌다가 종합되어야 한다는 것은 알아도, 소스가 몇 개일지는 모를 수 있습니다. 슈퍼바이저가 워커에게 위임해야 한다는 것은 알아도, 작업이 시작되기 전까지는 어떤 워커를 쓸지 모를 수 있습니다. 그래프에도 실행 시점의 유연성은 여전히 필요합니다.
정말로 새로운 것은 무엇인가
에이전트 시스템을 그래프로 표현하는 것은 새롭지 않습니다. 우리는 3년째 해 오고 있으니까요! 그렇다면 이번 '그래프 엔지니어링' 물결에서 달라진 것이 있을까요?
후하게 해석하자면, 달라진 것은 노드 안에 넣을 수 있는 것입니다. 초기에는 노드가 결정론적 코드나 단일 LLM 호출이었습니다. 이제는 에이전트 자체가 실제 업무를 맡길 만큼 신뢰할 수 있어져서, 노드 하나가 완전한 에이전트 실행일 수 있습니다. 단순한 LLM 호출이 아니라 에이전트를 오케스트레이션하는 것입니다.
코딩 에이전트가 좋은 예입니다. 오늘날 프로덕션에서 가장 효과적이고 파급력 있는 에이전트에 속하며, 이를 더 큰 그래프 안의 노드로 끼워 넣는 것은 이제 막 실용화된 패턴입니다.
문서 에이전트 하나를 생각해 봅시다. 이 에이전트는 아래와 같은 Slack 요청을,
리뷰 준비가 끝난 풀 리퀘스트로 바꿔 놓습니다.
이 그래프의 각 노드는 '결정론적'과 '에이전트적' 사이 스펙트럼에서 서로 다른 지점에 자리합니다.
- 고정 단계: Slack과 Linear 작업은 정해진 코드와 API 호출로 동작합니다.
- 모델 단계: 분류기와 종합 단계는 도구 없이 단일 LLM 호출을 사용합니다.
- 에이전트 단계: 레퍼런스 문서 에이전트와 개념 문서 에이전트는 각자 담당하는 코드베이스에서 더 개방적인 작업을 수행합니다.
이렇게 결정론과 에이전트적 자율성이 섞여 있기에 이 문서 에이전트는 예측 가능하면서도 강력하고 효율적입니다.
더 큰 그림
그래프 엔지니어링은 새로운 아이디어가 아닙니다. 신뢰할 수 있는 에이전트를 만드는, 이미 자리 잡은 접근법에 붙은 최신 이름일 뿐입니다.
루프 엔지니어링과 하네스 엔지니어링의 바탕에 있는 것과 같은 아이디어입니다. 즉, 각 단계마다 모델의 추론을 알맞은 자리에, 알맞은 컨텍스트와 함께 배치하는 것입니다.
그래프 엔지니어링을 시도해 보고 싶다면 LangGraph를 써 보세요.
