Heart’s Develop Inside

ENTClic@blog……just another day - 엑티브엑스 방어하는 개발자들 정신 좀 차려라..

특정 글을 비판하기 위해 포스팅을 해 보기는 처음이군요.

올블 서핑하다가 찾은 포스트인데, 읽고 그냥 넘어가려다가 제목에 기분이 그다지 좋지 않아서(솔직히 확 상해서) 개발자의 입장에 대해 좀 길게 써보려고 포스팅합니다.
뭐 이 포스트의 출처가 유명한 블로그이고 올블로그 TOP 100 임은 신경쓰지 않겠습니다. 블로고스피어에 특권계층이란 존재하지 않아야 한다고 믿기 때문입니다.

바로 작년이었죠, 웹표준에 대한 관심이 한창 달아오르고 있었고, 때마침 ‘싸이월드 불여우 사과 이미지 사건’까지 겹쳐서 온 블로고스피어가 떠들썩했습니다.
논쟁에는 당연히 두 편이 있어야 했고, 그 편은 단순하게 나누자면 ‘IE 유저’와 ‘비 IE 유저’ 였습니다.
그 때, 비 IE 유저가 비판의 근거로 들고 나온 게 ActiveX이죠.

보안 취약, Windows에만 지원함을 이유로 ActiveX를 비난하는 포스팅이 줄지어 올라왔습니다.
근데 그거 아십니까?
그 중에 ActiveX에 대한 완벽한 대안을 제시한 포스팅은 없었습니다.
(혹시 보셨다면 꼭 리플이나 트랙백을 통해 알려주시기 바랍니다. 보고 반성좀 하게요.)

제가 이전에 웹 표준에 대해 약간은 회의적인 입장에서 쓴 글을 링크하겠습니다.(당시의 글 보기)
제가 던진 질문에 답변해 주신 분들 중 보안, 공인인증서 등에 대해서는 대안을 제시하시는 분들이 많았습니다. 하지만 RIA로 활용되어 로컬 자원을 접근하는 ActiveX에 대한 대안을 제시하시는 분은 제 글에도, 그리고 블로고스피어에서도 보지 못했습니다.

저도 개발자이면서 컴퓨터 유저이고, 특히 파폭 유저이기도 합니다.
그렇기 때문에 비 ActiveX로 충분히 대체 가능한 것들은 대체가 되었으면 합니다.(저도 파폭 씁니다. 답답한 거 저도 몸으로 느낀답니다.)
다만, 모든 상황에서 대체 가능하지는 않다는 점을 좀 이해해 주셨으면 합니다.

또한 아무리 IT가 기술에 의해 하루가 다르게 변한다고 하는 직종이라고 해도 신기술이 상용 시장에서 활용되는 데에는 충분한 시간이 필요하다는 것도 인지해 주셨으면 합니다.
(이유에 대해서는 많이들 아시겠지만, 하나는 기존의 프로그램을 버려야 한다는 것이고, 또 하나는 개발자들의 재교육에 드는 시간과 노력, 그리고 금전적인 문제입니다.)

개발자들, 누구보다 신기술 좋아하는 사람들입니다. 그렇지 않은 사람들은 개발에 흥미를 잃고 몇 년 못가서 나가떨어지기 마련입니다.
하지만 이런저런 사정을 따져보았을 때 ‘이건 어렵다’ 라고 생각되는 건 어쩔 수 없는 것입니다.

그런데 ActiveX를 변호한다는 이유로 저렇게 포괄적으로(어쩔수 없는 것인지, 아니면 귀찮아서인지는 명시하지 않은 채) 싸잡아 까내리는 포스팅을 보니 참 안타깝네요.

문장실력이 형편없어서 더 논리적으로 적지 못한 점, (원치않게도 초보 개발자를 통해 변호받게 된)이 땅의 개발자 분들과 (이 분야의 전문가의 의견을 듣고 싶으실)컴퓨터 유저 분들께 죄송하게 생각합니다. 이상으로 저의 생각을 정리하고자 합니다.

출처는 미친병아리님 홈페이지… 원문보기

ActiveX 만들 때 마다 찾게 되어서 아예 퍼왔음… 물론 허락 없이 퍼왔다 -_-;;
(댓글이나 뭐 이런 걸 달 수 있는 게시판이 아닌 관계로;; 미친병아리님의 삭제 건의가 들어오면 바로 삭제…)

- 아래부터 펌글 시작 -

<< IObjectSafety 인터페이스를 구현하는 방법 >>

이 인터페이스를 구현하기 위해서는 GetInterfaceSafetyOptions와
SetInterfaceSafetyOptions 두개의 함수가 필요합니다. 이것은 퍼즐ocx를 예
를 들어 설명하겠습니다.

우선 [Controlname]Ctrl.h 파일에 ObjSafe.h를 Include하고 클래스에 다음과
같은 코드를 삽입합니다.

그리고 cpp 파일에 다음과 같은 코드를 삽입해 주면 됩니다.

그리고 자세한 사항은
http://premium.microsoft.com/msdn/library/techart/msdn_signmark.htm
에 상세히 설명되어 있으니 참조해 보세요..

