컴 언어를 몇개 배워본 사람이라면, 컴언어의 종류에 다음과 같은 세가지가 있음을 알것이다.
인터프리터 : 구석기시대의 GW-BASIC, ASP, PERL, PHP, 자바스크립트 같은 대부분의 스크립트 언어
런타임 컴파일러 : RM-COBOL, VB6, 파워빌더, 자바, 닷넷
순수 컴파일러 : C, C++, Delphi
..인터프리터는, 실행시 프로그램 소스를 한줄 식 기계어로 번역하여 실행한다.
..런타임 컴파일러는, 소스 코드를 특수한 형태로 압축 정형화하고 실행시 이를 기계어로 번역하여 실행한다.
..컴파일러 : 소스 전체를 번역하여 기계어화하고, 이를 실행시 즉각 실행한다. 즉 실행시 번역 과정이 필요없다.
보통 디버깅, 즉 개발 편의성 관점에서는 인터프리터 > 런타임 컴파일러 > 순수 컴파일러 순이며, 실행 효율 관점에서는 순수 컴파일러 > 런타임 컴파일러 > 인터프리터의 순이다.
인터프리터와 런타임 컴파일러 방식으로 작성한 프로그램을 실행하려면,
번역기 역할을 하는 프로그램이 클라이언트 PC에 반드시 존재해야 하지만,
순수 컴파일러 방식은 단지 실행파일만 있으면 된다. VB의 경우,
VB 어플과 함께 배포되는 여러 DLL들이 그것이며, 자바나 닷넷의 경우, 런타임,
혹은 프레임웍이란 형태로 별도의 DLL 덩어리들이 존재해야만 실행된다.
따라써 닷넷 프로그램들은 최종 배포에서 런타임 배포라는 다소 골치아픈 문제를 수반한다.
이 런타임 배포에 대해서 MS가 신경을 무지 쓴 것은 사실이나,
델파이 실행 파일 배포와는 차원이 다른 복잡성이 분명히 존재한다.
따라서 전문 개발자들은,
C나 델파이 같은 순수 컴파일러 방식를 선호한다. 이는 순수 컴파일러 방식이
실행 효율성과 배포 편의성이 우수하기 때문이다.
또 컴파일러 방식은 다른 방식에 비해 유별난 장점이 있는데,
역디버깅, 즉 해킹이 비교적 어렵다는 것이다. 인터프리터 방식은 소스 내용을 숨길 수가 없기 때문에 소스가 훤히 보인다는 치명적 단점이 있다. 이는 상용 전문적 개발자한테는 치명적이다.
런타임 컴파일러 방식은 소스 코드를 특수 형태로 압축 정형화 하기 때문에,
소스 노출이 어려울 것 같지만, 사실 이는 기우다. 압축 코드 해석 방식만 알면,
런타임 컴파일러들의 역컴파일러 만들기는 그리 어렵지 않다.
자바나 닷넷으로 만든 프로그램의 경우, 역컴파일하면 소스의 90-100 퍼센트까지
그대로 복원할 수 있다. 이러한 자바나 닷넷 역컴파일러들은 인터넷에서
이미 공공연하게 나돌고 있다.
혹자는 델파이나 C++로 만들어도 어셈블러 레벨에서 역디버깅이 가능하지 않는가하고 물을 것이다. 어셈블러(기계어) 차원에서 역디버깅은 매우 어렵다.
이는 아무나 할 수 있을 정도의 만만한 기술이 아니다.
그러나 어떤 형태로든 소스가 훤히 보인다면, 충분히 소스 역추적이 가능하다.
자바와 닷넷의 경우, Code 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사가 기술적 어쩌고를 한다는 뉴스를 이곳에서 보았는데
선사와 DM$가 얼마나 이같은짓들을 날려댈지도 두고봐야할것같다.
