Jeff-Code: 작은 AI가 코딩 에이전트의 사고 시간과 다음 행동을 조절하기

배경과 문제

Qwen3.8-27B 같은 추론 모델은 행동 하나를 고르기 전에 사고 토큰을 먼저 생성한다. 코딩 에이전트의 턴 중 상당수는 파일 하나를 열거나 폴더 목록을 보는 일처럼 깊은 사고가 필요 없는 일이다. 그런데 Pi는 세션 전체에서 사고를 켜거나 끄기만 할 수 있어서, 쉬운 턴에도 항상 최대 사고를 켜면 시간이 오래 걸린다. 반대로 모든 턴에서 사고를 끄면 통과율이 크게 떨어진다. 이 문제를 해결하려면 턴마다 사고 필요성을 판단하는 빠른 결정 모델이 필요하다.

Jeff-Code는 이 판단을 0.8B 결정 모델 Jeff에게 맡긴다. Jeff는 문장을 생성하지 않고, 상황 설명과 선택지 목록을 받아 선택지마다 보정된 확률을 한 번의 순전파로 돌려준다. 저자들은 이를 사람의 빠른 직관적 판단에 빗대어 System 1 모델이라고 부른다. Jeff는 Qwen3.5-0.8B를 미세조정한 베이스 위에 두 개의 LoRA 어댑터를 올려 사용한다. 하나는 정보 수집 단계를 대신 실행할지 정하고, 다른 하나는 Qwen의 사고 수준을 정한다.

기존 접근의 한계

Pi의 확장 프레임워크로는 빠른 결정 모델을 에이전트 루프 깊숙이 넣을 수 없어서 Jeff-Code는 Pi를 포크했다. 또한 Pi는 사고를 세션 전체에서만 켜거나 끌 수 있어서, 턴마다 사고 수준을 바꾸려면 에이전트 루프를 수정해야 한다. 저자들의 테스트에서 Qwen의 low와 medium 사고 수준은 최대 수준과 거의 같은 길이로 생각해서 시간을 줄여 주지 못했다. 따라서 실제로는 '끄거나 최대로 켜거나' 두 가지 선택만 유효했다.

사고를 모든 턴에서 끄면 시간은 가장 많이 줄지만 통과율이 분명하게 떨어진다. 평가에서 사고를 항상 끈 설정은 기준선 대비 통과율이 7.6%p 낮았고, Terminal-Bench 2.0에서는 13.5%p까지 떨어졌다. 이는 단순히 사고를 끄는 것만으로는 속도와 품질을 동시에 잡을 수 없음을 보여준다. Jeff의 역할은 사고가 필요한 턴을 골라내어, 사고를 끈 턴의 속도 이점을 누리면서도 통과율 하락을 막는 것이다.

연구방법을 단계별로

Jeff-Code는 매 턴 전에 Jeff에게 두 가지 질문을 보낸다. 첫째, 프로그램이 지금까지 알려진 정보로 다음 단계 메뉴를 만들고, code 어댑터를 쓰는 Jeff가 도구와 인자를 고른다. 가장 높은 선택지의 확률이 임계값 0.40 이상일 때만 그 단계를 실행하고, 아니면 Qwen에게 턴을 넘긴다. Jeff가 맡을 수 있는 단계는 파일 읽기, 폴더 목록 보기, 코드 검색, 설치된 도구 확인, 테스트나 빌드 실행 등이다. 파일 작성과 수정은 항상 Qwen이 맡는다. Jeff는 한 번에 최대 8단계까지 연속으로 실행할 수 있고, Qwen은 그 결과를 이미 받아 둔 상태로 턴을 시작한다.

둘째, code-router 어댑터가 Qwen의 사고 수준 네 가지(off, low, medium, xhigh)에 각각 확률을 매긴다. 공개 설정에서는 xhigh의 확률이 0.6 이상일 때만 사고를 켜고, 나머지 턴은 사고 없이 보낸다. 평가에 쓴 실행에서는 low와 medium이 한 번도 쓰이지 않았다. 제작자는 어댑터별 보정 데이터를 이용해 확률을 조정했다. 보정이 잘된 확률은 비슷한 확신을 보인 판단들을 모았을 때 실제 정답 비율과 맞는다는 뜻이다. 새로운 업무에서도 같은 수준으로 맞는지는 별도 검증이 필요하며, 임계값은 속도와 신중함을 조절하는 설정이다.

두 어댑터 모두 Jeff가 'Qwen이라면 다음에 무엇을 할지'를 예측하도록 학습했다. code 어댑터의 라벨은 기록된 Qwen 세션에서 Qwen이 실제로 다음에 실행한 정보 수집 단계다. 데이터는 공개 데이터셋 약 14,400개 세션, 공개 Terminal-Bench 세션, 저자들이 직접 돌린 세션의 세 단계로 모았고, 이 순서대로 커리큘럼 학습을 했다. code-router 어댑터의 라벨은 더 복잡하다. 먼저 Qwen이 최대 사고(xhigh)로 진행한 턴을 기록하고, 같은 요청을 사고 off, low, medium 순서로 다시 보내 행동이 충분히 좋았던 첫 수준을 라벨로 삼는다. '충분히 좋다'는 우선 코드 규칙으로 판정하고, 불가능하면 호스팅 모델 Qwen3.8-Max가 판정한다. 이렇게 만든 학습 라벨의 비율은 off 약 27%, low 약 8%, medium 약 5%, xhigh 약 60%다.

