스스로 개선되는 AI 에이전트의 설계와 평가 플라이휠

URL: https://www.youtube.com/watch?v=kJj9sHyiRHI 날짜: 2026-09-29 채널: Tech Bridge

---

📌 핵심 질문 / 핵심 논점

==프로덕션에서 발생한 에이전트의 모든 성공과 실패를 동일한 오프라인 평가 환경으로 가져오고, Arya가 그 데이터를 이용해 스스로 변형·검증·개선하도록 만드는 방법은 무엇인가?==

• 벤치마크, 평가 방식, 에이전트 구성은 서로 공변(covariant)하므로 동적으로 바뀌는 시스템에는 프로덕션과 오프라인을 잇는 동일한 측정 체계가 필요하다.
• Weights & Biases Weave는 프로덕션 추적(production tracing)과 오프라인 시뮬레이션 추적을 같은 형식으로 기록해 실제 실패를 재현 가능한 회귀(regression) 과제로 바꾼다.
• Arya는 YAML 구성, 샌드박스 실행, 다수의 후보 변형, 점수 산정, 결과 분석을 반복하며 다음 에이전트 변형을 제안하는 오프라인 hill climbing 루프를 수행한다.

Zuban Isaola는 Weights & Biases에서 Arya agent를 만드는 일을 맡고 있다. Arya는 발표 당시 월요일에 general availability(GA)로 공개됐고, 핵심 목표는 단순히 도구를 호출하는 LLM을 제공하는 것이 아니라 연구·평가·배포를 하나의 관찰 가능한 루프로 묶는 데 있다. 프로덕션에서 수집한 trace를 오프라인 평가 환경에서 재실행하고, 개선 후보를 비교한 뒤, 검증된 변형을 다시 배포하면 에이전트의 품질 개선이 일회성 프롬프트 수정이 아니라 반복 가능한 시스템이 된다.

1. Arya와 에이전트 harness가 필요한 이유

에이전트의 능력은 모델 하나만으로 결정되지 않고, 도구 호출·프롬프트·스킬·컨텍스트 압축·UI payload 조립·실행 환경을 묶은 harness 전체의 설계에 좌우된다.

1.1. agentic harness의 구성 차이

1. 같은 모델도 포장 방식에 따라 성능이 달라진다

   1. 서로 다른 tool call과 패키지 조합으로 에이전트를 구성하면 동일한 모델이라도 벤치마크별 성능이 크게 달라진다.
   2. Claude Code와 skills를 조합하는 방식처럼 에이전트를 어떤 harness로 감싸느냐가 실제 작업 결과에 직접 영향을 준다.

2. 자유 실행 LLM과 소프트웨어 harness는 목적이 다르다

   1. LLM이 임의로 도구를 호출하도록 내버려두는 대신, harness는 실행 순서·환경·관찰 지점·평가·재현 조건을 통제한다.
   2. Arya의 목적은 Weights & Biases 플랫폼 안에서 사용자를 대신해 연구하고, 그 연구 결과를 다시 자신의 구성 개선에 활용하는 것이다.

1.2. 공변성(covariance)과 sim-to-real 문제

1. 벤치마크와 에이전트 설정은 분리된 변수가 아니다

   1. 벤치마크, 평가(evaluation), 에이전트, 에이전트 구성(configuration)은 모두 함께 변하는 공변 관계에 있다.
   2. 에이전트를 바꾸면 측정 방식과 작업 수행 양상도 바뀌므로, 고정된 단일 점수만으로 동적 시스템의 품질을 설명하기 어렵다.

2. 시뮬레이션과 실제 환경 사이의 간극을 줄여야 한다

   1. 원칙적인 평가를 적용하려면 시스템이 실제로 어떻게 동작하는지 확인할 수 있는 좋은 측정이 필요하다.
   2. 강화학습에서 말하는 sim-to-real gap처럼, 오프라인 시뮬레이션에서 얻은 결과가 프로덕션에서도 성립하는지 검증해야 한다.
   3. 프로덕션과 오프라인 환경을 별개의 파이프라인으로 만들면 구성·로깅·데이터의 drift가 생기므로 두 환경을 같은 실행 형식으로 맞춘다.

