• LLM 평가는 아직 "SAT 점수"에 머물러 있다 — MMLU, HumanEval, SWE-bench 모두 단일 세션·단일 정답 패러다임. 실제 코딩 에이전트는 여러 세션에 걸쳐 작업하고, 실수에서 배우고, 기존 컨벤션을 읽는다. 이건 지식(knowledge)이 아니라 행동(behavior)의 문제다.
• 우리는 사람 뽑을 때 학점보다 "어떻게 생각하나"를 본다 — LLM 평가엔 왜 그걸 안 하는가. 지금은 모든 모델이 90퍼센타일을 찍는 "GPA 확인" 단계에 멈춰 있다.
• 같은 버그를 고쳐도 접근 방식은 완전히 다르다 — Model A는 30초 만에 grep해서 패치(프로토타이핑형), Model B는 하위 작업 분해 후 체계적 접근(아키텍처형), Model C는 git log에서 선례 학습 후 수정(유지보수형). 셋 다 버그는 고친다. 점수는 동일하다. 역할 적합성은 완전히 다르다.
• 4가지 행동 관찰 차원 제안 — Decomposition(분해하는가 vs 바로 실행하는가), Approach(패턴을 찾는가 vs 원리에서 추론하는가), Recovery(막혔을 때 전략을 바꾸는가 vs 밀어붙이는가), Consistency(비슷한 문제에 같은 접근을 보이는가).
지식 평가 vs 행동 평가
| 기존 벤치마크 | 측정하는 것 | 놓치는 것 |
|---|---|---|
| MMLU | 지식 암기량 | 적용 판단력, "모르는 것에 대한 인지" |
| HumanEval | 첫 시도 합격률 | 디버깅, 반복, 적응 과정 |
| SWE-bench | 패치 통과 여부 | 접근 경로, 아키텍처 이해, 크로스세션 학습 |
2026년, 진짜 필요한 질문
코딩 에이전트가 데모가 아니라 실제 팀 도구가 된 지금, 우리가 던져야 할 질문은 "몇 점이냐"가 아니다:
- "레거시 유지보수에 어떤 모델이 맞는가"
- "주니어 페어프로그래밍에 어울리는 디버깅 스타일은 무엇인가"
- "주 단위로 가장 예측 가능한 행동을 보이는 모델은 무엇인가"
이건 role-fit 질문이다. 채용 질문이다. 우리는 아직 SAT 점수로 답하고 있다.
프레임워크를 완성형으로 제시하지 않는다. "내가 틀렸다면 정정해달라"는 태도로 4가지 가정을 명시적으로 열어두고 댓글 토론을 유도한다. 2026년 4월 Tang et al.의 "In-Situ Behavioral Evaluation for LLM Fairness" 논문도 유사한 방향성을 제시한다.