LLM 에이전트 워크플로우 설계 가이드: LangChain vs LangGraph vs Semantic Kernel 완벽 비교

최근 LLM(Large Language Model)의 발전 속도는 그야말로 폭발적입니다. ChatGPT와 같은 챗봇 인터페이스를 통해 누구나 LLM의 강력한 능력을 체감할 수 있게 되면서, 기업들은 이제 단순한 '질의응답'을 넘어선, 복잡하고 다단계적인 '지능형 자동화 시스템'을 구축하는 단계에 접어들었습니다.

하지만 개발자 입장에서 막상 복잡한 워크플로우를 설계하려 하면, 어떤 프레임워크를 써야 할지 막막함을 느끼기 쉽습니다. LangChain, LangGraph, Semantic Kernel... 이름만 들어도 머리가 지끈거리는 이 세 가지 도구들은 대체 무엇이 다르고, 내 프로젝트에는 어떤 것이 맞을까요?

이 글은 단순한 튜토리얼을 넘어, 아키텍처 설계 단계에서 '어떤 문제를 풀 것인가'에 기반하여 최적의 오케스트레이션 프레임워크를 선택하는 명확한 로드맵을 제시하는 것을 목표로 합니다.

1. LLM 애플리케이션, '단순 호출'을 넘어 '지능형 워크플로우'로 진화하다

💡 LLM API 호출의 근본적인 한계: 단일 턴(Single Turn)의 벽

가장 기본적인 LLM API 호출은 마치 '질문 $\rightarrow$ 답변'이라는 단일 턴(Turn)의 대화에 가깝습니다. 모델은 주어진 프롬프트와 컨텍스트를 바탕으로 가장 그럴듯한 단일 답변을 생성합니다.

하지만 실제 비즈니스 로직은 그렇지 않습니다. 예를 들어, "지난달 매출이 저조했던 이유를 분석하고, 다음 달 마케팅 전략을 제안해 줘"라는 요청은 한 번의 호출로 끝나지 않습니다.

1. 정보 검색: (DB 조회 $\rightarrow$ 매출 데이터 추출)
2. 분석: (추출된 데이터와 시장 트렌드를 비교 분석)
3. 추론 및 계획: (원인 분석 $\rightarrow$ 마케팅 전략 초안 작성)
4. 반복 개선: (초안을 바탕으로 가설을 세우고, 가설 검증을 위해 추가 데이터를 요청)

이처럼 여러 단계의 추론, 외부 도구 사용, 그리고 이전 단계의 결과를 다음 단계의 입력으로 재활용하는 과정이 바로 '에이전트 워크플로우(Agent Workflow)'의 핵심입니다.

🧩 에이전트 워크플로우란 무엇인가?

에이전트 워크플로우는 LLM을 단순한 '답변 생성기'가 아닌, **'계획을 세우고, 도구를 사용하며, 목표를 달성하기 위해 스스로 추론하는 자율적인 주체(Agent)'**로 활용하는 구조를 의미합니다. 이를 가능하게 하는 것이 바로 **오케스트레이션(Orchestration)**입니다.

📌 글의 목표: 이 글을 끝까지 읽으시면, LangChain, LangGraph, Semantic Kernel의 기술적 차이점뿐만 아니라, **'내 프로젝트는 어떤 구조의 흐름을 가져야 하는가?'**라는 아키텍처적 질문에 대한 명쾌한 답을 얻게 되실 겁니다.

2. 에이전트 워크플로우의 핵심 개념 이해: 오케스트레이션의 필요성

오케스트레이션이란, 여러 개의 독립적인 컴포넌트(LLM, 벡터 DB, 외부 REST API 등)들을 마치 오케스트라의 연주처럼, 정해진 순서나 조건에 따라 유기적으로 연결하고 제어하는 과정 그 자체를 말합니다.

🧠 핵심 원리 1: 상태(State) 관리의 중요성

가장 중요한 개념입니다. 에이전트가 여러 단계를 거칠 때, 이전 단계에서 얻은 결과물(예: 검색된 문서 조각, 추출된 사용자 ID)은 반드시 다음 단계의 입력으로 사용되어야 합니다. 이 **'이전 상태를 기억하고 다음 단계에 전달하는 메커니즘'**이 바로 상태 관리입니다.

🔄 핵심 원리 2: 순환 구조(Cyclical Loop)와 상태 전이(State Transition)

단순한 선형(Linear) 흐름을 넘어, 에이전트는 스스로 생각하고, "이 정보로는 부족하다. A라는 도구를 다시 사용해서 B를 확인해 봐야겠다"와 같이 되돌아가거나(Loop), 조건에 따라 다른 경로를 선택해야 합니다. 이것이 바로 순환적 흐름(Cyclical Flow)이며, 이를 모델링하는 것이 핵심입니다.

🚀 세 가지 엔진 비교: LangChain vs. LangGraph vs. Semantic Kernel

🛠️ 심층 분석: 왜 LangGraph가 강력한가? (The Power of Graphs)

LangChain의 기본 체인(Chain)은 A $\rightarrow$ B $\rightarrow$ C 와 같은 선형적 흐름에 강합니다. 하지만 실제 지능형 에이전트는 '계획 $\rightarrow$ 실행 $\rightarrow$ 검토 $\rightarrow$ 재계획'과 같은 순환적 의사결정 과정을 거칩니다.

LangGraph는 이 과정을 **상태 머신(State Machine)**의 개념으로 모델링합니다.

1. 상태(State): 현재까지의 모든 정보(사용자 입력, 검색 결과, 중간 결과물)를 하나의 '상태'로 정의합니다.
2. 노드(Node): 상태를 기반으로 실행되는 개별 작업(예: 검색 실행, LLM 호출, 데이터 파싱).
3. 엣지(Edge): 노드 실행 후, 다음 상태로 이동할지, 아니면 같은 노드에서 재실행할지를 조건부로 결정합니다.

예시: "최신 스마트폰 시장 동향을 분석하고, 경쟁사 대비 강점을 3가지 도출해줘."

• LangChain: 검색 $\rightarrow$ 요약 $\rightarrow$ 강점 도출 (단방향)
• LangGraph: (1) 검색 $\rightarrow$ (2) 검색 결과 분석 $\rightarrow$ (3) 강점 도출 시도 $\rightarrow$ (4) 도출된 강점이 충분한가? (조건 검사) $\rightarrow$ (충분하지 않다면) (2)로 돌아가 재검색 $\rightarrow$ (충분하다면) 최종 출력.

이러한 '반복적 검증 및 재계획' 능력이 LangGraph의 핵심 가치입니다.

🎯 결론: 어떤 것을 선택해야 할까?

1. 가장 쉽고 빠르게 MVP를 만들고 싶다면: LangChain (가장 많은 튜토리얼과 컴포넌트가 존재합니다.)
2. 복잡한 '에이전트'의 의사결정, 계획, 반복 검증 로직을 구현하고 싶다면: LangGraph (가장 강력하고 현대적인 접근 방식입니다.)
3. 이미 Microsoft Azure/Graph 생태계에 깊이 종속된 기업 환경이라면: Semantic Kernel (엔터프라이즈 통합에 유리합니다.)

요약하자면, '단순한 파이프라인'은 LangChain으로, '지능적인 자율 에이전트'는 LangGraph로 접근하는 것이 현재 업계의 트렌드입니다.