2026년 6월 12일 금요일 2026 년 6 월 12 일
오랜만에 개발 회고를 다시 작성하기로 함
그동안 너무 완벽한 기록만 남기고 싶다는 생각 때문에 오히려 기록을 미루게 되었음
지난 약 10일 동안 진행했던 시도와 고민을 의미 있게 남기기 위해, Godot 특화 코딩 모델을 만들기 위한 조사와 아키텍처 설계 과정을 정리함
RunPod 사용료를 줄이기 위해 로컬 PC에 Qwen 계열 모델을 배치하는 실험을 진행
RTX 3060 환경에서 9B 모델을 WSL로 구동해보려 했음
하지만 네트워크 연결 속도와 응답 지연 문제가 심했고, 실제 답변을 생성하기 전 사고 단계에서만 5분 이상 소요되어 로컬 구동 실험은 중단함
Godot 특화 모델 학습을 위해 먼저 데이터셋 수집 방식을 조사
Hugging Face의 wallstoneai/godot-gdscript-dataset
Gemini를 통해 해당 데이터셋이 어떤 방식으로 만들어졌는지 분석
핵심은 GitHub 레포지토리 단위로 README.md , .gd 파일, 프로젝트 구조를 하나의 텍스트로 병합하고, project.godot 설정 파일과 GDScript 문법 차이를 이용해 Godot 3/4 버전을 분류하는 방식이었음
특히 config_version, config/features, onready var, @onready, KinematicBody, CharacterBody3D 같은 버전별 단서를 활용하면 JSON 기반 의존성 파일이 없는 비주류 언어도 버전 필터링이 가능하다는 인사이트를 얻음
파인튜닝 흐름을 이해하기 위해 OPL이라는 고전 프로그래밍 언어를 대상으로 한 파인튜닝 영상을 참고
SSAFY 코치님께 특정 버전의 비주류 언어 데이터를 효과적으로 수집하는 방법을 질문
현재 참고한 Godot 데이터셋은 assistant 학습용 Q&A 데이터셋이라기보다 raw 코드 데이터셋에 가깝다는 답변을 받음
챗봇 형태의 제품을 만들려면 raw 데이터를 그대로 넣는 것보다, LLM을 이용해 질문/답변 쌍을 생성하고 instruction 데이터셋으로 가공해야 한다는 방향을 잡음
이 과정을 거치지 않으면 “맵을 설계해줘” 같은 요청에 대해 기존 모델이 많이 학습한 Python 중심 답변을 생성할 가능성이 높다고 판단함
instruction 데이터셋 후보로 ise-uiuc/Magicoder-Evol-Instruct-110K
대부분 Python 중심으로 작성되어 있어 Godot 4 전용 학습 데이터로 그대로 사용하기에는 적합하지 않다고 판단
“Godot을 명시하지 않아도 Godot 답변을 하도록 만들 수 있을까?”라는 의문을 가졌지만, 기존 모델의 Python 가중치가 크기 때문에 질문에 Godot이라는 맥락을 명확히 주는 것이 정답 가능성을 높이는 방향이라고 정리함
학교 선배님께 RAG와 프롬프팅 방향에 대해 자문
전체 데이터를 모델에 모두 주입하기보다, 마크다운 문서 기반의 벡터 검색 구조를 만들고 필요한 데이터를 찾게 하는 지도를 만드는 방식이 더 현실적일 수 있다는 조언을 받음
대규모 문서를 전부 재인덱싱하는 비용과 시간이 크기 때문에, 현재 단계에서는 학습보다 검색/프롬프팅 기반 구조가 더 적합할 수 있다고 판단함
Godot 특화 코딩 모델을 만들기 위한 초기 아키텍처를 설계
처음에는 데이터셋 수집 -> 질문/정답 데이터셋 생성 -> 모델 학습 정도의 단순한 구조를 생각함
하지만 Godot 3에서 4로 바뀐 내용을 충분히 알아야 정확한 필터링과 정답 데이터 생성이 가능하다는 문제가 있었음
잘못하면 Godot 3 코드, Python 코드, 구버전 API가 정답 데이터에 섞일 수 있다고 판단하여 아키텍처를 다시 고민함
Godot 3/4 버전 분류와 변환을 위해 공식 문서 기반 RAG 챗봇을 앞단에 배치하는 구조를 설계
Godot 공식 마이그레이션 문서와 Godot 4 문서를 크롤링해 RAG 챗봇을 만들고, 이 챗봇을 이용해 수집 데이터가 Godot 3인지 4인지 분류하는 방향을 떠올림
이후 Godot 4로 판별된 데이터만 instruction 데이터셋으로 가공하는 흐름을 구상함
ChatGPT를 통해 추가적으로 SFT/DPO 학습 방향에 대한 인사이트를 얻음
SFT에서는 Godot 3/4 분류, Godot 3 -> 4 변환, Godot 4 코드 생성, Godot 4 오류 수정, Godot 3 API 거부/교정 같은 태스크를 만들 수 있음
DPO/Preference에서는 나쁜 답변 = Godot 3 코드가 섞인 답변, 좋은 답변 = Godot 4 순수 코드 답변으로 선호 데이터를 구성할 수 있다는 방향을 정리함
unclecode/crawl4ai데이터 저장과 학습 파이프라인의 디스크 I/O 병목에 대해 학교 선배님께 추가 자문
실시간으로 파인튜닝을 돌리기보다, 데이터 확보와 전처리/후처리를 실시간에 가깝게 처리하고 학습은 배치성으로 수행하는 편이 낫다는 조언을 받음
데이터셋이 특정 수치 이상 쌓였을 때 강화학습 또는 파인튜닝을 실행하는 방식으로 메트릭 기반 배치 처리를 고려하기로 함
리인덱싱 비용은 구조적으로 완전히 제거하기 어렵기 때문에, 학습 실시간성보다 데이터 확보와 가공 파이프라인의 안정성이 더 중요하다고 정리함
현재 정리한 전체 방향
공식 문서를 크롤링해 Godot 4 기준 RAG 지식 베이스를 구축
GitHub Godot 프로젝트를 수집하고 레포지토리 단위로 README, 프로젝트 구조, GDScript 파일을 병합
project.godot 설정과 Godot 3/4 문법 차이를 이용해 1차 필터링RAG 챗봇을 이용해 Godot 3/4 여부, 구버전 API 사용 여부, Godot 4 적합성을 추가 판별
Godot 4로 정제된 데이터에서 instruction/response 데이터를 생성
SFT와 DPO/Preference 데이터로 Godot 4 코딩 모델을 학습
회고
지난 10일 동안 완성된 결과물만 남기려는 생각 때문에 오히려 과정을 기록하지 못했음
하지만 실패한 실험, 막혔던 지점, 중간에 바뀐 판단이야말로 다음 방향을 잡는 데 중요한 기록이라는 것을 느낌
앞으로는 완벽한 결과만 남기려 하기보다, 시도와 판단의 흐름을 꾸준히 남기면서 발전해나가기로 함
개발 회고: docs/retrospectives/2026-06-12.md