Managed Code & Native Code

 Native code는 Unmanaged code라고 불립니다. (관리되지 않는 코드)

하지만 'Managed code는 좋은 것이고 Unmanaged code는 좋지 않은 것이다'는 것은 절대 아닙니다.

 

 Compile을 하게 되면 OS에서 해석가능한 기계어로 바로 번역이 되고, 이것은 프로그램하는 사람 입장에서 이런 저런 신경을 많이 쓰게 만듭니다.

 

 예를 들어 프로그램 실행시 사용했던 메모리는 프로그램이 끝날 때 잘 확인해서 모두 OS에 반납을 해야하고 혹시라도 프로그래머가 잊어 버리고 반납하지 않으면 시스템 에러를 일으킬 것입니다.

 

또 다른 예로 OS는 H/W에 따라 다르므로 프로그램을 Windows에서 Linux로 또는 그 반대로 옮기고 싶을 때(Porting한다라고 하죠.) 이거 생각보다 굉장히 어렵습니다. 비록 프로그램 소스는 비슷하다고 할지라도 그 결과물이 OS에 종속되어 있다 보니 생각지 못한 문제들이 많이 생기게 되죠. PC에서 윈도우즈용 프로그램을 작성한 것과 PDA를 위한 WindowsCE로 옮기는 것조차 쉬운 작업이 아니죠. PC와 PDA는 H/W가 많이 다르니까요.

 

 그래서 생각하게 된 것이 OS에 종속되지 않게 프로그램을 하는 방법은 없을까 하는 것입니다. 이런 시도는 많이 되었지만 아마도 최초로 성공한 예가 Java입니다. Java용 프로그램은 어디서 작성하던 똑같은 소스를 사용해서 Java가 실행되는 기계에서는 똑같은 결과를 보여 줍니다. 하나의 소스를 작성하면 아무런 변경없이 Windows, Linux, Mac 에서 바로 실행 가능하게 되는 것이죠.

 

이런 것이 되는 이유는 Java 소스가 컴파일될 때 바로 OS가 이해할 수 있는 바이너리로 변환되는 것이 아니고 일종의 임시 코드(IL, Intermediate Language)로 변환시키는 것입니다. 이 IL 코드는 실제로 OS에서 실행할 수는 없습니다. 이 IL코드가 실행되기 위해서는 각 OS에 이미 설치되어 있는 JIT(Just In Time) 컴파일러가 OS용 코드로 변환을 해 주어야 합니다. 이 JIT 컴파일러들은 각 OS마다 다르지만 설치만 되어 있다면 IL코드는 어디서나 같은 동작을 하게 됩니다.

 

Microsoft가 Java에 대항하기 위하여 만든 것이 바로 .NET 입니다. 기본적으로 Java나 .NET이나 그 기본 원리는 같습니다. OS와 Application 사이에 위치하면서 중간자의 역할을 하는 것입니다.

 

어쨌던 Java나 .NET 같은 새로운 환경에서 실행되는 프로그램들은 기존의 프로그램들과는 다른 특징들을 가지고 있습니다. 그래서 기존의 프로그램들은 Native Code라고 부르고 새로운 프로그램들은 Managed code라고 불러서 구분을 하게된 것입니다.

 

Managed code가 가지는 몇 가지 특징들을 말하자면 다음과 같습니다.

 

    # 객체지향모델 - Java나 .NET이나 모두 OOP로 설계되어 있습니다.

    # 언어 독립적 - 어떤 언어로 프로그래밍하더라도 상관없습니다.

    # 형안정성 - Managed code는 변수의 형을 엄격하게 제한합니다.

    # Garbage Collection - 프로그램에서 메모리 해제를 하지 않더라도 알아서 해줍니다.

                                             대체로 Managed code에서는 포인터 같은 것을 지원하지 않죠.

    # 단일통합라이브러리 - 플랫폼레벨에서 많은 API들을 제공해 줍니다.

    ...

 

등이 있습니다. 단점으로는 대표적으로 Native code에 비해 실행속도가 느리다던가 Java Virtual Machine이나 .NET Platform이 설치되어 있지 않은 컴퓨터에서는 실행이 되지 않는 다던가 하는 것들이 있습니다. 이것은 생각보다 매우 중요한 요건일 수 있습니다. 내가 윈도우용 프로그램을 만들었는데 이것을 실행하기 위해서는 .NET Platform이 반드시 설치되어 있어야 하고 사용자는 이것을 싫어 할 수도 있기 때문이죠.

 

가장 대표적인 것으로는 최근 각광받고 있는 VB나 C#을 들 수 있겠습니다.

 

그 사용의 편의성 때문에 많은 이들이 점점 기존 C/C++가 주류인 Native code에서 Java나 C#이 주류인 Managed code로 이동하고 있지만 속도는 생각보다 빠르지 않습니다. 아직도 많은 프로그래머들이 VB 6.0을 사용하고 있죠.(6.0은 Native code를 만들 수 있었지만 그 이후 버전들은 전부 Managed code만 지원합니다.)  VC++는 현재 Native code, Managed code 를 동시에 만들 수 있는 거의 유일한 컴파일러이지만 사람들이 VC++를 사용하는 이유는 Native code를 만들기 위해서인 경우가 훨씬 많죠.

 

 

 

