코딩 에이전트를 학습시키는 데 필요한 것은 “정답 코드”만이 아닙니다.
실제 소프트웨어 엔지니어링 작업에서는 모델이 저장소를 탐색하고, 도구를 호출하고, 실패한 실행 결과를 해석하고, 다시 패치를 수정합니다. NVIDIA의 Open-SWE-Traces는 이 과정을 학습 데이터로 다루기 위해 설계된 소프트웨어 엔지니어링용 에이전트형 SFT 데이터셋입니다.1
Open-SWE-Traces는 코드 데이터셋이 아니라 에이전트 trajectory 데이터셋이다
Open-SWE-Traces의 핵심 단위는 최종 코드 패치가 아니라 trajectory입니다.
trajectory는 에이전트가 문제를 해결하는 동안 남긴 다중 턴 대화 기록이며, system, user, assistant, tool 역할을 포함합니다.1
데이터셋은 총 207,489개의 에이전트 trajectory로 구성되어 있습니다.1
이 trajectory들은 20,000개 실제 PR에서 출발했으며, Python, Go, TypeScript, JavaScript, Rust, Java, PHP, C, C++ 등 9개 프로그래밍 언어를 다룹니다.2
따라서 이 데이터셋을 볼 때는 “어떤 코드가 생성됐는가”보다 “에이전트가 어떤 절차로 문제를 해결했는가”를 먼저 봐야 합니다. 저장소를 어떻게 탐색했는지, 어떤 도구를 사용했는지, 최종 패치에 도달하기까지 몇 번의 대화와 검증이 있었는지가 SFT 품질을 좌우합니다.
학습 전에 먼저 정규화하고 측정해야 한다
Open-SWE-Traces는 Hugging Face에서 직접 스트리밍해 사용할 수 있습니다.1
하지만 데이터를 그대로 학습에 넣기보다, 먼저 trajectory를 정규화하고 분석 가능한 형태로 바꾸는 과정이 필요합니다.
특히 각 샘플에서 다음 정보를 분리해 보는 것이 중요합니다.
다중 턴 대화의 길이
tool 호출 횟수와 종류
최종 코드 변경인
model_patch패치 크기
언어 분포
해결 여부를 나타내는
resolved수정 파일 수와 수정 라인 수 같은 메타데이터1
이런 지표를 DataFrame으로 만들면 데이터셋의 품질을 빠르게 판단할 수 있습니다.
예를 들어 trajectory가 지나치게 길면 토큰 예산을 초과할 수 있고, 패치가 없거나 너무 크면 학습 신호가 불안정할 수 있습니다. tool 호출이 거의 없다면 에이전트형 문제 해결을 충분히 반영하지 못할 가능성도 있습니다.
즉, trajectory length, tool usage, patch size, language distribution, resolution outcomes는 단순한 통계가 아닙니다. “많은 데이터”를 “학습에 쓸 수 있는 데이터”로 바꾸기 위한 품질 게이트입니다.
최종 패치만 보면 중요한 신호를 놓친다
Open-SWE-Traces에는 model_patch처럼 최종 코드 변경을 직접 분석할 수 있는 정보가 포함됩니다.1
패치를 파싱하면 어떤 파일이 바뀌었는지, 변경 규모가 어느 정도인지, 특정 언어에 패치가 집중되어 있는지 확인할 수 있습니다.
하지만 최종 패치만 보는 것은 충분하지 않습니다.
같은 패치라도 에이전트가 한 번에 도달했는지, 여러 번의 tool 호출과 실패를 거쳐 도달했는지는 학습 관점에서 전혀 다른 의미를 갖습니다.
그래서 Open-SWE-Traces를 다룰 때는 패치 분석과 trajectory 분석을 함께 해야 합니다.
패치는 “무엇이 바뀌었는가”를 보여주고, trajectory는 “어떻게 바뀌게 되었는가”를 보여줍니다. 코딩 에이전트 SFT에서는 이 둘을 함께 봐야 실제 문제 해결 행동을 학습 데이터로 만들 수 있습니다.
thinking trace와 non-thinking trace를 구분해야 한다
Open-SWE-Traces의 trajectory는 OpenHands와 SWE-agent 프레임워크를 사용해 수집됐습니다.1
또한 trajectory 합성에는 Minimax-M2.5와 Qwen3.5-122B-A10B가 사용됐습니다.1
논문에 따르면 Minimax-M2.5는 명시적 thinking 과정이 포함된 trajectory를 생성하는 데 사용됐고, Qwen3.5-122B는 non-thinking trace를 생성하는 데 사용됐습니다.2
이 구분은 모델의 응답 스타일과 직접 연결됩니다.
복잡한 버그 수정이나 저장소 탐색에는 계획, 검증, 재시도가 필요할 수 있습니다. 반면 모든 작업에 긴 추론 과정이 필요한 것은 아닙니다. SFT 데이터를 구성할 때 thinking trace와 non-thinking trace의 비율을 따로 확인하면, 모델이 과도하게 장황해지거나 반대로 필요한 추론을 생략하는 문제를 줄이는 데 도움이 됩니다.
Open-SWE-Traces에서 배워야 할 것은 “경로”다
Open-SWE-Traces의 가치는 규모보다 구조에 있습니다.
207,489개의 trajectory와 9개 언어 지원도 중요하지만, 더 중요한 점은 이 데이터가 소프트웨어 엔지니어링 작업의 절차를 담고 있다는 것입니다.
따라서 이 데이터셋을 활용할 때의 실용적인 기준은 명확합니다.
다중 턴 대화를 정규화한다.
최종
model_patch를 파싱한다.trajectory 길이와 토큰 예산을 확인한다.
tool 사용량을 측정한다.
패치 크기와 언어 분포를 본다.
resolved기준으로 해결 결과를 나눠 본다.thinking trace와 non-thinking trace를 구분한다.
결국 코딩 에이전트는 정답 파일 하나를 외워서 좋아지는 것이 아닙니다.
문제를 읽고, 저장소를 탐색하고, 도구를 사용하고, 실패를 반영해 패치를 고치는 과정을 배워야 합니다. Open-SWE-Traces를 분석할 때도 최종 코드보다 그 코드에 도달한 경로를 중심에 두어야 합니다.
참고
1nvidia/Open-SWE-Traces · Datasets at Hugging Face
2Open-SWE-Traces: Advancing Dual-Mode Multilingual Distillation for Software Engineering Agents
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.