LLM 컨텍스트 길이와 긴 입력 처리¶
한 줄 요약: LLM이 한 번에 볼 수 있는 글의 양(컨텍스트)에는 한도가 있다. 하지만 실무에서 더 자주 터지는 건 "안 들어감"이 아니라 나눈 조각끼리 맥락이 끊기고, 뒤쪽을 얕게 다루고, 시간과 사용량이 불어나는 문제다.
📍 만난 상황¶
- 2026-11-11 12:06 — 학습 일지 형식을 다듬던 중이었다. 직전에 "세션 개수와 세션별 주제 한 줄을 넣어 세 번째 미리보기를 돌린다"는 보고를 들었다. 그러다 세션이 너무 많거나 길면 요약에 문제가 생기냐고 물었다. 입력이 길면 "다 안 들어가서" 실패할 거라고만 생각했다. → 그날 일지
🧩 쉽게 말하면¶
LLM을 책상 하나를 쓰는 편집자라고 하자. 책상(컨텍스트) 위에 올린 원고만 볼 수 있다.
- 원고가 책상보다 크면 나눠서 줘야 한다. 그런데 2부를 받은 편집자는 1부를 못 봤다.
- 책상이 아주 커도, 원고 300장을 한꺼번에 주면 앞쪽은 꼼꼼히 보고 뒤쪽은 훑고 만다.
- 원고를 한 장 고칠 때마다 책상 위 전체를 다시 훑으니, 원고가 많을수록 시간이 오래 걸린다.
이걸 모르면 "책상에만 들어가면 괜찮겠지" 하고 설계했다가 품질이 조용히 떨어진다.
📖 제대로 알기¶
토큰¶
- 토큰(token: 모델이 글을 다루는 최소 단위)은 단어나 글자 조각이다. 영어는 대략 단어 하나가 토큰 1~2개다. 한국어는 글자 하나가 토큰 1개 안팎인 경우가 많다.
- 길이 한도, 속도, 요금이 모두 토큰 수로 정해진다.
컨텍스트 윈도¶
- 컨텍스트 윈도(context window: 모델이 한 번에 볼 수 있는 토큰 수의 한도)는 입력과 출력을 합친 한도다.
- 입력에는 시스템 지시, 이전 대화, 도구 결과, 이번 질문이 모두 들어간다.
- 오늘 기준 Opus는 100만 토큰짜리 컨텍스트를 쓸 수 있다. 세션 10개치 재료도 들어가는 크기다.
길이 한도 말고 생기는 문제¶
- 맥락 끊김: 입력을 조각으로 나눠 따로 처리하면, 각 처리는 다른 조각을 모른다.
- 주의 분산: 긴 입력에서 모델은 앞부분과 끝부분을 잘 쓰고 중간이나 뒤쪽을 덜 반영하는 경향이 있다. 연구에서는 "lost in the middle"이라고 부른다.
- 턴 누적: 대화형·에이전트 작업은 턴마다 앞 내용 전체를 다시 입력으로 넣는다. 턴이 늘면 처리 시간과 사용량이 계속 커진다.
- 사용량 한도: 구독이든 API든 일정 기간 쓸 수 있는 양이 정해져 있다. 큰 작업이 한도를 먼저 써 버리면 실패하거나 다른 작업이 막힌다.
⚙️ 어떻게 동작하나¶
학습 일지 정리가 긴 입력을 다루는 순서다.
- 1단계(세션별 정리): 세션 기록을 읽는다. 12만 자를 넘으면 12만 자씩 자른다.
- 각 조각을 따로 Claude에 넣어 정리 메모를 받는다. 지금 구조에선 두 번째 조각을 맡은 Claude는 첫 번째 조각을 모른다.
- 2단계(하루 종합): 하루치 메모 전체를 한 번의 Claude 실행에 넣는다.
- 그 실행 안에서 일지와 주제 파일을 차례로 쓴다. 파일 하나를 쓸 때마다 턴이 하나 늘고, 턴마다 앞 내용을 다시 읽는다.
- 전체가 제한 시간(30분)을 넘기면 그날 정리가 통째로 실패한다.
개선된 흐름은 조각마다 앞 조각의 요약을 함께 넘긴다.
flowchart LR
A["조각 1"] --> S1["정리 1"]
S1 -->|"지금까지 흐름 요약"| S2["정리 2"]
B["조각 2"] --> S2
S2 -->|"지금까지 흐름 요약"| S3["정리 3"]
C["조각 3"] --> S3🧪 예시¶
- 예시 1 · 일상에 빗대어: 회의록 3시간분을 세 사람이 1시간씩 나눠 요약한다고 하자.
- 2번 요약자는 1시간째에 "A안은 폐기"로 결론 난 걸 모른다. 그래서 2시간째에 나온 "A안"을 살아 있는 안처럼 적는다.
- 3번 요약자는 1시간째에 이미 설명된 용어를 "새로 나온 개념"으로 다시 적는다.
- 한 사람이 3시간을 다 듣고 요약하면 이런 일은 줄지만, 마지막 1시간은 지쳐서 얕게 적는다.
-
그래서 각자에게 "앞 사람 요약 5줄"을 함께 주고, 전체 분량도 필요한 회의 안건만 추려서 준다.
-
예시 2 · 실제로는: 하루 규모별 예상(오늘 실측 기준)이다.
| 하루 규모 | 2단계 예상 | 위험 |
|---|---|---|
| 세션 2개 (오늘) | 6~7분, 17턴 | 없음 |
| 세션 5개 | 15~20분 | 대체로 괜찮음 |
| 세션 8개+, 주제 20~30개 | 30분 초과 가능 | 그날 정리 전체 실패 |
① 세션당 약 7만 자였다. 하루 종일 이어지는 세션은 12만 자를 쉽게 넘겨 조각이 생긴다. ② 입력 길이 자체는 100만 토큰 안에 들어간다. 문제는 턴 수와 시간이다. ③ 1단계는 세션을 하나씩 차례로 처리한다. 세션당 2~3.5분이면 세션 10개에 1단계만 30분을 넘는다. ④ 오늘 규모만으로도 API 요금으로 환산하면 3~5달러 수준을 쓴다. 18시 실행은 근무 시간과 겹쳐, 대화 중인 Claude와 같은 구독 한도를 나눠 쓴다.
⚖️ 비교 · 흔한 오해¶
| 문제 | 겉으로 보이는 모습 | 대책 |
|---|---|---|
| 한도 초과 | 오류로 바로 실패 | 자르기, 재료 줄이기 |
| 맥락 끊김 | 배경이 비거나 중복 | 앞 요약 넘기기 |
| 뒤쪽 얕음 | 뒤 세션 설명이 짧음 | 작업을 나누기 |
| 시간·한도 | 중간 실패, 지연 | 병렬, 상한, 재시도 |
오해: "컨텍스트에 들어가기만 하면 괜찮다" 들어가는 것과 잘 쓰는 것은 다르다. 한도 초과는 오류가 나서 바로 알아챈다. 하지만 맥락 끊김과 뒤쪽 얕음은 오류 없이 결과만 나빠진다. 그래서 더 위험하다.
왜 그렇게 생각하기 쉬운가: "100만 토큰" 같은 숫자가 가장 눈에 띄는 사양이다. 그리고 실패를 떠올리면 보통 "오류 메시지"를 떠올린다. 품질이 조용히 떨어지는 실패는 직접 결과를 비교해 봐야 보인다.
🛠️ 실무에서는¶
- 근본 대책은 넣는 양을 줄이는 것이다. 필요한 부분만 추린다(오늘 구조에선 대화 원문 대신 질문·설명만 뽑았다).
- 작업을 나눈다: 일지 작성 1회, 주제 파일은 3~5개씩 따로. 하나가 실패해도 나머지는 남는다.
- 상한을 둔다: 하루 주제 수를 10개 정도로 제한한다. 넘치는 건 표 한 줄로만 남긴다.
- 나눌 땐 앞 요약을 넘긴다: "지금까지의 흐름"을 다음 조각에 붙인다.
- 동시에 돌린다: 서로 독립적인 세션 정리는 2~3개씩 병렬로 돌려 시간을 줄인다.
- 한도 초과를 알아본다: 사용량 한도 오류는 일반 실패와 구분해 "연기됨" 알림을 보내고 다음에 재시도한다.
- 문제가 생기면 먼저 볼 것: 조각이 몇 개로 나뉘었나, 실행이 몇 턴·몇 분 걸렸나, 뒤쪽 세션 결과가 앞쪽보다 눈에 띄게 짧은가.
❓ 자주 묻는 질문¶
- Q. 컨텍스트가 더 큰 모델을 쓰면 다 해결되나? A. 한도 초과만 해결된다. 뒤쪽을 얕게 다루는 경향, 시간과 사용량 증가는 그대로다.
- Q. 왜 턴이 늘면 느려지나? 앞 내용은 이미 읽었는데? A. 모델은 기억을 따로 저장하지 않는다. 매 턴 앞 대화 전체를 다시 입력으로 받는다. 캐시로 일부 줄일 수는 있지만 길이에 비례한 부담은 남는다.
- Q. 중요한 내용은 어디에 두는 게 좋나? A. 긴 자료는 앞에, 지시와 질문은 맨 끝에 두는 게 대체로 낫다. 꼭 지켜야 할 규칙은 짧게 반복해 두기도 한다.
🔭 더 깊이 보기¶
- 요약을 이어 붙이는 방식과 검색(RAG: 필요한 조각만 찾아 넣는 방식)은 어떻게 다른가 — 긴 자료를 다루는 두 큰 갈래라서.
- 프롬프트 캐시는 무엇을 줄여 주나 — 턴마다 앞 내용을 다시 읽는 비용을 줄이는 장치라서.
- 관련 주제: CLI headless 실행과 claude -p, cron 예약 실행과 클라우드 실행
📚 참고 자료¶
- Context windows (Anthropic 공식 문서, 영문) — 컨텍스트가 입력·출력·턴마다 어떻게 쌓이는지 · 링크
- Long context prompting tips (Anthropic 공식 문서, 영문) — 긴 자료를 어디에 두고 어떻게 지시할지 · 링크
- Lost in the Middle: How Language Models Use Long Contexts (2023년 연구 논문, 영문) — 긴 입력의 중간을 덜 반영하는 현상을 잰 연구 · 링크
🗓️ 이력¶
- 2026-11-11: 세션이 너무 많거나 길면 자동 요약에 어떤 문제가 생기는지 물었다 → 일지