효과적인 AI 에이전트 만들기 — 워크플로 다섯 패턴과 에이전트 레퍼런스

• 들어가며 — 워크플로와 에이전트, 그리고 증강된 LLM
• 워크플로 다섯 가지 패턴
• 자율 에이전트 — 루프, 그리고 언제 꺼내 쓰는가
• 실패 모드 — 과설계, 무한 루프, 비용과 지연
• 프레임워크 — 빠른 시작, 디버깅 비용
• 마치며 — 단순함·투명성·ACI
• 참고 자료

들어가며 — 워크플로와 에이전트, 그리고 증강된 LLM

"에이전트"라는 말이 인플레이션을 겪는 동안, Anthropic의 엔지니어링 가이드 Building Effective Agents는 드물게 차분한 정의부터 시작합니다. 이 글은 그 문서를 실무에서 꺼내 보는 레퍼런스로 정리한 것입니다. 핵심 구분은 하나입니다.

• 워크플로(workflow). LLM과 도구가 사람이 미리 정해 둔 코드 경로("predefined code paths", Anthropic)로 조율되는 시스템입니다. 흐름은 개발자가 고정합니다.
• 에이전트(agent). LLM이 스스로 자기 과정과 도구 사용을 동적으로 지휘하며, 어떻게 작업을 완수할지에 대한 통제권을 쥐는 시스템입니다. 흐름은 모델이 런타임에 정합니다.

이 둘 위에 깔린 단 하나의 조언이 문서 전체를 관통합니다: 가장 정교한 시스템이 아니라 필요에 맞는 올바른 시스템을 만들라는 것. 단순한 프롬프트에서 시작해 종합적인 평가로 다듬고, 더 단순한 해법이 부족할 때만 다단계 에이전트를 더하라고 말합니다.

모든 패턴의 바닥에는 증강된 LLM(augmented LLM) 이 있습니다. 그냥 텍스트를 뱉는 모델이 아니라 세 가지 능력을 얹은 모델입니다.

• 검색(retrieval). 스스로 검색 쿼리를 만들어 필요한 정보를 끌어옵니다.
• 도구(tools). 상황에 맞는 도구를 골라 외부 시스템에 실제 행동을 합니다.
• 메모리(memory). 무엇을 남기고 무엇을 버릴지 판단해 다음 단계로 넘깁니다.

도구 통합은 Model Context Protocol(MCP) 같은 표준으로 붙이길 권합니다. 이 블록이 아래 모든 패턴의 원자 단위입니다.

워크플로 다섯 가지 패턴

먼저 알아야 할 것: 아래 다섯은 모두 워크플로입니다. LLM 호출이 여러 번 등장해도 그 순서와 연결은 코드가 고정합니다. 자율 에이전트는 그다음 절에서 따로 다룹니다.

표는 빠른 참조용이고, 각 패턴이 실제로 어떻게 도는지는 아래에 한 줄씩 더 적습니다.

• 프롬프트 체이닝. 작업을 순차 단계로 쪼개 각 LLM 호출이 앞 단계의 출력을 입력으로 받습니다. 단계 사이에 프로그램적 게이트(형식·조건 검사)를 두어 틀어진 출력이 다음 단계로 새는 것을 막습니다. 지연은 늘지만 호출마다 한 가지에만 집중하므로 정확도가 오릅니다.
• 라우팅. 먼저 입력을 분류한 뒤 전용 프롬프트나 모델로 흘려보냅니다. 관심사가 분리되어 경로별로 따로 최적화할 수 있고, 한 프롬프트에 모든 경우를 욱여넣을 때 생기는 품질 저하를 피합니다.
• 병렬화. 섹셔닝은 서로 독립인 하위 작업을 동시에 돌려 지연을 줄이고, 보팅은 같은 입력을 여러 번 돌려 결과를 모읍니다(다수결·합의). 답변 생성과 안전 점검을 분리하는 가드레일처럼, 한 호출에 섞으면 서로 방해하는 일을 떼어낼 때 특히 유용합니다.
• 오케스트레이터-워커. 중앙 LLM이 문제를 런타임에 하위 작업으로 쪼개 워커에게 위임하고 결과를 종합합니다. 하위 작업의 개수와 형태를 코드가 아니라 모델이 정한다는 점이 병렬화와의 결정적 차이이고, 그래서 이 패턴은 워크플로와 에이전트의 경계에 서 있습니다.
• 이밸류에이터-옵티마이저. 한 LLM이 초안을 만들고 다른 LLM이 평가와 피드백을 주는 루프를 돕니다. 명확한 평가 기준이 있고 반복이 결과를 실제로 개선할 때만 값을 합니다 — 기준이 흐릿하면 루프는 비용만 태웁니다.

