Qwen Godot 코드 JSONL 근거 매칭 테스트 체크리스트
작성일: 2026년 6월 28일
목적
Qwen으로 Godot 3 코드 chunk 50개를 생성하고, 어제 진행한 JSONL 근거 매칭 테스트와 같은 방식으로 예/아니오 판정이 제대로 갈리는지 확인한다.
이번 테스트는 모델이 Godot 지식을 알고 있는지 보는 것이 아니다. SOURCE_CODE와 JSONL을 같이 넣었을 때, JSONL 안에 실제 코드 chunk와 직접 맞는 문자열/API/패턴 근거가 있는지 판정하는 테스트다.
즉, 관련 있는 JSONL은 예로 나와야 하고, 관련 없는 JSONL은 아니오로 버려져야 한다.
테스트 방식
각 코드 chunk마다 최소 두 종류의 JSONL을 붙여 테스트한다. 다만 Godot 3과 Godot 4에서 문법이 똑같은 공통문법이 있을 수 있으므로, 모든 기능을 Godot 3 전용 문법처럼 다루지 않는다.
| JSONL 종류 | 기대 응답 | 의미 |
|---|---|---|
| 제대로 된 JSONL | 예 |
JSONL 안의 source_api, source_pattern, match_terms, required_when_seen_in_code, before_code 중 하나 이상이 코드 chunk와 직접 일치한다 |
| 잘못된 JSONL | 아니오 |
JSONL이 다른 API, 다른 노드, 다른 시스템, 넓은 단어만 공유하는 근거다 |
각 테스트는 다음 입력 묶음으로 본다.
JSONL
Qwen direct-evidence validator prompt
SOURCE_CODE chunk실제 검증 요청은 JSONL + 프롬프트 + chunk를 같이 던졌을 때 Qwen이 예 또는 아니오만 반환하는지 확인하는 방식이다.
공통문법인 경우에는 같은 코드 chunk 하나를 기준으로 테스트한다. 이때 정답 JSONL은 해당 코드/함수에 대한 설명이나 패턴을 담은 JSONL이고, 오답 JSONL은 전혀 다른 함수나 시스템에 대한 설명을 담은 JSONL이다. 기대 응답이 예인 케이스와 아니오인 케이스는 코드가 달라서 갈리는 것이 아니라, JSONL 안에 직접 근거가 있느냐 없느냐로 갈려야 한다.
반복 생성 루프
전체 목표는 50개 기능 전체 테스트다. 다만 오늘은 5개까지만 수기로 확인하고, 이후에는 누적 결과에서 예/아니오 응답 패턴을 먼저 분석하는 것으로 줄인다.
오늘 목표: 5개
전체 목표: 50/505개를 채운 뒤에는 새 항목 수를 무리해서 늘리지 않고, 공통문법/버전 차이/테이블별 false positive와 false negative 양상을 먼저 본다.
테스트는 아래 흐름을 반복하면서 데이터를 만든다.
1. Qwen에게 테스트할 Godot 기능 하나를 준다.
2. 해당 기능이 Godot 3/4 공통문법인지, Godot 3 특이 문법인지, Godot 4 특이 문법인지 먼저 표시한다.
3. 공통문법이면 같은 코드 chunk 하나를 만든다.
4. 공통문법이면 해당 코드/함수에 대한 정답 JSONL 하나와, 전혀 다른 함수에 대한 오답 JSONL 하나를 만든다.
5. 공통문법이 아니면 Godot 4 전용 JSONL과 Godot 3 전용 JSONL을 따로 만들어 테스트한다.
6. 모든 JSONL은 대상 테이블 컬럼에 맞게 만든다.
7. 검증 프롬프트에 JSONL + SOURCE_CODE chunk를 넣고 `예`/`아니오`를 확인한다.
8. 기대 응답과 실제 응답이 일치하는지 기록한다.핵심은 코드 생성 품질이 아니라, JSONL 근거 매칭 판정이 안정적인지 보는 것이다. 그래서 정답 JSONL은 예가 나와야 하고, 오답 JSONL은 아니오가 나와야 한다.
공통문법 주의사항
Godot 3과 Godot 4에서 같은 형태로 유지되는 문법은 버전 분류 테스트로 보면 안 된다. 예를 들어 _ready(), _process(delta), 기본 변수 할당, print()처럼 양쪽에서 모두 쓰이는 코드가 있을 수 있다.
이런 경우에는 다음처럼 본다.
| 코드 성격 | 테스트 방식 | 기대 |
|---|---|---|
| Godot 3/4 공통문법 | 같은 코드 chunk 하나로 해당 함수 JSONL과 전혀 다른 함수 JSONL을 테스트 | JSONL 직접근거 여부만으로 예/아니오가 갈려야 함 |
| Godot 3 특이 문법 | Godot 3 chunk를 기준으로 Godot 3 전용 JSONL과 Godot 4 전용 JSONL을 비교 테스트 | 실제 Godot 3 문자열/패턴이 JSONL에 있으면 예 |
| Godot 4 특이 문법 | Godot 4 chunk를 기준으로 Godot 4 전용 JSONL과 Godot 3 전용 JSONL을 비교 테스트 | 실제 Godot 4 문자열/패턴이 JSONL에 있으면 예 |
| 버전 차이와 무관한 기능 설명 | 코드가 어느 버전이든 JSONL content/code_blocks에 직접 근거가 있어야 함 | 넓은 의미 유사성만 있으면 아니오 |
따라서 기록표에는 공통문법 여부를 반드시 남긴다. 나중에 결과를 볼 때 공통문법인데 migration 근거로 억지 판정했는지, 버전 차이가 있는 문법인데 공통문법처럼 처리했는지 구분하기 위해서다.
기준 재정의 메모
4번과 5번을 테스트하면서 확정 판정을 내리기 어렵다는 점이 보였다. 특히 Godot 3 기준으로 JSONL을 만들었는지, Godot 4 기준으로 JSONL을 만들었는지에 따라 같은 코드 chunk의 응답이 달라졌고, 그 차이 자체가 패턴 분석 대상이 되었다.
따라서 지금은 좋다/나쁘다를 확정하지 않고, 다음처럼 원시 응답을 먼저 기록한다.
| 구분 | JSONL 생성 기준 | 검사 코드 | 현재 기대 흐름 |
|---|---|---|---|
| 공통문법 | Godot 3 기준 | 공통 코드 또는 같은 의미의 Godot 3/4 코드 | 예, 아니오, 예, 아니오, 예, 아니오 |
| 공통문법 | Godot 4 기준 | 공통 코드 또는 같은 의미의 Godot 3/4 코드 | 예, 아니오, 예, 아니오, 예, 아니오 |
| 버전 차이 | Godot 3 기준 | Godot 3 코드 | 예, 아니오, 예, 아니오, 예, 아니오 |
| 버전 차이 | Godot 3 기준 | Godot 4 코드 | 대부분 아니오. 단, api_mapping이나 prototype이 명시적으로 Godot 3 -> 4 변환 근거를 담고 있으면 일부 예가 나올 수 있으므로 원시 응답을 따로 본다 |
| 버전 차이 | Godot 4 기준 | Godot 3 코드 | 대부분 아니오. 단, JSONL이 source/target 양쪽 문자열을 동시에 담고 있으면 일부 예가 나올 수 있으므로 원시 응답을 따로 본다 |
| 버전 차이 | Godot 4 기준 | Godot 4 코드 | 예, 아니오, 예, 아니오, 예, 아니오 |
응답 순서는 기본적으로 docs_chunks 관련, docs_chunks 무관, api_mapping 관련, api_mapping 무관, label_prototypes 관련, label_prototypes 무관으로 본다.
4번도 기존에는 정리된 항목처럼 기록했지만, Godot 3 검사에서 아니오, 아니오, 예, 아니오, 예, 아니오처럼 나온 흐름이 있었기 때문에 확정 판정에서 제외한다. 이 문서는 지금부터 “몇 개가 맞았는가”보다 “어떤 기준에서 어떤 응답이 흔들리는가”를 보는 관찰 기록으로 둔다.
생성 요청 예시
아래는 첫 번째 기능인 _ready() 함수 초기화 및 뷰포트 크기 설정을 테스트할 때의 요청 예시다.
JSONL 형식과 각 JSONL별 용도는 별도 문서로 분리했다.
_ready() 함수 초기화 및 뷰포트 크기 설정에 맞는 godot3 청크 하나,
godot4 청크 하나 제공해줘.
단, 이 기능이 godot3과 godot4에서 공통문법인지 먼저 표시해줘.
공통문법이라면 같은 코드 하나를 기준으로 테스트해도 된다고 표시해줘.
그리고 docs_chunks JSONL 형식에 맞는 정답 JSONL과
정답이 아닌 JSONL을 제공해줘.이 예시는 docs_chunks 기준이다. api_mapping, label_prototypes도 같은 방식으로 각 JSONL 형식과 용도에 맞는 정답 JSONL과 오답 JSONL을 만들고, 같은 검증 프롬프트로 예/아니오를 확인한다.
검증 입력은 아래처럼 된다.
JSONL:
<정답 또는 오답 JSONL 한 줄>
PROMPT:
<direct-evidence validator prompt>
SOURCE_CODE:
<Godot 3 코드 chunk, Godot 4 코드 chunk, 또는 공통문법 코드 chunk>프롬프트는 아래처럼 SOURCE_CODE와 JSONL 사이의 직접적인 설명 근거 또는 변환 근거를 판정하는 느낌으로 보낸다.
너는 JSONL 근거 매칭 판정기다.
아래 SOURCE_CODE에 대해 아래 JSONL이 직접적인 설명 근거 또는 변환 근거를 포함하는지 판정하라.
판정 기준:
- JSONL 스키마 중 하나가 SOURCE_CODE 안의 실제 문자열 또는 API 호출과 직접 일치해야만 "예"다.
- 단순히 Godot, Godot3, Godot4, migration, 2D, physics 같은 넓은 단어가 같으면 관련 없음이다.
- JSONL이 다른 API, 다른 노드, 다른 시스템에 대한 내용이면 "아니오"다.
- 네가 알고 있는 Godot 지식은 사용하지 말고, JSONL에 적힌 문자열 근거만 사용하라.
- 답변은 반드시 "예" 또는 "아니오" 하나만 출력하라.판정 매트릭스
| 기대 응답 | 실제 응답 | 임시 해석 | 기록할 내용 |
|---|---|---|---|
예 |
예 |
기대와 일치 | 제대로 된 JSONL을 직접 근거로 인정함 |
아니오 |
아니오 |
기대와 일치 | 잘못된 JSONL을 폐기함 |
예 |
아니오 |
재검토 필요 | 직접 근거가 있는데도 놓침. false negative 후보 |
아니오 |
예 |
재검토 필요 | 직접 근거가 없는데도 인정함. false positive 후보 |
예 또는 아니오 |
다른 답변 | 재검토 필요 | 응답 형식 위반. 설명, JSON, 빈 응답, 애매한 답변 포함 |
관찰 체크리스트
테이블별 50개 샘플 테스트가 끝난 뒤 다음 항목을 확인한다.
| 체크 | 기준 | 결과 |
|---|---|---|
| 응답 형식 | 모든 응답이 예 또는 아니오 하나만 출력됨 |
|
| 관련 JSONL 응답 | 관련 JSONL 테스트에서 예 응답이 충분히 안정적으로 나옴 |
|
| 무관 JSONL 응답 | 무관 JSONL 테스트에서 아니오 응답이 충분히 안정적으로 나옴 |
|
| false positive 기록 | 아니오가 맞는데 예가 나온 케이스를 모두 따로 기록함 |
|
| false negative 기록 | 예가 맞는데 아니오가 나온 케이스를 모두 따로 기록함 |
|
| 넓은 단어 필터 | Godot, migration, 2D, physics 같은 넓은 단어만으로 예가 나오지 않음 |
|
| 직접 문자열 근거 | 예 판정에는 실제 코드 문자열/API/패턴과 맞는 JSONL 필드가 있음 |
|
| 공통문법 구분 | Godot 3/4 공통문법인 샘플은 같은 코드 chunk 기준으로 기대 예/기대 아니오 JSONL을 테스트했음 |
|
| 테이블별 차이 | docs_chunks, api_mapping, label_prototypes에서 불일치 양상이 어떻게 다른지 기록됨 |
|
| 재현 가능성 | 같은 입력을 다시 넣었을 때 판정이 크게 흔들리지 않음 | |
| 다음 판단 | 이 프롬프트와 판정 방식으로 다음 PoC에 넘겨도 되는지 결정함 |
테스트 기록 양식
아래 표를 복사해서 테스트 결과를 채운다.
| ID | 기능 | 공통문법 여부 | 테이블 | JSONL 종류 | 기대 응답 | 실제 응답 | 판정 | 직접 일치한 필드 | 메모 |
|---|---|---|---|---|---|---|---|---|---|
| G03-001-A | _ready() 함수 초기화 및 뷰포트 크기 설정 |
제대로 된 JSONL | 예 |
||||||
| G03-001-B | _ready() 함수 초기화 및 뷰포트 크기 설정 |
잘못된 JSONL | 아니오 |
테이블별 기록
docs_chunks
공식문서 설명형 근거가 코드 chunk와 직접 맞는지 확인한다.
| 번호 | 기능 | 공통문법 여부 | 관련 JSONL 결과 | 무관 JSONL 결과 | 메모 |
|---|---|---|---|---|---|
| 1 | _ready() 함수 초기화 및 뷰포트 크기 설정 |
공통문법 | 관련 JSONL 예 관찰 |
무관 JSONL 아니오 관찰 |
Node._ready, get_viewport().get_visible_rect().size, DisplayServer.window_set_size가 있는 docs_chunks 설명 근거는 예; _process(delta) 설명 JSONL은 아니오로 판정됨 |
| 2 | _process(delta) 프레임별 업데이트 루프 |
공통문법 | 관련 JSONL 예 관찰 |
무관 JSONL 아니오 관찰 |
_process(delta), position.x +=, speed * delta가 있는 docs_chunks 설명 근거는 예; Vector2.lerp 설명 JSONL은 아니오로 판정됨 |
| 3 | 플레이어 이동 입력 처리 (WASD 또는 화살표 키) | 공통문법 | 관련 JSONL 예 관찰 |
무관 JSONL 아니오 관찰 |
Input.is_action_pressed, Vector2.ZERO, direction.normalized(), velocity, move_and_slide()가 있는 docs_chunks 설명 근거는 예; TileMapLayer.set_cell() 설명 JSONL은 아니오로 판정됨 |
| 4 | 플레이어 이동 속도 및 가속도 적용 | 버전 차이 | 기존 양방향 예 기록은 확정 판정에서 제외 |
Godot 3 검사에서 docs 쪽 아니오/아니오가 나온 흐름이 있어 재검토 |
아니오, 아니오, 예, 아니오, 예, 아니오 원시 응답 때문에 기준 재정의 필요 |
| 5 | 플레이어의 최대 속도 제한 | 버전 차이 | Godot 3 기준 1차 관찰. Godot 4 기준 역방향 원시 응답: Godot 4 코드 예/예, Godot 3 코드 예/예 |
Godot 4 기준 역방향에서 docs 후보가 모두 예로 잡힘 |
CharacterBody2D, max_speed, velocity = input_vector * max_speed, move_and_slide(), Input.is_action_pressed가 직접 문자열로 겹친다. 기능 범위를 좁혀야 하는지 패턴 분석 필요 |
| 6 | 마우스 클릭 시 발사체 생성 및 발사 | 버전 차이 | Godot 3/4 설명 근거가 각각 코드 기준과 맞아 24/24 전체 통과 흐름에 포함됨 |
다른 코드 설명 JSONL도 기대대로 폐기됨 | PackedScene.instance()와 instantiate(), 마우스 입력 처리 차이가 코드 기준으로 분리되어 docs 후보가 잘 갈림 |
| 7 | 발사체의 이동 및 수명(time-to-live) 관리 | 버전 차이 | docs_chunks 쪽 설명 근거는 발사체 이동/TTL 코드와 맞는지 확인됨 | docs_chunks 무관 설명 후보는 기대대로 폐기됨 | 전체 22/24 중 불일치는 api_mapping/label_prototypes의 Godot 3 변환 근거가 Godot 4 코드에도 예로 붙은 쪽에서 발생함 |
| 8 | 적(Enemy)의 플레이어 추적(AI) 로직 | 버전 차이 | Godot 4 docs 설명 후보가 Godot 3 코드에도 예로 붙는 false positive 관찰 |
다른 코드 설명 후보도 Godot 3/4 코드에서 예로 붙은 케이스가 있어 재검토 필요 |
전체 21/24; docs_chunks가 같은 추적/이동 주제나 비슷한 API 단서를 직접 설명 근거처럼 넓게 잡은 사례 |
| 9 | 적의 이동 속도 및 회전 로직 | 버전 차이 | 이동 속도와 회전 처리 docs 근거가 코드별로 기대대로 매칭됨 | 무관 docs 후보도 기대대로 폐기됨 | 24/24 통과. 이동/회전 목적과 최종 동작이 비교적 분명해서 docs 후보가 안정적으로 갈림 |
| 10 | 플레이어가 화면 밖으로 나가면 사라지기 | 공통문법 | 화면 밖 이탈, global_position, get_viewport_rect().size, hide() 설명 근거가 예로 정리됨 |
다른 코드 설명 후보는 아니오로 정리됨 |
공통문법 6/6 통과. docs 설명 근거와 migration 계열 후보가 잘 분리됨 |
| 11 | 충돌 감지 (Area2D or PhysicsBody) | 버전 차이 | 충돌 이벤트, 감지 대상, 충돌 콜백/물리 바디 관계를 설명하는 docs 후보를 코드 chunk와 대조 | 데미지 계산이나 체력 처리처럼 충돌 이후 로직을 설명하는 후보와 구분 | sample-11에서 충돌을 “감지”하는 근거와 충돌 후 “처리” 근거가 섞이지 않는지 확인하는 항목 |
| 12 | 충돌 시 데미지 계산 및 적용 | 공통문법 | 충돌 결과로 데미지 값을 계산하고 대상 체력에 적용하는 설명 근거를 코드 chunk와 대조 | 단순 충돌 감지, 점수 갱신, 게임 오버 설명 후보와 구분 | sample-12는 충돌 자체보다 데미지 산식/적용 흐름이 docs 설명 근거의 핵심인지 확인 |
| 13 | 플레이어 체력 감소 로직 | 공통문법 | 플레이어 체력 변수 감소, 피격 처리, 하한값 처리 설명 근거를 코드 chunk와 대조 | 적 체력 감소나 점수 증가 후보와 구분 | sample-13은 같은 health 문자열이 있어도 플레이어 대상인지 적 대상인지 구분해야 하는 항목 |
| 14 | 플레이어 체력이 0이 되면 게임 오버 처리 | 공통문법 | health <= 0, 게임 오버 상태 전환, 씬 전환/정지 흐름 설명 근거를 코드 chunk와 대조 |
단순 체력 감소나 적 제거 후보와 구분 | sample-14는 체력 감소가 아니라 0 도달 이후 결과 상태가 docs 근거와 맞는지 확인 |
| 15 | 적 체력 감소 로직 | 공통문법 | 적 체력 변수 감소와 피격 처리 설명 근거를 코드 chunk와 대조 | 플레이어 체력 감소나 게임 오버 후보와 구분 | sample-15는 대상 객체가 enemy인지 player인지가 직접 설명 근거 판정의 핵심 |
| 16 | 적이 체력 0이 되면 제거 및 점수 추가 | 공통문법 | 적 제거, queue_free()/비활성화, 점수 증가 흐름 설명 근거를 코드 chunk와 대조 |
단순 체력 감소나 점수 표시 후보와 구분 | sample-16은 제거와 점수 추가가 함께 있는 최종 동작을 설명하는지 확인 |
| 17 | 점수(Score) 변수 업데이트 | 공통문법 | 점수 변수 증가/감소, 누적 값 갱신 설명 근거를 코드 chunk와 대조 | Label 표시 갱신이나 UI 렌더링 설명 후보와 구분 | sample-17은 데이터 값 갱신과 화면 표시 갱신을 분리해서 보는 항목 |
| 18 | 점수 텍스트(Label) 갱신 함수 | 공통문법 | Label.text/문자열 포맷팅으로 점수를 화면에 반영하는 설명 근거를 코드 chunk와 대조 |
점수 변수만 갱신하는 후보와 구분 | sample-18은 score 값 자체보다 UI 텍스트 반영이 직접 근거인지 확인 |
| 19 | 배경음악(BGM) 재생 및 볼륨 조절 | 공통문법 | BGM 재생 노드, bus volume, loop/volume 조절 설명 근거를 코드 chunk와 대조 | 효과음 단발 재생 후보와 구분 | sample-19는 지속 재생 BGM과 짧은 SFX 호출을 분리해서 검증하는 항목 |
| 20 | 효과음(SFX) 재생 함수 | 공통문법 | 효과음 플레이어 생성/호출, 단발 재생 설명 근거를 코드 chunk와 대조 | 배경음악 루프/볼륨 조절 후보와 구분 | sample-20은 Audio 관련 공통 단어만으로 BGM 근거가 붙지 않는지 확인 |
| 21 | 화면 진동(Screen Shake) 효과 구현 | 버전 차이 | 카메라 오프셋, 흔들림 강도/시간, Tween 또는 랜덤 오프셋 설명 근거를 코드 chunk와 대조 | 적 이동, 카메라 추적, UI 애니메이션 후보와 구분 | sample-21은 “카메라” 단어가 같아도 화면 흔들림 결과를 직접 설명하는지 확인 |
| 22 | 파티클 시스템 생성 및 위치 매칭 | 버전 차이 | 파티클 노드 생성, 위치 동기화, 방출 시작 설명 근거를 코드 chunk와 대조 | 일반 노드 생성, 발사체 생성, 애니메이션 후보와 구분 | sample-22는 생성 대상이 particle인지, 위치 매칭과 emission 흐름이 들어있는지 확인 |
| 23 | 씬 전환(Scene Change) 함수 | 버전 차이 | 씬 전환 요청, SceneTree 호출, 대상 씬 경로를 설명하는 docs 후보를 코드 chunk와 대조 | 메뉴 표시, 일시정지, 리소스 로딩처럼 씬 전환 자체가 아닌 후보와 구분 | sample-23은 실제로 화면/씬을 바꾸는 호출인지, 단순 로딩이나 UI 표시 설명인지 분리해서 봄 |
| 24 | 메인 메뉴 씬 로딩 및 표시 | 버전 차이 | 메인 메뉴 씬을 로드하고 화면에 표시하는 설명 근거를 코드 chunk와 대조 | 단순 씬 전환, 일시정지, 리소스 preload 후보와 구분 | sample-24는 메뉴 씬을 실제로 표시하는 흐름인지, 다른 씬 처리 설명인지 분리해서 봄 |
| 25 | 게임 일시정지(Pause) 기능 토글 | 공통문법 | pause 상태 토글, get_tree().paused, 입력에 따른 정지/재개 설명 근거를 코드 chunk와 대조 |
메뉴 열기, 씬 전환, 게임 오버 후보와 구분 | sample-25는 일시정지 상태 자체를 바꾸는지, 단순 UI 표시인지 확인 |
| 26 | 키보드 입력 상태 확인 (Input.is_key_pressed) | 버전 차이 | Input.is_key_pressed와 키 상수/키 코드 확인 설명 근거를 코드 chunk와 대조 |
action map 입력, 마우스 입력, 이동 처리 후보와 구분 | sample-26은 키보드 상태 조회 자체와 이동 로직 전체를 분리해서 봄 |
| 27 | 마우스 위치(커서) 좌표 가져오기 | 공통문법 | viewport/global mouse position 조회 설명 근거를 코드 chunk와 대조 | 마우스 클릭 발사, 터치 입력, 커서 표시 후보와 구분 | sample-27은 클릭 이벤트가 아니라 좌표를 읽는 코드인지 확인 |
| 28 | 랜덤 숫자 생성 함수 | 버전 차이 | RNG 초기화, 난수 생성, 범위 지정 설명 근거를 코드 chunk와 대조 | 랜덤 위치 분포, 적 스폰 타이머 후보와 구분 | sample-28은 숫자 생성 함수 자체와 그 숫자를 쓰는 gameplay 로직을 분리해서 봄 |
| 29 | 특정 시간마다 적 스폰(Spawn) | 버전 차이 | Timer/timeout/누적 시간 기반으로 적을 주기적으로 생성하는 설명 근거를 코드 chunk와 대조 | 랜덤 위치 계산이나 적 이동 AI 후보와 구분 | sample-29는 시간 간격과 spawn 호출이 직접 근거인지 확인 |
| 30 | 스폰된 적의 위치 랜덤 분포 | 공통문법 | 랜덤 좌표 범위, spawn area, 위치 분포 설명 근거를 코드 chunk와 대조 | 특정 시간마다 스폰하는 타이머 후보와 구분 | sample-30은 언제 생성하는지가 아니라 어디에 배치하는지를 설명하는지 확인 |
| 31 | 플레이어 애니메이션 상태 전환 (Idle, Run, Jump) | 버전 차이 | 입력/속도/상태에 따라 애니메이션 이름을 바꾸는 설명 근거를 코드 chunk와 대조 | 애니메이션 재생 속도나 시간 제어 후보와 구분 | sample-31은 상태 전환과 재생 시간 제어를 분리해서 봄 |
| 32 | 애니메이션 재생 시간 제어 | 공통문법 | animation speed, seek, advance, playback position 제어 설명 근거를 코드 chunk와 대조 | Idle/Run/Jump 상태 전환 후보와 구분 | sample-32는 어떤 애니메이션을 고르는지가 아니라 재생 시간/속도를 조절하는지 확인 |
| 33 | 충돌 영역 크기 조정 | 버전 차이 | CollisionShape2D/Shape2D 크기 속성, RectangleShape2D의 size/extents 계열 설명 근거를 코드 chunk와 대조 | 충돌 감지, 데미지 처리, Area2D signal 후보와 구분 | sample-33은 충돌이 발생했는지가 아니라 충돌 영역의 모양/크기를 조정하는 코드인지 확인 |
| 34 | 물리 중력(Gravity) 적용 | 버전 차이 | velocity에 gravity와 delta를 누적하고 move 함수로 적용하는 설명 근거를 코드 chunk와 대조 | 점프 힘, 착지 감지, Area gravity 설정 후보와 구분 | sample-34는 중력 누적 흐름과 점프/착지 판정을 분리해서 검증하는 항목 |
| 35 | 점프(Jump) 힘 적용 및 착지 감지 | 버전 차이 | is_on_floor(), jump velocity, 입력 조건, 착지 상태 설명 근거를 코드 chunk와 대조 |
중력만 적용하는 후보나 애니메이션 상태 전환 후보와 구분 | sample-35는 점프 입력과 바닥 판정이 같은 이동 흐름 안에서 설명되는지 확인 |
| 36 | 벽 충돌 시 미끄러짐(Slide) 처리 | ||||
| 37 | 플레이어 방향 전환 (Facing Left/Right) | ||||
| 38 | 탄창(Ammo) 카운트 감소 | ||||
| 39 | 탄창이 비었을 때 재장전(Reload) 상태 전환 | ||||
| 40 | UI 버튼 클릭 이벤트 연결 | ||||
| 41 | 설정(Settings) 메뉴 오픈/닫기 토글 | ||||
| 42 | 언어(Language) 변경 시 텍스트 업데이트 | ||||
| 43 | 저장 데이터(Save Game) JSON 직렬화 | ||||
| 44 | 로드 데이터(Load Game) JSON 역직렬화 | ||||
| 45 | 파일 읽기/쓰기 오류 처리 | ||||
| 46 | 네트워크 연결 상태 체크 | ||||
| 47 | 원격 함수(RPC) 호출을 통한 동기화 | ||||
| 48 | 씬 리소스 동적 로딩 | ||||
| 49 | 메모리 할당 해제 및 리소스 언로드 | ||||
| 50 | 디버깅 로그 출력 (print 또는 print_debug) |
api_mapping
Godot 3에서 Godot 4로 이름, 클래스, 함수, 심볼이 어떻게 바뀌는지에 대한 근거가 코드 chunk와 직접 맞는지 확인한다.
| 번호 | 기능 | 공통문법 여부 | 관련 JSONL 결과 | 무관 JSONL 결과 | 메모 |
|---|---|---|---|---|---|
| 1 | _ready() 함수 초기화 및 뷰포트 크기 설정 |
공통문법 | 관련 JSONL 예 관찰 |
무관 JSONL 아니오 관찰 |
DisplayServer.window_set_size, Vector2i가 있는 mapping은 예; AudioServer.get_bus_volume_db mapping은 아니오로 판정됨 |
| 2 | _process(delta) 프레임별 업데이트 루프 |
공통문법 | 관련 JSONL 예 관찰 |
무관 JSONL 아니오 관찰 |
position.x, delta, _process가 있는 stable mapping은 예; get_node("Sprite2D") mapping은 아니오로 판정됨 |
| 3 | 플레이어 이동 입력 처리 (WASD 또는 화살표 키) | 공통문법 | 관련 JSONL 예 관찰 |
무관 JSONL 아니오 관찰 |
CharacterBody2D.move_and_slide, velocity, Vector2가 있는 mapping은 예; Node.connect/signal connect mapping은 아니오로 판정됨 |
| 4 | 플레이어 이동 속도 및 가속도 적용 | 버전 차이 | 기존 양방향 예 기록은 확정 판정에서 제외 |
Godot 3 검사에서 api_mapping 쪽은 예/아니오로 갈림 |
move_and_slide, CharacterBody3D, move_toward, velocity.x, velocity.z, target_velocity mapping이 코드 버전에 따라 어떻게 반응하는지 재검토 필요 |
| 5 | 플레이어의 최대 속도 제한 | 버전 차이 | Godot 3 기준 1차 관찰. Godot 4 기준 역방향 원시 응답: Godot 4 코드 예/예, Godot 3 코드 아니오/아니오 |
Godot 4 코드에서는 mapping 후보 2개가 모두 예, Godot 3 코드에서는 모두 아니오 |
move_and_slide, velocity, limit_speed, collision normal 반환 차이 기준. Godot 4 문법과 Godot 3 문법을 어떻게 기대값으로 나눌지 패턴 분석 필요 |
| 6 | 마우스 클릭 시 발사체 생성 및 발사 | 버전 차이 | Godot 3/4 발사체 생성 API 차이와 입력 처리 mapping이 기대대로 매칭됨 | 무관 mapping 후보도 폐기됨 | PackedScene.instance()와 instantiate()처럼 source/target 형태가 분리되어 24/24 통과 흐름에 포함됨 |
| 7 | 발사체의 이동 및 수명(time-to-live) 관리 | 버전 차이 | Godot 3 기준 변환 mapping이 Godot 3 코드에서는 예로 잡힘 |
같은 mapping이 Godot 4 코드에도 예로 붙은 불일치 관찰 |
전체 22/24; 이미 Godot 4 코드라면 변환 적용 대상이 아니므로 검증 프롬프트에서 source-side 여부를 더 분명히 봐야 함 |
| 8 | 적(Enemy)의 플레이어 추적(AI) 로직 | 버전 차이 | api_mapping 쪽은 8번 불일치의 직접 원인은 아니었음 | 무관 mapping 후보는 기대대로 폐기되는 흐름 | 전체 불일치는 docs_chunks에서 발생. mapping은 추적 AI 코드의 버전별 API 변경 여부를 확인하는 보조 축으로 기록 |
| 9 | 적의 이동 속도 및 회전 로직 | 버전 차이 | 회전/이동 관련 mapping이 코드 기준과 맞게 매칭됨 | 무관 mapping 후보도 기대대로 폐기됨 | 24/24 통과. 이동 속도와 회전 API 차이가 비교적 잘 분리됨 |
| 10 | 플레이어가 화면 밖으로 나가면 사라지기 | 공통문법 | 공통 코드라 api_mapping 관련 JSONL은 변환 필요로 보지 않음 | 무관 변환 후보도 아니오 흐름 |
6/6 통과. 공통문법에서는 migration 테이블이 굳이 붙지 않는 흐름이 확인됨 |
| 11 | 충돌 감지 (Area2D or PhysicsBody) | 버전 차이 | Area2D/PhysicsBody 충돌 감지 API나 signal 연결 변화가 현재 코드에 필요한 mapping인지 확인 | 데미지 적용이나 체력 처리 mapping과 구분 | sample-11은 감지 API 자체와 후속 처리 로직을 분리하는 mapping 판정 항목 |
| 12 | 충돌 시 데미지 계산 및 적용 | 공통문법 | 데미지 적용 방식에서 버전별 API 변경이 실제 코드에 있는지 확인 | 충돌 감지 signal만 설명하는 mapping과 구분 | sample-12는 mapping이 필요한 변경인지, 단순 게임 로직 설명인지 나누는 항목 |
| 13 | 플레이어 체력 감소 로직 | 공통문법 | 플레이어 체력 감소 코드에 버전별 API 변경 근거가 실제로 필요한지 확인 | 적 체력/점수/게임오버 mapping 후보와 구분 | sample-13은 대부분 게임 로직 성격이 강하므로 migration 근거가 과도하게 붙는지 관찰 |
| 14 | 플레이어 체력이 0이 되면 게임 오버 처리 | 공통문법 | 게임 오버 처리에서 씬 전환, pause, tree API 변화가 코드에 직접 있는지 확인 | 단순 체력 감소 mapping 후보와 구분 | sample-14는 결과 상태 전환 API가 mapping 근거인지 확인 |
| 15 | 적 체력 감소 로직 | 공통문법 | 적 체력 감소 로직에 실제 Godot 3->4 API 변경 근거가 필요한지 확인 | 플레이어 체력 처리나 점수 처리 mapping과 구분 | sample-15는 대상 객체가 다르면 mapping 후보가 검색되어도 아니오로 떨어져야 하는 항목 |
| 16 | 적이 체력 0이 되면 제거 및 점수 추가 | 공통문법 | 제거 API, score 갱신 API, scene tree 조작 차이가 현재 코드에 있는지 확인 | 단순 damage mapping이나 Label 갱신 mapping과 구분 | sample-16은 제거와 점수 추가 중 어떤 부분이 mapping 근거인지 분리해서 봄 |
| 17 | 점수(Score) 변수 업데이트 | 공통문법 | 점수 변수 갱신에 실제 API 변경 근거가 필요한지 확인 | UI 텍스트 갱신이나 저장/로드 mapping과 구분 | sample-17은 단순 변수 연산을 migration 근거로 과대 판정하지 않는지 보는 항목 |
| 18 | 점수 텍스트(Label) 갱신 함수 | 공통문법 | Label 텍스트 접근 방식이나 노드 참조 방식 변화가 현재 코드에 필요한지 확인 | 점수 값 계산 mapping과 구분 | sample-18은 Label.text 계열 표현이 공통인지, 버전별 변경이 있는지 확인 |
| 19 | 배경음악(BGM) 재생 및 볼륨 조절 | 공통문법 | AudioServer, AudioStreamPlayer, bus volume 관련 변경 근거가 코드에 직접 필요한지 확인 | SFX 단발 재생 mapping과 구분 | sample-19는 오디오 관련 넓은 단어만으로 mapping이 붙지 않게 보는 항목 |
| 20 | 효과음(SFX) 재생 함수 | 공통문법 | 효과음 재생 API나 노드 생성 방식 변화가 코드에 직접 있는지 확인 | BGM 루프/볼륨 조절 mapping과 구분 | sample-20은 SFX와 BGM이 같은 Audio 계열이라도 변환 근거를 분리해서 봄 |
| 21 | 화면 진동(Screen Shake) 효과 구현 | 버전 차이 | Tween, Camera2D, offset/random shake 구현에서 버전별 API 변화가 있는지 확인 | 카메라 추적이나 일반 이동 mapping과 구분 | sample-21은 카메라 관련 후보가 화면 흔들림 변환 근거인지 검증 |
| 22 | 파티클 시스템 생성 및 위치 매칭 | 버전 차이 | Particles2D/GPUParticles2D, emitting, position/global_position 관련 변경 근거가 코드에 직접 있는지 확인 | 발사체 생성이나 일반 노드 생성 mapping과 구분 | sample-22는 파티클 시스템 전용 API 변화와 일반 생성 로직을 분리해서 봄 |
| 23 | 씬 전환(Scene Change) 함수 | 버전 차이 | change_scene, change_scene_to_file, change_scene_to_packed 계열 변경 근거가 현재 코드에 직접 있는지 확인 |
단순 load()/preload()나 메인 메뉴 표시 mapping과 구분 |
sample-23은 Godot 3의 씬 전환 호출과 Godot 4의 대체 호출이 실제 코드 버전에 맞게 붙는지 확인 |
| 24 | 메인 메뉴 씬 로딩 및 표시 | 버전 차이 | scene loading, instancing, menu scene 표시 관련 변경 근거가 현재 코드에 필요한지 확인 | 일반 씬 전환이나 리소스 preload mapping과 구분 | sample-24는 메인 메뉴 표시 목적과 scene API 변경 근거가 섞이지 않는지 보는 항목 |
| 25 | 게임 일시정지(Pause) 기능 토글 | 공통문법 | pause mode/process mode, tree pause 관련 변경 근거가 현재 코드에 실제로 필요한지 확인 | 메뉴 UI나 게임 오버 mapping과 구분 | sample-25는 공통 pause 토글 코드에 migration mapping이 과도하게 붙는지 확인 |
| 26 | 키보드 입력 상태 확인 (Input.is_key_pressed) | 버전 차이 | 키 상수, scancode/keycode, Input.is_key_pressed 관련 변경 근거가 코드와 직접 맞는지 확인 |
action map 이동 처리나 마우스 입력 mapping과 구분 | sample-26은 키 상태 조회 API 변화와 입력을 사용하는 gameplay 로직을 나눠 봄 |
| 27 | 마우스 위치(커서) 좌표 가져오기 | 공통문법 | mouse position 조회 API가 버전별 변경 근거를 필요로 하는지 확인 | 클릭 발사체 생성이나 터치 입력 mapping과 구분 | sample-27은 좌표 읽기 코드에 불필요한 변환 근거가 붙지 않는지 확인 |
| 28 | 랜덤 숫자 생성 함수 | 버전 차이 | randomize, RandomNumberGenerator, range 함수 변경 근거가 코드에 직접 있는지 확인 | 랜덤 스폰 위치나 spawn timer mapping과 구분 | sample-28은 난수 API 자체의 변경과 난수 사용 목적을 분리해서 봄 |
| 29 | 특정 시간마다 적 스폰(Spawn) | 버전 차이 | Timer signal, timeout 연결, yield/await 계열 변경 근거가 현재 코드에 직접 있는지 확인 | 적 위치 랜덤 분포나 적 AI 이동 mapping과 구분 | sample-29는 주기 실행 구조와 생성 대상 로직을 함께 확인 |
| 30 | 스폰된 적의 위치 랜덤 분포 | 공통문법 | random range, viewport size, spawn area 계산에 실제 API 변경 근거가 필요한지 확인 | Timer 기반 주기 spawn mapping과 구분 | sample-30은 위치 계산만 있는 코드에 spawn 주기 mapping이 붙지 않는지 확인 |
| 31 | 플레이어 애니메이션 상태 전환 (Idle, Run, Jump) | 버전 차이 | AnimatedSprite/AnimatedSprite2D, AnimationPlayer 상태 전환 관련 변경 근거가 코드와 직접 맞는지 확인 | playback speed/seek/time control mapping과 구분 | sample-31은 애니메이션 노드 이름 변경과 상태 전환 패턴을 분리해서 봄 |
| 32 | 애니메이션 재생 시간 제어 | 공통문법 | playback speed, seek, current position 관련 변경 근거가 현재 코드에 필요한지 확인 | Idle/Run/Jump 상태 선택 mapping과 구분 | sample-32는 재생 시간 조절 API와 상태 전환 API를 구분 |
| 33 | 충돌 영역 크기 조정 | 버전 차이 | CollisionShape2D, RectangleShape2D, shape size/extents 변경 근거가 현재 코드에 직접 필요한지 확인 | collision signal, physics layer, damage mapping과 구분 | sample-33은 충돌 판정 API가 아니라 shape 크기 조정 API 변화가 실제 코드와 맞는지 보는 항목 |
| 34 | 물리 중력(Gravity) 적용 | 버전 차이 | CharacterBody2D/KinematicBody2D, velocity, move_and_slide 계열 변경 근거가 현재 코드에 직접 필요한지 확인 | jump impulse, floor check, Area2D gravity mapping과 구분 | sample-34는 물리 프레임에서 중력을 누적해 이동에 반영하는 mapping인지 확인 |
| 35 | 점프(Jump) 힘 적용 및 착지 감지 | 버전 차이 | is_on_floor(), jump velocity, Input action, move_and_slide 관련 변경 근거가 코드와 직접 맞는지 확인 |
gravity-only 이동, 애니메이션 상태, 벽 충돌 mapping과 구분 | sample-35는 점프 시작 조건과 착지 판정이 함께 필요한 mapping인지 확인 |
| 36 | 벽 충돌 시 미끄러짐(Slide) 처리 | ||||
| 37 | 플레이어 방향 전환 (Facing Left/Right) | ||||
| 38 | 탄창(Ammo) 카운트 감소 | ||||
| 39 | 탄창이 비었을 때 재장전(Reload) 상태 전환 | ||||
| 40 | UI 버튼 클릭 이벤트 연결 | ||||
| 41 | 설정(Settings) 메뉴 오픈/닫기 토글 | ||||
| 42 | 언어(Language) 변경 시 텍스트 업데이트 | ||||
| 43 | 저장 데이터(Save Game) JSON 직렬화 | ||||
| 44 | 로드 데이터(Load Game) JSON 역직렬화 | ||||
| 45 | 파일 읽기/쓰기 오류 처리 | ||||
| 46 | 네트워크 연결 상태 체크 | ||||
| 47 | 원격 함수(RPC) 호출을 통한 동기화 | ||||
| 48 | 씬 리소스 동적 로딩 | ||||
| 49 | 메모리 할당 해제 및 리소스 언로드 | ||||
| 50 | 디버깅 로그 출력 (print 또는 print_debug) |
label_prototypes
단순 이름 변경이 아니라 함수 사용 방식, 인자 구성, 호출 패턴이 통째로 바뀌는 예시 근거가 코드 chunk와 직접 맞는지 확인한다.
| 번호 | 기능 | 공통문법 여부 | 관련 JSONL 결과 | 무관 JSONL 결과 | 메모 |
|---|---|---|---|---|---|
| 1 | _ready() 함수 초기화 및 뷰포트 크기 설정 |
공통문법 | 관련 JSONL 예 관찰 |
무관 JSONL 아니오 관찰 |
DisplayServer.window_set_size(Vector2i(1920, 1080)) prototype은 예; AudioStreamPlayer3D prototype은 아니오로 판정됨 |
| 2 | _process(delta) 프레임별 업데이트 루프 |
공통문법 | 관련 JSONL 예 관찰 |
무관 JSONL 아니오 관찰 |
func _process(delta)와 position.x += move_speed * delta prototype은 예; _input(event)/event.is_action_pressed prototype은 아니오로 판정됨 |
| 3 | 플레이어 이동 입력 처리 (WASD 또는 화살표 키) | 공통문법 | 관련 JSONL 예 관찰 |
무관 JSONL 아니오 관찰 |
Input.is_action_pressed, velocity = direction * move_speed, move_and_slide() prototype은 예; @onready/node path access prototype은 아니오로 판정됨 |
| 4 | 플레이어 이동 속도 및 가속도 적용 | 버전 차이 | 기존 양방향 예 기록은 확정 판정에서 제외 |
Godot 3 검사에서 label_prototypes 쪽은 예/아니오로 갈림 |
축별 move_toward(velocity.x/velocity.z), move_and_slide(), CharacterBody3D prototype이 버전 전용 근거인지 공통 문자열 근거인지 재검토 필요 |
| 5 | 플레이어의 최대 속도 제한 | 버전 차이 | Godot 3 기준 1차 관찰. Godot 4 기준 역방향 원시 응답: Godot 4 코드 예/아니오, Godot 3 코드 예/아니오 |
Tween prototype은 양쪽 모두 아니오로 폐기됨 |
CharacterBody2D, move_and_slide(), velocity가 양쪽 코드에 모두 있어 관련 prototype은 둘 다 예로 잡힘. 버전 전용 근거와 공통 문자열 근거를 분리해야 함 |
| 6 | 마우스 클릭 시 발사체 생성 및 발사 | 버전 차이 | 발사체 생성/발사 호출 패턴 prototype이 코드 기준과 맞게 매칭됨 | 무관 prototype 후보도 폐기됨 | 24/24 통과 흐름에 포함됨. 입력 처리와 projectile 생성 패턴이 잘 분리됨 |
| 7 | 발사체의 이동 및 수명(time-to-live) 관리 | 버전 차이 | Godot 3 기준 변환 prototype이 Godot 3 코드에서는 예로 잡힘 |
같은 prototype이 Godot 4 코드에도 예로 붙은 불일치 관찰 |
전체 22/24; 이미 변환된 Godot 4 코드에 “변환 필요” prototype이 붙으면 안 되는 사례 |
| 8 | 적(Enemy)의 플레이어 추적(AI) 로직 | 버전 차이 | label_prototypes 쪽은 8번 불일치의 직접 원인은 아니었음 | 무관 prototype 후보는 기대대로 폐기되는 흐름 | 전체 불일치는 docs_chunks에서 발생. prototype은 추적 AI의 사용 방식 변화 여부를 보는 보조 축으로 기록 |
| 9 | 적의 이동 속도 및 회전 로직 | 버전 차이 | 이동/회전 호출 패턴 prototype이 코드 기준과 맞게 매칭됨 | 무관 prototype 후보도 기대대로 폐기됨 | 24/24 통과. 이동 속도 계산과 회전 적용 패턴이 비교적 선명하게 분리됨 |
| 10 | 플레이어가 화면 밖으로 나가면 사라지기 | 공통문법 | 공통 코드라 label_prototypes 관련 JSONL은 변환 필요로 보지 않음 | 무관 변환 후보도 아니오 흐름 |
6/6 통과. 공통문법에서는 prototype이 굳이 붙지 않는 흐름이 확인됨 |
| 11 | 충돌 감지 (Area2D or PhysicsBody) | 버전 차이 | 충돌 감지 signal/callback 사용 방식이 현재 코드의 변경 전 패턴인지 확인 | 충돌 후 데미지 적용 prototype과 구분 | sample-11은 감지 이벤트 패턴과 후속 gameplay 처리 패턴을 분리해서 보는 항목 |
| 12 | 충돌 시 데미지 계산 및 적용 | 공통문법 | 충돌 결과로 데미지를 적용하는 호출 패턴이 현재 코드에 직접 있는지 확인 | 단순 충돌 감지나 체력 0 처리 prototype과 구분 | sample-12는 인자 구성, 대상 객체, 데미지 적용 순서가 prototype 근거인지 확인 |
| 13 | 플레이어 체력 감소 로직 | 공통문법 | 플레이어 피격/체력 감소 패턴이 현재 코드에 직접 있는지 확인 | 적 체력 감소 prototype과 구분 | sample-13은 같은 health 계열이라도 player/enemy 대상 차이를 검증 |
| 14 | 플레이어 체력이 0이 되면 게임 오버 처리 | 공통문법 | 체력 0 이후 게임 오버 호출 패턴이 현재 코드에 직접 있는지 확인 | 단순 체력 감소나 적 제거 prototype과 구분 | sample-14는 조건식 이후 상태 전환/씬 처리까지 prototype이 설명하는지 확인 |
| 15 | 적 체력 감소 로직 | 공통문법 | enemy damage/health 감소 패턴이 현재 코드에 직접 있는지 확인 | player damage prototype과 구분 | sample-15는 대상 객체와 상태 변수 이름이 넓게 겹칠 때 false positive가 생기는지 보는 항목 |
| 16 | 적이 체력 0이 되면 제거 및 점수 추가 | 공통문법 | enemy 제거와 score 증가가 함께 있는 호출 패턴이 현재 코드에 직접 있는지 확인 | 단순 score 업데이트나 단순 제거 prototype과 구분 | sample-16은 여러 행동이 묶인 prototype이 SOURCE_CODE의 실제 순서와 맞는지 확인 |
| 17 | 점수(Score) 변수 업데이트 | 공통문법 | score 변수 갱신 패턴이 현재 코드에 직접 있는지 확인 | Label 텍스트 반영 prototype과 구분 | sample-17은 내부 데이터 갱신과 UI 표시 갱신을 나누는 항목 |
| 18 | 점수 텍스트(Label) 갱신 함수 | 공통문법 | Label text 갱신 패턴이 현재 코드에 직접 있는지 확인 | score 변수만 바꾸는 prototype과 구분 | sample-18은 값 변경이 아니라 화면 표시에 대한 prototype인지 확인 |
| 19 | 배경음악(BGM) 재생 및 볼륨 조절 | 공통문법 | BGM 재생/볼륨 조절 패턴이 현재 코드에 직접 있는지 확인 | SFX 단발 재생 prototype과 구분 | sample-19는 Audio 계열 공통 단어보다 지속 재생/볼륨 조절 목적을 봐야 하는 항목 |
| 20 | 효과음(SFX) 재생 함수 | 공통문법 | SFX 호출/재생 패턴이 현재 코드에 직접 있는지 확인 | BGM 루프나 bus volume prototype과 구분 | sample-20은 짧은 효과음 재생과 배경음악 관리 흐름을 구분 |
| 21 | 화면 진동(Screen Shake) 효과 구현 | 버전 차이 | 화면 흔들림 강도/시간/offset 적용 패턴이 현재 코드에 직접 있는지 확인 | 카메라 추적이나 일반 Tween prototype과 구분 | sample-21은 Camera2D/Tween이 있어도 최종 효과가 shake인지 확인 |
| 22 | 파티클 시스템 생성 및 위치 매칭 | 버전 차이 | particle 생성, 위치 매칭, emitting 시작 패턴이 현재 코드에 직접 있는지 확인 | 발사체 생성이나 일반 노드 생성 prototype과 구분 | sample-22는 위치 동기화와 방출 시작까지 prototype이 설명하는지 확인 |
| 23 | 씬 전환(Scene Change) 함수 | 버전 차이 | 씬 경로를 받아 SceneTree로 전환하는 호출 패턴이 현재 코드에 직접 있는지 확인 | 단순 리소스 로딩, 메뉴 열기, 일시정지 prototype과 구분 | sample-23은 씬 전환의 입력 경로, 호출 대상, 전환 결과까지 prototype이 설명하는지 확인 |
| 24 | 메인 메뉴 씬 로딩 및 표시 | 버전 차이 | 메뉴 씬을 불러오고 표시하는 호출 패턴이 현재 코드에 직접 있는지 확인 | 단순 리소스 로딩, 씬 전환, pause menu prototype과 구분 | sample-24는 “메인 메뉴를 표시한다”는 결과까지 prototype이 설명하는지 확인 |
| 25 | 게임 일시정지(Pause) 기능 토글 | 공통문법 | pause 상태를 뒤집고 관련 UI/입력 처리를 묶는 패턴이 현재 코드에 직접 있는지 확인 | 설정 메뉴 열기나 게임 오버 prototype과 구분 | sample-25는 pause flag 변경과 화면 표시를 같은 흐름으로 봐야 하는지 확인 |
| 26 | 키보드 입력 상태 확인 (Input.is_key_pressed) | 버전 차이 | 키 입력 상태를 직접 polling하는 패턴이 현재 코드에 있는지 확인 | action strength, movement vector, mouse input prototype과 구분 | sample-26은 입력 조회와 그 입력으로 수행하는 행동을 분리해서 기록 |
| 27 | 마우스 위치(커서) 좌표 가져오기 | 공통문법 | 커서 좌표를 읽어 변수나 위치 계산에 쓰는 패턴이 현재 코드에 직접 있는지 확인 | 마우스 클릭 이벤트나 발사체 생성 prototype과 구분 | sample-27은 mouse position 조회 자체가 핵심인지 확인 |
| 28 | 랜덤 숫자 생성 함수 | 버전 차이 | 난수 생성/범위 지정 호출 패턴이 현재 코드에 직접 있는지 확인 | 스폰 위치 분포, 드랍 테이블, 타이머 spawn prototype과 구분 | sample-28은 random API 호출과 random 결과 사용처를 분리해서 봄 |
| 29 | 특정 시간마다 적 스폰(Spawn) | 버전 차이 | 일정 시간마다 spawn 함수를 호출하는 패턴이 현재 코드에 직접 있는지 확인 | 랜덤 위치 계산이나 적 추적 AI prototype과 구분 | sample-29는 시간 조건, 타이머, spawn 호출 순서가 맞는지 확인 |
| 30 | 스폰된 적의 위치 랜덤 분포 | 공통문법 | 생성된 적의 위치를 랜덤 범위 안에 배치하는 패턴이 현재 코드에 직접 있는지 확인 | 일정 시간마다 생성하는 spawn loop prototype과 구분 | sample-30은 분포/좌표 계산과 생성 주기를 분리 |
| 31 | 플레이어 애니메이션 상태 전환 (Idle, Run, Jump) | 버전 차이 | 상태값이나 속도에 따라 animation name을 바꾸는 패턴이 현재 코드에 직접 있는지 확인 | playback speed, seek, frame/time control prototype과 구분 | sample-31은 어떤 상태로 전환하는지가 핵심인지 확인 |
| 32 | 애니메이션 재생 시간 제어 | 공통문법 | 재생 속도, seek, 현재 재생 위치를 제어하는 패턴이 현재 코드에 직접 있는지 확인 | Idle/Run/Jump 상태 전환 prototype과 구분 | sample-32는 애니메이션 선택이 아니라 재생 시간 제어가 핵심인지 확인 |
| 33 | 충돌 영역 크기 조정 | 버전 차이 | 충돌 shape의 크기 값을 읽거나 바꾸는 패턴이 현재 코드에 직접 있는지 확인 | 충돌 이벤트 처리나 데미지 적용 prototype과 구분 | sample-33은 shape 크기 변경이 핵심인지, 충돌 결과 처리인지 분리해서 기록 |
| 34 | 물리 중력(Gravity) 적용 | 버전 차이 | delta 기반으로 중력을 velocity에 누적하고 이동 호출로 반영하는 패턴이 현재 코드에 직접 있는지 확인 | 점프 입력, 착지 확인, 스폰/타이머 prototype과 구분 | sample-34는 물리 이동 루프 안에서 중력 누적이 핵심인지 확인 |
| 35 | 점프(Jump) 힘 적용 및 착지 감지 | 버전 차이 | 바닥에 있을 때 점프 힘을 적용하고 이후 착지 여부를 확인하는 패턴이 현재 코드에 직접 있는지 확인 | 중력 누적만 있는 이동 prototype이나 애니메이션 상태 전환 prototype과 구분 | sample-35는 점프 조건, 수직 속도 변경, floor 판정이 한 흐름으로 묶이는지 확인 |
| 36 | 벽 충돌 시 미끄러짐(Slide) 처리 | ||||
| 37 | 플레이어 방향 전환 (Facing Left/Right) | ||||
| 38 | 탄창(Ammo) 카운트 감소 | ||||
| 39 | 탄창이 비었을 때 재장전(Reload) 상태 전환 | ||||
| 40 | UI 버튼 클릭 이벤트 연결 | ||||
| 41 | 설정(Settings) 메뉴 오픈/닫기 토글 | ||||
| 42 | 언어(Language) 변경 시 텍스트 업데이트 | ||||
| 43 | 저장 데이터(Save Game) JSON 직렬화 | ||||
| 44 | 로드 데이터(Load Game) JSON 역직렬화 | ||||
| 45 | 파일 읽기/쓰기 오류 처리 | ||||
| 46 | 네트워크 연결 상태 체크 | ||||
| 47 | 원격 함수(RPC) 호출을 통한 동기화 | ||||
| 48 | 씬 리소스 동적 로딩 | ||||
| 49 | 메모리 할당 해제 및 리소스 언로드 | ||||
| 50 | 디버깅 로그 출력 (print 또는 print_debug) |
2026년 7월 6일 추가 기록
6번부터 10번까지는 2026년 7월 3일에 이미 개선 흐름까지 반영해 상세 관찰을 남긴 구간이다. 그래서 이번 문서에서는 6~10번을 빈칸으로 두지 않고, 기존 관찰 내용을 docs_chunks, api_mapping, label_prototypes 표에도 각각 맞춰 적었다.
2026년 7월 6일에는 http://localhost:8520/#item=sample-22 기준으로 11번부터 22번까지 추가 기록했다. 이 구간은 각 항목에서 어떤 근거 후보가 관련 JSONL인지, 어떤 후보가 다른 코드/다른 변환/다른 패턴으로 떨어져야 하는지를 항목별로 풀어쓴다.
2026년 7월 8일 추가 기록
2026년 7월 8일에는 http://localhost:8520/#item=sample-32 기준으로 23번 이후 이어서 32번까지 추가 기록했다. 이 구간도 확정 판정표라기보다, docs_chunks, api_mapping, label_prototypes가 같은 코드 chunk를 각자 어떤 관점으로 설명하거나 거절해야 하는지 남기는 관찰표로 본다.
2026년 7월 13일 추가 기록
2026년 7월 13일에는 http://localhost:8520/#item=sample-35 기준으로 33번 이후 이어서 35번까지 기록했다. 이번 구간은 충돌 영역 크기, 중력, 점프/착지처럼 물리 이동과 충돌 형태가 서로 영향을 주는 항목이라, 단순 문자열 겹침보다 코드의 목적과 적용 위치를 같이 봐야 할 것 같다.
5번 역방향 관찰
5번은 오늘 목표 수량에는 들어갔지만, Godot 4 기준 JSONL로 역방향 검사했을 때 결과가 깔끔한 예/아니오 쌍으로만 떨어지지 않았다. 따라서 확정 여부를 판단하지 않고, 다음 단계에서 패턴 분석 대상으로 본다.
응답 순서는 docs_chunks #1, docs_chunks #2, api_mapping #1, api_mapping #2, label_prototypes #1, label_prototypes #2다.
| 검사 코드 | 응답 순서 | 관찰 |
|---|---|---|
| Godot 4 코드 | 예, 예, 예, 예, 예, 아니오 |
limit_speed, velocity, move_and_slide(), Input.is_action_pressed처럼 코드와 직접 겹치는 문자열이 많아 docs/api 후보가 넓게 예로 잡힘 |
| Godot 3 코드 | 예, 예, 아니오, 아니오, 예, 아니오 |
docs 후보와 CharacterBody2D prototype은 예로 잡히지만, Godot 4 기준 api_mapping 후보는 아니오로 갈림 |
이 결과는 단순히 모델이 틀렸다고 보기보다, JSONL 안의 match_terms, required_when_seen_in_code, content가 너무 넓은지 확인해야 하는 신호로 본다. 특히 move_and_slide()와 Input.is_action_pressed처럼 공통으로 등장하는 문자열은 직접 근거가 되지만, 최대 속도 제한이나 버전 차이 근거로는 너무 넓을 수 있다.
불일치 케이스 기록
False Positive
아니오가 맞는데 예라고 나온 케이스를 적는다.
| ID | 기능 | 공통문법 여부 | 테이블 | 잘못된 JSONL 요약 | Qwen 응답 | 왜 재검토인지 |
|---|---|---|---|---|---|---|
False Negative
예가 맞는데 아니오라고 나온 케이스를 적는다.
| ID | 기능 | 공통문법 여부 | 테이블 | 제대로 된 JSONL 요약 | Qwen 응답 | 왜 재검토인지 |
|---|---|---|---|---|---|---|
응답 형식 위반
예 또는 아니오가 아니라 설명문, JSON, 빈 응답, 여러 문장으로 답한 케이스를 적는다.
| ID | 기능 | 공통문법 여부 | 테이블 | 기대 응답 | 실제 응답 | 메모 |
|---|---|---|---|---|---|---|
관찰 요약
테스트를 진행하면서 아래 숫자와 원시 응답을 채운다. 여기서는 판정을 확정하지 않고, 응답이 어떤 기준에서 흔들리는지만 본다.
| 항목 | docs_chunks | api_mapping | label_prototypes | 합계 |
|---|---|---|---|---|
| 오늘 관찰량 | 23~32 추가 기록 | 23~32 추가 기록 | 23~32 추가 기록 | 2026-07-08 기준 23~32 추가 기록 |
| 전체 관찰량 | 32/50 테스트 기록 | 32/50 테스트 기록 | 32/50 테스트 기록 | 32/50 테스트 기록 |
| 테스트한 코드 chunk 수 | 32/50 | 32/50 | 32/50 | 32/50 |
| 공통문법 샘플 수 | 누적 산정 보류 | 누적 산정 보류 | 누적 산정 보류 | 32번까지 라벨 기록 후 별도 집계 필요 |
| 버전 차이 샘플 수 | 누적 산정 보류 | 누적 산정 보류 | 누적 산정 보류 | 32번까지 라벨 기록 후 별도 집계 필요 |
| 1차 기준 기대 응답 일치 | 5 | 5 | 5 | 15 |
| 1차 기준 기대 응답 불일치 | 0 | 0 | 0 | 0 |
| 5번 Godot 4 기준 역방향 원시 응답 | Godot 4 예/예, Godot 3 예/예 |
Godot 4 예/예, Godot 3 아니오/아니오 |
Godot 4 예/아니오, Godot 3 예/아니오 |
패턴 분석 필요 |
| 응답 형식 위반 | 0 | 0 | 0 | 0 |
| 재검토 필요 | 2 | 2 | 2 | 4번/5번 기준 재정의 필요 |
| 현재 판단 | 확정 판정 보류 | 확정 판정 보류 | 확정 판정 보류 | 23~32 추가 기록까지 포함해 후속 패턴 분석 필요 |