효과적인 에이전트 구축하기

지난 1년간 Anthropic은 다양한 산업 분야에서 대규모 언어 모델(LLM) 에이전트를 구축하는 수십 개 팀과 협업했습니다. 그중 가장 성공적인 사례들에는 공통점이 있었습니다. 복잡한 프레임워크나 전문 라이브러리를 사용하지 않았다는 것입니다. 대신, 단순하고 조합 가능한 패턴을 활용해 시스템을 구축했습니다.

이 글에서는 고객사와의 협업과 자체 에이전트 개발 과정에서 얻은 인사이트를 공유하고, 효과적인 에이전트를 만들기 위한 실용적인 조언을 드리겠습니다.

에이전트란 무엇인가?

"에이전트"의 정의는 다양합니다. 어떤 고객은 다양한 도구를 활용해 장시간 독립적으로 복잡한 작업을 수행하는 완전 자율 시스템을 에이전트라고 정의합니다. 또 어떤 고객은 미리 정해진 워크플로를 따르는 규범적 구현체를 에이전트라고 부르기도 합니다. Anthropic에서는 이 모든 변형을 에이전틱 시스템(agentic systems)으로 통칭하되, 아키텍처 관점에서 워크플로와 에이전트를 명확히 구분합니다.

• 워크플로는 LLM과 도구가 사전 정의된 코드 경로에 따라 조율되는 시스템입니다.
• 에이전트는 LLM이 자체적으로 프로세스와 도구 사용을 동적으로 결정하며, 작업 수행 방식에 대한 주도권을 유지하는 시스템입니다.

아래에서는 두 유형의 에이전틱 시스템을 상세히 살펴봅니다. 부록 1("에이전트 실전 활용")에서는 고객들이 특히 높은 가치를 체감한 두 가지 적용 분야를 소개합니다.

에이전트를 써야 할 때와 쓰지 말아야 할 때

LLM 기반 애플리케이션을 만들 때는 가능한 한 가장 단순한 방법부터 시작하고, 필요할 때만 복잡도를 높이는 것이 좋습니다. 에이전틱 시스템을 아예 만들지 않는 것이 정답일 수도 있습니다. 에이전틱 시스템은 더 나은 작업 성능을 위해 지연 시간과 비용을 대가로 치르는 경우가 많으므로, 이 트레이드오프가 합리적인지 먼저 따져봐야 합니다.

더 높은 복잡도가 필요하다면, 잘 정의된 작업에는 예측 가능하고 일관된 워크플로가 적합하고, 대규모 환경에서 유연성과 모델 기반 의사결정이 필요하다면 에이전트가 더 나은 선택입니다. 하지만 많은 애플리케이션에서는 검색(retrieval)과 인컨텍스트 예시를 활용한 단일 LLM 호출 최적화만으로도 충분합니다.

프레임워크를 활용하는 시점과 방법

에이전틱 시스템 구축을 수월하게 해주는 프레임워크가 다양하게 존재합니다:

• Claude Agent SDK
• AWS의 Strands Agents SDK
• 드래그 앤 드롭 GUI 기반 LLM 워크플로 빌더인 Rivet
• 복잡한 워크플로를 구축하고 테스트할 수 있는 또 다른 GUI 도구인 Vellum

이러한 프레임워크는 LLM 호출, 도구 정의 및 파싱, 호출 체이닝 같은 저수준 작업을 간소화해 빠르게 시작할 수 있게 해줍니다. 하지만 추상화 레이어가 추가되면서 내부 프롬프트와 응답이 가려져 디버깅이 어려워지는 경우가 많습니다. 또한 단순한 구성으로 충분한 상황에서도 불필요한 복잡도를 더하고 싶은 유혹에 빠지기 쉽습니다.

먼저 LLM API를 직접 사용하는 것을 권장합니다. 대부분의 패턴은 몇 줄의 코드로 구현할 수 있습니다. 프레임워크를 사용하더라도 내부 동작 원리를 반드시 이해해야 합니다. 실제로 프레임워크 내부 동작에 대한 잘못된 가정이 고객사에서 발생하는 오류의 주요 원인입니다.

구현 예시는 cookbook에서 확인할 수 있습니다.

빌딩 블록, 워크플로, 에이전트

이 섹션에서는 실제 프로덕션 환경에서 관찰한 에이전틱 시스템의 주요 패턴을 살펴봅니다. 기본 빌딩 블록인 증강 LLM(augmented LLM)에서 출발해, 단순한 조합형 워크플로부터 자율 에이전트까지 점진적으로 복잡도를 높여가겠습니다.

빌딩 블록: 증강 LLM

