[태그:] 머지된 PR당 비용

일반 채팅 질문 하나의 10~50배. 코딩 에이전트가 작업 하나를 처리하면서 쓸 수 있는 토큰 양이에요. 에이전트는 답 한 번 내놓고 끝내지 않아요. 계획을 세우고, 코드를 만들고, 테스트를 돌리고, 실패하면 다시 고치는 과정을 스스로 되풀이하죠. 곤란한 건 에이전트가 쓸모 있어질수록 호출도 같이 늘어난다는 점이에요. 토큰 단위로 요금을 매기는 구조에서는 가장 큰 가치를 만드는 워크플로가 곧 가장 비싼 워크플로가 되는 셈이고요. 인프라 업체 HPE가 MIT 테크놀로지 리뷰에 낸 후원 콘텐츠에서 내놓은 답은 단순해요. 비용을 ‘얼마나 썼나’가 아니라 ‘얼마나 내보냈나’로 재라는 것. 그 잣대가 ‘머지된 PR당 비용’이에요.

테스트가 한 번 실패할 때마다 토큰이 계단식으로 쌓인다

채팅형 AI는 질문 하나에 답 하나가 기본이에요. 비용도 대략 짐작이 되죠. 에이전트는 사정이 달라요. 테스트가 한 번 실패하면 실패 로그를 다시 읽고, 코드를 고치고, 테스트를 또 돌려요. 이 과정에서 앞서 주고받은 맥락이 대개 입력으로 다시 들어가요. 반복이 한 바퀴 돌 때마다 토큰이 계단처럼 한 칸씩 올라가는 구조. 에이전트가 몇 바퀴를 돌지는 미리 정해져 있지 않으니, 채팅 때처럼 질문 수로 비용을 어림하는 방식은 잘 맞지 않아요.

청구서는 이미 기업 예산을 흔들고 있어요. 우버는 클로드 코드(Claude Code) 사용을 넓힌 뒤 1년 치 AI 예산을 연초 몇 달 만에 다 쓴 것으로 알려졌어요. 깃허브 코파일럿은 정액 요금제에서 쓴 만큼 크레딧을 차감하는 방식으로 바꿨고요. 가트너는 AI 코딩에 드는 토큰 비용이 머지않아 개발자 평균 연봉을 넘어설 것으로 내다봤어요. 예산 초과, 요금제 전환, 연봉 추월 전망. 결은 조금씩 달라도 ‘좌석당 얼마’로 끝나던 계산이 흔들리고 있다는 쪽을 가리키는 신호들이에요.

이럴 때 회사가 가장 먼저 꺼내는 카드는 배급제예요. 사용량 상한을 걸고, 좌석 수를 줄이고, 에이전트를 돌리기 전에 승인을 받게 하는 식이죠. 그런데 일괄 제한은 정작 성과를 내는 워크플로까지 막을 수 있어요. 더 근본적인 문제는 엉뚱한 숫자를 줄이려 든다는 점이에요. 토큰당 비용은 ‘소비’를 재는 지표지 ‘결과’를 재는 지표가 아니에요. 지출 중 일부는 재시도나 끝없이 도는 루프 같은 낭비예요. 나머지는 실제로 소프트웨어를 출시하는 데 들어간 돈이고요. 미터기도, 지출 상한도 이 둘을 구분하지 못해요. 낭비를 잡으려고 상한을 걸면 출시에 쓰일 돈까지 같이 깎이는 이유가 여기 있어요.

머지된 PR당 비용은 재작업·결함 비율과 한 세트

HPE가 대안으로 제안한 지표는 ‘머지된 PR당 비용(cost per merged pull request)’이에요. 계산식은 간단해요.

머지된 PR당 비용 = AI 보조 개발에 들어간 총비용 ÷ 리뷰를 통과해 머지된 변경 수

이 숫자만 따로 보면 착시가 생겨요. 재작업과 결함을 꼭 같이 봐야 해요. PR당 비용이 내려갔는데 머지 후 되돌리거나 다시 고치는 일이 늘었다면, 비용이 줄어든 게 아니라 떨어진 품질이 숫자 뒤에 가려진 것일 수 있어요. 판단 기준은 이래요. AI 사용량이 늘어도 품질이 유지되면서 머지된 PR당 비용이 내려간다면, 팀이 쓴 토큰을 쓸모 있는 소프트웨어로 잘 바꾸고 있다는 뜻이에요. 토큰을 몇 개 썼느냐보다 투자한 돈으로 완성된 작업이 얼마나 나왔느냐. 봐야 할 건 그쪽이에요.

