P6-2.2 문자열·토큰·token ID로 이어지는 모델 입력¶

Section ID: P6-2.2 Version: v2026.07.23

P6-2.1에서는 토큰을 길이, 비용, 잘림, 문맥 보존 문제를 설명하기 위한 계산 단위로 붙잡았습니다. 이제 그 계산 단위가 tokenizer 출력과 모델 입력에서 어떤 값으로 보이는지 읽어야 합니다.

이 절의 중심은 토큰이라는 말을 넓게 설명하는 데 있지 않습니다. tokenizer 출력에서 보이는 토큰 문자열, 토큰 수, 토큰 ID를 구분하고, 그 ID들이 순서열(sequence)로 모델 입력이 된다는 점을 붙잡는 데 있습니다.

tokenizer 출력에서 먼저 구분할 값¶

토큰(token)은 모델이 입력과 출력을 다룰 때 세는 기본 계산 단위입니다. 다만 실제 출력 화면이나 로그에서는 토큰이 하나의 값으로만 보이지 않습니다. 원문 문자열, 토큰 문자열, 토큰 수, 토큰 ID가 함께 나오기 쉽고, 이 값들을 섞어 읽으면 모델 입력이 어떻게 만들어지는지 흐려집니다.

토큰은 사람이 읽기 좋은 뜻 단위로 정해지는 것이 아니라, 특정 모델의 tokenizer가 가진 어휘 사전(vocabulary)과 분할 규칙에 따라 정해집니다. 그래서 같은 원문이라도 모델이나 tokenizer가 달라지면 토큰 조각과 토큰 수가 달라질 수 있습니다.

여기서 필요한 최소 구분은 아래와 같습니다.

이 표가 이 절의 기준입니다. 먼저 원문이 어떻게 잘렸는가, 몇 조각인가, 각 조각이 어떤 번호로 바뀌었는가를 나누어 읽고, 그다음에 그 번호들이 어떤 순서로 모델 입력에 놓이는지 봅니다.

먼저 버릴 오해¶

토큰은 경우에 따라 다음처럼 보일 수 있습니다.

• 한 단어
• 단어 일부
• 공백을 포함한 짧은 조각
• 숫자와 기호가 섞인 조각
• 구두점까지 붙은 조각

즉, 토큰은 사람이 직관적으로 느끼는 단어와 항상 같지 않습니다. 같은 한 단어처럼 보여도 여러 토큰으로 쪼개질 수 있고, 공백이 앞에 붙은 조각처럼 사람이 단어로 잘 보지 않는 부분이 하나의 토큰 경계에 포함될 수도 있습니다.

다음 표처럼 보면 차이가 더 분명합니다.

이 차이는 특히 다음 장면에서 자주 드러납니다.

중요한 것은 위 표의 분할이 모든 모델에서 그대로 나온다는 뜻이 아닙니다. 실제 분할은 tokenizer마다 다릅니다. 다만 어떤 결과가 나오든 판독 기준은 같습니다. 원문을 먼저 보고, 그다음 토큰 문자열의 경계를 보고, 마지막으로 토큰 수와 ID를 확인합니다.

또 하나의 오해는 토큰을 Part 1에서 보았던 symbolic AI의 상징(symbol)처럼 읽는 것입니다. symbolic AI의 symbol은 사람이 정한 의미나 규칙의 이름에 가까웠습니다. 반면 LLM의 token은 tokenizer가 원문을 잘라 만든 계산 조각이고, 모델은 그 조각을 ID와 벡터로 바꾸어 확률적 계산에 넣습니다.

따라서 토큰을 논리 기호처럼 과하게 해석하면 안 됩니다. 반대로 토큰 ID를 의미 없는 내부 숫자처럼만 넘겨도 안 됩니다. 지금 필요한 것은 토큰 문자열을 뜻풀이로 읽는 일이 아니라, 그 조각이 vocabulary의 어떤 번호로 바뀌어 모델 입력의 어느 자리에 놓이는지를 읽는 일입니다.

모델 안에서는 어떻게 쓰이나¶

토큰은 그대로 계산되지 않습니다. 모델은 보통 다음 흐름으로 입력을 다룹니다.

flowchart TD
  A["원문 문자열"]
  B["토큰 문자열<br/>조각 경계"]
  C["토큰 수<br/>조각 개수"]
  D["토큰 ID 순서열<br/>vocabulary 번호"]
  E["임베딩 벡터<br/>계산 입력"]
  F["모델 계산"]

  A --> B
  B --> C
  B --> D
  D --> E
  E --> F

