에이전트 실행 기록은 런타임 계약입니다

세 편의 새로운 에이전트 논문은 서로 다른 각도에서 같은 주장을 해요. 최종 답변은 신뢰하기에 가장 약한 단위라는 점이에요. SHEPHERD는 에이전트 실행을 타입이 지정되고 분기 가능한 실행 기록으로 바꿔요. AI 작업 흐름 저장소는 반복되는 에이전트 작업이 즉석 계획이 아니라 설계된 재사용 작업 흐름으로 실행되어야 한다고 주장해요. WildClawBench는 최종 답변만 보지 않고 실제 도구, 부작용 감사, 궤적 검사를 포함해 네이티브 명령줄 런타임 안에서 에이전트를 평가해요.¹²³

에이전트 신뢰성은 이제 실행 기록, 작업 흐름 산출물, 런타임 평가기에 있어요. 채팅 대화록은 에이전트가 무엇을 했다고 말하는지 설명할 수 있어요. 실행 기록은 에이전트가 무엇을 건드렸는지 보여줄 수 있어요. 작업 흐름은 다음번에 에이전트가 무엇을 할 수 있는지 제한할 수 있어요. 네이티브 런타임 벤치마크는 모델, 도구, 상태, 제어 루프가 함께 제대로 작동했는지 측정할 수 있어요.

저는 이미 관리형 에이전트가 런타임 인프라를 흡수하고 있다고 썼어요. 또한 정리 계층이 진짜 에이전트 시장이다라고도 주장했어요. 이 글은 더 좁은 주제를 다뤄요. 두 주장 밑에 있는 계약은 에이전트의 실행 기록이라는 점이에요. 실행 기록을 검사하고, 분기하고, 재생하고, 재사용하고, 평가할 수 없다면 아직 대규모로 신뢰할 수 있는 에이전트 시스템을 가진 것이 아니에요.

인접한 글들은 제어 표면, 증거 관문, 스킬 반복 고리를 다뤄요. 채팅은 AI 에이전트에 맞지 않는 인터페이스다, 증거 관문, 정적 스킬은 죽은 스킬이다가 그 글들이에요. 실행 기록 계약은 이 셋 모두의 아래에 놓여 있어요.

요약

에이전트 시스템은 최종 답변 평가에서 계속 멀어지고 있어요. SHEPHERD는 모든 에이전트와 환경의 상호작용을 Git과 비슷한 실행 기록 안에 타입이 지정된 이벤트로 기록해서, 이전 상태를 분기하고 재생할 수 있게 해요.¹ AI 작업 흐름 저장소는 적절한 설계, 테스트, 적대적 평가, 단계적 출시 비용을 매번 프롬프트마다 치르는 대신, 여러 사용자에게 나누어 부담할 수 있는 재사용 가능하고 단단한 작업 흐름을 제안해요.² WildClawBench는 런타임이 왜 중요한지 보여줘요. 60개의 긴 작업이 실제 도구를 갖춘 실제 CLI 에이전트 런타임 안에서 실행되고, 평균 약 8분과 20회 이상의 도구 호출을 사용하며, 산출물과 환경 부작용을 감사하는 혼합 평가 방식을 사용해요.³

실무적인 변화는 이거예요. 답이 맞는지만 묻지 마세요. 실행 기록을 검사할 수 있는지, 작업 흐름을 재사용할 수 있는지, 평가가 에이전트가 실제로 일하는 런타임에서 이루어졌는지 물어야 해요.

핵심 정리

에이전트 빌더에게: - 실행 기록을 제품 계약으로 다루세요. 다른 프로세스가 검사할 수 있는 구조 안에 도구 호출, 인수, 종료 상태, 파일 변경, 부작용, 의사결정 지점을 기록하세요. - 반복되는 고위험 작업은 검증된 작업 흐름으로 승격하세요. 탐색 단계에는 즉흥성이 어울리지만, 반복 작업에는 테스트와 제약이 있는 재사용 산출물이 필요해요.

평가 팀에게: - 모델만 따로 평가하지 말고, 모델과 런타임을 함께 평가하세요. WildClawBench는 CLI 런타임만 바꿔도 같은 모델의 점수가 최대 18점까지 달라질 수 있다고 보고해요.³ - 결정론적 검사는 의미 판단과 분리하세요. 파일 존재 여부, 형식 유효성, 작업 공간 청결도, 서비스 부작용은 LLM 판정자 없이도 확인할 수 있어야 해요.³

운영자에게: - 공급사가 실행 기록을 보여주지 못한다면 “에이전트 신뢰성”을 사지 마세요. 대화록, diff, 성공 문장만으로는 충분하지 않아요. - 제품별 판단 규칙은 제품 가까이에 두세요. 관리형 실행 기록은 무슨 일이 있었는지 보여줄 수 있지만, 무엇을 출시할 가치가 있는지는 결정할 수 없어요.

