복잡한 프레임워크는 이제 그만: 실용적인 LLM 에이전트 시스템 설계 가이드

LLM을 활용한 기능이나 서비스를 만들려다 보면 이런 고민에 마주하게 됩니다. “도대체 어디까지 복잡하게 설계해야 하지?”, “프레임워크는 꼭 필요한가?”, “에이전트가 필요한 건 맞을까?”

이 글은 그런 고민을 하고 있는 실무자를 위한 안내서입니다. Anthropic이 여러 산업군과 함께 다양한 LLM 시스템을 구축하며 얻은 실제 경험을 바탕으로, 언제 단순한 워크플로우로 충분한지, 언제 복잡한 에이전트 구조가 필요한지, 각각 어떤 방식으로 구현할 수 있는지를 체계적으로 정리합니다.

복잡한 시스템이 항상 정답은 아닙니다. 단순한 방식이 성능까지 좋을 수 있다면, 그것이 바로 최적의 선택입니다.

반응형

LLM 기반 에이전트 시스템이란?

LLM 기반 시스템을 크게 두 가지 유형으로 나눌 수 있습니다.

• 워크플로우 시스템: 정해진 흐름대로 모델과 도구를 연결하는 구조입니다. 예측 가능하고, 처리 속도와 비용 면에서도 유리합니다.
• 에이전트 시스템: LLM이 스스로 작업 흐름을 결정하고 도구를 사용하며 문제를 해결합니다. 유연성과 확장성은 뛰어나지만, 더 많은 자원과 복잡한 설계가 필요합니다.

모든 문제에 에이전트를 쓸 필요는 없습니다. 핵심은 목적에 맞는 적절한 구조를 선택하는 것입니다.

언제 에이전트를 써야 할까?

다음과 같은 기준으로 판단할 수 있습니다.

• 단일 프롬프트 호출로 해결 가능 → 워크플로우도 필요 없음
• 작업 단계가 정해져 있고 예측 가능 → 워크플로우가 적합
• 작업 흐름을 사전에 정의하기 어렵고, 매 순간 판단이 필요한 경우 → 에이전트 구조가 유리

예: 고객 지원, 복잡한 코드 변경, 정보 수집 자동화 등은 에이전트 구조가 효과적입니다.

에이전트 시스템 구현 워크플로우 6가지

아래는 Anthropic이 실제 프로젝트에서 자주 사용한 워크플로우 유형 6가지를 구조, 작동 방식, 적합한 사용 사례로 나눠 설명한 내용입니다.

---

1. 프롬프트 체이닝 (Prompt Chaining)

구조
작업을 여러 단계로 나누고 각 단계마다 LLM을 호출합니다.
이전 단계의 출력을 다음 단계의 입력으로 사용하며, 각 단계를 명확하게 분리할 수 있습니다.

예시

• 마케팅 문구 작성 → 기준 검토 → 다국어 번역
• 문서 개요 작성 → 개요 검토 → 본문 작성

언제 사용하나

• 각 작업이 명확히 분리되고 순차적으로 처리되는 경우
• 높은 정확도가 필요한 경우, 작은 단위로 쪼개 작업함으로써 전체 품질을 개선

---

2. 라우팅 (Routing)

구조
입력을 분석하여 적절한 경로(프롬프트/모델/도구)로 분기합니다.
일종의 분류 시스템으로, 이후 작업의 성격에 따라 맞춤형 처리를 할 수 있게 만듭니다.

예시

• 고객 질문을 환불, 기술 지원, 일반 문의로 분류
• 간단한 질문은 소형 모델로, 복잡한 질문은 대형 모델로 라우팅

언제 사용하나

• 다양한 유형의 입력이 들어오고, 각각을 다른 방식으로 처리할 필요가 있을 때
• 성능과 비용 최적화를 동시에 추구할 때

---

3. 병렬 처리 (Parallelization)

구조
하나의 작업을 병렬로 나누어 동시에 여러 LLM 호출을 실행합니다.
출력을 수합하거나, 다수 결과를 기반으로 평가하거나 조합합니다.

두 가지 방식

• Sectioning: 작업을 파트별로 나눠 병렬 처리
• Voting: 동일 작업을 여러 번 수행하여 다수결이나 품질 판단에 활용

예시

• 하나의 문서를 파트별로 나눠 병렬 요약
• 코드 보안 점검 시, 여러 프롬프트로 같은 코드를 분석해 취약점 발견율 향상

언제 사용하나

• 작업을 나눠 처리해 속도를 높이거나
• 다양한 관점을 취합해 더 높은 품질을 도출하고 싶을 때

