# 감사 로그 사용하기

Source: https://help.didit.me/ko/account-organization/audit-logs
Updated: 2026-10-29

조직의 모든 API 요청은 콘솔, 연동, 팀원 모두를 대상으로 365일 동안 기록됩니다. 설정 → 감사 로그에서 확인하세요.

조직 내 모든 API 요청은 콘솔, 자체 연동, 팀원 모두를 대상으로 자동 기록되어 **365일** 동안 보관됩니다. **설정 → 감사 로그**에서 확인할 수 있습니다. 인베스티게이터가 스스로 내린 결정도 **조사관**으로 이곳에 기록됩니다.

[Video: 감사 로그 - Didit Academy](https://www.youtube.com/watch?v=MkULotdgz2o&t=31)

## 기록되는 내용

![타임스탬프와 상태 코드가 포함된 API 활동을 보여주는 Didit 콘솔의 감사 로그](https://help.didit.me/screenshots/audit-logs-light.webp)

*조직 내 모든 API 요청이 365일 동안 보관됩니다.*

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

| 필드 | 내용 |
|---|---|
| **Timestamp** | 요청이 이루어진 시각 |
| **User** | 수행자: 요청을 보낸 멤버. API 키 요청의 경우 **API 키** 태그와 함께 키 이름이 표시되고, Didit이 스스로 한 일은 **Didit**, 인베스티게이터가 스스로 내린 결정은 **조사관**으로 표시됩니다 |
| **Method** | GET, POST, PUT, DELETE |
| **Path** | 호출된 엔드포인트 |
| **Status** | HTTP 응답 상태 |
| **IP address** | 요청이 온 위치 |
| **Application** | 어떤 애플리케이션에 속한 요청인지 |

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

각 변경 사항을 문장으로 설명하고 보고 있는 내용을 내보낼 수 있는, 새로 디자인된 감사 로그가 순차적으로 적용되고 있습니다. 조직에 적용되기 전까지는 이 페이지에 여기서 설명하는 요청 로그가 표시됩니다.

## 실제 쓰임새

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

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

## 필터링

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

## API 키 요청은 사람이 아니라 키에 귀속됩니다

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

실질적인 결과는 이렇습니다. 여러 서비스가 키 하나를 공유하면 사고 조사가 훨씬 어려워집니다. 귀속이 중요하다면 서비스마다 별도의 키를 부여하세요. [API 키 관리하기](https://help.didit.me/ko/account-organization/api-keys)를 참고하세요.

## 인베스티게이터가 스스로 내린 결정은 인베스티게이터에게 귀속됩니다

인베스티게이터가 부여받은 자율성 범위 안에서 스스로 결정하면, 항목에는 사람이나 키가 아니라 **조사관**이 표시됩니다. 인베스티게이터가 내리는 모든 결정이 해당됩니다. 세션 승인 또는 거부, 사용자에게 재제출 요청, 거래 상태 설정, 그리고 케이스 해결, 에스컬레이션 또는 정보 요청입니다. 이러한 각 항목은 결정의 근거가 된 인베스티게이터 보고서로 연결되므로, 무엇을 발견했고 정책의 어떤 규칙을 적용했는지 확인할 수 있습니다.

사람이 인베스티게이터 보고서에 대해 결정하면, 즉 권고를 수락하거나 변경하면, 그 항목은 그 사람이 하는 다른 모든 변경과 마찬가지로 그 사람에게 귀속됩니다. 보고서, 질문, 안전 규칙을 포함한 인베스티게이터의 전체 기록은 계속 자체 **활동** 로그에 남습니다. [인베스티게이터 제어 및 감독하기](https://help.didit.me/ko/investigations/investigator-automation-and-oversight)를 참고하세요.

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

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

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

## 볼 수 있는 사람

감사 로그 접근 권한은 역할을 따릅니다. **Compliance Officer**는 포함되지만 **Reader**는 폭넓은 접근 권한을 갖지 않습니다. 오너는 커스텀 역할에 이 권한을 부여할 수 있습니다. [팀원 초대와 역할 설정](https://help.didit.me/ko/account-organization/team-members-and-roles)을 참고하세요.

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

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

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

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

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

> **Note:** 감사 로그 보존 기간과 **인증 데이터** 보존 기간은 별개의 설정입니다.
> 세션 데이터의 보존 기간을 짧게 설정해도 감사 로그가 짧아지지 않으며, 그 반대도 마찬가지입니다.
> [Didit가 사용자 데이터를 보호하는 방법](https://help.didit.me/ko/data-privacy/how-didit-protects-data)을 참고하세요.