_(1).jpeg&blockId=0e552736-74f0-4f5a-89e1-328d4931ca7c)
•
기능 추가, 버그 픽스, 테스트 등 상황별 토큰 압축 전략
claude나 cursor에서는 사실 프롬프트 자체보다는 LLM이 맥락 파악을 위해 파일을 읽으면서 토큰 소비하는 게 제일 크다.
Cursor Settings에서 Index New Folders 해제
사용안하는 탭 닫기
cursor rules: global, architecture,
docs 폴더에 SUMMARY_ARCHITECTURE.md 생성
필요한 파일만 참조 명령
동적 컨텍스트
커서는 실시간으로 활동을 추적합니다
활성 파일의 전체 내용(편집자 포커스 파일)
최근에 본 파일 목록
활성 린터/컴파일러 오류
최근 코드 변경 사항
주요 암묵적 컨텍스트는 현재 활성화된 탭입니다. 이는 의도적인 설계 결정입니다: 모든 열려 있는 파일을 자동으로 포함하면 비대해지고 관련 없는 컨텍스트가 생성됩니다.
현재 작업과 관련된 파일만 열어두세요.
채팅의 경우 이는 덜 중요하지만 탭 자동 완성의 경우 탭 열기가 제안의 품질에 영향을 미칩니다.
특정 글로브 패턴을 사용하세요. src/**/*.ts 대신(src/의 모든 TypeScript 파일에 대한 applies), 테스트에는 src/**/test*.ts를, 컴포넌트에는 src/components/**/*.tsx를, API에는 src/api/**/*.ts를 사용합니다. 이렇게 하면 .ts 파일을 사용할 때 모든 규칙을 동시에 로드할 수 없습니다.
세션이 길어지면 전체 채팅에 대한 압축 없이 LLM에 전달됩니다. 90%를 채우고나서야 압축이 됩니다.
새로운 주제에 대한 새로운 채팅을 시작합니다. 기능 구현, 디버깅, 리팩토링, 테스트 쓰기를 한 세션으로 해결하려고 하지 마세요. 각 작업—각 개별 채팅.
채팅이 너무 길어졌다고 느끼면서도 세션을 보존하고 싶을 때는 /summarize 명령을 수동으로 사용하세요.
AI가 혼란스러워지기 시작하면(모순한 해결책을 제시하고 작동 코드를 깨뜨리는 등) 세션을 "저장"하려고 하지 마세요. 현재 작업에 중요한 사항에 대한 간결한 요약으로 새 채팅을 시작하세요.
1.
명시적 문맥 (@-참조)
@-reference 시스템을 사용하면 정확히 무엇을 포함할지 수동으로 지정할 수 있습니다:
@Files—특정 파일
@폴더—전체 디렉토리
@Code / @Symbols—특정 함수, 클래스 또는 변수
@Docs—외부 문서(인덱스 및 포함)
@Web—라이브 웹 검색
@Git—커밋 히스토리 또는 Diff
실용적인 팁: 작업에 필요한 파일을 정확히 알고 있다면, 명시적인 @-refe 참조(@path/to/file.ts)를 사용하고 코드베이스 검색을 활성화하지 않고 Enter 키를 눌러 요청을 제출하세요. @를 통한 정확한 컨텍스트는 RAG를 통한 전체 코드베이스의 의미 검색보다 빠르고 저렴합니다동적 컨텍스트(지금 하고 있는 작업)
커서는 실시간으로 활동을 추적합니다:
활성 파일의 전체 내용(편집자 포커스 파일)
최근에 본 파일 목록
활성 린터/컴파일러 오류
최근 코드 변경 사항
주요 암묵적 컨텍스트는 현재 활성화된 탭입니다. 이는 의도적인 설계 결정입니다: 모든 열려 있는 파일을 자동으로 포함하면 비대해지고 관련 없는 컨텍스트가 생성됩니다.
3. Claude에서 절약하는 방법
Claude는 context window가 크지만, 파일 업로드 + 프로젝트 문서도 전부 토큰 안에서 소비됩니다.
3-1. Projects를 “지식 베이스”로, 채팅 컨텍스트는 얇게
•
Projects에 스펙/문서/코드 많이 넣어도, 한 번의 답변에서 실제로 읽는 건 20만 토큰 정도까지.
•
그래서 전략은:
◦
자주 쓰는 문서/코드는 모두 Project에 올려두고,
◦
개별 채팅에서는 “프로젝트의 spec-subscription.md 기준으로만 답해줘”처럼 파일 이름·섹션을 지정해서 범위를 좁혀달라고 요청.
•
여러 파일 동시에 붙이지 말고, 1~3개로 제한해서 “이 파일들만 참고해서 봐”라고 명시.
3-2. 업로드 파일도 요약·샤딩
•
50페이지짜리 스펙 PDF →
◦
Claude에게 먼저 “챕터별 한 줄 요약” / “API별 요약 테이블”을 만들어달라고 시킨 뒤,
◦
이후 작업에서는 그 요약 텍스트만 계속 사용.
•
거대한 코드 파일도
◦
“이 파일에서 컴포넌트/훅/유틸별 역할만 정리” → summary 파일 만들어두고,
◦
디버깅/리팩터 때만 해당 함수 정의 부분만 발췌해서 붙이기.
4. 코드베이스 쪽 구조 리팩터링으로 절약하는 방법
토큰 문제를 툴 세팅만으로 해결하기보다, 코드 구조를 LLM 친화적으로 쪼개는 것도 꽤 효과 있습니다.
•
파일 단위:
◦
1,000~2,000 라인짜리 파일은 주요 기능별로 나눠서, AI가 한 번에 읽는 범위를 줄이기.
•
관심사별 폴더:
◦
ui/, domain/, infra/ 같은 식으로 폴더를 잘 나눠두면, 특정 영역만 인덱싱하거나 @참조하기 쉽습니다.
•
공통 유틸/타입:
◦
자주 참조되는 유틸/타입은 작은 전용 파일로 뽑아서, 항상 그 파일만 컨텍스트에 포함하도록 패턴 고정.
이렇게 해두면, “이 기능 관련 테스트 짜줘” 했을 때 Cursor/Claude가 몽땅 쓸어오는 대신, 특정 서브트리만 보게 만들기 쉽습니다.
대형 모노레포에서는 “어떤 서브셋만 모델에 보여줄지”를 설계하는 게 핵심이에요. 툴을 바꾸기보다, 코드/폴더/워크플로를 LLM 친화적으로 쪼개는 방향으로 생각하면 관리가 훨씬 쉬워집니다.
1. “서비스 단위”로 문제를 쪼개기
•
모노레포라도 LLM에는 항상 한 번에 한 서비스/패키지만 보여준다는 원칙을 잡는 게 좋습니다.
•
예: apps/web, apps/admin, packages/payments, packages/core 단위로 작업 세션을 나누고,
◦
“이번 Claude/Cursor 세션은 apps/web만 본다” 같은 식으로 명확하게 스코프를 잡기.
•
프롬프트에도 스코프를 못 박기:
◦
“이 작업에서는 apps/web과 packages/ui 파일만 참고해. 다른 서비스/폴더는 무시해.”
이렇게 하면 검색/인덱싱/RAG가 전체 레포를 긁어오지 않고, 논리적인 서브셋에서만 돌게 됩니다.
2. 폴더/규칙 설계로 “기본 컨텍스트” 줄이기 (특히 Cursor)
2-1. rules / 기본 컨텍스트 최소화
•
Cursor는 .cursorrules(또는 프로젝트 rules)가 기본 컨텍스트로 매번 들어가는데, 이것만으로도 수만 토큰이 나갈 수 있습니다.
•
모노레포에서는 전역 규칙을 매우 얇게 하고, 서비스별로 rules를 쪼개서 “작업할 서비스 것만 적용”되게 만드는 게 좋습니다.
◦
예:
▪
/.cursor/rules/global.mdc (공통 10–20줄)
▪
/apps/web/.cursor/rules.mdc
▪
/apps/admin/.cursor/rules.mdc
▪
/packages/payments/.cursor/rules.mdc
이렇게 하면 web 작업할 때는 web 규칙만, admin 작업할 때는 admin 규칙만 들어가서 고정 토큰이 줄어듭니다.
2-2. 인덱싱/검색 범위 좁히기
•
모노레포 전체를 인덱싱하면, 간단한 질문 하나에도 엄청난 코드가 후보로 떠오르고, 그중 일부가 컨텍스트로 들어가면서 토큰이 폭증합니다.
•
가능하다면 서비스/폴더별로 인덱싱 범위를 나누고,
◦
문서/설정/빌드 아웃풋/스냅샷 테스트 폴더(예: dist/, coverage/, __snapshots__/)는 기본 인덱싱에서 제외.
3. “요약 레이어”를 둬서 원문 대신 요약을 보이기
대형 모노레포의 스펙/아키텍처/도메인 문서를 그대로 컨텍스트에 넣으면 바로 수만~수십만 토큰이 나갑니다.
•
핵심 문서 요약 파일 두기
◦
예:
▪
/docs/SUMMARY_ARCH.md (아키텍처 1–2페이지 요약)
▪
/docs/SUMMARY_PAYMENTS.md (결제 도메인 규칙만)
◦
실제 작업에서는 원문 PDF/Notion 대신 이 요약 파일만 @참조.
•
패키지별 README 강제
◦
각 packages/*에 “역할/주요 API/의존성” 정도만 정리한 짧은 README를 두고, LLM에는 README + 관련 파일만 보이게 하기.
즉, 모노레포 전체 지식 → 서비스 요약 → 패키지 요약 → 실제 편집 파일 순으로 계층화해서, 위 계층 텍스트만 항상 컨텍스트로 들어가게 하는 전략입니다.
4. LLM에게 “컨텍스트 예산”을 명시하기
도구에서 자동으로 많이 집어넣는 걸 막기 힘들면, 프롬프트에서 직접 컨텍스트 예산을 제한하는 것도 유효합니다.
•
예시 지시문:
◦
“관련 코드/파일은 최대 5개까지만 가져와서 사용해.”
◦
“현재 질문을 답하는 데 필요한 최소 범위만 읽어줘. 패키지 전체가 아니라 관련 함수/파일만.”
◦
“모든 레이어를 보지 말고, 우선 apps/web과 그 바로 아래 의존 패키지에서만 답을 찾으려고 해.”
이런 식으로 “토큰 예산/검색 범위”를 언어로 지정해주면, RAG 계열 시스템이 과한 컨텍스트 주입을 어느 정도 피하도록 유도할 수 있습니다.
5. Claude 전용: 세션 관리로 컨텍스트 누적 줄이기
•
Claude Code는 긴 세션에서 과거 코드/대화가 쌓이면서 컨텍스트를 계속 먹습니다.
•
모노레포에서 특히 중요한 패턴:
◦
기능 단위로 세션을 끊고 /clear 후, 정말 필요한 메모만 session-notes.md 같은 파일에 적어두고 다시 불러오는 방식.
◦
“지금부터는 결제 서비스 작업으로 전환할 거라, 이전 세션의 컨텍스트는 전부 비워줘.”라며 /clear 후, @SUMMARY_PAYMENTS.md 정도만 다시 포함.
이렇게 하면 “이전 유스케이스 + 새로운 유스케이스”가 섞여서 불필요하게 많은 파일/코드가 컨텍스트에 남아 있는 상황을 피할 수 있습니다.
6. 실제 모노레포 워크플로 예시 (적용 이미지)
당신 상황을 가정한 흐름:
1.
모노레포 구조
•
apps/web, apps/admin, packages/core, packages/payments, packages/ui, docs/
2.
각 패키지에 요약/README 작성
•
packages/payments/README.md에 책임/핵심 흐름만 1–2페이지로 정리.
3.
Cursor / Claude 사용 시
•
“이번 작업은 apps/web + packages/ui만 볼 거야”를 프롬프트에 못 박고,
•
관련 파일을 @지정해서 보내고, 모노레포 전체 검색은 피하기.
4.
긴 도메인 설명이 필요하면
•
처음 한 번 Claude로 “결제 플로우/도메인 규칙 요약본”을 만들고
•
그 결과를 docs/SUMMARY_PAYMENTS.md에 저장해서 이후에는 그 파일만 컨텍스트로 사용.
이 정도만 해도, “대형 모노레포를 그냥 통째로 보여주고 시작하는” 방식에 비해 컨텍스트 토큰은 상당히 줄어듭니다.
