3장. 공장의 성과를 측정하는 법

다음은 여러 현장에서 반복된 패턴을 합친 합성 사례로, 등장하는 숫자는 설명을 위한 예시 수치다.

한 팀은 에이전트 도입 뒤 PR 생성 시간이 평균 90분에서 12분으로 줄었다고 발표했다. 석 달 뒤 개발자는 더 바빠졌다. 리뷰 요청은 밤에도 쌓였고, 생성된 테스트를 이해하는 데 시간이 들었으며, 배포 후 긴급 수정이 늘었다. 12분은 거짓이 아니었다. 다만 전체 시스템에서 가장 편리한 한 구간만 잰 숫자였다.

이번 장의 약속

처리량·품질·사람의 주의·비용을 균형 있게 측정한다.
실행, 작업, 변경, 배포의 단위를 섞지 않는다.
도입 전후 비교를 작은 실험으로 설계한다.
지표가 목표를 왜곡하는 신호를 찾는다.

측정 단위를 먼저 고정한다

에이전트 한 번 실행, 작업 하나, PR 하나, 배포 하나는 같은 단위가 아니다. 한 작업이 세 번 재시도되어 하나의 PR이 될 수 있고, 다섯 PR이 한 배포로 묶일 수 있다. 분모를 섞으면 성공률과 비용이 왜곡된다.

이 책의 기본 식별자는 다음과 같다.


requestId  사용자 또는 제품의 요구
taskId     검증 가능한 작업 단위
runId      에이전트의 한 번의 실행
changeId   리뷰·통합할 변경 묶음
deployId   운영에 전달된 배포

모든 이벤트는 최소한 taskId와 runId를 가진다. 변경이 만들어지면 changeId, 운영 결과를 연결할 수 있으면 deployId를 추가한다. 이 연결이 있어야 “어떤 유형의 작업이 재시도를 많이 만들고 운영 결함으로 이어졌는가?”를 물을 수 있다.

네 축의 계기판

1. 흐름

리드 타임은 요청이 준비된 시각부터 검증된 변경이 통합될 때까지 걸린 시간이다. 사이클 타임은 실제 작업 시작부터 통합까지다. 팀 안에서 정의를 고정하고 대기 시간과 활동 시간을 분리한다.

처리량은 일정 기간에 필수 게이트를 통과해 통합된 작업 수다. 시작하거나 생성된 수가 아니다.

진행 중 작업(WIP)은 시작했지만 통합되지 않은 작업 수다. 병렬 에이전트를 늘릴 때 반드시 함께 본다. 처리량이 그대로인데 WIP만 늘면 공장은 빨라진 것이 아니라 대기열을 키운 것이다.

2. 품질

첫 시도 통과율은 재시도 없이 필수 게이트를 모두 통과한 작업의 비율이다.


첫 시도 통과율 = 첫 실행에서 통과한 작업 수 / 완료된 작업 수

재작업률은 리뷰 또는 통합 뒤 요구 변경이 아닌 결함 때문에 다시 수정한 작업의 비율이다.

유출 결함률은 공장 안의 게이트를 통과했지만 배포 후 발견된 결함을 작업 또는 배포 단위로 측정한다. 심각도를 함께 기록하지 않으면 사소한 문구 오류와 데이터 손실이 같은 한 건이 된다.

게이트별 검출률은 어떤 검사가 어떤 결함을 잡았는지 보여 준다. 항상 통과하는 게이트는 안정적인 것이 아니라 쓸모가 없을 수도 있다.

3. 사람의 주의

에이전트의 목적은 단지 타이핑을 줄이는 것이 아니라 사람의 제한된 판단 시간을 더 가치 있는 곳에 쓰게 하는 것이다.

다음 시간을 분리해 기록한다.

작업을 명세하는 시간
실행 중 질문에 응답한 시간
결과를 리뷰한 시간
실패를 진단하고 복구한 시간
공장 자체를 유지한 시간

작업당 사람 개입 시간은 자동화의 실질 효과를 보여 준다. 다만 명세 시간이 늘고 운영 결함이 크게 줄었다면 좋은 교환일 수 있다. 총량과 분포를 함께 본다.

개입 횟수보다 개입 이유가 중요하다. requirement-ambiguity, permission, test-flake, architecture-decision, security-review처럼 분류하면 어디를 개선해야 하는지 보인다.

4. 비용과 자원

모델 사용료만 기록하면 불완전하다. 실행 환경, CI, 저장 공간, 관측 시스템, 사람의 시간, 실패한 배포의 비용을 함께 고려한다. 처음에는 정확한 화폐 환산보다 다음 원시값을 보존하는 편이 낫다.


