자주 묻는 질문

아니요. PDFluna의 모든 도구는 JavaScript, WebAssembly, 브라우저 내장 PDF 렌더링 라이브러리 덕분에 브라우저에서 완전히 동작해요. 파일은 로컬에서 읽고, 로컬에서 처리하고, 로컬에 저장돼요. 직접 확인할 수 있어요: 도구를 사용하기 전에 브라우저 DevTools → 네트워크 탭을 열고 관찰해보세요 — 파일을 보내는 외부 요청이 0개예요. 유일한 네트워크 트래픽은 첫 페이지 로드와 도구가 필요로 하는 오픈소스 라이브러리(PDF.js, pdf-lib 등)뿐이에요.

아니요. 할 수 없어요 — 애초에 파일이 서버에 도달하지 않아요. 우리 측에는 "파일 삭제 정책"이 없어요. 우리 측에 삭제할 파일이 없기 때문이에요. AI 학습, 광고 프로파일링, 통계 분석 등을 위해 파일 콘텐츠를 사용하지 않아요.

네. GDPR(그리고 한국 개인정보 보호법) 준수의 가장 강력한 형태는 애초에 개인 데이터를 수집하지 않는 거예요. 그게 우리의 기본 동작이에요. 계정 불필요, 우리 인프라에서 파일 콘텐츠를 처리하지 않고, 사이트가 수집하는 유일한 데이터는 익명 분석이에요(페이지뷰, 도구 사용 카운트 — 개인 식별자 없음, 파일 콘텐츠 없음). 구체적인 데이터 보호 요청이나 개인정보 열람 요구는 [email protected]으로 메일 보내주세요. 자세한 내용은 개인정보처리방침에 있어요.

네 — 사실 대부분의 대안보다 안전해요. 서버 측 경쟁 도구(iLovePDF, Smallpdf, Adobe 온라인 도구)는 모든 파일을 자체 인프라에 업로드하고 거기서 처리한 후 출력을 돌려보내요. 계약서, 급여 명세서, 의료 기록, 신분증의 경우, 그들의 개인정보처리방침이 완벽하더라도 심각한 노출이에요: 파일이 통제 밖의 장소에 잠시 존재해요. PDFluna에서는 그 노출이 애초에 존재하지 않아요 — 파일이 네트워크를 통과하지 않아요.

아니요, 운영 방식에 필요하지 않아요. SOC 2 / ISO 27001은 조직이 서버의 클라이언트 데이터를 어떻게 관리하는지 감사해요. 우리는 서버에서 클라이언트 파일 데이터를 관리하지 않으므로(기기에 머물러요), 이 감사들이 살펴볼 게 없어요. 가장 비슷한 등가물은 오픈소스 코드 자체예요: 사용하는 각 라이브러리(PDF.js, pdf-lib, fflate, html2canvas)는 공개 검증이 가능하고, 브라우저 DevTools로 파일이 기기를 떠나지 않는 것을 실시간으로 확인할 수 있어요.

Google Analytics 4를 사용해 익명 페이지뷰를 카운트하고 도구 사용을 집계해요. 파일 이름, 파일 콘텐츠, 식별 정보 없음. 동의 배너를 거부한 EU 방문자는 쿠키 없는 Plausible 분석을 받아요. 둘 다 쿠키 정책에서 설정 가능해요. 거부해도 도구 기능에 영향이 없어요.

최신 브라우저는 웹페이지 렌더링 이상을 할 수 있어요. JavaScript와 WebAssembly로 실제 PDF 라이브러리(PDF.js, pdf-lib)를 브라우저 탭 안에서 직접 실행할 수 있고, 파일 선택기나 드래그&드롭으로 선택한 파일에 완전히 접근할 수 있어요. 파일은 탭 메모리에 로드되고 거기서 처리되며 결과가 다운로드용으로 제공돼요. 같은 기술이 Figma, 웹의 Photoshop, Google Docs를 동작시켜요.

업로드가 없기 때문이에요. PDFluna 도구의 진행 막대는 로컬 처리를 추적해요 — 브라우저 라이브러리가 파일의 얼마나를 읽고, 인코딩하고, 스탬프했는지 — 네트워크 전송이 아니에요. 빠른 컴퓨터에서는 거의 즉시일 때도 있고, 서버 도구의 몇 초 업로드에 익숙하다면 의심스럽게 느껴질 수 있지만, 속도는 네트워크 왕복을 완전히 건너뛰는 이점이에요.

무거운 도구(OCR, 서명, Word-to-PDF)를 처음 사용할 때 전용 라이브러리를 필요할 때 로드해요 — OCR용 Tesseract.js(약 14 MB), Word 파싱용 mammoth.js(gzip 약 150 KB) 등. 이 라이브러리들은 첫 로드 후 브라우저에 캐시되므로 두 번째 사용은 즉시예요. 랜딩의 time-to-interactive를 빠르게 유지하기 위해 홈페이지에서는 의도적으로 로드하지 않아요.

