GitHub Copilot AI credit 세션 한도: 백그라운드 에이전트 과소비를 막는 새 안전장치

요약: GitHub가 Copilot CLI와 Copilot SDK에 AI credit session limit을 공개 프리뷰로 추가했다. 사람이 지켜보지 않는 자동화 작업에서 에이전트가 계속 모델을 호출하는 문제를 줄이는 기능이며, CI·배치·장시간 리팩터링 큐를 운영하는 팀에는 비용 안전장치로 볼 수 있다.

새 기능의 핵심

GitHub Changelog와 공식 문서에 따르면 AI credit session limit은 Copilot CLI 또는 SDK 세션 하나가 사용할 수 있는 AI credits 상한을 정한다. Interactive session에서는 /limits set max-ai-credits NUMBER 형태로 설정하고, non-interactive 실행에서는 --max-ai-credits=NUMBER 옵션을 넘긴다.

GitHub는 AI credit을 모델 상호작용 비용을 추적하는 단위로 설명하며, 문서상 1 credit은 0.01달러다. 실제 사용량은 선택 모델과 토큰 수에 따라 달라진다. 한도에 도달하면 에이전트는 무한히 계속 달리지 않고 정리한 뒤 멈춘다. interactive mode에서는 한도를 올리고 이어갈 수 있고, non-interactive mode에서는 실행이 종료된다.

중요한 단서는 soft limit이라는 점이다. 이미 진행 중인 응답은 끝난 뒤 멈추므로 설정값을 약간 넘을 수 있다. 이 기능은 월 예산이나 조직 전체 spending limit을 대체하지 않는다. 대신 ‘한 작업이 통제 없이 커지는 것’을 막는 세션 단위 회로 차단기다.

왜 지금 개발팀에 필요한가

코딩 에이전트 비용 사고는 대개 평균 사용량에서 발생하지 않는다. 문제는 사람이 퇴근한 뒤 백그라운드 작업이 실패한 테스트를 계속 고치려 하거나, 잘못 잡은 목표 때문에 큰 리팩터링을 끝없이 시도할 때 생긴다. 특히 subagent, background compaction, tool call이 붙으면 비용은 사람이 예상한 프롬프트 한 줄보다 훨씬 커진다.

GitHub 설명도 자동화 작업에서 누군가 적극적으로 모니터링하지 않을 때 유용하다고 말한다. 이 말은 기능의 성격을 정확히 보여준다. 세션 한도는 productivity 기능이 아니라 운영 안전장치다. CI에서 lint 수정, dependency upgrade, release note 작성 같은 일을 에이전트에 맡길 때 ‘실패하면 멈춘다’는 규칙을 비용 단위로 강제한다.

기존에는 타임아웃만 거는 팀이 많았다. 그러나 타임아웃은 느린 모델과 빠른 모델을 구분하지 못한다. 20분 동안 싼 모델을 조금 쓰는 작업과, 3분 동안 고가 모델을 여러 번 호출하는 작업은 비용이 다르다. AI credit 한도는 시간 제한보다 비용에 더 직접적으로 대응한다.

운영 기준: 얼마로 시작할까

GitHub 문서는 대부분 모델 호출이 20 credits 이상 들 수 있으므로 30 credits보다 큰 값에서 효과가 좋다고 안내한다. 이 문장을 그대로 ‘무조건 30 이상’으로 읽으면 부족하다. 팀은 작업 유형별로 한도를 나눠야 한다.

문서 생성이나 간단한 테스트 추가는 낮은 한도로 시작할 수 있다. 예를 들어 PR 설명 초안, changelog 생성, 타입 에러 한두 개 수정은 50~100 credits 범위에서 충분할 가능성이 높다. 반면 실패 원인 분석, flaky test 재현, 대규모 dependency upgrade는 더 높은 한도가 필요하다. 중요한 것은 한도를 넉넉하게 잡는 것이 아니라, 한도 초과가 작업 분할 신호가 되도록 만드는 것이다.

