AI 에이전트 개발을 멈추고, 더 똑똑한 LLM 워크플로우를 써라

• LLM 기반 시스템을 만드는 대부분의 팀 모두가 에이전트(Agent)부터 만들려고 하지만, 대부분은 복잡성, 조정 불가, 디버깅 난이도로 인해 쉽게 무너짐
• 기억, RAG, 도구 사용, 워크플로 제어가 모두 필요한 진짜 에이전트 패턴은 실제론 드물고, 대부분의 문제는 단순 워크플로우(체이닝, 병렬화, 라우팅 등) 로 더 효과적으로 해결 가능
• 현실에서 유용한 5가지 LLM 워크플로 패턴을 먼저 적용할 것을 권장하며, 에이전트는 정말 필요할 때만 신중하게 사용할 것
  • 프롬프트 체이닝, 병렬화, 라우팅, 오케스트레이터-워커, 평가자-최적화
• 에이전트가 필요한 경우도 결국 사람의 관여와 명확한 제어, 관측 가능성(Observability) 이 핵심임

AI 에이전트, 정말 필요한가?

• Netflix, Meta, 미국 공군 등 다양한 엔지니어 및 팀에 LLM 시스템 구축과 관련한 컨설팅 및 교육을 제공하는 Hugo Bowne-Anderson의 통찰
  • 그는 Building LLM Applications for Data Scientists and Software Engineers 라는 교육 과정을 운영함

잘못된 시작: 왜 모두가 에이전트에 집착하는가

• 많은 팀이 LLM 프로젝트 시작 시 에이전트, 메모리, 라우팅, 툴 사용, 캐릭터성 등 복잡한 구조를 우선적으로 도입함
• 실제로 구성해보면, 에이전트 간 협업, 도구 선택, 장기 메모리 등 다양한 부분에서 지속적인 이상 동작과 실패가 빈번하게 발생함
• 예시로 CrewAI 기반 연구 에이전트 프로젝트에서 각 역할(리서처, 요약자, 코디네이터)이 예상된 만큼 협력하지 못하고 속수무책으로 무너짐을 경험함

에이전트란 무엇인가?

• LLM 시스템의 4가지 특성: 메모리, 정보 검색(RAG), 툴 사용, 워크플로 제어
• 마지막 워크플로 제어(LLM이 다음 단계 또는 도구 사용 여부를 직접 결정)는 에이전트적 특성이라 불림
• 실제 대부분의 업무에서는 단순한 워크플로(체이닝, 라우팅 등) 가 더 높은 안정성을 보임

에이전트 대신 써야 할, 실전에서 유용한 LLM 워크플로 패턴

1. 프롬프트 체이닝(Prompt Chaining)

• 설명: 여러 작업을 일련의 단계(체인)로 분할하여, 각 단계를 순차적으로 LLM이 처리하도록 설계함
• 예시: LinkedIn 프로필에서 이름, 직함, 회사 정보를 추출 → 해당 회사의 추가 정보(미션, 채용 등) 추가 → 프로필+회사 정보를 바탕으로 맞춤형 이메일 작성
• 장점: 각 단계가 명확히 분리되어 있어 버그 발생 시 쉽게 원인 추적/수정 가능, 디버깅과 유지보수에 유리함
• 가이드라인:
  • 순차적으로 연결되는 태스크에 적합
  • 한 단계라도 실패하면 전체 체인이 무너질 수 있음
  • 작은 단위의 작업으로 분할하면, 예측 가능한 결과와 쉬운 디버깅 가능

2. 병렬화(Parallelization)

• 설명: 여러 독립적인 작업을 동시에 실행하여 전체 프로세스의 속도를 높임
• 예시: 여러 명의 프로필에서 각각 학력, 경력, 스킬 등 여러 항목을 병렬로 추출해 전체 처리 시간 단축
• 장점: 독립적 데이터 추출/처리 등에서 대규모 데이터에도 효율적, 분산처리 환경과 잘 어울림
• 가이드라인:
  • 각 작업이 상호 독립적이고, 동시에 실행하면 전체 속도가 크게 향상됨
  • 병렬 실행 중 race condition, 타임아웃 등 예외 상황에 주의 필요
  • 대량의 데이터 처리, 여러 소스 동시 분석에 적합

3. 라우팅(Routing)

• 설명: 입력 데이터를 LLM이 분류(classification)해서 각각에 맞는 워크플로로 자동 분기
• 예시: 고객지원 도구에서 입력 내용이 제품 문의, 결제 이슈, 환불 요청인지 분류 후 해당 워크플로로 자동 처리, 유형이 모호하면 기본 핸들러로 전달
• 장점: 입력 유형별로 전문화된 처리 로직을 적용해 다양한 케이스를 깔끔하게 분리
• 가이드라인:
  • 서로 다른 입력 유형/상황별로 별도 처리가 필요할 때 활용
  • 경계 케이스나 예외 상황에서는 라우팅이 실패하거나 빠짐 현상 발생 가능
  • 미분류/예외 상황을 위한 catch-all 핸들러 반드시 설계

