인사이트리포트

들어가며

코로나 시국이 계속되면서 사회적 거리두기에 대한 요구가 지속되는 동안 많은 기업들이 재택 근무 환경을 갖출 수 있도록 적극적인 투자를 해왔다. 그 결과 재택 근무가 하나의 기업 문화로서 정착이 되었다. 하지만 사실 이러한 움직임은 코로나 이전부터 이미 진행되어 왔다고 볼 수 있는데 그 중심에는 모바일(휴대폰)이 있다.

스마트폰이 대중들에게 일상화된지도 어언 10년이 지났다. PC에서 해왔던 많은 일들이 모바일로 대체되면서 업무용 메일을 열람하고 결재를 처리하고 업무용 메신저로 소통을 하게 되었다. Work from Anywhere로 대변되는 모바일 업무 환경은 의사결정 지연에 따른 손실을 줄였고 이는 기업 생산성 향상으로 직결되었다.

잠깐 눈을 돌려보자. 2022년 현재 기후 위기가 전세계적인 문제로 거론되고 있으며 탄소 중립에 대한 요구도 드세지는 추세다. 이에 대응하여 전자 문서를 활성화 하면 벌목량과 종이 생산량을 줄여 탄소중립 실현에 큰 기여를 할 수 있을 것이다. 실제로 공공기관, 민간기업 할 것 없이 서면으로 진행해왔던 많은 업무 절차들이 전자문서로 대체되고 있으며 서면으로 작성하고 보관하는 각종 계약서도 전자 계약으로 바뀌고 있다.

본 아티클에서는 필자의 경험을 토대로 시장의 요구, 특히 모바일 환경에 부합하는 기업용 문서 스트리밍 솔루션을 논해 보고자 한다. 어떤 시스템이지, 그리고 어떠한 전략으로 서비스를 설계하고 구축해야 할 것인지를 소개하도록 하겠다.

 

 

PC에 가까워지는 모바일 서비스

시기를 거슬러 올라가서 iOS, 안드로이드 수준의 스마트폰이 보급되기 전에는 모바일에서 사용할 콘텐츠는 되도록 간략하고 적은 데이터를 사용해야 했다. 따라서 WAP이라는 이동통신용 인터넷 표준이 필요했고 웹사이트를 만들 때 모바일 전용 페이지를 따로 구축하기도 했다.

 

 

폰 성능이 많이 좋아지면서 PC에서 볼 수 있는 웹, 오피스 문서는 모바일에서도 대부분 동일한 형태로 열람이 가능해졌다. 과거 피처폰 시절처럼 데이터를 어떻게 최소화 할 것인가에 대한 고민이 필요없어졌고 대신 이제는 PC와 동일한 수준의 정보량과 인터페이스를 어떻게 구현할 것인가를 고려해야 할 시기가 된 것이다.

포털 사이트나 SNS 등 많은 웹서비스들이 여전히 PC와 모바일 버전으로 이원화된 채널을 운영하고 있지만 필자는 개인적으로 모바일에서 포탈사이트에 들어갈 때 ‘https://m.~’으로 시작하는 모바일용 웹페이지를 선호하지 않아서 곧바로 PC 화면보기로 전환하고 있다. 요즘 스마트폰이 제공되는 해상도 만으로도 PC 화면으로 볼 수 있는 콘텐츠는 충분히 담을 수 있다고 생각하기 때문이다.

 

 

PC에서 MS 오피스나 어도비 리더로 볼 때와 동일한 포맷의 화면으로 모바일에서 열람을 하기 위해서는 검토해야 할 사항이 많다. 프로그램을 구현하는 방법은 여러가지가 있겠지만 가장 일반적인 접근법은 서버에서 각 문서의 구조를 분석한 후 스트리밍이 가능하도록 메타데이터로 치환한 다음 단말에 전송하는 것이다. 이와 동시에 단말은 서버로부터 전송 받은 메타데이터를 그대로 렌더링해서 PC에서 보는 화면과 일치하도록 재현해야 한다. 이와 관련된 내용은 후반부에서 다시 다루겠다.

 

 

기업용 문서 스트리밍 서비스 설계 및 구축 시 고려사항

