솔직히 말하면 멀티에이전트 시스템이라는 말을 처음 들었을 때 나는 좀 회의적이었다. 에이전트 하나도 제대로 만들기 어려운데 여러 개를 동시에 돌린다고? 그게 정말 프로덕션 환경에서 돌아갈까? 그런데 LangGraph 1.0이 2025년 10월에 정식 릴리스되면서 이 생각이 완전히 바뀌었다. Uber, LinkedIn, Klarna 같은 글로벌 기업들이 이미 프로덕션에서 LangGraph를 쓰고 있다는 사실을 알게 되면서 나도 본격적으로 파고들기 시작했다. 특히 Supervisor 패턴으로 GPT-5를 파운데이션 모델로 활용한 멀티에이전트 구조를 직접 설계하고 운영해보면서 느낀 점들이 꽤 많다. 오늘은 그 경험을 바탕으로 LangGraph 1.0의 최신 기능과 Supervisor 아키텍처를 실전 관점에서 깊이 있게 다뤄보려 한다. 단순히 공식 문서를 정리하는 수준이 아니라, 직접 부딪히며 알게 된 것들을 솔직하게 공유하려고 한다.
LangGraph 1.0이 가져온 핵심 변화
LangGraph 1.0은 단순한 버전 업데이트가 아니다. 에이전트 프레임워크 역사상 첫 번째 안정화 메이저 릴리스라는 타이틀을 가지고 있다. 기존의 코어 프리미티브인 State, Node, Edge는 그대로 유지하면서 프로덕션에 필수적인 네 가지 핵심 런타임 기능을 공식 안정화했다.
첫 번째는 Durable Execution이다. 에이전트가 10단계 워크플로우 중 3단계를 실행하다가 서버가 재시작되면 어떻게 될까? LangGraph 1.0에서는 정확히 멈춘 지점부터 다시 시작된다. 모든 노드 실행 시점에 자동으로 체크포인팅이 되기 때문이다. 내가 실제로 장시간 실행되는 리서치 에이전트를 만들 때 이 기능 덕분에 중간에 프로세스가 죽어도 처음부터 다시 돌릴 필요가 없었다. 이건 데모 수준이 아닌 실제 운영 환경에서 정말 중요한 차이를 만든다.
두 번째는 스트리밍이다. LLM 토큰, 툴 콜, 상태 업데이트, 노드 전환까지 모든 것을 실시간으로 스트리밍할 수 있다. 에이전트가 30초 동안 아무 반응이 없으면 사용자는 고장이라고 느끼지만, 중간 과정이 실시간으로 보이면 완전히 다른 경험이 된다. 세 번째는 Human-in-the-Loop으로 실행을 일시정지하고 상태를 저장한 뒤 스레드 블로킹 없이 사람의 입력을 기다렸다가 정확히 멈춘 지점에서 재개되는 구조다. 사람이 몇 초 뒤에 응답하든 몇 시간 뒤에 응답하든 상관없다. 네 번째는 단기 메모리와 장기 메모리를 모두 지원하는 내장 메모리 시스템이다. 세션을 넘나드는 대화 맥락 유지가 프레임워크 수준에서 가능해졌다.
또 하나 중요한 변화가 있다. 기존 langgraph.prebuilt 모듈이 deprecated 되고 향상된 기능이 langchain.agents로 이동했다. create_react_agent 대신 create_agent를 사용하는 방향이고, 미들웨어라는 새로운 개념이 도입되어 에이전트 커스터마이징의 유연성이 크게 높아졌다. Python 3.10 이상이 필수가 된 점도 참고해야 한다.
Supervisor 패턴이란 무엇이고, 왜 핵심인가
멀티에이전트 시스템을 설계할 때 가장 먼저 부딪히는 질문은 에이전트들 간의 통신을 어떻게 관리할 것인가이다. 모든 에이전트가 서로 직접 소통하면 에이전트 수가 늘어날수록 통신 경로가 기하급수적으로 복잡해진다. Supervisor 패턴은 이 문제를 중앙 집중식 관리로 해결한다.
Supervisor 패턴은 중앙의 감독 에이전트가 전체 워크플로우를 관장하는 계층적 구조다. 사용자의 요청은 항상 Supervisor에게 먼저 도달하고, Supervisor가 적절한 전문 에이전트에게 작업을 위임한다. 완료된 결과는 다시 Supervisor에게 보고되고, Supervisor가 최종 응답을 전달한다. 마치 팀 리더가 프로젝트를 받아서 각 전문가에게 업무를 배분하고 결과를 취합하는 것과 같다.
내가 직접 느낀 가장 큰 장점은 디버깅이었다. 에이전트가 잘못된 결과를 내놓았을 때 Supervisor의 라우팅 결정을 추적하면 문제의 원인을 빠르게 찾을 수 있었다. 에이전트 간 직접 통신 구조에서는 이런 추적이 훨씬 어렵다. 각 에이전트는 자기 전문 분야에만 집중하면 되고, 새로운 도메인이 필요하면 에이전트를 하나 추가하면 된다. 기존 에이전트를 건드릴 필요가 없다는 점이 확장성에서 정말 큰 차이를 만든다. 초기에 2개의 서브 에이전트로 시작했다가 나중에 5개로 늘렸을 때도 기존 코드 수정 없이 에이전트만 추가하면 됐다. 서비스 운영 중에 특정 에이전트에 문제가 생겨도 해당 에이전트만 수정하면 되니까 장애 대응도 훨씬 빨라진다.
GPT-5를 파운데이션 모델로 선택한 이유와 비용 전략
Supervisor 에이전트의 파운데이션 모델 선택은 전체 시스템 성능에 직결된다. 나는 GPT-5를 기본 모델로 사용하고 있다. GPT-5는 tool calling 성능이 현재 시점에서 가장 안정적인 모델 중 하나다. Supervisor 패턴에서 에이전트 간 핸드오프는 본질적으로 tool calling이기 때문에 이 안정성이 시스템 전체 신뢰도에 직결된다. 구조화된 출력을 빠르게 생성하는 능력이 뛰어나서 라우팅 판단이 정확하고 빠르다.
비용 측면에서 하나 공유할 전략이 있다. Supervisor에는 GPT-5를 사용하되 단순한 작업을 수행하는 서브 에이전트에는 GPT-5-mini를 사용하는 방식이다. 예를 들어 단순 계산이나 텍스트 포맷팅 같은 작업은 미니 모델로도 충분하다. Supervisor의 라우팅 판단은 정확해야 하므로 여기에는 풀 사이즈 모델을 쓰는 것이 맞다. 이렇게 역할별로 모델을 분리하면 전체 API 비용을 상당히 절감하면서도 품질은 유지할 수 있다.
LangGraph 1.0에서는 모델 초기화도 더 간편해졌다. create_react_agent에서 model=”openai:gpt-5″ 형태의 문자열 지정을 지원하면서 코드가 깔끔해지고 모델 교체 시 수정 범위가 최소화되었다. 사실 이 부분이 생각보다 중요한데, A/B 테스트로 GPT-5와 다른 모델의 성능을 비교할 때 모델명 문자열만 바꾸면 되니까 실험이 훨씬 편해졌다. 참고로 langchain-openai 패키지를 최신 버전으로 유지하는 것을 잊지 말아야 한다. 모델 호환성 문제가 가끔 발생하는데 대부분 패키지 버전 차이에서 오는 문제다.
실전 Supervisor 구현, 두 가지 접근법의 차이
LangGraph 1.0에서 Supervisor 멀티에이전트를 구성하는 방법은 크게 두 가지다. langgraph-supervisor 라이브러리를 사용하는 방법과 직접 tool calling 패턴으로 구현하는 방법이다.
라이브러리 방식은 create_supervisor 함수에 에이전트 목록과 모델을 전달하면 워크플로우가 자동 구성된다. compile 단계에서 checkpointer와 store를 전달하면 메모리도 바로 활성화된다. 빠른 프로토타이핑에 적합하다. 그러나 LangChain 공식 문서에서는 현재 직접 tool calling 패턴을 더 권장한다. context engineering에 대한 제어권이 더 크기 때문이다. 실제 프로덕션에서는 메시지 히스토리 관리나 에이전트 간 전달되는 컨텍스트를 세밀하게 다뤄야 하는 경우가 많다.
직접 구현 방식에서는 서브 에이전트를 Supervisor의 도구로 래핑한다. 캘린더 에이전트와 이메일 에이전트가 있다면, Supervisor는 schedule_event와 manage_email 도구를 가진 것과 같다. 사용자가 “미팅 잡아주고 리마인더도 보내줘”라고 하면 Supervisor가 두 도구를 순차 호출하고 결과를 종합한다. 이 방식의 핵심은 도구 설명의 품질이다. 설명이 모호하면 잘못된 에이전트에게 작업이 전달되고, 구체적이면 정확한 라우팅이 이루어진다. 나는 실전에서 이 도구 설명을 반복적으로 개선하는 과정이 시스템 전체 성능 향상에 가장 큰 영향을 미친다는 것을 체감했다. 처음에는 간단하게 “검색 에이전트”라고만 써놓았다가, “최신 뉴스와 웹 정보를 검색하여 사실에 기반한 답변을 제공하는 에이전트. 날짜, 통계, 시장 동향 등 시의성이 중요한 질문에 적합”으로 바꾸니까 라우팅 정확도가 눈에 띄게 향상됐다. 도구 설명은 사실상 Supervisor에게 주는 업무 매뉴얼인 셈이다.
Dynamic Tool Calling과 Functional API의 활용
2025년 8월에 도입된 Dynamic Tool Calling은 멀티에이전트 신뢰성을 한 단계 끌어올리는 기능이다. 기존에는 에이전트가 모든 단계에서 동일한 도구 세트를 사용했지만, 이제는 워크플로우 각 단계에서 사용 가능한 도구를 동적으로 제어할 수 있다. 인증이 필요한 시스템이라면 인증 도구를 먼저 호출해야만 민감한 작업 도구가 활성화되는 식이다. 불필요한 도구가 줄면 LLM이 잘못된 도구를 선택할 확률이 낮아진다. 내가 고객 지원 시스템에서 적용했을 때 Supervisor의 라우팅 오류가 체감될 정도로 줄었다.
Functional API도 주목할 만한 변화다. @entrypoint와 @task 데코레이터로 그래프 구조를 정의하지 않고도 파이썬 함수처럼 워크플로우를 작성할 수 있다. task를 호출하면 future 객체가 반환되어 병렬 실행도 자연스럽다. 코드량이 확실히 줄어든다. 다만 실행 흐름이 동적 생성이라 시각화가 안 되는 단점이 있다. 내 경험상 Supervisor 수준의 워크플로우는 Graph API로 명확한 구조를 유지하고, 서브 에이전트 내부 로직은 Functional API로 간결하게 작성하는 하이브리드 접근이 가장 효과적이었다. 두 API는 동일한 런타임 위에서 동작하기 때문에 자유롭게 혼합할 수 있다.
2025년에 추가된 Task Caching은 동일 입력에 대한 결과를 캐싱해서 중복 실행을 방지한다. cache_policy 파라미터로 세밀한 제어가 가능하다. Deferred Node Execution은 병렬 브랜치가 모두 완료된 후에 특정 노드가 실행되게 한다. 이 둘을 조합하면 여러 분석 에이전트를 병렬 실행하고 모든 결과가 모인 뒤에 종합 리포트를 생성하는 패턴을 효율적으로 구현할 수 있다. 예를 들어 시장 분석 시스템에서 경쟁사 가격 분석, SNS 감성 분석, 산업 트렌드 분석을 각각 다른 에이전트가 동시에 수행하고, 전부 끝나면 종합 에이전트가 실행되는 구조다. 각 분석 결과는 캐싱되어 있으므로 같은 요청이 들어오면 즉시 반환된다. 이 패턴을 도입한 뒤 전체 응답 시간이 순차 실행 대비 거의 3분의 1로 줄었다.
Handoff와 Forward Message, 비용 최적화의 핵심
Supervisor와 서브 에이전트 간 통신의 핵심이 Handoff 메커니즘이다. 기본적으로 create_handoff_tool이 에이전트 간 작업 전달 도구를 자동 생성한다. 여기서 실전 최적화 포인트가 create_forward_message_tool이다.
기본 동작은 서브 에이전트가 결과를 반환하면 Supervisor가 이를 다시 처리해서 사용자에게 전달하는 것이다. 하지만 서브 에이전트의 응답이 이미 충분하다면 forward_message를 사용해 그대로 최종 출력으로 보낼 수 있다. 이 방식은 두 가지 이점이 있다. Supervisor의 추가 LLM 호출이 줄어 토큰 비용이 절감되고, 전문적인 응답이 요약 과정에서 왜곡될 위험도 사라진다. 기술적 답변이나 정확한 수치가 포함된 응답에서 이 차이가 특히 크다.
커스텀 핸드오프 도구도 만들 수 있다. InjectedState와 InjectedToolCallId를 활용하면 다음 에이전트에게 상세한 작업 지시와 현재 상태를 함께 전달해서 컨텍스트 유실 문제를 해결할 수 있다. 메모리 설정에서는 체크포인터를 최상위 에이전트에만 설정하는 것이 정석이다. 개발 때는 InMemorySaver를, 프로덕션에서는 PostgreSQL 기반 체크포인터를 사용하면 된다.
실전에서 마주치는 문제들과 해결 전략
이론은 깔끔하지만 실전은 늘 지저분하다. 대표적인 문제들과 해결법을 공유한다.
라우팅 실패는 가장 흔한 문제다. 사용자 질문이 모호할 때 Supervisor가 엉뚱한 에이전트에게 작업을 보낸다. Supervisor의 시스템 프롬프트에 “결제 관련: 환불, 카드 변경, 구독 해지” 같은 구체적 키워드와 시나리오를 명시하면 정확도가 크게 올라간다. 5개에서 10개 정도의 실패 트레이스를 열어보고 Supervisor의 라우팅 판단 과정을 분석하면 패턴이 보인다.
컨텍스트 유실은 커스텀 핸드오프 도구에 task_description 파라미터를 추가해서 Supervisor가 구체적인 작업 지시를 전달하도록 하면 해결된다. 무한 루프는 Supervisor가 결과가 불충분하다고 판단해서 같은 에이전트에게 계속 재요청하는 상황인데, retry_policy로 재시도 횟수를 제한하거나 타임아웃을 설정하면 된다.
비용 관리도 빼놓을 수 없다. 멀티에이전트는 LLM 호출이 배로 늘어난다. forward_message 활용, 서브 에이전트에 경량 모델 사용, task caching을 조합하고 LangSmith로 에이전트별 토큰 소비를 모니터링하면 병목을 정확히 파악할 수 있다. LangSmith 연동은 정말 강력 추천하는데, 각 에이전트의 입출력 트레이스를 시각적으로 확인할 수 있어서 어디서 토큰이 낭비되는지 한눈에 보인다. 시스템이 커지면 계층적 Supervisor 구조를 도입해서 서브그래프로 팀 단위 독립 개발과 테스트를 가능하게 하는 것도 방법이다. 최상위 Supervisor 아래에 도메인별 중간 Supervisor를 두고, 중간 Supervisor가 다시 워커 에이전트에게 작업을 배분하는 형태다. Human-in-the-Loop도 실전에서 중요한데, LangChain 1.0의 HumanInTheLoopMiddleware를 서브 에이전트에 적용하면 이메일 발송이나 결제 같은 민감한 작업 전에 자동으로 사람의 승인을 요청할 수 있다. 모든 작업에 적용하면 자동화의 의미가 퇴색되니까 위험도 높은 작업에만 선별적으로 적용하는 것이 현실적인 정답이었다.
마무리
LangGraph 1.0의 Supervisor 멀티에이전트 아키텍처는 AI 에이전트 개발의 현주소를 보여준다. Durable Execution, 스트리밍, Human-in-the-Loop, 메모리라는 프로덕션 핵심 기능이 안정화되면서 드디어 데모가 아닌 실제 서비스를 만들 수 있는 기반이 갖춰졌다. GPT-5 기반 Supervisor 패턴은 tool calling의 안정성 위에서 복잡한 업무를 효과적으로 분할하고 조율하는 구조를 제공하고, Dynamic Tool Calling이나 Task Caching 같은 신기능은 에이전트의 신뢰성과 효율성을 동시에 끌어올려준다. 물론 라우팅 실패나 컨텍스트 유실 같은 현실적 문제가 있지만 체계적인 프롬프트 엔지니어링과 아키텍처 설계로 충분히 극복 가능하다. 핵심은 프레임워크 기능을 아는 것이 아니라 실제로 부딪히면서 최적의 설계를 찾아가는 과정에 있다. 처음부터 완벽한 시스템을 만들겠다는 욕심보다는, 작은 Supervisor 구조부터 시작해서 에이전트를 하나씩 추가하며 점진적으로 확장해가는 전략이 결국 가장 빠른 길이었다. LangGraph 생태계는 지금도 빠르게 발전하고 있으니, 공식 문서와 체인지로그를 꾸준히 확인하면서 새로운 기능을 적극적으로 시도해보길 바란다.