Anthropic이 신뢰할 수 있는 AI 에이전트를 어떻게 개발하는지 알아보세요. 에이전트의 역량, 안전성 고려 사항, 그리고 신뢰도 높은 AI를 구축하기 위한 기술 프레임워크에 관한 연구를 소개합니다.
지난 1년간 Anthropic은 다양한 산업 분야에서 대규모 언어 모델(LLM) 에이전트를 구축하는 수십 개 팀과 협업했습니다. 그중 가장 성공적인 사례들에는 공통점이 있었습니다. 복잡한 프레임워크나 전문 라이브러리를 사용하지 않았다는 것입니다. 대신, 단순하고 조합 가능한 패턴을 활용해 시스템을 구축했습니다.
이 글에서는 고객사와의 협업과 자체 에이전트 개발 과정에서 얻은 인사이트를 공유하고, 효과적인 에이전트를 만들기 위한 실용적인 조언을 드리겠습니다.
"에이전트"의 정의는 다양합니다. 어떤 고객은 다양한 도구를 활용해 장시간 독립적으로 복잡한 작업을 수행하는 완전 자율 시스템을 에이전트라고 정의합니다. 또 어떤 고객은 미리 정해진 워크플로를 따르는 규범적 구현체를 에이전트라고 부르기도 합니다. Anthropic에서는 이 모든 변형을 에이전틱 시스템(agentic systems)으로 통칭하되, 아키텍처 관점에서 워크플로와 에이전트를 명확히 구분합니다.
아래에서는 두 유형의 에이전틱 시스템을 상세히 살펴봅니다. 부록 1("에이전트 실전 활용")에서는 고객들이 특히 높은 가치를 체감한 두 가지 적용 분야를 소개합니다.
LLM 기반 애플리케이션을 만들 때는 가능한 한 가장 단순한 방법부터 시작하고, 필요할 때만 복잡도를 높이는 것이 좋습니다. 에이전틱 시스템을 아예 만들지 않는 것이 정답일 수도 있습니다. 에이전틱 시스템은 더 나은 작업 성능을 위해 지연 시간과 비용을 대가로 치르는 경우가 많으므로, 이 트레이드오프가 합리적인지 먼저 따져봐야 합니다.
더 높은 복잡도가 필요하다면, 잘 정의된 작업에는 예측 가능하고 일관된 워크플로가 적합하고, 대규모 환경에서 유연성과 모델 기반 의사결정이 필요하다면 에이전트가 더 나은 선택입니다. 하지만 많은 애플리케이션에서는 검색(retrieval)과 인컨텍스트 예시를 활용한 단일 LLM 호출 최적화만으로도 충분합니다.
에이전틱 시스템 구축을 수월하게 해주는 프레임워크가 다양하게 존재합니다:
이러한 프레임워크는 LLM 호출, 도구 정의 및 파싱, 호출 체이닝 같은 저수준 작업을 간소화해 빠르게 시작할 수 있게 해줍니다. 하지만 추상화 레이어가 추가되면서 내부 프롬프트와 응답이 가려져 디버깅이 어려워지는 경우가 많습니다. 또한 단순한 구성으로 충분한 상황에서도 불필요한 복잡도를 더하고 싶은 유혹에 빠지기 쉽습니다.
먼저 LLM API를 직접 사용하는 것을 권장합니다. 대부분의 패턴은 몇 줄의 코드로 구현할 수 있습니다. 프레임워크를 사용하더라도 내부 동작 원리를 반드시 이해해야 합니다. 실제로 프레임워크 내부 동작에 대한 잘못된 가정이 고객사에서 발생하는 오류의 주요 원인입니다.
구현 예시는 cookbook에서 확인할 수 있습니다.
이 섹션에서는 실제 프로덕션 환경에서 관찰한 에이전틱 시스템의 주요 패턴을 살펴봅니다. 기본 빌딩 블록인 증강 LLM(augmented LLM)에서 출발해, 단순한 조합형 워크플로부터 자율 에이전트까지 점진적으로 복잡도를 높여가겠습니다.
에이전틱 시스템의 기본 빌딩 블록은 검색, 도구, 메모리 등의 기능으로 강화된 LLM입니다. 현재 모델은 이러한 기능을 능동적으로 활용할 수 있어, 자체적으로 검색 쿼리를 생성하고, 적절한 도구를 선택하며, 어떤 정보를 보존할지 판단합니다.

