누가·언제·무엇을 — 감사로그와 백업의 자리

신진형 · 에스엘파워 · 2026.06.17

“이 데이터 누가 바꿨어?”라는 질문은 언제나 사고가 난 다음에 옵니다. 그때 답할 수 없으면 이미 늦은 것입니다. 감사로그와 백업은 평소엔 아무 일도 안 하는 것처럼 보이다가, 딱 한 번 필요한 순간에 프로젝트를 통째로 구합니다. 보험과 똑같습니다. 그래서 둘 다 “기억나면 남기는 것”이 아니라 “처음부터 자동으로 굴러가는 것”이어야 합니다. 이 글은 그 두 가지를 어떻게 자동으로 만들고, 무엇을 빠뜨려 한 번 데었는지에 대한 기록입니다.

용어 정리 — 감사로그란 무엇인가

먼저 말부터 맞추겠습니다. 비슷해 보이는 개념이 섞여 있어 헷갈리기 쉽습니다.

감사로그는 손으로 남기면 반드시 빠진다

가장 흔한 실수는 감사로그를 각 기능마다 “기억나면” 남기는 것입니다. 이렇게 하면 거의 확실하게 절반은 빠집니다. 새 기능을 만들 때마다 “아, 여기 로그 남겨야지”를 매번 기억해야 하는데, 사람은 잊습니다. 특히 급할 때 더 잊습니다. 그 결과는 잔인합니다 — 정작 추적이 절실한 그 데이터에만 로그가 없습니다.

그래서 SL.AIMS는 감사로그를 횡단 관심사로 다뤘습니다. 개별 기능이 신경 쓰는 게 아니라, 모든 요청이 통과하는 공통 길목에 기록 장치를 한 겹 깔아 둔 것입니다. 데이터를 만들거나 고치는 작업이면 “누가(작성자) · 언제 · 무엇을”이 자동으로 따라 붙습니다. 개발자가 의식하지 않아도, 새 모듈을 만들면 감사 기록은 공짜로 딸려 옵니다.

공통 길목 패턴: 모든 변경 요청이 한 인터셉터를 통과하게 두면, 거기서 "누가·언제·무엇을"을 자동으로 붙입니다. 새 기능을 만들어도 감사 기록은 따라옵니다 — 사람이 매번 기억할 필요가 없습니다.

버전 추적도 일종의 접근 기록이다

감사로그가 “데이터가 어떻게 바뀌었나”의 기록이라면, 그 사촌 격으로 “코드가 어떤 버전으로 올라갔나”의 기록이 있습니다. 운영(여기서는 개발 서버) 환경에서 **“지금 도는 코드가 정확히 어느 버전이냐”**는 의외로 자주 묻게 되는 질문입니다. 배포가 제대로 됐는지, 방금 그 버그가 이미 고쳐진 버전인지 확인하려면 답이 있어야 합니다.

그래서 헬스 체크(시스템이 살아 있는지 확인하는 점검 경로)에서 현재 빌드의 버전 식별자를 돌려주게 했습니다. 배포 스크립트는 배포 직후 그 값을 읽어 “내가 올린 버전이 맞는지” 검증하고, 안 맞으면 자동으로 직전 빌드로 되돌립니다(롤백). “무엇이 언제 올라갔는가”를 기록하고 검증하는 일도, 넓게 보면 운영 추적의 한 부분입니다.

배포 안전 흐름 (예시)

배포 전 — 현재 멀쩡한 빌드를 “직전 버전”으로 따로 보관해 둡니다(되돌릴 곳을 미리 마련).
배포 — 새 빌드를 올립니다.
검증 — 헬스 체크가 돌려주는 버전 식별자가 내가 올린 것과 일치하는지 확인합니다.
분기 — 일치하면 통과. 안 맞거나 시스템이 응답을 못 하면 자동으로 직전 버전으로 롤백합니다.

방식	새 기능 만들 때	결과
기능마다 손으로 로그	매번 “로그 남기기”를 기억해야 함	바쁠 때 빠짐 → 정작 필요한 데 로그 없음
공통 길목에서 자동 기록	아무것도 안 해도 따라옴	빠짐 없음 (단, 경계 목록은 관리)

감사로그가 답해 주는 질문들

감사로그를 왜 그렇게까지 챙기는지는, 그것이 답해 주는 질문을 보면 분명해집니다. 평소엔 쓸모없어 보이지만, 막상 필요한 순간에는 이 질문들에 답할 수 있느냐가 프로젝트의 신뢰를 가릅니다.

