“우리 팀도 Coding Agent를 씁니다.” 이제 이 말은 자랑이 아닙니다. 다음 질문이 바로 오기 때문입니다.

“그래서 $1의 Agent 비용으로 production에 보낸 task가 몇 개인가요?”

GitLab이 Duo Agent Platform Impact Analytics를 early access로 내놓은 배경이 여기 있습니다. 단순 사용 횟수가 아니라 팀·태스크·모델별 credit 소비를 실제 production 결과와 연결하려는 시도입니다. 같은 맥락에서 GitLab은 최근 3개월 agentic 개발 active user가 전년 대비 200% 늘었다고 밝혔습니다. 쓰는 팀이 늘면, 다음은 “잘 쓰고 있나”를 재는 도구가 필요합니다.

토큰 KPI가 놓치는 것

지금 많은 팀의 Agent 지표는 이 셋 중 하나에 머뭅니다.

사용량 지표: 호출 수, 활성 사용자 수, 채택률
토큰 지표: 입력·출력 토큰, credit 소모
점수 지표: 벤치마크 pass@1, 리더보드 순위

문제는 이 숫자들이 “일이 끝났는가”를 말해주지 않는다는 것입니다. 토큰을 많이 썼다는 건 일을 많이 시켰다는 뜻이지, 일을 끝냈다는 뜻이 아닙니다. 점수가 높다는 건 시험을 잘 본다는 뜻이지, 우리 repo에서 되돌려지지 않았다는 뜻이 아닙니다.

빠진 고리가 둘 있습니다.

  • 되돌림(revert): 머지됐다가 되돌려진 변경은 사용량에는 잡히지만 결과에는 마이너스입니다.
  • 사람 손: Agent가 1달러 쓰고 사람이 2시간 고쳤다면, 진짜 비용은 1달러가 아닙니다.

그래서 KPI를 토큰에서 결과로 옮겨야 한다는 말이 나옵니다.

Impact Analytics가 하려는 일

GitLab Docs와 릴리스 발표를 기준으로 Impact Analytics(Impact dashboard) 계열의 방향을 정리하면 이렇습니다.

왼쪽: 비용 (team·task·model별 credit 소비, GitLab Credits 사용량 가시성)
   +
오른쪽: 결과 (Duo가 만든 MR의 상태, 머지·배포·DORA 지표, 사이클 타임)
   =
질문: "어디에 쓴 돈이 production으로 연결됐나?"

19.4에서 함께 간 “GitLab Credits 사용량 가시성 GA”가 왼쪽(비용)을 맡고, Impact 계열 대시보드가 오른쪽(결과)을 붙이는 구조입니다. Data Analyst Agent처럼 자연어로 “우리 팀 MR이 리뷰에 얼마나 머무나”를 묻는 표면도 같은 흐름에 있습니다. 관점이 “AI를 얼마나 썼나”에서 “쓴 만큼 배송이 빨라졌나”로 이동한 것입니다.

Forrester TEI 쪽 숫자도 같은 언어로 읽힙니다. Duo Agent Platform 도입 시 400% ROI, 3년 NPV 750만 달러, 6개월 이내 회수, 신규 온보딩 80% 단축, 마이그레이션 8개월→2개월, QA·보안 수정 40% 절감, 개발자 개인 생산성 20% 향상. 벤더 의뢰 연구라 할인해서 봐야 하지만, 측정 단위가 토큰이 아니라 시간·비용·배송이라는 점이 포인트입니다.

결과 KPI 4종 세트

기업용 대시보드가 없어도 됩니다. 개인 프로젝트에서도 이 네 숫자면 시작할 수 있습니다.

KPI 정의 재는 법
AI cost 기간 내 AI 총비용 API·credit 청구액 + 구독료 안분
Completed tasks production에 살아남은 task 수 머지 후 7일 내 revert 없이 유지된 건
Reverted changes 되돌려진 변경 비율 revert MR 수 ÷ Agent 기인 MR 수
Human correction time 사람이 고친 시간 Agent 결과 리뷰·수정 시간 합 (대략 측정)

여기서 파생되는 대표 지표가 하나 있습니다.

성공 1건당 비용 = AI cost ÷ Completed tasks
진짜 성공 1건당 비용 = (AI cost + 사람 시간 환산) ÷ Completed tasks
되돌림률 = Reverted ÷ Agent 기인 MR

“성공 1건당 비용” 계산의 뼈대는 성공 1건당 비용 글 그대로입니다. 다른 점은 분모가 “성공 판정”에서 “production 생존”으로 엄격해졌다는 것. 테스트를 통과한 것과 배포 후 일주일을 버틴 건 다른 난이도입니다.

모델·태스크별로 쪼개면 더 쓸모가 있습니다. 같은 일 10개를 모델 A/B에 돌리고 위 네 숫자를 비교하면, “어느 모델이 똑똑한가”가 아니라 “어느 모델이 우리 일을 싸게 끝내는가”가 보입니다. 리더보드 읽는 법은 Pass@1·비용·시간 글을 참고하세요.

CodeBridge Mini Lab: 2주 측정 스프린트

기간: 2주, 대상: 본인이 Agent에게 시킨 일 전부

매 task마다 한 줄 기록:
- 날짜 / task / 모델 / AI 비용 / 성공(Y/N, 기준: 머지+7일 생존)
- 되돌림 여부 / 사람 수정 시간(분) / 실패 유형

2주 후 집계:
- AI cost 총액: __원
- Completed: __건 → 성공 1건당 __원
- 되돌림률: __%
- 사람 수정 시간 총합: __시간 → 시간당 환산 __원 포함 시 진짜 1건당 __원

판정:
- 되돌림률이 20%를 넘으면 모델이 아니라 workflow 문제 (리뷰·테스트·권한부터 손보기)
- 사람 수정 시간이 AI 비용을 압도하면 "싼 모델"이 비싼 선택
- 성공 1건당 비용이 낮은 조합을 다음 2주의 기본값으로 고정

이 기록 자체가 포트폴리오가 됩니다. “AI를 써봤다”가 아니라 “AI cost, completed task, reverted changes, human correction time 네 숫자를 재고 workflow를 바꿨다”는 engineering story는 채용이나 협업 자리에서도 통합니다.

결론: 측정이 workflow를 바꾼다

마지막 줄은 짧습니다.

토큰을 재면 토큰이 늘고, 결과를 재면 결과가 는다.

개인 프로젝트에서도 네 숫자를 기록해보세요. AI cost, 완료 task, 되돌림, 사람 수정 시간. 대시보드가 없어도 스프레드시트 한 장이면 됩니다. 2주만 재보면 “어떤 일을 Agent에게 시키고, 어떤 일은 사람이 할지”가 보이기 시작합니다. 그 구분이 생기는 순간, AI 활용이 취미에서 엔지니어링으로 바뀝니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

비용 대비 결과를 따지는 일은 결국 “무엇을 자동하고 무엇을 사람이 검토할지”를 정하는 판단 문제입니다. 반복되는 판단을 코드에 연결하고 확신도·정책·사람의 검토를 함께 설계하는 연습이 이 글의 네 숫자 기록법과 바로 이어집니다.