우리는 다양한 산업 분야에서 LLM 에이전트를 구축하는 수많은 팀들과 협업해 왔습니다. 공통적으로 가장 성공적인 구현 사례들은 복잡한 프레임워크보다는 단순하고 조합 가능한 패턴을 사용하는 경우였습니다.
지난 1년 동안, 우리는 여러 산업 전반에서 대규모 언어 모델(LLM) 기반 에이전트를 개발하는 팀들과 함께 일했습니다. 꾸준히 증명된 사실은, 가장 성공적인 구현이 특수한 라이브러리나 복잡한 프레임워크에 의존하지 않았다는 점입니다. 대신, 단순하면서도 조립식으로 결합 가능한 패턴을 기반으로 구축되었죠.
이 글에서는 우리가 고객과 함께 작업하며 얻은 경험, 그리고 직접 에이전트를 개발한 과정에서 배운 점들을 공유합니다. 또한 개발자들이 효과적인 에이전트를 구현하는 데 실질적으로 도움이 될 수 있는 조언들을 제공합니다.
에이전트란 무엇인가? (What are agents?)
“에이전트(Agent)”라는 개념은 여러 방식으로 정의될 수 있습니다. 어떤 고객들은 에이전트를 여러 도구를 활용해 복잡한 작업을 장기간 동안 독립적으로 수행하는 완전 자율 시스템으로 이해합니다. 반면, 다른 고객들은 이를 사전에 정의된 워크플로우(workflow)를 따르는 더 규범적인 구현 방식을 가리키는 용어로 사용하기도 합니다.
Anthropic에서는 이러한 다양한 형태를 모두 에이전트적 시스템(agentic systems)이라 부르지만, 아키텍처적인 관점에서 중요한 구분을 두고 있습니다. 바로 워크플로우(workflows)와 에이전트(agents)의 차이입니다:
- 워크플로우(Workflows)는 LLM과 도구들이 사전에 정의된 코드 경로에 따라 조율되는 시스템입니다.
- 에이전트(Agents)는 반대로, LLM이 자신의 프로세스와 도구 사용 방식을 동적으로 지시하며, 작업 수행 방법에 대한 통제권을 유지하는 시스템입니다.
이후 본문에서는 두 가지 유형의 에이전트적 시스템을 상세히 살펴보겠습니다. 또한 부록 1 (Agents in Practice)에서는 고객들이 이러한 시스템을 활용하며 특히 높은 가치를 발견한 두 가지 도메인을 소개합니다.
에이전트를 언제 사용해야 하고, 언제 사용하지 말아야 하는가
LLM을 활용해 애플리케이션을 구축할 때는 가능한 한 가장 단순한 해법을 찾고, 필요할 때에만 복잡하게 만드는 것이 바람직합니다. 이는 경우에 따라 애초에 에이전트적 시스템(agentic systems)을 구축하지 않는 것이 더 나을 수도 있다는 뜻입니다. 에이전트적 시스템은 종종 지연 시간(latency)과 비용을 더 많이 요구하는 대신, 작업 성능을 향상시키는 선택지를 제공합니다. 따라서 이 트레이드오프가 언제 타당한지 반드시 고민해야 합니다.
더 높은 수준의 복잡성이 필요한 상황이라면, 워크플로우(workflows)는 정의가 명확한 과제에 대해 예측 가능성과 일관성을 제공합니다. 반면, 대규모로 유연성과 모델 주도적 의사결정(model-driven decision-making)이 요구되는 상황에서는 에이전트가 더 적합합니다. 그러나 많은 애플리케이션에서는 사실상 단일 LLM 호출을 최적화하고, 그 안에 검색(retrieval)이나 문맥 내 예시(in-context examples)를 적절히 활용하는 것만으로도 충분한 경우가 많습니다.
프레임워크를 언제, 그리고 어떻게 활용해야 하는가
에이전트적 시스템(agentic systems)을 구현하기 쉽게 만들어주는 프레임워크들은 여러 가지가 있습니다. 예를 들면:
- LangChain의 LangGraph,
- Amazon Bedrock의 AI Agent framework,
- 드래그 앤 드롭 방식의 GUI LLM 워크플로우 빌더 Rivet,
- 복잡한 워크플로우를 구성하고 테스트할 수 있는 또 다른 GUI 도구 Vellum.
이러한 프레임워크들은 LLM 호출, 도구 정의 및 파싱, 호출 연결 같은 기본적인 반복 작업을 단순화하여 손쉽게 시작할 수 있게 해줍니다. 하지만 동시에, 추가적인 추상화 계층을 만들어 프롬프트와 응답의 실제 과정을 가려버리기도 하여 디버깅을 어렵게 만들 수 있습니다. 또한, 단순한 구성만으로 충분한 경우에도 불필요하게 시스템을 복잡하게 만드는 유혹에 빠지게 할 수 있습니다.
우리는 개발자들이 우선 LLM API를 직접 사용하는 방법부터 시작할 것을 권장합니다. 사실 많은 패턴이 몇 줄의 코드만으로도 구현될 수 있기 때문입니다. 만약 프레임워크를 사용한다면, 반드시 그 내부 동작을 이해해야 합니다. 내부 구현에 대한 잘못된 가정은 고객들이 흔히 겪는 오류의 원인이 됩니다.
구체적인 구현 사례는 우리 cookbook에서 확인할 수 있습니다.
구성 요소, 워크플로우, 그리고 에이전트
이 섹션에서는 실제 프로덕션 환경에서 자주 등장하는 에이전트적 시스템(agentic systems)의 공통 패턴을 살펴보겠습니다. 가장 기초적인 구성 요소인 ‘확장된 LLM(augmented LLM)’부터 시작해, 점차 복잡성을 높여가며 단순한 조합형 워크플로우(workflows)에서 자율적인 에이전트(agents)에 이르는 흐름을 다룰 예정입니다.
기본 구성 요소: 확장된 LLM (Building block: The augmented LLM)
에이전트적 시스템의 기본 단위는 검색(retrieval), 도구 연결(tools), 메모리(memory) 같은 기능으로 확장된 LLM입니다. 현재 모델들은 이러한 기능들을 능동적으로 활용할 수 있는데, 예컨대 스스로 검색 쿼리를 생성하거나, 알맞은 도구를 선택하고, 어떤 정보를 기억해둘지 결정하는 식입니다.
이 구현에서 특히 중요한 두 가지는 해당 기능들을 구체적인 사용 사례에 맞게 조정하는 것, 그리고 LLM이 쉽게 활용할 수 있도록 인터페이스를 명확하고 문서화된 형태로 제공하는 것입니다. 이러한 확장 기능을 구현하는 방법은 다양하지만, 최근 우리가 공개한 Model Context Protocol을 사용하는 것이 한 가지 방법이 될 수 있습니다. 이를 통해 개발자들은 클라이언트 구현을 단순하게 적용하면서도, 점점 확장되는 서드파티 도구 생태계와 손쉽게 연동할 수 있습니다.
이후 본문에서는, 각 LLM 호출이 이러한 확장 기능을 활용할 수 있다는 전제를 기반으로 설명을 이어가겠습니다.
워크플로우: 프롬프트 체이닝 (Workflow: Prompt chaining)
프롬프트 체이닝(prompt chaining)이란 하나의 작업을 여러 단계로 나누어 처리하는 방식입니다. 각 단계에서는 LLM이 이전 단계의 출력을 입력으로 받아 이어서 처리합니다. 또한, 중간 단계마다 프로그램적인 검사(아래 다이어그램의 “gate” 참조)를 추가해, 절차가 올바르게 진행되고 있는지 확인할 수도 있습니다.
이 워크플로우를 사용할 때: 프롬프트 체이닝은 작업을 명확하고 깔끔하게 여러 하위 과제로 쪼갤 수 있을 때 특히 유용합니다. 핵심 목적은 각 LLM 호출을 더 단순한 작업으로 만들어 정확성을 높이는 대신, 약간의 지연 시간을 감수하는 데 있습니다.
프롬프트 체이닝이 도움이 되는 대표적인 사례:
- 마케팅 카피를 생성한 뒤, 그것을 다른 언어로 번역하는 경우
- 문서 개요를 작성하고, 그 개요가 특정 기준에 맞는지 확인한 후, 해당 개요를 바탕으로 실제 문서를 작성하는 경우
워크플로우: 라우팅 (Workflow: Routing)
라우팅(routing)이란 입력을 분류한 뒤, 그 결과에 따라 적합한 후속 작업으로 연결하는 방식을 말합니다. 이 워크플로우를 사용하면 역할을 분리하고, 더 특화된 프롬프트를 설계할 수 있습니다. 만약 라우팅을 적용하지 않는다면, 특정 입력 유형에 맞춰 최적화하는 과정에서 다른 입력 유형의 성능이 떨어질 수 있습니다.
이 워크플로우를 사용할 때: 라우팅은 복잡한 작업을 명확한 카테고리로 나눌 수 있고, 각 카테고리가 별도로 처리되는 것이 더 효과적일 때 적합합니다. 또한 입력 분류를 LLM 자체나 전통적인 분류 모델·알고리즘으로 정확히 처리할 수 있는 경우에 특히 잘 맞습니다.
라우팅이 도움이 되는 대표적인 사례:
- 고객 상담 요청을 유형별(일반 문의, 환불 요청, 기술 지원 등)로 분류해 각기 다른 처리 프로세스나 프롬프트, 도구로 전달하는 경우
- 비교적 단순하고 흔한 질문은 작은 모델(예: Claude 3.5 Haiku)로 처리하고, 더 어렵거나 드문 질문은 성능이 더 뛰어난 모델(예: Claude 3.5 Sonnet)로 보내 비용과 속도를 최적화하는 경우
워크플로우: 병렬화 (Workflow: Parallelization)
때때로 LLM은 하나의 작업을 동시에 여러 곳에서 처리하도록 만들고, 그 결과를 프로그램적으로 모아낼 수 있습니다. 이러한 방식을 병렬화(parallelization)라고 하며, 대표적으로 두 가지 변형 형태가 있습니다:
- 섹셔닝(Sectioning): 작업을 독립적인 하위 과제로 쪼개어 동시에 실행하는 방식
- 보팅(Voting): 동일한 작업을 여러 번 실행해 다양한 출력을 얻는 방식
이 워크플로우를 사용할 때: 병렬화는 하위 과제를 병렬 처리하여 속도를 높이거나, 더 높은 신뢰도를 위해 여러 관점이나 시도를 확보해야 할 때 효과적입니다. 특히 다양한 요소를 고려해야 하는 복잡한 작업에서, 각각의 요소를 별도의 LLM 호출로 나누어 집중해서 다루면 성능이 더 좋아지는 경향이 있습니다.
병렬화가 유용한 사례들:
- 섹셔닝:
- 한 모델 인스턴스가 사용자 질의를 처리하는 동시에, 또 다른 인스턴스가 해당 질의에 부적절한 콘텐츠나 요청이 포함되어 있는지 검사하는 ‘가드레일(guardrails)’을 구현하는 경우. 이는 동일한 LLM 호출이 응답과 가드레일 검사를 함께 처리하는 것보다 성능이 더 우수합니다.
- LLM 성능 평가를 자동화할 때, 각 LLM 호출이 특정 프롬프트에 대한 모델 성능의 서로 다른 측면을 평가하는 경우.
- 보팅:
- 코드의 보안 취약점을 점검할 때, 여러 가지 서로 다른 프롬프트로 코드를 검토하고 문제가 발견되면 표시하는 경우.
- 특정 콘텐츠가 부적절한지 여부를 평가할 때, 여러 개의 프롬프트가 각기 다른 측면에서 검토하거나 서로 다른 투표 기준을 적용해 잘못 탐지된 사례(false positives)와 놓친 사례(false negatives)의 균형을 맞추는 경우.
워크플로우: 오케스트레이터-워커 (Workflow: Orchestrator-workers)
오케스트레이터-워커(orchestrator-workers) 워크플로우에서는 중앙 역할을 하는 LLM이 작업을 동적으로 쪼개어 여러 ‘워커’ LLM들에게 분배하고, 그 결과를 다시 종합합니다.
이 워크플로우를 사용할 때: 이 방식은 복잡한 작업인데도 미리 필요한 하위 작업들을 정확히 예측할 수 없는 경우에 적합합니다. 예를 들어 코딩에서는 몇 개의 파일을 수정해야 하는지, 또 각 파일에서 어떤 방식의 수정이 필요한지는 과제마다 달라지기 때문에 사전에 정리하기 어렵습니다. 오케스트레이터-워커 방식은 병렬화(parallelization)와 구조적으로 비슷해 보이긴 하지만, 핵심적인 차이점은 유연성입니다. 세부 작업들이 미리 고정되어 있는 게 아니라, 주어진 입력에 따라 오케스트레이터가 실시간으로 어떤 하위 작업이 필요한지를 판단합니다.
오케스트레이터-워커가 유용한 사례:
- 여러 파일에 걸쳐 복잡한 수정을 매번 수행해야 하는 코딩 작업
- 다양한 출처에서 정보를 수집하고 분석하여, 연관 가능성이 있는 내용을 종합적으로 찾아내는 검색 작업
워크플로우: 평가자-최적화자 (Evaluator-optimizer)
평가자-최적화자(evaluator-optimizer) 워크플로우에서는 한 번의 LLM 호출이 응답을 생성하고, 다른 LLM 호출이 그 응답을 평가하며 피드백을 제공하는 과정이 반복(loop)됩니다.
이 워크플로우를 사용할 때: 이 방식은 명확한 평가 기준이 존재하고, 반복적인 개선 과정이 실제로 가치를 창출할 수 있을 때 특히 효과적입니다. 적합 여부를 판단하는 두 가지 기준은 다음과 같습니다. 첫째, 사람이 피드백을 제공했을 때 LLM 응답 품질이 분명히 개선될 수 있는지. 둘째, LLM 자체가 그러한 피드백을 줄 수 있는지. 이는 사람이 글을 쓸 때 여러 차례 고쳐 나가며 더 매끄러운 최종 결과물을 완성하는 과정과 비슷합니다.
평가자-최적화자 방식이 유용한 사례:
- 문학 작품 번역처럼 번역 LLM이 처음에는 다 담아내지 못하는 뉘앙스를, 평가자 LLM이 비평과 피드백을 제공해 반영할 수 있는 경우
- 복잡한 검색 작업처럼, 충분한 정보를 수집하기 위해 여러 차례의 검색·분석이 필요할 때. 이때 평가자 LLM이 추가 검색이 필요한지 여부를 결정하는 경우
에이전트 (Agents)
에이전트는 핵심 기능들이 고도화됨에 따라 실제 프로덕션 환경에서 점차 자리 잡고 있습니다. 여기에는 복잡한 입력을 이해하는 능력, 추론과 계획을 수행하는 능력, 도구를 안정적으로 활용하는 능력, 오류에서 회복하는 능력이 포함됩니다. 에이전트는 보통 인간 사용자의 명령이나 상호적인 대화로부터 출발합니다. 작업이 명확해지면, 에이전트는 자체적으로 계획을 세우고 실행을 이어가며, 경우에 따라 추가 정보나 판단이 필요할 때 다시 사용자에게 돌아오기도 합니다. 실행 과정에서 중요한 점은, 각 단계마다 도구 호출 결과나 코드 실행 같은 환경으로부터의 실제 검증 신호(ground truth)를 확보해 진행 상황을 평가하는 것입니다. 또한 특정 지점에서 체크포인트를 두어 인간의 피드백을 받거나, 장애물을 만났을 때 중단할 수 있어야 합니다. 작업은 보통 완료 시 종료되지만, 반복 횟수 제한과 같은 종료 조건을 추가하여 전체 과정을 관리하는 방식도 흔히 쓰이는 방식입니다.
에이전트는 복잡한 과제를 수행할 수 있지만, 구현 자체는 의외로 단순한 경우가 많습니다. 대체로 에이전트는 환경에서 얻는 피드백에 따라 도구를 활용하며 루프를 도는 LLM에 불과합니다. 그렇기 때문에 사용 가능한 도구들과 해당 문서를 얼마나 명확하고 세심하게 설계하느냐가 매우 중요합니다. 도구 개발을 위한 모범 사례에 대해서는 부록 2 (Prompt Engineering your Tools)에서 더 자세히 다룹니다.
에이전트는 굉장히 복잡한 과제도 다룰 수 있지만, 아이러니하게도 구현 방식 자체는 의외로 단순한 경우가 많습니다. 흔히 보면 환경에서 피드백을 받아 도구를 활용하고, 그 과정을 루프로 반복하는 LLM 정도에 불과하죠. 그렇기 때문에 어떤 도구 셋(toolset)을 사용할지, 또 그 도구들을 어떻게 문서화할지를 명확하고 신중하게 설계하는 게 정말 중요합니다. 도구 설계와 관련된 모범 사례들은 부록 2(Prompt Engineering your Tools)에서 더 자세히 다뤘습니다.
에이전트를 언제 써야 할까?
에이전트는 필요한 단계를 미리 예측하기 어렵거나, 아예 고정된 절차를 하드코딩할 수 없는 ‘열린 문제(open-ended 문제)’에서 특히 유용합니다. 이런 경우 LLM이 여러 차례에 걸쳐 지속적으로 작업을 이어갈 수 있고, 개발자는 일정 수준 이상 모델의 의사결정을 신뢰해야 합니다. 이 자율성 덕분에 에이전트는 ‘안정적으로 신뢰할 수 있는 환경’ 안에서는 작업을 대규모로 확장하는 데 적합합니다.
물론 자율성이 있다고 해서 장점만 있는 건 아닙니다. 에이전트는 코스트가 더 들고, 작은 실수가 누적되며 큰 문제로 이어질 가능성도 있습니다. 그래서 저희는 반드시 샌드박스 환경에서 충분한 테스트를 거치고, 그 과정에 적절한 가드레일(guardrails)을 설정할 것을 권장합니다.
에이전트가 잘 쓰이는 사례들
아래 예시는 실제로 저희가 구현했던 사례들입니다:
- 여러 파일에 걸쳐 수정이 필요한 과제를 다루는 SWE-bench 태스크를 해결하는 코딩 에이전트
- Claude가 실제 컴퓨터를 사용해 작업을 수행하는 “computer use” 레퍼런스 구현
이 패턴들을 결합하고 커스터마이징하기 (Combining and customizing these patterns)
여기서 소개한 구성 요소들은 어떤 정답을 강요하는 것이 아닙니다. 흔히 쓰이는 패턴들을 다양한 활용 사례에 맞춰 개발자가 자유롭게 변형하고 조합할 수 있습니다. 다른 LLM 기능들과 마찬가지로, 성공의 핵심은 성능을 측정하고 구현을 반복 개선하는 데 있습니다. 다시 한번 강조하지만, 복잡성을 추가하는 것은 오직 결과가 명확히 개선되는 경우에만 고려해야 합니다.
요약 (Summary)
LLM 분야에서 성공을 가르는 기준은 가장 정교한 시스템을 만드는 것이 아닙니다. 진짜 중요한 것은 필요에 맞는 올바른 시스템을 설계하는 것입니다. 단순한 프롬프트부터 시작해, 충분한 평가 과정을 거쳐 이를 최적화하고, 단순한 방법으로는 한계가 있을 때에만 다단계 에이전트 시스템을 추가하는 접근이 바람직합니다.
우리가 에이전트를 구현할 때 지키려고 하는 세 가지 원칙은 다음과 같습니다:
- 에이전트 설계에서 가능한 한 단순함을 유지할 것
- 에이전트의 계획 과정을 드러내어 투명성을 확보할 것
- 신중한 도구 문서화와 테스트를 통해 에이전트-컴퓨터 인터페이스(ACI)를 꼼꼼히 설계할 것
프레임워크는 초기 개발 속도를 높이는 데 도움이 되지만, 프로덕션 단계로 갈수록 추상화 계층을 과감히 줄이고 기본 요소들을 활용하는 편이 나을 때도 있습니다. 이 원칙들을 따른다면, 강력하면서도 안정적이고 유지보수가 용이하며 사용자들이 신뢰할 수 있는 에이전트를 구축할 수 있습니다.
감사의 말 (Acknowledgements)
이 글은 Erik Schluntz와 Barry Zhang이 작성했습니다. 본 문서는 우리가 Anthropic에서 에이전트를 구축하면서 쌓은 경험, 그리고 고객들이 공유해준 소중한 인사이트를 바탕으로 쓰였으며, 이에 깊은 감사의 뜻을 전합니다.
부록 1: 실제 적용 사례 (Appendix 1: Agents in practice)
우리가 고객들과 협력하며 얻은 경험을 통해, 위에서 다룬 패턴들의 실질적인 가치를 잘 보여주는 AI 에이전트의 두 가지 주요 활용 사례를 확인할 수 있었습니다. 이 두 영역 모두, 에이전트가 대화와 실행을 함께 요구하는 작업에 가치를 더하고, 명확한 성공 기준이 존재하며, 피드백 루프를 가능하게 하고, 의미 있는 인간의 개입을 통합할 수 있을 때 가장 효과적이라는 점을 보여줍니다.
A. 고객 지원 (Customer support)
고객 지원 업무는 익숙한 챗봇 인터페이스에 도구 통합을 더해 고도화된 기능을 제공하는 형태로 발전할 수 있습니다. 이는 보다 개방적인(open-ended) 형태의 에이전트가 잘 맞는 영역인데, 그 이유는 다음과 같습니다:
- 고객 지원 대화는 기본적으로 대화 흐름을 따르면서도 외부 정보 및 액세스 권한이 필요합니다.
- 도구를 통합하면 고객 데이터, 주문 내역, 지식 베이스 기사 등을 바로 불러올 수 있습니다.
- 환불 처리나 티켓 업데이트 같은 작업은 프로그램적으로 자동 처리할 수 있습니다.
- 성공 여부는 고객이 정의한 ‘문제 해결 여부’를 기준으로 명확하게 측정할 수 있습니다.
실제로 여러 기업들이 이 접근법을 활용해, 오직 성공적으로 해결된 경우에만 비용을 청구하는 사용량 기반 과금 모델(usage-based pricing model)을 도입해왔습니다. 이는 곧 그들이 자사 에이전트의 효과에 대해 충분한 자신감을 가지고 있다는 방증이기도 합니다.
B. 코딩 에이전트 (Coding agents)
소프트웨어 개발 분야는 LLM 기능이 눈에 띄게 성장한 영역으로, 단순한 코드 완성에서부터 자체적인 문제 해결까지 그 역량이 확대되고 있습니다. 에이전트가 이 분야에서 특히 효과적인 이유는 다음과 같습니다:
- 코드 솔루션은 자동화된 테스트를 통해 검증할 수 있습니다.
- 에이전트는 테스트 결과를 피드백으로 활용해 솔루션을 반복적으로 개선할 수 있습니다.
- 문제 영역이 명확하고 체계적으로 정의되어 있습니다.
- 결과물의 품질을 객관적으로 측정할 수 있습니다.
우리의 자체 구현 사례에서는, 에이전트가 SWE-bench Verified 벤치마크에서 풀리퀘스트 설명만으로 실제 GitHub 이슈를 해결할 수 있게 되었습니다. 다만 자동화된 테스트가 기능 검증에는 도움을 주지만, 전체 시스템 요구사항에 부합하는지를 확인하기 위해서는 여전히 인간의 리뷰가 필수적입니다.
부록 2: 도구에 대한 프롬프트 엔지니어링 (Appendix 2: Prompt engineering your tools)
어떤 에이전트적 시스템을 만들든, 도구(tools)는 에이전트의 중요한 구성 요소가 될 가능성이 큽니다. 도구는 Claude가 외부 서비스 및 API와 상호작용할 수 있도록, API 내에서 정확한 구조와 정의를 명시해주어야 합니다. Claude가 도구를 호출할 계획이 있을 때는 API 응답에 도구 사용 블록(tool use block)이 포함됩니다. 도구 정의 및 사양에 대해서도 전체 프롬프트만큼이나 세심한 프롬프트 엔지니어링이 필요합니다. 이 간단한 부록에서는 도구의 프롬프트 엔지니어링 방법에 대해 설명합니다.
동일한 작업을 지정하는 여러 방법이 존재하는 경우가 많습니다. 예를 들어, 파일 수정을 지정할 때 ‘diff’를 작성하는 방법과 ‘전체 파일을 다시 쓰는’ 방법이 있습니다. 구조화된 출력을 반환할 때는 코드가 마크다운(markdown) 안에 들어가거나, JSON 포맷 안에 포함될 수도 있습니다. 소프트웨어 공학에서는 이런 차이들이 주로 외형적인 문제이며, 한 형식에서 다른 형식으로 무손실 변환이 가능합니다. 하지만 일부 포맷은 LLM이 작성하기 훨씬 더 어려울 수 있습니다. 예를 들어, diff를 작성하려면 새로운 코드가 작성되기 전에 변경된 행 수를 정확히 알아야 합니다. JSON 내에 코드를 작성하는 것은 마크다운에 쓰는 것보다 줄바꿈과 따옴표를 추가로 이스케이프 시퀀스(escape)를 사용해야 하는 부담이 있습니다.
도구 포맷을 결정할 때 저희가 권장하는 사항은 다음과 같습니다:
- 모델이 스스로 막다른 골목에 빠지기 전에 충분히 “생각”할 수 있도록 토큰을 충분히 할당하세요.
- 포맷은 모델이 인터넷 텍스트에서 자연스럽게 접했을 법한 형태와 최대한 가깝게 유지하세요.
- 수천 줄에 달하는 코드 라인 수를 정확히 세거나, 작성하는 코드 내 문자열에 추가로 이스케이프(escape) 처리를 해야 하는 등의 불필요한 형식상의 부담은 없애세요.
한 가지 경험적인 원칙은, 인간-컴퓨터 인터페이스(Human-Computer Interface, HCI)에 들이는 노력만큼 에이전트-컴퓨터 인터페이스(Agent-Computer Interface, ACI)를 만드는 데 투자해야 한다는 점입니다. 다음은 이를 위해 고려할 만한 아이디어들입니다:
- 모델 입장에서 생각해 보세요. 도구 설명과 매개변수만 보고 이 도구를 어떻게 써야 할지 명확한가요? 아니면 신중히 생각해야 할 부분이 있나요? 후자라면 모델도 마찬가지일 가능성이 큽니다. 좋은 도구 정의에는 사용 예시, 에지 케이스, 입력 형식 요구사항, 그리고 다른 도구와의 명확한 경계가 포함되는 것이 좋습니다.
- 매개변수명이나 설명을 어떻게 바꾸면 더 명확해질지 고민해보세요. 마치 팀 내 신입 개발자를 위한 훌륭한 도큐먼트 스트링(docstring)을 작성하는 것처럼 접근하는 게 유용합니다. 특히 유사한 도구를 많이 사용할 때 더욱 중요합니다.
- 도구를 모델이 어떻게 사용하는지 테스트하세요. Anthropic의 워크벤치(workbench)에서 다양한 입력 예시를 실행해 모델의 실수를 파악하고, 이를 바탕으로 개선해 나가세요.
- 포카요케(poka-yoke) 방식을 도구에 적용하세요. 매개변수를 변경해 실수하기 어렵게 만드는 겁니다.
저희가 SWE-bench 에이전트를 구축할 때는 전체 프롬프트를 다듬는 것보다 도구 최적화에 더 많은 시간을 투자했습니다. 예를 들어, 에이전트가 루트 디렉토리를 벗어난 뒤 상대 경로(relative filepath)를 포함하는 도구를 사용할 때 실수를 자주 했습니다. 이를 해결하기 위해 도구가 항상 절대 경로(absolute filepath)를 요구하도록 변경했고, 모델이 이 방법을 완벽하게 사용한다는 점을 확인할 수 있었습니다.
blog by ash에서 더 알아보기
구독을 신청하면 최신 게시물을 이메일로 받아볼 수 있습니다.
