Skip to content

Agent by Anthropic

Anthropic 에서 Agent와 관련된 흥미로운 글을 하나 올려서 이를 보고 재해석 합니다. (참조 - https://www.anthropic.com/research/building-effective-agents)

글을 아주 간단하게 요약하면,

Anthropic 이 본인들 시스템, 그리고 고객들의 시스템을 Agent 개념으로 구현하면서 정리한 내용입니다.

Agent 에 대한 정의가 사람마다, 기관마다 다 다릅니다. 앞선 도입부에서는 LangGraph가 정의한 "Agentic System" 에 대해 이야기를 해 보았는데, Anthropic 에서는 어떻게 바라보고 있는지 한번 보겠습니다.

Anthrophic의 Agent 정의

  • 여러 도구를 활용해 복잡한 작업을 스스로 해결하고 오래 동작하는, 완전 자율적인 시스템을 에이전트라 부르기도 하고, 미리 정해진 workflow를 따르는 모델 중심의 flow를 에이전트라 부르기도 합니다.
  • Anthropic에서는 이러한 모든 경우를 ‘agentic system’이라고 보고 그 안에서, 두 가지로 구분합니다.
  • Workflow
    • LLM과 도구들이 미리 정해진 코드 흐름에 맞춰 동작하는 것
    • 아래에서 보다 자세하게 설명하겠지만, RAG, Tool Use, Prompting chaining 과 같은 수 많은 LLM Application이 여기에 해당됩니다.
  • Agent
    • LLM이 동적으로 스스로 프로세스와 도구 사용을 결정
    • 작업을 해결하는 방법과 순서를 모델이 직접 결정하고 통제

Anthropic의 Agentic system 이 LangGraph의 Agentic System 이네요. 정의가 비슷합니다. 그 중에서도 LLM 이 자체판단하는 로직이 추가된 경우에 Agent라고 더 좁혀서 부르는 군요.

Agent는 언제 써야할까요?

  • LLM으로 애플리케이션을 만들 때는 가능한 간단한 접근부터 시도하고, 정말 필요할 때만 복잡도를 높이는 걸 추천합니다.
  • 에이전트 시스템은 지연(latency)과 비용을 더 들여서 성능을 높이려는 목적일 때 쓰는 것이죠.
  • 미리 정해진 작업(규칙이 명확한 작업)에는 workflow가 예측 일관적인 대답을 내놓으니 더 좋습니다.
  • 복잡한 의사결정이나 유연성이 중요한 규모가 큰 작업을 할 때나 Agent가 필요한 것입니다.
  • 대부분의 경우, 정보 검색 + 단일 LLM 호출 정도로 충분할 때가 많으니 먼저 간단하게 시작하세요.

Simple is the best!

Frameworks

  • 에이전트 개발을 쉽게 만들어주는 다양한 프레임워크가 존재합니다. ( LangChain의 LangGraph, Amazon Bedrock의 AI Agent, Rivet, Vellum 등)
  • 이런 프레임워크는 기본적인 LLM 호출, tool use, chaining calls 등을 간단히 해줘서 시작하기 편리합니다.
  • 추상화 레이어가 많아질수록 실제 프롬프트와 응답을 디버그하기 어려워지죠.
  • 가장 간단한 코드로 직접 LLM API를 다뤄보는 것을 권장합니다. 프레임워크를 쓸 경우에도 내부 동작을 충분히 이해해야 합니다.

LangChain이 공격받는 대표적인 문제를 꼽네요. 불필요한 Abstraction과 디버깅의 어려움 가중. 저도 직접 개발하면서 느낌 점입니다. rivet, vellum 같은 gui 도구들을 훨씬 더 심하겠죠. LangGraph는 진입장벽이 높은 만큼 위의 문제가 덜한 편이긴 합니다. Studio로 디버깅도 편하고요.

Building Blocks, Workflows, Agents

이제 실제로 에이전트 시스템을 구성하는 전형적인 패턴들을 살펴보겠습니다.

1. 빌딩 블록: Augmented LLM

  • 가장 기본이 되는 요소는 LLM + 부가 기능(검색, 도구 사용, 메모리 등)을 결합한 구조입니다, 현재의 ChatGPT 가 거의 이 구조에 부합하는 것 같군요.
  • RAG, Search, Memory, 기타 가장 기본적인 구조에 해당합니다, 이것도 Agentic System 에 포함시킵니다.

2. Workflows

아래와 같은 다양한 패턴들을 모두 Workflows로 분류합니다. - Prompt Chaining - Routing - Parallelization - Orchestrator-Workers - Evaluator-Optimizer

인상적인 구조 몇개만 그림을 첨부합니다.

Prompt Chaining 입니다. 일반적으로 시퀀셜하게 task를 쪼개서 행하는 작업이죠. 충분히 납득이 잘 갑니다.

Evaluator-Optimizer 입니다. evaluator 가 (일반적으로) LLM 이니까 LLM 이 control flow를 결정하게 되는데, 이를 workflow로 구분을 했군요. 보다 LLM 이 많은 것을 컨트롤 해야 Agent로 취급을 합니다.
검색 과정에서 추가 검색이 더 필요한지 판단을 하고 되돌려 일을 더 시키는 경우 같은 예시를 생각할 수 있습니다.

3. Agents

Anthropic의 Agent는 모델이 작업 목표(명령 또는 사용자의 대화)를 받고, 스스로 계획을 세워 여러 단계와 도구 활용을 반복하며 결과를 완성하는 것을 지칭합니다. 중요 포인트로는 아래와 같은 요소가 있습니다. - 각 단계에서 환경(도구 호출 결과, 코드 실행 결과 등)의 실제 정보를 피드백받아 판단 - 필요하면 중간에 사람에게 추가 정보를 요청하거나, 피드백을 받아 수정 - 반복 횟수나 에러 시 중단 등 제어 장치를 두어야 함

Planning, Human-in-the-loop 과 같은 개념이 눈에 띄는 군요. 조금 더 나아가 LLM 이 자유도를 가지는 Agentic 시스템이라고 보는게 맞겠습니다.

정확하게 Computer Use Demo 가 이 예시에 해당하는 군요. 본인의 환경 (Computer Use) 를 들고, human 과 상호작용을 하면서 필요한 만큼 일을 하다가 멈추는 것이죠.

요약 및 결론

LLM 프로젝트에서 성공의 핵심은 “가장 복잡하지 않은 올바른 솔루션”을 찾는 것이라고 합니다. 그래서 아래와 같이 접근하는 것을 추천합니다.
1. 가능한 한 간단한 단일 LLM 호출(프롬프트)부터 시작
2. 꼼꼼하게 성능을 측정하고 평가
3. 더 필요한 경우에만 에이전트와 같은 복잡한 구조를 도입

에이전트를 구현할 때는 세 가지 원칙을 기억하자: 1. 단순성: 최소한의 설계
2. 투명성: 에이전트의 계획 단계를 명시적으로 드러내고 확인 가능하도록
3. 도구 설계(Agent Computer Interface) 주의: 에이전트가 활용하는 도구에 대한 문서를 구체적으로 작성하고 잘 테스트하기

LangGraph와 같은 프레임워크는 진입 장벽을 낮춰 초기 시도에 도움을 주지만, 직접 low-lever 구현으로 내려가 보는 것을 추천합니다.

현재 대부분의 실제 개발자들이 LangChain에서 LangGraph로 한 단계 더 내려가는 상황이라고 생각이 됩니다. LangGraph도 충분히 low-level 하기 때문에, 장벽이 꽤나 있고 대부분의 것들을 구현, 관찰, 디버깅, 유지/보수 할 수 있습니다. Anthropic은 물론 선두 기업 중 하나이니, 더욱 더 내려가서 직접 더 많은 것들을 구현하는 것을 추천하네요.

Agent라는 개념이 이제 막 정립되고 토론이 되고 있다보니, 다양한 집단에서 어떻게 바라보고 있는지 궁금했습니다. 실제로 많은 분들이 다른 의미로 많이 사용하고 계시고요. (특히 아무거나 다 그냥 똑똑해 보이면 동작 원리랑 상관없이 Agent 라고 과대광고 하시는 분들이 많더라고요.) 적어도 LangGraph와 Anthropic은 같은 방향을 바라보고 있는 것 같고, 이것이 가장 큰 흐름이겠죠.

많은 분들이 Agent 에 대해 보다 명확한 이해가 되셨기를 바랍니다.