4. 오케스트레이터-워커(Orchestrator-Worker)

• 설명: 오케스트레이터 역할의 LLM이 작업을 분해/판단해 워커(실행 LLM)에게 세부 작업을 위임, 전체 흐름과 순서를 직접 제어함
• 예시: 타깃 프로필을 tech/non-tech로 분류 → tech라면 전문 워커에게 이메일 생성 위임, non-tech라면 다른 워커에게 위임
• 장점: 의사결정(분류/판단)과 실행(개별 처리) 분리, 동적 플로우 제어와 확장에 유리
• 가이드라인:
  • 각 태스크마다 전문적 핸들링이 필요한 경우, 복잡한 분기와 단계별 조율에 적합
  • 오케스트레이터가 태스크를 잘못 분해하거나 위임하면 전체 플로우에 오류 발생
  • 로직을 명시적으로 단순하게 유지하고, 위임/순서/종료 조건을 명확히 설계

5. 평가자-최적화(Evaluator-Optimizer)

• 설명: LLM이 결과물을 평가하고(스코어/피드백), 기준에 미달하면 반복적으로 수정/개선하는 구조
• 예시: 이메일 초안 생성 → 평가자가 품질 점수/피드백 → 일정 기준 이상 만족/최대 반복 횟수 초과시 종료, 아니면 다시 수정
• 장점: 최종 산출물의 품질을 목표 수준까지 반복 개선 가능, 정량적 기준 활용에 유리
• 가이드라인:
  • 속도보다 품질이 중요한 상황, 반복 최적화가 필요한 워크플로에 적합
  • 종료 조건이 없으면 무한 반복에 빠질 수 있음
  • 명확한 품질 기준과 반복 제한 설정 필수

에이전트가 정말 필요한 경우

• 사람의 실시간 개입(Human-in-the-loop)이 보장되는 환경에서 에이전트가 진가를 발휘함
  • 예시1: 데이터 사이언스 보조 - SQL 쿼리, 시각화, 데이터 분석 추천 등에서 LLM이 창의적으로 시도하고, 사람이 결과를 판단/수정
  • 예시2: 크리에이티브 파트너 - 문구 아이디어, 헤드라인 제안, 텍스트 구조 추천 등에서 사람의 방향 수정과 품질 심사가 핵심
  • 예시3: 코드 리팩토링 조수 - 디자인 패턴 제안, 에지 케이스 탐지, 코드 최적화 등에서 개발자가 승인/보완
• 특징: 에이전트가 “모든 걸 알아서” 처리하는 게 아니라, 사람이 실시간으로 오류/방향을 잡아주는 환경에서 가장 효과적

에이전트가 적합하지 않은 경우

• 엔터프라이즈·미션 크리티컬 시스템(금융, 의료, 법률 등):
  • 자동화의 신뢰성·결정론적 동작이 중요하므로, LLM 에이전트가 판단하는 구조는 위험
  • 오케스트레이터, 라우팅 등 명확한 제어 패턴을 활용해야 함
• 안정성과 예측 가능성이 중요한 모든 상황
  • 비정상적 사례: 에이전트가 맥락/메모리 없이 도구 선택을 반복적으로 잘못하거나, 분업/조정이 실패해 전체 플로우가 무너지는 문제
• 실무에서 빈번하게 발생하는 에이전트 시스템의 실패 요인
  • 명시적 메모리 시스템 미설계로 맥락 누락
  • 도구 선택 제약 부족(불필요한/잘못된 툴 사용)
  • 자유로운 위임 구조만 의존해 협업 조정 실패

실무 설계 시 교훈

• 에이전트 도입 시에도 “완성도 높은 소프트웨어 시스템” 수준의 설계·관측성·제어 체계가 반드시 필요
• 복잡한 에이전트 프레임워크보다, 관측 가능성(Observability), 명확한 평가 루프, 직접 제어 가능한 구조로 설계하는 것이 더 빠르고 안전함

결론(TL;DR)

• 에이전트는 과대평가/과잉 활용되는 경우가 많음
• 대부분의 실전 과제는 단순 워크플로 패턴이 더 적합
• 에이전트는 “사람이 직접 관여하는” 환경에서 진가 발휘
• 안정적 시스템에선 오히려 위험 요소
• 관측 가능성과 명시적 제어, 반복 평가 구조로 설계할 것

• 복잡한 에이전트 프레임워크 대신, 관측성, 명확한 평가 루프, 직접 제어 가능한 구조로 설계하는 것이 실제로 더 빠르고 안전한 LLM 기반 서비스 개발의 비결임