AI, 추론, 토큰까지 모두 다뤄봅시다!
자, 여러분, 지금 바로 멈춰주세요. “토큰”과 “모델” 같은 용어가 마치 틱톡에서 Gen Z 속어처럼 무분별하게 쓰이는데, 대부분 잘못 이해된 경우가 많습니다.
제 말은 제가 한 그대로입니다.
추론 기반 애플리케이션이 어떻게 구성되는지, 토큰이 생성되고 사용되는 위치와 과정을 명확히 설명하겠습니다. 커피 한잔 준비하시고 바로 시작하겠습니다.
추론 서버가 무엇인지 알고 계신가요?
여기서부터 시작할 필요는 없지만 그렇게 하겠습니다. “추론”이라 할 때, 우리는 대규모 언어 모델(LLM)이 방대한 데이터를 바탕으로 사고하는 방식을 말하는 겁니다. LLM에 직접 호출하지는 않습니다. “LLM API”라는 건 사실 없습니다. 그렇게 말하면 제가 엄마의 눈빛으로 바라볼 겁니다.
추론을 호출하는 API는 추론 서버를 거쳐 처리됩니다.
추론 서버는 AI 모델 실행 환경이며, 앱 서버가 Java 등 다양한 개발 언어의 실행 환경인 것과 같습니다. 추론 서버 없이 로컬에서 모델을 실행하는 경우는 드뭅니다. Ollama, vLLM, NVIDIA Triton, HuggingFace Text Generation Interface(TGI) 등이 널리 사용됩니다.
이제 일반적으로 애플리케이션 패키지를 배포하는 앱 서버처럼 추론 서버에 “AI 패키지”(모델)를 배포합니다. 이 서버는 텍스트 생성, 토큰화, 임베딩처럼 모델 추론 작업에 집중된 최소한의 API 엔드포인트(예: REST나 gRPC의 /generate, /completions, /embeddings)를 통해 AI 모델 기능을 제공합니다.
추론 서버와 상호 작용하려면 앱을 만들어야 합니다. 네, 기존 애플리케이션(물론 최신 애플리케이션일 수도 있지만요. 당연히 그럴 수도 있으니까요)을 만들면 추론 서버와 통신하게 됩니다.
사용자는 브라우저나 휴대폰에서 앱을 받아서, 보통 평범한 API로 직접 만든 앱과 소통합니다. 자, 완성입니다! 클라이언트에서 앱, 추론 서버로, 그리고 다시 돌아오는 메시지 흐름이 완벽하게 연결됩니다.
맞습니다. 데이터 계층 대신 추론 계층을 적용한 3계층 웹 애플리케이션을 새롭게 해석한 것뿐입니다. 솔직히, 기대에 미치지 못하죠?
가장 기본적인 AI 애플리케이션은 데이터 계층을 추론 서버로 교체한 3계층 웹 애플리케이션입니다.
- JSON 요청을 받으면, 필요에 따라 검색 증강 생성(RAG)을 수행한 후 JSON으로 추론 서버를 호출합니다. RAG는 보통 사용자 쿼리를 임베딩하고, 벡터 또는 검색 인덱스에서 유사한 내용을 찾아 그 스니펫을 프롬프트에 연결하는 과정을 말합니다. 모두 JSON 트래픽으로 이루어집니다. 아직 모델 토큰은 생성되지 않았습니다.
- 추론 서버가 JSON을 파싱하고 텍스트를 모델 토큰으로 토큰화한 후, 컨텍스트와 할당량을 확인하며 호환되는 요청들을 묶어 처리하고 모델을 실행한 뒤 출력 토큰을 다시 텍스트로 디코딩합니다. 호출자에게 JSON 응답을 반환합니다. 스트리밍 모드에서는 토큰이 생성되는 즉시 디코딩되어 전송됩니다. 대부분 API에는 입력 및 출력 토큰 수가 포함된 사용 정보를 제공합니다.
그것이 추론입니다. 세션, 쿠키, 쿼리 대신 토큰, 컨텍스트, 스트림으로 표현되지만, 기본적으로 우리가 변함없이 소중히 여겨 온 운영 원칙을 반영하는 새로운 애플리케이션 워크로드입니다.
그렇다면 토큰은 어디에 있을까요?
사람들이 주로 헷갈려서 용어의 기본 원칙을 어기는 방식으로 단어를 사용하는 지점입니다. 토큰은 LLM이 처리하는 단어의 단위입니다. 추론 서버에서 토크나이저가 이를 공식적으로 생성합니다.
앱에 토크나이저를 포함해 비용 예측과 지역별 속도 제한을 위해 미리 토큰 수를 계산할 수 있습니다. 다만, 정확한 토큰 수는 추론 단계에서 결정됩니다. 토큰은 네트워크 트래픽이 아닌 모델 내부 표현이며, 네트워크에는 JSON 텍스트가 전송됩니다. API가 명확히 토큰 ID를 반환할 때만 확인할 수 있습니다.
기본적으로 인프라는 토큰을 인식하지 않습니다. 인프라는 JSON만 봅니다. 토큰은 네트워크를 통해 전송되지 않습니다. 인프라에서 토큰을 처리하려면 동일한 토크나이저로 게이트웨이에서 직접 토큰을 계산하거나, 모델 서버가 제공하는 개수를 활용해야 합니다. 토큰은 AI의 기본 단위이지만, 다룰 의지가 없다면 대부분 추론 스택 내부에 머뭅니다.
인프라에 미치는 추론의 영향
추론은 신비로운 과정이 아닙니다. 새로운 제어값을 가진 애플리케이션 워크로드입니다. 트래픽은 JSON 형식입니다. 토큰은 모델의 단위입니다. 임베딩은 벡터로 표현됩니다. 이들을 혼동하면 잘못된 제어를 설계하고, 가격을 틀리게 책정하며, 잘못된 레이어에서 문제를 해결하게 될 것입니다. 예를 들어, 토큰 수 대신 JSON 크기를 기준으로 라우팅하면 긴 컨텍스트 요청 때문에 모델이 과부하될 수 있습니다.
인프라가 토큰을 기반으로 작동하려면 그 방법을 알려주세요. 게이트웨이에 토크나이저를 배치하거나 모델 서버에서 발생하는 토큰 수를 활용하세요. 그렇지 않으면 라우터는 텍스트만 인식해 텍스트 단위로 결정을 내리고, 청구는 토큰 단위로 발생하게 됩니다. 정확한 집계를 위해 토크나이저가 모델과 일치해야 한다는 점을 기억하세요(예: GPT-4와 LLaMA의 토크나이저는 다릅니다). 불일치하는 토크나이저는 비용이나 제한 계산에 오류를 일으킬 수 있습니다.
가용성을 단순히 동작하는 상태가 아니라, 실질적으로 사용 가능하고 정확한 상태로 인식하세요. 초당 토큰 수, 첫 토큰이 생성되는 시간, 그리고 컨텍스트 실패(컨텍스트 창 제한 초과나 포화된 컨텍스트에서 발생하는 비논리적 출력)를 초당 쿼리 수와 캐시 적중률을 관리하듯 꼼꼼히 추적하세요. 로그는 반드시 신중하게 기록하세요. 추론 트래픽은 직접 명시하지 않는 한 훈련 데이터로 사용하지 않습니다. 프롬프트와 결과를 저장한다면 반드시 안전하게 보호하세요.
이름을 정확하게 붙이세요. 적절한 계층을 측정하세요. 비용 초과를 막으려면 게이트웨이에서 토큰 기반 할당량 같은 핵심 위치에 한도를 설정하세요. 그렇게 하면 추론은 나머지 시스템처럼 예측 가능하고 합리적인 비용으로 안정적으로 작동합니다. 토큰은 네트워크 대역폭이 아니라 모델 내부에서 결정을 구매합니다. 이름을 정확히 부르면 사용자 만족도는 높아지고 청구액은 줄어듭니다.