효과적인 AI 에이전트 구축하기 (Anthropic)

1. 서론: 단순함이 강력하다 ✨

Anthropic는 지난 1년간 다양한 산업의 수십 개 팀과 함께 대형 언어 모델(LLM) 에이전트를 구축해왔어요. 그 과정에서 가장 성공적인 사례들은 복잡한 프레임워크나 특수 라이브러리 대신, 단순하고 조합 가능한 패턴을 활용했다는 공통점이 있었습니다.

"가장 성공적인 구현은 복잡한 프레임워크를 쓰지 않았습니다. 오히려 단순하고 조합 가능한 패턴을 사용했습니다."

이 글에서는 Anthropic가 고객과 직접 에이전트를 만들며 얻은 실전 노하우와, 개발자들이 효과적인 에이전트를 만들 때 참고할 수 있는 실용적인 조언을 공유합니다.

2. 에이전트란 무엇인가? 🤖

에이전트(Agent)는 여러 방식으로 정의될 수 있어요.

어떤 고객은 완전히 자율적으로 동작하며, 다양한 도구를 사용해 복잡한 작업을 수행하는 시스템을 에이전트라 부릅니다.
또 다른 고객은 정해진 워크플로우를 따르는, 좀 더 규범적인 구현을 에이전트라 부르기도 하죠.

Anthropic는 이 모든 변형을 에이전틱 시스템(agentic systems)으로 분류하지만, 워크플로우(workflows)와 에이전트(agents)를 다음과 같이 구분합니다:

워크플로우: LLM과 도구가 미리 정해진 코드 경로로 오케스트레이션되는 시스템
에이전트: LLM이 스스로 프로세스와 도구 사용을 동적으로 결정하며, 작업 수행 방식을 직접 통제하는 시스템

"워크플로우는 미리 정해진 경로를 따르지만, 에이전트는 스스로 과정을 설계하고 도구를 사용합니다."

3. 언제 에이전트를 써야 할까? 언제 피해야 할까? 🤔

LLM을 활용한 앱을 만들 때는 가장 단순한 해결책을 먼저 찾고, 필요할 때만 복잡성을 높이는 것이 좋아요.
에이전틱 시스템은 지연(latency)과 비용(cost)을 더 들이지만, 작업 성능을 높여줍니다. 이 트레이드오프가 합리적인지 꼭 고민해야 합니다.

워크플로우: 예측 가능하고 일관된 결과가 필요한, 잘 정의된 작업에 적합
에이전트: 대규모로 유연성과 모델 주도 의사결정이 필요한 경우에 적합

"대부분의 경우, 단일 LLM 호출에 검색(retrieval)과 인컨텍스트 예시만 추가해도 충분합니다."

4. 프레임워크, 언제 어떻게 쓸까? 🛠️

에이전틱 시스템을 쉽게 구현할 수 있는 프레임워크들이 많아요.

LangGraph (LangChain)
Amazon Bedrock의 AI Agent 프레임워크
Rivet (드래그 앤 드롭 GUI LLM 워크플로우 빌더)
Vellum (복잡한 워크플로우 구축 및 테스트용 GUI 툴)

이런 프레임워크는 LLM 호출, 도구 정의/파싱, 호출 체이닝 등 저수준 작업을 쉽게 만들어줍니다.
하지만 추상화 레이어가 늘어나면, 실제 프롬프트와 응답이 가려져 디버깅이 어려워질 수 있고,
불필요하게 복잡성을 추가하게 만들 수도 있습니다.

"프레임워크를 쓸 때는 반드시 내부 동작을 이해하세요. 내부를 잘못 가정하는 것이 고객 오류의 흔한 원인입니다."

팁:
가능하면 LLM API를 직접 사용해보세요. 많은 패턴이 몇 줄의 코드로 구현됩니다.
프레임워크를 쓴다면, 반드시 내부 코드를 이해하고 사용하세요.

5. 에이전틱 시스템의 빌딩 블록과 워크플로우 패턴 🧩

5-1. 기본 빌딩 블록: 확장된 LLM (Augmented LLM)

에이전틱 시스템의 핵심은 검색, 도구, 메모리 등으로 확장된 LLM입니다.
이런 LLM은 스스로 검색 쿼리를 만들고, 적절한 도구를 선택하며, 어떤 정보를 기억할지 결정할 수 있습니다.

"핵심은, 이런 확장 기능을 내 사용 사례에 맞게 맞추고, LLM이 쉽게 쓸 수 있도록 잘 문서화된 인터페이스를 제공하는 것입니다."

