콜드메일 리드 이메일 수집 자동화, 매일 도는 작업이 30일에 8회였다

콜드메일 리드 이메일 수집 자동화, 한 달에 몇 시간을 아끼나

콜드메일을 보내는 회사라면 리드 이메일을 모으는 일부터 자동화하고 싶어집니다. 받는 사람의 주소가 있어야 메일을 쓸 수 있고, 주소를 모으는 일은 사람이 하면 지루하고 오래 걸립니다. 저희도 이 일을 매일 새벽 2시에 도는 예약 작업에 맡겼습니다.

자동화 항목마다 «사람이 했다면 몇 시간이 걸렸을까»를 적는 목록 파일이 있습니다. 여기서 리드 이메일 수집의 줄은 최근 30일 8회 실행에 건당 40분을 곱한 5.3시간이었습니다. 숫자만 보면 작고, 계산에도 틀린 데가 없어 보였습니다.

그런데 이 줄을 한 칸씩 뜯어보니, 곱셈에 들어간 값이 모두 확인을 기다리는 상태였습니다. 매일 도는 작업의 실행 기록이 30일에 8회뿐이었고, 건당 40분은 사람이 재 본 적 없는 추정이었으며, «한 건»이 무엇을 얼마나 처리하는지는 적혀 있지 않았습니다.

이 글은 5.3시간이라는 한 줄을 끝까지 따라가 본 기록입니다. 코드를 짜는 이야기라기보다 자동화가 낸 숫자를 읽는 방법에 가깝습니다. 영업 대행이나 자동화 업체에서 «리드 수집 자동화로 매달 몇 시간 절감» 같은 숫자를 받아 본 적이 있다면, 같은 순서로 그 숫자를 다시 읽어 볼 수 있습니다.

5.3시간은 어떻게 계산했나

목록 파일은 항목마다 같은 공식을 씁니다. 최근 30일 동안 작업이 돈 횟수에 «사람이 하면 1회에 몇 분»을 곱합니다. 리드 이메일 수집 항목에 적힌 값을 그대로 옮기면 아래와 같습니다.

근거 등급 estimate는 «사람이 직접 재 본 값은 아니지만 어떻게 계산했는지는 적어 두었다»는 뜻입니다. 이 항목의 계산 근거는 «대상 사이트 순회 30분 + 정리 10분» 한 줄입니다. 사람이 대상 사이트를 돌며 이메일 주소를 찾는 데 30분, 찾은 주소를 목록으로 정리하는 데 10분이 든다고 본 셈입니다.

근거가 문장으로 남아 있으니 반박할 수 있고, 반박할 수 있어야 고칠 수도 있습니다. 그래서 곱셈에 들어간 두 값, 8회와 40분을 차례로 열어 봤습니다. 먼저 손을 댄 쪽은 기계가 센 값이라 더 단단해 보였던 8회입니다.

매일 새벽 2시 작업이 왜 30일에 8회뿐인가

이 작업의 실행 일정은 크론 표기로 «0 2 * * *»입니다. 매일 새벽 2시 0분에 한 번 돈다는 뜻이고, 일정표대로라면 30일 동안 30번 돌아야 합니다. 목록에 적힌 값은 8회였습니다.

처음 떠오른 설명은 단순했습니다. 리드 수집 작업이 자주 실패하거나 중간에 멈춘다는 가설입니다. 남의 사이트를 도는 작업은 상대 사이트가 느리거나 응답하지 않으면 멈추기 쉬우니, 그럴듯해 보였습니다.

셈법도 이 가설을 거드는 듯했습니다. 이 항목은 «전용 로그», 곧 이 작업만 쓰는 로그 파일에서 실행 기록을 셌습니다. 여러 작업이 섞인 로그에서 줄을 골라내는 방식보다 잘못 셀 여지가 적으니, 8회는 믿을 만한 숫자이고 문제는 작업 쪽에 있다고 봤습니다.

이 가설이 맞다면 다른 작업에서는 이런 숫자가 나오지 않아야 합니다. 리드 수집만의 사정이라면 이웃 항목의 실행 횟수는 일정표에 가까워야 합니다. 같은 목록의 이웃 항목을 나란히 놓고 확인했습니다.

