이 글은 Thorben Bochenek와 Robert Nyman [Editor]이 쓴 How fast is PDF.js?의 한국어 번역본입니다.

안녕하세요, 제 이름은 Thorben 입니다. 저는 오슬로에 있는 오페라 소프트웨어에서 일하고 있습니다. 모질라가 아닙니다. 그런 제가 왜 모질라 블로그에 글을 쓰고 있을까요? 알고 계실지 모르겠지만 오페라 브라우저에는 디폴트 PDF 뷰어가 없습니다. 우리가 개선하고 싶은 부분이지요. 어떻게 개선하면 좋을까요? Adobe 나 Foxit 에서 PDF 뷰어를 사와야 할까요? 아니면 아예 새로 만들어야 할까요?

PDF.js를 소개합니다

적절한 방법을 찾던 중 우리는 우연히 PDF.js를 보게 됐습니다. PDF.js는 자바스크립트와 캔버스(Canvas)를 이용해서 완벽한 브라우저용 PDF 뷰어를 만드는 프로젝트입니다. 약간 허황된 얘기 같을 수도 있지만 일리 있는 시도입니다. 본질적으로 브라우저는 텍스트, 이미지, 폰트, 벡터그래픽을 잘 처리해야 하는 소프트웨어입니다. 바로 PDF 뷰어가 잘 처리해야 하는 기능들이죠. PDF가 처리하고 있는 그리기 명령들은 포스트스크립트(Postscript) 명령들의 부분 집합입니다. 그리고 그 명령들은 캔버스가 제공하는 것들과 크게 다르지 않습니다. 더구나 보안(Security)도 전혀 문제가 되지 않습니다. PDF.js를 사용하는 것은 다른 웹사이트를 보는 것만큼 안전합니다.

PDF.js 깊이 보기

그래서 Christian Krebs, Mathieu Henri, 그리고 저는 PDF.js를 더 깊이 보기 시작했습니다. 그리고 감동했습니다. PDF.js는 잘 설계되어 있었고, 처리속도도 빨랐으며, 대부분의 코드가 정말 멋졌습니다!

하지만 우리는 문제점들도 발견했습니다. 일부 무거운 그래픽을 포함한 PDF 문서를 처리할 때 발생하는 성능이 문제였습니다. PDF.js를 좀 더 잘 이해하고 프로젝트 진전시키기 위해, 우리는 PDF.js 프로젝트에 직접 참여해서 발견한 문제들을 알리는 것이 좋을 것 같다고 판단했습니다. 프로젝트에 참여함으로써 우리는 PDF.js 프로젝트 자체와 PDF.js 프로젝트의 높은 잠재력을 아주 잘 이해하게 되었습니다. 우리는 우리가 작업에 참여하는 동안에도 PDF.js의 성능이 계속 개선되는 것에서 깊은 인상을 받았습니다. PDF.js는 활발하게 살아 있을 뿐 아니라 잘 관리되고 있는 프로젝트입니다.

PDF.js 벤치마크 하기

당연히, 우리가 발견한 문제들은 퍼포먼스에 관해 나쁜 인상을 전해줍니다. 우리는 아주 크고, 이상하고, 그려내기 어려운 PDF 파일들을 찾아 테스트했습니다. 하지만 보통 사람들이 보는 파일들은 그런 것이 아닙니다. 당신이 보려고 하는 대부분의 PDF 파일들은 PDF.js가 문제 없이 처리합니다. 그런데 그런 파일들을 어떻게 테스트해야 하나요?

아마도, 인터넷에서 가장 인기 있는 PDF 파일들을 골라서 벤치마크 하면 될 것 같습니다. 인터넷에서 구한 파일이라면 당신이 보는 파일과 비슷한 종류일 것입니다. 5천에서 1만개 정도의 PDF 파일을 테스트하면 충분할 것입니다 … 그런데 그런 파일들을 어떻게 구하죠?

저는 검색엔진의 도움을 구하기로 했습니다. 검색엔진에 PDF 파일만 찾도록 요구하면, 검색엔진은 당신이 입력한 키워드와 가장 밀접한 관련이 있는 PDF 파일들을 찾아줍니다. 아마도 가장 인기 있는 PDF 파일들일 것입니다. 그리고 가장 인기 있는 검색어로 시도한다면 결과적으로 가장 훌륭한 벤치마크 시료를 얻을 수 있을 것입니다.

