그래프
LangGraph의 핵심은 에이전트 워크플로우를 그래프로 모델링하는 것입니다. 세 가지 주요 구성 요소를 사용하여 에이전트의 동작을 정의합니다:-
State: 애플리케이션의 현재 스냅샷을 나타내는 공유 데이터 구조입니다. 모든 데이터 타입이 가능하지만, 일반적으로 공유 상태 스키마를 사용하여 정의됩니다. -
Nodes: 에이전트의 로직을 인코딩하는 함수입니다. 현재 상태를 입력으로 받아서 계산 또는 부수 효과를 수행하고, 업데이트된 상태를 반환합니다. -
Edges: 현재 상태를 기반으로 다음에 실행할Node를 결정하는 함수입니다. 조건부 분기 또는 고정 전환이 될 수 있습니다.
Nodes와 Edges를 조합하여 시간이 지남에 따라 상태를 진화시키는 복잡한 반복 워크플로우를 생성할 수 있습니다. 진정한 힘은 LangGraph가 상태를 관리하는 방식에서 나옵니다. 강조하자면: Nodes와 Edges는 함수에 불과합니다 - LLM을 포함할 수도 있고 그냥 일반 코드일 수도 있습니다.
요약하면: 노드는 작업을 수행하고, 엣지는 다음에 무엇을 할지 알려줍니다.
LangGraph의 기본 그래프 알고리즘은 메시지 전달을 사용하여 범용 프로그램을 정의합니다. 노드가 작업을 완료하면 하나 이상의 엣지를 따라 다른 노드로 메시지를 보냅니다. 이러한 수신 노드들은 함수를 실행하고, 결과 메시지를 다음 노드 집합으로 전달하며, 이 과정이 계속됩니다. Google의 Pregel 시스템에서 영감을 받아, 프로그램은 개별 “슈퍼 스텝”으로 진행됩니다.
슈퍼 스텝은 그래프 노드에 대한 단일 반복으로 간주될 수 있습니다. 병렬로 실행되는 노드는 동일한 슈퍼 스텝의 일부이며, 순차적으로 실행되는 노드는 별도의 슈퍼 스텝에 속합니다. 그래프 실행 시작 시 모든 노드는 inactive 상태에서 시작됩니다. 노드는 들어오는 엣지(또는 “채널”) 중 하나에서 새 메시지(상태)를 받으면 active 상태가 됩니다. 활성 노드는 함수를 실행하고 업데이트로 응답합니다. 각 슈퍼 스텝이 끝날 때 들어오는 메시지가 없는 노드는 자신을 inactive로 표시하여 halt에 투표합니다. 모든 노드가 inactive이고 전송 중인 메시지가 없을 때 그래프 실행이 종료됩니다.
StateGraph
StateGraph 클래스는 사용할 주요 그래프 클래스입니다. 이는 사용자 정의 State 객체로 매개변수화됩니다.
그래프 컴파일
그래프를 빌드하려면 먼저 상태를 정의하고, 노드와 엣지를 추가한 다음 컴파일합니다. 그래프 컴파일이란 정확히 무엇이며 왜 필요할까요? 컴파일은 매우 간단한 단계입니다. 그래프 구조에 대한 몇 가지 기본 검사(고아 노드 없음 등)를 제공합니다. 또한 체크포인터 및 중단점과 같은 런타임 인수를 지정할 수 있는 곳이기도 합니다..compile 메서드를 호출하여 그래프를 컴파일합니다:
State
그래프를 정의할 때 가장 먼저 하는 일은 그래프의State를 정의하는 것입니다. State는 그래프의 스키마와 상태에 업데이트를 적용하는 방법을 지정하는 reducer 함수로 구성됩니다. State의 스키마는 그래프의 모든 Nodes와 Edges에 대한 입력 스키마가 되며, Zod 스키마 또는 Annotation.Root를 사용하여 빌드된 스키마일 수 있습니다. 모든 Nodes는 지정된 reducer 함수를 사용하여 적용되는 State에 대한 업데이트를 내보냅니다.
Schema
그래프의 스키마를 지정하는 주요 문서화된 방법은 Zod 스키마를 사용하는 것입니다. 그러나 그래프의 스키마를 정의하기 위해Annotation API를 사용하는 것도 지원합니다.
기본적으로 그래프는 동일한 입력 및 출력 스키마를 갖습니다. 이를 변경하려면 명시적인 입력 및 출력 스키마를 직접 지정할 수도 있습니다. 이는 키가 많고 일부는 명시적으로 입력용이고 다른 일부는 출력용일 때 유용합니다.
다중 스키마
일반적으로 모든 그래프 노드는 단일 스키마로 통신합니다. 이는 동일한 상태 채널을 읽고 쓴다는 의미입니다. 하지만 이에 대한 더 많은 제어가 필요한 경우가 있습니다:- 내부 노드는 그래프의 입력/출력에 필요하지 않은 정보를 전달할 수 있습니다.
- 그래프에 대해 다른 입력/출력 스키마를 사용하고 싶을 수 있습니다. 예를 들어 출력은 단일 관련 출력 키만 포함할 수 있습니다.
PrivateState를 정의하기만 하면 됩니다.
또한 그래프에 대한 명시적인 입력 및 출력 스키마를 정의하는 것도 가능합니다. 이러한 경우 그래프 작업과 관련된 모든 키를 포함하는 “내부” 스키마를 정의합니다. 그러나 그래프의 입력 및 출력을 제한하기 위해 “내부” 스키마의 하위 집합인 input 및 output 스키마도 정의합니다. 자세한 내용은 이 가이드를 참조하십시오.
예제를 살펴보겠습니다:
-
node1에 대한 입력 스키마로state를 전달합니다. 그러나OverallState의 채널인foo에 씁니다. 입력 스키마에 포함되지 않은 상태 채널에 어떻게 쓸 수 있을까요? 이는 노드가 그래프 상태의 모든 상태 채널에 쓸 수 있기 때문입니다. 그래프 상태는 초기화 시 정의된 상태 채널의 합집합이며, 여기에는OverallState와 필터InputState및OutputState가 포함됩니다. -
StateGraph({ state: OverallState, input: InputState, output: OutputState })로 그래프를 초기화합니다. 그렇다면node2에서PrivateState에 어떻게 쓸 수 있을까요?StateGraph초기화에 전달되지 않았는데 그래프가 이 스키마에 어떻게 액세스할까요? 상태 스키마 정의가 존재하는 한 노드는 추가 상태 채널을 선언할 수도 있기 때문에 이를 수행할 수 있습니다. 이 경우PrivateState스키마가 정의되어 있으므로 그래프에bar를 새 상태 채널로 추가하고 거기에 쓸 수 있습니다.
Reducers
Reducer는 노드의 업데이트가State에 적용되는 방식을 이해하는 데 핵심입니다. State의 각 키에는 자체적인 독립적인 reducer 함수가 있습니다. reducer 함수가 명시적으로 지정되지 않은 경우 해당 키에 대한 모든 업데이트가 이를 재정의한다고 가정합니다. 기본 유형의 reducer부터 시작하여 몇 가지 다른 유형의 reducer가 있습니다:
기본 Reducer
다음 두 예제는 기본 reducer를 사용하는 방법을 보여줍니다: 예제 A:{ foo: 1, bar: ["hi"] }. 그런 다음 첫 번째 Node가 { foo: 2 }를 반환한다고 가정해 봅시다. 이것은 상태에 대한 업데이트로 처리됩니다. Node가 전체 State 스키마를 반환할 필요가 없고 업데이트만 반환하면 됩니다. 이 업데이트를 적용한 후 State는 { foo: 2, bar: ["hi"] }가 됩니다. 두 번째 노드가 { bar: ["bye"] }를 반환하면 State는 { foo: 2, bar: ["bye"] }가 됩니다.
예제 B:
bar)에 대한 reducer 함수를 지정했습니다. 첫 번째 키는 변경되지 않았습니다. 그래프에 대한 입력이 { foo: 1, bar: ["hi"] }라고 가정해 봅시다. 그런 다음 첫 번째 Node가 { foo: 2 }를 반환한다고 가정해 봅시다. 이것은 상태에 대한 업데이트로 처리됩니다. Node가 전체 State 스키마를 반환할 필요가 없고 업데이트만 반환하면 됩니다. 이 업데이트를 적용한 후 State는 { foo: 2, bar: ["hi"] }가 됩니다. 두 번째 노드가 { bar: ["bye"] }를 반환하면 State는 { foo: 2, bar: ["hi", "bye"] }가 됩니다. 여기서 bar 키는 두 배열을 함께 추가하여 업데이트됩니다.
그래프 상태에서 메시지 작업하기
메시지를 사용하는 이유는?
대부분의 현대 LLM 제공자는 메시지 목록을 입력으로 받는 채팅 모델 인터페이스를 가지고 있습니다. 특히 LangChain의ChatModel은 Message 객체의 목록을 입력으로 받습니다. 이러한 메시지는 @[HumanMessage](사용자 입력) 또는 AIMessage(LLM 응답)와 같은 다양한 형태로 제공됩니다. 메시지 객체가 무엇인지에 대해 자세히 읽어보려면 이 개념 가이드를 참조하십시오.
그래프에서 메시지 사용하기
많은 경우 그래프 상태에 이전 대화 기록을 메시지 목록으로 저장하는 것이 유용합니다. 이를 위해Message 객체 목록을 저장하는 키(채널)를 그래프 상태에 추가하고 reducer 함수로 주석을 달 수 있습니다(아래 예제의 messages 키 참조). reducer 함수는 각 상태 업데이트(예: 노드가 업데이트를 보낼 때)에 따라 상태의 Message 객체 목록을 업데이트하는 방법을 그래프에 알려주는 데 필수적입니다. reducer를 지정하지 않으면 모든 상태 업데이트가 가장 최근에 제공된 값으로 메시지 목록을 덮어씁니다. 기존 목록에 메시지를 단순히 추가하려면 배열을 연결하는 함수를 reducer로 사용할 수 있습니다.
그러나 그래프 상태의 메시지를 수동으로 업데이트하고 싶을 수도 있습니다(예: 사람-루프). 단순 연결 함수를 사용하면 그래프에 보내는 수동 상태 업데이트가 기존 메시지를 업데이트하는 대신 기존 메시지 목록에 추가됩니다. 이를 방지하려면 메시지 ID를 추적하고 업데이트된 경우 기존 메시지를 덮어쓸 수 있는 reducer가 필요합니다. 이를 위해 미리 빌드된 messagesStateReducer 함수를 사용하거나 상태 스키마가 Zod로 정의된 경우 MessagesZodMeta를 사용할 수 있습니다. 완전히 새로운 메시지의 경우 기존 목록에 단순히 추가되지만 기존 메시지에 대한 업데이트도 올바르게 처리합니다.
직렬화
메시지 ID를 추적하는 것 외에도MessagesZodMeta는 messages 채널에서 상태 업데이트가 수신될 때마다 메시지를 LangChain Message 객체로 역직렬화하려고 시도합니다. 이를 통해 다음 형식으로 그래프 입력/상태 업데이트를 보낼 수 있습니다:
MessagesZodMeta를 사용할 때 상태 업데이트는 항상 LangChain Messages로 역직렬화되므로 state.messages[state.messages.length - 1].content와 같이 점 표기법을 사용하여 메시지 속성에 액세스해야 합니다. 다음은 MessagesZodMeta를 사용하는 그래프의 예입니다:
MessagesZodState는 @[BaseMessage] 객체의 목록이며 적절한 reducer를 사용하는 단일 messages 키로 정의됩니다. 일반적으로 메시지보다 더 많은 상태를 추적해야 하므로 사람들이 이 상태를 확장하고 다음과 같이 더 많은 필드를 추가하는 것을 볼 수 있습니다:
Nodes
LangGraph에서 노드는 일반적으로 다음 인수를 받는 함수(동기 또는 비동기)입니다:state: 그래프의 상태config:thread_id와 같은 구성 정보 및tags와 같은 추적 정보를 포함하는RunnableConfig객체
addNode 메서드를 사용하여 그래프에 노드를 추가할 수 있습니다.
START Node
START 노드는 사용자 입력을 그래프에 보내는 노드를 나타내는 특수 노드입니다. 이 노드를 참조하는 주요 목적은 어떤 노드를 먼저 호출해야 하는지 결정하는 것입니다.
END Node
END 노드는 터미널 노드를 나타내는 특수 노드입니다. 이 노드는 완료된 후 작업이 없는 엣지를 나타내고자 할 때 참조됩니다.
노드 캐싱
LangGraph는 노드에 대한 입력을 기반으로 태스크/노드 캐싱을 지원합니다. 캐싱을 사용하려면:- 그래프를 컴파일할 때(또는 진입점을 지정할 때) 캐시를 지정합니다
- 노드에 대한 캐시 정책을 지정합니다. 각 캐시 정책은 다음을 지원합니다:
- 노드에 대한 입력을 기반으로 캐시 키를 생성하는 데 사용되는
keyFunc입니다. ttl, 캐시의 수명(초)입니다. 지정하지 않으면 캐시가 만료되지 않습니다.
- 노드에 대한 입력을 기반으로 캐시 키를 생성하는 데 사용되는
Edges
엣지는 로직이 라우팅되는 방식과 그래프가 중지를 결정하는 방식을 정의합니다. 이는 에이전트가 작동하는 방식과 서로 다른 노드가 통신하는 방식의 큰 부분입니다. 몇 가지 주요 엣지 유형이 있습니다:- 일반 엣지: 한 노드에서 다음 노드로 직접 이동합니다.
- 조건부 엣지: 다음에 이동할 노드를 결정하기 위해 함수를 호출합니다.
- 진입점: 사용자 입력이 도착할 때 먼저 호출할 노드입니다.
- 조건부 진입점: 사용자 입력이 도착할 때 먼저 호출할 노드를 결정하기 위해 함수를 호출합니다.
일반 엣지
노드 A에서 노드 B로 항상 이동하려면addEdge 메서드를 직접 사용할 수 있습니다.
조건부 엣지
하나 이상의 엣지로 선택적으로 라우팅하거나(또는 선택적으로 종료하려면)addConditionalEdges 메서드를 사용할 수 있습니다. 이 메서드는 노드의 이름과 해당 노드가 실행된 후 호출할 “라우팅 함수”를 받습니다:
routingFunction은 그래프의 현재 state를 받아서 값을 반환합니다.
기본적으로 routingFunction의 반환 값은 다음에 상태를 보낼 노드(또는 노드 목록)의 이름으로 사용됩니다. 이러한 모든 노드는 다음 슈퍼 스텝의 일부로 병렬로 실행됩니다.
선택적으로 routingFunction의 출력을 다음 노드의 이름에 매핑하는 객체를 제공할 수 있습니다.
상태 업데이트와 라우팅을 단일 함수로 결합하려면 조건부 엣지 대신
Command를 사용하십시오.진입점
진입점은 그래프가 시작될 때 실행되는 첫 번째 노드입니다. 가상START 노드에서 실행할 첫 번째 노드로의 addEdge 메서드를 사용하여 그래프에 진입할 위치를 지정할 수 있습니다.
조건부 진입점
조건부 진입점을 사용하면 사용자 정의 로직에 따라 다른 노드에서 시작할 수 있습니다. 가상START 노드에서 addConditionalEdges를 사용하여 이를 수행할 수 있습니다.
routingFunction의 출력을 다음 노드의 이름에 매핑하는 객체를 제공할 수 있습니다.
Send
기본적으로 Nodes와 Edges는 미리 정의되어 있으며 동일한 공유 상태에서 작동합니다. 그러나 정확한 엣지를 미리 알 수 없거나 State의 다른 버전이 동시에 존재하기를 원하는 경우가 있을 수 있습니다. 이에 대한 일반적인 예는 맵-리듀스 디자인 패턴입니다. 이 디자인 패턴에서 첫 번째 노드는 객체 목록을 생성할 수 있으며 해당 객체 모두에 다른 노드를 적용하고 싶을 수 있습니다. 객체의 수는 미리 알 수 없을 수 있으며(엣지의 수를 알 수 없음을 의미함) 다운스트림 Node에 대한 입력 State가 달라야 합니다(각 생성된 객체에 대해 하나씩).
이 디자인 패턴을 지원하기 위해 LangGraph는 조건부 엣지에서 Send 객체를 반환하는 것을 지원합니다. Send는 두 가지 인수를 받습니다: 첫 번째는 노드의 이름이고 두 번째는 해당 노드에 전달할 상태입니다.
Command
제어 흐름(엣지)과 상태 업데이트(노드)를 결합하는 것이 유용할 수 있습니다. 예를 들어 동일한 노드에서 상태 업데이트와 다음에 이동할 노드 결정을 모두 수행하고 싶을 수 있습니다. LangGraph는 노드 함수에서 Command 객체를 반환하여 이를 수행하는 방법을 제공합니다:
Command를 사용하면 동적 제어 흐름 동작(조건부 엣지와 동일)도 달성할 수 있습니다:
Command를 사용할 때 노드를 추가할 때 라우팅할 수 있는 노드를 지정하기 위해 ends 매개변수를 추가해야 합니다:
노드 함수에서
Command를 반환할 때 노드가 라우팅하는 노드 이름 목록과 함께 반환 타입 주석을 추가해야 합니다(예: Command[Literal["my_other_node"]]). 이는 그래프 렌더링에 필요하며 my_node가 my_other_node로 이동할 수 있음을 LangGraph에 알립니다.Command를 사용하는 방법의 엔드-투-엔드 예제는 이 how-to 가이드를 확인하십시오.
Command 대신 조건부 엣지를 언제 사용해야 할까요?
- 그래프 상태를 업데이트하고 다른 노드로 라우팅해야 할 때
Command를 사용하십시오. 예를 들어 다른 에이전트로 라우팅하고 해당 에이전트에게 일부 정보를 전달하는 것이 중요한 다중 에이전트 핸드오프를 구현할 때입니다. - 상태를 업데이트하지 않고 노드 간에 조건부로 라우팅하려면 조건부 엣지를 사용하십시오.
부모 그래프의 노드로 이동하기
서브그래프를 사용하는 경우 서브그래프 내의 노드에서 다른 서브그래프(즉, 부모 그래프의 다른 노드)로 이동하고 싶을 수 있습니다. 이를 위해Command에서 graph: Command.PARENT를 지정할 수 있습니다:
서브그래프를 사용하는 경우 서브그래프 내의 노드에서 다른 서브그래프(즉, 부모 그래프의 다른 노드)로 이동하고 싶을 수 있습니다. 이를 위해
Command에서 graph: Command.PARENT를 지정할 수 있습니다:
이는 다중 에이전트 핸드오프를 구현할 때 특히 유용합니다.
자세한 내용은 이 가이드를 확인하십시오.
도구 내부에서 사용하기
일반적인 사용 사례는 도구 내부에서 그래프 상태를 업데이트하는 것입니다. 예를 들어 고객 지원 애플리케이션에서 대화 초기에 계정 번호나 ID를 기반으로 고객 정보를 조회하고 싶을 수 있습니다. 자세한 내용은 이 가이드를 참조하십시오.사람-루프
Command는 사람-루프 워크플로우의 중요한 부분입니다: interrupt()를 사용하여 사용자 입력을 수집할 때 Command는 new Command({ resume: "User input" })를 통해 입력을 제공하고 실행을 재개하는 데 사용됩니다. 자세한 내용은 사람-루프 개념 가이드를 확인하십시오.
그래프 마이그레이션
LangGraph는 체크포인터를 사용하여 상태를 추적하는 경우에도 그래프 정의(노드, 엣지 및 상태)의 마이그레이션을 쉽게 처리할 수 있습니다.- 그래프 끝에 있는 스레드(즉, 중단되지 않은)의 경우 그래프의 전체 토폴로지(즉, 모든 노드 및 엣지, 제거, 추가, 이름 변경 등)를 변경할 수 있습니다
- 현재 중단된 스레드의 경우 노드 이름 변경/제거를 제외한 모든 토폴로지 변경을 지원합니다(해당 스레드가 더 이상 존재하지 않는 노드에 진입하려고 할 수 있으므로) — 이것이 차단 요인인 경우 연락하시면 솔루션의 우선순위를 정할 수 있습니다.
- 상태 수정의 경우 키 추가 및 제거에 대한 완전한 하위 및 상위 호환성이 있습니다
- 이름이 변경된 상태 키는 기존 스레드에서 저장된 상태를 잃습니다
- 호환되지 않는 방식으로 타입이 변경된 상태 키는 현재 변경 전 상태가 있는 스레드에서 문제를 일으킬 수 있습니다 — 이것이 차단 요인인 경우 연락하시면 솔루션의 우선순위를 정할 수 있습니다.
런타임 컨텍스트
그래프를 생성할 때 노드에 전달되는 런타임 컨텍스트에 대한contextSchema를 지정할 수 있습니다. 이는 그래프 상태의 일부가 아닌 정보를 노드에 전달하는 데 유용합니다. 예를 들어 모델 이름이나 데이터베이스 연결과 같은 종속성을 전달하고 싶을 수 있습니다.
context 속성을 사용하여 이 구성을 그래프에 전달할 수 있습니다.
재귀 제한
재귀 제한은 단일 실행 중에 그래프가 실행할 수 있는 슈퍼 스텝의 최대 수를 설정합니다. 제한에 도달하면 LangGraph는GraphRecursionError를 발생시킵니다. 기본적으로 이 값은 25단계로 설정됩니다. 재귀 제한은 런타임에 모든 그래프에서 설정할 수 있으며 config 객체를 통해 invoke/stream에 전달됩니다. 중요한 것은 recursionLimit이 독립적인 config 키이며 다른 모든 사용자 정의 구성처럼 configurable 키 내부에 전달되어서는 안 된다는 것입니다. 아래 예제를 참조하십시오:
시각화
그래프를 시각화할 수 있는 것은 특히 복잡해질수록 유용한 경우가 많습니다. LangGraph는 그래프를 시각화하는 여러 가지 내장 방법을 제공합니다. 자세한 정보는 이 how-to 가이드를 참조하십시오.Connect these docs programmatically to Claude, VSCode, and more via MCP for real-time answers.