AI 스타트업이 $9M을 받고 제일 먼저 한 일은, 자기 모델을 일부러 약하게 만드는 거였어요.
그것도 프런티어 모델보다 4단계나 낮은 모델로요.
다들 "더 똑똑한 AI"가 답이라고 믿죠
AI가 틀리면 다음 버전, 더 큰 모델을 기다리는 게 보통이에요. GPT가 안 되면 다음 GPT, Claude가 헷갈리면 다음 Claude. "모델이 커지고 똑똑해지면 언젠가 안 틀리겠지"라는 게 업계 전체의 암묵적 전제였어요.
근데 숫자를 보면 이 전제가 흔들려요. 2026년 37개 모델을 벤치마크한 결과, 전체 환각(할루시네이션) 비율이 15%~52%로 나타났고, 가장 정확하다는 최상위 모델들도 15~17% 수준이었어요. 법률 질의에선 69~88%, 안전장치 없는 의료 업무에선 최대 64%까지 치솟고요. 모델이 계속 좋아지고 있는데도 이 숫자가 쉽게 안 떨어지는 거예요.
이게 그냥 통계로 끝나는 문제가 아니에요. 2024년 한 해 AI 환각으로 인한 글로벌 손실이 670억 달러 규모로 집계됐고, 2026년 1분기에만 잘못된 금융 분석 때문에 23억 달러가 날아갔어요. 기업들은 직원 1인당 연간 14,200달러, 주당 4.3시간을 AI 답변 검증에 쓰고 있고요. 경영진의 47%는 이미 환각 섞인 콘텐츠를 근거로 중요한 의사결정을 내린 적이 있다고 해요.
그래서 다들 "다음 모델이 나오면 나아지겠지" 하고 기다리는 동안, a16z가 9백만 달러를 건 스타트업 하나는 정반대 방향으로 갔어요.
근데 Probably는 정반대로 갔다
Optimizely에서 데이터 플랫폼을 이끌다 나온 Peter Elias가 창업한 Probably는, 모델을 더 키우는 대신 모델을 감시하는 하네스를 만들었어요. Elias는 이걸 "데이터 사이언스 메크수트"라고 불러요 — LLM이 내놓은 모든 답을 실제 데이터셋과 대조하는 결정론적 검증기를 씌우고, 그 검증기를 통과하도록 모델을 다시 학습시키는 방식이에요.
결과가 반직관적이에요. 하네스가 제 역할을 하니까, 프런티어 모델보다 4단계나 약한 모델로도 비슷한 신뢰도를 낼 수 있었다는 거예요. Elias의 말을 그대로 옮기면 이래요.
"하네스 엔지니어링이 잘 될수록, 모델은 더 약해도 됩니다. 컨텍스트를 충분히 다듬을 수 있다면, 모델이 그렇게 열심히 일할 필요가 없어요."
— Peter Elias, Probably 창업자
목표는 결정론적 시스템에서나 흔한 99.99% 정확도예요. 왜 이게 돈이 되냐면 — 모델이 약해도 된다는 건 로컬 하드웨어(현재 Beta 0.1은 M1~M5 Apple Silicon 지원)에서 돌릴 수 있다는 뜻이고, 토큰 비용이 확 줄고, 고객 데이터는 로컬에 남긴 채 추론만 클라우드로 보낼 수 있다는 뜻이에요. Probably는 이 구조로 인프라 비용을 25%까지 줄인다고 밝혔어요.
Elias가 짚은 이유도 흥미로워요. "빅랩은 이렇게 할 유인이 없어요. 모델을 고쳐 써야 하는 횟수가 많을수록 돈을 더 버니까요"라고요. a16z도 같은 맥락에서 최근 "AI를 지루하게 만드는 회사가 가장 큰 가치를 만들 것"이라는 투자 논지를 밝힌 적 있어요 — 여기서 "지루하다"는 건 재미없다는 뜻이 아니라 데이터베이스처럼 예측 가능하고 믿을 수 있다는 뜻이고요.
| 기존 방식 — 더 큰 모델 | Probably 방식 — 검증 하네스 | |
|---|---|---|
| 정확도를 높이는 법 | 더 크고 비싼 프런티어 모델로 교체 | 결정론적 검증기로 약한 모델의 오답을 걸러냄 |
| 비용 | 토큰 비용·API 비용 계속 증가 | 로컬 실행 가능, 인프라 비용 최대 25%↓ |
| 판정 기준 | 또 다른 모델이 채점 (LLM-as-judge) | 사람이 정한 규칙 + 실제 데이터셋 대조 |
| 한계 | 정답이 없는 창의적 업무에도 적용 시도 | 정답이 정해진 업무(데이터·회계·의료)에 특화 |
여기서 판정 기준 얘기가 중요해요. 요즘 유행하는 LLM-as-judge 방식은 결국 또 다른 확률 모델이 채점하는 거라, 앞에 나온 답을 더 좋아하는 포지션 편향이나 긴 답을 선호하는 장문 편향에서 자유롭지 못해요. Probably는 이 채점 자체를 AI한테 안 맡기고, 사람이 정한 결정론적 규칙으로 대체한 거예요. "AI가 맞았는지"를 또 다른 AI에게 물어보지 않겠다는 선언인 셈이죠.
이 판, 한국에서도 이미 벌어지고 있다
이게 실리콘밸리만의 얘기는 아니에요. 어제(2026년 7월 14일) 국내 AI 기업 제네시스코텍스AI도 비슷한 문제의식으로 'AI Debate Engine'을 상용화했어요. 접근 방식은 다른데요 — Probably가 결정론적 규칙으로 답을 검증한다면, 이쪽은 ChatGPT·Claude·Gemini·Grok을 한 플랫폼에서 서로 토론시키고 실행 기반으로 검증하는 '경쟁 → 검증 → 협력' 프레임워크를 씁니다. 단일 모델의 확률적 답을 그냥 믿지 않는다는 방향은 똑같아요.
이게 왜 지금 국내 기업들에도 남 얘기가 아니냐면, AI를 실무에 붙일수록 검증되지 않은 리스크도 같이 붙기 때문이에요. 최근 국내 보안 리포트에서는 프롬프트 인젝션이 기업 AI 운영 환경의 치명적 취약점으로 꼽혔고, 대기업 취약점의 37%가 1년 넘게 방치되고 있다는 통계까지 나왔어요. "AI가 준 답을 얼마나 믿을 수 있나"는 이제 기술팀만의 질문이 아니라, AI 도구를 실무에 붙이는 모든 조직의 질문이 된 거예요.
| 접근법 | 핵심 아이디어 | 누가 하나 |
|---|---|---|
| 결정론적 검증 하네스 | 정답 데이터셋과 하드코딩 규칙으로 대조 판정 | Probably |
| 다중 모델 토론 | 여러 LLM을 경쟁·토론시켜 합의 도출 | 제네시스코텍스AI |
| LLM-as-judge | 별도 LLM이 답변을 채점 | 범용 평가 프레임워크 다수 |
세 방식 다 나름의 쓸모가 있지만, 우리 조직이 지금 당장 흉내 낼 수 있는 건 결정론적 검증 하네스 쪽이에요. 여러 모델을 동시에 돌리거나 별도 채점 모델을 훈련시킬 필요 없이, "정답을 코드로 정의하고 AI 답을 거기에 대조한다"는 원칙만 가져오면 되거든요.
우리 회사 AI 워크플로우에도 이 원칙 적용하는 법
Probably를 지금 당장 살 수는 없어요(아직 베타, Apple Silicon 한정). 근데 이 회사가 증명한 원칙 — "정답이 정해진 업무엔 결정론적 검증을 씌워라" — 은 지금 쓰는 어떤 AI 워크플로우에도 적용할 수 있어요.
- 검증 가능한 업무부터 고르기
숫자·코드·DB 조회처럼 "맞다/틀리다"가 명확한 업무를 먼저 골라요. 창의적 글쓰기나 열린 질문엔 이 방식이 안 맞아요. - 정답 데이터셋(ground truth) 확보하기
AI 답을 대조할 기준이 필요해요. 이미 검증된 과거 데이터, 사내 DB, 공식 문서가 후보예요. - 결정론적 규칙으로 검증기 만들기
또 다른 AI에게 채점을 맡기지 마세요. "이 조건이면 통과, 아니면 반려" 같은 하드코딩 규칙을 직접 짜야 편향 없는 판정이 돼요. - 실패 케이스로 프롬프트·컨텍스트 보정하기
검증기가 걸러낸 오답 패턴을 모아서, 프롬프트나 제공 컨텍스트를 계속 다듬어요. Elias 말대로 "컨텍스트가 좋아질수록 모델은 덜 열심히 일해도" 됩니다. - 감사 기록(citation trail) 남기기
AI 답이 어떤 근거로 통과했는지 로그를 남겨두면, 나중에 "왜 이 답을 믿었냐"는 질문에 답할 수 있어요. 신뢰는 결국 이 기록에서 나와요.
