NCurses 기반 Space Invader 게임을 웹으로 포팅하기

지난번 PacVim 포팅1http://andrwj.com/post/2019/09/porting-pacvim-with-emscripten/ 실패후에 찝찝함이 남아서 다른 패키지를 포팅해보았다.  흔해빠진 Invader 게임인데 ncurses 기반이다. 2http://ninvaders.sourceforge.net/ 둘다 ncurses v6.1 이지만 이번 nInvader 게임은 PacVim 보다 화면제어가 잘되고 있다. 그러나 역시나 어쩔 수 없는 점도 많이 보인다.

 

 

nInvaders 게임 코드 수정사항

1  pthread를 사용하지 않기 때문에 간단히 window.requestAnimationFrame()를 사용해서 브라우저가 뻗지 않도록 적절하게 업데이트하게 했다. iTerm2 에서 동작할 때와 별반 다른 점을 찾기 힘들정도로 부드럽게 움직였다. (뭐 당연한 얘기)

2  역시나 main()exit() 을 업애버리고 시작과 종료를 적절히 웹에서 조절하게 했다. 

3  장애물이 이상하게 표시되고 미사일 발사 주변이 말려올라가고 … 등등은 iTerm2에서 실행할 때는 전혀 문제없다. PacVim에서보다 훨씬 화면 제어가 잘되는 걸로 봐서 xterm.js에서 제대로 표시하려면 특정 ncurses API를 WebAssembly로 변환된 후의 상황을 고려해서 보정해줘야하는게 있다고 추측한다. 그게 뭔지 알려면 시간이 필요할 뿐이다. xterm.js 에는 문제가 없는 것 같다. (여전히 추측)

4  종료후 GPL 라이센스 출력을 하지 않게했다. 

5  ‘q’를 눌러도 exit() 하지 않고 다시 게임 대기화면으로 돌아가게 했다.

 

 

별 수정을 가하지 않아도 제대로 포팅되는 ncurses 기반 프로젝트를 발견할 때까지 쉬엄 쉬엄 포팅을 해볼 요량이다. 더불어 xterm.js 를 Client/Server 방식으로 돌려보며 문제해결채을 찾게되면 다시 업데이트 할 예정. 

References   [ + ]

커맨드라인 게임 PacVim을 Emscripten으로 웹으로 포팅하기

Vim 키맵을 사용하기 때문에 이런류의 게임1https://github.com/jmoon018/PacVim 좋아라 한다.  Emscripten을 사용한지도 오래됐고 WebAssembly Tool의 현재 상태도 알아보고 싶기도해서 겸사겸사 포팅을 시작했더랬다.  React Hooks를 씌워서 그럴싸한 UI까지 만드는게 목표였는데, ncurses + xterm.js 조합에 해결하기엔 시간이 너무 들어갈 것으로 보이는 문제 때문에 잠시 묵혀두기로 결정한다.

 

컴파일환경
  • Emscripten v1.38.41-upstream2https://emscripten.org/docs/getting_started/downloads.html, Target: WASM
  • Developing OS: Ubuntu
  • ncurses v6.13https://github.com/mirror/ncurses
  • xterm.js4https://xtermjs.org/ 
  • PacVim5https://github.com/jmoon018/PacVim 

 

중단원인

아래 두 그림에서 보듯 iTerm2 에서의 게임내 레벨 표시에 비해 xterm.js 에서 표시는 중간 부분이 완전히 사라져보이는데, 해당 원인은 Emscripten으로 컴파일된 ncurses에서 제어문자열이 도중에 많은 부분이 제거된채  xterm.js으로 보내지기 때문이다. (비교를 위해 이미지 높이를 동일하게 했더니 왼쪽이 좀 좁아 보인다)

Level 8 in iTerm2 Level 8 in xterm.js

