[한영자막] 스스로 개선되는 AI 에이전트는 어떻게 만들었을까요?

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

스스로 개선되는 AI 에이전트는 운영 기록을 평가 과제로 바꾸고, 동일한 실행 코드로 개선 후보를 비교하며, 프롬프트와 스킬을 반복 수정하는 순환 구조로 만들어진다.

📌 핵심 요점

1. 운영과 오프라인 평가를 연결한다. Weave에 같은 형식으로 실행 기록을 남기고, 실제 운영에서 발생한 실패와 성공 사례를 오프라인 평가 과제로 전환한다. 이 기록이 다음 개선 실험의 출발점이다. [01:49–02:35, 12:02–12:14]
2. 실행 코드의 차이를 줄여 평가 신뢰도를 높인다. 발표자는 운영과 시뮬레이션에서 바이트 단위로 동일한 에이전트를 실행하고, 운영 코드를 연구 환경에 4시간마다 동기화한다고 설명한다. 다만 코드가 같아도 데이터와 환경의 차이는 계속 점검해야 한다. [05:27–06:02, 09:36–09:55]
3. 자기 개선의 중심은 프롬프트·스킬 실험이다. 발표자는 현재 강화학습보다 프롬프트와 스킬 개선에 주로 집중한다고 밝힌다. 모델과 설정을 바꾼 여러 후보를 YAML로 정의하고 병렬 평가해 더 나은 구성을 찾는다. [05:05–05:25, 07:00–07:43]
4. 과제 성공 여부와 후보 간 행동 차이를 함께 평가한다. 평가는 과제 통과 여부를 판정하는 방식과, 사용자에게 질문하는 방식처럼 후보별 행동을 상대 비교하는 방식으로 구성된다. 발표 당시 886개 과제를 운영하며, 단일 지시와 사용자 역할 모델을 활용한 다중 턴 대화 등을 시험한다고 설명한다. [09:58–10:16, 10:30–11:39]
5. 데모는 오류 재현부터 개선 후보 평가까지 연결한다. Arya는 운영 기록을 회귀 평가 과제로 만들고, 샌드박스의 weave.log 호출 문제를 식별한 뒤 프롬프트 또는 스킬에 지침을 추가한 후보를 실행했다. 다만 제공된 transcript에는 운영 버전 대비 후보의 최종 점수 차이가 명확히 제시되지 않는다. [12:45–13:48, 15:40–16:10]

🧩 배경과 문제 정의

• 발표는 Weights & Biases의 Arya 에이전트를 운영하면서, 실제 사용 기록을 오프라인 평가 과제로 바꾸고 그 결과로 에이전트를 개선하는 과정을 다룬다. 여기서 자기 개선은 주로 프롬프트·스킬·구성 변경과 반복 평가를 뜻하며, 발표자는 현재 강화학습보다 프롬프트와 스킬 개발에 집중한다고 설명한다.
• 핵심 문제는 벤치마크, 평가 방식, 에이전트 구성이 서로 영향을 주고 계속 변한다는 점이다. 따라서 운영 환경과 시뮬레이션 환경의 차이를 줄이고, 두 환경에서 같은 형식으로 실행 기록을 수집해야 개선 효과를 판단할 수 있다.
• 검증 필요: 데모에서는 운영 기록의 과제화와 후보 변형 실행을 보여주지만, 후보가 기존 버전보다 얼마나 좋아졌는지 최종 비교 수치는 명확히 제시되지 않는다. 자기 개선의 일반적인 효과와 실제 운영 성능 향상은 추가 평가가 필요하다.

🕒 시간순 섹션별 상세정리

1. Arya 개발 배경과 평가의 어려움

• 발표자는 Arya의 개발·평가 체계와, Arya를 자체 연구 및 개선 반복 과정에 사용하는 방법을 보여준다. 도구 호출과 에이전트 실행 구조의 차이가 벤치마크 성능에 영향을 준다는 점이 출발점이다. [00:19]
• 벤치마크·평가·에이전트 설정이 함께 변하므로, 동적으로 바뀌는 시스템에는 신뢰할 수 있는 측정이 필요하다. 특히 오프라인 평가 결과가 운영 환경에서도 이어지는지 확인해야 한다. [01:16]
• 연구팀은 시뮬레이션 환경에서 Arya를 실행하고 Weave에 기록한다. 운영팀도 같은 형식으로 기록해, 실제 운영 추적 기록을 오프라인 환경으로 가져와 오류 분석과 개선에 활용한다. [01:49]
• 발표자는 Arya가 이 오프라인 개선 작업을 스스로 수행할 만큼 발전했다고 설명하며, 이를 직접 보여주는 데모로 넘어간다. [02:25]

