GitHub Copilot에서는 이용할 모델을 고정하는 방법과 Auto 모드에 맡기는 방법이 있습니다.

고성능 모델을 고정해 두면 항상 좋은 결과를 얻을 수 있을 것처럼 보입니다. 반면, 조직 전체가 이용 한도(Quota)를 공유하고 있는 경우, 모델 선택 방식에 따라 소비량에 큰 차이가 발생할 가능성이 있습니다.

이에 따라, 소속된 개발 팀의 연속된 2개월간 이용 데이터를 분석하여 Auto 모드와 모델 고정 시의 경향을 비교했습니다.

각 수치는 공개 가능한 범위 내에서 반올림하였습니다.

• Auto의 중앙값은 약 100~130으로, 소비량이 비교적 안정적임
• 모델 고정 시의 평균 소비량은 Auto의 약 2.4~2.8배
• 고정 시에는 약 6,000~7,000을 초과하는 스파이크(Spike)가 발생
• Auto에서는 약 80%의 요청에서 Sonnet 이외의 모델이 선택됨
• 고정 지정된 Sonnet 계열은 약 20%의 요청에서 소비량의 약 3분의 2를 차지함

고성능 모델을 사용하는 것 자체가 문제는 아닙니다.

Auto에서도 필요에 따라 Sonnet이 선택되고 있으므로, 통상적으로는 Auto를 이용하고 명확한 목적이 있는 경우에만 고성능 모델로 전환하는 것이 개발 효율과 이용 한도를 양립하기에 더 유리하다고 생각합니다.

대상은 GitHub Copilot의 연속된 2개월간 조직 내 이용 데이터입니다.

다음 항목들을 확인했습니다.

• Auto와 모델 고정의 소비량
• 평균값, 중앙값, 최댓값
• Auto에서 선택된 모델
• 모델별 이용 횟수와 소비량

참고로, 이번에 분석한 것은 모델 선택과 크레딧(Credit) 소비량입니다.

생성된 코드의 품질, 태스크 완료 시간, 수정량 등은 측정하지 않았으므로, Auto와 모델 고정 간의 품질 차이까지는 평가하지 않았습니다.

2개월간의 결과를 공개 가능한 범위로 반올림하면 다음과 같습니다.

모델 고정은 중앙값만 보면 Auto보다 낮게 나타납니다.

하지만 평균값은 Auto의 약 2.4~2.8배였습니다.

모델 고정 시에는 중앙값 부근의 값이 비교적 작은 반면, 일부에 수천 단위의 스파이크가 포함되어 있었습니다.

따라서 중앙값만 보면 소비량이 작아 보이지만, 소수의 큰 값에 의해 평균값이 크게 끌어올려집니다.

이번 데이터에는 요청 내용이 포함되어 있지 않기 때문에, 어떤 처리가 스파이크를 유발했는지까지는 판단할 수 없습니다.

다만, 조직 전체의 이용 한도를 살펴보는 데 있어서는 평균값이나 중앙값뿐만 아니라, 최댓값이나 상위의 고소비 요청(High-consumption request)도 확인할 필요가 있다는 것을 알 수 있습니다.

Auto 모드에서 실제로 선택되었던 주요 모델은 다음과 같습니다.

• GPT-5.3-Codex
• Claude Sonnet 4.6
• Claude Haiku 4.5
• GPT-5.4
• GPT-5.4 mini

2개월 모두 가장 많이 선택된 것은 GPT-5.3-Codex였습니다.

Auto 모드 내의 선택 결과를 Claude Sonnet 4.6과 그 외로 나누면 다음과 같습니다.

Auto에서는 약 80%의 요청에서 Sonnet 이외의 모델이 선택되었습니다.

반면, 약 20%의 요청에서는 Claude Sonnet 4.6이 선택되었습니다.

즉, Auto는 고성능 모델을 일률적으로 피하는 것이 아니라, 요청에 따라 모델을 전환하는 메커니즘이라고 생각할 수 있습니다.

다만, 이 결과만으로 "약 80%의 태스크에서는 Sonnet을 사용할 의미가 없다"라고까지 단정할 수는 없습니다.

이번에 확인된 것은 Auto 모드에 의한 실제 선택 결과로서, 약 80%에서 Sonnet 이외가 선택되었다는 사실입니다.

모델별로 보면, 고정 지정된 Claude Sonnet 계열의 소비량이 돌출되어 있었습니다.

고정 지정된 Sonnet 계열은 요청 전체의 약 20%였습니다.

