감사 로그 UI 설계: 누가 무엇을 바꿨고 무엇이 누락됐는지 보여 주기

감사 로그 인터페이스는 권한 있는 사람이 사건을 재구성할 수 있게 해야 합니다. 누가 무엇을 바꿨고, 어떤 대상이 영향을 받았으며, 언제 일어났고, 성공했는지 알아야 합니다. “설정 업데이트”라는 한 줄로는 부족한 경우가 많습니다. 완료된 변경, 변경 시도, 백그라운드 처리를 구분할 수 없기 때문입니다.

재사용 가능한 데이터 테이블 컴포넌트(영어)로 레이아웃을 만들 수 있지만, 로그에는 이벤트 항목의 정의도 필요합니다. 아이콘, 심각도 색상, 상세 패널 구조를 고르기 전에 각 필드가 무엇을 뜻하고 시스템이 실제로 무엇을 입증할 수 있는지 정합니다.

로그가 답해야 할 질문부터 정하기

가상의 고객 지원 앱을 생각해 보겠습니다. 관리자는 새 대화가 이제 General 대신 Billing으로 배정되는 이유를 조사합니다. 라우팅 규칙 RR-17이 바뀐 것 같습니다. 유용한 질문은 “오늘 이벤트가 몇 건 발생했나?”가 아니라 “어떤 기록된 행동이 이 규칙을 바꿨고, 무엇이 달라졌나?”입니다.

디자인에는 의도적으로 구분되는 두 이벤트를 사용합니다.

• 2026년 10월 6일 14:08:12 UTC, 관리자 Mina가 RR-17의 배정 대상을 General에서 Billing으로 변경했습니다. 변경은 성공했습니다.
• 14:09:03 UTC, Routing automation이 RR-17을 다시 업데이트하려 했습니다. 시도는 실패했고 배정 대상은 Billing으로 유지되었습니다.

두 번째 이벤트를 또 한 번의 성공한 변경처럼 읽게 해서는 안 됩니다. 두 번째 실패가 첫 번째 변경을 되돌리는 것도 아닙니다. 모든 행을 똑같이 짧은 문장으로 만드는 것보다 이 차이를 드러내는 일이 중요합니다.

실행 주체, 행동, 대상을 구분하는 행 만들기

“Mina가 라우팅 규칙 RR-17을 변경함”처럼 간결한 문장은 목록을 훑어보는 단서가 됩니다. 보조 필드는 결과와 시간을 보여 주고, 상세 화면은 공개 가능한 변경 내역과 이벤트 참조 번호를 제공합니다. 모든 원시 속성을 기본 목록에 밀어 넣지 마세요.

여기의 이름, ID, 사건은 모두 디자인 연습을 위해 만든 가상의 정보입니다. 실제 로그에서는 출처에 따라 실행 주체가 사람, 서비스 계정, 자동화로 구분됩니다. 모든 이벤트에 사람 아바타를 넣지 말고 그 차이를 표시하세요.

GitHub 조직 감사 로그 문서(영어)는 실행 주체, 행동, 영향을 받은 맥락, 시간을 구분하는 구체적인 예입니다. 정의된 검색 한정자는 인터페이스의 필터가 원래 이벤트 데이터로 안정적으로 지원되는 조건에 맞아야 한다는 점도 보여 줍니다. 존재하지 않는 무제한 검색을 약속해서는 안 됩니다.

이벤트가 뒷받침하는 변경만 보여 주기

EV-2041에서 필요한 상세 정보는 짧습니다. 배정 대상이 General에서 Billing으로 바뀌었다는 것입니다. 필드 이름은 한 번 표시하고 이전 값과 새 값에 라벨을 붙여 색 없이도 방향을 읽을 수 있게 합니다. 좁은 화면에서는 “변경 전”과 “변경 후”를 세로로 쌓되 두 라벨을 모두 유지합니다.

현재 레코드와 무관한 스냅샷을 비교해 이전 값을 만들어 내지 마세요. 이벤트가 규칙이 업데이트되었다는 사실만 기록했다면 어떤 상세 정보를 확인할 수 없는지 알립니다. 현재 상태는 “지금 무엇이 사실인가?”에 답하고, 이벤트 상세는 “이 행동에 관해 무엇이 기록되었나?”에 답합니다. 서로 바꿔 쓸 수 없습니다.

실패한 자동화 이벤트에서는 시도한 행동과 기록된 실패 이유를 적절한 상세 수준으로 보여 줍니다. 반영되지 않은 제안 값을 아무 설명 없이 “변경 후” 아래에 표시하지 마세요. 출처에 그 정보가 있고 사용자가 볼 권한도 있다면 “요청된 변경”이라는 별도 라벨이 유용할 수 있습니다.

변경 화면에서는 빈 값, 삭제됨, 알 수 없음, 접근 제한도 다르게 표현해야 합니다. 빈 문자열은 유효한 값일 수 있습니다. “기록되지 않음”은 이벤트에 데이터가 없다는 뜻이고, “접근 제한”은 사용자가 볼 수 없다는 뜻입니다. 모두 대시로 표시하면 알 수 없는 것까지 확정된 듯한 인상을 줍니다.

조사에 필요한 시간과 범위를 명확히 하기

“2분 전” 같은 상대 시간은 최근 여부를 파악하는 데 좋지만, 조사에는 정확한 타임스탬프가 필요합니다. 날짜, 시각, 시간대를 접근 가능하고 쉽게 도달할 수 있는 곳에 제공합니다. 마우스로만 열 수 있는 툴팁이 정확한 시각의 유일한 출처가 되어서는 안 됩니다.

