AI 에이전트 개발 필수 용어 총정리 (3): 에이전틱 오케스트레이션 프레임워크

Think harder. Think systematically.

[Context]
I am a new junior developer who has absolutely zero background in modern AI agent development and software infrastructure. I have recently joined a development team to build AI agents, but I find myself completely lost when my seniors use terms like 'Bun' or 'pi' as if they are common knowledge. I now need to master the essential vocabulary of AI agent development and its underlying infrastructure to build and manage agents effectively in a software development setting.

I have never studied, practiced, or even casually encountered modern runtimes, package managers, or agentic frameworks. My knowledge in this area is completely blank.

Therefore, do NOT skip over terms, actions, or concepts that a senior software engineer would consider so obvious they go without saying. The things that are "too basic to mention" are precisely what I need explained — the implicit, taken-for-granted knowledge that experts forget is not universal.

[Request]
Create an encyclopedia-level deep-dive terminology dictionary covering these sub-domains: JavaScript and TypeScript Runtimes, Package Managers and Dependency Management, Agentic Orchestration Frameworks, Vector Databases and Memory Management, Execution Environments and Sandboxing, API Integration and Tool Calling.

For each term, explain not just the definition but also: why the term exists (historical or practical origin), how it connects to neighboring concepts, common beginner mistakes or misconceptions, edge cases or exceptions that practitioners know from experience, and how the term is actually used in day-to-day work (not just textbook definitions).

[Output Constraints]

Output Language: ALL output MUST be written in Korean. English original terms should appear in parentheses where they aid understanding (e.g., 런타임(Runtime)).

Output Volume: Use your FULL output token capacity with ZERO abbreviation. Absolute maximum verbosity.

Output Format: Use long-form descriptive paragraphs, NOT short bullet points. No emojis.

Depth: Expand on every nuance, edge case, historical context, and common real-world mistake for each term.

If you reach the output limit, end with ">>> 여기서부터 이어서 작성 <<<" so the user can prompt you to continue.

3부: 에이전틱 오케스트레이션 프레임워크 (Agentic Orchestration Frameworks)

에이전트(Agent)란 무엇인가

에이전트(Agent)는 AI 개발에서 가장 자주 등장하는 단어지만, 그 의미의 폭이 넓어서 맥락에 따라 다른 뉘앙스로 쓰인다. 가장 핵심적인 정의는, 에이전트란 “목표(Goal)를 달성하기 위해 스스로 판단하여 행동(Action)을 선택하고 실행할 수 있는 AI 시스템”이다. 단순한 챗봇(Chatbot)은 사람이 입력한 질문에 답변을 생성하는 것에 그친다. 반면 에이전트는 “다음에 어떤 행동을 할지”를 스스로 결정하고, 필요하면 외부 도구(Tool)를 사용하며, 그 결과를 바탕으로 다시 판단하는 루프(Loop)를 반복한다.23

예를 들어 “2025년 1월 삼성전자 주가 분석 보고서를 작성해”라는 요청을 받은 에이전트는 다음과 같이 동작할 수 있다. 먼저 웹 검색 도구를 호출하여 해당 기간의 주가 데이터를 수집하고, 그 다음 데이터 분석 도구로 차트를 생성하며, 이후 텍스트 생성 능력으로 분석 보고서를 작성한 다음, 마지막으로 이메일 전송 도구로 보고서를 발송한다. 이 모든 과정이 사람의 개입 없이 LLM(Large Language Model)의 추론 능력을 기반으로 이루어진다. 이것이 단순한 LLM과 에이전트의 차이다.

오케스트레이션(Orchestration)

오케스트레이션(Orchestration)은 음악에서의 편곡(Orchestration)에서 온 메타포다. 오케스트라에서 지휘자가 여러 악기 연주자들이 조화롭게 연주하도록 조율하듯, 소프트웨어에서 오케스트레이터(Orchestrator)는 여러 에이전트, 도구, 서비스들이 협력하여 복잡한 작업을 완수하도록 조율하는 역할을 한다. AI 에이전트 개발에서 오케스트레이션 프레임워크는 다음 질문들에 답한다. 어떤 에이전트가 먼저 실행되는가? 에이전트 A의 출력이 에이전트 B의 입력이 되는가? 중간에 오류가 발생하면 어떻게 처리하는가? 특정 조건이 충족되면 실행 흐름이 다른 경로로 분기하는가? 여러 에이전트가 동시에 병렬로 실행되는가?24

