Who are you?


이동범(Dongbum Lee)


Microsoft Regional Director


Microsoft MVP - VB.net


MHVB.net 시삽

Wanna talk with me?

Subscription

MSN 메신저를 통해 글이 갱신되면 알려드립니다.

Windows Live Alerts

Search

Navigation

Categories

.net (16) .NET Service (1) Ajax (1) asp.net (2) authentication (1) AxWebBrowser (1) Azure (2) basic (2) blog (3) browser (1) Cloud Computing (4) das blog (1) dasBlog (2) Data Portability (1) DataGridView (1) Delegated Web Authentication (1) FabrikamShipping (1) Geneva Framework (1) Google (1) Identity (1) ie (1) iis (2) IIS7 (1) I'm a PC (1) Internet Information Server (1) javascript (1) jQuery (1) Live Framework (4) Live messenger (8) Live Service (6) Live Writer (0) mac (1) Microsoft (16) Microsoft Azure Service Platform (3) oAuth (2) Office (2) OOXML (1) OpenID (1) PC (1) PHP (1) Silverlight (1) small basic (2) Team System (2) UX (1) VB (3) vb.net (4) Vista (1) visual studio (5) visual studio 2010 (1) Windows Azure (2) Windows Azure Service Platform (2) Windows Live (9) Windows Live ID (4) Windows Live Messenger (7) Windows Live Messenger Web Toolkit (7) windows7 (1) Winform (3) WinFX (1) WPF (2) 개발자 (1) 독점 (1) 라이브 메신저 (3) 라이브 아이디 (3) 마이크로소프트 애저 (2) 베이직 (1) 성공사례 (1) 성산포 (1) 스몰베이직 (1) 아웃백 (1) 애저 (2) 웹서버 (1) 윈도우 라이브 (7) 윈도우 라이브 메신저 웹 툴킷 (6) 음악 (1) 일상 (9) 제네바 프레임워크 (1) 조용필 (1) 클라우드 (1) 클라우드 컴퓨팅 (1)

On this page

Small Basic v0.5 is now public!
Windows Live Messenger Web Toolkit - Part3
Visual Studio 2010 to come with ‘Black Box’
Why VB? It’s Dynamic !
UI의 생산성을 높여주는 획기적인 아이디어! - NukeationMachine
Source code of Visual Basic runtime has been released to public
AxWebBrowser 컨트롤을 사용하는 MDI 폼에서 Focus를 받을 수 없다구?
DataGridView에서 Enter 키 입력시 다음 셀로 이동하기
Visual Studio 2008 Beta2 is now available for download!!
비스타에서 웹 어플리케이션 F5 디버깅 오류 패치 드디어 나오다.
Visual Studio 2005 Service Pack 1 Update for Windows Vista is ready for download!
SPUtility.HideTaiwan()
Code Monkey
Revoluxions - 새로운 UX를 개발하기 위한 Expression Blend 를 친근하게.
Microsoft Pre-release Software Visual Studio Code Name "Orcas" - October Community Technology Preview (CTP)
MS사의 공정위 소송 이의 신청에 즈음하여

Archive

Blogroll

Notice

알림
본 블로그는 저의 개인적인 의견을 담고 있습니다.
제가 몸담고 있는 조직의 공식적인 의견과는 다를 수 있습니다.

RSS 2.0 | Atom 1.0 | CDF Send mail to the author(s) E-mail

BlogStats

Total Posts: 66
This Year: 1
This Month: 0
This Week: 0
Comments: 23

Sign In

# Wednesday, June 17, 2009
Wednesday, June 17, 2009 10:31:12 AM (Korea Standard Time, UTC+09:00) ( .net | basic | Microsoft | small basic | 개발자 | 베이직 | 스몰베이직 )

기다리던 Small Basic의 다섯 번째 릴리즈인 Small Basic v0.5 CTP가 public 하게 오픈 되었습니다.
추가된 기능들은 커뮤니티를 통해 요청되어 오던 것들 중심이라고 하네요.

다들 다운로드 받으러 클릭! http://msdn.microsoft.com/en-us/devlabs/cc950524.aspx

clip_image001

변경된 사항들이 궁금하시면 다음의 링크를 참조하세요~http://blogs.msdn.com/smallbasic/
새로 태어날 제 딸에게 Small Basic을 가르쳐 보면 어떨까 하는 (안사람 들으면 싫어할) 상상을 해 봅니다.

Small Basic의 Turtle Graphics와 MS Robotics studio와 연결을 해 보면 어떨까 하는 생각을 하는데 어떨까요, 재미있지 않겠어요? :-)

# Tuesday, June 09, 2009

윈도우 라이브 메신저 웹 툴킷 – 라이브 메신저의 모든 것을 웹에서

intro

두 개의 포스팅을 통하여 간단히 라이브 메신저 웹 툴킷 UI 컨트롤들 중 Web Bar 를 웹 페이지에 호스팅 해 보았습니다.

이제는 보다 자세히 윈도우 라이브 메신저 웹 툴킷의 구성에 대해 살펴 봅니다.

Windows Live Messenger Web Toolkit의 구성 

1. HTML UI Control

앞서 설명한 바와 같이 윈도우 라이브 메신저 웹 툴킷은 모든 기능들이 모두 구현되어 있는 Web Bar 컨트롤에서부터 메신저를 구성하기 위해 요구되는 다양한 기능들을 모두 컨트롤화 하여 각 시나리오에 맞춰 사용할 수 있는 다양한 UI 컨트롤을 제공합니다. 이것들을 모두 통틀어 HTML UI 컨트롤 이라고 합니다.

2. Windows Live Messenger Library

윈도우 라이브 메신저 라이브러리는 자바스크립트로 구성되어 있는 스크립트 라이브러리로써 UI 는 별도 제공되지 않으며, 모든 기능들이 스크립트 객체와 객체들 간의 이벤트들을 통해 개발자들이 직접 메신저를 구현할 수 있도록 해 줍니다.

DHTML 기반이건(Ajax) Silverlight 건 Flash 이건 간에 JavaScript를 호스팅 할 수 있는 모든 곳에서 사용이 가능합니다. 앞서 소개한 HTML UI Control의 모든 기능들은 윈도우 라이브 메신저 라이브러리를 사용하고 있습니다.

그러므로 HTML UI Control의 모든 이벤트들과 객체모델들을 스크립트 라이브러리들과 공유할 수 있습니다.

3. Windows Live IM Control

제 블로그 옆에 보이는 웹 메신저 창이 바로 Windows Live IM Control 입니다.
메신저 창의 기능이 오직 특정 사용자와의 대화로 제한됨을 확인 하실 수 있습니다.
이 경우 메신저 창을 통해서는 저하고만 대화 하실 수 있죠.
온라인 상점 혹은 온라인 오픈 마켓 등에서 특정 판매자 와 웹 상에서 대화를 할 수 있도록 해 주는 기능 등을 제공해 줄 때 유용합니다. [구현 예제 참조 : EC 21 (온라인 B2B 사이트)]

4. Windows Live Presence API

단순히 특정 사용자의 온라인 유무를 나타내기 위해 제공되는 API 입니다. 요청에 따라 JSON Format 의 데이터 혹은 Image 형식(온라인/ 오프라인 아이콘)의 서비스가 제공됩니다.

이러한 4가지 라이브러리가 바로 Windows Live Messenger Web Toolkit 의 구성 요소들 입니다.

Architecture 
[Windows Live Messenger Web Toolkit의 구성]

다시 HTML UI Control 살피기

윈도우 라이브 메신저 웹 툴킷이 이런 기능들로 이루어 져 있구나… 라는 것을 대강 살폈으니 이제 다시 우리가 구현해 두었던 HTML UI Control 들 중 Web Bar로 되돌아 옵니다.
그리고 내부 구성 들을 하나씩 들쳐 보도록 하죠.

우리가 실행했었던 웹 프로젝트를 비주얼 스튜디오의 솔루션 탐색기를 통해 들여다 보면 다음과 같은 파일들이 보이실 겁니다.

Source

각각의 파일들의 용도는 다음과 같습니다.(보이는 순서대로)

  • Channel.html – 메신저 서버와의 통신을 위해 사용되는 스크립트가 담겨있는 파일입니다.
    Cross Domain scripting의 보안상의 문제를 우회할 수 있는 다양한 방법들이 있는데 그 중 내부적으로 iframe을 동적으로 만들어 호출하는 방식이 있습니다.
    Microsoft Web Messenger Library에서는 이 방식을 통하여 Cross Domain 문제를 해결하고 있습니다. 
    이 기법에 대해 보다 자세히 알고 싶으시다면 소개해 드리는 링크를 참조하시기 바랍니다.
    내용을 한번 정독해 보시는 것도 많은 도움이 될 것이라 생각합니다.
    [ The Architecture Journal - Secure Cross-Domain Communication in the Browser ]
  • Default.aspx – Web Messenger Control UI 를 호스팅 하고 있는 페이지이죠. 각 파일들에 대한 설명을 마치고 다시 살펴 봅니다.
  • Privacy.html – Login 창에서 Privacy 정책과 관련한 안내 문구가 담긴 페이지입니다. 서비스 시에는 정식 문구가 쓰여져야 하겠지만 현재로써는 별 내용 없는 Dummy 페이지에 불과합니다. (하지만 반드시 필요한 파일입니다!)
  • RefreshMessengerToken.aspx – Windows Live ID Delegated(위임인증) 을 통하여 사용자의 인증 토큰과 메신저 사용을 위한 인증 토큰을 쿠키에 넣어 관리하기 위해 필요한 파일입니다. 별도로 토큰을 관리할 목적이 아니라면 그냥 사용해도 무방한 파일입니다. 이 부분 역시 좀 더 자세히 알아 볼 때 다시한번 살펴볼 파일입니다.
  • web.config – 우리가 메신저를 호스팅 하기위해 필요한 Application ID와 Security Key에 대한 정보를 저장해 둔 환경설정 파일입니다.

