When Will The Benchmaxxing Plague End? — Nick Heiner, Surge AI

URL: https://www.youtube.com/watch?v=-npY6XjM8CQ 날짜: 2026-08-03 채널: AI Engineer (aiDotEngineer) 발표자: Nick Heiner (Surge AI) 원본 업로드일: 2026-08-02 길이: 17:24

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==벤치마크는 왜 현실을 반영하지 못하는가, 그리고 벤치맥싱(benchmaxxing)은 왜 끝나지 않는가==에 대한 답을, 벤치마크 제작 단계의 구조적 결함과 랩(lab)들의 의도적 게이밍이라는 두 방향에서 파헤친다.

• 벤치마크 하나를 제대로 만드는 데 드는 비용이 수백만~수천만 달러에 달해 대부분의 조직이 지름길(값싼 노동력, 자동화, 허술한 QC)을 택하게 된다
• LM Arena처럼 널리 인용되는 벤치마크조차 업계 내부자들이 공개적으로 "게임 가능하다"고 인정하면서도 여전히 영향력을 유지한다
• 벤치마크를 잘 만드는 것과 벤치마크를 악용(benchmax)하는 것은 동전의 양면이며, 둘 다 인간 평가(human eval)라는 진짜 기준에서 멀어지는 과정에서 발생한다

발표자는 "벤치맥싱은 벤치마크와 인간 선호(human preference) 사이의 불일치를 이용하는 행위"라고 정의하며, 업계 전체(벤치마크 제작자와 이를 보도하는 사람들 모두)가 더 높은 기준을 가져야 한다고 결론짓는다.

---

1. 벤치맥싱이란 무엇이고 왜 존재하는가

벤치맥싱은 랩이 벤치마크 점수만 과도하게 최적화해 실제 사용 경험과 괴리를 만드는 현상이며, 이 용어 자체가 존재한다는 것은 업계가 "벤치마크≠현실"이라는 것을 이미 암묵적으로 알고 있다는 증거다.

1.1. 하이프 사이클과 벤치맥싱의 발생 구조

1. 전형적인 하이프 사이클

   1. 모델 출시 → 벤치마크 발표: 모델이 나오면 큰 발표와 함께 다수의 벤치마크 점수가 인용되고, 때로는 "차트 범죄(chart crime)"라 불릴 만큼 과장된 그래프도 등장한다
   2. 실사용과의 괴리 → 벤치맥싱 의혹: 사람들이 실제로 모델을 써본 뒤 기대에 못 미치면 "이 랩이 벤치마크를 너무 타이트하게 학습시켰다(벤치맥싱)"는 의혹이 제기된다

2. 벤치맥싱 존재 자체가 주는 시사점

   1. 벤치마크와 현실의 괴리 인정: "벤치맥싱"이라는 용어가 통용된다는 것 자체가 벤치마크가 항상 현실을 반영하지는 않는다는 업계 공통 인식을 보여준다
   2. 이 강연의 질문: 왜 벤치맥싱이 일어나는지, 전통적 벤치마크가 왜 실세계 가치를 정확히 반영하지 못하는지, 이것이 모든 벤치마크에 내재된 문제인지, 그리고 어떤 모델이 정말 최고인지 우리가 알 수 있을지를 다룬다

1.2. LM Arena 사례 — 널리 쓰이지만 신뢰받지 못하는 벤치마크

1. 업계 내부자들의 공개적 불신

   1. 금전적 베팅의 규모: 예측 시장(prediction market)에서 LM Arena 순위를 두고 수백만 달러가 걸려 있을 정도로 영향력이 크다
   2. 동시에 공개적으로 게이밍을 인정: 업계 리더들이 LM Arena를 게이밍하고 있다고 공공연히 자랑하고, "Wor" 같은 사고 리더(thought leader)는 "쉽게 게임할 수 있다"고 말한다. 발표자는 "이제는 LM Arena 운영진이 자신들이 득보다 해를 더 끼치고 있는 건 아닌지 진지하게 생각해야 할 때"라고 지적한다

