대형 언어 모델(LLM)을 처음 다루는 개발자가 가장 먼저 마주치는 벽은 모델의 똑똑함이 아니라 “왜 입력이 잘렸지?”, “왜 비용이 이렇게 나오지?” 같은 운영 문제입니다. 이 글에서는 LLM의 작동을 이해하는 데 필수인 토큰, 컨텍스트 윈도우, 비용 구조를 실무 관점에서 정리합니다. 이 세 가지만 정확히 이해해도 첫 프로젝트의 시행착오를 크게 줄일 수 있습니다.
토큰이란 무엇인가
LLM은 글자나 단어가 아니라 토큰 단위로 텍스트를 처리합니다. 토큰은 단어보다 작은 조각으로, 영어는 대략 1토큰이 4글자, 한국어는 보통 1글자가 1~2토큰 정도로 더 많이 소모됩니다. 즉 같은 길이의 문장이라도 한국어가 영어보다 토큰을 더 쓰며, 이는 비용과 컨텍스트 한도에 직접 영향을 줍니다.
예를 들어 “안녕하세요”라는 다섯 글자는 모델에 따라 6~10토큰까지 차지할 수 있습니다. 한국어 서비스를 만들 때 영어 기준 토큰 계산을 그대로 적용하면 실제 비용을 30~50%까지 과소평가하게 됩니다. 반드시 사용하는 모델의 토크나이저로 실제 측정해야 합니다.
컨텍스트 윈도우의 의미
컨텍스트 윈도우는 모델이 한 번에 “기억”할 수 있는 토큰의 총량으로, 입력과 출력을 합산합니다. 예를 들어 128K 컨텍스트 모델이라면 입력 120K를 채우면 출력은 8K밖에 남지 않습니다. 긴 문서를 통째로 넣고 긴 요약을 기대하는 설계가 자주 실패하는 이유가 여기 있습니다.
- 입력 토큰: 시스템 프롬프트 + 사용자 메시지 + 검색으로 붙인 문맥
- 출력 토큰: 모델이 생성하는 답변
- 둘의 합이 컨텍스트 윈도우를 넘으면 오류 또는 앞부분 손실 발생
비용은 어떻게 계산되는가
대부분의 상용 API는 입력 토큰과 출력 토큰에 서로 다른 단가를 매기며, 보통 출력이 입력보다 3~5배 비쌉니다. 따라서 “짧게 질문하고 길게 답을 받는” 패턴은 생각보다 비쌉니다. 월 비용을 추정할 때는 평균 입력 길이, 평균 출력 길이, 일 호출 수를 곱해 보수적으로 잡는 것이 안전합니다.
실무 팁: 출력이 비싸므로 “답변은 3문장 이내로” 같은 길이 제약을 프롬프트에 명시하면 품질 손실 없이 비용을 20~40% 줄일 수 있는 경우가 많습니다.
흔한 실수와 주의점
첫 번째 실수는 컨텍스트 윈도우를 무조건 꽉 채우려는 것입니다. 컨텍스트가 길수록 모델이 중간 정보를 놓치는 “lost in the middle” 현상이 심해지고, 비용과 지연 시간도 함께 늘어납니다. 두 번째는 토큰 수를 추정값으로만 쓰는 것입니다. 운영 환경에서는 실제 토큰 사용량을 로깅해 두어야 비용 이상치를 추적할 수 있습니다.
세 번째는 대화형 서비스에서 이전 대화를 통째로 누적해 보내는 것입니다. 대화가 길어질수록 매 호출의 입력 토큰이 선형으로 증가하므로, 일정 길이를 넘으면 요약해서 압축하는 전략이 필요합니다.
정리와 다음 단계
토큰은 비용과 한도의 단위, 컨텍스트 윈도우는 입출력 합산 한도, 비용은 출력에서 크게 발생한다는 세 가지를 기억하면 LLM 운영의 절반은 이해한 셈입니다. 다음 단계로는 실제 토크나이저로 자신의 데이터를 측정해 보고, 평균 토큰 사용량 기반으로 월 비용 시뮬레이션을 만들어 보길 권합니다. 그 위에 RAG나 파인튜닝 같은 고급 주제를 얹으면 훨씬 탄탄한 설계를 할 수 있습니다.
