파일은 100% 올라갔는데, 왜 첨부가 안 됐을까?

진행률을 보여달라는 요청에서 먼저 확인할 것

처음에는 진행률만 넣으면 기다리는 이유를 설명할 수 있을 것 같아. 그런데 100%를 보고 제출했는데 파일이 없다면, 문제는 기다리는 시간이 아니라 완료라고 이해한 시점이야. 파일을 골랐는지, 바이트를 전송했는지, 서버가 받았는지, 검사까지 통과했는지를 같은 말로 묶었는지부터 봐야 해.

이번 예제는 워크숍 제안서를 PDF 한 개로 받는 화면이야. PDF는 10MB 이하이고 빈 파일과 암호 파일은 받지 않아. 여기서 10MB는 10,000,000바이트로 정할게. 본문 입력은 별도로 남아 있어. 이 조건은 예제를 위해 정한 거고, 실제 서비스에서는 PDF가 꼭 필요한 이유부터 확인해야 해. 접수 담당자가 문서 형태를 그대로 검토해야 하는지, 이미 입력받은 내용을 다시 파일로 요구하는 건 아닌지 기획서에 남겨.

같은 파일로 화면과 서버 결과를 같이 봐

조사할 때 “가끔 첨부가 안 돼요”로만 기록하면 다시 물어볼 게 많아져. 언제 파일을 골랐고, 100%가 언제 떴고, 서버는 언제 수신과 검사 결과를 줬는지 같은 순서에 놓아봐. 테스트용으로 새로 만든 파일을 쓰고, 화면에 보인 이름과 서버가 그 파일에 붙인 식별값을 연결해. 같은 이름으로 다른 파일을 올렸을 때도 구분할 수 있어야 해.

GOV.UK의 파일 업로드 안내는 업로드 필요성과 구체적인 오류 안내를 확인하는 데 참고했어. OWASP는 확장자나 브라우저가 보낸 유형만 믿지 않고 서버에서 내용과 권한도 검증해야 한다는 근거로 썼어. 여기서 판단이 바뀌어. 전송률이 끝났다고 완료 문구를 보여줄 게 아니라, 서버가 지금 선택한 파일을 사용할 수 있다고 확인한 뒤 완료로 바꾸는 거야.

완료 기준을 정하면 문구와 버튼도 바뀌어

선택하자마자 파일명을 목록에 넣는 건 괜찮아. 다만 그 목록이 완료 목록처럼 보이면 안 돼. 첫 대안은 전송률 100%에서 제출을 여는 방식이야. 빠르게 보이지만 아직 수신 확인이나 검사가 남아 있을 수 있어. 두 번째는 전송과 검사를 분리하고 서버가 확인해 준 뒤 제출을 여는 거야. 이번에는 두 번째를 선택할게.

마지막까지 아무것도 안 보여주는 방법도 있겠지. 하지만 실패했을 때 어떤 파일을 다시 골라야 하는지 알기 어려워져. 그래서 파일명은 일찍 보여주되 상태를 붙여. 검사 기능이 아직 없으면 완료처럼 보이는 화면부터 배포하지 않고, 개발과 실제 확인 가능한 상태를 맞춰서 범위를 줄여야 해. 기획서에는 선택 이유를, 설계서에는 완료를 판단하는 응답 조건을 남겨.

검사 중과 결과를 모르는 상태를 섞지 마

100%가 떠도 서버가 받았는지 모르면 “전송 결과 확인 중”이야. 서버가 받은 것은 확인됐고 검사만 남았다면 “파일 검사 중”이야. 둘 다 아직 제출할 수 없지만 확인할 곳이 달라. 파일 크기가 기준을 넘은 경우에는 줄이거나 다른 파일을 고르게 하고, 검사 서비스가 응답하지 않은 경우에는 파일이 잘못됐다고 말하지 않아.

완료 응답도 지금 선택한 파일의 결과인지 확인해야 해. 화면이 기억하는 선택 버전과 업로드 시도가 맞고, 서버의 첨부 식별값과 접수 연결, 검사 통과가 확인돼야 “첨부 완료”야. 같은 시도의 오래된 검사 중 응답이 늦게 오더라도 최신 완료 상태를 되돌리지 않게 응답의 상태 버전도 비교해. 이렇게 쓰면 개발이 어떤 값을 보장해야 하는지, QA가 무엇을 바꿔 봐야 하는지가 이어져.