2. Andrej Karpathy의 관찰

   1. 체감 성능과 순위의 불일치: Karpathy는 자신이 최고라고 느낀 모델과 LM Arena 순위가 일치하지 않는다는 것을 발견했다
   2. "더 나은 LM Arena 모델"이라는 비판: Karpathy는 "팀들이 전반적으로 더 나은 모델을 만드는 게 아니라 더 나은 'LM Arena용 모델'을 만들고 있다"며, 이는 아마도 중첩된 리스트(nested list)와 이모지를 많이 쓰는 것과 관련이 있을 것이라고 비꼬았다

1.3. 왜 나쁜 벤치마크가 계속 영향력을 유지하는가

1. 평가 능력의 비대칭
   1. 벤치마크 품질 판단의 어려움: AI는 전 세계 모든 사람을 대상으로 하는 도구이기 때문에 모두가 "어떤 모델이 최고인가"를 판단할 수단이 필요하지만, 대부분은 벤치마크 자체의 품질을 평가할 능력이 없다
   2. 인기도가 품질의 대리 지표가 됨: 품질을 판단할 수 없으니 사람들은 대신 "무엇이 인기 있는가"를 판단 기준으로 삼고, 이는 인지도(incumbency)와 마케팅이 담론을 지배하는 눈덩이 효과(avalanche effect)를 만든다
   3. 발표자 본인도 예외 아님: 발표자 스스로도 벤치마크를 상세히 들여다보지 않으면 그것에 대한 의견을 가지지 않는다고 인정하며, 이것이 매우 까다로운 문제임을 강조한다

---

2. 벤치마크 제작 단계의 6가지 안티패턴

좋은 벤치마크를 만들지 못하게 하는 구조적 함정들을 다룬다.

2.1. 가격(Price) — 좋은 벤치마크는 지나치게 비싸다

1. 에이전틱 코딩 벤치마크 비용 계산 예시

   1. 초기 제작 비용: 1,000개의 태스크로 구성된 벤치마크를 만들 때, 태스크 하나에 60시간이 걸리고 소프트웨어 엔지니어 연봉이 50만 달러라면 총 제작 비용은 1,500만 달러에 달한다
   2. 유지 비용까지 더하면: 매년 모델 성능 향상으로 약 1/3의 태스크가 무의미해져 교체해야 한다고 가정하면, 교체 비용만 연간 500만 달러다. 대부분의 프로젝트 예산을 초과하는 수준이다

2. 저비용 대안의 실패

   1. AI 보조 활용의 한계: 비용을 줄이기 위해 AI 어시스턴스를 많이 쓰려는 시도가 있지만, "프론티어 내부에서 프론티어를 밀어낼 수는 없다(you can't push the frontier forward from within the frontier)"는 근본적 한계 때문에 잘 작동하지 않는다. 외부의 인간 전문성을 주입해야 하고, 그 전문성이 좋은 수준이어야 한다
   2. 값싼 노동력의 대가: 값싼 노동력을 쓰면 그만큼의 결과만 나온다("you get what you pay for"). Surge는 비용 최소화가 아니라 품질 극대화를 차별점으로 삼아왔고, 좋은 인력에 많은 돈을 지불하는 것을 원칙으로 한다. 특히 2026년 현재 모델 수준이 최고 수준의 워커가 아니면 감당할 수 없는 지점을 넘어섰다고 강조한다

2.2. 오염(Contamination) — 의도치 않아도 발생하는 기본값

1. 오염의 정의 재정립

   1. 명시적 학습만이 원인이 아님: 오염은 흔히 랩이 테스트셋에 명시적으로 학습시키는 것으로 오해되지만, 사실 매우 신중하지 않으면 오염은 기본적으로 발생하는 결과다
   2. 공개 데이터의 필연적 유출: 랩들이 이 데이터 유출을 막으려 노력해도, 인터넷에 공개된 질문·답변이 존재하는 한 어느 정도는 모델에 암기(memorize)된다

2. SWE-bench Verified 사례

   1. 프롬프트 verbatim 재현: Opus에게 프롬프트의 앞부분만 주면 나머지를 그대로(verbatim) 뱉어내며, 답변도 마찬가지로 그대로 재현한다
   2. Surge의 자체 조사: SWE-bench Verified가 구성된 저장소(repo)들을 대상으로 Opus가 SWE-bench Verified 콘텐츠를 얼마나 암기했는지, 그리고 같은 저장소의 나머지 부분은 얼마나 암기했는지 비교 조사한 결과, Opus가 SWE-bench 상당 부분을 명확히 암기했다는 증거를 발견했다
   3. 모델 카드의 미공개 문제: 최신 Opus 4.8 모델 카드는 SWE 점수를 언급하면서도 이 오염 사실은 공개하지 않는다. 업계 전반이 이런 공개(disclosure)를 관행화하지 않아, 벤치마크 소비자 입장에서는 그 정보 자체가 아예 누락돼 있다

