Anthropic의 효과적인 AI 에이전트 구축 – 실용적인 패턴 및 가이드라인

TL;DR

Anthropic은 LLM 기반 에이전트를 구축하며 얻은 1년간의 경험을 요약한 가이드를 발표했습니다. 이 가이드는 증강 LLM(augmented LLMs), 프롬프트 체이닝(prompt chaining), 라우팅(routing), 병렬화(parallelization), 오케스트레이터-워커(orchestrator-workers), 평가자-최적화기(evaluator-optimizer), 그리고 자율 에이전트(autonomous agents)와 같은 단순하고 결합 가능한 패턴이 무거운 프레임워크보다 성능이 뛰어나다는 점을 보여주며, 각 패턴을 언제 사용해야 하는지와 도구(tools)를 설계하는 방법에 대한 구체적인 조언을 제공합니다.

무엇을 "에이전트"라고 하는가?

*에이전트(Agents)*는 LLM이 어떤 도구를 호출할지, 작업을 어떻게 순서대로 수행할지를 동적으로 결정하며 프로세스에 대한 제어권을 유지하는 시스템입니다. 반면, *워크플로우(workflows)*는 LLM 호출과 도구를 조율하는 고정된 코드 경로를 따릅니다. 이 차이점이 이 가이드의 나머지 내용을 구성하는 틀이 됩니다.

에이전트 시스템을 도입해야 할 때

단순하게 시작하기: 검색(retrieval) 및 인컨텍스트 예시(in-context examples)를 포함한 단일 LLM 호출을 선호하십시오. 결과가 명확하게 개선될 때만 복잡성을 추가하십시오.
트레이드오프 인식: 에이전트는 지연 시간(latency)과 비용을 증가시키지만, 개방형 문제에 대한 작업 성능을 높일 수 있습니다.
패턴 선택하기:
- 워크플로우(Workflows) → 잘 정의된 작업에 대한 예측 가능하고 일관된 처리.
- 에이전트(Agents) → 대규모 환경에서의 유연하고 모델 중심적인 의사 결정.

프레임워크 vs 직접 API 사용

인기 있는 SDK(Claude Agent SDK, Strands Agents SDK, Rivet, Vellum)는 LLM 호출, 도구 파싱 및 체이닝을 추상화하여 진입 장벽을 낮춰줍니다.
주의사항: 추상화는 프롬프트와 응답을 숨길 수 있어 디버깅을 어렵게 만들고 불필요한 복잡성을 조장할 수 있습니다.
권장사항: 가공되지 않은(raw) LLM API로 시작하십시오. 프레임워크를 사용하더라도 기저에 있는 코드에 대한 가시성을 유지하십시오.

핵심 구성 요소: 증강 LLM (augmented LLM)

*증강 LLM(augmented LLM)*은 기본 모델에 검색, 도구 사용 및 메모리를 결합한 것입니다. Anthropic의 모델은 검색 쿼리를 생성하고, 도구를 선택하며, 무엇을 유지할지 결정할 수 있습니다. Model Context Protocol은 서드파티 도구를 통합하기 위한 표준 클라이언트 구현을 제공합니다.

일반적인 워크플로우 패턴

1. 프롬프트 체이닝 (Prompt chaining)

정의: 작업을 순차적인 LLM 호출로 분해하며, 선택적으로 프로그래밍 방식의 게이트(gates)를 삽입합니다.
사용 시점: 추가된 지연 시간보다 높은 정확도가 더 중요한 고정된 하위 작업.
예시: 마케팅 문구 생성 → 번역; 개요 작성 → 검증 → 전체 문서 작성.

2. 라우팅 (Routing)

정의: 입력을 분류하여 전문화된 다운스트림 프롬프트나 도구로 전달합니다.
사용 시점: 맞춤형 처리를 통해 이점을 얻을 수 있는 뚜렷한 카테고리를 가진 작업.
예시: 고객 서비스 문의를 서로 다른 핸들러로 라우팅; 쉬운 질문은 Claude Haiku 4.5로, 어려운 질문은 Claude Sonnet 4.5로 전송.

3. 병렬화 (Parallelization)

변형:
- 섹션화(Sectioning) – 독립적인 하위 작업을 분할하여 동시에 실행.
- 투표(Voting) – 동일한 프롬프트를 여러 번 실행하여 다양한 답변을 수집.
사용 시점: 동시성을 통한 속도 향상 또는 다각적 관점을 통한 신뢰도 향상.
예시: 가드레일(안전 스크리닝을 위한 별도 모델); 여러 프롬프트를 사용한 코드 취약점 검토; 콘텐츠 모더레이션 투표.