수집이 지연될 수 있다면 이벤트 시각과 로그가 이벤트를 수신한 시각을 구분합니다. 기본 정렬과 같은 시각일 때의 순서를 정하세요. 새로 수신한 이벤트가 시간상 앞부분에 들어갈 수 있습니다. UI가 표시 순서만으로 두 변경 사이의 인과관계를 입증하는 듯 보여서는 안 됩니다.

필터 옆에 적용 중인 기간과 관련 시간대를 보여 줍니다. “오늘”은 서로 다른 지역의 동료에게 다른 구간일 수 있습니다. 정확한 경계를 쓰는 필터라면 끝 시각을 포함하는지 제외하는지 구현 명세에 기록하고, 사용자에게는 읽기 쉬운 구간으로 표시합니다.

이벤트를 열었다가 돌아와도 필터를 유지합니다. 가능하면 결과 안의 위치도 보존해 EV-2041을 조사할 때마다 다시 검색하지 않게 합니다. 새 이벤트가 도착해도 사용자가 읽는 행을 갑자기 옮기지 마세요.

이벤트 행에서 필요한 상세 정보까지 설계하기

Pixso 파일에 지원 앱의 이벤트 표와 EV-2041 상세 패널을 나란히 만듭니다. RR-17, Mina, 14:08:12 UTC, General → Billing이 양쪽에서 일치하게 합니다. 나중에 실패한 자동화 시도는 아이콘만 다른 행이 아니라 결과가 다른 별도의 행으로 추가합니다.

선택한 행과 패널의 이벤트가 쉽게 연결되어 보이도록 합니다. 좁은 화면에서는 상세 내용을 집중해서 보는 별도 화면과 분명한 복귀 경로를 시험합니다. 리뷰어에게 어떤 행동이 배정 대상을 바꿨고 나중의 시도는 성공했는지 물어보세요. 행 색상을 보고 추측해야 한다면 텍스트를 개선합니다.

Pixso에서 감사 이벤트와 상세 화면 설계하기 →

누락된 이력을 “아무 일도 없었음”으로 바꾸지 않기

이벤트 목록이 비어 있는 이유는 여러 가지입니다. 현재 필터에 맞는 이벤트가 없거나, 선택한 기간이 보관 범위 밖이거나, 사용자가 접근 권한이 없을 수 있습니다. 출처가 이벤트를 보내지 않았거나 서비스가 불러오지 못했을 수도 있습니다. 각각 다른 설명이 필요합니다.

“이 필터와 일치하는 이벤트가 없습니다”는 이용 가능한 범위에서 조회에 성공했을 때만 적절합니다. 보관 경계의 문제라면 완전한 빈 이력처럼 보이게 하지 말고 확인 가능한 기간을 설명합니다. 데이터를 사용할 수 없다면 활동이 없었다고 단정하지 말고 지원하는 복구 행동을 제공합니다.

제한된 화면은 개수, 필터 선택지, 겉보기에는 무해한 미리보기를 통해 숨겨진 리소스의 존재나 신원을 누설해서는 안 됩니다. 보이는 상세 정보를 권한 모델과 맞추세요. 권한 UX 가이드는 리소스가 없는 경우와 현재 사용자가 접근할 수 없는 경우의 구분을 다룹니다.

상세 정보가 많다고 더 좋은 증거는 아닙니다

OWASP 로깅 치트 시트(영어)는 기록 목적을 구분하고 조사에 도움이 되는 이벤트 속성을 권장합니다. 비밀번호, 접근 토큰, 민감한 개인정보처럼 일반적으로 직접 기록해서는 안 되는 데이터도 설명합니다. 풍부한 차이 화면을 만든다는 이유로 그런 값을 넣어서는 안 됩니다.

상세 화면과 내보내기에도 같은 경계를 적용합니다. 표에서 숨긴 필드를 CSV 다운로드로 노출하면 보호한 것이 아닙니다. 마스킹이 적절하다면 원래 값이 비었다는 인상을 주지 말고 접근이 제한된 값이라고 표시합니다. 보안 담당자와 데이터 소유자가 대상별로 무엇을 확인할 수 있는지 정해야 합니다.

이력과 복구 행동도 구분합니다. 규칙이 바뀌었다는 로그가 있다고 안전한 원클릭 롤백까지 가능한 것은 아닙니다. 그 뒤에 레코드가 다시 바뀌었을 수 있고, 이전 배정 대상으로 되돌리는 데 권한과 현재 상태 검증이 필요할 수 있습니다. 실제로 지원할 때만 허용된 관리 흐름으로 연결합니다.

화면을 통해 무엇을 확인할 수 있는지로 평가하기

RR-17에 대해 관리자는 성공한 변경을 찾고, 공개가 허용된 전후 값을 읽고, 나중의 실패한 시도를 구분하며, 조사한 기간과 범위를 설명할 수 있어야 합니다. 확인할 수 없는 상세 정보도 알아보고 추측으로 빈틈을 채우지 않아야 합니다.

읽기 쉬운 로그만으로 완전성, 불변성, 규정 준수를 입증할 수는 없습니다. 이는 수집, 저장, 접근, 운영 통제에 달려 있습니다. 인터페이스의 역할은 더 좁지만 중요합니다. 시스템이 실제로 가진 증거를 사람이 해석할 수 있도록 돕는 것입니다.