모두가 지속적 학습(Continual Learning)이라고 하면 모델 가중치 업데이트라는 한 가지 의미만 떠올립니다. 하지만 에이전트 생태계에는 불편한 진실이 하나 있습니다. 현재 프로덕션 환경에 배포된 대다수의 에이전트는 폐쇄형 최첨단 모델을 활용한다는 점입니다. 가중치를 소유하지 않으면 당연히 미세 조정(fine-tuning)도 할 수 없습니다. 대부분의 에이전트 빌더에게 가중치 수준의 지속적 학습은 불가능한 일이며, 특히 최첨단 성능(Fable 5 또는 GPT 5.6 등)을 목표로 할 때 더욱 그렇습니다.
그렇다고 에이전트가 학습할 수 없다는 뜻은 아닙니다. 에이전트 시스템은 모델, 하네스(Harness), 컨텍스트(Context) [0]의 세 가지 계층에서 개선될 수 있으며, 마지막 두 계층은 전적으로 여러분이 통제할 수 있습니다. 바로 여기에 거대하지만 종종 간과되는 기회가 숨어 있습니다. 하네스 수준의 학습을 통해 프로덕션 트레이스를 분석하여 에이전트의 모든 인스턴스를 구동하는 코드, 도구, 명령어를 체계적으로 개선할 수 있습니다. 반면, 컨텍스트 수준의 학습을 통해 에이전트, 사용자, 조직 수준에서 개인화를 적용하여 모든 상호작용마다 제품이 향상되도록 만들 수 있습니다. 이 모든 것을 수행하면 매일 배포할 수 있는 복합적인 개선 효과를 얻을 수 있습니다.
이 글의 나머지 부분에서는 지난 1년간 Replit Agent 에 지속적 학습을 적용해 온 방법과 그 과정에서 얻은 모든 교훈을 공유하겠습니다.
Replit Agent 의 대규모 평가 및 개선
대부분의 Replit Agent 사용자는 아이디어에서 시작합니다. 저장소(repo), 테스트 스위트, 선택된 프레임워크 없이 자연어로 목표를 설명하면, 에이전트가 이를 실행 가능한 앱으로 만들어 주기를 기대합니다. 그 결과물은 웹사이트, 슬라이드 데크, 모바일 앱, 여러 개의 연결된 아티팩트, 또는 완전히 다른 형태가 될 수 있습니다.
Vibe 코더들은 일반적으로 diff나 테스트 출력을 확인하지 않습니다. Replit Agent 의 성공 기준은 생각보다 단순합니다. 사용자가 클릭했을 때 앱이 제대로 작동해야 한다는 것입니다.
이것이 평가의 역할을 바꿉니다. 단일 점수는 특정 배포 결정에 도움을 줄 수 있지만, 매주 Replit Agent 가 사용자에게 더 나아지고 있는지 알려주지는 못합니다. 이 질문에 답하기 위해 평가는 개선 루프의 일부가 되어야 합니다.
NASA Lewis Research Center, 엔진 연구 빌딩 중앙 통제실, 1968년 — 측정은 그것이 출시되는 것을 변화시킬 때 의미가 있습니다.
평가는 이제 더 많은 역할을 해야 합니다
에이전트 평가는 한때 일방향 프로세스처럼 보였습니다. 평가를 실행하고, 점수를 산출하고, 배포 결정을 내리는 식이었습니다. 이는 릴리스가 드물고 측정 대상이 거의 변하지 않을 때는 잘 작동합니다. 하지만 모델, 프롬프트, 도구, 제품 표면이 모두 빠르게 변화할 때는 무너집니다.
기존 루프는 평가가 제한적이라고 느끼게 만들었습니다. 하지만 Replit Agent 는 너무 빠르게 변화하기 때문에 단일 점수로 전체 결정을 내릴 수 없습니다. 점수는 특정 작업 집합에 대해 두 후보를 비교할 수 있습니다. 하지만 사용자가 무엇을 중요하게 생각하는지, 프로덕션에서 어디가 문제인지, 다음에 무엇을 개선해야 하는지는 설명하지 못합니다.
평가는 출시 점검에서 개선 루프로 전환되어야 했습니다.
기존 평가 작업은 인간의 배포 결정에서 끝납니다. 새로운 평가 작업은 프로덕션에서 학습하고 개선된 에이전트를 출시하는 지속적인 시스템에 정보를 제공합니다.
이 시스템은 두 가지 측정 축과 하나의 최적화 루프로 구성됩니다. 오프라인 벤치마크는 후보 변경 사항이 배포 전에 시뮬레이션된 앱 빌드 작업을 완료할 수 있는지 알려줍니다. 온라인 A/B 테스트와 프로덕션 트레이스는 변경 사항이 배포된 후 실제 사용자에게 어떤 영향을 미치는지 보여줍니다. 이러한 신호는 다시 평가 및 배포 결정으로 흘러갑니다.
어떤 계층도 단독으로 충분하지 않습니다. 벤치마크는 릴리스 전에 회귀(regression)를 잡아냅니다. A/B 테스트는 프로덕션 동작이 변경되었는지 보여줍니다. 트레이스 클러스터는 집계 지표 아래 숨겨진 실패를 설명합니다. 인간의 판단은 개선 루프가 올바른 제품 및 엔지니어링 결과를 향하도록 유지합니다. 이 구조는 안전 공학의 스위스 치즈 모델과 유사합니다. 각 계층에는 구멍이 있지만, 함께 사용하면 어떤 단일 계층보다 더 많은 것을 잡아낼 수 있습니다.
기존 벤치마크는 사용자의 요구를 충족시키지 못합니다
SWE-bench [1] 및 Terminal-Bench [2] 와 같은 에이전트 코딩 벤치마크는 제한적이고 반복 가능한 환경에서 코드를 평가합니다. 이러한 벤치마크는 가치 있고 널리 채택되었지만, Vibe 코더가 중요하게 생각하는 신호를 놓칩니다.
Replit Agent 는 종종 코드베이스를 처음부터 생성합니다. 사용자는 고정된 경로, 함수 시그니처, 선택자 또는 테스트를 가져오지 않습니다. 그들은 제품 요청을 가져옵니다. 에이전트가 스택, 스키마, 경로, 컴포넌트 및 상호작용 흐름을 선택합니다.
이는 기능적 정확성의 격차를 만듭니다. 에이전트는 코딩 벤치마크의 로컬 제약 조건을 충족하면서도 사용자가 보는 것, 즉 완성된 앱이 요청된 대로 작동하는지 여부에서는 실패할 수 있습니다. Vibe 코딩의 경우 평가 대상은 아티팩트 자체입니다. 로드되는지, 핵심 워크플로가 작동하는지, 결과가 요청과 일치하는지입니다.
ViBench 소개
이러한 종단 간 평가 스타일에 대한 필요성이 바로 우리가 ViBench [3]를 구축한 이유입니다. ViBench는 Vibe 코딩을 위한 공개 벤치마크로, 간단하지만 중요한 신호를 측정합니다. 에이전트가 구축한 애플리케이션이 사양을 충족하는가?
ViBench는 익명화된 Replit 프로덕션 트레이스에서 추출한 일반 영어 제품 요구 사항 문서(PRD)로 시작합니다. 그런 다음 에이전트는 PRD를 받고 기존 코딩 벤치마크에서 요구하는 스캐폴딩, 경로 또는 참조에 제약받지 않고 실행 가능한 앱을 처음부터 빌드합니다.
그러나 ViBench를 현실적으로 만드는 동일한 유연성은 동등하게 유연한 평가 에이전트, 즉 PRD에 기반을 둔 에이전트를 필요로 합니다. SWE-bench 스타일 벤치마크에서는 프로젝트가 이미 존재하므로 평가 표면이 고정되어 있습니다. Vibe 코딩에서는 에이전트가 스택, 경로, 컴포넌트 및 흐름을 선택합니다. 평가는 에이전트가 발명한 모든 것을 탐색해야 합니다.
이를 위해 각 ViBench 작업은 PRD와 완성된 앱이 충족해야 하는 기능 수준의 상호작용 및 어설션을 설명하는 자연어 테스트 계획 세트를 쌍으로 구성합니다. 평가 에이전트는 Playwright를 유연한 백본으로 사용하여 오프라인 시뮬레이션, 파일 조작, 멀티 테넌시와 같은 복잡한 기능을 실행할 수 있습니다. 앱의 로케이터나 구조를 사전에 알지 못하기 때문에 노트북 환경에서 작업하며 앱이 어떻게 구축되었는지 점진적으로 발견하고 단계별로 상호작용합니다. 이는 Replit의 자동화된 자체 테스트에 대한 초기 연구 [4]에서 가져온 접근 방식입니다.
Replit 규모에서 ViBench 및 일반적인 평가를 실행하려면 강력한 인프라 지원 [5]도 필요합니다. 내부적으로는 앱 빌드 및 에이전트 실행을 위해 격리되고 리소스가 풍부한 샌드박스를 빠르게 생성할 수 있는 동일한 프로덕션 인프라를 활용합니다. 샌드박스를 빠르게 포크(fork) [6]할 수 있기 때문에 평가 간 오염 위험 없이 평가의 상당 부분을 병렬로 실행합니다.
처음부터 앱을 빌드하는 것 외에도, 자연어 PRD를 자연어 테스트 계획으로 평가하는 동일한 ViBench 기반은 다양한 Vibe 코딩 시나리오에 적용됩니다. 기존 앱 내에서 에이전트가 어떻게 작동하는지 평가하기 위해, Replit의 중간 궤적 워크로드에 더 가깝게, 기존 코드베이스에서 시작하여 기능 PRD에서 기능 확장을 얼마나 잘 제공하는지 측정합니다. 해당 코드베이스는 자체 참조 구현 또는 에이전트가 Vibe 코딩한 앱에서 가져올 수 있으며, 이를 출판물에서는 Vibe-to-ref 및 Vibe-on-Vibe라고 부릅니다. 새로운 제품 표면을 출시할 때, 동일한 백본을 사용하여 Agent 4의 병렬-및-병합 및 하위 에이전트 분해에서 했던 것처럼 새로운 상호작용 패턴을 평가하기 위한 새로운 문제를 신속하게 도출할 수 있습니다.
ViBench는 행동 평가자를 고정한 상태에서 입력 및 구성 전략을 다양화합니다.
초기 ViBench 결과는 두 가지 유용한 교훈을 주었습니다. 첫째, 최첨단 코딩 벤치마크 점수가 항상 전체 앱 빌드로 이어지지는 않으며, 특히 오픈 가중치 모델의 경우 더욱 그렇습니다. 둘째, 대부분의 모델은 자체 코드를 확장할 때 성능이 저하되는데, 이는 오류가 종종 누적되기 때문입니다. 이 두 교훈은 우리에게 더 나은 목표를 제시합니다. 단지 테스트를 통과하는 코드를 작성하는 것이 아니라, 다음 사용자 요청을 견딜 수 있는 앱을 빌드하는 것입니다.
A/B 테스트는 우리 자신을 정직하게 유지하는 방법입니다
우리는 오프라인 평가를 깊이 신뢰하지만, 그것이 유일한 판단자는 아닙니다. 통제된 환경에서 좋아 보였던 에이전트 업데이트가 실제 사용자 행동을 퇴보시키는 경우를 충분히 목격했기 때문에 프로덕션에는 자체 측정 계층이 필요하다는 것을 알고 있습니다.
사용자는 대본이 없고, 항상 활동하며, 어떤 오프라인 벤치마크도 완전히 재현할 수 없는 규모로 운영됩니다. 그들은 프로젝트를 포기하고, 마음을 바꾸고, 예상치 못한 방식으로 기능을 결합하며, 우리가 테스트할 줄 몰랐던 실패 모드를 발견합니다.
따라서 우리는 대부분의 에이전트에 영향을 미치는 업데이트(프롬프트, 도구, 하네스 수정, 모델 교체, 더 큰 동작 변경)를 A/B 테스트합니다. 여러 실험이 동시에 실행되는 경우가 많으며, 상호작용 효과를 숨기지 않도록 기여도를 명확히 유지합니다. A/B 테스트는 사용자 행동, 감정 및 성공을 표면화합니다. 사용자가 계속 사용했는지, 비용이 예상치 못하게 행동했는지, 감정이 움직였는지, 사용자가 무언가를 출시했는지 등을 보여줍니다.
A/B 테스트는 프로덕션 동작에 대한 통제된 판독값을 제공하지만, 집계 지표는 스스로를 설명하지 않습니다. 이것이 승리인가? 근본적인 행동 변화는 무엇인가?
A/B 테스트의 과제는 결과를 해석하기 어렵다는 점입니다. 실행 시간이 늘어났다면 에이전트가 더 유용한 작업을 수행한 것일까요, 아니면 멈춰버린 것일까요? 비용이 줄었다면 효율성을 개선한 것일까요, 아니면 에이전트가 조용히 가치 있는 작업을 중단한 것일까요? 감정이 떨어졌다면 어떤 사용 사례가 퇴보했고, 어떤 실패 모드가 새로운 것이며, 어떤 사용자가 포기했을까요?
Telescope: 무엇이 문제인가
A/B 테스트는 프로덕션 동작이 언제 변경되었는지 알려줍니다. Telescope(트레이스 분석 및 클러스터링 시스템)는 그 이유를 설명하는 데 도움을 줍니다.
프로덕션 규모에서는 어떤 엔지니어도 모든 트레이스를 읽을 수 없습니다. Telescope는 반복되는 패턴을 엔지니어와 에이전트가 조치를 취할 수 있는 이슈 클러스터로 구성합니다. 실패 궤적을 요약하고, 임베딩하며, 유사한 사례를 클러스터링하고, 분포가 변경됨에 따라 새로운 세션을 분류합니다. 목표는 단순히 실패를 집계하는 것이 아니라, 눈에 띄지 않는 곳에 숨겨진 실패를 발견하는 것입니다.
GIF
우리가 찾을 줄 몰랐던 것을 클러스터링합니다.
Telescope는 Clio [7]와 동일한 상향식 접근 방식에서 영감을 받은 짧고 증거에 기반한 패싯(facet)을 사용합니다. 트레이스의 경우 사용자 메시지, 표시된 에이전트 응답, 도구 호출, 오류, 메타데이터 및 기타 컨텍스트에서 세션을 재구성합니다. 그런 다음 Telescope는 무엇이 잘못되었는지 요약하고, 해당 요약을 임베딩하며, 밀도 기반 클러스터링 [8]을 사용하여 새로운 이슈 그룹을 형성합니다.
패싯은 특히 클러스터링만으로는 충분하지 않을 때 조사를 더 빠르게 만듭니다. 지원 보고서가 포트 오류와 같은 광범위한 문제를 지적할 때, 엔지니어와 에이전트는 먼저 압축 계층을 검색하고, 관련 패싯을 탐색한 다음, 이를 설명하는 데 필요한 로그 및 관찰 가능성 컨텍스트가 있는 대표 세션을 자세히 살펴볼 수 있습니다.
집계적으로 동일한 구조는 흩어진 실패를 제품 질문으로 전환합니다. 어떤 워크플로가 지배적인지, 어떤 것이 포기되는지, 무엇이 반복적으로 고장 나는지, 그리고 완화 조치가 의도된 클러스터를 줄이고 있는지 여부입니다.
이 기본 아키텍처에 대한 자세한 내용은 Braintrust [9]의 협력자가 작성한 Topics에 대한 심층 게시물을 참조하십시오.
루프: 증거에서 에이전트 개선으로
일단 측정이 이루어지면 병목 현상이 이동합니다. ViBench, A/B 테스트 및 Telescope는 무엇이 실패했는지, 어디서 실패했는지, 얼마나 자주 발생하는지 알려줄 수 있습니다. 우리는 여전히 그 증거를 그럴듯한 수정으로 전환해야 합니다.
이를 해결하기 위해 우리는 자기 개선 루프를 사용합니다. 작동 원리는 간단합니다. 에이전트가 소프트웨어를 구축하는 데 유용하다면 에이전트 자체를 개선하는 데도 유용해야 한다는 것입니다. 각 패스는 프로덕션 로그, 트레이스 클러스터 및 최근 실패를 읽어 추적할 가치가 있는 가설을 찾는 것으로 시작합니다. 그런 다음 후보를 빌드하고, 추론이 첨부된 초안 PR을 열고, ViBench, A/B 결과, 궤적 데이터 및 최근 기준선에 대해 결과를 측정하고, 출시, 반복 또는 폐기할지 권장합니다.
최적화 루프는 문제를 발견하고, 에이전트 변경을 제안하며, 이를 평가하고, 출시, 반복 또는 폐기할지 결정합니다.
출시가 자동화되지는 않습니다. 루프는 증거와 첫 번째 구현을 준비할 수 있습니다. 엔지니어는 여전히 결과를 검토하고 출시 결정을 책임집니다.
각 실행은 시도한 내용과 발생한 상황(실패 포함)을 기록합니다. 이 기록은 시간이 지남에 따라 루프를 개선합니다. 향후 실행은 작동했던 것을 재사용하고, 알려진 막다른 길을 피하며, 일반화되는 변경을 제안할 수 있습니다.
에이전트 반복은 엔지니어링 제어를 포기하지 않으면서 더 빨라집니다. 새로운 모델, 제품 표면 또는 안정성 목표가 주어지면 루프는 엔지니어가 시스템을 더 큰 제품 최적점으로 유지하는 동안 프롬프트 편집, 스킬 제안, 도구 수정 및 하네스 변경을 사전에 찾을 수 있습니다.
구체적인 예
최근 한 실행은 작지만 성장하는 Telescope 클러스터에서 시작되었습니다. 환경 설정이 다양한 콜드 스타트 시나리오에서 조용히 저하되고 있었습니다. 이러한 세션은 집계 지표에서 명확하지 않았지만, 클러스터는 조사할 가치가 있는 패턴을 보여주었습니다.
패턴을 표면화한 후, 루프는 영향을 받은 궤적을 읽고, 패치를 제안하고, 회귀 테스트를 추가하고, ViBench에 대해 후보를 실행하여 해피 패스가 퇴보하지 않았는지 확인했습니다. 엔지니어는 증거를 검토하고, 변경을 승인하고, 같은 날 프로덕션에 푸시했습니다.
패치가 출시된 후 감정이 회복되고 영향을 받은 사용자의 문제가 해결되었습니다. 이것이 우리가 원하는 형태입니다. 실제 실패 패턴을 찾고, 영향을 받은 사용자에게 연결하고, 적절한 수준의 수정을 제안하고, 인간이 출시 여부를 결정하기에 충분한 증거를 가져오는 루프입니다.
인간의 취향이 여전히 가장 중요한 부분
이 중 많은 부분이 자율적으로 실행될 수 있습니다. 실패 클러스터링, 가설 제안, 후보 빌드, 평가 실행 및 증거 수집 등입니다. 인간은 여전히 방향을 설정하고 대부분의 출구를 통제합니다. 여기에는 다음이 포함됩니다.
- 가설 선택. 시스템은 수천 개의 실패를 표면화할 수 있지만, 어떤 질문이 루프의 야간 예산을 받을 자격이 있는지는 인간이 결정합니다. 모든 클러스터가 동등하게 중요한 것은 아니며, 모든 회귀가 올바른 제품 문제를 가리키는 것은 아닙니다.
- 구현 아키텍처. 트레이스는 사용자가 워크플로를 포기하고 있음을 보여줄 수 있지만, 해당 경로를 매끄럽게 할지, 에이전트의 동작을 변경할지, 아니면 표면을 재설계할지 결정하는 것은 엔지니어링 및 제품 판단입니다.
- 평가 큐레이션. 이것은 관리 작업이 아닙니다. 에이전트가 오르는 언덕을 형성합니다. 평가가 잘못된 행동에 보상한다면 최적화 루프는 충실하게 잘못된 방향으로 최적화할 것입니다.
- 출시 승인. 에이전트 변경을 출시하는 것은 단순히 숫자를 읽는 것이 아닙니다. 출시 승인은 증거를 읽고, 영향 범위를 이해하고, 위험이 수용 가능한지 결정하고, 롤아웃을 책임지는 것을 의미합니다.
이 균형이 중요합니다. 루프는 검색, 측정 및 합성의 더 많은 부분을 수행할 수 있습니다. 엔지니어는 여전히 방향을 선택하고, 제품 결정을 내리며, 무엇을 출시할지 결정합니다.
루프 닫기
평가는 더 이상 출시 전의 단순한 관문이 아닙니다. 무엇을 수정할지, 무엇을 테스트할지, 무엇을 릴리스할지 결정하는 데 도움을 줍니다.
목표는 더 나은 숫자를 만드는 것이 아닙니다. 사용자의 실패를 더 나은 릴리스로 전환하여 더 많은 아이디어가 사람들이 자랑스럽게 게시할 수 있는 앱이 되도록 하는 것입니다.
우리는 가장 복잡한 코딩 작업에 대한 안정성에 중점을 두고 자율 에이전트의 최전선을 계속해서 밀어붙이게 되어 기쁩니다. 자율 코딩 에이전트 작업에 관심이 있다면, 저는 항상 Replit AI 팀에서 채용 중입니다. [email protected]으로 연락주세요.
저자: Daniel Furman, Peter Zhong, Zhen Li, Michele Catasta
참고 자료
[1] SWE-bench: 언어 모델이 실제 GitHub 문제를 해결할 수 있을까?
[2] Terminal-Bench: 명령줄 인터페이스에서 어렵고 현실적인 작업에 대한 에이전트 벤치마킹
[4] REPL 기반 검증으로 Agent 3의 대규모 자체 테스트 활성화
[6] Replit의 스냅샷 엔진 내부: AI 에이전트를 안전하게 만드는 기술
[7] Clio: 실제 AI 사용에 대한 프라이버시 보호 인사이트
