AI 에이전트 프레임워크는 왜 복잡할까? Rails처럼 혁신적인 프레임워크가 필요하다
(aisparkup.com)현재 AI 에이전트 프레임워크의 주요 문제
- 컨텍스트 윈도우 고갈
- 복잡한 작업 시 모델이 원래 목표 잊음
- 할루시네이션, 무한 루프 발생
- 프레임워크의 얇은 래퍼 역할
- 모델 선택, 임베딩 제공자, 도구 구조화 등 개발자에게 떠넘김
- "생각하게 만들지 마라" 원칙 위배
- 도구 과다로 인한 혼란
- 불필요한 옵션 평가로 컨텍스트 낭비
제안 솔루션: 서브에이전트 중심 아키텍처
- 서브에이전트를 일급 시민으로 활용
- 함수 호출처럼 자연스럽게 위임
- 독립 컨텍스트 보유 → 부모 에이전트 집중력 유지
- 예: 코드베이스 검색 서브에이전트 → 관련 파일 경로만 반환
- 효과
- 단일 에이전트: 컨텍스트 90% 소비
- 서브에이전트 사용: 부모 컨텍스트 25%만 사용
Rails 교훈 적용: Convention over Configuration
- 기본 관례 우선
- 모델 자동 선택(작업 복잡도 기준)
- 컨텍스트 예산 부모-자식 상속
- 위험 작업 자동 체크포인트 생성
- 아키타입(Archetype) 도입
- Searcher: 검색 도구만
- Writer: 쓰기 도구만
- Researcher: 웹 접근만 → 도구 과다 방지
실용적 설계 원칙
- 작업 중심 설계
- "어떤 모델 쓸까?" 대신 실제 작업(예: 회원가입 폼 검증) 우선
- 서브에이전트 컨텍스트 임시성
- 중간 작업 요약본만 부모에게 반환
- 도구 vs 서브에이전트 구분
- 도구: 상태 없음(날짜 포맷팅, JSON 파싱)
- 서브에이전트: 반복·판단 필요(검색, 분석)
기술 선택: TypeScript
- 타입 안전성 강화(Branded types, discriminated unions)
- 개발 도구 생태계 호환(VS Code 등)
- Bun으로 독립 실행 파일 컴파일 가능
미해결 과제
- 서브에이전트 간 컨텍스트 공유(프로젝트 지식 베이스)
- 동료 에이전트 협업(메시지 전달)
- 에이전트 평가(시나리오 캡처·재생, 성공·일관성·선호도 기준)
결론
- 프레임워크는 복잡성 추가가 아닌 "올바른 복잡성" 제공해야 함
- Rails처럼 혁신적 프레임워크로 에이전트 개발 혁신 가능
- 배관 작업 최소화 → 핵심 문제 집중
Rails는 convention을 강제하고 추상화 레이어 아래에서 마법을 많이 부리니 편리하지만 성능이 떨어지는 트레이드오프가 있지만 이건 당장 돈이 나가는건 아닌 반면
모델을 프레임워크가 마음대로 선택하면 토큰 사용량 폭탄 맞는건 누가 책임져줄까요...?