크론 모니터링에서 '등록'과 '실행'은 왜 다른 말인가?
크론(정해진 시각마다 자동으로 실행되는 프로그램)을 여러 개 운영하다 보면 '목록에 등록해 뒀으니 잘 돌고 있겠지'라는 가정에 기대게 됩니다. SGK 스튜디오도 그렇게 믿고 있었는데, 크론 모니터링을 등록 목록이 아니라 실제 실행 로그 기준으로 다시 해 보니 그 가정이 절반 가까이 어긋나 있었습니다.
2026년 9월 14일 기준으로 등록된 크론은 168개였고, 그중 사람이 하던 일을 대신한다고 보아 시간 절감을 말할 자격을 준 것은 업무대체형 70개였습니다. 이번에 그 70개를 대상으로 최근 30일치 실행 로그를 실제로 세어 보니, 20개는 실행 흔적이 0회였고 17개는 로그 형식이 서로 달라 횟수를 셀 수조차 없었습니다. 실제로 셀 수 있었던 크론은 70개에서 20개와 17개를 뺀 33개뿐이었습니다.
- 실행 0회 20개 — 로그는 있는데 최근 30일 동안 실행 흔적이 하나도 없습니다.
- 셀 수 없음 17개 — 로그 형식이 서로 달라 실행 횟수를 셀 수 없습니다.
- 확인 가능 33개 — 위 두 그룹을 뺀 나머지로, 실제로 실행 횟수를 셀 수 있었습니다.
이 문제는 크론을 직접 운영하지 않는 회사에도 남의 일이 아닙니다. 반복 업무를 자동화로 넘기는 회사라면 어디서나 '자동화를 걸어 뒀다'와 '자동화가 실제로 돌고 있다' 사이에 같은 간격이 생길 수 있습니다. 등록 화면이나 설정 목록만 보고 절감 효과를 계산하면, 그 계산에 실행 0회인 항목이 섞여 있어도 걸러지지 않습니다.
168개에서 70개로 좁혀 둔 이유
크론 모니터링을 70개부터 시작한 데는 이유가 있습니다. 등록된 크론 168개를 성격별로 나누면 사람이 하던 일을 대신하는 업무대체형 70개, 사람이 원래 하지 않던 일을 감시하는 감시형 45개, 손이 아니라 판단을 앞당기는 보고형 35개, 인프라 자체를 유지하는 위생형 17개, 아직 분류하지 않은 것 1개로 갈립니다.
시간 절감을 말할 자격은 업무대체형 70개뿐이고, 그중에서도 비교할 기준선까지 갖춘 것은 16개였습니다. 이 분류를 처음 정리한 기록은 크론 168개를 성격 넷으로 가른 글에 있습니다.
다섯 성격은 시간 절감과 맺는 관계가 다릅니다. 감시형은 사람이 원래 하지 않던 일이라 '사람이 했으면 몇 분 걸렸을까'라는 비교 기준 자체가 없습니다. 보고형은 손이 아니라 판단을 앞당기는 일이라 시간으로 환산하기 애매합니다. 위생형은 인프라를 유지하는 일이라 업무로 셀 수 없습니다. 업무대체형만 '사람이 하던 일을 그대로 가져왔다'는 전제가 성립해서, 실행 횟수에 사람 기준 시간을 곱하는 계산에 뜻이 있습니다.
이번 크론 모니터링은 그 70개 안에서 한 걸음 더 들어간 결과입니다. 자격을 준 70개라고 해서 전부 실행 기록이 멀쩡한 것은 아니었습니다.
70개를 실제로 세어 보니 무엇이 나왔나?
확인 방법은 크론마다 전용 로그가 있으면 그 로그를 먼저 보고, 없으면 여러 작업이 함께 쓰는 공용 로그를 검색하고, 그것도 없으면 작업이 남긴 산출물 표시를 세는 순서였습니다. 기준 기간은 최근 30일이었습니다.
세 가지 확인 방법은 신뢰도가 다릅니다. 전용 로그는 그 크론만의 시작·종료·결과가 남아 실행 여부를 가장 분명하게 보여 줍니다. 공용 로그 검색은 여러 작업이 뒤섞인 파일에서 이름으로 걸러내는 방식이라 이름이 바뀌면 놓칠 수 있습니다. 산출물 표시를 세는 방법은 크론이 직접 남긴 흔적이 아니라 결과물의 생성 시각 같은 간접 증거를 세는 방식이라, 다른 경로로 같은 결과물이 생겨도 실행으로 잡힐 여지가 있습니다. 세 방법을 같은 신뢰도로 취급하면 안 되는 이유입니다.
결과는 셋으로 갈렸습니다. 실행 흔적이 0회인 크론이 20개, 로그 형식이 서로 달라 횟수 자체를 셀 수 없는 크론이 17개, 나머지 33개만 실행 횟수를 실제로 셀 수 있었습니다. 자격을 준 70개 가운데 절반에 못 미치는 수만 확인이 가능했다는 뜻입니다.
여기서 갈리는 두 그룹은 성격이 다릅니다. 실행 0회는 '로그를 봤고, 그 결과가 0이었다'는 확인된 사실입니다. 셀 수 없음은 '로그가 없거나 형식이 달라 애초에 셀 수 없었다'는 뜻으로, 실제로 도는지조차 알 수 없는 사각지대입니다.
크론 모니터링을 등록 목록에 기대게 되는 이유는 단순합니다. 크론이 10개 정도일 때는 사람이 하나씩 기억하고 눈으로 확인할 수 있습니다. 168개로 늘어나면 그 방식은 버틸 수 없고, '등록해 뒀으니 도는 셈'이라는 지름길을 쓰게 됩니다. 이번 조사가 보여 준 것은 그 지름길이 업무대체형 70개 중 37개에서 이미 틀렸다는 사실입니다.
이름이 확인된 크론은 어떤 것들인가?
실행 0회 20개와 셀 수 없음 17개, 합쳐 37개 가운데 이름이 남아 있던 것은 10개였습니다. 4개는 전용 로그가 있는데도 실행 0회였고, 6개는 로그 자체가 없어 셀 수 없음 쪽에 들어갔습니다.
- refresh_discovery — 전용 로그 있음, 실행 0회
- cron_content_pipeline — 전용 로그 있음, 실행 0회
- staleness_refresh~2 — 전용 로그 있음, 실행 0회
- nts_refresh — 전용 로그 있음, 실행 0회
- cron_kin_pipeline, cron_kin_pipeline~2, cron_kin_pipeline~3, cron_kin_pipeline~4 — 로그 없음, 셀 수 없음
- build_work_query_backlog — 로그 없음, 셀 수 없음
- ads_search_terms_to_backlog — 로그 없음, 셀 수 없음
실행 0회와 셀 수 없음은 같은 문제인가?
실행 0회는 확인이 끝난 상태입니다. 전용 로그가 있으니 최근 30일 동안 실행이 있었는지 물으면 답이 나오고, 그 답이 0이었을 뿐입니다. 원인을 찾는 다음 단계로 바로 넘어갈 수 있습니다 — 스케줄 자체가 잘못됐는지, 크론을 실행하는 서버가 그 시간에 꺼져 있었는지, 아니면 애초에 그 시간에 할 일이 없어서 정상적으로 아무 흔적도 안 남긴 것인지를 나눠 보면 됩니다.
세 가지 원인은 다음 조치도 다릅니다. 스케줄이 틀렸다면 시각을 고치는 것으로 끝나고, 서버가 꺼져 있었다면 그 시간대에 서버가 켜져 있는지부터 확인해야 하고, 할 일이 없어서 조용했던 것이라면 크론 자체는 문제가 없고 로그에 '이번에는 할 일 없음'이라는 흔적을 남기지 않은 설계가 문제입니다. 세 갈래를 가르기 전까지는 이 20개를 하나로 묶어 말할 수 없습니다.
셀 수 없음은 다릅니다. 질문 자체에 답할 수단이 없습니다. 로그 형식이 달라 실행 여부를 확인할 방법이 없으니, 실제로는 매일 잘 돌고 있어도 이 조사에서는 '모른다'로 남습니다. 등록 목록에는 두 그룹이 똑같이 한 줄로 보이지만, 하나는 원인을 좁힐 수 있는 문제고 다른 하나는 확인 수단부터 새로 만들어야 하는 문제입니다.
«통과»를 정답의 증거로 읽지 않는다. 통과는 «검사한 것 중 걸린 게 없다»일 뿐이다.
이 문장은 원래 화면 품질을 확인하는 규칙에서 나왔지만 크론 모니터링에도 그대로 들어맞습니다. '등록돼 있다'는 사실도 통과와 같은 종류의 착각을 부릅니다. 목록에 이름이 있다는 사실은 «검사 대상에 올랐다»는 뜻일 뿐, «잘 돌고 있다»는 증거가 아닙니다.
로그 형식을 통일하면 무엇이 바뀌나?
셀 수 없음 17개를 줄이는 방법은 원인을 하나씩 찾는 것이 아니라 로그 형식을 통일하는 것입니다. 실행 0회 20개는 크론마다 원인이 다를 수 있어 하나씩 들여다봐야 하지만, 셀 수 없음 17개는 원인이 전부 같습니다 — 확인 방법이 없다는 것 하나뿐입니다.
그래서 이 17개는 한 번에 풀리는 문제이기도 합니다. 로그 형식을 한 번 통일해 두면 그다음부터는 크론이 아무리 늘어나도 같은 방식으로 셀 수 있습니다. 사내 화면 품질 검사 규칙에서 같은 버튼·같은 카드를 여러 제품이 함께 쓰면 그 부품을 한 번만 검수해도 된다고 정리해 둔 것과 같은 구조입니다 — 개별로 대응하는 대신 공통 부분을 먼저 손보면, 그다음부터는 개수가 늘어도 확인 비용이 늘지 않습니다.
실행 기록이 있는 크론과 나란히 놓으면 무엇이 보이는가?
같은 기간 실행 기록이 멀쩡한 크론 5개를 나란히 놓아 보면 대비가 뚜렷합니다. 기술 글 1편을 쓰는 크론은 최근 30일 실행 55회, 건당 120분으로 대체 시간 110.0시간이었습니다. 리포트형 콘텐츠를 발행하는 크론은 실행 97회, 건당 90분으로 145.5시간이었습니다.
채용 사이트 공고를 수집하는 두 크론은 각각 실행 10회, 건당 20분으로 3.3시간이었고, 리드 이메일을 수집하는 크론은 실행 10회, 건당 40분으로 6.7시간이었습니다. 다섯 크론 모두 실행 횟수와 대체 시간이 로그 그대로 남아 있어, 실행 0회 20개·셀 수 없음 17개와 비교할 기준이 됩니다. 다섯 모두 근거 등급은 추정이지만, 적어도 '몇 번 돌았나'는 로그로 확인된 값입니다.
등록 목록만 보고는 왜 이 차이를 못 잡았나?
크론을 등록하는 목록 명령은 실행 시각과 명령어만 보여 줍니다. 그 크론이 지난 30일 동안 실제로 몇 번 돌았는지는 알려 주지 않습니다. 등록 목록과 실행 로그는 서로 다른 질문에 답합니다 — 하나는 '무엇을 언제 돌리기로 했나', 다른 하나는 '실제로 돌았나'입니다. 두 질문의 답이 늘 같다는 보장은 어디에도 없습니다.
그래서 크론 모니터링을 등록 목록이 아니라 로그와 산출물의 실행 흔적으로 바꿨습니다. 등록만으로는 실행이 보장되지 않기 때문입니다. 이 기준으로 다시 세자 업무대체형 70개 중 37개가 실행 0회이거나 셀 수 없음으로 나왔고, 등록 목록만 봤다면 이 차이는 그대로 묻혀 있었을 셈입니다.
질문을 바꾼 것도 도움이 됐습니다. '이 크론이 맞게 돌고 있나'는 결과가 맞는지까지 판단해야 해서 답하기 어렵습니다. 대신 '이 크론이 최근 30일 동안 흔적을 남겼나'는 로그 한 줄만 있으면 답할 수 있는 질문입니다. 더 쉬운 질문으로 바꾸자 168개 전부에 같은 기준을 적용할 수 있었고, 그 결과가 실행 0회 20개와 셀 수 없음 17개입니다.
크론 모니터링을 직접 할 때 확인할 두 가지
회사에서 여러 크론을 운영하고 있다면, 이번 크론 모니터링에서 갈린 두 그룹을 각자 다르게 다뤄야 합니다.
- 실행 0회로 확인된 크론 — 스케줄이 맞는지, 실행 서버가 그 시간에 켜져 있는지, 할 일이 없어서 정상적으로 흔적이 안 남은 것인지부터 나눠 봅니다.
- 셀 수 없음으로 남은 크론 — 원인을 찾기 전에 로그 형식부터 통일합니다. 이 상태로는 원인을 물을 수조차 없습니다.
- 확인 방법의 신뢰도 표시 — 전용 로그·공용 로그 검색·산출물 표시 중 어느 방법으로 셌는지를 숫자 옆에 같이 적어 둡니다. 방법이 다르면 같은 숫자도 믿을 수 있는 정도가 다릅니다.
이번 크론 모니터링이 끝까지 답하지 못한 질문도 남아 있습니다. 실행 0회 20개가 정말로 할 일이 없어서 조용했던 것인지, 스케줄 자체가 잘못돼 있던 것인지는 이 조사만으로는 가릴 수 없습니다. 이름이 확인된 4개(refresh_discovery·cron_content_pipeline·staleness_refresh~2·nts_refresh)부터 하나씩 원인을 나누는 일이 다음 확인 대상입니다.
168개를 처음 넷으로 가를 때는 '무엇을 셀 자격이 있나'를 물었고, 이번에는 '자격이 있다고 한 것이 실제로 확인되나'를 물었습니다. 두 질문을 한 번씩 거치고 나니 168개 중 실제로 숫자를 믿고 쓸 수 있는 크론은 33개로 좁혀졌습니다. 다음 크론 모니터링에서는 이 33개마저 다시 줄어들 수 있고, 반대로 나머지 37개 중 일부가 원인을 고친 뒤 33개 쪽으로 넘어올 수도 있습니다. 숫자는 한 번 고정되는 값이 아니라 매번 다시 세야 하는 값입니다. 크론을 여러 개 운영하면서 등록 목록과 실행 로그가 서로 다른 말을 하고 있는지 함께 확인해 보고 싶다면 상담에서 이야기를 나눌 수 있습니다.