ncurses 에서 문자하나를 현재 위치에 출력하는 addch() 함수호출 뒤에 refresh() 호출 여부가 JS 쪽 출력에 영향을 주는 것이 확인됐다. ncurses API에서 내놓는 escape sequence code를 xterm.js 쪽에서 해석을 하지 못하는 게 아닌가 의심스럽지만,  ncurses API쪽에서 적절한 단위로 코드를 나눠 전송하지 않는 문제일수도 있다.  문자열이 아닌 ASCII code 31 이하의 특수문자는  xterm.js 에서 제대로 해석하는 걸로 확인됐다. 따라서 현재 테스트해봐야할 부분은 ncurses API쪽에서 보낸 데이터와 브라우저 JS에서 받은 코드를 비교함으로써 데이터 누락 유무를 확인 하는 것이다.  제대로 전달되지 않는다면 Emscripten으로 컴파일된 ncurses 쪽 문제이고, 제대로 전달된다면  ncurses 쪽에서 내놓는 코드가 xterm.js 에서 제대로 해석되는지 확인해야 한다. 이래저래 시간 엄청 들어가므로 여기서 멈춘다. 

 

PacVim 코드 수정사항

1  게임내 Player 움직임을 제어하기 위해 ncurses getch() 로 입력받는 부분을 제거하고 브라우저 JS 쪽에서 입력받고 C++ API를 호출하는 방식으로 변경했다.

void EMSCRIPTEN_KEEPALIVE player_move(const char *key) {
        if(!READY) return;
        if(*key) {
                onKeystroke(player, *key);
                move(player.getY(), player.getX());
        }
        refresh();
}
 

 

Emscripten으로 포팅된 getch()는 동기함수라서 매번 입력받는 팝업이 게임 흐름을 정지시키므로 도저히 사용할 수가  없다. 앞으로 ncurses API로 데이터 입력받는 일은 없을 듯. 입력된 키 전달은  브라우저 JS에서  C++ API 호출로 전송한다. 

function onKeyUp(event) {
   if(event.key === 'Enter') {
      running = !running;
      Module._toggle_game_state(running);
      return;
   }
   Module._player_move(event.key);
}

output.addEventListener("keyup", onKeyUp, true);

 

2  game.cpp init() 함수에서 while()루프를 돌며 게임이 진행되지만  emscripten_set_main_loop()로 변환하지 않았다. Ghost는 while 루프와 무관하게 pthread로 동작하기 때문이다. pthread상의 Ghost는 READY 변수로 동작을 pause/resume 시킬 수 있다. 이 부분도 브라우저에서 조절하는 게 훨씬 조작성을 좋게한다.  pthreads 때문에  -s ALLOW_MEMORY_GROWTH=1 설정과 -u USE_PTHREADS=1 설정을 동시에 사용하면 귀찮은 메모리 설정 문제가 발생하므로  전체 메모리를 48MB, 스택을 16MB로 지정하고 컴파일했다.

3  게임속 player life 갯수가 0 이하가 될 때까지 루프를 돌게되어 있지만,  단순히 게임 한판을 종료하면 끝내게 해서  main()을 사용하지 않는다.  사용자입력 검증및 후처리를 ncurses API로 받아 하는 것보다 React Hooks 에서 조절하는게 훨씬 보기 좋기 때문이다. 

4  TERM 설정 값 외에는 다른 terminfo 파일이 필요없으므로 embed 방식으로 포함하였다:

   ↳  --embed-file /opt/emscriptened/share/terminfo/x/xterm@/home/web_user/.terminfo/x/xterm

5  PacVim 레벨 데이터 파일은 preload 로 포함시킨다:

    --preload-file maps@/usr/local/share/pacvim-maps

 

ncurses 기반 앱 활용가능성

SDL6https://www.libsdl.org/ 사용하면 이런 종류의 문제는 없겠지만 개인적으로 콘솔형 어플을 선호하기 때문에 가능한 ncurses + xterm.js 조합이 성공하길 기대하고 있다. ncurses를 사용하는 다른 오픈소스가운데 몇가지 Emscripten으로 컴파일해서 살펴보며 추후 수정여부를 새 글로 올릴 예정이다.

 

References   [ + ]

1. https://github.com/jmoon018/PacVim
2. https://emscripten.org/docs/getting_started/downloads.html
3. https://github.com/mirror/ncurses
4. https://xtermjs.org/
5. https://github.com/jmoon018/PacVim
6. https://www.libsdl.org/

Native Web Application

