토큰

사람은 글의 길이를 글자나 단어로 셉니다. 모델은 그렇게 세지 않습니다. 이 차이를 모르면 한도와 비용이 둘 다 어긋나는데, 어긋난다는 사실을 알아채는 시점이 보통 운영 중입니다.

페이지덱이 문서 요약 기능을 만들 때 그랬습니다. 대규모 언어 모델에 문서를 넣어 세 줄 요약을 받는 기능인데, 많은 텍스트로 학습해 언어를 다루는 모델입니다. 태오가 입력 한도를 문서 5,000자로 걸었습니다. 그런데 어떤 문서는 통과하고 어떤 문서는 한도를 넘었다는 오류가 났습니다. 글자 수는 같았습니다.

갈린 기준은 언어였습니다. 영문 회의록 5,000자는 문제없이 들어갔고 같은 길이의 한글 문서는 막혔습니다. 모델이 세는 단위가 글자가 아니라 토큰이고, 같은 글자 수라도 언어에 따라 토큰 수가 두세 배 차이 났기 때문입니다. 한도를 글자로 걸어 둔 것이 원인이었습니다.

글을 자주 나오는 덩어리 단위로 쪼개고, 그 덩어리 하나를 토큰 하나로 셉니다. 덩어리 목록은 모델을 만들 때 학습 데이터에서 정해지므로, 자주 나온 문자열은 하나로 묶이고 드문 문자열은 여러 조각으로 갈라집니다.

1. 흔한 단어는 통째로 하나입니다. 영어에서 the 나 have 처럼 자주 나오는 단어는 1토큰입니다.
2. 드문 단어는 조각으로 갈립니다. 사람 이름이나 전문 용어는 두세 조각이 되고, 무작위 문자열은 글자마다 하나씩 잡히기도 합니다.
3. 띄어쓰기와 줄바꿈도 토큰에 포함됩니다. 그래서 같은 내용을 줄바꿈 없이 붙여 쓰면 토큰이 조금 줄어듭니다.
4. 언어별 차이가 큽니다. 영어는 4글자쯤이 1토큰인 경우가 많고 한국어는 한 글자가 1토큰에서 2토큰 사이입니다. 같은 뜻의 문서가 한국어에서 두세 배 토큰을 씁니다.
5. 입력과 출력을 따로 셉니다. 모델에 넣은 글과 모델이 내놓은 글이 각각 계산되고, 한도는 둘의 합에 걸립니다.

정확한 수는 모델마다 다릅니다. 쪼개는 규칙이 모델별로 달라서 같은 문장이 한 모델에서 12토큰, 다른 모델에서 15토큰이 됩니다. 그래서 어림값으로 설계하고 실제 값은 호출 결과로 확인합니다. 모델을 호출하는 API의 응답에 사용된 토큰 수가 함께 돌아옵니다. 프로그램끼리 주고받기로 약속한 창구인데, 그 응답의 사용량 항목이 유일하게 믿을 수 있는 숫자입니다.

가장 먼저 걸리는 자리는 비용 추산입니다. 요금이 토큰 단위로 붙기 때문입니다. 입력 100만 토큰에 6,500원, 출력 100만 토큰에 2만 6,000원 하는 식으로 입력보다 출력이 비쌉니다. 문서 요약 한 건이 입력 8,000토큰과 출력 500토큰이면 한 건에 65원입니다. 하루 2,000건이면 한 달에 390만 원이 됩니다. 기능을 만들기 전에 이 계산을 해 두면 어디를 줄여야 하는지가 정해집니다.

나머지 세 자리는 이렇습니다.

1. 입력 제한 — 사용자가 넣을 수 있는 길이를 토큰으로 정합니다. 화면에는 글자 수로 안내해도 되지만, 막는 판정은 토큰으로 합니다. 한글과 영문이 섞인 문서에서 글자 기준은 반드시 어긋납니다.
2. 넣을 내용 고르기 — 긴 문서를 통째로 넣는 대신 필요한 부분만 찾아 붙입니다. 외부 자료를 찾아 붙여 답을 만들게 하는 방식이 RAG인데, 이 방식을 쓰는 이유의 절반이 토큰을 줄이는 데 있습니다. 문서 300쪽을 매번 넣을 수는 없습니다.
3. 출력 길이 제한 — 모델이 내놓을 최대 토큰 수를 걸어 둡니다. 걸어 두지 않으면 요약을 부탁했는데 원문만큼 긴 답이 돌아오는 일이 생기고, 출력이 비싼 쪽이라 비용이 먼저 튑니다.

지시문을 다듬는 프롬프트 엔지니어링에서도 이 단위를 봅니다. 모델이 원하는 답을 내도록 지시문을 설계하는 일인데, 예시를 많이 넣으면 답이 좋아지는 대신 예시가 매 호출마다 토큰으로 계산됩니다. 예시 다섯 개가 답을 얼마나 좋게 만드는지와 얼마를 더 쓰게 하는지를 함께 재야 판단이 됩니다.

사용자에게 보여 주는 안내에는 이 단위를 쓰지 않습니다. 토큰 8,000개까지라는 문구는 사용자에게 아무 정보도 아닙니다. 화면에는 A4 열 장쯤이라고 적고 안에서 토큰으로 판정합니다.

"한도를 글자로 걸어 두면 안 돼요. 한글 문서가 먼저 막힙니다."

세는 단위가 글자가 아니라는 지적입니다.

"이 기능 한 건에 65원인데 하루 2,000건이면 한 달에 390만 원입니다."

토큰 단가로 운영 비용을 추산한 보고입니다.

"출력 토큰 상한을 안 걸었네요. 요약이 원문보다 길게 나옵니다."

응답 길이를 제한하지 않았다는 지적입니다.

태오가 한도를 다시 걸었습니다. 문서를 넣기 전에 토큰 수를 세어 8,000을 넘으면 앞부분만 쓰도록 바꾸고, 화면에는 긴 문서는 앞부분만 요약된다는 안내를 붙였습니다. 출력 상한은 400토큰으로 걸었습니다.

그 뒤로 한도 초과 오류는 사라졌고 한 건당 비용이 65원에서 52원으로 내려갔습니다. 지현이 물은 것은 그다음이었습니다. 앞부분만 요약하는 것이 사용자에게 쓸모가 있는지였습니다. 그 질문 때문에 다음 분기에 문서를 나눠 여러 번 호출하는 방식으로 다시 만들었습니다.

토큰을 단어와 같은 것으로 보는 경우가 가장 많습니다. 영어에서 흔한 단어가 실제로 1토큰이니 자연스러운 오해입니다. 하지만 사람 이름 하나가 세 토큰이 되고 이모지 하나가 여러 토큰이 되는 일이 흔합니다. 단어로 어림하면 한국어와 코드가 섞인 입력에서 두 배 이상 틀립니다. 이 오해를 그대로 두면 비용 추산이 절반으로 나오고, 그 숫자로 승인받은 기능이 출시 한 달 뒤에 예산을 넘깁니다.

한도가 입력에만 걸린다고 보는 것도 흔합니다. 넣는 쪽을 신경 쓰다 보면 그렇게 생각하게 됩니다. 그런데 한도는 입력과 출력의 합에 걸립니다. 입력을 한도 가까이 채워 넣으면 모델이 답할 자리가 남지 않아서, 답이 중간에 끊기거나 아예 오류가 납니다. 긴 입력을 다루는 기능에서는 출력에 쓸 몫을 미리 떼어 두고 입력 한도를 정합니다.