요약 (TL;DR):

**신뢰할 수 있는 에이전트 시스템 (agentic systems)을 구축할 때 어려운 점은 각 단계에서 LLM이 적절한 문맥 (context)을 갖도록 보장하는 것입니다. 이는 LLM에 들어가는 정확한 콘텐츠를 제어하는 것과, 관련 콘텐츠를 생성하기 위해 적절한 단계를 실행하는 것 모두를 포함합니다.****에이전트 시스템은 워크플로우 (workflows)와 에이전트 (agents), 그리고 그 사이의 모든 것으로 구성됩니다.****대부분의 에이전트 프레임워크는 선언적 (declarative) 또는 명령형 (imperative) 오케스트레이션 프레임워크가 아니라, 단지 에이전트 추상화 (agent abstractions)의 집합일 뿐입니다.****에이전트 추상화는 시작을 쉽게 만들어 줄 수 있지만, 종종 내부를 모호하게 만들어 각 단계에서 LLM이 적절한 문맥을 갖도록 보장하는 것을 어렵게 만들 수 있습니다.****모든 형태와 규모의 에이전트 시스템 (에이전트 또는 워크플로우)은 프레임워크에 의해 제공되거나 처음부터 직접 구축될 수 있는 동일한 유용한 기능 세트로부터 이점을 얻습니다.**LangGraph는 일련의 에이전트 추상화가 그 위에 구축된 오케스트레이션 프레임워크 (선언적 및 명령형 API 모두 포함)로 생각하는 것이 가장 적절합니다.

OpenAI는 최근 에이전트를 구축하는 방법에 대한 가이드를 발표했는데, 여기에는 아래와 같이 잘못된 견해들이 포함되어 있습니다:

이 인용구는 처음에 저를 화나게 했지만, 답변을 쓰기 시작하면서 깨달았습니다. 에이전트 프레임워크를 생각하는 것은 복잡하다는 것을요! 아마도 100가지 이상의 서로 다른 에이전트 프레임워크가 있을 것이고, 이들을 비교할 수 있는 다양한 축이 존재하며, 때로는 (이 인용구처럼) 개념이 혼동되기도 합니다. 세상에는 많은 과장과 허세, 그리고 소음이 존재합니다. 에이전트 프레임워크에 대한 정밀한 분석이나 사고는 거의 이루어지지 않고 있습니다. 이 블로그는 그렇게 해보려는 우리의 시도입니다. 우리는 다음 내용을 다룰 것입니다:

배경 정보 (Background Info)

• 에이전트란 무엇인가?
• 에이전트를 구축하는 것이 왜 어려운가?
• LangGraph란 무엇인가?

에이전트 프레임워크의 유형 (Flavors of agentic frameworks)

• “에이전트 (Agents)” vs “워크플로우 (workflows)”
• 선언적 (Declarative) vs 비선언적 (non-declarative)
• 에이전트 추상화 (Agent abstractions)
• 멀티 에이전트 (Multi agent)

자주 묻는 질문 (Common Questions)

• 프레임워크의 가치는 무엇인가?
• 모델이 발전함에 따라, 모든 것이 워크플로 (workflows) 대신 에이전트 (agents)가 될 것인가?
• OpenAI는 그들의 관점에서 무엇을 잘못 생각했는가?
• 모든 에이전트 프레임워크들은 어떻게 비교되는가?

이 블로그 전반에 걸쳐 저는 몇 가지 자료를 반복적으로 참조할 것입니다:

• OpenAI의 에이전트 구축 가이드 (특별히 훌륭하다고 생각하지 않습니다)
• Anthropic의 효과적인 에이전트 구축 가이드 (매우 좋아합니다)
• LangGraph (신뢰할 수 있는 에이전트를 구축하기 위한 우리의 프레임워크)

배경 정보 (Background info)

블로그의 나머지 내용을 위한 무대를 설정하는 데 도움이 되는 맥락입니다.

에이전트란 무엇인가 (What is an agent)

에이전트에 대한 일관된 정의는 없으며, 종종 서로 다른 관점을 통해 제시됩니다.

