Git에 저장된 설정과 실제 운영 설정이 달라지는 문제: Configuration Drift 탐지 설계

Git에 저장된 설정과 실제 운영 설정이 달라지는 문제: Configuration Drift 탐지 설계

설정의 세계에서 벌어지는 보이지 않는 위험

개발팀에서 일하다 보면 깃에 저장된 코드는 완벽한데 실제 서버에서만 오류가 발생하는 상황을 마주하게 됩니다. 누군가 급하게 서버에 접속해 설정을 직접 수정했거나 예상치 못한 시스템 업데이트로 인해 기본값이 바뀌었기 때문입니다. 이러한 현상을 설정 표류라고 부릅니다. 깃에 기록된 설정값과 실제 운영 환경의 설정이 서로 달라지는 문제를 의미합니다.

현대의 많은 기업이 인프라와 설정을 코드로 관리하는 방식을 채택하고 있습니다. 모든 변경 사항을 이력으로 남기고 안전하게 배포하기 위해서입니다. 하지만 운영 환경의 특성상 긴급 장애 대응이나 임시 테스트를 위해 수동으로 설정을 건드리는 유혹에 빠지기 쉽습니다. 이렇게 발생한 작은 차이가 나중에는 감당하기 힘든 거대한 시스템 장애로 이어지곤 합니다.

설정 표류가 발생하는 원인과 유형 살펴보기

설정이 달라지는 이유는 다양합니다. 가장 흔한 경우는 긴급 장애 복구 과정에서 발생합니다. 새벽에 서버가 다운되었을 때 개발자는 원인을 분석할 겨를 없이 당장 서버를 살리기 위해 설정 파일을 직접 수정합니다. 문제는 상황이 해결된 후 이 수정 사항을 깃에 반영하는 것을 잊어버린다는 점입니다.

운영 환경의 특성에 따른 자연스러운 변화도 원인이 됩니다. 운영체제가 자동으로 업그레이드되면서 설정 파일의 기본값이 바뀌거나 서드파티 서비스의 정책 변경으로 인해 환경 변수가 달라질 수 있습니다. 이러한 변화는 인간의 개입 없이 일어나기 때문에 더욱 알아채기 어렵습니다.

설정 표류는 크게 세 가지 유형으로 나눌 수 있습니다.

• 명시적 표류는 사람이 직접 서버에 로그인하여 파일을 수정하거나 데이터베이스 값을 바꾼 경우입니다.
• 암시적 표류는 시스템이나 패키지 관리자가 자동으로 설정 파일을 덮어쓰거나 변경하는 경우입니다.
• 환경별 분기 표류는 개발, 스테이징, 운영 환경 간의 미세한 차이를 인정하지 않고 잘못된 설정이 전파될 때 발생합니다.

실생활에서 적용할 수 있는 설정 표류 탐지 방법

설정 표류를 막는 가장 좋은 방법은 정기적으로 깃의 상태와 실제 서버의 상태를 비교하는 자동화 시스템을 구축하는 것입니다. 수동으로 서버마다 접속해 확인할 수는 없는 노릇이므로 도구의 힘을 빌려야 합니다.

가장 널리 쓰이는 접근법은 CI 파이프라인이나 감시 도구를 활용하는 것입니다. 예를 들어 테라폼이나 앤서블 같은 인프라 관리 도구는 실제 인프라의 상태를 미리보기 기능으로 조회할 수 있습니다. 이를 통해 깃에 정의된 코드와 실제 서버의 설정이 어떻게 다른지 시각적으로 확인할 수 있습니다.

가벼운 스크립트를 주기적으로 실행하는 방법도 실용적입니다. 정해진 시간에 깃 저장소의 설정 파일과 운영 서버의 설정 파일을 다운로드하여 체크섬을 비교하거나 차이점을 분석하는 파이썬 스크립트를 윈도우나 리눅스의 스케줄러에 등록해 둘 수 있습니다. 차이점이 발견되면 즉시 슬랙이나 이메일로 담당자에게 알림이 가도록 설정하는 것이 핵심입니다.

흔히 갖는 오해와 진실

설정 관리에 대해 사람들이 가장 많이 하는 오해 중 하나는 한번 인프라를 코드로 구축해 놓으면 수동 수정이 원천적으로 불가능해진다는 믿음입니다. 깃허브 액션이나 깃랩 CI를 도입했다고 해서 누군가 서버에 직접 접속해 파일을 고치는 것을 시스템이 막아주지는 않습니다. 도구는 관리의 편의성과 이력을 제공할 뿐 운영자의 행동까지 강제하지는 못합니다.