기업용 문서 스트리밍 서비스가 갖춰야할 지표로 보안성, 편의성, 효율성을 들 수 있다.

이들은 함께 효용이 증대되는 이른바 동반상승하는 관계가 될 수 있다. 효율성을 높이면 사용자 입장에서 좀 더 빨리 결과물을 받아볼 수 있기 때문에 편의성에도 긍정적인 영향을 끼친다. 다만 어느 한쪽으로 과도하게 매몰되면 다른 쪽의 부족함으로 인해 문제가 될 수도 있다.

예를 들어 편의성에 지나치게 매몰될 경우 스트리밍 서버에서의 지나친 자원 소모나 계산 작업으로 인해 CPU 점유율이 과도하게 높아질 수 있고(이를테면 지도 앱에서 서울 지도를 살펴보고 있는데, 백그라운드에서 대한민국 전체 지도 정보를 미리 렌더링하고 있다거나) 효율에 매몰될 경우 반드시 필요한 암호화 작업이나 인증 과정을 등한시 하느라 정보 보안이 위험해질 수 있는 것이다. 따라서 기업 보안 유지, 사용자 만족, 서비스 비용 절감을 골고루 충족하기 위해서는 한쪽으로 치우치지 않는 균형 잡힌 전략이 필요하다.

 

1) 보안성

기본적으로 스트리밍 서비스(동영상, 문서 등)를 하는 가장 큰 목적은 원본 콘텐츠가 무단으로 복제되지 않도록 하는 것이다. 기업 내 보안 유지를 위해 그리고 e-book 스토어처럼 콘텐츠에 대한 무단 복제를 방지해야 하는 서비스에서 보안성은 무엇보다 중요하다.

이를 충족시키는 중요한 요건은 문서 원본을 모바일과 같은 단말의 보조 기억 장치(SD메모리)에 저장하지 않는 것이다. 그리고 메모리 해킹을 통한 복사가 가능하기 때문에 RAM과 같은 주기억 장치에 문서 데이터 전체를 저장하는 것도 안전하지 않다. 즉 서버가 문서 원본을 가지고 있고 이를 단말에 다운로드 하지 않도록 하면서 단말이 보고자 하는 화면의 최소 구성 요소만 전달함으로써 보안성을 유지해야 합니다.

무선 인터넷 환경은 스니핑(sniffing)과 같은 네트워크 탈취 기술에 더더욱 취약하기 때문에 반드시 암호화가 필요하다. http 프로토콜 기반이라면 반드시 https를 사용하고 추가로 AES256 이상의 보안성을 보장하는 패킷 암호화를 하는 것이 좋다.

그리고 단말에서 화면 캡처 방지에 대한 대책도 필요하다. 안드로이드의 경우 관련 API가 제공되고 있어 이를 적극적으로 활용해야 한다. iOS는 화면 캡처 방지가 기술적으로 불가능하지만 사용자가 특정 앱 화면에서 캡처를 시도했을 때 이벤트 함수를 발생시킬 수 있기 때문에 이를 통한 관리가 가능하다.

또한 화면 자체를 또 다른 단말기의 카메라로 촬영을 할 수도 있기 때문에 워터마크도 필수이다. 열람 중인 화면에서 특정 사용자를 식별할 수 있는 워터마크를 함께 표시함으로써 사용자에게 보안에 대한 좀 더 많은 책임을 부여할 수 있다.

 

 

2) 편의성

‘편의성’은 사용자 입장에서 문서를 불편함 없이 열람할 수 있는지가 척도가 된다.

사용자가 문서 열람을 시도했을 때 응답이 오기까지 대기 시간이 짧을수록 그리고 열람 시 해당 문서 정보를 되도록 많이 취할 수 있는 것이 좋다. 아울러 페이지를 이동할 때 끊김 없이 실시간으로 정보를 원활하게 제공할 수 있도록 유지하는 것도 중요하다.

