무거운 엑셀 다운로드 요청을 사전에 판별하는 방법

엑셀 다운로드 기능을 운영하다 보면 모든 요청을 같은 방식으로 처리하기 어렵다는 사실을 금방 체감하게 된다. 어떤 요청은 수백 건 수준이라 즉시 응답해도 무리가 없지만, 어떤 요청은 수십만 건을 읽어야 해서 비동기 처리로 넘겨야 한다.

문제는 사용자가 요청을 보내기 전까지는 그 비용이 겉으로 드러나지 않는다는 점이다. 그래서 필요한 것이 사전 판별 로직이다. 이 글에서는 “이 요청은 즉시 처리해도 되는가, 아니면 비동기로 넘겨야 하는가”를 어떻게 판단할 수 있는지 정리한다.

왜 사전 판별이 필요한가

엑셀 다운로드는 단순히 조회 건수만 많다고 느린 것이 아니다.

• 조인이 많을 수 있다.
• 정렬 기준이 무거울 수 있다.
• 필터가 넓어 풀스캔이 발생할 수 있다.
• 생성 단계에서 메모리 사용량이 커질 수 있다.

따라서 요청을 받은 뒤에야 “생각보다 무거웠다”는 사실을 알게 되면 늦다. 이미 웹 서버와 DB 자원을 사용하기 시작했기 때문이다.

판단 기준을 한 가지에만 의존하면 안 된다

가장 단순한 기준은 예상 row 수다. 하지만 row 수만으로는 충분하지 않다.

예를 들어:

• 5만 건이지만 단순 조회면 빠를 수 있다.
• 5천 건이어도 복잡한 조인과 정렬이면 느릴 수 있다.

그래서 보통 다음 요소를 같이 본다.

1. 예상 결과 건수
2. 필터의 범위
3. 정렬 유무
4. 조인 수
5. 과거 동일 요청의 실행 시간

1. 예상 결과 건수로 1차 필터링

가장 현실적인 시작점은 COUNT(*) 또는 이에 준하는 추정치를 보는 것이다.

예:

SELECT COUNT(*)
FROM target_table
WHERE ...

이 값이 임계치를 넘으면 즉시 다운로드 대신 비동기 큐로 보낼 수 있다.

예시 정책:

• count < 5_000: 즉시 처리
• 5_000 <= count < 50_000: 조건에 따라 분기
• count >= 50_000: 비동기 처리

단, COUNT(*) 자체가 너무 비싸면 그대로 쓰기 어렵다. 이 경우 샘플 통계, 요약 테이블, 사전 집계 테이블이 필요할 수 있다.

2. 필터 복잡도를 점수화한다

실무에서는 요청 자체에 스코어를 부여하는 방식도 유용하다.

예를 들어:

• 기간 조건이 1년 이상이면 +2
• 텍스트 검색이 있으면 +1
• 여러 테이블 조인이 필요하면 +2
• 정렬이 있으면 +1
• 전체 다운로드면 +3

이 점수의 합이 일정 기준을 넘으면 “무거운 요청”으로 분류한다.

이 방식의 장점은 DB 비용을 매번 정확히 측정하지 않아도, 운영 경험을 정책으로 녹일 수 있다는 점이다.

3. 쿼리 플랜을 참고할 수 있다

더 정밀한 판단이 필요하면 EXPLAIN 기반 정보를 사용할 수 있다.

이때 보고 싶은 것은 대체로 다음이다.

• 풀스캔 여부
• 사용 인덱스
• 예상 row 수
• 정렬 또는 임시 테이블 발생 여부

다만 이 방식은 요청마다 직접 수행하면 오히려 오버헤드가 될 수 있다. 그래서 보통은:

• 자주 들어오는 패턴만 캐싱하거나
• 특정 유형의 요청에만 적용하거나
• 운영 중 튜닝 도구로 활용

하는 식으로 제한적으로 사용한다.

4. 과거 실행 이력을 재사용한다

같은 필터 조합이 반복되는 기능이라면, 가장 신뢰할 수 있는 기준은 과거 실행 시간이다.

예를 들어 다음 정보를 남길 수 있다.

• 요청 해시
• 조회 건수
• 파일 생성 시간
• 총 처리 시간
• 실패 여부

이 데이터를 쌓으면 다음과 같은 정책이 가능해진다.

• 과거 평균 시간이 긴 요청은 즉시 비동기 처리
• 자주 반복되는 요청은 미리 파일 생성
• 특정 패턴의 요청은 UI에서 경고 표시

즉, 사전 판별은 정적인 규칙만이 아니라 운영 이력 기반 정책으로 발전할 수 있다.

5. 즉시 처리와 비동기 처리의 분기 기준을 명확히 한다

사전 판별의 목적은 단순히 “이 요청이 무겁다”를 아는 데 있지 않다. 실제로는 실행 경로를 분기해야 한다.

예:

• 가벼운 요청: 즉시 응답
• 무거운 요청: 큐 적재 후 상태 반환
• 매우 자주 반복되는 요청: 기존 생성 파일 재사용

여기서 중요한 것은 사용자가 왜 비동기로 전환됐는지 이해할 수 있어야 한다는 점이다.

예를 들어:

• “요청 범위가 커서 비동기 다운로드로 전환되었습니다.”
• “동일 조건의 파일이 이미 생성되어 있어 기존 파일을 제공합니다.”

처럼 명확한 피드백이 필요하다.

UI와도 연결되어야 한다

사전 판별 로직은 서버 안에서만 끝나면 아쉽다. 사용자 경험까지 연결해야 효과가 커진다.

예를 들면:

• 필터 선택 중 예상 건수 표시
• 대량 요청 예상 시 경고 문구 표시
• 동기/비동기 예상 경로를 미리 안내

이렇게 하면 사용자는 “왜 이 요청은 바로 내려오지 않는가”를 이해할 수 있다.

정리

무거운 엑셀 다운로드 요청을 사전에 판별하려면 다음 네 가지를 조합하는 것이 현실적이다.

1. 예상 결과 건수
2. 필터와 쿼리 복잡도 점수
3. 필요 시 EXPLAIN 기반 정보
4. 과거 실행 이력

핵심은 정확한 예측 모델 하나를 만드는 것이 아니라, 운영에 도움이 되는 분기 기준을 만드는 것이다. 결국 이 로직의 목적은 요청을 잘 예측하는 것이 아니라, 시스템이 과부하되기 전에 올바른 처리 경로를 선택하는 데 있다.