2. Weave가 만드는 프로덕션–오프라인 관찰 루프

프로덕션 trace와 오프라인 trace를 같은 포맷으로 연결하면 실제 오류를 재현하고, 성공 사례까지 반복 학습 과제로 전환할 수 있다.

2.1. Weave의 양쪽 관찰성(observability)

1. 오프라인 평가 관찰

   1. 연구팀은 시뮬레이션 환경을 만들고 그 위에서 Arya를 실행한 뒤 Weave에 trace와 오프라인 metric을 기록한다.
   2. 여러 에이전트 변형의 실행 궤적(trajectory), 도구 호출, 결과 점수를 한 프로젝트에서 비교한다.

2. 프로덕션 관찰

   1. 다른 팀은 실제 환경에 배포된 Arya가 수행하는 작업을 동일한 형식으로 로깅한다.
   2. 프로덕션 trace를 오프라인 환경으로 가져와 hill climb하거나 오류를 재현하고, 개선된 후보가 실제 배포 변형보다 나은지 비교한다.

3. flywheel의 핵심

   1. 프로덕션에서 발생한 trace가 오프라인 평가의 입력이 된다.
   2. 오프라인에서 검증한 agent variant가 다시 프로덕션에 배포된다.
   3. 새 프로덕션 trace가 다시 다음 평가와 개선의 재료가 되면서 관찰–재현–개선–배포의 순환이 이어진다.

2.2. Arya가 자기 자신을 개선하는 위치

1. Arya는 평가 대상이면서 평가를 수행하는 도구다

   1. Arya가 충분히 정교해지면서 스스로 오프라인 hill climbing을 실행할 수 있게 됐다.
   2. 코드베이스와 평가 프레임워크를 읽고, 새 task를 만들고, 후보 variant를 실행하고, 결과를 분석해 다음 수정 방향을 제안한다.

2. 일상적인 개발 루프

   1. Weave에서 프로덕션 trace를 확인한다.
   2. 오프라인 evaluation sandbox에서 동일한 작업을 실행한다.
   3. 새 에이전트 버전을 배포하고 팀과 결과를 검토한다.
   4. 프로덕션에서 얻은 성능과 실패를 다시 오프라인 평가 항목으로 추가한다.

3. 라이브 데모: Arya가 Arya를 연구하는 프로젝트

3.1. Arya Researches Arya의 실행 구성

1. 자기 연구 프롬프트

   1. Arya Researches Arya라는 데모 프로젝트를 만들고, 다른 Arya 세션에서 생성한 비교적 긴 프롬프트를 입력했다.
   2. 프롬프트는 Arya가 자신의 코드와 평가 체계를 조사하고, 새 변형을 만들어 결과를 비교하도록 지시한다.

2. 실행에 사용된 자원

   1. Weights & Biases artifact로 기록된 코드베이스를 읽는다.
   2. 오프라인 evaluation framework를 대상으로 training job을 실행한다.
   3. 기존 프로덕션 trace를 검토하고 hill climb할 새 task를 추가한다.
   4. 평가에 시간이 걸리는 동안 Arya는 자기 자신의 새 variant를 작성하고 실행한다.

3. 프로덕션 trace의 재사용

   1. 개인정보와 세부 정보가 정리된(sanitized) 내부 고객 trace를 프로덕션 프로젝트에서 확인한다.
   2. 현재 실행 중인 대화가 trace로 남는 것을 확인한 뒤, 그중 하나를 오프라인 evaluation framework로 복사한다.
   3. Arya에게 trace를 오프라인 eval에 기록하고 production agent와 candidate agent를 같은 task에서 실행하라고 요청한다.
   4. 두 평가의 결과는 실행 중인 상태부터 Weave에 기록된다.

