2026-06-28 회고 | idea_world

오늘은 Qwen으로 Markdown을 JSONL로 수집하는 작업을 돌려두고, 그 JSONL을 나중에 DB에 밀어넣었을 때 어떻게 검색해서 뽑아올지를 고민했다.

우리가 만들었던 AST 디버깅 프로그램은 Godot 프로젝트에서 코드 chunk를 뽑아낸다. 그 chunk를 기반으로, DB에 들어간 docs_chunks, api_mapping, label_prototypes JSONL을 어떤 방식으로 검색해서 받아올지 전략이 필요했다. 그래서 A부터 F까지 검색 전략을 나눠서 문서화했고, 지금 기준에서는 F 전략을 채택했다.

지금은 아직 Markdown을 JSONL로 수집하는 중이라, 실제 DB에 넣고 리트리버로 검색하는 테스트를 바로 하기는 어렵다. 그래서 오늘은 50개의 체크리스트를 만들고, Qwen에게 임의의 Godot 코드를 짜달라고 요청했다. 그 코드에 맞는 임의 JSONL과 맞지 않는 임의 JSONL도 만들어서, jsonl + prompt + chunk를 같이 던졌을 때 Qwen이 어떻게 판정하는지 확인했다. 오늘 5개 정도만 해봤는데도, 이 작업은 생각보다 손이 많이 간다는 것을 바로 알 수 있었다.

50개 테스트 계획과 현실

원래는 오늘 Godot 기능 50개를 전부 테스트할 생각이었다.

하지만 실제로 해보니 이상과 현실은 달랐다. 먼저 Godot 3에서 함수 단위나 작은 코드 블록으로 자주 나올 만한 기능 50개 리스트를 만들고, 그 리스트를 문서로 정리했다. 그리고 jsonl + prompt + chunk를 같이 던졌을 때 Qwen이 예 또는 아니오로 근거 매칭을 제대로 판정하는지 보기 위한 프롬프트 템플릿도 써두었다.

처음에는 하나씩 만들고 확인하면 될 것 같았다. 그런데 기능 하나를 테스트하려면 생각보다 만들어야 하는 JSONL이 많았다.

docs_chunks, api_mapping, label_prototypes 세 테이블을 모두 봐야 하고, 각 테이블마다 관련 있는 JSONL과 전혀 관련 없는 JSONL을 따로 만들어야 했다. 여기에 Godot 3과 Godot 4에서 문법이 같은 경우와, 버전별로 달라지는 경우도 나눠야 했다.

공통문법이면 같은 코드 하나를 기준으로 세 테이블의 성공 JSONL과 실패 JSONL을 넣어 검증할 수 있다. 반대로 공통문법이 아니면 Godot 3 코드와 Godot 4 코드를 둘 다 만들어야 한다. 그리고 Godot 3 기준으로 만든 JSONL을 Godot 3 코드에 넣었을 때, Godot 4 코드에 넣었을 때, Godot 4 기준 JSONL을 다시 반대로 넣었을 때까지 비교해야 했다.

결국 오늘은 50개 중 5개 정도만 테스트했다. 처음 계획보다는 훨씬 적지만, 오히려 이 정도에서 멈춘 것이 다행일 수도 있겠다는 생각이 들었다. 50개를 전부 수기로 밀어붙인 뒤에 기준이 애매하다는 사실을 알았다면 훨씬 더 크게 꼬였을 것이다.

공통문법과 버전 기준

오늘 테스트하면서 가장 크게 느낀 것은 Godot 3과 Godot 4를 단순히 둘로 나누기 어렵다는 점이었다.

어떤 기능은 Godot 3과 Godot 4에서 문법이 거의 같다. 이 경우에는 코드 하나만 보고 Godot 3 전용인지 Godot 4 전용인지 억지로 가르는 것이 오히려 이상하다. 공통문법이라면 공통문법으로 보고, 같은 코드에 대해 docs_chunks, api_mapping, label_prototypes의 관련 JSONL과 무관 JSONL이 제대로 갈리는지를 보는 편이 맞다.

반대로 버전 차이가 있는 기능은 더 복잡하다. Godot 3 기준 JSONL을 만들었을 때 Godot 4 코드에서도 예가 나올 수 있고, Godot 4 기준 JSONL을 만들었을 때 Godot 3 코드에서도 일부 필드 때문에 예가 나올 수 있었다. 특히 migration 관련 JSONL은 source와 target이 같이 들어가기 때문에, 단순 문자열 매칭만으로는 결과가 흔들릴 수 있다.

그래서 앞으로는 JSONL을 어떤 기준 버전으로 만들었는지와 검사하는 코드가 어떤 버전인지를 분리해서 기록해야겠다고 느꼈다. 같은 예라도 공통문법이라 자연스러운 예인지, source/target 문자열이 섞여서 나온 애매한 예인지 구분해야 한다.

F1-score식 기록이 필요하다

테스트 결과를 그냥 “성공”이나 “실패”로만 적으면 나중에 패턴을 보기가 어렵다.

