비서에게 작업을 맡겼을 때 필요한 건 실행 기록 전체가 아니었어요. 어떤 일이 끝났고 지금 무엇을 확인하면 되는지 알고 싶었죠. 그런데 4월의 한 위임 작업은 일을 마친 뒤 결과를 채팅방으로 보내는 과정에서 실패했어요. 작업과 전달이 서로 다른 단계라는 사실이 그때 드러났어요.
사용자가 보는 것은 마지막 메시지예요. 중간에 일이 잘 진행됐어도 마지막에 오류만 도착하면 처음부터 실패한 것처럼 읽힐 수 있어요. 내부에서는 결과가 남아 있지만, 바깥에서는 다시 부탁해야 하는지 기다려야 하는지 알 수 없는 상태였어요.
다시 실행하기 전에, 어디에서 멈췄는지 보기
먼저 작업 자체와 메시지 전송을 나눠 확인했어요. 위임한 작업은 결과를 만들었고, 짧은 메시지는 정상적으로 보낼 수 있었어요. 연결 전체가 끊긴 상황과는 달랐죠. 긴 실행 기록을 보내는 경우에만 전송이 거절됐다는 점이 원인을 좁혀 줬어요.
전달하려던 내용에는 최종 답변 외에도 실행 안내와 중간 기록이 함께 들어 있었어요. 일을 진행하며 필요한 기록이었지만 사용자가 결과를 읽는 데 모두 필요한 것은 아니었어요. 내부에서 유용한 기록을 그대로 밖으로 보내는 방식이 마지막 단계를 막고 있었어요.
그 상태에서 원래 작업을 다시 실행하면 같은 결과를 더 만들 뿐, 전달 문제는 남을 수 있었어요. 이미 끝난 일을 처음부터 반복하기 전에 완성된 결과가 있는지 확인해야 했어요. 실패 알림 하나가 작업 전체의 상태를 대신하게 두지 않는 것이 먼저였어요.
결과와 실행 기록의 자리를 나누기
수정 방향은 최종 답변을 중심으로 전송하고, 한 번에 보낼 수 있는 범위를 넘지 않도록 하는 것이었어요. 다른 전송 방식으로 넘어갈 때도 같은 기준을 유지했어요. 방식만 바꾼 뒤 긴 기록을 다시 보내면 사용자가 겪는 문제는 그대로 남을 수 있으니까요.
중간 기록을 보존할 필요와 채팅창에서 읽을 내용을 고르는 일은 함께 할 수 있었어요. 자세한 실행 흔적은 문제가 생겼을 때 확인할 자료이고, 답변은 사용자가 다음 행동을 결정하기 위한 자료예요. 두 목적을 같은 메시지에 넣으려다 둘 다 읽기 어려워진 상황이었어요.
이 구분은 답변을 무조건 짧게 만들자는 뜻과도 달랐어요. 사용자가 필요한 내용을 잃으면 전송은 성공해도 다시 질문해야 해요. 남길 것은 작업의 결과와 확인할 점이었고, 덜어낼 것은 결과를 찾기 어렵게 만드는 실행 중간의 소음이었어요.
당시 수정 문서에는 최종 답변 중심의 전달로 바꾼 내용이 남아 있어요. 다만 수정 후 긴 위임 작업을 처음부터 끝까지 다시 돌려 실제 수신까지 확인한 결과는 그 문서에 없어요. 구현을 바꿨다는 사실과 사용자가 정상적으로 받았다는 사실은 여기서도 나눠야 했어요.
그래서 이 작업의 끝은 전달 방식의 수정까지예요. 다음에는 짧은 시험 메시지뿐 아니라 실제로 긴 결과가 생기는 작업을 보내고, 채팅창에서 읽을 수 있는지 확인할 일이 남았어요. 연결이 살아 있다는 시험과 실사용에서 결과가 도착한다는 시험은 다른 질문이었어요.
사용자가 결과를 받지 못한 상황에서는 재요청도 조심스러워요. 같은 일을 다시 맡기면 이미 끝난 작업을 반복할 수 있고, 기다리기만 하면 필요한 결과를 놓칠 수 있어요. 내부의 완료 상태를 전송 실패와 함께 설명할 수 있어야 이 두 선택 사이의 불확실성이 줄어들어요.
확인 순서가 중요했던 이유도 여기에 있었어요. 짧은 전송 시험은 채널이 살아 있는지 보여 줬고, 완성된 결과의 존재는 작업이 끝났는지 보여 줬어요. 둘을 대조해야 마지막 전달 단계만 수정할 근거가 생겼어요.
다시 긴 결과를 시험할 때도 답변이 잘렸는지만 볼 일은 아니었어요. 사용자가 결과와 남은 일을 읽고 다음 행동을 고를 수 있는지가 확인 대상이었죠. 길이 제한은 그 경험을 이어 주기 위한 조건이지 결과의 품질을 대신하는 기준은 아니었어요.
내가 원했던 경험은 작업이 끝났는지 알아내기 위해 내부 기록을 다시 열지 않아도 되는 것이었어요. 결과가 도착하지 않은 경우에도 어디까지 끝났는지 설명할 수 있어야 했고요. 일을 잘 수행하는 것만큼, 끝난 일을 사용자가 확인할 수 있게 만드는 과정이 중요해졌어요.
