오래 걸리는 보고서 생성, 앱과 서버는 어떻게 나눠 처리할까요?

조건을 통과하면 서버가 작업 번호를 부여하고 요청자·조회 기간·생성 상태를 저장하도록 설계합니다. 작업 번호 RPT-2101의 첫 상태는 ‘대기’입니다. 이때 저장하는 것은 완성된 엑셀 파일이 아니라, 누가 어떤 조건으로 무엇을 만들라고 요청했는지에 관한 작업 기록입니다.

API는 이 기록을 남긴 뒤 202 Accepted와 작업 번호, 상태를 조회할 주소를 돌려주도록 정합니다. 202 응답은 요청을 처리 대상으로 받았다는 의미이며 실제 처리가 끝났거나 반드시 성공한다는 보장은 아닙니다. 앱도 이 응답을 받으면 ‘보고서 생성 요청을 접수했습니다’라고 안내해야 합니다.

작업자는 RPT-2101을 실행할 대상으로 확보한 뒤 상태를 ‘처리 중’으로 바꾸고, 저장된 기간과 허용된 데이터 범위로 업무 기록을 읽도록 설계합니다. 실행 시점에도 요청자가 원본 기록에 접근할 수 있는지 다시 확인합니다. 앱에서 나중에 다른 기간을 선택해도 이미 접수한 작업의 조건이 저절로 바뀌지 않게 합니다. 같은 작업을 두 작업자가 동시에 실행하지 않도록 가져오는 기준도 서버에 둡니다.

파일을 만든 뒤에는 결과를 보관하고, 그 파일이 어느 작업의 결과인지 연결해야 합니다. 파일을 쓰는 도중이거나 결과를 받을 준비가 되지 않았다면 ‘완료’로 바꾸지 않습니다. 이런 요청과 실행의 분리는 비동기 요청·응답 구조의 한 형태입니다.

상태를 확인하기 위해 매 순간 요청을 보낼 필요는 없습니다. 화면이 열려 있을 때 정해진 간격으로 조회하고, 화면을 벗어나면 반복 조회를 멈추도록 구성할 수 있습니다. 다시 들어왔을 때는 새 생성 요청 대신 기존 작업 기록부터 읽습니다. 실제 처리량을 알 수 없다면 시간이 지났다는 이유로 진행률을 만들어 올리지 않습니다.

새로고침과 재진입을 이어주려면 현재 화면의 기억에만 작업 번호를 보관해서는 부족합니다. 서버에 요청자의 작업 기록을 남기고, 앱이 본인의 작업 목록이나 상세 화면에서 같은 번호를 다시 찾도록 설계합니다. 화면을 닫는 행동과 서버 작업을 취소하는 행동도 구분합니다.

반면 작업자가 파일 생성이나 보관을 끝내지 못했다는 결과를 기록했다면 실행 실패로 다룰 수 있습니다. 이때는 실패 이유와 해당 시도를 남기고, 불완전한 파일을 완료 결과로 제공하지 않습니다. 단순히 오래 걸린다는 이유만으로 실패를 확정하지 않는 것입니다.

예를 들어 결과 파일을 보관하는 단계에서 실패가 확인됐다면, 기존 작업과 요청 조건을 유지한 채 재처리 여부를 결정할 수 있습니다. 재처리를 허용할 때도 서버가 현재 상태와 시도 기록을 확인해야 합니다. 이미 다시 처리 중인 일을 버튼을 한 번 더 눌렀다고 별도로 시작하지 않게 하는 기준이 필요합니다.

최초 접수 응답 자체를 받지 못한 경우에도 새 작업부터 만들면 안 됩니다. 요청을 구분하는 값과 서버의 접수 기록을 대조해 같은 요청의 작업이 있는지 먼저 확인하도록 정합니다. 이 글의 중심은 접수 이후의 실행 구조이며, 요청 유실과 중복 방지의 세부 처리는 별도로 연결되는 문제입니다.

하지만 작업 번호나 파일 주소를 안다는 이유만으로 누구나 결과를 받아서는 안 됩니다. 서버는 작업 상태를 조회할 때와 파일을 받을 때 각각 현재 요청자의 접근 권한을 확인해야 합니다. 화면에서 버튼을 숨기는 것만으로 파일을 보호할 수는 없습니다. OWASP 권한 관리 안내도 개별 요청과 파일 같은 자원에 대한 접근 확인을 강조합니다.

또한 보고서 조건을 저장했다고 요청 당시의 모든 데이터 값까지 고정되는 것은 아닙니다. 여기서는 작업자가 조회할 때의 업무 기록을 사용하도록 정합니다. 접수 시점의 값이 그대로 필요한 보고서라면 데이터를 고정하는 별도 기준이 필요합니다.