운영 서버 설정 드리프트 줄이는 GitOps 점검 루틴

1. 문제 정의: 코드가 같은데 운영 결과가 다를 때

지난달 금요일 저녁 배포에서 같은 커밋이 스테이징에서는 정상인데 운영에서만 결제 콜백이 지연되는 일이 있었습니다. 처음엔 외부 PG 응답 문제로 봤지만, 실제 원인은 운영 인그레스의 타임아웃 값이 수동 수정으로 바뀌어 있던 것이었습니다. 코드 저장소에는 없는 변경이라 로그만 따라가면 원인을 놓치기 쉬웠고, 담당자가 바뀐 뒤에는 “누가 언제 바꿨는지”도 바로 확인되지 않았습니다. 장애 당일에도 온콜 엔지니어는 애플리케이션 로그를 먼저 뒤졌고, 플랫폼 담당자는 네트워크 정책을 의심해 서로 다른 방향으로 한 시간을 소모했습니다. 이런 상황이 반복되면 장애 자체보다 팀 신뢰가 먼저 무너집니다. 설정 드리프트 대응의 목표는 완벽한 자동화가 아니라, 배포 전에 차이를 보이게 만들고 장애 시간 안에 되돌릴 수 있는 기준선을 유지하는 데 있습니다.

2. 판단 기준과 원인: 무엇을 드리프트로 볼 것인가

실무에서 흔한 실패는 모든 설정 차이를 동일하게 취급하는 것입니다. 저희는 드리프트를 세 등급으로 나눴습니다. 첫째는 즉시 복구가 필요한 보안·네트워크 정책, 둘째는 성능에 영향 주는 리소스 한도와 캐시 정책, 셋째는 일시 허용 가능한 운영 편의 설정입니다. 이 분류를 두지 않으면 알림은 많아지고 실제 대응은 늦어집니다. 원인도 대부분 비슷합니다. 긴급 장애 대응 중 수동 핫픽스가 커밋으로 환원되지 않거나, 팀별 템플릿 버전이 달라서 동일 서비스라도 선언 파일이 미세하게 갈립니다. 여기에 릴리스 직전 임시 우회 설정이 남아 다음 배포까지 이어지는 경우도 많습니다. 따라서 핵심 판단 기준은 “사용자 영향도”와 “복구 난이도” 두 축으로 단순화해야 합니다. 그래야 야간 온콜에서도 우선순위를 빠르게 합의할 수 있고, 다음날 회고에서도 왜 그 순서로 조치했는지 설명이 명확해집니다.

3. 실행 절차: 선언형 기준선과 비교 리포트 분리 운영

운영 절차는 복잡한 도구보다 흐름이 선명해야 합니다. 먼저 모든 환경의 기준 설정을 단일 저장소에 선언형으로 관리하고, 서비스별로 baseline 브랜치를 둬 승인된 상태를 고정합니다. 다음으로 배포 파이프라인에서 실제 클러스터 상태를 스냅샷으로 수집해 기준선과 비교한 리포트를 생성합니다. 여기서 중요한 점은 자동 복구를 바로 걸지 않는 것입니다. 저희는 2주 동안 탐지 전용으로 돌려 오탐 패턴을 먼저 정리했고, 그 뒤 1등급 항목만 자동 복구를 허용했습니다. 실제로 이 단계 분리만으로 야간 배포 중 롤백 결정 시간이 크게 줄었습니다. 또한 드리프트 리포트를 슬랙 알림으로만 끝내지 않고 PR 코멘트로 남겨, 다음 배포 전에 원인과 수정 커밋이 연결되도록 만들었습니다. 체크 포인트도 명시했습니다. 리포트에는 변경 키, 이전값, 현재값, 영향 서비스, 조치 담당자 다섯 항목이 없으면 실패 처리해, 알림은 적더라도 바로 행동 가능한 정보만 남기도록 강제했습니다.

4. 운영 체크리스트와 주의사항: 자동화보다 변경 통제가 먼저

운영 체크리스트는 짧아야 지켜집니다. 배포 전에는 기준선 갱신 PR 승인자 2인 규칙, 배포 후에는 30분 내 드리프트 리포트 확인, 주간 리뷰에서는 반복 항목 상위 3개 원인 제거를 고정 의제로 두는 식입니다. 특히 자동 복구는 “가능하다”보다 “되돌려도 안전하다”가 기준이어야 합니다. 데이터 저장 경로나 트래픽 라우팅처럼 영향 범위가 큰 항목은 자동 복구 대상에서 제외하고, 사람이 확인 후 적용하도록 남겨 두는 편이 안전했습니다. 마지막으로 감사 로그를 별도 보관해 변경 주체와 시간을 남기면 책임 추적이 아니라 학습 자료로 활용할 수 있습니다. 저희 팀은 월말에 드리프트 다발 서비스 하나를 정해 40분짜리 개선 세션을 열고, 다음 달 알림 수와 MTTR 변화를 같이 봅니다. 이때 수정 건수보다 재발 건수를 우선 지표로 삼아 과잉 수정도 같이 통제합니다. 드리프트 대응은 도구 도입으로 끝나지 않고, 팀이 같은 기준으로 변경을 승인하고 복구하는 운영 습관에서 성패가 갈립니다.