컨텍스트 윈도

언어 모델을 처음 제품에 붙이는 팀은 대체로 같은 순서를 밟습니다. 사내 문서를 통째로 넣고 물어보면 답이 나오겠거니 하고, 실제로 짧은 문서에서는 잘 나옵니다. 그래서 다음에는 더 긴 문서를 넣습니다.

거기서 사고가 납니다. 200쪽짜리 계약서를 붙여 놓고 위약금 조항을 물었는데 모델이 그런 조항은 없다고 답합니다. 조항은 분명히 140쪽에 있었습니다. 다만 모델에게 전달된 글은 앞부분에서 끊겨 있었고, 잘려 나간 뒤쪽은 모델에게 처음부터 존재하지 않았습니다. 더 나쁜 것은 모델이 "뒷부분을 못 봤다" 고 말하지 않는다는 점입니다. 자기가 받은 만큼만 보고 확신에 찬 문장으로 답합니다.

컨텍스트 윈도는 이 한계에 붙은 이름입니다. 모델을 쓰는 일이 글을 넣는 일이 아니라 정해진 크기의 자리에 무엇을 넣을지 고르는 일이라는 사실을 드러내는 말이고, AI 개발에서 기능의 모양을 가장 먼저 제약하는 조건입니다.

모델은 요청을 받을 때마다 아무것도 모르는 상태에서 시작합니다. 그 요청에 실어 보낸 글 전체를 그 자리에서 읽고, 읽은 만큼만 가지고 답합니다. 그 글의 길이에 상한이 있고, 길이는 글자가 아니라 토큰 개수로 셉니다. 토큰은 모델이 글을 쪼개 다루는 최소 단위로, 한국어에서는 대체로 한두 글자가 하나입니다.

한 번의 요청에서 그 자리를 나눠 쓰는 것은 넷입니다.

1. 시스템 지시문. 이 기능이 무엇을 하는 물건인지, 어떤 형식으로 답해야 하는지를 적어 둔 고정 문구입니다. 매 요청에 똑같이 실려 갑니다.
2. 대화 기록. 앞서 오간 질문과 답입니다. 대화가 길어질수록 이 몫이 계속 불어납니다.
3. 붙인 자료. 검색해서 끌어온 사내 문서, 사용자가 올린 파일, 데이터베이스에서 뽑은 값입니다.
4. 모델이 쓸 답. 출력도 같은 자리를 씁니다. 입력으로 자리를 거의 다 채우면 답을 쓸 공간이 남지 않아 문장이 중간에 끊깁니다.

창이 20만 토큰이라면 지시문 1천, 자료 15만, 기록 2만을 쓰고 남는 2만 9천이 답의 몫입니다. 계산이 맞아떨어지면 정상으로 돌아가고, 합이 상한을 넘으면 셋 중 하나가 일어납니다. 요청이 오류로 거절되거나, 오래된 대화가 조용히 버려지거나, 붙인 자료의 뒷부분이 잘립니다. 사고가 나는 쪽은 언제나 조용히 처리되는 두 번째와 세 번째입니다. 오류는 화면에 뜨지만 잘림은 아무 신호도 남기지 않아서, 기능이 멀쩡히 돌아가는 것처럼 보이는 채로 답만 틀립니다.

모델이 요청 사이에 아무것도 기억하지 않는다는 점이 중요합니다. 어제 나눈 대화를 오늘 이어 가는 것처럼 보이는 기능은 모델이 기억해서가 아니라, 제품이 그 대화 기록을 저장해 두었다가 오늘 요청에 다시 실어 보내기 때문입니다. 매번 처음 보는 사람에게 회의 자료 전체를 다시 건네는 것과 같고, 그래서 자료가 두꺼워질수록 건네는 비용도 매번 다시 듭니다.

이 값은 기능을 설계할 때 무엇을 넣고 무엇을 뺄지 정하는 기준으로 먼저 등장합니다. 넣고 싶은 것이 창보다 크면 기능의 구조 자체가 달라집니다.

