
영상 링크: Conquering Agent Chaos — Rick Blalock, Agentuity
채널명: AI Engineer
에이전트 혼돈 극복 — Rick Blalock, Agentuity 핵심 요약
- “Conquering Agent Chaos(에이전트 혼돈 극복)“는 에이전트의 실제 배포 문제와 Agentuity의 솔루션 중심 기능에 대해 논의함
- 플로리다 대학교(University of Florida)에서 만난 교수와 학생들도 모두 에이전트 배포상 문제를 1순위 고민으로 언급함 (예: AWS Lambda 타임아웃, 장기 실행 불가, VM 미허용, 게이트웨이 구성의 복잡성)
- 에이전트는 무상태(stateless) 아키텍처가 아닌, 상태(stateful)를 요구하는 특성상 기존 웹 인프라에 부합하지 않아 문제 발생
- 성공적인 에이전트 배포에 필요한 요소로 “지속 실행, 일시정지/재개, 코드와의 분리된 입력·출력(다양한 포맷), 자체 관찰성/성찰성, 메모리, 진화적 코드 실행” 등 제시
- Agentuity는 에이전트 중심 배포환경을 제공하는 CLI 도구 및 웹 대시보드를 개발: 다양한 런타임 지원(bun, Python+UV, node.js), 프레임워크 아그노스틱, 템플릿 선택, GitHub 자동 배포 연동
- 각 에이전트를 ‘1급 인프라 시민’으로 취급, API키 관리 및 보호 옵션 제공, 프로젝트 단위 에이전트 묶음·다수 에이전트간 내부 통신 지원
- dev 모드에서는 다양한 입력 포맷(텍스트, JSON, HTML, PDF 등) 시뮬레이션 가능, 실시간 로그/세션/코스트 분석 및 AI Gateway 통합 제공
- 프로젝트·에이전트·실행 단위 비용 분석, 입력/출력 채널(JsON, Email, SMS, 웹훅, 추후 슬랙/디스코드 등) 동적 추가 가능
- 템플릿 기반 최소한의 코드 컨벤션(YAML+입력포인트), 다양한 프레임워크· 에이전트 아키텍처와 호환성 확보
- 여름 중 인프라 모니터링용 “에이전트 기반 Pager Duty” 등 추가 기능 론칭 예정
세부 요약 - 주제별 정리
에이전트 배포가 실전에서 반복적으로 마주치는 주요 문제임이 드러남
- Rick Blalock는 플로리다 대학교에서 교수 및 학생들과 에이전트 프로젝트의 최대 난제를 논의함
- 학생, 교수 모두 “에이전트의 실제 배포”를 가장 어려운 부분으로 지목
- AWS Lambda 등 서버리스 환경 사용 시 15~40분 이내 실행 제한(타임아웃)이 반복적으로 문제
- 플로리다 대학은 보안 및 리소스 문제로 학생들의 EC2(VM) 사용을 허용하지 않음
- 게이트웨이 연동, 에이전트간 통신 문제도 고질적으로 지적됨
- Rick 본인 역시 과거 질적 리서치 에이전트 프로젝트에서 비슷한 문제에 직면, 아키텍처 재설계 경험 설명
에이전트는 기존 무상태 웹 인프라와 달리 상태를 유지해야 하는 본질적 차이가 있음
- 웹 서비스 대부분은 무상태(stateless) 아키텍처 기반으로 설계됨
- 그러나 많은 에이전트는 반드시 상태(stateful)를 저장·관리해야 함
- 이로 인해 기존 인프라(서버리스, 단일 HTTP Handling 등)와 충돌, 복잡성↑
- 상태 유지 및 장기 실행 등 “에이전트 특화 기능”이 인프라 차원에서 필요
성공적인 에이전트 운영을 위해 반드시 갖추어야 할 핵심 요건 제시
- 에이전트는 “필요한 만큼 오랫동안” 실행돼야 하며, 일시정지/중지/재개가 가능해야 함
- 코드와 입출력 채널이 분리되어(Decoupling) 다양한 포맷의 입력·출력을 처리해야 함
- 프로젝트별로 여러 에이전트 그리고 각기 다른 프레임워크·런타임·아키텍처 혼합 가능성이 많음
- introspection, self-observability(자체 관측성), self-reflection(자기 성찰)능력이 필요(단순 human-centric 모니터링과 차별)
- 메모리, 코드 실행 진화능력 등 인공지능 에이전트 특유의 특성 고려 강조
Agentuity 플랫폼은 에이전트 배포의 구조적 난점을 직접 타깃으로 설계됨
- ‘에이전트 중심’ 인프라를 명확하게 표방
- 각 에이전트를 ‘1급 시민(first-class citizen) 인프라 요소’로 관리
- CLI 및 웹 환경에서 간단히 프로젝트 생성(agent create 명령), 에이전트별 개별 API 키 발급·보호 정책 설정
- 프로젝트=GitHub 저장소 매핑 가능, GitHub main 브랜치 병합 시 자동 배포(Continuous Deployment) 연동
- 런타임 선택: bun, Python(UV 추천), Node.js 세 가지 런타임 공식 지원
- 프레임워크 아그노스틱: Monstra(TypeScript), Versell AI SDK+Grok 등 다양한 템플릿/프레임워크 선택 및 혼용 가능
다양한 입력 포맷 및 다채로운 입출력 채널을 지원하여 유연성 확보
- 에이전트 입력값으로 텍스트뿐 아니라 JSON, HTML, PDF, 이메일 등 다양한 포맷 실험 및 테스트 가능
- 단순 HTTP 요청 뿐 아니라, 이메일 주소/전화번호/SMS/Webhook/크론잡 등 다양한 채널에 ‘동적으로’ 연결 가능
- Slack, Discord 등도 향후 연동 예정이라고 언급
- 프로젝트 단위로 입출력 채널 추가·관리 가능(예: 이메일 주소 발급 후 즉시 사용)
dev 모드(로컬 시뮬레이션) 환경과 실전 배포 흐름을 상세 데모로 설명
- agent2 dev 명령어로 각 에이전트를 로컬에서 포트별로 실행, 개발 시 실시간 테스트
- 에이전트별 터널링 기능: 외부 서비스·기기에서 바로 접근 가능
- 입력값을 선택(텍스트, JSON 등)해 에이전트 동작 시뮬레이션, 실행결과(respons), 로그, 세션, 호출 코스트 등 한눈에 확인
- AI Gateway를 자체적으로 제공(GPT, Anthropic 등 상용 모델의 키 직접 등록·관리가 필요 없음), Prompt/Response/Cost 등 상세 분석 지원
- 개발환경과 프로덕션 환경이 거의 동일하게 동작(미러 이미지 구조)
코드 구조와 최소한의 개발 컨벤션은 단순하고 프레임워크 아그노스틱하게 설계됨
- 프로젝트 당 YAML 설정파일과 agents 폴더가 기본 구조
- 각 에이전트는 한 개의 entry point(자바스크립트: export default function, 파이썬: run 함수)만 구현
- request 객체에는 다채로운 입력값(이메일, PDF, JSON 등) 자동 맵핑
- ctx.getAgent 기능으로 프로젝트 내 다른 에이전트 호출(예: pyantic agent 등), 임시 토큰 발급·제어 포함
- Monstra, Crew AI, LangChain, Pydantic 등 다양한 프레임워크나 에이전트 템플릿을 자유롭게 드롭인(삽입) 가능
에이전트 실행 및 배포, 비용·리소스 통계까지 한눈에 제공(데모)
- 생성된 에이전트를 agent2 deploy 명령으로 배포, 런타임별 컨테이너에 래핑됨
- 대시보드에서 에이전트별 배포 현황, 행복한 ‘bun’ 아이콘 등 UI 제공
- 프로젝트/에이전트/실행별 상세 비용 분석, 호출별 코스트 트레킹 가능
- 문제 발생시(예: 메모리 한도 초과 시 오류 발생), YAML에서 직접 자원 할당 변경 가능
동적으로 에이전트 기능 확장 및 통합 워크플로우 구현이 쉬움
- 단일 프로젝트에서 여러 에이전트 생성, 다양한 프로젝트/조직 내 자유롭게 혼합 배포
- 외부에서 이메일, SMS 등으로 입력, 필요한 경우 GitHub에서 클론 후 즉시 배포 및 입/출력 라우팅 가능
- 내부적으로 약 50~60개 이상의 에이전트가 Agentuity 상에서 운용되고 있음
- 성능 및 개발 속도에서 원활함을 확보(회사 내 자체 경험 강조)
지속적으로 새로운 인프라 모니터링/관리용 에이전트 도구 개발이 예정됨
- 곧 “인프라스트럭처 에이전트” 개발 예정: 로그를 모니터링해 문제점 알림 등(개발자에게 자동 알람 제공)
- “에이전트 Duty”라는 이름의 Pager Duty 대체/보완 제품 기획(내부 농담)
- 다양한 외부 서비스·툴 연동 및 인프라 서비스 계층의 에이전트 자동화 기능 확장 예정
Q&A에서 “토큰 내 툴 추가” 관련 질문과 확장성 관점에서의 대응 논의
- 최근 업계 화두로 부상한 “토큰 내 툴 삽입” 여부에 대해 질문
- Rick Blalock는 “에이전트 성공에 필요한 기능을 서비스 레이어에서 기본 제공할 계획”
- Versell AI SDK 등 외부 툴과의 통합성 유지 방침, 특정 CRM 에이전트에 실제적 필요성 언급
- 유연하고 모듈화된 서비스 레이어 확장 의지 피력