고객사 담당자가 “퇴사한 직원의 관리자 권한은 누가 언제 회수했나요?”라고 물을 때가 있습니다. 지원팀이 대신 처리했는지, 자동 작업이 실행했는지, 요청은 성공했는지까지 확인해야 답이 끝납니다. 여러 화면과 담당자의 기억을 뒤져야 한다면 기록이 있어도 고객은 안심하기 어렵습니다.
B2B SaaS 관리자 권한 감사 로그 설계는 목록 화면을 하나 추가하는 일이 아닙니다. 고객별로 중요한 변경을 누가, 언제, 무엇을, 어떤 결과로 처리했는지 나중에 다시 설명할 수 있게 권한 변경 흐름과 운영 책임을 함께 정하는 일입니다. 요구사항 단계에서는 저장 방식보다 먼저 “문제가 생기면 다시 확인해야 하는 변경은 무엇인가”를 골라야 합니다.
모든 행동이 아니라 고객에게 설명할 변경을 고릅니다
화면 이동이나 단순 조회까지 같은 수준의 감사 이력으로 쌓으면 중요한 변경을 찾기 어려워집니다. 처음에는 권한을 넓히거나 고객 데이터 접근에 영향을 주는 행동부터 범위를 잡는 편이 좋습니다. 서비스 초기에는 사용자 초대·삭제와 역할 변경으로 시작하고, 고객이 직접 운영하는 범위가 넓어질 때 접속 정책과 외부 연동 설정을 더할 수 있습니다.
초기 요구사항의 우선 후보는 다음 네 가지입니다.
- 관리자 추가·비활성화, 역할과 접근 범위의 부여·회수
- 로그인 방식, 추가 인증, 비밀번호 정책 같은 접속 정책 변경
- 외부 연동 권한이나 API 키의 발급·폐기
- 대량 내려받기와 보관 설정처럼 고객 데이터에 영향을 주는 변경
기록 한 건은 사람이 읽고 상황을 설명할 수 있어야 합니다. 고객사 또는 조직, 실행자와 당시 역할, 변경 대상, 이전값과 이후값, 성공·실패 결과, 발생 시각, 처리 경로를 연결해 두는 이유입니다. 다만 설명력이 높다고 모든 값을 저장할 수는 없습니다. 비밀번호, 인증 비밀값, API 키 전체값, 민감한 고객 데이터 원문은 남기지 않거나 가려야 합니다. 각 항목을 고객에게 표시 가능, 일부 표시, 값 자체 미보관으로 나눠 정해 두면 개발 범위도 선명해집니다.
고객에게 보일 이력과 운영팀이 볼 기록을 나눕니다
고객 관리자가 자기 조직의 권한 변경 이력을 직접 확인하게 할지는 제품 운영 방식에 따른 선택입니다. 고객이 스스로 관리자를 운영하는 서비스라면, 자기 조직 안에서 누가 어떤 역할을 바꿨는지 찾을 수 있는 화면이 문의를 줄일 수 있습니다. 반대로 내부 운영팀이 변경을 대신 처리하는 서비스라면 고객용 화면보다 지원 응대 과정에서 정확히 설명할 수 있는 내부 조회 기능이 더 먼저일 수 있습니다.
두 화면을 처음부터 완전히 따로 만들 필요는 없습니다. 먼저 조회 범위와 수정 권한을 나누면 됩니다. 고객은 자기 조직의 이력만 보게 하고, 운영팀은 대리 처리 경로와 담당 정보를 더 확인하게 하는 방식입니다. 예를 들어 고객 요청으로 지원 담당자가 퇴사자의 권한을 회수했다면, 고객 화면에는 대리 처리와 결과를 표시하고 내부 기록에는 요청 접수 경로까지 남길 수 있습니다.
자동 작업이나 외부 연동 계정이 변경을 수행한 경우에도 실행 주체를 구분해 보이도록 설계하는 편이 좋습니다. 사람이 처리한 일처럼 표시하면 문의 대응 과정에서 책임 경로가 흐려질 수 있기 때문입니다. 일반 관리자가 이미 남은 이력을 수정하거나 삭제할 수 없게 할 범위도 함께 정해야 합니다. 더 강한 훼손 방지나 별도 보관 방식은 고객 계약, 업종 특성, 조사 필요성에 따라 추가로 판단할 수 있습니다.
업체에는 한 건의 변경을 끝까지 보여 달라고 요청합니다
“감사 로그를 만들 수 있다”는 답만으로는 충분하지 않습니다. 관리 화면에서 변경한 내용만 기록되고, 지원팀 대리 처리나 일괄 작업, 외부 연동을 통한 변경이 빠진다면 가장 설명이 필요한 상황에서 이력이 끊길 수 있습니다. 반면 데이터베이스를 직접 수정하는 예외 작업까지 고객용 이력에 같은 방식으로 보여 줄지는 별도 선택입니다. 그런 작업을 허용한다면 누가 어떤 절차로 예외를 처리하고, 사후에 무엇을 확인할지 업체와 미리 합의하는 편이 안전합니다.
상담에는 가정의 사례 하나를 가져가면 좋습니다. 예를 들어 “지원팀이 고객 요청을 받아 최고 관리자 권한을 회수했고, 같은 날 자동 작업이 연동 권한을 갱신했다”는 상황입니다. 이 사례를 놓고 전후값 비교가 가능한지, 두 변경이 같은 고객사 이력에서 구분되는지, 고객 관리자와 운영팀의 조회 범위가 어떻게 다른지를 시연으로 확인하면 됩니다. 성공한 변경만 보지 말고 권한 부족으로 실패한 요청도 남는지 살펴보십시오.
업체 선정 전 최소 검수 기준은 세 가지로 묶을 수 있습니다. 한 건에서 전후 내용을 비교할 수 있는지, 화면 밖 경로의 변경도 필요한 범위에서 기록되는지, 고객사 경계가 조회와 내보내기에서 지켜지는지입니다. 보관 기간은 모든 SaaS에 같은 답이 없으므로 고객 계약, 개인정보 범위, 사고 조사 필요성에 맞춰 정하면 됩니다.
요구사항 문서의 출발점은 “감사 로그 화면 개발”이 아니라 “고객사별 관리자 변경을 나중에 재구성할 수 있어야 한다”가 좋습니다. 이 문장을 기준으로 잡으면 기록할 변경, 고객에게 보일 정보, 운영팀이 책임질 예외 처리까지 한 흐름으로 결정할 수 있습니다.
