AI 업무 자동화 절감 시간, 283.3시간 중 실측은 0시간이었다

AI 업무 자동화로 아낀 시간, 왜 합계 하나로 말하면 틀리나

AI 업무 자동화를 들인 회사가 가장 먼저 받는 질문은 «그래서 몇 시간 아꼈나»입니다. 저희도 같은 질문에 답하려고 자동화 항목마다 사람이 했다면 걸렸을 시간을 적어 두고 합계를 냈습니다. 항목별로 최근 30일 실행 횟수에 건당 시간을 곱해 더한 값이고, 2026년 9월 12일 기준 합계는 283.3시간이었습니다.

그런데 이 283.3시간을 근거 종류별로 쪼개 보니, 사람이 직접 시간을 재 본 값은 0시간이었습니다. 비슷한 업무에서 잰 실측치를 빌려 온 값도 0시간이었습니다. 283.3시간 전부가 «계산 과정을 적어 둔 추정»이었고, 시간을 잴 방법조차 없는 17건은 합계에서 뺐습니다.

합계 하나만 들고 나가면 «자동화로 283.3시간을 아꼈다»는 문장이 됩니다. 계산이 틀린 숫자는 아니지만, 이 문장을 읽는 사람은 누군가 그 시간을 재 봤다고 받아들입니다. 근거가 추정뿐인 숫자를 실측처럼 읽히게 두면 숫자는 맞아도 문장이 거짓말이 됩니다.

이 글은 그 합계를 등급별로 갈라 적은 방법과, 갈라 놓고 나서야 보인 빈틈을 정리한 기록입니다. 코딩 이야기라기보다 숫자를 읽는 방법에 가깝습니다. 자동화 업체에서 «월 몇 시간 절감»이라는 숫자를 받아 본 적이 있다면, 같은 기준으로 그 숫자를 다시 읽어 볼 수 있습니다.

근거 등급 4단 — 2026년 9월 12일 집계표

자동화 항목 하나하나에 «이 시간은 무엇을 근거로 적었나»를 네 등급 중 하나로 붙였습니다. 이름은 영어 그대로 두고 뜻을 함께 적습니다.

• measured — 사람이 실제로 그 일을 해 보며 잰 값
• analogous — 형태가 같은 다른 업무에서 잰 실측치를 옮겨 온 값
• estimate — 실측은 없지만 어떻게 계산했는지 적어 둔 추정
• 미계측 — 잴 방법도, 계산할 근거도 없는 항목. 합계에 넣지 않고 따로 센다

표를 세로로 읽으면 결론이 바로 나옵니다. 위의 두 줄이 비어 있고, 모든 시간이 셋째 줄에 몰려 있습니다. 283.3시간이라는 숫자 자체는 계산이 맞습니다. 다만 이 숫자가 말할 수 있는 범위는 «이렇게 계산하면 이만큼 나온다»까지이고, «이만큼 아꼈다»까지는 가지 못합니다.

등급을 네 칸으로 나눈 이유는 등급마다 틀릴 수 있는 방식이 다르기 때문입니다. measured는 재는 날의 조건에 따라 흔들리지만 적어도 누군가 확인한 값입니다. analogous는 «이 업무가 저 업무와 정말 같은 형태인가»라는 가정 하나에 기댑니다. estimate는 계산식에 들어간 값 하나하나가 모두 가정입니다.

이 셋을 더하면 서로 다른 종류의 불확실성이 한 숫자 안에 섞입니다. 읽는 사람은 어느 부분을 얼마나 믿어야 할지 가를 수 없고, 쓴 사람도 나중에 어느 칸을 고쳐야 합계가 바로잡히는지 찾기 어려워집니다.

항목마다 등급은 어떤 순서로 붙이나

네 등급의 정의를 판정 순서로 바꾸면 질문 세 개가 됩니다. 위에서부터 차례로 묻고, 처음으로 «예»가 나오는 자리에서 등급이 정해집니다.

