WebAsssembly는 새로운 표준의 하나로 보안과 빠른 웹 페이지 이동을 유지하면서 크기와 로딩 시간 면에서 효율적인 포맷을 정의하기 위한 목적으로 진행되고 있습니다. WebAssembly는 컴파일러에 의해서 네이티브에 가까운 성능으로 동작합니다.즉, WebAssembly는 웹을 위한 가상 CPU 실행 코드입니다. 현재는 Mozilla, Microsoft, Google그리고 Apple을 포함한 회원사로 구성되는 W3C의 커뮤니티 그룹(CG)에서 논의되고 있습니다.

WebAssembly가 중요한 로드맵으로 복수의 브라우저가 WebAssembly을 상호 운용 가능한 형태로 지원 중입니다. 현재는 실험적인 것이며, 표준 구현에도 몇몇 완료되지 못한 기능이 있습니다. 하지만 그동안의 성과를 공개하고 피드백을 모아 다음에 할 일에 관한 논의를 하기에는 좋은 기회입니다.

WebAssembly를 도입하는 이유

JavaScript의 낮은 레벨의 asm.js을 통해 웹 브라우저가 샌드박스에 의한 안전성을 유지하면서 네이티브 코드에 가까운 계산 성능을 낼 수 있는 것이 나타났습니다. 동시에 이들 기능에 대한 수요가 매우 커서, 웹 게임이나 CAD, 화상 처리나 얼굴 인식과 같은 다양하고 많은 애플리케이션이 Emscripten 컴파일러를 통해서 asm.js을 이용하게 되었습니다.

지난해 결성한 WebAssembly 커뮤니티 그룹은 바이너리 포맷의 표준화를 위한 다음 단계를 진행했습니다. 이 포맷으로 JavaScript에서 가능한 한계를 넘어 파일 크기를 줄이고 로드 시간을 단축 시킬 수 있게 되었습니다. 또한, 독립된 새로운 표준이 되기 위해 WebAssembly는 기본적인 단계의 기능을 JavaScript의 진화와 별도로 도입할 수 있게 되었습니다.

뿐만 아니라 WebAssembly가 웹 기술의 일부분으로 계속 되는 것의 중요성도 인식하고 있습니다. 기존의 Web API 접속, JavaScript에서 정의된 함수의 상호 호출과 같은 JavaScript와의 긴밀한 결합성은 유지되어야 합니다. 다만, 플러그 인 모델과 달리 WebAssembly는 JavaScript에 의한 애플리케이션이나 라이브러리와 asm.js 처럼 쉽게 결합할 수 있습니다.

WebAssembly의 초기 설계에서 Emscripten과 asm.js에 관한 경험을 참조할 수 있었습니다. 또한, 브라우저가 asm.js를 고속으로 동작하는데 대응하지 않는 웹 브라우저에서 WebAssembly를 이용하기 위한 Poloyfill 기능도 개발되었습니다. 이를 이용함으로써 각 브라우저 WebAssembly에 대응이 충분히 이뤄지기를 기다리지 않고도 WebAssembly를 이용하여 개발할 수 있습니다.

진행 사항

과거의 이야기는 이 정도로 하고, 최근 소식을 알려드리도록 하겠습니다. 커뮤니티 그룹은 아래의 성과를 달성하고 있습니다. 모든 기술 문서는 WebAssemby의 GitHub에서 공개되고 있습니다:

• 기능 사항: 초기 구현 및 장래적인 계획에 관한 이론적 근거와 소개
• 표준 사양 및 레퍼런스 구현
• 인터프리터와 웹 브라우저의 실행 결과를 검증하기 위한 13,000행에 이르는 테스트 구현
• 바이너리 포맷 초안 작성

또한 4개의 주요 웹 브라우저 엔진을 작성하는 엔지니어가 WebAssembly의 프로토 타입 구현하고, asm.js의 최적화 파이프 라인을 리팩토링, 구문 분석 쓰레드에서 백그라운드 컴파일러 스레드에 넘어가 asm.js의 코드 표현을 WebAssembly의 바이너리 포맷으로 변경했습니다.

이러한 변경으로 asm.js의 병렬 컴파일 성능이 많이 향상됐습니다. MIR 생성과 코드 생성이라는 두 가지 무거운 처리를 순차절 크리티컬 패스로부터 분리되어 나누었기 때문입니다. 최적화된 프로세스 파이프 라인의 리팩터링을 통해 신뢰할 수 없는 바이트 코드의 검증하기 위한 작은 프론트 엔드로 WebAssembly 디코딩 부분을 구현하였습니다.

