리플이 늦어 죄송하네요.
요즘 쉴새없이 울어대는 애기때문에 정신이 없습니다.
늦었지만, 궁그미님의 글에 대해서 추가로 제 의견을 써보겠습니다.

ASP.NET의 웹폼이 인트라넷에 더 적합하다..라는 말을 잘 이해하지 못하신 듯 해서 다시 설명하면..

웹폼이 인터넷 사이트에 멋지게 응용될 수 있을 거라는 생각은 대부분 윈도우 GUI 개발자들의 머리에서
나온 것입니다. 인터넷 사이트의 디자인에서 책임과 실무를 담당하는 웹 기획자나 웹 디자이너에게
웹폼을 보여주면 그거 멋지네... 정도의 반응밖에 나오지 않습니다. 윈도우 환경보다 훨씬 화려한
웹사이트에 쓰기엔 너무 딱딱하고 디자인 컨셉을 맞추기가 쉽지 않기 때문입니다.

또한 ASP/JSP/PHP 등의  HTML 임베드된 스크립트의 단점으로 지적되는, 코드와 디자인이 혼재됨으로써
오는 작업의 혼선 면에서도 개선점이 없습니다. 개발자와 디자이너가 영역을 다투게 되는 것입니다.

인터넷 사이트의 기획은 구조와 디자인이 거의 다라고 할 정도로, 기능은 부수적인 중요도만을
가지고 있습니다. 이에 반해서 웹폼은 기능에 주력하기 위한 기술인데 디자인에는 걸리적거립니다.

이와는 반대로, 인트라넷 사이트... 그러니까 ERP/CRM/SCM/KP/EP/EIP 등에서는 디자인의 중요도가
뒤로 밀려나고 기능이 가장 중요한 요소가 됩니다. 그래서 웹폼이 인트라넷에 더 적합하다고 한
것입니다. 그리고 실제로도 웹폼과 아주 유사한 형태의 기능들이 이런 인트라넷 사이트에 사용되고
있습니다. (저도 간접적으로 그런 프로젝트에 참여하고 있기도 하고...)

실제로 MS의 의도를 추측해봐도, MS가 인터넷 사이트 서버 부문에서 리눅스와 경쟁하려고 ASP.NET을
고안했을 가능성은 적습니다. 닷넷의 주요 타겟이 엔터프라이즈 부문이기 때문에, ASP.NET이
인트라넷에 적합한 것은 MS의 의도에도 딱 맞아떨어집니다.


닷넷에서의 자바 애플릿과 비슷한 형태에 대해서는... 뭐 저로서는 첨 듣습니다만...
좀 회의적인 생각부터 드는군요.

직접 만들어보신 프로젝트의 결과물이 30k 정도를 넘지 않으니, 일반적인 애플리케이션들도 그정도를
넘지 않을 거라고 생각하시는 것은 좀 성급한 결론이 아닐까요.
C++빌더에서도 공유 라이브러리들을 미리 배포하면 실행파일은 25k 정도밖에 안됩니다.
공유라이브러리를 미리 배포한다고 가정하면 그 정도로 크기를 낮추는 것은 일도 아니지요.
그리고 프로젝트에 따라 공유 라이브러리들을 다 빼고 컴파일해도 십몇메가가 넘을 수도 있습니다.

자바 기반의 오피스인 씽크프리 오피스가 궁그미님이 말씀하신 형식과 비슷하겠습니다만...
MS 오피스에 별 위협이 못되고 있지요. 역시 낮은 GUI 성능 때문입니다.
닷넷 기반에서 비슷한 시도를 한다고 해서 그것이 씽크프리 오피스에서 모토로 내세우는
"이제 SW를 다운받아 쓰는 시대!"를 실현할 수 있을 것으로 생각되진 않습니다.


모노나 아파치와 닷넷의 관계에 대해서 제 의견은.. 좀 전에 다른 글의 리플로 쓴 것이 있는데..
결론만 요약해서 말하자면, 리눅스에서 닷넷을 돌리도록 MS가 놔둘 리가 만무하다는 것입니다.

그럼...