모델 입력/출력 사용량
도구 호출 수와 실행 시간
CI 분
실패·재시도 횟수
사람 개입 분
실행별 산출물 저장량

가격은 바뀌지만 원시 사용량은 나중에 다시 계산할 수 있다.

가운데 검증 완료 작업을 두고 흐름, 품질, 사람의 주의, 비용과 자원 네 카드가 둘러싸며 각각 리드 타임, 첫 시도 통과율, 작업당 사람 개입 시간, 성공 작업당 자원을 표시한 균형 계기판.

그림 3-1. 처리량 하나를 높이면 다른 축에서 재작업·주의·비용이 늘 수 있다. 네 축의 방어 지표를 함께 본다.

북극성 지표 하나로 줄이지 않는다

한 숫자만 목표로 삼으면 시스템은 그 숫자를 쉽게 만드는 방향으로 변한다. 완료 작업 수를 높이면 작업을 지나치게 잘게 나눌 수 있다. 첫 시도 통과율을 높이면 쉬운 일만 에이전트에 보낼 수 있다. 사람 시간을 줄이면 중요한 리뷰를 생략할 수 있다.

최소 계기판은 다음 다섯 값을 나란히 둔다.

목적	핵심 값	방어 지표
더 빨리 전달	리드 타임 중앙값/상위 90%	WIP, 유출 결함
더 많이 완료	검증 완료 처리량	재작업률
덜 개입	작업당 사람 분	심각 결함, 차단 시간
더 안정적으로 실행	첫 시도 통과율	쉬운 작업 편향
비용 통제	성공 작업당 자원	품질, 사람 시간

평균만 보면 긴 꼬리가 숨는다. 중앙값과 상위 90% 값을 함께 본다. 일부 작업만 며칠씩 멈추는 현상은 상위 구간에서 드러난다.

성공 작업당 비용

실패 실행을 제외한 평균 비용은 낙관적으로 보인다. 분모를 필수 게이트를 통과한 작업으로 둔다.


성공 작업당 자원 비용 = 전체 실행 자원 / 검증 완료 작업 수

예를 들어 A 모델이 실행당 1단위를 쓰고 성공률이 40%이며, B 모델이 1.8단위를 쓰고 성공률이 90%라면 실행 단가만으로 A를 선택할 수 없다. 재시도와 사람의 복구 시간을 포함하면 결론이 달라진다.

실습: 2주짜리 도입 실험 설계

1단계: 업무군을 좁힌다

형태가 비슷하고 자동 판정 가능한 업무 하나를 고른다. 예를 들면 내부 API에 필드 하나 추가, 반복적 마이그레이션, 테스트 보강이다. 신규 기능, 장애 대응, 대규모 리팩터링을 한 실험에 섞지 않는다.

2단계: 기준선 표본을 만든다

기존 방식으로 완료한 비슷한 작업 10~20개의 다음 값을 수집한다.

설계 예(실행용 아님) — 원본: 이 장의 기준선 레코드 설명; 명령: 없음.


{
  "taskType": "api-field",
  "leadMinutes": 510,
  "activeHumanMinutes": 95,
  "reviewRounds": 2,
  "escapedDefects": 0,
  "severity": null
}

표본이 작다는 사실을 숨기지 않는다. 목적은 업계 전체의 효과를 증명하는 것이 아니라 우리 공정의 다음 결정을 돕는 것이다.

3단계: 성공과 중단 기준을 먼저 적는다

예시:


가설: api-field 업무에서 유출 결함을 늘리지 않으면서
      리드 타임 중앙값을 25% 줄이고 사람 개입 중앙값을 20% 줄인다.

중단: 심각도 높은 결함 1건, 비밀 노출 1건, 또는
      3회 연속 수동 복구 60분 초과 시 자동 실행을 멈춘다.

목표 수치는 팀의 기준선과 위험 허용도에 맞춘다. 실험 뒤 유리한 수치를 고르는 일을 막기 위해 먼저 기록한다.

4단계: 같은 완료 정의를 쓴다

기존 방식과 에이전트 방식 모두 같은 수용 기준과 품질 게이트를 통과해야 완료다. 에이전트 쪽만 느슨한 테스트로 평가하면 비교가 아니다.

5단계: 결과와 원인을 분리한다

리드 타임이 줄지 않았다면 모델이 나쁘다고 바로 결론 내리지 않는다. 작업 준비 시간, 실행 시간, 게이트 시간, 리뷰 대기, 통합 대기를 나누어 병목을 찾는다.

