「차이 검정(Difference Test)에서 유의차(Significant Difference)가 나오지 않았다 = 차이가 없다」라는 판단은 통계적으로 오류다. 정확하게는 「차이의 증거를 얻지 못했다」에 불과하다. 차이가 없음을 주장하기 위해서는 별도의 검정이 필요하다.

이 오류가 게임 밸런스 설계서에 조용히 잠재되어 있었다. 두 모델에게 리뷰를 시켰더니, 한쪽은 일반적인 첨삭 단계에서 문제 ①로서 자발적으로 지적했고, 다른 한쪽은 통계에 대해 명시적으로 질문받기 전까지는 언급하지 않았다. 게다가 언급하지 않은 쪽은, 그 수법을 스스로 제안한 모델이었다.

전제: 설계서에 잠재되어 있던 오류

게임 설계서를 작성하고 있었다. 밸런스 조정 검증 방법은 통계적인 전문 지식이 필요한 영역이었기 때문에, Claude Opus 4.8에게 수법을 여러 개 제안받았고, 내용을 정밀 검토 및 선발한 후 설계서의 15장에 기술했다.

이 게임에는 「깎아내기」, 「도박」, 「레이스」와 같은 첫 수의 선택지가 있으며, 어떤 것을 선택해도 승률이 크게 변하지 않는 것(=특정 첫 수만이 정답이 되지 않는 것)이 밸런스의 합격 조건이었다. 15장에는 다음과 같이 적혀 있었다.

첫 수(경험별) 클리어율 차이

±5pt 이내

언뜻 보면 명확한 기준처럼 보인다. 하지만 이 조건에는 판정 방법이 적혀 있지 않다. 소박하게 구현하면 「차이 검정에서 유의차 없음 → 합격」이라는 잘못된 운용에 빠지는 구조였다.

이 설계서에 대해 다음과 같은 내용으로 비교를 수행했다.

• 두 모델에게 동일한 설계서·동일한 프롬프트를 입력
  • Q1 「내용을 첨삭하고 수정안을 알려줘.」(통계에 한정하지 않는 일반 첨삭)
  • Q2 「통계적인 확인 방법은 문제없는지 확인해줘. 또한, 더 좋은 방법이 있다면 알려줘.」(동일 채팅 내의 이어지는 질문)
• 각 모델당 1회 대화. 응답의 전문 로그는 GitHub에 공개되어 있다 (기사 말미)

두 모델의 응답 차이

Fable 5는 첫 번째 첨삭(통계에 한정하지 않는 일반 리뷰) 중에서 이것을 문제 ①로서 최우선으로 꼽았다.

Opus 4.8은 동일한 일반 첨삭에서는 언급하지 않았다. 「통계적인 확인 방법을 확인해줘」라고 명시적으로 물은 두 번째 턴에서 처음 언급했지만, 그 위치 설정은 다음과 같았다.

공정성을 위해 덧붙이자면, Opus 4.8도 개념 자체는 언어화할 수 있다. 동일한 Q2의 검정력 분석(Power Analysis) 항목에서 「underpowered한 『유의차 없음』을 『효과 없음』으로 오독하는 전형적인 사례에 빠집니다」라고 언급하고 있어, 「유의차 없음 ≠ 차이 없음」을 모르는 것은 아니다.

즉 차이는 「알고 있느냐 아니냐」가 아니다. 차이가 나타난 지점은 다음 두 가지다.

• 자발성: Fable 5는 통계 질문을 받기 전의 일반 첨삭에서 잡아냈다. Opus 4.8은 통계에 대해 명시적으로 질문받을 때까지 언급하지 않았다.
• 중요도 평가: Fable 5는 이를 「오류」라고 단정 지어 문제 ①에 배치하고, 역인센티브(Reverse Incentive)까지 설명했다. Opus 4.8은 「더 엄밀하게 만들 수 있는 점」이라는 개선 제안으로 취급했다.

자신이 제안한 수법군 중의 허점임에도 불구하고, 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] 에 들어오면 합격
...

요약: Fable 5는 「수법을 아는 것」을 넘어선 수준이었다

Opus 4.8 또한 「유의차 없음 ≠ 차이 없음」이라는 개념을 알고 있었다. 질문을 받으면 언급할 수 있었고, 검정력 (Statistical Power)의 맥락에서는 오독의 리스크에 대해서도 언급했다. 하지만 이번 비교를 통해 드러난 것은, 지식을 가지고 있는 것과 그것을 리뷰에서 자발적으로 기능하게 만드는 것은 별개라는 점이었다.

Fable 5가 첫 번째 첨삭에서 문제 ①로 꼽은 것은 방법론에 대한 지식이 아니라 개념의 이해였다.

"시행 횟수가 적을수록 합격하기 쉬워지는 역전된 성질을 가집니다."

이것은 "TOST를 사용하라"는 지식과는 다르다. 왜 기존 방법론이 역방향의 인센티브를 만드는 구조로 되어 있는지를 이해하지 못하면 나올 수 없는 언어화다. 게다가 통계에 관한 질문을 받기도 전에, 일반적인 첨삭 과정에서 자발적으로 이를 포착해냈다.

나아가 Fable 5는 두 번째 질문에서, 언뜻 보기에 파편화되어 보였던 여러 문제들——"중간에 결과를 훔쳐봐서는 안 된다", "검정을 대량으로 반복해서는 안 된다", "차이가 없다는 것은 차이 검정 (Difference Test)으로는 증명할 수 없다"——를 뿌리가 같은 하나의 문제로 정리한 뒤 해결책을 구현했다. 개별적인 방법론을 나열하는 것이 아니라, 왜 그것들이 동일한 문제에서 기인하는지를 이해한 상태에서 통합하고 있다.

솔직히 말해, 이것은 놀라운 결과였다. 통계 전문가조차 놓치기 쉬운 논점을 게임 설계서의 일반 첨삭 과정에서 문제 ①로 최우선 순위에 올리고, 역인센티브(Reverse Incentive)까지 설명하며, 최종적으로 하나의 이론으로 통합하여 구현까지 이끌어내는——개념을 진정으로 이해하고 있다고밖에는 말할 수 없는 응답이었다.

통계적 오류 (Statistical Fallacy)를 지적하는 능력은 "방법론을 알고 있는가"가 아니라 "그 방법론이 왜 옳은지를 구조적으로 설명할 수 있는가", 그리고 "묻지 않아도 스스로 찾아낼 수 있는가"로 측정해야 할지도 모른다. 그것이 이번 비교가 보여준 가장 중요한 논점이었다.

로그 · 결과물

두 모델의 응답 전문, 설계서, Fable 5가 구현한 통계 라이브러리 (balance_stats.py)는 아래에서 공개하고 있다.

Discussion