3.2. 프로덕션 CI의 관찰 결과

1. 장기간 성능 추적

   1. 프로덕션 프로젝트에는 최근 7주 동안 매일 밤 실행된 CI job의 trace가 쌓여 있다.
   2. 실제 프로덕션 형식의 에이전트와 새로 만든 candidate variant의 상대 성능을 시간 흐름에 따라 비교할 수 있다.

2. 실패도 개선 데이터가 된다

   1. CI가 한동안 깨졌을 때 Arya가 전날 밤 스스로 수정했다.
   2. 일부 task에서 약 66%의 성능을 기록했고, 여러 종류의 작업을 함께 측정하면서 어떤 영역이 약한지 확인한다.

4. 오프라인 시뮬레이션 환경의 설계

오프라인 hill climbing은 실제 배포 환경을 최대한 그대로 복제한 뒤, 저렴하고 반복 가능한 방식으로 많은 변형을 비교하는 문제다.

4.1. 강화학습보다 prompt engineering에 집중하는 배경

1. 현재의 실용적 선택

   1. 전통적으로 강화학습을 적용하면 강건한 에이전트를 만들 수 있지만, Weights & Biases의 작업에서 최신 모델은 이미 많은 task를 비교적 잘 수행한다.
   2. 그래서 현재는 모델 가중치를 직접 학습시키기보다 소프트웨어 에이전트의 skills와 prompt를 설계하는 데 더 많이 집중한다.

2. 강건성 방법론은 그대로 적용된다

   1. 강화학습을 쓰지 않더라도 시뮬레이션 환경을 얼마나 실제와 강건하게 맞추는지는 동일하게 중요하다.
   2. 프로덕션과 시뮬레이션에서 bitwise-identical한 에이전트 버전을 벤치마크해 환경 차이로 인한 오판을 줄인다.

4.2. 연구 환경과 프로덕션 환경의 동기화

1. 코드와 로깅의 동일성

   1. Weave logging framework를 사용하는 방식과 시스템 설계 모두에서 연구 코드와 프로덕션 코드가 정확히 같다.
   2. 배포 계층과 오프라인 benchmarking 계층이 서로 닮은 구조를 가지므로 어느 한쪽에서 확인한 trace를 다른 쪽에서 재현할 수 있다.

2. 4시간 동기화 작업

   1. 프로덕션에서 연구 환경으로 4시간마다 sync job이 실행된다.
   2. 연구자가 새 agent variant나 skill을 만들고 hill climbing을 진행할 때 양쪽의 drift가 커지는 것을 막는다.

3. score trajectory

   1. 팀 내부에는 run eval 명령이 여러 개 제공되며, 각 명령은 점수 궤적(score trajectory)을 생성한다.
   2. 여러 metric의 상대 점수와 에이전트가 시간에 따라 남긴 실행 trace를 프로젝트에서 함께 확인한다.

4.3. 많은 trace에서 emergent property를 찾는 방식

1. trace의 양과 해석

   1. 많은 trace를 먼저 생성하고, 그 많은 trace를 어떻게 사용할지 결정하는 것이 기본 전략이다.
   2. trace에는 에이전트의 emergent property가 드러나며, 관찰된 행동을 원하는 방향으로 정렬할 단서가 들어 있다.

2. 사람과 Arya의 공동 분석

   1. 개발자는 task와 rollout을 직접 살펴보고 무엇이 잘됐고 무엇이 잘못됐는지 판단한다.
   2. Arya에게 자기 rollout이나 다른 rollout을 검토하게 하고, 발견한 행동을 prompt나 다른 수정 방식으로 강화하도록 할 수 있다.

5. 모델·구성·샌드박스의 변형 전략

동일한 실행 구조를 유지하면서 모델, YAML 구성, 샌드박스 권한, skill을 여러 방향으로 바꿔야 어떤 변화가 실제 개선을 만드는지 알 수 있다.

