네이티브 코드의 최후?

인터프리터/JIT 언어라기 보다는, 그러한 기술이 적용된 언어라는 관점에서,

그게 대세면, C 내지 C++ 도 그 기술이 적용된 바이트 코드 생성기를 만들면 된다고 봅니다.

엔터프라이즈 서버 쪽은 이미 자바 .NET 등 인터프리터/JIT 기반 언어가 대세인듯 하구요.

데스크탑 어플리케이션은 아직 네이티브 코드를 생성하는 언어가 대세지만 많은 인터프리터/JIT 기반 언어들이 충분한 가능성을 보여주고 있다고 생각합니다.
윈도의 경우 앞으로 .NET 데스크탑 어플리케이션 영역 역시 커버하게 될테니 더욱 그렇구요. 리눅스에서는 요새 심심치 않게 python 으로 GUI 를 만든 프로그램들도 찾아볼 수 있지 않나요?
데스크탑 어플리케이션에서 자바는 현재 좀 문제가 있습니다. 첫번째는 너무 큰 런타임환경, 두번째는 VM startup 시간이 너무 길다는 것. 일반 사용자들에게 JRE 가 깔려있냐 없냐, 깔려 있으면 버젼은 뭐냐를 판단하게 할 수는 없으니 속편한 방법은 JRE 를 같이 배포하는 것인데... 네트워크 대역폭이 넓어지고, 하드 디스크 용량이 100G 를 넘어가는 요새는 60M 짜리 런타임이 큰 무리가 아니라는 입장도 있지만, 런타임을 제외하면 1~2 M 면 충분한 프로그램에 60M 런타임은 좀 부담스럽습니다. 그리고 VM startup 시간은 앞으로 좀 더 좋아지겠지만 splash screen 을 바라보면서 프로그램이 뜨기 기다리는 것은 갑갑한 일입니다. Look&Feel 은 스윙의 경우 문제가 있지만 SWT 는 괜찮은 것 같구요.

임베디드 쪽은 잘 모르지만 J2ME 가 아직 가능성은 있다고 봅니다. .NET 의 임베디드 지원에 대해서는 전혀 모르겠군요. 임베디드 쪽이 갈아탈지 말지를 고민해야할 분야가 아닐까요?

하드웨어를 직접 다룰 필요가 있는 OS, driver 등의 분야, 실시간 응답이 필요한 분야에는 아직 인터프리터/JIT 기반 언어가 전혀 침입하지 못하고 있는 것 같구요.

뭐 현재 상황은 이렇게 봅니다만, 저는 현재 인터프리터/JIT 기반 언어의 장점으로 꼽히는 이기종간(프로세서, OS) 바이너리 호환성과 언어간 라이브러리 호환성, 런타임/다이나믹 최적화 기술이 인터프리터/JIT 기반에서만 가능한 것들이 아니라고 봅니다.
런타임/다이나믹 최적화 기술은 현재는 인터프리터/JIT 언어기반으로 많이 발전해 있지만... 이건 네이티브 코드를 생성하는 언어에서도 가능하지 않은가요? 현재 네이티브 코드를 생성하는 주류 언어들이 컴파일타임/스태틱 최적화에 초점을 맞추고 있어서 그렇지 불가능한 것이 아니니까요.
그리고 잘 설계된 언어들은 이기종간 바이너리 호환성은 없어도 소스 코드 호환성은 있습니다. 네이티브 코드/바이트 코드를 모두 지원하는 언어도 있지요. 물론 컴파일러가 여러 플래폼을 지원해야하는 문제가 있지만 이는 어차피 플랫폼별로 인터프리터/JIT 를 따로 작성해야하는 것과 마찬가지이므로 약점이 아니라고 봅니다.
언어간 라이브러리 호환성 역시 네이티브 코드에서도 프로토콜만 잘 정의되면 별 문제 없다고 생각합니다. 어느 세월에 누가 프로토콜 표준을 정하고 또 각 언어들이 그걸 지원하느냐고 물으시면 할 말 없기는 합니다만...^^; 현재 언어간 라이브러리 공유가 wrapping 같은 삽질을 통해서 이루어지지만 (swig 같은 거의 자동화된 wrapping 툴도 존재합니다.) 아주 최소한의 노력으로 표준화된 프로토콜을 사용해서 가능하게 될 날을 기대합니다..

