이 글은 Anthropic 엔지니어링 블로그에 2024년 12월 19일 게재된 **“Building Effective Agents”**를 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/building-effective-agents
이 글이 중요한 이유 #
Anthropic은 수십 개의 팀과 함께 다양한 산업에서 LLM 에이전트를 구축해왔습니다. 그 경험에서 나온 결론이 이 글입니다.
놀라운 점은, 가장 성공적인 구현들은 복잡한 프레임워크를 쓰지 않았다는 것입니다. 대신 단순하고 조합 가능한 패턴을 사용했습니다. AI 시대에 “더 복잡한 것이 더 좋다"는 통념을 정면으로 반박하는 내용이에요.
에이전트 시스템이란 무엇인가 #
먼저 용어부터 정리합니다. Anthropic은 에이전트 시스템을 두 가지로 구분합니다.
**워크플로우(Workflow)**는 LLM과 도구가 미리 정해진 코드 경로를 따라 실행되는 시스템입니다. 순서가 정해져 있고, 예측 가능합니다.
**에이전트(Agent)**는 LLM이 스스로 다음 행동을 결정하고, 도구를 동적으로 선택하며, 환경 피드백에 따라 루프를 반복하는 시스템입니다. 훨씬 유연하지만, 그만큼 예측하기 어렵습니다.
워크플로우: 입력 → 단계1 → 단계2 → 단계3 → 출력 (경로 고정)
에이전트: 입력 → LLM 판단 → 도구 선택 → 결과 확인 → 다시 판단 → ... (경로 유동)중요한 것은 둘 중 어느 것이 더 좋은가가 아니라, 언제 무엇을 써야 하는가입니다.
언제 에이전트를 써야 하는가 #
에이전트 시스템에는 트레이드오프가 있습니다.
| 워크플로우 | 에이전트 | |
|---|---|---|
| 속도 | 빠름 | 느림 |
| 비용 | 낮음 | 높음 |
| 예측 가능성 | 높음 | 낮음 |
| 유연성 | 낮음 | 높음 |
| 적합한 경우 | 잘 정의된 반복 작업 | 복잡하고 유동적인 작업 |
Anthropic의 핵심 조언은 간단합니다. 항상 가장 단순한 것부터 시작하세요. 에이전트가 필요하다고 느껴질 때도, 먼저 워크플로우로 해결할 수 없는지 먼저 확인하세요.
7가지 핵심 패턴 #
Anthropic이 정리한 에이전트 시스템의 빌딩 블록입니다. 이 패턴들을 조합하면 대부분의 실무 문제를 해결할 수 있습니다.
패턴 1. Augmented LLM (기반) #
모든 것의 기초입니다. LLM에 세 가지를 붙여줍니다.
LLM + 검색(Retrieval) + 도구(Tools) + 메모리(Memory)검색은 RAG처럼 외부 지식을 가져오는 것, 도구는 계산기나 웹 검색처럼 LLM이 직접 할 수 없는 작업을 실행하는 것, 메모리는 대화 내용을 기억하는 것입니다. Anthropic은 외부 도구 연동에 MCP(Model Context Protocol) 를 추천합니다.
패턴 2. Prompt Chaining (프롬프트 체이닝) #
복잡한 작업을 여러 단계로 쪼개서 순서대로 실행하는 방식입니다.
마케팅 카피 작성 → 품질 검토 → 한국어로 번역 → 최종 검토각 단계에서 프로그래밍 방식으로 검사(Gate)를 추가할 수 있어서, 앞 단계가 실패하면 다음 단계로 넘어가지 않습니다. 예측 가능하고 디버깅이 쉽습니다.
적합한 경우: 고정된 하위 작업으로 분해할 수 있는 모든 작업
패턴 3. Routing (라우팅) #
입력을 분류하고, 분류에 따라 적합한 처리 경로로 보내는 방식입니다.
고객 문의 → 분류 → "환불 요청" → 환불 처리 모듈
→ "기술 문의" → 기술 지원 모듈
→ "일반 질문" → FAQ 모듈모든 입력을 하나의 방식으로 처리하지 않고, 문제의 성격에 맞는 전문화된 처리를 연결할 수 있습니다. 복잡도에 따라 성능이 다른 모델을 연결하는 것도 가능합니다(비용 최적화).
적합한 경우: 고객 서비스, 다양한 유형의 요청을 처리하는 시스템
패턴 4. Parallelization (병렬화) #
두 가지 방식이 있습니다.
섹셔닝(Sectioning): 독립적인 하위 작업을 동시에 처리합니다.
긴 문서 → [섹션1 분석] [섹션2 분석] [섹션3 분석] → 결과 합산
(동시에 실행)보팅(Voting): 동일한 작업을 여러 번 실행해서 다양한 결과를 얻습니다.
코드 검토 → [검토1] [검토2] [검토3] → 다수결 또는 앙상블적합한 경우: 독립적으로 처리 가능한 대용량 작업, 정확도가 중요한 판단 작업
패턴 5. Orchestrator-Workers (오케스트레이터-워커) #
중앙 LLM(오케스트레이터)이 전체 계획을 세우고, 하위 LLM들(워커)에게 작업을 배분합니다.
오케스트레이터: "이 기능을 구현하려면 3개 파일을 수정해야 해"
↓
워커1: auth.py 수정
워커2: api.py 수정
워커3: tests.py 수정
↓
오케스트레이터: 결과 통합 및 검증적합한 경우: 미리 어떤 하위 작업이 필요한지 예측하기 어려운 복잡한 작업, 코딩처럼 여러 파일에 걸쳐 변경이 필요한 작업
패턴 6. Evaluator-Optimizer (평가자-최적화) #
한 LLM이 결과물을 만들면, 다른 LLM이 평가하고 피드백을 주는 루프입니다.
생성자 LLM → 초안 작성
↓
평가자 LLM → "논리적 오류 있음, 3번 항목 수정 필요"
↓
생성자 LLM → 수정
↓
평가자 LLM → "통과"
↓
최종 결과물적합한 경우: 명확한 평가 기준이 있는 작업, 반복 개선이 의미 있는 작업(번역 품질, 코드 정확도 등)
패턴 7. Autonomous Agents (자율 에이전트) #
가장 고도화된 패턴입니다. LLM이 환경을 인식하고, 도구를 선택하며, 결과를 보고 다음 행동을 결정하는 루프를 스스로 반복합니다.
목표 설정
↓
현재 상태 파악 → 도구 선택 → 실행 → 결과 확인
↑___________________________________|
(목표 달성까지 반복)강력하지만 그만큼 신중하게 사용해야 합니다. Anthropic은 반드시 샌드박스 환경에서 충분히 테스트하고, 적절한 가드레일을 설치할 것을 권고합니다.
도구 설계의 핵심: ACI #
Anthropic은 ACI(Agent-Computer Interface) 설계에 HCI(Human-Computer Interface) 설계만큼의 투자가 필요하다고 강조합니다.
SWE-bench 개발 시 팀이 발견한 사례가 인상적입니다. 모델이 상대 경로를 사용할 때 파일 경로 오류를 자주 냈는데, 절대 경로만 허용하도록 도구를 수정하자 오류가 사라졌습니다. 프롬프트를 수정한 게 아니라, 도구 자체를 수정한 거예요.
좋은 도구 설계 원칙:
- 모델이 추론할 충분한 공간(토큰)을 제공할 것
- 인터넷에서 자연스럽게 나타나는 형식에 가깝게 유지할 것
- 복잡한 포맷(정확한 카운트, 이스케이프 처리 등)은 피할 것
- 충분한 예시와 엣지 케이스가 포함된 문서를 작성할 것
- 실수를 원천 차단하는 방향으로 설계할 것 (Poka-yoke)
핵심 결론 #
“성공은 가장 정교한 시스템을 만드는 것이 아니다. 나에게 맞는 올바른 시스템을 만드는 것이다.”
Anthropic이 정리한 성공 공식:
1. 단순한 프롬프트부터 시작
2. 포괄적인 평가로 최적화
3. 단순한 방법이 명확히 부족할 때만 복잡성 추가많은 팀이 처음부터 에이전트를 만들려 합니다. 하지만 실제로 필요한 건 잘 설계된 프롬프트 체이닝 하나인 경우가 많습니다.
실무 적용 방법 #
지금 당장 적용할 수 있는 것 #
패턴 선택 기준표 만들기: 새로운 자동화 과제가 생길 때마다 아래 질문을 먼저 해보세요.
단계가 고정되어 있나? → Prompt Chaining
입력 유형이 다양한가? → Routing
독립적으로 처리 가능한가? → Parallelization
평가 기준이 명확한가? → Evaluator-Optimizer
위 모두 해당 없는 복잡한 작업? → Autonomous Agent (최후 수단)도구보다 프롬프트 먼저: 복잡한 에이전트 프레임워크 도입 전에, 프롬프트 개선만으로 얼마나 해결되는지 먼저 확인하세요.
ACI에 투자하기: AI가 사용하는 도구의 인터페이스를 사람이 쓰는 UI처럼 섬세하게 설계하세요. 절대 경로 강제, 명확한 파라미터 명명, 풍부한 예시가 큰 차이를 만듭니다.
우리 파이프라인에 적용한다면 #
현재 구축 중인 Anthropic 블로그 수집 → 분석 → 발행 파이프라인은 이 글의 Prompt Chaining 패턴 그 자체입니다.
수집 (12_fetch_article.py)
↓ [Gate: 상태 코드 200 확인]
분석 (Claude)
↓ [Gate: 마크다운 형식 검증]
발행 (git push)
↓ [Gate: 배포 로그 확인]
완료나중에 이 파이프라인을 자동화할 때, Evaluator-Optimizer 패턴을 추가하면 글 품질을 자동으로 검증하는 단계를 넣을 수 있습니다.
Anthropic 엔지니어링 블로그를 읽고 정리합니다.