실패 알림을 받으면 다음 일이 생겨요. 내용을 읽고 원인을 찾고 고친 뒤 다시 실행해야 하죠. 7월에는 이 부담을 비서가 먼저 맡게 하려는 흐름을 만들었어요. 하지만 실패를 알아차리는 권한과 시스템을 바꿔 회복시키는 권한을 같은 것으로 보면 문제가 생길 수 있었어요.
처음에는 원인 분석과 복구, 재실행까지 이어지는 설계를 시도했어요. 검사에서는 통과했지만 실제 운영에서는 분석에 걸리는 시간과 예약 실행의 제한이 맞지 않았어요. 작업을 시작했다는 사실만으로 끝까지 책임 있게 수행되는 것은 아니었어요.
복구를 자동으로 잇다가 발견한 경계
오래 걸리는 분석을 짧은 예약 실행에 연결하면 부모 작업이 먼저 종료될 수 있었어요. 남은 작업과 결과 전달을 따로 관리해야 하는 문제가 나타났죠. 눈앞의 오류를 빨리 고치는 기능보다 어떤 작업이 아직 진행 중인지 설명할 구조가 먼저 필요했어요.
권한에서도 비슷한 차이가 드러났어요. 기존 작업을 다시 실행한다는 말은 작은 조치처럼 들릴 수 있어요. 하지만 그 작업 안에 외부 반영이 들어 있으면 재실행은 단순 확인이 아니에요. 실패 알림을 받았다는 이유만으로 그 변경까지 맡았다고 볼 수 없었어요.
초기 기록에는 일부 작업을 회복한 결과와 권한이 필요한 지점에서 멈춘 결과가 함께 남아 있어요. 이후 기록에서는 기본 범위를 읽기 중심 진단으로 줄였어요. 현재 실패를 식별하고 근거를 모으되 변경까지 자동으로 이어지지는 않도록 한 거예요.
오래된 알림과, 지금의 실패도 구분하기
현재 작업이 이미 정상이라면 과거 오류 메시지만으로 다시 개입할 필요가 없어요. 같은 알림이 여러 번 보인다고 매번 별도 사건도 아니에요. 후속 실행에서는 최신 상태와 알림의 관계를 확인하고 이미 다룬 문제에 중복으로 개입하지 않는 과정을 살폈어요.
자연스럽게 회복된 작업도 비서가 고쳤다고 설명하지 않았어요. 관찰한 회복과 직접 수행한 복구는 다르니까요. 실행 권한을 좁히는 것만큼 결과를 말하는 범위도 좁혀야 사용자는 무엇이 실제 조치의 결과인지 이해할 수 있어요.
당시 실제 실행에서는 제한된 진단과 중복 개입 방지 흐름을 확인했어요. 초기 자율 복구 설계와 후속 읽기 중심 설계를 두 개의 성공담으로 나누기보다 같은 목표를 다루며 범위를 바꾼 과정으로 기록했어요. 운영에서 드러난 제약이 판단을 수정한 근거였어요.
모든 실패 알림이 동일한 기준을 갖춘 상태는 아니었어요. 생산하는 작업마다 표현이 달랐고 한꺼번에 바꾸지는 않았어요. 그래서 이 변경만으로 모든 운영 문제를 중앙에서 진단하고 복구한다고 말할 수는 없었어요. 적용 범위와 남은 연결을 구분했어요.
사용자가 기대한 것은 실패 뒤의 확인 부담을 덜어 주는 일이었어요. 그렇다고 내가 모르는 변경을 대신 수행해도 된다는 기대는 아니었죠. 먼저 어디가 문제인지 설명하고 다음 조치가 왜 필요한지 보여 주면 사람이 판단해야 할 지점을 좁힐 수 있어요. 그 효과를 숫자로 측정한 것은 아니지만 설계의 방향은 분명했어요.
사람에게 돌아오는 질문도 구체적이어야 했어요. 무엇인가 실패했다는 알림만 있으면 다시 원인을 찾는 일이 시작돼요. 읽기 중심 진단은 근거를 모으고 현재 상황을 좁혀 다음 변경을 판단할 지점을 남기려는 방향이었어요.
자동 복구의 초기 결과를 없애지도 않았어요. 어떤 조치가 가능했고 어디에서 경계가 필요했는지 알아야 후속 축소의 이유를 읽을 수 있어요. 설계를 바꾼 기록 자체가 실패 사례가 아니라 운영 조건을 확인하며 범위를 조정한 과정이었어요.
변경을 수행하지 않는 진단에도 결과를 잘못 말할 위험은 남아요. 관찰만 한 회복을 직접 고쳤다고 설명하면 사람은 실행 권한까지 있었던 것으로 이해할 수 있어요. 무엇을 했는지와 무엇을 봤는지를 나누는 문장도 역할의 경계를 유지하는 일부였어요.
이번에는 자동으로 하는 일의 양보다 맡긴 일의 경계를 더 살피게 됐어요. 실패를 발견하는 단계, 원인을 설명하는 단계, 실제로 변경하는 단계를 나눴어요. 작업을 더 많이 대신하는 것만으로 운영이 나아지는 것은 아니었고, 어디까지 맡았는지 알 수 있는 과정이 필요했어요.
