에이전트 하네스 설계 · 6/10
독립 판정기가 생기자 실행마다 기준별 점수와 반려 사유가 남기 시작했습니다. 이 신호는 답을 한 번 더 만들지 결정하는 데만 쓸 수도 있지만, 같은 유형의 실패가 반복된다면 다음 실행의 설정을 고치는 근거가 될 수도 있습니다. 반복 상한이나 검색 폭, 판정 문턱 같은 값을 사람이 하나씩 바꿔 보던 작업을 제한된 탐색 문제로 바꿀 수 있었습니다.
6월 17일 SelfForge를 시작할 당시에는 생성과 판정, 재시도 이유가 이미 분리돼 있어 설정 변화와 점수 변화를 연결해 시험할 기반이 마련돼 있었습니다.
가장 단순한 구현은 여러 설정 조합을 실행한 뒤 점수가 가장 높은 조합을 고르는 방식입니다. 하지만 출력 길이와 반복 횟수를 동시에 바꿔 점수가 올랐다면 어느 변경이 효과를 냈는지 알 수 없습니다. 평가에 사용한 과제와 판정기의 취향에만 잘 맞는 설정을 선택할 위험도 큽니다. 자동 탐색기는 성능을 높이는 장치인 동시에 평가의 빈틈을 더 빨리 파고드는 장치가 될 수 있습니다.
그래서 중심을 후보 생성 알고리즘보다 변경을 승격하거나 되돌리는 절차에 뒀습니다.
한 번에 한 항목만 바꿨습니다
하네스 설정 전체를 모델에게 넘겨 자유롭게 다시 쓰게 하면 다양한 후보를 만들 수 있습니다. 그러나 시스템 지시문, 반복 상한, 판정 문턱, 활성 전략이 한꺼번에 달라지면 사실상 새로운 하네스가 됩니다. 점수 변화의 원인을 분리할 수 없고, 롤백도 이전 설정 파일을 통째로 덮는 수준에 머뭅니다.
SelfForge는 등록된 설정 항목만 바꿉니다. 숫자, 불리언, 열거형마다 자료형과 허용 범위를 두고, 하나의 Move는 설정 한 곳만 변경합니다. 후보를 만들 때는 바꾸기 전 값과 바꾼 뒤 값뿐 아니라 정확히 반대로 적용할 inverse도 함께 계산합니다.
Move
target : max_iterations
before : 4
after : 3
inverse : 3 → 4
이 제약은 탐색 공간을 줄입니다. 여러 값을 함께 움직이는 방법보다 최적점에 천천히 도달할 수 있습니다. 대신 ‘검색 폭을 줄였더니 평가 점수가 어떻게 변했다’처럼 한 단계의 인과를 남길 수 있습니다. 오프라인 탐색은 기준 설정의 복사본에 후보를 적용하고, 탈락하면 그 복사본을 채택하지 않습니다. inverse는 변경을 되돌릴 수 있는지 검증하고 감사 기록과 런타임 복구에 쓰는 계약이지, 탈락할 때 운영 설정에 역변경을 다시 실행한다는 뜻은 아닙니다.
개발 점수와 승격 문턱을 나눴습니다
한 항목씩 바꿔도 같은 문제셋으로 후보를 만들고 채택하면 과최적화는 남습니다. 개발 과제에 자주 나오는 표현을 판정기가 선호할 뿐 새로운 입력에서는 나빠질 수 있습니다. 판정 점수 자체가 목표가 되면 설정 탐색이 판정기의 허점을 학습하는 Goodhart 문제가 생깁니다.
그래서 기준 설정을 먼저 평가한 뒤, 한 항목을 바꾼 후보의 개발 점수가 좋아졌는지와 별도 점수가 떨어지지 않았는지를 각각 확인하도록 승격 문턱을 뒀습니다. 독립 보조 지표를 등록했다면 그 값도 함께 비교합니다. 하나라도 실패하면 후보 복사본을 채택하지 않고 현재 기준 설정을 유지합니다.
기준선 평가
→ 한 항목 변경
→ 개발 점수 개선?
→ 별도 점수 유지?
→ 등록한 보조 지표 유지?
→ 승격 또는 후보 폐기
세 결과를 평균 하나로 합치지 않았습니다. 개발 점수가 크게 올랐다는 이유로 다른 점수의 하락을 상쇄하게 두면 과최적화 신호를 놓칩니다. 후보가 탈락했을 때 어떤 문턱을 넘지 못했는지 설명할 수 있어야 다음 탐색이 같은 실수를 반복하지 않습니다.
다만 현재 구현을 엄밀한 held-out 검증이라고 부를 수는 없습니다. Objective.evaluate()가 별도 문제셋의 실행 기록을 반환하고, 다음 후보를 제안하는 reflection이 그 기록을 읽습니다. 간편 API인 from_bench()는 개발 문제셋과 비교 문제셋도 동일하게 둡니다. 보조 지표 역시 도메인이 등록한 경우에만 작동합니다. 개발 점수는 1e-9보다 크기만 하면 상승으로 보고, epsilon은 비교 점수의 하락 허용치에만 적용합니다. 따라서 모델 판정의 잡음보다 충분히 큰 개선인지를 검정하는 문턱도 아직 없습니다.
현재 문턱은 회귀를 줄이는 방어선이지만, 후보 생성이 보지 못하는 최종 테스트셋을 보장하지는 않습니다. 시간·토큰·비용도 지금 Objective의 기본 축이 아니므로, 별도 보조 지표와 실행 기록으로 추가해야 합니다.
실전에서는 문제셋을 최소 세 층으로 나누는 편이 안전합니다. 후보를 만드는 개발셋, 승격을 거르는 검증셋, 탐색이 끝난 뒤 한 번만 여는 최종 테스트셋입니다. 지금 구현은 앞의 두 역할이 일부 섞여 있으므로 최종 테스트를 탐색기 밖에서 별도로 실행해야 합니다.
반성은 후보를 제안하지만 범위를 넘지 못합니다
점수만으로는 다음에 어떤 설정을 바꿀지 정하기 어렵습니다. 평가 피드백을 읽는 reflection은 실패 사례를 바탕으로 다음 Move의 이유를 제안합니다. 예를 들어 도구를 찾지 못한 사례가 반복되면 검색 폭을 조정하자는 후보를 만들 수 있습니다.
하지만 reflection이 설정을 직접 쓰지는 않습니다. 제안은 등록된 항목과 자료형, 허용 범위를 통과해야 하며 한 번에 한 항목이라는 규칙도 지켜야 합니다. 판정 모델이 낸 자연어 제안과 실제 적용 권한을 분리한 것입니다. 후보 생성이 아무리 영리해져도 승격 게이트와 롤백 계약은 바뀌지 않습니다.
탐색 자체에도 종료 조건을 뒀습니다
‘더 좋은 설정이 나올 때까지’라는 목표에는 끝이 없습니다. 후보 하나가 여러 모델 호출과 판정을 요구하므로 종료 조건이 없으면 개선 기능이 비용 폭주 경로가 됩니다.
SelfForge는 최대 단계 수인 max_steps와 연속으로 승격하지 못했을 때 멈추는 patience를 사용합니다. 둘 중 하나에 닿으면 현재 기준선을 반환합니다. 조기 종료는 실패가 아니라 정한 범위에서 더 나은 후보를 확인하지 못했다는 결과입니다.
각 탐색 기록에는 단계와 변경, 역변경, 비교 점수의 전후 값, 승격 또는 후보 폐기 결과, 과최적화 신호가 남습니다. 다만 개발 점수와 보조 지표 전체, 시간과 토큰, 비용이 현재 기록에 모두 보존되는 것은 아닙니다. 전체 평가 예산과 이미 방문한 조합을 추적하는 기능도 탐색 규모를 키우기 전에 보강해야 할 경계로 남았습니다.
다음 버전 탐색과 현재 실행 복구를 나눴습니다
설정 자동 변경에는 시간축이 다른 두 문제가 있습니다. 준비된 과제 묶음으로 다음 버전의 기본 설정을 찾는 일과, 현재 사용자 요청이 실패했을 때 이번 실행 안에서 복구하는 일입니다. 둘을 같은 기능으로 만들면 오프라인에서 검증한 변경과 운영 중 즉흥적인 변경이 섞입니다.
SelfForge는 전자에 해당합니다. 준비한 문제셋을 반복 실행하고 승격 문턱을 통과한 후보만 다음 기준 설정으로 남기는 오프라인 탐색기입니다. RuntimeConfigMutator는 현재 실행의 실패 신호를 받아 제한된 설정을 바꾸는 런타임 장치입니다. 이 경로는 별도 문제셋을 돌릴 수 없으므로 훨씬 좁은 권한과 실행 상한 안에서 움직여야 합니다.
런타임 변경은 off, observe, act 세 모드로 나눴습니다. 기본값인 off에서는 아무 값도 바꾸지 않습니다. observe에서는 어떤 변경을 제안했을지만 기록하고 실제 설정은 유지합니다. 운영 입력에서 제안 빈도와 오탐을 확인한 뒤에야 act에서 허용된 변경을 적용하고 역변경을 저널에 남깁니다. 오프라인 탐색 결과가 좋았다는 이유로 운영 중 자동 변경 권한까지 열지 않았습니다.
설정을 스스로 바꾸는 기능의 핵심은 많은 후보를 만드는 데 있지 않았습니다. 바꿀 수 있는 범위를 좁히고 승격 문턱과 종료 조건을 두며, 탐색기가 보지 않은 최종 테스트를 별도로 남기는 것이 먼저였습니다. 다음 편에서는 설정 탐색과 별개로, 두 모델을 실제 비교할 때 하네스의 실행 조건을 어떻게 맞췄는지 살펴봅니다.
이전 편 → 재시도와 종료 조건을 분리하는 이유(5편) 다음 편 → 모델을 비교하기 전에 실행 조건부터 통제하기(7편)