오늘 생각한 방향은 F1-score를 바로 계산한다기보다, 나중에 precision과 recall처럼 볼 수 있게 원시 판정 결과를 남기는 것이다. 예를 들어 예가 나와야 하는데 아니오가 나왔는지, 아니오가 나와야 하는데 예가 나왔는지, 공통문법이라 양쪽에서 예가 나오는 것이 맞는지, migration JSONL이라 애매하게 걸린 것인지 따로 기록해야 한다.

이런 식으로 쌓아두면 나중에 프롬프트가 문제인지, JSONL 생성 기준이 문제인지, 테이블별 필드 설계가 문제인지 조금 더 잘 볼 수 있을 것 같다. 반대로 지금처럼 수기로 대충 적어두면 나중에 왜 그 응답이 나왔는지 다시 추적하기가 어려워진다.

오늘 5개만 해도 애매한 지점이 꽤 보였다. 그래서 6번째부터는 테스트 전략을 그대로 밀고 가기보다, 기록 방식과 프롬프팅 전략을 먼저 조금 바꿔야 할 것 같다.

수기 테스트의 한계

직접 프롬프트를 복사하고, 코드 chunk를 붙이고, JSONL을 하나씩 넣고, Qwen 응답을 다시 기록하는 방식은 너무 비효율적이다.

처음 몇 개를 손으로 해보는 것은 기준을 잡는 데 도움이 됐다. 실제로 직접 해보니 기능 하나에도 생각보다 많은 JSONL이 필요하다는 점, 공통문법과 버전 전용 문법을 나눠야 한다는 점, 예와 아니오의 의미가 상황에 따라 달라진다는 점을 알 수 있었다.

하지만 이 방식을 50개 전체에 반복하는 것은 현실적이지 않다. 내가 직접 수기로 넣다 보면 실수도 생길 수 있고, 나중에 결과를 비교하기도 어렵다.

그래서 다음에는 디버깅 도구를 만드는 쪽도 고민하게 됐다. 코드 chunk, 테이블 종류, JSONL 생성 기준 버전, 검사 코드 버전, 기대 응답, 실제 응답을 한 화면에서 넣고, Qwen 호출 결과가 자동으로 기록되는 구조가 있으면 훨씬 낫다. 지금 웹으로 AST와 Retriever 흐름을 확인했던 것처럼, JSONL 매칭 테스트도 GUI나 디버깅 페이지에서 반복할 수 있으면 좋을 것 같다.

Qwen 챗봇 테스트 데이터 생성 고민

오늘 고민한 것은 Qwen 챗봇으로 임의의 테스트 데이터를 만드는 과정이었다.

내가 만들고 싶었던 것은 검증 방식 자체를 흔들어볼 수 있는 작은 데모 셋이었다. 예를 들면 Qwen 챗봇에게 Godot 3 코드 chunk 하나, Godot 4 코드 chunk 하나, 그리고 docs_chunks, api_mapping, label_prototypes 형식에 맞는 관련 JSONL과 무관 JSONL을 만들어달라고 요청하는 방식이다.

문제는 챗봇에게 그냥 “정답 JSONL과 오답 JSONL을 만들어줘”라고 하면 결과가 너무 그럴듯하게 섞일 수 있다는 점이다. 특히 공통문법인지, Godot 3 전용인지, Godot 4 전용인지, migration source와 target이 같이 들어가는지에 따라 예와 아니오가 달라진다. 그래서 임의 데이터를 만들 때도 기준 버전, 검사 코드 버전, 테이블 종류, 기대 응답을 같이 적어야 한다.

오늘 느낀 것은 Qwen 챗봇으로 만드는 임의 테스트 데이터의 생성 방식과 프롬프트를 더 정교하게 잡아야 한다는 점이다. 그래야 이 테스트 안에서도 Qwen이 자기 지식으로 대충 이어붙이는지, 아니면 JSONL 안의 직접 문자열 근거만 보고 판정하는지 확인할 수 있다.

오늘의 결론

오늘은 많은 양을 테스트한 날이라기보다, 리트리버 검색 전략과 Qwen 챗봇 기반 JSONL 매칭 실험이 각각 생각보다 손이 많이 간다는 것을 확인한 날이었다.

나는 처음에 50개 테스트를 다 해볼 수 있을 거라고 생각했다. 하지만 실제로는 5개만 해도 충분히 많은 문제가 보였다. Godot 3과 Godot 4가 완전히 갈라지는 경우도 있지만, 공통문법도 있고, migration JSONL처럼 source와 target이 같이 들어가서 판정이 흔들리는 경우도 있다.

그래서 지금 필요한 것은 테스트 개수를 무작정 늘리는 것이 아니라, 테스트 결과를 제대로 남기는 구조다. JSONL 생성 기준 버전, 검사 코드 버전, 테이블 종류, 기대 응답, 실제 응답, 애매한 이유를 기록해야 한다. 그래야 50개를 다 했을 때도 단순한 감상이 아니라 패턴으로 볼 수 있다.

오늘은 별생각 없이 임의 데이터를 만들어 테스트하면 되겠다고 시작했지만, 결국 Qwen 챗봇으로 테스트 데이터를 만드는 방식, 프롬프트 전략, 그리고 자동 호출되는 디버깅 도구의 필요성까지 보게 됐다. 내일 이후에는 6번째 테스트부터 기준을 조금 바꾸고, 수기로 반복하는 흐름을 줄일 방법을 먼저 잡아봐야겠다.