OpenAI는 에이전트를 정의하는 데 있어 더 높은 수준의, 더 사고 주도적인 (thought-leadery) 접근 방식을 취합니다.

에이전트는 당신을 대신하여 독립적으로 작업을 수행하는 시스템입니다.

개인적으로 저는 이를 좋아하지 않습니다. 이는 에이전트가 무엇인지 이해하는 데 실제로 도움이 되지 않는 모호한 진술입니다. 이는 단지 사고 주도적 (thought-leadership)일 뿐이며 전혀 실용적이지 않습니다.

이를 Anthropic의 정의와 비교해 보십시오:

"에이전트"는 여러 가지 방식으로 정의될 수 있습니다. 어떤 고객들은 에이전트를 복잡한 작업을 완수하기 위해 다양한 도구를 사용하며 장기간 독립적으로 작동하는 완전 자율 시스템으로 정의합니다. 다른 이들은 사전 정의된 워크플로 (workflows)를 따르는 더 규정적인 (prescriptive) 구현을 설명하기 위해 이 용어를 사용합니다. Anthropic에서는 이러한 모든 변형을 에이전트적 시스템 (agentic systems)으로 분류하지만, 워크플로 (workflows)와 에이전트 (agents) 사이에 중요한 아키텍처적 구분을 둡: 워크플로 (Workflows)는 LLM과 도구가 사전 정의된 코드 경로를 통해 오케스트레이션 (orchestrated)되는 시스템입니다. 반면, 에이전트 (Agents)는 LLM이 자신의 프로세스와 도구 사용을 동적으로 지시하며, 작업을 어떻게 완수할지에 대한 제어권을 유지하는 시스템입니다.

몇 가지 이유로 저는 Anthropic의 정의를 더 좋아합니다:

• 그들의 에이전트 (agent) 정의는 훨씬 더 정밀하고 기술적입니다.
• 또한 그들은 “에이전트적 시스템 (agentic systems)”이라는 개념을 언급하며, 워크플로 (workflows)와 에이전트 (agents)를 모두 이 개념의 변형으로 분류합니다. 저는 이 점이 정말 마음에 듭니다.

💡

우리가 실제 서비스(production)에서 보는 거의 모든 “에이전트적 시스템 (agentic systems)”은 “워크플로 (workflows)”와 “에이전트 (agents)”의 결합입니다.

블로그 포스트 후반부에서, Anthropic은 에이전트를 “… 일반적으로 루프(loop) 내에서 환경 피드백 (environmental feedback)을 기반으로 도구 (tools)를 사용하는 LLM일 뿐이다”라고 정의합니다.

처음에는 에이전트에 대해 거창한 정의를 내렸음에도 불구하고, 이것은 기본적으로 OpenAI가 의미하는 바와도 같습니다.

이러한 유형의 에이전트는 다음 요소들에 의해 매개변수화 (parameterized)됩니다:

• 사용할 모델 (model)
• 사용할 지시 사항 (system prompt)
• 사용할 도구 (tools)

당신은 루프 (loop) 안에서 모델을 호출합니다. 모델이 도구를 호출하기로 결정하면, 해당 도구를 실행하고, 어떤 관찰/피드백 (observation/feedback)을 얻은 다음, 이를 다시 LLM에 전달합니다. LLM이 더 이상 도구를 호출하지 않기로 결정할 때까지 (또는 중단 기준 (stopping criteria)을 트리거하는 도구를 호출할 때까지) 이 과정을 반복합니다.

OpenAI와 Anthropic 모두 워크플로 (workflows)를 에이전트 (agents)와는 다른 디자인 패턴 (design pattern)이라고 명시합니다. 워크플로에서는 LLM의 제어권이 더 낮으며, 흐름이 더 결정론적 (deterministic)입니다. 이는 매우 유용한 구분입니다!

