🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

LangGraph는 LangChain에서 얻은 피드백을 바탕으로, LLM 에이전트를 프로덕션에서 안정적으로 실행하기 위해 낮은 추상화와 높은 제어성·내구성을 중심에 둔 저수준 에이전트 런타임으로 설계되었다.

📌 핵심 요약

• 글은 LangGraph가 기존 LangChain의 체인과 에이전트를 다시 설계하는 과정에서 출발했으며, 초기 사용은 쉬웠지만 커스터마이즈와 확장이 어렵다는 피드백을 해결하려 했다고 설명한다.
• 저자들은 LLM 기반 에이전트가 전통적 소프트웨어와 다른 핵심 이유로 긴 지연시간, 장기 실행 실패의 재시도 비용, 비결정적 입출력을 들고, 이를 프로덕션 요구사항으로 전환한다.
• 필요 기능은 병렬화, 스트리밍, 태스크 큐, 체크포인팅, 휴먼 인 더 루프, 트레이싱으로 정리되며, 각각 실제 지연시간 절감, 체감 지연시간 완화, 실패 복구, 사용자 협업, 관찰 가능성 확보와 연결된다.
• 기존 DAG 프레임워크는 순환적 계산을 필요로 하는 LLM 에이전트에 맞지 않고, 기존 내구 실행 엔진은 스트리밍·단계 간 지연·긴 실행 이력에 따른 성능 문제 때문에 충분하지 않다고 판단한다.
• LangGraph의 설계 철학은 미래의 AI 사용 방식에 대해 최소한의 가정만 두고, 개발자가 일반 코드를 쓰는 느낌을 유지하도록 하는 것이며, 런타임과 SDK를 분리하고 필요한 기능을 빌딩 블록처럼 선택하도록 만드는 방향으로 구현된다.

🧩 주요 포인트

1. 글은 LangGraph가 기존 LangChain의 체인과 에이전트를 다시 설계하는 과정에서 출발했으며, 초기 사용은 쉬웠지만 커스터마이즈와 확장이 어렵다는 피드백을 해결하려 했다고 설명한다.
2. 저자들은 LLM 기반 에이전트가 전통적 소프트웨어와 다른 핵심 이유로 긴 지연시간, 장기 실행 실패의 재시도 비용, 비결정적 입출력을 들고, 이를 프로덕션 요구사항으로 전환한다.
3. 필요 기능은 병렬화, 스트리밍, 태스크 큐, 체크포인팅, 휴먼 인 더 루프, 트레이싱으로 정리되며, 각각 실제 지연시간 절감, 체감 지연시간 완화, 실패 복구, 사용자 협업, 관찰 가능성 확보와 연결된다.
4. 기존 DAG 프레임워크는 순환적 계산을 필요로 하는 LLM 에이전트에 맞지 않고, 기존 내구 실행 엔진은 스트리밍·단계 간 지연·긴 실행 이력에 따른 성능 문제 때문에 충분하지 않다고 판단한다.
5. LangGraph의 설계 철학은 미래의 AI 사용 방식에 대해 최소한의 가정만 두고, 개발자가 일반 코드를 쓰는 느낌을 유지하도록 하는 것이며, 런타임과 SDK를 분리하고 필요한 기능을 빌딩 블록처럼 선택하도록 만드는 방향으로 구현된다.

🧠 상세 정리

1. LangGraph를 다시 만들게 된 배경

글은 LangGraph가 약 2년 전 LangChain의 인기 있었던 체인과 에이전트를 사실상 재부팅하는 시도에서 시작됐다고 설명한다. 원래 LangChain 오픈소스 라이브러리는 시작하기 쉽다는 장점이 있었지만, GitHub, Discord, Slack, Twitter 등 여러 채널에서 커스터마이즈와 확장성이 어렵다는 피드백을 받았다. 그래서 팀은 기존 구조를 조금씩 고치는 대신 새로 시작하는 편이 더 많은 설계 자유도를 준다고 판단했다. 이때 LangGraph의 최우선 목표는 학습 진입장벽을 낮추는 것이 아니라, 실제 프로덕션에서 에이전트를 실행할 수 있게 만드는 것이었다.

2. 프로덕션 준비성을 우선한 문제 설정