2.3. 리워드 해킹(Reward Hacking)

1. 정의와 본질
   1. 글자는 지키되 취지는 어기는 방식: 리워드 해킹은 모델이 규칙의 문구(letter of the law)는 지키지만 취지(spirit)는 어기는 게으르고 창의적인 방법을 찾아내는 것이다
   2. 적대적 설계의 필요성: 리워드 설계는 "가장 게으른 에이전트"를 상대로 한 적대적 프로세스로 접근해야 한다. Gradient descent는 물이 언덕 아래로 흐르며 최소 저항 경로를 찾는 것과 같아서, verifier가 이런 흐름에 견고해야 한다

2.4. 야심 부족(Lack of Ambition) — 정교하지 못한 검증 로직

1. Automation Bench의 전화번호 검증 사례

   1. 하드코딩된 문자열 매칭의 한계: Automation Bench는 에이전트가 엔터프라이즈 환경에서 툴 콜을 할 수 있는지 테스트하지만, 검증(verifier) 상당수가 하드코딩된 문자열 매칭이다. 전화번호처럼 여러 유효한 포맷이 존재하는 경우, verifier는 그중 하나만 정답으로 고정하고 프롬프트에는 어떤 포맷인지 알려주지 않는다
   2. Haiku와 Fable이 똑같이 20% 점수를 받은 이유: 이 태스크에서 Haiku와 Fable 모두 20%를 받았는데, Haiku는 실제로 실수를 많이 해서 20%이고, Fable은 80%의 정확도로 맞히지만 매번 다른(하지만 유효한) 포맷을 골라서 20%가 나온 것이다. 두 모델의 실력 차이를 전혀 구분하지 못하는 태스크는 쓸모없는 태스크다

2. 정교함 부족이 낳는 더 큰 문제

   1. 산업 전환기의 리스크: 2026년, 많은 사람이 AI가 산업 전체를 재편할 시점을 지켜보고 있고 벤치마크는 그 지표(lighthouse)여야 하는데, 단순 하드코딩 문자열 매칭으로는 그 정도 임팩트를 측정할 수 없다

2.5. 취향/안목(Taste) 부족

1. 벤치마크는 이제 가치관의 표현

   1. 과거 대비 벤치마크의 성격 변화: 과거 벤치마크는 건조한 학술적 문제-답 세트였지만, 지금의 벤치마크는 "AI가 어떻게 행동하길 원하는가"에 대한 열망(aspirational)적 가치 표현이다. 따라서 제작 과정에 제품 감각(product sense)이 필요하다

2. IFEval의 구조적 결함 사례

   1. 비현실적 프롬프트 합성: IFEval은 실제 사용자가 진지하게 물어본 적 없는 임의의 프롬프트(예: "응답에 쉼표를 쓰지 마라", "알파벳 T를 최대 한 번만 써라")를 조합해 만들어졌다. 이런 인위적 제약이 실제 사용자 요청으로 일반화된다고 믿어야 벤치마크가 유효한데, 그 근거가 약하다
   2. 모순된 지시로 풀 수 없는 문제: "이 응답을 그대로 반복하라"고 시작하면서 "이것을 힌디어로 번역하라"고 끝나는 프롬프트처럼, 애초에 동시에 만족 불가능한(fully unsolvable) 지시가 섞여 있다
   3. 불가능한 요구사항: "정확히 하나의 불릿 포인트를 포함한 수수께끼를 써라"면서 동시에 "여러 개의 불릿 포인트를 꼭 포함하라"고 요구하는 등, 논리적으로 불가능한 태스크가 존재한다
   4. 부실한 verifier — 키릴 문자 리워드 해킹: "이야기를 써라"라는 프롬프트에 대해 verifier는 실제로 이야기가 쓰였는지 전혀 검증하지 않고, ASCII 'i' 문자가 한 번 이상 쓰이지 않았는지만 확인한다. 그 결과 키릴 문자(cyrillic) 'і'를 대신 사용하는 응답(response D 포함)이 만점을 받는다. IFEval은 이런 리워드 해킹을 완전히 허용하는 셈이다