1. 짤막한 사용 경험이 있는 초보 프로그래머의 글이고, 사용했던 게 2004년 말이니 현재와 조금 다를 수 있습니다. 잘못된 부분이 있으면 바로잡아 주시기 바랍니다.

2. Signed Applet이 적용된 프로젝트는 Programmer/Portfolio 구분에 있는 WebHard 입니다.

3. 태터툴즈 위지윅 에디터를 썼더니 도무지 문서 내 링크를 못하겠네요… 잡설을 제외하고 보시려면 본론부터 보시면 됩니다.

서론

2004년 11월, 학원 프로젝트로 웹 하드 구현을 선택했다.
순전히 내 아이디어였고, 벤치마킹할 사이트도 있었다.

선택된 프로젝트가 내 아이디어였고, 팀장 역할도 내가 했기 때문에 설계 파트는 거의 내 몫이었다.
난 우선 벤치마킹한 사이트와 우리 팀의 환경이 다르다는 것 부터 정리해보기 시작했다.

그 사이트는 php + ActiveX 조합이었지만 학원 과정 자체가 XML & EJB Expert(쉽게 말하면 자바 과정)였기 때문에 XML과 EJB가 들어가지 않을 지언정 Servlet & JSP는 써야겠다는 생각이 들었고, 파일 서버 프로그램과 ActiveX 또한 자바로 구현해야겠다는 생각이 들었다.

웹 사이트야 JSP로 구현하면 되는 것이고, 파일 서버도 우선 성능을 논외로 하고 Swing으로 얼추 구현하기로 마음먹었다.

문제는, ActiveX를 자바로 대체하는 방법이었다.

이 과정에서 관련 자료를 많이 찾아보았지만, 내 짧은 지식으로는 한계가 있었다.
‘Applet으로 얼추 하면 되겠지’ 했던 게 샌드박스의 보안을 미처 생각 못했던 것이다.
그렇게 찾아나서는 중에 학원 강사님의 도움으로 ‘Signed Applet’ & ‘Live Connect’라는 기술을 알게 되면서 실마리를 조금씩 풀고, 소켓 통신 및 DB 접속, 파일 업로드/다운로드를 구현할 수 있었다.

본론

ActiveX를 대체하기 위해 내가 사용했던 기술을 간략하게 설명해 보겠다.

Live Connect는 간단하게 자바스크립트와 애플릿 간의 통신을 말한다.
별 내용 아니므로 생략…

Signed Applet이란, 말 그대로 Applet에 서명을 넣는 것이다.
(물론 jar로 묶고 jar에 인증을 한다)
서명을 넣음으로써 샌드박스에게 ‘나 이런 인증도 받았는데 나 믿을 수 있지? 그러니 로컬 좀 건들자~’ 라고 할 수 있는 것이다.

어디서 많이 본 것 같지 않은가?
맞다. ActiveX의 캐비넷 인증과 같은 방법이다.

하도 이전 꺼라 스크린샷을 보여줄 수는 없지만, 설치할 것인지 물어보는 것도 ActiveX를 처음 띄울 때와 비슷하고, 내용 변경이 없으면 한번만 다운로드한다는 것도 비슷하다.

그런데, 이 Signed Applet 때문에 시행착오가 꽤 있었다.

브라우저/JRE 버전에 따라 구현 및 서명 시에 차이가 있다는 게 문제가 된 것이다.

어떻게 차이가 있는지는 기억이 나지 않지만, 관련 자료를 좀만 찾아보면 방법이 여러가지임을 확인할 수 있다.
특히 문제가 됐던 게, 다른 브라우저는 JVM을 사용하는 반면, IE는 MSVM을 사용하기 때문에 다른 브라우저와 Signed Applet 만드는 방식이 달랐던 것으로 기억한다.
결국 프로젝트에는 IE에 맞추어서 만들 수 밖에 없었다. 시간도 없었고…

결론

사실 ActiveX의 대안으로 Signed Applet을 지명하려면, 서명이라던지 구현이라던지 반드시 일관적이어야 한다.
하지만 그 요구사항을 충족시키지 못하기 때문에 대안이라고 말하기에는 2% 부족한 감이 있다.(지금은 어떤지 모르겠다.)

그리고, ActiveX보다 속도가 조금 느린 것도 사실이다.(자바의 단점임)

추가적으로, Signed Applet도 로컬 자원에 액세스할 수 있는 권한을 가지는 것이므로, 악용될 소지가 있다는 것은 ActiveX 나 이거나 마찬가지이다.

그리고, 애플릿의 버전과 같은, 혹은 더 높은 JVM을 설치해야 정상적으로 동작한다는 것도 단점 중에 하나이다.(이것도 자바의 단점)

어찌됐던, Signed Applet은 위에서 언급한 문제가 해결이 된다면 자바의 최대 특혜인 Multi Platform에 힘입어 ActiveX를 대체하는 웹 표준 기술로 자리잡을 수 있을 것이라고 생각한다.

그 전에는… 글쎄… 좀 더 생각해봐야 할 문제일 듯…