네이버 실버라잇 카페에 올라온 질문(http://cafe.naver.com/mssilverlight/166)에 대한 나름대로의 생각이에요.



사용자 리소스에의 무제한적인 접근.
이것이 바로 ActiveX가 훌륭한 기술임에도 불구하고 사방팔방에서 뭇매를 맞게된 가장 큰 원인이죠.
ActiveX에 대해 오해가 생기지 않도록 얘기하자면 엄청나게 길어지겠지만, 과감하게 압축해서 얘기해볼께요. 다소 엉뚱한 주장이 들어가더라도 이해해 주세요.

ActiveX는 애초에 HTML의 한계를 벗어난 동적인 웹애플리케이션을 작성하기 위한 시도였어요. 무려 10년도 전에 이미 지금 말하는 RIA라는 것에 대한 고민과 하나의 해답이었던거죠.

시장의 흐름을 캐치하고 빠르게 ActiveX를 발표한 것 까진 좋았는데, MS가 늘 그래왔듯이 초기에는 거대한 구멍투성이의 기술이었고 이를 애초의 목적인 동적인 UI 구성에 사용하는게 아니라 갖가지 악의적인 구멍으로 사용되어 버렸죠.

해외에서는 진작에 이런 문제점들과 플랫폼 종속적인 한계 때문에 최강의 기술이었던 ActiveX를 사용하기 보다는 다소 불편한 DHTML, JavaScript, CSS 등의 기술들을 더 선호하게 되고 급기야 구글맵으로 유명해진 AJAX를 탄생시키게 되었죠.

반면 국내에서는 해외와 달리 일반 유저의 IE 의존도가 99% 이상이었기 때문에 애초에 플랫폼을 고려할 필요가 전혀 없었고 보안 문제는 누구 하나 지적하는 일 조차 없었어요. 국내 개발자들을 탓하는게 아니에요. 보안... 당장 한달 걸릴 일을 1주일만에 해내라고 닥달하는데 누가 신경이나 쓸 수 있었겠어요? 여하튼.

그런 와중에 ActiveX의 무분별한 사용을 어느정도 제어하기 위해 XP SP2가 출시되었지만 국내는 이미 ActiveX 중독 말기환자였고 정상적으로 ActiveX를 꼭 필요한데만 사용하는게 아니라 사용자에게 'ActiveX 설치 어쩌고 나오면 예를 누르세요', '팝업이 막히면 풀어주세요' 이따위 대응을 하게 되었던 거죠.

이 점은 강력하게 개발자를 성토할 수 있어요. 분명히 중독에서 치료될 수 있는 기회였는데 스스로 거부한 셈이죠. 여하튼.

이런 역사(?)때문에 ActiveX가 웹애플리케이션의 전부인양 생각하게 되었고 웹애플리케이션이 사용자 리소스에 접근하는데 아무런 거리낌이 없게 되었지만, 단정적으로 얘기해서 웹애플리케이션은 사용자 리소스에 접근 할 수 없고 접근 해서도 안되는 거에요!

ActiveX에 대해 정리하자면,
1. ActiveX는 동적인 UI 구성 등을 기존 윈도 개발자가 빠르게 접근할 수 있도록 도와주기 위해 나온 기술이다.
2. 하지만 그 무한한 접근권한 때문에 원래 의도와는 달리 철저하게 악용되는 기술이 되어 버렸다.
3. 그런 문제 때문에 ActiveX의 무분별한 사용을 줄이고 다른 방법으로 웹애플리케이션을 구현하게 되었는데 국내에는 중독에서 헤어나오지 못했다.
4. 그 결과 국내에서 ActiveX를 통해 사용자 리소스에 접근하는 것에 대해 아무런 의문도 문제점도 느끼지 못하게 되었다.

이에요.

다음 실버라잇으로 넘어가서, MS는 어느 매체에서도 실버라잇으로 ActiveX를 대체할 거라고 발표한 적은 없어요.

다시 한번 강조하지만 실버라잇과 ActiveX는 개미 눈꼽만큼도 비교할 만한 기술이 아니에요.

비교한다면 실버라잇, Flex(플래쉬도 아닙니다), JavaFX인지 뭔지(이쪽은 관심이 없어서 이름도 잘 몰라요;;;) 이 정도 되겠고요.

심지어 DHTML도 실버라잇과 비교할만한 기술은 아님과 동시에 DHTML, CSS, JavaScript, AJAX 등의 기존 기술은 실버라잇과 함께 사이좋게 연동할 수 있는 평행한 관계라고 보면 되겠습니다.

Q. 그럼 도대체 실버라잇을 왜써요?
A. 좋은 질문이죠. 한마디로 압축하자면 실버라잇은 RIA를 구현하기 위한 기술이에요.

Q. 그럼 기존에 플래쉬도 Flex도 있는데 뭐하러 써요? 머리아프게?
A. 실버라잇은 프리젠테이션의 표현을 XAML이라는 XML로 완전히 공개적으로 제공하며 따라서 프리젠테이션의 교환, 다시말해 디자이너와 개발자와의 협업이 훨씬 더 유연해질 수 있어요. 그리고 이 XAML은 일반적으로 컴파일되지 않고 공개되므로 다른 웹애플리케이션, 다른 서비스들과 동일한 코드를 가지고 연동할 수 있어서 디자이너-개발자 수준을 떠나 서비스-서비스 수준의 협력이 가능해요.

단순히 기능적인 면만 살펴봐도 이미지 리소스와 동영상 리소스에 대한 런타임 자체의 지원이 실버라잇 쪽에 압도적으로 우세하고 특히 실버라잇은 완전한 클라이언트 기술로 서버 사이드에는 아무런 제약이 없기 때문에 Flex처럼 별도의 라이센스 서버나 라이센스된 코덱 같은 추가적인 낭비가 필요 없어요.

이 외에도 말하자면 엄청나게 많지만 이쯤하죠. 자세한 검색은 셀프.

Q. 그건 그렇다치고 그러니까 왜 내가 만든 실버라잇 프로그램으로 사용자 리소스에 접근 못해요? 우리 서버랑 통신도 해야되고 백도어도 만들어야 되고 파일 업/다운도 해야되는데...
A. ActiveX 편을 다시 복습하시기 바래요. 그리고 지금 백도어 까는걸 자랑이라고 하는거니? 응? 응? 응?

추가적으로 TCP통신 기능에 관해서는 Silverlight 1.1 개발팀에서 심각하게 그 방법을 제시하기 위해 노력한다고 MS의 로렌스 모로니씨에게 '직접' 들었어요.(맞아요, 자랑하는거에요. 히히 싸인도 받았지롱~) 실버라잇 개발 로드맵 상에도 WCF 기술이 포함되는 것은 거의 확정적이라고 보고 있으니 이 부분에 대해서는 조금 기다려야겠고, 지금 당장 필요하다면 서버사이드에 프록시를 만들어 연동할 수도 있어요.

Q. 에고... 그럼 파일 업/다운은요?
A. 옙. 돼요. 실버라잇은 사용자 리소스에 대한 접근과 크로스 도메인(외부 주소)에 대한 접근을 아주 철저하게 막고 있지만 몇 몇 애플리케이션 개발에 필수적인 수단은 제공해요.

예를 들어 파일 업로드를 위해 파일 목록을 얻어야 한다면 그 파일 목록을 개발자 코드가 지 꼴리는대로 검색해서 가져갈 수 있는게 아니라 사용자에게 업로드할 파일을 선택하는 다이얼로그를 띄워서 사용자가 직접 선택하게 되어 있고 다운로드 역시 다른 곳에 악용될 수 있는 시스템 폴더(C, C:\Windows, C:\Windows\System32) 따위에 명시적으로 접근할 수 있는게 아니고 실버라잇 웹애플리케이션에 종속적이고 암시적이며 다른 애플리케이션에 고립된 영역에 저장돼요. 만약 사용자가 저장을 원한다면 마찬가지로 저장할 위치를 결정하는 다이얼로그를 통해서만 가능하죠.

Q. 아 짱나 그냥 ActiveX 쓸래요.
A. 옙, 그러세요. 한가지 안좋은 소식이 있다면 VISTA 이후로 ActiveX가 예전처럼 지 꼴리는대로 사용자 리소스를 헤집을 수 있게 놔두지 않을거에요. 아직 레거시 지원때문에 이런저런 유도책을 제공하고 있긴 하지만 단언코 말하건대 ActiveX의 사용자 리소스 접근은 결국 막히게 될거에요. 뭐, 그때까지 생명연장의 꿈을 꾸는 것도 나쁘진 않겠죠. 모름지기 개발자는 꿈을 품고 살아야하니까요. ^-^

그냥 라이브 타이핑(?)하다 보니 말이 막나간 점도 있긴 하지만, 이 긴 문장들은 단 하나의 문장으로 요약할 수 있겠어요.

웹앱(Web Application)은 웹앱이요 데스크탑앱은 데스크탑앱이로소이다.

P.S.1. 혹시나 또 오해가 있을까 말해두지만, 질문 올리신 네오군님을 공격하기 위한 설명이 아니에요;; 나름대로 재미있게 쓴답시고 저렇게 쓴거니까 삐지지 마세요.
P.S.2. 추가적인 의견 대환영~♥

Posted by gongdo

Submit comment.

  1. Favicon of http://blog.naver.com/super810910 BlogIcon 슈퍼낙훈 2007.07.11 02:29  comment URL  Edit/Remove  Submit comment.

    그에 대한 모든 해결책은 ActiveW 에 있을텐데요....

    워.....

    죄송함당^^;

  2. Favicon of http://log.ssen.name BlogIcon SSen 2007.07.11 09:33  comment URL  Edit/Remove  Submit comment.

    ActiveX 만큼 막무가내는 아닌것 같지만, 비스므레한 수준까지 가는게 xbap 가 아닐까 싶어요. 아직 제대로 만져보질 못해서 잘은 모르겠지만요. 웹게임을 만드는데 flash 로 못만들던것들을 xbap 로 만들수 있을것 같아서 살펴보는 중입니다. 뭐 좀 쓸만하다 하니깐 크로스 플랫폼이 안되고, silverlight 크로스 플랫폼 되니깐 이건 하드웨어 렌더링이 아니라서 퍼포먼스가 여전히 살인적으로 부족하고 죽겠네요...

    일단 데스크탑 자원을 멋대로 뚫어쓰는 개념이 아닌, 데스크탑으로 개발되던 자원을 웹브라우저 상에서 동작시킨다는 개념으로 보면 xbap 가 ActiveX 의 계보를 잇는게 맞는것 같아요.

  3. ㅎㅎ 2007.07.11 10:04  comment URL  Edit/Remove  Submit comment.

    하지만 현업에서 아직 vc+6 로 코딩해 주지 않으면 소스를 거부하는 회사도 많답니다...
    대다수의 나이 많은 코더들은 십년동안 공부를 거의 않한다고 봐요...
    후배들에게 그런 소리 듣지 않도록 노력하는중....

  4. Favicon of http://blog.naver.com/inasie BlogIcon 김플레 2007.07.11 10:51  comment URL  Edit/Remove  Submit comment.

    XBAP은 웹어플리케이션용이 아니라 윈어플리케이션(WPF)를 인트라넷상에서 쉽게 배포할 수 있게 만들었다고 얼핏 들은적이 있어요
    다시말해 XBAP이 웹 어플리케이션을 만들기위해 쓰이진 않을것이다라는 말이었죠
    대신 웹을 위해선 SILVERLIGHT(저 말을 들을 당시엔 WPF/E였죠..)를 사용하라
    라고 들은적이있어요

    제가 잘못들은건가요 ? -_-;;

  5. Favicon of http://blog.naver.com/inasie BlogIcon 김플레 2007.07.11 10:53  comment URL  Edit/Remove  Submit comment.

    이매진컵이라는 대회에서 저도 XBAP을 이용한 게임을 만들었었는데요
    다른 웹서버와 통신하는 과정에서(OpenAPI를 이용한 게임이라 XML을 받아서 처리해야했죠)
    보안설정때문에 애먹은적이있어요

    사용자 데스크탑에서 열리질 않더군요.. 결국 개발한 사이트를 신뢰할 수 있는 영역까지 올려주는 과정을 거쳐야 보이더라구요~ 매우 불편했어요 - -;;

  6. Favicon of http://gongdo.tistory.com BlogIcon 공도 2007.07.11 12:41  comment URL  Edit/Remove  Submit comment.

    음... XBAP이 ActiveX를 대체한다... 그건 일리가 있는 얘기에요.
    현재 ActiveX는 레거시 지원때문에 울며 겨자먹기로 보안 레벨을 최고 수준으로 높히지 못하는 부분도 있는데 XBAP은 애초에 원하는대로 보안 레벨을 확 높혀버렸죠.

    그래서 김플레님의 경우처럼 배포를 해봤더니 잘 안되더라...하는 일이 생길 것 같은데요, XBAP과 WPF 애플리케이션의 가장 큰(거의 유일한) 차이는 바로 보안 레벨이에요.
    WPF는 일단 사용자가 애플리케이션 실행에 동의하면 Full-trusted로 동작하고 XBAP은 사용자가 어떤 동의를 거치더라도 Partial-trusted로 동작하기 때문에 로컬 리소스 접근에 제한이 생기죠.
    그래서 XBAP으로 개발할 때에는 보안 가이드를 철저하게 따를 필요가 있어요.

  7. Favicon of http://gongdo.tistory.com BlogIcon 공도 2007.07.11 12:47  comment URL  Edit/Remove  Submit comment.

    그런데, 설령 닷넷 프레임웍 3.0, 3.5가 크로스플랫폼이 된다고 해도 그걸 기반으로 진행하기는 무리가 있을거에요. 닷넷 프레임웍 3.0은 런타임만 해도 수십메가바이트인데 이걸 사용자에게 설치하도록 강요하는 것은 굉장히 납득되지 않는 일일 것 같거든요.

    최근 드는 생각이지만, 하드웨어 가속지원씩이나 필요한 애플리케이션이라면 애초에 리눅스나 맥을 위해 개발하는 회사가 드물지 않나요? 굳이 웹이 아니더라도 말이죠. 리눅스는 몰라도 맥은 일반 사용자 층이 상당하니까 어쩌면, 만약, 혹시라도 MS에서 맥을 위한 닷넷 런타임을 내줄지도 모른다는 생각은 하고 있지만... 리눅스쪽은 모노 프로젝트가 잘 되길 바래야죠^^;

  8. lcsco@paran.com 2009.01.22 03:29  comment URL  Edit/Remove  Submit comment.

    한가지만 여쭤 보고 싶은데요
    데탑의 리소스를 사용을 못한다면 FA를 하는쪽에선 시리얼통신을 해야하는데
    이런 사용자들의 요구사항이 있어요
    이런 것들은 어떻게 해야 하는가요?

    • Favicon of http://gongdosoft.com BlogIcon gongdo 2009.01.22 12:59  comment URL  Modify/Remove

      모든 걸 실버라이트로 해야 할 필요는 없겠죠?
      시리얼 통신을 하는데 웹 플랫폼을 고수해야 할 필요도 없겠고요.

  9. Favicon of http://lcsco.tistory.com BlogIcon 현애비 2009.01.22 15:39 신고  comment URL  Edit/Remove  Submit comment.

    그렇게 된다면 웹에서 USB, Rs232와 같은 자원을 읽는것은 ActiveX를 사용하는 방법외에는 대안이 없는건가요?
    저는 ActiveX에 대해 하루 빨리 없어져야 되는 물건이라는 생각을 하고 있어요
    특히 은행사이트 무신 ActiveX를 그렇게도 많이 까는지 컴퓨터를 지 맘대로 깔아버리니 쩝
    외국에서는 ActiveX를 무분별하게 사용하지를 않을텐데...

    • Favicon of http://gongdosoft.com BlogIcon gongdo 2009.01.22 22:48  comment URL  Modify/Remove

      모든 것을 웹에서 해야 한다는 일종의 강박 관념이 문제일 수도 있죠.
      만약 웹 플랫폼이 그 본래의 의미처럼 모두에게 열려있는 투명한 접근성을 가지고 있다면 USB나 시리얼 포트 등의 민감한 사용자 리소스에 접근하는 것을 허용해서는 안될 거에요.

      만약 사용자 로컬의 리소스에 접근하는 것이 목적이라면 웹보다는 ActiveX또는 데스크탑 애플리케이션을 만드는 것이 더 적합하겠고요.

      ActiveX는 나쁜 물건이 아니라 올바른 용도로 사용되지 않았을 뿐이라고 생각해요.

  10. Favicon of http://lcsco.tistory.com BlogIcon 현애비 2009.01.23 06:43 신고  comment URL  Edit/Remove  Submit comment.

    답변 감사합니다.
    전 개인적으로 생각컨데 TCP도 열어주는데 통신리소스(USB,프린트)등은 열어주는게 맞지 않나 싶어요.(지극히 개인적인 생각)
    데탑의 자료를 직접 억세스 하는건 안된다 손 치더라도(데탑의 특정 폴더를 사용할 수 있음 더 좋겠지요)
    특정 리소스와 통신은 가능해졌으면 하는 바람이네요 ^^;;