AI 벤치마크가 실제 업무의 90%를 놓치는 이유

제 친구 한 명은 중견 물류 회사에서 운영을 맡고 있는데, 지난봄 그녀의 팀은 LLM이 예외 처리 워크플로우를 맡을 수 있는지 3주 동안 평가했습니다. 서로 앙숙인 세 개의 시스템에 걸쳐 구매 주문서(PO)와 맞지 않는 송장을 대조하는, 화려하진 않지만 꼭 필요한 작업이었죠. 벤더의 발표 자료는 인상적인 수치로 가득했습니다. MMLU, GSM8K, HumanEval, 그리고 몇 가지 에이전트 벤치마크까지요. 모델은 그들이 던진 정형화된 테스트를 모두 높은 점수로 통과했습니다. 그런데 실제 한 주치 예외 건을 물리자, 어떤 벤더가 자기 회사 이름을 다르게 줄여 쓴 탓에 14,000달러짜리 송장을 엉뚱한 PO에 자신만만하게 매칭해 버렸습니다. 그 어떤 리더보드도 이런 건 측정하지 않습니다.

그 격차는 이제 측정 가능한 수준이 되었습니다. 최근 공개 AI 벤치마크를 미국 노동부의 O*NET 직업 분류 체계와 대조한 분석(미국 노동을 구성하는 923개 직업, 18,797개 과업 전체)에 따르면, 미국 근무시간의 90%는 벤치마크가 거의 또는 전혀 다루지 않는 과업에 쓰이고 있습니다. 923개 직업 중 과업 하나라도 5개 이상의 벤치마크 프롬프트로 뒷받침되는 직업은 208개뿐입니다. 22개 직업군 중 6개는 아예 하나도 없습니다. 불편한 결론은 AI가 약하다는 게 아닙니다. AI 역량을 재는 도구들이 경제의 거의 엉뚱한 쪽만 겨냥하고 있다는 것입니다.

AI 벤치마크가 실제로 다루는 범위

이 분석의 방법론은 헤드라인보다 훨씬 신중하다는 점에서 이해해 볼 만합니다. 연구진은 고품질이면서 아직 포화되지 않은 에이전트형 벤치마크 29개를 골랐습니다. 질문에 답하는 게 아니라 모델이 실제로 작업을 수행해야 하는 테스트들이죠. 그리고 전문가 검증을 거친 LLM 심사자를 활용해 각 벤치마크 프롬프트가 어떤 O*NET 과업을 연습시키는지 태그를 붙였습니다. 과업 하나에 최소 5개 프롬프트가 매핑되면 '커버됨'으로 간주합니다. 여기에 각 과업이 차지하는 근무 시간 추정치를 결합하면, 우리의 평가 체계가 경제 전체에서 무엇을 볼 수 있는지 한눈에 드러납니다.

보이는 범위는 넓기보다 좁고 길쭉합니다. 소프트웨어 엔지니어링과 금융 분석은 벤치마크로 포화 상태입니다. 트럭 운전, 가스 플랜트 운영, 식음료 서비스, 그리고 의료 현장의 대부분 일상 업무는 사실상 보이지 않습니다. 편향은 기술적으로 자동화 가능한가의 문제만이 아닙니다. 'AI 노출도'가 높은 과업은 낮은 과업보다 벤치마크 대상이 될 확률이 약 6배 높은데, 이건 당연해 보입니다. 하지만 그 영향을 통제하고 나서도, 전체 임금 규모가 큰 직업의 과업들이 여전히 유의미하게 과대대표되었습니다. 변호사의 과업은 촘촘하게 커버되어 있습니다. 반면 비슷한 수준의 AI 노출에 직면한 법률 비서와 법원 서기는 거의 등장하지 않습니다.

