레미 루프, AI 에이전트 프레임워크에 반대하며 최소한의 런타임 구축 옹호

레미 루프는 Opus 4.6과 같은 강력한 모델의 등장에 힘입어 1월에 2주 동안 AI 에이전트 개발을 집중적으로 탐구했습니다. 그의 목표는 이론적 이해를 넘어 이러한 기술의 실제 구현에 참여하는 것이었습니다. 루프는 "저는 CTO에게 '좋아, 2주 동안 잠시 자리를 비우고 이 일에 뛰어들어 우리가 무엇을 얻을 수 있는지 이해하려고 노력할 거야'라고 말했습니다."라고 언급했습니다.

루프는 자신의 이상적인 AI 에이전트를 끊임없는 감독 없이 작동하는 자율 로봇 잔디 깎는 기계에 비유했습니다. 그는 시장 뉴스 및 CRM 데이터 검토와 같은 아침 루틴을 자동화하여 '설정하고 잊어버리는' 경험을 목표로 했습니다. 루프는 "아침에도 똑같은 것을 원했습니다. 왜냐하면 제 아침은 항상 처음 몇 시간 동안은 똑같기 때문입니다."라고 분명히 말했습니다.

현재 AI 에이전트 인터페이스는 자율 주행 트랙터 잔디 깎는 기계에 계속 탑승해야 하는 것과 마찬가지로 지속적인 인간의 감독을 요구합니다. 루프는 초기 모바일 에이전트 인터페이스가 '분위기 있는 SSH'처럼 느껴진다고 묘사하며 진정한 자율성 부족을 암시했습니다. 사용자들은 종종 에이전트가 작업을 수행하는 동안 지속적으로 모니터링하고 지시해야 한다고 느끼며, 이는 자동화의 목적을 무색하게 합니다. 루프는 "이것은 마치 스스로 운전하더라도 여전히 탑승해야 하는 로봇 트랙터 잔디 깎는 기계를 가지고 있는 것과 같습니다. 그렇죠?"라고 설명했습니다.

루프는 종종 복잡하고 제약이 많은 프레임워크에 의존하는 대신 에이전트 런타임을 위한 가장 간단한 솔루션을 구축하기로 결정했습니다. 그는 프레임워크가 종종 개발자를 코드 내에서 프롬프트 편집을 지속적으로 반복하도록 강요하여 유연성과 버전 제어를 방해한다고 지적했습니다. 로직을 별도의 파일로 외부화함으로써 변경 사항을 추적하고 공동 작업을 훨씬 쉽게 할 수 있습니다. 루프는 "저는 작동할 수 있는 가장 멍청한 것을 만들기 시작했습니다."라고 말했습니다.

루프는 YAML을 에이전트 구성에 사용하여 버전 제어 및 개발 워크플로를 크게 향상시켰습니다. 이 접근 방식은 명확한 차이점 확인, 간소화된 풀 리퀘스트 검토, 더 간단한 구현 프로세스를 가능하게 합니다. 그는 "여전히 코드를 사용하지 않고 에이전트를 구현하는 것이 훨씬 쉽다는 것을 알게 되었습니다. 버전을 관리하고, 차이점을 확인하고, PR에서 검토할 수 있습니다."라고 언급했습니다. 이 시스템은 에이전트 정의 파일을 폴더에 놓기만 하면 실행을 시작할 수 있는 간단한 워크플로를 가능하게 하여 배포를 더욱 간소화합니다.

루프는 동적 상태 변화에 반응하기보다는 고정된 시간 간격으로 작동하는 전통적인 크론 작업의 한계를 강조했습니다. 그는 음성 메모, 이메일, 풀 리퀘스트 업데이트 등에 의해 트리거되는 것과 같은 이벤트 중심 시스템이 에이전트 워크플로에 더 큰 유연성과 반응성을 제공한다고 강조했습니다. 에이전트는 입력과 출력을 이벤트로 정의하도록 설계되어야 하며, 이는 반응형 시스템 내에서 더 나은 모듈성과 원활한 통합을 가능하게 합니다. 루프는 "그것은 단지 크론 작업이 아닙니다. 그리고 그것은 에이전트가 음성 메모 프로세서가 단지 크론 작업이 아니라 여기에는 수락과 반환이 있다는 것을 의미합니다."라고 설명했습니다.