4. 오케스트레이터-워커 (Orchestrator-workers)

정의: 중앙 LLM이 동적으로 문제를 하위 작업으로 분해하고, 워커 LLM에 위임한 후 결과를 합성합니다.
사용 시점: 하위 작업을 미리 정의할 수 없는 복잡하고 예측 불가능한 작업(예: 다중 파일 코드 변경, 다중 소스 검색).

5. 평가자-최적화기 (Evaluator-optimizer)

정의: 한 LLM이 출력을 생성하면, 두 번째 LLM이 이를 평가하고 피드백을 제공하여 반복적인 개선 루프를 형성합니다.
사용 시점: 명확한 평가 기준이 존재하고 반복적인 개선이 측정 가능한 가치를 창출할 때.
예시: 미묘한 비평이 포함된 문학 번역; 평가자가 추가 조사가 필요한지 결정하는 다회차 검색.

자율 에이전트 (Autonomous agents)

라이프사이클: 명령 또는 대화형 프롬프트 수신 → 계획 → 루프 내에서 도구 호출 실행 → 선택적으로 인간의 피드백을 위해 일시 중지 → 완료 시 또는 최대 반복 제한 도달 시 종료.
핵심 요구사항:
1. 명확한 문서화가 포함된 견고한 도구 세트(부록 2 참조).
2. 각 도구 호출 후 환경으로부터의 그라운드 트루스(ground-truth) 피드백.
3. 누적되는 오류를 완화하기 위한 가드레일 및 샌드박스 테스트.
사용 시점: 모델의 의사 결정에 대한 신뢰가 허용되는 범위 내에서, 단계 수가 예측 불가능한 개방형 문제.
실제 사례:
- 여러 파일을 편집하여 SWE-bench 작업을 해결하는 코딩 에이전트.
- Claude가 사용자가 지정한 목표를 달성하기 위해 데스크톱을 제어하는 "Computer use" 데모.

패턴의 결합 및 커스텀

제시된 패턴은 엄격한 레시피가 아니라 **구성 요소(building blocks)**입니다. 개발자는 다음을 수행해야 합니다:

각 단계에서 성능을 측정하십시오.
측정 가능한 개선이 있을 때만 복잡성을 추가하십시오.
프롬프트, 도구 정의 및 오케스트레이션 로직을 반복 개선하십시오.

신뢰할 수 있는 에이전트를 위한 핵심 원칙

단순성(Simplicity) – 에이전트 설계를 최소한으로 유지하십시오.
투명성(Transparency) – 로그에 계획 단계와 도구 호출을 노출하십시오.
도구 엔지니어링(Tool engineering) – 명확하고 문서화가 잘 된 도구 인터페이스에 투자하십시오(부록 2 참조).

부록 1 – 실전 에이전트 (요약)

고객 지원: 대화 흐름과 도구 통합(예: 주문 데이터 가져오기, 환불 처리)을 통해 측정 가능한 해결 지표를 가능하게 합니다.
코딩 에이전트: 자동화된 테스트가 객관적인 검증을 제공하며, 에이전트는 테스트 피드백을 사용하여 실제 GitHub 이슈를 해결하기 위해 반복 작업을 수행합니다.

부록 2 – 도구 프롬프트 엔지니어링

설계 팁:
- 모델이 도구 호출을 내보내기 전에 생각할 수 있도록 충분한 토큰을 제공하십시오.
- 모델에게 친숙한 형식을 사용하십시오(예: 과도하게 이스케이프된 JSON보다는 일반 코드).
- 불필요한 포맷팅 오버헤드를 피하십시오(라인 수 추적 금지, 최소한의 이스케이프).
인간-컴퓨터 인터페이스 마인드셋: 도구 사양을 개발자 독스트링(docstrings)처럼 취급하십시오. 예시, 엣지 케이스 및 명확한 매개변수 이름을 포함하십시오.
테스트: Anthropic의 workbench에서 광범위한 예시를 실행하여 오용 패턴을 찾아내십시오.
포카요케(Poka-yoke): 모델이 실수하기 어렵게 인수를 구조화하십시오.
사례 연구: SWE-bench 에이전트에서 상대 경로를 절대 경로로 전환하여 경로 해석 오류를 제거했습니다.

최종 요약

LLM 에이전트의 성공은 가장 정교한 아키텍처를 구축하는 것이 아니라, 적절한 결합 가능한 패턴을 선택하고, 도구 인터페이스를 엄격하게 테스트하며, 결과가 명확하게 개선될 때만 복잡성을 추가하는 것에 달려 있습니다.