원장이 답할 질문
아직 처리하지 못한 업무가 무엇인지, 언제부터 지연됐는지, 누가 다음 행동을 할지 알 수 있어야 합니다. 오류 스택 전체를 복사하는 표보다 요청의 업무 의미와 복구 가능성을 정리합니다. 비밀키·개인정보·원본 메시지를 불필요하게 저장하지 않습니다.
최소 필드의 가정 예시
아래는 데이터 설계 논의용 예시입니다. 실제 도구가 제공하는 전달 ID와 업무 식별값의 차이를 확인해 적용합니다.
{
"run_id": "demo-failure-021",
"action_type": "notify_operator",
"first_failed_at": "2026-10-20T09:00:00+09:00",
"latest_attempt": 3,
"status": "manual_review_required",
"error_category": "destination_unavailable",
"next_owner": "operations_role",
"resolution_evidence": null
}
상태를 닫는 조건
경보를 읽었다는 사실과 업무가 완료됐다는 사실을 구분합니다. 외부 작업 결과 확인, 재처리 성공, 유효하지 않은 요청의 승인된 종료처럼 근거를 정합니다. 가정한 예로 담당자 메일이 실패했다면 메일 발송 성공 또는 대체 업무 배정 확인 전에는 접수 처리 완료로 닫지 않습니다.
검수 순서
- 의도한 외부 실패를 시험 환경에서 만듭니다.
- 원장에 상태와 최소 정보가 남는지 봅니다.
- 자동 재시도와 수동 인수를 확인합니다.
- 복구 뒤 증거와 상태 변경이 연결되는지 확인합니다.
원장 저장 자체가 실패하면 다른 경보 경로가 필요한지도 검토합니다. 자동 성공률만 보면 원장에 들어오지 못한 실패를 놓칠 수 있습니다. 일정 시간이 지난 미처리 항목을 발견하는 조회와 알림도 함께 설계합니다.
운영 완료 기준
담당자가 코드 로그 없이도 남은 업무를 찾고 필요한 기술 조사에 연결할 수 있어야 합니다. 같은 업무가 두 원장에 중복 생성되는지, 재처리 성공 후 미처리로 남는지 시험합니다. 원장의 항목 수를 단순 오류 수로 보고하지 않고 실제 처리 지연과 해결 상태를 구분해 사업 영향을 설명합니다.
자주 묻는 질문
- 서버 로그에 오류가 있으면 원장은 없어도 되나요?
- 로그는 보존과 검색 범위가 제한되고 업무 처리 상태와 다를 수 있습니다. 미처리 항목을 누가 언제 해결해야 하는지 별도 상태로 관리해야 오류 메시지를 찾는 일에 의존하지 않습니다.
- 재시도 성공 후 실패 행은 지우나요?
- 현재 상태를 완료로 바꾸더라도 원인과 지연을 분석할 이력은 필요한 범위에서 보존할 수 있습니다. 개인정보 최소화와 보존 정책을 정하고 무조건 삭제하거나 무제한 저장하지 않습니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.