안드로이드 한글 뷰어 만들기: rhwp + WebView를 문서 222개로 실측한 기록

측정 조건: S21 한 대, 문서 222개, 매번 콜드 스타트

rhwp는 Rust로 짠 HWP·HWPX 파서를 WebAssembly(WASM)로 빌드한 오픈소스 엔진입니다. 문서의 쪽을 SVG로 그려 주고, 라이선스는 MIT입니다. 측정에는 npm 패키지 @rhwp/core 0.8.6을 썼고, 지금 출시된 앱도 같은 버전에 고정돼 있습니다.

테스트 앱은 WebView 하나에 rhwp와 rhwp가 제공하는 글꼴 CSS(글꼴 규칙 153개)를 넣었습니다. 문서마다 앱을 강제 종료한 뒤 다시 띄웠고, 앞 3쪽만 화면에 그리고 나머지 쪽은 렌더링 시간만 쟀습니다.

• 정책브리핑(korea.kr) 보도자료 첨부: 2026-10-02에 받은 17파일(보도자료 14건, HWPX 13·HWP 4)
• rhwp 저장소의 샘플 198개: 한컴오피스 2020/2022로 출력한 정답 PDF가 함께 있어 쪽 수와 첫 쪽 이미지를 비교할 수 있습니다. 시험지, 수식, HWP 3.0 변환 문서처럼 까다로운 사례가 많습니다.
• 그 밖의 7개: 아래 "AI가 틀린 숫자" 절에서 설명합니다.

저사양 기기는 없었습니다.

측정표: 221/222 열림, 첫 쪽까지 중앙값 1.2~1.5초

"탭→첫 쪽"은 콜드 스타트를 포함해 앱 실행 시간과 첫 쪽 렌더링 시간을 더한 값입니다. p90은 느린 쪽 10%가 시작되는 값입니다. 렌더러 메모리는 WebView 렌더러 프로세스의 PSS(공유 메모리를 나눠 계산한 실사용량)로 쟀습니다.

못 연 1개는 issue2063_huge_cellbreak_table.hwp입니다. 쪽 나눔이 걸린 초대형 표로 성능을 시험하려고 일부러 만든 문서라서, 120초 제한을 넘겼습니다. 실측 보고서는 이런 문서를 위한 대체 경로를 채택 조건으로 걸었습니다. 지금 앱은 10초가 넘으면 계속 기다릴지, 다른 앱으로 넘길지 고르게 합니다.

모양도 확인했습니다. 정답 PDF가 있는 샘플은 쪽 수가 197개 중 195개에서 맞았고(2개는 1쪽 차이), 첫 쪽 이미지 유사도 중앙값은 0.997이었습니다. 문서 7개(보도자료 2, 샘플 5)는 한컴 출력과 나란히 놓고 눈으로 봤습니다. 보도자료의 표·로고·굵은 글씨, 수능 모의고사의 수식과 2단 편집이 거의 같았고, 시험지 첫 문항 번호 "문1)" 하나만 빠져 있었습니다.

384쪽 문서는 보이는 쪽만 그려야 버팁니다

rhwp 샘플에는 384쪽짜리 행정 편람(파일 10.7MB)이 있습니다. 모든 쪽의 SVG를 한꺼번에 DOM에 넣자 WebView 렌더러 프로세스가 2.8GB까지 커졌습니다. 같은 문서를 보이는 쪽만 그리는 방식으로 열었을 때는 255MB였습니다. 같은 날 다른 회차에서는 366MB가 나왔습니다.

HWP 뷰어를 WebView로 만든다면 가상 스크롤(보이는 쪽과 그 앞뒤만 DOM에 두는 방식)을 처음부터 넣으십시오.

출시한 앱은 모든 쪽에 크기만 잡힌 빈 칸을 두고, 화면에 보이는 쪽 앞뒤로만 SVG를 둡니다. 메모리가 넉넉한 기기는 앞뒤 2쪽, 적은 기기는 1쪽입니다. 그려 둔 SVG 문자열은 바이트 한도가 있는 LRU 캐시에 넣고, 한도를 넘으면 가장 오래 안 본 쪽부터 버립니다.

글꼴은 144MB에서 9.2MB로 줄였습니다

rhwp가 함께 배포하는 글꼴 폴더는 파일 87개, 144,327,972바이트입니다. 실측 문서에는 이 값이 "138MB"로 적혀 있는데, 1MB를 1,048,576바이트로 센 값입니다. 222개 문서가 실제로 쓴 글꼴은 17개 파일, 약 37MB였습니다.

