idea_world_labDEV JOURNAL
2026년 6월 17일 수요일

2026-06-17 SWE-agent trajectory 키워드 메모

핵심 결론

Godot 4 코딩 모델을 만들 때 작은 Q&A 데이터셋만으로는 부족할 가능성이 높다. 지금 고민 중인 문제는 단순한 instruction dataset 문제가 아니라, 레포지토리 단위의 긴 컨텍스트를 읽고 파일 탐색, 판단, 수정, 검증, patch 생성까지 이어지는 software engineering agent 학습 문제에 가깝다.

정리하면 현재 방향의 이름은 다음에 가깝다.

Long-context repository-level software engineering agent training

또는 더 짧게는 다음 키워드로 볼 수 있다.

SWE-agent trajectory training

Godot 쪽으로 치환하면 목표는 단순한 Godot Q&A 모델이 아니라 다음에 가깝다.

Godot용 SWE-agent trajectory dataset 만들기

왜 작은 Q&A만으로 부족한가

기존 고민은 다음과 같았다.

"맵 만들어줘"
-> 프로젝트 읽기
-> 관련 파일 찾기
-> 에셋 확인
-> Godot 4 문법/API 판단
-> 코드 수정
-> 실행/테스트/검증
-> patch 생성

이 흐름은 질문 -> 답변 하나로 끝나지 않는다. 실제 코딩 에이전트는 여러 파일을 탐색하고, 중간 판단을 하고, 수정한 뒤 검증까지 수행해야 한다. 따라서 최종 답변 코드만 남기는 데이터셋보다, 에이전트가 문제를 풀면서 남긴 trajectory와 patch를 학습 데이터로 만드는 방향이 더 적합할 수 있다.

찾아볼 우선순위

1. SWE-smith
2. nebius/SWE-agent-trajectories
3. CoderForge-Preview
4. ACC
5. aiXcoder CoLT
6. RepoBench / CrossCodeEval / RepoCoder
7. godot-dodo / wallstoneai dataset

사례 메모

SWE-agent trajectories

SWE-agent-trajectories는 GitHub issue를 보고 레포 파일을 탐색하고, 필요한 파일을 열고, 수정하고, 테스트하고, 최종 patch를 만드는 에이전트 행동 기록 데이터셋이다.

핵심 키워드:

  • agent trajectory
  • GitHub issue solving
  • file exploration
  • patch generation
  • software engineering agent training

Godot 쪽 대응:

"맵 만들어줘"
-> Godot 프로젝트 구조 탐색
-> 관련 scene/script/resource 확인
-> 수정
-> 실행 또는 screenshot 검증
-> patch 생성

SWE-smith

SWE-smith는 GitHub 레포를 software engineering agent 학습용 환경으로 바꾸는 툴킷이다. 설명상 임의의 GitHub repository를 SWE-gym 형태로 바꾸고, file localization, program repair, SWE-bench 스타일 task를 만들 수 있다.

Godot 쪽 대응:

Godot repo
-> 맵/씬/스크립트 수정 task 생성
-> Godot agent trajectory 생성
-> Godot patch 모델 학습

SWE-Gym

SWE-Gym은 codebase, executable runtime environment, unit tests, natural language task를 묶어 SWE agent와 verifier를 학습하는 방향의 사례다.

Godot 쪽 대응:

Godot project
+ 실행 가능한 Godot version
+ scene/test/screenshot 검증
+ 자연어 task
+ 수정 trajectory
+ patch

중요한 점은 코드만 학습하거나 자연어 질문만 학습하는 것이 아니라, 실행 환경과 검증까지 같이 묶는다는 것이다.

CoderForge-Preview

CoderForge-Preview는 agent trajectory를 기반으로 long-context SFT 데이터를 만드는 사례다. 최대 128K 토큰 long-context trajectory를 사용했다는 점이 중요하다.

이 사례는 다음 의문에 대한 근거가 된다.

레포 단위 작업에는 큰 컨텍스트가 필요하지 않을까?

실제 코딩 에이전트 학습 쪽에서도 긴 컨텍스트 trajectory를 사용하는 흐름이 있다.

ACC

ACC: Compiling Agent Trajectories for Long-Context Training은 agent trajectory를 long-context QA 형태로 컴파일하는 방향이다. 여러 turn에 걸친 tool call, observation, 파일 내용, 검색 결과를 긴 문맥 학습 데이터로 바꾸는 것이 핵심이다.

이 사례는 다음 의문과 연결된다.

최종 답변 코드만 학습하면 충분한가?
아니면 파일 탐색과 판단 과정까지 학습 데이터로 남겨야 하는가?

RepoBench / CrossCodeEval / RepoCoder

이 계열은 레포지토리 단위 코드 이해와 완성 문제를 다룬다.

핵심 문제의식:

  • single-file benchmark만으로는 실제 프로젝트 복잡도를 담기 어렵다.
  • 유용한 정보가 여러 파일에 흩어져 있다.
  • cross-file context가 필요한 code completion을 평가해야 한다.
  • retrieval-generation pipeline이 필요하다.

Godot 쪽 대응:

파일 하나만 보고는 맵 수정이 어렵다.
scene, script, resource, project 설정, 에셋 경로를 함께 봐야 한다.

aiXcoder CoLT

aiXcoder-7B-v2와 CoLT는 긴 컨텍스트를 줘도 모델이 유용한 정보를 무시할 수 있다는 문제를 다룬다.

중요한 의문:

컨텍스트를 크게 넣으면 되는가?
-> 아니다.
크게 넣어도 모델이 실제로 읽고 활용하는지 학습/검증해야 한다.

Godot 쪽에서는 Godot 4 관련 정보가 긴 컨텍스트 안에 있어도 모델이 Python식 패턴이나 Godot 3 API로 답할 수 있다. 따라서 long-context 활용 자체를 학습시키거나, Godot 4 문맥을 더 강하게 고정하는 데이터 설계가 필요할 수 있다.

godot-dodo / wallstoneai dataset

Godot 쪽 직접 사례로는 godot-dodo와 wallstoneai/godot-gdscript-dataset이 있다.

이 둘은 GDScript raw code 또는 repo text 데이터셋에 가깝다. Godot 특화 학습의 시작점으로는 의미가 있지만, 최종 목표인 agent trajectory dataset과는 거리가 있다.

현재 목표와 비교하면 다음처럼 정리할 수 있다.

기존 Godot 데이터셋:
GDScript raw code / repo text

필요한 Godot 데이터셋:
Godot repo context
+ user task
+ file exploration
+ patch
+ verification
+ long-context trajectory

현재 고민과 연결되는 키워드

6월 14일 회고에서 정리한 의문과 연결하면 다음과 같다.

프로젝트 전체 문맥과 검색된 공식 문서 조각을
한 번에 모델 입력 컨텍스트에 담을 수 있을까?
-> long-context repo-level coding problem
탐색과 판단 과정까지 데이터로 남겨야 하는가?
-> trajectory training problem
긴 컨텍스트를 줘도 모델이 Godot 4 문맥을 제대로 사용할까?
-> long-context utilization / CoLT problem

참고 링크