고객사가 ‘어제 누가 계약 상태를 바꿨나요?’라고 물었다. 애플리케이션 서버 로그에는 요청 URL과 오류 메시지가 있지만, 어떤 고객의 어떤 계약이 무엇에서 무엇으로 바뀌었는지는 알기 어렵다. 반대로 모든 요청 본문을 통째로 저장하면 비밀번호, 연락처, 첨부 내용까지 로그에 남을 수 있다. 감사 로그는 많이 찍는 로그가 아니라 나중에 중요한 행위를 재구성할 수 있는 기록이다.
OWASP 로깅 가이드는 보안·감사·운영 목적에 따라 필요한 이벤트가 다르며, 언제·어디서·누가·무엇을 했는지를 남기라고 설명한다. SaaS에서는 이 원칙에 ‘어느 고객사의 데이터인가’와 ‘처리가 성공했는가’를 더해야 한다. 이 글은 법률상 보관 의무를 판정하는 문서가 아니라 제품 설계 관점의 출발점이다.
디버그 로그와 감사 로그는 질문이 다르다
디버그 로그는 개발자가 왜 요청이 실패했는지 알아내는 데 도움이 된다. 감사 로그는 운영자나 고객 관리자가 어떤 주요 변경이 일어났는지 확인하는 데 필요하다. 한쪽을 다른 쪽으로 대체하려고 하면 둘 다 부족해진다. 예를 들어 ‘HTTP 200 /contracts/42’는 성공 응답을 보여 주지만 계약의 승인 상태가 실제로 바뀌었다는 증거는 아니다. 감사 이벤트는 업무 결과가 확정된 시점과 연결돼야 한다.
첫 범위는 중요도가 높은 행위로 좁힌다. 권한 변경, 고객 데이터 다운로드, 설정 수정, 대량 삭제, 승인·취소, 다른 사용자 대신 수행한 작업 등이다. 모든 화면 조회를 동일한 수준으로 쌓으면 정작 찾아야 할 이벤트가 묻힌다. 목적별로 감사 이벤트와 일반 접근 로그의 수집 범위를 나누는 편이 낫다.
이벤트 한 건으로 답할 수 있어야 하는 질문
기본 필드는 이벤트 ID, 발생 시각, 고객사 ID, 행위자 ID와 유형, 수행한 동작, 대상 자원 ID, 결과, 요청 상관관계 ID다. 사람이 직접 누른 변경인지, 예약 작업이나 서비스 계정이 수행했는지도 구분한다. 대리 작업이라면 실제 실행자와 권한을 위임한 주체를 따로 남긴다. ‘관리자’라는 표시만으로는 누가 했는지 답하기 어렵다. 시간은 서버 기준을 일관되게 보관하고 화면에서 지역 시간으로 표시한다.
변경 전후 값은 모두 저장할 필요가 없다. 상태 전환이나 권한 목록처럼 추적해야 하는 필드만 구조화해 기록한다. 고객 메시지 원문이나 신분증 이미지 같은 민감한 본문은 넣지 않고 대상 ID, 변경된 필드명, 승인 결과처럼 최소한의 정보로 답한다. 비밀번호·토큰·비밀키는 감사 로그에도 남기지 않는다. 로그 열람 자체가 새로운 정보 노출 경로가 될 수 있기 때문이다.
이벤트 이름도 화면 버튼 이름과 분리한다. ‘저장 버튼 클릭’보다 ‘계약 승인 상태 변경’이 나중에 이해하기 쉽다. 클라이언트가 보낸 설명을 그대로 믿지 말고 서버가 실제 처리한 업무 결과로 이벤트를 만든다. 시간이 지나 이벤트 구조가 달라지면 스키마 버전을 남겨 과거 기록도 해석할 수 있게 한다. 요청 상관관계 ID는 같은 사용자 행동이 여러 서비스와 비동기 작업을 거쳤을 때 기록을 연결하는 실마리가 된다.
이벤트는 성공한 업무와 일치해야 한다
요청을 받았다는 사실과 데이터 변경이 성공했다는 사실을 구분한다. 실패 시도도 보안상 중요할 수 있지만 ‘변경 완료’로 표시하면 조사할 때 혼란을 준다. 업무 트랜잭션과 감사 이벤트 기록 사이가 어긋나지 않도록 설계하고, 비동기 처리라면 요청됨·진행 중·완료·실패를 별도 사건으로 표현한다. 실패 시도를 따로 기록하되 실제 결과를 과장하지 않는다.
또한 로그를 바꿀 수 있는 권한을 일반 애플리케이션 관리자에게 주면 사후 증거로서 가치가 떨어진다. 작성 권한과 열람 권한을 분리하고, 수정·삭제를 제한하며, 별도 보관소나 무결성 검증 절차를 검토한다. ‘append-only’라는 제품 이름만 보고 변조 불가능을 보증하지 말고 저장소 관리자 권한, 보관 기간, 백업까지 살핀다. OWASP 가이드는 로그의 기밀성·무결성·가용성을 각각 고려하라고 강조한다.
조회 화면과 운영 절차까지 있어야 쓸 수 있다
감사 로그가 쌓여도 고객사, 기간, 행위자, 대상, 이벤트 유형으로 빠르게 찾을 수 없으면 실제 문의 대응에 쓰기 어렵다. 대상 상세 화면에서 관련 이벤트로 들어가고, 그 이벤트에서 같은 요청의 다른 조치로 이어지는 탐색 경로를 설계한다. 조회하는 사람도 역할에 맞게 범위를 제한한다. 고객사 A의 관리자가 고객사 B의 로그를 볼 수 없다는 멀티테넌트 경계는 일반 데이터와 같다.
공유 관리자 계정은 감사 추적을 약화한다. 기록에는 한 계정 이름이 남지만 실제 수행자를 특정하기 어렵기 때문이다. 사람마다 계정을 분리하고, 자동 작업에는 사람 계정이 아닌 서비스 신원을 부여하는 것이 좋다. 관리자 대신 조치가 필요한 고객지원 업무라면 대리 수행 사실과 사유를 이벤트에 남겨야 한다. 감사 로그만 잘 만들어도 신원 관리가 느슨하면 ‘누가’라는 질문에 답하기 어렵다.
보관 기간은 업무 목적과 계약·규정 요구를 확인해 정한다. 무조건 영구 저장은 비용과 개인정보 위험을 높인다. 중요한 이벤트가 빠지지 않았는지 샘플링하고, 시간이 어긋나거나 중복되는 기록을 찾고, 감사 로그 자체의 열람과 내보내기도 감사한다. 이렇게 해야 ‘로그가 존재한다’에서 ‘질문에 답할 수 있다’로 넘어간다.
출시 전 체크리스트
- 고객사가 나중에 확인해야 할 주요 행위를 고른다.
- 행위자·고객사·시각·동작·대상·결과를 구조화한다.
- 사람과 자동 작업, 대리 작업을 구분한다.
- 요청 접수와 최종 성공을 다른 이벤트로 다룬다.
- 비밀정보와 불필요한 원문을 제외한다.
- 기록·열람·삭제 권한을 분리한다.
- 실제 고객 문의 시나리오로 검색과 재구성을 시험한다.
감사 로그의 목표는 모든 것을 감시하는 것이 아니다. 중요한 변경에 책임과 맥락을 남기면서 고객 데이터는 최소한으로 다루는 것이다. 설계 초기에 업무 이벤트를 정의하면 운영에서 훨씬 적은 자료로 더 정확히 답할 수 있다.