OpenAI와 Anthropic은 모두 항상 에이전트가 필요한 것은 아니라고 명시적으로 언급합니다. 많은 경우, 워크플로 (workflows)가 더 단순하고, 더 신뢰할 수 있으며, 더 저렴하고, 더 빠르며, 더 성능이 좋습니다. Anthropic 포스트의 멋진 인용구입니다:

LLM으로 애플리케이션을 구축할 때, 우리는 가능한 한 가장 단순한 해결책을 찾고, 필요할 때만 복잡성을 높일 것을 권장합니다. 이는 에이전트적 시스템 (agentic systems)을 전혀 구축하지 않는 것을 의미할 수도 있습니다. 에이전트적 시스템은 종종 더 나은 작업 성능을 위해 지연 시간 (latency)과 비용을 희생하며, 당신은 이러한 트레이드오프 (tradeoff)가 타당한 시점이 언제인지 고려해야 합니다.

더 많은 복잡성이 정당화될 때, 워크플로 (workflows)는 잘 정의된 작업에 대해 예측 가능성과 일관성을 제공하는 반면, 에이전트 (agents)는 대규모 환경에서 유연성과 모델 주도 의사결정 (model-driven decision-making)이 필요할 때 더 나은 선택지입니다.

OpenAI도 이와 유사한 말을 합니다:

에이전트를 구축하기로 결정하기 전에, 귀하의 유스케이스 (use case)가 이러한 기준들을 명확히 충족할 수 있는지 검증하십시오. 그렇지 않다면 결정론적 (deterministic) 솔루션으로도 충분할 수 있습니다.

실제로 우리는 대부분의 "에이전트적 시스템 (agentic systems)"이 워크플로우 (workflows)와 에이전트 (agents)의 결합이라는 것을 목격합니다. 이것이 제가 어떤 것이 에이전트인지 아닌지에 대해 이야기하는 것을 실제로 싫어하며, 대신 시스템이 얼마나 에이전트적인지 (how agentic)에 대해 이야기하는 것을 선호하는 이유입니다. 이러한 사고방식을 제시해 준 위대한 Andrew Ng에게 감사를 표합니다:

어떤 것이 에이전트인지 아닌지를 이진법적인 방식으로 선택하기보다는, 시스템을 다양한 정도로 에이전트와 유사하게 (agent-like) 생각하는 것이 더 유용할 것이라고 생각했습니다. 명사인 "에이전트 (agent)"와 달리, 형용사인 "에이전트적 (agentic)"을 사용하면 그러한 시스템들을 고찰하고 이 성장하는 움직임에 모두 포함시킬 수 있습니다.

에이전트를 구축하는 것이 왜 어려운가?

에이전트를 구축하는 것이 어렵다는 점에는 대부분의 사람들이 동의할 것이라고 생각합니다. 더 정확히 말하자면, 프로토타입 (prototype)으로서의 에이전트를 만드는 것은 쉽지만, 비즈니스 핵심 애플리케이션 (business-critical applications)을 구동할 수 있는 신뢰할 수 있는 에이전트를 만드는 것은 어렵습니다.

까다로운 부분은 바로 그것, 즉 신뢰성을 확보하는 것입니다. Twitter에서 보기 좋아 보이는 데모를 만드는 것은 쉽습니다. 하지만 그것을 비즈니스 핵심 애플리케이션을 구동하는 데 사용할 수 있을까요? 엄청난 노력 없이는 불가능합니다.

우리는 몇 달 전 에이전트 빌더들을 대상으로 설문 조사를 실시하여 다음과 같이 물었습니다: “더 많은 에이전트를 프로덕션 (production)에 배치할 때 겪는 가장 큰 제약 사항은 무엇입니까?” 압도적인 1위 답변은 “성능 품질 (performance quality)”이었습니다. 이러한 에이전트들이 제대로 작동하게 만드는 것은 여전히 매우 어렵습니다.

무엇이 때때로 에이전트의 성능을 저하시키나요? LLM이 실수를 하기 때문입니다.

왜 LLM은 실수를 하나요? 두 가지 이유가 있습니다: (a) 모델의 성능이 충분하지 않거나, (b) 모델에 잘못된 (또는 불완전한) 컨텍스트 (context)가 전달되기 때문입니다.