부분적으로요. 도구를 사용해 페이지와 라이브러리가 브라우저에 캐시된 후에는 보통 같은 도구를 오프라인에서 다시 로드할 수 있고 동작해요. 현재는 명시적인 오프라인 사용을 위한 Service Worker를 제공하지 않으므로 새 에셋 가져오기가 필요한 다시 로드는 오프라인에서 실패해요. 진정한 오프라인 사용은 로드맵에 있어요.

대부분의 도구는 최대 100 MB의 PDF를 받아요. 포맷 변환 도구(Word-to-PDF, Excel-to-PDF)는 이 포맷들의 파싱이 메모리를 많이 사용하므로 20 MB로 제한돼요. OCR은 각 페이지가 300 DPI로 렌더링된 후 OCR되는 가장 느린 파이프라인 때문에 50 MB / 50페이지로 제한돼요. 구체적인 제한은 각 도구 페이지의 드롭존 위에 표시돼요.

PDF(모든 도구), 이미지(JPG, PNG, HEIC, WebP — JPG-to-PDF용), Word 문서(.docx, .rtf, .odt — Word-to-PDF용), 스프레드시트(.xlsx, .xls, .ods, .csv, .tsv — Excel-to-PDF용), 서명 이미지(PNG, JPG, GIF, WebP — PDF 서명용).

PDF(모든 기본값), JPG(페이지당 1개 또는 PDF-to-JPG를 통한 다중 페이지 ZIP), PNG(페이지당 1개 또는 PDF-to-PNG를 통한 ZIP). PDF에서 Word, PowerPoint, Excel은 만들지 않아요 — 플로우/그리드 포맷으로의 역변환은 정말 어렵고, 사용 불가능한 출력의 도구를 제공하고 싶지 않아요. 자세한 근거는 블로그 참조.

Word 97–2003 레거시 바이너리 .doc 포맷은 허용 가능한 충실도로 변환하려면 Microsoft Word 자체나 수천 줄의 커스텀 파서가 필요해요. 출력이 다른 서비스와 비교해 불리한 도구를 제공하기보다 깔끔히 거부하는 걸 선호해요. 10초 해결책: Word 또는 LibreOffice에서 .doc를 열고, 파일 → 다른 이름으로 저장 → .docx, 그런 다음 .docx를 Word-to-PDF 도구에 드롭하세요. 모든 게 보존돼요.

일부 도구는 가능해요(PDF 병합은 설계상 여러 파일을 받아요. JPG-to-PDF는 이미지 일괄을 받아요). 대부분은 의도적으로 한 번에 하나예요: 50 MB 파일 5개를 동시에 브라우저에 푸시하면 중급 스마트폰이 충돌해요. 압축/변환을 위한 가장 빠른 일괄 흐름은 같은 탭에서 순차적으로 실행하는 거예요 — 도구는 파일 사이에 즉시 재초기화돼요.

제목 접두사 `[Bug]` 또는 `[Feature request]`를 붙여 [email protected]으로 메일 보내주세요. 버그의 경우 파일(공유 가능하다면)과 브라우저+OS를 포함하면 재현이 약 10배 빨라져요. 모든 메시지를 읽어요. 일반 질문 답변은 1~2영업일 이내예요.

모든 최신 브라우저: Chrome 120+, Edge 120+, Safari 17+, Firefox 120+, 그리고 모바일 버전(iOS Safari 17+, Android Chrome). 오래된 버전은 더 단순한 도구에서 동작할 수 있지만 테스트하지 않아요 — 의존하는 WebAssembly + Pointer Events API는 최신 버전에서만 견고해요.

네. iOS Safari 17+는 재구축이 끝나기 전 브라우저 탭이 메모리 부족으로 떨어지는 매우 긴 문서의 일부 극단적 경우를 제외하고 모든 걸 지원해요. 일반 규칙으로 30 MB 미만 파일은 스마트폰에서 잘 동작해요. 태블릿 기기(iPad Air 5+ 이상)는 대부분 도구에서 완전한 100 MB 제한을 처리해요.

네 — 최신 Chrome, Firefox, Edge, Samsung Internet에서. 저사양 기기(4 GB RAM 이하)는 iPhone과 같은 메모리 압박 이유로 큰 파일 중간에 멈출 수 있어요. 긴 문서에서 도구가 실패하면 먼저 PDF 분할로 분할하면 보통 통과해요.

