롱 컨텍스트

LLM이 수십만~수백만 토큰을 조각내지 않고 통째로 받아 처리하는 능력이다. 긴 코드베이스, 계약서, 책 한 권처럼 전체를 엮어 봐야 하는 자료를 한 번에 넣고 질문할 때 쓴다. 예전처럼 잘라서 따로 요약한 뒤 합칠 필요가 없다.

한 번에 넣을 수 있는 토큰 수. 100만 토큰이면 코드 약 5만 줄, 장편소설 여덟 권 정도다.

통째로 넣을지, RAG로 골라 넣을지

질문이 어떤 성격인지에 따라 정한다. 자료 전체를 엮어 봐야 하는 질문이면 통째로 넣고, 많은 문서 가운데 한두 곳에만 답이 있으면 RAG로 골라 넣는 편이 싸고 정확하다.

긴 문서는 앞에, 질문은 끝에

API로 긴 자료를 넣을 때는 문서를 프롬프트 앞쪽에 두고 질문을 맨 끝에 두면 더 정확하다. 같은 문서에 여러 번 질문한다면 프롬프트 캐싱으로 앞부분을 재사용해 비용과 첫 응답 지연을 함께 줄인다.

예시 수백 개를 프롬프트에 그대로 넣는 매니샷 인컨텍스트 학습도 가능하다. 분류처럼 답 형식이 정해진 작업이라면 파인튜닝 없이 비슷한 효과를 낼 때도 있다.

코딩 에이전트는 창이 금방 찬다

Claude Code 같은 에이전트는 파일을 읽고, 테스트를 돌리고, 로그를 보는 기록이 모두 컨텍스트에 쌓인다. 창이 길면 초반에 읽은 설계 의도를 잊지 않고 오래 작업을 이어간다. 시스템 프롬프트, 도구 정의, 도구 결과, 출력까지 모두 같은 창을 나눠 쓰기 때문에 긴 빌드 로그 몇 개만 붙여도 금세 찬다.

한계에 가까워지면 앞부분 대화를 요약해 자리를 비우는 컴팩션이 자동으로 돌고, Claude Code에서는 /compact로 직접 압축할 수도 있다.

넣을 수 있다고 다 읽지는 않는다

모델은 입력의 처음과 끝은 잘 찾지만 가운데 묻힌 정보는 자주 놓친다. 입력이 길어질수록 성능이 떨어지고 비슷하지만 틀린 문장에 쉽게 흔들리는데, 이를 컨텍스트 부패(context rot)라고 부른다. 실제로 쓸 만한 길이가 광고된 길이의 절반쯤인 모델도 많다.

토큰이 늘면 비용과 응답 시간도 늘어난다. "다 넣으면 알아서 찾겠지"라고 기대하지 말고, 필요한 부분만 골라 넣는 RAG나 컨텍스트 엔지니어링과 같이 쓰는 것이 가장 좋다.

긴 자료를 한 번에 맡기는 곳에서 쓴다

가장 흔한 쓰임은 코딩 에이전트와 긴 문서 검토다. 자료가 서로 얽혀 있어서 잘라 보면 놓치는 게 생기는 일에 주로 쓴다.