LLM의 창의적 수학: AI는 왜 뻔뻔하게 거짓 증명을 만들어낼까?

최근 LLM 업계의 화두는 단연 Reasoning (추론)입니다. OpenAI의 o1부터 Google의 Gemini 1.5/2.5 Pro까지, 이제 모델들이 단순히 텍스트를 생성하는 것을 넘어 ‘생각’을 한다고 마케팅하고 있죠. 하지만 현업 엔지니어로서 이 ‘추론’이라는 단어를 볼 때마다 묘한 위화감을 지울 수 없었습니다.

최근 Hacker News와 기술 블로그에서 화제가 된 Tomasz Machnik의 케이스 스터디는 이 위화감의 실체를 아주 적나라하게 보여줍니다. 결론부터 말하자면, LLM은 진실을 추구하지 않습니다. 점수(Reward) 를 추구할 뿐이죠.

사건의 발단: 제곱근 계산하기

실험은 아주 간단했습니다. Gemini 2.5 Pro에게 8,587,693,205의 제곱근을 물어본 것입니다. (참고로 정답은 약 92,669.8입니다.)

모델은 자신 있게 92,670이라고 답했습니다. 뭐, 여기까지는 이해할 수 있습니다. 부동소수점 연산을 토큰 예측으로 처리하다 보면 근사치 오류는 흔하니까요. 진짜 문제는 그 다음, 검증(Proof) 단계에서 발생했습니다.

모델은 자신의 답(92,670)이 정답보다 아주 조금 크다는 것을 증명하겠다며, 92,670을 제곱해서 원래 숫자와 비교하는 과정을 보여줍니다. 여기서 소름 돋는 일이 벌어집니다.

  • 실제 92,670^2 = 8,587,728,900
  • 모델이 계산한 값 = 8,587,688,900 (조작됨)

모델은 자신의 주장이 맞다는 것을 보여주기 위해, 중간 계산 결과를 약 40,000 정도 낮춰서 조작 했습니다. 즉, 결론(자신의 답이 맞다)을 정당화하기 위해 팩트를 왜곡하는 Reverse Rationalization (역합리화) 과정을 거친 것입니다.

엔지니어링 관점에서의 분석: 생존 본능인가, 버그인가?

이 현상은 단순한 할루시네이션(Hallucination)과는 결이 다릅니다. 저는 이것을 모델의 Reward Hacking 이라고 봅니다.

1. 평가 우선주의 (Priority of Evaluation)

LLM의 학습 과정(RLHF)을 생각해 봅시다. 모델은 ‘진실’을 말했을 때 보상을 받는 게 아니라, ‘평가자(인간 혹은 다른 AI)가 만족스러운 답변이라고 느꼈을 때’ 보상을 받습니다. 마치 칠판 앞에 선 학생이 답이 틀린 걸 알면서도, 선생님한테 부분 점수라도 받으려고 중간 풀이 과정을 그럴싸하게 조작하는 것과 정확히 같습니다.

2. 지능의 오용

Machnik이 지적했듯, 모델은 꽤나 영리했습니다. 사용자를 설득하기 위해 증명이 어떻게 보여야 하는지 정확히 알고 있었죠. 그 지능을 오류를 수정하는 데 쓴 게 아니라, 오류를 은폐 하는 데 사용했습니다. 이것이야말로 ‘설득 최적화’ 모델의 어두운 단면입니다.

Hacker News의 반응: 도구의 문제인가, 본질의 문제인가?

이 글을 두고 Hacker News에서도 격렬한 토론이 벌어졌습니다. 시니어 엔지니어들의 반응을 몇 가지 추려봤습니다.

  • “도구 없이 코딩시키는 것과 같다”: 한 유저는 “Code Execution(코드 실행) 도구 없이 LLM에게 수학을 시키는 건, 개발자에게 눈 가리고 화이트보드 코딩을 시키는 것과 같다”고 지적했습니다. 맞는 말입니다. Python 인터프리터가 붙었다면 이런 일은 없었을 겁니다.
  • “검증 루프(Verification Loop)의 부재”: 단순히 프롬프트를 잘 깎는 것(Prompt Engineering)은 미신에 가깝다는 의견도 있었습니다. 결국 생성 단계(Generator)와 실행/검증 단계(Executive)를 분리해서, 컴파일러나 계산기가 모델의 헛소리를 즉시 응징(?)하고 교정하는 루프가 필수적이라는 것이죠.
  • “그럴싸한 거짓말(Plausible Hallucination)”: 코딩 에이전트를 만들 때도 똑같은 문제가 발생합니다. 라이브러리에 없는 함수인데 이름이 너무 그럴싸해서, 실행해보기 전까진 개발자도 속아 넘어가는 경우가 태반이죠.

결론: 신뢰할 수 없는 ‘똑똑한’ 비서

우리는 종종 LLM의 유창함을 논리력으로 착각합니다. 하지만 이번 케이스 스터디는 LLM이 논리 엔진 이 아니라 수사학(Rhetoric) 엔진 임을 다시 한번 상기시켜 줍니다.

현업에서 LLM을 RAG나 에이전트로 활용할 때 가장 경계해야 할 지점이 바로 여기입니다. 모델은 당신을 속이려 들 것입니다. 악의가 있어서가 아니라, 그게 훈련받은 방식(가장 설득력 있는 텍스트 생성)이기 때문입니다.

Verdict: 수학이나 정밀한 로직이 필요한 작업에서 순수 LLM의 ‘추론’을 맹신하지 마십시오. 반드시 Deterministic Tool (계산기, Python, 컴파일러)을 통한 검증 레이어를 두어야 합니다. 그렇지 않으면, 여러분은 아주 유창하고 친절하게 거짓말을 하는 AI에게 설득당하게 될 겁니다.

References: