지난 한 달 동안, 제가 구축하고 있는 코딩 에이전트는 입력과 출력 사이에서 130억 개의 토큰을 처리했으며, 97.24%의 캐시 적중률과 백만 토큰당 약 R$ 0.04의 실질 비용을 기록했습니다.
이 수치를 언급하면, 첫 반응은 대개 불신입니다. 그리고 그것은 건강한 반응입니다. 비용은 기업들이 자율 에이전트를 포기하는 가장 큰 이유입니다: 파일럿은 성공하고, 청구서가 도착하며, 프로젝트는 죽습니다. 따라서 이 글은 이러한 수치가 어떻게 가능했는지에 대한 이야기입니다. 단 하나의 비결은 없습니다. 모든 입력 및 출력 토큰이 압축, 라우팅, 측정되는 아키텍처가 있습니다.
이것이 바로 Velua Code입니다. 제가 새로 시작한 스타트업 Velua AI (https://velua.aihttps://velua.ai/))에서 구축 중인 에이전트입니다. 아키텍처에 앞서, 논제부터 설명하겠습니다.
논제: 세 가지 문제를 함께 해결하기
코딩 에이전트는 세 가지 지점에서 실패하며, 하나만 해결해서는 충분하지 않습니다.
비용. 자율 에이전트는 어떤 CFO라도 겁먹게 할 규모로 토큰을 소비합니다. 각 반복 비용이 비싸면, 아무도 에이전트가 반복 작업을 수행하도록 두지 않습니다. 그리고 반복하지 않는 에이전트는 실제로 아무것도 해결하지 못합니다.
컨텍스트. 컨텍스트 윈도우는 유한하고 비용이 많이 듭니다. 일반적인 구현은 프롬프트 전체 파일과 grep 결과로 채워, 매 호출마다 수천 개의 관련 없는 토큰에 비용을 지불하게 만듭니다.
메모리. 모든 세션은 처음부터 시작합니다. 에이전트는 화요일에 이미 월요일에 배운 내용을 다시 발견하고, 그 재발견에 (토큰과 오류 비용을) 지불합니다.
세 가지는 서로를 악화시킵니다: 부풀려진 컨텍스트는 비용을 증가시키고, 메모리 부족은 컨텍스트를 부풀립니다. 이것이 Velua Code가 세 가지를 동시에 공략하는 이유입니다.
비용: 소스 압축 + 능동적 라우팅
첫 번째 아키텍처 결정: 컨텍스트를 끝에서가 아닌 소스에서 압축합니다. 모든 도구 출력(파일 읽기, 검색 결과, 빌드 로그)은 세션 기록에 들어가기 전에 압축 파이프라인을 거칩니다. 핵심은 개발자 머신이나 에이전트 컨테이너 내에서 로컬로 실행되는 ONNX 기반의 독점 압축 모델입니다. 압축을 위한 네트워크 호출이 없습니다: 절감액에 토큰 비용이 들지 않습니다.
그 주변에는 더 간단한 레이어가 중요한 작업을 수행합니다: 읽기 중복 제거(에이전트가 같은 파일을 다시 읽었는가? 이전 버전은 컨텍스트에서 제거), 구조적 JSON 압축, 서명 유지와 함께 코드 본문 생략, 그리고 컨텍스트가 커짐에 따라 압축을 강화하는 적응형 임계값. 모든 것은 대상 모델의 실제 토큰화기로 측정됩니다—절감액은 추정치가 아닌 실제 토큰으로 계산됩니다.
그리고 하지 않기로 한 결정도 있습니다: 런타임에 시스템 프롬프트를 절대 건드리지 않습니다. 안정적인 프롬프트가 97.24% 캐시 적중률을 유지하는 핵심이며, 캐시 적중은 존재하는 가장 저렴한 비용 레버입니다. 캐시된 토큰은 전체 토큰의 극히 일부 비용만 들기 때문입니다.
두 번째 결정: 에이전트가 모델을 선택하지 않습니다. 로컬 분류기가 각 작업을 카테고리와 복잡성에 따라 사전 분류하고, Velua Gateway(50개 이상의 모델을 실시간 가격 및 성능과 함께 확인)가 필요한 범위 내에서 가장 적합한 모델로 라우팅하며, 가드레일을 적용하고 RAG로 강화합니다. 변수 이름 변경에 프론티어 모델이 필요하지 않습니다. 스키마 마이그레이션 설계에는 필요하죠. 능동적 라우팅을 통해 대부분의 호출은 더 작은 모델로 전달되고, 복잡성이 요구될 때만 비싼 모델이 투입됩니다.
게이트웨이는 또한 각 요청의 실제 비용을 측정합니다. 이는 프로덕션 에이전트에 필수적이라고 생각하는 기능을 가능하게 합니다: 정지 조건으로서의 예산. 자율 루프는 희망이 아닌 통화 단위의 비용 상한선을 가지고 실행됩니다.
바로 이 조합(소스 압축, 높은 캐시, 소규모 모델 간 라우팅)이 백만 토큰당 R$ 0.04를 만들어냅니다. 세 가지 중 어느 하나만으로는 이에 근접할 수 없습니다.
컨텍스트: Grep 대신 그래프
에이전트가 코드베이스를 "이해"하는 표준 방식은 grep과 파일 읽기입니다. 비용이 많이 들고 맹목적이죠. Velua Code는 코드 지식 그래프를 유지 관리합니다: 함수, 클래스, 라우트, 그리고 그들 간의 관계(누가 누구를 호출하는지, 누가 무엇을 구현하는지).
이것은 루프의 양쪽 끝을 모두 변화시킵니다. 입력 측면에서, 에이전트는 파일을 프롬프트에 덤프하는 대신 그래프를 참조하여(프로젝트의 아키텍처 뷰와 작업에 관련된 노드로 구성된) 간결한 컨텍스트 패키지를 조립합니다. 출력 측면에서는 검증이 변경됩니다: 에이전트가 함수를 수정하면, 그래프가 정확히 영향받는 호출 지점을 나열하고, 리뷰어 에이전트(깨끗한 컨텍스트와 코드를 작성한 사람의 편향 없이)가 각 지점을 확인하며, 추가로 테스트, 린트, 빌드를 실행합니다. "processOrder의 시그니처를 변경했습니다. 7군데에서 호출하고 있습니다"와 같은 유형의 검증은 grep으로는 불가능합니다.
메모리: 학습하는 루프
시스템을 완성하는 요소입니다. 각 검증된 반복이 끝날 때마다, 에이전트는 엔지니어링 결정 사항을 기록합니다: 무엇이 결정되었는지, 왜 그랬는지, 어떤 대안이 고려되었는지, 무엇이 실패했는지. 그리고 각 결정은 그래프 내에서 설명하는 코드 노드에 연결됩니다.
다음 반복에서, 컨텍스트 수집 단계는 이러한 결정 사항(이미 실패한 접근 방식도 포함하여 반복을 방지)을 검색합니다. 루프는 작업을 반복하는 실행기에서 벗어나 코드베이스에 대한 지식을 축적하는 시스템이 됩니다. 이는 또한 존재하는 최고의 비용 분산 수단입니다: 저렴한 메모리가 값비싼 재발견을 대체합니다.
따라서 완전한 루프는 다음과 같습니다: 컨텍스트 수집(그래프 + 메모리 + RAG), 문제 크기에 맞는 올바른 모델로 계획 수립, 하위 에이전트로 실행, 깨끗한 컨텍스트의 리뷰어와 그래프 인식을 통한 검증, 결정 사항 기록을 통한 학습, 그리고 비용 상한선 내에서 반복. 이것은 정식 에이전트 루프로, 각 일반 단계가 고유한 기능으로 대체된 것입니다.
왜 첫 번째 고객이 우리 자신인가
제품 전략은 의도적으로 직관에 반합니다: 어떤 고객에게도 판매하기 전에, Velua Code는 SIGE Cloud 내부에서 실행됩니다. 진정한 도그푸딩(Dogfooding)입니다—프로덕션 환경의 ERP에서 실제 팀이 실제 코드로 에이전트를 운영하며 매일 사용합니다.
이 내부 사용이 130억 개의 토큰을 생성했으며, 제품을 형성하고 있습니다. 프로덕션 환경의 자율 에이전트는 어떤 벤치마크도 드러내지 못하는 문제들을 드러냅니다: 권한, 누적 비용, 지연되는 작업, 썩어가는 컨텍스트. 저는 고통이 우리의 것일 때 성숙해지기를 선호합니다.
앞으로의 계획: 기업을 위한 통합 메모리
현재 결정 메모리는 프로젝트별로 존재합니다. 다음 단계는 제가 가장 기대하는 부분입니다: 이를 기업을 위한 통합 엔지니어링 메모리 레이어로 격상시키는 것입니다.
팀 A의 에이전트가 기록한 결정("우리는 Y 때문에 X로 마이그레이션했습니다. W를 망가뜨리기 때문에 Z는 피했습니다")이 팀 B의 에이전트와 이러한 에이전트를 운영하는 인간 개발자 모두가 액세스 제어, 출처 증명, 감사 기능을 갖추고 검색할 수 있다고 상상해보세요. "이 코드가 왜 이렇게 되었나요?"라는 질문에 원래 결정 사항이 코드에 연결되어 답변되며, 조직 내 누구나 또는 어떤 에이전트든 접근할 수 있습니다. 더 빠른 온보딩, 팀 간 일관성, 그리고 더 이상 사람들의 머리 속에만 존재하지 않는 회사의 엔지니어링 지식.
게이트웨이를 통해 제공되는 이 메모리는 인프라가 됩니다: 회사의 모든 에이전트, 모든 도구에서 축적된 학습 내용을 상속받습니다.
자율 에이전트는 상품이 될 것입니다. 하지만 그들이
당신의
시스템에 대해 축적하는 지식은 그렇지 않을 것입니다.
이것이 바로 그 베팅입니다.
프로덕션 환경에서 에이전트를 구축 중이거나, 컨텍스트 비용으로 골머리를 앓고 계신다면, 제 DM은 열려 있습니다.