5.1. 모델에 무관한 소프트웨어 스택

1. 다양한 모델 비교

   1. CoreWeave inference에서 제공하는 모델과 여러 foundation model provider의 모델을 함께 시험한다.
   2. 특정 모델에 종속되지 않도록 compaction 처리, context 준비, UI payload 조립을 상대적으로 agnostic한 소프트웨어 계층으로 정의한다.

2. 동일 구성의 다수 변형

   1. 에이전트 구성은 YAML로 정의해 같은 기본 설정에서 여러 variant를 병렬로 만든다.
   2. 각 variant를 모두 실행하고 결과를 비교해야 문제를 개선할 수 있는 구체적인 통찰을 얻는다.
   3. 오래된 reinforcement learning이나 일반적인 model training의 교훈처럼, 적은 실험보다 많은 실험을 실행하는 편이 낫다는 원칙을 harness에도 적용한다.

5.2. 제약이 적은 sandbox

1. sandbox의 목적

   1. 고객에게 최선의 제품을 제공하려면 에이전트가 필요한 작업을 자유롭게 시도할 수 있는 sandbox가 필요하다.
   2. 코드 모드(code mode)가 많이 언급되는 환경에서, 제한된 단일 경로가 아니라 스스로 실험할 수 있는 실행 공간을 제공한다.

2. 자기 연구 루프의 병렬 실행

   1. 발표 준비 전날까지 Arya가 자기 연구 루프를 여러 개 병렬 실행할 수 있을지 확신하지 못했다.
   2. 발표 자료를 작성하고 준비하는 과정에서 Arya에게 자기 자신을 위한 sandbox를 만들고 연구 루프를 병렬 실행하라고 요청했다.
   3. 제한되지 않은 sandbox는 설계자가 미리 예상하지 못한 emergent behavior를 발견하는 데 유용하다.

3. 불명확한 슬라이드 문구

   1. 슬라이드에 보인 six phrases per record라는 문구는 발표자도 정확한 의미를 확신하지 못한다고 짚었다.
   2. 그 문구의 세부 의미보다, simulation environment를 생성하는 일반적인 패턴을 만드는 일이 이론적으로 더 중요하다고 설명했다.

6. 시뮬레이션 DAG와 실행 단계

전통적인 machine learning pipeline처럼 구성 파일을 실제 데이터와 환경으로 확장한 뒤 에이전트를 실행하고 점수를 산정하는 DAG를 사용한다.

6.1. 환경 생성 DAG

1. 구성 로드와 데이터 주입

   1. YAML 파일로 된 configuration을 입력으로 받는다.
   2. 필요한 live data를 불러와 configuration을 hydrate한다.

2. 비용이 큰 환경 준비

   1. 프로덕션 데이터나 전체 machine learning training log를 대조해야 하므로 Weights & Biases 환경 생성에는 비용이 든다.
   2. auto research에서 GPU 실행까지 시뮬레이션해야 한다면 작업량이 더 커지므로 여러 환경을 병렬화한다.

3. runtime 설정 보완

   1. YAML만으로는 표현할 수 없는 runtime configuration이 있다.
   2. 환경을 준비한 뒤 필요한 값을 다시 주입하고(hydrate/rehydrate), configuration에 hot patch한다.

4. 에이전트 실행과 점수 산정

   1. 프로덕션에서 사용하는 bitwise-identical한 에이전트를 실행한다.
   2. 실행 자체는 상대적으로 단순하고, 결과의 robustness를 보장하는 scoring이 가장 많은 사고를 요구한다.

5. 병렬 실행 정리

   1. 병렬 evaluation이 끝나면 환경을 teardown한다.
   2. 다음 실행을 위해 자원을 정리하고, 팀원의 작업을 덮어쓰거나(clobber) 방해하지 않도록 한다.

6.2. 평가 건강도와 production drift

