오늘날의 인공지능 분야에서 가장 흥미롭고 역설적인 현상 중 하나가 있습니다. 최신 대규모 언어 모델(LLM)은 복잡한 Python 코드를 작성하고, 정교한 법률 계약서를 검토하며, 셰익스피어 스타일의 소네트를 짓기도 합니다. 하지만 정작 “strawberry(딸기)라는 단어에 ‘r’이 몇 개 들어있니?” 혹은 “방금 당신이 한 말은 몇 개의 단어로 이루어져 있니?”와 같은 유치원 수준의 질문에는 황당할 정도로 틀린 답을 내놓곤 합니다.
인간의 관점에서 이런 실패는 이해하기 어렵습니다. 튜링 테스트를 통과할 정도로 똑똑해 보이는 시스템이 왜 이런 단순한 산수에서 무너지는 걸까요?
그 이유는 AI가 ‘멍청해서’가 아니라, 인공 신경망의 근본적인 설계 방식 때문입니다. LLM은 본질적으로 계산기가 아니며, 인간과 전혀 다른 방식으로 텍스트를 ‘읽습니다’. AI가 왜 숫자를 세지 못하는지 이해하기 위해, 신경망의 내부 구조를 통해 그들이 세상을 인지하고 데이터를 처리하는 방식을 살펴보겠습니다.
1. 토큰화(Tokenization)의 병목 현상: 숲만 보고 나무는 보지 못한다
LLM이 글자나 단어의 개수를 정확히 세지 못하는 가장 큰 원인은 토큰화(Tokenization)라는 전처리 과정에 있습니다.
인간이 “strawberry”라는 단어를 읽을 때, 우리의 눈은 10개의 독립된 알파벳이 나열된 것을 봅니다. 시각적으로 각 위치를 훑으며 ‘r’이 어디에 있는지 하나씩 찾아낼 수 있죠.
하지만 LLM은 원문 텍스트를 직접 처리하지 않습니다. 텍스트가 신경망에 입력되기 전, ‘토크나이저’라는 도구가 이를 토큰(Token)이라는 단위로 잘게 쪼갭니다. 이 토큰은 단어 전체일 수도 있고, 음절일 수도 있으며, 훈련 데이터에서 얼마나 자주 등장하느냐에 따라 임의로 나뉜 문자 뭉치일 수도 있습니다.
- 예시: 토크나이저는 “strawberry”를
straw와berry라는 두 개의 독립된 토큰으로 나눌 수 있습니다. - 결과: AI에게 이 두 토큰은 각각 고유한 숫자 ID(예: 토큰 4912와 토큰 813)로 인식됩니다.
즉, 모델은 단어 내부의 개별 철자를 전혀 ‘보지’ 못합니다. LLM에게 “strawberry”에 ‘r’이 몇 개냐고 묻는 것은, 인간에게 속이 보이지 않는 불투명한 잼 병을 건네주며 “이 안에 딸기 씨가 몇 개 들어있느냐”고 묻는 것과 같습니다. 모델은 ‘딸기’라는 개념과 그것이 ‘과일’이라는 사실은 알지만, 그 단어 내부의 철자 구조는 블랙박스 상태인 것입니다.
2. 자기회귀적 생성: 확률적 예측 vs 논리적 계산
설령 토큰화 문제를 우회하더라도(예: 모든 단어를 하나의 토큰으로 인식하게 하더라도), LLM은 여전히 숫자를 세는 데 어려움을 겪습니다. 이는 자기회귀적 생성(Autoregressive Generation)의 본질과 관련이 있습니다.
전통적인 소프트웨어는 알고리즘을 실행합니다. 숫자를 세는 Python 스크립트를 작성하면, 컴퓨터는 0부터 시작하는 변수를 만들고 텍스트를 반복문으로 돌며 항목을 발견할 때마다 1씩 더하는 확정적인 논리를 따릅니다.
하지만 LLM은 알고리즘을 실행하는 것이 아니라 통계적 확률을 계산합니다. 이들은 본질적으로 ‘다음 토큰 예측기’입니다.
AI에게 “이 문장에 단어가 몇 개 있니?”라고 물으면, AI는 문장을 하나씩 훑으며 숫자를 세는 것이 아니라, 지금까지 나온 문맥을 바탕으로 “이 상황에서 다음에 나올 숫자로 가장 확률이 높은 것은 무엇인가?”를 추측합니다. 학습 데이터에 기반해 그럴듯해 보이는 숫자를 ‘찍는’ 것에 가깝습니다. 숫자를 세는 것은 엄격한 규칙 기반의 수학적 작업이지 언어적 패턴이 아니기 때문에, 확률 엔진은 종종 논리적으로 틀린 답을 내놓게 됩니다.
3. 작업 기억(Working Memory)과 상태 저장의 부재
숫자를 세기 위해서는 작업 기억이라는 인지 기능이 필요합니다. 인간은 수를 셀 때 머릿속으로 “하나, 둘, 셋…” 하며 현재 상태를 계속 업데이트합니다. 이것은 선형적이고 상태 유지적인(stateful) 과정입니다.
반면, 현대 LLM의 기반인 트랜스포머(Transformer) 아키텍처는 정보를 선형이 아닌 병렬로 처리합니다. ‘어텐션 메커니즘’을 통해 문맥 전체를 한꺼번에 분석하죠. 이 과정에서 모델은 중간 값을 저장해두는 ‘내부 연습장’이나 누적 카운터를 가지고 있지 않습니다.
컴퓨터 과학적으로 숫자를 세는 것은 $O(n)$의 시간이 걸리는 작업이지만, 트랜스포머는 고정된 연산 레이어 안에서 단 한 번에 최종 정답으로 도약하려 합니다($O(1)$ 방식). 중간 단계를 외부로 기록하지 않는 한, 모델은 순차적인 논리를 실행할 수 없습니다.
4. 숫자 인코딩의 불일치
숫자 데이터 자체를 처리할 때도 토큰화가 발목을 잡습니다. 인간의 수학은 10진법 체계를 따르지만, 토크나이저는 숫자를 매우 불규칙하게 쪼갭니다.
123은 하나의 토큰일 수 있습니다.1234는12와34로 나뉠 수 있습니다.12345는123과45로 나뉠 수 있습니다.
숫자가 쪼개지는 방식이 제각각이기 때문에, 모델은 자릿수를 맞추거나 사칙연산을 수행할 때 큰 혼란을 겪습니다. 모델은 수학의 근본 원리를 배우는 것이 아니라, “2+2″가 “4”로 번역되는 ‘언어적 패턴’으로 수학을 학습하기 때문입니다.
5. 간극 메우기: AI에게 숫자를 가르치는 법
LLM이 구조적으로 숫자를 세기에 부적합하다면, 우리는 이 한계를 어떻게 극복하고 있을까요?
- 생각의 사슬(Chain of Thought, CoT) 프롬프팅: 모델에게 “단계별로 생각하라”고 지시하여 작업 기억을 흉내 내게 합니다. “strawberry의 철자를 하나씩 하이픈으로 연결해 쓰고, r이 나올 때마다 숫자를 매겨봐”라고 하면, 모델은 스스로 외부 연습장을 만드는 셈이 되어 훨씬 정확한 답을 냅니다.
- 도구 활용(Code Interpreter): 가장 확실한 방법입니다. 현대적인 모델은 숫자 세기 질문을 받으면 직접 Python 코드를 작성해 실행합니다. 확정적인 수학 계산은 전통적인 컴퓨터 프로세서에 ‘외주’를 주는 방식입니다.
- 바이트 단위 모델(Byte-level Models): 토큰화 과정을 생략하고 텍스트를 바이트나 캐릭터 단위로 직접 읽는 모델들이 연구되고 있습니다. 이렇게 되면 모델이 개별 철자를 ‘원시적으로’ 볼 수 있게 되어 인식 능력이 향상됩니다.
언어와 논리의 경계
대규모 언어 모델이 숫자를 제대로 세지 못하는 것은 시스템의 ‘오류’라기보다 설계상의 필연적인 특징입니다. 이는 유기적인 인간의 인지 구조와 인공 신경망 처리 방식 사이의 근본적인 차이를 보여줍니다.
LLM은 패턴 인식과 언어 합성의 천재이지만, 전통적인 컴퓨팅의 핵심인 단계별 논리 처리 능력은 부족합니다. 이러한 특성을 이해한다면 우리는 AI를 더 현명하게 활용할 수 있습니다. 창의적인 아이디어나 요약이 필요할 때는 LLM을 믿되, 정확한 숫자나 산술이 필요할 때는 계산기를 쥐여주거나… 우리의 손가락을 사용하는 것이 훨씬 낫습니다.