fender
14k
2016-03-31 08:51:31
37
23784

데스크탑 자바가 몰락한 이야기


데스크탑 환경에서 자바를 잘 쓰지 않는 이유를 묻는 질문글에 대한 답글을 쓰다보니 옛날 생각이 나서 이야기가 길어지는 것 같아서 아예 별도의 글로 정리해봅니다.

처음 자바가 등장했을 때는 지금보다 훨씬 무게축이 클라이언트로 쏠려있었습니다. 그래서 많은 사람들이 앞으로 브라우저 플러그인이나 데스크탑 응용프로그램도 모두 자바로 개발하는 시대가 될 것을 예측하기도 했습니다.

문제는 당시 자바의 GUI 툴킷이었던 AWT의 기능이 무척이나 제한적이었다는 것인데(심지어 트리나 툴바 조차 없습니다), 아마도 크로스 플랫폼적 특성을 지나치게 강조한 나머지 지원하는 모든 데스크탑 환경에 공통적인 위젯들만 구현하다보니 그렇게 된게 아닌가 하는 추측이 듭니다.

이후 이런 문제를 깨닫고 완전히 극단적으로 접근을 바꾸게 되는데, 즉 네이티브 환경의 위젯의 최대 공약수를 뽑기보단 아예 네이티브에서 완전히 독립된 '경량' 그래픽 툴킷을 만들겠다는 것이고, 그렇게 탄생한 것이 자바 1.2의 스윙(Swing)입니다(정확하게는 넷스케이프의 그래픽 라이브러리가 정식 API가 된 것입니다).

이 당시까지만 해도 아직 개발자들은 데스크탑 환경에서 자바의 미래를 밝게 생각하고 있었습니다. 당시에 널리 사용되던 포르테(넷빈즈의 전신), 비주얼에이지, 제이빌더 등의 IDE에선 모두 스윙 기반 위지윅 디자이너를 핵심 기능으로 자랑했고, 지금은 엉뚱하게 EJB로 이름만 남은 자바빈즈(JavaBeans) 스펙 같은 것도 그런 분위기를 반영한 결과였습니다.

문제는 이렇게 탄생한 스윙에도 여러 제약사항이 있었다는 건데, 무엇보다 자바의 특성상 네이티브한 데스크탑의 기능을 제대로 활용하기 어려웠다는 점입니다. 예컨대 브라우저를 임베드한다거나 작업 표시줄로 최소화 한다던가하는 식의 기능을 구현하기 어려웠고, 실제 네이티브 위젯을 사용하던 AWT와 달리 스윙에선 모든 것이 그림에 불과하기 때문에, 파일 대화창에서 아이콘이 표시되지 않는다거나 끌어놓기 동작이 일반 네이티브 프로그램들 처럼 동작하지 않는 등 다양한 제약사항이 있었습니다.

또 하나의 문제는 스윙이 당시 기준으로도 꽤나 '못생긴' 그래픽 툴킷이었다는 것인데 - 윈도우즈95 시절에 그와 비교해서 못생겼다는 건 음미할 필요가 있습니다 - 개인적인 생각으로 이건 당시 자바 플랫폼을 소유하고 있던 썬 마이크로시스템즈의 성격이 한몫을 했다고 봅니다.


[스윙의 기본 테마였던 '메탈' 룩앤필(LookAndFeel)]

지금의 오라클이 '악의 축'이라면, 당시의 썬은 대체로 '대책없는 공돌이 집단'에 가까웠습니다. 아마도 워크스테이션으로 윈도우즈가 아닌 자사의 솔라리스의 CDE 데스크탑(대충 이렇게 생겼습니다)을 쓰면서 눈이 낮아지다 보니 스윙 정도의 테마가 꽤 예쁘게 보였던 모양입니다.

썬의 공돌이적 발상은 여기서 그치지 않는데, 단적으로 자바의 기본 글꼴을 바꾸려면 어떤 작업을 해야하는 지 생각해보면 이는 단적으로 드러납니다. 일반 사용자라면 제어판 같은데서 글꼴을 변경한다거나 그런 생각을 하겠지만, 우리의 대책없는 공돌이 개발자들은 텍스트 파일을 열어서 로우레벨의 글꼴 정보를 직접 편집하는 방법을 제공했습니다(궁금하시면 JRE의 fontconfig.properties.* 파일을 열어보시면 됩니다).

하다못해 완성된 프로그램을 실행하는 방법조차 썬의 발상은 공돌이스러웠습니다. 일반 사용자라면 예컨대 윈도우즈에선 아이콘이 예쁘게 표시된 exe 파일을 두 번 클릭하면 프로그램이 실행되는 걸 기대했겠지만, 우리의 공돌이 개발자들께선 "그냥 터미널에서 java -jar program.jar 치면 되잖아?"하고 일갈하셨습니다. 나중엔 javaw라는 네이티브 런쳐가 추가되고, jar 파일도 두 번 클릭하면 바로 실행되는 정도로 바뀌긴 했습니다. 하지만, 실행 파일의 아이콘도 못바꾸고 클릭해도 실행이 되는지 마는지 피드백도 없다가 한 참 후에 창이 뜨는 식의 총체적 난국이었던 걸로 기억합니다.

