자바가 주목받는 이유
자바는 학계와 업계에서 가장 많이 연구되고 있는(가장 좋다는 의미와는 다름) 언어이다.
- 가장 많이 쓰이는 언어는 C와 COBOL과 FORTRAN일 것이다. 또한 가장좋은프로그래밍언어를 보라.
- 가장 많이 쓰이는 언어는 C와 COBOL과 FORTRAN일 것이다. 또한 가장좋은프로그래밍언어를 보라.
자바는 최신의 프로그램언어 연구결과(패턴,상속 등)를 많이 반영하고 있다.
- 특히 패턴관련연구는 초기의 책(GOF 같은)이 C++예제로 사용했음에도 불구하고 현재 대부분의 패턴책들은 예제언어로 자바를 사용한다.
- 특히 패턴관련연구는 초기의 책(GOF 같은)이 C++예제로 사용했음에도 불구하고 현재 대부분의 패턴책들은 예제언어로 자바를 사용한다.
자바는 실행이 느린 대신에 매우 빠르게 증가하고 있는 하드웨어사양에 힘입어 매우 느리게 발전하고 있는 소프트웨어의 개발속도를 개선하는 문제를 가상머신이라는 방법으로 해결하고 있다.
- 이는 이미 파워빌더라는 프로그램에서 그리고 연이어 비주얼베이직이 시도했듯이 모두 실행속도의 희생과 함께 빠른 개발속도를 보장하여 업계선두에 올라서는 탁월한 선택이다. XP에서도 기저에 깔고 있듯이 지금의 프로그래밍의 문제는 실행속도가 아니라 테스트를 용이하게 하기와 버그를 없애기인 것이다.
- 이는 이미 파워빌더라는 프로그램에서 그리고 연이어 비주얼베이직이 시도했듯이 모두 실행속도의 희생과 함께 빠른 개발속도를 보장하여 업계선두에 올라서는 탁월한 선택이다. XP에서도 기저에 깔고 있듯이 지금의 프로그래밍의 문제는 실행속도가 아니라 테스트를 용이하게 하기와 버그를 없애기인 것이다.
자바 베타 0.9버전이 인터넷에 올랐을 때부터 지금까지 계속 자바를 연구하고 있으면서도 한번도 자바프로젝트를 할 기회를 가지지 못했던 것은 바로 느리다는 특성때문에 업계 솔류션으로 많이 채택되지 못했던 이유가 크다. 그러다가 갑자기 폭발적으로 수행된 자바 프로젝트들이 또한번 잘못된 선행소스코드를 남겼고 이는 앞으로 자바에 큰 부담으로 작용할 것이다. 이의 치유는 언어의 외적인 측면(돈이 되는가!)이 아닌 내적인 측면들(왜!무엇을!어떻게!)에 우리나라 개발자들이 좀 더 관심을 기울어야 할 때가 아닌가 한다. ---이정호
자바의 특징은
- 운영체제에 독립적인 프로그램을 작성하기 쉽다.
- API가 풍부하고 구성이 잘되어 있다.
- 대부분의 JavaProgrammer 들은 Sun의 CodingStandards를 잘 따르므로 여러 비표준 라이브러리를 섞어 써도 코드가 깔끔해 보인다.
- 메모리를 엄청나게 잡아먹는다. 그리고 쓰레드를 제대로 구현했는지 어쨌는지 가끔 메모리 반환이 안된다. 그러나 대부분의 메모리는 JVM을 로딩하는데 쓰이는 것이다. 또한 메모리가 반환되지 않은 것은 일반적으로 잘못 작성된 에플리케이션에 의한 것이지 JVM 자체의 문제가 아니다. 물론 잘못 구현된 JVM이 존재할 가능성을 배제할 수는 없다.
- 처음 실행속도가 느리다. 서버쪽에서는 별상관 없지만 빠른 반응을 요구하는 클라이언트용으로는 부적합하다.
- 자바가상머신이 깔려있어야 사용가능하다.
자바의 플랫폼 독립성에 대한 토론:
그러나 견고한 Sun이 공식적으로 지원하는 운영체제는 사실 몇 개 안된다. .png ";)")
그리고 완벽하게 OS에 독립적이지도 않은게 OS에 종속된 애플리케이션은 개발하지 못한다. 
자바는 OS독립적인 어플리케이션을 만들기 쉽도록 도움을 줄뿐 자바를 사용한다고 OS 독립성이 보장되는 것은 아니다. 그리고 완전히 OS독립적인 어플리케이션이 있을 수가 없다.
그리고 완벽하게 OS에 독립적이지도 않은게 OS에 종속된 애플리케이션은 개발하지 못한다. 자바는 OS독립적인 어플리케이션을 만들기 쉽도록 도움을 줄뿐 자바를 사용한다고 OS 독립성이 보장되는 것은 아니다. 그리고 완전히 OS독립적인 어플리케이션이 있을 수가 없다.자바가 플랫폼에 독립적이라는 것은 플랫폼마다 각각의 JVM이 존재하기 때문이다. 작성된 코드는 플랫폼이 바뀌었을 때 그 플랫폼에 맞는 JVM이 돌고 있기에 인식이 가능하다는 것이다. 결국, 자바 자체는 플랫폼에 독립적이지 않다.
.NET은 플랫폼독립+언어독립이죠. 사실상 플랫폼 독립은 MS에서 노력을 하지 않으므로 무의미하겠구요. 중요한 것은 언어 독립이라고 볼 수 있죠. --F176자바가 플랫폼에 독립적이라는 것은 소스코드를 한번 작성하면 어느 기계에서나 사용할 수 있게 하도록 기계마다 자바가상머신을 만들려고 하고 있으며 많은 기계플랫폼회사들이 자바가상머신을 만들어 주고 있기 때문에 플랫폼 독립적이라 이야기할 수가 있다. 다만 운영체제마다 다른 기계적 환경과 소프트웨어적 구현상에서 작동하고 있기 때문에 각각 다른 JVM이 동일한 소스코드에 대하여 동일한 동작을 한다고 보증할 수 없다. 하지만 이전의 환경들(예를 들어 C의 경우 무수한 운영체계와 무수한 컴파일러들에서 각각 다른 소스코드가 있어야 했다.)보다는 훨씬 더 빠르게 플랫폼호환이 가능하다. C#은 이를 본받은 것이나, 과연 다른 무수한 개발자들과 회사들이 이에 호응할 것은 불분명하다. ---이정호
JVM 위에서도 다른 언어들을 얼마든지 돌릴 수 있는데요? .NET은 어떤 면에서 언어독립적인가요? see ![[http]](/ns/imgs/http.png)
Jython, Kawa, Jacl. --서상현
Jython, Kawa, Jacl. --서상현.NET 프레임워크는 CLI를 만족하는 어떤 언어로도 사용 가능합니다. 이런 의미에서 언어 독립이라고 말씀드렸습니다.--F176
언어 독립은 .NET보다 더 다양한 언어가 JVM에서 증명되었습니다. --씨엔
http://www.robert-tolksdorf.de/vmlanguages.html JVM에서 돌아 가는 언어는 수십단위 입니다. 거의 100에 다가 갑니다만.. 아니, 그것 보다는 JavaLanguage 페이지에서 .Net의 특성을 말씀하신 것은, 비교 또는 토론을 하지고 하시는 것인지, 아니면 그런 정보가 있다는 것인지 구분하기 어렵습니다. 
언어 독립이 일반적으로 중요시 되지 않는 이유는, 멀티랭귀지 프로젝트의 복잡도가 매우 높다는 점 때문입니다. 예를 들어 .Net 프로젝트에서 C#과 Visual Baisc과 Cobol을 동시에 사용한다고 가정해 보면 쉽게 이해 하실수 있을 겁니다. (유사 언어를 멀티로 사용하는 것을 그나마 복잡도가 낮은 편입니다.) 일반적으로 멀티 랭귀지를 사용한다면 "고객의 요구 사항"이거나, Logic+VIsual을 분리을 위해서 이거나(예, Visual C++ + Visual Basic), glue Script language + Main Langauge(예:python + c) 일 것입니다.어느쪽이든 프로젝트의 복잡도를 높이는 방향이죠. (마지막 case는 예외가 될수 있습니다만). --안지성
http://www.robert-tolksdorf.de/vmlanguages.html JVM에서 돌아 가는 언어는 수십단위 입니다. 거의 100에 다가 갑니다만.. 아니, 그것 보다는 JavaLanguage 페이지에서 .Net의 특성을 말씀하신 것은, 비교 또는 토론을 하지고 하시는 것인지, 아니면 그런 정보가 있다는 것인지 구분하기 어렵습니다. 언어 독립이 일반적으로 중요시 되지 않는 이유는, 멀티랭귀지 프로젝트의 복잡도가 매우 높다는 점 때문입니다. 예를 들어 .Net 프로젝트에서 C#과 Visual Baisc과 Cobol을 동시에 사용한다고 가정해 보면 쉽게 이해 하실수 있을 겁니다. (유사 언어를 멀티로 사용하는 것을 그나마 복잡도가 낮은 편입니다.) 일반적으로 멀티 랭귀지를 사용한다면 "고객의 요구 사항"이거나, Logic+VIsual을 분리을 위해서 이거나(예, Visual C++ + Visual Basic), glue Script language + Main Langauge(예:python + c) 일 것입니다.어느쪽이든 프로젝트의 복잡도를 높이는 방향이죠. (마지막 case는 예외가 될수 있습니다만). --안지성
WORA(Write Once, Run Anywhere)
썬에서 주장하는 자바의 플랫폼 독립성을 강조하는 문구. 한번 작성하면 그 어떤 운영체제에서도 실행할 수 있다는 뜻. 감동적이지만 사기성이 농후함. 자바가 플랫폼에 독립적이기 보단 자바 자체를 하나의 플랫폼으로 인식을 요함. Java는 플랫폼 독립성을 제공한다기 보다는, 또 다른 플랫폼을 만들어 냈다고 생각한다. 기존의 애플리케이션을 자바 플랫폼으로 모두 옮기려면 새로운 디자인으로, 새롭게 개발해야 한다.
WORA는 단순화된 문장입니다. WORA에 대한 올바른 의미는 'Except for timing dependencies or other non-determinisms and given sufficient time and sufficient memory space, a program written in the Java programming language should compute the same result on all machines and in all implementations.' 입니다. 그리고, 기존의 에플리케이션을 자바 플랫폼으로 포팅하기 위한 비용문제는 WORA와는 무관하다고 생각됩니다. --아무개
WORA는 단순화된 문장입니다. WORA에 대한 올바른 의미는 'Except for timing dependencies or other non-determinisms and given sufficient time and sufficient memory space, a program written in the Java programming language should compute the same result on all machines and in all implementations.' 입니다. 그리고, 기존의 에플리케이션을 자바 플랫폼으로 포팅하기 위한 비용문제는 WORA와는 무관하다고 생각됩니다. --아무개
LinusTorvalds의 인터뷰 내용중에 이런게 있었는데, Linux도 WORA라고 말이죠.... 한번 리눅스 용으로 작성된 코드는 어떤 시스템이던 리눅스가 이식되어 있기만 하면 대부분 돌아갑니다..간혹.. 약간의 수정도 있긴 하겠죠.. --이기
리눅스용- 이란 말은 하드웨어 플랫폼에 대한 거겠죠? 이기종 하드웨어에서도 문제없다 라는 뜻일 것 같네요. -- F176
어제 gerecter가 참석한 캘리포니아 산 호세에서 열린 한 학회에서, 한 연사가 Wirte Once, Tune Anywhere 라고 비아냥거려, 갈채를 받았다.
.png ":-)")
--http://java.sun.com/자바스터디 : 대표적인 JavaLanguage 사이트JavaWorld : Best Java Online Magazine !!!자카르타한글홈페이지 : 국내유일의 자카르타 한글 홈페이지 ---이정호http://www.jabook.org : 소설같은 자바가 있는 곳임당...이 책에 대해 최근 평이 꽤나 좋더군요. 웹에서 조금 읽어봤는데, 이제까지 국내에서 출간된 자바 서적 중에서는 그나마 낫긴 하지만, "국내에서 좋다고 하는 게" 이 정도인가 하는 생각에 좀 서글픕니다. see also Bjarne Stroupstrup의 Learning Standard C++ as a New Language --김창준
Learning Standard C++ as a New Language --김창준자바가 플랫폼 독립적이라고 하는것은, 다른 프로그램 언어와 다른 방식의 실행환경을 지원하기 때문이라고 봅니다. 물론 JVM 이라는 환경이 필수적이고 효율이 떨어지는게 사실이지만, 자바 자체로 봐서는 어느 플랫폼에서도 같은 소스를 가지고 거의 같은 결과를 볼 수 있다고 하더군요. 기존의 프로그램들이 사용환경마다 제각기 컴파일 해야하며, CPU등의 H/W적인 요소까지 고려해서 프로그래밍 해야 하는 것과 비교한다면, 그나마 독립적이라고 할 수 있지 않을까요? -nataxia
자바...왠지 어수선하고 분산된 느낌이 들어 배우는데 약간 거부감이...ㅋㅋㅋ 그만큼 기능도 많긴 하지만..자바 공부하다 지금은 C쪽으로 다시 파는 중입니다...ㅋㅋㅋ --Oasis
JVM이 있기 때문에 플랫폼 독립적이지 않다는 관점에서 본다면, 그러한 의미의 플랫폼 독립성이라는 것은 (자바를 포함하여) 어떠한 언어도 가질 수 없는 특징이라고 생각합니다. 모든 인터프리터 언어는 인터프리터가 이식되어야 하므로 플랫폼 독립적이지 못하고, ANSI/ISO C나 C++ 또한 컴파일러가 이식되어야 하므로 플랫폼 독립적이지 못하며, 향후 어떠한 언어도 플랫폼 독립적일 수 없게 됩니다. 그러므로 플랫폼 독립성이라는 것은 항상 상대적인 의미로 이해해야 하며, 어떠한 언어가 플랫폼 독립성을 갖는다는 말은 타 언어에 비해 상대적으로 높은 플랫폼 독립성을 갖는다는 의미로 해석하는 것이 옳습니다. 또한 플랫폼 독립성이라는 특성은 그 자체로써 평가되기 보다는 ANSI/ISO C에서 말하는 소스코드 이식성에 대한 연장 - 바이너리 호환성 - 으로 보아야 할 것이며, 이식성 역시 생산성에 대한 연장으로 보아야 할 것입니다. 자바가 제공하는 플랫폼 독립성이라는 것은 결과적으로 생산성 향상에 도움을 주는 하나의 수단으로 보아야합니다. 자바의 플랫폼 독립성 논쟁은 이러한 전제를 깔고 하는 것이 좋습니다. --아무개
동의합니다. 제가 생각하는 바랑 거의 일치하는군요 --지원
좀더 쉽게 이야기 하면, 사용자의 컴퓨터와 운영체제의 종류를 가리지 않고 돌릴수 있다! 겠지요. (물론 제약사항이 있습니다)--안지성
예 플랫폼 독립적인 것은 상대적으로 그렇다는말 같습니다. 가상머신이 설치된 다른 운영체제에서 실행을 해보면 똑같은 결과를 같기 힘들더군요 특히 스레드 같은 경우요. 자바의 또 다른 장점으로 컴파일된 코드가 바이트 코드라 네트워크 전송에 알맞고 가상머신에 코드컴증기능이 있다는것입니다. 단점도 많은 것 같습니다. 특히 GUI를 만들기가 불편하더군요. SUN과 MS가 서로 내세우는 장점들은 장사군들의 이야기가 아닐까요? 거기에 현혹될 수도 있지만 개발하려는 제품의 특성과 소비자의 요구에 맞게 언어를 선택하는 것이 더중요하다고 생각됩니다. --goodday
2015년, Java 8 이 나오고, Java가 발표된 지 20년 째 되는 시점에서 돌아보면 JVM은 다른 언어와 비교해서 충분히 안정적이고 Platform에 따른 독립성을 보장해 주고 있습니다. 물론 100% 완벽하지는 않지만, 체감상 99% 정도는 완벽하다고 생각합니다. 당장 수 많은 사람들이 마인크래프트라는 Java 로 만들어진 게임을 수 많은 다앙한 Platform 의 컴퓨터에서 전 세계적으로 플레이하고 있습니다. 세세하게 파고 들면 Platform 별 JVM 구현체별로 차이가 나는 부분이 없지는 않으나, 비교적 꽤 높은 수준으로 동일한 Class 를 실행 시 이기종 Platform 사이에서도 동일한 동작을 보장해 줍니다. 게다가 이러한 특성은 Maven Central Repository 에 등록된 약 100만개의 JAR 로도 입증됩니다. 온갖 다양한 Platform 에서 제작된 JAR 가 중앙 저장소에 업로드되고, 이것이 다시 온갖 다양한 Platform 에서 구동되는 JVM 을 위해 다운로드됩니다. 그러므로 Platform Independent에 관한 토론은 더 이상 필요하지 않을 것 같습니다. 물론 이제는 노스모크에 거의 오는 사람이 없기도 하지만요. --daybreak --지원좀더 쉽게 이야기 하면, 사용자의 컴퓨터와 운영체제의 종류를 가리지 않고 돌릴수 있다! 겠지요. (물론 제약사항이 있습니다)--안지성
예 플랫폼 독립적인 것은 상대적으로 그렇다는말 같습니다. 가상머신이 설치된 다른 운영체제에서 실행을 해보면 똑같은 결과를 같기 힘들더군요 특히 스레드 같은 경우요. 자바의 또 다른 장점으로 컴파일된 코드가 바이트 코드라 네트워크 전송에 알맞고 가상머신에 코드컴증기능이 있다는것입니다. 단점도 많은 것 같습니다. 특히 GUI를 만들기가 불편하더군요. SUN과 MS가 서로 내세우는 장점들은 장사군들의 이야기가 아닐까요? 거기에 현혹될 수도 있지만 개발하려는 제품의 특성과 소비자의 요구에 맞게 언어를 선택하는 것이 더중요하다고 생각됩니다. --goodday
JAVA 의 플랫폼 독립성이란 사실 현실적인 입장에서 말하면, GUI, 네트워크, 멀티미디어 API들이 많은 플랫폼에서 수정없이 사용될 수 있도록 포팅되어 있다는 뜻으로 이해할 수 있다.
위에서 언급된 Linux도 WORA이다 라는 말이나, C소스코드로 만든 프로그램은 컴파일러만 있으면 어디서든 WORA라고 할 수 있다라는 말도 일리가 있긴 하다. JAVA 가 이들보다 훨씬 더 "WORA"스러운 점은, 순수한 구조와 JAVA 철학의 문제보다는 현실적이고 공학적인 부분에서 찾을 수 있다. 요즘 실제 소프트웨어를 만들때, GUI, 네트워크, 멀티미디어 기능은 필수적이다. 이러한 기능을 사용하는데 따른 "편의"의 입장에서 볼 때, JAVA는 차별화 되어 "WORA"라고 할만한 자격이 있다.
C++소스코드 배포라고 해보자, MFC로 인터페이스를 꾸민다면? Linux 배포라고 해보자. 그 끔찍한 X-window 라이브러리 구성 맞추기와 각종 드라이버 맞추기를 떠올려 보자. 인터프리팅 플랫폼을 만들어서 그위에서 돌린다는 점만으로, 구조적/철학적으로 WORA라고 하면 기존의 수많은 인터프리터들이 삐진다..png ":)")
JAVA의 "WORA스러움"은 Sun Microsystems 인간들이 죽어라고 통일된 API 세트를 잘 돌릴 수 있도록 여기저기 포팅하고 실험하고 수정한 데 그 가치가 있다.
JAVA의 강력한 WORA는 분명, JAVA라는 언어가 통채로 완전히 Sun Microsystems라는 한 회사에 종속되어 있기 때문에 가능한 일이었다. 만약 JAVA와 Microsoft를 대립적으로 인식한다고하면, JAVA가 Microsoft를 완전히 제압하고 Microsoft가 망하기 보다는, JAVA와 Microsoft가 대등한 경쟁 구도로 가는 편이 바람직하다고 본다. 지금 JAVA의 종속성 문제는 Microsoft 보다 심한 편이다. ( 농담하나 : Microsoft가 공짜 오피스를 대학가에 뿌릴 때, 얼마나 욕을 들어 먹었는가? Sun Microsystems는 칭찬을 들으면서 JAVA를 공짜로 뿌려대고 있다. ) -- gerecter
위에서 언급된 Linux도 WORA이다 라는 말이나, C소스코드로 만든 프로그램은 컴파일러만 있으면 어디서든 WORA라고 할 수 있다라는 말도 일리가 있긴 하다. JAVA 가 이들보다 훨씬 더 "WORA"스러운 점은, 순수한 구조와 JAVA 철학의 문제보다는 현실적이고 공학적인 부분에서 찾을 수 있다. 요즘 실제 소프트웨어를 만들때, GUI, 네트워크, 멀티미디어 기능은 필수적이다. 이러한 기능을 사용하는데 따른 "편의"의 입장에서 볼 때, JAVA는 차별화 되어 "WORA"라고 할만한 자격이 있다.
C++소스코드 배포라고 해보자, MFC로 인터페이스를 꾸민다면? Linux 배포라고 해보자. 그 끔찍한 X-window 라이브러리 구성 맞추기와 각종 드라이버 맞추기를 떠올려 보자. 인터프리팅 플랫폼을 만들어서 그위에서 돌린다는 점만으로, 구조적/철학적으로 WORA라고 하면 기존의 수많은 인터프리터들이 삐진다.
JAVA의 "WORA스러움"은 Sun Microsystems 인간들이 죽어라고 통일된 API 세트를 잘 돌릴 수 있도록 여기저기 포팅하고 실험하고 수정한 데 그 가치가 있다.JAVA의 강력한 WORA는 분명, JAVA라는 언어가 통채로 완전히 Sun Microsystems라는 한 회사에 종속되어 있기 때문에 가능한 일이었다. 만약 JAVA와 Microsoft를 대립적으로 인식한다고하면, JAVA가 Microsoft를 완전히 제압하고 Microsoft가 망하기 보다는, JAVA와 Microsoft가 대등한 경쟁 구도로 가는 편이 바람직하다고 본다. 지금 JAVA의 종속성 문제는 Microsoft 보다 심한 편이다. ( 농담하나 : Microsoft가 공짜 오피스를 대학가에 뿌릴 때, 얼마나 욕을 들어 먹었는가? Sun Microsystems는 칭찬을 들으면서 JAVA를 공짜로 뿌려대고 있다.
) -- gerecter자바를 볼때 조심해야 하는 것 줌에 하나가, "자바는 언어적으로 훌륭하다"라는 사고 방식입니다. 물론 자바는 언어적으로 상당히 훌룡한 디자인을 가지고 있습니다. 그러나 자바를 바라볼때는 그것 보다는 "시장의 요구에 잘 맞춘다"를 보아야 합니다. 그래서 자바를 "돈버는 언어"라고 평가하는 사람도 있지요. C/C++을 가지고 돈을 벌기는 상당히 어려우 시절이 되어 버린 지금(각종 스크립트언어, VB, 파워빌더등의 DB 어플리케이션과 GUI 제작에 최적화된 Tool등을 보시면 이해가 가실듯) 시장에서 가장 돈이 되는 것은 웹스크립트언어와 자바입니다. 물론 시장이라고 하는 곳을 떠나, 저 머나먼 해커의 세계에서는 여전히 C가 강력합니다만, 아무래도 그런 것들은 해커들의 장난감에 지나지 않는 경우가 많습니다. 그럼 시장의 요구는 무엇일까요? 인터넷과 분산환경, 그리고 반MS입니다. 앞의 두가지는 MS에서도 제공가능합니다만, 마지막 반MS는 MS에서 제공 할수 없는 것이지요 자바를 사용하는 어느 프로젝트를 가보아도 항상 나오는 말. "비독점적인 기술을 사용합니다", "공개되어 검증된 솔루션을 제공합니다". 제가 보는 반MicroSoft의 핵심은 리눅스와 자바입니다. 두가지 모두 MS가 존재하기 때문에 기업들에게 체용 되어 온 기술들이죠. 아무튼 이러한 것들을 보지 못하고 "자바는 무조건 좋다"라고 말하는 일부 사람들을 보면 답답해지고는 합니다. "왜 자바가 좋으냐?"라고 물으면 답하지 못하면서 말입니다. --안지성
자바를 사용하는 어느 프로젝트를 가보아도 항상 나오는 말. "비독점적인 기술을 사용합니다", "공개되어 검증된 솔루션을 제공합니다". 제가 보는 반MicroSoft의 핵심은 리눅스와 자바입니다. 두가지 모두 MS가 존재하기 때문에 기업들에게 체용 되어 온 기술들이죠. 아무튼 이러한 것들을 보지 못하고 "자바는 무조건 좋다"라고 말하는 일부 사람들을 보면 답답해지고는 합니다. "왜 자바가 좋으냐?"라고 물으면 답하지 못하면서 말입니다. --안지성시장의 요구에 반MS를 넣으시다니..참 의외군요. 시장의 요구는 친MS가 아닐까요? 프로그램이 쓰이는 곳이 워낙 방대하긴 하지만 거의 모든 앤드유저는 MicrosoftWindows를 쓰는 데 말이죠. 공개되어 검증된 솔루션과 비독점적인 기술이라는 것은 개발자에게 편리한 것 같은 데요. MS-Windows에서 돌아가는 프로그램을 만드는 것이 개발자에게는 정.말. 편합니다. 어떤 면에서 반MS를 시장이 요구한다고 생각하시는 지 궁금하네요. --RedPain
물론 End User인 일반 고객에게는 MicrosoftWindows, InternetExplorer, MSN등의 MS의 솔루션은 이미 많이 친숙해져 있는 상태입니다. 또한 GUI가 중심이 되는 어플리케이션 역시 Windows 전용 어플리케이션(Native application)이 여전히 강력하지요. 하지만, 기업의 요구는 다릅니다. 기술적으로 MS에 종속되기를 원하지 않죠. 자신이 요구하는 어플리케이션을 얻기 위해 소프트웨어 제작사에 종속되어 기다리기보다는 소프트웨어 제작사들이 저렴한 가격에 좋은 성능을 가지고 서로 경쟁하여 기업에게 제공해 주기를 바랍니다. (이것이 대부분의 어플리케이션들을 웹 어플리케이션으로 변화시키는 근본 원인입니다.) 바로 Open이라는 것입니다. Open된 기술을 사용하게 되면 기업은 더이상 "사라진 제작사"를 원망하지 않아도 되게 되죠.
Open. 바로 이것을 MS가 가지고 있지 못한 것입니다. MTS나 ASP가 다른 운영체제를 지원하던가요?(물론 몇몇 회사에서 유닉스에서도 돌아가는 ASP를 만들기는 했지만 Active-x가 동작하지 않기 때문에 거의 사용되지 않죠) 반MS라고 하는 것은 바로 Closed Technologe를 거부하는 움직임을 의미합니다.
웹 어플리케이션으로 전환하게 되면 MS의 기술에 종속 되지 않게 되죠. 이것이 Internet이 기업들에게 가르쳐준 비밀입니다. 열어라. 그리고 나눠라(Open it, and share it). 닫혀진 기술을 사용할때, 독점이 되어버리고 시장의 축소를 가져온다...라는것을 MS가 보여주었기 때문에 기업들은 열린 기술을 사용하게 되는 것입니다. 뭔가 글이 정리가 않되는 군요 --안지성
Open. 바로 이것을 MS가 가지고 있지 못한 것입니다. MTS나 ASP가 다른 운영체제를 지원하던가요?(물론 몇몇 회사에서 유닉스에서도 돌아가는 ASP를 만들기는 했지만 Active-x가 동작하지 않기 때문에 거의 사용되지 않죠) 반MS라고 하는 것은 바로 Closed Technologe를 거부하는 움직임을 의미합니다.
웹 어플리케이션으로 전환하게 되면 MS의 기술에 종속 되지 않게 되죠. 이것이 Internet이 기업들에게 가르쳐준 비밀입니다. 열어라. 그리고 나눠라(Open it, and share it). 닫혀진 기술을 사용할때, 독점이 되어버리고 시장의 축소를 가져온다...라는것을 MS가 보여주었기 때문에 기업들은 열린 기술을 사용하게 되는 것입니다. 뭔가 글이 정리가 않되는 군요
--안지성그렇다면 웹 개발을 하면서도 MS 솔루션을 선택하는 기업에 대해서는 어떻게 생각하시는지 궁금합니다. 또, 많은 상황에서 기업에게 필요한 것은 플랫폼 독립성이 아니라 단지 플랫폼간 상호운용성(Interoperability) 정도라는 점은 어떻게 생각하시는지요. --아무개
웹 개발 또는 임베디드 시스템에서의 MS 솔루션을 선택하는 기업들이 많습니다. 많은 경우, End-User를 상대로 하는 중소 규모의 기업이죠. 이유는 여러가지가 있겠습니다만, 제가 생각하는 것은 "제품을 만들기 쉽다"입니다. 왜냐하면 윈도우와 IE 컴포넌트를 사용하면 해결 되는 문제가 굉장히 많죠.(대표적인 예로 국내의 많은 셋탑 박스가 윈도우를 기반으로 하는데 이유는 단한가지, Media Player때문인 경우가 많습니다.) 또한 "개발 환경이 친숙하다"라는 점도 들수 있습니다.
웹 개발을 살펴보면 자바든 MS 솔루션이든 그것을 가지고 원하는 기능을 구현하지 못할 이유는 없습니다. 그만큼 기술이 많이 발전했고, HTTP라고 하는 기술의 한계점도 있지요. 그래서 회사의 입장에서는 자신들이 보유하고 있는 엔지니어의 기술 보유 현황에 따라 원하는 솔루션을 선택할 수 있습니다.그러나 회사의 이익 또는 시장 가능성이라는 것을 보았을때, 윈도우에서만 팔수 있는 기술과, 상당히 많은 플렛폼(OS, h/w)에 팔수 있는 기술중에서 선택하라고 한다면 역시 후자쪽을 선택할 확률이 높지요. (또한 MS 솔루션의 한계라고 생각하는 것중에 하나가 윈도우 자체의 안정성과 성능입니다. MS 솔루션은 결국 모든 웹 페이지가 Windows 2000 Server와 IIS를 통해서 제공되어야 하는데, 같은 H/W Spec을 사용한다면 Linux쪽의 성능이 훨씬 우세한게 사실입니다.)
기업을 바라볼때 관점을 설명하면 원천 기술 제작 기업 -> 기업용 솔루션 제작기업 -> 엔드유저용 어플리케이션 제공 기업 이 존재합니다. 마지막의 엔드유저 어플리케이션 제작기업은 사실 자바가 되었든 MS가 되었든 PHP가 되었든 고객에게 서비스만 제공하면 되는 기업이지요(쇼핑몰 같은 곳이라고 생각하시면 됩니다.). 첫번째의 원천기술 제작 기업은 MS나 Sun 같은 회사죠. 결국 기술의 선택이 중요시 되는 것은 중간에 존재하는 기업용 솔루션 제작 기업입니다. 이들은 자신들이 만든 제품이 다른 기업에서 도입되어야만 생존 할수 있는 기업이고, 따라서 가급적 많은 시장을 노리게 됩니다. 그러니 윈도우에서만 돌아가는 솔루션 보다는 윈도우도 포함해서 돌아가는 솔루션을 만드는 것이 더욱 더 유리하게 되죠. (바로 이것 때문에 많은 기업들이 Write once run anywhere라는 모토를 가진 자바에 지대한 관심을 가지게 된 것입니다). 거기에 더 나아가, 표준화를 통해 컴포넌트 단위로도 제품을 팔수 있다라고 하는 J2EE(물론 약간의 거짓말이 포함되어 있습니다만)는 작은 기업들에게 굉장한 매력을 느끼게 하죠.(비슷한 예로 임베디드 시스템에서도 표준화를 통해 컴포넌트 서비스를 제공하자고 하는 OSGi도 존재합니다)
또한 그동안 MS가 보여준 시장 독점에 대한 위기감이 중간에 위치한 회사들로 하여금 반MS 진영을 구축하게 하였고, 여기에 Free (or Open) Software라고 하는 급물살이 더해 지고 있는 것입니다.
정리하자면, 중간에 존재하는 기업용 솔루션 제작 기업들의 요구사항이 반 MS인 것이고(다시 말하면 Open), 이것을 가장 적절하게 지원하고 있는 것이 Linux와 Java인 것입니다. 둘다 무료로 사용할수 있지요.또한 성능 역시 MS 솔루션 못지 않은, 오히려 더 좋은 경우도 있지요. 이들이 만들어 내는 솔루션과 트렌드가 시장에 반영되어 적용되는 것입니다. 결국 Protocol(Platform, format등등의 모두 포함하는 의미로써)을 독점하려고 하는 MS와 Protocol을 공개하여 시장을 공유하려고 하는 반 MS의 요구사항이 만들어내는 경쟁인 것입니다. (최근에는 MS역시 Open의 물결을 타려고 하고 있지요 ^^)
아무개님이 말씀하신 Interoperability는 Open Technology의 부산물입니다. Open되지 않은 기술은 절대로 상호 운영 될수 없습니다. MS가 그토록 노력함에도 불구하고 리눅스용 Win32 API를 제대로 못만들어 내는 것과 비슷합니다. 공개할 수 없기 때문입니다. (오히려 cygwin같은 경우 open된 linux를 Windows로 옮기는 데 대단한 성과를 보여주고 있지요. 최근에는 X-window나 Apache같은 소프트웨어도 구동시킬수 있습니다.) 생각해 보니 완전 독점 상태도 비슷한 현상을 가져 올 듯 싶습니다. 만약 모든 컴퓨터에 Windows 2000만이 설치되어 있다면 프로그램 만들기도 꽤나 편하기늘 할 듯 하군요 ^^;
기업들은 과거에는 상호 운영성 보다는 독점을 노리고 개발을 했습니다만, 인터넷이 보여준, 웹이 보여준 Open Technology가 가져다준 거대한 시장을 목격한 이후로 상호운영성을 중요시 하게 되었지요. 아.. 글이 정말 정리가 않되는 군요^^ 나중에 다시 정리하지요 --안지성
웹 개발을 살펴보면 자바든 MS 솔루션이든 그것을 가지고 원하는 기능을 구현하지 못할 이유는 없습니다. 그만큼 기술이 많이 발전했고, HTTP라고 하는 기술의 한계점도 있지요. 그래서 회사의 입장에서는 자신들이 보유하고 있는 엔지니어의 기술 보유 현황에 따라 원하는 솔루션을 선택할 수 있습니다.그러나 회사의 이익 또는 시장 가능성이라는 것을 보았을때, 윈도우에서만 팔수 있는 기술과, 상당히 많은 플렛폼(OS, h/w)에 팔수 있는 기술중에서 선택하라고 한다면 역시 후자쪽을 선택할 확률이 높지요. (또한 MS 솔루션의 한계라고 생각하는 것중에 하나가 윈도우 자체의 안정성과 성능입니다. MS 솔루션은 결국 모든 웹 페이지가 Windows 2000 Server와 IIS를 통해서 제공되어야 하는데, 같은 H/W Spec을 사용한다면 Linux쪽의 성능이 훨씬 우세한게 사실입니다.)
기업을 바라볼때 관점을 설명하면 원천 기술 제작 기업 -> 기업용 솔루션 제작기업 -> 엔드유저용 어플리케이션 제공 기업 이 존재합니다. 마지막의 엔드유저 어플리케이션 제작기업은 사실 자바가 되었든 MS가 되었든 PHP가 되었든 고객에게 서비스만 제공하면 되는 기업이지요(쇼핑몰 같은 곳이라고 생각하시면 됩니다.). 첫번째의 원천기술 제작 기업은 MS나 Sun 같은 회사죠. 결국 기술의 선택이 중요시 되는 것은 중간에 존재하는 기업용 솔루션 제작 기업입니다. 이들은 자신들이 만든 제품이 다른 기업에서 도입되어야만 생존 할수 있는 기업이고, 따라서 가급적 많은 시장을 노리게 됩니다. 그러니 윈도우에서만 돌아가는 솔루션 보다는 윈도우도 포함해서 돌아가는 솔루션을 만드는 것이 더욱 더 유리하게 되죠. (바로 이것 때문에 많은 기업들이 Write once run anywhere라는 모토를 가진 자바에 지대한 관심을 가지게 된 것입니다). 거기에 더 나아가, 표준화를 통해 컴포넌트 단위로도 제품을 팔수 있다라고 하는 J2EE(물론 약간의 거짓말이 포함되어 있습니다만)는 작은 기업들에게 굉장한 매력을 느끼게 하죠.(비슷한 예로 임베디드 시스템에서도 표준화를 통해 컴포넌트 서비스를 제공하자고 하는 OSGi도 존재합니다)
또한 그동안 MS가 보여준 시장 독점에 대한 위기감이 중간에 위치한 회사들로 하여금 반MS 진영을 구축하게 하였고, 여기에 Free (or Open) Software라고 하는 급물살이 더해 지고 있는 것입니다.
정리하자면, 중간에 존재하는 기업용 솔루션 제작 기업들의 요구사항이 반 MS인 것이고(다시 말하면 Open), 이것을 가장 적절하게 지원하고 있는 것이 Linux와 Java인 것입니다. 둘다 무료로 사용할수 있지요.또한 성능 역시 MS 솔루션 못지 않은, 오히려 더 좋은 경우도 있지요. 이들이 만들어 내는 솔루션과 트렌드가 시장에 반영되어 적용되는 것입니다. 결국 Protocol(Platform, format등등의 모두 포함하는 의미로써)을 독점하려고 하는 MS와 Protocol을 공개하여 시장을 공유하려고 하는 반 MS의 요구사항이 만들어내는 경쟁인 것입니다. (최근에는 MS역시 Open의 물결을 타려고 하고 있지요 ^^)
아무개님이 말씀하신 Interoperability는 Open Technology의 부산물입니다. Open되지 않은 기술은 절대로 상호 운영 될수 없습니다. MS가 그토록 노력함에도 불구하고 리눅스용 Win32 API를 제대로 못만들어 내는 것과 비슷합니다. 공개할 수 없기 때문입니다. (오히려 cygwin같은 경우 open된 linux를 Windows로 옮기는 데 대단한 성과를 보여주고 있지요. 최근에는 X-window나 Apache같은 소프트웨어도 구동시킬수 있습니다.) 생각해 보니 완전 독점 상태도 비슷한 현상을 가져 올 듯 싶습니다. 만약 모든 컴퓨터에 Windows 2000만이 설치되어 있다면 프로그램 만들기도 꽤나 편하기늘 할 듯 하군요 ^^;
기업들은 과거에는 상호 운영성 보다는 독점을 노리고 개발을 했습니다만, 인터넷이 보여준, 웹이 보여준 Open Technology가 가져다준 거대한 시장을 목격한 이후로 상호운영성을 중요시 하게 되었지요. 아.. 글이 정말 정리가 않되는 군요^^ 나중에 다시 정리하지요 --안지성
아무개는 다음 몇 가지 이유에서 여러분들의 의견을 더 듣고 싶습니다.
- Interoperability는 Open source의 부산물이라기보다 Standardization의 부산물로 보는 것이 타당합니다. 물론 Open source가 Standardization을 가속화시킬 수 있다고 생각한다면 "Open source가 Interoperability를 향상시키는데에 도움을 준다"는 정도로 생각할 수는 있으나 Interoperability를 위해 Open source가 필요한 것은 아닙니다. 일례로 XML Web Services가 제공하는 Interoperability는 Open source의 부산물이 아닌 Standardization의 결과입니다.
Interoperability는 Standard를 통해 얻어지는 것이 맞습니다. 하지만 Standard 역시 Open된 Standard가 있고 Close된 Standard가 있습니다. 제가 말하고자 하는 것은 OpenTechnology이지 OpenSource 가 아닙니다. 중요한 것은 모든 표준이 성공하지는 못한다는 것이고, 성공하기 위해 가장 중요한 것중에 하나가 Open되어야 한다는 것입니다. MS가 Office를 XML로 표준화 했지만, 정작 지지를 못받는 이유는 Open되지 못했기 때문일겁니다. 물론 MS Office의 시장 독점력때문에 어쩔수 없이 따라가는 회사들도 있을 것이겠습니다만 . 그리고 Close시절에는 별로 지지 받지 못하다가 Open되고나서 성공한 표준의 대표로 SOAP를 들수 있겠지요. MS가 혼자서 SOAP를 들고 나왔을때, 사실 시장에서는 "MS가 만들었다"라고 하는 사실때문에 지지 받지 못했습니다. 하지만 SOAP가 Open되고 사실상 MS의 손에서 벗어나게 되자(여기에는 그당시 XML 기술의 한계사항이 많은 영향을 끼쳤지요 ) 많은 회사들에서 SOAP를 지지했고 이제는 B2B 표준의 핵심으로 자리잡았습니다. --안지성
- 기업용 솔루션 제작기업에서는 자바를 선택하는 것이 유리하다고 하셨지만, 대부분의 기업용 솔루션에 대해서 요구되는 특성은 WORA가 아니라 Interoperability 입니다. 솔루션이 무엇으로 만들어졌는지, 어떤 플렛폼에서 돌아갈 수 있는지 보다는 "어떤 플렛폼과 함께" 사용될 수 있는지가 중요한 경우가 많습니다. 대부분의 기업에 있어서 자신들이 기존에 사용중인 솔루션과 새로운 솔루션 간에 Interoperability가 보장된다면 새로운 솔루션이 Windows 기반이건 Unix 기반이건 중요하지 않다는 것입니다. 아무개가 일하고 있는 회사와 아무개가 일했던 회사, 아무개가 알고 있는 많은 회사들이 바로 이 "중간에 있는" 업체이면서도 MS 솔루션을 개발하고 있습니다. 오히려 예전에 모대기업에 자바로 개발된 솔루션을 납품하려고 하다가 그 솔루션이 "자바" 였기때문에 납품을 못할 뻔 한 적이 두 번이나 있었습니다. 그 이유는 모두 자바는 느리고 불안정하다는 오해 때문이었는데, 간신히 설득할 수 있었습니다.
예, 저도 비슷한 경험이 있습니다. 하지만 최근들어 대부분의 대기업이 자바를 선택하는 것을 저는 목격하고 있지요. 기업에게 임베디드부터 엔터프라이즈까지 일관된 Interoperability와 ServiceIntegration을 제공할수 있는 사실상 유일한 솔루션이 자바이기 때문입니다. OSGi가 대표적인 예가 되겠습니다만, 임베디드 시스템 역시 자바로 진행되어 가고 있습니다. 다시말하면 Interoperability를 해결하기 위해 자바 플랫폼이라는 단일 플랫폼을 선택하는 트렌드를 보여주고 있는 것입니다. 속도와 안정성 문제는 이미 충분한 정도로 해결이 되어 있는 상태이지만, 사람들의 인식은 그렇지가 않아서 저도 많이 고생했습니다만, 최근 대기업들이 겪은 Pain, 즉 통합성문제는 대기업들을 자바쪽으로 돌려놓는데 성공했습니다. 이제 남은 것은 매몰비용이죠 (사실 이게 가장 큰 저항으로 작용하더군요 ) --안지성
- Cygwin과 Win32 API 이야기는 Open source의 중요성을 설명하는 예로써는 적당해보이지만 Interoperability가 Open source의 부산물임을 보여주는 예로써는 적당하지 않아보입니다. Interoperability란 하나의 프로그램을 여러 플렛폼에서 실행하는 것을 의미하는 것이 아니라 서로 다른 플랫폼에서 실행되는 프로그램이 서로 연동되어 실행되는 것을 의미하는 것입니다. --아무개
HTTP라고 하는 GlueProtocol로 인해 거의 모든 솔루션이 서로 상호 작용할수 있는 수단을 가지게 되었습니다. 물론 HTTP의 단점을 이야기 하는 사람도 많습니다만, 이건 대세라고 볼 수 있습니다. HTTP를 기반으로 상호 운용되기 위한 표준으로 XML이 최근에 각광받고 있지요. ebXML이라던가 SOAP, XHTML등등 너무 유명한 XML Application들이 이미 존재하지요. 사실 HTTP와 XML을 기반으로 한다면 자바든 MS솔루션이든 PHP든 뭐가 되었든 상관없이 Interoperability는 보장되죠 이러한 표준들이 어째서 힘을 얻게 되었는가를 생각해 보면 그 힘의 근본에는 OpenTechnology가 깔려 있다는 것입니다.
질문 / 답변 ¶
Q. Java를 처음 공부해보려고 하는데, 어떻게 하는게 좋을지 가르쳐 주세요. 우선 Java Language Specification이라는 책(e- book)을 볼까 하는데요. 이 책 괜찮나요? C++은 어느정도 할 줄 아는 수준입니다.
A. 읽어보진 않았습니다만, 일반적으로 "... Specification", "... Programming Language" 등을 제목으로 하는 책들은 대체로 프로그램 언어를 정의한 책들입니다. 즉, 프로그래밍 언어를 구현하여 판매할 회사들의 프로그래머들이 주로 본다고 생각하면 될만한 책들입니다. 혹은 이미 어느정도 수준 이상으로 해당 프로그래밍 언어를 잘 사용할 때 주로 사전처럼 볼 양으로 사용합니다. 그런 책들보다는 그 언어로 프로그래밍 하는 법을 가르쳐주는 책을 보는 것이 좋을 듯 하군요.
A. Specification은 말그대로 언어명세입니다. 문법같은 걸 정의 해놓은 책이죠. 처음 배울려고 하는 사람에게는 별 도움이 안됩니다. 다른 OOL을 많이 써보셨다면 The Java Programming Language( 
0201704331 )를 권합니다. 그리고 자바는 언어자체도 중요하지만 사용할려고 하는 목적에 맞는 API를 익히는 것이 중요합니다. 다른 OOL을 잘 모르신다면 튜토리얼류의 책이 좋습니다. 제가 직접 보지는 않았지만 소문에 의하면 Thinking In Java( 0130273635 )가 좋다고 합니다(http://www.mindview.net/Books 에 가시면 Thinking In Java 2판과 3판beta에 대한 PDF 문서를 무료로 받아보실 수 있습니다).
0201704331 )를 권합니다. 그리고 자바는 언어자체도 중요하지만 사용할려고 하는 목적에 맞는 API를 익히는 것이 중요합니다. 다른 OOL을 잘 모르신다면 튜토리얼류의 책이 좋습니다. 제가 직접 보지는 않았지만 소문에 의하면 Thinking In Java( 0130273635 )가 좋다고 합니다(http://www.mindview.net/Books 에 가시면 Thinking In Java 2판과 3판beta에 대한 PDF 문서를 무료로 받아보실 수 있습니다).A: 개인적으로 JavaTutorial을 두번정도 읽고 제임스고슬링의 자바라는 책을 공부하시길 권합니다. 아마 다른 프로그래밍 언어를 배우셨다면 이 코스가 가장 빠르게 자바를 배울수 있는 코스가 아닐까 생각 됩니다.