오케스트레이션이 필요한 이유는 현실의 작업이 단순하지 않기 때문이다. 단순한 Q&A는 LLM 하나로 처리할 수 있지만, “경쟁사 분석 보고서 작성 → 회계 데이터 정리 → 전략적 제안 생성 → 슬라이드 덱 제작 → 이해관계자에게 이메일 발송”처럼 여러 단계가 순차적 또는 병렬로 연결된 작업에는 반드시 오케스트레이션 레이어가 필요하다. LangGraph, CrewAI, AutoGen 같은 프레임워크들이 바로 이 역할을 담당한다.

LangChain

LangChain은 2022년 해리슨 체이스(Harrison Chase)가 만든 오픈소스 프레임워크로, LLM을 기반으로 한 애플리케이션 개발을 단순화하기 위해 설계되었다. LangChain이 등장했을 때 AI 개발 생태계에서의 위치는 거의 사실상 표준에 가까웠다. OpenAI API를 직접 호출하면 프롬프트(Prompt) 구성, 채팅 히스토리 관리, 메모리 저장, 외부 도구 연결 등을 모두 직접 구현해야 하는데, LangChain은 이러한 공통 패턴을 추상화하여 재사용 가능한 컴포넌트(Component)로 제공했다.25

LangChain의 핵심 개념들을 이해하면 다른 프레임워크들도 쉽게 파악할 수 있다. 체인(Chain)은 여러 컴포넌트를 파이프라인처럼 연결한 것이다. 예를 들어 “프롬프트 템플릿 → LLM 호출 → 출력 파싱”을 하나의 체인으로 묶을 수 있다. 도구(Tool)는 에이전트가 사용할 수 있는 외부 기능이다. 웹 검색, 계산기, 데이터베이스 쿼리, 코드 실행 등이 모두 도구가 될 수 있다. 프롬프트 템플릿(Prompt Template)은 변수를 포함하는 재사용 가능한 프롬프트 구조다. 예를 들어 “사용자 질문: {question}: {context}:” 같은 형태다. 리트리버(Retriever)는 벡터 데이터베이스 등에서 관련 문서를 검색하는 컴포넌트다.

LangChain을 처음 접한 초보 개발자들이 가장 많이 혼란스러워하는 것은 패키지 구조의 분산이다. 2023~2024년 사이에 LangChain은 langchain(핵심 패키지), @langchain/core(인터페이스 정의), @langchain/community(커뮤니티 통합 패키지), @langchain/openai(OpenAI 전용 패키지) 등으로 여러 패키지로 분리했다. 따라서 설치할 때 어떤 패키지를 설치해야 하는지 혼란스럽고, 버전 불일치로 인한 오류가 자주 발생한다. 예를 들어 @langchain/core의 버전과 @langchain/openai의 버전이 서로 호환되지 않으면 런타임에서 예상치 못한 오류가 발생한다.

LangGraph

LangGraph는 LangChain 팀이 개발한 프레임워크로, 에이전트 워크플로우를 그래프(Graph) 구조로 정의하는 접근 방식을 취한다. 2025년 하반기에 버전 1.0을 정식 출시했으며, 이것은 API 안정성을 공식으로 약속한다는 의미에서 중요한 이정표다. LangGraph의 핵심 철학은 에이전트의 실행 흐름을 유한 상태 머신(Finite State Machine)으로 모델링하는 것이다.26

LangGraph를 이해하기 위해서는 그래프(Graph), 노드(Node), 엣지(Edge), 상태(State)라는 네 가지 개념이 핵심이다. 그래프는 전체 워크플로우를 나타낸다. 노드는 그래프 안의 각 처리 단계로, 예를 들어 “LLM에게 다음 행동을 물어본다”, “검색 도구를 실행한다”, “결과를 요약한다” 같은 각각의 작업 단위다. 엣지는 노드와 노드 사이의 연결, 즉 어떤 노드가 끝나면 어떤 노드로 이동하는지를 정의한다. 조건부 엣지(Conditional Edge)를 사용하면 LLM의 판단에 따라 다른 경로로 분기할 수 있다. 상태(State)는 워크플로우 전체에 걸쳐 공유되는 데이터 구조로, 각 노드는 이 상태를 읽고 수정한다.27