또한 당시만 해도 컴퓨터의 사양도 좋지 못했고 자바 자체도 지금처럼 최적화가 잘되어 있는 상황이 아니었습니다. 그런 마당에 프로그램 이전에 JVM을 구동하는 방식이나, 네이티브 위젯을 배제하고 모든 것을 일일이 화면에 그리는 식의 스윙의 특성은 자바 GUI 프로그램의 성능에 대한 인식을 상당히 부정적으로 각인시켰습니다.

더구나 당시엔 광랜을 쓰던 시절도 아니었는데 자바로된 프로그램을 구동하려면 무조건 수십 메가바이트 - 지금의 JRE 크기는 이런 문제 해결을 위한 눈물겨운 노력의 결과입니다. 그런데 막상 해결해놓으니 데스크탑 자바는 망해버렸고 이젠 수십메가 쯤은 순식간에 받는다는 게 문제이지만 - 의 런타임을 다운로드 받아야한다는 것도 문제를 더욱 어렵게 만들었습니다.

사실 썬의 입장에서는 이 모든 문제를 한 방에 해결할 수 있는 방법이 있었습니다. 바로 마이크로소프트와 협력하는 것이었는데, 마이크로소프트 역시 초창기에는 자바의 미래를 밝게 생각하고 자체적인 런타임과 개발도구까지 갖추고 있는 상황이었기 때문입니다.

지금은 기억하는 사람조차 별로 없는 비운의 이름이 되었지만, 비주얼스튜디오 6 시절에는 비주얼 J++이라는 제품이 있었습니다. 서버를 주로 팔던 공돌이들이 모인 회사인 썬과는 달리 데스크탑 일반 사용자를 상대하던 마이크로소프트는 적어도 사용성 면에서 만큼은 썬보다는 훨씬 더 좋은 안목을 지니고 있었습니다.

이는 마이크로소프트의 자체 자바 구현인 MSJVM과 비주얼 J++에서도 드러나는데, 쓸만한 위젯도 없는 AWT이나 위젯들이 어마무시하게 못생긴 스윙과는 달리, J++을 사용하면 위지위그 방식으로 네이티브 윈도우즈 위젯을 사용하는 자바 프로그램을 쉽게 만들 수 있었습니다.

또한 JNI보다 훨씬 간단한 방식으로 네이티브 호출을 할 수 있었고, 패키징 측면에서도 J++을 통해 자바 프로그램을 exe 파일로 빌드해서 설치프로그램까지 만드는 기능을 제공했습니다.

결정적으로, MSJVM은 윈도우즈에 기본 탑재되어있었기 때문에 일반 사용자가 자바 프로그램을 사용하려고 수십 메가바이트의 자바 런타임을 별도로 다운 받을 필요도 없었습니다.

썬 마이크로시스템 입장에서 최선의 선택은 마이크로소프트와 협력하거나 최소한 이를 모방해서 윈도우즈 상에서 자바 프로그램의 사용성을 개선하는 것이었겠습니다만, 역시 대책없는 공돌이 집단인 썬은 이번에도 거하게 삽질을 하고 맙니다.

즉, 마이크로소프트가 자바 API의 일부만 구현하는 방식을 문제삼아 소송을 걸어 더 이상 MSJVM을 개발할 수 없게 만들어 버린 것입니다.

물론 자바 환경이라면 어디서나 동일한 API를 사용할 수 있다는 이상을 지키는 것은 좋은 일이지만, 이는 얼마든지 소송이 아닌 다른 방식으로도 풀 수 있는 문제였다고 봅니다. 하지만 썬은 완전히 마이크로소프트가 자바에서 손을 떼어 버리게 만듦으로서 이제 마이크로소프트와 자바는 협력이 아닌 경쟁 상대가 되어버리고 맙니다.

여담입니다만, 만일 이 소송이 없었다면 마이크로소프트는 여전히 MSJVM과 J++의 조합을 밀어부쳤을테고, 사실상 자바의 개념을 대거 차용해서 만든 닷넷(.NET)과 C#은 탄생하지 않았을 것입니다.

그리고 닷넷에서 자동화된 메모리 관리 등 자바의 특성을 고스란히 가져간 것을 감안하면, 아마도 소송이 없었다면 비주얼 스튜디오 제품군에서 J++의 입지는 VB나 VC++을 앞서거나 최소한 필적할 수준으로 자리잡았을 것입니다. 그랬더라면 아마도 지금 쯤 자바가 데스크탑에서 성공한 사례를 찾는 것보단 자바 기반이 아닌 프로그램중 성공 사례를 찾는 게 더 빨랐을지도 모르겠습니다.

어쨌건 주사위는 던져졌고, 이제 남은 것은 썬을 비롯한 자바진영의 몇몇 회사들이 네이티브 데스크탑 응용프로그램을 대체할만한 무엇을 만들 수 있느냐는 문제가 되었습니다.

많은 회사들과 오픈소스 진영은 어떻게든 데스크탑 자바를 살려보려고 상당한 노력을 쏟아부었습니다. 패키징 문제를 해결하기 위해 자바 프로그램에 대한 exe 래퍼를 만드는 프로젝트도 탄생했고, 자바를 직접 지원하는 설치 프로그램 빌더 제품도 등장했습니다. 또한 스윙 프로그램의 외관을 개선하기 위해 여러 테마(LookAndFeel)들이 등장하기도 했습니다.

스프레드 시트 같은 상용 스윙 컴포넌트를 판매하기도 했고, 네이티브 브라우저를 임베드하거나 반대로 완전한 자체 구현 브라우저를 지원하는 상용 제품이 등장하기도 했습니다.