물론 VM 같은 표준화된 플랫폼이 이런 작업들을 훨씬 쉽게 한다는 것에는 동의합니다. 하지만 속도/저수준 하드웨어 제어같이 VM 을 도입함으로써 잃게 되는 것들이 분명히 존재합니다. 하드웨어가 발전할수록 속도 문제가 없을거라는 이야기는 옳지 않다고 봅니다. 하드웨서 속도가 높아지면 그걸 잡아먹는 새로운 기능이 등장하기 마련이므로 속도는 언제나 문제가 됩니다.

따라서 네이티브 코드 세상에서 점차 위에 언급한 기술들이 발전해서 언젠가는 (한 10년 ? 너무 먼 일인가...) 현재의 인터프리터/JIT 유행이 다시 다시 네이티브 코드로 전환되지 않을까 생각합니다.

그리고 개발자 입장에서는 인터프리터/JIT 기반인가 네이티브 코드 기반인가는 별도 중요하지 않다고 생각합니다. 보다 논리적/추상적인 개념인 "언어" 문제이지요. 새로운 언어/새로운 방법들을(그게 좋아서든, 밥 벌어먹고 살기 위해서든) 공부하고 만들어가느냐 그냥 하던거 하느냐하는 문제인거지요.

MS에서 monad라는 프로젝트명으로 개발하던
perl과 unix쉘을 짬뽕으로 섞어놓은듯한 문법의
새로운 명령행 shell의 RC버젼을 Powershell 이란
이름으로 내놓았습니다.
http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx
http://blogs.msdn.com/PowerShell/
이것이 돌아갈려면 .NET 2.0 버젼이 깔려야 됩니다.
cmdlet이라는 개념으로 운영체제의 핵심부분을 object로
shell 상에 불러들여 처리합니다.
이런걸 보면 MS는 운영체제 차기버젼 Vista부터 운영체제의 핵심부분까지
모두 VM기반으로 옮겨가려고 하는듯 보입니다.

네이티브코드의 최후라고 하기는 그렇고 앞으로 VM기반의 컴퓨팅이
더욱 확대될것 같습니다.

개인적으로 일반 사용자들을 위한 어플리케이션 개발시 java의 가장 꺼려지는 부분은 사용자들이 이거 쓸려면 jvm이 있어야돼? 뭐가 그런게 다 있어? 불편하네.. 한다는 점입니다. 이것은 다른 인터프리팅 언어들도 마찬가진것 같구요.. 이것만 아니면 개발에 있어서는 뭔가 꺼림직한 부분은 없는것 같습니다.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.xo.st
http://hangulee.egloos.com/

native code의 최후는 올 수도 있으리라 생각하지만 Java, .NET에 의해서 올 수 있을까에 대해서는 의문입니다. Java Virtual Machine의 Spec을 읽으면서 예전에 JVM을 설계해 보았는데 지나치게 이상적으로 설계한 듯한 느낌이 들었습니다. 제가 JVM을 설계하면서 느낀 것은 JVM에 있는 쓸데없는거 다 빼버리고 아주 simple하게 VM하나 만들고 싶다는 생각이 들더군요. ^^;

일단 Sun에서 Java를 내 놓으면서 했던 이야기가 JVM위에서 작동하는 프로그램은 현재는 Java로 작성해야만 하지만 앞으로는 기존의 언어로 작성된 프로그램들도 잘 작동할 것이라고 했지만 이미 Java가 등장한지 10년이 넘었지만 아직 잘 작동하지 않는 경우가 많습니다. ( Python정도가 잘 작동하는 듯 하군요. )

