▲

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

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

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

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

  • 많은 팀이 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 기반 서비스 개발의 비결임
▲
GN⁺ 6시간전  [-]
Hacker News 의견
  • 에이전트 개발이 정말 재미있었음, 하지만 ‘컨텍스트 엔지니어링’에서 심각한 문제가 있음이 명확함. 아무리 컨텍스트 윈도우를 키워도 에이전트가 볼 요소를 큐레이션 해야 되고, 정말 중요한 정보만 골라주는 효과적인 필터가 부족하다고 느낌. 그래서 *.md 파일을 이곳저곳에 흩뿌려두는 방식으로 도와야 하고, 역할 배정도 중요함. 이 *.md 시스템은 일종의 원초적인 기억 시스템이고, 훨씬 더 견고하게 발전시킬 수 있음. 사용자의 상호작용을 바탕으로 실시간으로 프로그램이나 모델(자연어 기반)을 만들어내는 것도 가능하다고 생각함. Claude Code를 이용하면서 테스트 스위트로 에이전트를 ‘조종’하는 게 정말 강력한 강화 학습 메커니즘임을 깨달았고, 이 루프가 대부분 성공적으로 이어져서 앞으로 에이전트를 더 똑똑한 협업자로 만들 수 있는 새로운 아이디어가 나오길 기대함
    • 실제 작업보다 툴과의 싸움에 더 많은 시간을 쓰는 것 같아지는 느낌임
    • 이런 시스템에서 .md 파일을 구성하는 추천 방법이 있는지 궁금함. 사람이 읽기 쉽게 마크업을 많이 넣으면 llm이 처리하는데 문제가 되지 않을까 걱정임. 사람이 읽는 용도와 동일하게 .md 파일을 만들었을 때 llm 사용에 방해가 되지는 않는지 알고 싶음
    • 내가 경험해보니 컨텍스트 관리가 거의 모든 문제의 핵심임. 예를 들어 병렬/재귀적인 작업에 맞는 올바른 컨텍스트 만들기, 일부 단계(예: 이전 응답 편집)는 빼고 수정된 결과만 보여주기, 내가 코멘트를 달았을 때 해당 코멘트로 에이전트가 본인 출력을 인식하게 만들기 등등 실제로 여러가지 상황이 존재함
    • 테스트 스위트로 에이전트를 강화한다는 부분이 흥미로움, 구체적으로 어떤 절차로 진행하는지 좀 더 자세히 설명해줄 수 있는지 궁금함
  • AI 에이전트가 사람들이 LinkedIn에서 말하는 것처럼 대중적으로 쓰일지 아직 확신이 없지만, 그 가능성은 열어두고 있음. 나는 지금 Claude Code, Cursor처럼 AI를 강하게 통제하며 사용함. 이유는 모델이 부족해서가 아니라, 직접 ‘테이스트’와 방향을 자주 제시하고 싶어서임. AI에게 더 많은 자율성을 주는 게 오히려 매력적이지 않음, 내가 개입해야 정체성과 연결감을 느낄 수 있기 때문임. 앞으로 작업 방식이 바뀌거나 새로운 UX가 생긴다면 생각이 변할 수 있지만, 현재로선 AI가 너무 에이전트스러운 것을 원하지 않음
    • 시간이 지나 모델의 행동 방식을 잘 알게 되고, 더 많은/더 나은 컨텍스트와 지침만 주면 사용자의 테이스트와 방향성 요구를 어느 정도 채울 수 있다고 생각하는지 궁금함. 내 경험으로는 잘 만든 프롬프트 엔지니어링만으로도 상당수 워크플로우에서 AI가 원하는 대로 동작하게 할 수 있어서, 자주 개입하지 않아도 될 때가 많음
    • 정확히 공감함. 내가 다른 곳에서도 비슷한 댓글을 남겼는데, ‘공짜 점심은 없다’는 옛말이 여전히 맞다고 생각함. LLM이 인간을 아예 빼고서도 문제를 해결할 수 있다면, 몇 줄의 프롬프트만으로 모두가 똑같은 정교한 시스템을 만들 수 있다는 얘기이고, 그때는 시스템마다 차별점이나 가치가 사라짐. 만약 프롬프트가 새로운 추상화 수준이라면, 예를 들어 Claude에게 “노트 앱을 만들어줘”라고 할 때, 수백만 명의 사람이 동일한 저비용 프롬프트를 입력하게 되고, 이때 프롬프터가 더하는 의미가 도대체 무엇인지 의문임
    • 내가 생각하기엔 시간이 지나면서 이런 각각의 ‘테이스트’ 요소들도 프롬프트로 점점 체계화할 수 있을 것 같음. 예를 들어 하나의 프롬프트로 코드 변경 때 불필요한 가변성을 만들지 않고, 이미 가능하면 immutable로 작성하도록 유도함. 또 하나의 프롬프트로는 쓸모없는 로그 작성 피하기(내가 구체적으로 정의한 방식) 등 맞춤법을 세움. 코드 변경을 리뷰할 때 이 모든 프롬프트들을 개별적으로 실행하여 구조화된 MCP 출력물로 모아봄. 이런 부분들을 코드-에이전트에 적용해 자동화된 리뷰 반복을 실현함. 만약 직접 컨텍스트를 추가해야 하는 상황이 생기면, 새 프롬프트를 만들거나 기존 프롬프트를 확장해서 보강함
  • 신기하게도 경력이 1~2년밖에 안될 것 같은 분야에 ‘권위자’가 등장하는 현상이 재미있음. 마치 ‘2년 된 언어에서 10년 경력자 찾는 밈’의 뒤집은 버전 같음
    • 나는 GPT-3가 나왔을 때부터 ‘ai agent'라 불리는 것을 만들어왔고, 나 말고도 많은 사람이 같은 경험을 했음. 벌써 5년이나 됐는데, 만약 5년 동안도 전문가가 안 탄생하면 그건 이제 전문가 자체가 없는 거라고 생각함. 물론 요즘 ‘에이전트’란 단어가 버즈워드로 변해가서 의미가 퇴색되고 있음
    • 막상 “난 수십 팀과 같이 일했다...”라는 식의 경험담을 읽으면 좀 극적이라고 느껴지는 반응임
  • 핵심 요약: 미리 정의된 솔루션이 있다면 굳이 에이전트를 쓸 필요 없음(예: 기사에 등장한 '패턴’). 보통 프로그래머는 프로그램으로 풀 수 있는 문제에 대해 더 단순하고 신뢰할 수 있는 해결법을 추천함. 미래에는 AI가 정말 똑똑해져 아무 문제나 다 브루트포스로 해결하겠지만, 지금은 복잡성만 늘릴 뿐임. 사람들이 에이전트에 열광하는 이유 중 하나는 대부분 챗 어시스턴트 용도로 LLM을 접했기 때문이라 생각함. 이런 챗 어시스턴트는 정해진 해결법이 없고 상호작용이 복잡한 경우가 많아서 오히려 에이전트가 진가를 발휘함. 예: “가장 가까운 금요일 저녁 찾아서 Bob에게 만날 수 있냐고 문자 보내줘”—이런 건 미리 모든 경우를 프로그래밍하기엔 한계가 있음. 어시스턴트와의 상호작용 방법이 무한에 가까워져서 에이전트가 적합해짐
    • 확인 속도가 스스로 직접 하는 것보다 더 빠를 때 아주 잘 작동함. 다만 나는 검증 없이 AI를 신뢰하기 어렵다는 점이 있음
  • 왜 이렇게 많은 예시가 결국 “스팸을 빠르게, 더 잘 보내는 방법”으로 귀결되는지 의문임
    • 진짜 그게 예시 아니었냐는 생각이 듦. LinkedIn을 크롤링해서 사람 찾아내고, ‘개인화된’ 이메일로 스팸 보내기 식임
    • 바퀴는 결국 기름 없이는 안 굴러간다는 것에 비유할 수 있음
  • 2023년 말 ~ 2024년 초에는 맞는 말이었지만, 이제 mid 2025즈음엔 SOTA LLM을 쓰면 많은 작업에 해당하지 않는다는 생각임. 예전엔 대부분 함수로 LLM을 부르는 식이었지만, 그건 잘못된 도구 선택 때문이기도 했음. 요즘 최상위 LLM(Gemini 2.5 Pro, Claude 4 등)은 정말 똑똑해서 ‘인스트럭션 팔로잉’과 툴 선택 능력이 매우 좋아졌음. 체크리스트 툴이나 delegate 명령, 작업 분할 등은 여전히 필요함. 하지만 지침 만들고 명령어 지정하는 방식—특히 UI 환경에서 툴 커맨드를 쉽게 지정할 수 있다면—이 워크플로우보다는 유연하고 한 단계 높은 추상화임. 시각적 워크플로우도 결국 이는 부서지기 쉽고, 조정하기 까다로운 프로그래밍임. 6~12개월 전엔 이런 게 불가능했지만, LLM이 좋지 않다면 아직 해당하지 않음. 크게 봐서 instruction following과 툴 연동을 잘하는 모델이 소수라서 이런 모델에 에이전트를 적용하는 게 유리함. 앞으로 1~2년 내에 브라우저/컴퓨터 활용 에이전트의 대규모 트렌드가 생길 것임. 이들도 좋은 메모리 시스템과 ‘시연/관찰 모드’를 접목하여 사용자가 UI를 이용하는 과정을 학습(녹화)하게 될 것이고, 인간의 구두/문서 지시로부터 최적화된 프로시저도 학습할 것임
    • 최근 가장 강력한 에이전트 모델(Claude Opus 4 등) 이 등장하면서 상황이 완전히 달라짐. 여전히 좋은 컨텍스트가 필요하지만, 정말 툴에 대한 정확한 선택이 훌륭함
    • 원본 포스팅의 기법들은 대부분 '데이터 플로우 그래프로 문제를 모델링하고 그대로 따라가는 것**임. 모델링을 뛰어넘어 ‘알아서 잘하겠지’ 식으로 접근하면 그건 공학이 아니라 신앙임
  • 지난 3주간 에이전트를 안정적으로 작동시키려고 노력했지만, 결국 훨씬 간단한 패턴으로 전환하게 됨. 지금의 에이전트들은 마치 ‘여섯 손가락 달린 손’처럼 진화 초기 단계로 느껴짐
  • “코디네이터가 작업 정의가 명확하지 않으면 포기한다” 같은 걸 보고 “그럼 코디네이터도 버리고 명령형 로직으로 가라” 결론을 내는 경우, 사실은 프롬프트나 툴 설명을 더 구체적으로 써주고, 중간 요약이나 LLM 컨텍스트 압축 같은 절차를 넣어주면 해결될 문제일 수도 있다고 생각함. 기사에 실제로 사용할 만한 장문의 툴 설명/프롬프트 예시조차 없으면 판단이 쉽지 않음. 직관적으로 작업에 맞는 오케스트레이션을 활용하는 게 답이지만, 실제로는 훨씬 많은 작업에서 에이전트적 오케스트레이션이 효과적으로 쓰일 수 있다고 믿음
  • 나도 100% 동의함. 에이전트는 정말 재밌고 실험하기는 좋지만, 실제 생산성을 높이려면 특정한 워크플로우와 프로세스를 잘 오케스트레이션하고, AI로만 할 수 있는 부분에 집중하는 것이 핵심임. 참고로 ai.intellectronica.net의 AI 워크플로우에 대한 글도 추천함
  • 요즘 자주 보는 현상은, 기존의 워크플로우 오케스트레이션 툴에 LLM을 도입해 훨씬 쉽게 시스템을 빌드한다는 점임. 복잡성의 대부분이 a) 모델 자체(최신 연구소가 쉬운 모델 제공), b) 워크플로우 프로덕션화(워크플로우 툴이 쉽게 해줌)임. 이러한 워크플로우는 기존 업무에 기반을 두기에 가치를 쉽게 인식하고 측정함. 이런 패턴이 많아져서 Airflow(아주 인기 있는 워크플로우 툴)용으로 아예 SDK를 패키징하여 공개함.
    https://github.com/astronomer/airflow-ai-sdk
답변달기