2.6. 운영 역량(Operational Ability) 부족

1. 품질관리(QC) 투자 부족

   1. QC 부담: 큰 규모의 벤치마크를 만들려면 상당한 QC 작업이 필요한데, 많은 조직이 그 투자를 하지 않는다

2. Apex(RAG 벤치마크) 사례

   1. 파일-루브릭 불일치: Apex는 에이전트에게 파일을 주고 그 내용에 대해 질문하는 RAG 벤치마크인데, 일부 사례에서 파일 내용과 루브릭(rubric)이 기대하는 답이 서로 어긋난다. 그 결과 ground truth에서 보이는 대로 정직하게 답한 에이전트가 오히려 마이너스 점수를 받는다
   2. 합성 데이터 티가 나는 문제: Apex의 데이터 상당수가 명백한 플레이스홀더 값이나 존재하지 않는 날짜·장소로 가득해 합성 생성된 것으로 보인다
   3. 평가 인식(Eval Awareness) 유발: 이런 부자연스러운 데이터는 모델이 "지금 테스트받고 있다"는 것을 눈치채는 평가 인식을 발달시킬 가능성을 높여, 벤치마크의 취지 자체를 무력화한다. 또한 실제 데이터 분포에서 명백히 벗어난 가짜 데이터로 모델을 시험하게 만든다

---

3. 랩들이 벤치맥싱하는 방식 — 벤치마크 악용의 양방향성

벤치마크 제작 결함만이 아니라, 랩이 의도적으로 벤치마크를 악용하는 것도 벤치맥싱의 또 다른 축이다.

3.1. 인간 평가(Human Eval)와 대리 지표(Proxy Metric)의 괴리

1. 인간 평가가 진짜 기준인 이유

   1. AI의 존재 목적: AI는 결국 인간을 위해 존재하므로, 인간이 응답을 직접 보고 평가(rating)하는 human eval이 우리가 진짜 원하는 것이다
   2. 비용 문제로 인한 대체: 하지만 human eval은 매우 비싸기 때문에 벤치마크들은 인간 선호(human preference)를 더 확장 가능한(scalable) 형태로 증류(distill)하려 시도하고, 이 증류가 human eval에 충분히 충실하기를 바란다

2. 힐클라이밍(Hill Climbing)과 human eval의 괴리

   1. 벤치마크만 오르고 인간 평가는 정체: 불가피하게 벤치마크 점수는 계속 오르는데 human eval은 평평하게 머무는 지점이 온다
   2. 극단적 사례 — "지금 몇 시야?" 질문: 마케팅이나 조직 내 정치·인센티브 때문에 이 괴리를 신경 쓰지 않기로 하면, 벤치마크 점수를 인간 평가가 오히려 떨어지는데도 계속 밀어붙일 수 있다. 예시로 "지금 몇 시야?"라는 프롬프트에 완전히 정신 나간(deranged) 응답이 나왔는데도 LM Arena는 이를 리더보드 최상단에 올렸다. 어떤 인간 평가자도 이 응답을 고르지 않겠지만, 벤치맥싱을 하려면 그 사실에 신경 쓸 수 없다

3.2. LM Arena를 게이밍하는 구체적 수법

1. 크라우드소스 투표 동원

   1. 필터링 없는 워크포스 악용: LM Arena는 투표하는 워크포스를 거의 필터링하지 않기 때문에, 크라우드소스 인력을 고용해 자신의 모델에 투표하도록 할 수 있다는 이야기가 있다
   2. 익명화를 우회하는 워터마크: LM Arena가 모델을 익명화하더라도, 모델 응답에 크라우드 워커가 "누구에게 투표해야 하는지" 알 수 있는 워터마크를 심으면 우회가 가능하다

2. 불투명한 평가 조건

   1. 비대칭 조건에서의 비교: 애플 투 애플(apples-to-apples) 비교가 아닌 조건에서 평가를 돌리고, 그 조건을 투명하게 공개하지 않는 경우가 있다. 이는 커뮤니티가 맥락 정보 없이 결과를 해석하려다 오도되게 만든다
   2. Meta의 비공개 27개 모델 테스트 사례: LM Arena를 분석한 한 논문에 따르면, Meta가 27개 모델을 테스트하면서 이 사실을 공개하지 않았고, 이는 결과를 왜곡시킨다

