새로운 수학 벤치마크, AI 모델이 해결할 수 없는 문제를 자신 있게 해결하는 모습 드러내

SOOHAK은 64명의 수학자 컨소시엄이 직접 손으로 작성한 439개의 연구 수준 수학 문제로 구성된 벤치마크로, 그중 99개는 의도적으로 "풀 수 없는" 문제로 설계되어 있다는 점이 핵심이다. 기존 수학 벤치마크(GSM8K, MATH, AIME 등)가 정답이 존재하는 문제의 정확도만을 측정했다면, SOOHAK은 모델이 "이 문제는 해가 없다" 또는 "조건이 모순된다"는 판단을 내릴 수 있는지를 함께 평가한다. Google의 Gemini 3 Pro가 연구 수준 문제에서 30%로 선두를 차지했지만, 풀 수 없는 문제를 식별하는 능력에서는 어떤 모델도 50%를 넘지 못했다. 이는 LLM이 패턴 매칭과 체인-오브-쏘트(Chain-of-Thought) 추론에는 강하지만, 문제 자체의 유효성(well-posedness)을 메타 인지적으로 검증하는 능력은 여전히 빈약하다는 것을 시사한다. 특히 RLHF로 학습된 모델들은 "모르겠다"고 답하기보다 그럴듯한 답변을 만들어내는 쪽으로 편향되어 있다는 구조적 문제와도 연결된다.

엔지니어 입장에서 이 결과가 중요한 이유는 단순히 수학 영역에 국한되지 않기 때문이다. AI 에이전트가 코드 리뷰, 아키텍처 검토, 요구사항 분석을 수행할 때 "이 명세는 모순된다", "이 API 계약은 구현 불가능하다", "이 버그 리포트는 재현 조건이 빠져 있다"를 판단해야 하는 상황이 빈번하다. SOOHAK이 보여준 패턴—더 많은 컴퓨트를 투입해도 "해결 능력"만 향상되고 "불가능성 인지 능력"은 개선되지 않는 현상—은 그대로 코딩 도메인에도 적용된다. 실제로 Cursor, Copilot, Claude Code 같은 도구들이 잘못된 전제(예: 존재하지 않는 라이브러리 함수, 모순된 타입 시그니처)를 받았을 때 "이건 불가능합니다"라고 말하기보다 환각으로 채워 넣는 경향이 강한 것과 동일한 메커니즘이다.

실무에서 취해야 할 액션은 명확하다. 첫째, AI를 통한 자동화 파이프라인(코드 생성, 테스트 케이스 작성, 문서 분석)을 설계할 때 모델 출력을 "정답일 가능성이 있는 후보"로만 취급하고, 검증 단계(타입 체크, 단위 테스트, 정적 분석, 휴먼 리뷰)를 반드시 직렬로 두어야 한다. 둘째, 프롬프트 엔지니어링 단계에서 "조건이 모순되거나 정보가 부족하면 답변하지 말고 명시적으로 지적하라"는 지시를 강하게 주는 것이 도움이 된다—다만 SOOHAK 결과가 보여주듯 이것만으로는 50% 벽을 넘기 어렵다. 셋째, 모델 평가/선택 시에는 정확도 지표뿐 아니라 abstention rate(답변 거부율)나 calibration(자기 확신도와 실제 정답률의 일치도) 같은 지표를 함께 봐야 한다. 특히 의료·금융·보안 같은 고위험 도메인에 LLM을 통합할 경우, "자신 있게 틀린 답을 내는" 실패 모드가 가장 위험하므로 SOOHAK 같은 벤치마크가 평가 표준에 들어와야 한다는 점을 인지할 필요가 있다.