AI 에이전트 개발, 이제 그만! 더 똑똑한 LLM 워크플로우로 전환하자 🚦

도입: 에이전트 개발의 유혹과 현실

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

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

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

에이전트 시스템의 실패 사례와 교훈

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

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

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

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

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

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

에이전트란 무엇인가? 그리고 왜 문제가 되는가?

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

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

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

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

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

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

대부분의 문제는 더 단순한 LLM 워크플로우로 해결된다

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

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

🔎 핵심 요약:
"메모리, 위임, 계획이 정말 필요한 게 아니라면,
체이닝이나 라우팅 같은 더 단순한 워크플로우부터 시작하세요."

다섯 가지 LLM 워크플로우 패턴 (에이전트 없이도 충분하다!)

1. 체이닝(Chaining)

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

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

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

2. 병렬화(Parallelization)

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

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

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

3. 라우팅(Routing)

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

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

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

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

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

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

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

5. 평가 루프(Evaluation Loop)

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

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

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

🔎 핵심 요약:
"대부분의 경우, 에이전트가 아니라
더 나은 워크플로우 구조가 필요합니다."

에이전트가 진짜 빛을 발하는 순간은?

에이전트가 유용한 경우는 사람이 직접 개입해 실수를 바로잡을 수 있는, 불안정한 워크플로우입니다.

예를 들어, SQL 쿼리 작성, 시각화, 분석 제안을 에이전트가 하고,
사람이 결과를 평가하고 논리 오류를 수정하는 경우입니다.

"에이전트의 창의성이 엄격한 워크플로우보다 더 뛰어날 때,

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

에이전트가 진가를 발휘합니다."

또한,

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

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

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

에이전트 시스템의 실패 원인과 개선 방법

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

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

🔎 핵심 요약:
"에이전트를 만든다면,
완전한 소프트웨어 시스템처럼 다루세요.

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

결론: 에이전트는 과대평가됐다!

더 단순하고 명확한 워크플로우가 답이다

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

"실제 현업에서는 복잡한 에이전트 프레임워크보다

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

더 깊이 배우고 싶다면?

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

요약 키워드

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

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