구현 시 두 가지 핵심 사항에 집중하는 것을 권장합니다. 첫째, 각 기능을 특정 사용 사례에 맞게 조정하는 것이고, 둘째, LLM이 쉽게 활용할 수 있도록 명확하고 잘 문서화된 인터페이스를 제공하는 것입니다. 이러한 증강 기능을 구현하는 방법은 다양하지만, 최근 출시한 Model Context Protocol을 활용하면 간단한 클라이언트 구현만으로 점점 확대되는 서드파티 도구 생태계에 연결할 수 있습니다.
이후 내용에서는 모든 LLM 호출이 이러한 증강 기능을 사용할 수 있다고 가정합니다.
프롬프트 체이닝은 작업을 순차적인 단계로 분해하여, 각 LLM 호출이 이전 호출의 출력을 처리하는 방식입니다. 중간 단계마다 프로그래밍 방식의 검증(아래 다이어그램의 "gate" 참조)을 추가해 프로세스가 올바르게 진행되고 있는지 확인할 수 있습니다.

적합한 상황: 작업을 고정된 하위 작업으로 명확하게 분할할 수 있을 때 이상적입니다. 각 LLM 호출의 난이도를 낮춰 지연 시간을 감수하는 대신 정확도를 높이는 것이 핵심 목표입니다.
프롬프트 체이닝 활용 예시:
라우팅은 입력을 분류한 뒤 전문화된 후속 작업으로 전달하는 패턴입니다. 관심사를 분리하고 더 전문적인 프롬프트를 구성할 수 있다는 장점이 있습니다. 라우팅 없이 하나의 프롬프트로 처리하면, 특정 유형의 입력에 최적화할수록 다른 유형의 성능이 저하될 수 있습니다.

적합한 상황: 별도로 처리하는 것이 더 효과적인 명확한 카테고리가 존재하고, LLM이나 기존 분류 모델/알고리즘으로 분류를 정확하게 수행할 수 있는 복잡한 작업에 적합합니다.
라우팅 활용 예시:
LLM이 하나의 작업을 동시에 처리하고 그 결과를 프로그래밍 방식으로 집계할 수 있는 경우가 있습니다. 이러한 병렬화 워크플로는 두 가지 주요 변형이 있습니다:

적합한 상황: 하위 작업을 병렬로 처리해 속도를 높일 수 있거나, 더 높은 신뢰도를 위해 여러 관점이나 시도가 필요한 경우에 효과적입니다. 여러 고려사항이 있는 복잡한 작업에서는 각 고려사항을 별도의 LLM 호출로 처리해 각 측면에 집중할 수 있게 하는 것이 일반적으로 더 좋은 결과를 만듭니다.
병렬화 활용 예시:
오케스트레이터-워커 워크플로에서는 중앙 LLM이 작업을 동적으로 분해하고, 워커 LLM에게 위임한 뒤, 그 결과를 종합합니다.

적합한 상황: 필요한 하위 작업을 사전에 예측하기 어려운 복잡한 작업에 적합합니다. 예를 들어 코딩에서는 변경해야 할 파일 수와 각 파일의 변경 내용이 작업에 따라 달라집니다. 구조적으로는 병렬화와 유사하지만, 핵심적인 차이는 유연성에 있습니다. 하위 작업이 사전 정의되지 않고, 오케스트레이터가 입력에 따라 동적으로 결정합니다.
오케스트레이터-워커 활용 예시:
평가자-최적화자 워크플로에서는 하나의 LLM 호출이 응답을 생성하고, 다른 LLM 호출이 이를 평가하며 피드백을 제공하는 과정을 반복합니다.