엄격하고 하드코딩된 그래프 구조에 의존하는 대신, 에이전트는 다른 프로세스에서 발생하는 이벤트를 구독함으로써 오케스트레이션될 수 있습니다. 예를 들어, 일일 브리핑 에이전트는 음성 메모의 출력을 처리하여 Slack 알림을 트리거할 수 있습니다. 이 이벤트 중심 접근 방식은 에이전트가 관련 이벤트에 단순히 반응하므로 복잡한 그래프 에지를 유지할 필요가 없습니다. 루프는 "이 경우 그래프가 필요하지 않습니다. 필요한 것은 이벤트뿐입니다. 유지할 에지가 없으며 에이전트는 단순히 이벤트에 구독합니다."라고 말했습니다.

루프의 시스템에서 초기 실패에는 중복된 Slack 메시지, 누락된 음성 메모, 낮은 품질의 프롬프트 출력이 포함되었습니다. 중요한 과제는 버전 제어가 부족하여 일관되지 않은 프롬프트 성능의 원인을 파악하기 어려웠다는 것입니다. 루프는 이러한 각 실패 모드가 로그 및 큐와 같은 강력한 에이전트 런타임에 필수적인 기본 인프라 구성 요소를 구축할 기회가 되었다고 설명했습니다. 그는 "발견한 각 실패 모드가 결국 런타임이 된 한 조각을 구축하는 데 실제로 기여했습니다."라고 언급했습니다.

루프는 재현성을 보장하고 변경 사항을 효과적으로 추적하기 위해 Git 또는 Nix와 유사한 프롬프트 관리용 콘텐츠 주소 지정 시스템을 개발했습니다. 이 시스템은 프롬프트에 적절한 버전 관리가 부족할 때 종종 발생하는 '쓰레기' 출력을 방지합니다. 그는 이 인프라가 복잡한 프레임워크를 설계하려는 초기 욕구보다는 실제 필요성에서 구축되었다고 강조했습니다. 루프는 "저는 결국 이 시스템을 위한 콘텐츠 주소 지정 시스템을 구축했습니다. Git, Nix 및 기타 빌드 시스템을 생각할 수 있습니다."라고 자세히 설명했습니다.

루프는 로그가 시스템의 영구 메모리 역할을 하여 에이전트 실행 중 데이터가 손실되지 않도록 보장한다고 강조했습니다. 이 기본적인 구성 요소는 데이터 무결성과 시스템 안정성을 유지하는 데 매우 중요합니다.

모든 시스템 이벤트는 단일의 추가 전용 로그에 세심하게 캡처되어 포괄적인 관찰 가능성을 보장합니다. 이러한 이벤트는 인과적으로 연결되어 개발자가 어떤 이벤트가 다른 이벤트를 트리거했는지 추적할 수 있으며, 이는 복잡한 다중 에이전트 상호 작용을 디버깅하는 데 매우 유용합니다. 루프는 "모든 것이 관찰됩니다. 왼쪽에는 하나의 추가 전용 이벤트 테이블만 있습니다. 실제 명령줄과 같습니다. 명령 지타 이벤트에서 모든 이벤트를 얻을 수 있습니다. 또한 인과적으로 연결되어 있습니다. 어떤 이벤트가 어떤 이벤트를 트리거했는지 알 수 있으며, 이는 디버깅할 때 매우 유용합니다."라고 말했습니다.

루프의 시스템은 프롬프트의 각 구성 요소(시스템 프롬프트, 도구 설명, 사용자 메시지)를 고유한 해시 기반 식별자로 저장합니다. 그런 다음 프롬프트는 원시 텍스트 문자열이 아니라 이러한 해시 목록으로 표현됩니다. 이 그래프 기반 구조는 빌드 시스템이 의존성을 관리하는 방식과 유사하게 모델로 전송된 정확한 콘텐츠를 정밀하게 추적할 수 있도록 합니다. 루프는 "이것이 기본적으로 빌드 시스템이 작동하는 방식입니다. 프롬프트에는 다른 부분이 있습니다. 이들 각각은 해시인 식별자로 어딘가에 저장되고 주소 지정됩니다. 따라서 텍스트를 렌더링하기 전에 프롬프트를 빌드할 때 실제로는 이러한 해시 목록으로 프롬프트를 표현합니다."라고 자세히 설명했습니다.