---

4. 오케스트레이터-워커 (Orchestrator-Workers)

구조
중앙 LLM(오케스트레이터)이 입력을 분석하고, 하위 LLM(워커)에게 세부 작업을 배정합니다. 결과를 종합해 최종 응답을 생성합니다.

예시

• 코드 수정 요청 시, 오케스트레이터가 어떤 파일을 수정할지 판단하고
  워커 LLM이 각각 파일의 변경 작업 수행

언제 사용하나

• 작업이 복잡하고, 하위 작업이 상황에 따라 달라질 때
• 반복적인 병렬 작업이 아닌, 매번 새로운 구조적 판단이 필요한 경우

---

5. 평가자-최적화자 루프 (Evaluator-Optimizer)

구조
첫 번째 LLM이 작업 결과를 생성하고, 두 번째 LLM이 그 결과를 평가하고 피드백을 제공합니다. 피드백을 기반으로 결과를 반복 개선합니다.

예시

• 문학 번역: 초기 번역 → 평가 → 수정 → 재평가
• 검색 결과 요약: 요약 → 검토 → 추가 검색 여부 결정

언제 사용하나

• 평가 기준이 명확하고, 반복을 통해 품질이 개선될 수 있는 작업
• 사람이 리뷰하는 방식과 유사한 흐름을 자동화하고자 할 때

---

6. 자율 에이전트 (Autonomous Agents)

구조
작업 목표를 받은 후, 필요한 도구 사용, 판단, 반복 실행을 LLM이 스스로 수행합니다.
중간에 사용자 피드백을 받거나, 조건에 따라 실행을 중단하기도 합니다.

예시

• SWE-bench 수준의 실제 코드 이슈 해결
• 컴퓨터 사용 시나리오에서 웹 검색, 분석, 응답 생성을 반복 수행

언제 사용하나

• 정해진 흐름 없이 자유로운 판단이 필요한 경우
• 과제가 복잡하고, 단계 수를 예측할 수 없는 문제
• 일정 수준의 판단 신뢰성을 확보할 수 있는 상황

---

프레임워크 vs 직접 구현: 어떤 선택이 옳을까?

처음에는 가능한 한 직접 구현하는 것이 좋습니다. API 호출 몇 줄만으로도 많은 패턴을 구현할 수 있습니다. 복잡한 프레임워크는 오히려 디버깅을 어렵게 만들고, 구조를 파악하기 어렵게 만들 수 있습니다.

도움이 될 수 있는 프레임워크:

• LangGraph (LangChain 기반)
• Amazon Bedrock AI Agent
• Rivet, Vellum 등 GUI 기반 툴

프레임워크를 쓴다면 반드시 내부 작동 방식을 충분히 이해하고 사용할 것을 권장합니다. 겉보기 간단함에 속아 구조를 모른 채 사용하는 것은 가장 흔한 오류 원인입니다.

---

성공적인 에이전트 시스템 설계를 위한 3가지 원칙

1. 심플하게 시작하라
   처음부터 복잡한 구조를 설계하지 말고, 최소 기능부터 시작해 성능이 필요할 때 확장하세요.
2. 에이전트의 계획을 명시하라
   에이전트가 어떤 판단을 통해 어떤 도구를 사용했는지 추적 가능하게 만들면 디버깅이 쉬워집니다.
3. 도구 인터페이스를 명확히 하라 (Agent-Computer Interface, ACI)
   도구의 입력, 출력, 제약 조건을 명확히 정의하고 예시까지 제공하면 에이전트가 훨씬 안정적으로 작동합니다.

---

728x90

실무에서 어떻게 접근해야 할까?

에이전트를 만든다는 건 결국, 적절한 복잡성을 선택하는 것입니다. 처음부터 완벽한 구조를 만들려고 애쓰기보다, 다음과 같은 접근을 추천합니다.

• 단일 LLM 프롬프트로 먼저 해결 가능한지 확인하세요.
• 필요할 경우 워크플로우 패턴부터 도입하세요.
• 더 복잡한 작업에는 병렬 처리, 오케스트레이터 구조를 고려하세요.
• 반복 개선이 필요한 과제에는 평가자-최적화자 루프가 유효합니다.
• 예측 불가능하고 유연한 판단이 필요한 경우에만 에이전트 구조를 선택하세요.

모든 것을 자동화하려 하지 마세요. 때로는 단순함이 최고의 성능을 이끕니다.

Building Effective AI Agents \ Anthropic

Building Effective AI Agents