지운 파일이 뒤늦게 돌아오면 안 되잖아

검사 중인 파일을 지웠는데 성공 응답이 나중에 왔다고 다시 목록에 넣으면, 사용자가 지운 동작이 사라져 버려. 지우기와 교체는 기존 선택을 무효화하는 동작으로 정해. 파일 선택창에서 취소만 했다면 기존 상태를 유지하지만, 실제 새 파일을 고르면 기존 첨부는 제외해. 새 파일에 문제가 있어도 옛 파일로 몰래 돌아가지는 않아.

같은 이름의 제안서라도 내용이 바뀌었다면 새 선택이야. 새 선택 버전과 별도 시도로 구분하고 서버에서도 이전 선택을 접수 대상에서 제외해. 통신 중단 요청만으로 이미 서버가 받은 파일까지 삭제됐다고 말할 수는 없어. 화면에서 뺀 것, 전송 중단, 임시 파일 정리는 각각 남겨야 해. 임시 파일 수명은 실제 운영 규칙을 확인해 따로 확정하고, 삭제 완료라는 문구는 확인된 범위에서만 써.

다시 보내기와 제출하기도 같은 기준으로 묶어

연결이 끊겼다고 바로 다시 전송하면 서버에는 이미 받은 파일이 있을 수 있어. 먼저 같은 업로드 시도의 결과를 조회해. 진행 중이면 새 전송을 만들지 않고, 확정 실패나 미수신을 확인한 뒤에만 재전송을 검토해. 같은 내용·같은 시도의 재전송이 중복을 만들지 않는지는 개발이 확인해야 해. 그 계약이 없으면 자동 재전송 대신 결과 확인과 명시적인 새 파일 선택을 제공해.

제출 버튼도 화면의 “첨부 완료” 글자만 믿지 않아. 서버가 현재 소유·접수 연결·선택 버전·검사 통과를 접수 확정과 일관되게 다시 확인해야 해. 접수 중에는 첨부를 바꾸지 못하게 하고, 접수 응답이 없으면 같은 접수 식별값으로 결과를 찾아. 접수 후 첨부는 편집 중인 선택과 분리해. 이 예제에는 접수 후 교체를 제공하지 않고, 필요하다면 별도 변경 절차를 설계할 거야.

AI에는 성공 화면보다 엇갈리는 순서를 물어봐

“파일 첨부 기획서를 써줘”라고만 하면 버튼과 오류 문구가 채워질 수는 있어. 하지만 이번에 확인하려는 건 선택과 응답의 순서가 바뀌어도 같은 파일이 제출되는지야. 예제 조건, 완료 기준, 지우기·교체 규칙을 먼저 주고 시작 상태와 늦은 응답까지 표로 받으면 빠진 조건을 대조하기 쉬워.

답에서 100% 뒤 제출을 허용한다면 그 줄을 그대로 채택하면 안 돼. 수신 미확인과 검사 대기를 분리하게 고치고, 지운 뒤 성공 응답이 오는 순서를 추가해 봐. 파일 이름으로만 연결하자는 답도 선택 버전과 서버 첨부 식별값으로 수정해야 해. 서버가 실제로 지원하는지는 개발 확인으로 남기고, 바뀐 조건을 화면 문구와 QA에 같이 반영해.

