직원이 한 달치 데이터를 내려받으려고 ‘보고서 생성’을 누릅니다. 화면은 계속 돌아가고, 새로고침하면 처음부터 다시 해야 하는지조차 알 수 없습니다. 오래 걸리는 작업의 가장 큰 UX 문제는 느린 속도 자체보다 지금 무엇이 확정됐는지 모르는 상태입니다. 서버는 이미 요청을 받았는데 브라우저가 응답을 잃었다면 사용자는 다시 누르고, 두 건의 작업이 실행될 수도 있습니다. 반대로 화면을 닫았다고 서버 작업이 멈춘 것은 아닙니다. 이 차이를 API와 UI가 같은 언어로 설명해야 합니다.
접수와 완료를 분리해 계약한다
수 초 이상 걸릴 수 있는 분석·내보내기·일괄 변경이라면 요청 직후 작업 식별자를 돌려주고 별도 작업자로 처리하는 방식을 검토합니다. Microsoft의 비동기 요청·응답 패턴은 HTTP 202로 접수를 알리고 상태 조회 주소를 제공하는 방법을 설명합니다. 202는 결과 파일이 준비됐다는 뜻이 아닙니다. 상태 API에는 최소한 대기, 실행, 성공, 실패, 취소 요청 중, 취소 완료 같은 상태와 생성·갱신 시각을 담습니다. 사용자는 같은 작업 ID로 화면을 다시 열어도 상태를 이어서 봐야 합니다.
요청할 때는 입력을 먼저 검증하고, 현재 사용자가 해당 데이터에 접근할 수 있는지 확인합니다. 작업이 큐에서 한참 기다린 뒤에야 권한 오류가 발견되면 사용자는 시간을 버립니다. 동시에 작업 결과를 조회하는 시점에도 권한을 다시 확인해야 합니다. 한 고객사의 작업 ID를 다른 고객사가 알아도 상태나 결과 파일을 볼 수 없어야 합니다. 상태 주소는 단순한 난수 문자열이라는 이유만으로 안전하지 않습니다. 작업과 고객사·요청자를 서버에서 연결해 검증합니다.
진행률 숫자는 근거가 있을 때만 보여 준다
총 대상 건수가 확정되고 처리 단위가 균일하다면 처리 건수와 전체 건수를 보여 줄 수 있습니다. 하지만 외부 API 호출, 변동하는 데이터량, 마지막 압축 단계가 있는 작업에서 백분율을 억지로 계산하면 99%에서 오래 멈춥니다. 이때는 ‘대기 중’, ‘자료 읽는 중’, ‘파일 만드는 중’ 같은 단계와 마지막 갱신 시각이 더 정직합니다. 단계별 예상 시간은 측정값이 충분할 때만 제시합니다. 화면에는 작업 완료 알림과 다시 들어갈 수 있는 위치, 실패 시 재시도 방법도 함께 표시합니다.
취소는 UI에서 버튼을 숨기는 문제가 아니라 서버와 작업자의 협약입니다. 사용자가 취소를 요청하면 우선 ‘취소 요청 중’으로 바꾸고, 작업자가 안전한 중단 지점에서 이를 확인한 뒤 ‘취소 완료’로 확정합니다. 이미 외부로 발송한 이메일이나 완료된 결제를 되돌릴 수 없다면 취소 가능 범위를 정직하게 알려야 합니다. 단계별 중간 결과와 임시 파일은 취소 후 정리하고, 외부에 반영된 결과가 있다면 보상 절차나 수동 조치를 준비합니다. 취소 요청과 성공이 동시에 도착하는 경합도 테스트해야 합니다.
작업자 프로세스가 중간에 죽을 때도 상태가 영원히 ‘실행 중’으로 남지 않아야 합니다. 마지막 갱신 시각과 작업자 소유권을 기록하고, 일정 기간 갱신되지 않은 작업은 재시도 가능한지 또는 담당자 검토가 필요한지 판정합니다. 재시작 후 같은 파일을 두 번 만들거나 고객에게 같은 알림을 두 번 보내지 않도록 단계별 완료 기록을 남기는 것이 좋습니다.
중복 클릭과 잃어버린 응답을 함께 다룬다
제출 버튼을 잠깐 비활성화하는 것만으로 중복 작업을 막을 수는 없습니다. 네트워크 오류로 응답만 잃으면 사용자는 다시 보냅니다. 동일한 요청 키에 같은 작업 ID를 돌려주는 멱등성 계약을 두고, 키의 적용 범위와 유효 기간을 정의하세요. 작업 완료 후 결과 파일의 보관 기한과 재생성 가능 여부도 UI에 알려 줘야 합니다. 실제 점검은 새로고침, 뒤로 가기, 브라우저 종료, 중복 제출, 취소 직후 완료, 작업자 재시작에서 시작합니다. 오래 걸리는 기능은 빠르게 끝나는 것처럼 꾸미는 것보다 끝날 때까지 상태를 잃지 않게 하는 것이 중요합니다.
