얼마 전에 퇴근하고 사이드 프로젝트를 하나 만지기 시작했어요. 원래는 그냥 ChatGPT 켜놓고 “이거 왜 안 돼?”, “이 구조 괜찮아?” 이런 식으로 물어보면서 코딩했거든요. 뭐랄까, 옆자리에 말 잘 통하는 동료 한 명 앉혀놓은 느낌이라 좋긴 한데, 어느 순간부터 토큰이 너무 술술 새고 있다는 생각이 들더라고요. 특히 프로젝트 구조나 라이브러리 문서를 대충 던져주면 답변도 대충 나오고, 너무 많이 넣으면 비용도 부담되고요. 그러다 Context7을 써보게 됐는데, 이게 생각보다 제 작업 방식이랑 잘 맞았습니다. 오늘은 제가 AI 바이브 코딩하면서 Context7로 토큰을 어떻게 줄였는지, 프롬프트는 어떻게 정리했는지, 그리고 세팅해두면 꽤 오래 편한 것들을 편하게 이야기해볼게요.
Context7에서 토큰이 줄어드는 순간, 코딩 리듬이 좀 달라졌어요
처음 Context7을 붙였을 때는 솔직히 좀 무식하게 썼습니다. 프로젝트 전체를 그냥 다 긁어서 프롬프트에 넣었어요. 그때는 “많이 알려주면 더 잘 답하겠지” 싶었거든요. 그런데 개발 오래 해보신 분들은 아실 거예요. 많이 준다고 꼭 좋은 답이 나오는 건 아니잖아요. 로그도 너무 많으면 핵심 에러가 안 보이고, 회의도 말이 길어지면 결정이 흐려지는 것처럼요.
제가 처음에 겪은 문제는 이랬습니다. GPT-4 기준으로 질문 한 번 할 때마다 평균 2,000~3,000 토큰이 그냥 날아갔어요. 심할 땐 4,000 토큰 넘게 들어갔고요. 더 문제는 node_modules, .next, dist 같은 폴더가 컨텍스트에 섞이면서 정작 봐야 할 코드가 뒤로 밀려났다는 점이에요. 질문은 “이 컴포넌트 렌더링 버그 잡아줘”였는데, 답변은 이상하게 빌드 산물이나 예전 타입 정의를 붙잡고 있더라고요. 사람으로 치면 회의실에 관련 없는 사람 스무 명 들어와서 다 같이 떠드는 느낌이랄까요.
그때부터 .context7ignore를 제대로 쓰기 시작했습니다. Context7 최신 문서를 보니까 include/exclude 패턴을 꽤 세밀하게 잡을 수 있게 되어 있더라고요. 저는 일단 아래 항목부터 제외했어요.
node_modules/.next/dist/build/coverage/*.log.cache/__pycache__/
이렇게만 해도 체감이 꽤 컸습니다. 예전에는 질문 한 번 던질 때마다 “이거 또 토큰 많이 쓰겠네” 하는 묘한 찝찝함이 있었는데, 불필요한 폴더를 걷어내고 나니까 답변도 짧고 또렷해졌어요. 비용만 줄어든 게 아니라, 답변의 방향도 덜 흔들렸습니다.
| 제가 바꾼 방식 | 변경 전 평균 토큰 | 변경 후 평균 토큰 | 체감 |
|---|---|---|---|
| 프로젝트 전체를 그대로 컨텍스트에 포함 | 4,500 | 2,100 | 불필요한 잡음이 확 줄어듦 |
| 소스코드와 필요한 문서만 포함 | 2,100 | 800 | 답변이 현재 코드 중심으로 바뀜 |
| 문서 요약 기능 사용 | 800 | 350 | 질문을 여러 번 이어가기 편해짐 |
여기서 제일 마음에 들었던 건 문서 요약 기능이었어요. 예전에는 라이브러리 문서나 프로젝트 내부 문서를 통째로 넣고 물어봤거든요. 그런데 문서가 길면 LLM도 은근히 헤맵니다. 사람이 긴 위키 문서 읽다가 중간부터 대충 보는 것처럼요. Context7에서 //context7:summarize-docs 같은 식으로 문서 요약 지시를 넣어두면 핵심만 추려서 넣을 수 있어서 훨씬 낫더라고요.
제가 Next.js 15 App Router 쪽 작업을 할 때 이걸 꽤 유용하게 썼습니다. 원래는 관련 문서를 넣으면 1,500 토큰 정도가 훌쩍 넘어갔는데, 요약해서 넣으니 300 토큰 안팎으로도 충분했어요. 물론 아주 세세한 API 동작까지 물어볼 때는 원문이 필요할 때도 있습니다. 그런데 평소에 “이 흐름에서 어떤 방식이 맞아?” 정도를 물어볼 때는 요약 컨텍스트가 오히려 깔끔했습니다.
프롬프트는 길게 쓰는 것보다 덜 헷갈리게 쓰는 게 중요하더라고요
토큰을 아끼겠다고 무조건 짧게만 물어보면 또 답이 별로예요. 이게 참 애매합니다. 너무 많이 주면 비싸고, 너무 적게 주면 엉뚱하고요. 몇 번 삽질해보니 핵심은 프롬프트를 짧게 쓰는 것이 아니라 LLM이 어디를 봐야 하는지 덜 헷갈리게 만드는 것이었습니다.
예전의 저는 이런 식으로 많이 물어봤어요.
이 코드에서 버그 좀 찾아줘.이렇게 물으면 운 좋을 때는 잘 맞히는데, 아닌 날은 정말 엉뚱한 이야기를 합니다. import도 안 된 파일을 고치라고 하거나, 이미 삭제한 함수 이름을 기준으로 설명하기도 하고요. 특히 오래된 문서가 컨텍스트에 섞여 있으면 답변이 더 묘해집니다. 개발자 입장에선 제일 피곤한 상황이죠. 틀린 답인데 그럴듯한 답.
그래서 저는 .context7_prompt 파일에 기본 프롬프트를 넣어두고 씁니다. 매번 손으로 치면 귀찮기도 하고, 사람은 피곤하면 대충 쓰게 되거든요. 이런 건 세팅으로 밀어붙이는 게 맞습니다.
[Context7 최신 컨텍스트 자동 삽입]
You are an expert React and Node.js developer.
Your task is to analyze the provided code context and identify bugs.
- Focus only on files that are actively imported in the current working file.
- Use the exact file paths shown in the context.
- If you need more information, ask for specific file names, not entire directories.
- Do not assume APIs that are not shown in the provided context.
- Prefer small, safe changes over large refactoring unless requested.
이 정도만 넣어둬도 답변 톤이 달라집니다. 특히 Focus only on files that are actively imported 이 문장이 꽤 효과가 있었어요. LLM이 괜히 프로젝트 전체를 뒤져서 “이 파일도 고치면 좋겠습니다” 같은 말을 덜 하더라고요. 저는 업무할 때도 이런 스타일을 좋아합니다. 큰 그림도 중요하지만, 지금 장애 난 서버 앞에서는 일단 원인 파일부터 봐야 하잖아요.
그리고 Context7 최신 문서를 보니 $CONTEXT7_WORKSPACE, $PROJECT_NAME 같은 환경 변수 형태의 값도 활용할 수 있더라고요. 여러 프로젝트를 왔다 갔다 하는 사람에겐 이게 은근히 편합니다. 저는 회사 업무용 프로젝트, 개인 사이드 프로젝트, 테스트용 샘플 프로젝트가 다 따로 있는데, 매번 “이 프로젝트는 뭐고 구조는 이렇고” 설명하는 게 귀찮았거든요.
예를 들면 이런 식입니다.
현재 프로젝트는 $PROJECT_NAME 입니다.
이 프로젝트의 코드 컨벤션과 현재 Context7에 포함된 파일 기준으로만 답변해주세요.
추측이 필요한 부분은 추측이라고 표시하고, 필요한 파일명을 구체적으로 요청해주세요.별것 아닌 것 같지만, 이런 문장을 기본값으로 박아두면 프롬프트가 훨씬 안정됩니다. 저는 나이가 들수록 이런 세팅의 힘을 믿게 되더라고요. 매번 의지로 해결하려고 하면 오래 못 갑니다. 좋은 습관은 설정 파일에 넣어두는 게 제일 오래가요.
컨텍스트 오염 때문에 반나절 날린 날도 있었습니다
좋은 도구도 잘못 쓰면 사람을 피곤하게 합니다. Context7도 마찬가지였어요. 제가 한 번 크게 당한 적이 있습니다.
프로젝트 안에 documentation/ 폴더가 있었는데, 거기에 예전 API 문서가 들어 있었어요. 2022년 버전 문서였고, 지금 코드와는 꽤 달랐습니다. 문제는 Context7이 그 문서를 컨텍스트에 포함시켰고, LLM이 그걸 아주 자신감 있게 참고했다는 거예요.
그날 제가 받은 답변이 대충 이런 느낌이었습니다.
POST /api/v1/users 엔드포인트를 호출한 뒤 response.data.userId를 사용하면 됩니다.그런데 실제 현재 코드는 /api/v2/members를 쓰고 있었고, 응답 구조도 result.member.id 쪽이었어요. 처음엔 제가 코드를 잘못 본 줄 알았습니다. “아니, 분명히 AI가 이렇게 말했는데?” 하고요. 지금 생각하면 좀 웃기지만, 그 순간엔 꽤 진지했습니다. 결국 한참을 따라가다 보니 오래된 문서가 범인이더라고요.
그 뒤로 .context7ignore에 바로 추가했습니다.
documentation/**
legacy-docs/**
archive/**
*.old.md그리고 문서 파일을 포함할 때도 *.md처럼 넓게 잡지 않게 됐어요. 대신 필요한 파일만 딱 집어서 넣습니다.
README.mdCHANGELOG.mdUPGRADE_GUIDE.mdAPI_CURRENT.mddocs/current/**/*.md
사실 이건 Context7만의 문제는 아니에요. LLM을 코딩에 쓸 때 제일 무서운 건 틀린 정보가 컨텍스트 안에 들어가는 것입니다. 답변이 틀리면 티라도 나는데, 오래된 문서 기반으로 그럴듯하게 말하면 진짜 위험해요. 그래서 저는 요즘 “컨텍스트를 많이 넣자”보다 “믿을 수 있는 컨텍스트만 넣자” 쪽으로 생각이 바뀌었습니다.
제가 실제로 세팅해두고 쓰는 Context7 체크리스트
아래는 제가 여러 번 삽질하면서 정리한 체크리스트입니다. 대단한 비법이라기보다는, 해두면 다음 달의 내가 고마워하는 설정들이에요. 개발 일이 그렇잖아요. 오늘 10분 아껴둔 세팅이 다음 장애 때 한 시간을 벌어주기도 합니다.
- .context7ignore에 빌드 결과물과 캐시 폴더를 확실히 제외하기
저는node_modules/,.next/,dist/,build/,coverage/,.cache/,*.log는 거의 기본으로 빼둡니다. Python 프로젝트라면__pycache__/도 꼭 넣고요. 이거 빠지면 쓸데없는 토큰이 생각보다 많이 나갑니다. - max_context_tokens를 프로젝트마다 다르게 잡기
context7.config.json에"max_context_tokens": 3000처럼 제한을 걸어두면 마음이 편합니다. 저는 작은 프로젝트는 2000 안팎, 중간 규모는 3000~4000 정도로 잡아요. 무조건 크게 잡는다고 좋은 게 아니더라고요. LLM이 집중할 공간을 일부러 좁혀주는 것도 필요합니다. - auto_context 옵션으로 현재 작업 파일 중심의 컨텍스트 만들기
auto_context옵션을 켜두면 현재 편집 중인 파일이 import하는 모듈이나 git diff에 걸린 파일 위주로 컨텍스트를 잡을 수 있습니다. 이게 생각보다 자연스러워요. 우리가 실제로 디버깅할 때도 전체 프로젝트를 다 보진 않잖아요. 지금 바꾼 파일, 연결된 파일, 최근에 건드린 파일부터 보니까요. - 프롬프트 템플릿에 “모르면 파일명을 요청하라”는 문장 넣기
저는 이 문장을 정말 좋아합니다. “정보가 부족하면 전체 디렉터리를 요청하지 말고 구체적인 파일명을 요청해줘.” 이걸 넣으면 LLM이 답을 지어내는 빈도가 줄어듭니다. 완벽하진 않지만, 확실히 덜 뻔뻔해져요. - 공식 문서 URL은 변수나 플레이스홀더로 관리하기
<official_docs_url>같은 플레이스홀더를 템플릿에 넣어두면 매번 링크 찾는 시간을 줄일 수 있습니다. React, Node.js, Next.js 문서는 자주 보니까 이런 식으로 고정해두면 편해요. 별거 아닌데 반복 작업이 줄어듭니다. - 오래된 내부 문서와 archive 폴더는 과감히 제외하기
저는 이걸 늦게 해서 손해를 봤습니다. 오래된 문서는 차라리 없는 게 나을 때도 많아요. 특히 API 문서, DB 스키마 문서, 인증 플로우 문서는 현재 버전이 아니면 위험합니다. - 주 1회 changelog 확인하기
저는 금요일 오후에 가볍게 changelog를 보는 편입니다. 일이 한숨 돌 때 커피 한 잔 들고 보는 거죠. Context7 2.1에서 토큰 비용 예측 대시보드 같은 기능을 보고 나서는, 제가 예전에 얼마나 대충 쓰고 있었는지 좀 민망하더라고요.
제가 쓰는 기본 설정 예시는 이런 느낌입니다
아래 설정은 제 개인 프로젝트 기준이라 그대로 복사해서 쓰기보다는, 본인 프로젝트에 맞게 조금씩 손보는 걸 추천합니다. 그래도 처음 시작할 때 기준점으로는 괜찮을 거예요.
{
"max_context_tokens": 3000,
"auto_context": true,
"include": [
"src/**/*",
"app/**/*",
"pages/**/*",
"components/**/*",
"lib/**/*",
"README.md",
"CHANGELOG.md",
"UPGRADE_GUIDE.md"
],
"exclude": [
"node_modules/**",
".next/**",
"dist/**",
"build/**",
"coverage/**",
".cache/**",
"documentation/**",
"legacy-docs/**",
"archive/**",
"*.log"
],
"docs": {
"summarize": true,
"max_summary_tokens": 300
}
}저는 이 설정을 넣고 나서 질문 방식도 조금 바꿨습니다. 예전에는 “전체적으로 봐줘”라고 많이 했는데, 요즘은 좀 더 좁혀서 물어봐요.
| 예전 질문 | 요즘 질문 | 차이 |
|---|---|---|
| 이 코드 리팩터링해줘 | 현재 파일과 import된 파일 기준으로 중복 로직만 줄여줘 | 불필요한 대규모 수정이 줄어듦 |
| 버그 찾아줘 | git diff에 포함된 파일 기준으로 런타임 에러 가능성이 있는 부분만 봐줘 | 현재 변경분 중심으로 답변함 |
| 이 API 어떻게 써? | Context7에 포함된 최신 문서 기준으로 이 API 호출 예제를 만들어줘 | 오래된 사용법을 덜 끌고 옴 |
프롬프트를 이렇게 바꾸면 답변이 조금 심심해질 때도 있습니다. 막 화려한 제안이 쏟아지는 느낌은 줄어요. 그런데 저는 그게 더 좋았습니다. 실제 개발에서는 화려한 제안보다 안전한 변경이 더 고마울 때가 많거든요. 특히 회사 코드에서는요. 사이드 프로젝트야 마음껏 갈아엎어도 되지만, 운영 중인 서비스는 얘기가 다르니까요.
토큰 절약은 비용 문제가 아니라 집중력 문제에 가깝습니다
처음에는 저도 토큰을 돈으로만 봤어요. “이번 달 API 비용 얼마나 나오려나” 이런 생각이 먼저였죠. 그런데 Context7을 쓰면서 느낀 건, 토큰 절약은 비용보다 집중력의 문제에 가깝다는 겁니다.
컨텍스트가 지저분하면 LLM도 집중을 못 합니다. 사람도 마찬가지잖아요. 책상 위에 영수증, 충전기, 오래된 메모, 먹다 남은 과자 봉지가 쌓여 있으면 괜히 머리가 복잡해집니다. 프로젝트 컨텍스트도 비슷했어요. 불필요한 파일을 걷어내고, 최신 문서만 남기고, 현재 작업 파일 중심으로 좁히니까 답변이 훨씬 일관됐습니다.
제가 요즘 AI 바이브 코딩을 할 때 기준으로 삼는 건 딱 이 정도예요.
- LLM에게 프로젝트 전체를 맡기지 않는다.
- 현재 작업에 필요한 파일만 보여준다.
- 오래된 문서는 과감히 제외한다.
- 답을 모르면 추측하지 말고 필요한 파일명을 물어보게 한다.
- 반복되는 프롬프트는 설정 파일로 빼둔다.
이 기준만 잡아도 작업 흐름이 꽤 안정됩니다. 개발 오래 하다 보면 도구를 엄청 많이 만나게 되는데요. 결국 오래 남는 도구는 “나를 똑똑하게 만들어주는 도구”라기보다 “내가 덜 피곤하게 일하게 해주는 도구”더라고요. Context7은 제게 그런 쪽에 가까웠습니다.
이 글은 이런 분들이 읽으면 꽤 도움이 될 것 같아요
AI 바이브 코딩을 하고 있는데 프롬프트가 자꾸 길어지는 분, LLM 답변이 매번 엉뚱한 파일을 건드려서 피곤한 분, API 비용이 은근히 부담되는 분이라면 Context7 세팅을 한 번쯤 정리해보면 좋겠습니다. 특히 여러 프로젝트를 동시에 만지는 개발자라면 효과가 더 커요. 저처럼 회사 일도 하고, 밤에는 사이드 프로젝트도 조금씩 만지는 분들이라면 더더욱요.
솔직히 Context7도 처음엔 약간 귀찮습니다. .context7ignore도 만들어야 하고, 프롬프트 템플릿도 다듬어야 하고, 어떤 문서를 포함할지 판단도 해야 하니까요. 그런데 한 번 정리해두면 그다음부터는 꽤 조용히 일을 도와줍니다. 좋은 도구가 원래 그렇잖아요. 막 앞에서 나대는 게 아니라, 뒤에서 흐름을 덜 끊기게 해주는 것.
제 생각에 AI 코딩의 핵심은 “AI에게 얼마나 많이 물어보느냐”가 아니라 좋은 컨텍스트를 얼마나 깔끔하게 건네느냐에 있습니다. Context7은 그 작업을 꽤 현실적으로 도와주는 도구였고요. 저처럼 처음에 프로젝트 전체를 다 던져놓고 토큰을 줄줄 흘렸던 분이라면, 오늘 이야기한 설정부터 하나씩 손봐보세요. 아마 답변 품질도, 비용도, 코딩할 때의 마음도 조금은 가벼워질 겁니다.
댓글
댓글 쓰기