-------------------------------------------------------------------------------------------
예전에 델마당에 올린 글이지만, 약간 편집하여 새로 올려 봅니다.
-------------------------------------------------------------------------------------------

컴 언어를 몇개 배워본 사람이라면, 컴언어의 종류에 다음과 같은 세가지가 있음을 알것이다.

인터프리터(interpreter) : 구석시 시대의 GW-BASIC, ASP, PERL, PHP, 자바스크립트 같은 대부분의 스크립트 언어
런타임 컴파일러(Runtime Compiler) : RM-COBOL, VB6, 파워빌더, 자바, 닷넷
순수 컴파일러(Native Compiler) : C, C++, Delphi

인터프리터는, 프로그램을 실행할 때 마다 소스를 한줄 식 기계어로 번역하여 실행한다.
런타임 컴파일러는, 소스 코드를 특수한 형태로 압축 정형화하고  실행시 이를 기계어로 번역하여 실행한다.
순수 컴파일는 소스 전체를 번역하여 기계어화하고, 이를 실행시 즉각 실행한다. 즉 실행시 번역 과정이 필요없다.

보통 디버깅, 즉 개발 편의성 관점에서는 인터프리터 > 런타임 컴파일러 > 순수 컴파일러 순이며, 실행 효율 관점에서는 순수 컴파일러 >  런타임 컴파일러 > 인터프리터의 순이다.

인터프리터와 런타임 컴파일러 방식으로 작성한 프로그램을 실행하려면, 번역기 역할을 하는 프로그램이 클라이언트 PC에 반드시 존재해야 하지만, 순수 컴파일러 방식은 단지 실행파일만 있으면 된다. VB의 경우, VB 어플과 함께 배포되는  여러 DLL들이 그것이며, 자바나 닷넷의 경우, 런타임, 혹은 프레임웍이란 형태로 별도의 DLL 덩어리들이 존재해야만 실행된다. 따라서 닷넷 프로그램들은 최종 배포에서 런타임 배포라는 다소 골치아픈 문제를 수반한다. 혹자는 닷넷은 런타임 컴파일러 방식이 아니라고 하나 이는 틀린 말이다. JIT 컴파일 방식은 런타임 방식의 진전된 방식일 뿐이다.

차기 윈도우 버전에서는 어떨지 모르나 아직 닷넷은 윈도우에 기본적으로 설치되지 않기 때문에 개발자가 알아서 이를 설치해 줘야 한다. 차기 윈도우 버전에서 닷넷 런타임이 기본적으로 포함되어 있다해도 여전히 문제가 있다. 런타임의 버전 불일치 문제는 여전히 존재하기 때문이다. 이미 닷넷 1.0, 1.1, 2.0 버전간에는 런타임 DLL들의 버전 문제가 심각하게 존재한다. 자바에서도 비슷한 문제가 존재한다. 내 경험에 의하면 버전간 호환성이든, 오에스간 호환성이든간에 호환성을 유지한다는 것은 매우 어렵다. 개발을 많이 해본 사람이라면 남의 소스를 뜯어 고치는 것보다 차라리 새로 만드는 것이 훨씬 더 편할수도 있다는 말에 동의할 것이다.

이런 저런 이유때문에 상용 전문 개발자들은, C나 델파이 같은 순수 컴파일러 방식를 선호한다. 이는 순수 컴파일러 방식이 실행 효율성과 배포 편의성이 우수하기 때문이다. 또 컴파일러 방식은 다른 방식에 비해 유별난 장점이 있는데, 역디버깅, 즉 해킹이 비교적 어렵다는 것이다. 인터프리터 방식은 소스 내용을 숨길 수가 없기 때문에 소스가 훤히 보인다는 치명적 단점이 있다. 이는 상용 전문 개발자한테는 치명적이다. 런타임 컴파일러 방식은 소스 코드를 특수 형태로 압축 정형화 하기 때문에, 소스 노출이 어려울 것 같지만, 사실 이는 기우다. 압축 코드 해석 방식만 알면, 런타임 컴파일러들의 역컴파일러 만들기는 그리 어렵지 않다. 자바나 닷넷으로 만든 프로그램의 경우, 역컴파일하면 소스의 90-100 퍼센트까지 그대로 복원할 수 있다. 이러한 자바나 닷넷 역컴파일러들은 인터넷에서 이미 공공연하게 나돌고 있다.

