Stop Building AI Agents: Use Smarter LLM Workflows Instead

Introduction: agent 개발의 유혹과 현실

This article Hugo라는 LLM(large language model) 시스템 전문가가 수많은 팀을 지도하며 겪은 경험을 바탕으로, AI agent 개발의 한계와 더 효과적인 LLM 활용법을 이야기. Netflix, Meta, 미 공군 등 다양한 조직의 engineer들과 협업해온 He, LLM 기반 시스템을 설계할 때 흔히 저지르는 실수와 그 대안을 실제 사례와 함께 풀어냅니다.

"모두가 agent부터 시작해요. 메모리 시스템을 만들고, 라우팅 로직을 추가하고, 도구 정의와 캐릭터 설정까지 하죠. 뭔가 대단해 보이고, 진짜 진전이 있는 것 같아요.

그런데 모든 게 망가집니다. 그리고 문제가 생기면(항상 생깁니다), 아무도 원인을 모릅니다."

agent 시스템의 실패 사례와 교훈

Hugo는 6개월 전, CrewAI라는 framework로 "리서치 크루"를 만들었습니다.

3명의 agent와 5개의 도구가 완벽하게 협업하는 구조였죠.
하지만 실제로는 다음과 같은 문제가 발생.

"연구원 agent는 웹 스크래퍼를 70%나 무시했고, 요약 agent는 긴 문서를 처리할 때 인용 도구를 완전히 잊어버렸어요.

코디네이터는 작업이 명확하지 않으면 아예 포기해버렸죠.

멋진 계획이었지만, 현실에서는 화려하게 무너졌습니다."

Such 경험을 통해 Hugo는 agent가 필요한 경우는 극히 드물다는 사실을 깨달았습니다.
아래의 플로우차트에서 볼 수 있듯, agent가 필요한 경우는 전체 workflow 중 아주 작은 부분에 불과.

agent란 무엇인가? 그리고 왜 문제가 되는가?

agent란, LLM이 다음과 같은 네 가지 특성을 모두 갖춘 경우를 말.

메모리: LLM이 과거 상호작용을 기억함
정보 검색: RAG(검색 기반 생성) 등으로 맥락을 추가함
도구 사용: 함수나 API에 접근할 수 있음
workflow 제어: LLM의 출력이 어떤 도구를 언제 사용할지 결정함
→ 이 마지막 단계가 바로 agent.

"대부분의 사람들은 LLM이 workflow를 제어하도록 바로 넘어가요.

하지만 사실은, 더 단순한 패턴이 훨씬 잘 작동하는 경우가 많습니다."

agent는 LLM에게 너무 많은 자유를 주기 때문에,

작업 흐름이 미리 정의될 수 없는 매우 동적인 상황이 아니라면
오히려 복잡성과 불안정성만 커집니다.

대부분의 문제는 더 단순한 LLM workflow로 해결된다

Hugo는 수많은 팀에서 반복되는 패턴을 발견.

여러 작업을 automation해야 한다.
agent가 답인 것처럼 보인다.
역할과 메모리를 가진 복잡한 시스템을 만든다.
조정이 생각보다 훨씬 어려워서 모든 게 망가진다.
결국 더 단순한 패턴이 더 나았다는 걸 깨닫는다.

🔎 Key Summary:
"메모리, 위임, 계획이 정말 필요한 게 아니라면,
체이닝이나 라우팅 같은 더 단순한 workflow부터 시작하세요."

다섯 가지 LLM workflow 패턴 (agent 없이도 충분하다!)

1. 체이닝(Chaining)

예시: LinkedIn 프로필에서 맞춤형 이메일 작성
단계:
1. 프로필 텍스트 → 구조화 data 추출
2. 회사 정보 등 맥락 추가
3. 맞춤형 이메일 생성

"작업이 순차적으로 흐를 때 사용하세요.

한 단계가 실패하면 전체 체인이 끊길 수 있지만,
debugging이 쉽고 예측 가능한 흐름."

2. 병렬화(Parallelization)

예시: 여러 프로필에서 data 추출
단계:
1. 각 프로필의 주요 필드를 병렬로 추출(경력, 기술, 학력 등)
2. 모든 작업을 동시에 실행하고 결과를 모음

"독립적인 작업을 빠르게 처리할 때 유용.

단, 레이스 컨디션이나 타임아웃에 주의하세요."

3. 라우팅(Routing)

예시: 입력을 분류해 각기 다른 workflow로 전달
단계:
1. 입력을 분류(예: 임원, 리크루터, 기타)
2. 각 분류에 맞는 핸들러로 처리

