AI Sparkup

최신 AI 쉽게 깊게 따라잡기⚡

LangChain·LangGraph·AutoGen 팁 – 에이전트 AI 프레임워크 선택 가이드

LangChain, LangGraph, AutoGen은 에이전트형 AI 시스템을 구축하는 대표 프레임워크 세 가지다. 각각 설계 철학이 다르고 잘 맞는 사용 시나리오가 명확히 다르다. 처음부터 잘못 고르면 6주 후 전면 재작성이 기다린다.

왜 프레임워크 선택이 모델 선택보다 중요한가

모델은 프롬프트에 응답한다. 프레임워크는 작업이 어떻게 실행되는지를 결정한다 — 도구 재시도, 상태 추적, 병렬 실행, 사람 승인 게이트, 루프 처리 등. 에이전트 시스템이 복잡해질수록 프레임워크의 구조적 지원이 없으면 프롬프트가 제어 로직을 대신하게 되어 결국 관리 불가능한 코드가 된다.

흔한 실수 패턴: 데모가 깔끔해 보이는 경량 프레임워크로 시작 → 6주 후 엣지 케이스 처리, 도구 실패 재시도, 병렬 실행 요구가 쌓임 → 핵심 부분 재작성.

LangChain: 선형 워크플로의 출발점

LangChain은 에이전트 AI 프레임워크의 사실상 출발점이다. 생태계가 크고 문서가 풍부해 프로토타입을 빠르게 만들기에 좋다.

잘 맞는 사례

  • RAG 파이프라인: 문서 로드 → 임베딩 → 검색 → 응답
  • 도구 사용 에이전트: 검색, 계산기, API 호출 등 선형 순서의 도구 체인
  • 단순 Q&A 봇: 상태 분기 없이 입력-처리-출력이 순서대로 이어지는 경우
  • 빠른 프로토타입: 개념 검증(PoC) 단계

한계

  • 루프와 분기가 어렵다: 워크플로가 조건 분기·반복을 요구하면 체인 구조가 무너진다
  • 상태 관리가 불명확하다: 단계 간 상태를 전달하는 방식이 명시적이지 않아 디버깅이 어렵다
  • 복잡해지면 프롬프트가 제어 로직을 대신한다: 분기 조건을 프롬프트로 처리하면 신뢰도가 낮아진다

신호: 워크플로에 “만약 A이면 B를 하고, 그렇지 않으면 C를 하되 D 결과가 낮으면 다시 A로” 같은 조건이 생기기 시작하면 LangGraph로 이동할 때다.

LangGraph: 복잡한 상태 기반 워크플로

LangGraph는 LangChain의 대체가 아니라 다음 단계다. 워크플로를 방향 그래프(directed graph)로 모델링한다. 각 노드가 처리 단계이고, 엣지가 전환 조건을 정의한다.

잘 맞는 사례

  • 조건 분기 + 루프가 포함된 워크플로: 분류 → 유형별 처리 경로 분기 → 신뢰도 낮으면 재시도
  • 상태를 명시적으로 추적해야 하는 시스템: 어디까지 진행됐는지, 무엇을 봤는지 타입화된 상태 객체로 관리
  • 사람 승인(HITL) 게이트: 특정 단계에서 인간 검토 후 재개
  • 병렬 처리 후 합성: 지식 검색과 정책 확인을 동시에 실행 → 결과 합치기

LangGraph가 LangChain보다 나은 이유

측면LangChainLangGraph
워크플로 표현선형 체인명시적 그래프
상태 관리암묵적타입화된 상태 객체
분기 처리어색함조건부 엣지로 자연스럽게
루프핵(hack) 필요일급 객체(first-class)
디버깅어려움각 노드 독립 테스트 가능

실전 예: 지원 에스컬레이션 워크플로

티켓 수신 → 분류 → (일반) → 지식 검색 + 정책 확인 [병렬]
                  → (복잡) → 인간 리뷰 게이트 → 전문가 처리
                  → (긴급) → 즉시 에스컬레이션

이 구조를 LangChain 체인으로 표현하면 프롬프트가 제어 로직을 떠맡게 된다. LangGraph에서는 그래프 구조 자체가 명세서가 된다.

AutoGen: 멀티 에이전트 연구·탐색

AutoGen은 여러 에이전트가 대화를 통해 협력하는 패턴을 설계하기 위한 프레임워크다. 대부분의 팀이 여기서 시작하면 안 된다.

잘 맞는 사례

  • 플래너 + 실행자: 한 에이전트가 태스크를 분해하고 다른 에이전트가 수행
  • 코드 작성자 + 리뷰어: 한 에이전트가 코드를 쓰고 다른 에이전트가 검토
  • 논쟁 평가(debate-style): 여러 에이전트가 다른 입장을 취해 결론을 검증
  • 멀티 에이전트 협력 연구: 에이전트 간 협업이 실제로 효과 있는지 탐색

프로덕션에 바로 쓰지 말아야 하는 이유

멀티 에이전트 = 더 똑똑하다는 생각은 흔한 오해다:

  • 실패 지점이 늘어난다: 에이전트가 많을수록 전체 파이프라인 신뢰도가 낮아진다
  • 책임 경계가 불명확하다: 어떤 에이전트의 오류인지 추적이 어렵다
  • 오류가 증폭된다: 한 에이전트의 잘못된 출력이 다음 에이전트의 입력이 된다
  • 테스트와 관찰이 어렵다: 멀티 턴 대화 흐름은 재현과 디버깅이 복잡하다
  • 토큰 비용과 지연이 급증한다: 에이전트 간 대화가 길어질수록 비용이 기하급수적으로 는다

프레임워크 선택 기준

Q1: 워크플로에 조건 분기, 루프, 병렬 처리가 있는가?
  NO → LangChain으로 시작
  YES → LangGraph 사용

Q2: 여러 에이전트가 서로 대화하며 협력해야 하는 실험인가?
  YES → AutoGen 고려 (단, 프로토타입 단계에서만)

Q3: 프로덕션 멀티 에이전트 시스템인가?
  → LangGraph에서 오케스트레이션 + AutoGen 패턴을 선택적으로 차용

비교 요약

LangChainLangGraphAutoGen
적합한 단계PoC, 선형 파이프라인복잡한 프로덕션 워크플로멀티 에이전트 연구
상태 관리암묵적명시적 (타입 안전)대화 기반
학습 곡선낮음중간중간
프로덕션 신뢰성단순 사례에서 높음높음낮음 (복잡성↑)
언제 전환?분기·루프 필요 시멀티 에이전트 탐색 시

참고 자료

관련 문서



AI Sparkup 구독하기

최신 게시물 요약과 더 심층적인 정보를 이메일로 받아 보세요! (무료)