이 흐름에서 중요한 점은 두 가지입니다.

• 모델은 원문 문자열을 바로 계산하지 않고 먼저 토큰 문자열과 토큰 ID 순서열로 바꿉니다.
• 토큰 ID는 이후 벡터 표현으로 조회되어 실제 계산에 들어갑니다.

즉, 토큰은 그 자체로 완성된 의미 단위라기보다, 모델 계산이 시작되는 입구에 가깝습니다.

엔지니어링 관점에서 이 흐름이 중요한 이유는, 사람이 실제로 확인할 수 있는 값도 이 흐름을 따라 바뀌기 때문입니다.

즉, 토큰이 무엇인가를 안다는 것은 용어 정의 하나를 외우는 일이 아니라, 나중에 tokenizer 출력이나 로그를 볼 때 무엇을 읽고 있는지 구분할 수 있다는 뜻입니다.

여기서 토큰 ID를 볼 때는 한 가지를 더 조심해야 합니다. ID는 이 조각이 vocabulary의 몇 번 항목인가를 나타내는 식별자(identifier)에 가깝습니다. 4012가 812보다 크다고 해서 더 중요하거나 더 복잡한 토큰이라는 뜻은 아닙니다. 모델 계산에서 중요한 것은 ID의 크기 자체가 아니라, 그 ID가 어떤 임베딩 벡터로 조회되고 이후 문맥 계산에 들어가느냐입니다.

출력값 구분 사례 및 예시¶

사례 1. 사람이 보는 단어와 토큰이 다를 때¶

고객 지원 문서에 환불정책이라는 표현이 계속 나온다고 해 봅시다. 사람은 이 표현을 뜻이 분명한 한 단어로 읽습니다. 그래서 모델도 이 단어 하나를 그대로 한 계산 단위로 받는다고 생각하기 쉽습니다.

하지만 모델 입력에서는 사람이 한 단어로 느끼는가가 기준이 아닙니다. tokenizer 출력에서 이 표현이 한 조각으로 남는지, 여러 조각으로 나뉘는지, 각 조각에 어떤 ID가 붙는지를 봐야 합니다. 특히 한국어처럼 조사, 어미, 붙여 쓰기 표현이 자주 섞이는 문장에서는 사람이 보는 단어 경계와 tokenizer 경계가 쉽게 어긋날 수 있습니다.

이 사례에서 확인해야 할 결과는 토큰은 사람이 느끼는 단어와 항상 같지 않다는 점입니다. 같은 표현을 보더라도 원문 문자열과 토큰 문자열, 토큰 수, 토큰 ID를 분리해서 읽어야 합니다.

사례 2. 문장 하나가 토큰 시퀀스로 바뀔 때¶

회의는 내일 10:00 AM입니다를 사람은 일정 안내 한 문장으로 읽습니다. 사람 기준으로는 문장 하나, 의미 하나, 시간 정보 하나가 먼저 보입니다.

하지만 모델은 문장 전체를 통째로 계산에 넣지 않습니다. 먼저 원문 문자열을 토큰 문자열의 순서로 바꾸고, 그 조각 수를 세며, 각 조각에 ID를 붙인 뒤 계산 준비를 합니다.

처음에는 아래 네 층위만 분리해도 문장과 계산 입력의 차이가 보입니다.

이 사례에서 확인해야 할 결과는 모델이 먼저 문장 전체의 뜻이 아니라 번호를 붙일 수 있는 조각의 순서를 입력으로 받는다는 점입니다. 정확한 토큰 개수보다 중요한 것은 어떤 층위의 값을 보고 있는지 구분하는 일입니다. 이 구분이 있어야 모델 입력을 토큰 ID의 순서로 읽을 때, 그 값이 갑자기 튀어나온 내부 구현처럼 느껴지지 않습니다.

사례 3. 토큰은 바로 계산되는 것이 아닐 때¶

로그에 토큰 문자열과 토큰 ID가 함께 찍혀 있다고 해 봅시다. 처음에는 토큰 문자열만 보면 충분해 보입니다. 조각이 눈에 보이기 때문에 모델이 그 글자 조각 자체를 계산한다고 느끼기 쉽습니다.

