아랫분의 말씀이 일리가 있는 것 같습니다.
저는 컴파일러 내부에 별로 관심이 없어서 자세히는 모르겠습니다만.

작년 11월에 MS가 자바 개발자들을 흔들어놓기 위해 내놓았던 펫스토어 속도 논쟁이 있었습니다.
C#과 자바의 속도를 비교했더니 10배 이상이 차이가 나더라는 MS의 발표였는데요.
그리고 이 논쟁의 영향으로 상당수 자바 개발자들(주로 초급자들을 중심으로)이 흔들리거나 C#으로
넘어갔던 것으로 추측합니다.

자바를 공부하시는 분들은 다들 아시지만, 이 펫 스토어라는 것은 다양한 자바언어의 기술들을
종합해서 구현해본 상징적인 예제입니다. 필드에서 쓰기 위한 것이 아니라, 다양한 JVM 플랫폼들이
자바의 모든 스펙을 다 구현하고 있는지를 간단히 테스트해보기 위해 쓰는 예제지요.

MS의 주장은, 이 예제를 C#으로 포팅해서 해봤더니 자바보다 엄청나게 빠르더라, 하는 거였는데,
뭐 한마디로 말도 안되는 쌩 거짓말이었습니다.

일단, MS가 C#으로 컴파일했던 것은 펫 스토어와는 아주 많이 다른 소스였습니다.
상당히 많은 코드들을 DBMS의 스토어드 프로시저로 옮겨버렸고(데이터 핸들링 코드들을 스토어드
프로시저로 옮겨놓으면 속도가 빨라지는 것은 DB 최적화의 가장 기본적인 상식임), 또 펫스토어에
있던 엔티티빈 구조를 싹 빼버리고 직접 디비 핸들링을 해버렸습니다. (저도 자세히 알지는 못하지만
엔티티 빈은 DB 핸들링을 담당하는 일종의 미들웨어에 해당하는 것으로, 이걸 쓰면 직접 연결에 비해
속도가 많이 느려진다고 하더군요.)

코드를 스토어드 프로시저로 옮겨버렸는데 다른 최적화야 말할 것도 없겠지요.
한마디로, 원래 자바코드였던 펫스토어 프로젝트는 다양한 기술을 시험해보기 위한 샘플일 뿐인데
MS는 거기다 최대한의 최적화를 해서 완전히 다른 프로젝트를 만들어버린 것입니다.

또 사용한 DBMS도, 자바쪽에서는 오라클을 사용했는데 비해 C#의 경우엔 MS SQL을 썼습니다.
두가지 DBMS 사이의 속도차이도 영향이 클 거구요.

MS가 이런 눈가리고 아웅하기식의 결과를 마치 사실인양 뻔뻔스럽게 발표한 의도는 뻔하겠죠?
자바에 있어 중급 이상 개발자들이라면 코웃음을 치고 말 일이지만, 입문하시는 분들에게는
그런 배경이 어떤지를 모릅니다. 어떤 분야라고 하더라도 입문자가 상당수를 차지하기 때문에,
(아마도 30% 안팎?)이런 말도 안되는 결과라도 내놓으면 잘 모르는 입문자들은 영향을 많이 받게
됩니다.

또 이미 자바가 기득권을 가지고 있는 상황에서, 어떤 공격적이고 악의적인 비방이라고 하더라도
결과는 시장에 진입하고 있는 닷넷쪽에 유리한 결과가 됩니다. 정치가들이 세력에서 밀리면
각종 근거도 없는 의혹들을 쏟아내고, 그것이 실제로 조금이라도 의혹을 받은 쪽에 불리하게
작용하는 것과 같습니다.

이 결과에 대해 썬에서는 다시 벤치마크를 하는 등의 정면 대응은 안했던 것으로 기억하는데..
아마도, 사실 기본적으로 자바가 C#보다 조금쯤은 느리기 때문일 겁니다.

그럴 수밖에 없는것이.. 큰 관점에서 보면 자바와 C#은 같은 레벨의 언어입니다.
(C/C++과의 차이를 말하는 겁니다.) 자바는 이미 꽤 오래전에 만들어진 스펙이므로 훨씬 뒤에 나온
C#이 자바보다 못하다면 MS에 바보들만 모여있는 거겠지요.

게다가, C#, 그리고 닷넷은 적어도 지금 상황에서는 절대적으로 윈도우 플랫폼에 최적화에 최적화를
거듭한 것입니다. 반면 자바는 윈도우보다는 솔라리스에 더 최적화가 되어있죠.


이런 예에서와 같이...
일반적으로 IT업계의 속도와 성능 논쟁은 거의 최적화 문제로 얼룩진 논쟁일색이 되기 마련입니다.
그리고 보통 최초의 공격을 먼저 시작했던 업체쪽이 조금이라도 유리하게 상황이 전개됩니다.

위의 펫 스토어의 경우에도, 최초의 자바 펫스토어 벤치마크를 했던 오라클이 닷넷보다 J2EE가
더 빠르다는 결과를 최근에 다시 내놓았지만 별로 주목받지 못하고 있는 것 같습니다.
http://otn.oracle.com/tech/java/oc4j/pdf/9ias_net_bench.pdf