그럼에도 불구하고, 소비량 측면에서는 약 3분의 2를 차지했습니다.

다시 말해, 약 20%의 요청이 전체 소비량의 약 64~67%를 차지했다는 의미입니다.

이 결과로부터 단순한 이용 횟수뿐만 아니라, 어떤 모델을 고정했는지가 조직 전체의 소비량에 큰 영향을 미쳤음을 알 수 있습니다.

여기서부터는 이번 결과를 바탕으로 한 운영상의 고려 사항입니다.

평소 Copilot에 요청하는 모든 내용이 복잡한 태스크(Task)인 것은 아닙니다.

• 코드 보완 (Code Completion)
• 기존 코드에 맞춘 처리 추가
• DTO나 타입 정의 생성
• 테스트 코드의 뼈대(Template) 작성
• 경미한 수정
• 정형적인 변환 처리

이러한 작업에서는 Auto 모드에 맡겨도 충분한 경우가 많다고 생각됩니다.

반면, 다음과 같은 태스크에서는 고성능 모델을 명시적으로 선택할 가치가 있습니다.

• 신규 기능이나 아키텍처 설계
• 복잡한 리팩터링 (Refactoring)
• 원인 파악이 어려운 버그 조사
• 여러 파일을 가로지르는 변경
• 여러 구현 안 및 트레이드오프 (Trade-off) 비교
• 긴 컨텍스트 (Context)를 전제로 한 리뷰

중요한 것은 고성능 모델을 금지하는 것이 아닙니다.

태스크에 따라 구분하여 사용하는 것입니다.

이번 결과로부터 다음과 같은 운영 방식이 현실적이라고 판단됩니다.

일상적인 코딩이나 버그 수정에서는 Auto를 표준으로 합니다.

Auto 모드에서도 필요하다고 판단되는 태스크에서는 Claude Sonnet 4.6이 선택됩니다.

복잡한 설계나 버그 조사 등 명확하게 높은 추론 성능이 필요한 상황에서는 Sonnet, Opus, GPT-5.6 계열을 개별적으로 지정합니다.

고성능 모델을 고정해 두면, 그 이후의 태스크에서도 동일한 모델이 계속 사용됩니다.

따라서 고정 이용 후에는 다시 Auto로 되돌리는 것까지 운영 프로세스에 포함합니다.

이용 상황을 확인할 때는 다음 지표를 함께 확인합니다.

• 평균값
• 중앙값
• 최댓값
• 모델별 이용 횟수
• 모델별 총 소비량
• Auto와 고정 지정의 비율

평균값이 높다고 해서 모든 사용자가 균등하게 많이 사용하고 있다고 단정할 수는 없습니다.

일부 고소비 요청이나 특정 모델의 고정 이용이 전체 수치를 끌어올리고 있을 가능성이 있습니다.

이번 데이터만으로는 다음 사항까지는 판단할 수 없습니다.

• Auto와 모델 고정 간에 생성된 코드의 품질 차이가 어느 정도였는지
• 고성능 모델을 통해 개발 시간이 어느 정도 단축되었는지
• 소비량에 상응하는 성과를 얻었는지
• 동일한 태스크를 서로 다른 모델로 실행했을 때의 차이
• 사용자가 모델을 고정한 이유

따라서 Auto가 항상 품질 면에서도 최적이라고 단정할 수는 없습니다.

다만, 조직 전체의 이용 한도(Quota)를 안정화한다는 관점에서는 Auto를 표준으로 삼고, 필요한 상황에서만 고성능 모델로 전환하는 운영 방식이 유효해 보입니다.

• Auto의 중앙값은 약 100~130
• 모델 고정 시의 평균값은 Auto의 약 2.4~2.8배
• 고정 시에는 약 6,000~7,000 이상의 스파이크 (Spike) 발생
• Auto에서는 약 80%의 경우 Sonnet 이외의 모델이 선택됨
• 고정 지정된 Sonnet 계열은 약 20%의 요청으로 소비량의 약 64~67%를 차지함

Copilot의 이용 한도를 안정화하려면 단순히 이용을 자제하기보다, Auto를 표준으로 하고 고성능 모델의 고정을 필요한 상황으로 한정하는 것이 더 현실적입니다.

고성능 모델을 사용할 수 있다는 것은 Copilot의 큰 장점입니다.

그렇기에 모든 태스크에서 모델을 고정하는 것이 아니라, 필요한 상황에서 적절히 구분하여 사용하는 것이 개발 효율과 이용 한도의 양립으로 이어질 것이라고 생각합니다.