저자들은 LangGraph를 설계하면서 먼저 두 가지 질문을 던졌다고 말한다. 하나는 정말 LangGraph를 새로 만들어야 하는지였고, 다른 하나는 기존 프레임워크로 에이전트를 프로덕션에 올릴 수 없는지였다. 이 질문에 답하기 위해 팀은 에이전트가 전통적 소프트웨어와 무엇이 같고 무엇이 다른지를 정의하려 했다. Uber, LinkedIn, Klarna, Elastic 같은 팀들과의 협업 및 직접적인 에이전트 구축 경험을 바탕으로, LLM 에이전트의 차이를 지연시간, 실패 복구 비용, 비결정성이라는 세 축으로 압축했다.

3. 지연시간: 밀리초에서 분·시간 단위로 바뀐 실행 모델

LLM 기반 에이전트의 첫 번째 핵심 문제는 지연시간이다. 전통적인 백엔드 엔드포인트는 밀리초 단위로 지연을 측정했지만, 에이전트 실행은 초, 분, 앞으로는 시간 단위까지 고려해야 한다고 글은 설명한다. 이는 LLM 호출 자체가 느리고, 테스트 타임 컴퓨트가 늘어나면서 더 느려질 수 있으며, 원하는 결과를 얻기 위해 여러 번의 LLM 호출과 반복 루프가 필요하기 때문이다. 또한 데이터베이스 행을 컨텍스트에 넣거나, 출력의 정확성을 확인하는 가드레일과 검증기를 붙이는 등 비LLM 단계도 전후에 추가되기 때문에 전체 실행 시간이 더 길어진다.

4. 병렬화와 스트리밍으로 지연을 다루는 방식

글은 긴 실행시간을 줄이거나 완화하기 위한 기능으로 병렬화와 스트리밍을 제시한다. 병렬화는 다음 단계가 이전 단계의 출력에 의존하지 않을 때 여러 단계를 동시에 실행해 실제 지연시간을 줄이는 접근이다. 다만 프로덕션에서 이를 안정적으로 사용하려면 병렬 단계 사이의 데이터 레이스를 피할 수 있어야 한다. 반면 스트리밍은 더 이상 품질 저하 없이 실제 지연을 줄이기 어려울 때 체감 지연시간을 낮추는 방식으로, 진행률 표시, 에이전트가 수행한 주요 행동 표시, 토큰 단위의 LLM 메시지 실시간 전달까지 포함할 수 있다.

5. 장기 실행 실패와 재시도 비용

LLM 에이전트가 느리다는 특성은 신뢰성 문제로도 이어진다. 모든 소프트웨어는 언젠가 실패할 수 있고, 실행 시간이 길수록 중간에 문제가 생길 기회도 많아진다. 전통적인 소프트웨어에서는 실패하면 처음부터 재시도하는 방식이 흔하지만, 10분짜리 에이전트가 9분 지점에서 실패했다면 처음으로 돌아가는 것은 시간과 비용 면에서 비효율적이다. 그래서 LangGraph 설계에서는 요청과 실제 실행을 분리하고 공정하고 안정적인 재시도를 가능하게 하는 태스크 큐, 그리고 중간 계산 상태를 저장해 실패 시 복구 비용을 줄이는 체크포인팅이 중요한 요구사항으로 추가된다.

6. 비결정성과 인간 개입, 관찰 가능성

LLM의 비결정성은 전통적인 소프트웨어와 다른 또 하나의 큰 차이다. 일반 코드에서는 입력과 기대 출력의 범위를 비교적 명확히 정의할 수 있지만, 생성형 AI에서는 사용자의 입력도 열려 있고 모델의 출력도 매번 달라질 수 있다. 같은 프롬프트가 다른 날 다른 결과를 만들 수 있고, 사용자는 같은 의도를 여러 방식으로 표현할 수 있기 때문에 개발 중 테스트만으로 모든 사례를 예측하기 어렵다. 이 때문에 글은 임의 지점에서 에이전트를 중단·재개하고, 행동 승인·거절·수정·질문·이전 단계로 되돌리기 같은 패턴을 가능하게 하는 휴먼 인 더 루프와, 입력·경로·출력을 들여다보는 트레이싱을 필수 기능으로 본다.

7. 여섯 가지 기능 요구사항과 낮은 지연이라는 상위 조건

저자들은 프로덕션 에이전트에 필요한 기능을 여섯 가지로 정리한다. 병렬화는 실제 지연시간을 줄이고, 스트리밍은 사용자가 느끼는 지연을 줄이며, 태스크 큐는 재시도 필요성을 줄이고, 체크포인팅은 재시도 비용을 낮춘다. 휴먼 인 더 루프는 사용자와 협업할 수 있게 하고, 트레이싱은 사용자가 에이전트를 어떻게 사용하는지 학습하게 해준다. 다만 글은 모든 에이전트가 이런 기능을 다 필요로 하는 것은 아니며, 도구 없이 단일 프롬프트로 끝나는 매우 짧은 에이전트라면 LangGraph 같은 프레임워크가 필요 없을 수도 있다고 선을 긋는다.

