AI VIDEO BRIEFING

LangGraph로 직접 만드는 AI 에이전트와 워크플로우 5가지 핵심 패턴 완전 정리

LangChain의 Lance가 Anthropic의 '효과적인 에이전트 만들기' 글을 바탕으로 워크플로우와 에이전트의 차이, 그리고 프롬프트 체이닝·병렬화·라우팅 등 핵심 패턴을 LangGraph로 직접 구현해 설명했다.

워크플로우와 에이전트는 무엇이 다른가 — LangGraph로 배우는 효과적인 AI 에이전트 설계 영상 대표 이미지

핵심 메시지

  • 워크플로우는 LLM 호출을 미리 정해진 코드 경로(스캐폴딩) 안에 넣는 방식이고, 에이전트는 그 스캐폴딩을 걷어내 LLM이 스스로 행동을 결정하게 하는 방식이다.
  • LangGraph는 프롬프트나 아키텍처를 추상화하지 않고, 그 아래에서 지속성(메모리·휴먼인더루프)·스트리밍·배포라는 저수준 인프라를 제공한다.
  • 프롬프트 체이닝, 병렬화, 라우팅, 오케스트레이터-워커, 평가자-최적화기 등 대부분의 워크플로우는 '구조화된 출력'만으로도 구현할 수 있다.
  • 에이전트는 도구 호출을 하고 그 결과(환경 피드백)를 받아 다음 행동을 정하는 루프이며, 더 이상 도구가 필요 없을 때까지 반복한다.
  • 정해진 도구 호출 순서를 알 수 있다면 워크플로우가 더 안정적이고, 예측 불가능한 열린 문제일 때 비로소 에이전트가 적합하다.

쉽게 이해하기

LangChain의 Lance는 Anthropic이 공개한 '효과적인 에이전트 만들기(Building effective agents)' 글에 나오는 모든 워크플로우와 에이전트를 LangGraph로 처음부터 직접 구현하며 설명한다. 그는 워크플로우를 'LLM 호출을 감싸는 미리 정해진 코드 경로의 스캐폴딩'으로, 에이전트를 '그 스캐폴딩을 없애 LLM이 도구 호출로 스스로 행동을 이끌고 환경 피드백을 받아 다음을 결정하는 방식'으로 구분한다.

그는 이런 패턴을 프레임워크 없이 몇 줄의 코드로도 구현할 수 있음을 인정하면서도, LangGraph의 가치는 프롬프트나 아키텍처를 추상화하지 않는 대신 그 아래에 인프라를 깔아주는 데 있다고 말한다. 그 세 가지는 지속성(메모리와 휴먼인더루프, 즉 에이전트를 멈춰 도구 호출을 승인·검토하는 기능), 스트리밍(도구 호출 결과 등 중간 단계까지 세밀하게 출력), 그리고 테스트·디버깅·배포의 용이함이다.

기본 구성 요소는 '증강된 LLM'이다. 스키마를 묶어 구조화된 출력을 강제하거나, 함수를 도구로 묶어 도구 호출을 시키는 것이다. 이를 바탕으로 워크플로우 패턴들을 쌓는다. 프롬프트 체이닝은 앞 호출의 출력을 뒤 호출이 이어받는 방식으로, 농담을 생성한 뒤 '핵심 문장이 있는지' 게이트로 검사하고 두 번 더 다듬는 예시로 보여준다.

병렬화는 하나의 주제로 농담·이야기·시를 동시에 만들어 마지막에 합치는 식으로, 여러 관점이 필요하거나 독립적 작업을 나눌 때 쓴다. 라우팅은 구조화된 출력으로 LLM이 입력을 어느 경로로 보낼지 결정하게 하는 방식이다. 오케스트레이터-워커는 계획 단계에서 몇 개의 하위 작업이 필요한지 미리 알 수 없을 때, LLM이 섹션 목록을 동적으로 만들고 send API로 워커를 그때그때 띄워 각 섹션을 병렬로 작성하게 한다(리포트 작성이 대표 사례).

평가자-최적화기는 한 LLM이 응답을 만들고 다른 LLM이 채점·피드백하는 루프로, RAG 응답의 환각을 걸러낼 때 유용하다. 마지막으로 에이전트는 스캐폴딩을 없애고 LLM+도구+도구 실행 노드+조건부 엣지로 이뤄진 단순한 루프다. Lance는 SWE-bench 같은 열린 문제에는 에이전트가 적합하지만, 도구 호출 순서를 대략 알 수 있는 경우엔 워크플로우가 더 신뢰할 만해 현재 실무에서 더 많이 쓰인다고 말한다.

주요 인사이트

  • 워크플로우와 에이전트의 본질적 차이는 '스캐폴딩의 유무'다. 워크플로우 안에서도 LLM이 도구를 호출할 수 있지만, 에이전트는 그런 추론용 발판 없이 환경 피드백을 직접 받아 행동한다.
  • Lance는 '구조화된 출력이 사실상 필요한 전부'라고 표현한다. 라우터·게이트·평가자 같은 제어 흐름 판단을 도구 호출 대신 구조화된 출력으로 깔끔하게 만들 수 있기 때문이다.
  • 오케스트레이터-워커의 핵심은 워커에게 각자의 상태를 주고, 겹치는 상태 키(예: completed sections)에 병렬로 기록하게 해 바깥 상태에도 자동 반영시키는 설계다. send API로 워커 수를 동적으로 결정한다.
  • 에이전트 루프의 관용적 형태는 '마지막 메시지가 도구 호출이면 도구 노드로, 아니면 종료'라는 조건부 엣지 하나로 표현되며, LLM이 더 이상 도구가 필요 없다고 판단할 때까지 돈다.
  • LangGraph로 워크플로우나 에이전트를 컴파일하면 단·장기 메모리를 주는 지속성 계층, 중단·검토·재개(휴먼인더루프), 다양한 스트리밍, 그리고 빠른 배포를 사실상 공짜로 얻는다. 처음부터 직접 짜도 되고 create_react_agent 같은 사전 제작 메서드를 써도 된다.

자주 묻는 질문

이 영상에서 정의하는 워크플로우와 에이전트의 차이는?

워크플로우는 LLM 호출을 미리 정해진 코드 경로(스캐폴딩) 안에 배치하는 방식이고, 에이전트는 그 스캐폴딩을 없애 LLM이 도구 호출로 스스로 행동을 정하고 환경 피드백을 받아 다음을 결정하는 방식이다.

LangGraph가 실제로 제공하는 것은 무엇인가?

프롬프트나 아키텍처를 추상화하지 않는 대신, 그 아래에서 지속성(메모리·휴먼인더루프), 스트리밍, 테스트·디버깅·배포의 용이함이라는 저수준 인프라를 제공한다.

오케스트레이터-워커 패턴은 언제 쓰나?

필요한 하위 작업의 개수를 미리 알 수 없을 때다. LLM이 계획을 세워 섹션 목록을 동적으로 만들고, send API로 워커를 그때그때 띄워 각 섹션을 병렬로 처리한 뒤 합친다. 리포트 작성이 대표적이다.

언제 워크플로우 대신 에이전트를 써야 하나?

도구 사용 패턴을 미리 예측하기 어려운 열린 문제(예: SWE-bench 같은 소프트웨어 엔지니어링 과제)에는 에이전트가 적합하다. 반대로 도구 호출 순서를 대략 알 수 있으면 워크플로우가 더 안정적이라 실무에서 더 선호된다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식