제출한 파일 교체 UX: 검토 의견과 버전 맥락을 지키는 방법

제출한 파일을 교체하는 일은 업로드를 다시 시도하는 것과 다릅니다. 새 파일이 정확하더라도 기존 파일에 달린 검토 의견, 승인 맥락, 수정 요청의 근거가 사라지면 검토자는 처음부터 다시 확인해야 합니다. 화면을 설계할 때 먼저 답해야 할 질문은 활성 파일이 바뀌어도 제출 건에는 무엇이 남는가입니다.

Pixso에서 화면과 검토 흐름을 함께 설계하면 기존 파일, 교체 확인, 완료 상태를 나란히 볼 수 있습니다. 아래에서는 예산표 수정 요청을 받은 가상의 프로젝트 계획서 PDF를 예로 듭니다. 여기서 설명하는 제출·승인 동작은 설계할 포털의 요구사항이지, Pixso가 업로드 문서를 보관하거나 승인한다는 뜻은 아닙니다.

빈 업로드 칸이 아니라 이미 접수된 제출 건에서 시작하기

일반적인 업로드 화면에는 아직 접수된 파일이 없습니다. 그러나 이 사례에서는 Project_Plan_v1.pdf가 이미 검토 중입니다. 검토자가 6쪽 예산표의 수정을 요청했고 제출자는 Project_Plan_v1_corrected.pdf를 선택합니다. 이때 버튼에 단순히 '파일 업로드'라고 쓰여 있으면 파일을 하나 더 첨부하는지, 활성 파일을 바꾸는지, 새 제출 건을 만드는지 알 수 없습니다.

파일을 고르기 전에 현재 파일명과 상태, 검토자의 요청을 보여 주세요. 실제로 활성 첨부 파일을 바꾸는 경우에만 '현재 파일 교체'라고 표시합니다. 여러 첨부 파일을 동시에 활성 상태로 두는 서비스라면 '파일 추가'가 더 정확합니다. 결과가 다른 두 동작에 같은 모호한 이름을 쓰지 마세요.

확정 전에 이전 파일과 새 파일을 비교하게 하기

확인 화면은 현재 어떤 파일이 활성 상태인지, 어떤 파일이 활성화될 예정인지, 이전 버전과 검토 대화가 어떻게 되는지 알려줘야 합니다. 두 파일명을 나란히 놓고 필요한 경우 크기나 업로드 시간도 표시합니다. 단, 메타데이터를 비교하는 것을 PDF 내용의 차이 분석처럼 표현해서는 안 됩니다. 신뢰할 수 있는 내용 비교 기능이 없다면 있는 것처럼 암시하지 마세요.

이 예에서는 교체가 성공하기 전까지 기존 파일을 활성 상태로 유지하는 편이 안전합니다. 대화상자를 닫거나 연결이 끊겨도 원래 제출 건은 남아야 합니다. 개인정보 보호나 보존 정책에 따라 이전 파일을 삭제한다면 확정 전에 그 결과를 알려야 합니다. 실제 보존 정책을 확인하지 않고 무기한 버전 기록을 약속해서도 안 됩니다.

검토 의견을 제출 건에서 떼어 놓지 않기

'6쪽을 수정해 주세요'라는 의견은 첫 PDF의 바이트에만 관한 것이 아니라 검토 중인 작업에 관한 요청입니다. 교체 후에도 같은 제출 건 ID, 연결된 의견 대화, '이 요청에 따라 교체함'이라는 짧은 이력을 통해 수정 파일에서 요청으로 되돌아갈 수 있게 합니다. 정확한 데이터 모델은 제품마다 다르지만, 관련 없는 새 제출 건을 조용히 만드는 것은 피해야 합니다.

그렇다고 기존 PDF 6쪽에 꽂힌 핀을 새 PDF의 동일한 좌표에 옮겨서는 안 됩니다. 페이지 순서나 레이아웃이 달라졌을 수 있습니다. 이전 버전에 달린 의견임을 표시하고 검토자가 새 파일의 해당 내용을 다시 확인하도록 하는 편이 안전합니다. 그다음 수정 내용을 수락하거나, 재수정을 요청하거나, 이번 교체와 별개의 문제로 처리할 수 있습니다.

검토자가 이전 버전을 열어 둔 동안의 규칙 정하기

제출자가 수정 파일을 고르는 동안 검토자는 아직 기존 파일을 읽고 있을 수 있습니다. 열린 문서를 예고 없이 바꾸지 마세요. 이전 버전 검토를 계속하게 하면서 새 버전 도착을 알릴 수도 있고, 교체 완료 전까지 승인을 일시 중지할 수도 있습니다. 비공식 피드백인지, 규제 대상 승인인지, 법적 기록인지에 따라 맞는 규칙은 다릅니다. 두 사람이 서로 다른 파일을 '현재 버전'으로 여기지 않도록 명시적으로 결정해야 합니다.

