GitHub은 이번 주 Copilot 사용량 메트릭(metrics) API에 아주 작은 필드를 추가했는데, 이는 매우 확신에 찬 수많은 스프레드시트를 만들어낼 것입니다.

엔터프라이즈 및 조직 관리자는 이제 사용자 수준의 Copilot 사용 보고서에서 ai_credits_used를 확인할 수 있습니다. 사용자당 단 하나의 필드입니다. 일일 및 28일 보고서에서 사용할 수 있습니다. 이것은 인보이스(invoice)가 아니며, GitHub은 이것이 청구된 총액이라기보다 소비 신호(consumption signal)라고 조심스럽게 밝히고 있습니다.

그럼에도 불구하고, 그 흐름은 명확합니다.

이제 AI 사용량은 채택률(adoption), 활동(activity), 팀, 부서, 비용 센터(cost center), 그리고 회사가 이미 대시보드로 내보내고 있는 그 어떤 것과도 나란히 놓일 수 있습니다.

그것은 유용합니다.

또한, 그것은 도구의 지표(tool metric)가 관리 지표(management metric)로 변하는 정확한 방식이기도 합니다.

일단 그런 일이 발생하면, 질문은 더 이상 "AI 사용량을 측정할 수 있는가?"가 아닙니다.

질문은 "이 지표가 어떤 기이한 행동을 만들어낼 것인가?"가 됩니다.

모든 유용한 지표는 유혹이 된다

왜 이 필드가 존재하는지 이해합니다.

만약 회사가 Copilot에 비용을 지불하고 있다면, 특히 더 비싼 모델과 프리미엄 기능에 사용량 기반 요소가 결합되어 있다면, 소비량을 이해할 방법이 필요합니다. 플랫폼 팀은 예산 신호가 필요합니다. 엔지니어링 리더는 채택 신호가 필요합니다. 조달(Procurement) 부서는 "사람들이 좋아하는 것 같다"는 말보다 더 구체적인 무언가가 필요합니다. 재무(Finance) 부서는 결국 왜 어떤 조직은 다른 조직보다 크레딧을 훨씬 더 빨리 소진하는지 물을 것입니다.

그것은 정상입니다.

문제는 소비 신호가 생산성 신호(productivity signal)로 취급될 때 시작됩니다.

높은 AI 크레딧 사용량은 개발자가 에이전트 모드(agent mode), 코드 리뷰(code review), 테스트 생성(test generation), 리팩터링(refactoring) 또는 연구를 통해 가치 있는 작업을 수행하고 있음을 의미할 수 있습니다. 하지만 이는 또한 개발자가 막혀서, 모델에게 잘못된 문제를 해결하라고 반복해서 요청하거나, 삭제될 코드를 생성하거나, 작은 모델로도 충분했을 곳에 무거운 모델을 사용하고 있음을 의미할 수도 있습니다.

낮은 AI 크레딧 사용량은 개발자에게 많은 도움이 필요하지 않다는 의미일 수 있습니다. 이는 작업의 대부분이 설계 (design), 리뷰 (review), 디버깅 (debugging), 장애 대응 (incident response), 멘토링 (mentoring) 또는 아키텍처 (architecture)에 집중되어 있음을 의미할 수 있습니다. 또한 코드베이스 (codebase)가 작고 잘 파악되어 있음을 의미할 수도 있습니다. 개발자가 회의적일 수도 있고, 아직 도구 사용법을 익히지 못했을 수도 있습니다.

숫자 그 자체만으로는 알 수 없습니다.

그것이 첫 번째 함정입니다.

AI 크레딧은 결과물 (output)이 아닙니다.

그것은 투입물 (input)입니다.

우리는 이 영화를 본 적이 있습니다

소프트웨어 분야에는 세기 가장 쉬운 것을 측정하고, 그것이 우리가 실제로 중요하게 생각하는 것을 나타내는 것처럼 가장해 온 긴 역사가 있습니다.