혹자는 델파이나 C++로 만들어도 어셈블러 레벨에서 역디버깅이 가능하지 않는가하고 물을 것이다. 어셈블러(기계어) 차원에서 역디버깅은 매우 어렵다. 이는 아무나 할 수 있을 정도의 만만한 기술이 아니다. 그러나 어떤 형태로든 소스가 훤히 보인다면, 충분히 소스 역추적이 가능하다. 자바와 닷넷의 경우, Code Obuscator라고 하여, 소스 코드를 난잡하게(?) 하는 툴들이 존재한다. 이 툴의 주역할은, 클래스, 메서드, 변수 이름을 어렵게 하고, 구조 제어문 순서를 바꾸고, 문자열을 암호화 시켜서 역컴파일러로 분석한 자바나 닷넷의 소스 코드를 이해하기 어렵게 만드는 것이다. 그런데 어지럽게 하던 말던, 소스는 훤히 보인다는 것이다. 소스가 보이면 언젠가는 분석이 가능하다는 것이다. 이는 개발경험에 비추어서 충분히 가능하다. 델파이 실행파일로부터 원래 소스를 백프로 복원했다는 이야기는 아직 들은바 없지만, 자바나 닷넷은 이것이 비교적 쉽다는 것이다.

-----노트 ------
최근 소스 추적을 더욱 어렵게할 수 있는 새로운 Obuscator들이 등장했다는 이야기를 들었는데 이들을 사용해보지 않아서 그 프로그램들의 소스 꼬으는 실력은 직접 확인 해보지 못했다. 혹시 이런 툴을 사용해본 사람이 있다면 알려 주시라.
-----노트 ------

따라서 자바나 닷넷으로 만든 프로그램의 소스가 노출되지 않기를 바란다는 것은 불가능하다. 이 말은 클라이언트에 어떤 형태로든 설치될 경우, 닷넷과 자바 프록그램의 소스 노출은 피할 수 없다는 것이다. 그렇다면 자바나 닷넷으로 짠 프로그램의 경우에 소스 노출을 피하려면, 오로지 서버에서만 동작하는 서버 어플케이션으로만 작성해야 한다는 이야기이며, 이는 결론적으로 자바나 닷넷으로는 가급적 클라이언트 프로그램을 만들지 말라는 것과 다름 없다. 따라서 3 티어로 만든 프로그램일 경우, 어플 서버 측은 서버 쪽에서 실행되므로 이런 부분은 닷넷이나 자바로 만들어도 소스 노출은 피할 수 있을 것이다.

----노트----
닷넷 프레임웍의 보안에 대해서 공부한 사람이라면, 닷넷 보안이 소스 노출 방지 기능을 제공하지 않는가 하고 반문할지 모른다. 닷넷 보안이란 코드의 실행시 권한을 규정하는 것일 뿐, 소스 노출하고는 전혀 무관한 개념이다.
---노트끝----

그런데, 서버 어플과 클라이언트 어플의 비율 중 어느쪽이 높다고 생각하는가? 인터넷 시대인 요즘에도 수많은 클라이언트 프로그램이 존재하고 있고, 서버 어플보다는 월등히 그 비중이 높다. 자바로 만든 상용 클라이언트 프로그램을 본적이 있는가? 자바 애플릿이 한때 웹브라우저에서 사용된 적이 있지만, 상용 웹사이트가 자바 애플릿으로 어떤 서비스를 제공하는 것을 본적이 있는가? 의외로 그 비중은 매우 적다. 대부분의 자바 개발자들은 자바의 GUI 개발환경이 매우 열악하고 소스 노출이라는 치명적 단점 때문에 서버 어플 개발에만 전념하는 경우가 많다.

그렇다면 대체 MS는 왜 닷넷을 순수 컴파일러 방식이 아닌, 런타임 컴파일러 방식으로 만들었을까? 사실 닷넷의 탄생 목적은 선의 자바 견제가 거의 주목적이었다고 해도 과언이 아니다. 즉, 닷넷은 서버쪽 어플을 상당수 장악한 자바를 견제하기 위해서, 서버 어플 개발 툴로 만들어졌다는 것이다. 닷넷은 자바와는 달리 아주 막강한 GUI 라이브러리를 제공하긴 하나, 이는 닷넷의 또 다른 단점을 만들었다.