하지만 이러한 노력들이 앞서 언급한 문제를 모두 해소하진 못했고, 그 와중에 브라우저 플러그인 분야에서는 애플릿이 플래쉬에 빠른 속도로 밀려나고 데스크탑 분야에서도 전통적인 네이티브 프로그램의 입지를 잠식하는 데 실패했습니다.

스윙의 사용성이 얼마나 조악한지에 대한 반증은 이클립스의 기반이 되는 SWT 툴킷의 '성공'에서 찾을 수 있습니다. SWT는 앞서 말한 AWT와 스윙의 태생적인 한계를 극복하기 위한 일종의 절충점을 모색하는 과정에서 탄생했습니다.

즉, AWT와 마찬가지로 네이티브 위젯이 있을 경우엔 최대한 네이티브 위젯을 사용하되, 그렇지 않은 경우 AWT처럼 나몰라라하는 대신 스윙과 마찬가지로 그려서라도 다양한 위젯을 구현한다는 식의 접근이었습니다.

덕분에 SWT를 기반으로한 응용프로그램은 자바 GUI 특유의 못생기고 반응이 느린 단점을 극복할 수 있었고, 이는 프리웨어 데스크탑 자바 응용프로그램의 몇 안되는 성공 사례 대부분이 SWT 기반이라는 사실에서 그 중요도를 짐작할 수 있습니다.

만일 이 시점에서라도 썬이 MSJVM의 교훈을 바탕으로 SWT를 만든 IBM과 협력해서 AWT를 SWT로 대체하거나 최소한 공식 GUI로 채택해서 개선하는 선택을 했다면 어쩌면 데스크탑 자바의 몰락을 막을 수 있었을지 모르겠습니다.

하지만 역시 대책없는 우리의 공돌이들은 기대를 져버리지 않고 SWT에 대해선 철저하게 무시하는 전략으로 일관했고, 나름대로 모양을 '대폭' 개선해보겠다고 만든 결과가 이렇습니다:

[자바 1.5의 기본 테마인 '오션' 룩앤필]

하지만 윈도우즈XP와 OSX의 시대에 저 정도 개선이 딱히 '자바는 못생겼다'는 인식을 바꿀 수준도 아니었고, 무엇보다 패키징이나 체감 성능, 네이티브 연동의 어려움 등의 문제는 여전히 남아있는 상태였습니다.

이 시점부터 특히, 데스크탑 리눅스의 발전과 맞물려 wxWidgets, Qt 등 세련된 크로스플랫폼 툴킷의 입지가 넓어지는 것과 맞물려, 이제 데스크탑 자바는 네이티브 응용프로그램 뿐 아니라 크로스 플랫폼 응용프로그램 개발에서조차 더 이상 최선의 선택이라고 하기 어려운 처지가 되었습니다.

그 와중에 윈도우즈 응용프로그램 개발은 자바를 대체하려고 만든 닷넷/C#이 완벽하게 표준으로 자리를 잡았으며, OSX에서 조차 그 동안 기본탑재되었던 자바가 퇴출되면서 데스크탑 자바의 몰락은 점점 부정하기 힘든 현실이 되어가고 있었습니다.

오라클에 인수되기 직전인 자바 1.6 시절에 와서야 네이티브 연동을 개선하기 위한 기존 JDIC 프로젝트의 기능을 반영하고, 님버스(Nimbus)라는 제법 그럴듯한 테마를 제공하는 등 최후의 노력을 쏟아부었지만 대세를 돌리기엔 역부족이었습니다.


[자바 1.6에 탑재된 님버스 테마]

썬의 피할 수 없는 '뒷북' 감각은 여기서도 여실히 드러나는데, 어도비 에어와 실버라이트로 대변되는 리치 클라이언트의 막차를 타보겠다고 2000년 후반부터 JavaFX에 힘을 쏟지만, 대세는 곧 HTML5로 넘어가고 JavaFX는 원래의 원대한 계획인 리치 클라이언트 시장에서 입지 확보에는 완벽하게 실패하는 대신 기존 스윙 API의 괜찮은 대안이 되는 정도로 만족해야했습니다.

썬이 오라클에 인수된 시점 이후부터는 자바는 데스크탑 뿐 아니라 서버에서의 입지조차 장담할 수 없는 상태가 되었기 때문에 (이전 글 참조), 오라클은 더 이상 돈도 되지 않는 데스크탑 자바에 많은 투자를 할 이유가 없게 되었습니다.

또한 연이은 데스크탑 관련 정책의 실패는 시장에서 양질의 자바 GUI 컴포넌트나 경험 많은 클라이언트 자바 개발자의 공급 감소를 불러왔고, 이는 회사나 일반 개발자들이 데스크탑 개발을 위해 자바를 선택할 이유를 찾지 못하도록 만들었습니다.

지금 시점에서는 자바로 데스크탑 프로그램을 만든다면 못만들 이유는 없는 정도의 상황이라고 할 수 있습니다. 하지만 여전히 과거 이런 저런 문제들의 잔재는 여러 군데 남아있기 때문에 개발부터 배포까지 어느 정도 노하우가 필요하지만, 시장이 죽었기 때문에 그런 노하우를 가진 개발자를 수급하기도 어렵고 자료를 찾기도 쉽지 않습니다.

그리고 무엇보다 이미 데스크탑 개발에 대해선 자바보다 훨씬 나은 대안들이 존재하기 때문에, 이젠 자바로 데스크탑 개발을 못할 것까진 없지만 굳이 불편함을 감수하고 선택할 이유도 없는 상황입니다.