2. 자체 연구와 운영 기록의 평가 과제화 데모

• ‘Arya Researches Arya’ 프로젝트에서 코드베이스를 W&B 아티팩트로 제공한다. Arya는 이를 대상으로 작업을 실행하고, 운영 기록을 검토하며, 개선 대상으로 삼을 새 과제와 자체 변형을 만들도록 요청받는다. [02:44]
• 별도 대화에서는 특정 운영 추적 기록을 오프라인 평가에 추가하고, 후보 에이전트와 운영 중인 에이전트를 해당 과제에서 실행하도록 요청한다. 평가 실행 기록은 Weave에 남는다. [03:41]
• 발표자는 최근 7주간의 야간 CI 평가로 운영 버전과 후보들의 성능 변화를 살핀다고 보여준다. 일부 과제에서 약 66%의 성능을 언급하지만, 이를 전체 과제의 종합 성능으로 제시하지는 않는다. [04:33]

3. 운영 코드와 연구 코드의 일치

• 현재 개발은 주로 프롬프트와 스킬 개선에 집중하지만, 환경을 견고하게 시뮬레이션하는 데에는 강화학습에서 쓰는 방법론이 도움이 된다고 보여준다. [04:58]
• 운영 환경과 시뮬레이션 환경에서 바이트 단위로 동일한 에이전트를 평가한다. 연구·운영 코드의 차이를 줄이기 위해 운영 코드가 연구 환경으로 4시간마다 동기화된다고 보여준다. [05:27]
• 대량의 실행 기록에서 행동 패턴을 관찰한 뒤, 사람이 직접 검토하거나 Arya에 성공·실패 원인을 분석하게 한다. 그 결과를 프롬프트 등으로 반영해 원하는 행동을 강화한다. [06:20]

4. 다양한 구성 실험과 샌드박스

• 여러 모델을 시험할 수 있도록 컨텍스트 압축, 컨텍스트 준비, UI 전달 데이터 구성 등을 모델에 종속되지 않는 소프트웨어 구조로 다룬다. [06:57]
• YAML로 에이전트 구성을 정의해 여러 변형을 병렬로 비교하기 쉽게 만든다. 발표자는 더 많은 실험을 실행할 수 있는 구조를 에이전트 실행 체계의 핵심으로 본다. [07:18]
• 자유롭게 작업할 수 있는 샌드박스는 예상하지 못한 행동을 시도할 기반이 된다. 발표 준비 중에는 Arya에 자체 연구 과정을 병렬 실행할 샌드박스를 만들도록 요청했다고 보여준다. [07:48]

5. 오프라인 평가 환경의 실행 단계

• 평가 흐름은 YAML 구성 읽기, 필요한 실제 데이터 로딩, 환경 준비로 시작한다. 학습 로그나 GPU 실행 시뮬레이션을 포함할 수 있어 환경 준비 비용이 크며, 병렬화가 도움이 될 수 있다. [08:34]
• YAML에 미리 담을 수 없는 실행 시점 정보를 구성에 다시 반영한 뒤, 운영과 동일한 에이전트를 실행하고 결과를 채점한다. 발표자는 특히 측정 방식의 견고함에 시간을 많이 쓴다고 드러낸다. [09:04]
• 평가와 운영 사이의 차이를 지속적으로 점검해야 한다. 병렬 평가가 끝나면 환경을 정리해 다음 실행과 동료의 작업에 영향을 주지 않도록 한다. [09:37]

6. 절대평가와 상대평가

