9월 30일 수요일

에이전트가 자기 실행을 바꾸도록 허용하면서도, 개선을 재현하고 배포 위험을 제한하려면 하네스를 어떻게 닫힌 루프로 설계해야 하는가?

Arya 사례가 제시하는 핵심 단위는 프롬프트가 아니라 하네스 전체다. 모델, 도구 호출, 스킬, 컨텍스트 처리, 샌드박스, 로깅과 채점이 함께 바뀌므로 단일 벤치마크 점수만 보고 개선을 선언할 수 없다. Weave는 프로덕션과 오프라인 실행을 같은 trace 형식으로 기록하고, 실제 성공과 실패를 회귀 task로 옮긴다. YAML 구성에서 여러 variant를 만들고 프로덕션과 동일한 에이전트를 샌드박스에서 실행한 뒤 규범적 pass/fail과 후보 간 상대 점수를 함께 비교한다. 검증된 variant만 다시 배포하고 새 trace를 다음 평가 입력으로 되돌리면 `production → simulation → agent → improvement pattern`이라는 폐쇄루프가 만들어진다. 다만 루프가 자동이라는 사실은 안전이나 비용을 보증하지 않는다. 실행 환경의 동일성, 평가 건강도, 권한 경계, 후보별 총비용을 각각 관찰해야 한다.

1. 01

   재현 단위는 답변이 아니라 실행 궤적이다

   Arya의 오프라인 DAG는 구성을 불러오고 실제 데이터를 주입한 뒤 runtime 값을 다시 보완하고, 프로덕션과 bitwise-identical한 에이전트를 실행해 점수를 남긴다. 실제 trace에서 발견된 `weave.log` 오류를 WBAF 회귀 task로 만들고 production variant와 candidate variant를 같은 task에서 비교한 과정은 실패를 고칠 수 있는 최소 재현 단위가 최종 출력이 아니라 환경·도구 호출·점수까지 포함한 궤적임을 보여준다. 연구 환경은 프로덕션에서 4시간마다 동기화돼 drift를 억제하지만, 동기화 자체도 제대로 작동하는지 별도 지표가 필요하다.

2. 02

   평가 세트도 움직이는 시스템이다

   Arya 팀은 886개 task를 난이도별로 관리하고 제품팀 검토와 반복 실행을 거친다. 단일 instruction뿐 아니라 persona 기반 multi-turn 흐름도 포함하며, 최소 조건을 보는 규범적 점수와 두 variant의 행동 차이를 보는 상대적 점수를 나눈다. 여기서 경계는 분명하다. 최근 7주의 nightly CI와 일부 task의 약 66% 기록은 특정 운영계의 관찰값이지 일반 성능 보증이 아니다. 에이전트가 바뀌면 task와 scorer의 맹점도 함께 드러나므로 evaluation health와 evaluation-production drift를 별도 검토해야 한다.

3. 03

   강한 에이전트일수록 실행 경계는 다층이어야 한다

   Claude Code 논의는 추론하는 두뇌, 실제 시스템에 닿는 손, 상태를 보여주는 표면을 분리하는 구조를 제시한다. 이 분리는 관찰성과 권한을 설계하기 좋지만 그 자체가 격리를 보장하지는 않는다. 한 채널의 맥락, 다른 사용자의 MCP, 패키지 공급망, 네트워크와 평가기 사이의 작은 허점이 연쇄될 수 있기 때문이다. 따라서 샌드박스만 두는 대신 모델의 위험 의도를 보는 프로브·분류기, 현재 요청의 허용 범위를 확인하는 Auto Mode, ID와 권한, 로그, 외부 평가를 서로 다른 방어층으로 둬야 한다. 장시간 실행에서는 작은 권한 오판의 영향 반경도 함께 커진다.

4. 04

   모델 배치는 이름보다 작업 단위의 경제성으로 검증한다

   서브에이전트는 복잡한 저장소 조사와 가설 확인을 상위 에이전트에서 분리할 수 있지만, 싼 토큰 가격이나 높은 TPS만으로 효율을 판단하면 안 된다. Sonnet 5.5를 다룬 원문의 T3 Code 분석에서는 Opus의 절반가량 비용과 약 5분의 실행으로 조사 역할의 강점이 나타났지만, Cursor Bench에서는 작업당 271,920토큰을 써 Opus의 218,000토큰보다 많았고 Fish Slop 완료 시간도 43분으로 Opus의 36분보다 길었다. 즉 모델 라우팅은 역할별 실제 trace에서 전체 토큰, 캐시 읽기, 완료 시간, 결과 품질을 함께 비교해야 하며 한 데모의 승리를 기본 배치 규칙으로 일반화할 수 없다.

구현 순서는 명확하다. 먼저 프로덕션 trace와 오프라인 trace의 스키마·코드·환경을 맞추고, 성공과 실패를 재현 가능한 task로 고정한다. 다음으로 여러 variant를 동일 task에서 반복 실행해 절대 통과와 상대 행동을 함께 채점한다. 배포 후보에는 권한·샌드박스·관찰 계층을 독립적으로 적용하고, 서브에이전트 라우팅은 실제 비용과 완료 시간으로 평가한다. 마지막으로 배포 후 새 trace가 기존 분포와 달라지는지 확인한다. 어느 한 단계라도 관찰할 수 없다면 그 시스템은 자기개선이 아니라 자기변형에 가깝다.