같은 8회가 네 줄 더 있었다

목록 파일에서 리드 이메일 수집 주변에 있는 여섯 항목을 함께 펼쳤습니다. 일곱 항목 모두 하루 한 번 도는 일정으로 잡혀 있습니다.

리드 이메일 수집만 8회가 아니었습니다. 채용 사이트 공고를 모으는 작업 세 개와, 판매할 서비스 후보를 찾으려고 플랫폼 3곳을 훑는 작업도 모두 최근 30일 8회였습니다. 다섯 작업이 서로 다른 시각에 서로 다른 사이트를 도는데, 실행 횟수만 똑같습니다.

리드 수집 작업만 자주 멈춘다면 다섯 줄이 같은 숫자로 맞아떨어질 이유가 없습니다. 첫 가설은 여기서 힘을 잃었습니다. 8회는 리드 수집 작업의 성질보다는, 이 다섯 줄이 함께 가진 조건에서 나온 숫자일 가능성이 커졌습니다.

두 번째로 떠올린 설명은 실행 시각이었습니다. 새벽 2시라면 작업을 돌리는 컴퓨터가 꺼져 있거나 절전 상태였을 수 있습니다. 그런데 채용 공고 수집과 서비스 후보 스캔은 오전 7시대에 도는데도 똑같이 8회였습니다. 반대로 리드 수집보다 20분 늦은 새벽 2시 20분에 도는 기술블로그 작업은 46회였습니다.

실행 시각으로는 두 무리가 갈리지 않았습니다. 갈리는 기준은 셈법이었습니다. 8회로 적힌 다섯 줄은 로그에서 센 값이고(전용 로그 1개, 공용 로그 grep 4개), 46회와 101회는 작업이 끝나며 남기는 산출 마커를 센 값입니다.

일정표와 나란히 놓으면 두 무리 모두 어긋납니다. 산출 마커로 센 두 줄은 하루 한 번 일정으로는 나올 수 없을 만큼 많고, 로그로 센 다섯 줄은 일정보다 한참 적습니다. 어느 쪽도 «작업이 몇 번 돌았나»를 곧바로 말해 주지 못한다는 뜻입니다.

8회는 실행 횟수인가, 기록 개수인가

로그에서 센 값은 정확히 말하면 «로그에 남은 실행 기록의 개수»입니다. 작업이 돌았는데 기록이 남지 않았으면 세지 않고, 기록이 지워졌어도 세지 않습니다. 평소에는 실행 횟수와 기록 개수가 같지만, 둘이 어긋나는 순간 숫자는 아무 경고 없이 작아집니다.

다섯 줄이 같은 8회라는 사실은 원인 후보를 좁혀 줍니다. 작업마다 따로 생기는 실패보다, 다섯 작업이 함께 겪는 조건을 먼저 의심해야 합니다. 아직 확인하지 못한 후보를 적어 두면 이렇습니다.

• 센 기간이 정말 최근 30일인가 — 집계가 로그의 일부 구간만 읽었을 수 있다
• 로그가 30일치 다 남아 있나 — 오래된 기록을 지우거나 새 파일로 넘기는 설정이 있을 수 있다
• 컴퓨터가 켜져 있던 날만 돌았나 — 그렇다면 같은 새벽에 도는 기술블로그 작업의 46회와 설명이 맞지 않는다
• 시작하기 전에 멈춘 날이 있나 — 시작 기록조차 남기지 못한 실행은 어떤 셈법으로도 잡히지 않는다

넷 가운데 어느 쪽인지는 목록 파일만으로 가를 수 없습니다. 목록은 이미 센 결과만 담고, 무엇을 세다가 무엇을 놓쳤는지는 담지 않기 때문입니다.

평가 실무에서 쓰는 원칙이 이 자리에 그대로 들어맞습니다. 자동으로 판정하는 도구를 믿기 전에 실제 기록 20~50개를 사람이 먼저 읽고 어디서 틀리는지 찾으라는 원칙입니다. 셈을 믿기 전에 셈의 재료인 로그 줄을 직접 여는 일이 다음 순서입니다.

