기준: AIF-C01 시험 가이드오류 제보
어제 우리는 LLM이 "다음 토큰을 확률적으로 예측"한다고 배웠다. 그런데 모델은 컴퓨터다. 컴퓨터는 글자를 모른다. 숫자만 안다. 그렇다면 "오늘 날씨가 좋다"라는 한국어 문장이 도대체 어떻게 숫자로 바뀌어 모델에 들어가고, 어떻게 다시 글자로 나오는 걸까?
오늘은 LLM 내부에서 텍스트가 처리되는 여정을 4개의 핵심 개념으로 따라간다. 토큰(token) → 임베딩(embedding) → 컨텍스트 윈도우(context window) → 추론(inference). 이 네 단어는 AIF 시험에 직접 나오기도 하고, 비용·성능을 이해하는 열쇠이기도 하다. 수식 없이, 그림을 그리듯 이해하는 게 목표다.
LLM은 문장을 통째로 받지 않는다. 토큰이라는 작은 조각으로 잘라서 처리한다. 토큰은 단어일 수도, 단어의 일부일 수도, 글자 하나일 수도 있다.
"생성형 AI는 멋지다"
→ 토큰화 → ["생성", "형", " AI", "는", " 멋", "지다"] (예시)
"unbelievable"
→ ["un", "believ", "able"] (영어는 보통 단어 조각으로 쪼개짐)
왜 단어가 아니라 이렇게 어중간하게 자를까? 세상의 모든 단어를 사전에 넣을 수는 없기 때문이다. 자주 쓰는 조각(subword)만 사전에 두면, 처음 보는 단어도 조각을 조합해 표현할 수 있다. 이걸 서브워드 토크나이징이라고 한다.
실무에서 토큰이 중요한 이유는 두 가지다.
영어는 대략 "1 토큰 ≈ 0.75 단어", "100 토큰 ≈ 75 단어" 정도의 경험칙이 있다. 한국어·중국어·일본어는 글자 하나가 여러 토큰으로 쪼개지는 경우가 많아 같은 의미라도 영어보다 토큰을 더 많이 소비하는 경향이 있다. 그래서 다국어 애플리케이션의 비용을 추정할 때는 언어별 토큰 효율 차이를 고려해야 한다. AIF 시험에서 "비용 절감" 시나리오가 나오면 프롬프트/응답 길이를 줄여 토큰을 아끼는 것이 정석 답이다.
토큰으로 잘랐어도 아직 글자다. 이제 각 토큰을 숫자 벡터로 바꾼다. 이걸 임베딩이라고 한다. 임베딩은 보통 수백~수천 개의 숫자로 이뤄진 리스트다.
"왕" → [0.21, -0.47, 0.88, ... ] (예: 1536개 숫자)
"여왕" → [0.19, -0.42, 0.91, ... ] (왕과 비슷한 위치)
"사과" → [-0.66, 0.13, -0.05, ... ] (왕과 멀리 떨어진 위치)
핵심은 의미가 비슷한 단어는 벡터 공간에서 가까이 위치한다는 점이다. "왕"과 "여왕"은 가깝고, "왕"과 "사과"는 멀다. 모델은 이 숫자 공간에서 단어 사이의 관계를 계산한다. 유명한 예가 "왕 - 남자 + 여자 ≈ 여왕"이라는 벡터 산수다.
이 "의미의 거리"를 활용하는 대표 응용이 시맨틱 검색과 RAG(검색 증강 생성)다. 질문을 임베딩으로 바꾸고, 문서들도 임베딩으로 바꿔두면, 단순 키워드가 아니라 "의미가 가까운" 문서를 찾을 수 있다.
🔍 더 깊이: AWS에서 임베딩을 만드는 대표 모델이 Amazon Titan Embeddings나 Cohere Embeddings로, Bedrock에서 호출한다. 만든 임베딩 벡터는 벡터 데이터베이스(예: Amazon OpenSearch의 벡터 검색, Aurora pgvector, Amazon Kendra)에 저장해 유사도 검색을 한다. 두 벡터가 얼마나 가까운지는 보통 코사인 유사도(cosine similarity)로 잰다. AIF 시험에서 "사내 문서를 기반으로 답하는 챗봇"이 나오면 임베딩 + 벡터 DB + RAG 조합을 떠올리면 된다.
컨텍스트 윈도우(context window)는 모델이 한 번에 "동시에 볼 수 있는" 토큰의 최대 개수다. 입력(프롬프트)과 출력(응답)을 합친 토큰이 이 한도를 넘으면 안 된다. 사람으로 치면 "한 번에 머릿속에 담을 수 있는 분량"이다.
| 컨텍스트 윈도우 | 대략 분량 | 의미 |
|---|---|---|
| 4K 토큰 | 약 3,000단어 | 짧은 대화, 간단한 요약 |
| 32K 토큰 | 약 24,000단어 | 긴 문서 분석 |
| 200K 토큰 | 약 15만 단어 | 책 한 권 수준의 문맥 |
컨텍스트 윈도우가 중요한 이유:
⚠️ 함정: "모델이 우리 회사의 모든 데이터를 다 기억한다"는 오해하기 쉽다. 틀렸다. 모델은 학습 때 본 것 외에는 그때그때 컨텍스트 윈도우에 넣어준 것만 안다. 윈도우를 벗어난 내용은 모른다. 그래서 방대한 사내 지식을 다루려면 모델에 다 넣는 게 아니라, RAG로 "질문과 관련된 일부만 골라" 윈도우에 넣어주는 방식을 쓴다.
추론(inference)은 이미 학습이 끝난 모델에 입력을 넣어 출력을 받는 과정이다. 학습(training)과 추론(inference)을 구분하는 게 중요하다.
| 구분 | 학습(Training) | 추론(Inference) |
|---|---|---|
| 하는 일 | 데이터로 모델 파라미터를 조정 | 완성된 모델로 답을 생성 |
| 빈도 | 한 번(또는 가끔 재학습) | 매 요청마다 |
| 비용 구조 | 막대한 일회성 비용 | 요청당 토큰 기반 비용 |
| AIF에서의 위치 | FM 제공사가 주로 담당 | 사용자가 매일 쓰는 부분 |
추론할 때 출력의 "성향"을 조절하는 대표 파라미터가 temperature(온도)다.
이 외에도 Top-P(nucleus sampling), Top-K 같은 파라미터로 후보 토큰의 범위를 조절한다. 응답 길이는 max tokens로 제한한다.
temperature는 확률 분포를 "평평하게" 또는 "뾰족하게" 만드는 조절 손잡이다. 온도가 0에 가까우면 분포가 뾰족해져 거의 항상 1등 토큰만 뽑히고(결정적에 가까움), 온도가 높으면 분포가 평평해져 하위 토큰도 뽑힐 확률이 커진다(다양성↑). 같은 프롬프트에 매번 다른 답이 나오는 비결정성의 상당 부분이 이 샘플링에서 비롯된다. 일관성이 중요한 업무 자동화에서는 temperature를 낮게 잡는 것이 기본이다.
사용자 입력: "이 메일을 요약해줘: ..."
│
▼ ① 토큰화 → ["이", " 메일", "을", " 요약", ...]
│
▼ ② 임베딩 → 각 토큰을 의미 벡터로 변환
│
▼ ③ 컨텍스트 윈도우 안에서 Transformer가 관계 계산
│
▼ ④ 추론(다음 토큰 예측을 반복) — temperature로 성향 조절
│
▼ 출력: "이 메일은 회의 일정 변경을 알리는 내용입니다."
이 흐름을 이해하면 "왜 긴 프롬프트가 비싼가(토큰↑)", "왜 같은 질문에 답이 다른가(샘플링)", "왜 사내 문서를 다 못 넣나(컨텍스트 윈도우 한도)"가 한꺼번에 설명된다.
가상의 사례로, 한 핀테크 스타트업은 고객 약관 Q&A 챗봇을 만들면서 처음엔 약관 전문(全文)을 매 질문마다 프롬프트에 넣었다. 토큰이 폭증해 비용이 치솟고 응답도 느려졌다. 이후 약관을 잘게 나눠 임베딩으로 벡터 DB에 저장하고, 질문과 의미가 가까운 조각만 골라 넣는 RAG로 바꾸자 토큰 사용량이 크게 줄고 응답 속도와 정확도가 모두 개선됐다. 토큰·임베딩·컨텍스트 윈도우를 이해하면 이런 설계 결정이 자연스러워진다.
오늘의 그림은 4단계다. 토큰으로 텍스트를 자르고, 임베딩으로 의미를 가진 숫자로 바꾸고, 컨텍스트 윈도우라는 작업 기억 안에서 처리하며, 추론으로 다음 토큰을 반복 예측해 답을 만든다. 그리고 비용은 토큰에, 기억의 한계는 컨텍스트 윈도우에, 출력의 다양성은 temperature에 달려 있다.
다음 글에서는 이 모델에게 "어떻게 말을 걸어야 원하는 답이 나오는가" — 프롬프트 엔지니어링의 기초를 본다. 같은 모델이라도 프롬프트를 어떻게 쓰느냐에 따라 결과가 완전히 달라진다.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
LLM에서 "토큰(token)"에 대한 설명으로 가장 정확한 것은?
문제 2
임베딩(embedding)의 핵심 특성으로 옳은 것은?
문제 3
컨텍스트 윈도우(context window)가 의미하는 것은?
문제 4
사실 기반의 일관된 분류 작업을 자동화하려 한다. temperature 설정으로 가장 적절한 것은?
문제 5
학습(training)과 추론(inference)의 차이로 옳은 것은?