에이전트 설계 ① — 워크플로 vs 에이전트: 플로차트를 그릴 수 있다면 에이전트가 아니다

새 시리즈다. RAG 실전(11편)에 이어, 이번엔 LLM 에이전트를 실제로 설계하는 법 — 정의와 판단 기준부터 도구·컨텍스트·멀티에이전트·안전·평가·프레임워크까지 11편. 과대광고 대신 숫자와 실패담으로 간다.

정의는 정리됐다

Anthropic의 Building Effective Agents가 만든 구분이 사실상 표준이다: 워크플로는 미리 정의된 코드 경로가 LLM과 도구를 조율하는 것, 에이전트는 LLM이 스스로 과정과 도구 사용을 지시하는 루프. OpenAI 가이드가 같은 결론을 재확인했고, Google ADK는 아예 클래스 타입(LlmAgent vs SequentialAgent/ParallelAgent/LoopAgent)으로 박아 넣었다. 2026년의 정제(Anthropic 후속 글): 실전에서 살아남은 워크플로 패턴은 사실상 셋 — 순차(기본값), 병렬(지연이 병목일 때), 평가자-최적화 루프(초안 품질이 부족할 때).

에이전트의 경제학 — 숫자 세 벌

• 비용 — 단일 에이전트는 일반 챗의 ~4배, 멀티에이전트는 ~15배 토큰(Anthropic 실측). 과제의 가치가 이 배수를 정당화해야 한다.
• 신뢰성 산수 — 스텝당 95% 신뢰성이면 20스텝 성공률은 36%(0.95^20). 99%여도 82%. 프로덕션이 요구하는 99.9%+와의 간극이 곧 "3~5스텝 + 인간 결정 지점" 설계의 근거다.
• 현실 점검 — 가장 엄밀한 공개 Devin 평가(Answer.AI): 실제 과제 20개 중 성공 3개. 킬러는 능력이 아니라 예측 불가능성 — 막힘을 보고하는 대신 불가능한 해법을 며칠씩 판다. Gartner: 에이전틱 AI 프로젝트의 40%+가 2027년까지 취소 예측, 수천 벤더 중 진짜 에이전틱은 ~130개("agent washing"). AutoGPT(★186k)조차 자율 루프를 버리고 스케줄 워크플로 빌더로 피벗했다.

판단 기준 — 한 문장

실행 전에 플로차트를 그릴 수 있으면 워크플로를 만들어라(종종 크론 잡 + LLM 호출 하나면 된다). 플로차트를 그릴 수 없을 때만 — 스텝 수를 예측할 수 없는 열린 문제일 때만 — 에이전트를 만들되, 작고 관찰 가능하고 중단 가능하게. OpenAI의 "언제 에이전트인가" 체크리스트도 같다: 복잡한 의사결정 / 유지보수 불가능한 규칙 더미 / 비정형 데이터 의존 — 셋 다 아니면 결정론적 자동화로 충분. 실무 시스템 대부분은 이분법이 아니라 자율성의 스펙트럼 위 하이브리드다(워크플로 뼈대 + 경계 지어진 에이전틱 구간 — SK DevOcean의 한국어 정리가 좋다).

참고할 실패담 프레임: 12-Factor Agents(★25k) — "프레임워크 루프로 70-80% 품질까진 빨리 가지만, 마지막 다듬기에서 추상화를 역공학하다 결국 다시 짠다." 큰 자율 루프 하나보다 기존 제품 안의 작고 모듈화된 에이전틱 조각들을 배포하라는 것.

한 줄 요약: 에이전트는 기본값이 아니라 최후의 수단이다 — 그리고 그때도 목줄(관찰·중단·승인)을 쥐고 시작한다.

— 에이전트 설계 시리즈 ① / 다음 글: 도구 설계 — 도구 정의는 곧 프롬프트다