평가 기준선은 같은 Jeff-Code 빌드에서 Jeff 기능을 모두 끈 Qwen3.8-27B다. 기준선은 모든 턴에서 최대 사고를 켜고, 사고 토큰 상한을 두지 않았다. 각 과제는 기준선과 Jeff-Code 설정으로 같은 시각에 같은 Qwen 서버에서 나란히 실행했고, 결과는 과제 단위로 짝지어 비교했다. 평가에는 학습에 쓰지 않은 과제만 썼고, 저자들은 과제 단위로 분리했다고 밝힌다. SWE-bench Verified는 전체 500개를 평가했고, 다른 벤치마크는 학습 과제와 평가 과제를 분리했다.

결과와 숫자의 의미

6개 벤치마크의 대응 블록은 1,242개이며, 같은 과제의 반복 시도도 포함된다. 전체 완료 세션의 통과율은 기준선 62.8%, Jeff-Code 62.4%다. 반면 -0.2%p(95% 구간 -2.6~+2.1)는 양쪽 모두 완료한 대응 블록에서 계산한 차이여서 앞의 두 비율을 단순히 뺀 값과 분모가 다르다. 통과율 차이의 95% 구간이 0을 포함하므로 뚜렷한 차이를 확인하지 못했다. 이는 같은 통과율의 증명이 아니며, 제작자는 별도로 5%p 이상 하락하지 않는다는 목표를 사용했다. 과제당 시간은 Jeff-Code 시간을 기준선 시간으로 나눈 비율의 기하평균이 0.68배(95% 구간 0.64~0.72)였다. 이는 과제당 평균 32% 단축, 역수로 47% 더 빠르다는 뜻이다. 중앙값은 0.70배였다.

전체 과제 시간의 합계는 0.86배(95% 구간 0.80~0.93)로, 과제당 평균보다 덜 줄었다. 약 5%의 과제에서 Jeff-Code가 기준선보다 30분 넘게 더 오래 돌았는데, 기준선이 몇 분 만에 포기한 과제를 Jeff-Code는 시간 한도까지 계속 시도했기 때문이다. 그 과제들에서 Jeff-Code는 26개, 기준선은 24개를 풀었다. 벤치마크별로 보면 SWE-bench Verified 0.63배, SWE-rebench 0.66배, Terminal-Bench Pro 0.64배, Harbor Index 0.71배로 속도 향상이 뚜렷했다. 그러나 Terminal-Bench 2.0은 0.96배(95% 구간 0.78~1.16)로 속도 향상이 확인되지 않았고, 통과율 차이도 -4.6%p(95% 구간 -12.1~+3.7)로 5%p 넘는 하락을 배제할 수 없었다. SkillsBench도 0.91배로 뚜렷하지 않았다.

사고를 모든 턴에서 끈 설정은 시간이 0.55배로 가장 많이 줄었지만 통과율이 7.6%p 떨어졌다. Jeff의 사고 임계값을 0.7로 높인 설정은 시간 0.64배, 통과율 -4.5%p였다. 다만 항상 사고 끄기와 임계값 0.7 설정에는 SWE-bench Verified가 빠져 있어 공개 설정과 합산 과제 구성이 다르다. 공개 설정(임계값 0.6)은 시간 0.68배, 통과율 -0.2%p로, 속도와 품질의 균형을 잡았다. 평가 보고서의 동작 통계에서 공개 설정은 1,251개 세션, 82,435개 Qwen 턴을 기록했고, 그중 74.1%가 사고 없이 돌았다. Jeff가 Qwen 대신 실행한 단계는 2,600번이었다. 이 동작 통계는 전체 완료 세션 범위이며, 성능을 계산한 대응 블록 수와 구별해야 한다. 따라서 시간 절감은 주로 code-router가 사고를 끈 턴에서 나왔을 가능성이 크다. 이는 보고서의 횟수에 근거한 편집자의 해석이다.

구체적인 예시

Jeff-Code의 턴 구조를 이해하기 위해 가상의 예를 들어보자. 과제가 'tests/test_parser.py의 단위 테스트가 실패한다. 원인을 찾아 고쳐라'라고 하자. Qwen이 턴을 시작하기 전에 프로그램이 다음 단계 메뉴를 만들고 Jeff는 code 어댑터로 그중 하나를 고른다. 메뉴에는 과제 설명이나 앞선 출력에 이미 등장한 파일, 폴더, 프로그램, 패키지만 들어간다. Jeff가 'Read' 도구와 'src/parser.py' 인자를 높은 확률로 고르면, Jeff가 그 파일을 읽고 결과를 Qwen에게 넘긴다. Qwen은 파일 내용을 이미 받은 상태에서 턴을 시작하므로, 파일을 읽기 위해 한 턴을 쓰지 않아도 된다.

