GitHub Copilot AI Credits 시대의 절약 기술 23선

서론

GitHub Copilot은 기존의 "Premium Request" 중심 메커니즘에서 GitHub AI Credits 기반의 종량제 방식으로 전환되었습니다.

앞으로는 단순히 "몇 번 사용했는가"뿐만 아니라,

• 어떤 모델을 사용했는가
• 얼마나 많은 입력을 읽게 했는가
• 얼마나 많은 출력을 생성하게 했는가
• Agent가 얼마나 많은 파일이나 도구를 사용했는가
• 긴 채팅 이력이나 거대한 파일을 얼마나 포함했는가

가 비용에 영향을 미치게 됩니다.

해외에서도 "며칠 만에 크레딧을 상당히 소비했다", "Agent에게 자유 탐색을 시키면 비용이 높다", "고성능 모델을 상용하면 순식간에 줄어든다"와 같은 반응이 나오고 있습니다.

이 기사에서는 GitHub Copilot / GitHub Copilot Chat / VS Code Copilot을 사용할 때, AI Credits를 낭비하지 않기 위한 실천 규칙을 정리합니다.

결론

GitHub Copilot 절약에서 중요한 것은 다음 4가지입니다.

읽게 하지 않기
말하게 하지 않기
강력한 모델을 남용하지 않기
...

AI를 사용하지 않는 것이 아니라, AI에게 전달하는 범위를 관리하는 것이 포인트입니다.

최종 체크리스트

먼저, 자신을 위한 체크리스트입니다.

Ask 모드 우선
경량 모델 사용
Auto 모드 사용
...

모든 것을 매번 할 필요는 없습니다.

특히 효과적인 것은,

대상 파일 지정
새 채팅
Agent는 필요할 때만
...

등입니다.

1. Ask 모드를 우선한다

단발성 질문이나 가벼운 상담이라면, Agent 모드가 아닌 Ask 모드를 사용합니다.

Ask 모드로 충분한 작업은 다음과 같습니다.

• 에러의 의미를 묻기
• 구현 방침을 상담하기
• 코드의 일부만 설명을 듣기
• SQL이나 정규 표현식을 확인하기
• 작은 함수의 개선안을 묻기

Agent 모드는 파일 검색, 파일 편집, 커맨드 실행, 도구 호출 등을 수행합니다.

따라서 단순한 질문에 Agent를 사용하면, 불필요한 파일이나 도구 출력이 컨텍스트 (Context)에 들어가 AI Credits를 소비하기 쉬워집니다.

나쁜 예:

Agent로 이 에러의 원인을 조사해줘

좋은 예:

Ask mode.
이 에러의 원인을 짧게 설명해줘.
아직 파일 편집은 하지 마.

2. 경량 모델을 사용한다

평소 작업은 경량 모델이나 mini 계열로도 충분한 경우가 많습니다.

작업	추천
README 수정	경량 모델
...

전부를 최강 모델에 던지는 것이 아니라,

경량 모델로 구현
강력한 모델로 설계·리뷰

와 같이 나누면 절약하기 쉽습니다.

3. Auto 모드를 사용한다

모델 선택이 번거로운 경우에는 Auto 모드를 사용하는 것도 방법입니다.

Auto 모드는 태스크 (Task)에 따라 균형 잡힌 모델을 선택해 주기 때문에 평소 사용 시에는 무난합니다.

추천하는 구분법은 다음과 같습니다.

평소: Auto
분명히 간단함: 경량 모델 고정
어려운 설계·디버깅: 강력한 모델 고정

단, 법인 이용의 경우 "이용 가능한 모델을 사내에서 고정하고 있는" 경우가 있습니다.

그 경우에는 Auto가 아니라 사내 정책으로 허가된 모델을 사용하는 것이 안전합니다.

4. Thinking effort는 너무 높이지 않는다

Thinking effort나 Reasoning effort를 높이면, 모델이 더 깊게 생각하는 만큼 토큰 (Token) 소비나 대기 시간이 늘어납니다.

평소 작업에서는 기본값(Default)으로 충분합니다.

높이는 것은 다음과 같은 상황에서만 해도 충분하다고 생각합니다.

• 아키텍처 설계
• 보안 설계
• 복잡한 버그 조사
• 여러 파일을 가로지르는 어려운 리팩토링 (Refactor)
• 결제나 인증 등 실패해서는 안 되는 변경

평소부터 high로 설정하는 것은 절약 목적상 그리 추천하지 않습니다.

5. 대상 파일을 지정한다

이것은 상당히 중요합니다.

나쁜 예:

이 리포지토리 전체를 보고 문제를 고쳐줘

좋은 예:

Target only: src/auth/login.ts
로그인 실패 시의 에러 핸들링만 고쳐줘.
다른 파일은 건드리지 마.

