2026-06-14 회고 | idea_world

서울로 올라가는 버스에서 든 생각

오늘은 서울로 올라가는 버스 안에서 지난번에 설계했던 Godot 4 데이터셋/RAG 파이프라인을 다시 생각해봤다. 6월 12일에는 공식 문서를 크롤링하고, GitHub에서 Godot 프로젝트를 수집한 뒤, RAG 챗봇을 앞단에 두어 Godot 3/4 여부를 판별하고 instruction 데이터를 만드는 구조를 생각했다.

그런데 오늘 다시 생각해보니, 이 구조가 실제로 잘 동작하려면 아직 풀어야 할 의문이 꽤 많았다. 특히 “문서를 모았다”와 “모델이 그 문서를 잘 이용한다” 사이에는 생각보다 큰 간격이 있다는 점이 계속 걸렸다.

첫 번째 의문: RAG 챗봇이 전체 컨텍스트를 감당할 수 있을까

기존에는 Godot 공식 문서를 크롤링해서 RAG 챗봇을 만들면, 수집한 GitHub 프로젝트를 분류하거나 검증하는 데 사용할 수 있을 것이라고 생각했다. 하지만 GitHub 프로젝트를 스크래핑해서 md, jsonl 형태로 변환한 뒤 그 내용을 한 번에 챗봇에 던지는 시나리오를 떠올리니 의문이 생겼다.

모델이 그 입력 컨텍스트를 전부 받아올 수 있을까?

하나의 Godot 프로젝트만 해도 README, 디렉터리 구조, 여러 .gd 파일, 씬 파일, 리소스 경로가 들어간다. 여기에 RAG로 검색된 공식 문서 조각까지 붙으면 입력은 금방 커질 수 있다. 단순히 크롤링한 문서가 존재한다고 해서, 모델이 매 요청마다 프로젝트 전체와 관련 문서를 모두 안정적으로 읽을 수 있는 것은 아니다.

결국 RAG 챗봇을 만든다는 것은 문서를 통째로 넣는다는 뜻이 아니라, 어떤 질문에서 어떤 문서 조각을 가져올지 결정하는 검색/선별 구조를 만든다는 뜻에 가깝다. 이 부분이 허술하면 모델은 중요한 파일을 놓치거나, 불필요한 문서를 읽느라 정작 필요한 프로젝트 맥락을 잃을 수 있다.

두 번째 의문: 질문 하나에 답변 코드 하나만 있으면 충분할까

두 번째로 든 의문은 instruction 데이터셋의 형태였다. 예를 들어 “맵을 만들어줘”라는 질문을 생각해보면, 이 질문에 대한 답은 단순한 코드 한 덩어리가 아닐 수 있다.

LLM이 실제로 답을 만들려면 여러 단계를 거쳐야 한다. 프로젝트 구조를 보고, 어떤 씬과 스크립트가 있는지 파악하고, 사용할 수 있는 에셋을 확인하고, 기존 코드 스타일을 읽고, Godot 4 문법에 맞는지 검토하고, 마지막으로 수정할 파일과 코드를 결정해야 한다.

즉 “맵을 만들어줘”라는 질문은 겉으로는 하나의 요청이지만, 내부적으로는 여러 추론 레이어를 거쳐야 하는 작업이다. 그런데 학습 데이터에 최종 답변 코드만 남기면, 모델이 그 중간 판단 과정을 배울 수 있을지 의문이 생겼다.

정답 데이터에는 단순히 완성 코드만 있는 것이 아니라, 어떤 파일을 읽어야 하는지, 어떤 정보를 근거로 판단했는지, 왜 특정 API를 선택했는지 같은 과정이 어느 정도 포함되어야 할 수도 있다. 특히 코딩 에이전트처럼 동작하게 만들고 싶다면 “질문 -> 답변”보다 “질문 -> 탐색 -> 판단 -> 수정 -> 검증” 흐름을 데이터로 남기는 쪽이 더 맞을 수 있다.

세 번째 의문: 청크 단위 처리 중 Python 가중치가 다시 튀어나오지 않을까

세 번째 의문은 언어 가중치 문제였다. “Godot 4로 맵을 만들어줘”라고 프롬프트를 줘도, 모델이 기존 프로젝트나 문서를 청크 단위로 나눠 읽는 과정에서 Python 코드나 Python식 문제 해결 패턴의 가중치가 더 강하게 작동할 수 있지 않을까 하는 생각이 들었다.

기존 범용 코딩 모델은 Python을 훨씬 많이 학습했을 가능성이 높다. 그렇다면 Godot이라는 단어를 앞에 붙이는 것만으로는 부족할 수 있다. 특히 검색된 청크 안에 Godot 4 문맥이 충분히 강하지 않거나, 중간 추론 과정에서 일반적인 코딩 패턴을 떠올리게 되면 Python식 답변으로 흐를 가능성이 남아 있다.

그래서 단순히 “Godot 4로 작성해줘”라고 말하는 수준이 아니라, 프롬프트와 데이터 전처리 단계에서 Godot 4 문맥을 훨씬 강하게 고정해야 할 것 같다는 생각이 들었다. 예를 들어 입력 데이터에 Godot 4 전용 태그를 붙이거나, Godot 3/타 언어 코드가 섞인 데이터를 더 강하게 필터링하거나, 답변 생성 전 단계에서 “이 작업은 Godot 4 GDScript 기준”이라는 제약을 반복적으로 주입하는 방식이 필요할 수 있다.

오늘의 정리

오늘 생각한 핵심은 RAG나 크롤링 자체가 해결책은 아니라는 점이다. 문서를 많이 모으는 것보다 더 중요한 것은, 모델이 실제 요청에서 어떤 문맥을 읽고 어떤 판단을 해야 하는지 설계하는 일이다.

지금까지의 구조는 다음 단계로 더 쪼개야 할 것 같다.

프로젝트 전체를 한 번에 넣는 방식이 아니라, 파일/역할/의존성 기준으로 검색 가능한 구조를 만들어야 한다.
instruction 데이터는 최종 코드만이 아니라 탐색과 판단 과정까지 포함할 필요가 있는지 검토해야 한다.
Godot 4 문맥이 추론 중간에 희석되지 않도록 프롬프트, 태그, 필터링, 선호 데이터 기준을 더 강하게 설계해야 한다.

결국 “Godot 4 코딩 모델”을 만들려면 Godot 4 코드만 모으는 것으로는 부족하다. 모델이 어떤 순서로 프로젝트를 읽고, 어떤 기준으로 Godot 4라고 판단하고, 어떤 답변을 좋은 답변으로 선택해야 하는지까지 데이터에 반영해야 한다.

회고

오늘은 실제 코드를 많이 작성한 날은 아니지만, 이전 설계의 빈틈을 다시 본 날이었다. 버스에서 멍하니 생각하다 보니 오히려 책상 앞에서 놓쳤던 문제가 보였다. RAG 챗봇을 만든다는 말은 쉬운데, 실제로는 검색 단위, 컨텍스트 크기, 질문/답변 데이터 구조, 언어 가중치 제어가 모두 연결되어 있었다.

아직 답은 없다. 하지만 의문이 생긴 것은 좋은 신호라고 생각한다. 지금 단계에서 의문을 기록해두면, 나중에 파이프라인을 구현할 때 무엇을 검증해야 하는지 기준이 된다.

다음에는 이 의문을 바탕으로 프로젝트 컨텍스트를 어떤 단위로 쪼갤지, instruction 데이터에 추론 과정을 어느 정도까지 포함할지, Godot 4 문맥을 강하게 유지하는 전처리 규칙을 어떻게 만들지 구체화해봐야겠다.