두 번째 지표는 활성 개발자당 비용이에요. 전체 라이선스 수로 나눈 평균은 지출을 끌어올리는 파워 유저를 가려버리거든요. HPE가 공개한 자사 데이터를 보면 상위 5% 사용자가 사용량 대부분을 차지했어요. 같은 라이선스를 쓰는데도 가장 많이 쓰는 사람은 가장 적게 쓰는 사람의 약 450배를 썼고요. 이 정도 격차면 ‘1인당 평균’은 거의 아무것도 설명하지 못해요. HPE는 파워 유저가 소수에서 전체 인력의 절반으로 늘면 인원이 그대로여도 월 지출이 약 4.4배로 오를 수 있다는 계산도 내놨어요. 지출을 좌우하는 건 라이선스 수가 아니라 사용 패턴이라는 얘기예요. 다만 사용자 구성은 조직마다 다르니 이 배수를 그대로 빌려 쓰긴 어렵고, 결국 직접 재보는 수밖에 없어요.

분모인 머지된 PR 수는 깃허브에서 이렇게 뽑을 수 있어요. 메뉴 이름은 서비스 업데이트나 요금제에 따라 조금씩 다를 수 있으니 참고용으로 보세요.

• 저장소 → Pull requests 탭 → 검색창에 is:pr is:merged 입력 → merged: 조건으로 기간 지정
• 저장소 → Insights → Pulse → 기간 선택 → 그 기간에 머지된 PR 수 확인
• 코파일럿 사용량: 조직 Settings → Billing and licensing(예전 표기 Billing and plans) → Usage (이 단계의 메뉴 이름은 불확실)

분자인 총비용에는 API 요금과 구독료만 넣으면 안 돼요. 자체 인프라를 쓴다면 전력, 운영, 유지보수, 감가상각까지 모두 더한 ‘완전 부담 비용’으로 계산해야 공정하게 비교할 수 있어요. 이걸 빼고 계산하면 자체 인프라 쪽이 실제보다 싸 보일 수밖에 없고요.

설계는 프런티어 모델, 반복 작업은 오픈웨이트 모델로

에이전트 코딩의 모든 단계에 가장 강력한 모델이 필요한 건 아니에요. 비용을 줄이는 첫 번째 방법은 비싼 추론을 꼭 필요한 순간에만 쓰는 것. 작업 성격에 따라 나누면 대략 이래요.

• 프런티어 모델(정책상 필요하면 온프레미스 플래그십 모델): 어려운 설계와 계획, 처음 보는 문제에 대한 추론
• 직접 운영하는 오픈웨이트 모델: 코드 생성, 테스트 작성, 반복적인 리팩터링

이 분배를 사람이 매번 할 수는 없으니 중간에 게이트웨이를 둬요. 게이트웨이는 요청마다 작업 복잡도, 데이터 민감도, 비용, 지연 시간을 보고 어느 모델로 보낼지 정해요. 워크플로 전체에 비싼 요금을 매기지 않고, 정말 필요한 순간에만 비싼 추론을 쓰는 구조예요. HPE는 이를 ‘작업량 전체가 아니라 예외에만 미터기를 달라’고 표현해요. 뒤집어 말하면, 에이전트 호출 가운데 반복 작업 비중이 큰 팀일수록 이 방식으로 아낄 여지도 커진다는 뜻이에요.

오픈웨이트 모델이 이 역할을 맡을 수 있게 된 건 성능이 올라온 덕분이에요. 소프트웨어 엔지니어링 벤치마크에서 선두권 오픈웨이트 모델이 일부 작업에서는 프런티어 모델에 가까운 결과를 내고 있어요. 여기서 흘려들으면 안 되는 단서가 바로 ‘일부 작업’. 벤치마크 점수가 모든 저장소와 워크플로에서 같은 성능을 보장하진 않아요. 실제 업무를 맡기기 전에 후보 모델을 팀 코드로 직접 시험해봐야 하는 건 그래서예요. 점검은 이 정도로 시작하면 돼요.

• 우리 저장소에서 실제로 처리했던 이슈를 골라 같은 과제를 맡겨보기
• 기존 테스트 스위트를 통과하는지 확인하기
• 팀의 코드 리뷰 기준과 수용 기준을 그대로 적용해 머지할 만한 수준인지 보기