작업 난이도를 태그로 남긴다

쉬운 일만 자동화한 뒤 전체 개발이 빨라졌다고 일반화하지 않도록 다음 특징을 기록한다.

변경 예상 파일 수
관련 모듈 수
외부 시스템 의존 여부
명세 완전성
테스트 준비도
보안·데이터 위험
신규 설계 판단 필요 여부

정밀한 점수 모델보다 일관된 태그가 먼저다. 같은 유형 안에서 전후를 비교하고, 자동화 경계를 넓힐 때 변화가 있는지 본다.

실패 분류가 개선의 출발점이다

failed 하나로 끝내지 말고 원인을 분류한다.


SPEC_MISSING          명세 또는 수용 기준 부족
CONTEXT_STALE         오래된 문서·잘못된 참조
TOOL_TRANSIENT        일시적인 도구·네트워크 오류
TEST_PRODUCT_DEFECT   구현 결함을 테스트가 검출
TEST_FLAKE            같은 입력에서 결과가 흔들림
POLICY_VIOLATION      권한·경로·구조 규칙 위반
INTEGRATION_CONFLICT  병렬 변경 충돌
BUDGET_EXHAUSTED      시간·행동·비용 한도 초과
HUMAN_DECISION        제품·아키텍처 판단 필요

한 달 동안 SPEC_MISSING이 가장 많다면 모델 프롬프트보다 작업 준비 공정을 고친다. INTEGRATION_CONFLICT가 늘면 병렬 수가 아니라 작업 분할과 소유권을 손본다.

왜 실패하는가

전후 기간의 업무 구성이 다르다

도입 전에는 복잡한 기능, 도입 후에는 반복 작업만 비교하면 효과가 과장된다. 같은 업무군으로 비교하고 난이도 태그를 공개한다.

실패한 실행을 지운다

최종 성공만 남기면 비용과 신뢰성이 좋아 보인다. 모든 실행은 원래 taskId에 연결하고 취소·차단·실패를 보존한다.

사람 시간을 자동으로 추정한다

에이전트 실행 시간 전체를 사람 시간으로 보거나, 반대로 0으로 보면 틀린다. 초기 실험에서는 간단한 시작/종료 버튼이나 작업 후 30초 설문으로 직접 기록한다.

지표가 처벌 도구가 된다

개인별 생성량이나 실패율을 평가에 사용하면 사람은 어려운 작업과 실패 기록을 피한다. 공정 개선 지표는 팀과 시스템 수준에서 사용하고 학습을 위한 실패 기록을 보호한다.

운영 판단: 자동화 단계를 넓히는 기준

다음 조건을 두 번 이상의 관찰 기간에서 만족할 때 한 단계 넓힌다.

유출 결함의 심각도와 비율이 기준선보다 나쁘지 않다.
사람 개입 시간이 줄거나 더 높은 가치의 판단으로 이동했다.
실패의 80% 이상이 분류 가능하고 산출물로 재현된다.
상위 90% 리드 타임이 악화되지 않았다.
예산 초과와 정책 위반이 정의된 한도 안이다.

80%는 보편적 기준이 아니라 운영 예시다. 중요한 점은 확장 전에 팀이 수용 기준을 합의하는 것이다.

연습문제

실행 100회, 완료 작업 40개, 성공 작업 30개를 보고 “성공률 30%”라고 말했을 때 어떤 분모가 불명확한가?
현재 계기판에 생성 코드 줄 수만 있다면 흐름·품질·사람·비용 축에서 하나씩 지표를 추가하라.
자동화 도입 전후 비교에서 업무 난이도 편향을 줄이는 태그를 다섯 개 설계하라.
팀에서 가장 자주 발생하는 실패 열 개를 위 분류에 넣고, 분류되지 않는 항목은 새 코드로 정의하라.

체크포인트

요청, 작업, 실행, 변경, 배포의 식별자를 구분했다.
리드 타임, 검증 완료 처리량, 첫 시도 통과율, 사람 개입 시간, 성공 작업당 자원을 함께 본다.
작은 업무군의 기준선과 도입 가설, 중단 기준이 있다.
실패 이유를 검색 가능한 코드로 기록한다.

다음 장에서는 지금까지의 개념을 움직이는 최소 공장으로 만든다. 완벽한 플랫폼 대신 하나의 작업이 입력에서 증거 있는 결과로 흐르는 가장 작은 수직 단면을 완성한다.

Codex로 구축하는 AI 개발팀: 3장. 공장의 성과를 측정하는 법