LLM은 왜 수학을 틀릴까? LLM 추론 능력 3단계 진화

대규모 언어 모델(LLM)이 복잡한 코드를 생성하는 것을 보면 경이롭습니다. 하지만 이런 LLM에게 초등학교 수준의 간단한 수학 문제를 내주면 어떨까요?

“로저는 테니스 공 5개를 가지고 있습니다. 그는 테니스 공 3개가 든 캔 2개를 더 샀습니다. 지금 그는 총 몇 개의 공을 가지고 있을까요?”

많은 LLM이 이 문제에 5 + 2 + 3 = 10이나 5 + 3 = 8 같은 엉뚱한 답을 내놓곤 합니다. (정답은 5 + (2 × 3) = 11이죠.)

이유가 무엇일까요? LLM은 ‘지능’이라기보다, 수천억 개의 예문을 학습한 ‘정교한 패턴 인식기’에 가깝기 때문입니다. 논리적인 추론이나 정확한 계산은 본질적으로 약할 수밖에 없습니다.

이 글에서는 LLM의 이런 약점을 보완하기 위한 3단계 진화 과정을 살펴보겠습니다. Chain-of-Thought (CoT)에서 시작해 Program-aided Language Models (PAL)를 거쳐, 두 가지를 지능적으로 결합하는 ‘자동 선택’ 모델까지 분석합니다.

1단계: 생각의 사슬 (CoT)

LLM의 추론 약점을 보완하려 등장한 첫 번째 혁신이 ‘생각의 사슬(Chain-of-Thought, CoT)’입니다. CoT는 LLM에게 답만 요구하는 대신, 문제 해결 과정을 단계별로 ‘생각’하게 유도하는 방식입니다.

예를 들어 ‘베이커리 문제’를 보겠습니다.

문제

“한 베이커리에서 오전에 200개의 빵을 구웠습니다. 오전에 93개, 오후에 39개를 팔았습니다. 식료품점에서 팔리지 않은 빵 6개를 반품했습니다. 남은 빵은 총 몇 개인가요?”

CoT의 추론

“베이커리는 200개로 시작했습니다. 오전에 93개, 오후에 39개를 팔았으니, 총 93 + 39 = 132개를 팔았습니다. 6개를 반품받았으니, 남은 빵은 200 - 132 - 6 = 62개입니다. 정답은 62입니다.”

CoT의 추론은 그럴싸해 보이지만, 결정적인 오류가 있습니다. 계산이 틀렸습니다. 반품된 빵 6개는 ‘남은 빵’에 더해야 하므로, 200 - 132 + 6 = 74가 정답입니다.

CoT는 LLM이 문제를 분해하는 능력(이해력)은 향상시켰지만, 계산 능력은 여전히 LLM 자체에 의존했습니다. 즉, 분해는 잘해놓고 마지막의 간단한 산술에서 실수하는 문제가 빈번했습니다.

2단계: PAL

CoT의 한계(‘분해는 잘하지만 계산은 못한다’)를 해결하기 위해 ‘PAL(Program-aided Language Models)’이 등장했습니다. 아이디어는 천재적으로 간단합니다. LLM이 잘하는 것(언어 이해)과 못하는 것(계산)을 분리하는 것입니다.

LLM을 ‘문제 해결사’가 아닌, ‘프로그래밍 번역가’로 역할을 바꾼 셈입니다.

PAL은 LLM에게 자연어 추론 과정을 생성하라고 요구하는 대신, 문제를 해결할 수 있는 프로그램(예: 파이썬 코드)을 생성하라고 합니다. 그리고 실제 계산은 LLM이 아닌, 100% 정확성이 보장된 ‘파이썬 인터프리터’ 같은 외부 실행기에 맡깁니다.

다시 ‘베이커리 문제’를 PAL로 풀면 이렇습니다.

PAL의 추론 (LLM 생성)

# 베이커리는 200개로 시작
loaves_baked = 200

# 오전에 93개, 오후에 39개 판매
loaves_sold_morning = 93
loaves_sold_afternoon = 39

# 6개 반품
loaves_returned = 6

# 남은 빵 계산
answer = loaves_baked - loaves_sold_morning - loaves_sold_afternoon + loaves_returned
# print(answer)

실행 (파이썬 인터프리터): >>> 74

LLM은 ‘반품은 더해야 한다’는 의미를 이해해 + loaves_returned라는 코드를 정확히 생성했습니다. 그리고 실제 계산(74)은 파이썬 인터프리터가 완벽하게 수행했습니다.

이 접근은 수학 벤치마크(GSM8K)에서 SOTA(최고 성능)를 기록했습니다. 특히 LLM이 혼란을 겪는 큰 숫자 계산에서도, 인터프리터는 7자리 숫자든 2자리 숫자든 똑같이 정확하게 처리하므로 압도적인 안정성을 보였습니다.

3단계: 완벽한 해결책은 없다