• 한 평가 방식은 과제의 성공·실패를 판정한다. 다른 방식은 사용자에게 질문하는 변형과 질문하지 않는 변형처럼 서로 다른 행동 스타일을 상대적으로 비교한다. [09:58]
• 평가 과제는 환경의 시작 조건, 사용자 설정, 도달하려는 종료 조건을 YAML로 정의한다. 실제 사용자의 작업 흐름이 과제 설계의 기반이 된다. [10:30]
• 단순한 텍스트 지시로 과제를 만들 수 있다. 데모에서 요청한 ‘운영 추적 기록을 평가 프레임워크에 추가하기’도 하나의 질문에서 출발하는 과제의 예다. [10:45]
• 다중 턴 상호작용은 사용자 페르소나를 부여한 언어 모델이 정해진 순서로 질문하도록 시뮬레이션한다. 발표자는 886개 과제를 수준별로 분류하고, 제품팀이 적절성과 벤치마크 관련성을 검토하도록 공유한다고 보여준다. [11:14]

7. 성공과 실패를 모두 개선 데이터로 활용

• 운영과 오프라인의 실행 궤적을 함께 분석하고, 행동 패턴을 이해하기 위한 내부 도구를 만든다. 개별 점수뿐 아니라 에이전트가 어떤 과정을 거쳤는지가 중요한 분석 자료다. [11:42]
• 운영에서의 실패뿐 아니라 좋은 수행 사례도 평가 과제로 전환한다. 이를 반복적으로 활용해 에이전트의 행동을 개선하는 것이 평가 순환 구조의 핵심이다. [12:02]
• 발표자는 Arya가 개념적 안내에는 강점이 있다고 평가하며, 프로젝트 오류 분석은 더 개선하고 싶은 영역으로 꼽는다. 과제는 에이전트의 능력을 충분히 시험하도록 어렵게 만들려 한다. [12:17]

8. 데모 결과: SDK 오류를 회귀 평가로 전환

• 데모로 돌아와 Arya가 최근 운영 추적 기록을 새 과제로 만들고 실행·채점한 기록과 연구 보고서를 확인한다. 운영 버전이 해당 과제로 평가되는 과정도 보여준다. [12:34]
• 보고서에서는 운영 기록을 WBAF라는 오프라인 평가 프레임워크의 회귀 과제로 전환했다고 보여준다. Arya가 지목한 문제는 샌드박스에서 weave.log SDK 호출을 올바르게 사용하지 못한 것이었다. [13:07]
• 원래 추적 기록을 재현하고 수정 목표를 추가한 뒤 여러 에이전트 변형을 실행한다. 발표자는 운영 버전과 후보의 비교 결과를 요청하지만, 이 대목에서 최종 수치가 명확히 제시되지는 않는다. [13:27]

9. 자동화 이후에도 필요한 사람의 판단

• 발표자는 운영 추적 프로젝트와 오프라인 평가 프로젝트를 오가며, 팀의 실험과 스킬·에이전트 변경을 한 플랫폼에서 살피는 작업 방식을 강조한다. [13:50]
• 코드 작성과 실행을 자동화해도 어떤 개선이 필요한지 고민하는 책임은 남는다. 도구가 자체 개선 작업을 수행하면 사람은 시스템을 더 좋게 만드는 판단에 시간을 쓸 수 있다고 보여준다. [14:26]
• 운영과 오프라인 양쪽의 관측 가능성을 확보하고 평가 실행을 Arya에 맡기면, 사람은 개선 순환을 설계하고 유용한 도구가 되도록 제약 조건을 조정하는 데 집중할 수 있다는 주장이다. [15:09]

10. 최종 확인과 마무리: 운영 → 시뮬레이션 → 개선

• 마지막 데모에서는 예측·채점 과정과 도구 호출 기록을 살핀다. 후보 변형은 시스템 프롬프트나 스킬에 짧은 지시를 추가해 앞서 발견한 SDK 오류를 해결하거나 완화하려는 형태로 보인다고 보여준다. [15:40]
• 발표자가 남기려는 핵심은 운영에서 발견한 문제를 시뮬레이션으로 재현하고, 에이전트의 개선 방향을 정의하는 반복 과정이다. [16:04]
• 오프라인 평가 지표 설계, 운영 데이터 활용, 에이전트 개선의 순환 구조를 발표의 중심 논지로 다시 짚고 인사로 마무리한다. [16:29]

🧾 결론