왜 최종 답변은 너무 약할까요?

최종 답변은 잘못된 정보를 압축해요.

에이전트는 테스트를 실행하지 않고도 테스트가 통과했다고 보고할 수 있어요. 하위 호출 코드를 읽지 않고도 마이그레이션을 설명할 수 있어요. 사용자가 노출하려 하지 않았던 데이터를 건드린 도구 경로를 통해 올바른 최종 산출물을 만들 수도 있어요. 답변은 깨끗해 보여도 런타임 경로는 안전하지 않거나, 낭비가 심하거나, 재현이 불가능할 수 있어요.

이것이 답변보다 도구에 먼저 보상하라의 핵심 논지예요. 그 뒤에 있는 도구 증거가 빠져 있으면 답변은 채점할 수 없어요. 최근 연구는 같은 생각을 완료 보고서 아래로 내려요. 실행 기록 자체가 다른 에이전트, 평가기, 운영자가 검사해야 하는 대상이 돼요.

WildClawBench는 이 문제의 벤치마크 측면을 이름 붙여요. 저자들은 많은 에이전트 벤치마크가 여전히 합성 샌드박스, 짧은 작업, 모의 API, 최종 답변 검사에 기대고 있다고 주장해요. 이 벤치마크는 대신 실제 CLI 에이전트를 Docker 컨테이너 안에서 실행하고, 에이전트가 종료된 뒤 생성된 산출물, 환경 상태, 의미 기준을 평가해요.³ 이 차이가 중요한 이유는 긴 작업이 잘못된 텍스트만이 아니라 부작용과 런타임 선택 때문에 실패하기 때문이에요.

SHEPHERD는 무엇을 더하나요?

SHEPHERD는 에이전트 실행을 다른 에이전트가 다룰 수 있는 일급 객체로 봐요.¹

논문은 메타 에이전트를 다른 에이전트를 감독하거나, 최적화하거나, 훈련하는 고차 에이전트로 정의해요. 이런 메타 에이전트에는 대화록만으로는 부족해요. 실행 중인 내용을 읽고, 위험한 차례 전에 분기하고, 이전 상태에서 재생하고, 부모 실행을 오염시키지 않으면서 여러 갈래를 비교할 수 있어야 해요.

SHEPHERD는 그 기반을 제공해요. 런타임은 모든 에이전트와 환경의 상호작용을 Git과 비슷한 실행 기록 안에 타입이 지정된 이벤트로 기록해요. 모든 행동은 커밋 그래프의 일부가 돼요. 메타 에이전트는 타입이 지정된 이벤트 스트림을 구독하고, 이전 커밋을 체크아웃하고, 범위를 분기하고, 이후 실행을 재생하고, 원하는 분기를 병합할 수 있어요.¹

이 실행 기록은 일반 채팅 로그에는 없는 의미적 약속을 담아요.

보고된 수치는 이 기반을 구체적으로 보여줘요. 저자들의 벤치마크에서 SHEPHERD는 에이전트 프로세스와 파일 시스템을 Docker보다 더 빠르게 분기하고, 재생 시 95%가 넘는 프롬프트 캐시 재사용을 보고해요. 예시에서는 실시간 감독자가 CooperBench 공동 통과율을 28.8%에서 54.7%로 올리고, Tree-RL 설정이 보고된 구성에서 TerminalBench-2 성능을 34.2%에서 39.4%로 높여요.¹

이 숫자들을 보편적인 프로덕션 보장으로 과하게 읽으면 안 돼요. 중요한 점은 형태예요. 런타임이 최종 결과만이 아니라 실행에 대한 구조화된 접근을 다른 프로세스에 제공할 때, 감독과 최적화와 훈련이 모두 나아져요.

AI 작업 흐름 저장소는 무엇을 더하나요?

AI 작업 흐름 저장소 논문은 같은 신뢰성 문제를 재사용의 관점에서 다뤄요.²

저자들은 일반적인 에이전트 루프가 모델에게 몇 초 또는 몇 분 안에 계획을 합성하고 실행하라고 요구한다고 말해요. 그 속도는 전통적인 소프트웨어를 그나마 견딜 만하게 만든 절차를 건너뛰어요. 요구사항 작업, 설계, 테스트, 적대적 평가, 단계적 배포, 모니터링, 피드백 같은 절차들이에요. 논문은 많은 즉석 에이전트 실행이 프로덕션급 시스템보다는 즉흥적으로 만든 프로토타입에 가깝다고 봐요.²

