크론 스크립트 백업과 실행 권한을 문서화해 운영 불확실성을 줄였다
목차
프로덕션 환경에서 24/7 돌아가는 자동화 스크립트들의 설정을 백업하고 실행 권한 요구사항을 명확히 문서화했다.
자동화는 "불확실성"을 줄이는 작업
팀에 새로 들어온 엔지니어나 기존 팀원이 시스템을 인수받을 때, 가장 까다로운 부분은 크론 잡처럼 백그라운드에서 조용히 돌아가는 자동화다. 당사의 경우 hedvion-* 시리즈의 크론 스크립트들이 여러 데이터 처리와 동기화 작업을 담당하고 있었는데, 이 스크립트들의 위치, 정확한 실행 권한, 그리고 설정값들이 스크립트 파일 자체에만 존재하고 별도로 백업되거나 문서화되지 않은 상태였다.
이건 생각보다 위험하다. 스크립트 파일 하나가 실수로 삭제되거나, 권한이 변경되거나, 누군가 "잠깐"이라고 생각하고 수정했다가 테스트 없이 커밋하면 프로덕션 자동화가 깨진다. 그리고 그 순간엔 "어, 이게 뭐하는 스크립트지? root여야 하나?"같은 질문이 나온다.
세 가지 크론 스크립트의 백업과 권한 명시
| 스크립트 | 역할 | 주의사항 |
|---|---|---|
cron-hedvion-site-learner |
사이트 학습/분석 데이터 처리 | root 권한 필요 |
cron-hedvion-site-onboard |
신규 사이트 온보딩 자동화 | root 권한 필요 |
cron-hedvion-sites-dump |
사이트 데이터 덤프 및 백업 | root 권한 필요 |
이 세 스크립트가 모두 root 권한을 필요로 한다는 건 중요한 신호다. 보통 자동화 스크립트는 최소 권한 원칙(Principle of Least Privilege)을 따라 필요한 최소 권한만 부여하는 게 일반적인데, 세 개 모두 root가 필요하다면 그 이유가 명확해야 한다. 시스템 파일 접근? 특정 사용자 변경? 포트 바인딩? 이런 의도가 명시되지 않으면, 나중에 누군가 "이건 꼭 root여야 해?"라는 질문을 던질 때 대답하기 어렵다.
README.md에 이 요구사항을 명시함으로써, 팀원들이 크론 스케줄러를 설정할 때 실수로 낮은 권한으로 설정하는 걸 막고, 신입 엔지니어도 "아, 이건 root여야 하는구나"라고 한눈에 이해할 수 있게 했다.
"문서는 결국 운영의 보험"
자동화 시스템에서 문서화는 겉으로는 "그냥 읽을거"처럼 보이지만, 실제로는:
- 장애 복구 시간 단축: 크론 잡이 제대로 돌지 않을 때, 문서가 있으면 "아, root여야 하는데 설정이 잘못됐나" 같은 체크리스트를 빠르게 순회할 수 있다.
- 권한 감사의 명확성: 보안 감사할 때 "왜 이 스크립트는 root로 돌아?" 하는 질문에 문서로 대답할 수 있다.
- 팀 이탈 시 인수인계: 담당자가 떠날 때도 문서 하나로 모든 게 전승된다.
특히 크론 잡은 "한 번 설정하면 까먹는" 경우가 많다. 스크립트는 매일 신경 쓰지만, 크론 설정은 한 번 정해진 후론 거의 보지 않는다. 그런데 6개월 뒤 뭔가 고장 나면, "이게 왜 root로 돌지?"라는 기본 질문부터 시작하게 된다. 문서가 있으면 그 고민을 스킵할 수 있다.
또한 이런 "작은 문서화" 작업들이 팀 문화를 만든다. 한 두 개 스크립트는 신경 안 써도 되지만, 수십 개 자동화가 쌓일수록 이런 문서화가 있고 없고의 차이가 팀의 운영 난이도를 크게 좌우한다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.