아래에 먼저 글을 쓰신 분의 의견에서처럼 메모리의 문제가 될 수도 있을 것 같습니다.
그리고 그런 문제도 높아진 하드웨어의 사양에 따른 최적화가 충분히 되었다는 흐름의 일부일 겁니다.

예를 들어, C언어는 수십 kB짜리 메모리에서도 잘 동작하도록 만들어졌고, C++은 수백kB 단위 이상에
적합합니다. 또 윈도우XP가 윈도우2000보다 높은 사양에 최적화되어서 훨씬 더 커진 덩치에도 불구하고
몇가지 부분에서는 윈도우2000보다 빠른 것과도 비슷합니다.
아직은 절대다수이지 않은 펜티엄4에 새로 추가된 명령어에 최적화가 되어있는 컴파일러가
속도면에서 조금이나마 더 유리할 것은 당연합니다.

하지만 분명한 것은, 그런 최적화의 조건은 적어도 현재 상황에서는 일반적이지 않은 고사양 머신을
필요로 한다는 것입니다. 물론 몇년 후쯤 되면 그런 사양이 상당히 일반화될 것으로 보이긴 합니다만.

사실 이런 MS의 공세는, 몇년전까지만 하더라도 썬이 C/C++ 진영을 공략하기 위해 써던 전략의
재탕입니다. 자바 코드가 C++ 코드와 같거나 조금 더 빠르다고 주장하기를 매번 업데이트마다
계속했었지요. 그래서 어떻게 됐습니까.

JBuilder와 같이 절대적으로 pure 자바를 지향하는 경우 외에는, 데스크탑 솔루션은 자바로 만드는
경우는 거의 없습니다. 대표적인 경우가 넷스케이프 브라우저로, 넷스케이프에서는 몇년전에 이넘을
자바로 포팅하려는 야심찬 프로젝트를 하다가 포기한 바 있습니다.

개발자들은 대체로 좀 꼼꼼하다보니, 특정 연산에서 빠르다 아니다에 영향을 많이 받는데요.
그러다보니 나무만 보고 숲은 못보는 경우가 허다합니다. 특정 연산에서 빠를 수도 있습니다.
IT 기술이 발전하는 거니까 당연한 거지요. 하지만 자바의 경우 데스크탑에서 분명히 실패했습니다.

자바가 일반 데스크탑이 아닌 모바일이나 엔터프라이즈에서 특히 각광받는 것은 당연한 것입니다.
원래 자바는 모바일(정확하게는 가전제품)에서 사용되기 위해 설계된 것이었고, 또한 엔터프라이즈
레벨에서는 최악의 경우 대수를 늘리거나 사양을 높임으로써 하드웨어 비용을 높이는 대신 개발
비용을 낮추는 방법으로 공략이 가능했기 때문입니다. 일반 데스크탑 사용자들에게 당장 128MB의
메모리를 증설하고 CPU를 2G로 업그레이드하라는 것은 대단히 어려운 일이지만, 서버를 구축하면서
1GB쯤 메모리와 최신 제온 프로세서를 증설하거나 아예 서버 한대쯤 더 놓는 것은 쉬운 일이니까요.

윈도우에 최적화시킨만큼, C#은 자바보다는 데스크탑에서 강한 모습을 보여줄 것으로 생각하고 있습니다.
하지만 C#이 데스크탑에서 위력을 발휘하는 것은 가까운 시일이 되지는 못할 겁니다.
우리나라에서야 PC에 메모리 하나 더 꽂는 것을 연례행사 정도로 여기고 있지만 미국이나 다른 나라들은
우리나라보다 업그레이드에 좀 더 보수적이니까요.

그래서 C#도 자바의 전철처럼, 먼저 엔터프라이즈 레벨에서 채용되기 시작할 것은 당연합니다.
지금 C#을 도입하는 기업들은 아주 소수인데다 대부분 실험적인 시도이고, 엔터프라이즈 레벨의
프로젝트에 본격적으로 채용되기 시작하는 것은 유달리 유행을 좋아하는 우리나라의 IT업계라고
하더라도 아마도 내년 중반정도가 될 것으로 추측합니다.

반면 데스크탑에서 C++의 강력한 경쟁자가 되기 시작하는 것은 아주 빨라도 5년 정도는 걸리거나,
혹은 거의 불가능할 수도 있습니다.

너무 늦춰잡은 게 아니냐고 하실 분들도 있겠습니다만... C#이 데스크탑에서 실행되려면 방대한
CLR이 깔려있어야 하는데, CLR 도입의 전초전 역할을 할 윈도우 XP를 비롯하여 향후 CLR이 본격적으로
도입될 윈도우의 차기버전들이 지속적으로 업그레이드율이 낮아지고 있거나 그렇게 예상되고 있기
때문입니다. (당장 저부터, 향후 몇년간은 지금 쓰고 있는 윈도우2000에서 업그레이드하고 싶은
맘이 전혀 없습니다.)