본 게시글은 2014년 한 해동안 정보통신 산업진흥원(NIPA)의 글로벌 오픈프론티어 소속으로서 일을 하면서 도출된 결과물에 관련된 동향보고서이다. 제출된 보고서와 달리 일부 누락된 부분과 문장 흐름상 수정한 부분이 다 수 있다.  크리에이티브 커먼즈 라이선스이 저작물은 크리에이티브 커먼즈 저작자표시-비영리 3.0 Unported 라이선스에 따라 이용할 수 있습니다.

 

1. 프로젝트 개요

본 프로젝트는 ASM.JS와 HTML5 관련 기술을 사용하여 DICOM1medical.nema.org/standard.html 뷰어(viewer)를 만드는 것을 목표로 하였다.

 

DICOM은 Digital Imaging and Communication Medicine의 약자로써, 의료용 기기에서 디지털 영상표현과 통신에 사용되는 여러 가지 표준을 총칭하는 말이며 미국방사선의학회(ACR)와 미국전기공업회(NEMA)에서 구성한 연합 위원회에서 발표한다. 미국방사선의학회와 미국전기공업회는 의료 영상 장비의 표준화를 위해 1983년 ACR-NEMA 디지털 영상전송 표준 위원회를 발족하였다. 1985년 ACR-NEMA 표준 버전 1.0(출판번호 300-1985)이 북미방사선학회(RSNA)에서 처음으로 발표되었으며, 이어 1988년에는 버전 2.0(출판번호 300-1988)이 발표되었다. 이후 객체지향 정보 모델을 사용하는 등 큰 수정이 가해지면서 새로운 명칭을 필요로 하게 되었고, 그 결과 1992년 북미방사선학회 회의에서 DICOM이라는 명칭의 표준이 처음으로 제안되었다. DICOM은 1993년 첫 데모 버전이 발표된 이후 지금까지 꾸준히 수정되고 있다 2http://ko.wikipedia.org/wiki/의료용_디지털_영상_및_통신_표준

 

표준화된 DICOM 포맷이라 할지라도 20년이 넘는 기간 동안 여러 벤더의 장비에 따라 조금씩 변경되었고 관련 소프트웨어는 각각의 변경사항에 대해 수정돼야만 했다. 파편화된 DICOM 포맷 파일을 효율적으로 다루며 지명도 있는 몇 가지 라이브러리 가운데 DCMTK3http://dicom.offis.de/dcmtk.php.en와 GDCM4http://gdcm.sourceforge.net/, CxImage5http://www.xdp.it/cximage/ 등이 있다. 본 프로젝트는 DICOM software 분야에서 사실상의 표준으로 쓰이는 DCMTK 라이브러리를 사용한다. 1993년에 시작되었으나 DCMTK (DICOM Toolkit)이라는 이름으로 새롭게 시작한 1996년 이후 현재까지 개발되고 발전되어 쌓여진 신뢰도를 사용하고자 한 것이다. 하지만 윈도우 및 리눅스, 맥 등의 모든 에서 사용할 수 있다 할지라도 DCMTK를 사용한 어플리케이션은 윈도우 환경에서 동작하는 소프트웨어가 대부분이다.

 

운영체제 의존적인 부분을 벗어나 표준화된 HTML5와 웹 브라우저 기반에서 DCMTK 기반 소프트웨어를 만들려는 것은 운영체제와 무관하게 동작하는 작성함으로써 DICOM 관련 소프트웨어의 발전을 꾀하고자 함이다. 그러나 DICOM 소프트웨어는 반드시 만족시켜야 할 몇 가지 특성을 가지고 있기에 말처럼 쉽지 않다. 개인의 신상정보와 병력기록을 담고 있는 DICOM 소프트웨어는 보안이 무엇보다 중요한 요구사항 중 하나이지만 HTML5와 웹 브라우저에서 동작하는 소프트웨어는 기본적으로 소스의 공개를 피할 수 없기 때문이다. 이 문제를 100% 만족시키는 것은 아니지만 프로젝트를 통해 한가지 방법을 제안하였다.

 