이를 충족시키기 위해서는 사용자가 열람하고 있는 범위를 정확하게 파악하고 그 요청 범위에 맞게 문서 정보를 최대한 빠르게 추출하여 전달하는 것이 관건이다. 모바일이라는 제한된 화면에서 최대한의 정보를 출력하기 위해서는 공간을 최대한 활용하도록 화면을 설계해야 한다. 아울러 모바일 플랫폼은 디바이스 종류와 해상도에 따라 표시할 수 있는 출력물 형태가 다양하며 세로보기인지 가로보기인지에 따라 레이아웃도 별도로 지정해야 한다.

 

 

문서 열람 외에 상호간의 피드백을 원활히 하기 위한 판서, 특정 페이지 취합 후 재전송하는 별도 기능 등도 제공하는 것이 좋다.

 

3) 효율성 및 안정성

서비스 자원은 무한하지 않다. 따라서 효율성 높은 서비스 운영을 위한 자원 안배가 중요하다. 여기서 말하는 ‘효율성’은 작업 처리에 있어 얼마만큼 더 짧은 시간에 서버 및 네트워크 자원을 적게 사용해 많은 작업을 하느냐가 관건이 된다.

앞서 언급한 편의성이 클라이언트의 영역이라면 효율성은 서버의 영역이다. 물론 클라이언트, 서버 간의 흐름이나 연계 구조가 유기적으로 얽혀있기 때문에 이 둘을 딱 잘라 구분할 수는 없다. 서버에서도 단말의 편의성을 고려한 설계가 수반되어야 하는 부분이 있을 수 있고 단말도 나름의 효율성을 위해 처리하는 연산을 되도록 줄이는 것이 중요하지만 설계나 구현에 들어가는 비중으로 보면 그렇다는 것이다.

효율성을 좌우하는 것은 먼저 CPU로 하여금 가능한 한 적은 연산을 수행하도록 하는 것이다. 먼저 스트리밍 대상이 되는 문서의 성격을 잘 파악할 필요가 있다. 이를테면 스마트폰이 일상이 된 현재도 많은 e-book 서비스는 워드프로세서로 작성한 문서가 아닌 여전히 텍스트에 첨부 이미지가 곁들여진 문서를 출력해서 보여준다. 소설이나 수필과 같은 문학 작품이라면 괜찮을 것이나 디자인 시안이나 프리젠테이션 문서의 경우 단순히 이미지와 텍스트의 조합으로 출력하는 것은 곤란하다. 이와 같이 콘텐츠 성격에 맞도록 소요 자원을 적절하게 안배할 필요가 있다.

안정성은 말 그대로 안정적인 서비스 유지에 대한 지표이다. 이를테면 재시작하지 않고 장시간동안 서비스를 구동 상태로 두어도 shutdown이 되지 않고 서비스 시작 당시와 동일한 상태를 유지할 수 있는지를 판단하는 기준이 된다. 아울러 여러 사용자의 동시 열람 요청으로 트래픽이 몰려도 최대한 이를 수용하고 물리적인 이유로 더 이상 처리가 어려울 경우 대기를 시키거나 다시 시도하라는 안내 메시지를 통해서 이를 보완해야 한다.

또한 특정 OS에서 동작하도록 계획이 됐다면 그 OS의 특성과 구조를 최대한 활용하는 것도 중요하다. 이를테면 OLE Automation을 활용할 경우 관련 프로그램에 크게 의존하게 되는데 각각의 작업들이 충돌하지 않도록 작업 영역을 최대한 분할해서 처리하면 안정적으로 작업을 할 수 있다. 혹은 CPU 코어 점유에 제한을 걸어서 동시 처리에 문제가 없도록 튜닝을 거쳐 판단하는 것도 방법이다.

 

 

 

서비스 구성

서비스를 구축하기 위해서는 인증 정보를 전달하고 문서를 다운로드 받게 될 ‘첨부 문서 관리부’가 필요하다. 그리고 실제로 문서를 분석하고 이를 스트리밍이 가능하도록 데이터 변환을 수행할 ‘첨부 문서 변환부’도 있어야 합니다. 이는 역할에 대한 논리상의 구분이며 반드시 별도의 모듈이나 서버로 나눠야 하는 것은 아니다.

 

대략적인 사이클은 다음과 같다.

1. 기간계 서비스의 사용자 인증
2. 첨부 문서 관리부에서 문서 다운로드
3. 첨부 문서 변환부에서 스트리밍 데이터로 변환
4. 데이터 수신 및 출력