한 가지는 분명해졌습니다. 5.3시간의 한쪽 축인 8회는 «작업이 8번 돌았다»가 아니라 «로그에 8번의 흔적이 있다»까지만 말합니다. 실제로 더 돌았다면 5.3시간은 작게 잡힌 값이고, 정말 8번만 돌았다면 매일 모으려던 계획이 일정의 일부만 채운 셈입니다.

건당 40분의 «건»은 무엇인가

곱셈의 나머지 한쪽인 40분에도 비슷한 빈칸이 있었습니다. 목록은 «사람이 하면 건당 40분»이라고 적었고, 여기서 한 건은 작업 1회 실행입니다. 그런데 새벽 작업이 한 번 돌 때 사이트를 몇 곳 도는지, 주소를 몇 개 모으는지는 목록에 없습니다.

근거 문장인 «대상 사이트 순회 30분 + 정리 10분»은 사람이 30분 동안 돌 수 있는 만큼을 한 건으로 친 계산입니다. 기계가 한 번에 그보다 훨씬 많은 사이트를 돈다면 40분은 기계가 한 일을 작게 적은 값입니다. 반대로 기계가 한 번에 몇 곳만 돌고 끝난다면 40분은 크게 적은 값입니다.

사람 기준 시간과 기계 실행 1회를 잇는 다리가 «1회에 처리한 양»인데, 그 다리가 없습니다. 그래서 5.3시간은 위로도 아래로도 틀릴 수 있는 숫자입니다. 틀린 방향조차 모른다는 점이 이 항목의 가장 큰 빈칸입니다.

이웃 항목과 비교하면 이 빈칸이 더 잘 보입니다. 채용 공고 수집은 «채용 사이트 1곳»이 한 건이고, 근거도 «검색·목록 훑기 12분 + 상위 공고 열람·기록 8분»으로 그 1곳을 기준으로 적었습니다. 판매 서비스 후보 스캔은 «플랫폼 3곳 훑기»라고 범위를 적었고, 기술블로그와 리포트형 콘텐츠는 «1편»이 곧 한 건입니다.

일곱 줄 가운데 한 건의 크기가 적혀 있지 않은 줄은 리드 이메일 수집 하나뿐이었습니다. «대상 사이트 순회»라는 말에는 사이트가 몇 곳인지가 빠져 있습니다. 사람 쪽 계산과 기계 쪽 실행이 서로 다른 크기의 «한 건»을 세고 있어도 목록에서는 드러나지 않습니다.

사람 시간으로 다시 재려면 무엇이 필요한가

estimate를 사람이 잰 값으로 바꾸려면, 누군가 실제로 한 번 해 봐야 합니다. 리드 이메일 수집은 이 점에서 유리합니다. 목록에 적힌 사람 기준 시간이 40분이라, 한 번 재는 비용도 40분 안팎입니다.

같은 목록의 기술블로그 작업은 사람 기준 건당 120분, 리포트형 콘텐츠는 90분이라 한 번 재는 데도 그만큼 듭니다. 실측으로 가장 싸게 올릴 수 있는 항목이, 목록에서 작은 숫자를 가진 이 줄이었습니다.

다만 시계만 보면 반쪽짜리 기록이 됩니다. 40분 동안 사이트를 몇 곳 돌았고 주소를 몇 개 찾았는지를 함께 적어야, 기계의 1회 실행과 나란히 놓고 비교할 수 있습니다. 재는 순서는 이렇게 잡을 수 있습니다.

• 사람이 대상 사이트 순회와 정리를 한 번 직접 하며 시간을 잰다
• 그 시간 동안 돈 사이트 수와 찾은 주소 수를 함께 적는다
• 새벽 작업 1회의 로그에서 같은 두 값을 센다
• 두 값의 비율로 «기계 1회 실행 = 사람 몇 분»을 다시 계산한다

이 순서를 거치면 40분이 사람 기준 한 건의 시간에서 기계 기준 한 건의 시간으로 바뀝니다. 8회가 실행 횟수인지 기록 개수인지도 같은 로그를 열면서 함께 확인할 수 있습니다. 한 번의 수작업이 곱셈의 양쪽을 동시에 흔들어 보는 셈입니다.

