2026년 6월 14일 일요일2026 년 6 월 14 일
- 서울로 올라가는 버스 안에서 Godot 4 데이터셋/RAG 파이프라인에 대한 의문을 다시 정리함
- 기존에는 Godot 공식 문서를 크롤링하고, GitHub 프로젝트를
md, jsonl 형태로 변환한 뒤 RAG 챗봇을 통해 Godot 3/4 여부를 판별하는 구조를 생각했음
- 하지만 실제로는 프로젝트 전체 문맥과 검색된 공식 문서 조각을 한 번에 모델 입력 컨텍스트에 담을 수 있을지 의문이 생김
- RAG 챗봇을 만들었을 때의 입력 컨텍스트 한계를 고민
- 하나의 GitHub 프로젝트에도 README, 디렉터리 구조, 여러
.gd 파일, 씬 파일, 리소스 경로가 포함됨
- 여기에 RAG로 검색된 공식 문서까지 붙으면 입력이 커지기 때문에, 단순히 문서를 많이 모으는 것보다 어떤 파일과 문서 조각을 선별할지 설계하는 것이 더 중요하다고 판단함
- 질문/정답 데이터셋의 형태에 대한 의문을 정리
- “맵을 만들어줘” 같은 요청은 단순히 답변 코드 하나로 끝나는 문제가 아닐 수 있음
- 실제로는 프로젝트 구조 파악, 사용할 에셋 확인, 기존 코드 스타일 분석, Godot 4 문법 검토, 수정 파일 결정 같은 여러 추론 단계를 거쳐야 함
- 따라서 instruction 데이터셋에 최종 코드만 넣는 것이 충분한지, 탐색과 판단 과정까지 데이터로 남겨야 하는지 고민하게 됨
- 청크 단위 처리 중 Python 가중치가 다시 강해질 가능성을 고민
- “Godot 4로 맵을 만들어줘”라고 요청해도, 모델이 프로젝트와 문서를 청크 단위로 읽는 과정에서 Python 중심의 사전 학습 가중치가 다시 튀어나올 수 있다고 생각함
- Godot 4 문맥을 프롬프트 앞단에서 강하게 주입하고, 데이터 전처리 단계에서 Godot 3 코드나 Python식 답변이 섞이지 않도록 더 강하게 필터링해야 할 필요를 느낌
- 오늘의 정리
- RAG나 크롤링 자체가 해결책은 아니며, 중요한 것은 모델이 실제 요청에서 어떤 문맥을 읽고 어떤 판단을 하게 만들지 설계하는 것
- 프로젝트 컨텍스트를 파일/역할/의존성 기준으로 나누고, instruction 데이터에는 최종 답변뿐 아니라 필요한 경우 탐색과 판단 흐름도 포함하는 방향을 검토하기로 함
- Godot 4 문맥이 추론 과정에서 희석되지 않도록 프롬프트, 태그, 필터링, 선호 데이터 기준을 더 강하게 설계할 필요가 있음
- 개발 회고: docs/retrospectives/2026-06-14.md