LLM 평가의 맹점: 우리는 왜 '행동'이 아니라 '지식'만 보는가?

우리가 실제로 측정하고 있는 것

널리 쓰이는 세 가지 벤치마크를 보자. 점수가 아니라, 무엇을 측정하는지에 집중해서.

MMLU: 백과사전 테스트

57개 과목(법학, 의학, 철학 등)의 4지선다 문제. 정답 하나 고르기. 그게 끝이다.

• 측정하는 것: 지식의 폭. 얼마나 많이 암기했는가.
• 놓치는 것: 그 지식을 언제 적용해야 하는지 아는가? 법적 추론이 필요한 상황과 상식으로 충분한 상황을 구분하는가? 자신이 모른다는 걸 인지하는가?

필기시험이다. 붙었다고 운전할 수 있는 건 아니다.

HumanEval: 코딩 면접 문제

함수 시그니처와 docstring을 주고, 본문을 채우게 한다. 주어진 테스트 케이스를 첫 시도에 통과하면 합격이다. pass@1 — 첫 시도 통과율로 측정한다.

• 측정하는 것: 스펙을 한 번에 동작하는 코드로 옮길 수 있는가.
• 놓치는 것: 테스트가 실패하면 어떻게 하는가? 체계적으로 디버깅하는가, 아니면 무작위로 찔러보는가? 기존 코드베이스에 상충하는 패턴이 있다면 알아채는가? 패치 대신 리팩터링이 필요할 때를 아는가?

함수 하나. 시도 한 번. 소프트웨어는 그렇게 만들어지지 않는다.

SWE-bench: 첫 출근 과제

셋 중 가장 현실적이다. 실제 GitHub 이슈와 전체 레포지토리 접근 권한을 주고, 이슈를 해결하는 패치를 만들게 한다. 평가는 이진법이다 — 레포의 테스트 스위트가 통과하느냐 마느냐.

• 측정하는 것: 실제 코드베이스를 탐색하고 실제 버그를 고칠 수 있는가.
• 놓치는 것: 접근 경로에 대한 모든 것. 효율적으로 grep해서 관련 파일을 찾았는가, 아니면 레포 절반을 먼저 읽었는가? 기존 아키텍처를 이해했는가, 아니면 동작은 하지만 모든 설계 패턴을 위반하는 패치를 무식하게 찍어냈는가? 이 이슈에서 배운 것을 다음 이슈에 적용할 수 있는가?

SWE-bench는 목적지를 평가한다. 여정은 평가하지 않는다.

패턴: 셋 다 “첫인상"만 측정한다

이 벤치마크들은 하나의 근본적인 가정을 공유한다: 평가는 단일 세션에서, 단 한 번, 단 하나의 정답을 기준으로 이루어진다.

하지만 실제 AI 코딩 에이전트는 그렇게 동작하지 않는다. 여러 세션에 걸쳐 작업한다. 어제의 실수에서 배운다. 지난주 디버깅 세션의 컨텍스트를 재활용한다. 작업의 질은 무엇을 아는가뿐 아니라 시간에 걸쳐 어떻게 행동하는가에 달려 있다.

이건 지식(knowledge)의 문제가 아니다. 행동(behavior)의 문제다. MMLU-Pro에 더 어려운 문제를 추가한다고 해결될 문제가 아니다.

사람은 행동으로 뽑으면서, LLM은 왜 지식으로만 테스트하는가?

엔지니어 채용 과정을 생각해보자.

GPA를 흘깃 본다. GitHub을 훑어본다. 과제를 줄 수도 있다. 하지만 그 어느 것도 결정적이지 않다.

결정적인 건 면접에서 나온다. 그리고 무엇을 묻는가?

• “작년에 가장 어려웠던 기술적 결정에 대해 말씀해주세요.”
• “동료와 의견이 갈렸을 때 어떻게 해결했는지 설명해주세요.”
• “여기 문제가 있습니다. 답이 아니라 사고 과정을 보여주세요.”

이건 **행동 질문(behavioral question)**이다. 지원자가 무엇을 아는가가 아니라 어떻게 작동하는가를 측정한다. 그리고 이게 통하는 이유는 간단하다 — 과거 행동이 미래 성과를 예측하기 때문이다.

이제 LLM 평가를 보자. 행동 질문이 어디에 있는가?

없다. 우리는 아직 “GPA 확인” 단계에 머물러 있다. 모든 모델이 90퍼센타일을 찍는 걸 보면서, 그게 실제 업무 성과에 대해 뭔가 유용한 정보를 준다고 믿는 척하고 있다.

같은 문제, 완전히 다른 접근

행동 평가가 실제로 어떤 모습인지 보자.

같은 버그 티켓을 세 개의 다른 모델에게 준다. 누가 고쳤는지만 확인하지 말고, 어떻게 접근하는지 관찰하라.

모델 A — 티켓을 읽자마자 즉시 grep으로 관련 코드를 찾는다. 30초 만에 첫 패치가 나온다. 빠르고, 직관적이고, 패턴 매칭형이다. 이 모델은 래피드 프로토타이핑에 적합하다 — 속도와 감이 아키텍처적 엄밀함보다 중요한 환경.

