AI 코딩 지표AI Coding Metrics
📅
들어가기 전에 🔗
지침 파일을 줄이고 가벼운 모델로 바꿨더니 토큰 사용량이 내려갔습니다.
그런데 PR을 검토할 때 누락된 예외 처리가 더 자주 발견되고, 사람이 직접 고치는 시간은 늘었습니다.
이때 토큰 그래프만 보면 개선으로 보이지만, 실제 개발 작업은 더 오래 걸릴 수 있습니다.
시리즈 앞부분에서는 컨텍스트, 작업 요청, 모델 선택, 코드 검증을 다뤘습니다.
마지막으로 필요한 것은
바뀐 작업 방식이 완료율·시간·비용을 어떻게 바꿨는지 확인하는 기록
입니다.
이번 글에서는 큰 대시보드 없이도 시작할 수 있는 작업 단위 지표와 비교 방법을 정리합니다.측정 단위 🔗
대화 한 번이나 커밋 한 개보다, 완료 조건이 있는 작업 하나를 기준으로 기록합니다.
“검색 필터의 뒤로 가기 복원 오류 수정”은 하나의 작업입니다.
그 안에서 재요청을 세 번 하고 모델을 바꿔도 같은 작업으로 묶습니다.
호출마다 성공 여부를 따로 세면, 여러 번 실패한 뒤 한 번 해결한 작업의 실제 비용이 흐려집니다.
먼저 시작과 끝을 정합니다.
이 글의 예시에서는 AI에게 작업을 요청한 시점에 시작하고, 합의한 검증과 리뷰를 통과한 시점에 완료합니다.
시도했지만 끝내지 못한 작업은 실패 또는 중단으로 남깁니다.
배포까지 포함하는 팀이라면 배포 확인을 종료 조건으로 추가하되, 비교하는 설정에 동일하게 적용합니다.
👨💻
작업 번호와 완료 조건부터 기록해 보시기 바랍니다.
“검색 개선”보다 “URL과 입력값이 뒤로 가기 뒤 함께 복원”처럼 결과를 확인할 수 있는 이름이 좋습니다.
한 작업을 여러 세션에서 진행했다면 같은 작업 번호로 연결합니다.
핵심 지표 🔗
처음에는 네 가지를 함께 보면 충분합니다.
어느 하나를 최적화하기 전에, 다른 지표가 악화되지 않았는지 확인합니다.
| 지표 | 계산·기록 기준 | 주의할 점 |
|---|---|---|
| 완료율 | 완료 작업 수 ÷ 평가가 끝난 전체 작업 수 | 실패·중단도 분모에 포함 |
| 재작업 시간 | 사람의 수동 수정·재요청 준비 시간 | 기본 리뷰 시간과 구분 |
| 총 소요 시간 | 최초 요청부터 검증·리뷰 완료까지 | AI 실행과 대기 원인을 구분 |
| 총 사용량·비용 | 같은 작업의 재시도·모델 승격을 포함 | API 요금과 구독 한도를 구분 |
아직 진행 중인 작업은 최종 완료율의 분모에 섞지 않고 별도 집계합니다.
운영 데이터의 평가 종료 시점도 정해 두어야 늦게 끝난 작업 때문에 지난주 숫자가 계속 달라지는 일을 줄일 수 있습니다.
AI 코딩의 완료율, 사람 재작업, 총 소요 시간, 총 사용량을 함께 보는 지표 인포그래픽
OpenAI 공식 문서도 대표 작업에서 성공 여부·지연 시간·토큰 사용량·성공한 작업당 비용을 함께 비교하도록 안내합니다.
OpenAI 배포 체크리스트↗
재작업 구분 🔗
정상적인 리뷰와 AI 결과를 고치기 위한 재작업은 구분합니다.
코드를 읽고 검토하는 10분과, 누락된 조건을 설명하고 다시 요청하는 20분은 다른 비용입니다.
수동 수정 시간과 재요청을 준비한 시간을 기록하면 어떤 부담이 늘었는지 알 수 있습니다.
검증 과정에서 AI가 스스로 수정한 반복은 사람의 재작업 시간에 포함하지 않습니다.
그 비용은 총 소요 시간과 사용량에 반영합니다.
사람이 개입한 수정이 있었는지를 따로 표시하면, 최종 완료율이 높아도 사람의 도움이 많이 필요했던 작업을 구분할 수 있습니다.
작업 기록 🔗
처음에는 작업별 메모나 CSV 한 줄이면 됩니다.
필요한 필드는 실제 의사결정에 쓰이는 것부터 추가합니다.
다음은 별도 API나 제품 로그 형식이 아닌, 팀에서 사용할 수 있는 TypeScript 기록 예시입니다.
type TaskRecord = {
taskId: string;
taskType: "small-edit" | "feature" | "debug";
startCommit: string;
requestVersion: string;
modelPath: string[];
outcome: "accepted" | "failed" | "blocked";
elapsedSeconds: number;
humanReviewMinutes: number;
humanReworkMinutes: number;
extraRequests: number;
apiCostUsd: number | null;
};modelPath에는 실제로 사용한 모델과 추론 설정을 실행 순서대로 남깁니다.
extraRequests는 최초 요청 뒤 사람이 추가로 보낸 수정 요청 수로 정의합니다.
도구 호출이나 테스트 실행을 이 값에 섞지 않습니다.
apiCostUsd를 알 수 없는 구독 환경에서는 null을 사용하고, 확인되지 않은 비용을 0달러로 채우지 않습니다.검증 명령과 실패 근거는 7편의 완료 보고 형식으로 별도 보관하고, 작업 번호로 연결합니다.
집계표에는 짧은 실패 원인을 남기면 됩니다.
“진입점 정보 누락”, “응답 스키마 오해”, “테스트 환경 미준비”처럼 구체적으로 기록하면 다음 개선을 선택하기 쉽습니다.
사용량 수집 🔗
현재 Claude Code 공식 문서는
/usage의 Session 영역에서 세션 토큰 사용량과 추정 비용을 확인하도록 안내합니다.
구독 사용자는 같은 화면의 사용 한도를 확인하며, API 단가로 계산된 세션 추정 비용을 구독 청구액으로 해석하지 않습니다.
실제 API 청구 확인에는 Claude Console의 사용량 자료를 사용합니다.
Claude Code 비용 관리↗하나의 세션에서 여러 작업을 처리했다면 세션 전체 사용량을 각 작업에 그대로 복사하지 않습니다.
작업 경계별 차이를 계산할 수 있는지 확인하고, 구분할 수 없다면 세션 단위 집계라는 한계를 남깁니다.
누적 통계를 매 요청마다 더하면 같은 토큰을 반복해서 셀 수 있으므로 수집 값이 누적값인지 개별 호출값인지도 확인합니다.
👍
입력·출력·캐시·추론 토큰의 관계는 제공자가 반환하는 사용량 구조에 따라 다릅니다.
세부 필드가 합계에 이미 포함돼 있다면 다시 더하지 않습니다.
토큰 총수만으로 가격을 계산하지 말고 적용되는 모델·캐시·처리 요금을 함께 확인합니다.
완료당 비용 🔗
6편에서는 한 작업이 모델 승격을 거칠 때의 비용을 봤습니다.
여러 작업을 비교할 때는 실패한 시도에 쓴 비용까지 합쳐서 완료한 작업 수로 나눕니다.
그래야 끝내지 못한 작업을 제외해 저렴한 설정처럼 보이게 만드는 오류를 피할 수 있습니다.
function summarize(tasks: TaskRecord[]) {
const accepted = tasks.filter((task) => task.outcome === "accepted");
const costsKnown = tasks.every((task) => task.apiCostUsd !== null);
const totalCost = costsKnown
? tasks.reduce((sum, task) => sum + task.apiCostUsd!, 0)
: null;
return {
evaluated: tasks.length,
accepted: accepted.length,
completionRate: tasks.length ? accepted.length / tasks.length : null,
humanReworkMinutes: tasks.reduce(
(sum, task) => sum + task.humanReworkMinutes, 0,
),
costPerAcceptedTask:
accepted.length && totalCost !== null
? totalCost / accepted.length
: null,
};
}이 예시는 평가가 끝난 작업만 입력받는다고 가정합니다.
작업별 비용은 재시도·승격을 포함하고, 한 건이라도 비용을 모르면 완료당 비용도 미확인으로 처리합니다.
완료한 작업이 0개일 때도 비용을 0으로 표시하지 않습니다.
호출 수가 많은 작업이 두 번 집계되지 않도록
taskId별로 한 레코드를 만들어 전달합니다.비교 예시 🔗
다음은 실제 측정이나 모델 성능 자료가 아닌 계산용 가상 데이터입니다.
설정 A와 B에 같은 작업 10개를 실행했다고 가정합니다.
| 항목 | 설정 A | 설정 B |
|---|---|---|
| 완료한 작업 | 9개 | 7개 |
| 실패·중단한 작업 | 1개 | 3개 |
| 완료율 | 90% | 70% |
| 전체 API 비용 | 12달러 | 10달러 |
| 완료당 API 비용 | 약 1.33달러 | 약 1.43달러 |
| 사람의 재작업 시간 | 45분 | 80분 |
B는 전체 API 비용이 낮지만, 완료당 비용과 사람의 재작업 시간은 높습니다.
사람 시간과 API 비용을 별도 항목으로 보면 이 차이가 드러납니다.
팀 내부 인건비 기준이 없다면 임의의 시간당 단가로 둘을 하나의 금액으로 합칠 필요는 없습니다.
비교 조건 🔗
다른 작업으로 얻은 숫자만 비교하면 설정 효과와 난이도 차이가 섞입니다.
같은 시작 코드, 같은 요청, 같은 검증 기준, 같은 실행 환경을 준비하고 변수 하나씩 바꿉니다.
기존 수정이 반영된 코드에서 두 번째 설정을 실행하면 첫 번째 설정의 결과를 물려받는 비교가 됩니다.
같은 시작 코드·요청·검증·실행 환경을 고정하고 변수 하나를 바꿔 완료율, 재작업, 시간과 비용을 비교하는 기준
예를 들어
AGENTS.md를 줄이는 효과를 보려면 모델과 추론 수준은 그대로 둡니다.
모델 라우팅을 비교하려면 지침과 작업 요청을 고정합니다.
작업 요청·모델·검증 방법을 한꺼번에 바꾸면 어떤 변화가 결과에 영향을 줬는지 판단하기 어렵습니다.OpenAI의 Skill 평가 글도 성공 기준을 먼저 정의하고, 실행 결과와 검사 기준으로 개선과 퇴행을 확인하는 방식을 설명합니다.
OpenAI의 Skill 평가 방법↗
작업별 집계 🔗
단순 수정, 일반 기능 구현, 복잡한 디버깅은 따로 봅니다.
쉬운 작업이 많이 포함된 주의 전체 완료율을 어려운 작업이 많았던 주와 비교해서 모델이 좋아졌다고 결론 내리지 않습니다.
작업 유형별 건수와 완료율을 함께 표시합니다.
시간은 평균만 보지 말고 완료한 작업의 중앙값과 오래 걸린 사례도 확인합니다.
중앙값은 정렬한 값의 가운데에 있어 일부 긴 작업의 영향을 평균보다 덜 받습니다.
다만 완료 작업만의 시간이므로 실패·중단 건수와 그동안 사용한 시간은 별도로 남겨야 합니다.
🖐️
완료율을 높이려고 어려운 작업을 기록에서 빼거나 검증 조건을 약하게 바꾸지 마십시오.
비교의 입력과 성공 기준이 바뀌면 같은 지표 이름을 써도 이전 결과와 직접 비교할 수 없습니다.
개선 순서 🔗
지표는 수집보다 다음 행동을 고르는 데 쓰여야 합니다.
숫자가 나빠진 작업의 기록과 실패 원인을 확인한 뒤 한 가지 개선을 선택합니다.
| 관찰 | 먼저 확인할 것 | 적용할 개선 |
|---|---|---|
| 입력 사용량 증가 | 반복해서 읽는 지침·문서·도구 결과 | 진입점 안내, 조건부 참조, 응답 범위 제한 |
| 완료율 감소 | 실패 재현과 완료 조건 누락 | 요청 구체화, 검증 수단 제공 |
| 사람 재작업 증가 | 요구사항·인터페이스 오해 | 입출력 예시와 변경 경계 명시 |
| 대기 시간 증가 | 테스트·도구·환경의 병목 | 관련 검사 우선, 실행 환경 정비 |
| 승격과 재시도 증가 | 초기 모델 선택과 정보 부족 | 작업별 모델 기준·인계 요약 조정 |
사용량이 늘었어도 재작업이 줄고 완료율이 높아졌다면 받아들일 수 있는 변화일 수 있습니다.
반대로 비용 감소와 함께 검증 누락이 늘었다면 그 설정을 유지할 이유가 약해집니다.
원인은 숫자만으로 단정하지 말고 개별 작업의 근거를 확인합니다.
시작 방법 🔗
반복되는 작업 유형 하나를 골라 현재 설정의 기준값을 기록합니다.
지침 길이, 모델, 추론 강도 중 한 변수만 바꾸고 같은 사례로 비교합니다.
적은 표본의 결과는 방향을 보는 자료로 사용하고, 새 작업에서도 같은 경향이 유지되는지 확인한 뒤 기본 설정에 반영합니다.
👨💻
한 주에 개선 하나를 선택해 보시기 바랍니다.
“토큰 절약”처럼 넓은 목표 대신 “같은 검색 기능 작업에서 완료율을 유지하며 반복 문서 읽기를 줄인다”처럼 관찰할 수 있는 목표를 잡습니다.
결론 🔗
AI 코딩 지표는 작업을 얼마나 빨리 생성했는지보다, 검증과 리뷰를 거쳐 얼마나 끝냈는지 보여 줘야 합니다.
작업별 완료 조건을 정하고 실패·중단·재시도까지 기록하면 사용량 감소가 실제 효율 개선으로 이어졌는지 판단할 수 있습니다.
이 시리즈에서 다룬 컨텍스트 정리, 최소 지침, 저장소 안내, 작업 요청, Skill·MCP 로딩, 모델 라우팅, 코드 검증을 한꺼번에 바꿀 필요는 없습니다.
기준값 기록 → 변수 하나 변경 → 같은 조건 비교 → 작업별 원인 확인
의 순서로 팀에 맞는 방식을 만들어 보시기 바랍니다.