자동화 성과 측정에서 크론 168개의 절감 시간을 세다가 막힌 곳

증상: 「크론 168개가 일을 대신한다」를 숫자로 바꿀 수 없었다

자동화 성과 측정에서 먼저 막힌 곳은 재료가 아니라 계측이었다. 크론 168개를 성격별로 나눴더니 사람 업무를 대신하는 작업은 70개였고, 그 70개 가운데 사람이 직접 일하며 잰 시간 기록은 한 건도 없었다. 이 결론에 닿기까지 숫자를 세는 방법을 세 번 바꿨고, 세 번 다 버렸다.

출발점은 우리 기술블로그 목록이었다. 당시 공개한 글 9편 중 6편이 AI 에이전트 운영 이야기였는데, 전부 도구 쪽 각도였다. 승인 절차를 어디에 두나, 작업 중간 점검을 언제 하나, 여러 작업 창을 어떻게 나눠 돌리나 같은 이야기다. 정작 독자가 궁금해할 「그래서 어떤 업무가 얼마나 줄었나」를 다룬 글은 0편이었다.

이 빈칸은 블로그만의 문제가 아니었다. 우리가 고객사에 제안하는 일이 바로 AI 업무 자동화이고, 제안서에 들어가야 할 숫자도 같은 숫자다. 자기 인프라로 그 숫자를 못 내면 제안서에도 못 쓴다. 반대로 지어낸 숫자는 상대가 근거를 한 번만 물어도 무너진다.

실제로 비슷한 함정에 빠질 뻔한 적이 있다. 자동화 데모 14종을 만들어 두고, 크론으로 돌고 있는 데모가 0건인데도 「우리가 이걸로 회사를 굴린다」고 쓸 뻔했다. 이번에는 그 실수를 반복하지 않으려고 숫자를 직접 세기로 했다.

처음엔 무엇을 의심했나?

첫 가설은 「쓸 재료가 없다」였다. 업무 사례를 쓰려면 회사 업무를 다뤄야 하는데, 공개할 수 있는 범위가 좁다고 봤다.

이 가설은 크론 목록을 펼치자마자 틀렸다. 크론 168개가 콘텐츠 발행, 영업 리드, 채용, 운영 감시, 경영 보고를 무인으로 돌리고 있었고, 전부 우리 자체 사업이라 공개 범위에 제한이 없었다. 재료는 충분했다. 막힌 곳은 그 재료를 숫자로 바꾸는 단계였다.

그래서 두 번째 가설로 넘어갔다. 「숫자는 이미 로그에 있다」. 크론은 돌 때마다 로그를 남기니, 실행 횟수에 건당 시간을 곱하면 절감 시간이 나온다는 생각이었다. 이 가설을 세 갈래로 시험했고, 세 갈래 모두 아래에서 차례로 무너진다.

무엇으로 확인했나?

확인 수단은 넷이었다. 모두 이미 쌓여 있는 기록이라 새로 계측기를 달 필요가 없다고 판단했다.

• 크론 로그 — 최근 30일 창에서 작업별 줄 수와 날짜
• 산출 마커 — 글을 발행했을 때처럼 결과물이 생기면 남는 표시
• AI 작업 대화 기록(세션 기록) — 에이전트와 일한 구간의 시작과 끝
• 저장소 전체 검색 — manual_minutes·time_saved처럼 사람이 걸린 시간을 적어 둔 필드

앞의 셋은 「얼마나 자주 했나」를, 마지막 하나는 「한 번에 얼마나 걸렸나」를 찾는 수단이다. 절감 시간은 이 둘을 곱해야 나온다. 어느 한쪽이라도 비면 곱셈 자체가 성립하지 않는다.

로그 줄 수는 왜 실행 횟수가 아니었나?

첫 번째 시도는 로그 줄 수를 실행 횟수로 세는 방식이었다. 기술블로그 초안을 만드는 크론(techblog-daily)은 하루 한 번 돈다. 30일 창이면 많아야 30회여야 하는데, 줄 수로 세니 71회가 나왔다.

원인은 단순했다. 이 크론은 한 번 돌 때 로그를 여러 줄 찍는다. 줄 수가 재는 값은 실행 횟수가 아니라 출력량이었다. 그래서 같은 날짜가 몇 번 나오든 하루로 치는 방식, 즉 날짜를 세는 방식으로 바꿨다. 결과물 표시(산출 마커)가 있는 작업은 아예 그 표시가 몇 번 나왔는지를 센다.

여기까지는 셈법의 문제였다. 셈법을 고치면 풀리는 문제라 아직 가설 전체가 틀렸다고 보지는 않았다. 다만 날짜를 세도 「그날 무엇을 만들었나」는 여전히 알 수 없었다. 이 빈틈이 다음 시도에서 그대로 드러난다.