예를 들어서, 작년 10월에 출시된 윈도우 XP의 새로운 GDI+의 기능을 채용한 애플리케이션은 아직도
거의 없습니다. 윈도우2000의 블렌딩(반투명)효과를 사용하는 애플리케이션도 대단히 적은 실정이죠.

데스크탑 개발자에게 호환성은 절대적인 문제이기 때문에, 만약 CLR이 깔려있는 PC가 최소 50%
(혹은 그 이상일 수도)가 되지 않으면 소프트웨어 개발자들이 CLR용의 애플리케이션을 개발하기
시작하지 못합니다.
(여러분이라면, CLR이 깔린 PC가 절반도 안되는 상황에서 C#으로 데스크탑 애플리케이션을 만들어서
팔면서 최소 수십메가의 CLR을 깔라고 고객들에게 요구하겠습니까?)

여기서 가장 영향력을 발휘할 수 있는 변수가 MS오피스와 같이 절대적인 점유율을 가지고 있는
애플리케이션입니다. MS오피스의 새버전을 내놓으면서 CLR을 같이 깔아버린다든지, 아니면 설치시에
CLR을 깔라고 강요한다면 그 효과는 상당할 겁니다.
하지만, 이런 경우 안그래도 업그레이드율이 계속 하락하고 있는 오피스의 매출에 엄청난 타격이
되겠지요. 오피스의 매출이 전체 매출에서 절대적인 비율인 상태에서 이런 모험은 하기가 힘들겁니다.

현재 시점에서 MS의 모든 전략은 닷넷을 중심으로 꼬리에 꼬리를 물고 있어서, 그중 한두가지만
계획대로 되지 않아도 전체 닷넷 전략에 큰 타격이 됩니다.

이런 이유로...

닷넷이 데스크탑을 점령하는 것은 상당히 오랜 후(최소 4~5년)가 되거나 혹은 전혀 불가능할 수도 있습니다.
만약 엔터프라이즈 프로젝트를 꿈꾸는 분이 아니라면, 닷넷은 당분간 아예 머릿속의 메뉴에서
빼버리는 것이 좋을 겁니다. 엔터프라이즈를 제외하면 닷넷은 훗날의 이야기이고, 4~5년이면 지금
입문하시는 분이 중급 이상으로 경력을 쌓을만큼 IT업계에서는 대단히 긴 시간입니다.

그러므로, 너무 서두르지 맙시다.
저번에도 썼다시피, 개발자가 닷넷을 따라 오버해서 춤을 추면 피해를 보는 것은 개발자이고
이익을 보는 것은 MS입니다.

일반 소비자는? 소비자야 시장에서 완전히 대세가 된 쪽을 따르는 것이 보통이죠.
개발자처럼 홍보 공세에 밀려서 새로운 것을 일단 공부하고 보자고 나서지는 않습니다.

그럼...


궁그미 님이 쓰신 글 :
: Applied Microsoft .NET Framework Programming
:
: 이 책에보면 중간단계의 컴파일과정을 거치는 언어들이 바로 native code를 생성하는 언어보다 더 빠를 수도 있는 이유를 몇가지 들었는데요. 두가지 정도가 있습니다.
:
: 첫번째로 현재 프로그램이 수행되는 CPU를 인식해서 해당 CPU에 가장 최적화된 native code를 실행시간에 만들 수 있라는 것입니다. 같은 인텔 CPU라도 기종에 따라 좀 더 최적화된 코드를 만들 수 있다고 하네요.
: 두번째는 해석이 잘 안되서..ㅡㅡ;;
:
: The CLR could profile the code's execution and recompile the IL into native code while the application runs. The recomplied code could be reorganized to reduce incorrect branch redictions depending on the observed executed patterns.
:
: 즉, 클라이언트의 OS에 맞추어서 컴파일된는 정도를 넘어서 CPU에 맞추어진 코드를 생산할 수 있다면 C++보다 더 빨라질수도 있다라는 얘기같습니다.
:
: 질문
: 1. 위 내용에 대해 어떻게 생각하세요? (그럴리가 없다든지..^^;;)
: 2. 보통 C++가 C#이나 자바보다 우월한 점이 속도라고 알고 있습니다. 그리고 low level의 메모리 핸들링과 Generic Programming.. 이정도 생각이 나는데요. 어제 기사를 읽으니까 미국의 대학들이 필수프로그래밍 언어를 C++에서 자바로 변경하고 있다고 하네요. (MIT도 있던데요.)
: C++만이 가능한 다른 언어가 절대 넘볼수 없는 그런 영역이 있을까요? C++로 윈도애플리케이션 개발하는 것은 이제 점점 없어지지 않을까요? 어려운 C++ 공부하면서 자바나 C#도 할 수 있는 그런거 만드는 것 보다 C++만이 가능한 그런 영역을 집중적으로 파고 싶습니다. (low level 영역은 제외하구요. 하드웨어는 넘 어려워서..^^;;)