에이전트 루프는 이제 비용 통제가 필요하다

OpenClaw에 대한 논의는 공개 보고서에서 100개의 Codex 에이전트가 약 6,030억 토큰과 760만 건의 요청을 처리하여 발생한 30일간의 OpenAI 청구서 $1,305,088.81에 대한 내용이 나오면서 무시할 수 없게 되었습니다. 충격적인 가치는 명확합니다. 이제 작은 팀은 지칠 줄 모르는 코딩 작업자, 검토자, 벤치마크 감시자, 이슈 분류기, 회의 청취자로 자신을 둘러쌀 수 있게 되었습니다. 더 조용한 교훈이 더 중요합니다. 에이전트가 루프(loop)로 실행될 수 있게 되면, 주요 병목 지점은 접근 가능한 인텔리전스에서 주의력(attention), 컨텍스트, 그리고 비용에 대한 통제로 이동합니다.

루프 엔지니어링(Loop engineering)은 우아하게 들립니다. 왜냐하면 루프는 에이전시(agency)의 자연스러운 형태이기 때문입니다. 시스템은 상황을 관찰하고, 행동을 선택하며, 도구를 사용하고, 결과를 확인하고, 메모리를 업데이트한 다음, 다시 시도합니다. 이 패턴은 모델을 영리한 텍스트 생성기에서 추진력을 가진 작업자로 변화시킵니다. OpenClaw가 중요한 이유는 이 패턴을 실제 환경에서 눈에 보이게 만들기 때문입니다: 지속적인 상태(persistent state), 로컬 도구, 스킬, 코드 접근, 메시지, 파일, 그리고 자동화가 단일 에이전트 런타임으로 짜여집니다.

문제는 루프를 한 번 통과할 때마다 비용이 발생한다는 것입니다. 계획 단계는 컨텍스트를 소모합니다. 도구 호출은 로그를 추가합니다. 검토 단계는 더 많은 파일을 메모리로 가져옵니다. 재시도는 모델에게 이전 실패에 대해 추론하도록 요청합니다. 두 번째 에이전트가 첫 번째 에이전트를 검토하고 토큰의 또 다른 계층을 추가합니다. 사용자에게는 똑똑하게 느껴지는 루프도 청구서에서는 매우 다르게 보일 수 있습니다. 이는 성공이 얼마인지 아무도 정의하기 전에 모호함을 사용량으로 전환하는 엔진이 될 수 있습니다.

이것이 바로 토큰 비용 통제가 루프(Loop) 엔지니어링의 중심에 있어야 하는 이유입니다. 목표는 언제 계속할지, 언제 컨텍스트를 압축할지, 언제 모델을 전환할지, 언제 사람에게 요청할지, 그리고 언제 멈출지를 아는 에이전트를 설계하는 것입니다. 비용은 재무 지표인 동시에 불확실성에 대한 신호로 작용합니다. 반복적인 재시도는 누락된 요구사항을 밝혀낼 수 있습니다. 긴 프롬프트는 부실한 상태(state) 설계를 드러낼 수 있습니다. 값비싼 검토 체인은 약한 테스트 커버리지를 보여줄 수 있습니다. 증가하는 토큰 청구서는 종종 워크플로우가 제공하지 못한 구조를 시스템이 찾고 있다는 것을 의미합니다.

최신 OpenClaw 연구 역시 같은 방향을 가리킵니다. OpenClawBench는 작업 성공과 프로세스 건강 사이의 간극을 설명합니다. 이 데이터셋에서 많은 실행은 최종 검사를 통과했지만, 무시된 오류(ignored errors), 해결되지 않은 모호성(unresolved ambiguity), 안전하지 않은 쓰기(unsafe writes), 또는 과도하게 확장된 기능 주장(overextended capability claims)과 같은 프로세스 이상을 여전히 포함하고 있었습니다. 이는 비용에 중요합니다. 왜냐하면 낭비와 위험은 종종 함께 증가하기 때문입니다. 에이전트는 결과물이 완전해 보이는 데 수천 개의 토큰을 쓸 수 있지만, 그 결과로 가는 과정에는 숨겨진 부채가 있을 수 있습니다.

보안 연구원들은 관련 우려를 제기했습니다. 영구적인 자격 증명(credentials), 파일 접근, 도구 및 서드파티 스킬을 가진 자체 호스팅 에이전트는 새로운 운영 경계가 될 수 있습니다. 이는 합법적인 권한을 통해 작동할 수 있지만, 시간이 지남에 따라 그 메모리와 구성이 표류할 수 있습니다. 노력을 절약해 주는 것과 같은 루프도 조용히 위험을 축적할 수 있습니다. 따라서 예산 게이트(Budget gates), 권한 게이트(permission gates), 그리고 인간의 검토 지점(human checkpoints)은 하나의 시스템으로 설계되어야 합니다. 에이전트가 왜 토큰을 사용했는지 설명하는 데 어려움을 겪는 팀은, 그것이 왜 자격 증명을 건드렸는지, 파일을 수정했는지, 또는 작업을 에스컬레이션했는지 설명하는 데에도 어려움을 겪을 수 있습니다.