LangGraph가 단순한 LangChain 체인 방식보다 뛰어난 점은 복잡한 분기 로직과 루프(Loop) 처리다. 예를 들어 에이전트가 어떤 답을 생성했는데 그것이 충분하지 않다고 판단되면 다시 이전 노드로 돌아가서 재시도하는 루프를 자연스럽게 표현할 수 있다. LangChain의 기존 체인 방식은 일직선(Linear) 파이프라인에 가까웠지만, LangGraph는 임의의 비선형 흐름, 즉 루프, 분기, 병렬 실행을 모두 표현할 수 있는 범용 그래프를 제공한다. 이는 실제 현실의 복잡한 에이전트 시나리오에 훨씬 더 적합하다.

LangGraph의 또 다른 핵심 기능은 지속성(Persistence)과 체크포인팅(Checkpointing)이다. 에이전트가 복잡한 작업을 수행하다가 중간에 오류가 발생하거나 사용자의 개입이 필요할 때, 체크포인터(Checkpointer)가 현재 상태를 데이터베이스에 저장해둔다. 이후 작업을 이어서 재개할 때 처음부터 다시 시작할 필요 없이 저장된 상태에서 계속할 수 있다. 실무에서 LLM API 호출은 비용이 발생하므로, 여러 단계의 복잡한 에이전트 파이프라인이 중간에 실패했을 때 처음부터 다시 실행하는 것은 낭비다. 체크포인팅은 이 비용과 시간을 줄여주는 핵심 기능이다.

Human-in-the-Loop(인간 개입 루프)는 LangGraph의 실무 활용에서 매우 중요한 패턴이다. 에이전트가 어떤 작업을 수행하기 전에 인간의 승인을 받아야 하는 경우, 예를 들어 데이터베이스를 삭제하거나 큰 금액의 결제를 처리하는 경우, LangGraph는 그 지점에서 실행을 일시 정지하고 사람의 확인을 기다리는 interrupt() 메커니즘을 제공한다. 초보 개발자들이 흔히 범하는 실수는 에이전트에게 지나친 자율권을 주어 검증 없이 되돌릴 수 없는 작업을 실행하게 만드는 것이다. LangGraph의 인간 개입 루프는 이런 위험한 상황을 방지하는 안전장치다.

CrewAI

CrewAI는 2023년 조아오 모우라(João Moura)가 개발한 오픈소스 에이전트 오케스트레이션 프레임워크로, 여러 AI 에이전트를 “팀(Crew, 크루)”으로 구성하여 협업하게 만드는 데 특화되어 있다. CrewAI의 핵심 철학은 인간 조직의 역할 분담 구조를 AI 에이전트 시스템에 그대로 반영하는 것이다. 예를 들어 실제 뉴스 편집팀처럼 “조사 담당 에이전트”, “작성 담당 에이전트”, “편집 담당 에이전트”를 각각 정의하고, 이들이 순차적으로 또는 협업하여 최종 기사를 완성하는 구조를 코드로 쉽게 표현할 수 있다.1

CrewAI의 핵심 구성 요소는 에이전트(Agent), 태스크(Task), 크루(Crew), 도구(Tool), 그리고 프로세스(Process)다. 에이전트는 역할(Role), 목표(Goal), 배경 이야기(Backstory)로 정의된다. 예를 들어 역할은 “시장 조사 분석가”, 목표는 “AI 스타트업 생태계에 대한 통찰력 있는 분석 제공”, 배경 이야기는 “10년 경력의 벤처캐피털 분석가로 AI 시장 트렌드에 정통하다”처럼 마치 인물 카드처럼 설정한다. 이 배경 이야기가 단순한 장식처럼 보일 수 있지만, 실제로 LLM에게 전달되는 시스템 프롬프트의 일부가 되어 에이전트의 행동 방식과 출력 품질에 영향을 미친다.

