보고서를 채팅으로 받는 이유는 그 자리에서 내용을 확인하기 위해서예요. 파일이 필요한데 글자나 파일을 가리키는 표현만 오면 결국 다른 곳을 열어야 하죠. 6월에는 첨부 처리를 고친 뒤에도 이런 불편이 이어졌어요. 수정한 코드와 사용자가 만나는 서비스 사이에 반영 단계가 빠져 있었어요.
처음 보기에는 수정이 틀린 것처럼 보였어요. 하지만 기록을 따라가 보니 실제 운영 프로세스가 이전 코드를 계속 사용하고 있었어요. 같은 증상이 남았다고 원인도 그대로라고 볼 수 없었죠. 파일에 들어 있는 변경과 실행 중인 동작을 나눠 볼 필요가 있었어요.
수정한 파일보다, 지금 실행하는 쪽을 보기
첨부를 처리하는 부분에는 이미 변경이 들어 있었어요. 파일만 다시 열어 보면 고쳤다는 설명이 맞았죠. 그렇다고 그 변경이 사용자의 채팅 요청을 처리하고 있다는 뜻은 아니었어요. 서비스를 오래 켜 두는 환경에서는 이 둘 사이에 시간 차이가 생길 수 있었어요.
확인 질문을 바꿨어요. 수정이 존재하는지에서 지금 작동 중인 프로세스가 그 수정을 읽었는지로요. 같은 코드 부분을 다시 고치는 것보다 먼저 운영 반영을 살펴야 했어요. 이 구분이 없으면 이미 맞는 수정을 덧붙이면서도 실제 증상은 바꾸지 못할 수 있어요.
개인·회사·운영 프로필도 함께 확인해야 했어요. 한 곳에서 서비스를 새로 시작했다고 다른 곳까지 같은 상태가 되는 것은 아니에요. 사용자는 같은 비서의 용도를 나눠 쓰지만, 운영에서는 각 프로필이 현재 변경을 실행하는지 따로 봐야 했어요.
새 코드로 보내는 것과, 빠진 파일을 다시 보내는 것
관련 운영 프로세스를 다시 시작한 뒤 누락됐던 첨부를 재전송했어요. 첨부를 추출하는 처리도 다시 확인한 기록이 있어요. 앞으로의 요청을 정상화하는 조치와 이미 받지 못한 결과를 전달하는 조치를 함께 다룬 거예요.
수정 후 다음 파일부터 잘 보내진다고 해도 앞서 빠진 보고서는 사용자가 다시 찾아야 해요. 이번에는 그 누락을 별도 결과로 남기지 않고 재전송했어요. 사용자가 고쳐졌다는 설명만 받은 채 필요한 문서는 여전히 못 보는 상태를 피하려는 처리였어요.
이 단계부터는 확인할 자료도 달라졌어요. 코드 검사만으로는 부족하고 실제 전송 결과가 필요했어요. 기록에는 누락 첨부를 다시 보내고 전송 성공을 확인한 내용이 남아 있어요. 운영 프로세스를 새로 시작했다는 사실과 메시지를 보냈다는 사실이 각각 근거가 됐어요.
다만 전송이 성공했다고 모든 수신 기기에서 파일을 열어 봤다는 뜻은 아니에요. 파일이 도착하는 과정과 도착한 파일을 읽는 과정은 또 다를 수 있어요. 당시 확인은 운영 반영과 재전송까지였고, 수신 환경별 표시를 모두 검증한 기록은 없었어요.
완료를 설명할 때도 이 범위를 지켜야 했어요. 수정이 들어간 파일, 그 파일을 실행하는 서비스, 실제로 보낸 첨부를 연결할 수 있게 된 것이 이번 작업의 결과예요. 아직 확인하지 않은 마지막 읽기 경험까지 붙이면 다음 문제를 찾을 기준이 흐려져요.
이미 전송되지 않은 결과는 따로 다뤄야 했어요. 다음 요청부터 정상화되는 것만으로 이전 사용자의 기다림이 끝나지는 않아요. 누락된 첨부를 다시 보낸 기록이 중요한 이유는 수정이 과거의 불편에도 연결됐다는 점 때문이에요.
프로필마다 현재 실행 상태를 확인하는 일은 새로운 기능 개발처럼 눈에 띄지는 않아요. 하지만 같은 수정이 적용됐다는 설명을 실제 서비스와 맞추는 단계예요. 파일에 있는 코드만 보고 끝내면 그 적용 차이가 채팅창에서 다시 드러날 수 있어요.
이후 첨부 문제가 보이더라도 이번 원인을 바로 반복 적용할 수는 없어요. 현재 프로세스가 새 처리를 쓰는지 확인한 다음 전달과 읽기 단계도 봐야 해요. 운영 반영이 한 번의 원인이었다는 사실과 모든 첨부 문제의 원인이라는 주장은 달랐어요.
이 과정은 개발자가 완료라고 말하는 시점과 사용자가 고쳐졌다고 느끼는 시점이 왜 다를 수 있는지 보여 줬어요. 내가 필요했던 것은 수정 내역이 아니라 사용할 수 있는 첨부였어요. 코드에서 끝낸 변경을 실제 전달까지 이어 주는 단계가 있어야 그 차이를 줄일 수 있었어요.
