월 5만 달러를 태우는 엔지니어가 낭비인지 아무도 답하지 못한다

월 5만 달러를 태운 그 엔지니어를 어떻게 할 것인가

리플링에서 엔지니어 한 명이 한 달에 토큰으로 5만 달러를 썼다. 회사 전체로는 AI 토큰 지출이 매달 80%씩 불어나 R&D 인건비 예산의 40%를 태울 궤도에 올랐고, 많이 쓴 달에는 6,050억 토큰이 지나갔다. 직원의 10~15%가 전체 지출의 60%를 만들고 있었다(TechCrunch).

여기서 어려운 건 지출을 줄이는 일이 아니다. 5만 달러를 쓴 그 엔지니어를 어떻게 할지 정하는 일이다. 낭비라면 막아야 하고, 그만큼 산출물이 나온다면 오히려 다른 직원들이 그 사람처럼 쓰게 만들어야 한다. 지출 순위표만으로는 두 경우가 구분되지 않는데, 순위표 말고는 아무것도 없는 회사가 대부분이다.

리플링은 이 질문에 답하려고 내부 도구를 만들었고, 그걸 AI Spend Console 이라는 제품으로 내놨다(Rippling). 직원·팀·직무 단위 지출에 GitHub와 Salesforce 같은 업무 시스템의 신호를 물린다. 풀리퀘스트 수, 코드 벨로시티, 코드리뷰에서 재작업을 요구받는 빈도, 기여한 매출까지다(Business Wire). 결과가 흥미롭다. 통제 후 리플링의 7월 토큰 사용량은 6,000억 개로 피크와 비슷했는데 비용은 4월의 37%였다. 사용을 줄인 게 아니라 낭비만 걷어냈다는 뜻이다.

한 회사가 자기 고통 때문에 만든 도구가 곧 카테고리의 존재 증명이다. 다만 리플링의 제품은 자사 HR 스위트에 묶여 있고, 지출 통제 쪽에 무게가 실려 있다. 귀속 측정 자체를 파는 중립 계층의 자리는 비어 있다.

정액제에서는 이 질문이 성립하지도 않았다

작년까지는 이 측정이 애초에 불가능했다. 좌석당 정액제에서는 전 직원의 AI 비용이 같았으니 개인별로 볼 이유가 없었다. 사용량 과금으로 넘어오면서 같은 직무 안에서도 개인 간 지출이 수십 배씩 벌어졌고, 그제서야 “이 차이가 산출물 차이로 이어지는가”라는 질문이 성립하게 됐다.

첫 번째 대응 물결은 이미 지나갔다. 예산 상한, 저가 모델 라우팅, 팀별 한도 같은 지출 통제는 도구가 나와 있고 도입도 됐다. 통제가 끝나면 바로 다음 질문이 온다. 남긴 지출 중 어느 것을 보호하고 어느 것을 더 키울 것인가. 리플링의 순서가 정확히 그랬다. 먼저 막았고, 그다음 측정 도구를 만들었다.

산출물 데이터가 붙일 수 있는 형태로 쌓여 있다는 조건도 이제 갖춰졌다. 엔지니어링 조직은 풀리퀘스트, 사이클 타임, 리뷰 재작업률이 전부 API로 나오고, 영업 조직은 CRM에 파이프라인이 남는다. 지출 로그와 산출물 로그가 각각 존재하는데 둘을 잇는 조인 하나가 빠져 있는 상태. 빠진 조인은 제품이 된다.

지출 로그와 산출물 로그를 잇는 조인 하나

flowchart LR
  A[게이트웨이·SSO<br/>사용 로그] --> C[귀속 엔진]
  B[GitHub·Jira·CRM<br/>산출물 신호] --> C
  C --> D[팀·코호트 ROI 뷰]
  D --> E[더 태울 곳과 줄일 곳]
  E --> F[상위 사용자 패턴의<br/>사내 전파]

수집 계층은 새로 깔 필요가 없다. 대부분의 회사가 이미 LLM 게이트웨이나 프록시로 호출을 모으고 있으니, 그 로그에서 신원·모델·토큰을 받고 GitHub·Jira·CRM 은 기존 API 로 붙인다. 어려운 건 배관이 아니라 비교 설계다. 같은 직무, 비슷한 연차의 코호트를 잡아 AI 사용 강도에 따라 산출물이 어떻게 다른지 보여주는 것. 개인 순위표부터 내놓으면 감시 도구로 읽혀서 현장이 데이터를 오염시키기 시작한다. 팀과 코호트 단위가 기본값이고, 개인 드릴다운은 권한 뒤에 둔다.

두 번째 층이 이 제품의 진짜 차별점이다. 산출물 대비 지출이 좋은 상위 사용자들이 어떤 모델을 어떤 작업에 쓰는지 패턴을 뽑아, 나머지 조직에 전파할 플레이북으로 바꿔 준다. 여기까지 가면 구매자가 바뀐다. 비용 절감은 CFO의 관심사지만, 누구를 어떻게 일하게 할지는 CTO와 피플 조직의 관심사다. FinOps 도구와 피플 애널리틱스 사이의 빈 칸이 이 제품의 포지션이고, 특정 HRIS 에 묶이지 않은 중립성이 리플링 대비 방어선이 된다.

상관을 인과처럼 팔면 첫 데이터 리뷰에서 무너진다

가장 위험한 가정은 지출과 산출물의 상관을 인과처럼 팔 수 있다는 착각이다. 원래 잘하는 엔지니어가 AI 도 많이 쓰는 것뿐이라면, 이 도구의 추천은 첫 데이터 리뷰에서 무너진다. 코호트 설계를 보수적으로 잡고, 단정 대신 “이 팀의 이 구간에서 이런 차이가 관찰된다”까지만 말하는 절제가 제품 신뢰의 전부다.

두 번째는 굿하트의 법칙이다. 풀리퀘스트 수가 평가에 들어가는 순간 풀리퀘스트가 잘게 쪼개진다. 재작업률, 사이클 타임, 인시던트율처럼 게임하기 어려운 지표를 섞고, 지표 구성을 주기적으로 바꿔야 한다. 마지막은 확장 순서다. 산출물이 측정되는 엔지니어링에서 시작해야 하고, 측정이 흐릿한 직군으로 서둘러 넓히면 숫자의 신뢰가 전체에서 무너진다. 리플링의 40%라는 숫자가 한 회사의 사고였는지 내년 모두의 기본값이 될지, 그 답이 이 시장의 크기를 정한다.