하지만 토큰 문자열은 사람이 확인하기 쉬운 표시이고, 모델 계산으로 넘어갈 때는 각 조각에 대응하는 토큰 ID가 필요합니다. 그 ID가 다시 벡터 표현으로 바뀌어야 실제 계산에 들어갑니다. 다시 말해 토큰 문자열은 관찰하기 쉬운 표지이고, 토큰 ID는 모델이 vocabulary에서 임베딩을 찾아가기 위한 키(key)에 가깝습니다.

같은 흐름을 가장 짧게 줄이면 다음과 같습니다.

이 사례에서 확인해야 할 결과는 토큰 문자열과 토큰 ID를 같은 것으로 보면 안 된다는 점입니다. 토큰 문자열은 원문이 어떻게 잘렸는지 보여 주고, 토큰 ID는 그 조각이 모델 내부에서 어떤 번호로 다뤄지는지 보여 줍니다.

같은 장면을 한 번 더 비교표로 줄이면 다음과 같습니다.

층위를 바꿔 묻는 연습¶

실제 tokenizer를 아직 돌리지 못해도, 아래처럼 사람이 먼저 하는 말을 모델 기준 확인 질문으로 바꿔 보는 연습은 할 수 있습니다.

이 표에서 중요한 것은 정확한 값을 미리 맞히는 일이 아닙니다. 먼저 필요한 것은 지금 내가 보는 것이 단어 뜻풀이인가, 계산 조각인가, 조각 개수인가, 번호화된 입력인가를 구분하는 일입니다.

여기서 자주 섞이는 것도 바로 이 층위들입니다.

• 원문 문자열을 보고도 이미 모델 계산이 시작됐다고 느끼기 쉽습니다.
• 토큰 문자열을 보면 단어 뜻풀이처럼 받아들이기 쉽습니다.
• 토큰 ID를 보면 너무 내부 값 같아서 의미 없이 지나치기 쉽습니다.
• 토큰이 표식처럼 보인다는 이유만으로 symbolic AI의 symbol과 같은 층위로 읽기 쉽습니다.

모델 입력을 토큰 ID의 순서로 읽으려면 이 층위들을 먼저 구분할 수 있어야 합니다.

실제 로그나 설명 화면에서 같은 구분을 적용하면 아래처럼 읽습니다.

이 표는 조각, 개수, 번호, 자리의 구분을 현재 통합 Section 안에서 다시 멈춰 확인하게 만드는 장치입니다. 독자가 이 표를 통과하면 토큰을 낱개 이름으로 보지 않고, tokenizer 출력과 모델 입력 사이의 층위를 나누어 읽을 수 있습니다.

tokenizer 출력값 판독 예시¶

토큰화 종류를 비교하기 전에, 토큰 그 자체를 읽는 법부터 확인하는 편이 좋습니다. 아래 예시는 실제 tokenizer 출력에서 자주 보게 되는 세 값을 단순화해 보여 줍니다. 특정 모델의 정확한 결과를 외우기 위한 표가 아니라, 출력에서 무엇을 읽어야 하는지 구분하기 위한 예시입니다.

• 토큰 문자열(token pieces)
• 토큰 수(token count)
• 토큰 ID(token ids)

예를 들어 어떤 도구가 다음 형식으로 출력한다고 가정해 봅시다. 아래 토큰 조각과 ID 숫자는 개념 설명을 위한 단순 예시입니다. 실제 모델의 tokenizer에서는 조각 경계와 ID가 다르게 나올 수 있습니다.

여기서 독자가 바로 읽어야 할 결과는 다음입니다.

이 표를 읽을 때는 다음처럼 판단하면 됩니다.

• 토큰 문자열은 원문이 잘린 경계를 보여 줍니다.
• 토큰 수는 원문이 몇 개의 계산 조각으로 바뀌었는지 보여 줍니다.
• 토큰 ID는 사람이 읽는 뜻이 아니라 vocabulary 조회 결과입니다.
• 같은 원문이라도 tokenizer가 다르면 토큰 문자열, 토큰 수, ID가 달라질 수 있습니다.

같은 방식으로 영어 단어 하나도 읽어 봅니다.

이때 확인해야 할 점은 영어 단어 하나라는 사람 감각과 계산 조각 둘이라는 모델 감각이 다를 수 있다는 사실입니다.

반대로 짧은 기호나 구두점도 따로 토큰이 될 수 있습니다. 예를 들어 마침표 .나 콜론 :은 사람에게는 부가적인 표시처럼 보이지만, tokenizer 출력에서는 독립 조각으로 나타날 수 있습니다. 그래서 토큰 수를 볼 때는 중요한 단어가 몇 개인가보다 tokenizer가 실제로 몇 조각을 만들었는가를 먼저 봐야 합니다.