코드 라인 수 (Lines of code). 커밋 (Commits). 풀 리퀘스트 (Pull requests). 스토리 포인트 (Story points). 종료된 티켓 (Tickets closed). 테스트 커버리지 비율 (Test coverage percentage). 빌드 횟수 (Build count). 배포 횟수 (Deploy count). 리뷰 코멘트 (Review comments). 회의 시간 (Meeting hours). 슬랙 메시지 (Slack messages). 만약 당신이 유독 저주받은 곳에서 일한다면 키보드 활동량 (Keyboard activity)까지도 포함됩니다.

이러한 지표 중 일부는 맥락에 따라 유용할 수 있습니다. 하지만 그 중 어느 것도 엔지니어링 품질 (engineering quality)을 나타내지는 않습니다.

코드 라인 수는 가장 전형적인 사례입니다. 모두가 그것이 어리석다는 것을 알면서도 여전히 실수로 그것을 다시 만들어내기 때문입니다. 불필요한 코드 3,000줄을 삭제한 개발자가 이번 분기에 가장 가치 있는 일을 했을 수도 있습니다. 반면 3,000줄을 추가한 개발자는 6개월 치의 유지보수 작업을 만들어냈을 수도 있습니다.

지표 자체가 악한 것이 아닙니다. 해석이 악한 것입니다.

AI 크레딧도 똑같은 냄새가 납니다.

만약 팀이 예산, 도입률, 도구의 동작을 이해하기 위해 크레딧을 사용한다면, 좋습니다. 팀이 특정 워크플로 (workflow)가 왜 비용이 많이 드는지 묻기 위해 사용한다면, 이 또한 좋습니다. 팀이 특정 부서에 교육이 필요한지 결정하기 위해 사용한다면, 아마도 좋을 것입니다.

하지만 관리자가 작업 내용, 코드, 리뷰, 그리고 결과물을 살펴보지 않은 채, 왜 앨리스(Alice)는 밥(Bob)보다 10배 많은 크레딧을 썼는지, 혹은 왜 캐롤(Carol)은 거의 쓰지 않았는지 묻기 시작한다면, 우리는 더 세련된 브랜딩을 입은 '코드 라인 수의 세계'로 되돌아가는 것입니다.

활동은 레버리지 (leverage)가 아닙니다

가장 흥미로운 AI 작업이 항상 가장 눈에 띄는 AI 작업인 것은 아닙니다.

시니어 엔지니어는 세 가지 가능한 설계를 탐색하기 위해 한 시간 동안 Copilot을 집중적으로 사용한 뒤, 최종 변경 사항은 대부분 직접 손으로 작성할 수도 있습니다. 또 다른 엔지니어는 에이전트 모드 (agent mode)에서 오후 내내 시간을 보내며 대규모 풀 리퀘스트 (pull request)를 생성하지만, 도메인 제약 조건 (domain constraint)을 놓쳐 리뷰어들에게 거절당할 수도 있습니다. 세 번째 엔지니어는 까다로운 운영 장애 (production incident) 상황에서 채팅을 러버 덕 (rubber duck)처럼 활용하며 코드를 전혀 배포하지 않을 수도 있습니다.

이들 중 누가 생산적이었을까요?

크레딧 수치는 그 질문에 답할 수 없습니다.

크레딧 수치는 무언가가 소비되었다는 사실만을 알려줄 수 있습니다.

그 작업이 더 나아졌는지 여부는 알려줄 수 없습니다.

이러한 구분이 중요한 이유는 AI 도구들이 활동을 매우 분주해 보이게 만들기 때문입니다. 에이전트 (Agents)는 명령어를 실행합니다. 파일을 편집합니다. 요약합니다. 재시도합니다. 테스트를 생성합니다. 디프 (diffs)를 엽니다. 이들은 마치 진전을 이루고 있는 것처럼 보이면서 토큰 (tokens)을 소모할 수 있습니다.

