토큰과 토큰화: 모델이 텍스트를 이상하게 보는 이유

당신이 언어 모델에 문장을 입력하면, 당신 눈에는 단어가 보입니다. 모델은 그렇지 않습니다. 어떤 "사고"가 일어나기도 전에, 당신의 텍스트는 **토큰(token)**이라 불리는 조각으로 잘립니다. 그리고 모델이 실제로 처리하는 것은 바로 그 토큰이지, 글자도 단어도 아닙니다. 이 단 하나의 변환 단계가, 그러지 않으면 어리둥절했을 수많은 동작을 설명해 줍니다. 왜 모델이 한 단어의 글자 수를 잘못 셀 수 있는지, 왜 어떤 언어는 처리 비용이 더 드는지, 왜 입력이 예상보다 빨리 길이 제한에 부딪히는지, 왜 이상한 문자열을 붙여 넣으면 이상한 출력이 나오기도 하는지 말이죠. 토큰화를 이해하고 나면 모델의 많은 별난 점들이 더 이상 수수께끼가 아니게 됩니다.

토큰이란 실제로 무엇인가

토큰은 텍스트 덩어리입니다. 보통은 흔한 단어, 단어의 일부, 공백+단어, 또는 단일 문자죠. 모델이 읽고 쓰는 단위입니다. "the" 같은 짧고 흔한 단어는 종종 토큰 하나입니다. 더 길거나 드문 단어는 여러 개로 쪼개질 수 있습니다. 가령 "tokenization"은 "token" + "ization"이 될 수 있고, 흔치 않은 이름은 작은 조각 여러 개로 산산이 부서지기도 합니다.

핵심 통찰은, 토큰이 단어와도 다르고 글자와도 다르다는 점입니다. 토큰은 그 중간에 자리합니다. 언어에 대한 모델의 시야는 전부 이 덩어리들로 지어집니다. 모델이 응답을 생성할 때는 한 번에 토큰 하나씩 만들어내며, 각 토큰은 앞서 나온 토큰들을 바탕으로 선택됩니다. 모델이 글자나 문장 전체를 일차적 단위로 다루는 지점은 어디에도 없습니다.

애초에 텍스트를 왜 쪼개는가

모델에 단어 전체를 통째로, 혹은 개별 글자를 넣는 편이 더 단순해 보일 수 있습니다. 그런데 양극단 모두 문제를 일으키며, 토큰화는 그 타협안입니다.

단어 전체를 쓰면 어휘 사전이 엄청나게 커지는데도, 한 번도 본 적 없는 단어를 끊임없이 만나게 됩니다. 오타, 신조어, 전문 용어, 이름 같은 것들이죠. 모델은 이를 다룰 방법이 없게 됩니다.

단일 문자를 쓰면 어휘 사전은 아주 작아지고 미지의 것은 결코 없어지지만, 모든 텍스트 조각이 매우 긴 시퀀스가 되고, 모델은 날것의 글자에서 의미를 처음부터 배워야 합니다. 이는 낭비이고 느립니다.

토큰화는 그 차이를 절충합니다. 흔한 단어는 효율을 위해 자기만의 토큰을 갖습니다. 드문 단어는 더 작고 재사용 가능한 조각으로 쪼개지므로, 모델은 익숙한 조각을 조립해 무엇이든 다룰 수 있습니다. 한 번도 본 적 없는 단어라도, 그 조각들은 본 적이 있으니까요. 이것이 모델이 새로운 단어를 매끄럽게 처리하는 이유입니다. 모델은 하위 단어(sub-word) 조각으로부터 의미를 재조립하도록 만들어졌습니다.

모델이 "텍스트를 이상하게 보는" 이유

여기 결정적인 결과가 있습니다. 모델이 토큰 단위로 작동하기 때문에, 인간에게는 사소한 어떤 과제들이 모델에게는 이상하리만치 어려워집니다.

한 단어의 글자를 세거나, 거꾸로 뒤집거나, 두 단어가 운율이 맞는지 알아채는 일을 생각해 보세요. 당신에게 이것은 개별 글자에 관한 일입니다. 하지만 모델은 그 단어 전체를 토큰 하나로 받았을 수 있습니다. 안에 든 글자가 보이지 않는 불투명한 덩어리로요. 어떤 단어의 r이 몇 개인지 세라고 하는 것은, 누군가에게 그저 하나의 통째 형상으로만 인식하는 기호 속 글자를 세라고 하는 것과 같습니다. 정보는 기술적으로 복원 가능하지만, 모델이 텍스트를 표현하는 방식과는 어긋납니다. 이것이 수많은 "AI가 철자를 못 쓴다"는 일화 뒤에 있는 진짜 이유입니다. 멍청해서가 아니라, 글자 수준의 구조가 모델이 읽는 바로 그 단위에 의해 일부 가려져 있기 때문입니다.