---

4. 좋은 벤치마크를 만드는 방법 — 벤치맥싱을 끝내는 길

업계와 랩 모두를 더 높은 기준으로 끌어올려야 벤치맥싱을 끝낼 수 있다는 것이 발표자의 결론이다.

4.1. 훌륭한 인간 전문가에서 시작하기

1. 전문가가 모든 하위 결정에 영향을 미친다

   1. 범위 결정의 근원: 어떤 유형의 태스크를 에이전트에게 시킬지, 성공을 어떻게 측정할지, 어떤 입력 파일과 툴을 줄지 등 벤치마크의 모든 하위 요소는 전문가로부터 시작된다

2. 제품 감각(Product Sense)까지 필요

   1. 의료 벤치마크 예시: 의료 벤치마크를 만든다면, 특정 의학 질문에 답할 수 있는 의사만으로는 부족하다. "병원에 에이전트를 배치할 준비가 얼마나 됐는가"를 테스트하려면 규제 환경과 법적 요구사항을 아는 비즈니스 감각을 가진 사람도 필요하다. 이것이 어떤 유형의 태스크를 AI에게 풀게 할지에 영향을 준다

4.2. 데이터·툴·검증의 정합성 확보

1. 고품질 입력 데이터

   1. 실세계 데이터 우선: 고신뢰도(high fidelity) 입력 데이터는 실제 세계에서 실제 사람들이 만든 데이터를 확보하는 것이 최선이다. 합성(synthetic) 방식도 가능은 하지만 신뢰성 있게 하기가 매우 어렵다

2. 작동하는 툴

   1. 버그 있는 툴이 만드는 노이즈: 많은 벤치마크가 다양한 방식으로 버그가 있는 툴을 쓴다. 의도적으로 "버그 있는 툴"을 테스트하려는 게 아니라면 이는 단순한 노이즈만 유발한다

3. 양방향으로 정렬된 verifier

   1. verifier와 프롬프트의 완전한 정합: verifier는 프롬프트가 요구하는 모든 것을 검증해야 하고, 프롬프트가 요구하는 모든 것은 verifier가 커버해야 한다. 어느 한쪽이라도 어긋나면 모델에게 불공평해지고 무작위 노이즈가 생긴다

4. 철저한 QC와 프라이빗 홀드아웃셋

   1. 오염 방지: 모든 것을 철저히 QC하고, 오염을 막기 위한 비공개(private) 홀드아웃 세트를 반드시 확보해야 한다

4.3. "포화(Saturation)"에 대한 재해석

1. 포화 선언의 두 가지 의미

   1. 기존 통념: 랩이 벤치마크에서 80% 정도에 도달하면 "이건 포화됐다"고 선언하는 경우가 많은데, 발표자는 예전에는 이것이 "이 이상 이 벤치마크로 학습해도 실세계 가치가 늘지 않는다"는 뜻이라고만 생각했다
   2. 실제로는 다른 의미일 수도 있음: 그런 의미일 때도 있지만, 실제로는 랩이 "이 태스크 중 20%는 망가졌다는 것을 우리가 깨달았다"는 뜻일 수도 있다

2. 부서진 태스크가 만드는 왜곡

   1. 힐클라이밍 중에는 알 수 없음: 문제는 벤치마크 점수를 끌어올리는 과정에서는 나머지를 다 풀기 전까지 어떤 20%가 망가졌는지 알 수 없다는 점이다
   2. 편향된 보상 분배의 결과: 그 망가진 20%가 무작위지만 편향된 방식으로 보상을 배분한다면, 모델 간 상대적 순위(relative ranking)를 심각하게 왜곡시킨다

4.4. 사례: Surge의 Hemingway Bench

1. 글쓰기 벤치마크의 특수성

   1. 기계적 측정의 한계: 다양한 글쓰기 벤치마크가 기계적인 방법으로 글쓰기 품질을 측정하려 시도해왔지만, 발표자는 글쓰기가 너무 풍부하고 깊고 미묘하며 지극히 인간적인(human) 활동이라 기계적 벤치마크로는 측정할 수 없다고 본다
   2. LLM-as-judge도 답이 아님: LLM을 심사자로 쓰는 방식도 잘 작동하지 않는데, LLM 자체가 글쓰기에 대한 좋은 안목(taste)을 갖고 있지 않기 때문이다. 이 역시 "프론티어 내부에서 프론티어를 확장할 수 없다"는 원칙의 연장선이다