보안문제와 함께 한가지 더 요구되는 DICOM 소프트웨어의 기능은 충분한 이미지처리 속도를 내야 하는 점이다. 의료기기를 통해 환자 한 사람에 대해 적게는 수백 장 많게는 수천 장에 이르는 고품질 이미지 정보를 담은 DICOM 파일을 만들어낸다. 대부분의 DICOM 이미지는 웹 브라우저에서 조작되어 표현되기에 높은 화소/화질로 구성되어 있으나 이미지 처리에 필요한 HTML5/JavaScript API는 공개된 이미지조작 소프트웨어에 비해 턱없이 부족하고 제한된 표현만이 가능하다. 또한 뛰어난 성능의 하드웨어를 사용한다 하더라도 웹 브라우저내의 소프트웨어는 기본적으로 한번에 하나의 CPU만을 사용할 수 밖에 없어 하드웨어의 성능을 최대치로 사용하기 위해서는 빠른 속도를 낼 수 있는 기법이 동원 되야 한다.

 

2014년 초반에만 하더라도 웹 브라우저를 본격적인 DICOM 소프트웨어 동작환경으로 고려하기엔 무리였으나 본 프로젝트를 통해 제작된 프로토타입 소프트웨어에서 보여주듯, 속도문제마저도 해결할 수 있는 단계에 이른 HTML5/JavaScript 관련 기술은 C++로 작성된 기존의 소프트웨어와 비교해도 뒤떨어지지 않으며 오히려 웹 브라우저가 가지고 있는 다양한 가능성으로 인해 효율적인 DICOM 소프트웨어를 동작할 수 있는 하나의 환경이 되었음을 보여주고 있다.

 

프로젝트의 초기 목표는 공개 DICOM 뷰어를 제작하는 것이었다. 하지만 이 보고서에서는 Native Web Application6웹 브라우저를 통해 운영체제의 모든 서비스와 하드웨어의 이점을 모두 활용할 수 있는 어플리케이션을 말한다을 다양한 방면으로 활용하는 것과 제한적인 범위내에서 ActiveX를 대체하는 방법으로도 쓰일 수 있다는 것을 더 강조하고자 한다.

 

 

2. 프로젝트 현황

본 프로젝트에서 제작한 소프트웨어는 DCMScope라고 이름 지었으며 프로토타입 상태로써 DICOM 뷰어의 기본 기능을 제공한다.

 

[그림 1] DCMScope

 

 

DCMScope는 다음과 같은 기술과 패키지를 사용하고 있다:

  • ASM.JS
  • LLVM
  • Emscripten
  • HTML5 Canvas, File API
  • DCMTK
  • Node-Webkit

 

 

ASM.JS Specification7http://asmjs.org/spec/latest/

[그림 2] Native vs. ASM.JS vs. Plain JavaScript 속도 비교 (대략)


ASM.JS는 이름과 달리 새로운 프로그래밍 언어가 아니며 프로그래밍 라이브러리나 프레임워크도 아니다. 웹 브라우저의 기능을 확장하는 plugin 이나 extension도 아니고 단순히 JavaScript 라는 프로그래밍 언어 명세(Specification)의 일부분이며 컴파일러 타깃 중 하나이다. 컴파일러 타깃이라는 것은 C/C++ 소스에서 x86이나 x64 바이너리를 생성하듯 다른 프로그래밍 언어로부터 최종 결과물로써 JavaScript를 생성해 낸다는 말이다. 한마디로 다른 프로그래밍 언어에서 JavaScript를 효율적으로 생성하기에 적합하도록 작성된 저수준 프로그래밍 명세서라고 할 수 있다. ASM.JS 명세를 만족하는 JavaScript는 모든 브라우저에서 소스수정 없이 동작한다. 2013년 모질라 재단에서 시작하였고 2013년 11월 Draft 상태의 명세가 최종버전이다. 2014년 현재 인터넷 익스플로러를 제외한 주요 브라우저에서 ASM.JS 최적화 기능을 제공하고 있으며 C/C++로 작성된 어플리케이션의 속도에 계속하여 근접하는 중이다.

 

 

LLVM8http://llvm.org

 

