관리자 화면에 ‘엑셀 다운로드’ 버튼을 붙이는 일은 쉬워 보인다. 하지만 데이터가 많아지면 요청이 오래 걸리고, 사용자가 새로고침해 같은 파일을 여러 번 만들고, 파일이 저장된 뒤에는 원래 볼 수 없던 고객 데이터까지 다운로드될 수 있다. 게다가 고객이 입력한 문자열이 CSV에서 스프레드시트 수식으로 해석될 수도 있다. 내보내기는 화면 기능이 아니라 데이터를 외부로 내보내는 별도 업무다.
내보내기 설계는 ‘어떤 데이터를, 누가, 어느 시점 기준으로, 어떤 파일로 가져가도 되는가’에서 출발한다. 특히 B2B SaaS라면 고객사 경계와 개인정보 범위가 화면 조회와 똑같이 적용돼야 한다. 화면에서 볼 수 있다는 사실이 모든 행을 한번에 가져갈 권한을 자동으로 뜻하지는 않는다.
빠른 요청과 오래 걸리는 작업을 분리한다
작은 파일은 즉시 생성해도 되지만 시간이 오래 걸리는 내보내기를 웹 요청 하나에 묶으면 타임아웃과 재시도 문제가 생긴다. 사용자가 범위와 형식을 선택해 요청하면 서버는 권한과 입력을 확인하고 작업 ID를 돌려준다. 백그라운드 작업이 파일을 만들고 상태를 ‘대기·진행·완료·실패’로 갱신한다. 완료된 파일은 허용된 사용자에게만 제한된 기간 동안 제공한다. Microsoft의 비동기 요청-응답 패턴은 오래 걸리는 작업을 별도 처리하고 상태 엔드포인트로 결과를 확인하는 구조를 설명한다.
작업이 만든 파일을 항상 공개 URL에 두면 작업 ID나 경로를 추측한 사람이 가져갈 수 있다. 다운로드 시 고객사·사용자 권한을 다시 검사하거나 짧게 유효한 접근 수단을 사용한다. 계정 권한이 요청과 다운로드 사이에 바뀔 수도 있으므로 ‘처음 허용했으니 끝까지 허용’이라고 가정하지 않는다. 파일 생성·다운로드·만료는 감사 가능한 이벤트로 남긴다. 만료 후 삭제 정책을 정하고 실패 파일도 정리한다.
내보내기 권한은 조회 권한보다 더 좁힐 수 있다. 화면에서는 한 페이지씩 보이는 정보라도 파일로 받으면 검색·복제·외부 전송이 쉬워지기 때문이다. 범위가 큰 파일에는 관리자 승인이나 추가 확인을 둘 수 있고, 다운로드 화면에는 포함된 고객사·기간·열 목록을 명확히 표시한다. 보안팀과 운영팀이 누가 어떤 범위의 파일을 생성하고 가져갔는지 재구성할 수 있어야 한다.
‘현재 화면 그대로’인지 ‘요청 시점 기준’인지 정한다
검색 결과와 CSV 행 수가 다르면 사용자에게 버그처럼 보인다. 버튼을 누를 때의 필터, 정렬, 고객사, 시간 범위를 작업에 고정해야 한다. 다만 파일 생성 중 원본 데이터가 바뀐다면 ‘요청 시점 스냅샷’인지 ‘생성 시점 최신 데이터’인지 정책을 분명히 해야 한다. 모든 데이터를 한 번에 메모리로 읽지 말고 페이지나 스트림으로 처리하며, 대량 내보내기가 운영 DB를 압박하지 않도록 작업 동시성과 자원 사용을 제한한다. 진행 상태를 보여 주더라도 정확한 백분율을 계산할 수 없다면 임의 숫자를 표시하지 않는다.
CSV는 텍스트 파일이지만 스프레드시트에서는 코드처럼 해석될 수 있다
고객 이름이나 메모가 수식 시작 문자로 시작하면, CSV를 스프레드시트에서 열 때 단순 텍스트가 아닌 수식으로 처리될 수 있다. OWASP의 CSV Injection 설명은 구분자와 따옴표 때문에 셀 중간 입력이 새 셀의 시작이 되는 경우까지 주의하라고 말한다. 같은 자료는 모든 스프레드시트 앱과 모든 후속 처리에 통하는 만능 이스케이프 방식은 없다고 경고한다.
따라서 소비자가 사람의 엑셀 열람인지, 다른 시스템의 CSV 재입력인지 먼저 나눈다. 사람이 볼 파일이라면 대상 스프레드시트 앱에서 위험 문자, 구분자, 줄바꿈, 저장 후 재열기까지 시험한다. 기계가 다시 읽어야 하는 파일은 내용 보존이 중요하므로 ‘보안 처리’라며 데이터를 조용히 바꾸지 않는다. 필요하면 목적별로 별도 형식이나 다운로드 경로를 제공한다. 무조건 앞에 작은따옴표 하나를 붙였으니 안전하다고 선언하지 않는다.
파일의 사용성도 품질이다. 열 이름, 시간대, 문자 인코딩, 빈 값 표현, 숫자의 선행 0, 큰 정수의 변형 가능성을 사전에 정한다. 예를 들어 고객번호가 숫자로만 보인다고 엑셀이 임의로 숫자 서식을 적용하면 원래 식별자와 달라질 수 있다. 열 순서와 의미가 바뀌면 후속 업무가 깨질 수 있으므로 내보내기 형식에 버전과 변경 공지를 두는 것도 방법이다.
운영자가 확인할 결과를 정의한다
성공 기준은 파일이 생성됐다는 표시가 아니다. 선택한 고객사만 들어 있는지, 행 수와 기준 시각이 맞는지, 필수 열의 값이 깨지지 않았는지, 다운로드 권한이 바뀌었을 때 거부되는지 확인한다. 파일 생성이 실패하면 사용자에게 재시도 가능 여부를 알리고, 서버에는 원인을 추적할 작업 ID를 남긴다. 반복 다운로드가 불필요한 부하를 만들지 않도록 동일 요청 처리 정책도 정한다.
내보내기 체크리스트
- 권한과 고객사 범위를 요청·다운로드 양쪽에서 확인한다.
- 필터와 데이터 기준 시점을 명시한다.
- 오래 걸리는 작업은 상태가 있는 비동기 처리로 분리한다.
- 파일 저장 위치와 만료·삭제 정책을 둔다.
- 운영 DB 부담과 동시 작업 수를 제한한다.
- CSV 수식 주입을 대상 스프레드시트에서 시험한다.
- 사람 열람용과 시스템 재입력용 파일의 요구를 구분한다.
안전한 내보내기는 ‘다운로드가 된다’와 ‘의도한 데이터만 안전하게 전달된다’의 차이를 메우는 일이다. 버튼을 만들기 전에 데이터 범위와 후속 사용 방식을 먼저 합의하면, 속도와 보안 문제를 함께 줄일 수 있다.
