오래 걸리는 내보내기 UX: 진행 상태와 다운로드 복구 설계

큰 파일을 내보낼 때 회전 아이콘만 보여 주면 사용자는 작업이 시작됐는지, 다른 화면으로 이동해도 되는지, 완성된 파일을 어디에서 찾는지 알 수 없습니다. 다운로드 기한이 지나면 어떻게 해야 하는지도 필요합니다. 여기서는 42개 화면을 묶어 디자인 인계 패키지를 만드는 가상의 팀을 예로 듭니다. 기다림부터 결과 수령까지 하나의 작업으로 설계하고, 각 상태를 Pixso 프로토타이핑에서 연결해 검토합니다.

작업의 범위와 완료 결과부터 정의하기

예시 패키지에는 선택한 화면 42개, 현재 디자인 명세, 연결된 자산 목록이 들어갑니다. 요청자는 형식을 선택하고 생성을 시작합니다. 대기 화면을 만들기 전에 패키지에 무엇이 포함되는지, 탭을 닫아도 서버가 계속 처리하는지, 완성된 패키지를 어디에 나열하는지, 다운로드 링크가 언제 만료되는지를 결정해야 합니다. 이는 제품과 백엔드의 규칙이며 보기 좋은 진행 애니메이션으로 대신할 수 없습니다.

요청 화면에는 ‘Autumn launch의 화면 42개’, 선택한 형식, 저장 위치를 명시합니다. 일부 화면을 포함할 수 없다면 시작 전에 알리거나 완료 후 빠진 화면을 정확히 밝힙니다. 내용이 빠진 결과를 아무 조건 없이 ‘내보내기 완료’라고 부르지 않습니다. 이 가상 사례에서는 완성된 파일을 7일 동안 받을 수 있도록 설정하지만, 이는 Pixso의 보관 기간이나 내보내기 기능에 대한 설명이 아닙니다.

요청마다 다시 찾을 수 있는 고유 작업 ID가 필요합니다. 사용자가 다른 화면으로 이동했다 돌아왔을 때 같은 작업을 찾지 못하면 중복으로 시작할 수 있습니다. 두 번째 클릭이 기존 작업을 열지, 새 버전을 만들지, 중단된 작업을 재개할지는 백엔드 계약에 따라 정하고 화면도 그 규칙을 따라야 합니다.

시스템이 모르는 진행률은 보여 주지 않기

‘패키지 준비 중’이라는 상태는 다음 단계가 보일 때 의미가 있습니다. 전체 작업량을 모르는 상태에서 ‘73%’를 보여 주는 것은 근거 없는 약속입니다. 이 예시에서 서버는 ‘대기 중’, ‘파일 수집 중’, ‘패키지 생성 중’, ‘준비 완료’를 알려 주지만 남은 시간을 안정적으로 계산하지 못합니다. 따라서 현재 단계와 완료 비율을 주장하지 않는 활동 표시를 사용합니다. 나중에 전체 단위를 일관되게 측정할 수 있다면 수치형 진행 막대를 사용할 수 있습니다.

처리가 여러 단계라면 첫 단계가 끝났다는 이유로 전체를 100%라고 표시하지 않습니다. ‘파일 수집 중’ 다음에 ‘패키지 생성 중’이 이어진다는 것을 말로 알려 줍니다. 선택한 화면 일부가 제외되어 측정 대상이 바뀌었다면 그 이유를 설명하고 숫자만 갑자기 낮추지 않습니다. 진행 표시는 화면 장식이 아니라 사용자의 질문에 답해야 합니다.

다른 화면으로 가도 작업을 잃지 않게 하기

서버가 화면을 떠난 뒤에도 계속 처리한다면 몇 분 동안 모달 앞에 사용자를 붙잡아 둘 필요가 없습니다. 예시에서는 ‘다른 작업을 계속할 수 있습니다. 결과는 내보내기 목록에서 확인하세요’라고 안내합니다. 사용자는 패널을 닫고 다른 디자인 파일을 연 뒤 나중에 목록으로 돌아옵니다. 목록에는 동일한 작업의 이름, 시작 시각, 현재 단계, 지금 실행할 수 있는 동작을 보여 줍니다.

탭을 닫으면 서버 처리도 멈추는 제품이라면 백그라운드에서 계속된다고 약속하지 않아야 합니다. 이것은 문구 작성 전에 해결할 기능 요건입니다. 완료 알림은 도움이 되지만 놓치거나 꺼 둘 수 있습니다. 결과로 돌아오는 안정적인 경로는 목록에 남아 있어야 합니다.

입력이 같은 여러 작업도 구분할 수 있게 합니다. 모두 ‘내보내기’라고 적는 것보다 ‘Autumn launch — PDF — 10:42 시작’이 찾기 쉽습니다. 패널을 닫는 동작과 서버 작업을 취소하는 동작을 분리합니다. 화면을 떠났다고 실제 생성 작업까지 중단된 것처럼 보이면 안 됩니다.