Low Level Virtual Machine의 약자이지만 이름이 말하는 것과 달리 컴파일러 기반구조다. 2000년에 일리노이 대학에서 시작된 프로젝트였으나 2005년에 Apple사가 LLVM 주요개발자들을 고용하여 제품의 최적화 기능을 목적으로 개발을 이어가게 하였다. LLVM은 C++로 작성되어 있고 임의의 프로그래밍 언어에 대해 컴파일과 링크, 실행시간, 유휴시간에 적용할 최적화 기능을 제공한다. 사용자는 작 작성된 인터페이스를 통해 LLVM의 각 부분을 호출할 수 있으며 새로운 프로그래밍 언어에 대한 컴파일러를 손쉽게 작성할 수 있게 해주었다.

 

 

Emscripten9http://emscripten.org/

 

C/C++에서 JavaScript를 생성해내는 TransCompiler10http://en.wikipedia.org/wiki/Source-to-source_compiler로써 2010년 8월 Alon Kazai가 첫 커밋을 Github에 올렸다. 컴파일러의 한 종류이며 LLVM을 호출해서 C/C++ 소스를 컴파일하고 중간코드를 받아 JavaScript 파일을 생성해내는 툴킷이다. 툴킷에 포함된 emcc 명령에  -s USE_ASM  컴파일 스위치를 전달하여 ASM.JS 명세에 맞는 최종 결과물을 생성한다.

 

[그림 3] Emscripten 동작 개요

 

HTML5 Canvas API11http://www.w3.org/TR/2dcontext/, File API12http://www.w3.org/TR/FileAPI/

 

DCMScope는 DICOM 이미지를 브라우저에 표시하기 위해 HTML Canvas 요소를 사용한다. Canvas는 8bit 256 Color 밖에 표현하지 못하는 제한이 있으므로 DICOM 이미지 데이터를 적절히 조작해야 한다. 브라우저가 DICOM 파일을 읽기 위해 네트워크로부터 전송 받거나 로컬 저장장치에서 읽어 들이는 방법을 사용할 수 있겠으나 프로토타입 구현의 편이성을 위해 HTML5 File API를 사용하여 로컬 저장장치에서 읽어 들이는 방법을 선택하였다.

 

 

DCMTK

 

DICOM 툴킷의 표준이라 할 수 있는 DCMTK는 C++로 작성된 라이브러리이며 Windows, Linux, Mac OS X 세 개의 주요 플래폼에서 모두 빌드가능하고 동작한다. 이 패키지는 35개의 크고 작은 모듈로 구성되어있고 몇 십 년간 사용되면서 사용자의 요구와 의료장비 변화에 대응해왔다. DCMTK 라이브러리 하나로 모든 의료장비의 특성을 인식하고 처리할 수 있는 것은 아니지만 대부분의 프로젝트에서 DCMTK를 사용하고 있으며 여전히 수많은 개발자의 활발한 공헌으로 발전하고 있다. BSD라이센스아래 배포되고 있어 부가가치적인 제품을 만드는 것에 문제없다.

 

 

node-webkit13https://github.com/rogerwang/node-webkit

 

node-webkit은 nodejs14http://nodejs.org와 Webkit15https://www.webkit.org에 기반한 어플리케이션 런타임환경이다. 웹 브라우저에서 nodejs와 수많은 모듈을 직접 사용할 수 있게 됨에 따라 웹 어플리케이션 작성에 새로운 방법을 열어주었다. 기존의 JavaScript 어플리케이션은 대부분 소스가 공개되므로 보안이 필요한 영역에서 본격적인 상용제품으로 개발하는 것을 지양되어왔으나 node-webkit이 JavaScript 어플리케이션의 소스를 바이너리 포맷으로 변환해주는 기능을 제공함에 따라 JavaScript 어플리케이션의 보안성을 크게 향상시켰다. DCMScope 프로토타입 개발에 이 기능을 사용하여 개인정보유출을 목적에 둔 소스의 임의 접근을 어렵게 하였다

 

 

3. 추진 내용

 