저자들이 제안하는 답은 “모델이 더 오래 생각하게 하자”가 아니에요. 답은 단단하게 다듬어진 재사용 작업 흐름의 공유 저장소예요. 에이전트는 검증된 작업 흐름이 있을 때 사용자 요청을 거기에 맞추고, 사용자의 세부 정보에 맞게 매개변수화한 뒤, 매번 새 도구 체인을 발명하는 대신 제약이 걸린 그 작업 흐름을 실행해야 해요.²

이 생각은 스킬 논의를 더 날카롭게 만들어요. “X를 하는 방법은 이렇다”라고만 적힌 스킬 파일은 런타임 안에 너무 많은 즉흥성을 남겨요. 작업 흐름 저장소는 더 강한 산출물을 요구해요.

논문의 핵심 경제적 주장은 실용적이에요. 엄격한 엔지니어링은 즉석 실행보다 더 많은 시간과 연산을 요구할 수 있으므로, 그 비용은 사용자와 반복 요청 전체에 나누어 부담되어야 해요.² 이 주장은 진지한 에이전트 작업이 이미 체감되는 방식과 맞아요. 고위험 작업을 처음 할 때는 탐색해요. 두 번째와 세 번째부터는 전체를 처음부터 다시 탐색하지 말아야 해요.

WildClawBench는 무엇을 더하나요?

WildClawBench는 이 계약의 평가 버전을 제공해요.³

벤치마크는 사람이 작성한 60개의 작업을 6개 범주에 걸쳐 담고 있어요. 이중 언어 작업과 멀티모달 작업도 포함돼요. 각 작업은 OpenClaw, Claude Code, Codex, Hermes Agent 같은 실제 CLI 런타임을 호스팅하는 재현 가능한 Docker 컨테이너 안에서 실행돼요. 작업은 모의 서비스 API 대신 실제 도구를 사용하고, 저자들은 실행당 평균 약 8분과 20회가 넘는 도구 호출을 보고해요.³

순위표보다 중요한 것은 평가 설계예요. WildClawBench는 결정론적 산출물 검사, 부작용에 대한 환경 상태 감사, 의미 검증이 필요한 곳에서만 쓰는 LLM/VLM 판정자를 결합해요. 벤치마크는 평가 전용 자산을 에이전트가 종료될 때까지 숨기는데, 이렇게 하면 에이전트가 실행 중에 정답지를 보는 일을 막을 수 있어요.³

핵심 결과는 이렇습니다. 가장 좋은 보고 구성은 전체 62.2%에 도달하고, OpenClaw 실행에서 다른 모든 모델은 60% 아래에 머물며, 런타임을 바꾸는 것만으로 한 모델의 점수가 최대 18점까지 움직여요.³ 논문의 결론도 여기서 나와요. 런타임은 평가 대상 시스템의 일부예요. 모델만으로는 제품이 아니에요.

이 결과는 팀들이 에이전트 벤치마크를 더 신중하게 다루게 만들어야 해요. 짧고, 합성적이고, 최종 답변 중심인 벤치마크에서 높은 점수를 받았다고 해서 운영자가 가장 궁금해하는 질문에 답한 것은 아니에요. 에이전트가 실제 런타임과 실제 도구 안에서 긴 작업을 수행하고, 환경을 의도한 상태로 남길 수 있는지가 핵심 질문이에요.

계약은 무엇인가요?

세 논문을 함께 놓으면 계약은 분명해져요.

각 계층은 서로 다른 거짓말을 막아요.

실행 기록은 에이전트가 빠진 도구 호출을 그럴듯한 답변으로 세탁하지 못하게 해요. 작업 흐름은 반복 작업이 영원히 새로운 즉흥 실행을 필요로 하는 척하지 못하게 해요. 네이티브 런타임 벤치마크는 모델 점수가 런타임의 중요성을 지워 버리지 못하게 해요. 제품 기준은 검증된 산출물이 검사를 통과했다는 이유만으로 가치 있는 척하지 못하게 해요.

마지막 계층은 여전히 중요해요. 실행 기록은 무슨 일이 있었는지 증명할 수 있어요. 작업 흐름은 앞으로 일어날 일을 제한할 수 있어요. 벤치마크는 작업 완료를 측정할 수 있어요. 하지만 그 어떤 계층도 결과가 사용자와 제품과 작업 뒤의 기준을 존중하는지 결정할 수는 없어요. 그 결정은 여전히 팀의 몫이에요.

운영자는 지금 무엇을 바꿔야 할까요?

실행 기록 완전성부터 시작하세요.