PDF 처리는 CPU와 메모리를 많이 써요. 100 MB PDF는 렌더링과 재발행을 위해 300~500 MB 작업 메모리를 필요로 할 수 있어요. 이는 오래된 폰(총 시스템 RAM 4 GB)이 단일 브라우저 탭에 할당하는 것보다 많아요. 해결책: 먼저 PDF 분할로 문서를 나누거나, 래스터화 도구(PDF-to-JPG, OCR PDF)에서 출력 DPI를 낮추거나, 컴퓨터에서 실행하세요.

대부분의 도구에서 네 — 다시 렌더링하지 않고 기존 PDF 바이너리 구조에서 작동하므로 페이지가 원본 벡터 텍스트, 임베드 폰트, 이미지 품질을 유지해요. 예외: Word-to-PDF, Excel-to-PDF, PDF 잠금 해제는 문서를 이미지 기반으로 재구축해요(시각적 충실도는 보존되지만 폼 필드와 선택 가능한 텍스트를 잃어요). 각 도구 페이지가 트레이드오프를 문서화해요.

PDF 압축 도구는 증분 업데이트를 사용하므로 원본 텍스트, 폰트, 서명이 바이트 단위로 보존돼요. 공간 절약은 임베드 이미지를 더 낮은 해상도로 재인코딩하고 중복 히스토리 객체를 제거하는 데서 와요. 텍스트가 풍부한 PDF의 경우 시각적 결과가 원본과 구분되지 않아요. 이미지가 풍부한 PDF(스캔, 사진 기반)의 경우 트레이드오프 레벨을 선택할 수 있어요.

PNG는 무손실이에요 — 렌더링된 페이지의 각 픽셀이 정확히 보존돼요. JPG는 손실 압축이며 더 작은 파일을 만들지만 날카로운 가장자리(텍스트, 선화) 주변에 미세한 후광을 추가해요. S/M/L DPI 프리셋(72 / 150 / 300)이 해상도를 제어하고, JPG 품질 슬라이더(60~95%)가 압축을 제어해요. 같은 소스 라이브러리, 다른 출력 전략 — 필요에 따라 선택하세요.

일부 도구(PDF 잠금 해제와 변환 패밀리)는 각 페이지가 JPEG로 렌더링되어 새 PDF에 임베드되는 이미지 기반 출력을 만들어요. 레터 사이즈 200 DPI JPEG는 페이지당 평균 250~500 KB이고, 원본이 벡터 텍스트만 있었다면 원본보다 클 수 있어요. 결과를 줄이려면 PDF 압축 도구를 통과시키세요.

네, 가입 없음, 워터마크 없음, "내보내기 제한"이나 "하루 3개 파일" 없음. 함정(있다면): 사이트는 도구 페이지와 콘텐츠 페이지에 광고를 표시해요. 광고 수익이 호스팅과 개발을 충당해요. 비즈니스 모델은 이게 전부예요. 유료 플랜 도입은 계획하지 않아요. 모든 무거운 처리가 브라우저에서 실행되므로 인프라 비용은 최소예요.

계정이 저장할 게 아무것도 없기 때문이에요. 파일, 히스토리, 설정을 보관하지 않아요. 계정 없음은 기억할 비밀번호가 없고, 두 달 후 돌아왔을 때 "비밀번호 잊음" 흐름도 없다는 뜻이에요. 트레이드오프: 기기 간 연속성 없음(PC에서 작업 시작해 폰에서 끝낼 수 없어요). 가끔 PDF 작업하는 사람에게는 이 형태가 적합해요. 지속적인 문서 워크플로에는 Adobe Acrobat 같은 유료 SaaS가 더 나아요.

현재 도구셋에 대해서는 네. 인프라 비용은 트래픽에 맞춰 확장되지만 서버에서 아무 일도 일어나지 않으므로 낮게 유지돼요. 광고 수익이 편안하게 충당해요. 프로젝트가 미래에 유료 플랜을 도입해야 한다면 그건 새로운 서버 측 기능(공동 편집, 기기 간 동기화)을 위한 거고, 현재 브라우저 도구는 무료로 남아요.

네. PDFluna는 입력 파일이나 출력에 대한 권리를 주장하지 않아요. 생성하는 PDF는 당신 것이고 마음대로 사용할 수 있어요 — 상업 작업, 클라이언트 납품, 아카이브, 공유, 무엇이든. 유일한 제한은 원본 콘텐츠의 저작권이에요(우리는 변경하지 않아요. 가지지 않은 권리를 부여할 수 없어요).

작은 독립 팀이에요. 우리 자신이 빠른 PDF 도구가 필요했고 업로드형 서버 대안에 불만족해서 PDFluna를 만들었어요. 자세한 이유와 방법은 소개 페이지에 있어요. 구체적인 문의는 문의 페이지를 참조하세요.