P6-2.1 입력과 출력을 제한하는 토큰 단위¶

Section ID: P6-2.1 Version: v2026.07.23

LLM(large language model)을 실제로 쓰기 시작하면 곧바로 다른 질문이 생깁니다. 왜 어떤 입력은 예상보다 비싸고, 왜 긴 문서는 중간에 잘리며, 왜 같은 한 줄 문장도 표기 방식에 따라 길이 감각이 달라지는가 하는 질문입니다.

모델은 글자 수나 문장 수가 아니라 토큰 수를 기준으로 입력을 다룹니다.

즉, 토큰은 먼저 정의로 들어오는 개념이 아니라, 길이 제한, 비용, 잘림, 입력 분할 문제를 설명하기 위해 필요한 계산 단위로 들어옵니다.

이때 토큰을 곧바로 단어 하나나 뜻 하나로 단정하지 않는 것이 중요합니다. 토큰은 사람이 사전에서 찾는 단어도 아니고, 문장의 의미를 한 번에 담은 표지도 아닙니다. 지금 단계에서는 모델이 입력과 출력을 세기 위해 쓰는 계산 조각으로만 붙잡는 편이 안전합니다. 정확히 어떻게 잘리는지는 뒤의 P6-2.2와 P6-2.3에서 다시 설명합니다.

왜 글자 수나 문장 수로는 부족한가¶

사람은 입력을 보통 다음처럼 읽습니다.

문장이 짧은가
파일이 몇 개인가
문단이 몇 개인가
화면에서 얼마나 길어 보이는가

하지만 모델은 이런 단위를 그대로 계산에 쓰지 않습니다. 그래서 사람 기준으로는 비슷한 입력도, 모델 쪽에서는 전혀 다른 길이와 다른 비용으로 읽힐 수 있습니다.

예를 들면 다음과 같습니다.

사람 기준 질문	실제로 다시 봐야 하는 질문
문장이 짧은가	실제 입력 토큰 수가 작은가
파일이 한 개인가	전체 입력이 토큰 한도 안에 들어오는가
문단이 보기 좋은가	필요한 문맥이 같은 조각 안에 남는가

여기서 핵심은 사람이 먼저 세는 단위와 모델이 실제로 계산하는 단위가 다를 수 있다는 점입니다.

따라서 이 절의 첫 판단은 이 토큰이 무슨 뜻인가보다 모델은 이 입력을 어떤 계산 조각들의 길이로 보는가에 가깝습니다. 의미 해석은 뒤에서 임베딩과 Transformer를 거치며 다시 다루고, 여기서는 입력이 모델 계산 안으로 들어가기 전에 이미 사람의 길이 감각과 어긋날 수 있다는 점을 먼저 잡습니다.

토큰 관점에서 먼저 드러나는 문제¶

토큰 관점이 필요한 문제는 보통 다음 장면에서 먼저 드러납니다.

1. 입력 길이 제한¶

긴 문서를 넣으면 사람은 파일 하나니까 한 번에 읽겠지라고 생각하기 쉽습니다. 하지만 모델은 파일 개수가 아니라 전체 입력 길이를 계산 단위 기준으로 읽기 때문에, 뒤쪽 결론이나 예외 조항이 잘릴 수 있습니다.

2. 비용¶

짧아 보이는 문장도 숫자, 기호, 영문 표기, URL이 섞이면 실제 입력 비용은 더 빨리 커질 수 있습니다. 그래서 짧은 공지니까 싸겠지라는 직관이 자주 빗나갑니다.

3. 문맥 보존¶

RAG나 검색용 청크를 자를 때 사람은 문단 수를 먼저 보지만, 실제로는 질문과 조건, 원칙과 예외가 같은 입력 묶음 안에 남는지가 더 중요합니다. 이 문제도 결국 계산 단위를 무엇으로 보느냐와 연결됩니다.

같은 장면을 실무 판단처럼 다시 묶으면 다음과 같습니다.

상황	사람이 먼저 세는 것	모델 쪽에서 먼저 보는 것	바로 달라지는 판단
짧은 한 줄 질문	문장 수, 글자 수	실제 토큰 수	예상 비용과 입력 길이
긴 문서 한 파일	파일 수, 페이지 수	전체 토큰 길이	통째 입력 가능 여부
검색용 문단 분할	문단 수, 보기 좋은 길이	같은 조각 안의 문맥 보존	청크 설계와 회수 품질

아주 단순하게 그리면¶

