감사 로그와 실제 DB 상태의 드리프트 감지 시스템 구축

감사 로그와 실제 상태의 불일치를 감지하고 진단하는 시스템을 구축했다.

감사 로그 드리프트란 무엇인가

운영 중인 서비스에서 감사 로그(audit log)는 모든 중요한 상태 변화를 기록하는 안전장치다. 사용자 정보 수정, 권한 변경, 거래 처리 같은 작업들이 발생할 때마다 "누가, 언제, 무엇을, 왜" 변경했는지를 남긴다. 그런데 문제는 시간이 지나면서 감사 로그의 기록과 실제 데이터베이스의 상태가 어긋나기 시작한다는 것이다.

예를 들어, 어떤 사용자의 상태가 감사 로그에는 "활성(active)"으로 기록되어 있는데, 실제 DB를 조회하면 "비활성(inactive)"인 경우가 생긴다. 이게 발생하는 경로는 여러 가지다. 스키마 마이그레이션 과정에서 실수로 발생할 수도 있고, 직접 DB 접근으로 인한 변경이 로그에 기록되지 않을 수도 있으며, 분산 시스템에서 일부 노드의 업데이트만 실패하는 경우도 있다. 또는 단순히 레플리케이션 지연으로 인한 일시적 불일치도 가능하다.

드리프트 진단 시스템의 필요성

이런 불일치를 방치하면 여러 문제가 연쇄적으로 발생한다. 감사 추적의 신뢰성이 떨어지고, 컴플라이언스나 보안 감시에서 맹점이 생긴다. 특히 결제 관련 데이터나 권한 정보에서 이런 일이 발생하면 재무 감사나 보안 감시 때 심각한 문제가 될 수 있다.

그래서 정기적으로 또는 온디맨드로 감사 로그와 실제 상태를 비교하는 진단 기능이 필요하다. 데이터베이스에 존재하는 모든 엔티티(사용자, 계정, 리소스 등)를 순회하면서 해당 엔티티의 현재 상태와 감사 로그에서 추적한 마지막 상태를 비교하는 방식이다.

실제 진단 로직의 구조

이번 작업에서 구축한 진단 시스템은 기본적으로 이런 흐름을 따른다.

1. 스캔 시작 (전체 엔티티 순회)
   ↓
2. 각 엔티티에 대해:
   - 현재 상태 조회 (DB)
   - 감사 로그 추적 (마지막 기록)
   ↓
3. 비교 수행
   - 상태 값 일치 확인
   - 타임스탬프 일관성 확인
   - 누락된 변경 감지
   ↓
4. 드리프트 리포트 생성
   - 불일치 항목 목록
   - 원인 분류 (사람의 실수 vs 시스템 버그)
   - 해결 방안 제시

특히 대량의 엔티티를 처리할 때는 배치 스캔 방식을 쓰고, 성능 저하를 피하기 위해 비교 작업 자체를 비동기로 처리한다. 감사 로그는 불변(immutable)이어야 한다는 원칙이 있으므로, 진단 결과도 별도의 드리프트 레코드로 남겨서 나중에 조사하거나 통계를 낼 수 있게 한다.

회고와 배운 점

이런 진단 시스템을 만들면서 느낀 것은, 감사 추적을 단순히 "기록한다"고 생각하면 안 된다는 것이다. 로그를 남기는 것도 중요하지만, 그 로그가 실제로 신뢰할 수 있는지를 정기적으로 검증하는 메커니즘이 있어야 한다. 마치 좌표를 계속 기록하는 것도 중요하지만, 가끔씩 실제 위치와 기록된 위치를 확인해야 하는 것처럼 말이다.

또 하나는, 드리프트 진단의 결과를 어떻게 활용할지도 미리 생각해야 한다는 것. 단순히 "문제 있음"이라고 보고하는 것보다, 어떤 범주의 문제인지(의도된 변경인지, 버그인지, 레플리케이션 지연인지) 분류하고, 각 경우에 맞는 처리 방식을 제안할 수 있어야 한다. 그래야 운영팀이 실제로 대응할 수 있다.