SEO 메타데이터 검증 크론을 코드로 버전 관리하기 시작했다

SEO 메타데이터 검증 크론 작업의 설정을 코드 저장소에 명시적으로 추적하는 작업을 했다. 자동화 작업(chore)이라고 표기했지만, 사실 운영 안정성과 팀 커뮤니케이션에 꽤 중요한 변경이었다.

자동화 작업도 추적 대상이다

처음에는 "이게 뭐 하는 일인가" 싶었다. 크론은 서버에 설정되어 있으니, 굳이 git 저장소에 명시할 필요가 있나 하는 마음이었다. 하지만 팀 내에서 "어떤 크론들이 돌아가는가", "언제 언제 실행되는가"를 물어올 때마다 답하기 힘들었다. 서버 설정이 소스 코드와 분리되어 있으면 이런 불일치가 생긴다.

특히 자동화 작업은 누가 언제 시작했는지, 현재 설정은 뭔지 기록이 중요하다. 팀원이 인수인계받을 때, "예전부터 있던 거라 정확히 뭐 하는지 모르겠어요"라는 상황을 피할 수 있다. 깃 히스토리만 봐도 작업 의도와 변경 경력이 남으니까.

02:00 KST라는 선택

오전 2시는 실제로는 가장 트래픽이 적은 시간대다. 일반적으로 크론 작업들—특히 I/O 집약적인 메타데이터 검증 같은 일은—피크 타임을 피해서 스케줄한다.

우리는 비피크를 선택했다. 메타데이터 검증은 "지금 즉시 필요한" 작업이라기보다 "정기적으로 신뢰도를 확인하는" 성질이니까. 만약 실시간성이 중요했다면 다른 시간대를 고려했을 것.

설정을 코드로 표현하는 이유

이 변경의 핵심은 seo-monitor/cron-hedvion-meta-check 라는 파일을 추가하고 그것을 버전 관리하기로 결정한 것이다. Infrastructure as Code(IaC) 패러다임이 자동화 작업까지 확장된 셈이다.

장점:
- 누가 언제 어떤 의도로 변경했는지 추적 가능
- 배포 시 설정 검증 및 테스트 가능
- 여러 환경(dev/staging/prod)의 설정을 명확히 분리 가능
- 팀 온보딩 시 "자동화된 작업 목록"을 일목요연하게 설명 가능

반대로, 서버에만 설정하면:
- 실행 중인 크론과 코드 간 싱크가 깨질 수 있음
- 누군가 손으로 crontab을 수정했을 때 기록 남지 않음
- 재해복구 상황에서 "어떤 크론이 필요했지?"를 찾기 어려움

회고: 자동화 작업도 문서화다

이 작업을 하면서 든 생각은, "자동화되는 일일수록 투명하게 관리해야 한다"는 것이다. 자동으로 돌아가는 게 편하지만, 누군가는 그 자동화를 이해하고 유지보수해야 하니까.

팀에서 새로운 크론 작업이 추가될 때마다, 이제는 꼭 git에 등록하고 리뷰를 받도록 하는 패턴을 만들 생각이다. 작은 설정 파일 하나지만, 그게 팀 전체의 시스템 이해도를 높인다.

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

• 커피머신 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

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