적합한 상황: 평가 기준이 명확하고, 반복적인 개선이 측정 가능한 가치를 제공하는 경우에 특히 효과적입니다. 이 패턴이 적합하다는 두 가지 신호가 있습니다. 첫째, 사람이 피드백을 주면 LLM 응답이 눈에 띄게 개선되는 경우. 둘째, LLM이 그러한 피드백을 스스로 제공할 수 있는 경우입니다. 이는 사람이 완성도 높은 문서를 작성할 때 거치는 반복적인 글쓰기 과정과 유사합니다.
평가자-최적화자 활용 예시:
LLM의 핵심 역량—복잡한 입력 이해, 추론 및 계획, 안정적인 도구 활용, 오류 복구—이 성숙해지면서, 에이전트가 실제 프로덕션 환경에서 본격적으로 등장하고 있습니다. 에이전트는 사용자의 명령이나 대화를 통해 작업을 시작합니다. 작업이 명확해지면 독립적으로 계획을 세우고 실행하며, 필요한 경우 추가 정보나 판단을 위해 사용자에게 다시 돌아옵니다. 실행 과정에서 에이전트는 매 단계마다 환경으로부터 "실제 결과(ground truth)"를 확인하는 것이 매우 중요합니다. 도구 호출 결과나 코드 실행 결과 등을 통해 진행 상황을 평가하는 것이죠. 에이전트는 주요 체크포인트나 진행이 막히는 지점에서 사용자의 피드백을 받기 위해 일시 중단할 수도 있습니다. 보통 작업이 완료되면 종료되지만, 제어권을 유지하기 위해 최대 반복 횟수 같은 중단 조건을 설정하는 것도 일반적입니다.
에이전트는 복잡한 작업도 처리할 수 있지만, 구현 자체는 비교적 단순한 경우가 많습니다. 대부분의 에이전트는 루프 안에서 환경 피드백을 바탕으로 도구를 사용하는 LLM에 불과합니다. 따라서 도구 세트와 그에 대한 문서를 명확하고 신중하게 설계하는 것이 핵심입니다. 도구 개발의 모범 사례는 부록 2("도구를 위한 프롬프트 엔지니어링")에서 자세히 다룹니다.

에이전트를 사용해야 할 때: 에이전트는 필요한 단계 수를 예측하기 어렵거나 불가능하고, 고정된 경로를 하드코딩할 수 없는 개방형 문제에 적합합니다. LLM이 여러 턴에 걸쳐 동작할 수 있으며, 그 의사결정에 일정 수준의 신뢰를 부여해야 합니다. 에이전트의 자율성 덕분에 신뢰할 수 있는 환경에서 작업을 확장하기에 이상적입니다.
에이전트의 자율적 특성은 비용 증가와 오류 누적 가능성을 수반합니다. 샌드박스 환경에서의 충분한 테스트와 적절한 가드레일 설정을 권장합니다.
에이전트가 유용한 사례:
다음은 저희가 직접 구현한 사례입니다:

