[[분류:가져온 문서/넥스32 위키]] [Include(틀:가져옴,O=넥스32 위키, C=[[http://www.gnu.org/licenses/fdl-1.3.html|GNU Free Documentation License 1.3]], L=[[https://web.archive.org/web/20210412131144/https://wiki.nex32.net/%EC%86%8C%ED%94%84%ED%8A%B8/%EA%B5%AC%EA%B8%80_%EB%84%A4%EC%9D%B4%ED%8B%B0%EB%B8%8C_%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8|링크]])] 구글 네이티브 클라이언트(Google Native Client)는 구글에서 만든 구글 크롬 브라우저에서 지원하는 RIA 플랫폼의 일종이다. 약칭으로 NaCl로 표기하며, 약칭의 의미는 원소기호의 염화 나트륨, 즉 소금이라는 의미를 그대로 사용한다. 또한 NaCl환경 위에 돌아가는 어플리케이션 프로그래밍 환경의 연결자가 Pepper API로, 통칭 Pepper. 즉 소금과 후추라는 조미료로 이루어져 있다. 이 환경은 이름대로 CPU에서 실행되는 명령어셋의 원시 바이너리(Native Binary)통해 제공되는 프로그램으로, 여타 RIA플랫폼에 비해서 직접적으로 리소스에 접근하는 기능을 제공, 빠른 속도의 연산이 필요한 케이스에 적합하다. 하드웨어에 직접 접근되는 네이티브 바이너리 기반이기 때문에 보안문제 해결을 위해 샌드박스 방식의 환경 내에서 실행되도록 설계되어있으며, 소프트 기반의 실패분리 코드통제를 하기 때문에 샌드박스에서 제공하는 기능 밖으로 벗어날 수 없어 안전하다는 것이 구글측의 설명이다. BSD 스타일 라이센스로 개발이 진행중인 오픈소스 프로젝트로, 현재는 개발을 주도하고 있는 구글의 웹브라우저인 구글 크롬 웹브라우저와 구글 크롬OS에서만 작동되고 있다. 기기 호환성 문제를 줄이고 실행 플랫폼을 넓히기 위한 방안으로 LLVM에서 생성되는 비트코드를 전송해 클라이언트에서 1회에 한해 컴파일을 진행하는 방식을 사용하는 이식성 네이티브 클라이언트(Portable Native Client, PNaCl:통칭 피나클)[* portable은 여기서 ‘이동성’이 아니라 ‘porting’ 즉 이식가능성을 말하는 용어로 쓰인 것이다. 오해없도록 하자]도 개발이 진행되고 있다. == 상세 == 구글 네이티브 클라이언트는 여타 RIA 플랫폼과는 달리, 운용되는 프로세서에 맞는 네이티브 코드로 빌드되어 작동하는 구조로 작성되어 있는 것이 특징이다. 이전의 멀티 플랫폼을 지원하는 RIA 기반, 예를 들어 자바스크립트, 플래쉬, 자바, 자바FX, 실버라이트 등의 다양한 RIA환경을 구축하는 플랫폼이 스크립트 형태, 혹은 중간바이너리(예를 들면 자바의 바이트코드 등)로 전송되어 실행전에 해당 CPU에서 돌아가도록 번역되는 과정이 필요하다. 그러나 네이티브 바이너리를 작성해 전달하기 때문에 여타 RIA 플랫폼에 비해 처리 속도가 빠르고 접근 레벨이 낮아 고성능의 프로그램을 작성할 경우 여타 RIA 플랫폼보다 월등한 효율을 보여준다. 이는 얼핏보면 인터넷 익스플로러에서만 지원해온 액티브X와 유사한 요소이지만, 액티브X가 독립 어플리케이션과 동일한 수준으로 하드웨어에 접근하여 제어할 수 있었던 것과는 구분되게 소프트웨어 기반의 실패 분리(fault isolation) 방식을 통해 실행 플랫폼을 제약한 상태로 만든 샌드박스 속에서 구동되며, 그 안에서 악성코드나 기타 시스템에 허용되지 않은 형태로 접근하려는 프로세스를 제한하도록 철저히 통제하고 있다. 때문에 보안 문제를 유발하지 않으면서 빠른 속도의 프로그램 실행이 가능하다는 것이 최대 장점이다. 그러나 제한된 시스템 접근 허용으로 인해서 기능적으로 제약이 상당히 많이 있는 상태이다. 이는 기능을 철저히 제한하고 샌드박스 밖으로 직접 나갈 수 없도록 하여 보안을 지키기 때문이지만, 일반적으로 예상되었던 것보다 제약이 상당히 심한 편이다. 때문에 완전 독립적인 프로그래밍 플랫폼으로는 부적합하며, 웹앱을 개발하는데 있어서 내부 프로그래밍을 C와 Cpp등의 익숙한 언어로 제작할 수 있다는 점과 속도가 빠르다는 점이 가장 큰 장점이라 할 수 있다. 또한 NaCl 프로젝트 자체가 안정화가 아직 되지 않은 프로젝트인지라 개발이 진행되면서 제약을 해제해야 할 부분과 보안에 문제가 될 부분 등이 추가되는 등 변경점이 지속적으로 적용되어가고 있는 상태이다. == Pepper API == Pepper API(Pepper Plugin API, PPAPI)는 편의상 Pepper라고 부르는 경우가 많은데, 이는 NaCl과 웹 브라우저간의 데이터를 주고 받는데 필요한 API의 모음이다. NaCl상에서 운용되는 프로그램은 기본적으로 독립된 어플리케이션과 크게 다르지 않으나, 샌드박스 상에서 작동하기 때문에 하드웨어에 직접 접근을 할 수 없다. 또한 NaCl의 특성상 사용자 접근은 웹브라우저로 하게 되기 때문에 이에 대한 인터페이스도 필요하다. 때문에 이 중간에서 NaCl이 하드웨어에 접근하는 인증된(그리고 실시간으로 검사가 진행되는) 인터페이스가 필요하게 되는데, 이것을 처리하는 것이 바로 Pepper이다. == 장단점 == === 장점 === NaCl은 네이티브 바이너리를 실행시키는 것이기 때문에 어플리케이션의 실행속도나 용량 등에 있어서 여타 중간단계를 거치는 언어에 비해 강점을 가진다. 때문에 웹에서 제공되는 다른 RIA 환경에 비해서 높은 퍼포먼스를 요하는 프로젝트에 걸맞다. 또한 C와 Cpp로 작성된 언어의 경우 하드웨어 접근 정도나 요소에 따라 다르지만 이미 작성된 모듈을 재사용이 가능하다. 특정 연산을 위한 알고리즘이나 라이브러리 등의 저수준의 단계에서 작동하도록 작성된 코드라면 출력부와 세부사항을 고치는 것만으로 NaCl환경으로 이식이 가능하다. 또한 NaCl이라는 플랫폼은 CPU에 종속되기는 하지만 플랫폼의 특성상 OS단 위가 아닌 그보다 한단계를 더 거친 샌드박스 위에서 돌아가기 때문에 OS에는 종속되지 않는다.(단 샌드박스가 규격을 똑같이 지원해야만 돌아간다) 이는 하드웨어에 저레벨로 접근해야하는 소프트웨어 코덱 등에서 실 예를 어렵지 않게 찾아볼 수 있다. CRI에서 만든 ADX (코덱)나 Sofdec (소프덱)의 테크데모가 NaCl로 제작되어 공개된 것도 이러한 요소들이 이유라고 할 수 있다. ==== 게임 ==== 최근 확대되어가는 웹게임의 플랫폼으로서도 이는 매우 매력적인 요소로 받아들여지고 있으며, NaCl환경으로 많은 게임들이 이식, 제작되고 있다. OpenGL ES를 사용 가능하며, 웹브라우저의 IO를 통해 처리하던 요소들 중 상당수가 하드웨어와 근직접적으로 처리가 가능하기 때문에 2D와 3D를 포함한 그래픽 처리, 오디오 처리, 마우스, 키보드, 게임패드 등의 입력장치의 입력 이벤트 처리를 낮은 딜레이로 처리가 가능해진다. 또한 높은 성능을 기반으로 게임에서 사용되는 각종 내부 알고리즘의 메모리 직접 접근 등 반응속도나 부하가 심한 프로그래밍 환경에서 더 높은 성능과 C와 Cpp등의 선개발된 모듈을 쉽게 이식가능하기 때문에 이미 있는 노하우를 상당수 재활용할 수 있으며, 여타 플랫폼에 비해서 훨씬 높은 퀄리티의 게임을 만들어 제공할 수 있다. 이를 지원하기 위해서 유니티 엔진 또한 NaCl을 지원하여 이식되어있는 상태이며, 언리얼 엔진 또한 이식을 진행하고 있다고 알려졌다. 또한 구글은 GAIKAI와 협력해 클라우드 게이밍 환경을 웹브라우저 상에서 구동하는 데모를 실행하는 등[* [[https://www.youtube.com/watch?v=JbMF-X08etY|구글I/O 2012에서 GAIKAI가 진행한 프레젠테이션]]] 다양한 형태로 NaCl을 게임에 활용할 수 있도록 방안을 강구하고 있는 듯하다. === 단점 === 근본적으로 NaCl 환경의 가장 큰 문제는 메모리와 자원을 많이 먹는다는 점이다. 현재 지원되는 환경이 메모리를 많이 먹기로 유명한 크롬 브라우저 뿐인 탓도 없지는 않겠으나, 기본 환경이 열리는데에만도 상당한 메모리를 소요한다. 이것은 NaCl이 장점으로 내세우는 ‘빠르다’라는 것, 즉 가볍게 운용될 수 있다는 장점의 많은 부분을 상쇄하는 단점임에 틀림이 없다. 그러나 이러한 요소는 빠른 실행 속도로 어느정도 납득할 수 있는 요소이긴 하다. 다음으로 큰 문제는 크롬 브라우저 외의 브라우저가 NaCl환경을 지원할 예정이 없다는 점이다. 다른 브라우저 개발사들, 마이크로소프트와 애플 등의 경쟁업체는 물론이거니와 불여우를 만드는 모질라 재단조차 NaCl에 대해서 비판적인 시각을 표출한 바 있어 이에대한 가시적인 성과가 어느정도 나오기 전에는 다른 브라우저의 지원을 기대하기가 어려울 것으로 생각된다. 다음 문제는 개발자에게 있어서 플랫폼의 제약이 의외로 심하다는 점이다. 다음은 구글이 공개하고 있는 현재의 NaCl의 제약사항이다. * 직접 IDE 통합 없음(디버깅 옵션 참조) * 하드웨어 예외에 대한 지원 없음 * 프로세스 생성 및 하위 프로세스에 대한 지원 없음 * 고유 TCP/UDP 소켓에 대한 지원 없음 * 동시 발생 (차단) I/O에 대한 지원 없음 * 사용 가능한 메모리로의 쿼리가 지원되지 않음 * 인라인 어셈블리가 Native Client 검사기와 호환할 수 있어야 함(SDK의 ncval 도구(Tool)를 이용해서 확인할 수 있음) * Pepper API 호출이 메인 스레드에서 나와야 함 * TCP/UDP 소켓에 대한 지원이 아직되지 않는 점[* 대체 기능—TCP의 경우 웹소켓 및 UDT의 경우 피어 연결—이 개발 중이며 곧 출시될 예정이라고 밝히고 있음] 등의 문제로 인해 SSH 터미널 프로그램을 만드는데 실패한 내용 등이 나오고 있어 이러한 제약의 해결방안이 제공되어야 할 필요성이 제기되고 있다. == 외부 == * [[https://developer.chrome.com/docs/native-client/overview/|NaCl 오버뷰 문서]]