가동일 × 분은 왜 숫자를 부풀렸나?

두 번째 시도는 가동일에 건당 분을 곱하는 방식이었다. 날짜로 세면 실행 횟수 문제는 풀리니, 그 날짜 수에 사람이 하면 걸리는 시간을 곱하면 된다고 봤다.

리포트를 자동 발행하는 크론(report_autopublish)이 이 방식을 반증했다. 매일 돌기는 하는데, 최근 3일 동안 발행한 글은 0편이었다. 가동일로 곱하면 존재하지 않는 결과물에 시간을 얹어 준다. 크론이 돌았다는 사실과 일을 대신했다는 사실은 서로 다르다.

같은 문제가 더 크게 나타나는 쪽이 폴링형 크론이다. 5분마다(*/5) 또는 15분마다(*/15) 상태를 확인하는 작업은 실행 대부분이 아무것도 만들지 않는다. 여기에 기준선을 곱하면 숫자가 실행 빈도만큼 부푼다. 이 유형은 단위를 poll로 표시만 하고 합계에서 뺐다.

세션 기록은 왜 작업 시간이 될 수 없었나?

세 번째 후보는 AI와 작업한 대화 기록이었다. 사람이 그 일을 한 시간 대신, 에이전트와 그 일을 한 구간 길이라도 쓰자는 생각이었다.

기록 속 구간은 작업 시간이 아니라 세션 길이였다. 한 세션 안에서 여러 일을 처리하고, 잠시 자리를 비워도 세션은 이어진다. 키워드로 업무를 골라내는 방법도 막혔다. 문의 회신을 돕는 매뉴얼 이름(inbound-lead-reply)이 기록에 4,725회 나왔는데, 그만큼 문의에 회신해서가 아니었다. 매 세션 시작 때 쓸 수 있는 매뉴얼 목록이 통째로 들어가기 때문이었다.

구간 길이를 쓰려면 적어도 「이 구간에는 이 일만 했다」는 표시가 있어야 한다. 기록에는 그런 표시가 없었고, 있는 것은 어떤 단어가 몇 번 나왔는지뿐이었다. 그 단어 수마저 업무가 아니라 화면에 기본으로 깔리는 목록을 따라 움직였다.

4,725라는 숫자는 회신 업무량이 아니라 세션 수를 따라 늘어나는 소음이었다. 여기서 세 번째 갈래도 닫혔다.

진짜 원인: 사람이 그 일을 한 시간은 어디에도 적혀 있지 않았다

세 갈래가 모두 막힌 이유는 하나였다. 절감 시간을 계산하려면 「자동화 이전에 사람이 그 일을 하면 몇 분 걸렸나」를 알아야 하는데, 그 값이 어디에도 없었다. 저장소 전체에서 manual_minutes·time_saved 같은 필드는 0건이었다. 로그에도 사람이 그 일을 직접 하고 잰 시각이 없었다.

로그 줄 수·가동일·세션 기록은 전부 「크론이 얼마나 돌았나」를 재는 도구다. 「사람이 얼마나 덜 일했나」는 다른 질문이고, 그 답에 필요한 입력값은 처음부터 비어 있었다. 로그를 아무리 정교하게 세어도 빈 값은 채워지지 않는다.

분모도 틀려 있었다. 168개를 성격 넷으로 나누니 167개가 어느 한쪽에 들어갔다. 업무대체 70, 감시 45, 보고 35, 위생 17이고, 1개는 미분류로 남았다. 감시·보고·위생 작업은 사람 업무를 대신한다기보다 시스템 자체를 돌보는 일이라 기준선을 붙일 대상이 아니다.

통째로 「168개 자동화」라고 쓰면 절반이 틀린다. 기준선을 붙일 자격이 있는 것은 70개뿐이다.

어떻게 고쳤나?

고친 방향은 「숫자를 지어낼 수 없는 구조」였다. 기준선을 모아 두는 파일 하나와, 그 파일을 읽어 집계하는 스크립트 하나를 새로 만들고 규칙 넷을 걸었다.

• 업무대체형 70개에만 기준선을 붙인다. 감시·보고·위생 작업은 대상에서 뺀다.
• 모든 기준선에 근거 등급(basis)을 의무로 적는다. 등급은 measured(직접 잼)·analogous(비슷한 작업에서 빌려 옴)·estimate(추정)·없음 넷이다.
• 근거 등급이 없는 항목은 0으로 치지 않고 「미계측」으로 따로 떼어 합계에서 뺀다.
• 실측값을 넣는 입구는 명령 하나로 정했다. measure <작업 id> --minutes N --note "..." 로 한 번 재면 영구히 남는다.