검수 인프라 문서에 적힌 원칙 하나도 여기 옮겨 둡니다. «통과는 검사한 것 중 걸린 게 없다»는 뜻일 뿐이라는 원칙입니다. 5.3시간이 계산 오류 없이 나왔다는 사실도 같은 종류의 통과입니다. 계산식이 맞았다는 뜻이지, 계산에 넣은 값이 맞았다는 뜻은 아닙니다.

리드 수집 자동화를 검토할 때 무엇을 물어야 하나

리드 이메일 수집을 직접 자동화했거나 업체에 맡기려는 쪽이라면, «월 몇 시간 절감»이라는 숫자를 받았을 때 아래 네 가지를 물어보면 됩니다. 저희 목록의 이 한 줄도 네 질문 가운데 셋에서 답이 흐려졌습니다.

• 몇 번 돌았나 — 실행 일정과 실제 실행 기록이 맞는가
• 기록을 무엇으로 셌나 — 로그의 줄인가, 작업이 남긴 산출물인가
• 한 번에 얼마나 처리했나 — 사이트 몇 곳, 주소 몇 개인가
• 사람 기준 시간은 누가 쟀나 — 잰 값인가, 계산한 값인가

저희 경우 둘째 질문의 답은 분명했습니다. 전용 로그로 셌습니다. 하지만 그 답이 첫째 질문의 답을 보장하지는 않았습니다. 셈법이 깔끔해도 센 대상이 실행이 아니라 기록이면 숫자는 일정표와 어긋날 수 있습니다.

셋째와 넷째 질문은 서로 묶여 있습니다. 한 번에 처리한 양을 모르면 사람 기준 시간을 재도 기계 실행과 이을 수 없고, 사람이 재지 않으면 처리량을 알아도 시간으로 바꿀 수 없습니다. 둘 중 하나만 채우면 숫자는 여전히 추정에 머뭅니다.

콜드메일 쪽에서 보면 이 질문들은 절감 시간보다 더 중요한 곳과도 이어집니다. 리드 수집이 일정의 일부만 돌았다면 발송할 주소 목록도 계획만큼 쌓이지 않았을 수 있습니다. 절감 시간 한 줄의 빈칸이 곧 영업 목록의 빈칸일 수도 있다는 뜻입니다. 발송한 뒤의 숫자를 다시 센 이야기는 콜드메일 회신율을 다시 센 기록에 따로 정리해 뒀습니다.

아직 풀지 못한 것

• 최근 30일 8회가 실행 횟수인지, 로그에 남은 기록 개수인지 가르지 못했습니다. 같은 8회를 가진 다섯 줄을 함께 봐야 원인이 좁혀집니다.
• 새벽 작업 1회가 사이트 몇 곳, 주소 몇 개를 처리하는지 목록에 없습니다. 이 값이 없으면 건당 40분을 기계 실행과 이을 수 없습니다.
• 건당 40분은 여전히 estimate입니다. 사람이 한 번 직접 해 보며 재기 전까지 등급은 그대로입니다.
• 산출 마커로 센 46회와 101회가 왜 하루 한 번 일정보다 많은지도 이 글의 범위 밖에 남아 있습니다.

5.3시간은 지우지 않았습니다. 추정이라는 이름표와, 일정표와 맞지 않는다는 메모를 붙인 채 그대로 둡니다. 이름표가 붙어 있어야 나중에 한 칸씩 잰 값으로 바꿔 넣을 수 있습니다.

자동화 항목 전체를 근거 등급으로 나눈 이야기는 AI 업무 자동화 절감 시간을 등급별로 나눈 기록에, 예약 작업이 조용히 멈췄는데 감시 도구가 정상이라고 답한 사례는 크론 실패 감지 기록에 있습니다. 회사의 리드 수집이나 업무 자동화가 실제로 얼마나 도는지 이런 방식으로 따져 보고 싶다면 상담에서 이야기를 나눌 수 있습니다.