통신을 위한 체널 파일, 인증 쿠키를 관리할 RefreshToken 파일과 Privacy 정보가 담긴 파일 이렇게 3개의 파일들이 준비되어 있으면 기본적으로 메신저 서비스를 호스팅 할 수 있는 기본적인 요구사항들을 갖췄다 생각하시면 됩니다.

앞으로 살펴보게 될 모든 컨트롤들 역시 위에서 설명 드리는 이 파일들이 기본적으로 준비되어 있다는 가정하에서 구현이 시작됩니다.HTMLControls 
[시나리오에 따른 각각의 16개의 HTML UI Control들]

위의 그림은 16개의 HTML Control들을 각각의 시나리오 별로 나누어 구분 지어놓은 그림입니다. 이것들을 표로 정리하자면 다음과 같습니다.

구분

컨트롤 이름

설명

Profile Profile profileControl
Presence Displan Name displayname
  Display Picture displaypicture
  Presence Status status2 status1
  Personal Message personalmessage
Contacts Add Contact addContact
  Contact List contactList
  Contact Picker ContactPicker
  Application Contacts 특정 사용자에게 자신이 등록하지 않은 사용자에 대한 로그인 여부 상태를 알 수 있도록 합니다.(Invisible)
Chat Conversation Conversation
  Converstation List
WebBar Messenger Web Bar WebBar
  IF 특정 조건을 만족할 때 컨트롤을 보일 수 있도록 해 주는 Block (Invisible) – 예를 들어 로그인 했을 때 보일 것과 로그오프인 경우 각기 다른 UI를 보이고자 할 때 유용합니다.
  Else 위의 IF 컨트롤과 함께 사용되며 IF 조건에 만족하지 않은 조건 Block의 UI를 보이고자 할 때 사용됩니다. (Invisible)
  Messener Application Windows Live Messenger UI 컨트롤들에 대한 초기화를 위해 반드시 필요한 컨트롤입니다. 다른 컨트롤들을 사용하기 위해서는 반드시 사전에 추가되어야 할 컨트롤입니다.
  Sign In Signin

16개의 컨트롤들을 잘 조합해 주면 메신저 뿐만 아니라 간단히 Social 한 기능들을 여러분들의 웹 사이트에 추가해 줄 수 있습니다.

그러면 이제 앞서 실행했던 Default.aspx 파일의 HTML 코드를 살펴봅니다.

   1: <script type="text/javascript" src="http://www.wlmessenger.net/api/3.0/loader.js"></script>
   2: <script type="text/javascript">
   3:          Microsoft.Live.Core.Loader.load(['messenger.ui', 'messenger.ui.styles.core']);
   4: </script>

페이지의 서두에는 다음과 같이 자바스크립트 라이브러리의 위치를 지정하고 Microsoft.Live.Core.Loader.load 메서드를 호출하는 코드를 보실 수 있습니다. 이것은 Windows Live Messenger Control UI에서 사용할 자바스크립트 라이브러리를 로딩하는 과정입니다.
기억하십니까? Windows Live Messenger Control UI들은 모두 윈도우 라이브 메신저 라이브러리의 기능들을 활용한다는 사실.

자 조금 더 내려오시면 다음과 같은 HTML 을 확인하실 수 있습니다.

이 태그가 제가 설명 드렸던 UI Control들 중 Messenger Application 컨트롤 태그 입니다.

   1: <msgr:app 
   2:     id="appTag" 
   3:     application-verifier-token="<%= ApplicationVerifier %>"         
   4:     privacy-url="Privacy.html"
   5:     channel-url="Channel.html"
   6:     token-url="RefreshMessengerToken.aspx">
   7: </msgr:app> 

이게 무슨 HTML이냐~ XML 아니냐? 하시는 분들 계시겠지요? 이것을 XHTML이라고 합니다. XHTML 이 머냐? 이건 따로 공부해 주시고..(그래서 뭐냐?)
모든 윈도우 라이브 메신저 컨트롤들은 이러한 XHTML 태그로 구성되어 있습니다.

그래서 반드시 이러한 태그들에 정의에 앞서 네임스페이스 정의가 선행되어야 합니다. (제가 설명을 빼먹었죠?)
HTML 정의에 다음과 같이 네임스페이스 정의가 반드시 추가되어 있어야 합니다.

   1: <html xmlns="http://www.w3.org/1999/xhtml" xmlns:msgr="http://messenger.live.com/2009/ui-tags">

Messenger Application 컨트롤 태그의 어트리뷰트들을 보면 Application-verifier-token 과 privacy-url , channel-url 그리고 token-url 값들이 나란히 정의되어 있는 것을 볼 수 있습니다.

Application-verifer-token 값은 제가 첫 번째 글에서 설명했던 Azure Service Portal 에서 등록했던 Application 의 ID와 Security Key값을 바탕으로 hashing된 값으로 서비스의 유효성을 보장받기 위해 반드시 필요한 값 입니다. 이 값이 어떻게 생성되는지가 궁금하신 분들은 각 언어 폴더 별로 제공되는 소스들을 참조하시면 쉽게 이해하실 수 있습니다. ( Application ID + Timestamp tag 를 SHA256 알고리즘으로 hashing… )

privacy-url 과 channel-url은 이미 앞서 설명 드렸고,
우리가 흥미롭게 살펴봐야 할 것은 token-url 값에 지정된 파일입니다.

token-url 이 무엇이냐? 제가 앞서서도 다시 한번 살펴 보겠노라 말씀 드렸던 부분이 바로 여기입니다.
token 이란 현재 사용자가 로그인 했는지 여부를 확인해 주기 위한 일종의 티켓과 같습니다.
놀이 동산 들어가실 때 손목에 띠 채워 주는 것. 클럽 들어가실 때 손목에 큼지막한 도장 찍어 주는 것 뭐 이런 것들이 일종의 티켓 되겠지요.

아래 보시는 내용은 우리가 인증을 마치고 Default.aspx 로 돌아왔을 때의 Request Header의 내용입니다.