메일, 게시판, 클라우드 기반 보관함 등 사용자가 스트리밍을 통해 열람하려는 문서는 기간계 시스템에서 관리하고 있을 것이며 이를 정상적으로 전달받으려면 사용자 인증을 거쳐야 한다. 먼저 모바일 단말은 사용자 인증을 위해서 SSO 정보와 같은 인증 데이터를 에이전트 파트에 전달한다. 에이전트는 단말에서 받은 인증 정보로 기간계 서비스에 인증을 요청하고 통과되면 문서를 전달받는다. 전달받은 문서는 변환 서버와 공유하면서 스트리밍이 가능한 문서로 변환을 시도한다. 마지막으로 모바일 단말은 첨부 문서 변환부에서 변환한 데이터를 받아서 출력한다.

 

 

문서 처리 솔루션

문서 스트리밍 서비스의 핵심 기술은 문서를 스트리밍 전송이 가능하도록 변환하고 이를 다시 취합하여 보여주는 것이다. 많이 사용하는 MS 오피스, PDF, 한글(hwp) 문서가 그 대상이 된다.

 

 

서버의 첨부 문서 변환부와 단말에서의 출력 모듈을 구축하기 위하여 도입해야 하는 솔루션들은 어느 정도의 수준으로 제공이 되고 어떻게 활용할 수 있는지 소개하겠다.

 

1) OLE Automation의 활용

일반적으로 알려진 방법은 MS 오피스 문서, 한글(hwp)의 경우 프로그램에서 제공하는 OLE Automation 함수를 활용하는 것이다. 이들 문서 프로그램은 사무 자동화를 위한 OLE Automation 함수가 제공된다. 해당 기능으로 일정 수준의 문서 Object 정보들을 추출할 수 있고 인쇄나 PDF 저장 기능도 수행하기 때문에 편리하게 사용할 수 있다.

다만 OLE Automation을 활용하기 위해서는 서버에 MS 오피스, 한글(hwp)등 관련 소프트웨어가 설치되어야 하며 서버 라이선스가 필요하다. 참고로 OLE Automation은 마이크로소프트에서 제공하는 COM 기반의 기술로 Windows NT 계열의 서버에서만 활용이 가능하기 때문에 리눅스 OS에서는 적용이 쉽지 않을 수 있다.

 

마이크로소프트 오피스

마이크로소프트 오피스는 워드, 엑셀, 파워포인트 등 모든 프로그램에 대한 자동화 API가 존재하며 이는 Visual Basic for Applications(이하 VBA)이라는 이름으로 제공된다. 마이크로소프트가 개발한 프로그래밍 언어인 Visual Basic과의 통합 환경에서 오피스 자동화 기능에 손쉽게 접근하려는 용도이다. 단 COM 기반이기 때문에 꼭 Visual Basic이 아니더라도 타입 라이브러리 정보만 있다면 C++, C#, Java, Delphi등과 같은 범용 언어에서도 사용할 수 있다.

관련 레퍼런스는 아래 링크를 통해서 확인하실 수 있다.

https://docs.microsoft.com/en-us/office/vba/api/overview/

 

한글(hwp)

한글(hwp)도 한글 컨트롤(HwpCtrl)이라는 이름으로 OLE Automation 함수가 제공된다.

관련 API 정보와 사용 가이드는 아래 링크를 통해서 확인하실 수 있다.

https://www.hancom.com/board/devdataView.do?board_seq=47&artcl_seq=4082

 

Libre Office

Libre Office는 과거 Open Office에서 출발했고 가장 인기가 있는 오픈소스 기반의 오피로 UNO(Universal Network Objects)라는 이름의 API로 제공되고 있다.

관련 API 정보는 아래 링크를 통해 확인하실 수 있다.

https://api.libreoffice.org/

 

2) 오픈소스의 활용

한 때 PDF 문서 페이지를 생성하거나 렌더링하는 작업을 유료 솔루션에 의지해야 했던 시절이 있었다. 하지만 소프트웨어 시장의 흐름에 따라 개발용 도구나 라이브러리에서의 오픈소스 비중이 커지고 있다. 문서 처리 관련 주요 오픈소스 라이브러리는 다음과 같다.

 

