달력

3

« 2024/3 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31

'Entrophy'에 해당되는 글 1

  1. 2008.02.29 Java에 대한 보이지 않는 위협 3
괄목할만한 성공

 1995년 Java라는 언어가 생겼고, Web의 부흥과 맞물려 초창기에는 Java Applet, 현재는 Java Platform EE(Enterprise Edition)로 IT의 한 축을 그었다. Applet은 잠깐 반짝 하다 말았지만, 특히 Java Platform EE의 성공은 경이적이어서, 기업 전산 환경의 필수 middleware인 Web Application Server(이하 WAS)는 당연히 Java Platform EE 명세서에 준하는 것으로 생각하고(예전엔 Netscape Application Server라는 C/C++ 기반의 WAS도 있었지만 지금은 모두 Java Platform EE 명세를 따르는 WAS만 있는 것 같다), 따라서 기업/조직 전산 환경에서 Java는 가히 예전의 COBOL의 위치를 차지한다 해도 과언이 아니다. Embedded System 쪽으로는 특히 휴대전화 쪽으로 Java Platform ME(Micro Edition)이 널리 퍼졌고, Desktop이 조금 빈약하지만 Sun Microsystems가 Swing 다듬기에 여념이 없고, 특히 Eclipse의 SWT/JFace, RCP의 출현으로 말미암아, Platform 독립적인 Desktop Application 개발에도 Java가 세를 늘리고 있다(겪어보면 알겠지만 compile도 필요 없이 내가 짠 application이 Windows에서도 돌고 Linux에서도 돈다는 것은 정말 대단히 매력적인 일이다).

 분명 Java는 문법이, 특히 C++에 비하면, 깔끔하다. Java 이전에 OOP를 한다고 하면 C++로 coding한다는 이야기였던 때가 있었는데, C도 그렇지만 이 C++도 code 자체가 대단히 난잡하다. 특히 MFC로 짠 Windows program code는 지금 봐도 그 너저분함에 질린다(그래서 개인적으로 C#의 등장을 환영한다. 최소한 Windows program도 깔끔하게 짤 수 있으니까). 그런데 이 Java는 C++에 비하면 상당히 우아한 code가 나올 수 있다. 그러다보니 요새는 'Java로 된 자료 구조', 'Java로 된 algorithm', 'Java로 된 OOP' 등, 학계에서도 교육용 목적으로 Java를 많이 가르치며 S/W 공학 같은 것을 논할 때 예제 code도 Java로 짠 것을 심심찮게 볼 수 있다.

 또한, Java는 open source 개발자들에게도 매력적이었는지 Apache 재단, Eclipse 재단 등을 위시한 수많은 곳에서 Java 관련 제품을 개발하고 정보를 교류하고 있으며 이러한 산출물들은 Java 개발을 편리하게 하고, 새내기 개발자들이 참고할만한 교재 역할을 하며, Sun Microsystems 같은 Java 명세에 칼자루를 쥐고 있는 자들이 명세를 재정할 때 idea를 주고, 아울러 독단에 빠지지 않고 실질적으로 개발자들이 원하는 바를 잘 반영하게 하는 일종의 압력으로도 작용하여, 궁극적으로 Java의 세 확산을 일조하는 선순환 구조를 만들어냈다.

 즉 현재 Java는 Thomas Kuhn이 '과학 혁명의 구조'라는 책에서 말한 바로 그 Paradigm이다.

 Java의 비대화

 위에서 살펴본 바와 같이 Java는 정말 성공적인 가도를 달려왔다. 그러나 요즈음 일종의 이상 징후가 나오는 것도 사실이다.

2004년에 나온 Java Platform SE 5는 꽤 큰 문법 추가가 있었다. 하나는 Generics요, 또 하나는 Annotation이다. 그런데 이것이 좀 code를 난잡하게 만들었다. 예를 들면,

public EnumMap(EnumMap<K, ? extends V> m)

java.util.EnumMap이라는 class의 생성자이다. JDK 1.4 이전 code였으면 public EnumMap(EnumMap m)이라고 끝났을 code이다. 물론 Generics를 도입한 결과 Type 확인을 compile 시에 할 수 있게 되어 ClassCastException 꼴은 덜 보게 되어서 결과적으로 program 안정성 향상에 기여한 것은 사실이나 위 code를 보면 "먼 소린지~"다. Java 문법도 간결했던 문법이, 슬슬 사용자의 요구를 수용하다 보니 점점 난잡해지고 있는 한 예라 하겠다. API적인 측면은 더하다. 지금 Java Platform SE 6의 API는 JDK 1.2의 API에 비하면 훨씬 방대하다. 즉, 기술이 복잡해지고 있다. 그리고 이 복잡도를 사용자들이 수용하기 어려울 때, Java는 스스로의 무게에 비틀댈 것이다. 많은 기술들이 그랬었던 것처럼. Java도 entrophy의 증가라는 열역학 법칙에 자유롭지 못한 것은 아닐까.


sciprt 언어들의 도전

Java Platform이 Web 개발에는 거대하고 복잡하여 부적절하다는 말들이 여기저기서 나오고 있다. 이들 주장은 주로 PHP나 Python, Ruby와 같은 script 언어를 좋아하는 사람들에게서 많이 나오는데, 그동안 Java 진영은 그런 언어로 개발한 Web은 고가용성 등에 문제가 있어 mission-critical한 기업 업무 개발에는 부적절하다고 주장했다(재미있는 것은 이러한 주장은 이제는 한 물 간 것으로 취급하는 TP Monitor 진영, 더 한 물 간 것으로 여기는 Mainfram 진영이 Java를 폄하할 때 하는 주장이다). 확실히, script 언어들은 개발 생산성은 좋다. 그러나 Java 진영은 IBM, Sun Microsystems, BEA, Oracle 같은 IT 업계 거물이 버티고 돈은 받지만 동작을 보증함에 비해, 동적 type 언어들은 open source 진영에서 나온 것이다 보니, Do-it-yourself인 이런 open source 결과물을 자신의 업무 환경에 턱 적용했다가 문제 생기면 본인이 스스로 뒷감당을 해야 하므로, 혁신보다 보신이 중요한 (거대) 기업 조직 생리 상 이런 것들을 채용하기는 어렵다. 실제로 그러한 언어로 된 Web 개발은 기업 규모의 전산 환경에서는 underground 취급당했다. 그러나 RubyOnRails로 대표하는 쾌속 Web 개발이 개발자들의 이목을 끌고, Google이나 Wikipedia 같은, 무시무시한 traffic을 견디는 동적 type 언어들로 개발한 site들이 출현하다 보니, 과연 고가용성 때문에 거대함과 복잡함을 감내해야 하는지, 과연 그런 것들이 고가용성에 문제가 있는지에 대한 회의가 많이 늘었다. Java는 이러한 도전에 대한 응전으로 이번 Java Platform SE 6부터 JVM 상에서 script 언어를 돌릴 수 있는 길을 열어놓았다. 하지만 script 언어라는 것이 Java를 제치고 Paradigm의 영예를 순식간에 대체할 수 있는 가능성은 적지 않다.

 
Java 새 version의 비활성화

 요새 Microsoft는 Windows Vista를 열심히 팔고 있다. 그런데 이 Windows Vista 판매의 걸림돌은 Linux나 Solaris 같은 다른 운영체제가 아니라 바로 Windows XP, Windows 2000 같은 이전 version의 Windows이다. 그런데 이 현상이 Java에도 나타나고 있으니, Java Platform SE 6가 나오고 Java Platform EE 5가 나왔건만 아직도 현장에서는 JDK 1.4와 J2EE 1.4 기반의 WAS가 판을 치고 있다. 또한 WAS 제작사들도 Java Platform EE 5 인증 받는데 그닥 열의가 없다. TmaxSoft는 Java SE Platform EE 5 기반 WAS인 JEUS 6을 개발했지만, 현재 그 회사 site는 JEUS 5 위주로 소개하고 있다. BEA는 Java Platform EE 5 기반 WAS로 이제서야 WebLogic Server 10을 내놓았고, IBM 또한 J2EE 1.4 기반인 WebSphere Application Server 6.1에 머물러 있다. Open Source WAS의 대표 주자인 JBoss Application Server도 J2EE 1.4 명세에 일부 Java Platoform EE 5를 이루는 명세의 구현체 몇 개를 추가 탑재하는 식이다. 즉, 시장의 평가는 어떻게 보면 J2EE 1.4 기반 WAS로도 충분하다는 신호를 보내는 것이다. 또한 J2EE 1.4 명세는 JDK 1.4를 명시하므로 Java Platform SE 6은 고사하고 5도 각광을 덜 받는 것이다(이것은 위에서 언급한 문법 변화를 개발자들이 잘 수용하지 않기 때문이기도 하다).


Paradigm, 그리고 변곡점

 아까도 말했듯 Java는 확고한 Paradigm이다. 그러나 현재 이 Paradigm이 현실과의 괴리를 보이는 징후가 여기저기서 포착할 수 있다. 어쩌면 우리는 Intel의 전 CEO였던 Andrew Grove가 쓴 책, "편집광만이 살아남는다(Only Paranoids Survive)"에서 나온 변곡점을 지나는 중인지 모른다. 어떤 미분 가능한 함수에서 변곡점은 기울기가 급변하는 지점인데 재미있는 것은 그 변곡점에 처해서는 그 부분이 변곡점인지 인지하기가 쉽지는 않다. 그러나 함수의 독립변수를 계속 진행시키다 보면 그 기울기가 점점 급변한다.

 어차피 Java도 현상의 문제를 타파하기 위한 도구일 뿐이다. 가끔 어떤 computing platform에 대해 종교적인 믿음을 가진 신자들을 볼 수 있는데, 그러한 자세보다는 이러한 잘 드러나지 않는 변곡점을 기민하게 인식하고 새로운 Paradigm에 신속하게 자신을 적응시키 것이 현명하다 보여진다. 즉 적자생존(適子生存)이라는 말은 우리에게도 들어맞는 말이다. 그리고 또 하나, Thomas Kuhn이 과학 혁명의 구조에서 말한 것이 잘 들어맞는지 통사적(通史的)으로 살펴 보는 것도 재미있는 일일 것이다. 그리고 Java가 entrophy의 증대를 언제까지 성공적으로 제어할 지 지켜보는 것도 역시 흥미로울 것이다.

그나저나 Ruby랑 RubyOnRails를 공부해야겠다.

==================
예전 블로그에 2007.5.22에 쓴 글
:
Posted by 하얀 말