1. 평가 자체도 관찰 대상이다

   1. 실행 설정을 정한 뒤에는 결과를 얼마나 robust하게 측정하는지 별도로 점검해야 한다.
   2. 팀원이 하루 종일 evaluation health와 evaluation–production drift를 검토했다는 Slack 메시지를 보내왔고, 이런 점검이 높은 가치가 있다고 평가했다.

2. 문제 원인을 추적하는 질문

   1. 왜 어떤 결과는 잘 작동하는가?
   2. 왜 어떤 결과는 작동하지 않는가?
   3. 오프라인 패턴과 프로덕션 패턴 사이에 어떤 gap이 있는가?
   4. 이 질문들이 평가 체계를 단순 점수표가 아니라 시스템 진단 도구로 만든다.

7. 점수화와 task 설계

Arya의 평가 체계는 절대적인 통과 여부와 두 후보의 상대적인 행동 차이를 함께 측정한다.

7.1. 두 종류의 scoring

1. 규범적 점수(normative scoring)

   1. task를 통과했는지 여부를 판단한다.
   2. 기본적인 pass/fail 결과를 제공해 최소 성공 조건을 확인한다.

2. 상대적 점수(relativistic scoring)

   1. 한 variant는 사용자에게 질문하고 다른 variant는 질문하지 않도록 스타일을 다르게 설정한다.
   2. 두 variant의 행동과 결과를 비교해 어느 방식이 더 잘 작동하는지 판단한다.
   3. 여러 후보 중 어느 변경이 더 나은지를 비교한다는 점에서 전통적인 reinforcement learning의 상대 평가 방식과 닮았다.

7.2. 사용자 흐름으로서의 task

1. YAML task specification

   1. task는 환경의 시작 조건, 사용자 configuration, 도달해야 할 종료 조건을 YAML로 정의한다.
   2. 실제 제품에서 발생하는 사용자 흐름을 평가 환경 안에 옮긴다.

2. 단일 질문 task

   1. 가장 단순한 형태는 Arya에게 직접 instruction 하나를 보내는 텍스트 task다.
   2. 데모에서 프로덕션 trace를 오프라인 framework로 옮기고 Arya에게 자기 연구를 계속하라고 요청한 흐름이 이 유형에 해당한다.

3. persona 기반 multi-turn task

   1. 사용자 persona를 가진 별도의 language model을 시뮬레이터로 둔다.
   2. 시뮬레이터에게 특정 사용자인 것처럼 행동하고, 정해진 순서로 질문하게 해 여러 차례 상호작용을 재현한다.

4. 886개 task의 관리

   1. 총 886개 task를 보유하고 난이도(level)별로 분류한다.
   2. 제품팀에 task를 공개해 벤치마크가 관심 있는 행동을 충분히 반영하는지, task 자체가 품질 기준을 충족하는지 검토하게 한다.
   3. 검토된 task를 여러 번 실행해 단일 우연한 결과가 아닌 반복 성능을 측정한다.

8. 평가 flywheel과 자기개선 데모의 결과

8.1. trajectory가 만드는 학습 재료

1. 프로덕션과 오프라인 행동의 결합

   1. 실제 트래픽에서 발생한 프로덕션 trace와 오프라인 trace 모두에서 행동 패턴을 찾는다.
   2. 양쪽 trace를 이해하기 위한 자체 tooling을 만들고, 프로덕션과 오프라인에서 같은 behavior trace project를 실행한다.

2. 성공과 실패를 모두 task로 변환

   1. 프로덕션에서 발생한 miss는 재현해야 할 개선 task가 된다.
   2. 프로덕션에서 발생한 goodness도 긍정적인 방향으로 hill climb할 수 있는 기준이 되므로 task가 된다.
   3. 성공을 복제하고 실패를 교정하는 두 방향의 데이터가 agent framework를 계속 정의한다.