• 사람이 이 업무를 직접 해 보며 시간을 잰 기록이 있나 → 있으면 measured
• 없다면, 형태가 같은 다른 업무에서 잰 실측치가 있나 → 있으면 analogous
• 그것도 없다면, 건당 시간을 어떻게 계산했는지 문장으로 적을 수 있나 → 있으면 estimate
• 셋 다 아니면 미계측 → 합계에 넣지 않는다

순서를 이렇게 둔 이유는 위로 올라갈수록 확인한 사람이 가까워지기 때문입니다. 한 항목이 여러 등급에 걸쳐 보이면 더 위의 등급을 붙이지 않고, 근거가 실제로 있는 가장 위의 칸에 멈춥니다. 등급을 높여 적는 쪽이 늘 더 끌리기 때문에, 이 순서는 그 끌림을 막는 장치이기도 합니다.

이 순서로 목록을 훑은 결과가 앞의 집계표입니다. 첫째와 둘째 질문에서 «예»가 나온 항목은 없었고, 셋째 질문에서 16개가 멈췄으며, 17건은 끝까지 내려갔습니다.

추정 283.3시간은 어떻게 계산했나

estimate 등급 항목은 모두 같은 공식으로 계산합니다. 최근 30일 실행 횟수에 «사람이 하면 건당 몇 분»을 곱합니다. 공식이 단순하니 결국 곱하는 두 값 각각이 어디서 왔는지가 전부입니다.

목록에 오른 추정 항목 16개 가운데 여섯 개를 열어 봤습니다. 여섯 개 모두 매일 한 번씩 도는 예약 작업입니다.

여섯 개 중 콘텐츠를 만드는 두 항목이 151.5시간과 92.0시간으로, 추정 합계의 대부분을 이 둘이 차지합니다. 채용 공고 수집 세 항목은 각각 2.7시간이라 모두 합쳐도 콘텐츠 한 항목에 한참 못 미칩니다. 리드 이메일 수집은 5.3시간입니다.

그래서 283.3시간이 흔들린다면, 흔들리는 자리는 콘텐츠 두 항목의 «건당 몇 분»과 «몇 회»입니다. 작은 항목의 건당 시간을 두 배로 잘못 적어도 합계는 거의 움직이지 않지만, 큰 두 항목의 값이 조금만 어긋나도 합계가 크게 달라집니다. 확인할 순서도 여기서 정해집니다.

건당 120분은 어디서 왔나

추정이 추정으로 남는 이유는 곱하는 값 가운데 사람이 직접 잰 값이 하나도 없어서입니다. 항목마다 적어 둔 근거를 그대로 옮기면 이렇습니다.

• 기술블로그 1편 — «6,600자 이상 기술 글 1편 수기 작성 60~90분 + 검수·발행 30분. 라이브 9편의 실제 분량(11K~23K자)에서 역산»
• 리포트형 콘텐츠 1편 — «동일 형식 리포트 1편 수기 작성 60분 + 검수·발행 30분»
• 채용 공고 수집 — «검색·목록 훑기 12분 + 상위 공고 열람·기록 8분»
• 리드 이메일 수집 — «대상 사이트 순회 30분 + 정리 10분»

근거를 문장으로 적어 둔 점이 estimate 등급의 조건입니다. 계산 과정이 보이니 누구든 반박할 수 있고, 반박할 수 있어야 고칠 수 있습니다. 근거 없이 «한 20분쯤 걸리겠지»로 적은 값이었다면 estimate가 아니라 미계측으로 내려갔을 항목들입니다.

처음에는 이 정도면 충분히 정직한 추정이라고 봤습니다. 그런데 적힌 근거를 다시 읽으니 걸리는 자리가 하나 있었습니다. 기술블로그 항목의 근거는 «수기 작성 60~90분 + 검수·발행 30분»입니다. 이 식대로라면 한 편에 90분에서 120분 사이가 나오는데, 목록에는 범위의 위쪽 끝인 120분이 적혀 있습니다.

