이미지 메뉴가 사라지고 업로드가 거절됐을 때

업로드는 화면 안내와 실제 조건이 달라서 거절됐어요

처음에는 여러 파일을 한 번에 고른 것이 원인처럼 보였어요. 하나의 큰 요청으로 묶였다면 적게 고르면 해결될 테니까요. 살펴보니 화면은 이미 파일을 한 장씩 보내고 있었고, 파일은 저장을 처리하는 단계에 닿기 전에 거절되고 있었어요. 화면이 허용한다고 안내한 크기와 실제로 통과할 수 있는 조건이 맞지 않았던 거예요.

새 이미지, 여러 장의 이미지, 기존 이미지의 새 버전을 올리는 입구가 모두 같은 문제를 만날 수 있어서 파일을 받아들이는 흐름 자체를 고쳤어요. 원본 역할의 파일과 썸네일을 업로드에 맞는 상태로 다루고, 서버에서도 같은 조건을 확인하게 했어요. 처리할 수 없는 항목은 그 항목의 실패로만 남기고, 이미 성공한 파일까지 한꺼번에 실패로 보이지 않게 결과를 파일별로 나눴어요. 여러 장을 올리는 사람은 어느 파일을 다시 처리해야 하는지 알아야 하고, 이미 올라간 자료를 다시 고를 이유는 없으니까요. 구현 직후에는 운영에 반영되지 않은 상태였고, 이 점을 다시 짚은 뒤 후속으로 실제 배포까지 이어졌어요.

버전 숫자는 덜어내고 자산의 이력은 남겼어요

공개 앱 상단의 버전 숫자는 실제 배포와 맞지 않아서, 바뀐 기능을 보면서도 수정이 반영됐는지 다시 묻게 만들었어요. 이 숫자는 여러 화면과 기록, 관리 기능에 걸쳐 있어 한곳만 고치면 다른 곳이 이전 상태를 설명하게 돼요. 이미지나 문서의 버전은 사정이 달라서, 이전 자료와 현재 자료를 구분하는 데 실제로 필요한 기능이었어요. 그래서 같은 의미로 숫자를 보여 주던 화면들에서 공개 앱의 숫자 표시를 함께 덜어내고, 실제 개발 변화는 날짜별 기록으로 모았어요. 자산별 변경과 이력 기능, 과거 기록은 그대로 유지했어요. 지금 할 수 있는 일은 화면에서, 변경이 언제 있었는지는 이력에서 찾게 하려는 배치였어요.

사라진 메뉴는 오래된 배포 기준에 덮여 있었어요

숫자를 정리한 뒤 이미지 메뉴가 보이지 않았고 관련 페이지도 열리지 않았어요. 직전 수정이 필요한 기능까지 지운 것처럼 보였지만, 정상인 변경을 되돌리면 이미 정리한 문제가 다시 들어올 수 있었어요. 기록을 대조해 보니 오전에 반영한 최신 화면에는 메뉴가 있었어요. 이후 배포의 기준이 되는 쪽에는 그 변경이 아직 들어가 있지 않았고, 이전 상태를 바탕으로 한 변경이 다시 반영되면서 최신 기능을 덮은 거예요. 기능을 한 번 운영에 보여 주는 것과 다음 변경의 기준에도 남기는 것은 별개의 일이었고, 지금 화면만 되돌리면 다음 작업에서 같은 증상을 다시 만날 수 있었어요.

그래서 메뉴의 표시 조건을 손대는 대신, 필요한 메뉴와 페이지를 현재 배포 기준에 포함시켜 다시 운영에 반영했어요. 예전 화면을 통째로 되돌리지 않았기 때문에 정리하기로 한 오래된 표시는 다시 붙지 않았어요. 복구 뒤에는 메뉴가 보이는 데서 멈추지 않고 관련 페이지로 들어가 기존 이미지 교체와 미리보기가 유지되는지, 목록을 읽는 작은 경계까지 살폈어요. 숫자 정리와 메뉴가 사라진 일은 시간상 붙어 있었지만, 숫자를 없앤 수정을 원인으로 설명하지 않았어요.

확인한 범위는 사건마다 달라요. 업로드는 브라우저에서 파일 처리를 보고 운영 목록과 화면이 정상으로 열리는 것까지 확인했지만, 실제 운영 자료를 새로 쓰는 인증 업로드 시험은 실행하지 않았어요. 그래서 여러 이미지의 실제 업로드가 모두 성공했다고는 말할 수 없고, 처음 실패한 사용 순서를 같은 환경에서 끝까지 따라가는 확인이 남아 있어요. 모든 형식의 원본 보관 문제도 이번 범위 밖에 두었어요. 버전 숫자 정리는 운영에서 새 상태를 확인했지만 방문자의 혼란이 얼마나 줄었는지는 측정하지 않았어요. 이미지 메뉴 복구도 제보된 메뉴와 페이지 범위의 확인이라, 전체 자료와 모든 계정에서 오래 안정적으로 동작하는지는 단정할 수 없어요.