PDFium

PDFium은 PDF 렌더링 엔진이다. 대표적으로 웹브라우저인 구글 크롬이 PDF 출력 시 PDFium을 활용한다. BSD 라이선스이므로 기업에서는 부담없이 사용할 수 있으며 필요에 따라서는 추가적인 수정을 자유롭게 할 수 있다는 장점이 있다.

PDFium 라이브러리는 PDF 문서에 대한 많은 기능을 활용할 수 있으며 빠른 속도와 높은 싱크로율(Adobe Reader로 봤을 때와 비교했을 때)을 자랑한다. C++코드로 작성되었고 내부적으로 Ninja라는 가볍고 빠른 빌드툴을 사용하고 있으며 OS는 윈도우, OSX, 리눅스는 물론 모바일 환경인 안드로이드, iOS 등 다양한 플랫폼에서 활용이 가능하다. 단 공식적으로 구글에서 가이드 문서가 제공되지는 않고 Foxit 사에서 PDF SDK Reference guide에 PDFium 문서가 포함되어 있다.

https://developers.foxit.com/resources/pdf-sdk/c_api_reference_pdfium/group___f_p_d_f_i_u_m.html

웹 사이트는 아래와 같다.

https://pdfium.googlesource.com/pdfium/

아울러 실제로 다양한 방법으로 빌드해보고 여러 번의 시행착오 경험담을 알려주는 어느 한 개발자의 블로그도 도움이 될 것 같아서 함께 덧붙인다.

PDFium 라이브러리 삽질기: https://iskra.sarang.net/198

 

OpenMCDF

OpenMCDF는 MS 오피스에서 다루는 대부분의 문서의 근간이 되는 마이크로소프트 복합 문서 파일(Microsoft Compound Document, OLE 구조화 스토리지라고도 함)에 대한 정보를 가져오거나 생성과 편집을 자유롭게 할 수 있는 라이브러리이다. 닷넷(.NET) 기반이라 C# 언어로 쉽게 활용할 수 있으며 Mozilla Public 라이선스 2.0을 적용받는다.

아래 사이트에서 확인이 가능하다.

∙ Nuget: https://www.nuget.org/packages/OpenMcdf/

∙ GitHub: https://github.com/ironfede/openmcdf

대상이 되는 문서는 doc, xls, ppt와 같이 MS 오피스 2003 이전 기준으로 저장되는 표준 문서이다. 현재 사용하는 docx, xlsx, pptx처럼 오피스 오픈 XML 구조의 문서와 비교했을 때 XML 포맷이 아닌 바이너리 형태로 되어있다는 차이가 있다.

MS 오피스 2007 이후부터 표준 문서가 된 오피스 오픈 XML 문서의 경우 다음 챕터에서 소개할 Open Xml SDK를 참고하기 바란다.

 

Open XML SDK

Open XML SDK는 MS 오피스에서 다루는 오피스 오픈 XML 구조의 문서에 대한 정보를 가져오거나 생성, 편집을 자유롭게 할 수 있는 라이브러리이다. 닷넷(.NET) 기반으로 C# 언어로 쉽게 활용할 수 있으며 MIT 라이선스를 적용받는다.

docx, xlsx, pptx도 형태만 XML일 뿐 구조적인 기반은 앞서 다룬 마이크로소프트 복합 문서(Microsoft Compound Document)와 동일하다.

아래 사이트에서 확인이 가능하다.

∙ Nuget: https://www.nuget.org/packages/DocumentFormat.OpenXml/

∙ GitHub: https://github.com/OfficeDev/Open-XML-SDK

∙ 가이드 문서: https://docs.microsoft.com/en-us/office/open-xml/open-xml-sdk

이전 버전인 바이너리 문서와 현재 MS 오피스의 표준으로 자리잡은 오픈 XML 문서 모두를 지원하기 위해서는 OpenMCDF, Open XML SDK를 함께 활용하는 것이 좋다.

 

Apache PDFBox