“이 값 누가 바꿨어?” — 결재 금액이 이상하다, 권한이 누군가에게 잘못 부여됐다. 누가·언제 손댔는지 기록이 없으면 추궁할 대상도, 원인도 못 찾습니다.
“언제부터 이랬어?” — 변경 시각이 찍혀 있으면 “그 배포 직후부터”처럼 시점을 좁힐 수 있습니다. 디버깅의 출발점이 됩니다.
“되돌릴 수 있어?” — 무엇이 어떻게 바뀌었는지 알아야 안전하게 되돌립니다. 기록이 없으면 되돌리는 것 자체가 새로운 도박이 됩니다.
“규정상 남겨야 하는데?” — 업무 시스템은 종종 “누가 무엇을 승인·열람했는가”의 기록 보존 의무를 집니다. 이건 편의가 아니라 요건입니다.

한 가지 구분을 짚고 넘어가겠습니다. 감사로그와 접근로그는 비슷하지만 다릅니다. 접근로그는 “누가 무엇을 열어 봤는가”(조회·열람)의 기록이고, 감사로그는 “누가 무엇을 바꿨는가”(생성·수정·삭제)의 기록입니다. 둘은 답하는 질문이 다릅니다 — “이 민감 정보를 누가 들여다봤지?”는 접근로그가, “이 값이 왜 이렇게 됐지?”는 감사로그가 답합니다. 업무 시스템에서는 보통 둘 다 필요하지만, 처음에 “우리는 변경 추적이 중요한가, 열람 추적도 의무인가”를 가려 두면 어디에 힘을 줄지가 분명해집니다.

구체적인 장면으로 그려 보겠습니다. 어느 날 한 결재 문서의 금액이 이상하다는 게 발견됐다고 합시다. 감사로그가 없으면, 그 시점부터 할 수 있는 일은 추측뿐입니다 — “누가 그랬을까, 언제부터일까.” 반면 감사로그가 있으면 추적은 기계적입니다. 그 레코드의 변경 이력을 펼쳐 “마지막으로 이 값을 고친 사람과 시각”을 확인하고, 그 시각이 어느 배포·어느 작업과 겹치는지 좁혀 들어갑니다. 추측이 조사로 바뀝니다. 이 차이가 사고 대응의 속도와 신뢰를 통째로 결정합니다.

중요한 건, 이 질문들이 전부 사후에 온다는 점입니다. 사고가 난 다음에 “그때 로그 남겨 둘걸”이라고 후회해도, 그 순간엔 이미 데이터가 지나간 뒤입니다. 그래서 감사로그는 “필요할 것 같을 때 켜는 것”이 아니라 “처음부터 항상 켜 두고 잊는 것”이어야 합니다. 자동화가 핵심인 이유가 여기 있습니다 — 사람의 의지에 기대지 않아야 빠짐이 없습니다.

백업은 “복구해 본 적 있는가”가 전부다

백업에서 가장 위험한 착각은 “백업 스크립트가 돌고 있으니 안심”입니다. 진짜 질문은 그게 아닙니다 — 그 백업으로 실제로 복구를 해 본 적이 있는가입니다. 복구를 한 번도 안 해 본 백업은 백업이 아니라, 그냥 디스크를 차지하는 큰 파일 더미일 뿐입니다.

왜 이렇게 단정하느냐면, 검증 안 된 백업은 너무 많은 곳에서 조용히 망가지기 때문입니다.

”백업은 돈다”가 놓치는 것	실제로 복구할 때 터지는 문제
파일이 만들어지는 것만 확인	막상 부어 보면 포맷이 안 맞아 안 열린다
전체가 백업된 줄 안다	일부 테이블·파일만 들어가 있었다
스크립트 존재 = 절차 존재라 착각	복원 순서를 아무도 기억 못 한다
백업 따로, 첨부파일 스토리지 따로	DB는 살았는데 첨부 파일이 가리키는 곳이 비어 있다

흔한 착각	해야 할 것
”백업 스크립트가 매일 돈다 → 안전하다.” 정작 복구 시점에 포맷이 안 맞거나, 일부만 백업됐거나, 복원 절차를 아무도 모른다.	백업 + 복구 리허설을 한 세트로. “비어 있는 곳에 이 백업을 부으면 똑같이 살아나는가”를 실제로 해 본다. 그리고 그 절차를 문서로 남긴다.

아직 운영 단계가 아닌 개발 프로젝트라 해도, 백업과 복구 절차의 “자리”는 초기에 잡아 두는 편이 낫습니다(〈보안의 ‘게이트 자리’〉와 똑같은 논리입니다). 데이터가 쌓인 뒤에 처음 백업을 고민하면, 그땐 이미 잃을 게 있는 상태입니다.

관련 글: 〈보안은 나중에 추가할 수 없다〉, 〈배포 자동화의 후회〉. 전체 그림은 〈사례연구: SL.AIMS〉에 있습니다.