우리의 경험상, 두 번째 사례인 경우가 매우 빈번합니다. 무엇이 이를 유발할까요?

• 불완전하거나 짧은 시스템 메시지 (system messages)
• 모호한 사용자 입력 (user input)
• 적절한 도구 (tools)에 대한 접근 권한 부재
• 부실한 도구 설명 (tool descriptions)
• 적절한 컨텍스트를 전달하지 않음
• 잘못된 형식의 도구 응답 (tool responses)

💡

신뢰할 수 있는 에이전트 시스템 (agentic systems)을 구축하는 어려운 점은 각 단계에서 LLM이 적절한 컨텍스트 (context)를 갖도록 보장하는 것입니다. 여기에는 LLM에 들어가는 정확한 콘텐츠를 제어하는 것과, 관련 콘텐츠를 생성하기 위해 적절한 단계를 실행하는 것이 모두 포함됩니다.

에이전트 프레임워크 (agent frameworks)에 대해 논의할 때, 이 점을 염두에 두는 것이 도움이 됩니다. LLM에 전달되는 내용을 정확하게 제어하는 것을 더 어렵게 만드는 프레임워크는 그저 방해 요소가 될 뿐입니다. LLM에 올바른 컨텍스트를 전달하는 것만으로도 이미 충분히 어려운데, 왜 스스로를 더 힘들게 만들겠습니까?

LangGraph란 무엇인가

💡

LangGraph는 일련의 에이전트 추상화 (agent abstractions)가 그 위에 구축된 오케스트레이션 프레임워크 (orchestration framework, 선언적 및 명령형 API 모두 지원)로 생각하는 것이 가장 좋습니다.

LangGraph는 에이전트 시스템 (agentic systems)을 구축하기 위한 이벤트 기반 (event-driven) 프레임워크입니다. 이를 사용하는 가장 일반적인 두 가지 방법은 다음과 같습니다:

• 선언적 (declarative)인 그래프 기반 구문
• 에이전트 추상화 (하위 수준 프레임워크 위에 구축됨)

LangGraph는 함수형 API (functional API)뿐만 아니라 기반이 되는 이벤트 기반 API (event-driven API)도 지원합니다. Python 및 TypeScript 버전이 모두 존재합니다.

에이전트 시스템 (agentic systems)은 노드 (nodes)와 엣지 (edges)로 표현될 수 있습니다. 노드는 작업 단위 (units of work)를 나타내고, 엣지는 전이 (transitions)를 나타냅니다. 노드와 엣지는 일반적인 Python 또는 TypeScript 코드에 불과합니다. 따라서 그래프의 구조는 선언적인 방식으로 표현되지만, 그래프 로직의 내부 기능은 일반적인 명령형 (imperative) 코드입니다. 엣지는 고정될 수도 있고 조건부 (conditional)일 수도 있습니다. 따라서 그래프의 구조는 선언적이지만, 그래프를 통과하는 경로는 완전히 동적 (dynamic)일 수 있습니다.

LangGraph에는 내장된 지속성 계층 (persistence layer)이 포함되어 있습니다. 이를 통해 결함 허용 (fault tolerance), 단기 기억 (short-term memory), 그리고 장기 기억 (long-term memory)이 가능해집니다.

이 지속성 계층은 또한 중단 (interrupt), 승인 (approve), 재개 (resume), 타임 트래블 (time travel)과 같은 "human-in-the-loop" 및 "human-on-the-loop" 패턴을 가능하게 합니다.

LangGraph는 토큰 (tokens), 노드 업데이트 (node updates), 그리고 임의의 이벤트 (arbitrary events)에 대한 스트리밍 (streaming)을 기본적으로 지원합니다.

LangGraph는 디버깅 (debugging), 평가 (evaluation), 그리고 관찰 가능성 (observability)을 위해 LangSmith와 원활하게 통합됩니다.

에이전트 프레임워크의 유형 (Flavors of agentic frameworks)

