크론 작업을 코드로 버전 관리해 운영 추적성을 확보한 방법

운영 자동화는 우리 시스템의 등뼈다. 그런데 그 등뼈를 관리하는 방식이 종종 미흡했다. 이번에 brainstorm-auto 같은 크론 작업들을 코드 저장소에서 버전 관리하도록 정비했고, 그 결과가 생각보다 크다.

왜 이게 필요했는가

시스템 운영하다 보면 /etc/cron.d나 사용자 crontab에 수십 개의 작업들이 쌓인다. 백업 스크립트, 데이터 정산 작업, 헬스체크 등등. 어느 날 문제가 생기면 서버에 직접 들어가서 "어? 이 작업이 뭐였더라?" 하고 헤맨다. 가장 큰 문제는 세 가지다.

첫째, 변경 이력이 없다. 크론 작업을 수정한 사람이 누구인지, 언제 바뀌었는지 알 수 없다. 버그가 생겼을 때 "최근에 뭘 만졌나?" 하는 게 불가능하다.

둘째, 재해 복구가 어렵다. 서버가 새로 뜨거나 디스크가 부패했을 때, 모든 크론 설정을 손으로 다시 입력해야 한다. 빼먹기 쉽다.

셋째, 감사 추적성이 없다. "정산 자동화를 언제부터 야간 2시에 돌리기로 했어?" 같은 질문에 대답할 수 없다. 운영 의사결정의 기록이 남지 않는다.

코드로 정리하기

_lib/cron-brainstorm-auto 파일을 만들고 brainstorm-auto 크론 작업의 정의를 거기에 넣기로 했다. 단순하지만 효과는 크다.

실제로 배포할 때는 이 파일의 내용을 /etc/cron.d/에 동기화하는 방식으로 진행한다. 즉, 운영진이 직접 손댈 여지를 최소화하고, 모든 변경이 코드 형태로 기록되고 리뷰를 거친다.

이게 왜 "chore"인가

커밋 타입을 chore(ops):로 한 이유는 새로운 기능을 추가한 게 아니기 때문이다. 기존 크론 작업은 그대로 움직인다. 다만 그것을 어떻게 관리할 것인가의 방식을 개선한 것이다. 이걸 구분하는 게 중요하다.

운영 업무는 눈에 띄는 신기능이 아니라 작은 정비들이 누적돼서 큰 안정성으로 만든다. "이런 건 나중에 해도 된다"고 미뤄왔던 게 장애가 났을 때 돌이킬 수 없는 손실이 된다. 그래서 팀으로는 이런 ops chore를 우선순위 있게 밀어붙이는 게 중요하다.

배운 점

이번 작업을 하면서 느낀 건 기반시설(infrastructure)도 코드다라는 거다. 응용 코드만큼이나 충분히 리뷰되고 테스트되고 추적되어야 한다. 특히 팀의 규모가 커질수록 더 그렇다.

비슷한 패턴들이 있다. nginx 설정, 데이터베이스 마이그레이션, 방화벽 규칙 등도 모두 버전 관리와 자동 배포의 대상이 될 수 있다. 우리는 이걸 infrastructure-as-code라고 부른다. 단순한 유행어가 아니라, 운영팀의 부담을 줄이는 실질적인 방법이다.

앞으로 남은 자동화 작업들도 이 패턴으로 옮길 계획이다. 하나씩 정리하다 보면 결국 "우리 시스템이 정확히 뭘 하는지" 한눈에 볼 수 있는 운영 대시보드가 완성될 거다.

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

• 외장SSD 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

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