그리고 수시로 발생하는 Garbage Collection으로 인해 Realtime이 중요시되는 작업을 JVM위에서 하는 것이 불가능합니다. 공장의 벨브를 콘트롤 하는 프로그램을 JVM위에서 돌리려고 하면(실제로 제가 하려고 시도했었음) 뭔가 큰 일이 발생해서 얼른 벨브를 잠그려고 하는데 갑자기 Garbage Collection이 발생해서 열심히 Garbage를 Collect하는 상황이 발생해서 실제로 벨브를 잠구는데 상당시간 소요되기도 합니다. (-_-;;;)

그리고 Just In Time Compile도 좋긴 하지만 Compile하는데 시간이 너무 오래 걸립니다. 물론 startup만 되고 나면 native code에 비해 그다지 많이 느리지 않지만 JVM을 실행시키고 Compile도 하고 하다 보면 처음에 좀 지겹습니다. -_-; 그리고 그 compile된 code도 Garbage Collection을 할 때마다 정지되기 때문에 Realtime이 중요시되는 작업을 할 수가 없습니다. Java Application을 실행시키고 싶을 때 JVM을 실행하는게 아니라 미리 JVM을 실행시켜 놓는 방법도 있는데 JVM Spec상으로 하나의 Java Application이 일을 다 하고 끝마쳤을 때 JVM이 강제로 Java Application이 사용한 자원을 청소해 주는 방법이 존재하지 않습니다(요즘은 있을 지도?). JVM Process를 통째로 죽였다가 다시 실행해야 됩니다. 하지만 이것도 Process Model이 존재하지 않는 Embedded Platform에서는 Process를 죽일 수도 없으니 잘 눈속임하는 수밖에 없습니다. (몰래 초고속 reboot와 같은. ^^;;)

VM에 의해 native code가 사라질 가능성은 있지만 현재의 JVM은 여러가지로 문제가 많다는 것이 제 생각입니다. .NET도 살펴보면 JVM과 과연 뭐가 다른지 알기 힘들 정도로 유사한 느낌을 받았습니다. -_-;

Taeho Oh ( ohhara@postech.edu, ohhara@plus.or.kr ) http://ohhara.sarang.net
Postech ( Pohang University of Science and Technology ) http://www.postech.edu
PLUS ( Postech Laboratory for Unix Security ) http://www.plus.or.kr

네이티브 코드가 사라지는 경우는 없겠죠. 눈에 안보이는 경우는 생기더라도요.
일단 과학 계산이라던가 3D 그래픽스 등 순수하게 "계산"이 필요한 분야에서는 유효할 것이라고 봅니다.
인터프리터 언어나 JIT 언어들이 충분한 속도를 제공한다고 하더라도 네이티브보다 빠를 수는 없기 때문에 단순한 처리를 무지막지하게 해대야 하는 분야에서는 말이죠.
점점 임베디드 기계들이 많이 사용 되면서 그쪽 분야에서 활용되는 네이티브 언어들도 무시할 수 없죠. 저전력 소형 장비들은 앞으로 늘어날 분위기이고...이쪽은 말 그대로 "전력" 때문에라도 네이티르 언어를 써야 되겠죠. (전력 때문에 CPU 좋은거 꽂는게 부담됩니다.)
핸드폰쪽도...J2ME가 가장 잘 적용된 분야라고는 하지만, 제작년까지만 해도 Java기반 어플들이 네이티브 기반(BREW)을 절대 따라올 수 없었습니다.
WIPI초기에도(작년?) Java로 짠건 느려서 C로 짠다는 예기가 있었구요. 헨펀쪽은 뭐 워낙 H/W 발전이 빠른 분야라 어찌될지 모르긴 하군요. ^^;