때로는 실제로 진전을 이루기도 합니다.

하지만 때로는 더 보기 좋은 기록을 남기며 똑같은 실수를 반복하며 주변을 맴돌기도 합니다.

만약 관리자들이 소비량만을 본다면, 그들은 움직임 (motion)을 레버리지 (leverage)로 착각할 것입니다.

더 나은 질문은 "누가 AI를 가장 많이 사용했는가?"가 아닙니다.

더 나은 질문은 "AI 사용이 우리가 정당화할 수 있는 방식으로 업무를 어떻게 변화시켰는가?"입니다.

결함 (defects)이 늘어나지 않으면서 리뷰 시간이 줄어들었습니까? 지루한 마이그레이션 (migrations) 비용이 저렴해졌습니까? 불안정한 의존성 업그레이드 (dependency upgrades)가 덜 고통스러워졌습니까? 주니어 엔지니어들이 더 일찍 더 나은 피드백을 받았습니까? 시니어 엔지니어들이 상용구 코드 (boilerplate)에 쓰는 시간을 줄이고 설계에 더 많은 시간을 할애했습니까? 장애 (incidents)가 더 빠르게 해결되었습니까? 팀이 버려진 브랜치 (abandoned branches)를 줄이면서 유지보수 가능한 변경 사항을 배포했습니까?

이것들은 더 어려운 질문들입니다.

그렇기에 더 나은 질문입니다.

비용 가시성 (cost visibility)은 여전히 유익합니다

해답이 "이것을 절대 측정하지 마라"인 것처럼 들리고 싶지는 않습니다.

부디 측정하십시오.

AI 비용은 반드시 가시화되어야 합니다. 그렇지 않으면 팀들은 이미 습관이 형성된 이후에야 청구서를 발견하게 될 것입니다.

만약 새로운 코딩 에이전트 (coding-agent) 워크플로우가 성공적인 의존성 업그레이드(dependency upgrade) 한 건당 4달러가 든다면, 그것은 아주 멋진 일일 것입니다. 하지만 에이전트가 전체 통합 테스트 스위트 (integration suite)를 계속 실행하고, 가장 큰 모델을 호출하며, 동일한 패치 (patch)를 계속 재생성하느라 180달러가 든다면, 누군가는 이를 알아차려야 합니다. 만약 특정 리포지토리 (repository)가 빌드가 느리거나, 테스트가 불안정하거나, 지시 사항 (instructions)이 좋지 않아 크레딧을 낭비하고 있다면, 이는 유용한 플랫폼 피드백이 됩니다.

사용자별 및 팀별 지표는 도입 격차 (adoption gaps)를 드러낼 수도 있습니다. 어떤 팀은 좋은 리포지토리 지시 사항과 좁은 범위의 워크플로우를 구축했기 때문에 실제 가치를 얻고 있을지도 모릅니다. 어떤 팀은 아무도 사용하지 않는 시트 (seats) 비용을 지불하고 있을지도 모릅니다. 또 다른 팀은 AI를 끊임없이 사용하면서도 생성된 작업의 대부분을 거부하고 있을지도 모릅니다.

이 모든 것은 알 가치가 있습니다.

하지만 이 지표는 개인에 대한 도덕적 판단이 아니라, 워크플로우에 연결된 상태로 유지되어야 합니다.

유용한 단위는 종종 "Paulo가 1,200 크레딧을 사용했다"가 아닙니다.

그것은 "서비스 X의 주간 의존성 업데이트 워크플로우가 1,200 크레딧을 사용했고, 3개의 풀 리퀘스트 (pull requests)를 생성했으며, 테스트를 두 번 통과했고, 한 번의 인간 재작성이 필요했으며, 약 반나절의 유지보수 작업을 절감했다"가 되어야 합니다.

이것이 바로 엔지니어링적인 대화입니다.

"왜 Paulo가 1,200 크레딧을 사용했는가?"라는 질문은 그가 무엇을 하고 있었는지 이미 알고 있는 경우가 아니라면 함정입니다.