GET /FirstWebToolkit/Default.aspx HTTP/1.1
Accept: */*
Accept-Language: ko-KR
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; MS-RTC LM 8; Tablet PC 2.0; Zune 3.0; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET CLR 4.0.20506)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: www.wltoolkit.com
Pragma: no-cache
Cookie: msgr-consent-token=eact%3DB4D%252BMpQ64igwHH%252Fgxb6tQ8qViFQYj5Sox%252BZcAztw6hCXDomPpK3HFq2A5uOYNZBqsDj9BZS3NRDIEXCuFM7bUs6TwCe5BITYKig21KeexvKZQi1tbPVIrI1xqegMHl9oOF0V%252BQhA3yC4gwNknEFtWJf6fV9OnRAZyBgdRLwSU%252FpJlrgU5rT3SFQd5CkkV%252BXRVRmLQHCxarUl48DqfxNkRXtnf9oJUNwb%252BL%252FBZxbI97dGuyG%252BVhtwsVWCGFw5QcPqwCVaHhootaEwjsdvbMDiYTjiv9LM651ZleNgxfG2RBV2wtTdubOst2LqcfKQn%252BAZPqrHSNF2ccPdjbf3seN6Cdfmc4OG1Ny0U690Ndrd3fkTH2Cdm2E5syL3ypkVMfRG2ZJ58zWYOPFLG%252Fmjl7qiUuYzHzzBwPAehQ2X0UTkwZ7ywVM%252BAEodAnuzUlAWphLOwWVGJVzZ63Rg34CQulFbCDV1hc2CgXpukK3ubOVXrXad8MMYUdmYOum8nChgIZejNmZhQaVOeY%252Be2g58LacCLXVEfZEoYYfny42J%252BskjRLtaYQkMzZat%252BHmDs1W0ntynbUKH1gxT8KEon7F9ou0S7Qvx0xUU56zLgdgiISE9CF0E61VXUijvZgF3cjvu1e1w1K3ij72iikwoui5Rd34DzNpA%252BgrJXAil9qrfXQjWI1nmqQ9fQbFv%252BJRHloKSLPyFrgvEZbaFuZ8%252FBC47FLvGWCZlCO9bzKh4BqJxWUtdnwI5h2mHs%252FrJ8T3RZ0W7fZ79Jxqhqq6RC8s5zzGKc23UoEXR%252FtrsZHaUqLaNs9qFY9iF1B%252FBJcj6rE8yGDuUQn8pRnxN5IRMx%252F%252FRAacQNENwjjgKbaHk%252BxwoayrA%252FqrWh9SjS9JZYCU1z1r%252FkIFeIIhqG5d0izUsF9sbbFx%252BXwDL8Q2lsGnaMGfBeHylx2Q51%252B%252FframzH1pX%252BtwQffqmiLuTphIvv2bfQpsLqXJ7Hm3rpkxkIqzwWWQQlLgsv%252FG3ecZvmVoSBuP4%252FbcU%252BTWps19CQeks51V2k56uyXzoHBU7IMfpEwfu2nCTnYUbvXWhWEoo5qnCuzXaqJowcWRmQpfP2tjLHT0vG0EwflO5qLHGy0sB2Y6agu7lkxXqHeLIRvG5wq9ifTk%252BcjJNP%252B0FoDQTED3CeuX3LHnBZ1eM%252BUhQ7%252FL%252FKfEcThnelsRKosHHn0bb%252BtjGSA%252Fwfv%252FUI%252B7wFcULowsep58ijbtUooDz0N9CsVRTgcwC2E9yD0d3M6rADe4%253D; msgr-delegation-token=EwCoARAnAAAUWkziSC7RbDJKS1VkhugDegv7L0eAAOLW3dYlVfvVGleoVqojHl4s6F0u5CfDec3KyATZtM%2BBMtIbFiTcIZF7UFOlwRQKSqIP26Tx9YS6xRbXwbnhQmtxxrX3dpqy2NAajF8%2FIdmTJE2CVQaFidDhIMMHRIrulhmDWtOTYFw6bJxKfF9D6TSFoBDMIZvqJ5Xgg%2FJDRKSlA2YAAAj%2BOy4jki13iPgA1CK%2B0740%2FUleHLq%2FdyLKoQ4PgpGxRP%2Fft7QLEbpL8pM%2BoJQEdOfN%2FB%2BcmhKPafUwDk6nO4Qj4KPUvkbL1FHCOVJ4Yx8zjKPN58QEUTtdkIAkd%2Bi%2BIRhl0iJv6v5op2cg2Mb6BxgHuM1tRvaQ41inNt%2FzQlBCjP0gRsHK%2BH%2FGPgCIs%2BVzTspi6T3Nec425DdqvwchzIdz79wkCpnV5SW17lqdML129kma3EK3vnC%2FaLe0ww3i9wjz171tgwT%2Fowk1u%2FFdJWfnDv1nnMOBQ%2FmMqPE8ArjbtRJU3fMrz%2Blza6KGgcT0AFmIW64hR3pbVmYMq4zOfJnwt5MAAA%3D%3D

이 두 개의 값이 Coolkie에 저장되어 있기 때문에 우리가 Cross-page Navigation을 하더라도 Chat Session을 그대로 유지할 수 있게 되는 이유 입니다.
그렇다면 msgr-consent-token과 msgr-delegation-token은 각각 무슨 역할을 하고 있을까요?

하나의 글에서 너무 많은 내용을 다루면 지루하다라는 피드백을 받아서.
일단 여기서 끊고, 다음 차례에서는 윈도우 라이브 메신저 웹 툴 킷의 인증 방식에 대해서 설명을 하도록 하겠습니다.

간단한 2,3회로 설명이 끝날 줄 알았는데 해야 할 말이 점점 많아 집니다.

윈도우 라이브 메신저 웹 툴킷의 인증 방식에 대한 이해는 앞으로 윈도우 라이브 서비스들의 인증에 대한 이해에도 많은 도움을 주게 됩니다.

다음 글에 앞서 제가 예전에 포스팅 했었던 Making the Internet a Safer Place 를 읽어 주십사 권해 드립니다.

계속 관심 가져 주시길…

# Tuesday, September 30, 2008
Tuesday, September 30, 2008 12:40:57 AM (Korea Standard Time, UTC+09:00) ( .net | Microsoft | Team System | visual studio | visual studio 2010 )

비행기에 블랙 박스를 탑재하여 사고 당시의 상황을 유추해 낼 수 있듯, Visual Studio 2010 의 테스터 버전에는  테스터가 진행하는 모든 상황을 Black Box에 기록하듯 기록할 수 있는 기능을 제공해 준다고 한다.

VisualStudio2010B 
[Visual Studio 2010 의 일부 모습 – 출처 : Microsoft]

이런 기능을 추가하는 걸 보면,

“어! 내 PC에서는 잘 되던 건데!!” 라는 소리는 우리 개발자들에게만 통용되는 소리는 아닌 듯 싶다.
이젠 정말 개발자들이 *빼도 박도* 못하는 상황이 되 버리고 마는 것인가 :-)

CNET 의 뉴스 기사 클리핑. http://news.cnet.com/8301-13860_3-10052412-56.html

# Thursday, September 25, 2008
Thursday, September 25, 2008 3:55:31 PM (Korea Standard Time, UTC+09:00) ( .net | Microsoft | VB | vb.net | visual studio )

Visual Studio 2008과 .NET Framework 3.5와 함께 새롭게 릴리즈 된 Visual Basic .NET – VB9은 기존의 VB6 개발자들이 요구하는 높은 융통성과 생산성을 제공해 주고 있습니다. . NET Framework의 도래와 함께 기존의 VB개발자들이 느끼고 있는 혼동과 방황을 잠재워 줄 수 있는 VB만의 Dynamic한 특징들을 Visual Studio 2008의 통합 개발 환경과 새로워 진 언어적 특징 등을 통해 알아보도록 하겠습니다.

.NET Framework 가 소개되면서 기존 VB6를 사용하던 때에 비해 VB 개발자들의 수적인 감소가 눈에 띄게 나타나고 있는 현실입니다. VB언어가 가지고 있는 생산성이라는 강점에도 불구하고 아직도 기존의 VB 와 ASP 개발자들은 여전히 .NET의 환경에 대하여 많은 혼란을 느끼고 있습니다.

그 주된 요인은 엄격한 구문과 타입체킹, 그리고 본격적인 객체지향이라고 하는 그 동안 그다지 심각하게 생각하지 않고도 자신이 원하는 응용 프로그램들을 개발해 왔던 기존의 융통성 높은(비 구조적이거나 프로시저 중심적이거나 하는 것은 전혀 문제되지 않는!) 개발 방식과 경험들이 이제는 더 이상 통용되지 않는다는 것이 원인 중에 하나라고 생각합니다. 그도 그럴 것이 VB개발자들은 다른 개발자들과 달리 그 구성에 있어 전문적인 프로그래밍 교육과 경험을 가지지 못한 파워 유저의 비중이 크며(절대 다수의 이야기가 아닙니다), 이들에게 있어 객체지향 프로그래밍과 구조적인 프로그래밍에 대한 요구는. NET을 넘기 힘든 벽으로 여기게 되었습니다. 또한 다른 요인으로 볼 수 있는 것 은 기존 C++ 개발자들에 비해 언어적으로 열세라는 심리적인 열등감에 사로잡혀 있었던 VB개발자들이 느끼는 세미콜론(;)에 대한 막연한 동경심(?)이 요인이 될 수 있었을 것입니다.

이 글을 통하여 .NET으로 넘어오지 못한 기존 VB개발자들과 타 언어로 개종(?)을 결행한 옛 VB개발자들에게 VB.NET이 가진 프로그래밍적인 매력과 Visual Studio 2008을 통한 높은 생산성을 일깨워 주었으면 합니다. 그리고 이를 통해 많은 개발자들이 다시금 VB전성시대를 이끌어 갈 수 있는 기회를 만들게 되기를 바랍니다.

통합 개발 환경에서의 장점들

통합 개발 환경에서 VB2008의 향상

Visual Studio 2008은 클래스 파일의 로딩에서 컴파일에 이르기까지 대부분의 성능들이 최소 50% 이상 향상되었으며 VB개발자들에게 기존 개발 시에 비해 좀 더 시원한 체감속도를 제공해 줍니다. 아래는 Microsoft VB.net 개발팀이 제공한 VB2005 대비 VB2008 성능 향상 비교 자료입니다.

(http://blogs.msdn.com/vbteam/archive/2008/01/04/vb2008-outperforms-vb2005-lisa-feigenbaum.aspx)

Scenario

VB2005 대비 성능 향상 비율

대형 프로젝트 빌드 (using background compilation)

0.61%

다중 프로젝트 솔루션 빌드 (explicit build operation)

3.56%

다중 프로젝트 솔루션 빌드 (using background compilation)

8.91%

클래스에 맴버를 추가한 후의 응답성

11.16%

프로젝트를 오픈한 후의 응답성

15.17%

타입에 대한 하위 목록들에 대한 인텔리센스 호출(최초)

44.49%

Xml 커맨트가 달린 솔루션 내에서 Edit-and-Continue (최초)

47.71%

메소드 선언을 변경 한 후의 응답성

60.57%

10 Steps in the debugger (subsequent times)

63.06%

타입에 대한 하위 목록들에 대한 인텔리센스 호출 (subsequent times)

64.98%

솔루션이 이미 빌드 되었을 때 F5(실행) (subsequent times)

72.35%

오류 생성 후 오류 목록에 추가되는 항목 속도

74.26%

10 Steps in the debugger (first time)

86.05%

솔루션에 대한 background 컴파일 중의 응답성

89.21%

대형 솔루션에 대한 로딩 (subsequent times)

90.78%

대형 솔루션에 대한 로딩 (first time)
(Note: 본 수치는 XP에서의 향상이며, Vista에서는 본 XP 테스트 시나리오의 2배의 향상을 보였음

91.36%

[표1 – VB2005 대비 VB2008의 IDE 성능 향상 수치]

인텔리센스(Intellisense) 의 생산성

인텔리센스가 없는 VB를 생각해 볼 수 있을까요? VB가 개발생산성을 가질 수 있는 가장 큰 이유가 바로 인텔리센스에 있다고 생각합니다. 혹자들은 인텔리센스가 개발자들을 바보로 만들고 개발자들의 실력을 떨어뜨린다는 이해할 수 없는 주장을 펼치기도 하지만, 그럼에도 불구하고 텍스트 에디터에 Copy & Past 와 현란한 단축키로 날 코딩을 하는 천재(?)개발자들 보다는 바보(?) 개발자들이 쏟아내는 코드의 생산성이 월등하다는 것이 누구나 아는 사실입니다.

VB9에서는 개발자들의 생산성을 높이기 위한 인텔리센스 기능이 기존의 Visual Studio 2005에 비해 월등히 강력해 졌습니다. 이러한 기능을 인텔리센스 에브리웨어(Intellisence Everywhere)라고 합니다.

간단히 Visual Studio 2008에서 MyIntegerValue라고 하는 Integer 타입의 Private 변수를 선언해 보도록 하겠습니다.

그림1

[그림1 : Private 변수 선언 시 P 를 타이핑 한 경우]

그림2

[그림2: Private 변수 선언 시 Pr 을 타이핑 한 경우]

원래 당연한 듯 보이는 인텔리센스 기능도 Visual Studio 2005에서 위의 과정을 수행하면 사용자의 타이핑에 위와 같이 자동으로 반응하는 인텔리센스 기능은 제공하지 않았습니다. 이 기능 하나만으로도 개발자는 코딩 생산성을 높일 수 있습니다. 게다가 변수를 참조하는 경우에 있어서도 VB개발팀들은 기존의 단순 변수 나열에서 필터링 인텔리센스 기능을 제공함으로써 개발자들이 빠른 코드 작성을 가능케 해 줍니다.

이번에는 앞서 선언한 변수에 값을 지정하기 위해 myIntegerValue 를 타이핑 해 보도록 하겠습니다.

그림3

[그림 3: myIntegerValue에 값을 지정하기 위해 타이핑 하는 경우의 인텔리센스 필터]

자동으로 개발자가 키를 입력함에 따라 자동으로 원하는 변수들이 필터링 되어 보여짐을 알 수 있습니다. 독자들의 이해를 돕기 위해 아래에 Visual Studio 2005에서 동일한 작업 시에 제공되던 인텔리센스 화면을 함께 실어 보았습니다.

그림4

[그림 4: Visual Studio 2005에서 동일한 작업을 하는 경우 인텔리센스 – 모든 키워드가 나열되어 보여진다]

상당히 친절해 진 VB 코드 개발환경이 몸으로 느껴질 수 있을 것입니다. 한가지 팁을 더 소개한다면, 인텔리센스 창이 보이는 상태에서 Ctrl(컨트롤)키를 누르고 있으면 해당 창이 투명하게 변해 코드를 가리지 않게 할 수도 있습니다.

코드조각(Code Snippet)을 통한 코딩생산성 향상 및 코드 재활용

코드조각(Code Snippet) 추가하기 기능은 VB에서만 제공하는 기능은 아니지만, 이를 활용하는 방식에 있어서는 C#에 비해 상당히 사용하기 쉬운 구조로 이루어져 있습니다. 개발하려는 코드에 대한 정확한 사용 방법을 알 수 없다면, 코드 창에서 ‘?’(물음표)를 입력 한 후 Tab(탭)키를 입력해 봅니다.

그림5

[그림 5: Visual Studio 2008 코딩 창에서 코드 조각 추가하기 메뉴 - ?(물음표)를 입력 후 Tab(탭) 키를 누른 경우]

각 시나리오 별 예제 코드들이 제공됨으로써 자신의 상황에 맞는 예제 코드들을 쉽게 재 활용할 수 있으며, 개발자가 자신의 입맛에 맞도록 코드들을 수정 및 추가할 수 있는 기능을 제공합니다.

제가 자주 사용하는 코드 조각 추가기능은 프로퍼티 자동생성 기능입니다.

코딩 창에서 Property 라고 입력한 뒤 Tab(탭)키를 치면 아래 [그림 6]과 같이 기본적인 프로퍼티를 생성하기 위한 코드가 자동으로 추가됩니다. 프로퍼티의 타입과 프로퍼티명 만 변경해 주면 자동으로 프로퍼티가 만들어집니다.

그림6

[그림6 : 코드 조각 추가 기능을 이용하여 프로퍼티 구문이 자동으로 추가된 예]

마치 자동완성 기능의 일부로 보여지지만, 본 기능은 코드 조각 관리자에 의해 등록된 코드 조각 템플릿들 중 프로퍼티 코드조각에 부여된 단축키(단축단어)에 의해 호출되어 추가된 코드입니다.

이와 같이 유용한 단축단어들을 사전에 알고 있다면 코딩의 생산성이 보다 높아지게 되는 것은 당연한 일입니다.

예를 들어 코딩창에 qConsole + Tab(탭) 키를 치면 LINQ 구문을 활용하여 Process 목록을 콘솔창에 나열해 주는 코드가 자동으로 생성될 것입니다.

객체의 타입이 먼저 선언되고 뒤이어 변수명이 선언되는 C 계열의 언어의 경우 심리적으로 개발자는 자신이 선언할 객체에 대하여 정확한 타입명을 암기(?)하고 있어야 하지만 변수명 선언에 이어 객체의 타입이 선언되는 VB의 경우에는 개발 도구에서 제공해 주는 인텔리센스 기능으로 인해 정확한 타입명을 암기하지 않아도 어렴풋한 기억만으로 코딩을 시작할 수 있습니다.

여담이지만 LINQ 구문에서 From 절이 SQL 구문에서와는 달리 Select절 보다 앞에 오게 된 이유도 바로 코딩상의 인텔리센스를 지원하기 위한 선택 이었다고 합니다.

그림7

[그림 7. 변수 객체 타입의 자동완성 – Str 뭐였더라?.... ]

지금까지 통합 개발 환경에서 VB.net 이 가진 생산성 측면에서의 타 언어들과 견주어 비교될 만한 특징들을 살펴 보았습니다. 전투에 있어 병사 개개인의 전투 능력은 필수적이지만 이 병사들의 개인화기가 어떠한 것 이냐에 따라 그 전투의 승패는 크게 다를 수 있을 것입니다.

앞서 텍스트 에디터를 사용하는 천재(?) 개발자들을 언급했지만, VB를 타 언어보다 사랑하게 된 가장 큰 이유는 바로 이러한 도구에서 제공해 주고 있는 바보(?)도 쉽게 개발할 수 있는 편의성과 생산성입니다.

이제는 관심의 초점을 VB9의 새롭고 강력해 진 언어적인 특징에 초점을 맞춰 보도록 합니다.

VB9의 언어적 향상

이 글의 제목에 Dynamic이라는 단어를 사용하였습니다. 일찍이 VB만큼 Dynamic- 동적 -이라는 단어가 잘 어울리는 프로그래밍 언어는 없었습니다. Late Binding의 강력한 기능은 오히려 그 넓은 융통성 탓에 강력한 타입기반의 프로그래밍 방법에 익숙한 C 계열 개발자들에게 비난이 되기도 하였지만, 또 다시 추세는 느슨한 타입기반의 언어들인 루비, 파이선, 자바스크립트, VB들에 관심이 쏠리고 있습니다.

또한 .NET 기반의 언어인 C#, VB.net 에 있어서도 LINQ(Language Integrated Query)의 출시와 함께 Late Binding의 언어적 특징인 타입 유추(Type Infer) 기능을 제공해 줌으로 이러한 특징들이 나타나기 시작했습니다.

VB.net 에서는 이제 예전의 방식과 같이

Dim aVar = “Viva VB!!”

와 같은 코드작성이 가능해 집니다. 이와 같은 코딩은 컴파일러에 의해 자동으로 String 타입으로 변환되어 컴파일 됩니다. 하지만 변수 선언에 항상 객체의 타입이 선언되어야 하는 C#의 경우에는 JavaScript에서의 변수 선언자인 var 를 차용해 올 수 밖에 없었습니다.

var aVar = “Are you C#?”

어딘가 어색하게 보이는 문장입니다. 어쩐지 맞지 않은 옷을 입고 있는 C#의 모습이 아닐까요? J

VB개발자들에게 있어서는 당연한 것으로 받아들여질 수 있으나, 이러한 .NET 기반 언어들의 변화는 프로그래밍 관점에 있어서의 많은 변화가 함께 수반될 수 밖에 없습니다.

또 하나 고무적인 사실은 차세대 웹 개발 플랫폼이라 일컬어지는 Silverlight 1.1 버전에서(이후 2.0으로 재 Vesioning됨) DLR(Dynamic Language Runtime)을 지원하는 언어로써 루비, 아이언 파이선, 자바스크립트, 그리고 VB를 선정하였다고 합니다. 위의 언어들이 가지는 공통적인 특징이 바로 Dynamic 이라고 하는 점을 생각해 보면 이는 당연한 결과입니다.

마이크로소프트의 .NET Framework 기반 언어로써 First Citizen이라 일컬어지는 언어들 중 유일하게 윈도우 플랫폼 기반의 어플리케이션과 Cross browser에서 실행 가능한 RIA(Rich Internet Application) 개발을 가능케 하는 언어는 VB가 유일한 것이 될 것입니다.

Born in XML!
그림8
[코드 1 – XML Text가 변수로 선언된 예]

왠지 기존 코드와 비교해 보자면 어색합니다. 위의 코드가 컴파일 될 수 있을까요?

VB9에서는 아주 자연스러운 코드가 됩니다.

별도의 Line 연결자인 _ (언더바) 문자 없이도 변수 선언과 함께 작성되는 XML 텍스트는 그 자체로 XElement 타입의 객체로 선언됩니다. (XML Header를 추가해 준다면 자동으로 XDocument 타입이 됩니다) 이제 VB에서는 XML 텍스트 자체는 하나의 XML 요소 객체로 인식될 수 있게 됩니다.

아래는 C#을 통한 코드 1의 XML XElement를 선언하기 위한 코드입니다.

얼핏 보기에도 아래의 코드는 직관적이지 못합니다.

그림9

[코드 2 – 코드1의 XML 텍스트를 만들기 위한 코드. 한눈에 봐도 어떤 구조인지가 눈에 들어오지 않음]

VB에서는 단순 XML 텍스트 선언뿐만 아니라 동적인 XML Element 들을 생성해 낼 수도 있습니다. 아래의 코드를 통해 보다 자세히 살펴봅니다.

그림10

[코드 3 – Process 목록들을 XML로 표시하기]

ASP에 익숙한 개발자라면 아주 친숙한 Data Placeholde(<%= %>)를 확인 할 수 있습니다. 바로 위와 같이 Data가 표기되어야 할 Data Island 부분에 <%= %> 코드를 통해 원하는 데이터를 추가해 넣을 수 있습니다. 뿐만 아니라 코드의 가독성이 상당히 뛰어 나기 때문에 XML을 생성하는 코드를 작성하는 데 있어 그 어떠한 언어도 가질 수 없는 장점을 가집니다.

기존의 XML에서 XML로의 변환을 위해 사용되었던 XSLT 변환 작업들이 이러한 VB의 Dynamic한 언어적 특징으로 인해 손쉽게 처리될 수 있는 방법이 생겼습니다.

XML 데이터의 생성뿐만 아니라 파싱에 있어서도 그 직관적이고 손쉬운 코딩은 빛을 발하고 있습니다. 아래의 코딩은 Microsoft 사의 MSDN 사이트의 RSS XML을 파싱하여 콘솔에 디스플레이 해 주는 코드입니다.

그림11

[코드 4 – RSS XML 파싱하기]

XML 파싱에 있어서도 언어와 XML 텍스트를 직관적으로 혼용하여 사용하고 있음을 확인할 수 있습니다.

위의 코딩 역시 C#으로 변환하면 아래와 같습니다. 모든 XML Element 들에 대한 파싱 방식이 메소드 기반으로 되어 있어 VB에 비하여 직관성이 많이 떨어짐을 알 수 있습니다.

그림12

[코드 5 – C# 으로 RSS XML 파싱하기]

VB를 통한 XML 파싱은 메소드 기반의 API 호출이 아닌 기본적으로 XPath 쿼리 문장에서 사용하던 모든 XML 표기법들을 그대로 활용할 수 있기 때문에 코드의 가독성과 직관성 및 XML 처리에 있어서의 생산성은 더욱 뛰어나게 됩니다.

Upgrade를 지원하는 유일한 언어!

VB6 코드를 VB.net으로 변환할 수 있는 방법은 매우 다양합니다. VB.net으로 코드를 변환해 주는 코드 변환기가 기본적으로 Visual Studio에서 제공되고 있으며, 기존 VB6 코드와 VB.net 코드를 함께 사용할 수 있게 해주는 Interoperability Toolkit을 VB.net 홈페이지를 통해 제공해 줍니다. 또한 COM객체를 그대로 이용할 수 있는 .NET의 장점으로 인해 코드의 변환 없이도 .NET에서의 코드 활용이 가능할 수도 있습니다.

무엇보다 Microsoft 사의 관리형 언어들 중 유일하게 VB만은 기존 개발자들의 기존 코드들을 위한 다양한 Upgrade 방법들을 제공해 주고 있습니다.

이미 개발된 VB코드들에 대한 부담이 큰 개발자들도 일단 한번 해당 프로젝트를 Visual Studio 2008에서 실행하여 업그레이드 마법사를 통해 변환되는 코드를 살펴보기 바랍니다. 개발자들의 코딩패턴에 따라 달라지겠지만 약 80% 정도의 코드들은 별도의 변환 없이 사용이 가능한 수준의 코드로 변환해 줍니다.

Why VB?

이 밖에도 많은 기능들이 Visual Studio 2008에서 VB에 추가되었습니다. 여기서 이 많은 기능들을 다 담아낼 수 없는 아쉬움은 있지만 앞서 살펴본 VB만이 가지는 생산성 높고 강력한 기능들 만을 보더라도 충분히 VB가 이전에 비해 얼마나 많이 달라졌는지를 느낄 수 있었을 것이라 생각합니다. 저 역시 VB6 이후 버전에 있어서 VB 개발팀들이 VB만의 Dynamic한 융통성을 제공해 주지 못하고 C#과의 문법적 차이 이외의 두드러진 장점을 제공해 주지 못했던 기존 버전에 대한 아쉬움이 적지 않았지만 이제는 ‘왜 VB냐?’는 질문에 대한 해답을 명쾌하게 해 줄 수 있게 된 것 같습니다. 차기 버전으로 새롭게 기획되고 있는 VBx(VB10)는 지금의 Dynamic한 VB의 장점들을 보다 향상시켜 DLR(Dynamic Language Runtime) 을 아우르는 강력한 언어로 탈바꿈 할 것으로 전해지고 있습니다.

보다 VB스럽고, 보다 Dynamic해진 VB9.

Visual Studio 2008을 통해 코딩을 하고 있노라면 타격감 좋은 온라인 게임을 즐길 때의 짜릿함이 느껴집니다. 여러분들도 다음의 링크에서 평가판(http://msdn2.microsoft.com/en-us/vstudio/products/aa700831.aspx) 을 다운로드 하고 새로워진 VB.net을 느껴보시기 바랍니다. 왜 VB인지 말입니다.

# Thursday, August 21, 2008
Thursday, August 21, 2008 4:36:42 PM (Korea Standard Time, UTC+09:00) ( .net | visual studio | Winform | WPF | asp.net )


툴 박스를 이용한 UI의 생산성을 높여줄 수 있는 기발한 아이디가 돋보인다.

WPF, Winform, ASP.net까지 기본적으로 요구되는 다양한 UI ControlSet들을 몇번의 조작으로 손쉽게 완성한다.

게다가 Blend까지 지원하는 제품을 선보일 예정이라니... 놀랍다.
데모 Video clip만으로 신선하다.

시간을 갖고 좀 가지고 놀아 볼만한 가치가 있어 보인다. 와우~

http://machine.nukeation.com/default.aspx

# Sunday, January 20, 2008
Sunday, January 20, 2008 10:00:25 PM (Korea Standard Time, UTC+09:00) ( .net | VB | vb.net | vb.net )

Visual Basic 런타임에 대한 소스수준의 디버깅이 가능해 졌습니다.
VB개발자들에게 있어서는 반가운 리소스가 되어 줄 것 같습니다.

VB Team 의 블로그에 디버깅을 위한 설정과 관련한 자세한 내용이 실려 있네요.

http://blogs.msdn.com/vbteam/archive/2008/01/19/source-code-of-visual-basic-runtime-has-been-released-to-public.aspx

# Thursday, December 13, 2007
Thursday, December 13, 2007 1:52:31 AM (Korea Standard Time, UTC+09:00) ( .net | AxWebBrowser | vb.net | Winform )

(MDI Childform contains AxWebBrowser control can not be focused(activated) when this control is selected.)

비따 회원의 질문 중에 흥미로운 것이 있어 옮겨 본다.
윈폼 개발 중 WebBrowser 컨트롤을 사용할 경우 부득 WebBrowser Control 대신 기존 방식처럼 AxWebBrowser컨트롤(AxImp를 통한 RCW 생성을 통해)을 만들어 사용하게 된다.

이 경우 해당 폼이 MDI Child로 사용될 경우, MDI Form 내부에서 해당 웹브라우저 컨트롤을 사용자가 클릭했음에도 불구하고 타이틀바를 클릭하지 않는 이상 폼이 활성화 되지 않는 황당한 경우가 발생한다. 아마도 제대로 웹브라우저 RCW 코드에서 메세지 처리를 완벽하게 못 만들어 내는 것 같다.

Reflector로 까 봐야 자세히 알겠지만, 귀찮아서 생략한다. 대신 직감으로 WM_MOUSEACTIVATE 메세지를 가로채 해당 이벤트에서 컨트롤이 담겨진 폼을 찾아 Focus 받도록 메서드 날려준다.

소스는 초 간단. RCW - AxWebBrowser 컨트롤을 상속받아 WndProc 메서드를 재정의 해 준다.

Public Class AxFocusedBrowser
    Inherits AxSHDocVw.AxWebBrowser

    Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)
        If m.Msg = &H21 Then 'WM_MOUSEACTIVATE 
            Dim parentObject As Object = Me.Parent
            Do While Not (TypeOf parentObject Is System.Windows.Forms.Form)
                parentObject = parentObject.Parent
            Loop
            parentObject.Focus()
        End If
        MyBase.WndProc(m)
    End Sub
End Class

아.. 깔끔한 VB 코드.. 난 이 Object 타입에 아무렇지 않게 메서드와 프로퍼티를 지정해 줄 수 있는 융통성이 좋다.
Dynamic VB! :-)

# Thursday, August 23, 2007
Thursday, August 23, 2007 7:32:17 AM (Korea Standard Time, UTC+09:00) ( .net | DataGridView | Winform )

(Moving focus to next cell when 'Enter' key is pressed in DataGridView)

비따 회원 중 한분이 DataGridView에서 데이터를 편집시 Enter Key를 입력하면 왜 다음 셀로 이동하지 않고 다음 행으로 옮겨 가는지, 여간 불편하지 않다라는 질문을 해 왔다.

왜 DataGridView에서는 Enter키를 입력하면 다음 행의 셀로 이동하는 것일까?
해답을 찾기 위해 일단 Reflector를 통해 DataGridView에서 EnterKey가 입력될 때 수행하는 동작이 들어있는 DataGridView의 ProcessEnterKey 를 열어 보았다.

<SecurityPermission(SecurityAction.LinkDemand, Flags:=SecurityPermissionFlag.UnmanagedCode)> _
Protected Function ProcessEnterKey(ByVal keyData As Keys) As Boolean
    Dim moved As Boolean = False
    Dim flag2 As Boolean = True
    Dim flag3 As Boolean = True
    If ((keyData And Keys.Control) = Keys.None) Then
        flag3 = False
        keyData = (keyData And Not Keys.Shift)
        flag2 = Me.ProcessDownKeyInternal(keyData, moved)
    End If
    If Not moved Then
        Dim dataGridViewCurrentCell As DataGridViewCell = Nothing
        If (Me.EditMode = DataGridViewEditMode.EditOnEnter) Then
            If (Me.ptCurrentCell.X <> -1) Then
                dataGridViewCurrentCell = Me.CurrentCellInternal
                Dim args As DataGridViewDataErrorEventArgs = _ 
                  Me.CommitEdit((dataGridViewCurrentCell), _
                  (DataGridViewDataErrorContexts.Commit Or _
                  DataGridViewDataErrorContexts.Parsing), _
                  DataGridViewValidateCellInternal.WhenChanged, _
                  False, False, False, False, False) If ((Not args Is Nothing) AndAlso args.ThrowException) Then Throw args.Exception End If End If Else Me.EndEdit((DataGridViewDataErrorContexts.Commit Or
            DataGridViewDataErrorContexts.Parsing), _
            DataGridViewValidateCellInternal.WhenChanged, False, False, _       
            False, False, False, True, True, True) End If If (Not flag3 OrElse Not Me.IsCurrentRowDirty) Then Return flag2 End If dataGridViewCurrentCell = Nothing Dim x As Integer = Me.ptCurrentCell.X Dim y As Integer = Me.ptCurrentCell.Y If Me.IsInnerCellOutOfBounds(x, y) Then Return flag2 End If If Me.OnRowValidating((dataGridViewCurrentCell), x, y) Then Return flag2 End If If Me.IsInnerCellOutOfBounds(x, y) Then Return flag2 End If Me.OnRowValidated((dataGridViewCurrentCell), x, y) End If Return flag2 End Function

다른 코딩들은 잘 분석해 보시고~ 여기서 붉은 색으로 표시되어 있는 부분을 살펴보면 짐작할 수 있듯 알아서~ 다음 행으로 CurrentCell을 이동시키는 코드가 들어있다.

 

이를 가로채기 위해서 일단 ProcessCmdKey 메서드를 Override 하기로 한다. ProcessCmdKey가 뭐냐구?
ProcessCmdKey 메서드란 컨트롤에서 명령키를 처리하기 위해 메세지를 전처리하는 동안 발생하는 메서드이다.(말이 어렵나? 나도 설명하기 어려워서 MSDN의 설명을 그대로 차용했다) 예기인 즉슨 컨트롤에 키가 입력되면 먼저 가로챌 수 있는 곳이라 생각하면 되겠다.

또 하나 처리해 줘야 할 메서드는 ProcessDataGridViewKey 이다. 해당 메서드는 DataGridView컨트롤에서 이동을 위한 키 입력시 입력된 키를 가로챌 수 있는 부분이다. 이 역시 앞서 설명한 ProceddCmdKey와 동일한 메서드이나, DataGridView에 특화된 메서드라 생각하자.

이 두개의 메서드에서 EnterKey가 입력으로 들어오면 기존에 정의된 ProcessDownKeyInternal 을 호출되기 때문에, EnterKey를 Right키로 가로채 바꿔치기를 하면 된다.

Public Class MyDataGridView
    Inherits System.Windows.Forms.DataGridView 

    Private isAutoCellMoved As Boolean = False
    Protected Overrides Function ProcessCmdKey(ByRef msg As System.Windows.Forms.Message, _                                                 
                                                ByVal keyData As System.Windows.Forms.Keys) As Boolean
        If (Me.CurrentCell.ColumnIndex <> Me.ColumnCount - 1) AndAlso (keyData = Keys.Enter) Then
            Return Me.ProcessRightKey(keyData)
        End If
        Try
            Return MyBase.ProcessCmdKey(msg, keyData)
        Finally
            If keyData = Keys.Enter Then
                If Me.Rows.Count <> Me.CurrentCell.RowIndex + 1 Then
                    Me.CurrentCell = Me(0, Me.CurrentCell.RowIndex + 1)
                    isAutoCellMoved = True
                End If
            End If
        End Try
    End Function 

    Protected Overrides Function ProcessDataGridViewKey(ByVal e As System.Windows.Forms.KeyEventArgs) As Boolean
        If isAutoCellMoved Then
            isAutoCellMoved = Not isAutoCellMoved
            Return True
        End If 

        If (Me.CurrentCell.ColumnIndex <> Me.ColumnCount - 1) AndAlso (e.KeyData = Keys.Enter) Then
            Return Me.ProcessRightKey(e.KeyData)
        End If
        Return MyBase.ProcessDataGridViewKey(e)
    End Function 

위의 코드를 잘 보면, EnterKey가 입력될 시, ProcessRightKey를 호출하여 마치 Right 키를 누른 것 처럼 메세지를 넘겨 버리는 것을 알 수 있다.
하지만 무작정 Enter를 친다고 Right Key가 눌려진 것 처럼만 한다면 어떻게 될까?

맨 마지막 컬럼에서 EnterKey를 치게 되면 원래 ProcessRightKey의 기본 행태인 다음 행의 동일한 컬럼으로 포커스가 이동되고 만다.
하지만 원래 우리가 원하는 것은 맨 마지막 컬럼까지 포커스가 이동했다면, 다음번 EnterKey에는 그 다음 행의 첫번째 컬럼으로 가는 것이 보기도 좋고,
기본적으로 어플리케이션 사용자들이 그리드에서 다수의 데이터를 입력하고자 할때 편의를 제공해 줄 수 있을 것이다.

그래서 일반적은 경우에는 ProcessRightKey를 호출하지만, CurrentCell이 마지막 컬럼에 위치하고 있을 경우에는 직접 CurrentCell을 다음 행의 첫번째
컬럼으로 이동시키게 하는 코드를 추가했다. 또 하나 CurrentCell이 맨 마지막 행, 마지막 컬럼에 위치하고 있다면? 그냥 둔다 :-)

개발자들의 취향에 맞게 고쳐쓰면 될 듯 싶다.

상용 컴퍼넌트를 구매하지 않고 기본 컨트를을 통하여 우리의 입맛에 맞게 바꾸기 위해 이러저러한 궁리와 코딩을 하다보면, 컴퍼넌트 가격이 참 저렴하다라는 생각이 든다.

비싼 개발자들의 인건비를 100만원정도 하는 상용컨트롤 구매와 맞 바꾸려 하다니 -.-
개발자는 자고로 비지니스로직 구현에만 전념할 수 있도록 하면 되거늘... 

여전히 시장선 개발자의 인건비가 X 값이다

에휴우....

# Friday, July 27, 2007
Friday, July 27, 2007 10:14:17 AM (Korea Standard Time, UTC+09:00) ( .net | Microsoft | visual studio )

Vstudio2008.png

Orcas Beta2 버전이 public open 되었습니다.

http://go.microsoft.com/?linkid=7175498

 

이번 주 에는 이 녀석과 함께 보내게 되겠군요 :-)

Happy downloading~

# Thursday, June 28, 2007
Thursday, June 28, 2007 1:28:31 PM (Korea Standard Time, UTC+09:00) ( .net | iis )

비스타에서 IIS를 이용해 웹 어플리케이션 디버깅을 하려면 무척 번거로운 작업들을 거쳐야만 가능했다.
http://support.microsoft.com/kb/937523

짜증나는 작업들은 이제 그만 :-)

다운로드는 여기에서!
http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=7250


# Wednesday, March 07, 2007
Wednesday, March 07, 2007 8:23:42 PM (Korea Standard Time, UTC+09:00) ( .net | Microsoft )

각 제품군들의 빠른 변화가 가끔한 혼동스런 결과를 가져오기도 한다 :-)

드디어 나왔다. VS 2005 SP1 for Windows Vista.

http://www.microsoft.com/downloads/details.aspx?FamilyId=90E2942D-3AD1-4873-A2EE-4ACC0AACE5B6&displaylang=en

Wednesday, March 07, 2007 1:29:51 PM (Korea Standard Time, UTC+09:00) ( .net | Microsoft )

중국의 요청이였으리라 확신이 되지만, 어딘지 씁쓸한 생각이 드는 메서드명이다..

http://msdn2.microsoft.com/en-us/library/ms441219.aspx

타이완. 개인적으로는 그 나라의 탄생 배경이 그리 달갑지만은 않지만, 그렇다고 숨길수도, 지워버릴 수도 없는
사실을...

Hide고구려(); Hide고조선();

자신들의 양심도, 자존심들 마져도 Hide 하려는 생각은 아닐까...

# Tuesday, February 27, 2007
Tuesday, February 27, 2007 12:04:02 PM (Korea Standard Time, UTC+09:00) ( .net )
# Tuesday, February 13, 2007
Tuesday, February 13, 2007 12:23:01 PM (Korea Standard Time, UTC+09:00) ( .net | WinFX | WPF )
Microsoft 사의 새로운 UX 저작도구인 Microsoft Express Blend 를 쉽게 익힐 수 있는 사이트를 소개합니다.
# Thursday, November 02, 2006
Thursday, November 02, 2006 10:58:52 PM (Korea Standard Time, UTC+09:00) ( .net )

10월 30일 release 하면서, October CTP랍니다. :-)
10월은 10월 이니까... 즐거운 WinFX Programming~

http://www.microsoft.com/downloads/details.aspx?FamilyId=C09B5A2D-EB6A-44B6-8BBD-3764A2FDA9CE&displaylang=en

# Thursday, July 27, 2006
Thursday, July 27, 2006 11:52:51 PM (Korea Standard Time, UTC+09:00) ( .net | Microsoft )

Microsoft 사는 지난 주 Windows Priciples 라고 하는 새로운 윈도우 플랫폼에 대한 원칙을 발표하였다.

많은 주위의 적(?)들로 부터 집중 포화를 받고 있는 윈도우 운영체제에 대한 획기적인 방향 전환을 선언하고

나섰다.

자세한 내용에 대해서는 다시 블로그를 별도로 작성하려고 한다.

이에 앞서 3월달에 작성했었던, 공정위의 MS사에 대한 "끼워팔기" 소송에 대한 의견을 블로그에 다시 개재한다.

 

독점적인 지위로 인해 자신들이 손해를 입었다면서 거액을 MS로 부터 삥(?) 뜯어간 "다음(http://www.daum.net)  

과 공정위의 비전문적이고 선정적인 태도에 대한 유감을 피력한 글이다.


“MS의 끼워팔기

오늘(2006년 3월 27) 모든 언론들은 마이크로소프트사가 공정거래위원회(이하 공정위)를 상대로

끼워팔기제재 처분에 대한 처분 취소 청구 소송을 제기했다는 소식을 일제히 발표했다.

필자의 의견을 피력하기에 앞서 마이크로소프트사에 대한 공정위의 끼워팔기제재 처분이 무엇인가를 먼저 알아보자.

 

2005 12월 공정거래위원회는 마이크로소프트사가 미디어 플레이어와 메신저 프로그램을

윈도우 운영체제에 기본 장착하고, 미디어 서버 프로그램을 윈도우 서버 운영체제에 포함한 행위를

위법한 결합판매행위로 심결했다. 그 핵심적 논리는 이러한 결합 판매로 인해 부 상품

(미디어 서버, 미디어 플레이어, 메신저) 시장에서 경쟁을 봉쇄하고 독점화하는 한편,

주 상품인 PC 서버 OS PC OS 시장에 대한 진입장벽을 높임으로써 시장경쟁을 제한하고 소비자 이익을

저해하였다는 것이 그 요지이다. 이에 마이크로소프트사는 자사의 OS인 윈도우에서 문제되고 있는

윈도우 미디어 서버, 윈도우 미디어 플레이어 그리고 윈도우 메신저를 분리하여 판매하거나,

설치하도록 함과 동시에 279억여 원의 과징금을 추징 받게 되었다.

 

이러한 마이크로소프트사의 끼워팔기행위에 대한 제소는 미국에서는 IE(Internet Explorer),

EU에서는 윈도우 미디어 플레이어에 대해 이루어졌으며, 한국이 세 번째로 윈도우 미디어 플레이어와,

미디어 서버 그리고 한 걸음 더 나아가 윈도우 메신저에까지 끼워팔기를 문제 삼아 마이크로소프트사의

불공정(?) 판매행위에 대한 법적 제재를 취하고 나선 것이다.

 

개발자의 입장에서 본 MS 공정위 소송

이 문제에 대한 가치 판단에 있어서는 상당히 첨예한 의견대립이 있을 수도 있는 부분이다.

그렇기 때문에 필자의 글이 마이크로소프트사를 옹호하는 사람들에게는 긍정적인 의견이 될 수도 있고,

혹은 반대하는 사람들에게 있어서는 비난이 될 수도 있을 것이라고 생각한다.

하지만 IT 업체에 몸을 담고 있는 사람으로서, 또 소프트웨어를 개발하고 판매하는 개발자의 입장으로서의

관점에서 MS사의 공정위 소송 문제에 대한 의견을 피력하고자 한다.

 

끼워팔기?”

우리생활에 있어서 없어서는 안될 필수품이 된 핸드폰. 이전의 핸드폰은 벽돌만한 크기에 큼지막한 안테나와

숫자 패드만이 존재하는 전화기 그 자체의 기능만이 제공되었지만, 오늘날의 핸드폰은 어떠한가?

곱상한 디자인에 mp3 파일 재생기능과 인터넷 접속 기능, TV 수신 및 디지털 카메라 등 수 많은 다양한 기능들이

탑재된 작은 최첨단 디지털 디바이스로 탈바꿈하였다. 우리가 쉽게 MS DOS를 떠올릴 수 있는 예전의 OS

검정색 콘솔화면에 기업의 단순 업무 처리로만 사용되었지만 오늘날의 OS는 어떠한가?

현란한 그래픽 화면에 기업 내의 업무처리뿐만 아니라 우리 일상 생활의 모든 부분을 차지하고 있으며,

우리가 사용하는 디지털 기기 – PDA, 디지털카메라, 핸드폰, 오디오 게임기 등 과의 연동을 통한 소위 말하는

디지털 컨버전스 시대의 중심이 되고 있다.

 

핸드폰의 여러 기능들이 이미 핸드폰의 일부로 인식되고 있는 것처럼 현재 윈도우 OS에 탑재되어 문제가 있다고

이야기하는 미디어 플레이어와 메신저 역시 OS의 일부일 뿐이다. 핸드폰의 여러 기능들이 끼워팔기라고 하는

이름으로  손가락질 받을 수 없는 것처럼 OS에 탑재된 미디어플레이어와 메신저 역시 디지털 컨버전스의 핵심인

홈 미디어와 컴퓨팅 사용자들 간의 협업(Collaboration)이라고 하는 새로운 컴퓨팅 패러다임을 제공하기 위한

OS의 일부이다.

이러한 것들에 대해 끼워팔기라고 하는 잣대를 들이댄다는 것은 참으로 개탄스러운 일이라 아니할 수 없다.

 

윈도우 미디어 플레이어는 OS에서 제공하는 멀티미디어 콘텐트를 재생하는 기능을 제공하는

프로그램이자 개발 플랫폼이다또한 윈도우 메신저는 윈도우 XP 이상에 탑재되어 원격 사용자들 간에

애플리케이션을 공유하고 문제를 해결할 수 있는 기능을 제공하기 위한 협업(Collaboration)기능으로써의 OS의 일부이다.

(*여기서 혼동하지 말자! 우리가 마이크로소프트 메신저라고 알고 있는, MSN 사이트를 통해 다운로드 하여 사용하는 제품은

MSN 메신저이고, 이는 사용자들이 자발적으로 다운로드를 받아야 하는, “끼워팔기와는 아무런 관계가 없는 제품이다! )

이 두 가지 제품들은 모두 OS의 일부로써 OS를 구성하기 위해서는 없어서는 안될 기반 컴포넌트 들이다.

이들을 끼워팔기라고 주장한다면 이는 자동차를 구매하면서 엔진이나 바퀴 등을 끼워 판다고 주장하는 것과,

휴대폰을 구매하면서 mp3 기능이나 TV 수신 기능들을 끼워 판다고 이야기 하는 것과 그 논리에서 다르지 않다.

 

기반 플랫폼!”

개발자의 입장에서 다시 한번 윈도우 미디어 플레이어와 윈도우 메신저를 살펴보겠다.

과연 이 두 제품이 과연 끼워팔기의 대상이 될 수 있는가를 생각해 보지 않을 수 없다.

만일 MS Internet Explorer끼워팔기의 대상으로 인정되어 윈도우 OS에서 제거된다면 다른 애플리케이션들에게는

어떠한 피해가 있을까? 아이러니하게도 MS로부터 메신저 시장에서의 막대한 피해를 입었다는 이유로 거액의 피해 보상을

받았던 회사의 메신저마저도 IE가 없으면 제대로 작동을 하지 않을 구조를 가지고 있다.

 

또 하나 재미있는 테스트 결과가 있다. 공정위와 일부 업체들이 주장하는 또 다른 끼워팔기프로그램인

윈도우 미디어 플레이어가 없다면 어떤 일들이 벌어질까?

(http://www.ebuzz.co.kr/content/buzz_view.html?ps_meid=0301&ps_ccid=2376&ps_hnum=1999997691)

테스트 결과 현재 미디어플레이어 시장에서 높은 점유율을 차지하고 있는 플레이어의 경우에도 WMV 포맷,

DVD 타이틀 및 WMA, WAV 포맷 등은 재생할 수 없었다. 테스트는 하나의 미디어 플레이어 소프트웨어만을 가지고 진행했지만

이 실험 결과는 다른 여타의 미디어 플레이어에서도 동일하거나 유사한 결과를 가져올 것이다.

 

왜 이러한 결과를 가져오는 것일까?

그것은 개발자들이라면 모두 공감할 수 있는, 개발 시에 반드시 필요한 플랫폼이기 때문이다.

 

물론 내가 직접 만들 수도 있는데 그냥 제공되고 있으니까 사용하는 것이다! 얼마든지 MS의 개발 플랫폼을

사용하지 않고도 애플리케이션을 개발 할 수 있어!” 라고 이야기 하는 개발자가 있을지도 모른다.

물론 얼마든지 가능하다. 당신은 마음만 먹는다면 OS까지도 얼마든지 만들 수 있는 개발자이니까!

 

허나, 개발 플랫폼을 사용한다는 것은 단순한 개발이라고 하는 작업 이외에 자신이 개발한 애플리케이션이

어떠한 환경에서 구동될 수 있는지를 가늠할 수 있는 중요한 잣대가 될 수 있다. MFC 라이브러리를 사용하여

애플리케이션을 개발하였다면 당연히 그 애플리케이션은 마이크로소프트사의 윈도우 플랫폼에서 구동이

가능하다라는 것을 보장 받을 수 있는 것처럼 말이다. 또한 애플리케이션 개발자나 개발사의 측면에서도

앞서 예를 든 미디어 플레이어의 경우에서 볼 수 있는 것처럼 이미 잘 마련된 개발 컴포넌트를 근간으로 개발이

진행됨으로써 불필요한 추가 개발을 하지 않아도 될 뿐만 아니라, 개발 전반에 대한 비용 절감을 가지고 옴으로써

많은 이점을 얻을 수 있다.

 

만일 이러한 개발 컴포넌트들이 빠진 OS가 출현하게 된다면? 많은 개발자와 개발사에서는

상당한 혼란을 가져올 뿐만 아니라, 이를 구현하기 위한 비용 내지 이러한 기능을 구현해 놓은 컴포넌트를 추가적으로

구매해야 하는, 또 이러한 컴포넌트가 OS상에서 정상적으로 작동하는지에 대한 검증을 지속적으로 진행해야 하는

비효율적인 낭비가 계속될 것이며, 장기적으로는 소프트웨어 산업에 대한 국제 경쟁력마저 상실케 되는 문제가 발생하게 될 것이다.

 

지극히 단편적인 일부 애플리케이션들과의 시장 점유율 수치만을 통하여 이를 독점이라 진단하고 OS에 대해

매스를 가하는 것은 해부학을 제대로 알지 못하는 돌팔이 의사에게 IT 업체 전체의 운명을 맡겨버리는 것과 같은

위험 천만한 일이 아닐 수 없다.

 

시장? 시장!”

공정위에서 문제를 삼고 있는 두 가지 애플리케이션 윈도우 미디어 플레이어, 윈도우 메신저 들에 대해

소프트웨어를 개발하고 판매하는 사람의 입장에서 이야기를 해 본다.

먼저 윈도우 메신저. 아마도 공정위는 윈도우 메신저와 MSN 메신저를 혼동하여 이러한 문제 제기를 하고 있을 것이라 생각한다.

적어도 이렇게 믿지 않는다면, 공정위의 결정을 이해할 수 있는 논리적 근거를 찾을 수 없을지도 모른다.

공정위는 기본적으로 윈도우 메신저가 탑재됨으로써 국내 메신저 시장이 고사될 것이라고 주장하고 있다.

하지만 윈도우 메신저의 주 목적은 원격 사용자들간의 기술 지원 및 협업을 위해 탑재된 OS의 일부일 뿐,

시장 점유율을 산정하는 MSN 메신저나 네이트온 메신저 등의 인터넷 인스턴트 메신저와는 전혀 다른 별개의 제품이다

(물론 MSN 메신저와 같은 통신 프로토콜을 사용한다는 점에 대해서는 이견이 있을 수 있다.

그러나 이 부분이 윈도우 메신저와 MSN 메신저를 동일한 제품이라 주장할 수 있는 정당한 근거는 될 수 없다).

대부분의 사용자들이 사용하고 있는 마이크로소프트사의 메신저는 OS에서 제공하는 윈도우 메신저가 아니라

MSN 메신저가 대부분이다. MSN 메신저와 다른 기타의 메신저들과의 비교는 몰라도, 메신저로써의 기능적인 부분만을 가지고

윈도우 메신저를 평가하자면 이는 낙제점을 받을 것이다. 윈도우 메신저는 상업적인 목적으로 개발된 것이 아니기 때문이다.

 

국내 메신저 시장의 점유율은 이미 네이트온 메신저가 부동의 1위 자리를 고수하고 있다. ?

사용자들의 입맛에 맞는 다양한 기능들을 제공하고 있기 때문이다.

많은 사람들로부터 사랑 받는 미니홈피와의 연동이라든가, SMS 문자서비스 기능 등 사용자 편의성을 극대화여

사용자들의 호감을 얻은 당연한 결과이다.

 

바로 시장에서 여러 메신저 개발사들의 경쟁을 통해 소비자들에 의해 선택된 결과이다.

 

이러한 시장 점유율에 있어서의 산술적 증거에도 불구하고 마이크로소프트사의 윈도우 메신저가 메신저 시장의

끼워팔기로 인한 쏠림 현상을 제공한다는 이유로 윈도우에 탑재되지 않을 경우, 마이크로소프트사의 또 다른 제품인

MS 오피스에서 제공하는 엔터프라이즈 환경에서의 협업을 지원하는 많은 기능들 및 통합하는 기능들을

하나도 사용할 수 없게 되어 버리고 만다. , 애초에 비교 대상이 될 수 없는 대상에 대한 비교가 우습게도 다른 소비자들의

정당한 소프트웨어에 대한 사용권리를 앗아가 버리는 결과를 초래할 뿐만 아니라, 이를 통해 발생하게 될 오피스 시장에 있어서의

마이크로소프트사의 공정한 경쟁 참여를 할 수 없게끔 절름발이로 만들어 버리는 결과를 가져오게 될 것이다.

 

이것이야 말로 시장을 소비자들이 인위적인 힘에 의해 왜곡시켜버리는 결과를 낳게 될 것이다.

 

윈도우 미디어 플레이어의 경우도 이와 크게 다르지 않은 상황이다. 이미 컴퓨터를 통해 미디어 파일들을 즐기는

사용자들이라면 자신들의 PC에 한 개 이상의 미디어 플레이어를 설치해 놓은 상태이고,

그 사용 방식에 있어서도 mp3 파일 등 음악 파일을 듣는 경우와 비디오 파일을 시청하는 경우에 따라 각기 다른 애플리케이션들을

사용하고 있는 실정이다.

 

이미 시장에서는 전혀 한쪽으로의 치우침 없이 각각의 애플리케이션들이 자신들만의 독특한 기능들을 무기로

건전한 경쟁을 벌이고 있는 상황임에도 불구하고 공정위는 MS의 윈도우 OS의 목젖인 미디어 플레이어를 제거하려 들고 있는 것이다

 

윈도우에서 미디어플레이어가 제거된 제품을 이미 출시했던 EU의 예를 신중히 살펴야 한다.

과연 누구를 위한 공정 경쟁이며, 누구를 위한 시장 정의란 말인가?

 

공정위 유감

공정위는 현재 공정한 시장 경쟁 체제가 불가능하다고 지적한 미디어플레이어 시장과 메신저 시장에 기존의 업체들과의

공정한 경쟁을 위해 마이크로소프트사의 미디어플레이어와 메신저를 분리하여 출시해야 하며 경쟁 제품들을 선택하여

설치할 수 있는 링크를 이용자들에게 제공하여 윈도우 미디어플레이어 이외의 제품을 선택하여 설치 할 수 있는

기회를 주도록 할 것을 지시했다. 하지만 이것은 또 다른 불공정 행위에 다름이 아니다.

수 많은 후발 업체들이 앞으로 미디어플레이어 시장과 메신저 시장에 뛰어들 수 있는 개연성이 높은 현 상황에서

특정 경쟁 업체들에 대한 링크를 제공해야 한다는 권고 자체가 바로 공정위 스스로 공정한 경쟁을 가로 막는 또 다른

불공정 행위를 조장하고 있는 것이다.

 

수 많은 소프트웨어 개발 업체에서는 자신들만의 특화된 기술을 통해 많은 이익 창출의 기회를 만들고자 노력하고 있고,

그러한 개발 업체들은 서로간의 경쟁을 통해 시장에 자리매김하고 때론 퇴출당하면서 스스로의 시장을 형성하고 있다.

 

공정위가 지적한 메신저 시장과 미디어플레이어 시장 역시 다르지 않다.

공정한 시장 상황에서 윈도우 플랫폼으로써 제공되고 있는 미디어 플레이어와 메신저(메신저 시장에서의 메신저와는

구분 지어야 할)가 과연 이 두 개의 시장의 질서를 교란하고 공정한 경쟁을 막고 있는지를 곰곰이 생각해 봐야 할 것이다.

 

공정위는 무엇보다 OS의 일부로써의 개발 플랫폼(컴포넌트)과 소프트웨어의 성격을 구분 지어 판단해야 한다.

 

이러한 명확한 판단이 이루어 지지 않은 성급한 결정은 자칫 소프트웨어 산업의 타격과 아울러

여러 소비자들의 피해만을 양산하게 될 것이다.

 

마지막으로 이번 결정이 국내 개발자들에게 어떤 영향을 미칠 것인지를 다시 판단해주기를 바란다.

이미 H/W와 통신 중심으로 개편된 국내 IT 산업에서는 개발자들의 활로는 다국적의 공용 애플리케이션을 개발하는 것뿐이다.

해외 시장을 생각하는 개발자들에게는 MS의 윈도우 그리고 관련된 제품과 기능들은 전세계 시장으로 진출할 수 있는

중요한 채널 역할을 한다. 필자의 회사도 독일, 덴마크, 미국, 홍콩 등 해외 시장을 접촉할 수 있게 된 것도

MSInfopath IE가 있었기 때문이다.

개발자와 한국 S/W 산업에 대한 영향은 생각하지 않고 단편적인 경제학과 정치 논리로 국내시장을 보호한다면

개발자와 S/W 산업의 세계화는 희망이 없어지고 만다. 이번 결정을 위해 죽어있는 경제 논문과 법률 조항을 읽고

교수들을 만날 시간에 “The World is flat”을 읽고 인도와 중국의 IT 전문가들을 만나볼 것을 권한다.

 

진정으로 공정위가 IT시장에 있어서의 공정한 시장 질서 확립을 원한다면, 그에 대한 노력을 경주해야 할 곳이 단지

미디어 플레이어와 메신저 시장에 있지 않다는 것을 자신들 스스로가 더 잘 알고 있을 것이라 생각한다.