위에서 이용한 용어의 정의나, JS와 asm.js의 컴파일에 관한 배경 지식에 대해서는 블로그 글을 참조하세요.

WebAssembly 사용해 보기

이제 WebAssembly를 실제로 동작해 볼 수 있게 되었습니다. “실험적”인 두 가지 요소, 즉 바이너리 포맷과 WebAssembly에 대한 JavaScript 바인딩에는 최초 표준 완성까지 향후 수 개월 간에 몇가지 변경이 있을 것으로 예상됩니다. 아직 모든 브라우저가 지원하기까지는 계속적인 구현과 테스트 등이 필요합니다만 현재까지 어느 정도 구현된 라이브 데모를 볼 수 있습니다.

위의 화면은 AngryBots는 Unity의 튜토리얼 프로젝트에서 Unity의 WebGL 출력을 만든 스모크 테스트입니다. 이 데모를 위해서는Firefox의 Nightly 빌드을 다운로드하고 about:config에서 javascript.options.wasm에 true를 설정하세요.

출시 로드맵

안정된 기능 출시를 하기 전에 할 일이 아직 있습니다. 커뮤니티 그룹은 아래 작업이 매우 필요하다고 생각하고 있습니다:

• 개방적인 WebAssembly 텍스트 표현 정의
• 바이너리 포맷의 사이즈 추가 및 축소. 현재 바이너리 포맷은 압축되지 않는 asm.js와 비교해서 42% 축소(gzip 압축시는 12%) 되었으나, 바이너리 포맷에 관한 작업 결과 더욱 크게 줄일 것을 알고 있습니다
• WebAssembly JavaScript API 개선. 현재 실험적인 빌드에는 wasm.instantiateModule라는 동기적인 함수 하나만 정의되어 있습니다. 이는 컴파일과 인스턴스 작성 두 가지를 실행합니다. 잠정적인 계획에서는 이들 두 개의 처리를 분리하고 구조화하여, 복제 가능 코드 객체를 출력하는 함수를 준비하려고 합니다. 새로 마련되는 함수는 동기적으로 실행하는 것 외에 비동기적으로 실행되며,이로서 현재 암묵적으로 실행되는 asm.js가 훨씬 유연하게 컴파일과 네이티브 코드의 캐싱 제어를 할 수 있게 됩니다.
• 컴파일러 개발자 도구 및 학생들에게 보다 읽기 쉬운 개발 문서 정비
• 테스트 스위트를 보강

Firefox에 관해서는 아래 사항을 예정하고 있습니다.

• 디버거와 프로 파일러 포함, 개발 도구에서 WebAssembly 대응. JavaScript에서는 Firefox에 내장된 개발 도구와 Firebug 팀이 협력하여 새로운 추상적이고 테스트 가능한 Debugger API를 사용하는 방향으로 가고 있습니다. 우리는 이 API을 WebAssembly용으로도 만들려고 합니다. 기능 구현은 이미 시작됐고, 앞에서 본 데모를 실행 중에 디버거의 탭을 열면, 바이너리 포맷에서 생성된 텍스트 포맷을 보기 위한 플레이스 홀더가 놓이는 것을 보실 수 있습니다.(개방된 텍스트 포맷이 정의된 시점에서 그것을 대체합니다)
• 콜드 로드에 걸리는 시간의 단축. 16개 2.4 GHz의 코어를 가진 Linux 기계로 측정한 결과 WebAssembly기반 AngryBots의 컴파일 시간은 asm.js 보다 52% 정도 감소했습니다. 이는 WebAssembly의 디코딩에서 코드는 asm.js의 파싱보다 10배 정도 높은 속도로 인한 결과입니다. 컴파일 파이프 라인의 다른 부분을 개량함으로써 콜드 로드의 추가 단축이 가능합니다
• WebAssembly에서 정의된 연산자 구현 및 테스트 개발

WebAssembly의 개발 방향은 지금까지 항상 긍정적인 것이었습니다. WebAssembly 커뮤니티 그룹의 협력을 촉구하는 분위기와 구현에 대한 감사 인사가 끊어지지 않습니다. 더 자세히 알고 싶은 분은 GitHub 페이지을 보세요.여기서 시작하시면 됩니다. Happy hacking!

이 글은 Luke Wagner의 A WebAssembly Milestone: Experimental Support in Multiple Browsers의 한국어 번역입니다.