• 긴 문서 다루기. 자료가 창을 넘으면 통째로 넣지 못하므로, 문서를 잘게 쪼개 두었다가 질문과 관련된 대목만 찾아 붙이는 RAG 방식으로 갑니다. 창이 커진다고 이 방식이 사라지지는 않습니다. 관련 없는 내용을 잔뜩 넣으면 답의 정확도가 떨어지기 때문입니다.
• 대화형 기능. 기록이 쌓이면 언젠가 창을 넘기므로 무엇을 버릴지 정해 둡니다. 오래된 순서로 버리거나, 앞부분을 요약해 한 문단으로 접어 두고 최근 대화만 원문으로 남기는 식입니다.
• 비용과 속도. 요금이 토큰 수로 매겨져서 창을 가득 채우면 한 번의 답이 비싸집니다. 읽을 글이 길수록 첫 글자가 나오기까지 걸리는 시간도 함께 늘어납니다.
• 에이전트 구성. 도구를 써 가며 여러 단계를 밟는 구성에서는 각 단계의 결과가 다음 요청에 누적됩니다. 열 단계쯤 가면 창이 차고, 중간을 잘라 내면 앞 단계에서 정한 것을 잊은 채 뒤를 진행하게 됩니다.
• 지시문 설계. 프롬프트 엔지니어링에서 예시를 몇 개까지 넣을지 정하는 것도 결국 이 자리를 나누는 일입니다.

"이 문서 그대로는 컨텍스트 윈도를 넘어서 잘라 넣어야 해요."

자료가 상한보다 커서 일부만 전달되고, 전달되지 않은 부분은 답에 반영되지 않는다는 뜻입니다.

"대화가 길어지면 앞부분이 창에서 밀려나요."

오래된 대화가 버려지고 있어서 사용자가 처음에 말한 조건을 모델이 더는 보지 못한다는 뜻입니다.

"창이 넉넉하니까 관련 문서를 다 넣어 볼까요?"

넣을 수는 있지만 비용과 정확도를 함께 따져 보자는 논의를 여는 말입니다.

페이지덱에서는 사내 문서 검색 기능을 만들면서 이 말이 계속 나왔습니다. 태오가 첫 판을 만들 때는 검색된 문서 열 건을 통째로 붙였고, 회의록처럼 긴 문서가 걸리면 뒤쪽 문서가 잘려 나갔습니다. 사용자가 보기에는 검색 결과에 분명히 있는 내용을 모델이 모른다고 답하는 현상이었습니다.

태오는 문서를 통째로 붙이는 대신 문단 단위로 쪼개 관련된 대목만 넣는 쪽으로 바꿨고, 지현은 답변 화면에 어느 문서의 어느 대목을 봤는지 함께 띄우자고 했습니다. 잘려 나간 것이 있으면 사용자가 알아챌 수 있게 만든 겁니다.

창이 크면 고민이 끝난다고 생각하기 쉽습니다. 100만 토큰짜리 모델이 나오면 문서를 골라 넣는 일이 필요 없어 보입니다. 하지만 넣을 수 있다는 것과 잘 쓴다는 것은 다릅니다. 관련 없는 내용이 많이 섞이면 모델이 엉뚱한 대목을 근거로 삼아 환각이 늘고, 요금은 넣은 만큼 붙고, 답이 나오기까지 걸리는 시간도 길어집니다. 창을 가득 채우는 설계는 대개 세 가지를 한꺼번에 나쁘게 만듭니다.

창을 모델의 기억으로 읽는 오해도 흔합니다. 대화가 이어지는 것처럼 보이니 모델이 앞을 기억한다고 여기게 됩니다. 실제로는 제품이 매 요청마다 앞 대화를 다시 실어 보내고 있을 뿐이고, 그 몫도 토큰으로 계산돼 요금에 포함됩니다. 이 오해를 그대로 두면 왜 대화가 길어질수록 응답이 느려지고 비싸지는지 설명하지 못하고, 앞부분이 밀려나 생긴 문제를 모델 성능 탓으로 돌리게 됩니다.