장애가 발생했습니다. 원인을 찾으려고 합니다. 그런데 어디서부터 시작해야 할지 모릅니다. 최근에 무엇이 바뀌었는지 알 수 없기 때문입니다.
이 상황은 많은 시스템에서 실제로 벌어지고 있습니다.
추적성이란 무엇인가
시스템 운영에서 추적성(traceability)은 언제, 누가, 무엇을, 왜 바꿨는지를 나중에 확인할 수 있는 능력입니다.
코드 변경은 Git으로 추적합니다. 그러나 운영 환경의 변경은 훨씬 넓습니다.
- 서버 설정 변경
- 환경 변수 수정
- 데이터베이스 스키마 변경
- 인프라 리소스 추가/삭제
- 외부 연동 설정 변경
이 중 Git으로 추적되는 것은 얼마나 될까요? 대부분의 운영 환경에서 이런 변경은 담당자가 직접 서버에 접속해 수작업으로 처리하고, 기록은 남지 않습니다.
추적성 부재의 비용
추적성이 없는 환경에서 장애가 나면 원인 파악 자체가 어렵습니다.
세 시간 전에 무언가 바뀐 것 같은데, 정확히 무엇인지 모릅니다. 담당자들에게 물어봐도 "저는 건드리지 않았다"는 대답만 돌아옵니다. 로그를 뒤져봐도 변경 이력은 없고 에러 메시지만 있습니다.
이 상황에서 원인을 찾는 유일한 방법은 추측과 시도입니다. 시간이 걸리고, 장애가 길어집니다.
추적성 부재의 비용은 장애 시에만 나타나지 않습니다.
감사 대응. 공공기관은 주기적인 보안 감사와 시스템 감리를 받습니다. "이 설정은 언제 바뀌었고 누가 승인했나요?"라는 질문에 답할 수 없으면 감사 지적을 받습니다.
온보딩 비용. 새 담당자가 시스템을 인수인계 받을 때, 현재 상태와 변경 이력이 없으면 처음부터 파악해야 합니다. 수개월이 걸리기도 합니다.
의존성 파악. 시스템 A를 변경하면 시스템 B에 영향을 줄 수 있습니다. 변경 이력이 없으면 어떤 변경이 어떤 영향을 미쳤는지 알 수 없습니다.
추적 가능한 운영 구조 설계
추적성을 확보하기 위한 핵심 원칙입니다.
Infrastructure as Code(IaC). 서버 설정, 인프라 구성을 코드로 관리합니다. 코드가 변경되면 Git에 기록이 남습니다. 누가 언제 무엇을 바꿨는지 추적 가능합니다.
변경은 자동화된 경로를 통해. 담당자가 직접 서버에 접속해 변경하는 방식을 줄입니다. 파이프라인이나 자동화 도구를 통한 변경은 기록이 남습니다.
모든 변경에 이유를 기록. 코드 커밋 메시지, 배포 티켓, 변경 요청서에 왜 이 변경을 하는지 기록합니다. 기술적 변경만 기록하고 이유는 기록하지 않으면, 나중에 맥락을 복원하기 어렵습니다.
변경 이력과 장애 이력의 연결. 특정 시점에 어떤 변경이 있었는지, 그 이후 장애가 발생했는지를 연결해서 볼 수 있어야 합니다.
현실적인 시작점
완벽한 추적 시스템을 갖추기 어렵다면, 가장 먼저 해야 할 것은 변경 로그입니다.
운영 환경에서 발생한 모든 변경을 간단한 형식으로 기록합니다. 날짜, 변경 내용, 담당자, 이유. 엑셀이든, 위키든, 전용 도구든 형식은 나중에 개선할 수 있습니다. 기록을 시작하는 것이 먼저입니다.
추적성은 규제를 위한 것이 아닙니다. 장애 원인을 빠르게 찾고, 반복을 막고, 시스템을 다음 담당자에게 안전하게 넘기기 위한 것입니다.