다시 한 번 읽어 보세요. 우리는 사람들이 실제로 가진 직무가 아니라 그 직업의 번듯한 버전을 기준으로 AI를 벤치마크하고 있습니다. 근무 시간을 합치면 경제에서 엄청난 비중을 차지하는 중간 소득대 지식 노동의 롱테일, 즉 코디네이터, 사무원, 전문 담당자, 일정 관리자들에 대한 측정 인프라는 거의 없습니다. 누군가 AI가 '지식 노동'의 몇 퍼센트를 할 수 있다고 주장하면, 어떤 지식 노동인지, 어떻게 측정했는지, 어떤 과업 목록에 대해서인지 물어보세요. 정직한 답은 대개 이렇습니다. 연구 논문을 위해 설계된 테스트로 잰, 얇고 대표성 없는 한 조각.

벤치마크 포화는 평가 설계의 실패다

저도 수년간 평가 파이프라인을 만들어 봤는데, 가장 어려웠던 교훈은 이것입니다. 벤치마크는 세계의 모델이고, 대부분의 벤치마크는 형편없는 모델입니다. 복잡하고 맥락적이며 여러 단계로 이루어진 사람의 업무를, 채점하기 쉽다는 이유로 정답 확인이 가능한 깔끔한 프롬프트로 압축해 버리죠. 그다음에는 굿하트의 법칙이 나머지를 처리합니다. 벤치마크가 모델 개발의 목표가 되는 순간, 그것이 원래 대변하려던 역량을 더 이상 측정하지 못하게 됩니다. 학습 데이터가 테스트 분포를 흡수하고, 팀은 리더보드에 맞춰 튜닝하며, 점수는 올라가는데 실제 성능은 제자리걸음을 합니다.

포화는 눈에 보이는 증상일 뿐입니다. 모든 프런티어 모델이 어떤 테스트에서 90% 이상을 기록하면 그 테스트는 더 이상 변별력이 없습니다. 하지만 더 깊은 문제는, 우리가 같은 방식으로, 같은 종류의 과업을 다루는 벤치마크를 또 만들어 대응한다는 데 있습니다. 자동 채점이 가능한 과업을 우리가 잘 알기 때문이죠. 객관식 QA는 더 어려운 객관식 QA를 낳고, 코딩 문제는 더 어려운 코딩 문제를 낳습니다. 그사이 '이 계약서의 면책 조항이 3월의 텀시트와 은밀히 모순된다는 점을 알아채기' 같은 벤치마크는 아무도 만들지 않습니다. 채점하려면 변호사, 시간, 자동화에 저항하는 판단이 필요하기 때문입니다.

그래서 벤치마크 포화가 AI가 어떤 영역을 '해결했다'는 뜻이라는 주장에 저는 동의하지 않습니다. 포화는 측정 도구가 한계에 도달했다는 뜻일 뿐입니다. 40°C에서 눈금이 끝까지 올라간 온도계는 방이 40도라는 것을 증명하지 못하고, 더 나은 온도계가 필요하다는 것을 증명할 뿐입니다. 프로덕션용 모델을 평가하고 있다면, 특히 오류에 실제 비용이 따르는 LLM 기반 의사결정 시스템을 만들고 있다면, 포화된 벤치마크에서 리더보드가 몇 점 오른 것은 의사결정에서 거의 무게를 두지 말아야 합니다.

우리는 우리가 측정하기로 정한 업무에서 모델이 얼마나 잘하는지는 정확히 압니다. 하지만 나머지 90%에 대해서는 거의 아무것도 모릅니다.

AI 평가의 가로등 효과

잃어버린 열쇠를 다른 곳에서 찾다가 결국 가로등 아래에서 찾는 술 취한 사람의 오래된 농담이 있습니다. 열쇠를 거기서 잃어버려서가 아니라, 빛이 거기 있기 때문이죠. 벤치마크 설계도 같은 논리를 따르며, 데이터는 이것이 무작위가 아님을 확인해 줍니다. 분석에 따르면 한 직업 안에서 과업의 중요도가 벤치마크 커버리지를 예측합니다. 해당 직업에서 가장 중요하다고 평가된 O*NET 과업은 가장 덜 중요한 과업보다 6~10배 더 벤치마크 대상이 되기 쉽습니다. 표면적으로는 합리적인 우선순위처럼 들립니다. 하지만 실제로는 대표 과업은 측정하고, 그것들을 잇는 연결 조직은 건너뛴다는 뜻입니다.