같은 효과가, 정밀한 문자 조작, 한 자리씩 적어 내려가는 특정 산술, 그리고 문자열의 의미가 아니라 정확한 내부 구성에 의존하는 과제들에서 모델이 흔들릴 수 있는 이유도 설명해 줍니다.

같은 텍스트의 비용이 다른 이유

토큰은 측정과 과금의 단위이기도 합니다. 모델 사용량과 요금은 보통 단어나 글자가 아니라 토큰으로 셉니다. 여기에는 새겨둘 만한 실질적 함의가 있습니다.

언어마다 토큰화 효율이 크게 다릅니다. 토크나이저의 학습 데이터에 잘 반영된 언어의 텍스트는 한 가지 개념당 더 적은 토큰으로 압축되는 경향이 있는 반면, 다른 언어, 또는 토크나이저가 덜 효율적으로 다루는 문자 체계는 같은 내용을 표현하는 데 훨씬 더 많은 토큰이 필요할 수 있습니다. 그 결과, 동일한 의미라도 한 언어에서 처리하는 비용이 다른 언어보다 눈에 띄게 더 들 수 있습니다. 코드, 구조화된 데이터, 또는 특이한 기호로 가득한 텍스트도 마찬가지여서, 보이는 길이가 같은 평범한 산문보다 더 많은 토큰으로 쪼개질 수 있습니다.

전형적인 영어 산문에 대해 흔히 인용되는 대략적인 경험칙은, 평균적으로 토큰 하나가 단어보다 조금 적은 정도에 해당한다는 것입니다. 다만 그런 비율은 어떤 것이든 상수가 아니라 느슨한 길잡이로만 받아들이세요. 토큰 수를 확실히 아는 유일한 방법은 해당 모델의 토크나이저로 직접 측정하는 것입니다. 모델 계열마다 토큰화 방식이 다를 수 있기 때문입니다.

토큰과 문맥 창

모든 모델에는 **문맥 창(context window)**이 있습니다. 입력과 출력을 합쳐, 한 번의 교환에서 받아들이고 만들어낼 수 있는 토큰의 최대 개수죠. 그 한계는 토큰으로 측정되며, 그래서 같은 창이라도 무엇을 넣느냐에 따라 더 크게도 작게도 느껴집니다.

긴 문서를 다루는 과제에 주의가 필요한 이유도 여기 있습니다. 화면상으로는 적당해 보이는 문서가, 특히 토큰화 효율이 낮은 언어로 쓰였거나 서식과 기호로 가득하다면, 짐작보다 훨씬 더 많은 창을 잡아먹을 수 있습니다. 큰 입력을 다루는 무언가를 설계할 때, 페이지나 글자가 아니라 토큰으로 생각하면 입력이 잘려나가거나 요청이 조용히 한계를 넘어서는 일에 당황하지 않게 됩니다.

실질적 함의

토큰이 사고의 일부가 되면 자연스럽게 따라오는 습관 몇 가지가 있습니다.

• 모델에게 글자 수준의 수술을 가볍게 시키지 마세요. 글자 세기, 문자열 뒤집기, 그와 비슷한 과제는 토큰 표현과 충돌합니다. 그런 일을 확실히 처리해야 한다면, 모델의 직관보다 도구에 기대세요.
• 문맥 한계에 가깝거나 비용을 지켜볼 때는 길이를 단어가 아니라 토큰으로 추정하세요. 그리고 중요한 것이라면 짐작하지 말고 측정하세요.
• 비용과 길이가 언어와 콘텐츠 유형에 따라 달라질 것을 예상하고, 언어 간에 같으리라 가정하지 말고 그에 맞춰 예산을 잡으세요.
• 눈에 보이는 길이를 과신하지 마세요. 짧아 보이는 코드나 기호 덩어리가 토큰을 많이 잡아먹을 수 있고, 길게 늘어진 평범한 산문이 보기보다 가벼울 수 있습니다.

정리

토큰은 당신의 텍스트와 모델 사이에 숨어 있는 층입니다. 모델이 읽고 쓰는 모든 것은 이 덩어리들로 이뤄지며, 보통은 단어와 단어 조각인데, 다루기 힘든 단어 전체 어휘 사전과 비효율적인 글자 단위 처리 사이의 타협으로 선택된 것입니다. 그 타협이 모델로 하여금 어떤 텍스트든 매끄럽게 다루게 해주지만, 동시에 글자 수준의 세부를 가립니다. 그래서 정밀한 철자와 문자 과제에서 모델이 걸려 넘어지는 것이죠. 또 토큰은 길이, 비용, 문맥 한계를 측정하는 자연스러운 단위이며, 같은 개념이 왜 한 언어에서 더 비쌀 수 있는지를 설명해 줍니다. 토큰을 직접 들여다볼 일은 좀처럼 없겠지만, 그것을 염두에 두면 일군의 이상한 모델 동작이 예측 가능한 것으로 바뀝니다.