대형 웹앱 구동 지연과 프로파일링 분할의 한계
어도비 개발자 블로그는 대규모 C++ 기반 엔진을 웹으로 이식할 때 발생하는 초기 구동 번들 비대화 문제를 완화하기 위해 '빌드 타임 Wasm 모듈 분할(Build-Time Wasm Module Splitting)' 방식을 고안해 적용했다고 밝혔다. 대상 환경은 어도비 아크로뱃 웹, 왓츠앱 내 PDF 연동 엔진, 어도비 PDF 임베드 API 등 복잡한 내부 구조를 지닌 서비스들이다.
기존 Emscripten 도구 체인은 `-sSPLIT_MODULE` 플래그를 통한 프로파일 기반 분할을 지원해 왔다. 하지만 방대한 PDF 사양 특성상 사전 프로파일링 단계에서 비정형 데이터 처리 경로가 누락될 경우 초기 구동에 필수적인 함수가 지연 모듈로 밀려나 런타임에 심각한 지연을 초래하는 위험이 있었다. 또한 누락을 방지하려면 대규모 코퍼스를 매 릴리스마다 실행해 프로파일을 재수집해야 해 빌드 파이프라인 유지 비용이 컸다.
호출 그래프와 DWARF를 결합한 빌드 타임 분할 파이프라인
새로운 분할 기법은 런타임 데이터 수집 대신 빌드 파이프라인 내부의 정적 분석 도구를 활용한다. 어도비 엔지니어링 팀은 Binaryen의 `wasm-opt --print-call-graph`를 실행해 컴파일된 WebAssembly 모듈의 정적 호출 관계를 추출하고, 자바스크립트가 초기화 단계에서 호출하는 익스포트 함수군(집합 A)과 필수 전역 및 정적 이니셜라이저(집합 B)를 우선 식별했다.
정적 호출 그래프에 잡히지 않는 C++ 가상 함수와 함수 포인터 등 간접 호출 대상은 Wasm의 Elem 테이블(집합 C)을 기반으로 처리했다. 모든 간접 호출을 1차 모듈에 포함하면 용량이 비대해지므로, `-g` 디버그 빌드의 DWARF 디버그 정보를 파싱해 지연 대상 디렉터리 경로와 C++ 네임스페이스에 해당하는 함수(집합 D)를 제외하는 규칙을 적용했다. 이렇게 정제된 함수 목록은 Binaryen의 `wasm-split`에 전달되어 즉각 다운로드되는 기본 모듈과 백그라운드로 로딩되는 보조 모듈로 분리된다.
실측 번들 18% 감축 성과와 측정 지표의 경계
어도비의 발표에 따르면 이 파이프라인을 아크로뱃 웹 프로덕션 환경에 적용한 결과 초기 구동 시 다운로드되는 기본 모듈의 크기가 11MB에서 9MB로 약 18% 감소했다. 지속적인 기능 추가에도 불구하고 시작 번들 증가를 정적으로 억제할 수 있다는 점을 실무적으로 입증한 셈이다.
다만 공개된 수치는 다운로드 파일 크기에 국한되어 있으며, 실제 네트워크 속도별 First Meaningful Paint나 Time to Interactive 등 사용자가 체감하는 렌더링 지연 시간 단축 수치는 명시되지 않았다. 어도비 측 역시 18%라는 수치는 초기화 단계 외에 분리 가능한 기능 비중이 큰 아크로뱃 웹 엔진 구조에 따른 결과이며, 초기 필수 실행 경로가 넓은 다른 앱에서는 동일한 감축률을 보장하기 어렵다고 선을 그었다.
디버그 기호 불일치와 정적 분석 파이프라인의 제약
이 기법을 도입할 때 부딪히는 실질적 기술 장애물 중 하나는 릴리스 빌드와 디버그 빌드 간의 기호 불일치 현상이다. Emscripten 컴파일 최적화 과정에서 릴리스 바이너리의 기호가 `-g` 빌드의 DWARF 메타데이터와 1:1로 일치하지 않는 사례가 발생한다.
규칙 평가가 불가능한 기호가 발생할 경우, 엔진 작동 오류를 막기 위해 해당 함수를 안전 우선 원칙에 따라 기본 모듈에 강제 잔류시켜야 한다. 이로 인해 초기 실행에 필요하지 않은 일부 간접 호출 대상 코드가 1차 모듈에 남게 되어 번들 최적화 효과가 일부 상쇄되는 한계가 존재한다.
Wasm 프로젝트 도입 시 고려해야 할 구조적 조건
빌드 타임 분할 방식을 도입하려는 개발팀은 먼저 코드베이스의 모듈화 수준을 점검해야 한다. 이 기법은 파일 경로와 네임스페이스 규칙을 기반으로 지연 대상을 필터링하므로, 기능별 경계가 모호한 레거시 모놀리식 C/C++ 프로젝트에서는 규칙 정의가 까다롭고 사전 리팩터링 부담이 커질 수 있다.
아울러 어도비는 알고리즘과 수학적 합집합 도식만을 공개했을 뿐, 내부 DWARF 파서 자동화 스크립트나 빌드 플러그인은 오픈소스로 공개하지 않았다. 따라서 타 조직이 이를 실제 환경에 적용하려면 Binaryen 도구군을 감싸는 자체 분석 파이프라인을 구축해야 하는 구현 비용을 감안해야 한다.
출처
Adobe Developers Blog의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
Build-Time Wasm Module Splitting: Ship More Features Without Growing Your Startup Bundle (새 창)
.png&w=1200&q=75)