Apache PDFBox는 아파치 소프트웨어 재단에서 만든 java 기반의 PDF 문서 라이브러리로 대부분 java 플랫폼에서 동작하는 프로그램 개발 시 많이 애용되고 있다. PDF 파일을 읽거나 생성, 편집이 가능하며 렌더링 기능도 지원한다.

필자는 해당 솔루션을 사용해보지 않았지만 서버는 Spring 프레임워크로 개발하고 모바일은 안드로이드까지 지원한다면 유용하게 활용할 수 있을 것으로 생각된다.

∙ 공식 사이트: https://pdfbox.apache.org/

∙ GitHub: https://github.com/apache/pdfbox

∙ GitHub (안드로이드 지원): https://github.com/TomRoush/PdfBox-Android

 

Apache POI

Apache POI는 아파치 소프트웨어 재단에서 만든 Java 기반 라이브러리이다. 마이크로소프트 오피스 파일 포맷을 순수 자바 언어로서 읽고 쓰는 기능을 제공한다.

앞서 소개한 OpenMCDF, Open XML SDK의 Java 버전이라 생각하면 된다. 주로 워드, 엑셀, 파워포인트 파일을 지원하고 최근에는 아웃룩(msg), 비지오(visio), 퍼블리셔 등으로 지원 파일 포맷을 늘려가고 있다. 아직 개발이 진행 중인 단계로 기능적으로 지원되지 않는 부분(이를테면 특정 object를 인식하지 못한다든가)들이 있으니 도입 결정 전에 충분한 검토가 필요할 수 있다.

∙ 공식 사이트: https://poi.apache.org/

∙ GitHub: https://github.com/apache/poi

참고로 컨텐츠 파싱 전용 라이브러리인 Apache Tika가 오피스 문서 감지용으로 해당 라이브러리를 사용하고 있다.

 

QPDF

QPDF는 하나의 PDF 파일을 동등한 내용으로 다른 포맷의 PDF 파일로 변환하는 기능을 제공한다. PDFium이나 Apache PDFBox처럼 다양한 PDF 문서 처리 기능을 제공하는 것은 아니지만 특정 기능에 특화되어 있어 스트리밍 서비스 구축 시 유용하게 활용 가능한 소프트웨어이다. 대락 △선형화 △암호화 및 복호화 △페이지 병합 및 분할 기능이 제공된다. QPDF는 커맨드 방식으로 동작하는데 Apache 2.0 라이선스를 적용 받는 오픈소스이므로 라이브러리 형태로도 활용이 가능하다.

∙ 공식 사이트: https://qpdf.sourceforge.io/

∙ GitHub: https://github.com/qpdf/qpdf

 

3) 외부 솔루션 도입

전자 문서 솔루션은 표준이 다양하고 많은 형태의 출력 케이스를 충족하면서도 성능이 보장되어야 하기 때문에 자체 기술력을 확보하는 것이 쉽지 않다. 따라서 외부 솔루션을 도입하는 것도 좋은 방법이다.

국내의 전자 문서 솔루션 전문 기업은 다음과 같으니 참고하기 바란다.(가나다 순)

∙ 사이냅소프트: https://www.synapsoft.co.kr/

∙ 유니닥스: http://www.unidocs.co.kr/

∙ 이파피루스: https://epapyrus.com/

∙ 쿠쿠닥스: https://kukudocs.com/

∙ 포시에스: https://www.forcs.com/kr/

∙ 폴라리스 오피스: https://www.polarisoffice.com/

∙ 휴먼토크: https://www.hmtalk.com/

 

 

문서 스트리밍 서비스 구현 사례

많은 전자문서 솔루션들이 PDF 문서를 중심으로 하는데 그 이유는 다음과 같다.

∙ 대부분의 문서는 PDF 파일로 치환이 가능하다. MS 오피스 문서나 한글의 경우 OLE Automation 함수를 통해서 PDF로 저장할 수 있으며 텍스트 문서를 PDF 포맷으로 변환하는 것도 가능하다. 변환된 결과물이 변형되거나 누락되지 않고 원본 문서와 100%에 가까운 싱크로율을 보인다.

∙ 선형화 작업을 통해 실시간 스트리밍 서비스에 최적화된 구조를 가져올 수 있다.

