# Anthropic에서 말하는 성공적인 AI 에이전트 설계 원칙 [번역글]

> Clean Markdown view of GeekNews topic #22607. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=22607](https://news.hada.io/topic?id=22607)
- GeekNews Markdown: [https://news.hada.io/topic/22607.md](https://news.hada.io/topic/22607.md)
- Type: news
- Author: [ashbyash](https://news.hada.io/@ashbyash)
- Published: 2025-08-19T23:45:38+09:00
- Updated: 2025-08-19T23:45:38+09:00
- Original source: [blogbyash.com](https://blogbyash.com/translation/building-effective-agents/)
- Points: 37
- Comments: 4

## Summary

Anthropic 팀은 **LLM/AI 에이전트 설계**에서 **단순함**을 최우선으로 두고, 필요할 때만 **복잡성**을 추가하는 것이 성공의 핵심임을 강조합니다. 워크플로우와 에이전트 패턴, 프롬프트 체이닝, 라우팅, 병렬화 등 다양한 **설계 패턴**들은 실제 **비즈니스 목적**에 따라 조합 및 테스트하며 적용해야 하며, 프레임워크 도입 전에는 반드시 LLM API를 직접 다뤄보고 **깊이 이해**하는 과정이 필요합니다. **실전 적용**에서는 챗봇 고객지원 자동화, 반복적인 **코딩 업무 최적화** 등 사례가 늘고 있으며, 모든 도구와 인터페이스는 명확하게 문서화하고 테스트해야 예측 가능한 결과를 얻을 수 있습니다.

## Topic Body

> # TL;DR  
>  
> - LLM/AI 에이전트 구축은  
>   - 항상 단순함을 기본 원칙으로, 필요할 때만 복잡성을 추가"  
>   - "프레임워크는 깊이 이해하고 도입", "워크플로우·에이전트 패턴(체이닝, 라우팅, 병렬화, 평가자-최적화자 등)을 실제 환경과 목적에 맞게 조합 및 테스트하며, 도구(API) 설계와 문서화, 테스트를 꼼꼼히 할 것".  
  
  
### 1. **성공적인 LLM 에이전트의 설계 원칙**  
   - **단순함에 집중**: 성공적인 구현들은 복잡한 프레임워크에 의존하기보다, 단순하고 조립형(compoundable) 패턴을 활용하는 경향이 강함.  
   - **필요할 때만 복잡성 추가**: 기본 구조는 최대한 단순하게 설계하되, 반드시 필요할 때에만 복잡성을 도입하는 것이 효율적임.  
   - (원문: "가장 성공적인 구현이 특수한 라이브러리나 복잡한 프레임워크에 의존하지 않았다... 단순하면서도 조립식으로 결합 가능한 패턴을 기반으로 구축되었죠.")  
  
### 2. **워크플로우 VS 에이전트 개념 구분**  
   - **워크플로우(Workflows)**: LLM과 도구가 사전에 정의된 루트(코드 경로)를 따라 처리.  
   - **에이전트(Agents)**: LLM이 자체적으로 작업과 도구 사용을 동적으로 관리(의사결정 주체가 LLM).  
   - (원문: "워크플로우는 LLM과 도구가 사전 정의된 코드 경로에 따라 조율... 에이전트는 LLM이 자신의 과정과 도구 사용 방식을 동적으로 지시")  
  
### 3. **에이전트 도입 판단 기준**  
   - **단순한 방법 → 필요시 점진적 복잡화**: 처음엔 단순한 LLM 호출, 검색 등으로 시작해보고 부족하다면 점진적으로 Workflows/Agents 도입.  
   - **예측 가능성/일관성이 중요**→ 워크플로우 활용 적합  
   - **대규모 유연성·모델 주도 의사결정** 필요→ 에이전트가 더 적합  
  
### 4. **프레임워크 도입 원칙**  
   - LangGraph, Bedrock, Rivet, Vellum 등 다양한 도구/프레임워크가 있으나,  
   - **직접 LLM API 활용부터 출발**하고, 필요할 때만 프레임워크 도입 권장.  
   - 프레임워크 쓸 땐 내부 동작에 대한 **깊은 이해 필수** (추상화로 인해 문제 해결 어려워질 수 있음)  
   - (원문: "개발자들이 우선 LLM API를 직접 사용하는 방법부터 시작할 것을 권장")  
  
### 5. **실전 패턴별 워크플로우 및 예시**  
   - **확장된 LLM (Augmented LLM)**: 검색, 도구연결, 메모리 등 빌트인 확장기능 추가 (구체적 인터페이스 설계와 문서화 중요)  
   - **프롬프트 체이닝(Prompt Chaining)**: 하나의 과제를 여러 LLM 호출(단계)로 나눠 명확성과 정확성 확보.  
     - 예: 마케팅 카피 생성→번역, 문서 초안→검토→작성  
   - **라우팅(Routing)**: 입력 분류 후 그에 맞는 처리·도구로 분기  
     - 예: 고객 문의 유형별 라우팅, 어려운 질문만 고성능 모델로 전달  
   - **병렬화(Parallelization)**:  
     - **섹셔닝(Sectioning)**: 작업을 여러 서브태스크로 쪼개 동시에 처리  
     - **보팅(Voting)**: 똑같은 작업을 여러 번 시도해 최선의 결과를 결정  
     - 예: 코드 취약점 검토, LLM 평가 자동화  
   - **오케스트레이터-워커(Orchestrator-Workers)**: 마스터 에이전트가 하위 작업을 분배·통합.  
     - 예: 복잡한 코딩 작업에서 필요한 부분만 실시간 분배, 여러 데이터 수집/통합  
   - **평가자-최적화자(Evaluator-Optimizer)**: 한 LLM이 답을 만들고, 다른 LLM이 해당 답을 평가·피드백해 개선 반복  
     - 예: 번역 결과 반복 개선, 복합적인 정보 수집  
  
### 6. **실제 산업 적용 사례**  
   - **고객지원**: 챗봇+도구 통합, 고객 데이터/주문/환불 작업 자동화, 성공 여부는 '문제해결' 기준으로 명확. 실제 Usage-based 요금 적용 등 기업 레퍼런스.  
   - **코딩 에이전트**: 자동 테스트 피드백 기반 반복·개선, SWE-bench 등에서 실증. 문제 영역과 결과 품질이 명확히 측정가능. 다만, 항상 최종 검토는 인간개입 필요함.  
  
### 7. **도구 프롬프트 엔지니어링(부록2) 팁**  
   - **LLM이 편하게 쓸 수 있는 포맷**과 충분한 토큰 할당 권장  
   - **도구 설명(usage, 예시, 에지케이스, 경계설정 등) 명확하게**  
   - 실제 모델 활용 양상을 **테스트⇒ 개선**(워크벤치 등 이용)  
   - **사소한 실수도 방지**할 수 있는 poka-yoke 방식 설계  
   - (원문: "좋은 도구 정의에는 사용 예시, 에지 케이스, 입력 형식 요구사항, 그리고 다른 도구와의 명확한 경계가 포함되는 것이 좋습니다.")  
  
### 8. **핵심 원칙**  
   - **단순함 유지** (Keep it simple)  
   - **에이전트 계획과정(Planning)의 투명성** 필수  
   - **도구·인터페이스의 명확한 문서화와 테스트**  
   - 프레임워크는 초기 속도에 좋지만, **추상화는 최소화** 및 직접 제어 권장

## Comments



### Comment 42674

- Author: kaydash
- Created: 2025-08-20T08:45:48+09:00
- Points: 1

예측 가능성/일관성이 중요→ 워크플로우 활용 적합  
대규모 유연성·모델 주도 의사결정 필요→ 에이전트가 더 적합

### Comment 42715

- Author: ashbyash
- Created: 2025-08-20T23:16:41+09:00
- Points: 1
- Parent comment: 42674
- Depth: 1

글 디테일하게 보시고 핵심을 정확히 파악하셨네요..!

### Comment 42672

- Author: ummjoonsick
- Created: 2025-08-20T08:42:16+09:00
- Points: 1

좋군요 좋다구요 으하하

### Comment 42714

- Author: ashbyash
- Created: 2025-08-20T23:16:22+09:00
- Points: 1
- Parent comment: 42672
- Depth: 1

글 좋게 봐주셔서 감사합니다 :)