flowchart TD
  A["같은 토큰 질문"]
  B["한 문장<br/>몇 조각으로 읽히는가?"]
  C["긴 문서<br/>전체 토큰 시퀀스가 들어가는가?"]
  D["비용 점검<br/>몇 토큰이 과금되는가?"]

  A --> B
  A --> C
  A --> D

이 도식에서 확인해야 할 점은 과업이 달라도 먼저 부딪히는 문제가 비슷하다는 것입니다. 짧은 문장, 긴 문서, 비용 계산처럼 장면은 달라도, 결국은 모델이 실제로 무엇을 몇 개의 계산 조각으로 읽는가를 다시 봐야 합니다.

사례 및 예시¶

사례 1. 짧아 보이는 문장의 비용 감각이 흔들릴 때¶

오늘 날씨가 좋다와 회의는 내일 10:00 AM입니다. 자료는 https://example.com/report 를 참고하세요는 모두 짧은 한 줄처럼 보일 수 있습니다. 사람은 보통 문장 수나 화면 길이로 먼저 판단하기 때문입니다.

하지만 숫자, 시간 표기, 영문, URL, 기호가 섞이면 모델이 세는 입력 조각은 사람의 한 줄 감각과 다르게 늘어날 수 있습니다. 비용을 글자 수나 문장 수로만 예측하면 짧은 요청인데 왜 비용이 생각보다 커졌지라는 문제가 생깁니다.

확인해야 할 결과는 짧아 보이는가가 아니라 모델이 실제로 몇 개의 입력·출력 단위로 세는가입니다. 그래서 비용을 설명하려면 토큰이라는 공통 계산 단위가 필요합니다.

입력 장면	사람 기준 첫인상	토큰 관점에서 다시 봐야 하는 것
`오늘 날씨가 좋다`	짧은 한 줄	기준이 되는 입력 조각 수
`회의는 내일 10:00 AM입니다`	짧은 일정 안내	숫자와 영문 표기가 어떻게 세어지는가
URL이 붙은 공지	여전히 한 문장	기호와 긴 문자열이 입력 길이를 얼마나 늘리는가

사례 2. 파일 하나인데 끝까지 읽히지 않을 때¶

회의록 30쪽을 통째로 넣으면 사람은 파일 하나니까 한 번에 읽겠지라고 생각하기 쉽습니다. 하지만 모델은 파일 개수가 아니라 입력 전체가 몇 개의 토큰으로 들어오는지를 기준으로 한도를 만납니다.

표, 숫자 목록, 부록, 코드 조각이 많으면 사람이 느끼는 페이지 수보다 입력 길이가 더 빨리 커질 수 있습니다. 한도를 넘으면 뒤쪽 결론이나 예외 조항이 잘리거나, 애초에 요청을 나누어야 합니다.

확인해야 할 결과는 파일이 몇 개인가가 아니라 끝까지 남길 토큰 예산이 충분한가입니다. 그래서 입력 한도를 설명하려면 토큰 기준이 필요합니다.

문서 장면	사람 기준 첫판단	토큰 관점에서 바뀌는 판단
회의록 30쪽 한 파일	파일 하나니까 한 번에 읽힐 것 같음	전체 입력이 한도 안에 들어오는가
표와 부록이 많은 보고서	페이지 수는 비슷해 보임	표기 요소가 토큰을 더 빨리 늘리는가
결론이 마지막에 몰린 문서	끝까지 넣었으니 결론도 읽었을 것 같음	뒤쪽 핵심 결론이 잘리지 않았는가

사례 3. 보기 좋은 문단인데 검색 답이 흔들릴 때¶

RAG용 문서를 자를 때 사람은 문단 둘이면 적당하다고 느끼기 쉽습니다. 하지만 원칙 문단과 예외 문단이 서로 다른 입력 묶음으로 갈라지면 검색은 원칙만 가져오고 중요한 예외를 놓칠 수 있습니다.

이 장면에서는 문단 모양이 자연스러운지보다 질문에 필요한 조건, 원칙, 예외가 같은 입력 단위 안에 남는지가 더 중요합니다. 너무 길게 묶으면 한도와 비용이 커지고, 너무 짧게 자르면 필요한 문맥이 흩어집니다.

확인해야 할 결과는 문단이 예쁜가가 아니라 필요한 문맥이 같은 토큰 묶음 안에 남는가입니다. 그래서 문맥 보존을 판단할 때도 토큰 관점이 필요합니다.

