“컨텍스트가 가득 차니까 모델이 자기가 뭘 하고 있었는지 잊어버려요. 같은 말을 반복하고, 할루시네이션을 시작하죠. 결국 실패합니다.”

VMware의 Principal Engineer Bryan Liles가 최근 발표한 글에서 AI 에이전트 프레임워크의 근본적인 문제를 지적했습니다. 그는 현재 상황을 Ruby on Rails가 등장하기 이전의 웹 개발에 비유합니다. 모두가 에이전트를 만들고 있지만, 같은 문제들을 각자 처음부터 해결하고 있다는 것이죠. Rails가 웹 개발을 바꿨듯이, 에이전트 개발에도 그런 혁신적 프레임워크가 필요하다는 게 핵심 메시지입니다.

이 글은 현재 프레임워크들이 왜 복잡성만 늘리고 핵심 문제는 해결하지 못하는지 분석하고, “올바른 아키텍처가 쉬운 아키텍처”가 되는 프레임워크의 설계 원칙을 제시합니다. 컨텍스트 고갈, 무한 루프, 도구 선택 혼란 같은 실제 문제들을 해결하는 구체적인 방법론을 담고 있습니다.

출처: Agents Done Right: A Framework Vision for 2026 – Bryan Liles 블로그

현재 프레임워크의 문제: 복잡성이 복잡성을 낳는다

저자는 한번은 전화 통화 중에 에이전트가 npm run build를 5분 동안 계속 반복하는 걸 지켜봤다고 합니다. 토큰만 소비하면서 같은 실패한 동작을 반복하는 “무한 루프(doom loop)”에 빠진 거죠. 이게 바로 현재 프레임워크들이 직면한 현실입니다.

문제의 핵심은 컨텍스트 윈도우 관리입니다. 에이전트가 복잡한 작업을 수행하면서 컨텍스트 윈도우가 채워지면, 모델은 원래 요구사항을 잊어버립니다. 코드를 읽고, 코드베이스를 검색하고, 다른 접근을 시도하다 보면 정작 코드를 작성할 차례가 됐을 때는 처음 목표를 잊어버린 상태가 되는 거죠.

현재 프레임워크들은 이런 문제를 회피합니다. LLM API를 감싸는 얇은 래퍼에 불과하고, 어떤 모델을 쓸지, 어떤 임베딩 제공자를 선택할지, 도구를 어떻게 구조화할지 같은 결정들을 모두 개발자에게 떠넘깁니다. Steve Krug의 첫 번째 사용성 법칙 “생각하게 만들지 마라”를 정면으로 위배하는 거죠.

서브에이전트: 함수처럼 쉬워야 한다

저자가 제시하는 핵심 솔루션은 서브에이전트를 일급 시민으로 만드는 것입니다. 함수가 프로그램에서 하는 역할을 서브에이전트가 해야 한다는 겁니다.

생각해보세요. 하나의 PDF 문서가 전체 컨텍스트 윈도우를 차지할 수 있습니다. 큰 코드베이스는 더 심하죠. 하지만 작업을 독립된 하위 작업으로 나누면 각각이 자신만의 컨텍스트를 가집니다. 한 서브에이전트는 코드베이스를 검색해서 관련 파일 경로만 반환하고, 다른 서브에이전트는 특정 함수를 분석해서 발견 사항만 반환합니다. 부모 에이전트는 집중력을 유지하면서 정제된 결과만 받게 되죠.

차이는 극적입니다. 단일 에이전트 접근법은 컨텍스트 윈도우의 90%를 비틀거리며 소비할 수 있지만, 서브에이전트를 쓰면? 부모는 25%만 사용하면서 끝까지 집중력을 유지합니다.

// 이게 함수 호출처럼 자연스러워야 한다
const result = await agent.delegate("searcher", {
  task: "locate authentication logic",
  returnFormat: "file_paths_with_snippets"
});

Convention over Configuration: Rails의 교훈

저자는 Ruby on Rails의 성공 비결을 강조합니다. Rails는 데이터베이스 테이블 이름, 파일 위치, URL 구조를 모두 관례로 정했습니다. 필요하면 재정의할 수 있지만, 기본적으로는 생각할 필요가 없었죠.