• 이 발표에서 말하는 자기 개선은 에이전트가 자신의 실행 기록을 분석하고, 평가 과제와 수정 후보를 만들어 실험하는 과정이다. 모델 가중치를 스스로 학습·갱신했다는 설명은 없다.
• 개선의 기반은 실행 기록의 관측 가능성, 실제 사례를 반영한 평가 과제, 운영과 평가 환경의 정합성이다. 자동화가 늘어날수록 평가 기준의 품질이 중요해진다.
• 사람은 여전히 개선 방향과 가드레일을 설계해야 한다. 발표자도 실행을 자동화하는 것이 시스템을 어떻게 개선할지 고민할 책임까지 없애지는 않는다고 강조한다. [14:26–14:49, 15:23–15:35]
• 검증 필요: 일부 과제에서 약 66% 성능을 언급하지만, 해당 수치의 정확한 지표·대상 과제·비교 기준은 transcript만으로 확인하기 어렵다. 전체 성능이나 자기 개선의 효과로 일반화할 수 없다.

📈 투자·시사 포인트

• 시사점: 운영 기록을 평가와 개선 실험으로 연결하는 관측·평가 도구는 에이전트 개발 과정의 중요한 기반이 될 수 있다. 발표는 Weave와 Arya를 함께 사용하는 구체적인 작업 흐름을 보여준다.
• 투자 관점의 해석: 고객의 운영 사례와 평가 과제가 지속적으로 축적되면 플랫폼의 활용 가치와 전환 비용이 높아질 가능성이 있다. 실제 고객 유지율이나 매출 효과는 별도 확인이 필요하다.
• 비용 관점: 발표자는 대규모 학습 로그와 GPU 실행을 포함한 평가 환경 구성이 자원 집약적이라고 설명한다. 자동 개선의 경제성은 성능 향상뿐 아니라 평가 실행 비용과 소요 시간까지 함께 비교해야 판단할 수 있다.
• 검증 필요: 이 발표만으로 Arya의 상용 도입 규모, 유료 고객 성장, 수익성, 경쟁 제품 대비 우위를 판단할 수 없다. 투자 판단에는 고객 지표와 동일 조건의 성능·비용 비교가 추가로 필요하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 성능 수치의 해석: 약 66%의 성능을 언급하지만, 해당 과제의 범위·채점 기준·반복 횟수는 제시되지 않아 전체 성능으로 일반화하기 어렵다. [04:46–04:52]
• 개선 효과의 검증: 데모에서 SDK 오류를 겨냥한 프롬프트를 후보 버전에 추가했다고 설명하지만, 운영 버전 대비 점수 차이와 다른 과제의 성능 저하 여부는 확인되지 않는다. [15:54–16:04]
• 자기 개선의 범위: 발표는 주로 프롬프트와 스킬 개선을 다룬다. 모델 가중치의 자동 학습이나 변경 사항의 무인 운영 배포까지 이루어진다고 단정할 수 없다. [05:09–05:20]
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 운영 환경의 실패 사례와 성공 사례를 각각 선정하고, 초기 상태·사용자 요청·기대 결과를 명시한 오프라인 평가 과제로 전환한다. [10:33–10:42, 12:02–12:14]
• 운영 버전과 후보 버전을 같은 과제·환경 조건에서 실행하고, 과제 통과 여부와 행동의 상대 비교를 함께 기록한다. [09:58–10:13]
• 코드 버전과 트레이스 기록 형식을 맞추고, 운영 환경과 평가 환경 사이에 남는 차이를 점검한다. [02:13–02:23, 05:29–05:56]
• SDK 오류 대응 프롬프트를 검증할 때 원래 실패 과제뿐 아니라 관련 과제도 반복 실행해, 수정 효과와 성능 저하 여부를 확인한다. [13:22–13:39, 15:54–16:04]

❓ 열린 질문

• 에이전트가 자신의 결과를 채점할 때, 채점의 편향이나 오류를 어떤 독립적인 기준으로 검증하는가?
• 운영 트레이스에서 만든 과제를 반복 최적화하면서, 새로운 사용자 요청에 대한 일반화 성능은 어떻게 측정하는가?
• 후보 버전을 운영에 반영하는 통과 기준과 사람의 검토 범위는 무엇인가?