마지막으로, 이 다섯은 배타적이지 않습니다. 실무 시스템은 대개 이들을 겹쳐 씁니다 — 라우팅 뒤에 프롬프트 체이닝을 두거나, 오케스트레이터의 워커가 내부에서 병렬화를 부르는 식입니다. 패턴은 레고 블록이지 종교가 아닙니다.

자율 에이전트 — 루프, 그리고 언제 꺼내 쓰는가

자율 에이전트는 화려해 보이지만 구현은 대개 단순합니다. Anthropic의 표현을 빌리면 에이전트는 환경 피드백을 바탕으로 루프 안에서 도구를 쓰는 LLM에 가깝습니다. 매 단계마다 도구 결과나 코드 실행 결과 같은 "그라운드 트루스(ground truth)"를 얻어 스스로 진행 상황을 판단합니다.

에이전트 루프 (개념)
  1. 사람이 목표를 준다 (또는 대화로 범위를 좁힌다)
  2. LLM이 계획하고 도구를 호출한다
  3. 환경이 결과를 돌려준다   = 그라운드 트루스
  4. LLM이 결과를 보고 판단한다: 끝났는가? 아니면 2로 돌아가 반복
  5. 정지 조건: 완료 판정 · 스텝 예산 · 사람 체크포인트

여기서 핵심은 그라운드 트루스입니다. 에이전트를 단순한 챗봇과 가르는 것은, 매 단계 환경에서 오는 실제 신호 — 도구가 성공했는지, 코드가 통과했는지 — 로 자기 판단을 교정한다는 점입니다. 이 피드백 고리가 없으면 그것은 그냥 여러 번 호출되는 프롬프트일 뿐입니다.

언제 워크플로 대신 에이전트를 쓰는가. 잘 정의된 작업이고 예측 가능성과 일관성이 중요하다면 워크플로가 낫습니다. 필요한 단계 수를 예측할 수 없고 고정된 경로를 하드코딩할 수 없을 때 비로소 에이전트가 값을 합니다. 대신 대가가 있습니다 — 에이전트는 "지연과 비용을 더 나은 작업 성능과 맞바꾼다(trade latency and cost for better task performance)"고 문서는 못박습니다. 이 교환이 말이 되는 순간에만 꺼내야 합니다. 빠른 판단 체크리스트:

• 단계 수와 경로를 미리 그릴 수 있는가 → 그렇다면 워크플로.
• 같은 입력에 대해 일관되고 재현 가능한 결과가 중요한가 → 워크플로.
• 필요한 도구와 단계가 입력마다 달라 예측이 불가능한가 → 에이전트.
• 늘어난 지연과 비용을 성능 향상으로 정당화할 수 있는가 → 아니라면 에이전트를 미뤄라.

ACI가 절반이다. 에이전트의 성패는 도구 설계에 크게 달려 있습니다. Anthropic은 이를 에이전트-컴퓨터 인터페이스(agent-computer interface, ACI)라 부르며, 사람에게 API를 문서화하듯 모델에게 도구를 명확히 문서화하고 테스트하라고 강조합니다. 모호한 스키마와 부실한 도구 설명은 에이전트 실패의 가장 흔한 근본 원인입니다.

문서의 부록은 에이전트가 잘 맞는 두 영역을 듭니다. 고객 지원은 대화 흐름을 타면서 외부 정보와 행동(조회·환불 등)이 필요하고, 성공한 해결로 성과를 명확히 측정할 수 있습니다 — 일부 회사는 성공한 해결에만 과금하는 사용량 기반 가격을 쓸 만큼 자신감을 보입니다.

코딩은 해답을 자동 테스트로 검증할 수 있어 특히 잘 맞습니다. 에이전트가 테스트 결과를 피드백 삼아 반복하고, Anthropic은 SWE-bench Verified에서 PR 설명만으로 실제 GitHub 이슈를 푼 사례를 듭니다. 다만 해답이 더 큰 시스템 요구와 맞는지는 여전히 사람의 리뷰가 필요합니다.