실전 팁:
Anthropic의 Model Context Protocol을 활용하면,
간단한 클라이언트 구현만으로 다양한 서드파티 도구와 연동할 수 있습니다.

5-2. 워크플로우 패턴

(1) 프롬프트 체이닝 (Prompt Chaining)

정의: 작업을 여러 단계로 쪼개고, 각 단계의 LLM 호출이 이전 단계의 출력을 받아 처리
장점: 각 LLM 호출이 더 쉬운 작업을 하게 되어, 정확도가 높아짐 (대신 지연은 늘어남)
예시:
- 마케팅 문구 생성 → 번역
- 문서 개요 작성 → 기준 충족 여부 확인 → 본문 작성

"프롬프트 체이닝은 작업을 고정된 하위 작업으로 깔끔하게 나눌 수 있을 때 이상적입니다."

(2) 라우팅 (Routing)

정의: 입력을 분류해, 특화된 후속 작업으로 보냄
장점: 입력 유형별로 최적화된 프롬프트/도구 사용 가능
예시:
- 고객 문의(일반, 환불, 기술지원 등)를 각기 다른 프로세스/도구로 분기
- 쉬운 질문은 저렴한 모델(Claude 3.5 Haiku), 어려운 질문은 고성능 모델(Claude 3.5 Sonnet)로 분기

"라우팅은 입력이 명확히 구분되는 복잡한 작업에 효과적입니다."

(3) 병렬화 (Parallelization)

정의: 여러 LLM이 동시에 작업을 처리하고, 결과를 합침
변형:
- 섹셔닝(Sectioning): 독립적인 하위 작업을 병렬로 처리
- 투표(Voting): 동일 작업을 여러 번 실행해 다양한 결과를 얻고, 집계
예시:
- 한 모델이 사용자 질문을 처리, 다른 모델이 부적절한 내용 필터링 (섹셔닝)
- 코드 취약점 검토를 여러 프롬프트로 실행, 문제 발견 시 플래그 (투표)

"병렬화는 속도가 중요하거나, 다양한 관점/시도가 필요할 때 유용합니다."

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

정의: 중앙 LLM(오케스트레이터)이 작업을 동적으로 쪼개고, 워커 LLM에 분배 후 결과를 종합
장점: 사전에 하위 작업을 예측할 수 없는 복잡한 작업에 적합
예시:
- 여러 파일을 동시에 수정해야 하는 코딩 작업
- 다양한 소스에서 정보를 수집/분석하는 검색 작업

"오케스트레이터-워커 패턴은 유연성이 핵심입니다. 하위 작업이 입력에 따라 동적으로 결정됩니다."

(5) 평가자-최적화자 (Evaluator-Optimizer)

정의: 한 LLM이 결과를 생성, 다른 LLM이 평가/피드백을 주고, 이를 반복
장점: 명확한 평가 기준이 있고, 반복 개선이 가치 있을 때 효과적
예시:
- 문학 번역에서 미묘한 뉘앙스 개선
- 복잡한 검색 작업에서 반복적으로 정보 수집/분석

"이 패턴은 인간 작가가 글을 다듬는 과정과 유사합니다."

5-3. 에이전트 (Agents)

LLM이 복잡한 입력 이해, 추론/계획, 도구 사용, 오류 복구 등에서 성숙해지면서,
에이전트는 실제 서비스에 점점 더 많이 등장하고 있습니다.

작동 방식:
1. 사용자 명령 또는 대화로 시작
2. 작업이 명확해지면, 에이전트가 독립적으로 계획/실행
3. 필요시 중간에 사용자 피드백 요청
4. 각 단계에서 환경(도구 호출 결과, 코드 실행 등)에서 "현실 정보(ground truth)"를 얻어 진행 상황 평가
5. 완료 또는 중단 조건(예: 반복 횟수 제한)에서 종료

"에이전트는 도구를 활용해 환경 피드백을 받고, 루프를 돌며 작업을 완수합니다. 도구 설계와 문서화가 매우 중요합니다."

언제 사용?
- 필요한 단계 수를 예측할 수 없고, 고정 경로로 하드코딩할 수 없는 개방형 문제에 적합
- LLM이 여러 번 독립적으로 판단/실행해야 하는 신뢰 환경에서 이상적
주의:
- 비용이 높고, 오류가 누적될 수 있음
- 샌드박스 환경에서 충분히 테스트하고, 적절한 가드레일을 두세요
예시:
- 여러 파일을 수정하는 코딩 에이전트 (SWE-bench 작업)
- Claude가 컴퓨터를 사용해 작업을 수행하는 데모 (computer use reference)