또 다른 오해는 프로덕션 서버에는 개발자가 접근할 권한이 없으므로 표류가 발생하지 않을 것이라는 생각입니다. 개발자가 아니더라도 시스템 관리자나 보안 담당자 또는 자동화된 스크립트가 설정을 바꿀 수 있습니다. 따라서 권한을 통제하는 것만큼이나 바뀐 내용을 탐지하는 체계를 만드는 것이 중요합니다.

모든 설정을 완벽하게 코드로만 관리해야 한다는 압박감도 버려야 합니다. 때로는 보안 인증서나 동적으로 생성되는 비밀번호처럼 깃에 올릴 수 없는 민감한 정보가 존재합니다. 이러한 값들은 별도의 안전한 저장소에서 관리되어야 하며 일반 설정 파일과 분리해서 표류 여부를 감시해야 합니다.

비용 효율적으로 탐지 시스템 구축하기

완벽한 감시 체계를 만드느라 과도한 예산과 시간을 들이는 것은 비효율적입니다. 기업의 규모와 시스템의 중요도에 맞게 단계를 나누어 접근하는 것이 좋습니다. 처음부터 비싼 유료 엔터프라이즈 도구를 도입하기보다는 오픈소스나 기존에 사용 중인 도구를 활용하는 것이 현명합니다.

이미 깃허브나 깃랩을 사용하고 있다면 해당 플랫폼이 제공하는 기본 기능과 액션을 활용하는 것만으로도 비용을 크게 아낄 수 있습니다. 정기적으로 설정을 비교하는 잡을 무료 클라우드 함수의 크론 기능과 연동하여 서버 유지비 없이 구현할 수도 있습니다.

구축 비용을 줄이는 실용적인 방법들을 정리해 보았습니다.

• 서버에 직접 에이전트를 설치하는 방식 대신 주기적으로 원격에서 상태를 조회하는 가벼운 스크립트를 활용합니다.
• 모든 설정 파일을 감시 대상에 넣지 말고 장애 시 영향도가 큰 핵심 설정 파일 위주로 먼저 적용합니다.
• 새로운 도구를 직접 개발하기보다 이미 검증된 오픈소스 인프라 감사 도구를 커스터마이징하여 사용합니다.
• 알림을 받을 때 너무 사소한 공백이나 주석 변경까지 보고받지 않도록 필터링 규칙을 세밀하게 조정합니다.

현명한 운영을 위한 전문가의 조언

설정 표류를 관리하는 일은 기술의 문제라기보다는 문화와 프로세스의 문제입니다. 시스템이 아무리 경고를 보내도 개발팀과 운영팀이 이를 무시한다면 아무런 소용이 없습니다. 경고가 울렸을 때 왜 설정이 틀어졌는지 원인을 추적하고 다시는 수동 수정을 하지 않도록 프로세스를 개선하는 피드백 루프가 반드시 필요합니다.

긴급 상황에서의 수동 수정을 완전히 금지할 수는 없습니다. 대신 수동 수정을 허용하되 수정한 사람은 반드시 일정한 시간 내에 그 내용을 깃에 반영하여 코드로 동기화해야 한다는 규칙을 세우는 것이 현실적입니다. 이를 위한 사후 기록 문화를 정착시키는 것이 장기적으로 시스템의 안정성을 높이는 지름길입니다.

자주 묻는 질문

설정 표류 탐지 도구를 도입할 때 가장 많이 나오는 질문들을 모았습니다.

서버가 수십 대인데 모든 서버의 설정을 일일이 비교해야 하나요

모든 서버를 일일이 비교할 필요는 없습니다. 동일한 역할을 하는 서버 그룹 단위로 대표 서버 하나를 지정해 검사하거나 배포된 이미지 자체의 무결성을 확인하는 방식으로 효율성을 높일 수 있습니다.

자동으로 설정 표류를 교정하는 기능도 켜두는 것이 좋은가요

자동 교정 기능은 매우 강력하지만 자칫 잘못하면 정상적으로 작동 중인 서비스의 설정을 덮어써서 장애를 유발할 수 있습니다. 초기에는 탐지와 알림 기능만 사용하여 사람이 직접 확인하고 수정하도록 하고, 시스템의 신뢰도가 충분히 쌓였을 때 자동 교정을 도입하는 것을 권장합니다.

보안상 민감한 정보가 포함된 설정은 어떻게 처리해야 하나요

비밀번호나 API 키 같은 민감한 정보는 깃에 평문으로 저장하면 안 됩니다. 별도의 비밀 관리 도구를 사용하고 설정 표류 탐지 시에도 암호화된 값이나 해시값만 비교하는 방식으로 보안을 유지해야 합니다.