태스크(Task)는 에이전트가 수행해야 할 구체적인 작업 단위다. 각 태스크는 어떤 에이전트가 담당하는지, 예상 출력(Expected Output)이 무엇인지, 이전 태스크의 출력을 컨텍스트로 받을지를 정의한다. 크루(Crew)는 에이전트와 태스크들을 묶어 실행하는 최상위 오케스트레이터다. 프로세스(Process)는 태스크들이 어떤 순서로 실행되는지를 결정하는데, 순차적 실행(Sequential Process)과 계층적 실행(Hierarchical Process)을 지원한다. 계층적 프로세스에서는 매니저 에이전트(Manager Agent)가 다른 에이전트들에게 태스크를 동적으로 위임하는 구조를 가진다.

초보 개발자가 CrewAI를 처음 사용할 때 가장 자주 경험하는 문제는 에이전트 간의 출력 형식 불일치다. 에이전트 A가 JSON 형식으로 출력했는데 에이전트 B는 자유 텍스트 형식을 기대하는 경우, 또는 필요한 정보가 출력 중 엉뚱한 위치에 있어서 다음 에이전트가 제대로 파악하지 못하는 경우가 실무에서 빈번하다. 이를 방지하기 위해 Pydantic 모델을 사용하여 태스크의 예상 출력 형식을 명확히 정의하는 것이 좋다. 또 다른 흔한 실수는 에이전트를 너무 많이 만드는 것이다. 경험 많은 개발자들은 실제로 2~4개의 에이전트가 잘 정의된 역할을 가진 구성이, 10개 이상의 에이전트가 모호하게 정의된 구성보다 훨씬 좋은 결과를 낸다고 말한다.2

AutoGen

AutoGen은 마이크로소프트 리서치(Microsoft Research)가 2023년 발표한 에이전트 오케스트레이션 프레임워크로, 이름에서 알 수 있듯이 자동화된 에이전트 생성과 대화(Conversation) 중심의 에이전트 협업을 강조한다. AutoGen의 핵심 추상화는 “대화 가능한 에이전트(Conversable Agent)”다. 모든 에이전트는 서로 메시지를 주고받는 대화 참여자로 모델링된다. 사람 에이전트(Human Agent)와 AI 에이전트(AI Agent)가 동일한 인터페이스로 대화에 참여할 수 있어, 자동화 실행 중 언제든지 인간이 개입하기 쉬운 구조를 제공한다.3

AutoGen v0.4부터 아키텍처가 전면 개편되어 AutoGen Core, AutoGen AgentChat, AutoGen Extensions 등으로 계층화된 구조를 갖추었다. AutoGen AgentChat은 빠른 프로토타이핑을 위한 고수준(High-Level) API를 제공하고, AutoGen Core는 더 세밀한 제어가 필요한 프로덕션 환경을 위한 저수준(Low-Level) API를 제공한다. 마이크로소프트의 Azure OpenAI 서비스와의 긴밀한 통합이 강점이며, 기업 환경에서 Copilot 기능을 구축할 때 자주 선택된다.4

초보 개발자가 AutoGen을 처음 접할 때 혼란을 야기하는 개념은 그룹 채팅(Group Chat)이다. GroupChatManager라는 특수한 에이전트가 여러 에이전트 간의 대화를 중재하는 방식인데, 이 관리자 자체도 LLM을 사용하여 다음 발언자(Speaker)를 결정한다. 이는 매우 유연한 대화 흐름을 만들지만, 때로는 예측 불가능한 방식으로 대화가 진행되거나 무한 루프에 빠지는 문제를 일으킬 수 있다. 이를 방지하기 위해 최대 라운드 수(max_round)를 설정하거나 종료 조건(Termination Condition)을 명확히 정의하는 것이 필수적이다.

OpenAI Agents SDK

OpenAI Agents SDK는 OpenAI가 2025년 초에 공개한 경량 에이전트 프레임워크로, 이전의 Assistants API와 Swarm의 교훈을 바탕으로 설계된 공식 에이전트 개발 도구다. 이 SDK의 핵심 추상화는 에이전트(Agent), 핸드오프(Handoff), 가드레일(Guardrail), 그리고 트레이싱(Tracing)이다. 핸드오프는 한 에이전트가 특정 조건에서 대화의 제어권을 다른 에이전트에게 넘기는 메커니즘이다. 예를 들어 일반 고객 서비스 에이전트가 처리하다가 기술적 문의가 들어오면 기술 지원 전문 에이전트에게 핸드오프하는 방식이다.5