에이전틱 시스템의 기본 빌딩 블록은 검색, 도구, 메모리 등의 기능으로 강화된 LLM입니다. 현재 모델은 이러한 기능을 능동적으로 활용할 수 있어, 자체적으로 검색 쿼리를 생성하고, 적절한 도구를 선택하며, 어떤 정보를 보존할지 판단합니다.

구현 시 두 가지 핵심 사항에 집중하는 것을 권장합니다. 첫째, 각 기능을 특정 사용 사례에 맞게 조정하는 것이고, 둘째, LLM이 쉽게 활용할 수 있도록 명확하고 잘 문서화된 인터페이스를 제공하는 것입니다. 이러한 증강 기능을 구현하는 방법은 다양하지만, 최근 출시한 Model Context Protocol을 활용하면 간단한 클라이언트 구현만으로 점점 확대되는 서드파티 도구 생태계에 연결할 수 있습니다.

이후 내용에서는 모든 LLM 호출이 이러한 증강 기능을 사용할 수 있다고 가정합니다.

워크플로: 프롬프트 체이닝

프롬프트 체이닝은 작업을 순차적인 단계로 분해하여, 각 LLM 호출이 이전 호출의 출력을 처리하는 방식입니다. 중간 단계마다 프로그래밍 방식의 검증(아래 다이어그램의 "gate" 참조)을 추가해 프로세스가 올바르게 진행되고 있는지 확인할 수 있습니다.

적합한 상황: 작업을 고정된 하위 작업으로 명확하게 분할할 수 있을 때 이상적입니다. 각 LLM 호출의 난이도를 낮춰 지연 시간을 감수하는 대신 정확도를 높이는 것이 핵심 목표입니다.

프롬프트 체이닝 활용 예시:

• 마케팅 카피를 생성한 뒤 다른 언어로 번역하는 작업
• 문서의 개요를 작성하고, 해당 개요가 특정 기준을 충족하는지 검증한 뒤, 개요를 기반으로 문서를 작성하는 작업

워크플로: 라우팅

라우팅은 입력을 분류한 뒤 전문화된 후속 작업으로 전달하는 패턴입니다. 관심사를 분리하고 더 전문적인 프롬프트를 구성할 수 있다는 장점이 있습니다. 라우팅 없이 하나의 프롬프트로 처리하면, 특정 유형의 입력에 최적화할수록 다른 유형의 성능이 저하될 수 있습니다.

적합한 상황: 별도로 처리하는 것이 더 효과적인 명확한 카테고리가 존재하고, LLM이나 기존 분류 모델/알고리즘으로 분류를 정확하게 수행할 수 있는 복잡한 작업에 적합합니다.

라우팅 활용 예시:

• 고객 서비스 문의를 유형별(일반 질문, 환불 요청, 기술 지원)로 분류해 서로 다른 프로세스, 프롬프트, 도구로 전달하는 작업
• 쉽고 일반적인 질문은 Claude Haiku 4.5 같은 소형·저비용 모델로, 어렵거나 특수한 질문은 Claude Sonnet 4.5 같은 고성능 모델로 라우팅해 비용 대비 최적의 성능을 달성하는 작업

워크플로: 병렬화

LLM이 하나의 작업을 동시에 처리하고 그 결과를 프로그래밍 방식으로 집계할 수 있는 경우가 있습니다. 이러한 병렬화 워크플로는 두 가지 주요 변형이 있습니다:

• 섹셔닝(Sectioning): 작업을 독립적인 하위 작업으로 나눠 병렬로 실행하는 방식
• 보팅(Voting): 동일한 작업을 여러 번 실행해 다양한 출력을 얻는 방식

적합한 상황: 하위 작업을 병렬로 처리해 속도를 높일 수 있거나, 더 높은 신뢰도를 위해 여러 관점이나 시도가 필요한 경우에 효과적입니다. 여러 고려사항이 있는 복잡한 작업에서는 각 고려사항을 별도의 LLM 호출로 처리해 각 측면에 집중할 수 있게 하는 것이 일반적으로 더 좋은 결과를 만듭니다.

병렬화 활용 예시:

• 섹셔닝:
  • 하나의 모델 인스턴스가 사용자 쿼리를 처리하는 동안 다른 인스턴스가 부적절한 콘텐츠나 요청을 검출하는 가드레일 구현. 동일한 LLM 호출에서 가드레일과 핵심 응답을 모두 처리하는 것보다 성능이 더 우수합니다.
  • LLM 성능 평가 자동화. 주어진 프롬프트에 대해 각 LLM 호출이 모델 성능의 서로 다른 측면을 평가합니다.