궁그미 님이 쓰신 글 :
: 글이 너무 길이서 요지 파악이 힘드네요. 프린트해서 밑줄 그어가며 읽었습니다.
:
: ASP.NET
:
: MSIL로 컴파일하는 과정이 필요없다는 것은 저도 인정합니다. 그렇지만 이것은 낑궈 넣기가 될 수도 있지만 개발방법의 통합이라고 볼 수도 있다고 생각합니다.
: 웹사이트 서비스하기 전에 모두 기계어로 컴파일 해 놓으면 MSIL로 컴파일하는 과정이 포함되었다고 해서 성능에 문제될 것은 없습니다. 하지만 웹개발을 .NET에 포함시킴으로써 통합된 개발환경과 동일한 언어, 동일한 프레임워크을 사용할 수 있게 됩니다. 이것은 더 큰 장점이 될 수 있습니다.
:
: 예를 들어서 쇼핑몰에서 할인 행사를 합니다. 품목마다 할인율이 다릅니다. 품목의 이미지에 몇 % 할인인지를 표시해 주어야 한다고 할 때 어떻게 해야 할까요? 기존에 이것이 불가능하다는 것은 아닙니다. 하지만 닷넷에서는 너무나 쉽게 할 수 있다는 것이죠. 디비에서 할인율을 읽어서 동적으로 이미지를 생성해주면 됩니다. 닷넷프레임웍이 제공해 주는 GDI+를 쓰면 가능하죠. 윈도애플리케이션 개발에나 쓰던 GDI를 웹프로그램에서 바로 쓸 수가 있습니다.
:
: ASP.NET = ASP + .NET 이상의 큰 효과가 있다고 생각합니다.
:
: 웹폼에 대한 말씀도 있으셨습니다. 그런데 웹폼을 좀 오해하신것 같습니다. 웹폼이 쓰일 수있는 분야가 인트라넷이다.. 웹폼의 컨트롤은 ActiveX 같은 것이 아닙니다. 웹폼의 결과물은 순전히 HTML 뿐입니다. 웹폼이 인트라넷에 더 어울리다는 것은 이해가 안되네요.
:
: 웹폼의 컨트롤, 정확히 서버컨트롤들은 재사용성을 높이기 위한 개념들입니다. 늘상하는 노가다 코딩을 하나의 컨트롤로 만들어서 그냥 드래그&드롭으로 재사용자하는 것이죠. 저는 유저컨트롤의 경우는 자주 사용하고 커스텀 컨트롤은 가끔(조매 어렵기 땜시^^;;) 사용합니다.
:
: .NET GUI 개발
:
: 임프님의 의견에 대체적으로 동의하는 편입니다. 하지만 현재의 윈집을 단순히 닷넷 버젼으로 만들 필요가 있을까요? 저는 닷넷 프로그램과 Win32 프로그램이 오랫동안 공존할 것이라고 생각합니다. 예로드신 윈집은 Win32 프로그램이죠. 닷넷 프로그램은 설치프로그램을 구해다가 설치하고 실행하는 그런 방식은 아닐 것입니다.(물론 그렇게 해도 되죠) 닷넷 프로그램은 애플릿과 비슷하지만 더 강력한 환경을 제공해 줄 것입니다. 마치 웹사이트에서 그림 다운 받아서 보듯이 실시간으로 프로그램을 다운 받아서 컴파일해서 실행하는 것이죠. 물론 프로그램 통째라 받진 않습니다. 작은 모듈로 나누어서 필요할 때 즉시 다운 해서 실행하는 것이죠. 제가 만들어 본 바로는 닷넷 애플리케이션의 크기가 생각보다 아주 적습니다. 30K 넘기기가 쉽지가 않더군요.
: 이러한 새로운 개념의 애플리케이션이 등장할 것이라는 것입니다. 그러면 불법복제 문제가 해결되지 않을까요?
:
: 이렇게 만든 윈도애플리케이션이 아무런 수정없이 바로 모바일 디바이스에서 실행될 수도 있겠죠. 앞으로 점점 프로그램은 컴퓨터뿐만 아니라 다양한 곳에서 다양한 방식으로 실행이 되어야 합니다. 그러한 상황을 극복하기 위해서는 가상머신의 개념이 꼭 필요하겠죠.
:
: 예로 드신 오피스의 경우 부분적으로 닷넷과의 호환성을 열어 놓을 것입니다. 전체를 .NET으로 만드는 것은 저도 상상이 안되네요. 하지만 앞으로 출시되는 모든 MS 제품들은 닷넷과의 호환성을 강조하면서 출시되겠죠. 그러면 전혀 상관없는 프로그램들끼리 연동이 가능해지리라 생각합니다.
:
: 엔터프라이즈 프로그래밍에서의 .NET
:
: 역시 닷넷의 선전이 가장 기대되는 영역이죠. 데브피아 게시판을 보니 MONO의 구현정도가 상당한 것 같습니다. 심지어 닷넷으로 X-Window용 애플리케이션 개발도 가능하다고 하니..
: 곧 아파치용 ASP.NET 모듈도 나온다니 ASP.NET이 IIS를 탈출하는 희한한 광경도 보겠군요. 더 기대되는 것은 개발은 윈도환경에서 VS.NET으로 하고 호스팅은 리눅스서버로 할 수 있다는 것입니다.
: ASP.NET이 MSIL로 일단 만들어지기 때문에 가능한 일이겠죠.
:
: 마지막으로..
:
: 현재 개인 컴퓨터 위에 닷넷을 까는 것은 분명 어렵습니다. 하지만 다른 모바일 장치들은 다르죠. 핸드폰으로 동영상을 저장할 수 있는 시대입니다. 모바일 장치들의 기능이 좋아질 수록 닷넷은 더 위력적일 것입니다. 모바일 장치의 효용 가치가 더 커질 수록 PC와의 연동성도 중요해 지겠죠. 내 핸드폰에 닷넷 컴팩트 프레임웍이 깔려 있는데 PC와 연동하려면 PC에도 닷넷이 깔려 있어야 한다.. 뭐 이런 시나리오로 깔수도 있겠구요^^;; 너무 비약이 심한가..
:
: 임프님의 말씀대로 역시 관건은 소비자 맞습니다. 얼마나 많은 사람들이 프레임웍을 까는냐에 따라 닷넷의 성공이 빨라질 수 있겠죠. 까는 사람한테 돈이라도 주면 안되나? ^^;;;
:
: 감사합니다.