크론 도전 처리량을 일 15건으로 증량한 이유

README에 cron 빈도를 갱신했다. 5슬롯 × 3건 = 일 15건, 도전 상한 증량 반영.

왜 README를 먼저 고쳤나

코드를 바꾸기 전에 문서를 먼저 고치는 습관이 있다. 특히 cron처럼 "언제, 얼마나 자주, 몇 건씩" 돌아가는지가 핵심인 자동화 작업에서는 README가 사실상 운영 명세서 역할을 한다. 팀원이 장애 대응할 때 코드를 뜯어보기 전에 README부터 보게 되어 있으니까.

이번 변경은 cron 실행 단위를 기존보다 늘린 것이다. 5개 슬롯에서 슬롯당 3건씩, 총 일 15건으로 도전 상한을 증량했다. 숫자 자체는 단순해 보이지만 이 한 줄 뒤에는 "이 시스템이 하루에 몇 번, 얼마나 공격적으로 동작해도 되는가"에 대한 의사결정이 담겨 있다.

슬롯 × 건수 구조를 쓰는 이유

cron 기반 자동화에서 실행량을 설계할 때 흔히 두 가지 축을 나눠서 생각한다.

이렇게 나누는 이유는 레이트 리밋이나 외부 API 쿼터를 핸들링할 때 "빈도"와 "깊이"를 독립적으로 조절할 수 있어야 하기 때문이다. 예를 들어 외부 시스템이 분당 요청 수에 제한이 있다면 슬롯 간격을 늘리고, 일 총량을 늘리고 싶다면 건수를 올리는 식으로 두 파라미터를 따로 건드릴 수 있다.

이번엔 슬롯은 5개로 유지하되 건수를 올려서 일 총량을 늘린 케이스다. 슬롯을 늘리는 게 아니라 건수를 늘렸다는 건, 실행 빈도 자체를 더 촘촘하게 가져가는 게 아니라 한 회차당 처리량을 키우는 방향을 선택한 것이다.

문서 갱신이 자동화 운영에서 갖는 의미

# 도전 cron 실행 정책
- 슬롯 수: 5
- 슬롯당 처리 건수: 3
- 일 최대 처리량: 15건

이런 내용이 README에 명시되어 있으면 좋은 점이 몇 가지 있다.

• 온콜 대응: 새벽에 이상 징후가 생겼을 때 팀원이 "오늘 최대 몇 건이 돌아야 정상인지"를 코드 안 뒤지고 바로 확인 가능
• 리뷰 맥락: PR에서 코드 변경과 함께 수치가 왜 바뀌었는지 문서로 추적 가능
• 중복 질문 차단: "이 cron 하루에 몇 번 돌아요?" 슬랙 DM 안 와도 됨

팀이 작을 때는 이런 걸 다 머릿속에 들고 다닌다. 근데 규모가 조금이라도 커지거나, 내가 자리를 비우는 순간 그 맥락은 사라진다. README 한 줄 고치는 데 30초도 안 걸리는데, 그게 나중에 팀원 한 명의 30분을 아껴준다면 ROI는 압도적이다.

도전 상한 증량, 어떤 판단이 들어갔나

"도전 상한"이라는 표현이 커밋 메시지에 명시되어 있다는 건, 이게 단순한 버그 픽스가 아니라 정책적 결정임을 뜻한다. 자동화 시스템에서 상한을 올리는 결정은 보통 아래 질문들을 검토한 뒤에 이루어진다.

• 현재 상한이 병목이 되고 있는가?
• 늘렸을 때 다운스트림 시스템이 버틸 수 있는가?
• 롤백 기준은 무엇인가?

이 판단들이 코드 어딘가에 주석으로 남아 있으면 가장 좋고, 최소한 README에 변경 시점과 수치가 기록되어 있으면 나중에 "왜 이 숫자냐"는 질문에 답할 수 있다. 이번 커밋이 그 역할을 한다.

자동화 작업은 눈에 잘 안 띈다. 잘 돌아갈 땐 아무도 보지 않고, 문제 생기면 갑자기 모두가 들여다본다. 그때 README가 제대로 살아 있으면 디버깅 시간이 반으로 줄어드는 경험을 몇 번 해봤다. 그래서 이런 작은 문서 커밋도 절대 대충 안 한다.

다음

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.