권장 운영 방식은 3단계다. 1단계는 dry run에 가까운 관찰 기간이다. 한도를 높게 두고 실제 소모량을 기록한다. 2단계는 작업별 기본 한도를 정한다. 3단계는 한도 초과 시 사람이 볼 요약 포맷을 정한다. ‘무엇을 시도했고, 어떤 파일을 바꿨고, 왜 더 필요했는가’가 없으면 한도는 단순 실패로만 남는다.

CI와 스크립트에 붙일 때의 설계

Non-interactive mode에서는 copilot -p "YOUR PROMPT" --max-ai-credits NUMBER 형태로 실행한다. 이 방식은 GitHub Actions, 사내 배치 서버, 릴리즈 자동화에서 유용하다. 다만 한도만 넣고 끝내면 안 된다. 실패 exit code, 변경 파일 diff, 사용 credits, 모델 정보, 에이전트 마지막 요약을 artifact로 남겨야 한다.

CI에서는 에이전트가 직접 main branch에 push하지 못하게 해야 한다. 세션 한도는 비용을 막을 뿐, 잘못된 코드를 막지 않는다. 안전한 흐름은 branch 생성, 제한된 파일 범위 수정, 테스트 실행, PR 생성, 사람 리뷰다. 특히 migration이나 보안 설정은 자동 merge 대상에서 제외한다.

또한 작업 프롬프트를 작게 유지해야 한다. ‘전체 저장소를 개선해줘’ 같은 요청은 한도에 빨리 걸리고 결과도 검토하기 어렵다. ‘TypeScript strict 모드에서 발생하는 src/payments 폴더의 타입 에러만 수정해줘. public API 변경 금지’처럼 범위와 금지를 명시해야 한다.

세션 한도와 예산 한도의 차이

세션 한도는 한 번의 작업 폭주를 막는다. 월 예산 한도는 조직 전체 지출을 막는다. 둘은 서로 대체 관계가 아니다. 예를 들어 팀원이 100 credits 한도 작업을 하루에 100번 실행하면 세션별로는 안전하지만 월 예산은 빠르게 소모된다.

따라서 계층형 한도가 필요하다. 개인별 일일 한도, 저장소별 주간 한도, CI job별 세션 한도, 조직 전체 월 한도를 나눠야 한다. GitHub의 session limit은 이 중 CI job과 개별 CLI 세션에 해당한다. 특히 백그라운드 agent queue를 운영한다면 큐 전체 동시성도 제한해야 한다.

관리자는 비용 알림만 보지 말고 작업 성공률과 함께 봐야 한다. 비용이 낮아졌는데 성공률이 떨어지면 사람이 다시 작업하느라 총비용이 늘어난다. 반대로 비용이 조금 늘어도 PR throughput이 빨라지고 rollback이 줄면 도입 효과가 있다.

개발 문화 측면의 변화

이 기능은 ‘AI를 마음껏 쓰지 말자’가 아니라 ‘AI 작업도 리소스가 있는 운영 대상’이라는 신호다. CPU, 메모리, DB connection pool에 limit을 거는 것처럼 에이전트에도 credit limit을 거는 게 자연스러워지고 있다.

좋은 팀은 한도를 처벌로 쓰지 않는다. 한도 초과는 프롬프트가 너무 크거나, 작업이 잘못 나뉘었거나, 모델 선택이 맞지 않다는 피드백이다. 한도에 걸린 세션을 분석해 작업 템플릿을 고치면 다음 비용이 줄어든다.

실행 체크리스트

• Copilot CLI 1.0.66 이상, SDK 1.0.5 이상인지 확인한다.

• interactive 작업에는 /limits set max-ai-credits NUMBER를 적용한다.

• CI·배치 실행에는 --max-ai-credits=NUMBER를 기본 옵션으로 넣는다.

• 한도 초과 시 마지막 요약, diff, 테스트 결과, 사용 credits를 artifact로 저장한다.

• 세션 한도와 별도로 개인·저장소·조직 예산 한도를 운영한다.