AI Agent에 대해서는 이젠 매우 익숙한 단계가 아닌가 싶습니다. AI Agent는 LLM과 도구, 그리고 역할에 따른 인스트럭션을 기준으로 목표한 바를 달성하기 위한 단위로 정의된 것으로 보입니다. 오늘은 이러한 AI AGENT를 효과적으로 구축하는 실용적인 방법에 대해 포스트를 해보려고 합니다.
1. AI Agent란?
에이전트의 정의
“에이전트”는 다양한 방식으로 정의될 수 있습니다. 일부는 에이전트를 장기간 독립적으로 작동하며 다양한 도구를 사용해 복잡한 작업을 수행하는 완전 자율 시스템으로 정의합니다. 다른 이들은 미리 정의된 워크플로우를 따르는 보다 규정적인 구현을 지칭하는 용어로 사용합니다.
Anthropic에서는 이러한 모든 변형을 에이전틱 AI(Agentic AI)으로 분류하면서, 중요한 아키텍처적 구분을 합니다:
- 워크플로우(Workflows): LLM과 도구가 미리 정의된 코드 경로를 통해 조율되는 시스템
- 에이전트(Agents): LLM이 자체 프로세스와 도구 사용을 동적으로 지시하며, 작업 수행 방식에 대한 제어권을 유지하는 시스템
언제 사용해야 하는가?
LLM 애플리케이션을 구축할 때는 가능한 가장 간단한 솔루션을 찾고, 필요할 때만 복잡성을 높이는 것이 좋습니다. 에이전틱 시스템은 종종 지연 시간과 비용을 작업 성능 향상과 교환합니다. 이러한 트레이드오프가 언제 의미 있는지 고려해야 합니다.
워크플로우 선택 시기: 잘 정의된 작업에 대해 예측 가능성과 일관성이 필요할 때
에이전트 선택 시기: 대규모로 유연성과 모델 주도 의사결정이 필요할 때
많은 애플리케이션의 경우, 검색과 컨텍스트 내 예제를 활용한 단일 LLM 호출 최적화만으로도 충분합니다.
2. 프레임워크 선택과 활용
주요 프레임워크
에이전틱 AI 구현을 용이하게 하는 여러 프레임워크가 있습니다:
- LangGraph (LangChain): 복잡한 에이전트 워크플로우 구축
- LangFlow
- n8n
- Amazon Bedrock AI Agent Framework: AWS 통합 에이전트 프레임워크
- Rivet: 드래그 앤 드롭 GUI LLM 워크플로우 빌더
- Vellum: 복잡한 워크플로우 구축 및 테스트를 위한 GUI 도구
프레임워크 사용 시 주의사항
프레임워크는 LLM 호출, 도구 정의 및 파싱, 호출 체이닝과 같은 표준 저수준 작업을 단순화하여 시작을 쉽게 만듭니다. 그러나 몇 가지 주의할 점이 있습니다:
장점:
- 빠른 프로토타이핑 가능
- 표준 작업 자동화
- 검증된 패턴 제공
단점:
- 추가 추상화 계층으로 인한 디버깅 어려움
- 기본 프롬프트와 응답이 모호해질 수 있음
- 불필요한 복잡성 추가 유혹
권장 접근 방식
처음에는 LLM API를 직접 사용하세요. 많은 패턴은 몇 줄의 코드로 구현할 수 있습니다. 프레임워크를 사용하더라도 기본 코드를 이해해야 합니다. 내부 작동에 대한 잘못된 가정은 흔한 오류의 원인입니다.
3. 에이전틱 AI의 기본 패턴
기본 구성 요소: 증강된 LLM
에이전틱 AI의 기본 구성 요소는 검색(Retrieval), 도구(Tools), 메모리(Memory)와 같은 증강 기능으로 향상된 LLM입니다. 현재 모델은 이러한 기능을 적극적으로 사용할 수 있으며, 자체 검색 쿼리를 생성하고, 적절한 도구를 선택하고, 보유할 정보를 결정합니다.
구현 시 두 가지 핵심 측면에 집중하세요:
- 특정 사용 사례에 맞게 이러한 기능 조정
- LLM에 쉽고 잘 문서화된 인터페이스 제공
4. 워크플로우의 주요 유형
(1) 프롬프트 체이닝 (Prompt Chaining)
개념: 작업을 일련의 단계로 분해하고, 각 LLM 호출이 이전 호출의 출력을 처리합니다. 중간 단계마다 프로그래밍 방식의 검사(게이트)를 추가하여 프로세스가 올바른 방향으로 진행되는지 확인할 수 있습니다.
언제 사용하는가: 작업을 고정된 하위 작업으로 쉽고 명확하게 분해할 수 있는 경우. 주요 목표는 각 LLM 호출을 더 쉬운 작업으로 만들어 지연 시간을 정확도와 교환하는 것입니다.
활용 예시:
- 마케팅 카피 생성 후 다른 언어로 번역
- 문서 개요 작성 → 기준 충족 확인 → 개요 기반 문서 작성
(2) 라우팅 (Routing)
개념: 입력을 분류하고 전문화된 후속 작업으로 안내합니다. 이 워크플로우는 관심사의 분리를 허용하고 보다 전문화된 프롬프트를 구축할 수 있게 합니다.
언제 사용하는가: 별도로 처리하는 것이 더 나은 명확한 카테고리가 있는 복잡한 작업이며, LLM 또는 전통적인 분류 모델/알고리즘으로 분류를 정확하게 처리할 수 있는 경우.
활용 예시:
- 다양한 유형의 고객 서비스 문의(일반 질문, 환불 요청, 기술 지원)를 서로 다른 다운스트림 프로세스, 프롬프트 및 도구로 전달
- 쉽거나 일반적인 질문은 Claude Haiku 4.5와 같은 소형 모델로, 어렵거나 특이한 질문은 Claude Sonnet 4.5와 같은 더 강력한 모델로 라우팅하여 최적의 성능과 비용 효율성 확보
(3) 병렬화 (Parallelization)
개념: LLM이 작업을 동시에 수행하고 출력을 프로그래밍 방식으로 집계합니다. 두 가지 주요 변형이 있습니다:
- 섹셔닝(Sectioning): 작업을 병렬로 실행되는 독립적인 하위 작업으로 분할
- 투표(Voting): 동일한 작업을 여러 번 실행하여 다양한 출력 획득
언제 사용하는가: 분할된 하위 작업을 속도를 위해 병렬화할 수 있거나, 더 높은 신뢰도의 결과를 위해 여러 관점 또는 시도가 필요한 경우.
활용 예시:
섹셔닝:
- 가드레일 구현: 한 모델 인스턴스는 사용자 쿼리를 처리하고 다른 인스턴스는 부적절한 콘텐츠나 요청을 스크리닝
- 자동화된 평가: 각 LLM 호출이 주어진 프롬프트에 대한 모델 성능의 다른 측면을 평가
투표:
- 코드 취약점 검토: 여러 다른 프롬프트가 코드를 검토하고 문제를 발견하면 플래그를 지정
- 부적절한 콘텐츠 평가: 여러 프롬프트가 다양한 측면을 평가하거나 오탐/미탐의 균형을 위해 다른 투표 임계값 요구
(4) 오케스트레이터-워커 (Orchestrator-Workers)
개념: 중앙 LLM이 작업을 동적으로 분해하고, 워커 LLM에 위임하고, 결과를 합성합니다.
언제 사용하는가: 필요한 하위 작업을 예측할 수 없는 복잡한 작업에 적합합니다. 병렬화와 위상적으로 유사하지만, 핵심 차이점은 유연성입니다. 하위 작업이 미리 정의되지 않고 특정 입력을 기반으로 오케스트레이터가 결정합니다.
활용 예시:
- 매번 여러 파일을 복잡하게 변경하는 코딩 제품
- 관련 정보를 찾기 위해 여러 소스에서 정보를 수집하고 분석하는 검색 작업
(5) 평가자-최적화자 (Evaluator-Optimizer)
개념: 한 LLM 호출이 응답을 생성하고 다른 LLM이 루프에서 평가와 피드백을 제공합니다.
언제 사용하는가: 명확한 평가 기준이 있고 반복적인 개선이 측정 가능한 가치를 제공하는 경우에 특히 효과적입니다. 두 가지 적합성 신호는 첫째, 인간이 피드백을 명확히 표현할 때 LLM 응답이 명백히 개선될 수 있다는 것, 둘째, LLM이 그러한 피드백을 제공할 수 있다는 것입니다.
활용 예시:
- 문학 번역: 번역 LLM이 처음에 포착하지 못할 수 있는 뉘앙스가 있지만, 평가자 LLM이 유용한 비평을 제공할 수 있는 경우
- 여러 라운드의 검색과 분석이 필요한 복잡한 검색 작업: 평가자가 추가 검색이 필요한지 결정
5. 자율 에이전트 (Autonomous Agents)
에이전트의 작동 방식
에이전트는 LLM이 복잡한 입력 이해, 추론 및 계획, 신뢰할 수 있는 도구 사용, 오류 복구와 같은 핵심 역량에서 성숙해짐에 따라 프로덕션에 등장하고 있습니다.
에이전트 워크플로우:
- 시작: 사용자의 명령 또는 대화형 토론으로 시작
- 계획 및 실행: 작업이 명확해지면 에이전트는 독립적으로 계획하고 작동
- 피드백 루프: 각 단계에서 환경으로부터 “실측 자료”(도구 호출 결과 또는 코드 실행)를 얻어 진행 상황 평가
- 인간 개입: 체크포인트 또는 차단 요소 발생 시 인간 피드백을 위해 일시 중지
- 종료: 완료 시 종료, 또는 제어 유지를 위한 중지 조건(최대 반복 횟수 등)
구현의 단순성
에이전트는 정교한 작업을 처리할 수 있지만, 구현은 종종 간단합니다. 일반적으로 환경 피드백을 기반으로 루프에서 도구를 사용하는 LLM일 뿐입니다. 따라서 도구 세트와 문서를 명확하고 신중하게 설계하는 것이 중요합니다.
언제 사용하는가
에이전트는 다음과 같은 경우에 사용됩니다:
- 필요한 단계 수를 예측하기 어렵거나 불가능한 개방형 문제
- 고정된 경로를 하드코딩할 수 없는 경우
- LLM이 잠재적으로 많은 턴 동안 작동하며, 의사결정에 어느 정도 신뢰가 있어야 하는 경우
- 신뢰할 수 있는 환경에서 작업을 확장하는 데 이상적
주의사항
에이전트의 자율성은 더 높은 비용과 오류 누적 가능성을 의미합니다. 샌드박스 환경에서의 광범위한 테스트와 적절한 가드레일을 권장합니다.
실제 활용 사례
- 코딩 에이전트: SWE-bench 작업 해결, 작업 설명을 기반으로 여러 파일 편집
- 컴퓨터 사용: Claude가 컴퓨터를 사용하여 작업 수행하는 참조 구현
6. 도구 설계: Agent-Computer Interface (ACI)
에이전트를 구축할 때 도구는 중요한 부분입니다. 도구 정의와 사양은 전체 프롬프트만큼 많은 프롬프트 엔지니어링 주의를 기울여야 합니다.
도구 형식 선택 원칙
- 충분한 사고 공간 제공: 모델이 스스로를 궁지에 몰아넣기 전에 “생각”할 수 있는 충분한 토큰 제공
- 자연스러운 형식: 인터넷의 텍스트에서 자연스럽게 나타나는 형식에 가깝게 유지
- 형식 오버헤드 최소화: 수천 줄의 코드를 정확하게 세거나 문자열 이스케이프가 필요한 형식 피하기
Agent-Computer Interface (ACI) 최적화
Human-Computer Interface (HCI)에 들어가는 노력만큼 Agent-Computer Interface (ACI) 생성에도 투자해야 합니다.
좋은 ACI 만들기:
- 모델의 입장에서 생각하기: 설명과 매개변수를 기반으로 이 도구를 사용하는 것이 명확한가? 신중하게 생각해야 하는가? 그렇다면 모델에게도 마찬가지입니다.
- 명확한 문서: 매개변수 이름이나 설명을 어떻게 변경하면 더 명확해질 수 있는가? 팀의 주니어 개발자를 위한 훌륭한 독스트링을 작성한다고 생각하세요. 이는 유사한 도구를 많이 사용할 때 특히 중요합니다.
- 반복적 테스트: 많은 예제 입력을 실행하여 모델이 어떤 실수를 하는지 확인하고 반복하세요.
- Poka-yoke 적용: 실수하기 어렵게 도구를 설계하세요. 인수를 변경하여 실수를 방지하세요.
사례
SWE-bench 에이전트를 구축할 때, 전체 프롬프트보다 도구 최적화에 더 많은 시간을 투자했습니다. 예를 들어, 에이전트가 루트 디렉토리 밖으로 이동한 후 상대 파일 경로를 사용하는 도구에서 실수를 하는 것을 발견했습니다. 이를 해결하기 위해 도구를 변경하여 항상 절대 파일 경로를 요구하도록 했고, 모델이 이 방법을 완벽하게 사용하는 것을 확인했습니다.
7. 실전 적용 사례
고객 지원 (Customer Support)
고객 지원은 친숙한 챗봇 인터페이스와 도구 통합을 통한 향상된 기능을 결합합니다. 개방형 에이전트에 자연스럽게 적합한 이유:
- 지원 상호작용이 자연스럽게 대화 흐름을 따르면서 외부 정보 및 작업에 대한 액세스가 필요
- 고객 데이터, 주문 내역, 지식 베이스 문서를 가져오기 위한 도구 통합 가능
- 환불 발행 또는 티켓 업데이트와 같은 작업을 프로그래밍 방식으로 처리 가능
- 사용자 정의 해결을 통해 성공을 명확하게 측정 가능
여러 회사는 성공적인 해결에 대해서만 요금을 청구하는 사용량 기반 가격 모델을 통해 이 접근 방식의 실행 가능성을 입증했습니다.
코딩 에이전트 (Coding Agents)
소프트웨어 개발 공간은 코드 완성에서 자율적 문제 해결로 발전하면서 LLM 기능에 대한 놀라운 잠재력을 보여주었습니다. 에이전트가 특히 효과적인 이유:
- 코드 솔루션은 자동화된 테스트를 통해 검증 가능
- 에이전트는 테스트 결과를 피드백으로 사용하여 솔루션을 반복할 수 있음
- 문제 공간이 잘 정의되고 구조화됨
- 출력 품질을 객관적으로 측정 가능
Anthropic의 구현에서 에이전트는 이제 풀 리퀘스트 설명만으로 SWE-bench Verified 벤치마크에서 실제 GitHub 이슈를 해결할 수 있습니다. 그러나 자동화된 테스트가 기능을 검증하는 데 도움이 되지만, 솔루션이 더 광범위한 시스템 요구 사항과 일치하는지 확인하기 위해서는 인간의 검토가 여전히 중요합니다.
(* 최근 CLI 기반의 다양한 코딩을 지원하는 플랫폼들이 생겨나고 있고, 바이브 코딩을 지원하는 서비스들의 경쟁도 치열해지면서 이 부분에 대해서는 이후에 좀더 다뤄 보도록 하겠습니다. )
결론: 성공을 위한 핵심 원칙
LLM 공간에서의 성공은 가장 정교한 시스템을 구축하는 것이 아닙니다. 필요에 맞는 올바른 시스템을 구축하는 것입니다.
단계별 접근 방식
- 간단한 프롬프트로 시작: 단일 LLM 호출로 해결 가능한지 확인
- 포괄적인 평가로 최적화: 성능 측정 및 반복
- 필요시 복잡성 추가: 더 간단한 솔루션이 부족할 때만 다단계 에이전틱 시스템 추가
세 가지 핵심 원칙
에이전트를 구현할 때 다음 세 가지 핵심 원칙을 따르세요:
- 단순성 유지: 에이전트 설계를 단순하게 유지
- 투명성 우선: 에이전트의 계획 단계를 명시적으로 표시
- ACI 신중하게 제작: 철저한 도구 문서화 및 테스트를 통한 에이전트-컴퓨터 인터페이스 최적화
프레임워크 활용과 추상화 계층 최소화
프레임워크는 빠르게 시작하는 데 도움이 될 수 있습니다. 다만, 프로덕션으로 이동할 때 추상화 계층을 줄이고 기본 구성 요소로 구축하는 것에 집중하는 것이 좋습니다.
이러한 원칙을 따르면 강력할 뿐만 아니라 신뢰할 수 있고, 유지 관리 가능하며, 사용자에게 신뢰받는 에이전트를 만들 수 있습니다.
핵심 메시지: 복잡성보다는 단순함을, 추상화보다는 명확함을, 그리고 항상 실제 성능 측정을 근거로 효율성을 고려하는 것이 좋겠습니다.
답글 남기기