🤖
2064 in / 1678 out / 3742 total tokens
v2 평가에서 30샘플 100% 달성이 무의미했다는 걸 깨달았다. 생성 AI에 시그널 키워드를 노출한 상태로 테스트 데이터를 만들었으니 편향일 수밖에 없다. 이번 커밋은 두 가지를 동시에 고친다. 역할 분류 시그널의 어휘를 실전 기반으로 재조정하고, 평가 스펙을 v3로 재작성했다.
가장 큰 문제는 debug와 refactor의 경계가 모호했다는 거다. "고쳐줘", "수정해줘" 같은 범용어가 debug에 들어가 있었는데, 실제 사용 패턴을 보면 refactor/feature 요청에서도 똑같이 쓴다. debug 고유 표현인 "무한 루프", "stack trace", "재현" 같은 걸로 교체했다. refactor는 "중복 제거", "공통화", "분리해줘" 같이 실제로 자주 쓰는 표현으로 보강했다.
feature의 negative에서 "원인", "왜"를 뺀 것도 같은 맥락이다. 너무 범용해서 정상적인 feature 요청까지 필터링할 위험이 있었다. 게임 개발할 때도 "이 기능 왜 필요한지 알아?" 같은 논의는 feature 단계에서 자주 나오는 대화다.
평가 스펙 v3는 솔직히 부끄러운 내용이다. v2가 100% 달성이 자랑스러웠는데, 알고 보니 키워드를 미리 알려주고 시험 치는 거랑 같았다. 블라인드 생성 원칙을 명시하고, 목표를 400개에 정답률 65~85%로 현실적으로 잡았다. 게임 밸런싱이랑 비슷하다. 100% 정답률은 과적합이야.
회귀 테스트 30개는 기존처럼 100% 유지했다. 고친 부분이 기존 정상 케이스를 망가뜨리지 않았다는 확인.
typescript // Before: 범용어가 debug와 refactor를 섞어놓음 negative: ['원인', '왜', '에러', '오류', '리뷰']
// After: debug 고유 에러 컨텍스트로 한정 negative: ['에러 원인', '오류', '리뷰']
100% 정확도는 과적합이다. 건강한 평가는 틀릴 수 있는 여지를 인정하는 데서 시작한다.