운영 화면에서 정상이라고 나오면 필요한 보고서도 준비됐다고 기대해요. 그런데 7월에는 특정 발행 작업이 멈췄는데 같은 프로필에 다른 일일 보고서가 있다는 이유로 실패가 가려질 수 있었어요. 파일이 있다는 확인과 요청한 작업이 끝났다는 확인이 서로 다른 대상을 보고 있었어요.
사용자에게는 같은 날의 보고서라는 공통점보다 자신이 기다리던 결과인지가 중요해요. 다른 용도의 문서가 아무리 잘 만들어졌어도 필요한 보고서가 없으면 다음 업무를 시작하기 어려워요. 존재하는 파일 하나가 모든 작업의 성공을 대신하는 구조를 살펴야 했어요.
넓게 확인해서 생긴 오히려 좁은 시야
상태 수집은 프로필에 일일 자료가 있는지 살피는 방식에 기대고 있었어요. 여러 결과를 한 번에 확인하기에는 간단했지만 개별 작업의 실패를 구분하기 어려웠어요. 날짜와 프로필이 같다는 사실이 작업의 목적까지 같게 만들지는 않았어요.
실제 발행 작업에서는 안전하게 멈춰야 하는 조건이 있었어요. 작업 중인 상태를 무시하고 진행할 수 없었죠. 그 중지 자체와 운영 화면이 그것을 제대로 설명하는지는 다른 문제였어요. 작업이 멈춘 이유를 고치는 것과 멈춤을 숨기지 않는 확인이 함께 필요했어요.
기준을 해당 작업이 만들어야 하는 결과로 좁혔어요. 그 작업의 실행 상태와 그 결과가 연결되는지 봤어요. 아무 보고서나 찾는 대신 사용자가 기다리던 결과를 찾게 만든 거예요. 확인 범위를 좁히니 오히려 전체 상태에서 놓치던 실패가 보였어요.
복구한 작업과, 복구를 읽는 화면을 함께 확인하기
관련 작업을 복구하고 공식 예약 작업을 다시 실행했어요. 수동으로 결과를 만든 것과 정식 실행이 다시 성공한 것은 별도 근거로 남았어요. 이후 상태도 해당 실행과 산출물을 읽도록 정렬한 기록이 있어요.
여기서 중요한 것은 정상 표시를 먼저 만드는 일이 아니었어요. 실제 작업이 회복되고 필요한 결과가 준비된 뒤 표시가 그 상태를 따르게 해야 했어요. 표시만 바꿔 성공처럼 만들면 사용자가 보고서를 찾는 순간 다시 문제를 만나요.
당시 다른 입력 연결 오류는 별도로 남아 있었어요. 이번 발행과 상태 확인의 복구가 끝났다고 전체 운영에서 모든 문제가 사라졌다는 뜻은 아니었어요. 서로 다른 사건을 분리해 남겨야 다음에 어느 결과를 다시 확인할지 알 수 있었어요.
이 글은 회사 보고서의 발행 구현보다 비서가 성공 여부를 어떻게 판단했는지에 초점을 맞췄어요. 같은 원자료에 두 변경이 담겼다고 같은 이야기를 프로젝트 이름만 바꿔 반복하면 중복 글이 돼요. 발행을 고친 과정과 그 결과를 정확히 읽도록 한 과정을 편집 단계에서 함께 대조해야 했어요.
사용자 경험의 목표는 필요한 결과를 기다리며 정상이라는 답을 다시 의심하지 않도록 하는 것이었어요. 이것이 실제 확인 시간을 얼마나 줄였는지는 측정하지 않았어요. 기록으로 말할 수 있는 것은 특정 작업의 결과를 기준으로 실패와 회복을 확인하게 바뀐 점이에요.
결과를 정확히 찾으려면 날짜와 역할도 함께 읽어야 해요. 같은 날의 개인 기록이 회사 발행의 결과를 대신할 수 없고, 전날의 성공 파일이 오늘 실행의 성공을 뜻하지도 않아요. 사용자가 기다린 작업을 구체적으로 가리키는 조건이 필요했어요.
실패가 보이지 않았던 문제는 복구가 늦어질 가능성과도 연결돼요. 상태창만 보면 할 일이 없다고 생각할 수 있으니까요. 이번에는 이미 있는 문서의 양보다 어떤 요청의 결과가 빠졌는지 볼 수 있게 하는 기준을 먼저 정리했어요.
실행을 고친 근거와 상태를 고친 근거를 따로 남긴 것도 같은 이유예요. 작업이 성공해도 화면이 예전 실패를 읽을 수 있고, 화면이 정상이어도 실제 결과는 없을 수 있어요. 두 확인이 같은 작업을 가리킬 때에야 완료 설명을 묶을 수 있었어요.
이후에도 결과를 추가할 때 같은 질문이 필요해졌어요. 확인하는 파일이 정말 이 작업의 결과인지, 다른 문서의 존재로 성공을 대신하고 있지는 않은지요. 운영 화면은 많은 정보를 모을 수 있지만 사용자가 기다린 하나의 결과를 정확히 가리키지 못하면 안심할 근거가 되기 어려웠어요.