실패 모드 — 과설계, 무한 루프, 비용과 지연

레퍼런스가 유용하려면 잘 되는 그림뿐 아니라 자주 깨지는 지점도 적어야 합니다.

• 과설계와 성급한 프레임워크. 첫 수로 무거운 에이전트 프레임워크부터 꺼내는 것이 가장 흔한 실수입니다. 프레임워크는 시작을 쉽게 하지만, 밑에 깔린 프롬프트와 응답을 감추는 추상화 층을 더해 디버깅을 어렵게 만든다고 문서는 경고합니다. LLM API를 직접 쓰는 데서 출발하고, 복잡성은 "그것이 결과를 눈에 띄게 개선할 때만(only when it demonstrably improves outcomes)" 더하십시오.
• 폭주하는 루프. 에이전트는 본질적으로 루프라, 정지 조건이 없으면 같은 실수를 반복하며 토큰과 비용을 태웁니다. 스텝 상한, 타임아웃, 사람 체크포인트를 반드시 넣으세요. 계획 단계를 밖으로 드러내는 투명성이 이런 폭주를 조기에 잡아 줍니다.
• 비용과 지연. 모든 단계가 추가 LLM 호출입니다. 다중 에이전트나 보팅은 토큰을 배로 씁니다. 사용자 대면 지연 예산과 실제로 맞는지 먼저 재보세요 — 성능이 올라도 응답이 느리면 제품에서 쓸 수 없습니다.
• 도구 설계 방치. 앞서 말한 ACI를 프롬프트만큼 정성껏 다루지 않으면, 아무리 좋은 모델도 잘못 설계된 도구 앞에서 헤맵니다.
• 평가 건너뛰기. 에이전트 복잡성을 얹으면서 그것이 단순한 기준선보다 실제로 나은지 재지 않는 것. 문서의 처방은 명확합니다 — 단순한 프롬프트를 종합적 평가로 다듬고, 더 단순한 해법이 부족할 때만 복잡성을 더하라.

프레임워크 — 빠른 시작, 디버깅 비용

문서는 에이전트 프레임워크를 정면으로 다룹니다. Claude Agent SDK 같은 SDK나 Rivet·Vellum 같은 GUI 빌더는 착수의 문턱을 낮춰 주지만, 대가가 있습니다 — 밑에 깔린 프롬프트와 응답을 감추는 추상화 층을 더해, 무엇이 실제로 모델에 들어가고 나오는지 보기 어렵게 만들고 디버깅을 복잡하게 합니다.

그래서 권장은 담백합니다. LLM API를 직접 써서 바닥을 이해한 뒤, 그 추상화가 정확히 무엇을 해 주는지 알고 프레임워크를 도입하라는 것입니다. 프레임워크가 나쁘다는 뜻이 아니라, 밑단을 모른 채 얹은 편의는 문제가 터졌을 때 되레 발목을 잡는다는 뜻입니다.

마치며 — 단순함·투명성·ACI

문서가 제시하는 에이전트 구현의 세 가지 핵심 원칙으로 요약합니다.

• 단순함. 설계를 단순하게 유지하고, 복잡성은 결과가 눈에 띄게 나아질 때만 더합니다.
• 투명성. 에이전트의 계획 단계를 숨기지 말고 명시적으로 드러냅니다.
• ACI. 도구를 충분히 문서화하고 테스트해 에이전트-컴퓨터 인터페이스를 정성껏 만듭니다.

실무에서 이 글이 남기는 교훈은 담백합니다. 대부분의 프로덕션 문제는 단일 LLM 호출이나 한두 개의 워크플로 패턴으로 충분히 풀립니다. 진짜 자율 에이전트가 필요한 순간은 생각보다 드물고, 그 드묾을 인정하는 판단 자체가 좋은 엔지니어링입니다. 결국 성공은 가장 정교한 시스템을 짓는 일이 아니라, 필요에 맞는 올바른 시스템을 고르는 일 — 그 한 문장이 이 레퍼런스의 요지입니다.

참고 자료

• Anthropic — Building Effective Agents (엔지니어링 가이드, 원본)
• Anthropic Cookbook — patterns/agents (다섯 패턴의 최소 구현 코드)
• Model Context Protocol — Introduction (도구 통합 표준)