이어서 code-router 어댑터가 Qwen의 사고 수준을 정한다. 만약 최근 단계가 'pytest 실패, AttributeError 발생'이라면, Jeff는 xhigh 확률이 0.6 이상이라고 판단하여 Qwen에게 최대 사고를 켜도록 할 수 있다. 반대로 '폴더 목록 보기' 같은 단순한 턴이라면 사고를 끈다. 물론 이 예시는 이해를 돕기 위한 것이며, 실제 평가 로그의 특정 과제를 재현한 것은 아니다.

한계와 오해하기 쉬운 점

첫째, '47% 빠름'과 '32% 단축'은 같은 숫자다. 0.68배의 역수가 약 1.47이므로, 과제당 시간이 32% 줄었다는 뜻이다. 그러나 전체 작업량 기준으로 보면 시간 합계가 0.86배이므로 14% 줄었다. 여러 과제를 한꺼번에 돌릴 때 기대할 수 있는 절감은 과제당 평균보다 작을 수 있다. 둘째, 기준선과의 차이에는 Jeff의 결정뿐 아니라 안전장치도 포함된다. 기준선에는 루프 가드와 사고 토큰 상한이 없고, Jeff-Code 설정에는 있다. 공개 설정에서 사고 토큰 상한으로 잘린 응답은 458번, 루프 가드가 다시 물은 경우는 3,139번이었다. 따라서 0.68배라는 수치는 Jeff의 두 결정과 안전장치를 함께 넣은 결과다.

셋째, 벤치마크마다 결과가 다르다. Terminal-Bench 2.0에서는 속도 향상이 확인되지 않았고, 통과율 하락을 배제할 수 없다. SkillsBench와 Harbor Index는 과제가 41~42개뿐이라 신뢰구간이 넓다. 넷째, 평가 보고서는 INTERIM 상태이며 로그에는 27세션 진행 중, README에는 약 10개의 긴 재실행 진행 중으로 적혀 있다. 두 문서의 보고 시점과 단위가 달라 최종 결과로 확정할 수 없다. 모델 카드는 수치를 관리자의 자체 보고로 표시하며, 다른 사람이 다시 실행한 결과는 아직 없다. 평가 세트도 아직 카드에 첨부되지 않았다. 다섯째, 훈련 데이터 자체는 공개되지 않았다. code/code-router는 Qwen의 다음 행동·필요 사고 수준을 모방하는 LoRA이며, 별도 0.8B 서버와 Qwen 27B 서버가 필요하다. Jeff는 파일 작성/수정을 직접 맡지 않는다.

여섯째, 두 어댑터는 Jeff-Code와 Qwen3.8-27B 조합에서만 측정되었고, 다른 코딩 모델이나 다른 에이전트에 그대로 쓸 수 있는지는 확인되지 않았다. 어댑터는 학습한 베이스 버전에 묶여 있어서 Jeff v1.3 베이스에서만 동작한다. 마지막으로, Jeff 설정의 일부 세션은 Jeff 서버 용량 문제를 고친 뒤 몇 시간 늦게 다시 돌렸다. 같은 Qwen 서버였지만 서버 부하는 달랐을 수 있다. 합산에 들어간 재실행 블록은 63개다.

실제로 어떻게 활용할까

Jeff-Code를 실행하려면 두 서버가 필요하다. 하나는 OpenAI 호환 API로 Qwen3.8-27B를 서빙하는 서버(예: vLLM)이고, 다른 하나는 두 어댑터를 올린 Jeff 서버다. Jeff 서버는 Jeff 저장소의 안내대로 설치하고, 베이스 모델과 두 어댑터를 다운로드한 뒤 실행한다. Jeff-Code 저장소를 빌드하고, Qwen을 OpenAI 호환 모델로 추가한 뒤, 평가에 쓴 설정으로 환경 변수를 지정하고 실행한다. jeff 모드에서는 모든 설정이 필수이며, 하나라도 빠지거나 값이 잘못되면 오류를 내고 멈춘다.

컨테이너 밖에서 실행한다면 JEFF_FIRST_RUN_APPROVAL 값을 먼저 정해야 한다. 평가는 벤치마크 컨테이너 안에서 all로 돌았다. all은 Jeff가 Qwen이 작성한 스크립트를 실행하고 apt나 pip으로 패키지를 설치하는 것을 허용한다. seen은 그 과제에서 이미 한 번 실행된 스크립트의 재실행과, Qwen이 이미 쓴 설치 도구만 허용한다. never는 둘 다 막는다. llama.cpp로 Jeff를 돌릴 수도 있다. code 어댑터는 개발용 991행에서 Q4_K_M과 전체 정밀도의 실행·위임 결정이 97.9% 일치했지만, code-router 어댑터는 Q4_K_M에서 사고 켜기와 끄기 판단의 약 6%가 바뀌었다. 그래서 저자들은 code-router를 Q8_0 베이스에서만 서빙하라고 안내한다.