이 예시의 목표는 특정 tokenizer의 정확한 숫자를 외우는 데 있지 않습니다. 먼저 필요한 것은 tokenizer 출력에서 지금 내가 보고 있는 것이 단어 뜻풀이가 아니라 계산 조각, 개수, 번호라는 점을 분명히 구분하는 일입니다.

tokenizer 출력은 아래 세 질문으로 닫아 볼 수 있습니다.

이 예시에서 닫을 판단은 토큰이 무엇인가를 사전식으로 외우는 데 있지 않습니다. tokenizer 출력에서 조각, 개수, 번호를 각각 무엇으로 읽는지 구분할 수 있으면 됩니다.

token ID 순서열이 모델 입력이 되는 방식¶

앞에서는 토큰을 토큰 문자열, 토큰 수, 토큰 ID로 나누어 읽었습니다. 이제 그 값들이 모델 입력에서 어떻게 쓰이는지 봐야 합니다.

핵심은 토큰 하나의 뜻풀이가 아니라 토큰들의 순서열(sequence)입니다. 모델은 원문 문장을 통째로 받는 것이 아니라, 토큰 ID가 줄지어 있는 입력을 받고 그 순서 위에서 다음 계산을 이어 갑니다.

토큰 하나보다 순서열이 중요하다¶

토큰은 낱개로만 쓰이지 않습니다. 모델 입력에서는 여러 토큰이 순서대로 놓이고, 그 순서가 문장의 구조를 만드는 재료가 됩니다.

토큰 순서가 없으면 환불 가능과 환불 불가능처럼 비슷한 조각을 포함한 표현도 안정적으로 구분하기 어렵습니다. 모델은 각 토큰이 무엇인지뿐 아니라, 앞뒤에 어떤 토큰이 있었는지도 함께 읽어야 합니다.

여기서 순서열이라는 말은 단순히 토큰을 줄 세운다는 뜻만이 아닙니다. 각 토큰은 입력 안에서 자기 자리를 갖고, 그 자리는 앞뒤 토큰과 함께 해석됩니다. 같은 토큰 ID라도 앞에 어떤 토큰이 있었는지, 뒤에 어떤 토큰이 이어지는지에 따라 다음 계산에서 맡는 역할이 달라질 수 있습니다.

아주 작게 쓰면 입력은 아래처럼 읽을 수 있습니다.

이 표에서 중요한 것은 ID 숫자를 외우는 일이 아닙니다. 같은 조각 목록이라도 어떤 자리에 놓였는지, 어떤 조각 앞뒤에 붙었는지를 같이 봐야 모델 입력을 읽을 수 있다는 점입니다.

토큰 ID는 계산으로 들어가는 번호열¶

앞에서 본 토큰 ID는 단순한 라벨이 아닙니다. 모델은 문자열 자체가 아니라 토큰 ID의 순서를 입력으로 받고, 그 ID를 벡터 표현으로 바꾸어 계산합니다.

아주 단순하게 쓰면 흐름은 다음과 같습니다.

여기서 중요한 것은 토큰화 규칙을 아직 자세히 설명하는 것이 아닙니다. 먼저 모델이 문장 전체를 바로 읽는 것이 아니라 토큰 ID 순서열을 입력으로 받는다는 구조를 붙잡는 일입니다.

조금 더 촘촘하게 말하면, 모델 입력을 읽을 때는 세 가지를 같이 봅니다.

따라서 모델 입력은 ID 목록만도 아니고, 단어 뜻 목록만도 아닙니다. 어떤 ID가 어떤 순서와 위치에 놓였는가를 함께 보는 구조입니다.

ID 순서열 사례 및 예시¶

사례 1. 같은 조각도 순서가 달라지면 입력이 달라질 때¶

고객 지원 문서에서 환불 가능과 환불 불가능을 자동 분류한다고 해 봅시다. 사람은 두 표현을 뜻으로 바로 구분하지만, tokenizer 출력만 처음 보는 독자는 환불과 가능이 둘 다 보이니 비슷한 입력이라고 느끼기 쉽습니다.