셋째 규칙이 가장 중요했다. 근거 없는 칸을 0으로 두면 합계는 조용히 작아지고, 근거 없는 칸에 그럴듯한 분을 넣으면 합계는 조용히 커진다. 어느 쪽이든 읽는 사람은 그 차이를 모른다. 미계측을 따로 세워 두면 「몇 개는 아직 모른다」가 숫자 옆에 함께 보인다.

그 위에서 실제로 셀 수 있는 숫자를 다시 냈다. 업무대체형 70개 중 로그나 산출 마커로 결과물 개수를 셀 수 있는 작업은 3개였다. 최근 30일 리포트 자동 발행 79편에 편당 90분, 기술블로그 초안 5편에 편당 120분, 여기에 소재 발굴 작업(topic-mine)을 더해 128.9시간이 나왔다.

이 128.9시간에는 estimate 등급이 붙는다. 편당 90분과 120분은 사람이 재 본 값이 아니다. 작업 지시서는 measured 등급 3건 이상을 완료 조건으로 요구했지만 실제는 0건이었다. 그 자리를 그럴듯한 값으로 메우는 대신, 요건 미충족을 그대로 기록에 남겼다.

같은 실수를 막는 장치는 무엇인가?

장치는 사람의 주의력이 아니라 구조에 걸었다. 다음 사람이 서둘러 숫자를 써도 근거 없는 값이 합계에 섞이지 않게 하는 쪽이다.

• 근거 등급이 없는 기준선은 합계에 들어가지 못한다. 숫자가 없으면 0이 아니라 빈칸으로 보인다.
• 폴링형 크론은 poll 단위 표시로 계산에서 빠진다.
• 기술블로그 소재 발굴기가 이 기준선 파일을 읽도록 연결하고, 업무 기준선 쪽 소재가 한동안 안 나오면 경고하는 장치(굶주림 가드)를 걸었다.
• 크론 개수를 자동화 성과로 보고하지 않는다. 개수는 활동 지표일 뿐이다.

다만 이 장치에도 한계가 있었다. 9월 16일 회사 기능별로 AI 대체 정도를 감사하려고 이 파일을 다시 열었을 때, 168건 중 사람 시간과 근거 등급이 빈 항목이 139건이었고 measured는 여전히 0건이었다. 지어내기를 막는 장치는 제 몫을 했지만, 빈칸을 채우는 일은 아무도 하지 않았다.

그 감사는 질문 자체를 바꾼 작업이었다. 처음에는 「AI가 만든 상품 하나가 팔리나」를 보려 했지만, 상품 선정이 세 번 연달아 기각되면서 「제품·영업·마케팅·CS·재무·법무·행정 각 기능이 얼마나 AI로 바뀌었나」로 단위를 옮겼다. 기능 단위로 보려면 기능마다 사람 시간이 있어야 하고, 그 첫 입력이 바로 이 파일의 빈칸이었다.

그래서 계측 채우기를 다음 작업의 첫 단계로 올렸다. 어느 업무부터 자동화할지는 「사람 시간 × 빈도」로 정해야 하는데, 그 식의 입력값이 비어 있으면 우선순위를 낼 근거도 없다. 막는 장치와 채우는 일정은 별개라는 점이 두 번째로 배운 사실이다.

자동화 성과 측정, 무엇부터 해야 하나?

우리 사례에서 순서를 다시 짠다면 이렇다.

• 자동화 목록을 성격별로 먼저 나눈다. 우리 경우 168개 중 업무를 대신하는 작업은 70개였다.
• 실행 횟수는 로그 줄 수가 아니라 날짜나 결과물 표시로 센다.
• 돌았다는 사실과 결과물을 냈다는 사실을 분리한다. 매일 돌아도 3일 동안 0편일 수 있다.
• 숫자마다 근거 등급을 붙이고, 근거 없는 숫자는 합계에서 뺀다.
• 자동화하기 전에, 사람이 그 일을 할 때 한 번이라도 시간을 잰다. 이 값은 나중에 어떤 로그로도 복원하지 못한다.

같은 계측 문제를 근거 등급 쪽에서 다룬 글로 AI 업무 자동화 절감 시간 실측 이야기가 있고, 크론이 실제로 돌았는지부터 확인한 과정은 크론 실행 확인 기록에 적었다.

사내 자동화의 효과를 숫자로 설명해야 하는데 근거 기록이 비어 있다면, 상담에서 무엇을 먼저 잴지부터 함께 정할 수 있다.

글: SGK 스튜디오