API는 쓸수록 비싸지고, 보유 인프라는 쓸수록 싸진다

두 번째 방법은 반복 작업의 단가 자체를 낮추는 거예요. 갈림길은 추론 용량을 누가 소유하느냐. 빌려 쓰는 추론은 호출할 때마다 청구액이 늘어요. 직접 보유한 용량은 비용 대부분을 먼저 들이기 때문에 쓰면 쓸수록 호출 한 번당 비용이 내려가고요. 종량제는 많이 쓸수록 비싸지고, 보유 용량은 많이 쓸수록 효율이 좋아지는 정반대의 곡선이에요.

물론 소유한다고 공짜가 되는 건 아니에요. 전력, 운영 인력, 유지보수, 감가상각을 전부 따져야 하고, 비교 기준도 이 모든 비용을 더한 머지된 PR당 비용이어야 해요. 사용량이 적거나 들쭉날쭉하면 API가 유리해요. 놀고 있는 설비에 자본을 묶어둘 필요가 없으니까요. 소유는 수요가 꾸준해서 설비가 계속 바쁘게 돌아갈 때 제값을 해요. 손익을 가르는 건 결국 설비가 얼마나 쉬지 않고 도느냐, 다시 말해 팀 수요가 얼마나 꾸준하냐예요.

구분	종량제 API(임대)	자체 보유 인프라	하이브리드
비용 구조	호출할 때마다 청구액 증가	비용 대부분을 먼저 투입, 많이 쓸수록 호출당 비용 하락	반복 물량은 보유 용량에서 처리, 예외만 API로 과금
유리한 사용 패턴	사용량이 적거나 예측하기 어려울 때	수요가 꾸준해 설비가 계속 바쁠 때	까다롭거나 간헐적인 작업과 반복 물량이 섞여 있을 때
따로 따질 비용	사용량에 비례해 늘어나는 변동비	전력, 운영, 유지보수, 감가상각	양쪽 비용 모두
코드 통제	프롬프트에 담긴 코드가 외부 모델로 전달	코드 생성과 테스트를 사내에서 처리	승인된 계획 프롬프트와 관리되는 예외만 게이트웨이를 거쳐 외부로 전송
주로 맡길 작업	어려운 계획, 새로운 추론	코드 생성, 테스트 작성, 반복 리팩터링	게이트웨이가 복잡도, 민감도, 비용, 지연 시간을 보고 분배

청구서에 안 찍히는 가치도 있어요. 코드 생성과 테스트를 사내에서 돌리면 회사 코드가 밖으로 나가지 않거든요. 외부 모델로 나가는 건 승인된 계획 프롬프트와 관리되는 예외뿐이에요. 그것도 조직이 통제하는 게이트웨이를 거쳐서요. HPE는 보안 문제로 AI 도입이 멈춰 있던 민감한 저장소를 열 수 있다는 점을 장점으로 꼽아요.

HPE는 자사 사례로 하이브리드 플랫폼을 소개했어요. 150개가 넘는 내부 애플리케이션의 일상 워크로드를 HPE Private Cloud AI 같은 온프레미스 환경의 오픈웨이트 모델로 보내서 토큰 비용을 30~50% 줄였다고 해요. 숫자만 보면 솔깃한데, 걸리는 대목이 두 개 있어요. 이 수치가 전력과 감가상각까지 반영한 완전 부담 비용 기준인지 공개되지 않았다는 점. 그리고 인프라를 파는 회사가 직접 낸 사례라는 점. HPE가 스스로 제시한 ‘완전 부담 비용’ 잣대를 HPE의 숫자에도 똑같이 대봐야 하는 이유예요.

국내 팀 예산표에서 바뀌는 것: 좌석, 환율, 보안

좌석 수에 단가를 곱해 연간 예산을 잡던 방식은 점점 안 맞게 될 가능성이 커요. 국내 개발자도 많이 쓰는 깃허브 코파일럿이 정액제에서 크레딧 차감 방식으로 바뀌었고, 에이전트 기능을 쓸수록 사람마다 사용량 차이가 벌어지거든요. 인원이 같아도 파워 유저가 늘면 지출이 몇 배로 뛸 수 있다는 HPE 데이터를 보면, 예산을 인원이 아니라 사용 패턴으로 나눠 잡는 편이 현실적이에요.