런타임이 도구 호출, 인수, 종료 코드, 파일 변경, 생성된 에이전트, 배출된 산출물에 대한 구조화된 기록을 만들 수 없다면, 더 많은 자율성을 추가하기 전에 그것부터 고치세요. 약한 실행 기록은 이후의 모든 주장을 검증하기 비싸게 만들어요.

그다음 실행 기록 평가와 답변 평가를 분리하세요. 테스트가 통과했다고 주장하는 완료 보고서는 먼저 테스트 명령이 실행됐고 성공적으로 종료됐음을 증명해야 해요. 변경된 파일을 언급하는 보고서는 그 파일을 읽었거나 썼음을 증명해야 해요. 외부 작업을 요약하는 보고서는 그 작업의 부작용이 기대 상태와 일치함을 증명해야 해요. 실행 기록이 주장을 뒷받침한 뒤에야 답변의 품질을 판단해야 해요.

다음으로 반복되는 작업 흐름을 찾아내세요. 모든 반복 에이전트 작업에는 승격 질문이 붙어야 해요. 다음 실행은 재사용 가능한 작업 흐름 산출물을 가질 만한가요? 소스 스캔, 가이드 갱신, 번역 릴리스, 의존성 업데이트, 장애 분류, 콘텐츠 게시 모두 런타임이 순서를 다시 발명하지 않을 때 더 좋아져요.

마지막으로, 출시하는 런타임 안에서 평가하세요. 모의 도구와 합성 작업은 개발 중에는 여전히 도움이 될 수 있지만, 출시 결정을 떠받쳐서는 안 돼요. 출시 결정에는 실제 에이전트가 마주할 도구 경계, 파일 시스템 상태, 시간 예산, 부작용 검사가 필요해요.

짧은 요약

에이전트 실행 기록은 신뢰성 계약이 되고 있어요. SHEPHERD는 런타임이 타입이 지정되고 재생 가능한 실행 기록을 노출할 때 메타 에이전트가 실행을 감독하고 분기할 수 있음을 보여줘요. AI 작업 흐름 저장소는 반복 작업이 즉석 즉흥 실행에서 재사용 가능한 공학적 작업 흐름으로 이동해야 한다고 주장해요. WildClawBench는 네이티브 런타임, 도구, 부작용, 궤적 감사가 측정된 성능을 실질적으로 바꾼다는 점을 보여줘요. 최종 답변은 여전히 중요하지만, 계약의 중심이 아니라 끝에 있어요.

FAQ

실행 기록은 관측 가능성과 같은 건가요?

아니요. 관측 가능성은 운영자에게 무슨 일이 있었는지 알려줘요. 계약 수준의 실행 기록은 다른 프로세스가 검사하고, 분기하고, 재생하고, 평가할 수 있을 만큼 구조화되어야 해요. 로그는 사람이 디버깅하는 데 도움이 돼요. 타입이 지정된 실행 기록은 감독자, 평가기, 작업 흐름 빌더가 실행 자체를 직접 다룰 수 있게 해요.

SHEPHERD는 에이전트를 자동으로 안전하게 만드나요?

아니요. SHEPHERD는 관찰, 분기, 재생, 메타 에이전트 개입을 위한 기반을 제공해요. 나쁜 감독자는 여전히 나쁜 결정을 내릴 수 있어요. 이득은 감독자가 채팅 대화록을 파싱하는 대신 구조화된 실행 객체를 바탕으로 행동할 수 있다는 점이에요.

AI 작업 흐름 저장소는 에이전트가 절대 즉흥적으로 일하면 안 된다는 뜻인가요?

아니요. 검증된 작업 흐름이 없거나 작업이 정말 새로운 경우에는 에이전트에 여전히 탐색이 필요해요. 핵심은 승격이에요. 어떤 작업이 반복되고 실제 위험을 갖기 시작하면, 시스템은 성공한 경로를 제약, 테스트, 유지보수를 갖춘 재사용 작업 흐름으로 바꿔야 해요.

WildClawBench는 어떤 에이전트 런타임이 최고인지 증명하나요?

아니요. WildClawBench는 해당 작업 집합과 실험 설정 아래에서 런타임 선택이 측정 성능을 실질적으로 바꾼다는 점을 보여줘요. 그것을 제품의 영구 순위가 아니라, 평가 안에 런타임이 포함되어야 한다는 증거로 다루세요.

팀은 무엇부터 만들어야 하나요?

먼저 실행 기록을 만드세요. 그다음 근거 없는 주장을 거부하는 기준을 추가하세요. 그런 뒤 반복 작업을 작업 흐름으로 승격하세요. 신뢰할 수 있는 실행 기록이 없는 화려한 오케스트레이션은 실패를 재구성하기 더 어렵게 만들 뿐이에요.

참고 문헌