SUN이 원래 자바를 순수 컴파일러 방식이 아닌, 런타임 컴파일러로 만든 이유는 OS 호환성때문이었다. 여러 OS 환경에서 동작하려면 순수 컴파일러 방식보다는 런타임 컴파일러 방식이 매우 유리하기 때문이다. 왜냐하면 각 OS의 상이점을 런타임 환경이 보완해서, 그 OS에 맞는 적절한 API호출로 대체할 수 있기 때문이다. (사실 이러한 자바의 여러 OS 호환성은 실제로는 제대로 안되는 경우가 대부분이다. 이는 지난번 글에서도 언급했지만 호환성 유지는 매우 어렵다.) MS역시 이 OS 호환성과 언어 불문(language agnostic) 기능을 구현하기 위해 닷넷을 런타임 컴파일러로 만들었다.

그런데 닷넷의 윈폼 라이브러리는 윈도우에서의 막강한 GUI 개발환경을 위해서 WIN 32 API에 매우 의존적으로 개발되었다. 이 때문에 윈폼 라이브러리를 다른 OS에서도 동작하게 하는 것은 엄청나게 어렵다. 닷넷 콤팩트 프레임웍이 닷넷 프레임웍과 호환성이 전혀 없는 것도 이런 이유때문이다. 닷넷 프레임웍이 Win 98 계열에서 잘 동작하지 않는 것도 같은 이유다. 즉 MS가 원래 주장했던, 여러 OS에서 닷넷 프레임웍이 동작하게 할 것이란 야그는 거의 물 건너간 공수표로 봐도 무방하다. MS의 사업적 이익 때문에, 다른 OS를 지원한다는 자체가 거짓말이다. 닷넷을 리눅스에서 동작하게하면 MS 수입의 상당부분을 차지하는 윈도우 판매량이 줄것이 뻔한데 MS가 왜 그런짓을 하겠는가?

결론적으로 이야기해서 현재의 윈도우 계열에서만 두고 봤을 때, 닷넷은 델파이보다 호환성이 결코 좋다고 볼 수 없다. 아시다 시피 윈도우 API를 마구 호출해대지 않는, 일반적 방식으로 작성한 델 어플들은 윈 95에서 2003까지 아무런 문제없이 잘 동작한다.

따라서, 일전에 올린 델파이 수석 개발자의 글에서, 닷넷이 클라이언트 개발툴로는 적합하지 않다는데 나는 동의한다. MS의 행보로 봐서 서버쪽 개발툴로 닷넷을 여러모로 지원하는 것 같아 보인다. SQL서버의 닷넷 기본 지원이라든가, 차기 OS의 닷넷 지원 약속 등이 그것인데, 컴퓨터 분야에서는 숱한 공수표들이 난무하므로, 이는 좀더 두고 볼일이다. 선은 자바에서 엄청난 공수표들을 남발했으며, MS가 선의 그러한 공수표들을 재발행할지 두고 볼 일이다.(이미 해외에서는 닷넷의 공수표 가능성에 대해서 몇몇 글이 올라오는 듯하다.)

MS가 시샵을 런타임 컴파일러가 아닌, 순수 컴파일러로 만들었다면 차라리 더 낮지 않았을까 생각해본다. 닷넷은 말이 좋아 컴 언어 불문이지, 실제로는 전혀 컴언어 불문이 아니다. 이는 VB를 VB.NET으로 포팅해보거나, 기존 ASP를 ASP.NET으로 포팅해보면 금방 이해할 수 있다. 언어 문법보다 기존 코딩 경험을 바꿔야 한다는 것이 개발자에게는 더 큰 부담이다.

행여나 해서 하는 말이지만, 이 글을 닷넷을 공부할 필요가 없다는 글로 이해하지 말라! MS나 여러 언론에서 말하는 닷넷의 과장됨에 현혹되지 말라는 글이지, 닷넷을 공부하지 않아도 된다는 자기 변명으로 이 글을 받아들이지는 말기를 진심으로 바란다.

새로운 언어를 배움으로 인해서 얻는 것이 많기 때문이다. 나는 자바나 닷넷이든 새 언어가 나올 때마다 어느 정도 수준까지 연구해 본다. 이는 상당히 델파이 광신자적인 나로 하여금 겸허하게 다른 언어를 둘러보게 하고, 그 언어의 좋은 점을 델파이에서 구현해볼 수 있는 기회를 주기 때문이다.