새로운 웹용 바이너리 포맷 '웹어셈블리(WebAssembly)' 표준화에 본격적인 시동이 걸렸다. 표준화 결과물은 구글, 마이크로소프트(MS), 모질라같은 주요 IT업체 브라우저에 녹아들어, 개발자들이 더 다양한 프로그래밍 언어로 더 나은 성능을 내는 웹 애플리케이션을 작성할 수 있도록 이끌 전망이다.
최근 웹어셈블리 표준화를 위해 웹브라우저 시장의 IT거인들이 뭉쳤다. MS 엣지(Edge) 개발팀, 구글 크롬의 바탕인 오픈소스 브라우저 '크로미엄(Chromium)' 프로젝트 멤버, 모질라 파이어폭스 개발 담당자들이 주축이다. 애플 사파리에 들어가는 오픈소스 렌더링 엔진 '웹킷(Webkit)' 프로젝트 주요 개발자들도 동참한다.
지난주 모질라 개발자 루크 와그너는 블로그를 통해 "모질라가 크로미엄, 엣지, 웹킷 엔지니어들과 웹어셈블리라는 새 표준 작성에 협력한다는 소식을 알리게 돼 기쁘다"고 밝혔다. (☞링크)
표준화된 웹어셈블리를 통해 개발자들은 자신이 원하는 프로그래밍 언어로 짠 코드를 브라우저에서 돌릴 수 있게 된다. 자바스크립트 엔진이 그 코드를 실행하는 역할을 맡게 된다. 지금은 C와 C++ 코드를 지원하는 데 초점이 맞춰져 있다. 다른 언어로 짠 코드를 지원할 가능성도 열려 있다.
■웹어셈블리란?
웹어셈블리가 뭐길래 모질라, MS, 구글, 애플 브라우저 개발자들이 나섰을까?
가장 간단하게 표현하자면 웹어셈블리는 새로운 웹용 바이너리 포맷이다. 바이너리 포맷은 컴퓨터가 디지털 정보를 읽고 쓰고 저장하기 위해 만든 규칙을 가리킨다. 이 규칙을 따라 정리된 정보가 '파일'로 저장된다. 파일에 담긴 정보를 읽고 쓰려면 그 '바이너리 포맷'을 다룰 줄 아는 소프트웨어가 필요하다. HWP 파일의 정보를 읽고 쓰려면 '한글' 워드 프로그램이 필요하고 XLS 파일의 정보를 이해하려면 MS오피스 '엑셀' 프로그램이 필요한 식이다.
'웹용 바이너리 포맷'이라 표현된 웹어셈블리를 표준화한다는 것은, 참여자들이 웹에서 정보를 읽고 쓰고 저장하기 위한 규칙에 서로 합의한다는 의미다. 일반 컴퓨터 환경이 아니라 웹 환경에 맞춰 만들어진다는 점, 표준화를 위해 특정 소프트웨어 개발업체가 아니라 여러 소속 전문가들이 함께 모였다는 점이 일반적인 바이너리 포맷과의 큰 차이다.
웹어셈블리는 이제 겨우 표준화의 첫 걸음을 뗐다. 웹 표준화 단체인 월드와이드웹(W3C)에서 공식 추진하는 단계도 아니다. 당장은 명단이 확정된 표준화 조직이 없는 상태로, 'W3C 커뮤니티그룹' 웹페이지를 하나 띄워 놓고, 이런저런 의견을 교환하는 수준이다. 프로토타입을 만들기 시작했고, 여러 브라우저에 함께 지원되게끔 합의하는 상위 수준의 설계 문서를 만들어가야 할 시점이다.
와그너는 웹어셈블리에 대해 "이식 가능하고 크기와 읽어들이는 시간 측면에서 효율적인 포맷이자 실행 모델로 정의할 수 있다"며 "웹 환경을 타깃으로 한 컴파일 수행에 특화된 것"이라고 설명했다.
현재 관련 기트허브 사이트의 '바이너리 인코딩(Binary Encoding)'이라는 문서는 웹어셈블리에 담길 추상적인 구조를 논리적인 부호체계로 표현하는 방향과 달성할 목표에 대해 묘사하고 있다. 다운로드 크기를 줄이고 빨리 디코딩(decoding)할 수 있도록 설계해 빠르게 시동되게끔 한다는 게 목표다. (☞링크)
당장 손에 잡히는 결과물은 거의 없지만, 웹 업계는 이 소식에 대단히 주목하는 분위기다. 단지 웹표준화 활동에 여러 브라우저 업체 개발자들이 함께하기 때문이 아니라, 이들이 현존하는 자바스크립트 처리 방식의 한계를 인정하고 다른 프로그래밍 언어를 품는 방향에 합의를 해나갈 것으로 기대되고 있기 때문이다.
■모질라 엠스크립튼-asm.js의 연장
웹어셈블리 표준화의 배경은 웹용 프로그래밍 언어로 독점적 지위를 누리고 있는 자바스크립트(javascript)의 성능 문제다. 모질라에서 이를 개선하기 위해 고안한 문법 축소판 언어 'asm.js'와 관련 오픈소스 프로젝트 '엠스크립튼(Emscripten)' 컴파일러가 웹어셈블리 표준화를 위한 기술적 기반이 됐다.
모질라 최고기술책임자(CTO)였던 자바스크립트 창시자, 브렌던 아이크는 개인 블로그를 통해 웹어셈블리 표준화 소식을 전하며 "웹어셈블리는 처음엔 asm.js와 이를 위한 보조표현(co-expressive) 형태로, 장기적으로는 자바스크립트 문법에서 분리 가능한 형태로 구현될 것"이라고 설명했다. (☞링크)
게임이나 멀티미디어처리용 애플리케이션으로 구현된 C 또는 C++ 코드를 엠스크립튼 컴파일러로 처리하면 브라우저에서 자바스크립트로 인식되는 asm.js 코드가 만들어진다. asm.js 코드는 최신 파이어폭스에서 일반 자바스크립트보다 더 빠르게 실행된다.
이미 구글은 이런 asm.js 최적화 기능을 크롬에 적용 중이다. MS도 엣지 브라우저에 asm.js 최적화 기능을 투입해 테스트 중(☞관련기사)이며 에픽, 유니티같은 유명 게임 엔진 업체들도 3D 고성능 웹앱을 위한 자사 기술에 asm.js를 접목할 전망(☞관련기사)이다.
다만 모질라의 asm.js가 웹앱 성능 문제에 완벽한 해법은 아니었다. asm.js는 브라우저에서 더 빨리 처리될 수 있도록 가공된 자바스크립트 코드의 한 형태일 뿐, 자바스크립트의 근본 문제를 온전히 극복할 수단은 되지 못했던 것이다.
아이크는 "asm.js 처리시 파서가 과열지점(hotspot)이 되고, 그 전 단계에서 대역폭을 절약하기 위해 이뤄진 압축을 해제하는 과정도 (전체 실행 성능에) 지장을 초래한다"며 "그리고 자바스크립트는 asm.js에서 다루기 어려운 문제점도 포함하고 있다"고 지적했다.
■상호운용성 문제 해결 장치
발상의 전환이 필요해졌다. 브라우저가 아예 자바스크립트로 인한 문제를 피해갈 수 있다면 어떨까? 자바스크립트는 그 나름대로의 역할을 하고, 성능에 민감한 코드는 다른 언어에 맡기면 안 될까? 다른 언어로 짠 코드를 자바스크립트로 바꾸지 않고도 실행할 수 있게 하면 되지 않을까?
구글의 '네이티브클라이언트(NaCl)' 또는 '포터블 NaCl(PNaCl)'은 이런 아이디어를 구현한 사례다. C와 C++ 기반 네이티브 애플리케이션을 실행하는 브라우저용 기술이다. 자바스크립트 변환을 거치지 않고 실행할 수 있긴 하지만, 이를 위해 구글 독자 플러그인 'PPAPI'가 필요하다. (☞관련기사)
이런 특성은 인터넷익스플로러(IE) 전용 플러그인 '액티브X(ActiveX)'처럼 상호운용성이 취약하다는 비판의 빌미가 됐다. 구글 크롬을 비롯해 주요 브라우저 업체들은 그래서 PNaCl 지원에 인색했다. 삼성전자가 스마트TV SDK에 이를 탑재한 희귀한 파트너로 눈길을 끌었다. (☞관련기사) 좋은 해법은 아니었다.
PNaCl이 아니라 웹어셈블리라면 얘기가 달라진다.
여러 브라우저 개발자들이 웹어셈블리 표준화에 동참한다. 향후 각 브라우저가 이를 지원할 가능성이 높은 만큼, 상호운용성 문제는 거의 없는 셈이다. 동시에 어떤 언어가 웹어셈블리 표준에 맞게 컴파일된다면, 이를 자바스크립트 대신 범용 웹 애플리케이션 프로그래밍 언어로 쓸 수 있게 된다.
아이크가 블로그에서 "브라우저가 웹어셈블리 문법(syntax)을 네이티브로 지원한다면, 전혀 다른 프로그래밍 언어를 이해하는 컴파일러를 쓰기 위해 자바스크립트에 불완전한 기능을 넣지 않더라도 자바스크립트와 웹어셈블리가 갈라설 수 있게 될 것"이라고 언급한 부분이 이를 의미한다.
이게 말이 되려면 우선 웹어셈블리 표준을 만들고 이에 맞춰 자바스크립트가 아닌 프로그래밍 언어를 인코딩하는 컴파일러도 구현해야 한다. 모질라의 엠스크립튼 프로젝트가 그 기반을 제공할 예정이다. C나 C++ 코드를 asm.js 대신 웹어셈블리 표준 문법에 맞게 바꾸는 역할을 할 거란 뜻이다. asm.js는 웹어셈블리 표준이 스스로 온전한 틀을 갖출 때까지 뼈대 구실을 해 줄 것으로 보인다.
미래의 표준을 반영할 수 없는 기존 브라우저를 위한 지원 수단도 고려되고 있다. 웹어셈블리 포맷을 asm.js 코드로 번역하는 자바스크립트 라이브러리를 통해 구형 브라우저도 대응한다는 구상이다. 표준화 팀에서는 이를 '폴리필(polyfill) 라이브러리'라 부르고 있다. (☞링크)
■자바스크립트엔진으로 C·C++ 코드를 실행한다
향후 웹어셈블리 포맷을 다루는 역할을 브라우저의 자바스크립트 엔진이 맡는다. 사실상 어떤 브라우저가 웹어셈블리 포맷을 지원하려면 그런 기능을 수행하는 구성요소를 탑재해야 하는데, 뭔가를 따로 만들어 넣는 것보단 자바스크립트 엔진에 기능을 추가하는 게 효율적이기 때문이다.
뒤집어보면 웹어셈블리 포맷을 지원하는 자바스크립트 엔진은 주어진 코드가 자바스크립트일 경우엔 자바스크립트를 처리하겠지만, 웹어셈블리 포맷일 경우에는 그 원형이 된 언어를 처리하는 엔진이 된다는 얘기가 된다. 더 이상 자바스크립트 엔진이 자바스크립트만 처리하진 않을 거란 뜻이다.
아이크는 "몇년 안에 모든 주요 브라우저들이 자바스크립트 엔진을 진정한 '폴리글랏 가상머신'으로 과시할 것이라 예상한다"며 "자바스크립트는 시간의 경과에 따라 더 많은 API와 하드웨어 기반 특성을 흡수해 진화하되, 그 부담을 나눠 맡은 웹어셈블리의 영역만큼을 제외해야할 것"이라고 전망했다.
웹어셈블리의 존재가 커진다면 자바스크립트의 역할은 그만큼 줄어들 것으로 볼 수 있다. 이에 사실상 자바스크립트를 대체할 수단이 되지 않겠느냐는 관측도 나오고 있다. 그러나 표준화 팀의 입장이나 주요 기술 전문가들은 이를 부정하는 견해를 내놓고 있다.
자바스크립트 웹개발전문가로 알려진 악셀 라우슈마이어 박사는 개인 블로그 포스팅을 통해 자바스크립트와 웹어셈블리의 역할 분담에 따른 공존을 예측했다. (☞링크)
그는 "게임, 영상, 이미지디코더 등 성능이 중요한 기능은 웹어셈블리를 통해 구현되고 외부 코드베이스, 특히 C/C++같은 것이 쉽게 웹어셈블리를 통해 웹플랫폼으로 이식될 것"이라며 "자바스크립트는 그런 와중에도 진화를 거듭해 웹앱 구현을 위한 인기있는 방법으로 남을 것"이라고 전망했다.
관련기사
- "모바일앱개발, '퓨즈'로 더 화려하게 편리하게"2015.06.25
- 국내 대기업·금융권에도 HTML5 확산되나2015.06.25
- MS엣지, IE11보다 3배 빨라2015.06.25
- MS 새 브라우저, 추가될 것과 사라질 것들2015.06.25
asm.js처럼 자바스크립트를 웹어셈블리 포맷으로 바꿔서 전반적인 성능을 끌어올릴 수도 있지 않겠느냐는 의문을 품을 수 있지만, 기술적으로 이는 실현 가능성이 높지 않다는 설명도 덧붙였다.
그는 "첫째, 웹어셈블리코드는 통상 자바스크립트 코드보다 데이터 구조 등이 덜 동적이라서 빠르다는 점을 알아야 하고 둘째, 결국 자바스크립트를 웹어셈블리로 컴파일할 수 있게 되겠지만 당장 구현하는 건 자바스크립트에 특화된 객체나 배열 기능을 지원하는 데 제한돼 있다"며 "지금은 최상의 성능을 원할 경우 기존 방식대로 (자바스크립트 코드 그대로) 실행해야 한다"고 설명했다.
