기록의 세 종류
기술 로그는 실행과 오류, 업무 원장은 접수와 처리 사실, 감사 기록은 중요한 권한·상태 변경을 설명합니다. 보존과 열람 권한이 같을 필요는 없습니다. 로그를 지웠다는 이유로 실제 접수 원장도 없어졌다고 보지 않습니다.
가정한 로그 정책표
아래는 결정해야 할 항목을 보여주는 예시이며 특정 보존 기간의 권장값이 아닙니다. 실제 업무와 정책을 근거로 각 빈칸을 정합니다.
record_class: execution_error
purpose: identify failed step and retry outcome
allowed_fields: run_ref, action_code, category, timestamp
excluded_fields: secret, full_contact_payload, session_token
retention_rule: approved policy reference
read_access: authorized support roles
deletion_evidence: scheduled cleanup outcome
조사 가능성
가정한 예로 장애를 발견할 때 이미 실행 로그가 사라진다면 필요한 최소 정보가 원장에 남는지 봅니다. 반대로 원본 요청 전체를 계속 보관하면 불필요한 정보가 퍼질 수 있습니다. 실행 참조와 오류 범주만으로 추적할 수 있는지 먼저 설계합니다.
검수 순서
- 로그별 목적·필드·권한·보존을 정리합니다.
- 정상·오류·재시도에서 실제 기록을 봅니다.
- 비밀값과 시험 개인정보 문자열을 검색합니다.
- 만료·삭제·접근 거절과 저장 실패를 시험합니다.
로그 쓰기 실패가 고객 접수 자체를 막는지, 반대로 중요한 실패를 아무 흔적 없이 삼키는지도 확인합니다. 줄바꿈 등 입력값이 로그 구조를 혼란스럽게 만들지 않도록 구현 방식을 검토합니다. 출력된 로그를 일반 채팅에 붙여 조사하지 않습니다.
완료와 운영
담당자가 필요한 기간의 오류를 찾고 해석할 수 있어야 합니다. 로그가 존재한다는 사실과 업무가 성공했다는 사실을 구분합니다. 접근자 변경과 새 도구 추가 때 정책을 재검토하고 오래된 디버그 설정이 원문을 다시 남기지 않는지 확인합니다. 삭제 작업의 실제 결과도 검수해 설정만 있는 보존 정책으로 끝나지 않게 합니다.
자주 묻는 질문
- 로그는 오래 남길수록 좋은가요?
- 조사 필요와 정보 노출·저장 비용이 함께 있습니다. 자료별 목적과 정책에 맞는 보존을 정하고 법적 요건이 필요한 경우 별도 확인하며 임의의 일수를 보편 규칙으로 쓰지 않습니다.
- 마스킹하면 어떤 정보든 기록해도 되나요?
- 마스킹의 실제 효과와 재식별 가능성, 원본 보존 경로를 확인해야 합니다. 먼저 필요한 필드만 남기고 비밀값과 민감한 원문을 기록하지 않는 설계를 우선 검토합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.