- 네이버 지식인 펌 -

 

JVM은 Java Virtual Machine의 약자이다. Machine이라는 말이 들어가 있긴 하지만, 실제로는 소프트웨어이다. Machine이라는 말이 들어간 이유는 JVM이 실제적으로 CPU와 같은 역할을 하기 때문인 것이라고 추정된다.

프로그램은 CPU 위에서 돌아가게 된다. 따라서 C나 C++과 같은 일반적인 프로그램 언어에서 컴파일하여 생성된 코드는 바로 해당 CPU에서 실행이 가능한 코드이다. 하지만 자바 소스코드(*.java)를 컴파일한 경우 생성되는 클래스파일(*.class)은 직접 CPU에서 동작할 수 있는 코드(native code)가 아니다. 생성된 클래스파일은 중간단계의 언어라고 할 수 있는 byte code로 이루어져 있다. 바로 이 byte code를 실행시키기 위한 가상적인 CPU가 필요한데 바로 그것이 Java Virtual Machine이 되는 것이다.

그렇다면 왜 Java 언어는 native code가 아닌 byte code를 생성하는가? 그 이유는 바로 이식성 때문이다. 직접 native code를 생성하게 되면, 그 native code는 CPU에 종속적인 특성을 갖게 된다. 즉 컴파일된 CPU에서만 돌아간다는 것이다. 반면에 byte code는 JVM 위에서 돌아가기 때문에, 어떤 플랫폼이건 JVM만 있으면 실행이 가능하게 되는 것이다.

 

아래 두 그림에서 Interpreter의 역할을 하는 것이 바로 JVM이다. 실제로 JDK에 포함되어 있는 파일 중에 JVM(Java Interpreter)은 java.exe이고, Java Compiler는 java.exe이다.

아래 그램에서 보는 바와 같이, 일반적으로 Java Platform이라고 말할 때, 이는 Java API와 Java Virtual Machine을 두고 하는 말이다. Java API가 프로그램을 짤 때 사용하기 위한 라이브러리의 집합이라고 한다면, Java Virtual Machine은 작성된 프로그램을 실행시키기 위한 환경이라고 볼 수 있다.

JVM은 이와 같이 기본적으로 byte code를 실행시켜 주는 역할을 감당하고 있는데, 그 역할을 감당하기 위해서, runtime linking과 garbage collection을 지원한다.

runtime linking은 실행 class가 JVM을 통해서 실행되는 중에 필요한 외부 class와 결합(linking)되도록 하는 방식을 말한다. JVM에서 이런 runtime linking이 지원되므로, 여러 클래스들이 한 프로그램을 구성하는 경우에, 한 클래스를 수정해야 할 일이 발생할 경우, 전체를 다시 컴파일할 필요가 없이, 단지 변경된 클래스가 속한 파일만을 컴파일해주면 된다는 장점을 갖게 된다.

garbage collection은 더 이상 사용하지 않는 메모리 영역을 시스템 자원으로 돌려주는 것이라고 말할 수 있다. 이것은 프로그래머의 실수로 인한 memory leak(메모리 누수 현상)을 방지해주며, 그에 따라 프로그래머의 부담을 덜어주게 된다.

 

JVM의 단점은 다른 인터프리터 방식의 언어(ex. BASIC)보다는 상당히 빠른 수행능력을 보이지만, 일괄 컴파일 방식 언어(ex. C, C++)보다는 수행 속도가 느리다는 것이다. 이것은 JVM이 컴파일하여 생성한 byte code를 사용하긴 하지만, JVM이 실행 중에 byte code를 native code로 변환하는 시간을 필요로 하기 때문이다.

 

인터넷 프로그래밍에 있어서는 대부분의 웹브라우저 자체가 plug-in 형태로 JVM의 역할을 내장하고 있다. 따라서 웹 개발자가 Java Applet으로 개발을 한 경우, 사용자의 웹브라우저가 JVM을 내장하고 있다는 조건만 충족된다면, 그 사용자가 웹브라우저를 구동하고 있는 플랫폼이 어느 곳이건 간에 문제가 되지 않는다는 이점이 있다.

또한 서버측 스크립트 언어를 사용하면, 그 자체로 사용자가 웹브라우저를 구동하고 있는 플랫폼 자체가 문제가 되지 않으며, 따라서 JVM이 웹브라우저에 포함되어 있지 않다고 하더라고 문제가 되지 않는다. 그러나 이 경우 서버측 스크립트 언어가 돌아가고 있는 환경이 문제가 될 수 있다. 즉 웹서버가 돌아가는 플랫폼이 어떤 환경인가에 따라서 ASP와 같은 스크립트 언어는 실행될 수 없는 경우가 있다. 반면 Servlet이나 JSP와 같이 JVM을 이용하는 언어로 작성되어져 있는 경우에는, 돌아가는 웹서버가 어떤 플랫폼인가에 무관하게 잘 동작한다는 이점을 갖게 된다. (돌아가는 플랫폼에서 동작하는 JVM이 있을 경우)

 

 

 

 

 

 

출처

https://ssaturn.tistory.com/99

Managed Code vs Native Code의 차이