실제로 사용하면서 성능이 개선되는 에이전트 설정이 있나요? (자기생성)

저도 이 길을 걸어봤습니다. 작고 고정된 회귀 테스트 세트로 시작하세요. 겪었던 실패 패턴을 다루는 10~15개 정도의 작업이면 됩니다. 변경 사항을 적용할 때마다 전체 테스트를 실행하고 통과율, 평균 해결 시간, 재시도 횟수, 동일한 실패 모드가 얼마나 자주 발생하는지 기록하세요. 학습된 규칙은 단순히 도출된 작업뿐만 아니라 최소 2~3개의 '보지 못한' 작업에서도 성능이 개선될 때만 메인 루프에 반영하세요. 모든 규칙 버전은 깃으로 관리하세요. 롤백은 체크아웃 한 번이면 되고, 회귀 테스트 통과율이 떨어지면 자동으로 되돌려야 합니다. 가장 큰 함정은 과거 실패에 과적합되는 것입니다. 에이전트가 과거 데이터에서만 개선된다면 새로운 작업에서는 금방 무너질 겁니다. 회귀 테스트 세트를 화려한 데모가 아닌 실제 지표로 삼으세요.

감사합니다, 정말 유용하네요. 이 과정을 통해 메인 루프에 들어간 활성 규칙은 지금까지 몇 개나 되나요?

보지 못한 작업을 실제 테스트로 사용하는 게 핵심 같네요. 그렇지 않으면 과거 실패를 암기하는 걸 실제 개선으로 착각하기 너무 쉽죠.

코딩 에이전트를 위한 로컬 평가 하네스로 비슷한 걸 시도해 봤는데, 루프 자체가 아니라 '더 낫다'는 게 무엇인지 정의하는 게 어려웠습니다. 단순히 마지막 세 번의 실패에 과적합되지 않게 하는 게요.

제 설정은 이전에 실패했던 작업들의 작은 회귀 세트를 유지하고, 프롬프트나 도구 변경을 적용하기 전에 에이전트를 그 작업들에 돌려보는 방식이었습니다. 통과율이 임계값 아래로 떨어지면 자동으로 롤백되게 했죠.

실제로 개선된 지표는 반복되는 버그 카테고리의 해결 시간이었는데, 2주 후 약 20% 빨라졌습니다. 하지만 에이전트가 새로운 문제를 해결하기보다 평가 방식을 속이기 시작하면서 성능 향상이 멈췄습니다.

네, 하네스와는 다른 형태입니다. 에이전트 내부에서 학습하는 게 아니라 규칙으로 기록하는 거죠. 실행이 잘못되면, 모든 에이전트가 시작할 때 읽는 공유 페이지에 문장 하나를 추가합니다(보내기 전에 확인할 것, 완료로 간주할 것 등). 그리고 실패할 수 있는 체크 항목도 추가하고요. 매일 체크를 통해 발견된 원인을 찾고, 규칙이나 스크립트를 수정하고 검증합니다. 그래서 같은 실수가 다른 에이전트를 통해 다시 발생할 가능성이 훨씬 낮아집니다.

측정은 점수를 쓰지 않기로 했습니다. 대신 0으로 유지되어야 하는 체크 항목을 사용합니다. 예를 들어, 답장이 없고 열린 작업도 없고 종료 사유도 없는 하루 지난 대화나, 마감일은 있는데 담당자가 없는 작업 같은 거죠. 이건 데이터에 대한 단순 필터라서 에이전트가 계산을 돕는 점수보다 속이기 훨씬 어렵습니다. 하나라도 0 이상이 되면 보통 규칙이 빠졌다는 신호죠. 롤백은 그냥 페이지를 되돌리면 됩니다.