6. 패턴의 조합과 커스터마이징 🧬

이 빌딩 블록과 워크플로우는 처방이 아니라, 조합 가능한 패턴입니다.
각 사용 사례에 맞게 자유롭게 조합/변형하세요.
핵심은 성능을 측정하고, 구현을 반복적으로 개선하는 것!

"복잡성은 반드시 결과가 개선될 때만 추가하세요."

7. 요약 및 실전 원칙 📝

LLM 분야의 성공은 가장 복잡한 시스템을 만드는 것이 아니라,
내 필요에 맞는 '올바른' 시스템을 만드는 데 있습니다.

단순한 프롬프트로 시작하세요.
평가를 통해 최적화하세요.
멀티스텝 에이전트는 단순한 해결책이 부족할 때만 도입하세요.

Anthropic의 3대 원칙:

단순성 유지
투명성 확보 (에이전트의 계획 단계 명확히 보여주기)
에이전트-컴퓨터 인터페이스(ACI)를 꼼꼼히 문서화/테스트

"프레임워크는 빠른 시작에 도움되지만, 실제 서비스에서는 추상화 레이어를 줄이고 기본 컴포넌트로 구축하는 것이 더 좋을 수 있습니다."

8. 실전 사례 (부록 1) 💡

A. 고객 지원

대화형 챗봇 + 도구 통합 = 자연스러운 에이전트 활용
고객 데이터, 주문 내역, 지식 베이스 등 외부 정보 활용
환불, 티켓 업데이트 등 프로그램적 액션 가능
성공 기준이 명확 (예: 문제 해결 여부)

"여러 회사가 성공적인 해결 건에만 요금을 부과하는 모델로, 에이전트의 효과를 입증했습니다."

B. 코딩 에이전트

코드 솔루션은 자동화된 테스트로 검증 가능
테스트 결과를 피드백 삼아 반복 개선
문제 공간이 명확하고 구조화되어 있음
객관적 품질 측정 가능

"Anthropic의 에이전트는 이제 GitHub 이슈를 풀리퀘스트 설명만으로 해결할 수 있습니다.
하지만 자동화 테스트만으로는 충분하지 않고,
전체 시스템 요구사항에 부합하는지 인간 검토가 여전히 중요합니다."

9. 도구 프롬프트 엔지니어링 (부록 2) 🛠️

에이전틱 시스템에서 도구(tool)는 매우 중요합니다.
Claude는 외부 서비스/API와 상호작용할 때,
API에 정확한 구조와 정의를 명시해야 합니다.

도구 정의/명세는 프롬프트만큼이나 신경 써야 함
같은 작업도 여러 방식으로 명세 가능 (예: diff vs 전체 파일 재작성, markdown vs JSON)
LLM이 쓰기 쉬운 포맷을 선택해야 함

도구 설계 팁:

모델이 "생각할 시간"을 가질 수 있도록 충분한 토큰 제공
인터넷에서 자연스럽게 접할 수 있는 포맷 사용
불필요한 포맷팅 부담(예: 줄 수 세기, 문자열 이스케이프 등) 최소화

"좋은 도구 정의는 예시, 엣지 케이스, 입력 포맷, 다른 도구와의 경계까지 명확히 포함해야 합니다."

파라미터 이름/설명을 더 명확하게 바꿔보세요 (주니어 개발자에게 설명하듯)
다양한 입력으로 테스트하고, 모델이 실수하는 부분을 반복 개선
포카요케(Poka-yoke): 실수하기 어렵게 도구 설계

"SWE-bench 에이전트 개발 시, 전체 프롬프트보다 도구 최적화에 더 많은 시간을 썼습니다.
예를 들어, 상대 경로로 실수하던 문제를 절대 경로로 바꾸자, 모델이 완벽하게 사용했습니다."

10. 마무리 🎉

효과적인 AI 에이전트 구축의 핵심은
복잡함이 아니라, 내 문제에 딱 맞는 단순함과 투명성, 그리고 신뢰성입니다.

단순함을 유지하세요.
투명하게 설계하세요.
도구와 인터페이스를 꼼꼼히 문서화하고 테스트하세요.

이렇게 하면, 강력하면서도 신뢰할 수 있는 에이전트를 만들 수 있습니다! 🚀

"성공은 가장 복잡한 시스템이 아니라,
내 필요에 맞는 '올바른' 시스템을 만드는 데 있습니다."