BullshitBench 실전 가이드: 더 똑똑한 AI보다 먼저 확인해야 할 "헛소리 거부율"

발행일: 2026-04-06 | 카테고리: AI 뉴스

1) 문제 정의

이번 이슈의 핵심은 모델이 "얼마나 많이 안다"가 아니라, 질문 자체가 잘못됐을 때 멈출 줄 아느냐입니다. 대상 독자는 사내 챗봇, 코딩 에이전트, 분석 보조 도구를 운영하거나 도입 검토 중인 CTO, AI PM, 플랫폼 엔지니어, 보안·리스크 담당자입니다. 해결해야 할 문제는 명확합니다. 모델이 전문용어가 섞인 엉터리 질문에 그럴듯한 답을 길게 생성하면, 사용자는 이를 "추론"으로 오해하고 운영 리스크는 더 커집니다.

이 글의 적용 범위는 LLM 평가, 사내 에이전트 검수, 고위험 업무용 프롬프트 설계입니다. 반면 순수 연구용 리더보드 경쟁, 일반적인 지식문답 벤치마크 전체 비교, 특정 벤더 홍보는 다루지 않습니다.

2) 근거 및 비교

AI타임스 보도에 따르면 BullshitBench는 일부러 말이 안 되는 질문을 던져 모델이 이를 거부하는지 측정합니다. GitHub 공개 저장소 기준 v2는 100개 문항, 5개 도메인, 3단계 판정 체계로 구성됩니다. Anthropic의 Claude Sonnet 4.6이 상위권을 차지한 반면, 강한 추론을 표방하는 모델들도 잘못된 전제를 끝까지 합리화하는 경향을 보였습니다. 여기서 실무적으로 비교해야 할 평가 방식은 아래 3가지입니다.

• 비용: 잘못된 답 1건의 후속 검토·재작업 비용이 모델 호출비보다 더 큽니다.
• 시간: 배포 전 벤치 100문항을 돌리는 시간보다, 사고 후 원인분석 시간이 훨씬 길어집니다.
• 정확도: 여기서 중요한 정확도는 정답률이 아니라 잘못된 전제를 올바르게 거부하는 비율입니다.
• 난이도: 모델 교체보다 "어떤 질문을 위험 신호로 볼지" 평가기준을 합의하는 일이 더 어렵습니다.

3) 단계별 실행 방법

1. 위험 질문군부터 따로 모읍니다.
   재무·법무·의료·보안·개발 문서에서 실제로 섞이기 쉬운 헛소리 패턴을 20~30개만 먼저 수집합니다. 예: 서로 무관한 KPI를 인과관계처럼 묶기, 존재하지 않는 프레임워크 이름 넣기, 버전·규격을 일부러 섞기.
2. 모델 출력 판정 기준을 3단계로 고정합니다.
   Clear Pushback(명확한 거부), Partial Challenge(문제는 지적하지만 일부 수용), Accepted Nonsense(전제를 받아들이고 답변)로 구분하면 재현성이 높아집니다.
3. 배포 전 게이트에 넣습니다.
   정답형 벤치 통과와 별도로 "Accepted Nonsense 비율" 상한을 정합니다. 내부 도우미는 15% 이하, 고위험 보조 도구는 5~10% 이하처럼 사용처별 기준을 다르게 두는 편이 현실적입니다.
4. 시스템 프롬프트에 전제 검증 규칙을 명시합니다.
   모델에게 답을 빨리 주라고만 하면 과잉합리화가 늘어납니다. "질문의 전제가 성립하는지 먼저 점검하라"는 규칙을 넣고, 불명확하면 추가 확인 질문을 하게 해야 합니다.
5. 운영 로그에서 실패 케이스를 다시 수집합니다.
   실서비스에서 나온 이상 답변을 주 1회씩 벤치 세트에 추가하면, 리더보드 숫자보다 조직에 맞는 안전 기준을 빠르게 만들 수 있습니다.

# 배포 전 단순 게이트 예시
if accepted_nonsense_rate > 0.10:
    decision = "hold"
elif partial_challenge_rate > 0.25:
    decision = "needs_prompt_tuning"
else:
    decision = "ship_with_monitoring"

4) 실수/함정(Pitfalls)

1. 함정: 높은 추론 점수면 전제 검증도 잘할 것이라 가정
   예방: 정답형 평가와 헛소리 거부율을 분리 측정합니다.
   복구: 이미 배포했다면 실패 로그 10건부터 수집해 별도 안전 벤치를 만듭니다.
2. 함정: 도움을 많이 주는 모델이 좋은 모델이라고만 판단
   예방: "도움성"과 "멈춰야 할 때 멈추는 능력"을 다른 축으로 봅니다.
   복구: 시스템 프롬프트에 전제 검증 우선 규칙을 넣고 Partial/Accepted 비율을 다시 측정합니다.
3. 함정: 사용자 질문이 이상하면 사용자 탓으로 넘김
   예방: 실제 업무에서는 질문이 항상 깔끔하지 않다는 전제로 설계합니다.
   복구: 자주 나오는 혼합 프롬프트 유형을 체크리스트화하고 UI에 예시 경고를 추가합니다.

5) 실행 체크리스트

• 도메인별 헛소리 질문 세트 20개 이상을 확보했다
• Clear Pushback / Partial Challenge / Accepted Nonsense 판정 기준을 문서화했다
• 모델 선정 시 정답률과 전제 검증률을 별도 점수로 본다
• 시스템 프롬프트에 전제 검증 및 추가질문 규칙을 넣었다
• 배포 게이트에 Accepted Nonsense 상한선을 설정했다
• 운영 중 실패 답변을 주간 단위로 벤치에 재반영한다

Definition of Done: 대상 사용처에서 Accepted Nonsense 비율 기준을 만족하고, 최근 운영 실패 사례 10건 이상이 벤치 세트에 반영돼 재측정까지 끝나면 완료입니다.

6) 참고자료

• 엉뚱한 질문으로 구성된 '헛소리벤치' 등장...앤트로픽이 상위권 싹쓸이 (AI타임스, 2026-04-06)
• petergpt/bullshit-benchmark GitHub 저장소 (README 확인일: 2026-04-06)
• BullshitBench v2 공개 뷰어 (확인일: 2026-04-06)
• Claude Sonnet 4.6 공식 발표 (확인일: 2026-04-06)
• Anthropic Constitution (확인일: 2026-04-06)

7) 작성자 관점(Author Viewpoint)

제 판단은 분명합니다. 2026년 LLM 운영에서 중요한 차별점은 "더 길게 추론하는가"보다 말이 안 되는 요청을 얼마나 빨리 중단하느냐입니다. 특히 사내 에이전트, 문서 분석, 코딩 보조처럼 사용자가 모델을 신뢰하기 쉬운 환경일수록 BullshitBench류 평가는 선택이 아니라 필수에 가깝습니다.

추천은 정답형 벤치 + 전제 검증 벤치 + 운영 로그 재학습의 3단 구조입니다. 비추천은 리더보드 상위 모델을 그대로 들여오고 "사용자가 잘 물어보면 된다"고 보는 접근입니다. 예외적으로 단순 아이디어 브레인스토밍 도구는 기준을 완화할 수 있지만, 의사결정 보조나 내부 자동화에는 거부율 기준을 반드시 따로 둬야 합니다.