예를 들어 검토자가 10시 02분에 이전 PDF를 열었고 제출자가 10시 04분에 교체를 마쳤다고 가정해 봅시다. 6쪽에 단 의견은 검토자가 실제로 본 버전에 남아야 합니다. 10시 05분에 검토자가 '승인'을 누르면 이전 버전을 승인하는지, 수정 버전을 다시 본 뒤 승인하는지, 어느 쪽도 승인하지 않는지 분명해야 합니다. 버튼 옆의 버전 표시와 짧은 상태 안내가 애매한 녹색 배지보다 유용합니다. 구현을 확정하기 전에 두 브라우저 세션으로 흐름을 시험하세요.

실패와 취소의 결과를 분명하게 보여 주기

전송 전에는 지원하지 않는 형식, 빈 파일, 용량 초과를 확인할 수 있습니다. 전송 중 진행률은 측정한 전송 상태이지, 서버 검증과 파일 교체까지 끝났다는 증거가 아닙니다. 전송 후 검사에서 거부될 수도 있습니다. 단계를 나눠 보여 주면 새 버전을 사용할 수 있는지 확인하기 전에 '완료'라고 잘못 알리지 않을 수 있습니다.

전송이 78%에서 끊겼다면 기존 파일이 계속 활성 상태임을 알려 주고 안전하게 다시 시도할 수 있게 합니다. 수정 PDF가 거부됐다면 구체적인 이유를 보여 주고, 검토 요청을 잃지 않은 채 다른 파일을 고르게 합니다. 확정 전 취소는 변경이 없었던 원래 제출 화면으로 돌아가야 합니다. 파일 업로드 UI 가이드(영어)는 선택과 진행률, 전송 오류를 다룹니다. 여기에서 추가로 고려할 문제는 이미 접수된 검토 기록을 지키는 것입니다.

GOV.UK의 파일 업로드 가이드에는 구체적인 오류 문구의 예와 보안·개인정보 보호를 고려한 기존 업로드 파일 재사용 원칙이 있습니다. 하지만 검토 이후의 교체 규칙은 각 제품의 정책에 맞게 정해야 합니다.

화면을 보는 사람과 보조 기술 사용자 모두에게 상태 알리기

'검토 중'에서 '교체 완료'로 바뀌는 중요한 상태를 색상만으로 표현하지 말고 텍스트로도 표시하세요. 포커스를 갑자기 옮기지 않고 진행 상태와 성공 여부를 알릴 수 있어야 합니다. W3C의 상태 메시지 설명은 포커스가 이동하지 않는 변화도 보조 기술 사용자에게 전달되어야 하는 이유를 다룹니다. 업로드 진행률 예시는 한 가지 구현 방법이지, 매 퍼센트를 지나치게 자주 읽어 주라는 뜻이 아닙니다.

키보드만으로 교체 화면을 열고 두 파일명을 확인하고 취소 또는 확정한 뒤 제출 화면의 적절한 위치로 돌아갈 수 있어야 합니다. 열어 두었던 검토 의견으로 다시 가는 길도 남겨 둡니다. 좁은 화면에서는 파일 카드를 세로로 배치해도 되지만 위치만으로 이전 파일과 새 파일을 구분하지 말고 각 버전을 명확히 표시하세요.

Pixso에서 의사결정 흐름을 프로토타입으로 만들기

Pixso 캔버스에 수정 요청이 붙은 제출 파일, 이전·새 버전을 비교하는 확인 화면, 수정 파일과 연결된 검토 대화가 보이는 완료 화면을 나란히 둡니다. 실패 화면도 추가하세요. 그러면 디자이너와 개발자가 기존 파일의 보존 여부, 활성 버전의 표시, 검토 의견에 다시 접근하는 방법을 함께 검토할 수 있습니다. 캔버스 안의 파일 카드는 설계 예시이며 Pixso 자체의 첨부 기능이 아닙니다.

검토자에게 실제 수정 요청을 제시하며 '이전 의견은 지금 어디에 있나요?'라고 물어보세요. 제출자에게는 '전송이 실패하면 상대방에게 어떤 파일이 보이나요?'라고 묻습니다. 추측해야만 답할 수 있다면 그림자나 애니메이션을 다듬기 전에 상태 문구부터 고쳐야 합니다. 각 결과에서 활성 파일, 남는 검토 맥락, 복구 방법을 팀이 설명할 수 있을 때 개발에 넘길 준비가 된 것입니다.