Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
Claude Fable 5와 Opus 4.8을 대상으로 게임 설계서 리뷰 성능을 비교한 실험 결과입니다. Fable 5는 통계적 오류를 자발적이고 우선적으로 지적한 반면, Opus 4.8은 명시적 질문 후에야 개선 사항으로 언급하는 차이를 보였습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기「차이 검정(Difference Test)에서 유의차(Significant Difference)가 나오지 않았다 = 차이가 없다」라는 판단은 통계적으로 오류다. 정확하게는 「차이의 증거를 얻지 못했다」에 불과하다. 차이가 없음을 주장하기 위해서는 별도의 검정이 필요하다.
이 오류가 게임 밸런스 설계서에 조용히 잠재되어 있었다. 두 모델에게 리뷰를 시켰더니, 한쪽은 일반적인 첨삭 단계에서 문제 ①로서 자발적으로 지적했고, 다른 한쪽은 통계에 대해 명시적으로 질문받기 전까지는 언급하지 않았다. 게다가 언급하지 않은 쪽은, 그 수법을 스스로 제안한 모델이었다.
게임 설계서를 작성하고 있었다. 밸런스 조정 검증 방법은 통계적인 전문 지식이 필요한 영역이었기 때문에, Claude Opus 4.8에게 수법을 여러 개 제안받았고, 내용을 정밀 검토 및 선발한 후 설계서의 15장에 기술했다.
이 게임에는 「깎아내기」, 「도박」, 「레이스」와 같은 첫 수의 선택지가 있으며, 어떤 것을 선택해도 승률이 크게 변하지 않는 것(=특정 첫 수만이 정답이 되지 않는 것)이 밸런스의 합격 조건이었다. 15장에는 다음과 같이 적혀 있었다.
첫 수(경험별) 클리어율 차이
±5pt 이내
언뜻 보면 명확한 기준처럼 보인다. 하지만 이 조건에는 판정 방법이 적혀 있지 않다. 소박하게 구현하면 「차이 검정에서 유의차 없음 → 합격」이라는 잘못된 운용에 빠지는 구조였다.
이 설계서에 대해 다음과 같은 내용으로 비교를 수행했다.
Fable 5는 첫 번째 첨삭(통계에 한정하지 않는 일반 리뷰) 중에서 이것을 문제 ①로서 최우선으로 꼽았다.
Opus 4.8은 동일한 일반 첨삭에서는 언급하지 않았다. 「통계적인 확인 방법을 확인해줘」라고 명시적으로 물은 두 번째 턴에서 처음 언급했지만, 그 위치 설정은 다음과 같았다.
공정성을 위해 덧붙이자면, Opus 4.8도 개념 자체는 언어화할 수 있다. 동일한 Q2의 검정력 분석(Power Analysis) 항목에서 「underpowered한 『유의차 없음』을 『효과 없음』으로 오독하는 전형적인 사례에 빠집니다」라고 언급하고 있어, 「유의차 없음 ≠ 차이 없음」을 모르는 것은 아니다.
즉 차이는 「알고 있느냐 아니냐」가 아니다. 차이가 나타난 지점은 다음 두 가지다.
자신이 제안한 수법군 중의 허점임에도 불구하고, Opus 4.8의 리뷰에서는 그것이 「개선점」 수준에 그쳤다 —— 이 온도 차이가 이번 비교에서 가장 흥미로운 점이었다.
통상적인 검정은 비대칭적인 구조를 가지고 있다. 「차이가 있다」라는 가설을 기각할 수 있는지 여부를 조사하는 도구이지, 「차이가 없다」를 적극적으로 증명하는 도구가 아니다.
p > 0.05가 의미하는 것은 「차이가 있다고 말할 수 없다」일 뿐이다. 「차이가 없다」라고 말하는 것이 아니다.
이 비대칭성이 실무에서 까다로운 「역방향 인센티브」를 낳는다. 시행 횟수가 적을수록 정말 차이가 있어도 검정은 놓치기 쉬워진다 (검정력의 저하). 「차이의 증거가 나오지 않았다 = 차이 없음」이라고 판정하는 설계에서는, 이 놓침이 그대로 「합격」으로 카운트된다. 즉 손을 빼서 시뮬레이션 횟수를 줄일수록 합격하기 쉬워진다. 이것이 Fable 5가 말하는 「역전된 성질」이다.
차이가 없음을 주장하고 싶다면 「동등성 검정 (TOST, Two One-Sided Tests)」이 필요하다.
메커니즘은 심플하다. 「차이의 신뢰 구간(Confidence Interval)이 [-5%, +5%] 범위에 완전히 들어왔을 때, 비로소 차이가 없다고 말할 수 있다」라는 조건을 부과한다.
시행 횟수를 늘릴수록 신뢰 구간이 좁아져 범위 내에 들어오기 쉬워진다. 시행 횟수를 늘릴수록 합격하기 쉬워진다 —— 올바른 방향의 인센티브다.
# balance_stats.py 보다 (이번 실험의 결과물)
# paired_compare 의 TOST 부분의 이미지
# 차이의 90% CI 가 [-tost_margin, +tost_margin] 에 들어오면 합격
...
Opus 4.8 또한 「유의차 없음 ≠ 차이 없음」이라는 개념을 알고 있었다. 질문을 받으면 언급할 수 있었고, 검정력 (Statistical Power)의 맥락에서는 오독의 리스크에 대해서도 언급했다. 하지만 이번 비교를 통해 드러난 것은, 지식을 가지고 있는 것과 그것을 리뷰에서 자발적으로 기능하게 만드는 것은 별개라는 점이었다.
Fable 5가 첫 번째 첨삭에서 문제 ①로 꼽은 것은 방법론에 대한 지식이 아니라 개념의 이해였다.
"시행 횟수가 적을수록 합격하기 쉬워지는 역전된 성질을 가집니다."
이것은 "TOST를 사용하라"는 지식과는 다르다. 왜 기존 방법론이 역방향의 인센티브를 만드는 구조로 되어 있는지를 이해하지 못하면 나올 수 없는 언어화다. 게다가 통계에 관한 질문을 받기도 전에, 일반적인 첨삭 과정에서 자발적으로 이를 포착해냈다.
나아가 Fable 5는 두 번째 질문에서, 언뜻 보기에 파편화되어 보였던 여러 문제들——"중간에 결과를 훔쳐봐서는 안 된다", "검정을 대량으로 반복해서는 안 된다", "차이가 없다는 것은 차이 검정 (Difference Test)으로는 증명할 수 없다"——를 뿌리가 같은 하나의 문제로 정리한 뒤 해결책을 구현했다. 개별적인 방법론을 나열하는 것이 아니라, 왜 그것들이 동일한 문제에서 기인하는지를 이해한 상태에서 통합하고 있다.
솔직히 말해, 이것은 놀라운 결과였다. 통계 전문가조차 놓치기 쉬운 논점을 게임 설계서의 일반 첨삭 과정에서 문제 ①로 최우선 순위에 올리고, 역인센티브(Reverse Incentive)까지 설명하며, 최종적으로 하나의 이론으로 통합하여 구현까지 이끌어내는——개념을 진정으로 이해하고 있다고밖에는 말할 수 없는 응답이었다.
통계적 오류 (Statistical Fallacy)를 지적하는 능력은 "방법론을 알고 있는가"가 아니라 "그 방법론이 왜 옳은지를 구조적으로 설명할 수 있는가", 그리고 "묻지 않아도 스스로 찾아낼 수 있는가"로 측정해야 할지도 모른다. 그것이 이번 비교가 보여준 가장 중요한 논점이었다.
두 모델의 응답 전문, 설계서, Fable 5가 구현한 통계 라이브러리 (balance_stats.py)는 아래에서 공개하고 있다.