• 보팅:
  • 코드의 보안 취약점 검토. 여러 개의 서로 다른 프롬프트가 코드를 분석하고 문제가 발견되면 플래그를 지정합니다.
  • 콘텐츠의 부적절성 판단. 여러 프롬프트가 서로 다른 측면을 평가하거나 서로 다른 투표 임계값을 적용해 오탐(false positive)과 미탐(false negative)의 균형을 맞춥니다.

워크플로: 오케스트레이터-워커

오케스트레이터-워커 워크플로에서는 중앙 LLM이 작업을 동적으로 분해하고, 워커 LLM에게 위임한 뒤, 그 결과를 종합합니다.

적합한 상황: 필요한 하위 작업을 사전에 예측하기 어려운 복잡한 작업에 적합합니다. 예를 들어 코딩에서는 변경해야 할 파일 수와 각 파일의 변경 내용이 작업에 따라 달라집니다. 구조적으로는 병렬화와 유사하지만, 핵심적인 차이는 유연성에 있습니다. 하위 작업이 사전 정의되지 않고, 오케스트레이터가 입력에 따라 동적으로 결정합니다.

오케스트레이터-워커 활용 예시:

• 매번 여러 파일에 걸쳐 복잡한 변경을 수행하는 코딩 제품
• 여러 출처에서 정보를 수집하고 분석해 관련 정보를 찾아내는 검색 작업

워크플로: 평가자-최적화자

평가자-최적화자 워크플로에서는 하나의 LLM 호출이 응답을 생성하고, 다른 LLM 호출이 이를 평가하며 피드백을 제공하는 과정을 반복합니다.

적합한 상황: 평가 기준이 명확하고, 반복적인 개선이 측정 가능한 가치를 제공하는 경우에 특히 효과적입니다. 이 패턴이 적합하다는 두 가지 신호가 있습니다. 첫째, 사람이 피드백을 주면 LLM 응답이 눈에 띄게 개선되는 경우. 둘째, LLM이 그러한 피드백을 스스로 제공할 수 있는 경우입니다. 이는 사람이 완성도 높은 문서를 작성할 때 거치는 반복적인 글쓰기 과정과 유사합니다.

평가자-최적화자 활용 예시:

• 문학 번역. 번역 LLM이 초기에 포착하지 못한 뉘앙스를 평가 LLM이 유용한 비평을 통해 보완할 수 있는 경우.
• 포괄적인 정보 수집을 위해 여러 차례의 검색과 분석이 필요한 복잡한 검색 작업. 평가자가 추가 검색의 필요 여부를 판단합니다.

에이전트

LLM의 핵심 역량—복잡한 입력 이해, 추론 및 계획, 안정적인 도구 활용, 오류 복구—이 성숙해지면서, 에이전트가 실제 프로덕션 환경에서 본격적으로 등장하고 있습니다. 에이전트는 사용자의 명령이나 대화를 통해 작업을 시작합니다. 작업이 명확해지면 독립적으로 계획을 세우고 실행하며, 필요한 경우 추가 정보나 판단을 위해 사용자에게 다시 돌아옵니다. 실행 과정에서 에이전트는 매 단계마다 환경으로부터 "실제 결과(ground truth)"를 확인하는 것이 매우 중요합니다. 도구 호출 결과나 코드 실행 결과 등을 통해 진행 상황을 평가하는 것이죠. 에이전트는 주요 체크포인트나 진행이 막히는 지점에서 사용자의 피드백을 받기 위해 일시 중단할 수도 있습니다. 보통 작업이 완료되면 종료되지만, 제어권을 유지하기 위해 최대 반복 횟수 같은 중단 조건을 설정하는 것도 일반적입니다.

에이전트는 복잡한 작업도 처리할 수 있지만, 구현 자체는 비교적 단순한 경우가 많습니다. 대부분의 에이전트는 루프 안에서 환경 피드백을 바탕으로 도구를 사용하는 LLM에 불과합니다. 따라서 도구 세트와 그에 대한 문서를 명확하고 신중하게 설계하는 것이 핵심입니다. 도구 개발의 모범 사례는 부록 2("도구를 위한 프롬프트 엔지니어링")에서 자세히 다룹니다.

에이전트를 사용해야 할 때: 에이전트는 필요한 단계 수를 예측하기 어렵거나 불가능하고, 고정된 경로를 하드코딩할 수 없는 개방형 문제에 적합합니다. LLM이 여러 턴에 걸쳐 동작할 수 있으며, 그 의사결정에 일정 수준의 신뢰를 부여해야 합니다. 에이전트의 자율성 덕분에 신뢰할 수 있는 환경에서 작업을 확장하기에 이상적입니다.