라이브 9편의 분량이 11K~23K자로 기준선 6,600자보다 훨씬 길다는 점을 들어 위쪽을 고른 셈입니다. 그 판단에도 이유는 있지만, 누가 시계를 보고 확인한 값은 아닙니다. 이 한 칸을 90분으로 바꾸면 기술블로그 항목의 대체 시간이 줄고, 합계도 함께 줄어듭니다.

근거를 적어 두는 일과 근거가 맞는지 확인하는 일은 별개였습니다. 적어 둔 근거 안에도 범위에서 한쪽 끝을 고르는 선택이 숨어 있었고, 이번 경우 그 선택은 합계를 키우는 방향이었습니다. 범위가 있는 근거라면 어느 끝을 골랐는지까지 적어야 읽는 사람이 그 선택을 되돌려 볼 수 있습니다.

실행 횟수는 무엇을 셌나

곱하는 값의 나머지 절반인 실행 횟수는 기계가 센 값이라 믿을 만하다고 여겼습니다. 건당 시간은 추정이어도 실행 횟수만큼은 실측이라는 가정입니다. 다시 열어 보니 항목마다 세는 방법부터 달랐습니다.

• 산출 마커 — 작업이 끝나며 남기는 표시를 센다 (기술블로그·리포트형 콘텐츠)
• 공용 로그 grep — 여러 작업이 함께 쓰는 로그 파일에서 해당 작업의 줄을 찾아 센다 (채용 공고 수집 세 항목)
• 전용 로그 — 그 작업만 쓰는 로그를 센다 (리드 이메일 수집)

셈법이 셋이라는 사실만으로는 문제가 없습니다. 걸리는 자리는 실행 일정과 나란히 놓았을 때입니다. 여섯 항목은 모두 하루 한 번 도는 일정으로 등록돼 있고, 일정표대로라면 30일 동안 30회를 넘을 수 없습니다.

그런데 기술블로그는 46회, 리포트형 콘텐츠는 101회로 적혀 있습니다. 두 항목 모두 셈법이 산출 마커입니다. 사람이 손으로 추가 실행을 했거나 실행 한 번에 표시가 여러 개 남는 구조라면, 이 숫자는 «실행 횟수»보다 «산출물 개수»에 가깝습니다. 둘 중 무엇인지는 아직 확인하지 못했습니다.

반대쪽 어긋남도 있습니다. 공용 로그로 센 채용 공고 수집 세 항목과 전용 로그로 센 리드 이메일 수집은 모두 8회로, 일정표가 허용하는 횟수보다 적습니다. 작업이 실제로 덜 돌았는지, 로그가 일부만 남았는지도 아직 가르지 못했습니다.

이 확인으로 처음 가정이 무너졌습니다. 실행 횟수도 무엇을 세느냐에 따라 달라지는 값이었고, 가장 큰 두 항목에서 일정표와 맞지 않았습니다. 283.3시간이 흔들리는 자리가 곱하는 두 값 모두에 있다는 뜻입니다.

잴 수 없는 17건은 왜 0으로 세지 않았나

시간을 잴 방법도 계산할 근거도 없는 항목이 17건 있었습니다. 이 17건을 처리하는 가장 쉬운 방법은 0시간으로 적어 합계에 넣는 방법입니다. 표에 빈칸이 사라지고, 집계도 한 줄 짧아집니다.

그렇게 하지 않았습니다. 0시간은 «이 자동화는 사람 시간을 하나도 대신하지 않는다»는 주장입니다. 저희는 그걸 확인한 적이 없습니다. 모르는 값을 0으로 적으면 합계를 키우는 거짓말 대신 합계를 줄이는 거짓말을 하게 될 뿐, 모르면서 아는 척한다는 점은 같습니다.