8. 기존 프레임워크가 충분하지 않았던 이유

LangGraph를 새로 만들지 기존 오픈소스 프레임워크를 쓸지 판단하는 과정에서, 저자들은 기존 선택지를 크게 DAG 프레임워크와 내구 실행 엔진으로 나눠 검토한다. DAG 프레임워크는 Apache Airflow류의 접근을 대표하지만, 이름 그대로 비순환 그래프를 전제로 하기 때문에 루프가 중요한 LLM 에이전트와 맞지 않는다고 본다. 내구 실행 엔진은 더 가까운 선택지였지만, LLM 에이전트 이전에 설계됐기 때문에 스트리밍 같은 요구가 부족했고, 단계 사이 지연이 챗봇 개발자에게 체감될 수 있으며, 실행 이력이 길수록 성능이 나빠지는 설계적 부담도 있었다. 따라서 저자들은 LLM이 기존 프로덕션 인프라에 새로운 아이디어를 요구할 만큼 충분히 다르다고 결론 내린다.

9. LangGraph의 설계 철학과 런타임 구조

LangGraph의 설계 원칙은 두 가지로 제시된다. 첫째, AI의 미래가 어떻게 될지 모르므로 프레임워크가 미래에 대해 가능한 한 적은 가정을 해야 한다는 것이다. 둘째, 개발자가 프레임워크 없는 일반 코드를 쓰는 느낌에 최대한 가까워야 하며, 개발자 코드에 부과하는 요구사항은 매우 가치 있는 기능을 가능하게 할 때만 정당화된다는 것이다. 이 원칙에 따라 LangGraph는 개발자 SDK와 런타임을 분리했고, StateGraph와 명령형·함수형 API 같은 공개 인터페이스를 런타임과 독립적으로 발전시킬 수 있게 했다. 런타임인 PregelLoop는 앞서 정리한 기능을 구현하고 각 에이전트 호출의 계산 그래프를 계획·실행하며, 기능들은 강제된 고수준 추상화가 아니라 필요할 때 선택하는 저수준 빌딩 블록으로 제공된다.

🧾 핵심 주장 / 시사점

• 이 글의 핵심은 에이전트 프레임워크의 경쟁력이 더 높은 추상화가 아니라, 긴 실행·실패·비결정성을 개발자가 제어할 수 있게 하는 낮은 수준의 실행 기반에서 나온다는 점이다.
• LangGraph의 설계는 LLM 애플리케이션을 단순한 프롬프트 호출이 아니라, 상태·루프·재시도·관찰·사용자 개입이 필요한 장기 실행 소프트웨어로 보는 관점에 기반한다.
• 저자들이 모든 에이전트에 LangGraph가 필요하다고 주장하지 않는 점도 중요하다. 짧고 단순한 에이전트에는 프레임워크가 과할 수 있지만, 프로덕션 규모와 복잡도가 커질수록 제어성·내구성·관찰 가능성이 핵심 요구가 된다는 메시지가 분명하다.

✅ 액션 아이템

• LangGraph 설계의 저수준 제어성 원칙에 맞춰 LLM 에이전트 파이프라인에서 런타임 제약과 운영 가정을 재정의한다.
• 긴 지연, 장기 실행 실패 재시도 비용, 비결정적 출력 특성을 반영해 병렬화·스트리밍·태스크 큐·체크포인팅·휴먼 인 더 루프의 우선순위를 정한다.
• LangChain의 기존 체인/에이전트 한계와 런타임·SDK 분리 방향을 비교해 순환 계산 시나리오 대응 대체 구조를 점검한다.

❓ 열린 질문

• 기존 DAG 프레임워크가 순환 계산에서 실제로 병목을 내는 조건은 무엇이며 어떤 지표로 사전에 구분할 것인가?
• 긴 실행 흐름에서 체크포인팅 단위를 어떻게 설정하면 재시도 비용은 줄이고 상태 일관성은 보장할 수 있는가?
• 런타임과 SDK를 분리한 설계에서 개발자가 일반 코드를 쓰는 감각을 유지하려면 어떤 기능 조합을 기본값으로 허용해야 하는가?