에이전트의 자율적 특성은 비용 증가와 오류 누적 가능성을 수반합니다. 샌드박스 환경에서의 충분한 테스트와 적절한 가드레일 설정을 권장합니다.

에이전트가 유용한 사례:

다음은 저희가 직접 구현한 사례입니다:

• 작업 설명을 바탕으로 여러 파일을 수정해야 하는 SWE-bench 과제를 해결하는 코딩 에이전트
• Claude가 컴퓨터를 직접 사용해 작업을 수행하는 "computer use" 레퍼런스 구현

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

앞서 소개한 빌딩 블록은 정해진 공식이 아닙니다. 개발자가 다양한 사용 사례에 맞게 자유롭게 조합하고 변형할 수 있는 일반적인 패턴입니다. 다른 LLM 기능과 마찬가지로, 성공의 열쇠는 성능을 측정하고 구현을 반복적으로 개선하는 데 있습니다. 다시 한번 강조하자면, 복잡성을 추가하는 것은 그것이 실질적으로 결과를 개선한다고 확인된 경우에만 고려해야 합니다.

요약

LLM 분야에서의 성공은 가장 정교한 시스템을 구축하는 것이 아니라, 필요에 맞는 시스템을 구축하는 데 달려 있습니다. 단순한 프롬프트로 시작하고, 종합적인 평가를 통해 최적화한 뒤, 단순한 방식으로 해결되지 않을 때만 다단계 에이전트 시스템을 도입하세요.

에이전트를 구현할 때 저희가 따르는 세 가지 핵심 원칙은 다음과 같습니다:

1. 에이전트 설계의 단순함을 유지하세요.
2. 에이전트의 계획 단계를 명시적으로 드러내어 투명성을 확보하세요.
3. 철저한 도구 문서화와 테스트를 통해 에이전트-컴퓨터 인터페이스(ACI)를 정교하게 설계하세요.

프레임워크를 활용하면 빠르게 시작할 수 있지만, 프로덕션으로 전환할 때는 추상화 계층을 줄이고 기본 컴포넌트로 직접 구축하는 것을 주저하지 마세요. 이러한 원칙을 따르면 강력할 뿐만 아니라 안정적이고, 유지보수가 쉬우며, 사용자가 신뢰할 수 있는 에이전트를 만들 수 있습니다.

감사의 말

Erik Schluntz와 Barry Zhang이 작성했습니다. 이 글은 Anthropic에서 에이전트를 구축한 경험과 고객분들이 공유해 주신 소중한 인사이트를 바탕으로 합니다. 깊이 감사드립니다.

부록 1: 실전에서의 에이전트

고객사와의 협업을 통해, 앞서 다룬 패턴의 실용적 가치를 잘 보여주는 두 가지 유망한 AI 에이전트 활용 사례를 발견했습니다. 두 사례 모두 대화와 실행이 함께 필요하고, 명확한 성공 기준이 있으며, 피드백 루프가 가능하고, 의미 있는 사람의 감독이 통합되는 작업에서 에이전트가 가장 큰 가치를 발휘한다는 점을 보여줍니다.

A. 고객 지원

고객 지원은 익숙한 챗봇 인터페이스에 도구 통합을 통한 향상된 기능을 결합한 분야입니다. 개방형 에이전트에 자연스럽게 적합한 이유는 다음과 같습니다:

• 지원 상호작용은 대화 흐름을 따르면서도 외부 정보 및 액션에 대한 접근이 필요합니다.
• 고객 데이터, 주문 내역, 지식 베이스 문서를 가져오는 도구를 통합할 수 있습니다.
• 환불 처리나 티켓 업데이트 같은 작업을 프로그래밍 방식으로 처리할 수 있습니다.
• 사용자가 정의한 해결 기준으로 성공 여부를 명확하게 측정할 수 있습니다.

여러 기업이 성공적인 해결 건에 대해서만 과금하는 사용량 기반 가격 모델을 도입하며 이 접근법의 실효성을 입증했고, 이는 자사 에이전트의 효과에 대한 강한 자신감을 보여줍니다.

B. 코딩 에이전트

소프트웨어 개발 분야는 코드 자동 완성에서 자율적 문제 해결까지 역량이 빠르게 발전하며, LLM 활용의 놀라운 잠재력을 보여주고 있습니다. 에이전트가 특히 효과적인 이유는 다음과 같습니다:

