Copilot, Gemini 등 AI 툴에서 모델 선택을 기본값으로 두는 것이 왜 안 되는가

Microsoft Copilot이 동일한 데이터셋에 국가 라벨만 다르게 붙여 입력했을 때, 실제 데이터와 무관하게 국가별 고정관념에 기반한 분석 결과를 만들어냈다는 수학자 Adam Kucharski의 실험은 LLM의 근본적 한계를 드러낸다. 기본 모드의 LLM은 통계적 다음 토큰 예측에 의존하는데, 학습 데이터에 내재된 국가·문화별 스테레오타입이 강한 사전 확률(prior)로 작용해 실제 수치를 무시하고 "그럴듯한" 서사를 생성하기 때문이다. 반면 o1, Gemini 2.0 Thinking, Claude의 extended thinking 같은 추론(reasoning) 모델은 응답 전 체인 오브 소트(CoT)를 명시적으로 전개해 데이터를 단계별로 검증하므로, "두 데이터셋의 수치가 동일한가?"라는 메타 질문을 스스로 던지면서 함정을 회피한다. 즉 같은 회사·같은 UI 안에서도 어떤 모델을 선택하느냐에 따라 분석의 정합성이 완전히 달라진다.

개발자 관점에서 이는 단순히 "AI가 가끔 틀린다"는 수준의 문제가 아니다. 데이터 분석 자동화, BI 대시보드 보조, 코드 리뷰, 로그 분석 같은 워크플로우에서 기본 모델을 무비판적으로 사용하면, AI가 데이터를 보지 않고 "데이터에 대한 통념"으로 답변하는 사례가 침묵 속에 누적될 수 있다. 특히 Copilot, ChatGPT, Gemini의 무료/기본 티어는 비용·지연 최적화를 위해 추론 모델이 아닌 경량 모델을 디폴트로 둔다. 사용자가 "분석해줘"라고 요청하면 형식적으로는 분석처럼 보이는 결과물이 나오지만, 내부적으로는 검증 단계 없이 패턴 매칭만 수행한 출력일 가능성이 높다. 한국 엔지니어들이 자주 쓰는 시나리오 — 예컨대 "이 SQL 결과를 요약해줘", "이 에러 로그의 원인을 추정해줘" — 에서도 동일한 환각 위험이 존재한다.

실무에서 취해야 할 액션은 명확하다. 첫째, AI 도구 진입 시 모델 셀렉터를 반드시 확인하고 데이터 분석·수치 비교·인과 추론이 필요한 작업에는 thinking/reasoning 계열(o3, Gemini 2.5 Pro Thinking, Claude with extended thinking 등)을 명시적으로 선택해야 한다. 둘째, 프롬프트 단에서 "데이터의 실제 값을 인용하며 단계별로 검증하라", "통계적 일반화 대신 제공된 수치만 사용하라" 같은 제약을 거는 것이 기본 모델에서도 일부 효과를 발휘한다. 셋째, API 통합 시에는 model 파라미터를 코드 리뷰 대상에 포함시키고, 분석 태스크용 라우팅 정책(예: 숫자가 포함된 쿼리는 추론 모델로 라우팅)을 별도로 두는 것이 안전하다. 마지막으로 Kucharski의 실험처럼 동일 데이터에 라벨만 바꿔 넣는 A/B 검증을 사내 AI 도구 평가 체크리스트에 포함시키면, 어떤 모델이 "스테레오타입 환각"에 취약한지 정량적으로 파악할 수 있다.