프롬프트를 해시 그래프로 표현하면 원시 문자열 대신 그래프를 조작할 수 있으므로 컨텍스트 및 KV 캐시 관리가 크게 간소화됩니다. 이 접근 방식은 완전한 감사 가능성을 제공하여 개발자가 모델이 특정 출력을 생성한 이유를 명확하게 이해할 수 있도록 합니다. 루프는 "이는 압축을 훨씬 쉽게 만듭니다. 그래프를 조작하는 것이죠? 문자열을 조작하는 것이 아닙니다. 훨씬 쉽고 간접적으로 KV 캐시 관리도 훨씬 쉽게 만듭니다. 하지만 제가 생각하기에 가장 큰 장점은 이 기술을 사용할 때 진정으로 감사 가능성이라는 것입니다."라고 언급했습니다.

그래프 기반 프롬프트 시스템을 통해 개발자는 차이점을 생성하여 서로 다른 에이전트 실행을 정확하게 비교할 수 있습니다. 이 기능은 사용자 메시지, 제공된 도구 또는 에이전트의 기술이 변경되었는지 여부에 관계없이 실행 간에 정확히 어떤 구성 요소가 변경되었는지 보여줍니다. 이러한 세부적인 가시성은 성능 또는 출력 품질의 변화를 이해하는 데 중요합니다. 루프는 "이 그래프를 가지면 얻을 수 있는 것은 차이점입니다. '이 두 실행 사이에 무엇이 변경되었습니까? 어떤 구성 요소가 변경되었습니까? 단순히 내 메시지였습니까? 모델에 다른 기술을 주었습니까? 다른 도구를 주었습니까?'라고 말할 수 있습니다."라고 설명했습니다.

루프는 에이전트가 운영 체제의 프로세스와 유사하게 작동하여 예약 및 격리될 수 있도록 하는 커널 모델을 설명했습니다. 에이전트의 마크다운 정의는 시스템의 내부 정의와 별도로 사용자 영역에 남아 있습니다. 이 분리는 시스템이 특정 기능과 관계없이 에이전트 프로세스를 효과적으로 관리하고 격리할 수 있도록 보장합니다. 루프는 "커널이 프로세스를 실행하고 에이전트가 일종의 프로세스라고 가정해 봅시다. 실제로는 무엇을 하든 중요하지 않습니다. 그러나 시스템은 이를 예약하고 격리하도록 구축되어 있습니다."라고 말했습니다.

신뢰할 수 있는 구조화된 출력은 루프 회사의 핵심 역량입니다. 독점 모델을 사용한 초기 시도에서는 20%의 실패율이 발생했습니다. 그는 커널의 근본적인 역할이 단순히 바람직하지 않은 행동의 가능성을 줄이는 것이 아니라 바람직하지 않은 행동을 불가능하게 하는 것이라고 강조했습니다. 이 초점은 에이전트 작업의 무결성과 예측 가능성을 보장합니다. 루프는 "커널의 역할은 실제로 나쁜 행동을 불가능하게 만드는 것이지, 단지 가능성이 낮게 만드는 것이 아닙니다."라고 강조했습니다.

루프는 에이전트의 두 가지 협상 불가능한 경계를 강조했습니다. 즉, 외부 세계와의 상호 작용을 위한 유형화된 도구 호출과 에이전트 간 통신을 위한 엄격하게 유형화된 이벤트입니다. 이러한 엄격한 타이핑 요구 사항은 일반적인 오류를 방지하고 강력한 시스템 작동을 보장하는 데 중요합니다. 이러한 경계를 강제함으로써 시스템은 에이전트와 환경 간의 명확하고 예측 가능한 상호 작용을 보장합니다. 루프는 "에이전트와 외부 세계 사이에는 두 가지 경계가 있습니다. 첫 번째는 유형화된 도구 호출이고... 다른 에이전트와의 경계는 유형화된 이벤트이며, 이는 협상 불가능합니다."라고 확인했습니다.

루프는 특히 소규모 회사나 기술 CEO의 경우 외부 솔루션 구매를 고려하기 전에 내부 에이전트 런타임을 구축할 것을 강력히 권장합니다. 이 실용적인 접근 방식은 효과적인 구현에 필수적인 특정 요구 사항 및 한계에 대한 더 깊은 이해를 가능하게 합니다. 그는 현재 프레임워크 개발자들에게 '자신의 개밥을 먹으라'고 도전하고, 리더들에게 기술의 복잡성을 이해하기 위해 기술에 몰두할 것을 촉구했습니다. 루프는 "저는 오늘날 확실히 구매하기 전에 구축을 시작하라고 조언할 것입니다. 그래서 작은 회사라면 기술 CEO에게는 장점입니다. 엔지니어들에게 이것을 하도록 시키지 않고도 이것을 할 수 있기 때문입니다."라고 조언했습니다.