앞서 기술한 바와 같이 DCMTK가 20년을 이어온 DICOM 툴킷이라 할지라도 다양한 장비에서 생성되는 모든 DICOM 파일을 처리하지는 못한다. 따라서 신규로 작성하는 DICOM소프트웨어는 DCMTK소스를 응용하여 목적에 맞게 적절히 수정돼야 한다. 또한 기존의 C/C++ 소스가 아무런 수정 없이 ASM.JS로 컴파일 되는 경우는 드물고 대부분 어느 정도 수정해야 할 필요가 있다. 2014년 12월 현재, 다음과 같은 경우는 ASM.JS로 컴파일 되지 않거나 다른 방법으로 구현 되야 한다:

  • 멀티스레드
  • 공유메모리
  • 하드웨어에 맞춘 바이트 정렬
  • 함수 포인터의 캐스팅
  • 예외처리
  • longjump
  • TCP Networking

 

 

DCMTK를 Emscripten으로 컴파일하고 node-webkit 어플리케이션으로 작성하여 웹 브라우저에서 디버깅하는 과정은 C++과 nodejs, 웹 브라우저 등 몇 가지 영역에 걸쳐있어 까다로울 뿐만 아니라 꽤나 시간소모적인 작업이다. DCMTK 소스 중 필요한 부분을 파악하기 위해 툴킷 자체에 대한 학습시간이 소요되고 LLVM과 Emscripten 버전에 따라 컴파일 유무가 결정되기도 하기 때문에 문제가 발생할 경우 해당 패키지가 수정되기까지 기다리거나 직접 수정해야 할 경우도 생긴다. ASM.JS로 컴파일 불가한 코드를 발견해 내지 못해 하염없이 수정->컴파일->디버깅을 반복해야 할 수도 있다. 이러한 과정 때문에 Emscripten을 사용하는 것이 부정적으로 보여질 수 있으나 모질라 재단의 지속적인 투자와 세계 곳곳의 개발자들의 참여로 인해 머지 않아 해결될 것이라 기대한다.

 

DCMScope 프로토타입을 작성하기 위해 34개의 DCMTK 모듈가운데 DICOM파일 파서와 XML정보를 가져오는 dcm2pnmdcm2xml 두 가지 모듈만을 사용하였다. 이 두 모듈은 HTML5 File API에의해 로컬에서 읽어 들인 DICOM 파일을 표현 가능한 이미지 정보와 환자정보를 XML로 분리해내는 역할을 담당한다. 진단 케이스에 따라 몇 백 장에서 몇 천 장에 달하는 DICOM 파일을 관리하는 부분은 다른 개발자의 참여를 통해 진행할 계획이며 프로토타입 제작을 위해 이 부분은 간략히 작성되었다. 가장 핵심적이고 기본적인 Image window/width 조작 기능은 JavaScript로 작성되었으나 몇 가지 이슈가 해결되지 않은 상태다. 모든 소스는 HTML, CSS, JavaScript로 이루어져 있으며 node-webkit의 소스 메모리 덤프기능을 이용하여 암호화 하였다.

 

의료용 소프트웨어는 성능 못지않게 정확성 또한 매우 중요하다. DCMScope 프로젝트가 타 개발자와의 협업으로 발전할 수 있는 체계를 갖춘 후에는 실제 업무 환경에서의 검증을 통하거나 현업에 종사하는 다른 개발자의 참여 등으로 보완해 나가야 할 것이다.

 

프로젝트의 초기엔 웹 브라우저에서 동작하고 실무에서 사용하기에 부족함 없는 DICOM 뷰어를 계획하였고 몇가지 목표아래 ASM.JS와 웹 기술을 적용하여 프로토타입을 제작하였다. 시간이 지남에 따라 여기서 언급하는 Native Web Application 제작 방법외에 더 다양한 방법이 개발되었고 특정 분야에서는 이런 방식의 개발이 유연성과 확장성에서 기존의 방식과 대비해 이점이 될 수 있을 것이다. 향후 DCMTK 툴킷만 아니라 다양한 툴킷, 라이브러리 등을 ASM.JS로 컴파일하고 이를 저장소에서 가져와 간단히 모듈로써 사용하는 일이 늘어갈 것이라 생각한다.

 

 

4. 적용 분야

 

