랭그래프

에이전트 워크플로우를 그래프(노드와 엣지)로 정의하는 프레임워크. 복잡한 조건 분기와 루프가 있는 에이전트를 만들 때 쓴다.

왜 그래프로 그리나

AI 에이전트를 코드로 짜다 보면 흐름이 금방 지저분해진다. 검색을 해봤는데 결과가 부실하면 조건을 바꿔 다시 검색하고, 답이 충분하면 정리로 넘어가고, 중간에 사람 확인이 필요하면 멈췄다가 이어가야 한다. 이런 갈래길과 되돌아가는 흐름을 if문과 while 반복문으로 얽어 놓으면 나중에 아무도 못 알아본다.

LangGraph는 이 흐름을 그래프로 그리자는 발상이다. 에이전트가 하는 각 단계를 노드로, 어느 단계 다음에 어디로 갈지를 엣지로 표현한다. 노드는 그냥 파이썬 함수 하나다. LLM을 부르거나, 도구를 실행하거나, 결과를 검증하고 나서 바뀐 내용을 돌려준다. 그러면 전체 에이전트가 상태 기계(state machine)처럼 돌아가면서, 흐름을 눈으로 따라갈 수 있는 그림이 된다.

실제로 어떻게 짜나

가장 먼저 하는 일은 에이전트가 들고 다닐 상태를 정의하는 것이다. 검색어, 지금까지 모은 문서, 시도 횟수 같은 걸 TypedDict 한 덩어리로 묶어 두면, 모든 노드가 이 상태를 읽고 자기 몫을 채워 넣는다. 그다음 갈림길이 필요한 곳에 add_conditional_edges로 라우터 함수를 붙인다. 라우터는 현재 상태를 슬쩍 보고 다음에 갈 노드 이름만 문자열로 돌려주는 역할이다. 여기서 LLM을 부르거나 상태를 건드리면 안 되고, 실제 계산은 전부 노드 안에서 해야 흐름이 꼬이지 않는다.

이 구조 덕에 재시도도 자연스럽다. 노드 안에서 에러를 잡아 실패 횟수를 하나 올리고, 라우터가 그 횟수를 보고 다시 시도할지 대체 경로로 빠질지 정하면 된다. 사람이 중간에 끼어들어야 하는 승인 절차도 interrupt로 그래프를 그 자리에서 멈춰 세우고, 사람이 확인 신호를 주면 멈췄던 지점부터 이어서 돌린다.

체크포인트와 랭체인과의 관계

LangGraph가 특히 힘을 쓰는 지점은 상태를 계속 저장한다는 데 있다. 노드 하나가 끝날 때마다 체크포인터가 그 순간의 상태를 통째로 남긴다. 그래서 오래 걸리는 작업이 중간에 끊기거나 사람 승인을 며칠 기다려도, 처음부터가 아니라 마지막 저장 지점에서 되살릴 수 있다. 개발할 때는 메모리에, 실제 서비스에서는 데이터베이스에 저장하도록 바꾸면 된다.

이름이 비슷해서 헷갈리기 쉬운데, LangGraph는 LangChain을 대체하는 게 아니다. LangChain이 모델·도구를 손쉽게 붙이는 상위 도구라면, LangGraph는 그 아래에서 흐름을 끈질기게 굴리는 실행 엔진에 가깝다. 실제로 요즘 LangChain 에이전트도 내부적으로 LangGraph 위에서 돈다. 간단한 도구 에이전트는 LangChain으로 빠르게 시작하고, 조건 분기나 루프, 여러 에이전트 간 넘김이 얽히면 LangGraph로 흐름을 직접 설계하는 쪽이 편하다. 대신 노드와 엣지를 일일이 짜야 해서, 단순한 작업에는 오히려 손이 더 간다는 점은 감안해야 한다.