더욱 안전하게 하려면, 처음에 계획만 내놓게 합니다.

먼저 변경 계획만 알려줘.
아직 편집은 하지 마.

처음부터 리포지토리 전체를 보여주는 것이 아니라, 필요한 파일만 지정하는 것이 기본입니다.

#codebase

함부로 사용하지 않기

6. VS Code Copilot에서는 #codebase나 파일 지정을 통해 컨텍스트 (Context)를 전달할 수 있습니다.

편리하지만, #codebase를 함부로 사용하면 불필요한 파일까지 읽게 될 가능성이 있습니다.

나쁜 예:

#codebase 전체를 보고 적절하게 개선해줘

좋은 예:

#src/auth/login.ts 만 보고
#src/auth/session.ts 는 필요하다면 참조해줘

기본 원칙은,

전체를 보여주기 전에, 대상 파일을 좁힌다

입니다.

7. 새로운 태스크마다 새로운 채팅

이 방법은 상당히 효과적입니다.

채팅이 길어지면 과거의 대화, 파일 내용, 도구 (Tool) 출력 등이 문맥 (Context)으로서 쌓이게 됩니다.

같은 태스크라면 그대로 이어서 해도 좋지만, 다른 태스크로 넘어간다면 새로운 채팅을 만드는 것이 절약에 도움이 됩니다.

같은 채팅에서 OK인 예:

로그인 수정
↓
동일한 로그인 수정의 테스트 추가
...

새로운 채팅을 권장하는 예:

로그인 수정
↓
README 작성
...

다른 태스크로 넘어갈 때는 이전의 문맥을 끌고 오지 않는 편이 비용이 저렴해지기 쉽습니다.

/compact

8. 같은 태스크가 길어졌을 때: 같은 태스크라도 채팅이 길어진 경우에는 /compact로 대화를 압축할 수 있습니다.

예:

/compact 현재 버그, 변경 파일, 남은 TODO만 남기고 압축

완전히 다른 태스크라면 새로운 채팅을, 같은 태스크가 길어진 것이라면 /compact를 사용하는 것이 편리합니다.

/fork

9. 다른 안 (Alternative): 같은 태스크에서 다른 안을 시도하고 싶을 때는 /fork가 편리합니다.

같은 채팅에서 여러 안을 섞으면 문맥이 오염될 수 있습니다.

용도 구분은 다음과 같습니다.

완전히 다른 태스크 → 새로운 채팅
같은 태스크의 다른 안 → /fork
같은 태스크가 길어짐 → /compact

10. Agent는 필요할 때만 사용

Agent 모드는 편리하지만, 절약 목적이라면 상시 사용하는 것은 좋지 않습니다.

Agent에 적합한 작업은 다음과 같습니다.

• 여러 파일을 가로지르는 구현
• 테스트 실행을 포함한 수정
• 원인 조사가 필요한 버그
• 파일 탐색이 필요한 작업
• 명령 실행이 필요한 작업

반대로, 다음은 Ask나 Edit만으로 충분합니다.

• 1개 파일의 작은 수정
• 에러의 의미를 묻기
• 구현 방침 상담
• 코드 조각 (Code snippet) 개선
• 주석이나 README 수정

Agent는 편리하지만, 자유롭게 탐색하게 두면 비용이 높아지기 쉬우므로 사용하는 상황을 좁히는 것이 중요합니다.

11. 불필요한 tools / MCP 끄기

Agent가 사용할 수 있는 도구가 많으면 불필요한 도구 호출이 늘어날 수 있습니다.

도구 호출 결과도 컨텍스트를 소비하므로, 절약하고 싶다면 불필요한 tools나 MCP 서버를 끄는 것이 유효합니다.

예:

이번에 필요한 tools:
- filesystem only
불필요:
...

필요할 때만 활성화하는 운영 방식이 좋습니다.

법인 이용 시에는 MCP가 사내 정책이나 관리자 설정과도 관련되므로, 함부로 외부 MCP를 추가하지 않는 것이 안전합니다.

.gitignore / files.exclude로 거대 파일 제외하기

12. 생성물이나 거대 파일은 AI에게 읽게 해도 의미가 없는 경우가 많습니다.

제외 후보는 다음과 같습니다.

node_modules/
dist/
build/
...

단, lock file이나 생성 파일은 필요한 상황도 있습니다.

평소에는 읽게 하지 않고, 필요한 때만 지정하는 정도가 적당합니다.

memory.md에 짧게 요약하여 다음 채팅에서 읽게 하기

13. memory.md는 Copilot의 내부 메모리가 아닙니다.

리포지토리 내에 두는 일반적인 Markdown 파일입니다.

추천하는 방식은 다음과 같습니다.

docs/ai-memory.md

목적은 다음과 같습니다.

긴 채팅 이력을 읽게 하는 대신
↓
짧은 memory.md만 읽게 함
...