크레딧을 리뷰 기록의 일부로 만드세요

에이전트 기반 코딩 (agentic coding)을 위해, 저는 크레딧 사용량이 다른 증거들과 함께 나타나기를 바랍니다.

리더보드 (leaderboard) 형식이 아니라,

작업 기록 내의 비용 항목으로서 말입니다.

에이전트 세션 (agent session)에는 ID가 있어야 합니다. 이는 이슈 (issue), 브랜치 (branch), 풀 리퀘스트 (pull request), 로그 (logs), 도구 호출 (tool calls), 모델 선택 (model choices), 재시도 (retries), 테스트 실행 (test runs), 그리고 인간의 승인 (human approvals)과 연결되어야 합니다. 크레딧 사용량도 그곳에 속해야 합니다. 이는 팀이 워크플로우의 실제 비용을 이해하고 이를 결과와 비교하는 데 도움을 줍니다.

예를 들어:

• 소규모 린트 마이그레이션 (small lint migration): 낮은 크레딧, 높은 수용도, 자동화하기 안전함
• 의존성 업그레이드 (dependency upgrade): 중간 크레딧, 중간 수용도, 더 나은 테스트 필요
• 기능 구현 (feature implementation): 높은 크레딧, 낮은 수용도, 인간 주도로 유지
• 장애 조사 (incident research): 가변적인 크레딧, 가치 있는 요약, 증거를 신중하게 보존
• 코드 리뷰 지원 (code review assistance): 낮은 크레딧, 노이즈가 많은 댓글, 저장소 지침 개선

그러한 종류의 측정은 행동을 긍정적인 방향으로 변화시킵니다. 이는 팀이 더 나은 워크플로우 (workflow)를 설계하도록 독려합니다.

나쁜 버전은 팀이 얼마나 많은 AI를 소비했느냐에 따라 개발자의 순위를 매기도록 압박합니다.

하나는 플랫폼 엔지니어링 (platform engineering)입니다.

다른 하나는 API를 가진 카고 컬트 (cargo-cult) 식 관리입니다.

인센티브는 조용히 찾아온다

지표 (metrics)의 위험한 점은 아무도 나쁜 인센티브를 공표할 필요가 없다는 것입니다.

처음에는 대시보드 (dashboard)가 단순히 정보를 제공할 뿐입니다. 그러다 리더가 왜 어떤 팀은 다른 팀보다 Copilot을 적게 사용하는지 묻습니다. 그러다 누군가 목표치를 추가합니다. 그러다 매니저들이 사람들에게 "AI를 더 많이 도입하라"고 부추기기 시작합니다. 그러다 조직이 사용량을 현대성의 척도로 만들었기 때문에, 개발자는 모델을 더 자주 실행해 둡니다.

또는 인센티브가 반대 방향으로 흐를 수도 있습니다.

재무 부서가 높은 소비량을 인지합니다. 매니저가 사람들에게 AI 사용을 정당화하라고 요구하기 시작합니다. 엔지니어들은 비용이 많이 드는 것처럼 보이기 때문에 탐색적 작업에 도구를 사용하는 것을 중단합니다. 팀은 크레딧을 아끼지만 영향력(leverage)을 잃습니다.

두 가지 실패 모두 동일한 실수, 즉 사용량(usage)을 목표로 취급하는 데서 비롯됩니다.

사용량은 목표가 아닙니다.

더 나은 소프트웨어가 목표입니다.

더 저렴한 유지보수가 목표입니다.

더 빠른 피드백이 목표입니다.

덜 지루한 노고 (toil)가 목표입니다.

더 신뢰할 수 있는 시스템이 목표입니다.

만약 AI 크레딧이 이러한 것들을 이해하는 데 도움을 준다면 좋습니다. 만약 그것들이 이러한 것들을 대체한다면, 당신은 더 멋진 원격 측정 (telemetry) 기능을 갖춘 생산성 연극 (productivity theater)을 만든 것입니다.

