사람들이 워낙 액티브 X에 혼쭐이 나다보니까, 솥두껑만 봐도 화들짝 놀라는 형국이라 구글에서 유사품(?)을 만들어냈음에도 불구하고 별로 관심이 없는 모양이다. 이번에 새로 구글이 선보인 네이티브 클라이언트(Native Client, 이하 NC)는 기반 플랫폼이 지원하는 고유 코드(기계어라고 부르면 되겠다)를 웹 브라우저에서 동작하도록 만드는 기술이다.
여기까지 들어보면 딱 액티브 X랑 모질라 플러그인 아키텍처가 떠오른다. 그렇다면 기존 액티브 X와 차이점이 무엇일까? 한 걸음 더 나가 기존에 존재하는 기술에 덧붙여 NC를 만들어낸 구글이 품고 있는 의도는 무엇일까?
NC는 운영체제에 무관하게 샌드박스에서 고유 코드를 동작하도록 만든다는 측면에서 액티브 X와 확실히 다르다. 다시 말해 NC 아키텍처로 만든 코드는 윈도우, 맥, 리눅스에서 돌아가며(물론 기반 CPU가 같아야 하며, 가상화는 지원하지 않는다), 보안을 침해할만한 시스템 호출이나 기계어 호출은 원천적으로 차단된다. 말웨어 온상이며, 윈도우만 지원하는 액티브 X와 궤를 달리하고 있다는 말이다.
그렇다면 어떤 의도가 숨어있을까? B급 프로그래머 생각에는 네이티브 응용 프로그램이 윈도우와 딱 붙어 돌아가는 대신 크롬이나 파이어폭스와 같은 웹 브라우저와 딱 붙어 돌아가도록 만듦으로써 마이크로소프트 윈도우 영향력을 줄이려는 목적이 엿보인다. 기존 웹 기술로 하지 못하는 CPU 파워를 많이 쓰는 응용 프로그램을 웹 환경에서 돌릴 필요가 있다면 현재로서는 NC가 좋은 대안이다.
NC는 IE를 제외한(!) 대부분 브라우저(오페라, 파이어폭스, 크롬)에서 동작하며, 전용 gcc 툴 체인(C라이브러리로는 newlib를 사용한다)과 API 라이브러리를 제공하므로 기존 응용 프로그램 코드를 조금만 수정해서 빌드만 새로 하면 바로 NC 플러그인으로 결합이 가능하다고 한다. 아직 x86만 지원하지만 ARM이나 PPC 플랫폼에서도 동작하도록 프로젝트를 진행하고 있다고 하니 조만간 구글 안드로이드 폰에서도 동작하는 제품이 나오지 않을까 싶다(오히려 x86보다는 파워가 떨어지는 모바일용 장비에서 NC가 먹힐 가능성이 훨씬 더 높다). 멀티 운영체제/멀티 플랫폼용 네이티브 응용 프로그램을 손쉽게 만드는 구조를 고안하다니... 아무리 생각해도 구글 참 신기한 회사다.
EOB
Java VM과 지향하는 점이 비슷하다고 생각하는데 맞나요? :)
답글삭제NC를 보면, 가상 기계가 없고 native CPU에서 동작한다는 면에서 자바와 같은 한번 작성해서 모든 곳에서 돌린다는 철학은 배제되어 있습니다.
답글삭제다시 말해, CPU별로 한번씩 컴파일해야 한다는 부담이 있습니다. x86 환경에서 개발하더라도 운영체제에 무관한 일종의 크로스 컴파일(?)을 한다고 생각하시면 되겠습니다. 현재는 x86만 대상으로 하므로 큰 문제는 없겠지만, 향후 다양한 아키텍처를 지원할 경우 해당 아키텍처 특성에 따라 호환성 문제가 생길 가능성도 있습니다.
하지만 이런저런 불이익을 감수하더라도 VM이 없으니... 속력면에서 분명히 이익이 클겁니다(주의: JIT 논쟁 사절).
- jrogue
ActiveX도 터질 때마다 구멍을 막았지만, 결국 악명 높게 되어버리고 말았고...
답글삭제어차피 여러가지 재미있는 짓을 하려면 peripheral에 접근하거나 외부 라이브러리를 상대적으로 자유롭게 사용하는 게 가능해야 할텐데... 직접 만든 계산만 할꺼면 그냥 applet이 처음 나왔을 때, applet으로 물리 법칙 데모나 하는 거랑 무엇이 다를지 ;)
세라비님, 저도 애플릿이랑 뭐가 다를까 고민을 좀 해봤는데...
답글삭제NC는 애플릿이 인기를 끌지 못한 문제점을 어느 정도 극복하기 위한 수단으로 보여집니다.
i) 느린 로딩 속력: 자바 런타임 환경 초기화만 해도 사람 답답하게 만듭니다.
ii) 느린 수행 속력: 요즘 많이 좋아졌다고는 하지만 여전히 답답함을 느낍니다.
iii) 기존 legacy 코드 활용 측면: C로 된 코드는 자바 프로그래밍 언어로 새로 짜야 합니다.
NC를 사용할 경우 속력 문제와 활용 측면에서 자바 애플릿보다는 월등히 유리합니다. 외부 라이브러리 문제를 말씀하셨는데, 외부 라이브러리 원시 코드가 있을 경우 컴파일해서 쓰면 됩니다. 결국 최종적으로 I/O 쪽 문제가 남는데, 이건 기술이 아니라 trusted NC와 같은 정책으로 풀어야 할 문제 같습니다. ;)
애플릿처럼 찻잔 속 태풍으로 끝날지 아니면 폭풍을 일으킬지는 개발자 손에 달려있는 듯이 보이네요, NC도 처음부터 화끈한 killer app이 나오지 않고 데모 수준 응용 프로그램만 나온다면 상당히 힘들 것 같습니다. 공인 인증서 모듈이랑 신용카드 인증 모듈만 NC로 작성하더라도 국내에서는 한 수 먹고 들어갈텐데...
- jrogue
애플릿과 마찬가지로 flash와의 개념적인 면에서 비슷하지 않나 하는 생각이 듭니다.
답글삭제jrogue님말대로 OS dependency를 제거함이 목적인 듯 합니다. 하지만 키보드 후킹 방지 같은 것들을 sandbox안에서 구현할 수 없을 것이기 때문에 한국의 은행거래는 아직 Active X를 벗어나지 못할 것 같네용.
답글삭제