예시 질문이야. 실제로 실행한 대화는 아니야.
가상 워크숍 제안서 접수에서 필수 PDF 한 개를 첨부하는 기능을 검토해줘. PDF 1개, 1~10,000,000바이트까지 허용해. 빈 파일과 암호 파일은 거부하고 서버 내용 검사도 통과해야 해.
전송률 100%는 첨부 완료가 아니야. 서버 수신을 모르면 전송 결과 확인 중, 수신은 확인됐지만 검사가 안 끝났으면 파일 검사 중으로 보여줘. 현재 선택의 서버 검사 통과·첨부 식별값·접수 연결이 확인된 뒤에만 첨부 완료야.
파일을 새로 고르면 기존 첨부는 제외하고 새 선택을 시작해. 파일 선택창에서 취소만 한 경우에는 그대로 둬. 지우거나 교체한 파일의 늦은 응답은 적용하지 마. 같은 이름이어도 내용이 다르면 별도 선택이야.
결과를 모르면 실패로 단정하지 말고 같은 시도를 조회해. 같은 파일 전송을 재시도할 때는 서버가 보장하는 중복 방지 계약을 먼저 확인해야 해. 제출은 서버에서 현재 첨부의 소유·접수 연결·버전·검사 통과를 다시 확인해.
이 조건으로 시작 상태→사용자 행동→늦게 온 응답→화면 문구→제출 가능 여부를 표로 써줘. 정의되지 않은 서버 동작은 확인 필요로 남겨줘.
수정 지시 예시: 전송 100% 뒤 제출을 허용했다면 고쳐줘. 검사 중 지운 파일의 성공 응답과 같은 이름의 새 파일 응답이 뒤섞이는 순서를 추가해. 원래 제안서 입력값은 유지하고, 실제 제출 요청에 어느 첨부가 들어가는지도 QA에 써줘.

QA는 파일 하나 올려보는 걸로 끝내지 않아

작은 PDF가 한 번 올라갔다고 첨부 기능 전체가 맞는 건 아니야. 크기 경계와 빈 파일을 보고, 응답 순서를 바꿔보고, 같은 이름의 다른 파일로 교체해 봐. 예상 파일 식별값과 최종 접수에 연결된 값을 비교하면 이름은 맞는데 옛 파일이 들어가는 문제도 잡을 수 있어. 지연·끊김·과거 응답은 테스트 환경에서 재현하고 실제 결과를 남겨.

W3C의 상태 메시지 설명도 참고해서 진행·검사·완료를 글자로 알리고 초점을 불필요하게 옮기지 않도록 정해. 키보드로 파일을 고르고 오류에서 돌아올 수 있는지도 확인해. 아래 표는 검수할 순서와 기대 결과야. 이 글의 자료 화면이 동작하는 것과 실제 접수 서버·파일 검사·보조 기술이 검수를 통과하는 것은 따로 기록해야 해.

기획서에는 이유를, 설계서에는 바뀌는 조건을 남겨

기획서에는 왜 PDF를 받는지, 이번에 해결할 문제가 무엇인지, 왜 서버 확인을 완료 기준으로 골랐는지를 남겨. 설계서는 그 선택을 상태·문구·동작·예외로 풀어. 화면 번호만 나열하는 대신 “검사 중 지웠다면 늦은 응답은 반영하지 않는다”처럼 조건이 바뀔 때의 결과를 연결해야 다음 사람이 그대로 이어갈 수 있어.

개발에는 파일 검증·권한·중복·동시성·임시 파일 수명을 확인받고, QA에는 화면과 실제 첨부를 같이 비교하도록 넘겨. 운영에는 결과 미확인을 실패라고 안내하지 않도록 조회 가능한 상태와 확인 경로를 남겨. 출시 후에는 첨부 거부 사유, 미확인 상태에서의 이탈, 잘못 연결된 파일 신고를 구분해 보되 파일 내용은 분석 이벤트에 넣지 않아. 수치가 줄었다고 곧바로 좋아졌다고 말하지 않고, 접수 누락이 사라졌는지부터 대조할 거야.