"입력 유형에 따라 다른 처리가 필요할 때 사용하세요.

예외 케이스를 위한 기본 경로도 마련하세요."

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

예시: 이메일 생성 시, 업종에 따라 특화된 워커에게 위임
단계:
1. LLM이 업종(IT/비IT 등) 분류
2. 분류 결과에 따라 해당 워커에게 작업 위임

"오케스트레이터가 전체 흐름을 제어하고,
워커가 세부 작업을 수행.

오케스트레이터의 로직은 단순하고 명확하게 유지하세요."

5. 평가 루프(Evaluation Loop)

예시: 이메일 품질을 평가하고 기준 미달 시 반복 개선
단계:
1. 이메일 생성
2. 평가자(Evaluator)가 점수 매김
3. 기준 미달이면 feedback 반영해 재생성(최대 반복 횟수 제한)

"결과물의 품질이 속도보다 중요할 때 사용하세요.

무한 반복을 막기 위해 종료 조건을 명확히 설정하세요."

🔎 Key Summary:
"대부분의 경우, agent가 아니라
더 나은 workflow 구조가 필요."

agent가 진짜 빛을 발하는 순간은?

agent가 유용한 경우는 사람이 직접 개입해 실수를 바로잡을 수 있는, 불안정한 workflow.

For example, SQL 쿼리 작성, 시각화, 분석 제안을 agent가 하고,
사람이 결과를 평가하고 논리 오류를 수정하는 경우.

"agent의 창의성이 엄격한 workflow보다 더 뛰어날 때,

그리고 사람이 중간에 결과를 평가하고 수정할 수 있을 때

agent가 진가를 발휘."

Also,

헤드라인 브레인스토밍, 카피 수정, 구조 제안 등
창의적 아이디어가 필요한 작업에서
사람이 품질을 판단하고 방향을 제시할 때도 agent가 효과적.

agent가 적합하지 않은 경우

엔터프라이즈 automation:
안정적이고 신뢰성 높은 소프트웨어가 필요한 경우,
LLM이 중요한 workflow를 임의로 결정하게 해서는 안 .
오케스트레이터 패턴 등 명확한 제어 구조를 사용하세요.
고위험 결정(금융, 의료, 법률 등):
결정적 로직이 필요한 분야에서는
LLM의 추측에 의존하지 마세요.

agent 시스템의 실패 원인과 개선 방법

Hugo의 CrewAI 사례에서 드러난 주요 실패 포인트와 교훈은 다음과 같습니다.

agent가 맥락을 잘못 가정함
- 긴 문서에서 요약 agent가 인용을 잊음
- 개선: 역할 prompt만이 아니라, 명시적 메모리 시스템을 Introduction
도구 선택 실패
- 연구원 agent가 웹 스크래퍼 대신 일반 검색만 사용
- 개선: 명확한 도구 메뉴로 선택지 제한
조정 실패
- 코디네이터가 작업 범위가 불명확할 때 포기
- 개선: 자유로운 위임 대신 명확한 인수인계 프로토콜 구축

🔎 Key Summary:
"agent를 만든다면,
완전한 소프트웨어 시스템처럼 다루세요.

관찰 가능성(Observability)을 반드시 확보하세요."

Conclusion: agent는 과대평가됐다!

더 단순하고 명확한 workflow가 답이다

❌ agent는 과대평가되고, 과도하게 사용되고 있다
🔁 대부분의 경우, 단순한 패턴이 더 효과적이다
🤝 agent는 사람의 개입이 있는 상황에서 빛난다
⚠️ 안정적인 기업 시스템에는 agent를 쓰지 마라
🧪 관찰 가능성과 명확한 제어 구조를 갖춰라

"실제 현업에서는 복잡한 agent framework보다

단순한 패턴과 직접적인 API 호출이 훨씬 잘 작동."

더 깊이 배우고 싶다면?

LLM 소프트웨어 개발 전 과정을 다루는 강의도 운영 중.
(코드 PAUL 입력 시 $100 할인)
무료 10회 이메일 시리즈도 제공하니,
실전 전략을 단계별로 익히고 싶다면 참고해보세요.

Summary Keywords

agent(Agent), LLM workflow, 체이닝, 병렬화, 라우팅, 오케스트레이터-워커, 평가 루프, 관찰 가능성, 인간 개입, 복잡성, 안정성, 실전 사례

이 글을 통해, AI agent 개발에 집착하기보다, 더 단순하고 명확한 LLM workflow 설계가 실제로 더 효과적임을 꼭 기억하세요!
궁금한 점이 있다면 언제든 질문해 주세요 😊