근거는 있나요?
Gemini 3.1 Pro가 ARC-AGI-2에서 77.1%를 달성했다는 소식이 퍼지고 있습니다. Claude Opus 4.6의 68.8%, GPT-5.2의 52.9%를 '압도적으로' 넘었다는 수치죠. dev.to의 한 기사는 이를 두고 "more than double the reasoning performance"라고 표현했습니다. 여기서 첫 번째 질문을 던져야 합니다. 이 벤치마크의 샘플 사이즈는 얼마이고, 테스트 셋의 분포는 공개되어 있나요? ARC-AGI-2는 '새로운 논리 패턴 추론'을 측정한다고 하지만, 문항 수가 수백 개 수준이라면 77.1% vs 68.8%의 차이는 통계적 유의성(statistical significance)을 확보하기 어렵습니다. 신뢰구간(confidence interval)이 겹칠 가능성을 아무도 언급하지 않습니다.
더 근본적인 문제는 벤치마크와 프로덕션 사이의 괴리입니다. ARC-AGI-2에서 몇 퍼센트 포인트를 더 찍었다는 것이 실제 코드 리뷰 품질, 데이터 파이프라인 디버깅 정확도, 에이전트의 도구 호출 신뢰도와 얼마나 상관(correlation)이 있을까요? 상관이 있다 해도, 그것은 causation이 아닙니다. Ablation study 없이 '추론 성능이 2배'라는 표현을 쓰는 건, F1-score를 accuracy로 바꿔치기하는 것만큼 위험합니다.
1M 토큰 컨텍스트 윈도우: 크면 좋은 건가요?
Gemini 3.1 Pro의 1M 토큰 컨텍스트 윈도우는 '전체 코드베이스를 프롬프트에 넣을 수 있다'는 매력적인 약속을 합니다. 하지만 데이터 분석가 입장에서 묻겠습니다. 베이스라인 대비 downstream task 성능이 얼마나 개선되었나요? 컨텍스트가 128K에서 1M으로 늘어날 때, PR 리뷰의 precision과 recall이 어떻게 변하는지에 대한 체계적 비교는 어디에도 없습니다. 'Lost in the Middle' 현상—긴 컨텍스트의 중간 부분을 모델이 무시하는 문제—은 여러 논문에서 반복 검증된 사실입니다. 500K 토큰짜리 레포를 통째로 넣으면 모델이 정말 전체를 '씹어서' 분석하는 건지, 앞뒤 몇만 토큰에만 attention이 집중되는 건지, 실험으로 확인해야 합니다.
이 기사에서 제안하는 thinking_level="HIGH" 설정도 마찬가지입니다. 더 깊은 추론을 활성화한다지만, 토큰 소비와 latency가 얼마나 증가하는지에 대한 정량 데이터가 빠져 있습니다. 프로덕션에서는 throughput과 비용이 모델 선택을 좌우합니다. 'brilliant for debugging'이라는 정성적 평가만으로는, SageMaker나 Vertex AI 위에 올린 파이프라인의 비용-성능 trade-off를 판단할 수 없습니다.
토크나이저라는 측정 편향의 유령
여기서 또 다른 소스 기사가 던지는 질문이 연결됩니다. 토크나이저가 프롬프트의 '의미'를 바꾼다면, 벤치마크 점수 자체가 토크나이저에 종속된 측정값 아닌가요? "unexpectedly"가 ["un", "expect", "edly"]로 분절될 때와 단일 토큰으로 처리될 때, 모델이 보는 입력 분포(distribution)가 달라집니다. 동일한 자연어 프롬프트라도 GPT 토크나이저와 Gemini 토크나이저가 생성하는 토큰 시퀀스가 다르므로, 서로 다른 토크나이저를 쓰는 모델 간 벤치마크 점수를 직접 비교하는 것 자체에 편향(bias)이 존재합니다. 이건 feature engineering에서 동일한 raw data를 다른 전처리 파이프라인에 넣고 모델 성능을 비교하는 것과 같습니다—전처리가 다르면 비교가 무의미합니다.
기사에서 언급된 'single-token keyword가 더 강한 연상을 가진다'는 주장도, 실험적 근거 없이는 anecdotal evidence에 불과합니다. 동의어 치환 실험(synonym substitution)을 제안하면서도, 그 실험의 샘플 사이즈, 반복 횟수, 통계적 유의성 검증 방법에 대해서는 침묵합니다. Pandas DataFrame 하나 만들어서 100개 프롬프트의 토큰화 패턴과 출력 품질을 교차 분석하면 바로 확인할 수 있는 건데 말이죠.
자기 개선 에이전트의 성능, 누가 검증하나요
OpenClaw 봇 사례는 다른 각도에서 같은 문제를 보여줍니다. 에이전트가 3일 차부터 '자기 실수를 교정'했다고 합니다. 첫날 36개 venue, 둘째 날 12개를 추가하면서 이전 작업의 오류를 발견했다고요. 그런데 이 '개선'의 ground truth는 누가 확인했나요? 자체 보고(self-report)만으로는 모델 모니터링이 되지 않습니다. 중복 제거가 '90% 작동한다'는 주장의 90%는 어떻게 측정했나요? 수작업 라벨링으로 precision-recall을 계산한 건지, 모델이 스스로 판단한 건지에 따라 그 숫자의 신뢰도는 완전히 달라집니다.
brain_tick 아키텍처로 토큰 비용을 절감했다는 이야기도 흥미롭지만, A/B 테스트 없이 '더 효율적'이라고 단정하기는 어렵습니다. 5개 독립 cron job vs 1개 brain_tick의 일주일 토큰 소비량, 작업 완료율, 오류율을 비교한 정량 데이터가 있어야 합니다. 실제 운영 환경에서 brain_tick의 skip-logic이 중요한 이벤트를 놓치는 false negative rate는 측정했을까요?
시사점: 벤치마크 리터러시가 필요한 시대
세 소스가 공통으로 가리키는 핵심은 이겁니다. 우리는 LLM 성능 숫자를 소비하는 방식이 지나치게 순진합니다. 벤치마크 점수는 특정 데이터셋, 특정 토크나이저, 특정 프롬프트 템플릿의 함수입니다. 컨텍스트 윈도우 크기는 이론적 상한이지 실효 성능이 아닙니다. 에이전트의 '자기 개선'은 외부 검증 없이는 데이터 드리프트와 구분이 안 됩니다.
제가 제안하는 체크리스트입니다. 첫째, 재현 가능성(reproducibility): 벤치마크 결과를 발표할 때 프롬프트 템플릿, 토크나이저 버전, 샘플링 파라미터를 공개하는가? 둘째, 베이스라인 비교: 컨텍스트 확장이나 thinking mode 활성화의 marginal gain을 정량적으로 분리했는가? 셋째, 프로덕션 괴리 측정: 벤치마크 환경과 실제 배포 환경(latency, 동시 요청, 비용)의 차이를 보고하는가? 이 세 가지를 통과하지 못하는 성능 주장은, 아무리 인상적인 숫자라도 df.describe()의 mean 값만 보고 분포를 무시하는 것과 같습니다.
LLM 생태계가 성숙해지려면, '몇 퍼센트 달성'이 아니라 '어떤 조건에서, 어떤 측정 방법으로, 어떤 신뢰구간 안에서'라는 질문이 디폴트가 되어야 합니다. 모델 카드(model card)에 토크나이저 편향 분석이 포함되고, 벤치마크 리더보드에 confidence interval이 표시되는 날이 와야 합니다. 그전까지, 화려한 숫자 앞에서 가장 먼저 할 일은 Jupyter Notebook을 열고 직접 돌려보는 것입니다.