한 줄 요약: Anthropic 엔지니어링 블로그 글 "Building effective agents". LLM 시스템을 미리 정한 코드 경로로 움직이는 워크플로와 LLM이 스스로 과정과 도구 사용을 정하는 에이전트로 나누고, 가장 단순한 해법에서 시작해 필요할 때만 복잡도를 올리라고 권한다. 기본 블록(증강 LLM), 워크플로 다섯 가지(프롬프트 체이닝, 라우팅, 병렬화, 오케스트레이터-워커, 평가자-최적화자), 자율 에이전트를 패턴마다 "언제 쓰는가"와 예시로 설명하고, 부록에서 고객지원·코딩 에이전트 사례와 도구 설계(ACI) 요령을 준다.
원본 정보#
- 제목: Building effective agents
- 저자: Erik S., Barry Zhang (Anthropic)
- 발행: 2024-12-19, Anthropic Engineering 블로그
- URL: https://www.anthropic.com/engineering/building-effective-agents (새 창)
- 수집(fetch)일: 2026-10-18
- 성격: 개념·원칙 글. 원본 맨 위에 "이 글이 설명한 도구 지형의 상당 부분이 2024년 12월 이후 바뀌었다"는 안내가 붙어 있고, 현재 접근법은 Claude Managed Agents 글과 문서를 보라고 링크한다.
- 편집자 해석: 본문의 라우팅 예시에 Claude Haiku 4.5와 Claude Sonnet 4.5가 나온다. 이 위키의 다른 원본은 Sonnet 4.5 출시를 2025-09-29 글 시점의 일로 적고 있으므로(효과적인 컨텍스트 엔지니어링), 수집한 본문은 발행 뒤 일부 고쳐진 판일 수 있다. 원본은 고친 날짜를 밝히지 않아 확인 날짜는 발행일로 둔다.
핵심 주장#
- 워크플로와 에이전트는 구조가 다르다. 둘 다 "에이전트형 시스템(agentic systems)"이지만, 워크플로는 LLM과 도구가 미리 정한 코드 경로로 조율되는 시스템이고, 에이전트는 LLM이 자기 과정과 도구 사용을 동적으로 정하며 일하는 방식을 스스로 통제하는 시스템이다. → 워크플로와 에이전트
- 가장 단순한 해법을 찾고, 필요할 때만 복잡도를 올린다. 에이전트형 시스템을 아예 만들지 않는 것이 답일 수도 있다. 에이전트형 시스템은 흔히 지연과 비용을 내주고 더 나은 작업 성능을 얻으므로, 그 맞바꿈이 맞는지 따져야 한다. 많은 애플리케이션에는 검색과 맥락 내 예시로 단일 LLM 호출을 최적화하는 것으로 보통 충분하다. → 에이전트 시스템 패턴 고르기
- 잘 정의된 작업에는 워크플로, 규모 있게 유연성과 모델 주도 판단이 필요하면 에이전트. 워크플로는 예측 가능성과 일관성을 주고, 에이전트는 유연성과 모델 주도 의사결정이 규모 있게 필요할 때 더 나은 선택이다. 에이전트의 자율성은 비용 상승과 오류가 쌓일 가능성을 뜻하므로, 샌드박스 환경에서의 폭넓은 시험과 적절한 가드레일을 권한다. → 에이전트 시스템 패턴 고르기, 권한 모드
- 프레임워크보다 LLM API를 직접 쓰는 것부터 시작한다. 프레임워크는 시작을 쉽게 하지만 밑의 프롬프트와 응답을 가리는 추상화 층을 더해 디버깅을 어렵게 하고, 더 단순한 구성으로 충분할 때도 복잡도를 더하고 싶게 만든다. 프레임워크를 쓴다면 밑의 코드를 이해해야 한다. 밑에서 무슨 일이 일어나는지에 대한 잘못된 가정이 고객 오류의 흔한 원인이다. → 워크플로와 에이전트
- 세 원칙: 단순함, 투명성, 도구 문서화와 시험. 에이전트 설계를 단순하게 유지하고, 에이전트의 계획 단계를 명시적으로 보여 투명성을 우선하고, 철저한 도구 문서화와 시험으로 에이전트-컴퓨터 인터페이스(ACI)를 공들여 만든다. → 워크플로와 에이전트, 시스템 프롬프트·도구·예시 설계
원본의 숫자·사례#
- 지난 1년간 여러 산업에서 LLM 에이전트를 만드는 수십 개 팀과 일했고, 가장 성공한 구현은 복잡한 프레임워크나 전문 라이브러리가 아니라 단순하고 조합 가능한 패턴으로 만들었다.
- 프레임워크 예: Claude Agent SDK, AWS의 Strands Agents SDK, Rivet(드래그 앤 드롭 GUI 워크플로 빌더), Vellum(GUI 워크플로 구축·시험 도구).
- 고객지원: 성공한 해결에만 요금을 받는 사용량 기반 가격 모델로 여러 회사가 이 접근의 실효성을 보였다(원본은 회사 이름과 숫자를 들지 않는다).
- 코딩 에이전트: Anthropic 구현에서 에이전트가 풀 리퀘스트 설명만으로 SWE-bench Verified 벤치마크의 실제 GitHub 이슈를 푼다. 다만 자동 테스트가 기능을 확인해도, 더 넓은 시스템 요구에 맞는지는 사람의 리뷰가 여전히 중요하다.
- SWE-bench용 에이전트를 만들 때 전체 프롬프트보다 도구 최적화에 더 많은 시간을 썼다. 에이전트가 루트 디렉터리 밖으로 옮겨 간 뒤 상대 경로를 쓰는 도구에서 모델이 실수하자, 도구가 항상 절대 경로를 요구하도록 바꿨고 모델은 이 방식을 흠 없이 썼다.