검색 장면	사람 기준 첫판단	토큰 관점에서 바뀌는 판단
규정 문단 두 개	문단 단위가 보기 좋음	원칙과 예외가 같은 묶음 안에 남는가
긴 FAQ 항목	한 항목이니 같이 두고 싶음	한도와 비용을 넘기지 않는가
짧게 자른 청크	검색 후보가 많아져 좋아 보임	답에 필요한 조건이 흩어지지 않는가

세 사례를 모두 지나도 토큰을 뜻 단위로 읽으면 다시 헷갈립니다. 비용 문제에서는 뜻이 비슷해도 표기 방식 때문에 길이 감각이 달라지고, 긴 문서 문제에서는 한 파일 안에서도 계산 한도에 걸리며, 검색 문제에서는 보기 좋은 문단이 답에 필요한 조건을 보존하지 못할 수 있습니다. 여기서 필요한 토큰 감각은 의미를 담은 이름보다 계산 안에 들어가는 조각과 길이에 더 가깝습니다.

사람 기준을 모델 기준으로 바꾸기¶

아직 실제 토큰 수를 세지 못하더라도, 아래처럼 사람 기준 단위를 모델 기준 단위로 바꿔 보는 연습은 할 수 있습니다.

지금 보는 입력	사람 기준으로 먼저 하기 쉬운 말	토큰 관점에서 먼저 바꿔 물을 말
숫자와 URL이 섞인 공지 한 줄	짧으니 비용도 작겠다	실제 입력·출력 토큰 수가 얼마나 되는가
회의록 한 파일	파일 하나니까 통째로 읽히겠다	전체 입력이 context window 안에 들어오는가
규정 문단 두 개	문단 모양이 자연스러우니 검색도 괜찮겠다	원칙과 예외가 같은 토큰 묶음 안에 남는가

이 표에서 중요한 것은 정답 숫자를 맞히는 일이 아니라, 무엇을 먼저 세야 하는가를 바꾸는 일입니다.

같은 기준을 더 짧게 연습하면 다음처럼 읽을 수 있습니다.

지금 보이는 문제	먼저 떠올려야 할 토큰 관점
답변이 예상보다 비싸다	겉보기 길이보다 실제 토큰 수를 먼저 본다
긴 문서 끝부분이 빠진다	파일 수보다 전체 토큰 길이를 먼저 본다
검색 답이 예외를 놓친다	문단 모양보다 같은 토큰 묶음 안의 문맥 보존을 먼저 본다

이 단계에서는 이 세 줄을 바로 말할 수 있으면 충분합니다. 아직 정확한 토큰 수를 셀 수 없어도, 적어도 비용 문제, 잘림 문제, 문맥 보존 문제가 모두 사람 기준 길이 감각만으로는 설명되지 않는다는 점을 구분하기 시작한 것입니다.

세 사례를 다시 줄이면 다음처럼 볼 수 있습니다.

처음 붙들기 쉬운 기준	왜 부족한가	그래서 필요한 기준
한 줄, 글자 수	숫자·기호·URL이 섞이면 실제 계산 길이와 비용이 달라질 수 있음	입력·출력 토큰 수
파일 수, 페이지 수	한도는 파일 개수가 아니라 모델이 받을 수 있는 길이에 걸림	전체 토큰 길이와 context window
문단 모양	필요한 조건이 다른 묶음으로 갈라지면 답이 흔들림	같은 토큰 묶음 안의 문맥 보존
단어 수, 뜻의 개수	토큰은 단어 하나나 의미 하나와 항상 같지 않음	모델이 실제로 세는 계산 조각

이 표의 목적은 정확한 토큰 수를 외우게 하는 데 있지 않습니다. 왜 LLM을 다룰 때 사람이 먼저 보는 단위를 그대로 쓰기 어렵고, 별도의 모델 기준 계산 단위가 필요한지 붙잡게 만드는 데 있습니다.

세 사례를 다시 묶으면 기준은 하나로 모입니다. 한 줄, 파일 수, 페이지 수, 문단 모양, 단어 수처럼 사람이 먼저 붙드는 단위는 입력 비용, context window, 검색 청크, 출력 길이를 안정적으로 설명하기에 부족합니다. 그래서 LLM을 다룰 때는 사람 눈에 얼마나 길어 보이는가보다 모델이 실제로 몇 개의 계산 조각으로 읽고 쓰는가를 먼저 물어야 합니다.

그래서 토큰이 등장한다¶

이 지점에서 필요한 것이 토큰(token)입니다. 토큰은 모델이 입력과 출력을 다룰 때 세는 계산 단위입니다.

