서론: low가 오히려 더 많이 생각했다
추론 설정에 low, medium, xhigh이 나란히 배치되어 있다면, low는 가볍게, xhigh는 신중하게 생각할 것이라고 생각합니다.
하지만 모델이 그 순서대로 작동하는 것은 아닙니다.
bytkim 씨의 Qwen3.8-27B-pi 학습 리포트에서는 조정 전 모델을 조사했을 때, low가 medium보다 더 많은 사고 토큰(thinking token)을 사용하는 장면이 있었습니다. 예비 평가 5개 평가 세트를 평균하면 약 1.5배입니다. 성공한 시도만으로도 약 1.3배에 달합니다.
단순히 실패해서 길어진 것 때문만은 아니었습니다.
이 리포트가 다루는 것은 Qwen3.8-27B를 Pi라는 코딩 Agent의 실행 환경에 맞춰 조정(fine-tuning)한 사례입니다. Qwen 공식 팀의 학습 보고서가 아니라, bytkim 씨가 공개한 리포트로 읽어주세요.
SFT(Supervised Fine-Tuning) 이후에 RL(Reinforcement Learning)을 수행하는 구성 자체는 드문 것은 아닙니다. 다만, 그 과정에서 어떤 것을 학습 데이터로 삼고, 무엇을 성공으로 판정하며, 어떤 행동 방식을 어느 정도 변화시키려고 했는지가 구체적입니다.
금융이나 법률 지식을 추가하는 튜닝과는 조금 다른 이야기입니다. 직접 가진 도구와 실행 환경을 사용하여 어떻게 업무를 진행할지 학습시키는 것입니다. 업무 Agent를 만드는 입장에서 참고할 부분이 많다고 느꼈습니다.
1. 분야 특화와 실행 환경 적응
Agent harness는 모델에게 도구나 실행 환경을 제공하고, 호출과 결과 전달을 관리하는 메커니즘입니다. 모델 자체만을 의미하는 것이 아니라, 그 주변의 실행 측면을 가리킵니다.
리포트에서 사용된 Pi는 read, write, edit, bash를 사용하여 리포지토리를 읽고, 편집하며, 실행 결과에 따라 다음 행동을 변경합니다.
여기서 학습시키고자 하는 것은 특정 분야의 질문에 자세히 답하는 능력만이 아닙니다. 기존 코드를 확인하고, 편집하고, 도구를 실행한 후, 결과를 보고 수정하는 작업 흐름입니다.
지식 특화와 작업 적응은 양립할 수 있습니다. 다만, 업무가 끝나지 않는 원인이 도구 사용법이나 확인 절차에 있다면, 지식을 추가하는 것만으로는 대처하기 어렵습니다. 이 사례는 바로 그 부분을 학습 대상으로 삼고 있습니다.
또 다른 목표는 effort의 순서를 정돈하는 것이었습니다. low → medium → xhigh로 설정을 높인다면, 벤치마크 평균 사고량과 성공률도 그 순서대로 떨어지지 않는 상태를 목표로 합니다.
'low로 설정했는데 medium보다 더 많이 생각한다'면, 설정 자체를 고를 의미가 희미해집니다.
2. SFT에서 배우는 것은 마지막 답변뿐만이 아니다
SFT에 사용된 것은 Pi 상에서의 완전한 작업 세션입니다. 리포지토리 조사나 수정, 셸(shell)에서의 다단계 작업을 포함하며, off, low, medium, xhigh로 수집되었습니다.
최종적으로 작동한 코드뿐만 아니라, 그 과정까지의 대화와 도구 조작도 학습 대상이 됩니다.
다만, 기록 전체를 넣은 것은 아닙니다. 채택되려면, 태스크 검증기에 합격하는 것, 대화나 도구 호출 구조가 올바른 것, 수집 시의 채택 조건에 맞는 것이 필요했습니다. 짧기만 해서는 채택되지 않습니다.
여기서 중요한 것은 도구 관측 결과(observation result)를 다루는 것입니다. 테스트 실패 로그 등은 다음 행동을 결정하기 위한 문맥에 포함시키지만, 관측 결과 자체는 assistant의 loss에서 제외합니다.
로그를 무시하는 것이 아닙니다. 로그를 읽고 다음에 무엇을 할지는 학습시키되, 환경이 반환한 로그를 모델 자신의 출력으로 재현하도록 학습시키는 것은 분리하는 것입니다.
SFT는 BF16의 LoRA로, 선형층(linear layer)을 대상으로 데이터 전체를 대략 한 바퀴 돌리는 구성이었습니다. 하지만 성공 이력을 그대로 따라 하는 것만으로는 effort 문제가 남아 있었습니다.
채택된 세션에서도 low의 1턴당 사고 토큰이 medium보다 많은 경향이 있었고, SFT도 이를 물려받았기 때문입니다. 성공한 작업 이력에도 고쳐야 할 습관이 섞여 있습니다. 여기서 RL 설계로 이어집니다.
3. 일률적으로 짧게 만들지 않고, 같은 태스크의 성공 사례와 비교하기
'너무 많이 생각한다면, 사고 토큰이 많을수록 감점하면 되지 않을까?'라고 생각할 수 있습니다.
하지만 그렇게 하면 어려운 문제를 풀기 위한 사고 과정까지 줄어들 수도 있습니다. 그래서 사용하고 있는 것이 같은 태스크의 상위 effort에 의한 성공 사례입니다.
비교 대상 만들기
각 수집 라운드에서는 동일한 policy로, 각 태스크를 low, medium, xhigh 각각 여러 번 실행합니다. 1회의 시도는 도구와의 상호작용을 포함하는 완전한 Pi 세션입니다.
SFT와 달리, RL에는 올바르게 채점된 실패 시도도 포함됩니다. 다만, 참조 길이(reference length)를 만드는 데 사용하는 것은 성공 시도만입니다.
상위 effort의 성공 시도가 필요한 횟수만큼 모이면, 그 사고 토큰 수의 중앙값을 참조 길이로 사용합니다. 극단적으로 짧은 성공이 기준을 너무 엄격하게 만들지 않도록, 참조 길이에는 하한선도 설정했습니다.
| 평가하는 시도 | 참고하는 성공 사례 |
|---|
| low | medium과 xhigh 중 성립된 참조 길이가 더 짧은 쪽 |
| ... | |
| 상위 effort의 성공 횟수가 부족하여 참조 길이를 만들 수 없는 경우에는, 그 시도 역시 정확성만으로 평가합니다. 어려운 태스크를 근거 없는 짧은 기준으로 벌주지 않기 위한 조건입니다. | |
기준은 고정된 값이나 과거의 최고 기록이 아니라, 같은 수집 라운드의 현재 policy로부터 만듭니다. 그 라운드의 참조 길이와 보상을 사용하여 policy를 한 번 업데이트합니다.
성공을 우선한 보상
보상은 다음과 같습니다.
| 시도 결과 | 보상 |
|---|
| 실패 | 짧더라도 0 |
| ... | |
| 예를 들어, 설명용으로 medium의 참조 길이가 4,000, xhigh가 6,000 토큰이 되었다고 가정합니다. low가 비교할 상대는 4,000입니다. | |
성공한 low가 3,000 토큰이든 4,000 토큰이든 보상은 1입니다. 기준보다 짧아도 추가 보너스는 없습니다. 5,000이면 감점되지만, 성공한 보상은 실패보다 높은 상태를 유지합니다. 실패라면, 짧게 끝나도 0입니다.
이 예시의 수치는 메커니즘을 설명하기 위한 가상의 값입니다. 실제 보상 설계의 핵심은 정확하게 완료하는 것을 짧음보다 우선시하는 데 있습니다.
보상이 계산하는 것과 학습 대상은 같지 않다
참조 길이가 적용되는 성공 시도에 대해, 원본 보고서는 다음과 같은 형태로 보상을 정의했습니다.
초과율 = max(0, 사고 토큰 수 / 참조 길이 - 1)
보상 = 0.5 + 0.5 × φ(초과율)
φ는 초과율이 0일 때 1이 되고, 초과함에 따라 부드럽게 작아지는 함수입니다. 참조 길이보다 짧아도 초과율은 0이므로 보상은 증가하지 않습니다.
세는 것은 전체 턴을 합산한 사고 토큰이지만, 얻어진 Advantage는 답변이나 도구 호출을 포함한 학습 대상의 생성된 토큰 전체에 적용합니다. 개별적인 사고 단계만 잘라서 채점하는 설계가 아닙니다. 도구와 환경의 관측 결과는 loss에서 제외합니다.
참고로, xhigh에 길이 페널티를 주지 않는 것과 xhigh용 가중치를 동결하는 것은 별개의 문제입니다. 같은 policy를 업데이트하는 과정에서, xhigh에는 정확성만을 기준으로 한 보상을 주고 있습니다.
4. 작은 감점을 큰 학습 신호로 만들지 않기
보상을 완만하게 했다고 해서, 업데이트도 완만해진다고 할 수는 없습니다.
이 보고서에서는 GRPO를 사용하면서 Advantage를 표준편차로 나누지 않았습니다. 같은 태스크・같은 effort의 시도 그룹 내에서 평균을 빼는 것만 했습니다.
Advantage = 자신의 보상 − 같은 태스크・같은 effort의 평균 보상
예를 들어, 보상이 1.00과 0.98인 성공 시도만으로 이루어진 그룹을 생각해 봅시다. 이는 설명용 예시입니다.
평균은 0.99이므로, 평균을 뺀 값은 +0.01과 −0.01입니다. 여기에 표준편차 0.01로 나누면, 개념적으로는 +1과 −1까지 확대됩니다.
정확성은 같고, 효율에 약간의 차이가 있을 뿐인데, 그 작은 차이가 큰 업데이트 신호가 되어버립니다. 이 설계에서는 그 확대를 피하고 있습니다.
반대로, 모든 시도가 성공한 그룹이라도, 참조 길이를 초과한 시도와 사이에 보상 차이가 있다면 학습 신호를 만들 수 있습니다. 성공/실패만으로 이루어진 보상이라면, 모두가 성공할 경우 차이는 없어집니다. 어떤 이유로든, 그룹 내의 보상이 전부 같으면 Advantage는 0입니다.
표준편차에 의한 정규화가 항상 나쁘다는 이야기는 아닙니다. 무엇을 보상으로 삼을지뿐만 아니라, 그 차이를 어느 정도 강도로 학습시킬지까지 함께 설계하고 있다는 점이 참고가 됩니다.
5. QA-flow로 태스크와 채점기까지 수정하기
지금까지의 이야기는, 검증기가 성공을 올바르게 판정할 수 있다는 것이 전제입니다.
하지만, 검증기에도 오류가 있습니다. 작동하지 않는 결과물이 합격하거나, 올바른 해결책이 불명확한 요구사항 때문에 불합격하는 경우도 있습니다. 그 판정을 보상에 사용하면 학습에도 영향을 줍니다.
보고서에서는 기존의 태스크를 감사(audit)・수리(repair)・필요에 따른 난이도 상향/채택 판정까지 거치는 QA-flow를 정비하고 있습니다. Appendix C에 각 단계에 대한 설명이 있습니다.
오답이 통과하는 경우와, 정답이 탈락하는 경우
감사에서는 양쪽을 모두 조사합니다. 초기 상태 그대로라면 불합격이 될지, 실행 가능한 올바른 참조 해답이라면 합격할지도 확인합니다.
원본 보고서는 수리의 예시로, 파일의 존재 여부만 확인하던 검사를, 결과물을 실행하여 동작까지 확인할 수 있는 것으로 변경하는 것을 제시했습니다.
수정하는 Agent와 감사(Audit)하는 Agent는 별개입니다. 수정된 사실 자체를 합격의 근거로 삼지 않습니다. 수정 라운드에는 상한선을 두고, 미해결 지적 사항도 기록으로 남깁니다.
난이도를 산출물의 연결성으로 만듭니다
일부 태스크에서는 요구사항과 검증 범위를 의존 그래프(dependency graph)로 만들어 난이도를 높입니다.
계획, 실행 로그, 최종 보고서, 실제 최종 상태가 일치하지 않으면 통과할 수 있도록 합니다. 단순히 별개의 파일을 만드는 것만으로는 부족하며, 일련의 작업으로서 정합성을 갖추게 해야 하는 것입니다.
난이도 설정이 끝났다고 해서 그대로 학습에 적용하지는 않습니다. 독립적인 감사(audit), 실행 가능한 참조 해답(reference solution), 다른 solver를 통한 시도 등을 포함하는 증거들을 확인합니다.
다만, QA-flow를 적용할 수 있었던 것은 학습 풀(learning pool)의 일부입니다. 모든 태스크에 대한 감사가 완료되었다고 해석하는 것은 지나친 해석일 수 있습니다.
6. loss가 낮아져도 Agent가 좋아졌다고 할 수는 없다
SFT(Supervised Fine-Tuning) 체크포인트 선택 역시 이 보고서에서 참고할 만한 부분이 있습니다.
16개 태스크를 3단계의 노력(effort)으로 실행하는 소규모 평가로 후보군을 추려낸 후, Terminal-Bench 2.1의 89개 태스크를 medium 난이도로 실행하여 비교하고 있습니다.
| 체크포인트 | 후보 선정 시 성공 수 (89태스크) |
|---|
| C0: Base | 58 |
| ... | |
| 선택된 것은 초기 단계의 C5였습니다. validation loss는 C5의 0.2817에서 후반에는 0.2749까지 하락했습니다. 그럼에도 불구하고, 최소 loss를 기록한 후보가 작업을 가장 많이 완료한 것은 아니었습니다. | |
'5단계에서 멈추면 된다'고 일반화할 이야기는 아닙니다. 체크포인트는 실제로 Agent로 구동하여 선택하는 평가 방식이 중요합니다. 이 후보 선정 실행과, 후술할 최종 비교 실행은 별개입니다.
loss뿐만 아니라 기울기(gradient)도 비교한다
학습 구현에 대해서도 확인하고 있습니다. 보고서 진단에서는 Liger RMSNorm을 사용한 구성에서 loss가 가깝더라도, 참조 구현과의 기울기 상대 L2 차이가 82.05%를 기록했습니다.
이는 고정된 3,944 토큰의 입력과 FP32 출력 투영(projection)을 사용하는 특정 실행 환경에서의 비교입니다. optimizer로 가중치를 업데이트한 실험도 아니며, 모든 Liger 사용 환경에 적용되는 수치도 아닙니다.
보상이나 데이터를 고안한다는 전제 하에, 학습 측에서 의도한 기울기를 계산하고 있는지 여부도 확인합니다. loss 표시만으로는 알 수 없는 차이가 있다는 구체적인 예시입니다.
7. 개선된 결과와, 거기서 말할 수 없는 것들
최종 Pi 모델의 평가에는 FP8 가중치를 사용했습니다. Terminal-Bench 2.1에서는 다음과 같은 결과가 보고되었습니다.
| 모델과 노력(effort) | 성공 수 | 평균 출력 토큰/태스크 |
|---|
| Base・xhigh | 67/89 | 63,462 |
| Pi・medium | 67/89 | 37,423 |
같은 성공 수임에도 불구하고, Pi의 medium은 약 41% 적은 출력 토큰을 기록했습니다. 다만, 출력 토큰에는 사고(thought) 외의 내용도 포함됩니다. 보상이 직접 계산한 사고 토큰과 혼동하지 않도록 합니다.
또한, 이 결과를 '모든 노력 단계에서 빠르고 저렴해졌다'고 해석할 수도 없습니다. 같은 벤치마크의 low 난이도에서는 Pi의 출력 토큰은 줄어든 반면, 평균 실행 시간은 Base의 8.5분에서 Pi의 15.1분으로 늘어나고 있습니다.
SciCode의 medium 역시, 성공한 소문제는 늘었지만, 출력 토큰은 증가했습니다. 어떤 지표를 개선이라고 부르는지까지 확인하지 않으면, 듣기 좋은 요약이 될 수 있습니다.
실험에는 짧은 RL(Reinforcement Learning), 단일 학습 시드(seed), 보상이나 하이퍼파라미터의 ablation(제거) 등이 없다는 제약도 있습니다. Base와 Pi의 차이는 SFT・RL・후보 선정까지 종합적으로 포함되므로, 보상 설계만 개선 원인이라고 분리할 수 있는 결과는 아닙니다.
학습 중 수집된 데이터에서는 low 난이도가 medium보다 더 많이 사고하는 경향도 남아 있었습니다. 최종적으로 노력 단계의 순서가 정돈되었다는 보고는 평가 세트에서의 평균에 관한 것입니다. 개별 태스크에서 상위 노력이 반드시 성공한다는 보장은 아닙니다.
8. 업무 Agent로 무엇을 학습 자산으로 남길 것인가
여기서는 이 사례를 업무 Agent에 적용할 때 정리하는 내용입니다.
Acrosstudio로서 참고하고 싶은 것은, 업무 지식을 추가하는 것에 더하여 당사의 Tool・실행 환경・검증 절차에 맞는 행동을 학습시키는 방향입니다.
그러기 위해서는 최종 답변만 모으는 것만으로는 부족합니다.
| 남기고 싶은 것 | 나중에 확인하고 싶은 것 |
|---|
| 완벽한 실행 기록 | 무엇을 읽고, 무엇을 변경했으며, 실패로부터 어떻게 수정했는지 |
| ... | |
| 이것은 사내 로그를 그대로 학습에 흘려보낸다는 의미가 아닙니다. 기밀 정보나 개인 정보, 이용 권한을 확인하고, 학습용 기록과 평가용 태스크도 분리하여 관리하고 싶습니다. | |
도입 순서로는, 먼저 현재의 Agent를 재현 가능한 태스크로 측정하고, 실패가 지식 부족인지, 툴 조작 문제인지, 채점의 미비점인지를 알아봅니다. 그 위에 성공 기록을 정리하고 SFT(Supervised Fine-Tuning)의 필요성을 판단합니다. 노력(effort)별 비효율이 남아 있다면, RL(Reinforcement Learning)을 검토하는 것이 좋을 것 같습니다.
학습 전에 고치면 좋을 툴이나 검증기도 있을 것입니다. harness를 변경했더라도, 같은 평가를 통해 행동을 확인하고 싶습니다.
맺음말: 기록과 완료를 판정하는 메커니즘도 함께 남기기
이 리포트는 특정 모델을 사용하면 업무 Agent가 완성된다는 이야기가 아닙니다.
성공한 작업을 어떻게 선택하고, 불필요한 사고를 어떤 성공 사례와 비교하며, 보상 차이를 어느 정도의 크기로 학습시킬지. 게다가, 성공을 결정하는 태스크와 검증기까지 손질하고 있습니다. 그 조합이 참고가 될 것입니다.
업무 Agent의 실행 기록을 쌓는다면, 무엇을 가지고 올바르게 완료했다고 할지도 함께 남기고 싶습니다.
나중에 모델을 학습시킬지 여부와 관계없이, 그것만 있으면 다음 Agent가 정말 업무를 잘 처리하게 되었는지 비교할 수 있습니다.
참고 문헌・소스
수치와 학습 설계는 bytkim 씨의 공개 리포트를 중심으로 정리했습니다. 모델을 학습/추론하여 재현한 기사는 아닙니다. 설명용 수치 예시와, 업무 도입에 대한 제안은 원 리포트의 실험 결과와 분리하여 기재하고 있습니다. 그림은 필자의 개념도입니다.
- bytkim, Qwen3.8-27B-pi: Effort-Ordered Reasoning for Agentic Coding — SFT、報酬とAdvantage、QA-flow、評価、制約。특히 Appendix A・C도 참조.
- Qwen3.8-27B-pi 모델 카드 — Pi용으로 조정된 배포 모델 설명.
- Learning Generalizable Behaviors for Terminal Agents (RIVER) — 원 리포트가 QA-flow의 배경으로 참고하는 관련 연구.
- Environment Evolution for Terminal Agents — 원 리포트가 환경의 난화에 대해 참고하는 관련 연구.
논의(Discussion)