모든 직업은 대부분 연결 조직으로 이루어져 있습니다. 소프트웨어 엔지니어의 벤치마크 과업은 '이 테스트들을 통과하는 함수를 구현하라'입니다. 하지만 실제 하루에는 동료가 절반만 끝낸 마이그레이션을 읽고, 어떤 이해관계자가 실제로 결정권을 가졌는지 파악하고, 티켓이 엉뚱한 문제를 설명하고 있다는 것을 알아채는 일이 포함됩니다. 제가 전에 쓴 글에서도 다뤘듯이 에이전트형 코딩 도구의 성패는 바로 이 지점에서 갈립니다. 루프, 컨텍스트, 권한 경계가 순수한 생성 품질보다 훨씬 중요합니다. 이런 것들은 HumanEval 스타일의 점수에는 전혀 드러나지 않습니다.

커버리지 수치 자체에도 미묘한 정의 문제가 있습니다. '커버됨'은 다섯 개 이상의 프롬프트가 과업에 매핑된다는 뜻이지, 다섯 개의 프롬프트가 그 과업을 포착한다는 뜻이 아닙니다. 부모에게 아이 양육 문제를 상담하는 열세 개의 프롬프트는 사회복지사가 담당 사례, 법정, 가정 방문에서 실제로 하는 일을 대표하지 못합니다. 일반인의 '잘 커버됨' 정의를 적용하면, 측정된 경제 비중은 10%가 아니라 사실상 0에 가까울 것입니다. 가로등은 좁을 뿐 아니라, 그 빛 자체가 얇습니다.

모델은 생성하지만, 아무도 판단력을 벤치마크하지 않는다

제가 가장 큰 문제라고 보는 비대칭이 여기 있습니다. 존재하는 거의 모든 벤치마크는 생산을 테스트합니다. 코드를 작성하고, 메모를 쓰고, 문제를 푸는 것이죠. 하지만 실제 과업에서 경제적으로 핵심인 절반은 대부분 탐지입니다. 실수를 잡아내고, 불일치를 짚어내고, 자신 있게 내놓은 답이 틀렸다는 것을 아는 일이죠. 신입 회계사의 가치는 대사를 만드는 데 있는 게 아니라 숫자가 뭔가 이상하다는 것을 알아채는 데 있습니다. 벤치마크는 이걸 거의 테스트하지 않습니다. 채점 가능한 오류 탐지 과업을 만드는 게 채점 가능한 생성 과업을 만드는 것보다 훨씬 어렵기 때문입니다. 현실적인 결함 있는 산출물, 그럴듯하지만 틀린 미묘함, 무엇을 잡아낸 것으로 볼지에 대한 사람들 간의 합의가 필요하니까요.

이것은 평가 설계에 적용한 도어맨의 오류입니다. 도어맨을 자동문으로 바꾸면, 너무 늦게 깨닫게 됩니다. 도어맨은 입주자를 맞이하고, 택배를 받고, 거리를 지켜보기도 했다는 것을요. 직무의 벤치마크된 부분만 자동화하면, 벤치마크되지 않은 부분이 실은 구조를 떠받치고 있었다는 것을 알게 됩니다. 제 물류 회사 친구의 모델은 훌륭한 대사 노트, 즉 눈에 보이는 과업은 써낼 수 있었지만, 대사를 가치 있게 만드는 판단, 즉 매칭은 조용히 망쳤습니다. 평가 스위트는 요리가 아니라 고명을 채점했고, 요리 자체는 무시했습니다.

