누가 설정을 바꿨을까? 감사 로그로 변경 이력 확인하기

오늘의 인사이트 요약

• 감사 로그는 사용자와 시스템의 주요 행동을 추적하는 기록입니다.

• 버튼 클릭과 실제 저장 성공은 구분해 남깁니다.

• 기록할 항목뿐 아니라 보호·보관·조회 방법도 설계합니다.

관리자 화면의 설정이 바뀌었는데 담당자와 변경 시점을 찾기 어려울 때가 있습니다. 서버가 정상 응답했다는 기록만으로는 업무 변경 이력을 설명하기 부족합니다. 오늘은 감사 로그의 뜻과 서비스 로그와의 차이, 유지보수 범위에 담을 기록·조회 조건을 알아보겠습니다.

1. 감사 로그와 서비스 로그는 무엇이 다를까?

감사 로그는 누가 언제 어떤 대상에 어떤 행동을 했는지 추적할 수 있도록 남기는 기록입니다. 변경의 주체와 결과를 확인하는 데 쓰이며, 오류 원인이나 응답 시간을 살펴보는 서비스 로그와 목적이 다릅니다. 같은 저장 도구를 쓰더라도 필요한 항목과 열람 권한은 따로 정할 수 있습니다.

서비스 로그는 오류나 처리 시간처럼 프로그램의 동작을 살펴보는 데 자주 쓰입니다. 감사 로그는 권한 변경, 주요 데이터 수정, 내보내기처럼 나중에 행위자를 확인할 작업을 기록합니다. 용어와 분류는 조직마다 다를 수 있으므로 이름만 보고 포함 범위를 판단하지 않습니다.

가상의 관리자 서비스에서 회원의 이용 등급을 바꾼 경우를 살펴보겠습니다. API 요청이 성공했다는 로그가 있어도 누구의 등급을 누가 바꿨는지 없으면 담당자가 경위를 확인하기 어렵습니다. 반대로 변경 이력에 행위자와 대상이 있어도 서버 내부 오류 원인까지 알 수 있는 것은 아닙니다. 두 기록을 연결할 식별자가 있으면 함께 조사하기 편합니다.

클라우드 로그가 업무 변경까지 기록할까?

AWS CloudTrail은 AWS 계정에서 사용자·역할·서비스가 수행한 작업을 이벤트로 기록하는 서비스입니다. 클라우드 자원에 대한 작업 기록과 우리 앱 안의 등급 변경은 기록 대상이 다릅니다. 필요한 계정 활동을 어떻게 추적하는지 알고 싶다면 AWS CloudTrail 개요를 참고해 보세요. 별도 업무 기록이 필요한 범위를 나눠 보는 데 도움이 됩니다.

무엇을 감사 대상으로 삼을지는 서비스의 운영 질문에서 정합니다. 권한 설정을 누가 바꿨는지, 중요한 자료를 누가 내보냈는지처럼 나중에 답할 질문을 먼저 적습니다. 모든 클릭을 쌓는 방식은 저장량만 늘리고 정작 필요한 완료 결과를 놓칠 수 있습니다. 우선 추적할 행동과 제외할 행동을 구체적으로 나누는 편이 좋습니다.

2. 감사 로그에는 무엇을 남길까?

기본 항목은 행위자, 발생 시각, 대상, 행동, 결과입니다. 로그인한 계정이 작업했다면 계정 식별자를 남기고 자동 작업이면 실행 주체를 구분합니다. 사람이 요청했지만 시스템이 나중에 처리했다면 요청한 사람과 실행한 작업을 함께 연결해 두면 경위를 따라가기 쉽습니다.

변경 이력을 남길 때는 저장 버튼을 누른 사건과 실제 반영 결과를 나눕니다. 요청이 거부됐거나 일부만 바뀌었다면 성공으로 기록하지 않습니다. 한 번에 여러 항목을 수정하는 작업은 요청 전체의 상태와 개별 대상의 처리 결과를 함께 찾을 수 있는지도 확인합니다. 화면에 완료가 떠도 뒤에서 실패하는 작업은 완료 기준부터 정해야 합니다.