‘준비 완료’를 실제 다운로드로 연결하기

완료 화면에는 파일 이름과 형식, 확인할 수 있는 경우 크기, ‘패키지 다운로드’ 동작을 표시합니다. 이 사례처럼 링크가 7일 동안 유효하다면 사용자 지역에 맞는 날짜와 시각으로 만료 시점을 보여 줍니다. ‘잠시 이용 가능’이라는 문구로는 다음 날 동료에게 파일을 전달할 수 있을지 알 수 없습니다. 보관 기간 중에는 목록에서 같은 작업으로 돌아올 수 있게 합니다.

서버의 패키지 생성 완료와 브라우저의 저장 성공은 별개입니다. 다운로드 차단, 연결 끊김, 기기 저장 공간 부족이 생겨도 서버의 결과물까지 ‘실패’로 바꾸지 않습니다. 서버의 보관 기간이 끝날 때까지 준비 완료 상태를 유지합니다. HTTP Content-Disposition 설명은 첨부 파일로 내려받게 하고 추천 파일명을 제공하는 방법을 다룹니다. 하지만 기술적 헤더만으로 화면의 명확한 파일명과 다운로드 버튼을 대신할 수 없습니다.

링크가 만료되면 일반 404 페이지로 보내지 않습니다. ‘이 패키지는 더 이상 사용할 수 없습니다’라는 안내와 패키지 이름을 보여 주고, 이전 선택 범위가 아직 유효하다면 그 범위를 선택한 채 새 작업을 시작하게 합니다. 원본 디자인이 변경되었다면 새 패키지는 현재 버전을 반영한다는 점을 알리고 이전 파일과 완전히 같다고 약속하지 않습니다.

실패와 결과 불확실성을 구분해 복구하기

오류를 모두 같은 ‘실패’로 취급하지 않습니다. 시작 전 검증 오류라면 부족한 권한, 사용할 수 없는 화면, 지원하지 않는 형식을 구체적으로 알려 줍니다. 시작 후 처리 실패라면 작업 기록을 유지하고 사용할 수 있는 패키지가 없음을 설명한 뒤 안전할 때 재시도를 제공합니다. 다운로드 기한 만료는 처리 실패와 다른 상태입니다.

요청 전송 중 네트워크가 끊긴 경우는 특히 애매합니다. 브라우저가 응답을 받지 못했어도 작업이 생성되었을 수 있습니다. ‘다시 시도’를 제시하기 전에 요청 ID로 조회하거나 내보내기 목록을 확인합니다. 그렇지 않으면 같은 큰 작업이 두 번 생길 수 있습니다. 재시도가 기존 작업의 재개인지, 새 버전의 생성인지, 일부 결과의 활용인지도 실제 서비스 규칙과 맞춰야 합니다.

취소 버튼을 둔다면 서버 처리를 실제로 중단할 수 있는지, 부분 파일이 남는지, 언제 ‘취소됨’으로 바뀌는지를 정합니다. 진행 패널만 숨기면서 ‘내보내기 취소’라고 쓰면 잘못된 기대를 만듭니다. 취소할 수 없다면 ‘패널 닫기’가 정확합니다.

상태를 접근 가능하게 알리고 전체 흐름을 검토하기

각 작업에 읽을 수 있는 이름을 붙이고 바뀌는 상태를 색뿐 아니라 텍스트로 전달합니다. 수치형 진행 막대는 현재 값과 범위를 보조 기술에 전달하고, 전체량을 모르면 값을 만들어 넣지 않습니다. W3C의 meter 지침은 수치를 보여 주는 계기와 작업 진행을 구별하며, 진행에는 progressbar 역할을 사용한다고 설명합니다. 상태 업데이트를 알리는 라이브 영역 기법도 참고할 수 있습니다. 시각적인 막대만으로는 화면 읽기 사용자에게 변경이 자동으로 전달되지 않을 수 있습니다.

요청 화면, 대기, 처리 단계, 백그라운드 목록, 준비 완료, 만료, 실패, 전송 결과 불명 상태를 Pixso에 그립니다. ‘화면에 머무는 경로’와 ‘떠났다가 돌아오는 경로’를 각각 연결합니다. 검토자에게 ‘작업이 아직 진행 중인가?’, ‘완성품은 어디에 있나?’, ‘다운로드가 만료되면 어떻게 하나?’를 물어봅니다. 대답을 추측해야 한다면 상태와 문구를 고칩니다.

개발자에게는 실제 작업 상태 이벤트, 보관 정책, 재시도 방식, 권한 규칙과 함께 프로토타입을 전달합니다. Pixso는 상호작용을 설계하고 검토하는 도구이며, 운영 환경의 파일 생성과 배포는 해당 서비스가 구현해야 합니다. Pixso에서 내보내기 흐름 설계하기.