가드레일(Guardrail)은 에이전트의 입력이나 출력을 검증하는 레이어다. 입력 가드레일은 사용자 입력이 특정 정책을 위반하는지 확인하고, 출력 가드레일은 에이전트가 생성한 응답이 적절한지 검증한다. 실무에서 가드레일은 에이전트 시스템의 안정성과 안전성을 보장하는 데 필수적인 요소로, 이것을 생략하고 에이전트를 프로덕션에 배포했다가 예상치 못한 유해한 출력이나 잘못된 정보가 사용자에게 전달되는 사고가 발생하는 경우가 많다. 트레이싱 기능은 OpenAI의 대시보드에서 에이전트의 모든 실행 단계를 시각적으로 확인할 수 있게 해주어 디버깅을 크게 쉽게 만든다.

ReAct 패턴 (Reasoning and Acting)

ReAct는 에이전트 분야에서 가장 중요한 개념 패턴 중 하나로, 프린스턴 대학과 구글의 연구진이 2022년 발표한 논문에서 제안된 에이전트 행동 방식이다. ReAct의 핵심은 추론(Reasoning)과 행동(Acting)을 번갈아 반복하게 만드는 것이다. 구체적으로, 에이전트는 매 단계마다 Thought(현재 상황에 대한 생각) → Action(수행할 행동과 도구 선택) → Observation(행동의 결과 관찰) 의 사이클을 반복하여 최종 목표에 도달한다.

예를 들어 “대한민국의 현재 대통령은 누구이며 그의 나이는 몇 살인가?”라는 질문을 ReAct 에이전트에게 주면, Thought: “이 질문에 답하려면 현재 대통령 이름을 먼저 찾아야 한다” → Action: 웹 검색 도구로 “대한민국 현재 대통령” 검색 → Observation: 검색 결과 획득 → Thought: “이제 그 사람의 생년월일을 찾아야 한다” → Action: 웹 검색 도구로 해당 인물의 나이 검색 → Observation: 나이 정보 획득 → Thought: “이제 두 정보를 합쳐 답변할 수 있다” → Final Answer 생성의 순서로 진행된다. 대부분의 현대 에이전트 프레임워크는 내부적으로 이 ReAct 패턴, 혹은 그 변형을 사용한다. LangChain에서 create_react_agent 함수로 ReAct 에이전트를 간단히 만들 수 있다.

RAG (Retrieval-Augmented Generation)

RAG는 AI 에이전트 개발에서 가장 핵심적인 아키텍처 패턴 중 하나로, 직역하면 “검색 보강 생성”이다. LLM은 학습 시점(Training Cutoff)까지의 데이터만 알고 있으며, 특정 기업의 내부 문서나 최신 정보는 알지 못한다. RAG는 이 한계를 극복하기 위해, LLM이 답변을 생성하기 전에 외부 지식 저장소에서 관련 문서를 검색(Retrieval)하여 그 내용을 컨텍스트로 함께 제공하는 방식이다.

RAG의 작동 흐름은 크게 두 단계, 인덱싱(Indexing)과 검색-생성(Retrieval-Generation)으로 나뉜다. 인덱싱 단계에서는 문서를 청크(Chunk, 작은 조각)로 나누고, 각 청크를 임베딩 모델(Embedding Model)을 통해 벡터(Vector)로 변환한 뒤, 벡터 데이터베이스에 저장한다. 검색-생성 단계에서는 사용자 질문을 동일한 임베딩 모델로 벡터화하고, 벡터 데이터베이스에서 가장 유사한 청크들을 검색하여, 그 청크들과 함께 질문을 LLM에 전달하면 LLM이 근거 있는 답변을 생성한다. 이 전체 과정을 이해해야만 벡터 데이터베이스가 왜 중요한지, 임베딩이 무엇인지 맥락 속에서 파악할 수 있다.