대신 내가 측정할 것들

만약 내가 Copilot을 광범위하게 사용하는 엔지니어링 조직을 책임지고 있다면, 나는 여전히 AI 크레딧 사용량을 수집할 것입니다. 다만 그것이 단독으로 존재하게 두지는 않을 것입니다.

나는 그것을 워크플로우 결과 (workflow outcomes)와 결합할 것입니다:

• pull request 승인율 (pull request acceptance rate)
• 리뷰 주기 시간 (review cycle time)
• 병합 후 결함률 (defect rate after merge)
• 테스트 실패 패턴 (test failure patterns)
• 되돌려진 변경 사항 (reverted changes)
• 중단된 에이전트 세션 (abandoned agent sessions)
• 인간의 재작성 빈도 (human rewrite frequency)
• 성공적인 작업 템플릿당 비용 (cost per successful task template)
• 워크플로우별 모델 선택 (model choice by workflow)
• 시간에 따른 리포지토리 지침 변경 사항 (repository instruction changes over time)

나는 또한 높은 AI 사용량이 하나의 증상(symptom)인 지점들도 찾아볼 것입니다.

어쩌면 문서화가 제대로 되어 있지 않을 수도 있습니다. 어쩌면 테스트 스위트 (test suite)가 너무 느릴 수도 있습니다. 어쩌면 서비스 경계 (service boundaries)가 불분명할 수도 있습니다. 어쩌면 온보딩 (onboarding) 과정이 고통스러울 수도 있습니다. 어쩌면 리포지토리 (repo)에 유용한 지도가 없어서 에이전트가 계속해서 같은 파일을 다시 읽고 있는 것일 수도 있습니다. 어쩌면 개발자들이 아무도 이해하지 못하는 아키텍처 (architecture)를 보완하기 위해 채팅을 사용하고 있는 것일 수도 있습니다.

그 부분이 바로 내가 흥미롭다고 느끼는 지점입니다.

AI 크레딧 사용량은 개발자 경험 (developer experience) 그 자체를 나타내는 기묘하고 새로운 관측 가능성 (observability) 신호가 될 수 있습니다.

"누가 생산적인가?"가 아니라,

"어디에서 업무를 이해하는 데 비용이 많이 드는가?"가 되는 것입니다.

그것이 훨씬 더 나은 질문입니다.

핵심 요약 (the punchline)

GitHub가 ai_credits_used를 공개하는 것은 합리적인 제품 기능입니다. 기업은 예산 가시성 (budget visibility)이 필요합니다. 플랫폼 팀은 소비 데이터가 필요합니다. AI 보조 개발 (AI-assisted development)이 영원히 신비로운 항목으로 남아 있을 수는 없습니다.

하지만 우리는 이 지표가 무엇을 의미하는지에 대해 솔직해져야 합니다.

AI 크레딧은 소비량을 측정합니다. 그것은 판단력 (judgment), 유지보수성 (maintainability), 레버리지 (leverage), 취향 (taste), 리뷰 품질 (review quality), 장애 대응 (incident response), 멘토링 (mentoring), 또는 최종 시스템이 더 단순해졌는지 여부를 측정하지 않습니다.

그러니 그 수치를 사용하십시오.

다만, 그것을 숭배하지는 마십시오.

이를 잘 다루는 팀은 AI 크레딧을 클라우드 비용 (cloud cost)처럼 다룰 것입니다. 즉, 서비스, 워크플로우, 결과, 그리고 소유권 (ownership)과 결합될 때 유용하게 사용할 것입니다.

이를 잘못 다루는 팀은 코드 라인 수 (lines of code) 지표를 재발명하게 될 것입니다. 다만 이번에는 그 라인이 모델 청구서 (model bill)를 통과하게 될 뿐입니다.

내 프로젝트를 테스트하기 위해 나는 Railway를 사용합니다. 시작하기 위해 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.