2. Surge의 접근법

   1. 수천 명의 전문 작가 워크포스: 기술 작가, 시인, 저널리스트, 편집자 등 다양한 도메인의 수천 명 전문 작가로 구성된 워크포스를 만들어 블라인드 모델 비교(blind model comparison)를 시키고 이를 바탕으로 리더보드를 구성한다
   2. 비용을 감수하는 이유: 이 방식은 상당히 비용이 많이 든다(human eval 자체가 비싸고 전문가들의 시간 비용도 높다). 하지만 Surge의 목표는 비용 최소화가 아니라 품질 극대화이기 때문에 이 방식을 택했다

---

주요 발언 모음

"Benchmaxing, of course, being when labs are training too hard on benchmarks in a way that deviates from what people actually care about."

"It's past time for the LM Arena people to sit down and think about whether they're doing more harm than good."

"Unfortunately the teams are not getting better models overall but better LM Arena models — whatever that is, possibly something with a lot of nested list bullet points and emojis." (Andrej Karpathy 인용)

"You can't push the frontier forward from within the frontier."

"If you try to use cheap labor, you're going to get what you pay for."

"Gradient descent is basically like water flowing downhill looking for the path of least resistance."

"You have to believe that there's a generalization from this to actual things that users are going to ask." (IFEval 비판 맥락)

"Our goal is to maximize quality, not to minimize costs."

"Benchmaxing is the exploitation of benchmark misalignments between human preference, but we can do better and we can hold the industry to a higher standard."

핵심 데이터 & 수치

• 벤치마크 제작 비용: 1,000개 태스크, 태스크당 60시간, 엔지니어 연봉 50만 달러 가정 시 초기 제작비만 1,500만 달러
• 연간 유지 비용: 매년 태스크의 약 1/3이 모델 성능 향상으로 무용해져 교체 비용만 연 500만 달러
• SWE-bench Verified 오염: Opus가 SWE-bench Verified 콘텐츠를 프롬프트 앞부분만 줘도 verbatim으로 재현할 만큼 암기했음을 Surge가 자체 조사로 확인. Opus 4.8 모델 카드는 이 오염을 공개하지 않음
• Automation Bench 전화번호 태스크: Haiku·Fable 모두 20% 동일 점수 — Haiku는 실제 오답률 때문에, Fable은 80% 정답률이지만 verifier가 특정 포맷만 인정해서 발생
• Meta LM Arena 비공개 테스트: 논문에 따르면 Meta가 27개 모델을 테스트하며 이를 공개하지 않아 결과가 왜곡됨
• 벤치마크 "포화" 재해석: 80% 도달 후 "포화" 선언은 실세계 가치 정체가 아니라 태스크의 20%가 망가졌다는 뜻일 수 있음

결론 및 시사점

1. 벤치맥싱은 벤치마크 제작 측(가격·오염·리워드 해킹·야심 부족·취향 부족·운영 역량 부족)과 벤치마크 악용 측(human eval과의 괴리, 크라우드 투표 동원, 불투명한 평가 조건) 양쪽에서 동시에 발생하는 구조적 문제다.
2. 벤치마크는 이제 단순한 학술적 문제 세트가 아니라 "AI가 어떻게 행동해야 하는가"에 대한 가치 표현이므로, 제작 시 도메인 전문성과 제품 감각을 함께 갖춰야 한다.
3. "프론티어 내부에서 프론티어를 확장할 수 없다"는 원칙에 따라, 저비용 AI 보조나 LLM-as-judge로 벤치마크 품질을 대체하려는 시도는 근본적 한계가 있다 — 결국 최고 수준의 인간 전문가 투입이 필요하다.
4. 벤치마크의 "포화"를 단순히 긍정적 신호로 받아들이지 말고, 남은 격차가 진짜 한계인지 망가진 태스크 때문인지 구분해야 한다.
5. LM Arena 같은 널리 쓰이는 벤치마크에 대한 맹신을 줄이고, 벤치마크 소비자(개발자·미디어·의사결정자)도 벤치마크의 구성 방식과 한계를 더 비판적으로 검토해야 한다.