잘못된 파일을 보낸 뒤 “왜 늘 이 모양일까”만 반복하면 정정은 늦어지고 원인도 남지 않습니다. 반대로 시스템 문제라고만 말하면 책임을 피하는 설명이 될 수 있습니다. 복기는 피해를 줄인 뒤, 사람이 같은 상황에서 다시 실수하기 쉬운 조건을 고치는 작업입니다.

원인 분석 전에 진행 중인 영향을 멈춥니다

오발송 사실을 확인했다면 누가 어떤 파일을 받았는지, 외부 공개가 됐는지, 민감한 정보가 포함됐는지를 먼저 확인합니다. 조직의 보안 사고나 개인정보 처리 절차가 적용되는 경우에는 개인 판단으로 덮지 말고 그 절차를 따릅니다. 일반 버전 오류라면 올바른 파일과 변경점을 알리는 복구부터 합니다.

상대가 확인할 수 있도록 “앞선 첨부는 이전 버전입니다. 새 파일의 날짜는 9월 3일이며 표 2가 수정됐습니다”처럼 구분합니다. 실제 영향이 확인되기 전에는 아무 피해가 없었다고 단정하지 않습니다. 과도한 보상 약속도 내 권한을 넘지 않아야 합니다.

가상 사례를 시간 순서로 풀어봅니다

실제 사고가 아닌 사무 업무 복기 예시
시점행동·조건확인할 단서
오전공유 폴더에 이전 파일과 최종 파일이 함께 있었음파일명에 날짜 구분이 없었음
전송 직전검색 결과 첫 파일을 첨부하고 열어보지 않음전송 전 확인 순서가 없었음
전송 뒤수신자가 표가 다르다고 문의함외부 재배포 전 발견
복구정정본과 달라진 표를 알림수신자 확인을 기다리는 중

“부주의했다”는 말은 이 순서의 어느 부분도 바꾸지 못합니다. 파일 구분과 첨부 확인 중 어디에 장치를 둘지 보려면, 당시 무엇이 보였고 어떤 선택이 가능했는지를 적어야 합니다.

책임 인정과 사람 비난은 다릅니다

Google SRE의 사고 회고 원칙은 사고 영향과 대응, 원인, 후속 조치를 문서화하고 개인을 비난하기보다 시스템의 조건을 이해하는 데 초점을 둡니다. 본문은 이 운영 원칙을 사무 파일 작업에 응용한 것이며 심리치료 효과를 주장하지 않습니다.

“첨부 전 파일을 열 수 있었는데 하지 않았다”는 내가 바꿀 수 있는 행동입니다. “최종본을 구분할 규칙이 없었다”는 함께 개선할 환경입니다. 둘 중 하나를 지우지 않습니다. 현재 알게 된 사실을 당시에도 당연히 알았어야 했다고 평가하지 않고 결정 시점의 정보로 돌아갑니다.

예방 조치는 완료 여부를 확인할 수 있어야 합니다

  • 파일명에 날짜와 상태를 넣을 담당자를 정합니다.
  • 배포 폴더와 작업 폴더를 구분하고 이전 버전은 정해진 보관 위치로 옮깁니다.
  • 전송 전에 첨부 파일을 열고 수신자·버전을 확인하는 순서를 둡니다.
  • 다음 유사 작업에서 장치가 쓰였는지 확인할 날짜를 정합니다.

이 조치도 모든 업무에 필요한 것은 아닙니다. 작은 실수마다 복잡한 승인 단계를 만들면 작업이 느려지고 실제로 지키지 않을 수 있습니다. 피해 가능성과 반복성을 기준으로 최소한의 장치를 선택하고, 효과가 없으면 수정합니다.

복기를 마칠 조건

현재 복구 상태가 확인되고 후속 조치에 담당자와 기한이 붙었다면 같은 사건의 자기평가를 반복하지 않습니다. 아직 수신자 확인이 없다면 미완료로 표시합니다. 사과를 여러 번 보내는 대신 필요한 결과를 확인하는 한 번의 후속 연락이 더 명확할 수 있습니다.

안전·법률·큰 금전 손실이 관련된 사고는 이 간단한 표로 종결하지 말고 공식 보고와 전문가 검토를 따릅니다. 이 문서는 책임을 줄이는 자료가 아니라, 무엇을 복구했고 무엇이 남았는지 빠뜨리지 않기 위한 기록입니다.

조치를 적었다고 예방이 끝난 것은 아닙니다

“파일명 규칙을 만들었다”와 “다음 전송에서 올바른 파일을 구분했다”는 다른 단계입니다. 담당자가 규칙을 알고 실제로 사용할 수 있었는지 후속 작업에서 확인합니다. 오류를 다시 만들어 피해를 주는 시험을 할 필요는 없고, 다음 정상 작업의 확인 항목에 넣을 수 있습니다.

예방 장치가 너무 번거로워 생략됐다면 개인의 성실함만 탓하지 말고 더 간단한 방법을 찾습니다. 파일명 규칙 여러 개보다 배포용 폴더 하나가 명확할 수도 있고, 자동 검사로 놓치는 부분은 짧은 대조 질문을 추가할 수도 있습니다. 이 선택 역시 업무 위험에 따라 달라집니다.

최종 기록에는 확인된 사실과 아직 남은 위험을 구분합니다. 조치가 있었다는 이유로 재발 가능성이 0이라고 보고하지 않습니다. 새 문제가 발견되면 이전 조치의 한계를 갱신할 수 있어야 다음 사람이 같은 판단을 반복하지 않습니다.