감사 로그 사용하기

조직 내 모든 API 요청은 누가, 무엇을, 언제, 어디서, 어떤 애플리케이션으로 했는지 365일 동안 기록됩니다. 무슨 일이 있었는지 알아야 할 때 가장 먼저 확인할 곳입니다.

작성: Didit 지원팀 · 2026년 8월 19일 업데이트

#기록되는 내용

1234

1. 멤버, 경로, 메서드, 날짜로 필터링해 '누가 이걸 변경했는지'에 답할 수 있습니다.
2. Method와 status를 보면 단순 조회와 실제로 반영된 변경을 구분할 수 있습니다.
3. 그 호출을 만든 멤버입니다.
4. 요청이 어디서 왔는지 - 로그를 증거로 만들어 주는 항목입니다.

무엇을 통해 이루어졌든 조직 내에서 Didit 플랫폼에 요청된 모든 것이 기록됩니다. 각 항목에는 다음이 포함됩니다.

로그는 365일 동안 보관된 뒤 자동으로 삭제됩니다.

#실제 쓰임새

이 화면이 유용한 네 가지 상황입니다.

• "누가 이 워크플로우를 바꿨나요?" 어제와 다르게 동작하는 플로우는 대개 그 뒤에 변경 이력이 있으며, 로그는 누가 바꿨는지 알려줍니다.
• 인시던트 조사. 무엇이, 누구에 의해, 어느 주소에서, 어떤 순서로 접근됐는지 정확히 추적합니다.
• 연동 디버깅. 자신의 코드가 실제로 어떤 요청을 보냈는지 - 4xx로 끝난 요청까지 포함해서 - 짐작이 아니라 확인할 수 있습니다.
• 접근 통제 증빙. 인증 데이터 접근이 귀속되고 검토 가능하다는 것을 감사자에게 보여줄 수 있습니다.

#필터링

사용자, 엔드포인트, 날짜 범위로 필터링해 긴 목록을 좁힐 수 있습니다. 특정 사안을 조사할 때는 타임스탬프에서 시작해 바깥쪽으로 확장하세요. 요청은 좀처럼 단독으로 발생하지 않으며, 그 주변의 호출들이 대개 전체 맥락을 알려줍니다.

#API 키 요청은 사람이 아니라 애플리케이션 이름으로 귀속됩니다

API 키 요청에는 귀속시킬 사용자가 없으므로 애플리케이션 이름으로 표시됩니다. 이는 정직한 표현입니다. 플랫폼은 여러분의 어떤 서비스나 엔지니어가 그 호출을 만들었는지 실제로 알지 못하기 때문입니다.

실질적인 결과는 이렇습니다. 여러 서비스가 키 하나를 공유하면 사고 조사가 훨씬 어려워집니다. 귀속이 중요하다면 각 이용 주체에 애플리케이션과 키를 따로 부여하세요.

#로그에 담기는 것과 담기지 않는 것

이 로그는 활동을 기록합니다. 누가 무엇을 호출했는지, 언제, 어디서, 어떤 상태 코드가 반환됐는지입니다. 인증 데이터의 사본이 아니라 메타데이터 추적입니다.

이 항목에 고객 개인정보가 나타나는지 알아야 한다면 - 개인정보 보호 검토 과정에서 흔히 나오는 질문입니다 - 도움말 페이지에서 추론하지 말고 Didit 담당자에게 답을 받아 기록해 두세요. 이는 여러분의 DPIA에서 증빙을 요구받게 될 바로 그런 종류의 진술입니다.

#볼 수 있는 사람

감사 로그 접근 권한은 역할을 따릅니다. Compliance Officer는 포함되지만 Reader는 폭넓은 접근 권한을 갖지 않습니다. 오너는 커스텀 역할에 이 권한을 부여할 수 있습니다. 팀원 초대와 역할 설정을 참고하세요.

팀원을 제거해도 그 사람의 이력이 로그에서 사라지지 않습니다. 그것이 핵심입니다. 편집할 수 있는 추적 기록은 추적 기록이 아닙니다.

#내보내기와 리포트도 기록됩니다

세션 PDF나 CSV 내보내기를 생성하는 것도 API 호출이므로 누가 했는지와 함께 여기에 나타납니다. 인증 증거에 대한 접근이 통제되고 있음을 보여줘야 할 때 유용합니다. 검증 리포트 다운로드를 참고하세요.

#365일보다 길게 필요하다면

보존 기간은 365일로 고정되어 있습니다. 여러분의 의무 기간이 더 길다면, 필요한 만큼을 정기적으로 내보내 자체 시스템에 보관하세요. 세션 증거를 직접 보관하는 것과 같은 방식입니다. 필요한 기간을 정하는 것은 여러분 팀의 컴플라이언스 판단이며, 추측으로 설계해서는 안 됩니다.