오류 탐지가 1급 벤치마크 대우를 받기 전까지는, 데모 성능과 실제 배포 성능 사이의 지속적인 격차를 예상해야 합니다. 이건 명세가 말하는 것과 구현이 하는 것 사이의 격차와 같습니다. 소프트웨어에서와 마찬가지로, 실패는 바로 그 격차에서 자랍니다. 90번째 백분위로 생성하고 30번째 백분위로 검증하는 모델은, 실제 운영에서는 타이핑 속도가 빠른 30번째 백분위 직원일 뿐입니다.

실제 과업 분포에 맞춰 평가에 가중치 두기

벤치마크 매핑 연구에서 가장 실용적인 아이디어는 또한 가장 단순합니다. 벤치마크가 일부 과업을 과대대표한다면, 프롬프트 전체에 대해 평균 내는 것을 멈추고, 각 과업이 실제로 차지하는 근무 시간으로 가중치를 두어 과업 단위로 평균을 내라는 것입니다. '금융 분석가'로 태그된 모든 프롬프트를 단순 평균하면, 우연히 벤치마크 프롬프트가 가장 많은 과업, 보통 데이터셋을 만들기 가장 쉬웠던 과업이 결과를 지배합니다. O*NET 가중 평균은 실제 각 과업에 동등한 무게를 줍니다. 그 차이는 극적일 수 있습니다.

import pandas as pd
# The tasks an occupation actually performs, with time shares
# (from O*NET, your own ticket logs, or time-tracking data)
tasks = pd.DataFrame({
"task": ["draft contract", "advise client", "review filing", "coordinate closing"],
"time_share": [0.30, 0.25, 0.35, 0.10],
})
# Model results: one row per eval prompt, mapped to the task it exercises
results = pd.DataFrame({
"prompt_id": ["p1", "p2", "p3", "p4", "p5"],
"task": ["draft contract", "draft contract", "draft contract",
"review filing", "coordinate closing"],
"score": [0.92, 0.88, 0.95, 0.61, 0.40],
})
# Naive: flat average over prompts. Drafting has 3 of 5 prompts,
# so the score is dominated by the model's best task.
naive = results["score"].mean()  # 0.752
# Task-weighted: average within each task first, then weight by
# the share of working hours that task consumes.
per_task = results.groupby("task")["score"].mean()
weights = tasks.set_index("task")["time_share"]
weighted = (per_task * weights).sum() / weights[per_task.index].sum()
# 0.30*0.917 + 0.35*0.61 + 0.10*0.40, over covered time (0.75) = 0.705
# vs naive 0.752 — and 'advise client' (25% of the job) has no data at all

그 스니펫에서 두 가지를 눈여겨보세요. 첫째, 가중 점수가 떨어지는 이유는 모델의 가장 약한 과업이 프롬프트 풀에서 과소대표되었기 때문입니다. 단순 평균이 가려 버리는 바로 그 왜곡이죠. 둘째, 더 중요한 점은 '고객 자문'이라는 과업이 계산에서 완전히 사라졌다는 것입니다. 이를 매핑하는 프롬프트가 하나도 없기 때문이죠. 어떤 가중 방식이든 커버리지가 0인 과업은 조용히 빠뜨리게 되는데, 경제 대부분에서 커버리지 0이 일반적입니다. 가중치 문제는 가중치로 고칠 수 있지만, 데이터 누락 문제는 고칠 수 없습니다. 그건 오래된 평가를 다시 평균 내는 것이 아니라 새로운 평가를 만들어야 해결됩니다.

실제 하는 일을 기준으로 AI를 평가하는 법

모델을 고르거나 배포하고 있다면, 경제 전체의 커버리지 격차는 구체적인 의미를 갖습니다. 여러분이 우연히 벤치마크가 측정하는 작고 밝은 귀퉁이에 있지 않다면, 공개 벤치마크는 여러분의 사용 사례에 대한 약한 사전 정보에 불과합니다. 그러니 자신만의 귀퉁이를 직접 만드세요. 생각보다 영웅적인 일은 아니고, 벤더의 발표 자료를 믿는 것보다 훨씬 낫습니다.