환율도 국내 팀에게는 무시 못 할 변수예요. 해외 AI 서비스는 보통 달러로 결제하기 때문에 사용량 변동 위에 환율 변동이 한 겹 더 얹혀요. 머지된 PR당 비용을 원화로 환산해 매달 기록하면 사용량 때문에 늘어난 비용과 환율 때문에 늘어난 비용을 나눠 보기 쉬워요. 달러 기준 값을 옆 칸에 같이 적어두면 둘을 가르기가 한결 수월하고요.

보안 쪽은 변화가 더 클 수도 있어요. 금융권이나 공공기관처럼 소스 코드를 외부로 보내려면 보안 심사가 까다로운 조직은 코딩 에이전트 도입 자체가 막히는 경우가 많아요. 코드 생성과 테스트는 사내 오픈웨이트 모델이 맡고 승인된 계획 프롬프트만 게이트웨이로 내보내는 구성이라면 도입 논의를 시작할 여지가 생길 수 있어요. 다만 이건 구조를 보고 한 추측이에요. 각 조직의 보안 규정을 실제로 통과할지는 별개 문제고요. 반대로 사용량이 아직 적거나 프로젝트마다 들쭉날쭉한 스타트업이라면 인프라부터 살 이유가 약해요. API를 그대로 쓰면서 두 지표부터 쌓는 게 먼저예요.

확인된 것과 아직 불확실한 것

확인된 것

• 코딩 에이전트 작업 하나가 일반 채팅 프롬프트보다 10~50배 많은 토큰을 쓸 수 있다는 점
• 깃허브 코파일럿의 정액 요금제에서 크레딧 종량제로의 전환
• HPE가 밝힌 하이브리드 사례: 150개 이상 내부 앱의 일상 워크로드를 온프레미스 오픈웨이트 모델로 라우팅해 토큰 비용 30~50% 감소
• HPE 사내 데이터: 상위 5% 사용자가 사용량 대부분 차지, 최다 사용자와 최소 사용자의 사용량 차이 약 450배
• HPE가 추적을 권하는 두 지표: 활성 개발자당 비용, 머지된 PR당 비용

아직 불확실한 것

• 우버의 AI 예산 규모와 구체적인 사용 내역
• HPE의 30~50% 절감 수치에 전력, 운영, 감가상각이 포함됐는지 여부
• 각 팀 저장소에서 오픈웨이트 모델이 프런티어 모델에 얼마나 가까운 성능을 내는지
• 파워 유저가 늘 때 지출이 약 4.4배로 오른다는 추정이 다른 조직에도 맞는지 여부
• AI 코딩 토큰 비용이 개발자 평균 연봉을 넘어선다는 가트너 전망의 전제 조건

인프라를 바꾸기 전에 기준선부터 재는 4단계

1. 기준선 측정: 지금 구조 그대로 활성 개발자당 비용과 머지된 PR당 비용을 재요. 재작업 비율과 결함 비율도 함께 기록해요.
2. 작업 분류: 에이전트 호출을 ‘어려운 계획과 새로운 추론’, ‘코드 생성·테스트 작성·반복 리팩터링’으로 나눠요. 그다음 반복 작업이 얼마나 되는지 확인해요.
3. 후보 모델 평가: 반복 작업을 맡길 오픈웨이트 모델을 팀의 코드, 테스트, 수용 기준으로 검증해요.
4. 전체 사이클 시험: 개발 사이클 하나를 통째로 보유 용량(또는 하이브리드 구성)에서 돌려봐요. 사용량이 늘 때 두 지표가 모두 나아지는지 확인하고, 그렇지 않으면 지금 방식을 유지하는 편이 나을 수 있어요.

개발자가 코딩 에이전트에 기대는 정도는 앞으로 더 커질 가능성이 높아요. 늘어난 사용량이 더 큰 청구서로 끝날지, 더 많이 출시된 소프트웨어로 이어질지는 무엇을 재느냐에 달렸어요. HPE의 권고는 사용량을 제한하지 말고, 많이 쓸수록 비용 효율이 좋아지는 운영 방식을 만들라는 것. 다만 자체 인프라를 파는 회사의 주장이니 결론은 팀의 지표로 직접 확인하는 게 맞아요. 4단계 중 첫 단계는 인프라를 건드리지 않고 지금 당장 시작할 수 있어요. 토큰 대신 머지된 PR을 세기 시작하면 어디서 돈이 새고 어디서 성과가 나는지가 훨씬 잘 보일 거예요.

출처: MIT Tech Review AI