수많은 PDF 파일들을 벤치마크 하는 것을 큰 작업(task)입니다. 그래서 저는 구식 컴퓨터들을 이용해서 작은 클러스터를 만들었습니다. 그리고 멋진 서버 어플리케이션을 만들어서 컴퓨터들에게 작업(task)을 전달하게 했습니다. 현재의 레파지토리에는 대략 7천개의 PDF 파일들이 저장되어 있습니다. 특정 버전의 PDF.js를 벤치마크 하는 데 대략 8시간 정도 소요됩니다.

결과는요

이제 예쁜 그림이 있는 재미있는 부분으로 넘어갑시다. 이 그래프입니다.

이 그래프는 흥미로운 결과를 한눈에 보여줍니다. 이 그래프에는 PDF 페이지를 처리하는데 소요되는 시간과 Tracemonkey Paper (PDF.js를 열 때 보여지는 디폴트 PDF 파일)의 보통 페이지를 처리하는데 소요되는 시간의 비율을 표시한 막대 그래프입니다. 사용자가 Tracemonkey Paper를 볼 때 느끼는 체감 성능은 꽤 좋은 편입니다. 제가 테스트한 바로는 Tracemonkey Paper를 볼 때보다 최악의 경우 3에서 4배 느리더라도 사용자 경험 측면에서 괜찮았습니다. 이는 96%가 넘는 페이지들(크래쉬가 일어난 PDF 파일들 제외)의 벤치마크 결과가 사용자 경험 측면에서 괜찮다는 이야기 입니다. 이건 정말 좋은 뉴스입니다! 이 결과를 더 간단한 파이 차트로도 표시합니다 (페이지들의 %를 표시)

아마도 작은 문제를 눈치챘을 것입니다. 약 0.8% 정도의 PDF 문서는 테스트 하는 도중에 죽었습니다. 우리는 문제의 파일들을 자세히 살펴봤는데 삼분의 일 정도는 실제로 파일 자체가 많이 훼손되어 있어서 세상의 어떤 PDF 뷰어도 처리할 수 없는 상태였습니다.

그리고 이것은 우리에게 또 하나의 좋은 포인트를 일깨워 줍니다. 우리는 이 벤치마크 결과가 절대 평가라는 점을 기억해야 합니다. 인터넷 세상에는 매우 복잡하고 까다로운 PDF 파일들이 있으며 이런 파일들은 네이티브 PDF 뷰어라 하더라도 적절히 그리고 빠르게 처리할 수 없습니다. 가장 처리 속도가 느렸던 PDF 파일은 리스본의 대중 교통 체계에 관한 믿을 수 없을만큼 상세한 벡터 그래픽 지도였습니다. 그 파일을 Adobe Reader에서 열어보아도, 제대로 잘 처리되지 않습니다!

결론입니다

이런 결과로부터 우리는 PDF.js가 오페라 브라우저의 기본 PDF 뷰어로 사용하기에 아주 적절한 후보라는 결론을 얻었습니다. 아직 PDF.js를 오페라 브라우저에 멋지게 통합하려면 할 일이 많지만, 우리는 지금 현재 테스트 플랙(flag) 아래 통합 작업을 진행하고 있습니다 (일러두기: 모질라의 기본 뷰어를 추가하는 확장모듈은 이미 존재합니다. “멋지게” 통합한다는 말은 새로운 형태의 뷰어로 보다 긴밀하게 통합하는 것을 말합니다). 모질라에게 감사를 전합니다! 우리는 당신들과 함께 PDF.js 개발을 계속할 수 있으면 좋겠습니다!

PS: 벤치마크 시스템 코드와 결과가 모두 공개되어 있습니다. 한번 살펴보고 유용하다고 생각되면 우리에게 알려주세요!

PPS: 만약 큰 검색엔진 회사에 다니는 사람으로서 가장 많이 참조되는 PDF 파일 1만개의 목록을 전해줄 수 있는 사람이 있다면, 크게 감사하겠습니다. 🙂

부록: 다음은 뭔가요?

벤치마크를 위해 모은 데이터 파일과 앞서 설명한 테스트 프레임워크는 다른 종류의 재미있는 용도로도 사용할 수 있습니다. 다음 단계로 우리는 PDF 파일들을 사용된 폰트의 종류, 이미지의 종류 등에 따라 분류하려고 합니다. 그러면 PDF 파일로 어떤 새로운 항목을 테스트를 하려고 할 때 빨리 시료 파일을 구할 수 있을 것입니다. 우리는 또 포스트스크립트의 그리기 명령 중 어떤 명령이 어떤 빈도로 사용되는지 살펴볼 계획입니다. 그러면 우리는 빈번하게 사용되는 명령들을 좀 더 최적화 할 수 있을 것입니다. 우리가 HTML 브라우저에서 했던 것처럼요. 우리가 무엇을 해내는지 지켜봐 주세요 😉