터미널에서 일하는 AI 에이전트에는 이상한 버릇이 있다. 같은 모델에 같은 환경인데, 어떤 날은 과제를 풀고 어떤 날은 못 푼다. 에이전트가 한 번의 작업에서 수십 개의 명령을 조금씩 다르게 이어 내놓고, 명령 하나하나가 환경을 바꾸기 때문이다. 다음 결정은 늘 그 바뀐 환경 위에서 내려진다.
여기서 진짜 골치 아픈 건 그 변화를 되돌리기 어렵다는 점이다. 국을 끓이다 소금을 너무 넣으면 국을 통째로 버려야 한다. 에이전트가 엉뚱한 패키지를 설치하거나 잘못된 코드를 한 번 실행하면, 그 명령이 환경을 망가뜨려 이후 모든 진행을 가로막는다. 모델이 더 나은 수를 알고 있었더라도, 이미 나쁜 명령이 나가버린 뒤라면 소용없다.
추론할 때 연산을 더 쓰는 방식(테스트타임 연산)으로 이 문제를 손보려는 시도는 전에도 있었다. 샘플을 더 뽑고, 끝난 결과를 검증해 고친 뒤 다시 돌리는 식이다. 대부분 "실행한 뒤"에 바로잡는 접근이었다. 이 논문은 질문을 한 칸 앞으로 당긴다. 실행하기 전에 거를 수 있다면, 성공률이 실제로 오르는 조건은 무엇인가.
답은 조금 뜻밖이었다. 후보를 많이 뽑는 것보다, 그중 좋은 것을 가려내는 "검증기"의 질이 성패를 갈랐다. 병목은 생성이 아니라 선별이었다.
이 논문이 제안하는 방법의 이름은 Mid-Harness다. 설계가 이름에 그대로 담겨 있다. 명령을 만들어 내는 모델(생성기)과, 명령을 실제로 돌리는 실행 환경(하네스) "사이(mid)"에 한 겹을 끼운다는 뜻이다.
보통의 에이전트는 모델이 명령 하나를 내놓으면 곧장 실행한다. Mid-Harness는 그 자리에서 같은 대화 기록을 바탕으로 후보 명령을 여러 개 뽑는다. 그다음 검증기로 하나를 고르고, 고른 것만 하네스로 넘긴다. 나머지 후보는 버린다. 다음 스텝에서는 바뀐 기록으로 다시 여러 개를 뽑는다.
좋은 점은 손대는 데가 거의 없다는 것이다. 모델 가중치도, 서빙 구조도, 실행 환경도 그대로 둔다. 모델 호출을 감싸는 얇은 코드 한 겹에 "여러 개 뽑고 하나 반환"을 더하는 수준이다. 덕분에 후보 수, 검증 방식, 검증기 성능을 하나씩만 바꿔 가며 무엇이 효과를 내는지 깨끗하게 분리해 볼 수 있다.
검증기에는 함정이 하나 있다. 과제 설명과 지금까지의 관찰 기록, 그리고 후보 명령들은 받지만, 각 후보를 만들 때 모델이 속으로 한 추론은 받지 못한다. 즉 "이 명령이 이 환경에서 무엇을 할지"를 실행해 보지 않고 판단해야 한다. 이게 검증의 본질적 난점이다.
판단하는 방식은 세 가지다. 명령 두 개를 예로 들어 보자. ls -l은 지금 폴더에 어떤 파일이 있는지 자세히 보여주는 명령이고, pwd는 지금 내가 어느 폴더에 있는지 경로를 찍어 주는 명령이다. 작업이 막혔을 때 상황부터 파악할지(ls -l로 뭐가 있는지 보기), 위치만 확인하고 넘어갈지(pwd)는 그때그때 더 나은 쪽이 다르다. 이 둘 중 하나를 고르는 세 가지 방법은 이렇다.
pwd보다 ls -l이 낫다"처럼 차이에만 집중한다. 호출 수는 가장 많다.여기서 한 가지 직관이 중요하다. 모델에게도 여러 선택지를 한꺼번에 줄 세우거나 각자 절대 점수를 매기는 일보다, 둘만 놓고 어느 쪽이 나은지 고르는 상대평가가 훨씬 쉽고 정확한 과제다. 비교에 공통 기준이 생기기 때문이다. 대신 값을 치른다. 후보가 8개면 리스트와이즈는 1번, 포인트와이즈는 8번, 모든 쌍을 비교하는 페어와이즈는 28번 호출해야 한다.
생성기와 검증기가 같은 모델이면 이를 자가검증이라 부른다. 다른 모델을 검증기로 붙일 수도 있다. 뒤에서 보겠지만, 바로 이 선택이 결과를 크게 갈랐다.
실험은 기본 에이전트 모델을 터미널 과제 위에서 돌리며, 검증기만 바꿔 가며 비교한다. 성능은 두 지표로 본다. 과제마다 3번 실행해서, Pass@1은 그 3회의 평균 성공률(한 번에 얼마나 잘 푸나), Pass@3은 셋 중 하나라도 푼 과제의 비율(운이 좋으면 어디까지 가나)이다.
먼저 검증기만 매우 강한 외부 최신 모델(프런티어 모델)로 바꿔 봤다. 결과는 한쪽으로 분명히 기울었다. 아무 검증 없는 기본 에이전트가 Pass@1 50.00%였는데, 같은 생성기에 프런티어 검증기를 붙여 가장 단순한 리스트와이즈로 고르기만 해도 64.63%에서 68.03%까지 올랐다. 생성기는 이미 더 나은 명령을 만들어 내고 있었다는 뜻이다. 막힌 곳은 그걸 고르는 쪽이었다.
그렇다면 후보를 더 많이 뽑으면 되지 않을까. 아니었다. 생성기와 같은 모델로 검증하는 자가검증에서, 리스트와이즈 후보 수를 두 배로 늘려도 Pass@1은 49.32%에서 51.02%로 사실상 제자리였다. 약한 검증기로는 후보를 아무리 늘려도 좋은 것을 골라내지 못한다. 후보 수를 키우는 것은 약한 검증을 보상해 주지 않는다.
열쇠는 "몇 개를 뽑느냐"가 아니라 "어떻게 고르느냐"에 있었다. 같은 자가검증에서 비교 방식만 페어와이즈로 바꾸자 Pass@1 54.76%, Pass@3 71.43%에 이르렀다. 검증기 모델은 그대로 두고, 고르는 방식을 "둘씩 맞붙이기"로 바꾼 것만으로 올라간 것이다.
한 단계 더 얹을 수 있다. 프런티어 검증기의 판단을 자체 모델에 베껴 넣는 증류다. 강한 모델이 만든 11만 7천 건의 페어와이즈 응답을, 모델 전체를 다시 학습하지 않고 작은 추가 가중치만 얹는 경량 학습(LoRA)으로 집어넣었다. 이 가중치는 검증기에만 켜고 생성기에는 켜지 않는다. 그 결과 페어와이즈 Pass@1이 57.14%, Pass@3이 75.51%로 올랐다. 생성기는 손대지 않고 검증기만 똑똑하게 만들어 성공률을 끌어올린 셈이다.
증류가 실제로 무엇을 옮겨 왔는지는 저장해 둔 궤적을 다시 돌려 보는 오프라인 분석으로 드러난다. 점수 오차(MAE)가 2.59에서 1.05로 줄었다. 교사 모델과 같은 쪽을 고른 비율도 올랐는데, 쌍 하나하나에서의 일치율은 59.01%에서 74.58%로, 그 비교들을 종합한 최종 선택의 일치율은 38.52%에서 57.79%로 올랐다. 강한 검증기의 "고르는 감각"이 작은 가중치 한 장에 옮겨 담긴 것이다.
좋은 소식 뒤에는 비용이 따른다. 페어와이즈는 호출이 많아 모델이 토큰을 뱉는 데 드는 연산이 크게 붙는다. 완화책은 추론 과정을 생략하고 A와 B 중 어느 쪽이 나은지 결론만 내는 "결정만" 검증이다. 기본 모델에서 이 방식은 추론판보다 성능을 유지하거나 올리면서 토큰 비용을 20.9%, 24.1%씩 낮췄다. 다만 더 작은 모델과 더 큰 모델에서는 결정만 방식이 추론판보다 성능이 떨어졌다. 검증에 긴 추론이 꼭 필요한 건 아니지만, 그 이점이 모델 규모를 탄다는 단서다.
이 방법은 기존 기법을 밀어내지 않고 그 위에 얹힌다. 완성된 실행을 여러 개 만들어 고르는 Best-of-N 방식의 기준선이 Pass@1 55.10%였는데, 그 세 궤적을 Mid-Harness로 생성하면 61.22%, 증류 검증기를 쓰면 66.33%까지 올랐다. 환경을 돌린 횟수는 똑같이 3번인데 11.23%p가 더 나온 것이다. 이전 실행을 요약해 다음을 안내하는 순차 개선과 합쳤을 때도 Pass@1이 60.20%로, Pass@3도 함께 올랐다. 저자들은 여기에 순차 개선 한 라운드를 더한 조합이 Best-of-N을 추정 비용 절반 이하로 넘어섰다고 보고한다.
한계도 분명하다. 증류를 거친 자가검증도 프런티어 검증기 수준에는 못 미쳤다. 남은 격차의 정체가 흥미롭다. 교사와 엇갈린 판단은 "그 명령이 환경에서 실제로 무엇을 할지"를 가리는 영역에 몰려 있었고, 명백한 검증 실패의 67.4%가 여기였다. 실행해 보지 않고 명령의 효과를 예측하는 일이 여전히 핵심 난제라는 뜻이다.
또 하나, 작업이 길어질수록 검증이 약해진다. 교사와의 일치율은 초반(턴 1-4)의 68.13%에서 후반(턴 17-32)의 54.07%로 떨어졌다. 이건 논문이 관찰한 사실이다. 여기서 "그러니 후반엔 사람이 더 봐야 한다"는 결론으로 바로 건너뛰지는 말자. 그건 관찰이 아니라 운영 판단의 영역이다.
마지막으로, 이 모든 선별은 생성기가 애초에 다양한 후보를 내놓는다는 전제 위에 선다. 생성기가 비슷비슷한 명령만 뱉으면 검증기가 아무리 좋아도 고를 게 없다. 그리고 과제 수가 적으면 3회 평균의 분산이 커지므로, 54.42%와 55.44% 같은 작은 Pass@1 차이는 조심해서 읽어야 한다.
구체적인 장면 하나로 옮겨 보자. 한 고객사가 외부 회계 프로그램 연동을 요청했다. 온틀의 AI PM은 이 프로젝트 전용 데이터베이스에 수집용 테이블을 만들고, 접속에 필요한 자격 정보를 저장하는 명령을 내려야 한다. 모델이 떠올린 첫 명령이 곧장 실행되는 구조라면, 잘못된 테이블 설계 한 번이 이후 수집 파이프라인 전체를 꼬이게 만든다. 터미널 에이전트의 "되돌릴 수 없는 명령" 문제가, 여기서는 "고객 데이터와 연동을 건드리는 액션"으로 번역된다.
이때 먼저 분명히 해 둘 게 있다. 이 논문이 끌어올린 것은 과제 성공률이지, 고객 액션의 안전성이 아니다. 둘은 목표가 다르다. 그런데 수단은 같은 구조를 공유한다. "실행하기 전에 후보를 가려내는 관문"이다. 성공률을 높인 페어와이즈 비교와 증류 기법을, 치명적 실수를 막는 안전 필터를 더 싸고 똑똑하게 만드는 데 그대로 끌어 쓸 수 있다는 것. 이게 이 논문의 실무적 쓸모다.
그래서 이 장면에서 할 일은 순서가 있다. 먼저 되돌릴 수 없는 액션부터 추린다. 테이블 설계 변경, 자격 정보 쓰기, 금액이 오가는 처리처럼 실패 비용이 큰 것들이다. 그중 가장 비싼 테이블 설계 변경에만 페어와이즈 관문을 건다. 실행 직전 후보 둘을 맞붙여 "지금 이 수집 요구에 더 맞는 설계"를 고르게 하는 것이다. 모든 액션이 아니라 이 목록에만 선택적으로 켜서 비용을 억누른다.
"선택적이니 비용은 괜찮다"는 결론에는 조건이 붙는다. 되돌릴 수 없는 액션이 전체에서 드물고, 검증기가 쓸 만큼 정확할 때만 성립한다. 자체 모델의 자가검증이 약하면, 우선 프런티어 검증기를 붙여 성능의 상한부터 재 본다. 거기서 분명한 이득이 보이면, 그 판단을 증류로 자체 모델에 내재화한다. 외부 고성능 모델에 상시 기대지 않고도 검증 능력을 우리 모델로 옮겨 오는 길이 바로 이것이고, 이는 온틀이 쓰는 모델 라우팅 표준과도 맞물린다. 비용이 여전히 부담이면 추론을 생략한 결정만 방식을 함께 재되, 모델 규모에 따라 이득이 달라졌으니 실제로 쓰는 모델에서 직접 비교한 뒤 채택한다.
정리하면, 온틀에 더 급한 건 안전성 쪽이다. 이 논문은 그 안전 관문을 "어떻게 똑똑하게 만들지"에 대한 재료를 준다. 당장 전면 도입이 아니라, 가장 비싼 액션 하나에 관문을 걸어 상한을 재 보는 것 — 거기서부터 시작하면 된다.
아닙니다. 둘이 같으면 자가검증, 다르면 외부 검증기입니다. 논문에서 가장 큰 이득은 강한 외부 모델을 검증기로 붙였을 때 나왔습니다. 증류는 그 강한 검증기의 판단을 자체 모델로 옮겨 와, 운영에서는 다시 하나의 모델로 돌리면서도 비슷한 선별력을 얻으려는 절충입니다.
그렇지 않습니다. 증류에 쓴 11만여 건의 비교 데이터는 프런티어 검증기가 스스로 만든 판단(추론과 선호)입니다. 교사 모델이 라벨러 역할을 대신하므로 사람 주석이 필요 없고, 그만큼 모으기가 쉽습니다.
맞지만, 그러면 "실행 전에 거른다"는 전제가 무너집니다. 실행해 본 뒤 고르는 건 되돌릴 수 없는 명령에서는 이미 늦습니다. 이 방법의 핵심은 실행하지 않은 상태에서 판단하는 것이고, 바로 그 "실행 없이 효과 예측하기"가 가장 어려운 부분으로 남아 있습니다.
논문의 결과는 터미널 과제를 중심으로 검증됐습니다. 저자들은 이 범위 너머로의 확장을 앞으로의 과제로 꼽았습니다. 다만 "되돌릴 수 없는 행동을 실행 전에 골라낸다"는 뼈대 자체는 도구를 호출하는 다른 에이전트에도 그대로 옮겨 생각해 볼 수 있습니다.