앞의 세 사례가 모두 말하고 싶은 것도 사실은 하나입니다.

비용을 예측하려면 겉보기 길이보다 실제 입력·출력 토큰 수를 봐야 합니다.
긴 문서를 다루려면 파일 개수보다 전체 토큰 길이와 context window를 봐야 합니다.
검색용 입력을 나누려면 문단 모양보다 필요한 문맥이 같은 토큰 묶음 안에 남는지를 봐야 합니다.

즉, 토큰은 새 용어를 하나 더 배우기 위해 등장하는 것이 아닙니다. 사람이 먼저 보던 문장·단어·글자 수 감각만으로는 LLM 입력과 출력을 안정적으로 설명하기 어렵기 때문에, 모델 기준 계산 단위로 등장합니다.

토큰 자체가 정확히 무엇이고, 단어와 어떻게 다르며, 모델 안에서 어떻게 계산되는지는 P6-2.2에서 이어집니다. 여기서는 답변이 예상보다 비싸다, 긴 문서 끝부분이 빠진다, 검색 답이 예외를 놓친다 같은 장면을 볼 때 먼저 사람 기준 길이 감각을 내려놓으면 됩니다. 그다음에 물을 질문은 하나입니다. 이 입력과 출력은 모델이 세는 계산 조각 기준으로 얼마나 길고, 어디까지 같은 문맥 안에 남는가?

연습 및 예제¶

아래 세 입력 장면을 읽고, 먼저 확인할 토큰 관점을 하나씩 고릅니다. 처음에는 오른쪽 예시 답을 가리고 직접 골라 보면 좋습니다.

입력 장면	먼저 판단할 문제	예시 답
한 줄 공지에 시간, 가격, URL이 많이 들어 있다	비용 문제인지, 잘림 문제인지, 문맥 보존 문제인지 고른다	비용 문제: 짧아 보여도 실제 입력·출력 토큰 수가 늘 수 있다.
긴 회의록을 넣었는데 뒤쪽 결론을 답하지 못한다	비용 문제인지, 잘림 문제인지, 문맥 보존 문제인지 고른다	잘림 문제: 파일 하나라도 전체 토큰 길이가 한도를 넘을 수 있다.
규정 검색에서 원칙은 맞지만 예외를 놓친다	비용 문제인지, 잘림 문제인지, 문맥 보존 문제인지 고른다	문맥 보존 문제: 원칙과 예외가 다른 토큰 묶음으로 갈라졌을 수 있다.
같은 뜻의 문장을 더 짧은 말로 바꿨는데 비용 감각이 그대로일지 확신이 없다	단어 수와 토큰 수를 같은 것으로 봐도 되는지 판단한다	단어 수만으로는 부족하다. 실제 토큰 수는 tokenizer가 만든 계산 조각 기준으로 다시 봐야 한다.

이 연습의 목표는 정확한 토큰 수를 세는 것이 아닙니다. 같은 입력을 볼 때 사람 눈에 짧은가, 파일이 몇 개인가, 문단이 보기 좋은가보다 모델이 세는 계산 단위로 어떤 문제가 생기는가를 먼저 떠올리는 습관을 만드는 것입니다.

체크리스트¶

왜 글자 수나 문장 수만으로는 LLM 입력 문제를 설명하기 어려운지 말할 수 있는가?
길이 제한, 비용, 문맥 보존 문제가 모두 다른 계산 단위를 요구한다는 점을 이해했는가?
토큰을 단어 하나나 의미 하나로 단정하지 않고, 모델이 세는 계산 조각으로 먼저 설명할 수 있는가?
토큰이 먼저 문제 해결을 위한 계산 단위로 등장한다는 점을 설명할 수 있는가?

출처와 참고 자료¶

OpenAI Help Center, What are tokens and how to count them?, 확인 날짜: 2026-07-19. 토큰이 모델이 처리하는 텍스트 조각이며 입력·출력 토큰 수가 사용량과 한도 판단에 연결된다는 설명 확인에 사용했다.
OpenAI, tiktoken README, 확인 날짜: 2026-07-19. OpenAI 모델용 BPE tokenizer와 텍스트를 토큰 번호열로 바꾸는 흐름 확인에 사용했다.
Daniel Jurafsky, James H. Martin, Speech and Language Processing, 3rd ed. draft, online manuscript released January 6, 2026, 확인 날짜: 2026-07-19. Words and Tokens 장을 토큰·단어 경계 설명의 일반 NLP 배경 근거로 사용했다.