에이전트 프레임워크 (Agentic frameworks)는 몇 가지 차원에서 서로 다릅니다. 이러한 차원들을 이해하고 혼동하지 않는 것이 에이전트 프레임워크를 제대로 비교할 수 있는 핵심입니다.

워크플로우 (Workflows) vs 에이전트 (Agents)

대부분의 프레임워크는 더 높은 수준의 에이전트 추상화 (agent abstractions)를 포함하고 있습니다. 일부 프레임워크는 일반적인 워크플로우를 위한 추상화를 포함하기도 합니다. LangGraph는 에이전트 시스템을 구축하기 위한 저수준 오케스트레이션 (low level orchestration) 프레임워크입니다. LangGraph는 워크플로우, 에이전트, 그리고 그 사이의 모든 것을 지원합니다. 우리는 이것이 매우 중요하다고 생각합니다. 언급했듯이, 프로덕션 (production) 환경의 대부분의 에이전트 시스템은 워크플로우와 에이전트의 조합입니다. 프로덕션 준비가 된 프레임워크라면 두 가지를 모두 지원해야 합니다.

신뢰할 수 있는 에이전트를 구축할 때 어려운 점이 무엇인지 기억해 봅시다. 바로 LLM이 적절한 컨텍스트 (context)를 갖도록 보장하는 것입니다. 워크플로우가 유용한 이유 중 하나는 LLM에 적절한 컨텍스트를 전달하기 쉽게 만들기 때문입니다. 데이터가 어떻게 흐를지를 정확하게 결정할 수 있습니다.

여러분이 "워크플로우"에서 "에이전트"로 이어지는 스펙트럼 중 어디에서 애플리케이션을 구축하고 싶은지 생각할 때, 고려해야 할 두 가지가 있습니다:

• 예측 가능성 (Predictability) vs 자율성 (agency)
• 낮은 진입 장벽, 높은 한계치 (Low floor, high ceiling)

예측 가능성 (Predictability) vs 자율성 (agency)

시스템이 더 에이전트화될수록, 예측 가능성은 낮아집니다.

때때로 사용자의 신뢰, 규제상의 이유 또는 기타 이유로 시스템이 예측 가능하기를 원하거나 필요할 수 있습니다.

신뢰성 (Reliability)이 예측 가능성과 100% 일치하는 것은 아니지만, 실제로는 밀접하게 연관될 수 있습니다.

이 곡선의 어느 지점에 위치하고 싶은지는 여러분의 애플리케이션에 따라 매우 구체적으로 달라집니다. LangGraph는 이 곡선의 어느 지점에서든 애플리케이션을 구축하는 데 사용될 수 있으며, 여러분이 원하는 곡선 위의 지점으로 이동할 수 있게 해줍니다.

높은 진입 장벽, 낮은 한계치 (High floor, low ceiling)

프레임워크를 생각할 때, 그들의 진입 장벽 (floor)과 한계치 (ceiling)를 생각하는 것이 도움이 될 수 있습니다:

• Low floor (낮은 진입 장벽): low floor 프레임워크는 초보자 친화적이며 시작하기 쉽습니다. - High floor (높은 진입 장벽): high floor 프레임워크는 학습 곡선 (learning curve)이 가파르며, 효과적으로 사용하기 위해 상당한 지식이나 전문성이 필요함을 의미합니다. - Low ceiling (낮은 한계치): low ceiling 프레임워크는 이를 통해 달성할 수 있는 작업에 한계가 있음을 의미합니다 (금방 한계를 느끼게 될 것입니다). - High ceiling (높은 한계치): high ceiling 프레임워크는 고급 사용 사례 (advanced use cases)를 위한 광범위한 기능과 유연성을 제공합니다 (사용자와 함께 성장할 수 있습니다).

워크플로 (Workflow) 프레임워크는 높은 한계치 (high ceiling)를 제공하지만, 높은 진입 장벽 (high floor)을 동반합니다. 즉, 에이전트 로직 (agent logic)의 상당 부분을 직접 작성해야 합니다.