• 코드 솔루션은 자동화된 테스트로 검증할 수 있습니다.
• 에이전트가 테스트 결과를 피드백 삼아 솔루션을 반복 개선할 수 있습니다.
• 문제 영역이 잘 정의되어 있고 구조화되어 있습니다.
• 출력 품질을 객관적으로 측정할 수 있습니다.

저희 자체 구현에서는 에이전트가 풀 리퀘스트(Pull Request) 설명만으로 SWE-bench Verified 벤치마크의 실제 GitHub 이슈를 해결할 수 있는 수준에 이르렀습니다. 다만 자동화된 테스트가 기능 검증에 도움이 되긴 하지만, 솔루션이 전체 시스템 요구사항에 부합하는지 확인하려면 여전히 사람의 리뷰가 필수적입니다.

부록 2: 도구를 위한 프롬프트 엔지니어링

어떤 에이전트 시스템을 구축하든 도구는 핵심적인 요소입니다. 도구(Tools)는 API에서 정확한 구조와 정의를 명시하여 Claude가 외부 서비스 및 API와 상호작용할 수 있게 해줍니다. Claude가 도구를 호출하려는 경우, API 응답에 도구 사용 블록(tool use block)이 포함됩니다. 도구의 정의와 명세에도 전체 프롬프트 못지않은 프롬프트 엔지니어링 노력을 기울여야 합니다. 이 부록에서는 도구에 대한 프롬프트 엔지니어링 방법을 설명합니다.

동일한 작업을 지정하는 방법은 여러 가지가 있습니다. 예를 들어, 파일 편집을 diff로 작성할 수도 있고 파일 전체를 다시 쓸 수도 있습니다. 구조화된 출력의 경우 코드를 마크다운 안에 넣을 수도 있고 JSON 안에 넣을 수도 있습니다. 소프트웨어 엔지니어링 관점에서 이러한 차이는 표면적이며 손실 없이 상호 변환이 가능합니다. 하지만 LLM이 작성하기에 특정 형식이 다른 형식보다 훨씬 어려울 수 있습니다. diff를 작성하려면 새 코드를 쓰기 전에 청크 헤더에서 변경되는 줄 수를 미리 알아야 합니다. 마크다운 대신 JSON 안에 코드를 작성하면 줄바꿈과 따옴표에 대한 추가 이스케이프 처리가 필요합니다.

도구 형식을 결정할 때 다음 사항을 권장합니다:

• 모델이 막다른 길에 빠지기 전에 충분히 "생각할" 수 있는 토큰을 확보하세요.
• 인터넷상의 텍스트에서 모델이 자연스럽게 접했을 형식에 가깝게 유지하세요.
• 수천 줄의 코드를 정확히 세거나 작성한 코드를 문자열 이스케이프해야 하는 것과 같은 형식적 "오버헤드"가 없도록 하세요.

한 가지 기준을 제시하자면, 사람-컴퓨터 인터페이스(HCI)에 얼마나 많은 노력이 투입되는지를 떠올려 보세요. 좋은 에이전트-컴퓨터 인터페이스(ACI)를 만드는 데에도 그만큼의 노력을 투자할 계획을 세워야 합니다. 구체적인 방법은 다음과 같습니다:

• 모델의 입장에서 생각해 보세요. 설명과 매개변수만 보고 이 도구의 사용법이 명확한가요, 아니면 신중하게 고민해야 하나요? 사람이 고민해야 한다면 모델도 마찬가지일 가능성이 높습니다. 좋은 도구 정의에는 사용 예시, 엣지 케이스, 입력 형식 요구사항, 다른 도구와의 명확한 경계가 포함됩니다.
• 매개변수 이름이나 설명을 어떻게 바꾸면 더 직관적이 될까요? 팀의 주니어 개발자를 위한 훌륭한 docstring을 작성한다고 생각하세요. 유사한 도구가 여러 개 있을 때 특히 중요합니다.
• 모델이 도구를 어떻게 사용하는지 테스트하세요: 워크벤치(workbench)에서 다양한 입력 예시를 실행하여 모델이 어떤 실수를 하는지 확인하고 반복 개선하세요.
• 도구에 Poka-yoke를 적용하세요. 실수하기 어렵도록 인자를 변경하세요.

SWE-bench용 에이전트를 구축할 때, 실제로 전체 프롬프트보다 도구 최적화에 더 많은 시간을 투입했습니다. 예를 들어, 에이전트가 루트 디렉토리를 벗어난 후 상대 파일 경로를 사용하는 도구에서 실수를 범하는 것을 발견했습니다. 이를 해결하기 위해 항상 절대 파일 경로를 요구하도록 도구를 변경했고, 그 결과 모델은 이 방식을 완벽하게 사용했습니다.