∙ 공식적으로 문서 포맷이 공개되어 있다. (참고: https://ghostscript.com/~robin/pdf_reference17.pdf)

∙ PDF를 다루는 오픈소스 라이브러리나 문서 솔루션 업체가 다양하게 존재해 선택의 폭이 넓고 원활한 이슈 대응 및 기술 지원을 기대할 수 있다.

참고로 문서 솔루션 중에서는 PDF가 아닌 PNG, Jpeg와 같은 이미지 파일이나 html과 같은 웹페이지 포맷을 output으로 제공하는 케이스도 있다.

PDF로 문서 스트리밍 서비스를 구성하는 법은 다음과 같다.

 

1) PDF로의 변환

대부분의 문서는 PDF로 변환이 가능하다. 가장 손쉬운 방법은 오피스 프로그램에서 제공하는 OLE Automation을 활용하는 것이다. PDF로 저장하기 기능을 통해서 쉽게 변환할 수 있기 때문이다. OLE Automation이 아닌 서드파티 업체를 활용하는 방안도 있고 설계 및 구현 디테일에 따라서 Apache POI, OpenMCDF, OpenXMLDocument 등과 같은 오피스 분석 도구를 통해서 직접 구현하는 방법도 있다. 

 

2) 선형화(Linearization)

일반적인 PDF 문서 구조 특성 상 원활한 스트리밍을 위해서는 선형화 작업을 해줘야 한다. PDF가 오브젝트들이 얽혀있는 구조다보니 이 상태로는 스트리밍 전송이 쉽지 않기 때문이다.

 

선형화 작업을 하면 동영상 서비스처럼 PDF 문서에 대한 스트리밍 처리가 수월해진다. 작업은 QPDF라는 소프트웨어를 활용하면 된다.

 

3) 스트리밍 전송

선형화 작업이 완료됐으면 이제 사용자가 원하는 페이지에 맞춰서 문서 데이터를 스트리밍 형태로 단말에 전송한다.

 

 

단말에서는 PDFium가 제공하는 렌더링 기능을 활용한다. 서버에서 받은 스트리밍 데이터로 렌더링 작업을 해 pdf 원문과 동일하게 화면에 출력한다. 그리고 워드나 pdf의 페이지 이동, 엑셀 문서의 셀, 시트 이동과 같은 영역 변경이 발생할 때마다 추가로 변환 및 전송을 반복한다. 이 때 이미 변경된 산출물이 저장 공간에 남아있는 경우 최대한 재사용한다.

 

 

운영 전략

서비스에 적용하기에 앞서 어떤 식으로 운영할 것인가에 대한 검토가 필요하다. 이는 서버의 자원을 효율적으로 안배하고 보안성도 계속 유지하기 위해 필요한 절차로 보면 된다. 물론 개발 단계에서는 모든 가능성을 열어둔 개발이 필요하며 운영으로 넘어갈 때 환경설정으로 선택이 가능하도록 해야 할 것이다.

 

1) 변환 시점 결정하기

문서를 스트리밍이 가능하도록 메타데이터로 변환하는 데에는 많은 시간과 하드웨어 자원이 소요된다. 오피스 문서를 PDF로 변환하는 작업이나 PDF 문서 선형화와 같은 예시를 살펴보더라도 문서 전체를 읽어 들이고 분석하면서 재배치하는 과정이 필연적으로 들어갈 수 밖에 없기 때문이다. 따라서 사용자 입장에서 문서 열람을 위한 대기 시간을 최소화 하는 것과 첨부 문서 변환을 담당하는 서버의 CPU와 저장 공간을 적절히 안배하는 것, 이 두 마리 토끼를 잡기 위한 고민이 필요하다.

서버 가용량과 사용자의 쾌적한 사용성 등 여러가지 환경을 고려하여 변환 시점을 결정해야 하는데 판단 기준은 다음과 같이 잡을 수 있다.

선변환

선변환은 사용자가 문서를 열람하기 전에 원본 문서를 스트리밍 가능하도록 미리 변환을 해두는 작업이다. 문서 열람 시 대기 시간이 대폭 줄어든다는 장점이 있다.