• 상상이 아니라 로그에서 과업을 샘플링하세요. 실제 티켓, 이메일, 예외 건을 일주일 치 뽑아 빈도별로 샘플링하세요. 평가 세트는 여러분 업무량의 히스토그램처럼 보여야 하며, 지루한 롱테일까지 포함해야 합니다. 그 지루한 롱테일이 업무의 대부분이니까요.
• 시간이나 비용으로 가중한 뒤 두 수치를 모두 보고하세요. 단순 평균과 가중 평균은 진실을 양쪽에서 감싸 줍니다. 모델이 단순 평균에서는 이기고 가중 평균에서는 지면, 테스트하기 쉬운 과업에만 강하다는 뜻이며, 여러분이 걸러내고자 하는 바로 그 실패 양상입니다.
• 검증 과업을 포함하세요. 실제 산출물을 가져오되, 이미 알려진 불량품까지 포함해서, 심어 둔 오류와 자연 발생 오류를 잡아내는지 모델을 채점하세요. 제 경험상 탐지 능력과 생성 능력은 거의 상관이 없으며, 여러분이 실제로 돈을 주고 사는 것은 탐지 능력입니다.
• 비공개 세트를 따로 두고 주기적으로 갱신하세요. 몇 달 동안 재사용하는 평가는, 누군가 프롬프트를 그것에 맞춰 튜닝하기 시작하는 순간 의도치 않게라도 학습 대상이 됩니다. 분기마다 케이스를 교체하세요.
• 가능하면 종단간(end-to-end) 결과로 채점하세요. 과업이 '이 송장을 대조하라'라면, 중간 산문이 아니라 대조 결과를 채점하세요. 중간 지표는 통합 테스트 없이 단위 테스트만 있는 코드를 과대평가하듯, 모델을 과대평가하게 만듭니다.

마지막으로, 매일 AI 코딩 도구를 쓰는 사람이라면 알아볼 만한 조용한 효과를 짚어 두고 싶습니다. 바로 마이크로 스케일의 보몰 비용병입니다. 생성이 스무 배 빨라지면, 하루를 생성하는 데 쓰지 않습니다. 빨라지지 않은 부분, 즉 검토, 조율, 검증, 결정에 시간을 씁니다. 벤치마크되지 않은 나머지는 AI가 나아진다고 줄어들지 않고, 확보된 시간을 채우며 커집니다. 그리고 AI를 배포할 가치가 있었는지를 결정하는 요소에서 점점 더 큰 몫이 됩니다. 자동화 가능한 부분을 점점 더 정밀하게 재면서 나머지를 무시하는 것은 단순히 불완전한 게 아닙니다. 중요한 것을 거꾸로 뒤집어 버립니다.

이 모든 것이 AI 발전이 가짜라는 주장은 아닙니다. 역량 향상은 실제이고, 저도 그것에 프로젝트를 걸어 왔습니다. 다만 우리의 측정 문화가 잘못된 분포를 겨냥하고 있다는 주장입니다. 벤치마크는 프롬프트를 쓰고 채점하기 쉬운 곳, 즉 코드, 수학, 시험형 지식에서 만들어졌습니다. 경제는 대부분 그렇지 않습니다. 평가가 따라잡기 전까지는, AI의 모든 헤드라인 역량 주장을 지도의 밝은 10%에 대한 진술로 받아들이고, 여러분 자신의 어두운 90%를 다루는 평가를 만드세요. 이 지루하고 화려하지 않은 측정 작업을 하는 조직이 리더보드를 새로고침하는 모든 이보다 더 나은 배포 결정을 내릴 것이고, 그 차이는 근소하지 않을 것입니다.