변경 전후 값은 어디까지 필요할까?

담당자가 변경 내용을 판단할 만큼의 차이는 남기되 민감한 원문을 모두 복사하지 않습니다. 비밀번호, 접근 토큰, 불필요한 개인정보가 로그에 들어가면 기록 자체가 보호해야 할 데이터가 됩니다. 변경된 항목 이름만 남길지, 일부를 가릴지, 접근을 제한한 별도 기록이 필요한지 항목별로 정합니다.

요청 식별자를 두면 화면의 작업과 서버 처리 기록을 연결하기 좋습니다. 여러 서버에서 모은 기록은 시각과 시간대를 일관되게 다루고, 지연 처리라면 발생 시각과 수집 시각을 구분합니다. 누가·언제·어디서·무엇을 했는지 기록하고 제외할 정보를 고르는 방법은 OWASP의 Logging 지침에서 더 자세히 보실 수 있습니다.

3. 기록을 안전하게 찾으려면 무엇이 필요할까?

로그가 저장돼 있어도 필요한 사람이 찾지 못하면 운영에 쓰기 어렵습니다. 담당자가 행위자·대상·기간·결과로 검색할 수 있는지 살펴봅니다. 같은 계정을 이름으로만 저장하면 이름이 바뀐 뒤 이력이 끊길 수 있으므로 고유 식별자와 표시 이름을 어떻게 다룰지도 정합니다.

조회 권한과 삭제·수정 권한은 구분합니다. 운영 화면을 편집하는 권한이 있다고 감사 기록까지 지울 수 있어야 하는 것은 아닙니다. 로그를 누가 보고 내보내는지도 관리할지 정하고, 기록의 변조·유실을 알아차릴 수 있는 보호 방법을 검토합니다. 감사 로그가 있다는 사실만으로 모든 변경의 책임이 자동 입증되는 것은 아닙니다.

로그 수집이 실패하면 어떻게 알 수 있을까?

기록을 보내는 저장소가 가득 차거나 연결이 끊기는 경우도 있습니다. 수집 실패를 누가 확인할지, 재전송 중 같은 사건이 중복 저장되면 어떻게 식별할지 정합니다. 중요한 작업은 기록 실패 때 업무를 계속할지 멈출지 결정해야 하는데, 서비스 가용성과 추적 필요성을 함께 보고 작업별로 선택합니다.

유지보수 검수에서는 실제 변경 한 건을 수행한 뒤 권한이 있는 담당자가 이력을 찾아 원인을 설명해 봅니다. 거부된 요청과 자동 작업도 포함하고, 기록의 보관 기간이 지나면 정한 방식으로 처리되는지도 확인합니다. 보관 기간과 삭제 기준은 서비스 목적과 적용 조건에 맞춰 정하며 모든 조직에 같은 기간을 제시하지 않습니다. 기록 생성부터 조회·보호·폐기까지 이어져야 운영 범위가 분명해집니다.

서비스 운영에 필요한 유지보수 범위를 함께 정합니다

똑똑한개발자는 프로덕트 기획·디자인·개발·운영 경험을 바탕으로 서비스 운영과 개선을 돕습니다. 코람코·태그미 사례에서는 흩어진 유지보수 요청을 모아 중복 작업을 줄이고 정해진 반복 작업을 처리하는 자동화를 적용했습니다. 운영 요청을 정리할 때도 접수된 작업과 실제로 반영된 결과를 연결해 살펴보는 것이 중요합니다.

운영 중 변경 이력을 확인하기 어렵거나 관리자 기능의 유지보수 범위를 정하고 싶다면 아래 똑똑한개발자 링크로 이야기 나눠주세요. 감사합니다.