다음 내용은 앤트로픽의 공식 홈페이지에 나와 있는 글을 한글로 번역한 내용입니다. 에이전트의 개념을 명확히 잡지 못하고 계신 분들은 이 글이 도움이 되길 바라겠습니다.

(원문 : https://www.anthropic.com/engineering/building-effective-agents)


에이전트란 무엇인가?


“Agent”라는 단어는 사람마다 조금씩 다르게 사용합니다.


어떤 사람들은 여러 도구를 사용하면서 오랜 시간 독립적으로 작업하고 복잡한 목표를 수행하는 완전 자율 시스템을 Agent라고 부릅니다.


반면 다른 사람들은 미리 정의된 작업 절차를 따라가는 시스템까지 Agent라고 부르기도 합니다.


Anthropic에서는 이런 시스템들을 넓게 Agentic System, 즉 에이전트형 시스템​이라고 부릅니다.


다만 아키텍처 관점에서는 매우 중요한 차이를 두고 있습니다.

바로 Workflow와 Agent의 차이입니다.


Workflow

Workflow는 LLM과 여러 도구가 미리 프로그래밍된 경로에 따라 움직이는 시스템입니다.

즉 개발자가 순서를 정합니다.


예를 들면 다음과 같습니다.

사용자 질문
↓
내용 분류
↓
DB 검색
↓
LLM 답변 생성
↓
결과 반환


이 순서는 미리 프로그램에 정해져 있습니다.


Agent

반면 Agent에서는 LLM이 자신이 해야 할 작업 과정과 사용할 도구를 동적으로 결정합니다.

즉 개발자가 모든 단계를 미리 정해놓지 않습니다.


LLM이 목표를 보고

“먼저 파일을 찾아봐야겠다.”

“이 파일을 수정해야겠다.”

“수정했으니 테스트를 돌려봐야겠다.”

“테스트가 실패했네. 오류 메시지를 읽어보자.”

“원인을 찾았으니 코드를 다시 고쳐야겠다.”

와 같은 판단을 스스로 내립니다.


즉 목표는 사람이 주지만, 목표를 달성하는 과정은 AI가 결정합니다.


Agent를 언제 사용해야 하는가?


LLM 애플리케이션을 만들 때는 가능한 한 가장 단순한 해결책부터 시작하는 것이 좋습니다.


필요한 경우에만 복잡성을 높여야 합니다.


따라서 모든 문제에 Agent를 사용할 필요는 없습니다.


Agent 시스템은 보통 더 나은 작업 수행 능력을 얻는 대신 다음 비용을 지불하게 됩니다.

  1. 응답 시간이 길어질 수 있습니다.
  2. API 비용이 증가할 수 있습니다.
  3. 시스템이 복잡해집니다.
  4. 실수가 여러 단계에 걸쳐 누적될 가능성이 있습니다.


작업 절차가 명확하게 정의되어 있다면 Workflow가 더 예측 가능하고 안정적입니다.


반대로 상황에 따라 판단해야 하고 정해진 경로를 만들기 어려운 문제라면 Agent가 적합합니다.

많은 애플리케이션에서는 Agent까지 만들지 않아도 단일 LLM 호출에 검색 기능이나 예제 등을 추가하는 것만으로 충분할 수 있습니다.


Agent 프레임워크는 꼭 필요한가?


Agentic System을 만드는 데 도움을 주는 여러 프레임워크가 있습니다.


예를 들어 다음과 같은 것들이 있습니다.

  1. Claude Agent SDK
  2. AWS Strands Agents SDK
  3. Rivet
  4. Vellum

이러한 프레임워크는 LLM 호출, Tool 정의, 결과 파싱, 여러 LLM 호출 연결 등의 작업을 쉽게 만들어줍니다.


하지만 문제가 있습니다.


프레임워크가 너무 많은 추상화 계층을 만들면 실제로 LLM에게 어떤 Prompt가 전달되고 어떤 응답이 돌아오는지 알기 어려워질 수 있습니다.


결과적으로 디버깅도 어려워집니다.


또한 프레임워크를 사용하다 보면 사실 단순하게 해결할 수 있는 문제를 필요 이상으로 복잡하게 만드는 경우도 있습니다.


Anthropic은 개발자에게 가능하면 처음에는 LLM API를 직접 사용해보는 것을 권장합니다.

많은 패턴은 몇 줄의 코드만으로도 구현할 수 있습니다.


프레임워크를 사용하더라도 내부에서 실제로 무엇이 일어나는지는 이해해야 합니다.


Agentic System의 가장 기본적인 요소


가장 기본적인 구성요소는 Augmented LLM, 즉 기능이 확장된 LLM입니다.


일반적인 LLM에 다음과 같은 기능을 붙인 형태입니다.

LLM
+
검색(Retrieval)
+
도구(Tools)
+
메모리(Memory)


현대의 LLM은 이런 기능을 단순히 제공받는 것에 그치지 않습니다.


스스로 검색어를 만들고, 적절한 도구를 선택하고, 어떤 정보를 기억할지 판단할 수 있습니다.


예를 들어 사용자가

“우리 프로젝트에서 로그인 오류의 원인을 찾아서 수정해줘.”

라고 요청했다고 가정해보겠습니다.


LLM은 다음과 같이 움직일 수 있습니다.


프로젝트 파일 검색
↓
로그인 관련 코드 찾기
↓
파일 읽기
↓
문제 추론
↓
코드 수정
↓
테스트 실행
↓
테스트 결과 확인


이런 능력이 Agent의 기반이 됩니다.


Workflow 패턴 1: Prompt Chaining


Prompt Chaining은 하나의 작업을 여러 단계로 나누는 방법입니다.

각 LLM의 출력 결과를 다음 LLM의 입력으로 전달합니다.


예를 들어

문서 작성
↓
조건 검사
↓
문서 수정
↓
최종 문서 생성

과 같은 방식입니다.


각 단계 중간에는 프로그램을 이용한 검증 단계를 넣을 수도 있습니다.


이 방식은 작업을 명확한 하위 작업으로 나눌 수 있을 때 적합합니다.


예를 들어 다음과 같은 작업입니다.

  1. 마케팅 문구 작성 후 다른 언어로 번역하기
  2. 문서 목차를 만들고 조건을 검사한 다음 본문 작성하기


Workflow 패턴 2: Routing


Routing은 사용자의 요청을 분류한 다음 적절한 처리 과정으로 보내는 방법입니다.


고객센터를 생각하면 쉽습니다.

고객 문의
↓
분류
↙ ↓ ↘
일반 환불 기술지원


환불 문의는 환불 전문 처리 과정으로 보내고,

기술 문의는 기술지원용 Prompt와 Tool로 보내는 방식입니다.


또한 간단한 질문은 저렴한 모델로 보내고 복잡한 질문은 더 강력한 모델로 보내는 방식도 Routing의 예입니다.


Workflow 패턴 3: Parallelization


여러 LLM 작업을 동시에 실행하는 방법입니다.


크게 두 가지 형태가 있습니다.


Sectioning

큰 작업을 서로 독립적인 작은 작업으로 나눈 다음 병렬로 실행합니다.


예를 들어 코드 보안 검사를 한다면

코드
│
┌────────┼────────┐
↓ ↓ ↓
보안 검사 성능 검사 품질 검사
│ │ │
└────────┼────────┘
↓
결과 종합

과 같이 처리할 수 있습니다.


Voting

동일한 문제를 여러 번 실행한 다음 결과를 비교합니다.

예를 들어 여러 LLM이 각각 코드의 보안 취약점을 검사하고 다수의 모델이 문제라고 판단한 부분을 최종 결과로 사용할 수 있습니다.



Workflow 패턴 4: Orchestrator-Workers


이 패턴에서는 하나의 중앙 LLM이 전체 작업을 관리합니다.


중앙 LLM을 Orchestrator, 작업을 수행하는 LLM을 Worker​라고 합니다.


구조는 다음과 같습니다.

Orchestrator
│
┌──────────┼──────────┐
↓ ↓ ↓
Worker 1 Worker 2 Worker 3
│ │ │
└──────────┼──────────┘
↓
결과 통합


중요한 특징은 Worker가 수행할 작업이 미리 정해져 있지 않다는 것입니다.


Orchestrator가 입력된 문제를 보고 즉석에서 작업을 나눕니다.

예를 들어

“이 프로젝트의 인증 방식을 OAuth2로 바꿔줘.”

라는 요청이 들어왔다고 하겠습니다.


Orchestrator가 프로젝트를 살펴본 뒤


Worker 1 → 백엔드 인증 코드 수정
Worker 2 → 프론트엔드 로그인 수정
Worker 3 → 테스트 코드 수정
Worker 4 → 문서 수정

처럼 작업을 나눌 수 있습니다.


특히 여러 파일을 수정해야 하는 복잡한 코딩 작업이나 여러 출처에서 정보를 찾아야 하는 검색 작업에 유용합니다.


Workflow 패턴 5: Evaluator-Optimizer


하나의 LLM은 결과를 만들고 다른 LLM은 결과를 평가합니다.

작성 LLM
↓
결과 생성
↓
평가 LLM
↓
피드백
↓
다시 작성

이 과정을 반복하면서 결과를 개선합니다.

번역이나 복잡한 검색 작업처럼 여러 번 수정하면서 품질이 좋아지는 문제에 효과적입니다.


그리고 진짜 Agent


Agent는 LLM이 충분히 발전하면서 실제 서비스 환경에서도 사용되기 시작했습니다.


Agent가 제대로 동작하려면 몇 가지 능력이 필요합니다.

  1. 복잡한 입력 이해
  2. 추론
  3. 계획 수립
  4. Tool 사용
  5. 오류 발생 시 복구


Agent는 보통 사용자에게 명령을 받거나 사용자와 대화를 나누면서 작업을 시작합니다.


목표가 명확해지면 Agent는 스스로 계획을 세우고 작업합니다.

필요한 경우 다시 사용자에게 질문하거나 판단을 요청할 수도 있습니다.


Agent에서 특히 중요한 것은 작업 도중 계속 현실 세계의 결과, 즉 Ground Truth를 확인하는 것​입니다.


예를 들어 코딩 Agent라면

코드 수정
↓
테스트 실행
↓
테스트 결과 확인
↓
실패
↓
오류 분석
↓
다시 수정
↓
테스트
↓
성공

처럼 환경에서 실제 결과를 받아서 다음 행동을 결정합니다.

결국 Agent는 의외로 단순한 구조로 볼 수 있습니다.


LLM이 Tool을 사용하고, 그 결과를 다시 보고, 다음 행동을 결정하는 과정을 반복하는 시스템입니다.


Agent는 언제 사용하면 좋은가?


Agent는 필요한 작업 단계를 미리 예측하기 어려운 문제에서 특히 효과적입니다.


예를 들어

“이 GitHub Issue를 해결해줘.”

라는 요청을 생각해 보겠습니다.


어떤 파일을 수정해야 하는지 미리 알 수 없습니다.

한 개의 파일일 수도 있고 20개의 파일일 수도 있습니다.

테스트가 한 번에 통과할 수도 있고 여러 번 수정해야 할 수도 있습니다.

이런 문제는 고정된 Workflow를 만들기가 어렵습니다.


따라서 Agent에게 목표를 주고 스스로 해결 방법을 찾게 하는 것이 적합합니다.


하지만 Agent는 자율성이 높은 만큼 비용이 증가하고 오류가 누적될 수 있습니다.


따라서 Anthropic은 Sandbox 환경에서 충분히 테스트하고 적절한 Guardrail을 적용하는 것을 권장합니다.


Agent가 특히 유용한 예

Anthropic이 실제로 사용한 대표적인 사례 중 하나가 Coding Agent입니다.


예를 들어 SWE-bench 문제에서는 Agent가 작업 설명을 읽고 여러 파일을 수정하여 실제 소프트웨어 문제를 해결합니다.


또 다른 사례는 Computer Use입니다.

Claude가 컴퓨터를 직접 조작하면서 사용자가 요청한 작업을 수행합니다.


여러 패턴은 함께 사용할 수 있습니다


지금까지 소개한 패턴은 반드시 하나만 선택해야 하는 규칙이 아닙니다.


실제 시스템에서는 여러 방식을 조합할 수 있습니다.


중요한 것은 가장 복잡한 시스템을 만드는 것이 아닙니다.

현재 문제를 해결하는 데 필요한 만큼만 복잡하게 만드는 것입니다.


먼저 단순한 Prompt부터 시작하고 충분히 평가해보는 것이 좋습니다.

그리고 단순한 방식으로 해결할 수 없을 때만 Workflow나 Agent를 추가하는 것이 좋습니다.


Anthropic이 제안하는 Agent 설계의 세 가지 원칙


Anthropic은 Agent를 만들 때 크게 세 가지 원칙을 권장합니다.


1. 단순하게 만드세요

필요 이상으로 복잡한 Agent 구조를 만들지 않는 것이 좋습니다.


2. 투명하게 만드세요

Agent가 어떤 계획을 세우고 어떤 작업을 하고 있는지 확인할 수 있도록 만드는 것이 중요합니다.


3. Tool을 잘 설계하세요

Agent와 컴퓨터 사이의 인터페이스를 잘 설계해야 합니다.

사람과 컴퓨터 사이의 인터페이스를 HCI, 즉 Human-Computer Interface라고 부른다면

Anthropic은 Agent와 컴퓨터 사이의 인터페이스를 ACI, Agent-Computer Interface​라고 표현합니다.


Agent가 Tool을 정확하게 사용할 수 있도록 Tool 이름, Parameter, 설명, 입력 형식, 예외 상황 등을 명확하게 설계해야 합니다.


Anthropic은 실제 SWE-bench Agent를 만들 때 전체 Prompt보다 Tool을 개선하는 데 더 많은 시간을 투자하기도 했습니다.


결론


LLM 시스템에서 성공의 핵심은 가장 정교하고 복잡한 시스템을 만드는 것이 아닙니다.

자신의 문제에 맞는 적절한 시스템을 만드는 것입니다.


먼저 단순한 Prompt부터 시작하고,

필요하면 Retrieval과 Tool을 추가하고,

그다음 Workflow를 사용하고,

정말 필요한 경우 Agent를 도입하는 방식이 좋습니다.


Agent의 핵심은 생각보다 단순합니다.


LLM에게 목표와 Tool을 제공하고, LLM이 환경의 결과를 확인하면서 스스로 다음 행동을 선택하도록 만드는 것.


이것이 Anthropic이 이야기하는 Agent의 핵심입니다.