이 기준의 한계는 토큰을 포함된 조각 목록처럼 본다는 데 있습니다. 모델 입력에서는 어떤 조각이 들어 있는지만이 아니라, 그 조각이 어느 자리에 끼어드는지가 중요합니다. 불 같은 부정 조각이 가능 앞에 놓이면, 같은 환불과 가능을 포함하더라도 입력 순서열은 달라집니다.

이 사례에서 확인해야 할 결과는 토큰을 집합처럼 모아 보는 대신, 앞에서 뒤로 이어지는 번호열로 읽어야 한다는 점입니다. 숫자는 설명용 예시입니다.

따라서 이 사례의 더 안전한 판단은 어떤 토큰이 포함됐는가에서 멈추지 않고, 그 토큰들이 어떤 순서로 놓였는가까지 확인하는 것입니다.

사례 2. 같은 토큰이 반복되어도 위치가 다를 때¶

회의는 내일입니다. 회의 자료를 보내 주세요.라는 입력에는 회의가 두 번 나옵니다. 사람은 같은 단어가 반복됐다고 먼저 볼 수 있고, tokenizer 출력에서도 같은 토큰 문자열이나 같은 ID가 두 번 보일 수 있습니다.

하지만 같은 ID가 두 번 등장했다는 사실만으로는 두 자리가 같은 역할을 한다고 말할 수 없습니다. 첫 번째 회의는 일정 안내를 여는 자리에 놓이고, 두 번째 회의는 자료를 보내 주세요라는 요청 앞에 놓입니다. 같은 토큰이라도 위치와 주변 토큰이 다르면 모델 입력에서 읽히는 역할이 달라질 수 있습니다.

이 사례에서 확인해야 할 결과는 모델 입력이 토큰 종류 목록이 아니라 위치가 있는 토큰 순서열이라는 점입니다.

따라서 이 사례의 더 안전한 판단은 같은 토큰인가보다 같은 토큰이 입력의 어느 위치에서 어떤 주변 조각과 함께 놓였는가를 먼저 보는 것입니다.

사례 3. 입력 토큰 뒤에 출력 토큰이 이어질 때¶

사용자가 환불 불가능한 경우를 한 문장으로 알려 줘라고 묻고, 모델이 답을 만들기 시작한다고 해 봅시다. 사람은 보통 답변 문장을 완성된 결과물로 먼저 봅니다. 그래서 출력이 문장 단위로 한 번에 만들어진다고 느끼기 쉽습니다.

이 기준의 한계는 입력과 출력을 서로 끊어진 덩어리처럼 본다는 데 있습니다. LLM이 답변을 만들 때는 이미 들어온 입력 토큰 뒤에 새 출력 토큰이 이어지고, 방금 붙은 출력 토큰도 다음 출력을 고를 때 앞 문맥의 일부가 됩니다. 지금 절에서 붙잡을 것은 선택 방식의 세부가 아니라, 입력과 출력이 모두 같은 순서열 위에서 이어진다는 사실입니다.

이 사례에서 확인해야 할 결과는 토큰이 입력을 읽을 때만 쓰이는 표지가 아니라, 출력이 이어지는 기본 단위이기도 하다는 점입니다.

따라서 이 사례의 더 안전한 판단은 입력은 입력, 출력은 결과로 끊어 보는 것이 아니라, 입력 토큰 뒤에 출력 토큰이 이어지며 같은 순서열이 길어진다고 읽는 것입니다.

토큰을 순서열로 읽기¶

아래 장면을 보면 토큰을 낱개로 보는가, 순서열로 보는가를 먼저 구분해 봅니다.

여기서 필요한 적용 수준은 복잡한 모델 내부 수식이 아니라, 토큰을 낱개 이름보다 순서가 있는 입력 단위로 읽는 일입니다.

같은 판단을 실제 로그나 설명 화면에서 본다면 아래 순서로 확인하면 됩니다.

토큰 ID 순서열에서 남길 기준¶

토큰은 단순 개념어가 아니라 모델 입력과 출력이 이어지는 기본 단위입니다. 지금 닫아야 할 질문은 운영 판단이 아니라, 토큰이 모델 안에서 순서가 있는 입력으로 쓰인다는 점입니다.

이 흐름을 이해하면, 원문 문자열을 이런 토큰 순서열로 바꾸는 절차인 토큰화(tokenization)가 왜 필요한지도 자연스럽게 이어집니다.

연습 및 예제¶

