2026년 6월 17일 수요일2026 년 6 월 17 일
- Godot 4 코딩 모델 방향을 단순 Q&A 학습이 아니라 SWE-agent trajectory 학습 관점으로 다시 정리함
- 작은 instruction Q&A만으로는 “맵을 만들어줘” 같은 프로젝트 단위 요청을 처리하기 어렵다고 판단
- 실제 코딩 에이전트는 레포지토리 탐색, 관련 파일 선택, 코드 수정, 테스트/검증, patch 생성까지 이어지는 trajectory가 필요하다고 정리
- 관련 키워드로
Long-context repository-level software engineering agent training, SWE-agent trajectory training을 기록
- 참고 사례로 SWE-agent trajectories, SWE-smith, SWE-Gym, CoderForge-Preview, ACC, RepoBench/CrossCodeEval/RepoCoder, aiXcoder CoLT, godot-dodo, wallstoneai dataset을 정리
- Godot LLM 개발 전체 로드맵을 이미지와 문서로 기록
- 전체 흐름을
데이터 -> 1차 RAG 챗봇 -> SFT -> DPO -> SWE Agent 단계로 정리
- Stage 0 준비 단계부터 Stage 6 지속적 개선까지 나누어, 데이터 수집/구조화, 1차 RAG 챗봇, 데이터 라벨링, 모델 학습, SWE Agent 개발, 운영/재학습 흐름을 기록
- 핵심은 1차 RAG 챗봇을 먼저 Godot 문서 전문가로 만들고, 그 챗봇을 이용해 GitHub 데이터를 라벨링/가공한 뒤 모델 학습과 SWE Agent로 확장하는 것
- Godot RAG 판별기 기반 데이터 생성 구조를 메모로 추가
- LLM에게 최종 라벨 결정을 맡기지 않고, 라벨과 검증은 시스템 파이프라인이 결정하는 구조로 정리
- LLM은 수정 코드, 설명, SFT 질문/답변, DPO 나쁜 답변, patch 초안 같은 생성 보조 역할만 맡는 방향으로 설계
- API 매핑 DB, 공식문서 벡터 DB, 라벨 프로토타입 DB를 기반으로 심볼 추출, 검색, 라벨 스코어링, JSONL 조립/검증까지 이어지는 흐름을 기록
- 생성 대상 데이터셋을 version classification, api mapping, migration fix, instruction SFT, DPO preference, repo explorer, patch generation, metadata verification 8가지로 정리
- Godot RAG 판별기에서 Qwen 3.6 코딩모델로 이어지는 MVP 개발 흐름을 별도 메모로 정리
godot_docs_full.zip 원본 문서 준비부터 chunk_docs.py 기반 1차 청킹, Godot 전용 후처리, 로컬 검색 인프라 구축까지의 흐름을 기록- Vector DB, Keyword Index, Reranker, API Mapping DB, Label Prototype DB를 조합해 라벨을 시스템이 결정하는 구조로 정리
- GitHub 데이터를 구조화한 뒤 RAG 판별기를 실행하고, LLM은 수정 코드/설명/QA 샘플 같은 생성 보조 역할만 맡도록 역할을 분리
- 1차 Qwen 3.6 SFT에서는 Godot 4 우선 사고, GDScript 기본 출력, Godot 3 API 거부를 목표로 하고, 이후 DPO와 SWE 확장으로 이어지는 흐름을 기록
- GitHub 잔디 반영 문제를 해결하기 위해 Git author/email 설정을 정리
- 전역 Git 설정을
yyeongjin <appsky1888@gmail.com>으로 변경
- 기존
main 히스토리의 author/committer 이메일이 로컬 호스트 이메일, naver 이메일, GitHub noreply 등으로 섞여 있던 문제를 확인
main 히스토리의 author/committer를 yyeongjin <appsky1888@gmail.com>으로 통일하고 원격에 반영- 재작성 전 상태는 로컬 백업 브랜치
backup/before-author-email-rewrite-2026-06-17에 보관
- 기록 문서