한 동안 이래저래 데스크탑 자바 개발을 해본 입장에서 이전 생각이 나서 쓰다보니 너무 글이 길어졌네요. 아무튼 이 것이 제가 경험한 데스크탑 시장에서 자바가 몰락한 이유와 그 과정입니다.

36
11
  • 댓글 37

  • 멍태희
    512
    2016-03-31 09:22:47

    자바에 관한 이런 역사를 상식 수준으로 알 뿐만 아니라


    이렇게 장문의 글로 작성할 정도가 되려면 어떻게 해야해요?


    기술 외적인 이런 부분이 좀 부러워요



    0
  • fender
    14k
    2016-03-31 09:28:21

    멍태희 //

    오래 살면 됩니다 ㅎㅎ; (이제 딱 마흔 찍고 이런 이야기하기 민망합니다만).

    저로서는 저게 그냥 '상식'이 아니었던 것이, 1.1시절부터 자바를 사용하면서 데스크탑 개발을 할 때마다 어떻게든 그럴 듯한 결과를 만들기위해 검색을 하면서 삽질했던 기억이거든요...

    지금 스프링이나 마이바티스를 사용하면서 개발하시는 분들이 경력이 쌓이고 누군가 스프링 3.x나 아이바티스 시절이 어땠는지 묻는다면 아마도 비슷하게 장문으로 답변 다실 분이 계실 걸로 예상합니다.

    1
  • 리척
    809
    2016-03-31 09:29:23

    Visual J++ 오랜만에 듣네요. ^^

    당시 Java수업 프로젝트 제출할때 절반은 Visual J++로 구현했었던 것 같네요;;

    터보 파스칼과 델파이 개발을 했던 아네르스 하일스베르가 만들었다고 해서 당시에도 꽤나 기대를 많이 했었지만, 결국은 C#을 만들게 되는 중간다리 역할을 하게 되었죠.. 당시에는 특히나 주위의 델피언들이 배신감을 느끼면서도 많이들 좋아했었던 것 같습니다;;;

    자바로 데스크탑 UI를 20년 가까이 만들어오면서 느낀건 항상 덜 이쁘고, 기능이 시대에 뒤처진다는 느낌?

    SWT로 옮겼지만, 이건 위젯 커스터마이징을 하려면 플랫폼 디펜던트한 코드를 만들어야해서 이것도 문제..

    JavaFX에서 삽질을 하더니 JavaFX2를 거쳐 JavaFX8은 꽤 괜찮게 만들긴 했지만 너무 늦게 나왔다고 해야할까요. Electron 같은걸 사용해서 이젠 웹 브라우저에서만 쓰는 자바스크립트가 데스크탑으로도 진출했으니, JavaFX가 얘네들이랑 경쟁하기에는 힘들어 보이지 않나 싶습니다.

    0
  • h2s3426
    287
    2016-03-31 09:32:57

    //fender님 잘읽었습니다.

    읽다보니 JAVA 태생과 변천과정이 궁금해지네요..

    아침에 여유가 있어 읽어보니 이해도 되고 재밌네요.^^

    0
  • dkb
    1k
    2016-03-31 09:37:34
    대책없는 공돌이 집단 썬 왠지 호감이 갑니다.
    2
  • 하마
    6k
    2016-03-31 10:06:43

    출근 길에 내릴역 놓칠 정도로 재밌게 잘 읽었습니다.

    근데 지금도 크로스플랫폼 데스크탑 솔루션 대안은 별로 없지 않습니까?

    저 혼자 개발하면  C++ 경력이 길어서 QT 를 선택할수도 있겠지만 팀원들이 자바경험이 있고,

    C++ 로만 제공되는 컴포넌트를 꼭 써야 하는 경우 아니라면 , 자바가 선택 1순위 일거  같네요. :-)  


    p.s 닷넷 프레임웍이 크로스플랫폼으로 제대로 정착할 때야  우선순위가 달라질거 같습니다.  

    1
  • bongbongco
    10
    2016-03-31 10:10:54

    덕분에 데스크탑 자바의 역사에 대해 알게 되었어요! 좋은 글 잘 읽고 갑니다. :-)


    0
  • 장지락
    668
    2016-03-31 10:18:10

    저는 Java v1.0~1.5 까지만 하고, 스윙써서 몇 가지의 데스크탑 프로그래밍 해본 경험이 다 입니다만, 당시 제가 느끼기에는 정말 문제는 프로그램 덩치가 조금만 커지면 엄청 느려져서 사용성이 0점에 가까워 개발을 포기하고 VC++로 다시 개발했던 기억이 있네요. ㅠ

    0
  • 진C
    1k
    2016-03-31 10:26:29

    fender 님 // 스크롤 보고 허걱 했는데 어느새 몰입해서 한 번에 쭉 읽어버렸네요 ㅎㅎ

    좋은 글 고맙습니다! 행복한 하루 되세요! ^-^/

    0
  • fender
    14k
    2016-03-31 10:51:39

    덧글 주신 분들 모두 감사드립니다 ^^

    하마 //

    네, 그래서 본문에 적은 대로 '못할 것은 없지만 할 이유도 없는'그런 상황이 된 듯하고, 팀원이 모두 자바 개발자로 구성되어있다면 딱히 자바로 안할 이유가 없는 건 맞습니다.

    다만 생각해봐야할 것이, 현재 데스크탑 자바 시장(그런게 아직 있다면...)의 다수가 거의 자바 솔루션의 클라이언트 콘솔이나 자바 기반 솔루션 업체의 주로 특화된 일부 제품인 걸 감안하면, 자바 개발 전문 회사라거나 하는 경우가 아니면 크로스플랫폼 분야에서도 자바는 첫번째 고려사항이 아닌 것은 분명하지 않나 싶습니다.

    실제로 최종 사용자 대상 프로그램 중 크로스플랫폼 제품은 SWT기반 `Vuze`와 같은 몇 안되는 예외를 제외하고는 거의 wxWidgets나 Qt, 혹은 Gtk 기반이 대세이고, 아마도 앞으로는 위에서도 언급된 자바스크립트 기반이 입지를 넓혀가지 않을까 생각합니다.

    0
  • 하마
    6k
    2016-03-31 11:49:28

     fender //

    크로스플랫폼 데스크탑 솔루션에서 자바계열보다 거의  wxWidgets, Qt, 혹은 Gtk 로 쓴다는 근거가 있는지요?

    15년 정도 개인경험상으론 거의 비슷 비슷하게 쓰이는거 같았는데 말입니다. (의료쪽으론 확실히 QT 같고 )  


    자바를 선택하는것도 그냥 일반적인 선택지중 하나라 봅니다.  나쁠것도 좋을것도 없는...

    C ==> GTK

    C++ ===> QT

    Python ===> pyQT / pyGTK

    Java ===> SWT / Swing 


    그리고 굳이 자바 데스크탑 솔루션이 몰락한게 아니라, 그냥 데스크탑 솔루션이 몰락한거라 봐야겠지요. 
    애초에 자바 데스크탑 솔루션이 대세였던적도 없으니 말입니다. 

    0
  • fender
    14k
    2016-03-31 12:12:54

    하마 //

    최종 사용자 대상이라고 제한한 걸 감안하시기 바랍니다. 물론 일반 사용자 대상이 아닌 크로스플랫폼 데스크탑 시장이래봐야 서버 제품의 관리 화면 등이 대부분이긴 합니다만...

    자바의 경우는 기억하는 것이, 이전엔 저도 나름대로 데스크탑 자바에 대한 애착이 있었기에 일반 사용자가 접할 수 있는 사용 사례는 적극적으로 찾아보기도 했습니다.

    그래서 떠오르는 이름들이 Vuze(구 Azureus), RSS Owl, Sancho, LimeWire 같은 사례들이고 심지어 IL-2 같은 게임이 어디에 쓰는 지는 몰라도 자바 런타임을 번들하더라 같은 트리비아도 기억하고 있습니다.

    그 뒤로 수 년이 지났기에 그 이후에 또 어떤 자바 프로그램이 일반 사용자 사이에서 인기였는지는 모르겠습니다. 하지만, 솔직히 추세를 감안하면 그 이전보다 더 활발하게 개발이 이루어져왔을 것 같지도 않습니다.

    원하시면 하마님께서 반례를 들어주셔도 됩니다. 물론 잡다한 유틸이야 깃헙이나 구 소스포지를 뒤지면 많이 나오긴 합니다만, 일반 데스크탑 사용자가 알법한 인지도 있는 제품들은 위의 목록 정도가 거의 다일 것입니다.

    반면 Qt로 된 예를 들라고 하면 스포티파이나 텔레그램 같은 급의 예를 꽤 많이 들 수 있고 wxWidgets도 적어도 RSS Owl 급의 프로그램은 수십 단위로 나열할 수 있습니다(예 - FileZilla, TortoiseSVN, 등...)

    Qt나 Gtk의 경우 이들 툴킷을 우선 사용하는 데스크탑 환경이 존재한다는 점도 무시할 수 없습니다. 반면에 자바의 경우 어떠한 실용적 데스크탑 환경에서도 응용프로그램 개발에 있어서 첫번째 선택이 아니라는 점도 아마 이런 차이에 영향을 주었을 것 같습니다.

    이런 상황에도 불구하고 제가 관심을 접었던 지난 몇 년 간 자바 데스크탑 시장이 약진을 했다면야 저도 반갑게 받아들이겠습니다만, 그러기 위해선 제가 일반 사용자 대상크로스 플랫폼 환경에서 자바가 많이 쓰이지 않는 근거를 드는 것보단 하마님이 보통 사람들도 들어서 알법한 자바 데스크탑 프로그램들을 열거해주시는 게 빠르지 않을까 싶습니다.

    0
  • 리척
    809
    2016-03-31 13:23:27

    fender

    사실 사용하는 분야 나름이긴 한데, 개발자 대상 애플리케이션이라면 메이저급에서는 Java로 개발된 게 꽤 있습니다.

    IntelliJ IDEA, WebStorm 시리즈, Eclipse, NetBeans 등과 같은 IDE나 OpenOffice 등과 같은 오피스류는 모두 Java로 개발되어 있습니다.. 사실 이런쪽은 크로스플랫폼 플러그인이나 확장성을 고려하면 대부분 Java외에는 대안이 없어 보이긴 합니다.

    제가 보기에 그외에 자잘한 오픈소스 프로그램들은 fender님 말씀대로 Qt, Gtk로 된 게 대다수인 것 같습니다.

    요즘은 Atom 에디터 이후에 JavaScript 로 된 것들이 많이 보이는 것 같습니다. Visual Studio Code, Slack 등등...


    0
  • fender
    14k
    2016-03-31 13:28:19

    리척 //

    네, 개발자 대상이라면 저도 당장 사용하는 인텔리제이나 유어킷등 여러 예를 들 수 있을 것 같습니다. 아무래도 개발자들은 자신이 가장 잘하는 언어를 쓰고 싶어하고 자바 시장 자체는 넓고 일반 사용자 대상이 아니면 초기 실행 속도 같은 게 크게 문제가 되지 않는 것도 영향이 있을 것 같습니다.

    참고로 말씀하신 예시 중에 오픈오피스(또는 LibreOffice)는 자바 기반이 아닙니다. 전 처음 스타오피스 시절에 보고 스윙 룩앤필과 똑같이 생겨서 당연히 자바로 만들었을거라 생각했는데 아니어서 의아했던 기억이 있습니다. 어쩌면 정말 자바 기반인 씽크프리 오피스와 착각하셨는지도 모르겠네요.

    정확하게는 데이터베이스 연동이나 일부 마법사 정도에서 부분적으로 사용하고 자바 관련 부분은 선택사항으로 설치하도록 되어있습니다.

    0
  • 리척
    809
    2016-03-31 13:36:57

    fender //

    LibreOffice 설치할때 JRE 포함버전을 제공하길래 Java인줄 알았는데 지금까지 잘못 알고 있었네요;;;

    0
  • nova23
    118
    2016-03-31 15:42:16

    좋은 글 잘 읽었습니다.

    정말 호랑이 담배피던 시절 fender님이랑 J++로 개발하던 생각나네요

    fender님 글은 계속 잘읽고 있었는데.. 오늘 글은 옛날 생각이 많이 나서 코멘트 달아봅니다.



    1
  • fender
    14k
    2016-03-31 16:20:52

    nova23 //

    헉...; 제가 J++ 쓰던 시절이면 신입 때였을 것 같은데 왠지 첫 직장에 계셨던 선배님이나 동료분 아니신가 싶네요. 잘계신지 궁금하고 글로라도 소식 듣게되니 반갑네요 ^^

    1
  • zepinos
    18k
    2016-03-31 16:42:37

    개인적으로 옵저버 띄울 겸 한 댓글 적고 가봅니다. ^^;;;


    사실, 개인적으로 봤을 때 Java 는 Web 이라는 놈이 안나왔으면 진작에 인기 잃고 사망선고 받고 지금쯤이면 호흡기 뗀 언어였을지도 모릅니다.

    그런데, Web 의 시대가 오고, 제공자(=서버) 입장에서 업데이트를 할 수 있고, 이쁘고(단점 중의 단점인 Look&Feel 해소), 인터프리터 언어가 아니고(초기 JSP 최고의 장점으로 속도, 그것도 컴파일 언어이기에 가지는 속도)...그런 여러가지 이유 때문에 AWT 의 단점은 단점대로 덮고, 기존 고급언어의 강자들 중 시장 선점을 먼저 한게 크지 않나 싶습니다(C 의 C CGI 등은 너무 불편해서). Web 이라는 것 자체가 웹브라우저를 통해서 일종의 OS-Free 한 환경을 제공하기 때문이기도 하구요.


    그런 의미에서, OS 의존적인 Client Program 제작 언어로는 오래전에 사형선고 비스무리한 것을 받은 언어라고 생각합니다. SWT 나 JFace 같은 것들이 있다고 해도...느린건 느린거거든요. 그리고 Sun 이나 Oracle 이 사용자 친화적인 제품을 만드는 회사가 아니라는 점도 분명 한 몫하구요(fender 님께서 본문에서 지적하셨듯이).


    또한, 실제 프로그램을 만들 때 가장 중요한 요소 중 하나가 그 언어의 생태계(=라이브러리 Pool)라고 봤을 때...Java 로 Client 을 만들기위한 다양한 물건들이 있나 잘 생각해보면 데스크탑 자바에 대한 답이 나오죠. 사실 Visual J++ 의 몰락의 이유 중 빠진 하나는, 본문에 언급이 안되어있지만...어쨌든 기존 JVM 와 호환이 전혀 되지 않았다는 점도 무시할 수 없었을 겁니다. 가뜩이나 작은 생태계, 새로 꾸려 나간다는게...아무리 MS 가 잘났어도 Java 시장이 너무나 컸다면 어떻게 해서든 끈을 놓지도 않았을 것이었을껀데, 자사의 VC++ 6.0 과도 비교할 수 없을 정도로 적은 시장과 생태계를 가진 언어를...굳이 계속 물고 늘어질 리가...그냥 C# 만드는게 나았죠.


    저도 주로 웹개발만 하고, 아니면 프리젠테이션 영역이 없는 프로그램만 주로 만들지만, 윈도우즈에서 돌아가는 앱(GUI 가 필요한)을 만들라고 한다면 Java 안쓸 것 같네요.

    0
  • moonv11
    143
    2016-03-31 16:51:33

    좋은 글 잘 읽었습니다.

    0
  • fender
    14k
    2016-03-31 16:55:24

    zepinos //

    전체적으로 동의하지만 VJ++에 대한 부분은 제가 기억하는 내용과 조금 차이가 있는 것 같습니다. 제가 기억하기로 MSJVM은 자바 1.x와 대체로 호환이 되었고 지금의 안드로이드 처럼 일부 패키지의 구현이 빠져있거나 한 정도의 차이였습니다.

    썬은 그렇듯 불완전한 구현을 '자바'라고 부르는 것을 문제삼은 것이고, MSJVM이 말씀하신 것처럼 기존 JVM과 전혀 호환되지 않는 제품은 아니었다고 기억합니다.

    또한 생태계를 이야기한다면, MSJVM/J++은 당연히 다른 비주얼 스튜디오 제품군과 마찬가지로 액티브엑스 컴포넌트를 지원했습니다. 즉, 필요하다면 예컨대 VC++로 제작한 액티브엑스 컨트롤을 구매해서 J++에서 사용할 수 있다는 것인데 이는 VB의 경우와 전혀 다를 바가 없습니다.

    그런 이유로 전 썬의 소송이 없었다면 지금의 C#의 위치를 J++이 차지했을 가능성이 꽤 높다고 생각하고 있습니다.

    0
  • zepinos
    18k
    2016-03-31 17:00:54

    fender 님 // 제 기억이 틀렸을 수도 있습니다. 하지만 제 기억이 맞다면, VJ++ 로 만들어진 놈은 JVM 에서는 안돌아가고(=Windows 에서만 돌아가고) VJ++ 이외의 것에선 참조도 못하고...전체적인 Java 생태계 확장에는 도움이 안되는 놈이었죠(호환이 안된다는게 Java<->VJ++ 이 아니라 Java<-VJ++ 이 안된다는 의미였습니다). 제가 Sun 의 임원이라도 Java 생태계를 늘려주기는 커녕, 자기에게서 과실만 따다 먹는 애들은...보기 싫었을 것 같네요.

    그런 의미에서 지금의 C# 의 위치는 VJ++ 이 가져갔다기 보다는 더 커졌을지도 모르는 일이긴 하지만, Java 의 자율성을 해치는 것에 있어서는 Oracle 이 Sun 을 인수한 것 이상의 영향을 미쳤으리라...개인적으로 추측해봅니다.

    0
  • fender
    14k
    2016-03-31 17:12:29

    zepinos //

    아, 그런 부분이라면 동의합니다. 말씀처럼 MS 고유의 확장기능을 사용한 프로그램은 다른 플랫폼에서 구동되지 않습니다.

    아마도 마이크로소프트의 의도도 그런 방식으로 독점을 지키려는 것이었겠죠. 썬의 입장에서 그런 행동이 좋게 보였을리가 없고, 법원에서도 결국 원하는 판결을 얻어낸 이상 주장의 정당성도 썬 쪽에 있었다는 데는 이견이 없습니다.

    단지, 썬이 아닌 마이크로소프트 입장에서 VC보다 생태계가 훨씬 적은 자바(또는 J++)를 계속 밀어줄리 없다는 말씀에 대해서 이견이 있어 부연했을 따름입니다.

    왜냐하면 마이크로소프트 입장에서 중요한 생태계는 J++을 중심으로한 컴포넌트 시장이지 크로스플랫폼 자바를 중심으로한 시장은 아니기 때문에, J++로 전자의 시장에 존재하는 수 많은 상용 액티브엑스 컴포넌트를 활용하는 데 문제가 없는 한 마이크로소프트 입장에선 싫어할 이유가 없다는 뜻이었습니다.

    0
  • zepinos
    18k
    2016-03-31 17:26:57

    fender 님 //

    왜냐하면 마 이크로소프트 입장에서 중요한 생태계는 J++을 중심으로한 컴포넌트 시장이지 크로스플랫폼 자바를 중심으로한 시장은 아니기 때문에, J++로 전자의 시장에 존재하는 수 많은 상용 액티브엑스 컴포넌트를 활용하는 데 문제가 없는 한 마이크로소프트 입장에선 싫어할 이유가 없다는 뜻이었습니다.


    동의합니다.

    1
  • daejoon
    219
    2016-04-01 09:20:03

    제가 지금 JavaFX로 프로젝트를 하고 있습니다.

    MFC, Winform, JavaFX셋중에 JavaFX가 제일 편했습니다.

    사실근래에 사용해서 그런것도 있고 JavaFX에 SpringBoot를 붙여서 사용해서 인지 

    나름 편하게 잘 사용하고 있습니다.

    분명 자바의 데스크탑의 미래가 밝진 않은데 사용은

    꾸준히 될것 같다는 생각이 듭니다.

    아직은 자바의 생태계를 버리기 힘든것 같습니다.


    0
  • 영호충
    77
    2016-04-01 17:41:22

    재밌습니다..

    과거 기억도 새록새록 나네요

    참고로.. 저는  SI하면서 데스크탑 어플 만들때, 자바를 쓴적은 없는거 같습니다.

    대부분 MFC 아니면 c# 을  썼죠.

    꽤 오래전에는 단순 업무용으로 VB를 많이 쓰던 시절도 있었습니다....

    0
  • narise
    2k
    2016-04-01 20:25:23

    썬은 자바 표준만 스팩만 정하고, java 구현은 제약이 없어서,openJDK나 JRocket, IBM java라던지 나왔던걸로압니다.


    스팩이 전부인 썬과 상의없이 api 맘대로 구현하고,  자바다라고 한게 문제겠죠.


    데탑어플쪽은 자바가 Qt이상 속도 편리성없으면, 힘들 것같습니다. 

    게다가 아직도 메모리를 제대로 관리못하니, 빅데이터 딥러닝 관련, 앞으로 서버측도 힘들 거라 예상합니다.

    0
  • javaing
    1k
    2016-04-01 22:01:52

    디테일한 설명 감사드립니다. 정말 많은걸 배우고 가네요. 진짜 다른분들의 경험/지식/경력에 비하면 전 정말 보잘것없다는걸 다시 한번 느낍니다. 어서 빨리 다음 수준으로 올라가고 싶네요!

    0
  • 앙앙이
    3k
    2016-04-03 16:06:55

    말씀하시는 내용 모두 공감이 갑니다.

    특히 폰트 부분은 아련한 아픔이 떠 오르네요.

    학부시절 jdk 1.1 1.2 로 수업에 발표할 프로젝트가 있어 스윙으로 프로그래밍했는데

    리눅스에서 한글 잘 나오는데 유독 풍선 도움말 한글이 깨져 나와서 어찌나 당황했는지 모르겠네요.

    지금 개인 자바-프로젝트로 환결 설정과 필요한 유틸을 스윙으로 다시 만들고 있는데요.

    여전히 자바의 폰트는 두렵네요.

    뜨는 속도는 아직도 엄청 느리다는점

    그렇지만 일단 가동되면 그럭저럭 견딜만 한 속도이지만

    cpu, 메모리등이 낮은 컴에서는 많은 인내가 필요할듯합니다.

    그래도 다중 플랫폼 gui 라면 자바는 그래도 매력적인 선택이 아닌가합니다.

    0
  • HighwayStar
    2016-04-04 08:23:44

    유익한 정보 감사합니다 ^^ 왜 자바는 분명 응용프로그램 개발이 가능한데도 자바 개발자 하면 웹인가 했더니.. 이런 이유였군요. 

    0
  • IdwtbaSoldier
    285
    2016-04-04 08:54:12

    본격적인 프로그래밍 공부를 자바로 시작한 신입으로서, 굉장히 재밌는 글이네요 ㅎㅎ. 절반정도 봤는데, 아껴놓고 퇴근길에 봐야겠습니다.

    그런데 한가지 궁금한점이 있는데요, 


    지금의 오라클이 '악의 축'이라면, 당시의 썬은 대체로 '대책없는 공돌이 집단'에 가까웠습니다. 아마도 워크스테이션으로 윈도우즈가 아닌 자사의 솔라리스의 CDE 데스크탑(대충 이렇게  생겼습니다)을 쓰면서 눈이 낮아지다 보니 스윙 정도의 테마가 꽤 예쁘게 보였던 모양입니다.


    여기서, 오라클을 '악의 축' 이라고 하는 이유는 뭔가요..?

    0
  • fender
    14k
    2016-04-04 10:20:48

    IdwtbaSoldier //

    대체로 시장에 대한 독점적 지위를 획득하려는 시도나 오픈소스 진영과의 껄끄러운 관계가 그런 인식에 크게 기여했습니다. 오픈소스가 비즈니스 영역까지 진출하기 이전에는 마이크로소프트 역시 비슷한 공세적인 접근으로 '악의 축'이라는 명성을 얻었지만(본문에 언급된 MSJVM의 사례가 좋은 예가 될 것입니다) 오픈소스가 대세가 된 이후 마이크로소프트는 태도를 바꾸어 친 오픈소스/리눅스 정책을 적극적으로 추진하고 있습니다.


    반면, 오라클의 경우 여러 오픈소스 진영에 적대적인 행보를 이어가고 있는데, 대표적으로는 안드로이드와 관련한 특허권 소송을 예로 들 수 있습니다. 구글은 오픈소스 회사가 아니지만, 안드로이드 자체는 오픈소스로 개발되고 있고 무엇보다 소프트웨어의 특허권(저작권이 아닌)을 공격적으로 사용하는 것은 오픈소스 진영이 매우 강한 반감을 느낄만한 사안입니다.


    또한 MySQL, 오픈오피스, 오픈솔라리스 등 굵직한 오픈소스 프로젝트를 인수한 뒤에 (아마도 고의로) 방치해서 핵심 개발자들이 떠나도록 만든 것도 오라클을 마이크로소프트에 이은 새로운 '악의 축'으로 인식하는 데 일조하지 않았나 생각합니다.

    1
  • 깨구리
    1k
    2016-04-05 00:26:02
    한참 웃다 갑니다 ㅋㅋ 요약하자면 대책없는 공돌이적 미적감각 때문에 외면받게 된 거였군요. 이렇게 오래된게 왜 이렇게 구릴까 생각했는데, 그림이든 음악이든 프로그램이든 역사를 알면 더 재미있는 것 같습니다. 좋은 글 감사합니다.
    0
  • IdwtbaSoldier
    285
    2016-04-05 18:04:02

    오.. 재밌는 역사들이 있었네요.

    오라클이 오픈소스에 적대적이었다는것도 새롭게 알게된 사실ㅎㅎ..

    시간날때마다 이런 재밌는 역사공부도 같이하면 이 분야에 흥미가 더 돋을것같네요.

    감사합니다 ㅎㅎㅎ

    0
  • 바람이될게요
    267
    2016-04-06 14:45:17

     fender님 매번 참 재밌고도 신선한 글 잘보고 있습니다. 감사드립니다 ㅎㅎㅎ;;

    0
  • 리디
    264
    2016-04-06 17:16:37

    와~ 재밌고 공감가는 글이네요. 

    감사합니다.

    0
  • 데레베
    4
    2016-10-24 16:05:06

    글 꿀잼이네요~

    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.