그렇다면 PAL이 모든 추론 문제의 ‘만병통치약(Silver Bullet)’일까요? 안타깝게도 그렇지 않습니다. 모든 추론 문제가 계산으로 해결되지는 않기 때문입니다.

두 번째 논문은 CoT와 PAL이 서로 다른 강점과 약점을 가졌음을 100개의 실패 사례 분석으로 명확히 보여줍니다.

요약하자면, PAL은 ‘정확한 논리적 계산’에, CoT는 ‘유연한 의미론적 사고’에 특화되어 있습니다. PAL이 실패하는 실제 사례를 보면 이 차이가 명확해집니다.

PAL이 틀리는 경우: 유연성 부족 (방정식)

문제: “세스는 브룩보다 나이가 2배 많습니다. 2년 후, 그들의 나이 합은 28이 됩니다. 세스의 현재 나이는?”

CoT (성공): “브룩의 나이를 x라고 하자. 세스의 나이는 2x다. … (x+2) + (2x+2) = 28 … 3x+4 = 28 … x=8이다. 따라서 세스의 나이는 2 × 8 = 16살이다.”

PAL (실패): PAL은 x를 미지수로 두는 방정식을 세우는 데 서툴러, 나이 차이를 기반으로 엉뚱한 계산을 시도하다 실패합니다.

PAL이 틀리는 경우: 의미론적 이해 부족 (뉘앙스)

문제: “글로리아는 부츠와 하이힐 두 켤레를 고민 중입니다. 두 하이힐의 가격을 합치면 부츠보다 5달러가 ‘덜’ 나갑니다. … 부츠 가격은?”

CoT (성공): “…하이힐 총합 = $99. 부츠는 하이힐 총합보다 5달러 ‘더’ 비싸다. 따라서 부츠 = $99 + $5 = $104.”

PAL (실패): PAL은 “하이힐이 부츠보다 5달러 덜 나간다”는 문장을 “부츠 = 하이힐 – 5″로 오해하여 boots = heels_total - 5 라는 잘못된 코드를 생성, 94달러라는 오답을 냅니다.

4단계: 궁극의 전략

CoT와 PAL이 서로 다른 문제에 강점을 보이자, 연구자들은 두 가지를 결합하는 하이브리드 전략을 고안했습니다. 핵심은 또 다른 LLM을 ‘조정자(Selector)’ 또는 ‘감독관’으로 활용하는 것입니다.

작동 방식은 다음과 같습니다.

• 병렬 실행: 문제가 들어오면, 시스템은 내부적으로 CoT와 PAL 두 방식으로 동시에 답을 생성합니다.
• 선택자 호출: ‘선택자 LLM’이 문제와 (A) CoT의 답, (B) PAL의 답을 모두 전달받습니다.
• 최종 결정: 선택자 LLM이 두 해결책을 비교 검토한 후, “어느 쪽이 더 이 문제에 적합하고 정확한가?”를 판단해 최종 답을 고릅니다.

놀랍게도 이 ‘선택자’는 CoT의 의미론적 오류나 PAL의 계산 오류를 꽤 높은 정확도로 감지해냈습니다. 이 하이브리드 방식은 CoT와 PAL 각각의 최고 성능을 뛰어넘어 새로운 SOTA 정확도를 달성했습니다.

결론: 우리가 나아가야 할 방향

LLM의 추론 능력은 단일 모델만으로는 한계가 명확합니다.

• CoT는 LLM이 ‘생각’을 시작하게 했지만, 계산이 부정확했습니다.
• PAL은 ‘정확한 계산기(파이썬)’를 탑재해 수학/논리 문제에서 혁신을 일으켰습니다.
• 자동 선택은 LLM에게 ‘감독관’ 역할을 부여해, 문제 성격에 따라 유연한 ‘사고(CoT)’와 엄밀한 ‘계산(PAL)’ 중 적절한 도구를 선택하게 했습니다.

LLM을 활용하는 개발자나 기획자에게 이는 중요한 시사점을 줍니다.

• 하나의 만능 모델을 기대하지 마십시오.
• 산술, 논리, 알고리즘 작업이 필요하다면, LLM이 직접 풀게 하지 말고 코드를 생성하고 실행(PAL)하도록 설계하십시오.
• 의미론적 이해, 창의적 글쓰기, 유연한 사고가 필요하다면 CoT 방식을 사용하십시오.

궁극적으로, 두 가지(혹은 그 이상)의 전문화된 도구를 두고, 상황에 맞춰 최적의 도구를 선택하는 ‘라우터(선택자)’ LLM을 두는 것이 현존하는 가장 강력한 추론 시스템을 구축하는 방법입니다.

미래의 AI는 하나의 거대한 뇌가 아니라, 각기 다른 강점을 가진 전문가들이 협력하고 시너지를 내는 ‘지능형 시스템’의 모습에 더 가까울 것입니다.