0으로 넣으면 생기는 문제가 하나 더 있습니다. 항목당 평균을 내거나 «자동화 항목 중 몇 개가 효과를 냈나»를 셀 때, 0으로 적힌 17건이 «효과 없음»으로 섞여 들어갑니다. 나중에 누군가 그 표만 보고 효과 없는 자동화를 정리하자고 판단하면, 재지 않았을 뿐인 항목이 효과가 없다는 이유로 정리됩니다.

그래서 17건은 합계에서 빼고, 뺐다는 사실을 표의 한 줄로 따로 남겼습니다. 빈칸이 가짜 숫자보다 낫다는 원칙입니다. 빈칸은 «여기는 모른다»를 그대로 보여 주고, 다음에 잴 대상 목록 역할도 합니다.

밖으로 나가는 문장은 어떻게 쓰나

등급을 나눈 뒤 외부로 나가는 문장에는 규칙 하나를 붙였습니다. measured 합계를 먼저 쓰고, 나머지 등급은 그 뒤에 등급 이름과 함께 적습니다. 합쳐서 하나의 큰 수를 만들지 않습니다.

지금 기준으로 이 규칙을 따르면 첫 문장이 «사람이 재 본 절감 시간은 0.0시간입니다»가 됩니다. 보기 좋은 문장은 아닙니다. 하지만 이 문장이 먼저 나와야 뒤에 오는 283.3시간이 «계산해 보면 이만큼»으로 제대로 읽힙니다.

AI 업무 자동화를 검토하는 쪽이라면 같은 기준으로 받은 숫자를 읽을 수 있습니다. «월 몇 시간 절감»이라는 숫자를 받으면 네 가지만 물어보면 됩니다.

• 이 시간은 누가 시계를 보고 쟀나, 아니면 계산했나
• 계산했다면 «건당 몇 분»은 어디서 왔나. 범위가 있었다면 어느 쪽 끝을 골랐나
• «몇 회»는 실행 횟수인가, 산출물 개수인가. 실행 일정과 맞나
• 재지 못한 항목은 0으로 넣었나, 뺐나

네 질문에 답이 바로 나오면 그 숫자는 등급과 함께 믿을 수 있습니다. 답이 흐려지면 숫자보다 문장을 먼저 의심해야 합니다. 저희 목록도 이 네 질문 가운데 셋째 질문에서 아직 답을 못 하고 있습니다.

아직 풀지 못한 것

• measured 등급이 여전히 0개입니다. estimate 항목을 measured로 올리려면 사람이 그 업무를 실제로 한 번 해 보며 시간을 재야 합니다. 합계를 가장 크게 떠받치는 두 항목(151.5시간·92.0시간)부터 재야 흔들림이 가장 크게 줄어듭니다.
• 기술블로그 46회·리포트형 콘텐츠 101회가 실행 횟수인지 산출물 개수인지 가르지 못했습니다.
• 8회로 적힌 네 항목이 실제로 덜 돈 건지, 기록이 덜 남은 건지 모릅니다.
• analogous 등급도 0개입니다. 형태가 같은 업무의 실측치가 하나라도 생기면 옮겨 쓸 수 있지만, 옮기는 순간 «정말 같은 형태인가»라는 가정이 새로 붙습니다.

숫자를 크게 만드는 쪽보다 어디까지가 확인한 값인지 보이게 두는 쪽을 골랐습니다. 283.3시간이라는 추정은 버리지 않았고, 추정이라는 이름표를 붙인 채 그대로 둡니다. 이름표가 붙어 있어야 나중에 한 칸씩 실측으로 바꿔 끼울 수 있습니다.

자동화 항목을 성격별로 먼저 가르는 과정은 크론 자동화의 성격을 먼저 나눈 기록에, 자동 작업 때문에 숫자가 부풀어 오른 비슷한 사례는 git 커밋 수가 부풀려진 이유에 정리해 뒀습니다. 회사의 자동화 효과를 이런 방식으로 따져 보고 싶다면 상담에서 이야기를 나눌 수 있습니다.