3. 난도가 높은 task의 필요성

   1. Arya는 사용자를 개념적으로 안내하는 능력이 강하지만, 프로젝트의 error analysis를 더 잘하도록 만들 여지가 있다.
   2. 실제 성능의 한계를 드러내기 위해 task를 가능한 한 어렵게 설계하고, 높은 난도의 문제로 agent의 실력을 검증한다.

8.2. WBAF regression task 생성

1. trace에서 회귀 task까지 자동 연결

   1. Arya는 프로덕션 trace를 읽고 새 task를 작성한 뒤 실행하고 점수를 매겼다.
   2. 실제 Arya agent trace를 WBAF regression task로 변환했다.
   3. WBAF는 Weights & Biases Agent Factory의 약자로, 오프라인 benchmark를 구축하는 공장(factory) 역할을 한다.

2. 실제 오류의 발견

   1. sandbox에서 W&B SDK 호출인 weave.log를 올바르게 호출하지 않는 문제가 확인됐다.
   2. Arya는 원본 trace를 복제하고, 여러 agent variant를 실행해 어떤 변경이 문제를 개선하는지 비교했다.
   3. hill-climb target에는 오류를 고치기 위해 수행할 구체적인 조치가 기록됐다.

3. 프로덕션 후보 비교

   1. production variant와 candidate variant를 같은 task에서 실행한 결과를 비교한다.
   2. 최종 report에는 무엇이 발생했는지와 두 variant의 성능 차이가 남는다.
   3. 실제 개선안은 system prompt 또는 skill에 삽입한 짧고 정밀한 prompt였고, 해당 SDK 오류를 해결하고 완화했다.

9. 사람의 판단과 guardrail이 남는 이유

자동화 수준이 높아져도 개선의 방향과 안전한 실행 범위를 정하는 판단은 사람의 몫으로 남는다.

9.1. auto mode의 편리함과 위험

1. 코드를 직접 쓰지 않아도 되는 환경

   1. Zuban Isaola는 약 8개월 동안 직접 코드를 한 줄도 쓰지 않고 Claude에게 코드를 작성하게 했다고 말했다.
   2. auto mode는 에이전트가 작업 전체를 수행하게 만드는 편리한 방식이다.

2. 사고를 자동화할 수는 없다

   1. 자동으로 코드를 생성한다고 해서 어떤 방향으로 시스템을 개선할지 고민할 책임까지 사라지지는 않는다.
   2. 개발자는 trace와 결과를 보고 무엇을 강화할지, 어느 variant를 채택할지, 어떤 오류를 다음 task로 만들지 판단해야 한다.

9.2. 자기개선을 위한 guardrail

1. 더 중요한 개발자의 역할

   1. 자기개선 도구를 사용하면 반복 구현보다 시스템을 더 나은 방향으로 만드는 회색 영역의 사고에 시간을 쓸 수 있다.
   2. Arya가 스스로 강화되는 방식을 설계하고, 어떤 행동을 유용한 행동으로 간주할지 정의하는 일이 핵심 작업이 된다.

2. 작고 촘촘한 제어 경계

   1. auto mode 주변에 촘촘한 guardrail을 두어 에이전트가 더 유용한 도구가 되도록 한다.
   2. 자유로운 sandbox, robust scoring, production drift 점검을 함께 둬야 자기개선이 측정 가능한 개선으로 이어진다.

10. Weights & Biases 플랫폼을 떠나지 않는 운영 모델

10.1. 하나의 플랫폼에서 이어지는 작업

1. 두 프로젝트 사이의 왕복

   1. 프로덕션 tracing project에서 새 trace가 들어오는 과정을 관찰한다.
   2. 오프라인 evaluation project로 이동해 팀과 자신의 실험, skill 변경, agent variant 변경을 확인한다.
   3. 개선된 변형이 프로덕션으로 전개되는 과정을 다시 지켜본다.