이 연습의 목표는 토큰화 규칙을 맞히는 것이 아닙니다. 주어진 토큰 조각과 ID를 보고, 모델 입력을 낱개 목록이 아니라 자리 있는 순서열로 읽는 연습입니다. 각 문항에서 먼저 스스로 답을 고른 뒤, 바로 아래 해설과 비교합니다.

연습 1. 같은 조각 목록에서 순서 차이 찾기¶

아래 두 입력은 같은 조각 환불, 불, 가능을 모두 포함합니다.

먼저 스스로 답해 봅니다.

• 두 입력을 같은 입력으로 볼 수 있는가?
• 다르다면 어느 자리의 차이가 가장 먼저 보이는가?
• 이 차이를 토큰 종류 목록만으로 설명할 수 있는가?

해설: 두 입력은 같은 조각을 포함해도 같은 입력이 아닙니다. A에서는 920이 7731 앞에 놓이고, B에서는 920이 맨 뒤에 놓입니다. 이 절의 기준으로는 무엇이 들어 있는가보다 어떤 ID가 어떤 순서로 놓였는가가 먼저입니다.

연습 2. 같은 토큰의 위치 읽기¶

아래는 같은 토큰 ID 5100이 두 번 등장하는 단순화한 입력입니다.

먼저 스스로 답해 봅니다.

• 두 회의는 같은 ID이므로 같은 역할이라고 말할 수 있는가?
• 두 자리를 다르게 읽으려면 어떤 값을 더 봐야 하는가?
• 이 입력을 {회의} 같은 토큰 종류 목록으로 줄이면 무엇이 사라지는가?

해설: 같은 ID가 반복되어도 같은 역할이라고 단정할 수 없습니다. 두 토큰은 서로 다른 자리에 있고, 뒤에 이어지는 조각도 다릅니다. 토큰 종류 목록으로 줄이면 위치와 앞뒤 문맥이 사라지므로, 모델 입력을 읽는 데 필요한 핵심 정보가 빠집니다.

연습 3. 출력 토큰이 어디에 붙는지 추적하기¶

아래는 질문 뒤에 출력 토큰이 하나씩 이어지는 과정을 단순화한 것입니다.

먼저 스스로 답해 봅니다.

• 둘째 출력 토큰 훼손은 질문과 분리된 새 문장 덩어리인가?
• 둘째 출력이 붙을 때 모델이 참고하는 앞쪽 순서에는 무엇이 들어 있는가?
• 출력 과정을 완성된 문장 하나가 나온다로만 보면 무엇을 놓치는가?

해설: 훼손은 앞선 질문과 첫 출력 토큰 뒤에 이어진 새 토큰입니다. 둘째 출력이 붙는 시점에는 질문 토큰뿐 아니라 이미 생성된 제품도 앞 문맥의 일부가 됩니다. 그래서 출력은 완성 문장이 한 번에 생기는 것이 아니라, 기존 순서열이 토큰 단위로 길어지는 과정으로 읽어야 합니다.

세 연습을 마치면 아래 한 문장으로 정리할 수 있어야 합니다.

모델 입력은 토큰 종류의 모음이 아니라, 토큰 ID가 순서와 위치를 가진 채 이어지는 번호열이다.

체크리스트¶

• 모델 입력이 문장 전체가 아니라 토큰 ID 순서열이라는 점을 설명할 수 있는가?
• tokenizer 출력에서 토큰 문자열, 토큰 수, 토큰 ID를 서로 다른 값으로 구분할 수 있는가?
• 토큰 하나의 이름보다 앞뒤 순서와 위치가 중요하다는 점을 말할 수 있는가?
• 입력 토큰 뒤에 출력 토큰이 이어지며 답변이 만들어진다는 점을 설명할 수 있는가?

출처와 참고 자료¶

• OpenAI Help Center, What are tokens and how to count them?, 확인 날짜: 2026-07-19. API 요청 텍스트가 토큰으로 나뉘고 응답이 토큰 시퀀스로 생성된 뒤 텍스트로 변환된다는 설명 확인에 사용했다.
• OpenAI, tiktoken README, 확인 날짜: 2026-07-19. 언어 모델이 텍스트를 사람이 읽는 방식이 아니라 토큰 번호의 시퀀스로 본다는 설명 확인에 사용했다.
• Daniel Jurafsky, James H. Martin, Speech and Language Processing, 3rd ed. draft, online manuscript released January 6, 2026, 확인 날짜: 2026-07-19. Words and Tokens, Large Language Models 장을 토큰 순서열과 언어 모델 입력 설명의 배경 근거로 사용했다.