변환 시점은 서비스 상태나 사용자 시나리오에 따라 알맞게 정할 수 있다. 발송자가 첨부 문서가 포함된 메일 전송이나 게시물을 업로드 할 때 미리 메타데이터로 변환하면 수신자는 해당 첨부 문서를 대기 없이 짧은 시간에 볼 수 있다. 단 매번 업로드를 할 때 변환 시간까지 포함되기 때문에 발송 시 딜레이가 생길 수 있다. 따라서 매번 업로드 할 때마다 문서 변환을 무조건 하는 것이 아닌, 수신자 혹은 열람 가능성이 있는 사용자가 모바일에 로그인 한 이력이나 모바일 사용률에 따라서 변환을 미리 할 것인지 여부를 선택하도록 할 필요가 있다.

 

후변환

기업 규모에 따라 다르겠지만 대기업의 경우 메일 발송이 하루에 수십만 혹은 수백만 건씩 발생한다. 매번 메일 발송이나 결재 상신 때마다 문서를 변환하는 것은 서비스 운영자 입장에서는 큰 부담일 것이다. 이렇게 메일을 발송할 때마다 첨부 문서를 계속해서 스트리밍용으로 변환하기 위해서는 많은 서버 자원이 필요한데 이를 충당하기 위해 들여야 할 비용이 만만치 않기 때문이다.

따라서 이러한 경우 사용자가 요청할 때 변환을 발생시키도록 하는 방법을 채택할 수 밖에 없다. 절충안으로 문서를 열람하는 UI가 화면 상에서 잡힐 경우 사용자가 클릭하기 전에 미리 변환을 수행하는 방법을 고려할 수 있다.

동시에 많은 사람들이 보는 문서일수록 선변환을 수행하고 대상이 적고 발생량이 많은 시스템일수록 후변환을 수행하는 것이 유리하다. 선변환을 할지, 후변환을 할지는 메시지 발생량, 사용자 문서 열람 발생 수를 고려해 결정하면 된다.

 

2) 보안 등급에 따른 산출물 저장 기한 결정하기

변환을 수행하는 동안에는 많은 CPU 자원과 일정량의 메모리가 필요하며 변환 후 산출물을 저장하기 위한 별도의 저장 공간이 요구된다. 대외비 문서의 경우 최대한 보안을 유지해야 하기 때문에 변환 결과물을 가급적이면 바로 제거하는 것이 좋다. 이는 외부 해킹에 대한 보호 목적과 더불어 서버 접근 권한을 가지고 있는 관리자(개발, 운영 등)들도 내용을 볼 수 없도록 통제할 필요가 있기 때문이다.

대신 보안 유지를 위하여 매번 열람을 마칠 때마다 문서를 삭제한다면 이를 재사용 할 수 있는 기회를 잃게 된다. 문서 보안 등급에 따라 등급이 낮은 문서는 스토리지에 오래 보관하면서 재사용 여지를 남길 필요가 있다. 사내 게시판이나 제품 카탈로그처럼 많은 사람들이 열람하는 문서는 보안 등급을 낮게 책정하고 대외비 문서는 보안 등급을 최대한 높게 잡는 식으로 자원을 안배하는 전략이 필요하다.

앞서 서술한 선변환, 후변환에 대한 케이스도 보안 등급과 상관성이 있다. 선변환이 유리한 문서일수록 보안성이 낮을 가능성이 크고 후변환이 유리한 문서일수록 보안성이 높은 문서일 가능성이 높다.

 

 

마치며

이때까지 기업용 문서 스트리밍 서비스의 개략적인 설명과 개발 및 구축 전략을 설명했다. 앞으로 데이터 기술이 첨단화 되고 다양한 장소에서 업무를 처리하는 환경, AR∙VR과 같은 방법으로 사용자 요구를 반영하는 비즈니스 모델 등 진화하는 생태계에 맞춰 모바일 전자문서 서비스도 발전 방향에 대한 고민이 필요하다. 아울러 안정적이고 장기적인 서비스 유지 측면에서 이상적인 자원 안배 방안 수립과 보안 수준 향상에 대한 노력이 지속되어야 할 것이다.