프로그램 언어의 선택
많은 개발자들이 쉬운 프로그램언어 보다는 어려운 프로그램 언어를 선호하는 오류를 범한다.
코볼보다 C 언어를 선호하고 비주얼베이직보다 파워빌드나 자바를 선호한다.
왜? 어려우니까. 그래서 자기만이 할수 있다는 잘못된 도취감에 빠질 수 있으니까.
하지만 이는 분명 잘못된 생각이다.
전자제품의 사용이 갈수록 간편해지고 쉬워지듯이 단말의 사용자환경이 점점 쉬워지고 간편해지듯이
프로그래머에게는 프로그램 언어는 우선 쉬워야 한다.
그리고 요즘과 같이 모든 프로그램이 GUI를 기반으로 하는 경우에는
프로그램 언어의 쉬움과 함께 개발환경 역시 쉬워야 한다.
그래서 반드시 GUI 개발환경을 선택시에는 다음의 3가지를 고려하여야 한다.
- 유지보수를 포함한 개발의 용이성
- 개발환경의 편리성
- 개발 컴포넌트의 확장가능성
여러분도 아시다시피 처음에 Client/Server 환경기반의 RAD툴들이 소개되었을때
많은 개발자들이 파워빌드를 선호했다.
처음에는 그 기능이 화려했고 무엇보다도 완전하지는 않았지만
객체지향언어의 모습을 갖추었기 때문이었다.
하지만 개발환경에서 특히 호환성이나 확장성면에서 점점 Visual Basic에 떨어지기 시작했고
이로 인해 대부분의 개발자들이 Visual Basic으로 전환하게 되었다.
세계 PC OS 시장의 90%를 잠식한 MS의 영향력은 개발툴에서도 위력을 발휘했다.
OLE를 통한 단말 OS와의 거의 완벽한 호환성, Event Driven 방식의 빠른 개발 환경,
PC GUI 전문 OS업체로서의 사용자 편리성 제공 등과
그리고 미국내에 3천개가 넘는다는 MS 기반의 컴포넌트 개발업체가 컴포넌트의 확장성을 제공했다.
사실 비주얼베이직은 이러한 기본 프레임워크를 아주 쉽게 확장이 편리하도록 하는 기능만 제공했다.
결국 비주얼베이직의 성공은 오히려 이러한 Third Party업체들의 공로라고 할 수 있다.
내가 이렇게 말하면 왜 자바가 어려운 언어이냐 라고 반문하는 사람들도 있을 것이다.
물론 자바는 어려운 언어는 아니다. 정확히 말하자면 다른 쉬운 언어들에 비해서는
비교적 어려운 언어라는 표현과 이언어를 둘러싸고 있는 환경적인 요소가 어렵다는
표현이 더 정확하다고 할 수 있다.
객체지향이 어렵고, EJB, 그리고 벤더별로 다른 J2EE 환경 및 이로 인하여
정확한 표준이 없고 앞으로도 쉽게 바뀔 수 있다는 점들이 우리를 헷갈리고 어렵게 한다는 얘기다.
객체지향의 개념을 정확히 모르는 사람들이 자바의 우수성을 논하는 것은 적절하지 않다.
그래서 자바를 이야기하기 전에 우리는 우선 객체지향의 개념을 정확히 이해하여야 한다.
객체지향을 제대로 모르는 개발자들이 자바로 프로그램을 한다면
이는 앙코없는 붕어빵과 같기 때문이다.
왜냐하면 자바는 순수 객체지향언어이기 때문이다.
이는 집을 지을 때 설계없이 하는 부실공사와 다를 것이 없기 때문이다.
그런데 객체지향은 어렵다.여러분이 생각하듯이 쉬운 것이 결코 아니다.
그런데 자바가 쉽다고 과연 말할 수 있을까?
비주얼베이직이 쉽다는 것은 언어 자체 보다도 개발환경이 쉽기 때문이다.
자바는 언어자체로서는 C++에 비해서는 분명히 쉽고 편리한 언어임에는 틀림없다.
우선 포인터가 없어서 편하고 Garbage Collection에 대해서 신경쓰지 않아도 되고...
하지만 아직도 자바를 둘러싸고 있는 환경은 여전히 어렵기만 하다.
그런데도 아직도 많은 개발자들이 자바에 집착하고 있다.이름이 좋아서인지는 몰라도
기냥 사람을 '자바'비려 가지고 거의 한번 맛을 들이면 빠져나오지 못하게 하는 히로뽕
내지는 사이비 종교와 같다.
왜일까? 역시 앞에서 말했듯이 그들은 역시 어렵기 때문에 좋은 것이다.
솔직히 다른 사람들이 쉽게 할 수 없으니까 좋은 것이다.
옛날 양반네들이 상놈들이 한문을 모르니까 한문을 숭배했듯이...
사실 처음에 HTML이 나왔을때 프로그래머중의 한사람이었던 나도
프로그래머가 아닌 누구나 홈페이지를 만들어 대는 것을 보고
무지하게 기분 나빴으니까...
하지만 그렇다고 하더라도 프로그램 언어는 쉬워야 한다.
이유는 간단하다.개발은 쉽고 빠르게 누구나 쉽게 할 수 있는 것이 장땡이니까...
J2EE와 .NET
웹개발환경은 여러분이 생각하는 것처럼 결코 쉽지가 않다.
특히 업무를 웹으로 구현하는 것이 기존의 C/S만큼 쉽지가 않다.
이것은 단순한 개인 홈페이지 구축하는 것과는 차원이 다른 얘기이다.
기존의 C/S 보다 거의 2배 이상의 공수를 들이면서도 우리가 과연 웹으로 개발하여야 하는가?
기업환경에서의 웹플랫폼 도입배경은 사실 그것이 꼭 필요해서라기 보다는 New Trend에 의한 경향이 강했다.
그래서 초기에 웹환경을 구축한 부분의 기업이 적절한 검증이 없이 기술적인 동향이나 유행,
인터넷의 보편화 등에 대한 막연한 기대심리 등으로 웹환경을 채택하였다.
사실 웹환경의 장점이라면 단말 관리의 용이성, 즉 과거 C/S가 가지고 있던 프로그램 배포 등의 문제를 해결할 수 있다는 것,
그리고 인터넷의 발달로 사용자에게 친숙한 환경이라는것 외에는 별로 없다.
오히려 개발 비용 및 이에 대한 관리 비용, 급변하는 기술로 인한 개발자의 부담은 더욱 가중되었다.
이는 결국 기업의 비용과도 직결되는 문제이기 때문에 쉬운 웹개발환경이 무엇보다도 중요하다는 것이다.
나는 사실 J2EE와 .NET의 기술적인 구조나 공정하지 않은 각종 벤치마크자료를 가지고
장단점을 비교하는 것은 적절하지 않다고 생각한다.
IT회사라면 기술적인 아키텍쳐보다는 기업의 비용과 직결되는 쉬운 개발환경에 촛점을 맞추어야 하기 때문이다.
결국은 TCO 관점에서 냉정하게 비교 판단하여야 된다는 것이다.
그리고 앞으로 아키텍쳐를 선택하여 시스템을 구축하였을때 얼마나 우리가 오래 쓸 수 있고
앞으로의 Trend에 적합하게 시스템을 발전시켜 나갈 수 있는가 하는 비전적인 측면도 고려하여야 한다.
앞에서 GUI 개발환경을 선택시에는 고려해야 할 3가지를 말했듯이
동일한 관점에서 우리는 양쪽을 비교해볼 필요가 있다.
사실 J2EE나 .NET이나 기본적인 구현 아키텍쳐 측면에서는 별 차이가 없다고 볼 수도 있다.
두개의 아키텍쳐가 발생한 동기나 추구하는 목적은 동일하고 단지 구현의 메카니즘과 환경이 틀리다는 것 뿐이다.
양쪽 모두가 보다 나은 웹구현 기술을 위한 것이고 객체지향을 기본으로 설계되었다.
어느 아키텍쳐가 좋은가를 논하기 전에 양쪽의 분명하고 심각한 차이를 짚어 보자.
우선 J2EE는 플랫폼 독립적인 환경이다. 반면에 .NET은 개발언어 독립적인 환경이다.
나는 이 두가지의 차이점을 이 한마디로 말하고 싶다.
내가 이 차이점을 말하고자 하는 것은 이 차이점에 대해서 대부분의 개발자들이 크게 착각하고 있는 부분이 있기 때문이다.
개발자들이 생각하기에는 당연히 플랫폼 독립적인 환경이 우수한 것이 아니냐고 할 것이다.
하지만 Sun의 J2EE 버전은 많은 벤더들이 구현할 수 있는 개방적 구조의 멤버들로 구성되어 있다.
모든 기업이 이 기술을 라이센스하여 구현할 수 있다는 점에서 개방적이지만, Sun에 의해 통제되며,
Java 이외의 다른 기술과 연동될 수 있는 가능성이 매우 적다는 면에서는 한편으로 폐쇄적인 기술이기도 하다.
Sun이 장점으로 내세우는 이러한 개방성/이식성이 오히려 시스템의 진화로 인한 다중성을 증가시켜
특정 Vender에 종속적인 각종 시스템 모델로 발전되고 있으며 이러한 모순과 이에 따른 시스템의
역폐쇄적인 영향을 우리는 UNIX 시스템에서도 경험하였다.
만약에 MS의 또다른 표준아키텍쳐가 있는데 MS와 유사한 수준의 또다른 2개의 OS Vender가 있고
이 두업체는 동일한 플랫폼을(예를 들어 변형된 Win2000 같은) 제공하고 있다는 가정을 해보자.
그러면 원래 제안된 표준이 이 두업체간에 완벽하게 일치되게 유지될 수 있을 것인가를 생각해보라.
결국 두업체가 제공하는 개발환경은 Vender가 다르면 동일한 종류의 OS 플랫폼일지라도 달라질 수 밖에 없을 것이다.
개발환경이란 이런 것이다.
개발방법론이나 아키텍쳐는 그것이 하나의 개념으로서 또는 표준으로서 제안될 수 있지만
다수의 Vender가 제공하는 개발환경이나 툴은 결코 표준이 될 수 없다.
이는 MS가 제공하는 아키텍쳐 표준기술이 업계표준이 될 수 없는 것과 마찬가지 이치인 것이다.
그래서 Sun에서 얘기하는 플랫폼 독립적인 개발환경은 결국 허구가 된다는 것이다.
나는 많은 Unix Vender들이 Sun이 제안한 J2EE의 표준을 준수하리라고 생각하지 않는다.
결국 Sun의 J2EE를 모태로 IBM의 J2EE, HP의 J2EE, Oracle의 J2EE 이런식으로 변형될 것이다.
같은 OS(Unix)도 Vender별로 다른데 하물며 개발 아키텍쳐가 동일하게 유지되겠는가?
Sun OS J2EE 환경에서 개발한 자바빈즈가 IBM OS J2EE 환경에서 돌아 가지 않는다면
이게 과연 플랫폼 독립적인 환경이라고 할 수 있는가?
엄밀히 말해서 H/W 독립적인 아키텍쳐란 있을 수가 없다는 모순을 잘 모르는 사람들이 많다는 것이다.
그래서 자바진영에서 가장큰 장점으로 이야기하는 플랫폼 독립적인 아키텍쳐 구조는
결국 실제로는 별다른 장점이 되지를 못한다는 얘기다.
그러면 .Net의 개발언어 독립적인 환경이란 무엇인가?
물론 MS .Net은 분명히 MS 플랫폼에 종속적인 아키텍쳐이다.
하지만 J2EE가 오직 Java 언어로 제한되는데 반해 .NET은 VB, C/C++, VB, C#, 심지어 코볼언어까지도 지원한다.
이는 또다른 측면에서 시사하는 바가 있다고 할 수 있다.
J2EE는 이후 Java 보다 더욱 우수한 개발언어가 나오면 완전히 버려야 하지만
.NET은 또다른 좋은 개발언어가 나오더라도 대응할 수 있다는 논리가 된다.
즉 플랫폼 독립적인 환경이 결국은 자바 종속적인 환경이 되어 버린다는 논리적인 모순이 발생한다.
적어도 개발자는 프로그램 언어로부터 자유로워야 하고 선택의 권리가 있다.
영어만을 써야 한다고 강요할 수 없듯이 프로그램 언어의 자바 종속성은 앞으로의 IT 발전에 역행하는 것이 아닐까?
MS의 독주를 시기하는 사람들이 왜 자바의 독주를 슬로건으로 들고 나오는가?
따라서 시스템 독립적인 아키텍쳐와 언어독립적인 아키텍쳐 두가지 중에서 우리는 과연 어떤 것을 선택하여야 할 것인지를
신중하게 생각하여야 한다. 앞으로 더 좋은 프로그램 언어가 나올 수도 있고 시스템에 무관하게 돌아가기 위하여
반드시 자바이어야 한다는 논리와 언어와는 무관하려면 윈도우즈이어야 한다는 논리가 무엇이 다른가?
마찬가지로 업체의 독선이라는 것이다. 그리고 자바는 아직 표준이 아니다.
그리고 이런 이유 때문에 앞으로도 표준이 될 수가 없을 것이다.
따라서 인터넷 기술의 확산 및 발전을 놓고 볼때 모든 것을 자바 언어로 통일하는 것은 바람직하지 않다.
왜 .NET인가?
역시 앞에서도 말했듯이 J2EE와 .NET의 기술적인 구조나 공정하지 않은 각종 벤치마크자료를 가지고
.NET을 선택하여야 한다고 말할 수 없다고 생각한다.
벤치마크 자료를 가지고 비교하려면 양쪽 아키텍쳐에 대해서 다 알아야 하고
실전 경험과 더불어 양쪽 플랫폼의 구조나 특성, 장단점에 대해서도 정확히 알아야 한다.
과연 그런 능력을 가진 사람이 몇이나 될까?
그런데도 국내개발자들은 어이없게도 이런 자료들을 기술적인 기초도 없이
쉽게 믿어버리거나 한쪽의 경험만을 가지고 섣불리 판단해 버리는 우를 범한다.
이는 단언하건데 분명히 잘못된 비교접근 방식이다.
그보다는 차라리 이전의 사례를 살펴보는 것이 바람직하다고 생각한다.
과거 없는 미래가 없기 때문에...이는 결국 향후 비젼과도 무관하지 않다.
처음에 Visual Basic이 나왔을때를 생각해 보면 .NET의 가능성에 나는 높은 점수를 주고 싶다.
처음에 VB가 소개되었을 때 많은 개발자들이 수많은 혹평을 했고
VC++이나 파워빌드 비교하여 초라한 기능에 사실 나자신도 거들떠 보지도 않았다.
하지만 MS는 이를 계속 발전시켜 나갔으며 Windows OS의 막강한 위력과
그들과 함께하는 Third Party 컴포넌트 개발자들의 힘을 잘 이용하여
지금은 C/S환경에 있어서는 최고의 RAD툴이 되어 버렸다.
얼마전까지만 하더라도 전세계 RAD툴 사용자의 70% 이상이 VB를 사용하였다는 통계가 있었으니까.
Visual Studio가 모든 것을 제공하지는 않지만 C/S 환경에서 확장이 가능한 단단한 틀(Framework)을
제공하여 관련업체의 참여를 유도함으로써 누구도 예상하지 못한 시너지 효과를 창출하였듯이
Visual Studio .NET도 웹환경에서 이와 비슷한 틀을 제공하고 있다.
웹개발환경의 어려움을 몸소 체험하였던 나로서는 아직은 미약하지만
MS의 이러한 웹기반의 새로운 개념의 RAD 접근 메소드 제공이
결국 수많은 Third Party 업체들의 위력에 의하여 VB와 똑같은 결과로 몇년안에 나타 나리라고 감히 예상한다.
벌써부터 수많은 업체들이 .NET 기반의 Thin Client용 서버컨트롤들을 생산하기 시작하였고
웹사이트에서 이중에 일부는 Download 하거나 구입하여 사용할 수가 있다.
또한가지 Windows가 없었다면 VB도 없었듯이 인터넷익스플로러가 있기 때문에 .Net은 또한 성공하리라는
예상도 할 수 있다.이제는 넷스케이프 사용자는 거의 없으므로...
그리고 무엇보다도 .NET은 개발자에게 J2EE보다 쉬운 개발환경과 친숙한 GUI를 제공한다는 사실이다.
Why .Net?Because the ease is the best.
많은 개발자들이 쉬운 프로그램언어 보다는 어려운 프로그램 언어를 선호하는 오류를 범한다.
코볼보다 C 언어를 선호하고 비주얼베이직보다 파워빌드나 자바를 선호한다.
왜? 어려우니까. 그래서 자기만이 할수 있다는 잘못된 도취감에 빠질 수 있으니까.
하지만 이는 분명 잘못된 생각이다.
전자제품의 사용이 갈수록 간편해지고 쉬워지듯이 단말의 사용자환경이 점점 쉬워지고 간편해지듯이
프로그래머에게는 프로그램 언어는 우선 쉬워야 한다.
그리고 요즘과 같이 모든 프로그램이 GUI를 기반으로 하는 경우에는
프로그램 언어의 쉬움과 함께 개발환경 역시 쉬워야 한다.
그래서 반드시 GUI 개발환경을 선택시에는 다음의 3가지를 고려하여야 한다.
- 유지보수를 포함한 개발의 용이성
- 개발환경의 편리성
- 개발 컴포넌트의 확장가능성
여러분도 아시다시피 처음에 Client/Server 환경기반의 RAD툴들이 소개되었을때
많은 개발자들이 파워빌드를 선호했다.
처음에는 그 기능이 화려했고 무엇보다도 완전하지는 않았지만
객체지향언어의 모습을 갖추었기 때문이었다.
하지만 개발환경에서 특히 호환성이나 확장성면에서 점점 Visual Basic에 떨어지기 시작했고
이로 인해 대부분의 개발자들이 Visual Basic으로 전환하게 되었다.
세계 PC OS 시장의 90%를 잠식한 MS의 영향력은 개발툴에서도 위력을 발휘했다.
OLE를 통한 단말 OS와의 거의 완벽한 호환성, Event Driven 방식의 빠른 개발 환경,
PC GUI 전문 OS업체로서의 사용자 편리성 제공 등과
그리고 미국내에 3천개가 넘는다는 MS 기반의 컴포넌트 개발업체가 컴포넌트의 확장성을 제공했다.
사실 비주얼베이직은 이러한 기본 프레임워크를 아주 쉽게 확장이 편리하도록 하는 기능만 제공했다.
결국 비주얼베이직의 성공은 오히려 이러한 Third Party업체들의 공로라고 할 수 있다.
내가 이렇게 말하면 왜 자바가 어려운 언어이냐 라고 반문하는 사람들도 있을 것이다.
물론 자바는 어려운 언어는 아니다. 정확히 말하자면 다른 쉬운 언어들에 비해서는
비교적 어려운 언어라는 표현과 이언어를 둘러싸고 있는 환경적인 요소가 어렵다는
표현이 더 정확하다고 할 수 있다.
객체지향이 어렵고, EJB, 그리고 벤더별로 다른 J2EE 환경 및 이로 인하여
정확한 표준이 없고 앞으로도 쉽게 바뀔 수 있다는 점들이 우리를 헷갈리고 어렵게 한다는 얘기다.
객체지향의 개념을 정확히 모르는 사람들이 자바의 우수성을 논하는 것은 적절하지 않다.
그래서 자바를 이야기하기 전에 우리는 우선 객체지향의 개념을 정확히 이해하여야 한다.
객체지향을 제대로 모르는 개발자들이 자바로 프로그램을 한다면
이는 앙코없는 붕어빵과 같기 때문이다.
왜냐하면 자바는 순수 객체지향언어이기 때문이다.
이는 집을 지을 때 설계없이 하는 부실공사와 다를 것이 없기 때문이다.
그런데 객체지향은 어렵다.여러분이 생각하듯이 쉬운 것이 결코 아니다.
그런데 자바가 쉽다고 과연 말할 수 있을까?
비주얼베이직이 쉽다는 것은 언어 자체 보다도 개발환경이 쉽기 때문이다.
자바는 언어자체로서는 C++에 비해서는 분명히 쉽고 편리한 언어임에는 틀림없다.
우선 포인터가 없어서 편하고 Garbage Collection에 대해서 신경쓰지 않아도 되고...
하지만 아직도 자바를 둘러싸고 있는 환경은 여전히 어렵기만 하다.
그런데도 아직도 많은 개발자들이 자바에 집착하고 있다.이름이 좋아서인지는 몰라도
기냥 사람을 '자바'비려 가지고 거의 한번 맛을 들이면 빠져나오지 못하게 하는 히로뽕
내지는 사이비 종교와 같다.
왜일까? 역시 앞에서 말했듯이 그들은 역시 어렵기 때문에 좋은 것이다.
솔직히 다른 사람들이 쉽게 할 수 없으니까 좋은 것이다.
옛날 양반네들이 상놈들이 한문을 모르니까 한문을 숭배했듯이...
사실 처음에 HTML이 나왔을때 프로그래머중의 한사람이었던 나도
프로그래머가 아닌 누구나 홈페이지를 만들어 대는 것을 보고
무지하게 기분 나빴으니까...
하지만 그렇다고 하더라도 프로그램 언어는 쉬워야 한다.
이유는 간단하다.개발은 쉽고 빠르게 누구나 쉽게 할 수 있는 것이 장땡이니까...
J2EE와 .NET
웹개발환경은 여러분이 생각하는 것처럼 결코 쉽지가 않다.
특히 업무를 웹으로 구현하는 것이 기존의 C/S만큼 쉽지가 않다.
이것은 단순한 개인 홈페이지 구축하는 것과는 차원이 다른 얘기이다.
기존의 C/S 보다 거의 2배 이상의 공수를 들이면서도 우리가 과연 웹으로 개발하여야 하는가?
기업환경에서의 웹플랫폼 도입배경은 사실 그것이 꼭 필요해서라기 보다는 New Trend에 의한 경향이 강했다.
그래서 초기에 웹환경을 구축한 부분의 기업이 적절한 검증이 없이 기술적인 동향이나 유행,
인터넷의 보편화 등에 대한 막연한 기대심리 등으로 웹환경을 채택하였다.
사실 웹환경의 장점이라면 단말 관리의 용이성, 즉 과거 C/S가 가지고 있던 프로그램 배포 등의 문제를 해결할 수 있다는 것,
그리고 인터넷의 발달로 사용자에게 친숙한 환경이라는것 외에는 별로 없다.
오히려 개발 비용 및 이에 대한 관리 비용, 급변하는 기술로 인한 개발자의 부담은 더욱 가중되었다.
이는 결국 기업의 비용과도 직결되는 문제이기 때문에 쉬운 웹개발환경이 무엇보다도 중요하다는 것이다.
나는 사실 J2EE와 .NET의 기술적인 구조나 공정하지 않은 각종 벤치마크자료를 가지고
장단점을 비교하는 것은 적절하지 않다고 생각한다.
IT회사라면 기술적인 아키텍쳐보다는 기업의 비용과 직결되는 쉬운 개발환경에 촛점을 맞추어야 하기 때문이다.
결국은 TCO 관점에서 냉정하게 비교 판단하여야 된다는 것이다.
그리고 앞으로 아키텍쳐를 선택하여 시스템을 구축하였을때 얼마나 우리가 오래 쓸 수 있고
앞으로의 Trend에 적합하게 시스템을 발전시켜 나갈 수 있는가 하는 비전적인 측면도 고려하여야 한다.
앞에서 GUI 개발환경을 선택시에는 고려해야 할 3가지를 말했듯이
동일한 관점에서 우리는 양쪽을 비교해볼 필요가 있다.
사실 J2EE나 .NET이나 기본적인 구현 아키텍쳐 측면에서는 별 차이가 없다고 볼 수도 있다.
두개의 아키텍쳐가 발생한 동기나 추구하는 목적은 동일하고 단지 구현의 메카니즘과 환경이 틀리다는 것 뿐이다.
양쪽 모두가 보다 나은 웹구현 기술을 위한 것이고 객체지향을 기본으로 설계되었다.
어느 아키텍쳐가 좋은가를 논하기 전에 양쪽의 분명하고 심각한 차이를 짚어 보자.
우선 J2EE는 플랫폼 독립적인 환경이다. 반면에 .NET은 개발언어 독립적인 환경이다.
나는 이 두가지의 차이점을 이 한마디로 말하고 싶다.
내가 이 차이점을 말하고자 하는 것은 이 차이점에 대해서 대부분의 개발자들이 크게 착각하고 있는 부분이 있기 때문이다.
개발자들이 생각하기에는 당연히 플랫폼 독립적인 환경이 우수한 것이 아니냐고 할 것이다.
하지만 Sun의 J2EE 버전은 많은 벤더들이 구현할 수 있는 개방적 구조의 멤버들로 구성되어 있다.
모든 기업이 이 기술을 라이센스하여 구현할 수 있다는 점에서 개방적이지만, Sun에 의해 통제되며,
Java 이외의 다른 기술과 연동될 수 있는 가능성이 매우 적다는 면에서는 한편으로 폐쇄적인 기술이기도 하다.
Sun이 장점으로 내세우는 이러한 개방성/이식성이 오히려 시스템의 진화로 인한 다중성을 증가시켜
특정 Vender에 종속적인 각종 시스템 모델로 발전되고 있으며 이러한 모순과 이에 따른 시스템의
역폐쇄적인 영향을 우리는 UNIX 시스템에서도 경험하였다.
만약에 MS의 또다른 표준아키텍쳐가 있는데 MS와 유사한 수준의 또다른 2개의 OS Vender가 있고
이 두업체는 동일한 플랫폼을(예를 들어 변형된 Win2000 같은) 제공하고 있다는 가정을 해보자.
그러면 원래 제안된 표준이 이 두업체간에 완벽하게 일치되게 유지될 수 있을 것인가를 생각해보라.
결국 두업체가 제공하는 개발환경은 Vender가 다르면 동일한 종류의 OS 플랫폼일지라도 달라질 수 밖에 없을 것이다.
개발환경이란 이런 것이다.
개발방법론이나 아키텍쳐는 그것이 하나의 개념으로서 또는 표준으로서 제안될 수 있지만
다수의 Vender가 제공하는 개발환경이나 툴은 결코 표준이 될 수 없다.
이는 MS가 제공하는 아키텍쳐 표준기술이 업계표준이 될 수 없는 것과 마찬가지 이치인 것이다.
그래서 Sun에서 얘기하는 플랫폼 독립적인 개발환경은 결국 허구가 된다는 것이다.
나는 많은 Unix Vender들이 Sun이 제안한 J2EE의 표준을 준수하리라고 생각하지 않는다.
결국 Sun의 J2EE를 모태로 IBM의 J2EE, HP의 J2EE, Oracle의 J2EE 이런식으로 변형될 것이다.
같은 OS(Unix)도 Vender별로 다른데 하물며 개발 아키텍쳐가 동일하게 유지되겠는가?
Sun OS J2EE 환경에서 개발한 자바빈즈가 IBM OS J2EE 환경에서 돌아 가지 않는다면
이게 과연 플랫폼 독립적인 환경이라고 할 수 있는가?
엄밀히 말해서 H/W 독립적인 아키텍쳐란 있을 수가 없다는 모순을 잘 모르는 사람들이 많다는 것이다.
그래서 자바진영에서 가장큰 장점으로 이야기하는 플랫폼 독립적인 아키텍쳐 구조는
결국 실제로는 별다른 장점이 되지를 못한다는 얘기다.
그러면 .Net의 개발언어 독립적인 환경이란 무엇인가?
물론 MS .Net은 분명히 MS 플랫폼에 종속적인 아키텍쳐이다.
하지만 J2EE가 오직 Java 언어로 제한되는데 반해 .NET은 VB, C/C++, VB, C#, 심지어 코볼언어까지도 지원한다.
이는 또다른 측면에서 시사하는 바가 있다고 할 수 있다.
J2EE는 이후 Java 보다 더욱 우수한 개발언어가 나오면 완전히 버려야 하지만
.NET은 또다른 좋은 개발언어가 나오더라도 대응할 수 있다는 논리가 된다.
즉 플랫폼 독립적인 환경이 결국은 자바 종속적인 환경이 되어 버린다는 논리적인 모순이 발생한다.
적어도 개발자는 프로그램 언어로부터 자유로워야 하고 선택의 권리가 있다.
영어만을 써야 한다고 강요할 수 없듯이 프로그램 언어의 자바 종속성은 앞으로의 IT 발전에 역행하는 것이 아닐까?
MS의 독주를 시기하는 사람들이 왜 자바의 독주를 슬로건으로 들고 나오는가?
따라서 시스템 독립적인 아키텍쳐와 언어독립적인 아키텍쳐 두가지 중에서 우리는 과연 어떤 것을 선택하여야 할 것인지를
신중하게 생각하여야 한다. 앞으로 더 좋은 프로그램 언어가 나올 수도 있고 시스템에 무관하게 돌아가기 위하여
반드시 자바이어야 한다는 논리와 언어와는 무관하려면 윈도우즈이어야 한다는 논리가 무엇이 다른가?
마찬가지로 업체의 독선이라는 것이다. 그리고 자바는 아직 표준이 아니다.
그리고 이런 이유 때문에 앞으로도 표준이 될 수가 없을 것이다.
따라서 인터넷 기술의 확산 및 발전을 놓고 볼때 모든 것을 자바 언어로 통일하는 것은 바람직하지 않다.
왜 .NET인가?
역시 앞에서도 말했듯이 J2EE와 .NET의 기술적인 구조나 공정하지 않은 각종 벤치마크자료를 가지고
.NET을 선택하여야 한다고 말할 수 없다고 생각한다.
벤치마크 자료를 가지고 비교하려면 양쪽 아키텍쳐에 대해서 다 알아야 하고
실전 경험과 더불어 양쪽 플랫폼의 구조나 특성, 장단점에 대해서도 정확히 알아야 한다.
과연 그런 능력을 가진 사람이 몇이나 될까?
그런데도 국내개발자들은 어이없게도 이런 자료들을 기술적인 기초도 없이
쉽게 믿어버리거나 한쪽의 경험만을 가지고 섣불리 판단해 버리는 우를 범한다.
이는 단언하건데 분명히 잘못된 비교접근 방식이다.
그보다는 차라리 이전의 사례를 살펴보는 것이 바람직하다고 생각한다.
과거 없는 미래가 없기 때문에...이는 결국 향후 비젼과도 무관하지 않다.
처음에 Visual Basic이 나왔을때를 생각해 보면 .NET의 가능성에 나는 높은 점수를 주고 싶다.
처음에 VB가 소개되었을 때 많은 개발자들이 수많은 혹평을 했고
VC++이나 파워빌드 비교하여 초라한 기능에 사실 나자신도 거들떠 보지도 않았다.
하지만 MS는 이를 계속 발전시켜 나갔으며 Windows OS의 막강한 위력과
그들과 함께하는 Third Party 컴포넌트 개발자들의 힘을 잘 이용하여
지금은 C/S환경에 있어서는 최고의 RAD툴이 되어 버렸다.
얼마전까지만 하더라도 전세계 RAD툴 사용자의 70% 이상이 VB를 사용하였다는 통계가 있었으니까.
Visual Studio가 모든 것을 제공하지는 않지만 C/S 환경에서 확장이 가능한 단단한 틀(Framework)을
제공하여 관련업체의 참여를 유도함으로써 누구도 예상하지 못한 시너지 효과를 창출하였듯이
Visual Studio .NET도 웹환경에서 이와 비슷한 틀을 제공하고 있다.
웹개발환경의 어려움을 몸소 체험하였던 나로서는 아직은 미약하지만
MS의 이러한 웹기반의 새로운 개념의 RAD 접근 메소드 제공이
결국 수많은 Third Party 업체들의 위력에 의하여 VB와 똑같은 결과로 몇년안에 나타 나리라고 감히 예상한다.
벌써부터 수많은 업체들이 .NET 기반의 Thin Client용 서버컨트롤들을 생산하기 시작하였고
웹사이트에서 이중에 일부는 Download 하거나 구입하여 사용할 수가 있다.
또한가지 Windows가 없었다면 VB도 없었듯이 인터넷익스플로러가 있기 때문에 .Net은 또한 성공하리라는
예상도 할 수 있다.이제는 넷스케이프 사용자는 거의 없으므로...
그리고 무엇보다도 .NET은 개발자에게 J2EE보다 쉬운 개발환경과 친숙한 GUI를 제공한다는 사실이다.
Why .Net?Because the ease is the best.
'개발 관련 글' 카테고리의 다른 글
[Coding Contest] Most Useful/Innovative VS.Net Add-in/Macro (and some huge prizes) (0) | 2005.05.21 |
---|---|
Forum 2000 Keynote: Bill Gates의 .NET 기조 연설 (0) | 2005.05.14 |
사이트 속도에 목숨 걸 필요 없다 (0) | 2005.04.12 |
온라인 구매율이 100%가 못되는 이유 (0) | 2005.04.12 |
윤종용부회장 "청년들이여, 정신 차려라" (0) | 2005.03.29 |