핵심 개념

context window 관리

Bob의 270,000 token context window 작동 방식, 각 카테고리가 token 사용량에 미치는 영향, 그리고 task를 집중적으로 유지하고 비용 효율을 높이는 모범 사례를 알아봅니다.

context window 이해하기

채팅 패널의 각 task에는 context window가 있습니다 — 해당 스레드의 token 예산입니다. 상한선은 270,000 token입니다. Bob이 로드하는 모든 것이 여기에 계산됩니다.

window를 채우는 것들

채팅 패널 오른쪽 상단의 token usage indicator 위에 커서를 올리면 context window를 소비하는 항목의 분석 내용을 확인할 수 있습니다:

Context window breakdown panel showing token usage by category
카테고리포함 내용
System prompt세션에 대한 Bob의 핵심 지침
Tool definitions내장 도구 스키마 및 연결된 MCP 도구 정의
MCP Tools연결된 MCP 서버가 제공하는 도구의 지침 및 설명
Rules프로젝트 및 모드 rule 파일의 맞춤 지침 (예: AGENTS.md 또는 .bob/rules-*)
SkillsBob이 대화를 위해 로드한 skills의 지침
Messages대화에서의 prompt, Bob의 답변, 도구 활동. token으로 계산되는 transcript입니다.

@ 멘션, 명령어 출력, 도구 결과는 모두 Messages에 포함됩니다. 파일 내용에는 별도 항목이 없습니다.

Estimated breakdown 아래:

  • Reserved for model response: Bob의 다음 답변을 위해 확보된 token (일반적으로 20.0k).
  • Available space: 남은 여유 token.

기본 오버헤드

Bob과 작업을 시작하기 전부터 고정 카테고리들이 context를 소비합니다. Galaxium Travels 샘플 프로젝트에서는 "Quickly say hi back."만 해도 약 8.5k token에 달합니다. 대부분은 Tool definitions (5.1k), System prompt (1.5k), Rules (830), Skills (454)입니다. Messages에는 590만 있습니다.

Bob은 모든 prompt에서 전체 오버헤드 스택을 다시 전송합니다. MCP 서버나 로드된 skill이 많을수록 입력 전에 MCP Tools, Tool definitions, Skills가 증가합니다.

실제 수치와 리셋 연습은 Create a new context window를 참고하세요.

token 사용량 모니터링

token usage indicator270,000 token 상한선 대비 사용 비율과 사용됨/전체 분수를 표시합니다. 클릭하면 context window breakdown이 열립니다. 어떤 카테고리가 증가하고 있는지 확인하세요.

다음 표는 각 카테고리에 영향을 미치는 요소를 보여줍니다:

카테고리증가 요인
System prompttask 시작 시 로드됩니다. 일반 작업 중에는 변하지 않습니다.
Tool definitions내장 도구 스키마입니다. task 시작 시 설정됩니다. 일반 작업 중에는 변하지 않습니다.
MCP Tools연결된 MCP 서버 및 활성화된 도구입니다. 서버나 도구를 추가할 때 증가하며, prompt 전송 시에는 증가하지 않습니다.
Rules프로젝트 및 모드 rule 파일 (예: AGENTS.md). task가 열릴 때 설정됩니다.
SkillsBob이 task를 위해 로드하는 skill입니다. 스레드 중간에 Bob이 skill을 활성화하면 증가할 수 있습니다.
MessagesPrompt, Bob의 답변, 파일 읽기, 도구 출력, @ 멘션. 매 턴과 저장소 탐색 시마다 증가합니다.

짧은 교환에서는 고정 카테고리가 전체의 대부분을 차지하는 경우가 많습니다. Bob에게 파일을 읽거나 도구를 실행하도록 요청하면 Messages가 보통 가장 큰 카테고리가 됩니다. 이 변화에 주목하세요.

어떤 카테고리가 증가하더라도 Available space는 줄어듭니다. Reserved for model response는 Bob의 다음 답변을 위해 따로 확보되며, 위에 표시된 사용 합계에는 포함되지 않습니다.

실제 저장소의 측정 예시는 Create a new context window를 참고하세요.

token 제한

task당 하드 상한선은 270,000 token입니다. Bob은 제한에 도달하기 전에 압축을 시작합니다. 압축은 일반적으로 총 사용량 190,000 token 정도에서 시작됩니다.

자동 context condensation

압축 임계값에서 Bob은:

  1. 가장 최근의 관련성 높은 context를 보존합니다.
  2. 오래된 대화 세그먼트를 요약하거나 제거합니다.
  3. 중요한 시스템 지침, tool definitions, rules, skills를 유지합니다.
  4. 압축된 context로 계속 진행합니다.