앱에는 10개 파일, 9,207,952바이트(원래의 약 6%)만 넣었습니다. 기준은 라이선스와 모양 두 가지였습니다. 함초롬체는 앱 탑재 조건이 한컴 페이지에 명확히 적혀 있지 않아 빼고, 함초롬바탕은 Noto Serif KR, 함초롬돋움은 나눔고딕 같은 OFL 글꼴로 바꿔 그립니다. rhwp에 들어 있던 나눔고딕은 예약 이름을 그대로 둔 서브셋이어서, google/fonts의 원본 TTF로 바꿨습니다.

바꾼 글꼴로 모양이 얼마나 달라지는지는 2026-10-05에 같은 S21에서 다시 쟀습니다. 첫 쪽의 잉크 일치도(F1)가 정답 대비 얼마나 떨어지는지를 봤고, 미리 정한 기준은 중앙값 0.02 이하였습니다. 결과는 0.0071로 통과했습니다. 기준을 넘은 문서가 하나 있었습니다. 제목이 한자인 수능 문서로 0.0336이었고, 차이는 제목 한자와 원문자(①~⑤)에 몰려 있었습니다. 번들 글꼴에 한자가 없어 시스템 글꼴이 그린 부분입니다.

AI가 틀린 숫자와 검증 에이전트가 고친 값

엔진 실측은 AI 코딩 에이전트(Claude) 세션이 돌렸고, 보고서도 그 세션이 썼습니다. 이틀 뒤 후속 실험에서는 측정하는 에이전트와 별도로 검증 에이전트를 두고, 증거 파일을 다시 열어 수치를 재계산하게 했습니다. 문서에는 정정된 값만 남겨 둡니다. 처음 보고서의 통계도 이때 다시 세었습니다.

가장 크게 틀린 건 첫 줄입니다. "공문서 24/24"는 그럴듯하게 읽히지만, 24개 중 7개는 공문서가 아니었습니다. 17파일만 다시 계산하면 오히려 더 빠르고(중앙값 1.4초) 메모리도 적습니다(최대 286MB). 엔진 판단은 바뀌지 않았지만, 검증 없이 발행했다면 출처가 틀린 숫자를 그대로 인용했을 겁니다.

이 글을 쓰면서 원자료 JSON(s21b.json)으로 중앙값을 한 번 더 냈습니다. 문서에 적힌 1.5초, 2.1초, 3.0초는 그대로 나왔습니다. 384쪽 문서의 366MB 회차는 이때 찾은 것입니다. (원자료 하나는 다른 분석 스크립트가 덮어써서 다시 만들어야 한다는 메모도 검증 문서에 남아 있었습니다.)

남은 일

• 저사양 기기 측정. Firebase Test Lab 저사양 기기 실행은 개발 계획 문서 기준으로 아직 돌리지 못했습니다. 렌더러 400MB대가 RAM 3~4GB 기기에서 어떻게 되는지 모릅니다.
• 한자가 많은 문서. 0.0336은 기록만 해 두었고, 표본은 2개뿐입니다.
• rhwp 버전 올리기. 1.0 이전이라 0.8.6에 고정했고, 빌드마다 엔진 파일이 고정본과 같은지 검사합니다. 버전을 올릴 때는 같은 222개로 다시 잴 겁니다. 출시 전 검사 전체는 AI가 만든 Android 앱, 출시 전에 무엇을 검사하나에 있습니다.

자주 묻는 질문

다른 AX 노트

• Android assets를 미리 gzip한 실측: APK 이득은 0, .pack.gz는 .pack이 되어 FileNotFoundException
• SKT 판매 삼성 폰에서 market://을 열면 스토어 선택 창이 뜬다: Play 패키지부터 지정하기
• addOnCompleteListener(this)가 onStop에서 지운 리스너 때문에 스플래시에 멈춘 버그
• "6.7" < "6.11"이 거짓이라 콘텐츠 갱신이 멈췄다: 6.2~6.9 기기만 막힌 Remote Config 버전 비교
• 화살표 퍼즐 1,100판을 만든 역구성 생성기와 G2 게이트
• 대개편 직후 DAU는 올랐고, 자연 유입 코호트 D1은 15.2%에서 11.2%로 내려갔다

Android 개발 글 전체 보기 · AX 노트 전체 보기