에이전트 프레임워크도 마찬가지입니다. 작업 복잡도에 따라 모델을 자동 선택하고, 컨텍스트 예산을 부모-자식 간 상속하고, 위험한 작업(파일 삭제, 다중 파일 수정)에는 자동으로 체크포인트를 만들어야 합니다. 개발자가 일일이 지정하지 않아도요.

저자는 특히 아키타입(archetype) 개념을 제안합니다. Searcher는 검색 도구만, Writer는 쓰기 도구만, Researcher는 웹 접근 권한만 받습니다. 도구가 너무 많으면 에이전트는 관련 없는 옵션을 평가하느라 컨텍스트를 낭비하니까요.

저자는 최근 MCP(Model Context Protocol) 서버로 Outlook을 연결해봤는데, 여러 MCP 서버가 설치되니 에이전트가 바로 옆에 있는 메일 도구 대신 웹 검색을 시도했다고 합니다. 선택지가 너무 많으면 오히려 혼란만 가중되는 거죠.

실용적인 설계 원칙들

작업을 중심에 두기: “어떤 모델을 쓸까?”가 아니라 “회원가입 폼에 입력 검증 추가”라는 작업을 주면, 프레임워크가 알아서 빠른 모델이나 추론 모델을 선택합니다.

서브에이전트 컨텍스트는 임시적: Researcher가 문서 10페이지를 읽고 API 레퍼런스를 훑고 GitHub 이슈를 따라가더라도, 부모에게는 요약본만 반환합니다. 중간 작업은 전부 임시 작업 공간이고, 부모는 500개 토큰을 받지 50,000개를 받지 않습니다.

도구 vs 서브에이전트 구분: 날짜 포맷팅, JSON 파싱, 정규식 실행은 도구입니다. 상태가 없고 변환만 하니까요. 하지만 검색, 분석, 계획은 서브에이전트입니다. 반복, 판단, 컨텍스트 축적이 필요하니까요. 이 구분이 중요한 이유는 반복 작업을 도구로 구현하면 모든 실행 추적이 부모 컨텍스트를 오염시키기 때문입니다.

TypeScript를 선택한 이유

저자는 TypeScript가 에이전트 코드를 더 안전하게 만든다고 주장합니다. Branded types로 컨텍스트 토큰을 일반 숫자와 구별하고, discriminated unions로 체크포인트 상태(pending/approved/rejected)를 철저하게 처리하고, 제네릭 제약으로 서브에이전트 반환 타입을 명확히 할 수 있다는 겁니다.

VS Code 확장, 언어 서버 같은 개발 도구 생태계가 이미 TypeScript 기반이고, Bun을 쓰면 런타임 의존성 없는 독립 실행 파일로 컴파일된다는 점도 장점입니다.

남은 질문들

저자는 아직 해결해야 할 문제들도 솔직하게 제시합니다. 서브에이전트끼리 학습한 컨텍스트를 어떻게 공유할지(아마 프로젝트 수준의 지식 베이스), 동료 에이전트들이 어떻게 협업할지(메시지 전달 방식), 에이전트를 체계적으로 어떻게 평가할지(시나리오 캡처와 재생) 같은 질문들입니다.

특히 평가는 가장 어려운 문제입니다. 코드가 컴파일되고 테스트를 통과해도 아키텍처적으로 잘못됐거나 유지보수하기 어려울 수 있으니까요. 저자는 작업 성공, 행동 일관성, 인간 선호도라는 세 가지 레이어에서 평가해야 한다고 제안합니다.

이 글의 핵심은 단순합니다. 에이전트 프레임워크는 복잡성을 추가하는 게 아니라 올바른 복잡성을 제공해야 한다는 것입니다. Convention이 어려운 교훈을 코드화하고, 기본값이 바로 작동하고, 올바른 아키텍처가 쉬운 아키텍처가 되어야 합니다.

Rails가 웹 개발을 바꿨듯이, 올바르게 설계된 프레임워크는 에이전트 개발을 바꿀 수 있습니다. 배관 작업 대신 실제로 중요한 문제에 집중할 수 있게 말이죠.