모델 B — 티켓을 먼저 세 개의 하위 작업으로 분해한다. 각각을 독립적으로 재현한 후에야 수정을 시도한다. 체계적이고, 구조적이고, 시스템적이다. 이 모델은 복잡한 아키텍처 작업에 적합하다 — 엣지 케이스 하나 놓치면 몇 주가 날아가는 환경.

모델 C — 먼저 git log에서 유사한 이슈를 검색한다. 코드베이스의 컨벤션을 이해하기 위해 기존 패치를 연구한 후에야 코드를 작성한다. 신중하고, 선례 기반이며, 역사에서 배운다. 이 모델은 유지보수와 버그 수정에 적합하다 — 기존 패턴과의 일관성이 기발한 해결책보다 중요한 환경.

세 모델 모두 버그를 고친다. 점수는 동일하다. 하지만 행동 프로필은 완전히 다르다. 그리고 그 차이가 각 모델이 실제로 어떤 역할에 적합한지를 결정한다.

이게 행동 벤치마크가 측정해야 할 것이다. “문제를 해결했는가"가 아니라 “어떻게 해결했는가” — 그리고 그걸 통해 이 모델이 어디에 속하는지 알려주는 것.

제안: 행동 벤치마크 (Behavioral Benchmarks)

분명히 밝혀둔다: 이것은 제안이지, 완성된 프레임워크가 아니다. 논문을 인용하지 않는 이유는 — 아직 없기 때문이다. (흥미롭게도 2026년 4월 Tang et al.의 프리프린트가 LLM 공정성을 위한 “in-situ behavioral evaluation"을 주장하고 있다 — 이 아이디어가 공중에 떠 있다는 신호다.) 내가 틀렸다면 댓글로 정정해주길 바란다.

내가 작업 중인 정의는 이렇다:

행동 벤치마크(Behavioral Benchmark)란, LLM이 문제에 어떻게 접근하는지 — 그 인지적 패턴을 프로파일링하는 평가 프레임워크다. 답의 정확성만 점수화하지 않는다.

기존 벤치마크가 “몇 개 맞췄는가"를 묻는다면, 행동 벤치마크는 “이 모델은 어떤 사고방식을 가졌는가” 를 묻는다.

네 가지 관찰 차원을 제안한다:

이렇게 생각하면 된다:

• MMLU의 질문: “이 지원자는 무엇을 아는가?”
• 행동 벤치마크의 질문: “이 지원자는 어떻게 일하는가?”
• 그리고 두 번째 질문이 역할 적합성(role fit) 을 결정한다.

왜 지금인가

2026년, 코딩 에이전트는 더 이상 데모가 아니다. 실제 엔지니어링 팀의 일상 도구다. 그리고 팀들은 우리 벤치마크가 답할 수 없는 질문을 던지기 시작했다:

• “레거시 코드베이스 유지보수에는 어떤 모델을 써야 하는가?”
• “주니어 개발자들의 페어 프로그래머로 붙여주려는데, 어떤 모델의 디버깅 스타일이 맞을까?”
• “일관성이 중요하다. 주 단위로 가장 예측 가능한 행동을 보이는 모델은 무엇인가?”

이건 role-fit 질문이다. 채용 질문이다. 그리고 우리는 아직 SAT 점수로 답하고 있다.

더 똑똑한 모델을 향한 경쟁은 무르익고 있다. 다음 프론티어는 더 높은 MMLU 점수가 아니다 — 각 모델이 실제로 어떤 일에 적합한지 이해하는 것이다. 그리고 행동 평가 없이는 거기에 도달할 수 없다.

함께 정의하자

내가 이걸 완벽히 정리했다고 생각하지 않는다. 제안한 네 가지 차원은 출발점이지 목적지가 아니다. 더 나은 축이 있을 수 있다. 프레이밍 자체가 틀렸을 수도 있고, 나보다 똑똑한 누군가가 이미 이 문제를 해결했을 수도 있다.

1. 분해 스타일은 프롬프트의 반영이 아니라 모델의 안정적인 특성이다
2. 회복 행동은 모델을 감싸는 하네스/프레임워크의 영향을 배제하고 측정할 수 있다
3. 세션 간 일관성이 팀 도입에 있어 원시 성능보다 더 중요하다
4. Role-fit 평가가 언젠가 정확도 벤치마크보다 엔터프라이즈 도입에 더 중요한 요소가 될 것이다

코딩 에이전트를 만들고 있거나, 모델을 평가하고 있거나, 그저 “최상위 랭크” LLM이 기대와 다르게 행동해서 답답한 경험이 있다면 — 듣고 싶다. 당신의 팀에서 중요한 행동 차원은 무엇인가?

이 글은 Monet — AI 에이전트가 팀 레벨에서 지식을 공유하고 통제하는 오픈소스 플랫폼 — 을 만들면서 고민한 내용을 바탕으로 한다.

모든 예시와 시나리오는 실제 경험을 블로그 형식에 맞게 각색한 것이다.