주의할 점은, memory.md를 읽게 하는 것도 컨텍스트에 포함된다는 것입니다.

다만, 긴 채팅 이력을 전부 읽게 하는 것보다 짧은 요약을 읽게 하는 것이 더 저렴하다는 뜻입니다.

docs/ai-memory.md 예시

# AI Memory
## Current Status
- Main features:
...

작업 종료 시의 프롬프트

Update docs/ai-memory.md with:
- what changed
- changed files
...

다음 새로운 채팅의 시작

Cost-saving mode.
Read docs/ai-memory.md first.
Target only: <file or directory>.
...

14. M365 Copilot / ChatGPT 등으로 프롬프트를 미리 확정하기

Copilot에 대충 던지기 전에, 다른 AI나 메모장에서 프롬프트 (Prompt)를 정리해 두는 것도 유효합니다.

대충 작성한 프롬프트:

뭔가 버그가 있으니까 고쳐줘

정리된 프롬프트:

Cost-saving mode.
Target only: src/auth/login.ts
Problem:
...

프롬프트를 확정하고 나서 던지면, Copilot 측의 탐색이나 되묻는 과정이 줄어듭니다.

단, 법인 이용 시에는 주의가 필요합니다.

사내 코드, 고객 정보, 장애 로그, 개인 정보 등을 사내에서 승인되지 않은 AI 서비스에 붙여넣지 않도록 합니다.

안전하게 작성한다면,

사내에서 허가된 AI 환경에 한하여, 기밀 정보를 포함하지 않고 프롬프트를 정리한다

라는 표현이 좋다고 생각합니다.

15. 자동 완성(Completion)과 Next Edit Suggestions 활용하기

Code completions와 Next Edit Suggestions는 AI Credits 소비 대상이 아닙니다.

따라서 Chat이나 Agent에게 전부 작성하게 하기보다,

직접 함수명·타입·주석을 작성한다
↓
자동 완성으로 다음 내용을 나오게 한다

하는 편이 절약됩니다.

예시:

// Calculate monthly usage percentage and return warning level
function calculateUsageWarningLevel(

여기까지 작성하고, 자동 완성에 맡기는 이미지입니다.

"전부 AI에게 만들게 하기"보다, "자신이 방향성을 작성하고 자동 완성으로 채우게 하기"가 비용이 적게 듭니다.

16. Copilot Code Review를 남발하지 않기

Copilot Code Review는 편리하지만, AI Credits를 소비합니다.

게다가 상황에 따라서는 GitHub Actions minutes도 소비합니다.

절약하려면 다음 사항을 의식해야 합니다.

• 중요한 PR(Pull Request)에만 사용하기
• 거대한 PR에는 사용하지 않기
• 생성된 파일을 포함하지 않기
• lock file이나 빌드(build) 결과물을 포함하지 않기
• 먼저 스스로 diff를 확인하기

AI 리뷰는 편리하지만, 보안 리뷰나 최종 품질 보증을 완전히 대체하는 것은 아닙니다.

17. Custom Agent에 경량 모델과 필요한 최소한의 도구(tools) 설정하기

매번 모델이나 도구(tools)를 수동으로 선택하는 것이 번거롭다면, 용도별로 Custom Agent를 만드는 것도 방법입니다.

예시:

docs-agent → 경량 모델 / 도구(tools) 없음
ui-agent → mini 계열 / filesystem만 사용
review-agent → 중간 규모 모델 / read-only 중심
...

포인트는 Agent마다 다음 항목을 좁히는 것입니다.

사용할 모델
사용 가능한 도구(tools)
대상 태스크(task)
...

Agent를 만능으로 만들면 결국 비용이 늘어나기 쉽습니다.

Custom Agent는 "작고 전문화"하는 것이 좋습니다.

18. /context로 무거운 원인 확인하기

Copilot CLI 등에서는 /context로 현재의 컨텍스트 (Context)를 확인할 수 있습니다.

/context

확인해야 할 포인트는 다음과 같습니다.

대화 이력이 무거운가
파일 읽기가 무거운가
MCP tools가 무거운가
...

무엇이 무거운지 모르는 상태에서 절약하는 것보다, 원인을 보고 나서 대책을 세우는 것이 효과적입니다.

19. 프롬프트 캐시(prompt cache)를 의식하여 고정 템플릿 사용하기

매번 시작 프롬프트나 지시 사항을 계속 바꾸기보다, 고정 템플릿을 사용하는 것이 안정적입니다.

피해야 할 예:

매번 다른 긴 서문을 넣는다
그날의 기분이나 잡담을 대량으로 넣는다
태스크와 관계없는 설명을 넣는다

추천 방식:

고정된 짧은 템플릿을 사용한다
instructions.md를 짧고 안정적으로 유지한다
의뢰 형식을 통일한다

프롬프트 캐시 (prompt cache)를 노린다기보다, 프롬프트를 매번 짧고 안정적으로 유지한다고 생각하면 이해하기 쉽습니다.

20. gh CLI를 설치하여 MCP tools의 낭비를 줄이기

Copilot CLI나 GitHub MCP를 사용하는 경우, GitHub CLI를 사용할 수 있는 환경이라면 편리합니다.

gh --version

CLI나 MCP 주변 환경은 의존성이 있기 때문에 모든 사람에게 적합한 것은 아닙니다.

다만, CLI 기반으로 Copilot을 사용하는 사람에게는 GitHub 주변 조작을 정리하기 쉬워집니다.

법인 이용 시에는 회사 PC에 CLI를 설치해도 되는지, MCP를 사용해도 되는지를 사전에 확인하는 것이 안전합니다.

21. CLI review 전에 가벼운 모델로 전환하기

CLI에서 리뷰 계열 명령어를 사용할 경우, 먼저 가벼운 모델이나 Auto로 전환하면 절약이 되는 경우가 있습니다.

예:

/model Auto
/review

또는,

/model <경량 모델>
/review

단, 보안이나 과금 관련 리뷰는 가벼운 모델에 너무 치우치면 품질 면에서 불안 요소가 있습니다.

중요한 리뷰에서는 비용뿐만 아니라 안전성도 고려해야 합니다.

22. 최근 이용 상황에 따른 절약 어드바이스 명령어 사용하기

환경에 따라서는 최근 이용 상황에 맞춘 절약 어드바이스를 제공하는 명령어를 사용할 수 있습니다.

/chronicle:cost-tips

또는 환경에 따라 다음과 같은 표기 방식이 될 수도 있습니다.

/chronicle cost tips

버전이나 환경에 따라 사용할 수 없을 가능성도 있으므로, "사용 가능한 환경이라면 시도해 본다" 정도의 태도가 적당합니다.

23. Agent Debug Logs로 무거운 원인 파악하기

상급자용 방법이지만, Agent Debug Logs를 보면 어디에서 토큰이나 도구 호출 (tool call)이 증가하고 있는지 확인할 수 있습니다.

확인해야 할 포인트는 다음과 같습니다.

• tool call이 너무 많지는 않은가
• 불필요한 파일을 읽고 있지는 않은가
• 출력이 너무 길지는 않은가
• 캐시 (cache)가 작동하고 있는가
• 동일한 조사를 반복해서 수행하고 있지는 않은가

"갑자기 AI Credits 소모가 빨라졌다"고 느낄 때 유용합니다.

실제로 사용하는 템플릿

평소 질문할 때

Ask mode.
Auto model.
짧게 대답해줘.

구현 전

Cost-saving mode.
Target only: <file or directory>
Do not scan the whole repository.
...

구현 시

Implement only the approved plan.
No unrelated refactor.
Keep output concise.
...

작업 종료 시

Update docs/ai-memory.md with:
- what changed
- changed files
...

다음 새로운 채팅 시작 시

Cost-saving mode.
Read docs/ai-memory.md first.
Target only: <file or directory>.
...

법인 이용 시 주의사항

법인 이용 시에는 단순히 AI Credits를 절약하는 것뿐만 아니라, 정보 유출·감사·사내 규칙과의 정합성도 고려해야 합니다.

특히 주의해야 할 점은 다음과 같습니다.

M365 Copilot / ChatGPT 등으로 미리 프롬프트를 확정하기
외부 MCP 추가하기
사내 미승인 모델 사용하기

이것들은 편리하지만, 사내 코드나 로그를 어디로 전송하느냐라는 문제가 있습니다.

기사 작성이나 사내 전파 시에는 다음과 같이 생각하는 것이 안전합니다.

사내에서 허가된 AI 환경에 한해서만 이용할 것
기밀 정보·고객 정보·소스 코드를 미승인 AI에 붙여넣지 말 것
CLI / MCP / Custom Endpoint는 관리자가 허가한 환경에서만 이용할 것

요약

GitHub Copilot의 AI Credits 시대는 AI를 사용하지 않는 시대가 아니라, AI에 전달하는 정보량을 관리하는 시대라고 생각합니다.

특히 중요한 것은 다음과 같습니다.

Ask 모드 우선 사용
경량 모델 / Auto 모드 사용
대상 파일 지정
...

개인적으로 가장 봉인해야 할 프롬프트는 이것입니다.

전부 읽어서 알아서 잘 해줘

앞으로는,

대상 좁히기
계획과 구현 분리하기
긴 히스토리를 끌고 가지 않기

라는 방식의 사용이, AI Credits (AI 크레딧) 절약은 물론 구현 품질 향상에도 효과적일 것이라고 생각합니다.

Discussion