Tokens & Context Window

처음 실험할 때는 질문 몇 줄만 넣어도 답이 나와서 이 한계를 잘 못 느낍니다. 그런데 실제 서비스로 가면 정책 문서도 붙고, 이전 대화도 따라오고, 검색 결과나 도구 응답도 같이 실어야 합니다. 그러다 보면 중요한 지시가 뒤로 밀리거나, 참고 문서가 잘리거나, 답변 길이를 남기지 못해 응답이 중간에서 끊깁니다. 결국 문제는 단순히 길다는 데 있지 않고, 이번 호출에 무엇을 살리고 무엇을 덜어낼지 계속 골라야 한다는 데 있습니다.

초기 LLM 사용은 짧은 프롬프트 한 번으로 끝나는 경우가 많아서 context window를 모델 스펙 정도로만 봐도 됐습니다. 하지만 챗봇, RAG, 에이전트처럼 여러 정보원을 한 호출에 묶는 패턴이 보편화되면서, 이 개념은 단순한 숫자가 아니라 요청 설계 전체를 좌우하는 제약으로 읽히게 됐습니다.

애플리케이션은 시스템 지시, 현재 질문, 최근 대화, 검색 문서, 도구 결과를 하나의 입력 묶음으로 만들어 모델에 보냅니다. 모델은 이것을 tokenizer가 자른 토큰 단위로 읽고, 같은 예산 안에서 답변도 만들어야 합니다. 그래서 입력을 많이 넣을수록 출력에 쓸 공간은 줄고, 반대로 답을 길게 받아야 하면 앞단의 문맥을 더 과감히 줄여야 합니다. 한도에 가까워지면 오래된 대화를 요약하거나, 검색 결과를 덜 넣거나, 아예 호출을 둘로 나누는 식의 조정이 필요합니다.

context window는 이번 호출 안에 얼마나 실을 수 있는지를 다루는 개념입니다. memory가 다음 호출까지 무엇을 남길지의 문제라면, context engineering은 지금 이 좁은 공간에 무엇을 우선해서 넣을지의 문제에 가깝습니다. 셋이 같이 등장하는 경우가 많지만, 현재 호출이 자꾸 넘치고 잘린다면 먼저 context window가 드러난 상황으로 읽는 편이 자연스럽습니다.

실무에서는 긴 문서를 통째로 넣기보다 먼저 요약하거나 필요한 부분만 추립니다. RAG에서는 검색 결과를 많이 가져오는 것보다 지금 답변에 정말 필요한 조각만 남기는 편이 낫고, 에이전트에서는 도구 결과 전체 대신 핵심 필드만 다시 넣는 식으로 예산을 아낍니다. window가 크다고 안심하고 계속 쌓아 넣으면 비용과 지연이 같이 커지고, 정작 중요한 지시가 묻혀 버리기 쉽습니다.