Post-IT
Building effective agent 본문
Agent는 뭘까?
에이전트는 사람들마다 정의하는 방식이 조금씩 다릅니다. "혼자 알아서 일하는 AI" 혹은 "정해진 순서대로 일하는 AI"와 같이 다양하게 정의됩니다. Anthropic에서는 이를 Workflows와 Agents 두가지로 분류합니다.
- Workflows : 요리 레시피처럼 정해진 순서대로 일합니다. 프로그래머가 지시한 대로 따라갑니다.
- Agents : AI가 스스로 판단하며 일합니다. "이 문제를 해결해줘"라고 지시하면 how를 스스로 결정합니다.
Workflow는 주어진 길을 따라간다면, Agent는 스스로 길을 찾아가죠.
언제 Agent를 사용해야 할까?
LLM 애플리케이션을 만들 때 처음부터 복잡한 에이전트 시스템을 만들 필요는 없습니다. 에이전트 시스템은 좋은 성능을 내기는 하지만, 그만큼 시간과 비용이 많이 듭니다. 교환가치가 있는지 충분히 생각해볼 필요가 있습니다. 단순한 LLM을 호출해야 하는 경우에는 굳이 다른 방법을 생각할 필요가 없습니다. 정해진 작업을 예측 가능하고 일관된 처리가 필요할 때는 워크플로우로 충분하죠. 작업에 유연성이 필요할 때 비로소 Agent 도입에 대해 고민해볼 필요가 생깁니다.
LLM 호출 -> Workflow -> Agent 순서로 고민을 확장하는 것이 좋습니다.
어떤 프레임워크들을 언제 사용해야 할까?
LangGraph, Amazon Bedrock, Rivet, Vellum 다양한 프레임워크들이 존재합니다. 귀찮은 기본 작업들을 자동으로 처리해줘서 너무 좋습니다. 하지만, 너무 많이 추상화 되어 있어 레이어 내부에서 무슨 일이 일어나는지 보기 어려워집니다. 또, 간단하게 해결될 문제도 괜히 복잡하게 되기 쉽죠.
처음부터 프레임워크를 마구잡이로 사용하려 하지마세요. LLM API를 직접 사용해 보세요. 꽤 많은 부분은 단 몇 줄의 코드로도 구현이 가능합니다. 그냥 알아서 해주겠지가 아닌, 프레임워크 사용 시에도 내부 동작 원리는 반드시 이해가 필요합니다.
Building Blocks, Workflows, Agents
에이전트 시스템의 일반적인 패턴을 살펴보겠습니다. 가장 기본적인 것 부터 복잡한 구조로 설명하겠습니다.
기본: Augmented LLM
에이전트 시스템의 기본은 아래 기능들로 강화된 LLM입니다.
- Retrieval : 필요한 정보들을 찾음
- Tools : 외부 도구를 사용
- Memory : 정보를 기억하
현재 Claude 같은 모델들이 이런 것들을 스스로 할 수 있습니다. 스스로 검색어를 만들고 적절한 도구를 선택하며 정보를 기억합니다. 구현할 때 중요한 두가지가 존재합니다.
- 사용 사례에 맞게 맞춤화
- LLM이 쉽게 사용할 수 있도록 잘 정리된 인터페이스 제공
💡MCP 활용
이런 기능들을 구현하는 좋은 방법 중 하나가 바로 MCP(Model Context Protocol)입니다.
Workflow : 프롬프트 체이닝(Prompt Chaining)
프롬프트 체이닝은 하나의 작업을 여러 단계로 쪼개서 순차적으로 처리하는 방식입니다. 각 단계의 결과가 다음 단계의 입력이 됩니다.
- LLM 호출 -> 결과 확인
- 다음 LLM 호출 -> 결과 확인
- 다음 LLM 호출 -> 결과 확인
이렇게 순차적으로 진행하면서 제대로 진행되고 있는지 확인할 수 있습니다. 이 방식은 다음과 같은 경우에 사용하면 좋습니다.
- 작업을 명확하게 단계로 나눌 수 있을때
- 시간은 지연되지만 정확도를 높이고 싶을 때
- 각 LLM 호출이 더 쉬운 작업을 하다록 만들어 성공률을 높이고 싶을 때
Workflow : 라우팅(Routing)
라우팅은 입력을 분류해서 적절한 전문가에게 보내는 방식입니다. 진료받고 싶은 부분에 따라 내과, 외과, 졍형외과에 가는 것처럼 말이죠. 입력이 들어오면 어떤 것인지 파악하고 적합한 도메인으로 연결해주는 방식입니다.각 도메인 별로 특화된 프롬프트나 도구를 사용할 수 있습니다. 만약 라우팅 없이 하나의 프롬프트로 모든 것을 처리한다면 각 도메인에 따라 최적화가 불가능해 도메인 모두의 성능이 떨어질 수 있습니다. 라우팅 방식은 다음과 같은 케이스에서 사용된다고 합니다.
- 명확하게 구분되는 카테고리들이 존재할 때
- 각 카테고리를 별도로 처리하는 게 더 좋을 때
- 입력을 정확하게 분류할 수 있을 때
Workflow : 병렬화(Parallelization)
병렬화는 여러 LLM이 동시에 작업하고, 그 결과를 나중에 합치는 방식입니다. 작업 자체를 나누거나, 같은 작업을 여러번 나누는 방식이 있습니다.
- Sectioning : 큰 작업을 여러 태스크로 나눠서 동시에 처리합니다.
- Voting : 같은 작업을 여러번 실행해서 다양한 결과를 가지고 비교합니다.
방식이 두 가지 존재하는데 언제 사용하는 것이 좋을까요??
- 속도가 중요할 때 두 방식이 모두 유효합니다.
- 여러 관점이 필요하거나 높은 신뢰도의 경우에는 Voting을 사용하는 것이 좋아보입니다.
- 작업이 복잡하여 각 측면에 집중이 필요할 때는 Sectioning이 유리해 보입니다.
Workflow : 오케스트레이터-워커(Orchestrator-Workers)
오케스트레이터-워커는 이름에서도 알 수 있듯이, 중앙 지휘자가 작업을 분석하고 워커들에게 동적으로 일을 나눠주고 종합하는 방식입니다.
- 오케스트레이터가 작업 A,B,C를 요구한다.
- 워커가 각 작업을 수행한다.
- 결과를 모아 최종 답변을 생성한다.
병렬화와 매우 유사하지만 그 의미가 약간 다릅니다. 병렬화는 정해진 작업을 나누는 개념이라면, 오케스트레이터-워커는 작업에 따라 동적으로 판단하고 결정합니다. 그러면 언제 사용하면 좋을까요?
- 하위 작업을 미리 예측할 수 없을 때
- 작업의 복잡도와 범위가 입력에 따라 달라질 때
- 유연한 대응이 필요할 때
Workflow : 평가자 - 최적화자(Evaluator-Optimizer)
평가자 최적화자는 하나의 LLM 답변을 만들면, 다른 LLM이 평가하고 피드백을 주는 방식입니다. 이걸 반복하면서 성능을 개선하는 방식이죠.
- Optimizer : 초안 작성
- Evaluator : 수정 요구
- Optimizer : 피드백 반영/수정
- Evaluator : 재평가
- 위 루프를 조건을 만족할때까지 반복
이 방식은 명확한 평가 기준이 있을 때 사용해야합니다. 반복적인 개선이 실제로 도움이 되어야 하죠.
에이전트(Agents)
에이전트는 LLM이 스스로 판단하고 독립적으로 일하는 시스템입니다. 사람이 목표만 주면 알아서 계획하고 실행합니다.
작동방식
- 시작 : 사람이 명령하거나 대화로 작업을 설명합니다.
- 계획/실행 : 에이전트가 독립적으로 일을 수행합니다. 단계마다 결과를 확인하고 평가합니다.
- 중간 체크가 필요하면 인간에게 피드백을 요청합니다.
- 종료 : 작업 완료 / 조건 도달
구현은 생각보다 간단합니다. 실제로는 도구를 사용하는 LLM이 루프를 돕니다. 구현 자체는 간단하지만, 도구 설계와 문서화가 매우 중요합니다. 그러면 언제 사용해야 할까요?
- 필요한 단계를 예측이 불가능한 개방형 문제
- 고정된 경로를 코딩할 수 없을 때
- LLM이 여러번 판단해야 하고, 그 판단에 신뢰성이 있을 때
- 신뢰할 수 있는 환경에서 작업의 확장이 필요할 때
사람 개입 없이 복잡한 작업이 가능합니다. 하지만, 비용이 많이 들고 신뢰성이 떨어지는 환경에서는 결과가 좋지 않습니다. 따라서 충분한 테스트와 적절한 안전 장치가 필요합니다.
패턴은 정답이 아니다
앞서 설명한 패턴은 정해진 규칙이 아닙니다. 얼마든지 조합하거나 변형이 가능합니다. 성능을 실제로 측정하고 꾸준히 개선하는 것이 중요합니다. 복잡하게 만든다고 무조건 좋은게 아닙니다. 간단하게 해결할 수 있다면 그 상태로도 충분합니다.
Simple is the best.
요약
LLM으로 성공하려면 복잡한 시스템을 만드는 것이 아니라 상황에 맞는 시스템을 만드는 것이 중요합니다. 간단한 프롬프트로 시작해서 부족할 때만 에이전트 시스템을 추가합니다.단, 단순함을 유지하고, 투명성을 우선해야합니다.