운영 서버 git 백업 자동화와 로또 발행 정책 평일·주말 기준 재조정
목차
내부 운영 서버 관리를 좀 더 체계적으로 다루기 위해 git 백업을 자동화하고, 동시에 lotto 발행 정책의 목표치를 평일/주말 기준으로 재조정하는 작업을 했다.
git 백업 자동화로 운영 환경 안정성 확보
회사 규모가 커지면서 여러 서버를 운영하게 되는데, 이때 놓치기 쉬운 게 "운영 서버의 설정이나 데이터를 어떻게 관리할 것인가"라는 문제다. 우리도 처음엔 각 운영자가 필요한 파일을 로컬에 백업하거나 외부 저장소에 저장하는 식으로 대충 넘어갔는데, 이렇게 하면 몇 가지 문제가 생긴다.
첫째, 변경 이력 추적이 어렵다. 누가, 언제, 무엇을 바꿨는지가 명확하지 않으면 나중에 장애가 발생했을 때 원인 파악이 힘들다. 둘째, 여러 사람이 같은 파일을 다루는 과정에서 충돌이나 중복 수정이 발생할 수 있다. 셋째, 재해 복구 시나리오에서 정말 최신 상태가 맞는지 확신할 수 없다.
이번 작업에선 git을 운영 서버 설정 관리의 중심으로 삼기로 했다. git에 commit하면 커밋 로그에 자동으로 "누가", "언제", "무엇을" 남게 되고, 필요하면 특정 시점으로 복구할 수 있다. 팀원들도 같은 저장소를 바라보므로 중복 작업이나 동시 충돌을 사전에 방지할 수 있다.
.gitignore를 정리한 것도 같은 맥락이다. 운영 환경엔 민감한 설정, 임시 로그, API 키 같은 것들이 있는데, 이런 것들을 실수로 커밋하는 걸 방지해야 한다. README도 함께 업데이트해서 팀원들이 "이 저장소는 뭘 하는 곳이고, 어떤 파일을 조심해야 하고, 어떻게 백업하는지"를 명확히 알 수 있도록 했다.
lotto 발행 정책: 평일/주말 비율 조정의 배경
운영 과정에서 발견한 또 다른 이슈가 lotto 발행 목표치였다. 원래는 일정한 기준으로 발행하고 있었는데, 실제 운영 데이터를 분석해보니 평일과 주말의 사용 패턴이 크게 다르다는 걸 알 수 있었다.
주말에는 사용자 트래픽이 더 몰려 있고, 이에 따라 lotto 발행도 더 적극적으로 해야 사용자 만족도를 유지할 수 있다. 그래서 평일 1개, 주말 3개라는 기준을 설정했다. 이건 단순한 숫자가 아니라, 팀의 운영 역량, 사용자 수요, 비즈니스 목표를 모두 고려한 합의점이다.
이런 변경은 보통 몇 사람이 "요청"하는 게 아니라, 운영 데이터를 함께 보면서 "지금 이 수준이 맞다"는 걸 팀이 함께 인식하게 되는 과정에서 나온다. 그래서 변경사항을 커밋 메시지로 명확히 남기고, README 같은 문서에도 반영하는 게 중요하다. 나중에 신규 팀원이 "왜 이 기준이에요?"라고 물었을 때 "아, 이건 트래픽 분석 결과에 기반한 결정이구나"라고 이해할 수 있게 말이다.
| 항목 | 평일 | 주말 |
|---|---|---|
| 발행 목표 | 1개 | 3개 |
| 발행 주기 | 매일 | 매일 |
| 조정 근거 | 일관성 유지 | 트래픽 대응 |
운영 스크립트 정리: 자동화 도구들의 일원화
변경 파일들을 보면 _lib 디렉토리의 여러 유틸 스크립트가 함께 정리된 걸 알 수 있다:
- add-indexnow.sh: 검색 엔진 색인 처리
- ensure-build-ads-deps.sh: 광고 관련 의존성 빌드
- gsc_stats.py, gsc_submit.py: 검색 콘솔 통계 수집 및 제출
각 스크립트가 제각각 만들어졌을 때는 관리가 산만했을 거다. 근데 이번에 git 백업 프레임워크 안으로 모두 끌어들이면서, "이 스크립트들은 뭘 하는 건지", "어떤 빈도로 실행되는지", "상호 의존성이 있는지" 같은 걸 문서로 명시할 수 있게 됐다.
운영 자동화가 복잡해질수록 "이건 어디서 실행되고, 이건 언제 실행되지?"라는 질문이 많아진다. git 저장소 + README 조합이면 이런 질문들의 답이 한 곳에 집중된다. 그리고 스크립트를 수정할 때도 "이 변경이 다른 곳에 영향을 주는가"를 더 쉽게 판단할 수 있다.
회고: 운영 체계가 코드처럼 진화해야 한다
이 작업을 하면서 느낀 건, 운영 환경 관리도 사실 소프트웨어 개발과 다를 바 없다는 거다. 버전 관리, 문서화, 변경 추적, 팀 협업—이 모든 게 필요하다. 우리가 애플리케이션 코드에 git을 쓰고 코드 리뷰를 하는 이유가, 운영 설정에서도 동일하게 적용된다.
특히 팀이 커질수록, "왜 이렇게 설정했는가"라는 컨텍스트를 남기는 게 얼마나 중요한지 실감한다. 평일 1개, 주말 3개라는 기준도, 새로운 팀원이 와도 깃 이력과 문서를 통해 "아, 이건 이런 이유로 이렇게 설정된 거구나"라고 바로 이해할 수 있는 환경을 만드는 게 운영 효율성의 핵심이다. 그리고 나중에 정책 변경이 필요할 때도, 이전 결정의 배경을 알고 있으면 훨씬 더 신중하고 데이터 기반의 결정을 내릴 수 있다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.