PDF 업로드에 대한 크기 상한은 실제 비용이 있습니다. 또한 엔터프라이즈 소프트웨어에서 가장 과장된 수치 중 하나이므로, 이 글에서는 여러분이 직접 측정할 수 있는 방법을 제공하고, 여러분을 위해 만들어진 수치가 아니라 여러분 자신의 수치를 측정하도록 합니다.

소개

레거시 문서 관리 시스템은 종종 PDF 업로드에 25메가바이트라는 엄격한 상한을 적용합니다. 대부분의 문서는 이보다 훨씬 작아 제한이 무해하게 느껴지지만, 파일이 그 한도를 초과하면 누군가가 수동으로 조치를 취해야 합니다.

우리는 여기서 우리의 입장을 솔직히 밝혀야 합니다. 그렇지 않으면 이상하니까요: Doconut.app 의 무료 뷰어도 PDF에 대해 25 MB에서 멈춥니다. 이것이 우리의 상한이며, 이 글은 상한이 정당하지 않다는 주장이 아니라, 이동하기 전에 여러분의 상한이 어떤 비용을 초래하는지 알아야 한다는 주장입니다.

이 글의 숫자, 혹은 그 부재에 대한 주석입니다. 이 분야의 비용 모델은 보통 아무도 검증할 수 없는 설문조사와 출처를 알 수 없는 벤치마크에 기반합니다. 우리는 그런 자료가 없으므로 어떤 숫자도 제시하지 않을 것입니다. 아래는 산술식과 질문들이며, 실제 값은 여러분의 시스템에서 제공해야 합니다.

1. 거부된 업로드가 실제로 드는 비용

PDF가 제한을 초과하면 누군가가 파일을 분할하거나 압축하거나 다시 생성합니다. 이것이 직접 비용이며, 측정 가능한 세 가지 구성 요소가 있습니다:

볼륨. 크기 때문에 거부된 업로드는 몇 건인가요? 애플리케이션 로그에 기록됩니다. 거부 사유가 기록되지 않았다면 먼저 이를 수정해야 합니다. 아래 모든 내용이 이 숫자에 의존하며, 아무도 이를 정확히 추정할 수 없기 때문입니다.

처리 시간. 우회 작업에 얼마나 걸립니까? 추측 대신 실제 파일 다섯 개에 대해 시간을 측정하세요. Acrobat에서 스캔된 계약서를 압축하고 다시 업로드하는 것은 400페이지 매뉴얼을 여러 부분으로 나누는 작업과 동일하지 않습니다.

티켓 비율. 이러한 거부 중 어느 정도가 데스크에서 해결되지 않고 지원 티켓으로 전환되는가? 검색어를 사용해 티켓 시스템에서 추출하세요.

rejections per quarter
  x handling time in hours
  x blended hourly rate
+ (rejections x ticket rate x cost per ticket)
= direct quarterly cost

직접 계산해 보는 이유는 결과가 조직마다 규모가 10배 이상 차이 나며, 거의 전적으로 볼륨에 따라 달라지기 때문입니다. 한 달에 두 번 제한에 걸리는 팀이라면 솔직히 측정할 가치가 없는 비용이며, 더 이상 읽을 필요가 없습니다. 하루 종일 스캔 파일을 처리하는 청구 부서라면 이는 실제 라인 아이템이 됩니다.

2. 진지하게 고려해야 할 간접 비용

지연과 손실된 거래는 일반적인 두 번째 단계이며, 우리는 매출 모델링을 생략합니다. 업로드 제한으로 인한 판매 손실을 입증하려면 거의 아무도 가지고 있지 않은 증거가 필요하기 때문입니다.

하지만 하나의 간접 비용은 이름을 붙일 가치가 있습니다. 왜냐하면 질적으로 다르기 때문입니다: 문서를 분할하면 손상이 발생합니다.

세 부분으로 나뉜 PDF는 각각 별도로 전송되고, 별도 버전 관리되며, 불완전하게 보관됩니다. 서명은 이 작업을 견디지 못합니다 — 분할된 디지털 서명 PDF는 모든 조각에서 서명이 무효가 되는데, 서명이 전체 파일의 바이트를 포함하기 때문입니다. 메타데이터, 태그 및 PDF/A를 보관 가능하게 만드는 구조는 사용자가 선택한 도구에 따라 일관되지 않게 보존됩니다.

보존 또는 감사 의무가 문서를 하나의 객체로 가정한다면, 정기적으로 분할을 강요하는 크기 제한은 생산성이라는 겉모습을 가진 규정 준수 문제입니다. 이는 노동 산출이 무엇을 말하든지 상관없이 강조할 가치가 있습니다.

