목록에 적힌 한 줄 — 서비스 후보 스캔 크론의 한 달 4.5시간
자동화 작업이 늘어나면 «그래서 이 작업들이 사람 시간을 얼마나 아껴 주나»를 한곳에 모아 두고 싶어집니다. SGK 스튜디오는 크론 작업마다 한 줄씩, 같은 칸을 채워 목록 파일에 적습니다. 칸은 실행 주기, 최근 30일 실행 횟수, 그 횟수를 센 방법, 사람이 하면 걸릴 건당 시간, 그 시간의 근거와 근거 등급, 그리고 두 값을 곱한 대체 시간입니다.
이번에 뜯어 본 줄은 판매할 서비스 후보를 찾는 스캔 작업입니다. 외부 플랫폼 3곳에 새로 올라온 글을 매일 아침 훑어서, 우리가 새로 내놓을 만한 서비스의 실마리를 모으는 크론입니다. 목록에는 이렇게 적혀 있었습니다.
- 크론 이름 offer-scan · 실행 주기 `12 7 * * *`(매일 아침 7시 12분)
- 최근 30일 실행 9회 · 셈법: 공용 로그 grep
- 사람이 하면 건당 30분 · 근거 등급: estimate(추정)
- 근거: 플랫폼 3곳 훑기 20분 + 기록 10분
- 대체 시간 4.5시간 (9회 × 30분)
곱셈 자체는 틀린 데가 없습니다. 9회에 30분을 곱하면 4.5시간이고, 이 값만 떼어 보면 «이 크론이 매달 사람 몫의 4.5시간을 대신한다»는 문장이 자연스럽게 따라 나옵니다. 그런데 이 문장을 보고서에 옮기기 전에 두 인수가 각각 어디서 왔는지부터 확인해야 합니다. 결과가 깔끔할수록 인수의 출처를 묻는 사람이 줄어들기 때문입니다.
자동화 절감 시간 계산은 어떤 곱셈인가?
자동화 절감 시간 계산은 결국 한 줄짜리 곱셈입니다. 정해 둔 기간 동안 작업이 몇 번 돌았는지(실행 횟수)에, 같은 일을 사람이 손으로 하면 한 번에 몇 분이 걸리는지(건당 시간)를 곱합니다. 이 목록은 기간을 최근 30일로 잡았습니다.
이 목록의 장점은 두 인수에 각각 꼬리표가 붙어 있다는 데 있습니다. 실행 횟수 옆에는 «셈법»이, 건당 시간 옆에는 «근거 등급»과 «근거»가 붙습니다. 셈법은 횟수를 어디서 셌는지(여러 작업이 함께 쓰는 로그를 검색했는지, 작업이 남긴 산출물 표시를 셌는지, 작업 전용 로그를 봤는지)를 적고, 근거 등급은 건당 시간이 사람이 직접 잰 값인지 추정인지를 적습니다.
곱셈에서는 두 인수 중 약한 쪽이 결과 전체의 신뢰도를 정합니다. 횟수를 정확히 셌어도 건당 시간이 두 배 부풀었다면 결과도 두 배 부풉니다. 반대로 건당 시간을 초시계로 쟀어도 횟수가 절반만 잡혔다면 결과는 절반으로 줄어듭니다. 그래서 결과값 옆에 두 꼬리표를 함께 두어야 나중에 누군가 이 숫자를 의심할 수 있습니다.
이 작업의 꼬리표는 «공용 로그 grep»과 «estimate»였습니다. 앞의 꼬리표는 여러 작업이 함께 쓰는 로그 파일에서 이 크론의 흔적을 검색해 셌다는 뜻이고, 뒤의 꼬리표는 30분이 추정이라는 뜻입니다. 두 인수를 차례로 따라가 봤습니다.
매일 도는 크론인데 왜 30일에 9회인가?
먼저 실행 횟수입니다. 실행 주기 `12 7 * * *`는 크론 표기로 «매일 7시 12분»입니다. 기계가 매일 켜져 있고 작업이 매번 돌았다면 30일 동안 30회 가까이 찍혀야 합니다. 목록에 적힌 값은 9회였습니다.
처음 떠오르는 짐작은 둘 중 하나입니다. 작업이 한 달 가운데 대부분의 날에 돌지 않았거나, 셈법이 실제 실행 가운데 일부만 잡았거나. 이 한 줄만으로는 둘을 가를 수 없어서 같은 목록의 이웃 작업을 나란히 놓았습니다. 이웃 여섯 줄도 전부 하루 한 번 도는 일정이었습니다.
결과는 한눈에 갈립니다. 공용 로그 grep으로 센 네 줄(서비스 후보 스캔과 채용 사이트 공고 수집 세 곳)은 모두 9회였고, 전용 로그로 센 리드 이메일 수집도 9회였습니다. 반면 산출 마커, 곧 작업이 만든 결과물의 표시를 센 두 줄은 기술 글 1편 작성이 50회, 리포트형 콘텐츠 발행이 100회였습니다. 하루 한 번 일정에서 30일에 100회는 나올 수 없는 값입니다.
이 목록에서 실행 횟수는 일정보다 셈법을 더 따라갑니다. 로그를 검색한 줄은 일정보다 한참 적게, 산출물 표시를 센 줄은 일정보다 많게 나왔습니다. 9회가 맞는 값이라면 서비스 후보 스캔은 한 달 대부분을 쉬었다는 뜻이고, 셈법이 실행을 덜 잡았다면 4.5시간은 실제보다 작게 적힌 값입니다. 목록에는 어느 쪽인지 적혀 있지 않고, 이 글도 원인을 확인하지 못한 채로 남겨 둡니다.
실행 횟수가 일정보다 많이 찍힌 반대편 사례는 리포트 자동 발행 크론 — 하루 1번인데 30일에 100회에서 따로 다뤘습니다. 두 글을 합치면 결론은 하나입니다. 실행 횟수는 적힌 대로 믿기 전에 실행 주기와 먼저 맞춰 봐야 합니다. 30일 동안 하루 한 번이면 상한이 30회이고, 그보다 많거나 한참 적으면 작업보다 셈법을 먼저 의심합니다.
건당 30분은 어디서 왔나?
다음은 건당 시간입니다. 근거 등급이 estimate라는 말은 누군가 초시계를 들고 이 일을 해 본 적이 없다는 뜻입니다. 그렇다고 아무 숫자나 적지는 않았습니다. 30분은 «플랫폼 3곳 훑기 20분 + 기록 10분»으로 쪼개져 있습니다. 한 덩어리로 30분이라고 적는 대신, 사람이 이 일을 할 때 거치는 단계를 나누고 단계마다 시간을 붙였습니다.
쪼개 두면 좋은 점이 분명합니다. 30분이 부풀었는지 의심스러울 때 어느 칸을 먼저 재야 할지가 보입니다. 이 작업이라면 플랫폼 3곳을 훑는 20분이 큰 칸이므로, 사람이 한 번 직접 훑어 보며 시간을 재면 추정의 큰 쪽을 실측으로 바꿀 수 있습니다.
이웃 작업들도 같은 방식으로 건당 시간을 쪼갰습니다. 다섯 종류를 나란히 놓으면 아래 표와 같습니다. 채용 사이트 공고 수집 세 곳은 근거가 같아 한 줄로 합쳤습니다.
다섯 줄 모두 근거 등급이 추정입니다. 그중 근거의 출처까지 적은 줄은 기술 글 한 줄뿐이었습니다. 기술 글은 «라이브 9편의 실제 분량(11K~23K자)에서 역산»했다고 적혀 있어, 이미 발행한 글의 길이라는 관측값에서 출발했다는 사실을 알 수 있습니다. 나머지 네 줄은 단계별 시간을 적었지만, 그 시간이 어디서 나왔는지는 적지 않았습니다.
하나 더 눈에 띄는 점이 있습니다. 기술 글은 «60~90분 + 30분»으로 쪼갰는데 적힌 합계는 120분입니다. 범위가 있는 추정에서 위쪽 끝을 골랐다는 뜻입니다. 추정을 적을 때 범위의 어느 쪽을 골랐는지까지 남겨 두면, 나중에 합계를 보고하는 사람이 그 값이 넉넉하게 잡은 값인지 판단할 수 있습니다.
쪼갠 두 칸은 무엇을 알려 주나?
표를 세로로 읽으면 모든 줄이 같은 모양입니다. 앞 칸은 일 자체(훑기·순회·작성)이고, 뒤 칸은 그 일을 마무리하는 시간(기록·정리·검수·발행)입니다. 뒤 칸의 크기는 8분에서 30분 사이였습니다.
훑어보고 모으는 작업(서비스 후보 스캔·채용 사이트 공고 수집·리드 이메일 수집)의 마무리는 8~10분이었고, 글을 쓰는 작업(리포트형 콘텐츠·기술 글)의 마무리는 30분이었습니다. 훑는 작업에서는 찾은 내용을 적어 두는 시간이, 글 쓰는 작업에서는 검수하고 발행하는 시간이 마무리 칸을 차지합니다.
이 구분이 중요한 이유가 있습니다. 목록은 두 칸 모두 자동화가 대신한다고 가정합니다. 하지만 크론이 남긴 결과를 사람이 다시 열어 보고 쓸 만한지 판단하는 시간이 있다면, 그 시간은 절감에서 빼야 합니다. 서비스 후보 스캔이라면 크론이 모은 후보 목록을 누군가 읽어야 비로소 쓸모가 생기는데, 그 읽는 시간은 목록 어디에도 없습니다.
그래서 이 한 줄의 30분은 «사람이 하면 걸릴 시간»이지 «자동화 뒤에 사람에게서 사라진 시간»이 아닙니다. 두 값은 자동화가 일을 끝까지 맡을 때만 같아집니다. 결과를 사람이 받아 이어서 처리하는 자동화라면, 받아 드는 시간만큼 두 값이 벌어집니다.
4.5시간이 재지 않은 칸은 무엇인가?
목록의 칸을 다시 훑어보면 빠진 칸이 하나 더 보입니다. 이 작업이 무엇을 찾아냈는지를 적는 칸입니다. 30일 동안 9번 돌면서 서비스 후보를 몇 건 모았는지, 그중 몇 건을 실제로 검토했는지, 쓸 만한 후보가 하나라도 있었는지. 목록에는 이 가운데 어느 값도 없습니다.
이 빈칸이 4.5시간의 성격을 정합니다. 사람이 플랫폼 3곳을 훑으면 새 글이 없는 날에도 20분은 듭니다. 그러니 이 계산은 «사람이 찾아보느라 썼을 시간»을 재고, «찾아서 얻은 결과»는 재지 않습니다. 매일 아무것도 못 찾는 스캔도, 매일 좋은 후보를 찾는 스캔도 이 목록에서는 똑같이 4.5시간입니다.
우리가 사내 화면 품질 검사 규칙에 적어 둔 문장이 여기에도 그대로 들어맞습니다.
«통과»를 정답의 증거로 읽지 않는다. 통과는 «검사한 것 중 걸린 게 없다»일 뿐이다.
그 검사를 처음 돌린 2026년 8월 19일, 영어 페이지 첫 화면의 글자 잘림은 기계 검사를 통과했고 사람이 화면을 한 장으로 모은 이미지를 훑어보다가 잡았습니다. 검사를 통과했다는 사실이 화면이 멀쩡하다는 뜻이 아니었듯, 절감 시간이 쌓였다는 사실도 그 자동화가 쓸모 있었다는 뜻이 아닙니다. 둘 다 «잰 범위 안에서는 문제가 없다»까지만 말해 줍니다.
평가 규칙 문서에도 같은 경고가 있습니다. 실패 사례를 보기 전에 평가 도구부터 만들면 «측정 가능한 것만 측정, 진짜 문제 놓침»으로 끝난다는 문장입니다. 실행 횟수와 건당 시간은 로그와 추정으로 채울 수 있는 값이고, 결과는 누군가 후보를 읽고 판정해야 채워지는 값입니다. 이 목록에는 앞의 두 칸만 있습니다.
일곱 줄 가운데 이 한 줄의 크기
이제 이 한 줄을 목록 전체에 놓아 봅니다. 이웃 작업 여섯 줄을 포함한 일곱 줄의 대체 시간은 리포트형 콘텐츠 발행 150.0시간, 기술 글 1편 작성 100.0시간, 리드 이메일 수집 6.0시간, 서비스 후보 스캔 4.5시간, 채용 사이트 공고 수집 세 곳이 각각 3.0시간입니다.
서비스 후보 스캔은 작은 줄입니다. 합계를 움직이는 쪽은 산출 마커로 센 두 줄이고, 그 두 줄은 앞에서 봤듯 하루 한 번 일정으로는 나올 수 없는 횟수를 달고 있습니다. 합계를 보고할 일이 있다면 먼저 손볼 곳은 이 한 줄이 아니라 큰 두 줄입니다.
그래도 작은 줄을 가볍게 넘길 수 없는 이유가 있습니다. 공용 로그 grep으로 센 네 줄은 셈법 하나를 나눠 씁니다. 셈법이 실행을 덜 잡는다면 네 줄이 같은 방향으로 함께 작게 나오고, 서로 비교해서는 그 오차가 드러나지 않습니다. 네 줄이 모두 9회로 똑같다는 사실은 네 작업이 똑같이 돌았다는 증거일 수도 있고, 같은 셈법이 같은 방식으로 틀렸다는 신호일 수도 있습니다. 이 목록만으로는 둘을 가를 수 없습니다.
직접 계산할 때 챙길 네 칸
회사에서 돌리는 자동화의 절감 시간을 직접 계산해야 한다면, 이번 한 줄에서 배운 점을 네 칸으로 정리할 수 있습니다. 앞의 두 칸은 이 목록에 이미 있고, 뒤의 두 칸은 이 목록에 없습니다.
- 실행 횟수와 셈법 — 횟수 옆에 어디서 셌는지를 적고, 실행 주기와 먼저 맞춰 봅니다. 30일 동안 하루 한 번이면 상한은 30회입니다.
- 건당 시간과 분해 — «일 자체»와 «마무리»로 쪼개고, 큰 칸부터 한 번 직접 재서 추정을 실측으로 바꿉니다. 범위로 추정했다면 어느 끝을 골랐는지도 적습니다.
- 남는 사람 시간 — 자동화가 남긴 결과를 사람이 읽고 판단하는 시간을 따로 적고, 절감에서 뺍니다.
- 결과 — 이번 기간에 무엇을 몇 건 찾았고 그중 몇 건을 썼는지 적습니다. 시간은 투입을, 결과는 쓸모를 말합니다.
서비스 후보 스캔 한 줄에 이 네 칸을 적용하면, 지금 채울 수 있는 칸은 앞의 둘뿐이고 뒤의 둘은 «미기록»으로 남습니다. 빈칸이라도 먼저 만들어 두어야 다음 30일부터 값이 쌓입니다. 칸이 없으면 아무도 그 값을 찾지 않습니다.
이 글이 끝까지 답하지 못한 질문도 적어 둡니다. 매일 도는 크론이 왜 30일에 9회로 적혔는지, 9번의 스캔이 서비스 후보를 몇 건 찾았는지는 목록만으로 알 수 없습니다. 두 질문 모두 목록이 아니라 작업 자체의 기록을 열어야 답이 나옵니다.
절감 시간 값이 사람이 잰 값인지 추정인지를 등급으로 나눠 본 이야기는 자동화 절감 시간의 근거 등급을 나눈 글에 정리해 뒀습니다. 회사에서 돌리는 자동화가 실제로 얼마나 시간을 아끼는지, 절감 시간 목록을 어떤 칸으로 설계하면 좋을지 함께 따져 보고 싶다면 상담에서 이야기를 나눌 수 있습니다.