감사 로그 읽기

감사 로그는 FDAI에서 발생한 작업을 확인하는 단일 기준 기록입니다. 추가 전용 (추가 전용)이므로 기존 기록을 변경할 수 없으며, 컨트롤 플레인이 내리는 모든 자율 결정을 포함합니다. 거부, 시간 초과, no-op으로 끝난 결정도 기록합니다. 이 가이드에서는 각 항목의 내용과 증상에서 근본 이벤트까지 역추적하는 방법을 설명합니다.

항목이 담는 것

모든 항목은 하나의 결정에 대한 전체 라이프사이클을 기록하며, 최소한 다음 내용을 포함합니다:

이벤트 ID: 소스 이벤트의 안정적인 식별자로, 멱등성 키로 써도 안전합니다. 같은 이벤트에서 나온 여러 결정은 이 ID를 공유합니다.
티어: T0, T1, T2 중 무엇인지 표시하므로 결정이 결정론적 경로에서 처리됐는지 추론 티어까지 갔는지 바로 알 수 있습니다.
룰, 정책, 모델 참조: T0와 T1은 룰 ID를, T2는 모델 식별자와 인용한 근거 문서를 기록합니다.
결정: 자동 실행, 사람 승인, 거부 중 무엇인지와 그 결정을 만든 분류입니다.
결정 근거: 일치한 위험 룰, 카탈로그 버전, feature 스냅샷, 필요한 정족수, 자율성을 제한한 resolved_ceiling 축입니다.
실행 주체: 시작자, 판단자, 승인자, 실행자, 감사자를 각각 별도 필드로 기록합니다.
타임스탬프: RFC 3339, UTC 기준입니다.
관찰 모드와 적용 모드: 모든 항목은 그 시점에 기능이 어느 모드였는지 표시합니다. 관찰 항목은 실행됐을 작업을 함께 기록합니다.
롤백 참조: 실행된 작업과 연결된 롤백 계획이나 복구 근거입니다. 미실행, 거부, 반려, 시간 초과, 관찰 전용 기록에는 복원할 실행 상태가 없습니다. 이는 실행 가능한 ActionType에 필수 rollback_contract가 빠진 것과는 다릅니다.

인시던트 추적

증상(메트릭 급증, 알림, 예상과 다르게 변경된 리소스)에서 시작해 역순으로 추적합니다:

감사 로그에서 리소스를 찾습니다. FDAI 액션은 항상 레코드를 남깁니다. 외부에서 발생한 변경은 연동된 Activity Log나 변경 피드에서 이를 관찰하고 정규화한 경우에만 나타납니다.
해당 리소스의 최신 관련 항목을 읽습니다. 변경을 만든 이벤트 ID와 결정 체인을 확인할 수 있습니다.
상관관계 ID를 사용해 감사, 로그, 메트릭, 트레이스를 연결합니다. 감사 스트림 안에서는 이벤트 ID로 티어, 리스크, 승인, 실행, 전달, 롤백, 종료 레코드의 순서를 확인합니다.
resolved_ceiling과 일치한 위험 룰을 확인합니다. 결정 당시 설정을 기준으로 어떤 입력 때문에 자동 실행, 사람 승인, 관찰 모드, 거부 경로가 정해졌는지 알 수 있습니다.
관찰 항목과 비교합니다. 실행되지 않은 작업도 관찰 모드에서 예상 결정과 함께 나타나므로, FDAI의 제안과 사람이 실제로 한 조치를 비교할 수 있습니다.

종료 결과 읽기

결과	변경 실행 여부	확인할 내용
`auto` 완료	예	실행기 신원, 전달 참조, 중단 조건 상태, 롤백 참조
승인 후 완료	예	승인 ID, 승인자, 정족수, 액션 해시, 실행기와 전달 레코드
거부 또는 시간 초과	아니요	사유, 마감 시한, 승인자가 있으면 승인자, 최종 미실행
`deny`	아니요	일치한 하드 룰, feature 스냅샷, 카탈로그 버전
`abstain` 또는 `shadow_only`	아니요	부족한 근거 또는 가장 엄격했던 상한, 실행됐을 작업
롤백 완료	실행 후 복원 또는 보상	원래 작업, 롤백 주체, 복구 결과, 남은 영향

재생과 사후 분석

감사 로그는 판단만 재현하는 재생를 위해 설계되었습니다. 이벤트를 컨트롤 플레인에 다시 흘리면 실제 작업을 두 번 실행하지 않고도 어떤 결정이 나오는지 확인할 수 있습니다. 제안된 룰 변경을 지난달 이력에 적용해 보고 승격 전에 비교하는 방법이 바로 이것입니다.

감사 로그에 없는 것

감사 로그는 결정과 실행 주체 참조를 기록합니다. 시크릿, 토큰, 고객 식별자, 사용자 데이터 내용은 절대 기록하지 않습니다. 진단 데이터는 로그, 메트릭, 트레이스로 이루어진 관측 스택에서 확인하세요. 각 감사 항목은 그 관측 데이터로 이어지는 상관관계 ID를 담고 있습니다.

예상한 종료 레코드나 상관관계 연결 정보가 없다면 감사 로그 완전성 오류로 처리하세요. 오류 레코드가 없다는 이유만으로 성공했다고 판단하지 마세요.

다음 단계

학습 대상	문서
승인 항목을 만드는 운영자 작업	approve-change-ko.md
`would-have-been` 결정이 담기는 이유	../concepts/관찰 모드-then-enforce-ko.md
잘못된 결과가 반복 기록되는 룰의 범위 좁히기	override-a-rule-ko.md
감사 로그의 스토리지와 보존 설계	../../roadmap/rules-and-detection/observability-and-detection-ko.md