2. 모델 추적까지 확장된 사례

   1. Weights & Biases의 model tracking platform은 Arya가 machine learning model을 학습하는 작업도 관찰한다.
   2. 다른 데모에서는 CoreWeave 인프라에서 H200 GPU로 모델을 학습하고, Andrej Karpathy의 nanochat에 대한 auto research를 수행했다.
   3. 소규모 실험뿐 아니라 full-scale production project도 같은 관찰성 모델로 다룬다.

10.2. 발표가 남긴 운영 원칙

1. 프로덕션과 오프라인의 완전한 관찰성

   1. 프로덕션 관찰성과 오프라인 관찰성을 모두 갖추면 어느 환경에서든 원인을 추적할 수 있다.
   2. Arya가 대신 실행하는 수많은 evaluation 덕분에 개발자는 시스템이 스스로를 더 잘 강화하도록 만드는 방법에 집중할 수 있다.

2. 최종 연결 고리

   1. 프로덕션 trace를 simulation으로 복제한다.
   2. simulation에서 agent variant를 정의하고 개선 패턴을 찾는다.
   3. 점수와 trace로 검증한 변형을 다시 제품에 적용한다.
   4. production → simulation → agent → improvement pattern의 연결이 Arya 설계의 핵심이다.

Q&A 및 현장 상호작용

청중과의 별도 질의응답 세션은 자막에 나타나지 않는다. 대신 Zuban Isaola는 라이브 데모에서 Arya에게 프로덕션 trace를 오프라인 eval로 옮기고 production/candidate agent를 실행하라고 직접 요청했다. 발표 준비 과정에서 Arya가 자기 연구 루프를 병렬 실행할 수 있는지도 즉석에서 확인했으며, 실행 결과는 Weave trace와 report로 검증했다.

주요 발언 모음

“벤치마크, 평가, 에이전트, 그리고 에이전트를 구성하는 방식은 모두 공변 관계에 있다.”

“시스템이 실제로 어떻게 수행되는지 보려면 좋은 측정이 필요하고, 프로덕션과 오프라인 환경 양쪽에서 성능을 확인해야 한다.”

“많은 trace를 생성한 다음, 그 많은 trace로 무엇을 할지 결정하는 것이 핵심이다.”

“오래된 강화학습이나 단순한 모델 학습의 교훈을 빌리면, 적은 실험보다 많은 실험을 실행하는 편이 낫다.”

“프로덕션에서 발생한 모든 miss와 모든 goodness가 에이전트 framework의 task가 된다.”

“auto mode가 개선에 필요한 사고까지 대신해 주는 것은 아니다.”

“프로덕션 관찰성과 오프라인 관찰성을 모두 갖추면 이 플랫폼을 떠나지 않고도 업무를 수행할 수 있다.”

“프로덕션에서 simulation으로, simulation에서 agent로, agent에서 improvement pattern으로 이어지는 복제가 핵심이다.”

핵심 데이터 & 수치

• GA 공개 시점: Arya agent는 발표 당시 월요일에 general availability로 공개됐다.
• 동기화 주기: 프로덕션에서 연구 환경으로 4시간마다 sync job이 실행된다.
• CI 관찰 기간: nightly CI trace가 최근 7주 동안 축적돼 시간별 성능 비교에 사용됐다.
• 관찰된 성능: 일부 task에서 약 66% 성능을 기록했다.
• task 규모: 사용자 흐름을 반영한 task 886개를 난이도별로 분류했다.
• 직접 코딩 기간: Zuban Isaola는 약 8개월 동안 직접 코드를 한 줄도 쓰지 않고 Claude에게 작성하게 했다고 말했다.
• 모델 학습 데모: CoreWeave 인프라의 H200 GPU와 Karpathy의 nanochat auto research 사례가 언급됐다.
• 평가 점수: pass/fail을 판단하는 normative scoring과 두 variant의 상대 행동을 비교하는 relativistic scoring을 함께 사용한다.

결론 및 시사점