필수 PDF 첨부 전달안 — 가상 워크숍 제안서 접수
목적: 사용자가 확인한 현재 파일만 검사 완료 후 제출에 포함한다. 파일 선택·전송·검사·접수를 별도 상태로 다룬다.
입력: PDF 1개, 1~10,000,000바이트 허용. 안내는 10MB 이하이며 여기서 10MB는 10,000,000바이트다. 빈 파일·암호 파일·서버 검사 미통과 파일은 첨부 완료 불가. 브라우저 제한은 안내이고 서버에서도 검증한다.
시작: 파일 선택창 취소는 기존 첨부를 유지한다. 실제 새 파일 선택은 기존 첨부를 제외하고 선택 버전을 올린다. 새 파일이 잘못됐어도 과거 파일로 자동 복귀하지 않는다. 제안서의 다른 입력값은 유지한다.
상태: 선택 전→전송 중→서버 수신 확인→파일 검사 중→현재 첨부 사용 가능. 전송률 100%만으로 완료 처리하지 않는다. 수신 결과 미확인은 전송 결과 확인 중, 수신 확인 후 검사 대기는 파일 검사 중으로 구분한다.
완료: 현재 선택 버전·업로드 시도와 일치하는 서버 첨부 식별값, 접수 연결, 검사 통과 결과가 있어야 한다. 같은 시도의 오래된 상태 응답이 최신 완료를 검사 중으로 되돌리지 않도록 서버 상태 버전도 비교한다.
거부: 유형·크기·빈 파일·암호·검사 실패별 수정 행동을 표시한다. 검사 서비스 장애는 파일 결함으로 단정하지 않는다. 이때 사용 가능으로 승인하지 않고 결과 확인/재시도 경로를 안내한다.
교체·지우기: 기존 응답 적용과 첨부 사용 가능 상태를 즉시 무효화하고, 서버에서도 해당 선택을 폐기/제외하도록 처리한다. 지운 뒤 늦은 성공으로 다시 첨부하지 않는다. 화면 제거·통신 중단·서버 임시 파일 삭제 완료는 서로 다르다.
같은 이름: 이름이 같아도 새 선택은 새 버전이다. 서버가 발급한 파일 식별값으로 연결하고 파일명만으로 덮어쓰지 않는다.
미확인: 같은 업로드 시도의 결과를 먼저 조회한다. 기존 시도가 진행 중이면 새로 전송하지 않는다. 확정 실패/미수신 후 재전송은 같은 내용·같은 시도에 대한 중복 방지와 상태 규칙을 개발이 확인한 경우에만 제공한다. 새 파일 교체는 새 시도다. 계약이 없으면 자동 재전송 대신 결과 확인과 명시적 새 선택을 제공한다.
제출: 필수 첨부가 준비되지 않으면 이유를 설명하고 제출 불가. 서버도 현재 소유·접수 연결·선택 버전·검사 통과를 접수 확정과 일관되게 재검증한다. 접수 중에는 첨부 변경을 막는다. 접수 결과 미확인은 같은 접수 식별값으로 조회하고 중복 접수하지 않는다.
접수 이후: 접수된 첨부는 현재 편집 상태와 분리한다. 이 예제에는 접수 후 교체를 제공하지 않는다. 임시 파일 만료·영구 보관·삭제 시점은 실제 서비스 규칙과 담당자 확인 후 별도 확정한다.
접근성: 기본 파일 선택 입력과 키보드를 제공한다. 상태는 색·퍼센트 외에 글자로 알리고 불필요한 초점 이동을 하지 않는다. 오류 뒤 파일 입력과 수정 안내에 접근할 수 있게 한다.
문서/담당: 기획서는 필수 첨부 이유와 완료 기준·대안 선택을, 설계서는 상태·문구·버전·요청/응답·예외를 남긴다. 개발은 검증·권한·중복·동시성·임시 파일 수명, QA는 순서별 UI와 실제 첨부 식별값, 운영은 확인 가능한 처리 상태와 안내를 맡는다.
검수: 경계값, 100%, 서버 거부, 검사 장애, 같은 이름 교체, 삭제 후 늦은 성공, 오래된 상태 응답, 결과 미확인, 최종 권한 변화, 접수 중 변경/중복을 실행해 환경·버전·기대/실제 결과·증거를 기록한다. 이 전달안은 실제 접수 서버의 통합검수 통과 기록이 아니다.

출처와 예제 조건

2026년 9월 30일 확인한 GOV.UK·OWASP·W3C 공개 자료를 참고한 독립 가상 안건이야. PDF 한 개·10MB·완료와 교체 정책은 이 예제의 설계 선택이야. 위키렙AI가 작성했고 회사 자료나 진명의 실제 경험·성과를 사용한 글은 아니야. AI 질문은 실행하지 않은 예시이며 EN/ZH는 같은 한국어 안건의 현지화야. 제공한 자료의 화면 검증과 실제 접수 시스템 통합검수는 구분해.

GOV.UK Design System — File upload

OWASP — File Upload Cheat Sheet

W3C — Understanding WCAG 2.2, Status Messages