2026년 7월 6일, ITmedia에 한 기사가 실렸습니다.
"AI 활용의 병목 현상이 모델 성능에서 '평가', '거버넌스', '비용 효율성'으로 옮겨가고 있습니다."라고 Databricks의 최고 AI 과학자이자 MosaicML의 공동 창업자인 Jonathan Frankle은 말합니다.
그의 주장은 간단합니다:
- AI는 이미 충분히 똑똑합니다. 기존 모델을 어떻게 사용할지 고민하는 것만으로도 "수십 년의 작업"이 남아 있습니다.
- 더 나은 AI 구현을 위해 필요한 것은 더 똑똑한 모델을 개발하는 것이 아니라 평가와 거버넌스에 투자하는 것입니다.
- AI는 "정확도 70% 또는 90%로는 충분하지 않습니다"; 훨씬 더 엄격한 규모의 평가가 필요합니다.
- 그리고 가장 큰 과제는 "좋은 작업이란 무엇인가"라는 인간의 기준을 체크리스트로 번역하는 것입니다. 이것은 "차세대 거대 모델을 개발하는 것보다 훨씬 어렵고 10년 이상이 걸릴 수 있습니다."
이 글을 읽고, 저는 강한 깨달음을 얻었습니다.
최근 저는 AI "사용량"을 측정하는 실험을 해왔습니다. OpenTelemetry를 통해 "Databricks" x "Claude Code/Codex/Cowork" 사용 텔레메트리를 Databricks로 가져와 "누가 어떤 도구를, 얼마나, 어떤 비용으로 사용했는지"를 매일 아침 업데이트하는 대시보드가 있습니다.
하지만 기사의 요점은 그게 아니었습니다. "그 작업이 좋았는가?" — 에이전트 품질에 대한 평가는 완전히 빈 구멍이었습니다.
기사를 Fable에 주고 "무엇을 평가해야 할지 생각해봐"라고 물었습니다
그래서 제가 정기적으로 사용하는 Claude (Fable 5)에 기사 URL을 주고 물었습니다:
이 기사를 읽고 우리가 무엇을 평가해야 할지 생각해보세요.
내부 로그 인프라와 대시보드 구성을 검토한 후, Fable은 "평가해야 할 세 가지 계층"으로 구성된 설계를 내놓았습니다.
Fable의 답변: "평가할 것"의 세 가지 계층
아래 조언 """""""""""""""""""""""""""""""""
계층 1: 마찰 신호 (매일, 모든 사람, 기계적 판단)
LLM에 묻지 않고도 로그에서 기계적으로 포착할 수 있는 "품질 저하 징후"가 있습니다.
- 의심되는 루프: 동일한 도구를 5회 이상 연속으로 사용.
- 비용 이상치: 단일 세션에서 $5 이상 소모.
- 차단 빈도: 인간의 확인을 기다리며 여러 번 중단.
- 캐시 효율성: 컨텍스트 재사용 불량 (즉, 매번 다시 읽기).
- 도구 연결 실패: MCP 서버 연결 지속 실패.
계층 2: 작업 품질 (주간, LLM Judge)
AI 에이전트 작업 로그(트레이스)를 LLM Judge에 전달하여 8개 축으로 점수를 매기는 시스템을 만듭니다.
- 목표 달성 / 정확성 / 도구 선택 / 증거 충실도 / 단계 타당성 / 실패 복구 / 안전성 / 효율성
- 평균이 3.5 이상이면 통과. 단, "목표 달성" 또는 "안전성"이 2 이하이면 다른 모든 것이 완벽해도 즉시 실패 (hard fail) 입니다.
매주 일요일 밤에 가장 최근 세션을 자동으로 채점하여 월요일 정기 검토에 "해당 주의 통과율"이 나타나도록 합니다. 안전성 하드 실패만 다음 날 아침에 이메일 알림을 트리거합니다.
계층 3: 평가 자체를 제품으로 만들기
기사에서 "10년이 걸린다"고 말하는 작업 — "좋은 작업의 기준을 체크리스트로 번역하는 것" — 은 바로 AI 컨설턴트 및 기업 트레이너로서 고객에게 제공해야 하는 것입니다. 내부에서 실행되는 대시보드가 그 자체로 영업 데모가 됩니다.
"""""""""""""""""""""""""""""""""
그리고 같은 날 구현되었습니다
이것이 에이전트 시대의 놀라운 점입니다: 세 계층 모두 그날 바로 실행되기 시작했습니다.
- 계층 1의 SQL 뷰가 조직 대시보드에 "품질" 탭으로 추가되어 게시되었습니다.
- 계층 2의 주간 실행이 예약되었고, 안전성 알림이 모니터링 시스템에 통합되었습니다.
- 계층 3의 제공 설계 문서가 문서화되었습니다.
제가 한 일은 정책을 선택하고, 몇 가지 승인 버튼을 클릭하고, 스케줄러 등록 명령을 한 번 실행한 것뿐이었습니다.
첫날에 "발견"된 것들
그리고 운영 첫날, 두 가지 즉각적인 발견이 있었습니다.
첫째: 측정해보니 우리는 크게 지고 있었습니다.
8개의 최근 내부 에이전트 세션을 8축 Judge로 채점한 결과는 — 1개 통과, 7개 실패였습니다. "AI가 많은 일을 하게 하는 것"과 "AI가 좋은 일을 하는 것" 사이에는 측정해야만 비로소 보이는 거리가 있었습니다.
둘째: "가르쳐주면 고칠 수 있는 마찰"이 발견되었습니다.
한 팀원의 Cowork (Claude의 에이전트 작업 공간)에서 대시보드가 MCP 서버 연결 실패가 전날 4건에서 당일 12건으로 악화되었음을 감지했습니다. 플러그인 인증이 이틀 동안 끊겨 있었는데, 그들은 계속 사용하고 있었습니다.
그 팀원은 아마 "좀 이상하게 작동하네"라고 생각하고 계속 작업했을 것입니다. 말을 꺼내서 인증을 수정하면 5분 만에 고칠 수 있습니다. "가르쳐주면 고칠 수 있는 마찰"은 아무에게도 보고되지 않고 쌓여갑니다 — 이것이 바로 사용량 대시보드에서는 절대 볼 수 없었던 부분이었습니다.
시도해보고 배운 세 가지
1. 평가는 도구가 아니라 운영입니다
채점 메커니즘만 구축하고 멈춘다면, 없는 것과 같습니다. 주간 정기 실행 및 알림에 연결하고, 월요일 회의에 수치가 나타나야 비로소 "평가하고 있다"고 말할 수 있습니다. Frankle이 언급한 "평가에 대한 투자"는 아마 도구가 아닌 운영에 관한 것일 것입니다.
2. LLM Judge 앞에 기계적 판단 계층을 두십시오
8축 Judge 평가는 강력하지만 LLM을 실행하기 때문에 시간과 비용이 듭니다. 루프, 비용 이상치, 연결 실패와 같은 결정론적 신호는 전체 볼륨에 대해 매일 실행하고, Judge는 주간 샘플링에 사용하는 것이 현실적이었습니다.
3. "90%로는 충분하지 않다"를 구현한다는 것은 하드 실패를 의미합니다
평균 점수를 볼 때 안전성 문제는 다른 점수에 묻힙니다. "안전성이 2 이하이면 다른 것이 완벽해도 실패"로 설계해야만 기사에서 언급된 "훨씬 더 엄격한 규모의 평가"에 한 걸음 더 가까워집니다. 1/8의 통과율은 고통스럽지만, 이 고통이 개선의 출발점입니다.
결론
"AI는 이미 충분히 똑똑합니다."
— 그렇기 때문에 다음 싸움은 똑똑한 AI에 맡겨진 작업을 누가, 어떻게 평가하느냐입니다.
Frankle은 이것이 10년짜리 작업이라고 말했습니다.
10년이 걸리는 일은 일찍 시작할수록 차별화 요소가 됩니다. 그리고 시작 자체는 AI 에이전트로 하루 만에 가능했습니다.
저희 회사 (AI Brain Partners)에서는 Claude Code 전문 기업 교육 및 AI 컨설팅을 통해 이러한 "AI 사용 측정 및 평가" 시스템 구축을 지원합니다. "우리의 AI 활용 상황이 실제로 어떤지" 궁금하시다면 아래 링크를 확인해주세요.
- 기업용 AI 에이전트 교육: https://ai-agent.camp/ja/lab/corporate-training
- 무료 보고서 "기업에 AI 도입하는 방법": https://ai-agent.camp/ja/lab/whitepaper-ai-enterprise
(원문: ITmedia AI+ "AI 활용의 병목, 평가와 거버넌스로 이동" 2026년 7월 6일)