Condensation은 손실이 있습니다. Messages 초반의 세부 사항이 살아남지 못할 수 있습니다. 주제가 바뀌거나 Messages가 품질에 영향을 줄 만큼 커지면 + (New task)로 새 task를 시작하세요.

Bobcoins에 미치는 영향

Bobcoins는 token 사용량을 추적합니다. 입력 token과 출력 token 모두 계산됩니다.

  • 각 메시지는 고정 오버헤드를 포함한 전체 활성 context를 다시 전송합니다.
  • Bob은 이미 로드된 내용을 매 전송 시마다 재처리합니다.
  • Messages가 많은 긴 스레드는 이후의 prompt에서 비용이 더 많이 듭니다.

모범 사례

context window는 저장소가 아닙니다. 각 단계에서 Bob이 사용할 수 있는 작업 메모리입니다. 무엇이 들어가는지 통제하세요. 스레드가 오래된 출력으로 가득 차면 리셋하거나 압축하세요. Bob의 답변만이 아니라 테스트로 결과를 확인하세요.

task와 대화의 범위 설정

작업 목표당 하나의 task를 사용하고 구체적인 prompt로 시작하세요. Bob에게 저장소를 탐색하도록 요청하기 전에 목표, 예상 결과, 제약 조건을 명시하세요. 파일과 함수를 명시적으로 지정하세요. "전체 저장소를 읽어"나 "백엔드를 확인해"와 같은 모호한 요청은 피하세요. 주제가 바뀌면 + (New task)를 클릭하세요 — Messages의 관련 없는 내용은 비용을 늘리고 Bob을 혼란스럽게 할 수 있습니다.

고정 context를 가볍게 유지하기

고정 카테고리는 입력하기 전부터 token을 소비합니다. 오버헤드를 낮게 유지하려면:

  • custom rulesAGENTS.md를 짧게 유지하세요 — 설정, 테스트, 스타일 명령어만 넣으세요 (예: pnpm test, mvn verify).
  • 현재 작업에 필요한 MCP 서버, 도구, skills만 연결하세요. 사용하지 않는 것은 연결을 끊고, 글로벌 설정보다 프로젝트 스코프 MCP 설정을 선호하세요.
  • Messages는 이 task에 특화된 상황별 증거(버그, 로그, 관련 파일)를 위해 남겨두세요. 매 prompt마다 고정 rules를 반복하지 마세요.

필요할 때 context 추가하기

큰 내용 블록을 스레드에 붙여넣는 대신 Bob이 대상 파일을 검색하고 읽도록 하세요. context mentions를 사용해 특정 파일이나 행 범위를 참조하고, 광범위한 디렉터리 멘션은 피하세요:

✓ @/src/utils/validation.ts:45-67 Fix the email validation logic
✗ @/src @/tests @/docs Review everything and suggest improvements

에디터에서 텍스트를 선택하고 Cmd + L (Mac) 또는 Ctrl + L (Windows/Linux)을 사용해 채팅에 직접 추가할 수도 있습니다.

단계적으로 작업하세요 — 가능성 있는 파일을 찾고, 관련 파일을 검사하고, 계획하고, 변경하고, 검증하세요. 광범위한 저장소 읽기에는 subagents를 사용해 모든 read_file 호출이 Messages에 쌓이는 대신 압축된 결과가 task에 전달되도록 하세요. 소스가 충돌할 때는 오래된 주석이나 README 메모보다 실행 중인 코드와 테스트를 신뢰하세요.

대규모 저장소에 대한 더 많은 전술은 Working with large projects를 참고하세요.

Messages가 가득 찰 때 리셋 또는 압축하기

긴 대화에서는 Messages에 반복된 파일 내용, 포기된 계획, 오래된 도구 출력이 쌓입니다. 작업 목표가 바뀌거나 스레드가 품질에 영향을 줄 만큼 커지면 + (New task)로 새 task를 시작하세요. 제약 조건, 증거, 미해결 질문은 유지하고 — 나머지는 제거하세요.

Bob은 오래된 세그먼트를 자동으로 condensation할 수도 있지만, condensation은 손실이 있고 Messages 초반의 세부 사항이 살아남지 못할 수 있습니다. 큰 자율 실행 하나보다는 작게 승인된 변경을 선호해서 diff를 검토 가능하게 유지하고 Bob이 제대로 진행할 수 있게 하세요.

더 알아보기

Create a new context window에서 Galaxium Travels 샘플 프로젝트의 분석 내용을 열고 리셋을 연습해 보세요.

이 주제는 어떤가요?