앞서 소개한 빌딩 블록은 정해진 공식이 아닙니다. 개발자가 다양한 사용 사례에 맞게 자유롭게 조합하고 변형할 수 있는 일반적인 패턴입니다. 다른 LLM 기능과 마찬가지로, 성공의 열쇠는 성능을 측정하고 구현을 반복적으로 개선하는 데 있습니다. 다시 한번 강조하자면, 복잡성을 추가하는 것은 그것이 실질적으로 결과를 개선한다고 확인된 경우에만 고려해야 합니다.
LLM 분야에서의 성공은 가장 정교한 시스템을 구축하는 것이 아니라, 필요에 맞는 시스템을 구축하는 데 달려 있습니다. 단순한 프롬프트로 시작하고, 종합적인 평가를 통해 최적화한 뒤, 단순한 방식으로 해결되지 않을 때만 다단계 에이전트 시스템을 도입하세요.
에이전트를 구현할 때 저희가 따르는 세 가지 핵심 원칙은 다음과 같습니다:
프레임워크를 활용하면 빠르게 시작할 수 있지만, 프로덕션으로 전환할 때는 추상화 계층을 줄이고 기본 컴포넌트로 직접 구축하는 것을 주저하지 마세요. 이러한 원칙을 따르면 강력할 뿐만 아니라 안정적이고, 유지보수가 쉬우며, 사용자가 신뢰할 수 있는 에이전트를 만들 수 있습니다.
Erik Schluntz와 Barry Zhang이 작성했습니다. 이 글은 Anthropic에서 에이전트를 구축한 경험과 고객분들이 공유해 주신 소중한 인사이트를 바탕으로 합니다. 깊이 감사드립니다.
고객사와의 협업을 통해, 앞서 다룬 패턴의 실용적 가치를 잘 보여주는 두 가지 유망한 AI 에이전트 활용 사례를 발견했습니다. 두 사례 모두 대화와 실행이 함께 필요하고, 명확한 성공 기준이 있으며, 피드백 루프가 가능하고, 의미 있는 사람의 감독이 통합되는 작업에서 에이전트가 가장 큰 가치를 발휘한다는 점을 보여줍니다.
고객 지원은 익숙한 챗봇 인터페이스에 도구 통합을 통한 향상된 기능을 결합한 분야입니다. 개방형 에이전트에 자연스럽게 적합한 이유는 다음과 같습니다:
여러 기업이 성공적인 해결 건에 대해서만 과금하는 사용량 기반 가격 모델을 도입하며 이 접근법의 실효성을 입증했고, 이는 자사 에이전트의 효과에 대한 강한 자신감을 보여줍니다.
소프트웨어 개발 분야는 코드 자동 완성에서 자율적 문제 해결까지 역량이 빠르게 발전하며, LLM 활용의 놀라운 잠재력을 보여주고 있습니다. 에이전트가 특히 효과적인 이유는 다음과 같습니다:
저희 자체 구현에서는 에이전트가 풀 리퀘스트(Pull Request) 설명만으로 SWE-bench Verified 벤치마크의 실제 GitHub 이슈를 해결할 수 있는 수준에 이르렀습니다. 다만 자동화된 테스트가 기능 검증에 도움이 되긴 하지만, 솔루션이 전체 시스템 요구사항에 부합하는지 확인하려면 여전히 사람의 리뷰가 필수적입니다.
어떤 에이전트 시스템을 구축하든 도구는 핵심적인 요소입니다. 도구(Tools)는 API에서 정확한 구조와 정의를 명시하여 Claude가 외부 서비스 및 API와 상호작용할 수 있게 해줍니다. Claude가 도구를 호출하려는 경우, API 응답에 도구 사용 블록(tool use block)이 포함됩니다. 도구의 정의와 명세에도 전체 프롬프트 못지않은 프롬프트 엔지니어링 노력을 기울여야 합니다. 이 부록에서는 도구에 대한 프롬프트 엔지니어링 방법을 설명합니다.
동일한 작업을 지정하는 방법은 여러 가지가 있습니다. 예를 들어, 파일 편집을 diff로 작성할 수도 있고 파일 전체를 다시 쓸 수도 있습니다. 구조화된 출력의 경우 코드를 마크다운 안에 넣을 수도 있고 JSON 안에 넣을 수도 있습니다. 소프트웨어 엔지니어링 관점에서 이러한 차이는 표면적이며 손실 없이 상호 변환이 가능합니다. 하지만 LLM이 작성하기에 특정 형식이 다른 형식보다 훨씬 어려울 수 있습니다. diff를 작성하려면 새 코드를 쓰기 전에 청크 헤더에서 변경되는 줄 수를 미리 알아야 합니다. 마크다운 대신 JSON 안에 코드를 작성하면 줄바꿈과 따옴표에 대한 추가 이스케이프 처리가 필요합니다.
도구 형식을 결정할 때 다음 사항을 권장합니다:
한 가지 기준을 제시하자면, 사람-컴퓨터 인터페이스(HCI)에 얼마나 많은 노력이 투입되는지를 떠올려 보세요. 좋은 에이전트-컴퓨터 인터페이스(ACI)를 만드는 데에도 그만큼의 노력을 투자할 계획을 세워야 합니다. 구체적인 방법은 다음과 같습니다:
SWE-bench용 에이전트를 구축할 때, 실제로 전체 프롬프트보다 도구 최적화에 더 많은 시간을 투입했습니다. 예를 들어, 에이전트가 루트 디렉토리를 벗어난 후 상대 파일 경로를 사용하는 도구에서 실수를 범하는 것을 발견했습니다. 이를 해결하기 위해 항상 절대 파일 경로를 요구하도록 도구를 변경했고, 그 결과 모델은 이 방식을 완벽하게 사용했습니다.