실질적인 해결책은 지루하지만 가장 좋은 방식입니다. 모든 루프에 예산 계약(budget contract)을 부여하세요. 에이전트가 시작하기 전에 최대 호출 횟수(maximum calls), 최대 토큰 수(maximum tokens), 모델 등급(model tier), 도구 범위(tool scope), 그리고 인계 지점(handoff point)을 정의해야 합니다. 저렴한 관찰(observation)과 값비싼 추론(reasoning)을 분리하세요. 컨텍스트에는 작업 집합(working set)만 유지하고 나머지는 검색 가능한 아티팩트(retrievable artifacts)로 저장하세요. 다른 모델에게 판단을 요청하기 전에 결정론적 테스트(deterministic tests)를 사용하세요. 반복되는 분석은 캐싱(cache)하세요. 추가적인 패스마다의 한계 가치(marginal value)를 측정하세요. 다섯 번째 패스가 결과에 거의 변화를 주지 않는다면, 다섯 번째 패스는 더 강력한 이유를 요구해야 합니다.

모델 선택에도 규율이 필요합니다. 최첨단 모델(frontier model)은 아키텍처 판단, 생소한 코드, 또는 고위험 합성(high risk synthesis)에 적합할 수 있습니다. 반면, 작은 모델(smaller model)만으로도 라벨링(labeling), 추출(extraction), 포맷팅(formatting), 또는 일상적인 비교에는 충분할 수 있습니다. 낮은 지연 시간(latency)이 희소 자원일 때 빠른 실행 모드(fast execution modes)는 가치가 있을 수 있지만, 눈에 띄는 비용 레이블을 가져야 합니다. 기본값은 모든 단계에서 최대의 지능(maximum intelligence)이어서는 안 됩니다. 기본값은 검증된 결과로 가는 가장 저렴하고 신뢰할 수 있는 경로여야 합니다.

특화된 도구들은 모호한 모델 작업(fuzzy model work)을 편집 가능한 아티팩트(editable artifacts)로 변환함으로써 낭비를 줄일 수 있습니다. 기술 팀은 변경 계획을 세우기 위해 ChatGPT를 사용하고, 두 번째 추론 패스를 Gemini에서 비교하며, 스크린샷에서 공식을 복구하기 위해 Miss Formula를 사용하고, AI가 생성한 논문 그림을 편집 가능한 벡터 그래픽으로 변환하기 위해 Editable Figure를 사용할 수 있습니다. 이러한 종류의 워크플로우는 모델이 동일한 아티팩트를 반복적으로 재현하는 것을 방지합니다. 인간은 출력을 검사하고, 수정하고, 재사용할 수 있기 때문에 통제권을 유지합니다.

가장 강력한 에이전트 팀들은 토큰을 운전 자본(working capital)처럼 취급할 것입니다. 그들은 어떤 루프가 지속 가능한 지식을 창출하는지, 어떤 루프가 단순히 움직임만 만들어내는지, 그리고 어떤 루프가 누락된 결정을 숨기고 있는지를 질문할 것입니다. 그들은 작업 유형, 저장소, 모델, 에이전트, 결과별 토큰 사용에 대한 대시보드를 유지할 것입니다. 그들은 자율적인 수정(autonomous fix) 비용과 인간의 도움을 받은 수정 비용을 비교할 것입니다. 그들은 더 작은 프롬프트가 품질을 보존할 때 이를 축하할 것입니다. 그들은 비용 통제(cost discipline)를 제품 설계, 엔지니어링 위생(engineering hygiene), 그리고 조직적 성숙도와 동시에 볼 것입니다.

OpenClaw 논쟁은 빌더들이 더 명확한 규율과 함께 더 야심차게 만들도록 할 것입니다. 대규모 에이전트 군단(agent fleets)은 소프트웨어가 24시간 내내 작동할 때 무엇이 가능한지를 보여줍니다. 또한 루프에 명확한 계약(contract)이 없을 때 시스템이 얼마나 빨리 돈을 쓸 수 있는지도 보여줍니다. 에이전트 엔지니어링의 다음 단계는 에이전트를 영원히 작동하게 만드는 것보다, 루프를 통과할 때마다 그 자리를 얻도록 만드는 것에 더 가깝습니다. 토큰 제어(Token control)는 자동화가 볼거리(spectacle)가 아닌 운영 체제(operating system)가 되기 시작하는 순간입니다.