1. 에이전트 품질은 모델 선택보다 모델·도구·프롬프트·스킬·실행 환경을 묶은 harness와 평가 루프의 설계에 크게 좌우된다.
2. 프로덕션과 오프라인 환경이 같은 코드와 로깅 형식을 사용해야 실제 오류를 재현 가능한 task로 옮길 수 있다.
3. 4시간 동기화와 bitwise-identical 실행은 연구 변형과 실제 배포 사이의 drift를 줄이는 실무 장치다.
4. 많은 trace를 수집하는 것만으로는 부족하며, trace에서 emergent behavior와 개선 방향을 읽어내는 분석 단계가 필요하다.
5. normative score는 최소 성공 여부를 보여주고 relativistic score는 후보 변형 사이의 행동 차이를 보여주므로 두 방식이 상호 보완된다.
6. 단일 질문 task와 persona 기반 multi-turn task를 함께 구성해야 실제 사용자 흐름에 가까운 평가가 가능하다.
7. 프로덕션의 실패뿐 아니라 성공도 task로 변환하면 교정과 복제를 동시에 수행하는 평가 flywheel이 만들어진다.
8. 자기개선 에이전트는 자유로운 sandbox만으로 완성되지 않으며 robust scoring, drift 점검, teardown, guardrail이 함께 필요하다.
9. auto mode는 구현 속도를 높이지만 무엇을 개선할지 결정하는 사람의 판단을 대체하지 않는다.
10. production → simulation → agent → improvement pattern의 연결은 Arya뿐 아니라 지속적으로 변하는 모든 소프트웨어 에이전트에 적용할 수 있는 설계 원칙이다.

핵심 요약 (20줄)

Arya agent는 Weights & Biases 플랫폼 안에서 연구·평가·배포를 연결하는 소프트웨어 에이전트다. 에이전트의 실제 성능은 모델뿐 아니라 도구 호출과 skill을 묶는 harness 구성에 좌우된다. 벤치마크와 평가 방식과 에이전트 구성은 함께 변하므로 동적 시스템에는 지속적인 측정이 필요하다. Weave는 프로덕션 trace와 오프라인 simulation trace를 같은 형식으로 기록한다. 프로덕션 trace는 오프라인 평가 환경으로 이동해 재현 가능한 regression task가 된다. 오프라인 평가에서 검증된 agent variant는 다시 프로덕션 배포 후보가 된다. 연구 환경과 프로덕션 환경은 같은 코드를 사용해 환경 차이로 인한 오판을 줄인다. 프로덕션에서 연구 환경으로 4시간마다 sync job이 실행돼 drift를 억제한다. 최근 7주간의 nightly CI trace는 에이전트 변형의 시간별 상대 성능을 보여준다. 일부 task에서 관찰된 성능은 약 66%였고 CI 장애는 Arya가 스스로 수정했다. Arya는 YAML 구성과 sandbox를 이용해 자기 연구 루프의 여러 실행을 병렬화한다. 시뮬레이션 DAG는 구성 로드와 데이터 주입과 환경 준비와 에이전트 실행과 scoring으로 이어진다. 정확한 scoring은 실행보다 어렵기 때문에 evaluation health와 production drift를 별도로 점검해야 한다. 규범적 scoring은 task 통과 여부를 측정하고 상대적 scoring은 variant 간 행동을 비교한다. 사용자 흐름은 단일 텍스트 instruction과 persona 기반 multi-turn task로 시뮬레이션된다. 886개 task는 난이도별로 분류되고 제품팀 검토를 거쳐 반복 실행된다. 프로덕션의 실패와 성공은 모두 다음 hill climbing을 위한 task와 데이터가 된다. WBAF는 실제 Arya trace를 regression task로 바꾸고 weave.log 오류를 찾아 수정 후보를 비교했다. auto mode는 구현을 자동화하지만 개선 방향과 guardrail을 정하는 사람의 사고를 없애지 못한다. 프로덕션에서 simulation과 agent와 improvement pattern으로 이어지는 flywheel이 자기개선의 핵심이다.