3. 구매하기 전에 파일에 무엇이 들어 있는지 확인하세요

이 단계는 종종 건너뛰어져 프로젝트를 종료시키는 경우가 있어 자체 섹션을 가질 만큼 중요합니다.

거부된 파일 중 50개를 골라 무엇이 크기를 키우는지 살펴보세요. 우리의 포맷 경험에 따르면 일반적인 원인은 원본 캡처 해상도의 이미지입니다: 200 dpi 흑백으로도 충분한 계약서를 600 dpi 컬러로 스캔했거나, 스마트폰에서 바로 가져온 사진이 포함된 보고서 등. 이러한 PDF는 필요 이상으로 여러 배 크게 되며, 원본 단계(스캐너 프로파일, 내보내기 설정)에서 수정하면 별도의 구매 없이 거부를 없앨 수 있습니다.

때로는 실제로 큰 문서가 원인일 수 있으며, 이는 실제 요구 사항이 됩니다. 중요한 것은 여러분이 어느 경우에 속하는지를 아는 것입니다.

4. 공급업체에게 물어볼 질문, 우리 포함

상한을 높여야 한다면, 중요한 질문은 상한 자체에 관한 것이 아닙니다:

제한이 어디에서 적용되며, 그 이유는 무엇인가요? 애플리케이션 자체의 업로드 처리에 설정된 제한은 렌더링 엔진에 의해 강제되는 제한과 다릅니다. 우리 경우는 전자이며, 25 MB는 공개 사이트가 허용하는 것이고, 엔진이 그릴 수 있는 한도는 아닙니다.
제한에 도달하면 어떻게 되나요? 업로드 시 숫자를 명시한 거부는 90 %에서 타임아웃보다 친절합니다 — 사용자는 어떤 형태로든 정보를 얻지만, 하나는 더 빠릅니다.
메모리 사용 곡선은 어떻게 되나요? 큰 PDF를 렌더링하면 서버 메모리를 소모합니다. 자체 호스팅한다면 그 비용은 인프라로 이동하고, “무제한”은 “현재 구매 중인 하드웨어에 의해 제한됨”을 의미합니다.
무엇이 보존되나요? 파일 분할을 방지하기 위해 제한을 높인다면, 문서가 온전하게 유지되는지 확인하세요 — 서명, 태그, 메타데이터 포함.

참고로, 이 글에 우리가 확신할 수 없는 숫자는 없습니다: Doconut SDK 는 여러분이 자체 환경에 설치하는 .NET 구성 요소이며, 실제 크기 상한은 우리의 정책이 아니라 서버 메모리에 의해 결정됩니다. 우리는 메가바이트 수치를 제시하지 않을 것입니다. 이는 여러분의 하드웨어와 문서에 따라 달라지며, 단일 숫자는 마케팅에 불과하기 때문입니다.

5. 실행 가능한 단계

거부를 계측하세요. 이유와 파일 크기를 기록합니다. 실제 데이터 1분기의 양이 어떤 모델보다 뛰어납니다.
파일을 샘플링하세요. 거부된 PDF 50개를 통해 크기 문제인지 스캐너 설정 문제인지 알 수 있습니다.
위의 산술식을 자체 볼륨과 요율로 실행하고, 비용이 너무 작아 실행할 필요가 없다고 결론 내는 것을 받아들여야 합니다.
규정 준수 측면을 별도로 확인하세요. 분할이 서명이나 감사 추적을 깨뜨린다면, 그 주장은 자체적으로 설득력이 있으며 비용 모델이 필요 없습니다.
가장 문제 있는 파일로 파일럿을 진행하세요. 샘플이 아니라 대화의 시작이 된 300페이지 스캔 번들을 사용합니다.

결론

크기 상한은 실제 비용이 수반되는 제약이며, 엔터프라이즈 소프트웨어에서 숫자를 가장 쉽게 제시받는 부분이기도 합니다. 비용은 여러분의 볼륨, 처리 시간, 요율에 따라 달라지며 — 상당할 수도, 전혀 없을 수도 있습니다.

이동하기 전에 측정하세요. 오늘 읽기에 조금 큰 PDF가 하나라면, Doconut.app 은 25 MB까지 지원하고 비용이 없으며, 탭을 닫으면 파일을 삭제합니다.

SDK가 적합한지 확인하고 싶나요? 다운로드 페이지 에는 체험판이 있으며, 가장 무거운 문서에 적용해 보면 어떤 계산기보다 더 많은 정보를 얻을 수 있습니다.