Native Application 이라는 것은 특정 하드웨어와 운영체제에서 제공하는 기능과 서비스를 모두 자유롭게 사용할 수 있는 어플리케이션이라고 정의할 수 있다. 따라서 Native Web Application은 웹 브라우저에서 실행되는 어플리케이션이 하드웨어의 이점과 서비스를 모두 사용할 수 있어야 할 것이다. 웹 브라우저에서 Plugin 이나 Extension, ActiveX등을 사용하지 않고 ASM.JS로 컴파일 된 JavaScript를 사용하여 제한된 영역의 태스크를 수행할 수 있다면 강력한 성능과 기능을 제공하며 데스크톱 영역과 모바일 영역 모든 곳에서 수정 없이 동작하는 어플리케이션 작성할 수 있을 것이다.

 

계획된 범위내에서 DICOM 뷰어가 완성이 되면 의료업계종사자간의 화상회의뿐만 아니라 컨퍼런스 등에서 환자 케이스를 실시간으로 공유하며 의견을 나누는 일에 응용될 수 있다. 원격진료에도 일부 적용될 수 있으며 완성도 높은 제품으로 발전하여 사용제품으로써 판매도 가능할 수도 있을 것이다.

 

의료영상을 웹 브라우저에서 보고 조작하는 것 외에도 C/C++로 작성된 수많은 패키지를 웹 브라우저에서 동작할 수 있게 될 것이다. 웹 브라우저에서 이미지 처리 전문 어플리케이션인 GIMP를 사용하거나 Open Office의 Writer, MySQL Workbench, 각종 메신저, PGP, ActiveX가 처리해왔던 영역의 일들을 웹 브라우저에서 안전하게 구동하는 것을 상상하는 것은 허무맹랑한 일이 아니다.

 

HTML5가 공식적으로 표준으로 자리 잡았다는 것은 앞으로 가능한 모든 영역에서 웹 브라우저는 Windows, Linux, OS X, iOS, Android 등과 같이 분리된 환경이 아닌 통합된 어플리케이션 실행환경이 된다는 것을 의미한다. C/C++ 뿐만 아니라 거의 모든 종류의 프로그래밍 언어에서 JavaScript로의 변환을 지원하는 TransCompiler 개수만 250가지가 넘는다는 사실을 눈 여겨 보아야 한다. 앞으로의 Native Web Application UI는 HTML과 CSS를 통해 자유롭게 표현되고 C/C++, Java, Python, Ruby, Scala 등의 다양한 언어로 제작된 풍부한 패키지를 웹 브라우저로 가져와 응용할 수 있으며 데스크톱과 모바일 전역에 걸쳐 구동될 수 있을 것이다.

 

[그림 4] Example: ASM.JS Powered GIMP
[그림 5] Example: ASM.JS Powered Open Office Writer

 

해외 게임업계는 이미 기존게임과 새로 작성하는 게임 중 일부를 ASM.JS로 컴파일 된 버전을 제공하여 새로운 시장에 입지를 넓혀가고 있다.

 

[그림 6] 기존 게임에 ASM.JS를 적용한 Dungeon Defenders

Native Web Application 제작에는 HTML5, JavaScript, CSS등의 프론트엔드 기술뿐 아니라 C/C++, LLVM과 같은 컴파일러 등의 기술 등 종합적 지식이 필요하므로 쉽게 접근할 수 없으나 기술의 발전은 곧 복잡함을 벗기고 어플리케이션 제작의 다른 흐름을 만들어 낼 것이라 기대한다.

 

2014. 12. 글로벌 프런티어 1기 전담개발자 A.J

References   [ + ]

1. medical.nema.org/standard.html
2. http://ko.wikipedia.org/wiki/의료용_디지털_영상_및_통신_표준
3. http://dicom.offis.de/dcmtk.php.en
4. http://gdcm.sourceforge.net/
5. http://www.xdp.it/cximage/
6. 웹 브라우저를 통해 운영체제의 모든 서비스와 하드웨어의 이점을 모두 활용할 수 있는 어플리케이션을 말한다
7. http://asmjs.org/spec/latest/
8. http://llvm.org
9. http://emscripten.org/
10. http://en.wikipedia.org/wiki/Source-to-source_compiler
11. http://www.w3.org/TR/2dcontext/
12. http://www.w3.org/TR/FileAPI/
13. https://github.com/rogerwang/node-webkit
14. http://nodejs.org
15. https://www.webkit.org