정상 실행 한 번이 가벼워졌다는 결과만 보면 그 경로를 만드는 동안 쓴 진단과 실패가 사라질 수 있다. 반대로 개발 전체를 정상 실행 한 번의 비용처럼 보여 줘도 판단이 어긋난다. 북극성 작업 기록에는 두 범위를 나란히 남겼고 나는 그 구간을 글에서도 유지하기로 했다.
마지막 성공만 따로 떼어 읽었다
최종 성공 실행은 외부 모델 요청 한 번, 캐시 포함 전체 317,935토큰, 비캐시 입력+출력 623토큰으로 기록돼 있다. 이 수치는 실행기가 끝까지 기존 플러그인을 기다린 그 회차의 값이다. 이전 실패를 없던 일로 만든 값도 아니고 앞으로 매회 같을 것이라는 정액표도 아니다.
실행 완료와 사용량을 함께 볼 필요가 있었다. 작은 수치가 나왔지만 결과가 미확인이라면 같은 업무를 해냈다는 비교가 되지 않는다. 당시 최종 회차는 새 결과를 실제 확인했고 앞선 수동 새로고침 회차와 구별했다. 공개 글에는 원래 계정이나 게시·영상 ID를 넣지 않고 검증의 관계만 남긴다.
개발과 진단의 66회도 같은 표에 남겼다
최종 실행 앞의 개발·진단·시험은 외부 모델 요청 66회, 전체 16,415,813토큰, 비캐시 입력+출력 162,757토큰이었다. 이를 마지막 성공과 합치면 67회, 전체 16,733,748, 비캐시 입력+출력 163,380이 된다. 합계와 범위가 맞는지 다시 계산할 수 있는 기록이다.
이 합계를 정상 실행 한 번과 직접 나눠 절감률이라고 부르지 않았다. 개발은 앞으로 재사용할 구조를 만들기 위한 여러 시도이고 정상 실행은 이미 정한 절차를 쓰는 한 회차다. 그렇다고 개발 수치를 숨기지도 않는다. 두 범위가 모두 있어야 제작자가 무엇을 얻기 위해 어떤 시행을 했는지 읽을 수 있다.
측정 구간의 시작과 끝도 결과의 일부다
과거 보고서는 사용자 요청부터 최종 검증까지라는 시간 구간을 적고 이후 집계·보고서 작성·관제탑 기록·최종 답변은 제외했다고 명시했다. 전체 프로젝트의 영원한 총비용이라는 뜻은 아니다. 무엇을 포함하지 않았는지도 있어야 나중의 기록과 합쳐 중복 계산하지 않는다.
집필하면서 읽는 토큰이나 새 공유 모듈을 만드는 사용량을 과거 개발 표에 소급해서 끼워 넣지도 않는다. 다른 날짜의 개선은 새 구간이다. 같은 실행 ID를 여러 번 상태 조회했다고 모델 호출 여러 번으로 세는 것도 피해야 한다. 상태 응답 횟수와 사용량 영수증의 호출 집합을 따로 확인한다. 금액이나 구독 사용률로 변환할 정보도 여기서는 없다. 같은 토큰 단위여도 측정 기간과 대상 호출 집합이 다르면 서로 다른 수치다.
실패를 빼면 개발 기록도 정상 실행 표처럼 보인다
오류가 난 요청에도 실제 사용량이 알려졌다면 남겨야 한다. 파싱 실패나 가림, 로딩 오류를 거쳐 수정한 과정을 성공 호출만으로 구성하면 무엇이 어려웠는지가 사라진다. 모르는 수치는 unknown으로 두고 실패 상태를 그대로 유지하는 집계가 필요한 이유다.
과거 사용량 시험에는 같은 측정 실패 영수증을 재전달해도 한 번만 세고, 새 작업에 옛 응답을 더하지 않는 조건이 있다. 실패를 보존하는 것과 중복으로 비용을 늘리는 것은 다른 문제다. 다만 이 시험은 제거된 내부 모델 경로의 역사적 설계이며 이번 글에서 그 실행기를 다시 켠 것은 아니다.
반복 실행의 가치는 횟수와 조건을 더 봐야 한다
정상 경로가 여러 번 재사용되면 개발 노력이 어떻게 돌아오는지 검토할 수 있다. 하지만 단 한 번의 성공과 토큰 표만으로 손익분기 횟수나 모든 업무의 절감액을 정할 수는 없다. 이후 유지보수와 실패, 조건 변화도 새 비용과 결과로 남아야 한다. 미래 반복을 이미 성공한 횟수로 세지 않는다.
공유 원장은 development와 normal_run을 나누고 비교 함수에 개발 구간을 넣지 못하게 했다. 실제 제공자 계측이나 가격 계산은 하지 않는 합성 자료 예제다. 나는 반복 실행의 장점과 그것을 만들기 위해 실제로 들인 일을 함께 읽을 수 있게 남겼다. 어느 한쪽을 지워야 설득력 있는 수치가 되는 글은 만들고 싶지 않았다.