전자서명법과 공인인증서

2006.09.04 글쓴이 youknowit

  1. PKI
  2. 암호화 알고리즘
  3. 전자서명법령이 정한 기술 규격(준비 중)
  4. 정통부의 처분이 전자서명법에 위반되는 이유
    • MS 제품을 사용하지 않는 자는 소수에 불과하다는 주장
    • 비용이 많이 들고 관리에 어려움이 있다는 주장
    • 대안 기술이 현재로는 존재하지 않는다는 주장
  5. 즉시 실행 가능한 대안들
    • 자바 애플렛
    • 브라우저 확장 플러그인
  6. 위법한 현 상황을 시정하는 방법
    • 현재의 솔루션에 새로운 솔루션을 추가하는 방법
    • 현재의 솔루션을 새로운 솔루션으로 대체하는 방법
  7. 정보통신부 장관의 책임와 의무
  8. 장기적 계획
  9. 인터넷 금융거래 표준 사양

1. PKI

인증서(certificate)는 공개키 기반구조(Public Key Infrastructure; PKI)를 토대로 하여 암호화 교신(서버인증서의 경우)과 본인확인/거래내역 부인방지(클라이언트 인증서의 경우) 기능을 수행하는데 사용됩니다.

서버인증서의 경우, SSL (secure socket layer) 또는, 그 후속 기술이라 할 TLS (Transport Layer Security) 프로토콜에 기초하여 교신 당사자 간에 주고 받는 메시지를 암호화하는데 사용됩니다. 메시지 암호화는 양 당사자가 공통의 열쇠(shared key)를 가지고 있는 상태에서 일방이 그 열쇠로 데이터 암호화해서 보내면, 상대방이 같은 열쇠로 그것을 복호화하는 구조를 취합니다(대칭키 암호화). 그러나, 네트웍을 통하여 연결되어 있는 양당사자 간에는 공통의 열쇠가 안전하게 전달/전송되어야 하는 문제가 먼저 해결되어야 하는데, 이것을 위하여 동원되는 것이 비대칭 암호화 기술 입니다. 즉 공통의 열쇠를 네트웍 상에서 안전하게 공유하는 과정(hand-shake 과정)에서 일방이 자신의 개인키로 암호화해서 보낸 정보를 상대방이 그 개인키와 쌍을 이루는 공개키로 복호화 하거나, 일방이 상대방의 공개키로 암호화해서 상대방에게 보낸 정보를 상대방은 개인키로 복호화 해서(이것이 비대칭 암호화 방식입니다) 공통의 비밀을 공유하는 방법이 사용됩니다. 이렇게 일단 공통의 열쇠가 공유되고 나면, 모든 메시지는 대칭 암호화 방식으로 암호/복호화가 이루어집니다.(물론, 서버측만이 인증서를 제시하는 방식의 교신인가, 아니면 서버와 클라인언트가 모두 인증서를 제시하는 방식의 교신인가에 따라 구체적 과정은 조금 다릅니다)

한편, 클라이언트 인증서는 고객의 신원을 확인하는 용도와 거래 내역에 대한 전자서명을 하는 용도에 사용됩니다. 먼저, 인증기관은 어떤 자(가입자)의 신원을 비전자적 방법으로 확인한 다음(대면확인), 그 자에게만 고유한 개인키와 그 개인키와 유일한 연결관계에 있는 그자의 공개키를 만들어 주고, 그 공개키를 인증기관이 전자서명하여, 누구도 그 공개키를 변조하지 못하게(변조하면 당장 그 사실이 드러나게) 합니다. 이렇게 생성된 인증서는 인감증명서에 해당하고, 고객에게 만들어 준 개인키는 인감도장에 해당합니다. 거래를 하고, 그 거래내역을 적은 문서에 도장을 찍으면, “인영”이 생겨납니다. 전자서명은 바로 이 “인영”에 해당합니다.

고객의 인영(전자서명)을 전달받은 상대방은 과연 그 인영이 고객의 인감(개인키)으로 만들어 낸 것인지를 확인하기 위하려, 고객의 인감증명서(인증서)를 이용하여 인영과 대조(서명검증)하게 됩니다. 이 검증과정이 성공하면, 그 인영이 부착된 문서에 적힌 내용은 고객이 직접 서명한 것이라는 고도의 개연성이 인정됩니다. 그러나 이러한 효과를 거두기 위해서는 먼저 고객의 개인키(인감)가 유출되지 않았다는 점이 보장되어야 합니다. 만일 고객의 컴퓨터가 침입 공격을 받아 고객의 개인키가 공격자의 손에도 있는 상황이 되면, 전자서명을 아무리 받아도 소용이 없습니다. 그 전자서명이 과연 고객이 한 것인지, 공격자가 한 것인지를 판단할 방법이 없기 때문입니다.

전자서명 기술은 인터넷이 광범하게 보급되기 전(90년대 중반)에 등장한 기술입니다. 그때에는 개인 컴퓨터에 대한 해킹이 오늘날과 같으리라고는 상상을 못하였던 시절이었고, 그런 시절에는 훌륭한 부인방지 수단이라고 환영받았으나, 요즈음에는 전자서명은 별 의미 없는 기술로 취급되고 있습니다. ‘누군가’가 그런 내용의 거래를 하였다는 점을 확인할 수는 있으나, 그자가 과연 고객인지, 공격자인지를 전자서명으로는 가려낼 수 없기 때문입니다. 개인키 유출을 방지할 수 있는 저장매체(보안토큰)에 저장된 인증서(복제 불가 인증서)만이 부인방지 효과를 실제로 거둘 수 있으나, 이러한 저장매체를 다수의 고객에게 배포하는 작업은 매우 큰 비용이 들고, 보안토큰은 새로운 기기(스마트폰)에서는 사용이 불가능한 제약이 있습니다.

2. 암호화 알고리즘

정보는 암호화 알고리즘(encryption algorithm)을 적용하여 잠그고/풀고 합니다. 암호화 알고리즘은 여러가지가 있는 바(인터넷 백과사전인 Wikipedia 에 소개된 것만도 약 60 여 가지가 됩니다), 3-DES, BlowFish, IDEA 등과 함께 한국이 독자 개발한 SEED가 있습니다.

이러한 알고리즘은 암호화의 “원리”만을 제시할 뿐, 그것을 응용하여 컴퓨터 프로그램(application)으로 만들기 위하여는 이 알고리즘을 응용프로그램이 “불러와 쓸 수 있는” 이진(binary) 파일로 된 라이브러리가 필요합니다. 예를 들어, 3-DES 알고리듬을 구현할 수 있는 라이브러리로는 미국의 RSA Security 라는 회사가 개발한 BSAFE Crypto-C, Crypto-J 등의 라이브러리가 있고, 그 회사는 이 라이브러리에 대하여 특허권을 가지고 있습니다. 한편 DSA (digital signature algorithm) 라는 알고리즘을 구현할 수 있는 라이브러리 중에는 OpenSSL 이라는 이름으로 개발된 라이브러리가 있고, 이것은 공개소스로서 상용(商用) 여부를 불문하고 대부분 무료로 사용할 수 있습니다. 이 공개소스를 기초로 하여, 국산 SEED 알고리즘을 구현한 라이브러리장 혜식님이 2001. 경에 이미 만들었으며, 현재 오픈소스 툴킷 중, GNU libgcrypt (GPL), Botan (BSD), libtomcrypt (public domain) 등이 장혜식님의 라이브러리를 이용하여 SEED알고리즘을 지원하고 있습니다. 여기 참조.

4. 정통부의 처분이 전자서명법에 위반되는 이유

공인인증 업무를 취급하려는 자는 정보통신부 장관의 인가를 받아야 합니다(전자서명법 제4조). 정보통신부 장관은 신청자가 관련법규에 규정된 요건을 충족 하는지를 심사하여 공인인증기관으로 지정할지 여부를 결정하도록 되어있고, 이 심사절차의 자세한 사항은 전자서명법 시행령 제2조 및 제3조가 규정하고 있습니다. 현재, 한국정보인증(주), 금융결제원, (주)코스콤, 한국전산원, 한국전자인증(주), 한국무역정보통신이 공인인증기관으로 지정되어 있습니다.

그러나 이 어느 곳도 전자서명법이 규정하는 요건을 충족하지 못하고 있음에도 정보통신부 장관은 이들을 공인인증기관으로 지정한 위법이 있습니다. 그 이유는 다음과 같습니다.

전자서명법 제8조는 공인인증서 제도 운영의 기술적 측면을 규율하는 “전자서명인증 업무지침”(이하, “업무지침”)을 마련하고 시행하는 근거가 되는 규정입니다.

현행 업무지침(2003.11.27. 발효) 중 이 사안과 직접 관련 있는 조항은 다음과 같습니다. 업무지침 제10조 제1항은 공인인증기관이 전자서명키를 생성할 때 적용하여야 할 알고리즘을 지정하고, 제11조 제1항은 서명생성키를 보호하는데 사용되어야 할 보안모듈을 지정하고, 제11조 제2항은 서명키 암호화에 사용 되어야 할 알고리즘, 그리고 제18조 제2항은 전자문서를 암호화할 때 적용되어야 할 알고리즘을 규정하고 있습니다.

업무지침에서 언급된 이들 각 알고리즘과 모듈에 대하여는 “공인인증기관의 시설 및 장비 등에 관한 규정”에 첨부된 “기술규격”에 그 기준이 제시되어 있습니다.이 기술규격은 한국정보보호진흥원이 마련하여 게시하고 있습니다.

이 기술규격은 특정한 하나의 알고리즘 이나 보안모듈의 사용을 강제하지 않습니다. 예를 들어, 암호 알고리즘(기술규격 2.3)은 3-DES 또는 SEED를 사용하도록 되어 있고, 3-DES는 오픈소스로도 널리 구현되어 있는 알고리즘입니다. 기술규격이 어떤 배타적인 구현기술이나 특정 OS 또는 특정 브라우저에 종속된 기준을 정해둔 것은 더더욱 아닙니다. 오히려 “공인인증기관 간 상호연동을 위한 사용자 인터페이스 기술규격”(기술규격 6.1)은 MS 윈도즈 운영체제와 그 외의 운영체제를 모두 염두에 두고 작성되어 있습니다. 특히 그 개정연혁을 보면, “비 MS 윈도즈 사용자의 편의성을 고려하여 기술규격[이] 개정”(2003.12.) 되었음을 분명히 알 수 있습니다.

공인인증기관으로 지정된 여섯 곳 모두, MS사가 판매하는 운영체제와 MS사의 브라우저를 동시에 사용하지 않으면 공인인증서의 발급신청 조차 할 수 없도록 하는 기술을 사용하고 있습니다. 이것은 전자서명법 하위 규정에 부속된 기술규격 미달이라는 문제에 그치는 것이 아니라, 근거법률 자체를 어기는 것입니다. 이하에서 자세히 설명하겠습니다.

전자서명법(이하, “법”) 제7조 제1항은 다음과 같이 규정하고 있습니다:

공인인증기관은 정당한 사유없이 인증역무의 제공을 거부하여서는 아니된다.

법 제19조 제1항은 또한 다음과 같이 규정하고 있습니다:

공인인증기관은 자신이 발급한 공인인증서가 유효한지의 여부를 누구든지 항상 확인할 수 있도록 하는 설비 등 인증업무에 관한 시설 및 장비를 안전하게 운영하여야 한다.

법 제22조의2 제2항은 또한 다음과 같이 규정하고 있습니다:

공인인증기관은 이용자가 공인인증서에 의하여 다음 각호의 사항을 확인할 수 있도록 쉬운 수단을 제공하여야 한다.

1. 공인인증기관의 명칭 등 공인인증기관임을 확인할 수 있는 정보
2. 가입자가 당해 공인인증서가 발행된 당시에 전자서명생성정보를 지배·관리하고 있는 사실
3. 공인인증서의 발행 전에 전자서명생성정보가 유효한 사실

인증서 발급신청자가 MS 제품을 사용하지 않는 것이 인증역무의 제공을 거부할 “정당한 사유”인지에 대하여 우선 살펴보겠습니다.

첫째, MS 제품을 사용하지 않는 자는 소수에 불과하다는 주장

이 주장은, 잘못된 정책으로 생긴 결과를 이용하여 잘못된 정책을 정당화 하려는 시도에 불과합니다. MS 제품의 시장점유율이 한국에서 유난히 높아진 이유는 한국의 인터넷환경이 MS 전용화 되어 있기 때문입니다. MS 제품을 사용하지 않으면 공인인증서를 발급 받을 수 없고, 공인인증서를 사용하지 못 하게 되는 순간, 이용자는 인터넷 상에서 “신원불상자”, 정체불명의 위험 인물로 전락하게 되므로 조금이라도 (재산적 또는 비재산적으로) 의미 있는 인터넷 사용은 더이상 할 수 없게 됩니다. 이런 정책하에서 비 MS 제품 사용자가 늘어나기를 기대할 수는 없습니다.

세계 시장에서의 MS 운영체제(클라이언트 PC 용)의 시장 점유율은 다음과 같습니다:

표 2
운영 체계 2000 2001 2002
MS Windows 92.1 93.2 93.8
맥 OS 3.9 3.1 2.9
리눅스 1.7 2.3 2.8
기타 2.4 1.3 0.5

[출처: MS 사에 대한 EU Competition Commissioner 의 결정문 para. 434]
*출하량 기준
그러나 같은 기간 동안 한국 내에서의 시장 점유율은 다음과 같습니다:

운영 체계 2000 2001 2002
MS Windows 3,715,135(98.5%) 3,320,098(99.3%) 3,504,029(99.4%)
맥 OS 26,100 6,790 14,489
리눅스 30,931 15,038 7,404

[출처: 한국소프트웨어진흥원/(주)한국IDC 자료(2004. 9.)]
공정거래위 심결 <표 3.5> *출하량 기준
정부는 독점의 폐해를 규제하고, 경쟁을 촉진함으로써 소비자의 권익을 보호할 의무가 있습니다(독점규제 및 공정거래에 관한 법률 제1조 참조). MS제품을 사용 안하는 자가 별로 많지 않으니 그들에게 인증서비스 제공을 거절함으로써 그 수를 더욱 줄이겠다는 것은 정부로서는 도저히 입에 담아서는 아니 될 말입니다.

그러나, MS윈도즈 운영체제를 사용하더라도 MS사의 웹브라우저(IE)를 사용하지 않으면 인증서비스를 제공받을 수 없습니다. 파이어폭스(Firefox)와 오페라(Opera) 웹브라우저는 적지 않은 윈도즈 사용자들이 선호하는 브라우저 입니다. 세계 브라우저 시장의 점유율은 다음과 같습니다:

브라우저 2005. 4. 2006. 1. 2006. 5.
MS IE 86.63 85.82 85.17
파이어폭스 8.69 11.23 11.79
사파리 1.26 1.88 2.02
오페라 1.03 0.77 0.79

출처:
http://www.onestat.com/html/aboutus_pressbox42_microsoft_internet_explorer_has_slightly_increased.html
http://www.onestat.com/html/aboutus_pressbox37.html

국내 통계는 잘 알 수 없으나, IE 외의 브라우저도 MS전용화된 웹페이지를 그나마 조금이라도 더 처리하여 이용자에게 보여주기 위하여, 서버에게 자신을 마치 IE브라우저인 것처럼 “기술적”으로 보고하는 경우도 많으므로, IE 브라우저의 실제 시장점유율은 위의 수치보다는 낮습니다. 파이어폭스, 사파리 또는 오페라 웹브라우저를 선택한 이용자들에게 인증역무 제공을 거부함으로써 그들이 IE 브라우저를 쓰도록 압박을 가하는 행위는 그 숫자의 많고 적음을 떠나서 정부가 특정 브라우저의 배포와 확산을 편파적, 노골적으로 지원하고 있다는 의혹을 사기에 충분합니다. 잠재적으로는 국제 분쟁으로 비화할 염려도 없지 않습니다(이점은 후술).

둘째, 공인인증서 제도를 브라우저나 OS에 의존하지 않게 하려면 비용이 많이 들고 관리에 어려움이 있다는 주장

이러한 주장을 정부가 감히 제기한다는 것은 매우 놀라운 일입니다. 인증기관은 인증사업을 통하여 영리를 추구하는 주체입니다. 인증기관으로서는 저렴한 비용으로 많은 고객을 유치하고 이윤을 최대화하는 것이 당연한 관심사 입니다. 그러나 이들의 적나라한 이윤추구 욕망을 제어, 감독함으로써 우리의 전산환경이 왜곡되지 않게 하는 것이 정보통신부의 의무 입니다. 공인인증기관이 되려면 정통부 장관의 인가를 받도록 해 두는 이유는 바로 여기에 있습니다. “공인인증기관은 정당한 사유없이 인증역무의 제공을 거부하여서는 아니된다”는 조항을 전자서명법에 못박아 둔 이유도, 이 조항이 없으면 사업편의와 이윤극대화라는 私益추구에 골몰한 인증기관이 국가의 전산환경 전체를 엉망으로 만들고, 우리의 소프트웨어 산업에 치명타를 가하는 부당한 결과를 낳을 위험이 크기 때문입니다.

MS전용의 인증서 처리 솔루션을 채택함으로써 위 여섯 곳의 인증기관이 절약한 비용이 얼마가 될지는 잘 모르겠습니다. 그러나, 이들 기관의 사업규모는 다음과 같습니다(2005.1.1 – 2005.12.31).

인증기관 자산 규모 영업 수익 인증업무에 소요된 비용 영업 이익
한국정보인증(주) 20,638,436,589 14,057,931,307 ? 1,296,203,294
금융결제원 2004년말 현재 전체 공인인증서의 71%를 발급하는 시장지배적 사업자
(주)코스콤 157,735,905,431 176,713,893,508 ? 17,012,297,892
한국전산원 2005년 예산 => 5,242억원 중 3,966억은 집행하고 1,276억은 이월
한국전자인증(주) 2005년 자료 미입수 ? ? ?
한국무역정보통신 95,846,320,040 51,347,995,672(매출액) ? 13,935,662,378

출처 :

[다른 기관과는 달리, 금융결제원 홈페이지(http://www.kftc.or.kr/kftc/main.jsp)는 예산 규모를 공시하지 않고 있습니다. 금융결제원 회계 관련 자료를 검색, 수배하여 알려주시기 바랍니다.]
마치 정통부가 이들 업체의 이익을 대변하는 하수인 인양, “비용이 덜 들고, 관리가 쉽다”는 이유를 내세워, MS전용화 된 배타적 솔루션으로 인증기관 지정신청을 해 온 이들 업체에게, 전자서명법 규정을 어겨가면서까지 인증기관 지정처분을 해준 결과, 우리의 소프트웨어 산업은 초토화되고, 우리의 전산환경은 MS에 예속되게 되었습니다. 2003.9.에 이미 정통부 소프트웨어진흥과 김영문 사무관(그 당시)은 “우리나라 소프트웨어산업은 미국에서 수입한 소프트웨어에 약간의 부가가치를 덧붙이는 수준” 이라며 “이런 구조를 바꾸지 않고서는 소프트웨어산업을 키울 수 없다”고 지적한 바 있습니다. (한겨레 신문, 2003.9.1. 보도) 정통부는 공익을 수호할 의무가 있는 것이지, 개별 사업자의 영리추구를 위하여 망국적인 전산환경을 초래할 것이 뻔한 인증기관의 제안을 받아들여서는 아니된다고 생각합니다. 따라서, “비용이 더 들고, 관리에 어려움이 있다”는 것은 MS 제품을 사용 안하는 자에게 인증역무 제공을 거절할 “정당한 사유”가 되기는 어려울 것입니다.

셋째, MS 전용 인증서처리 솔루션이 제공하는 보안사양과 보안수준을 구현하는 대안 기술이 현재로는 존재하지 않는다는 주장

이것은 사실과 다릅니다. 이점을 자세히 설명하겠습니다. 인증서를 사용한 거래가 현재의 솔루션에서 처리되는 구조를 은행 거래를 예로 들어 보면 다음과 같습니다.

  1. 은행 웹서버가 사용자 컴퓨터로 보내 온 양식에 사용자가 계좌번호, 금액, 보안카드 번호 등을 입력하고 “확인”버튼을 누른다.
  2. 입력된 값(정보)이 사용자 컴퓨터 내에 가동되는 ActiveX 콘트롤에 공급된다.
  3. ActiveX 콘트롤은 이 정보에 전자서명을 부착할 필요가 있는지를 판단하고, 그럴 필요가 있으면 인증서 암호를 사용자에게 요구하여 확보한 다음 전자서명을 부착한다. 이때 사용자의 개인인증서에 포함된 그의 잠금쇠(공개키)도 부착된다.
  4. 이렇게 모아진 정보를 웹서버가 보내온 잠금쇠(기관인증서에 포함되어 있는 공개키)로 잠근 다음, 투명하게 공개된 네트웍을 통하여(http 프로토콜을 사용) 암호화된 정보를 내보낸다.
  5. 암호화된 정보를 받은 웹서버는 자신이 보관하는 비밀키를 이용하여 암호를 풀고, 인증 서버에 접속하여 사용자가 보내온 인증서가 유효한지를 확인한 후, 요구된 작업(예를 들어, 계좌 이체)을 한다.
  6. 작업 결과를 담은 정보(이체 처리 내역)를 사용자의 공개키로 잠근 다음 네트웍을 통하여 암호화된 정보를 사용자에게 보낸다.
  7. 사용자의 컴퓨터는 받은 정보를 ActiveX 콘트롤에 공급하고, ActiveX 컨트롤은 사용자의 비밀키로 이 정보를 열어 사용자 화면에 보여준다.

이 과정에서 ActiveX 콘트롤이 수행하는 역할은 위 3, 4, 7 에서 필요한 작업을 사용자의 웹브라우저 속에서 처리하고 그 결과를 웹브라우저에 그려내는 “mini 응용프로그램”, 즉 애플렛(applet)의 역할입니다. “애플렛”은 주어진 어떤 응용프로그램의 내부에서 특정 기능을 수행하여 그 응용프로그램의 기능성을 높이는 “부속 프로그램”입니다. 많이 알려진 애플렛으로는 자바 애플렛, 플래시 무비, 윈도즈 미디어 플레이어 애플렛 등입니다.

그러나 ActiveX 콘트롤은 원래는 MS사가 만든 비쥬얼 베이식스(Visual Basics)라는 개인용 컴퓨터 프로그램 개발도구의 하나로 등장한 소프트웨어 컴포넌트 기술이었습니다. 그 후 MS사가 자신의 브라우저(IE) 사양을 개조하면서 ActiveX 콘트롤을 통하여 기존에 데스크탑 프로그램에서만 쓰이던 윈도즈의 여러 소프트웨어 컴포넌트(예를들어, 풍부한 편집 기능을 제공하는 RichEdit, 엑셀과 같은 스프레드 시트 기능 등)을 웹브라우저 속으로 불러들일 수 있게 되었습니다. 이 방법을 사용하여 MS사는 경쟁사인 Sun Microsystems 사가 개발한 java applet과 비슷한 효과를 거둘 수 있게 됩니다. ActiveX 콘트롤을 이렇게 애플렛처럼 사용하는 MS사의 독특한 해법에 대하여 Wikipedia는 다음과 같이 평가하고 있습니다:

Microsoft later modified the Internet Explorer web browser to use [ActiveX Controls] to incorporate applet-like functionality into web pages. Because of that later use, ActiveX Controls have since been much derided in the mainstream and technical press for their ability to be used by unethical developers to create computer viruses, trojans and spyware infections.

그 후 MS사는 IE 웹브라우저를 개조하여 ActiveX 콘트롤을 통하여 애플렛과 비슷한 기능을 웹페이지에 구현하도록 하였다. ActiveX 콘트롤이 이런식으로 사용되었기 때문에 이 분야의 주류적 견해와 기술문헌에서 ActiveX는 많은 조롱을 받고 있는데, 그 이유는 악의적인 프로그래머가 이 방법으로 컴퓨터 바이러스, 트로이 목마, 스파이웨어 등으로 사용자의 컴퓨터를 감염시킬 수 있게 되었기 때문이다.

MS 사의 이러한 해법이 조롱과 비난을 받는 더 중요한 이유는, Sun 사가 개발한 자바 기술은 인터넷 콘텐츠가 사용자 컴퓨터의 하드웨어 설계구조(architecture)나 소프트웨어 운영 체제(OS) 또는 브라우저에 상관없이 두루 구현되어 정보의 막힘없는 소통 가능성을 열었음에 반하여, MS 사의 전략은 오로지 자신의 운영체제와 자신의 브라우저만이 처리할 수 있는 기술을 사용하여 자바 애플렛과 비슷한 결과를 거두게 한 다음, 윈도즈 운영체제의 시장지배력을 사용하여 ActiveX를 확산 시킴으로써 정보의 소통이 또다시 OS와 브라우저에 종속되도록 시도하(여 성공하)였기 때문입니다.

우리 공인인증서가 채택한 기술은 MS사의 이러한 독점 유지 및 정보 차단 전략에 철저히 봉사하는 것일 뿐 아니라, 심지어 국내 일부 은행은 위 6 과 7에 언급된 단계에서 암호화 하지 않은 정보를 그대로 네트웍으로 내보냄으로써 고객들의 송금, 계좌이체 내역, 잔고 등을 누구라도 큰 어려움 없이 인터넷 상에서 엿볼 수 있게까지 하고 있습니다.

[전자서명법 제19조 제1항과 제22조의2 제2항에 대한 논의 ... 준비 중]

5. 즉시 실행 가능한 대안들

현재의 솔루션과 같은 수준 또는 더 나은 수준의 보안을 확보할 수 있는 대안으로서 지금 당장 사용 가능한 것들은 다음과 같습니다.

자바 애플렛

ActiveX 라는 배타적 해법 대신에, 보편적 구현이 가능한 자바 애플렛을 사용하는 방법입니다. 자바애플렛이 사용자 컴퓨터의 웹브라우저에서 실행되는 구조는 간단합니다. 웹페이지 속에 자바 애플렛을 불러오라는 명령어가 발견되면 사용자 컴퓨터의 웹브라우저는 웹서버로부터 필요한 프로그램(java bytecode)을 내려받은 다음, 이 프로그램이 사용자 컴퓨터에서 실행됩니다. 즉, 위에 적은 3, 4, 7 의 단계에서 필요한 일을 수행할 프로그램을 웹서버가 실시간으로 사용자에게 제공하는 것입니다. 이렇게 내려받은 프로그램이 사용자의 컴퓨터에서 실행되는 환경은 매우 높은 수준의 보안이 확보된 환경입니다. 내려받은 프로그램은 컴퓨터에 설치되는 것이 아니고, 사용자 컴퓨터 안에 임시로 마련되는 가상의 컴퓨터(java virtual machine, sandbox)에서 그 즉시 실행되며, 가상컴퓨터와 사용자 컴퓨터 간에는 여러 보안 장벽이 마련되어 사용자의 컴퓨터가 외부 프로그램으로 부터 보호되는 구조입니다. 반면에, ActiveX가 가지는 보안상 취약점에 대하여는 여기 참조.

이 방법이 가지는 장점은, 우선 탁월한 안전성(security)이 확보되고, 운영체제에 구애 받지 않고 범용이 가능하다는 점(cross-platform application), 사용자가 컴퓨터에 관리자 권한으로 어떤 프로그램도 설치(install)할 필요가 없다는 점입니다. 관리자 권한이 없는 일반 사용자도 자바 애플렛을 불러와서 실행할 수 있다는 점은, 한국의 전산환경에서는 선뜻 그 장점을 이해하기 어려울지 모르나, 제대로 관리된 전산 환경에서는 극소수의 전문 인원만이 관리자 권한으로 컴퓨터를 사용한다는 점을 이해하면, 매우 중요한 장점입니다. 예를 들어, 현재의 공인인증서를 착탈식 저장매체(플로피, usb memory stick 등)에 저장하여 외국에서 사용하고자 하는 경우, 그 나라의 학교나 회사 등 네트웍으로 관리되는 컴퓨터에서는 윈도즈 운영체제와 IE브라우저를 사용하더라도 우리의 공인인증서를 이용할 수는 없습니다. 왜냐하면, 인증서 사용을 위하여는 컴퓨터에 추가프로그램을 설치하여야 하는데, 네트웍 관리자가 이것을 함부로 허락할리 없기 때문입니다. 외국의 공항, 인터넷 카페, 기타 공공 장소에 제공된 컴퓨터는 우리 나라와 같이 아무나 관리자 권한으로 프로그램을 마구 깔고 지우고 하도록 방치된 경우가 거의 없습니다. 결국 우리 공인인증서를 사용하려면, 윈도즈가 탑재된 개인용 컴퓨터를 하나 마련하여 들고 다니는 수 밖에 없습니다.

자바 애플렛의 단점은, 애플렛을 내려받는데 약간의 시간(약 1, 2 초 가량)이 소요된다는 점과, 사용자 컴퓨터 내에 가상컴퓨터가 마련되는 동안 약간(1, 2초간) 기다려야 한다는 점 입니다. 그러나, 한국과 같이 “초고속” 인터넷 망이 널리 확산된 경우 내려받는 시간은 더 이상 문제가 되지 않고, 일단 가상컴퓨터가 한번 마련되고 나면, 컴퓨터를 끄지 않은 이상 즉시로 자바애플렛의 실행이 가능하므로, 사용 편의성에 큰 문제가 있다고 볼 수는 없습니다.

국내 보안업체는 이미 플래시와 자바 애플렛을 사용한 공인인증서 처리 솔루션 개발을 완료한 상태입니다.

브라우저 확장 플러그인

플러그인(plugin)은 애플렛과 같이, 어떤 응용프로그램이 실행되는 맥락 하에서 그 응용프로그램 이용에 도움이 되는 특정한 부가적 기능을 수행하는 보조 프로그램 입니다. 때로는 확장(extension)이라 불리기도 하는데, 이 방법을 사용하면 주된 응용프로그램의 덩치를 줄이는 대신, 사용자마다 자신이 원하는 부가기능만을 선택적으로 추가하여 각자에게 적합한 이용편의성을 확보하게 되므로 각 개인이 컴퓨터의 리소스를 효율적으로 이용할 수 있게 됩니다. 특히 종속프로그램과 주프로그램간의 연락과 리소스 호출방법 및 규격을 제시하는 API가 투명하게 공개되어 있는 경우, 전 세계의 어떤 프로그래머더라도 자신이 생각해 낸 기발하고 독특한 부가기능을 수행하는 종속프로그램을 만들어 인터넷을 통하여 제공함으로써 주 프로그램 기능성의 무한한 확장이 가능하게 됩니다. 주응용프로그램의 소스코드와 정확하고 자세히 설명된 API가 완전히 공개된 파이어폭스 브라우저가 그 대표적인 예입니다. 공개소스에 기반한 파이어폭스 브라우저는 이처럼 자발적으로 형성되는 전세계의 개발자 공동체(developers’ community)에 의하여 계속 변화, 발전해 나가게 되는 것입니다.

공인인증서 처리와 관련된 위 3, 4, 7 의 단계에서 행할 작업을 브라우저 내에서 수행하는 보조 프로그램(plugin)이 만들어 질 수 있음은 물론입니다. 그리고 이미 그러한 확장 플러그인은 국내 기술진이 개발을 완료한지 오래되었습니다.

자바 애플렛이나 플래시의 경우와는 달리, 확장 플러그인은 그 설치파일을 사용자 컴퓨터에 설치하여야 하는 불편이 있긴하지만, 현재 사용되는 ActiveX 콘트롤과는 달리, 관리자 권한이 필요없이 일반 사용자의 개인 파일 공간에 프러그인을 설치하도록 되어 있어 보안 위험을 크게 줄인다는 차이점이 있습니다.

그리고 신한은행은 2002. 경부터 매킨토시 이용자를 위한 공인인증서 발급, 사용에 필요한 단독 프로그램(EzPlus)를 구비하여 실제로 사용하기 시작하였고, 지금도 사용하고 있습니다. EzPlus version 2.0

이 사건 민원신청이 언론에 보도된 후, 정보 통신부는 국정홍보실을 통하여 다음과 같은 해명을 공식발표하였습니다:

전자민원시스템의 경우, 인터넷을 통해 전송되는 개인정보 및 금융정보를 보호하기 위해 ▲암호화 통신 ▲키보드 해킹 방지 ▲바이러스 방지 등 보다 강화된 보안기술을 필요로 하나, 현재 공개 소프트웨어 기반에서 상용화된 보안제품이 없다.

키보드 해킹 방지, 바이러스 방지 용도의 응용프로그램 설치파일을 배포하는 것은 이 사안과는 아무 관련이 없는 문제일 뿐아니라, 그 두 프로그램을 설치하도록 요구하는 것은 마치 ‘약을 건네 주면서 더 큰 병에 대한 잠재적 원인까지 함께 제공’하는 것이나 마찬가지 입니다. 이 프로그램들을 설치하려면 관리자 권한으로 컴퓨터를 사용해야하고, 이것은 사용자 컴퓨터를 더 큰 위험에 노출 시키는 결과를 초래합니다. 더욱이, 이런 프로그램의 배포를 위하여 ActiveX 콘트롤을 사용하여야 할 하등의 이유도 없습니다. 문제는 암호화 통신에 관한 것인데, 전자민원이건, 은행거래건, 공인인증서 발급이건, 현재는 모두 ActiveX 콘트롤을 사용하고 있지만, 이 세가지 모두 지금보다 더 나은 보안 수준을 확보하면서 브라우저나 OS에 의존하지 않는 기술적 대안이 이미 개발되었거나, 상용화 단계에 있은지 오래 되었습니다. 따라서 정통부의 공식 해명은 기초적인 사실부터 틀린 것입니다. 이렇게 부정확한 정보에 근거하여 업무를 수행하는 인력이 우리 전산체계의 운명을 좌우하는 권한을 행사한다는 것은 국민으로서 일말의 불안감을 가질 수도 있는 일이라 하겠습니다.

6. 위법한 현 상황을 시정하는 방법

크게 보아 두가지가 있습니다.

첫째, 현재의 솔루션에 새로운 솔루션을 추가하는 방법

기존의 방법을 그대로 사용하기를 원하는 이용자는 아무런 변화를 느낄 이유도, 필요도 없습니다. 인터넷 거래도 아무런 변화 없이 계속 될 것입니다. NPAPI 기반의 웹브라우저 확장을 사용한 솔루션이 추가되는 경우를 예로 들어 설명하겠습니다. 현재 공인인증기관의 홈페이지에는 발급신청 버튼이 하나 뿐이지만, 추가 솔루션이 제공되면 발급신청 버튼이 두개로 늘어납니다. 그리고 그 각 버튼에 다음과 같은 간략한 설명이 제시될 것입니다:

발급신청 (ActiveX 플러그인 사용)
발급신청 (NPAPI 플러그인 사용)

인증서발급 신청자가 첫번째 버튼을 누르는 경우는 지금과 완전히 동일한 과정이 진행됩니다. ActiveX 브라우저 플러그인을 웹페이지에서 내려받아, 관리자 권한을 가지고 이것을 사용자 컴퓨터에 설치하고, 그 설치가 끝나기를 기다린 다음 (약 5-10초 소요), 그 다음 단계로 진행합니다. 두번째 버튼을 선택하는 경우 이용자는 관리자 권한이 없더라도 플러그인을 설치하고, 전자서명거래를 할 수 있게 됩니다. 두번째 버튼은 리눅스, 매킨토시 사용자는 물론이고 윈도즈 사용자도 브라우저에 상관없이 누구나 성공적으로 인증서 발급절차를 완료할 수 있는 버튼이 되는 것입니다.

윈도즈 기반에서 IE브라우저를 사용해오신 분들은 첫번째 버튼을 만족스럽게 선택할 것입니다. MS 제품을 사용하지 않거나, MS 제품을 사용하더라도 ActiveX 콘트롤이 가지는 보안상의 취약점을 염려하는 이용자, 관리자 권한이 아니라 일반이용자 권한으로 컴퓨터를 사용하는 자는 두번째 버튼을 클릭할 것입니다.

웹서버에는 거의 아무런 수정도 필요 없습니다. 플러그인을 내려주는 페이지 소스에 몇줄을 수정하고나면, 나머지 모든 서버측 프로세스는 수정이 필요없습니다. ActiveX 플러그인이건, NPAPI 플러그인 이건, 그 플러그인을 호출, 구동하는데 필요한 파라미터 명칭이나, 필드값은 동일하게 설계하면 됩니다. 즉, 서버와 플러그인 간의 인터페이스를 표준화하면 어떤 플러그인이건 간에 서버가 이를 호출하여 사용할 수 있게 됩니다.

둘째, 현재의 솔루션을 새로운 솔루션으로 대체하는 방법

이 경우에도 이용자에게는 어떠한 불편이나 비용이 초래되는 것도 아닙니다. 컴퓨터를 잘 모르는 이용자는 변화가 있는지 조차 못 느낄 것입니다. 발급신청 버튼 마저도 지금 그 모습 그대로 유지하면 됩니다. 다만 인증기관의 웹페이지 소스에 몇 줄만 수정되면 기존의 서버 프로세스를 그대로 이용하여 모든 작업이 이루어집니다.

이 두가지 방법 중 하나는 전자서명법을 준수하기 위하여 공인인증기관이 지금 즉시 채택하여야 할 의무가 있는 사항입니다.

7. 정보통신부 장관의 책임와 의무

전자서명법은 매우 혁신적이고, 야심찬 내용을 담은 법입니다. 장차 대부분의 재산적, 비재산적 거래와 인간의 상호작용이 적어도 일부는 인터넷을 통하여 이루어질 가능성을 염두에 두고, 그 기반을 준비하고 초석을 놓는 의미에서 공인인증제도를 마련하는 법입니다. 그러나 인증 제도가 지금처럼 잘못 자리잡으면, 얼마 가지 않아 MS 제품을 사용하지 않는 국민은 정체불명의 “불가촉 천민”으로 전락하여 인터넷 상을 떠돌게 될 것입니다. 우리의 전산망 전반과 정보통신 소프트웨어 산업이 건강하게, 독립적으로 성장할 가능성도 영영 말살 됩니다. 이러한 위험천만한 결과를 예방하고자 전자서명법은 정통부 장관에게 매우 강력한 권한을 부여하여, 그로 하여금 우리 전산 환경에 대한 중립적 감시자역할을 맡기고 있습니다.

전자서명법 제11조는, 공인인증기관이 인증역무의 제공을 거부하거나 가입자 또는 인증역무 이용자를 부당하게 차별한 경우에 정통부 장관은 기간을 정하여 시정조치를 명할 수 있다고 되어 있고;
제12조는 인증기관이 이러한 시정명령을 정당한 사유없이 이행하지 아니한 경우에는 정통부 장관은 인증업무의 전부 또는 일부의 정지를 명하거나 지정을 취소할 수 있다고 되어 있습니다.
그리고 제34조는, 정당한 사유없이 인증역무의 제공을 거부하거나 가입자 또는 이용자를 부당하게 차별한 자에 대하여는 정통부 장관이 과태료를 부과하도록 규정되어 있습니다.

국민의 위임을 받은 입법자가 이러한 규정들을 전자서명법에 둔 이유는 바로 지금과 같은 상황이 올 것을 우려하였기 때문입니다. 전산망을 통하여 제공되는 정보와 서비스에의 접근이 부당하게 거절되어서는 안된다는 점은 관련 법률 곳곳에 거듭 강조되는 바입니다. 예를 들어, 정보화 촉진 기본법 제16조의2 제1항은 정부는 정보통신망에 대한 자유로운 접근과 이용을 보장하고 지역적·경제적 차별이 없는 균등한 조건의 보편적 역무가 제공될 수 있도록 필요한 시책을 강구하여야 한다고 규정하고 있습니다. (이외에도 정보화 촉진 기본법 제3조 제3호, 제5조 제8호, 제13조; 정보격차 해소에 관한 법률 제3조, 제7조, 제8조, 제9조, 제16조 등 참조) 이 규정들의 혜택이 MS 제품 사용자에게만 베풀어져야 한다고 믿는 정통부 관계자는 없을 것입니다. MS고객 전용서비스가 관련 법에서 말하는 보편적 역무일 수는 없습니다.

인증기관이 오로지 자신의 이윤을 극대화하기 위하여, 존재하지도 않는 기술적 어려움을 과장하고, 사용자가 많지 않다는 이유로 MS 고객이 아닌 자들에 대한 인증역무 제공을 거부하는 지금의 상황은 전산망국으로 가는 벗어날 수 없는 궤도에 갇혀 있는 형국입니다. 기술적 어려움이 있다는 이들 업체의 주장은 사실과 다릅니다. 1997-1998 당시에는 Netscape 브라우저 용 플러그인을 제공하였습니다. 지금 이들 업체들이 IE 브라우저 외의 다른 브라우저에 대한 지원을 중단한 이유는 기술적 이유가 아니라 사업상의 이유로 선택한 결정입니다. 현재 우리 보안 업체들은 주요 브라우저에 대한 인증서 처리 솔루션을 이미 가지고 있습니다. 어느 인증기관도 이 기술을 구매하지 않기 때문에 사용되지 않을 뿐, 현실적으로 구현이 어렵다는 인증업체의 주장은 거짓입니다.

이러한 위법하고 부도덕한 상황이 지난 몇년 간 계속되었음에도 정통부 장관은 인증기관에 대한 아무런 시정명령도 발동하지 않고, 아무런 조치도 취한 바 없습니다. 우리의 소프트웨어 산업이 크게 위축되고, 개인용 컴퓨터 OS 시장의 MS 점유율이 세계 최고 수준인 99.4%에 까지 이르게 된데에는 정통부 장관의 이러한 직무 유기가 그 결정적인 원인을 제공하였다고 생각합니다.

어느 누구도 정통부 관계자의 선의(善意)와 우리 전산산업 육성에 대한 열정을 의심하지 않습니다. 그러나 지금처럼 위법한 상황이 앞으로도 계속 방치된다면, 업체와의 유착이나 부패에 대한 근거없는 의혹이 제기되어 참여정부의 도덕성에 상처가 가는 불행한 사태가 올까 염려됩니다.

8. 장기적 계획

이상 제기한 점들은 지금까지 너무 오래 계속된 위법 상황을 시급히 시정하고, 고사(枯死) 상태에 있는 우리의 소프트웨어 산업을 조금이나마 소생시키는데 필요한 응급처방을 투여하는 수단입니다. 소프트웨어는 계속 이용하고, 가꾸어 나가야 유지되는 것입니다. 이용자가 없어지면 아무리 기술적으로 우월한 소프트웨어라도 사라지게 마련입니다. 온 국민의 컴퓨터에 ActiveX 컨트롤을 하나씩 설치하려는 정통부의 시도는 자살행위에 다름 아닙니다.

그러나, 응급처방을 투여한 다음에는 건강회복에 필요한 재활치료가 이루어져야 합니다. 올바른 정보화 정책을 마련하고, 이를 분명히 실천하고, 그 성과를 꼼꼼히 점검하는 행정 시스템이 필요한 부분입니다. 정보격차 해소에 관한 법률 제3조는 국가 및 지방자치단체는 … 모든 국민이 정보통신서비스에 자유롭게 접근하고 이를 이용할 수 있도록 필요한 시책을 강구하여야 한다고 되어 있고, 제16조 제1항은 정부는 모든 국민이 정보통신서비스에 자유롭게 접근하고 이를 이용하여 삶의 질을 향상할 수 있도록 지원하기 위하여 한국정보문화진흥원을 설립한다고 되어 있으며, 이에 따라 2003.1. 설립된 정보문화진흥원은 현재 연 예산 1,130억을 사용하고 있습니다(웹 페이지에 2006년도 예산은 113,193천원이라고 되어 있으나, 이는 오기인 것으로 보입니다). 그리고 정보화 촉진 기본법 제5조 제3항에 의하면, 정부는 정보통신 표준화의 촉진을 위한 기본 계획을 마련하고 추진할 의무를 지고 있습니다. 그리고 소프트웨어산업 진흥법 제12조는 정보통신부장관은 소프트웨어의 효율적 개발 및 품질향상과 호환성 확보 등을 위하여 소프트웨어의 표준화를 추진하고, 이를 위하여 표준화 활동에 필요한 예산을 지원할 수 있다고 되어 있습니다. 이 법에 따라 한국소프트웨어진흥원이 1998에 설립되었고, 2006년 기준으로 연간 2,550억원의 예산을 사용하며 활동하고 있습니다.

이러한 여러 법 규정에서 말하는 표준화가 MS전용화를 뜻하는 것이 아님은 분명할 것입니다. 이미 마련되어 있는 조직과 예산(합계 3,680억/년) 그리고 매우 전향적인 법제의 뒷받침을 받는 현 상황이라면, 공인인증서 처리 솔루션과 관련하여 다음과 같은 계획을 신속하게 검토, 확정, 실행하는데 별 어려움이 없을 것으로 생각합니다.

9. 인터넷 금융거래 표준 사양 (Electronic banking internet communication standard)

자바 또는 플래시 애플렛, 브라우저 플러그인 등의 해법은 지금까지 부당하게 차별 받아 왔던 일부 국민들에게 인터넷 이용의 길을 공평하게 열어 준다는 점, MS사의 기술에 철저히 종속되어 하청업자 수준으로 전락해 온 우리의 소프트웨어 산업에 재활의 길을 터 준다는 점, 공정거래법과 WTO 조약 상 정부가 부담하는 의무에 반하는 현재의 위법 상황을 신속히 시정하는 길이 된다는 점 등에 비추어 보아, 반드시 취해져야 할 조치임은 분명합니다. 그러나 프로그램 개발이 지금과 같이 업체의 통제 하에 있게 되는 업체 제공 해법(proprietary solution)이 라는 점은 여전히 문제로 남습니다. 또한, 위 해법 중 플러그인의 경우에는 컴퓨터 하드웨어 설계구조와 운영체제 그리고 브라우저 별로 각각 그 프로그램을 컴파일하고 관리해야 하는 부담이 있고, 계속 변화하는 컴퓨터와 브라우저의 사양에 상응하는 새로운 버전의 배포를 해당 업체에 의존하여야 하는 구조 역시 지금과 어느정도는 공통점이 있습니다.

이러한 문제점을 근본적으로 해결하고, 공개소프트웨어 진흥정책의 초석을 놓는 작업은 바로 인증서처리 및 인증서를 사용한 은행거래가 수행되는 각 단계에서 이루어 져야할 작업들의 자세한 표준 규격(표준 사양, 표준 프로토콜)을 정하여 이것을 공표하는 것입니다. 그렇게 되면 국내 외를 막론하고 어떤 프로그래머이든지 이 규격에 맞추어 애플렛이건 플러그인이건 클라이언트 용 솔루션을 독자적으로 개발 할 수 있고, 이렇게 개발된 소프트 웨어는 어느 인증기관이나 어느 은행에서건 가동 될 수 있습니다. 서버측 솔루션도 마찬가지 입니다. MS 전용 기술을 사용한 솔루션 개발업체도 동등하고 공평한 조건에서 서버용이건 클라이언트 용이건, 프로그램 개발 경쟁에 참여하게 되고, 인증기관이나 은행으로서는 이러한 전용 솔루션과 범용솔루션을 병행하여 자신의 고객들에게 제공하기로 선택할 수도 있고, 범용 솔루션 하나로 통합하여 제공하기로 선택할 수도 있는 것입니다. 이 양자 사이의 선택은 각 은행이나 인증 기관의 정당한 사업 결정의 몫으로 돌리면 됩니다. 이것이 공정한 경쟁이고, 이것이 시장의 기능입니다. MS전용 솔루션 만이 존재하고, 인증서처리나 인터넷 금융거래에 관한 아무런 표준사양도 없는 현 상황에서는 은행 등으로부터 계약을 따낸 업체 이외에는 누구도 어쩔 도리가 없습니다. 범용솔루션이 오픈소스 기반에서 개발될 가능성이 현재로는 원천봉쇄되어 있는 셈입니다.

One Pingback/Trackback

  • 몽몽이

    이 문제에 대해 장구한 글들을 볼때마다 느끼는게 있습니다.
    당초 소위 국내 오픈소스 진영에서는 기술적인 문제를 제대로 알고 있는 사람이 거의 전무하면서도 맨날 남탓만 하곤 했습니다. 맨날 MS탓, ActiveX탓, 심지어는 ActiveX 개발자가 단견이라는둥…
    이제사 이정도 글이 나오는데… 참 오래도 걸렸군요
    ActiveX 개발자는 다 아는 사실을…
    뭐 이제라도 fact를 정리는 했다고 치고… 그런데 대책이?
    대책이 고작 남의 탓이니까 언넘들이 책임져라… 그거?
    왜 그 잘난 Do it Yourself!!는 어디 국 끓여 잡쉈는지?
    진상도 모르고 남의 욕만 하던 그 오랜 시간동안 그렇게 쉽다는 자바 애플릿은 왜 안 만들었는지?
    그런 식으로 오픈소스를 쓰는 사람들은 소수라는 이유로 무시해도 당연하다고 봅니다. 아니 그러니까 무시당해왔다고 생각합니다.
    이제라도 오픈소스의 초심에 맞게 행동하길…
    Do it Yourself.

  • 몽몽이

    하나 더 부연하자면, SEED의 구현은 장혜식님이 구현한 것 외에도 무료로 쉽게 구할 수 있습니다. 문제는 이게 표준 구현에 포함이 안되었다는거지요. 하지만 ActiveX로 구현을 할 때에는 어차피 상관이 없으니까 개발자의 몫은 아니라는 겁니다. 굳이 행정적인 잘못을 지적하려면 이것이 문제일진 모르겠는데, 여하튼 “아쉬운 놈이 우물파라” 여기에 비춰보면 역시 Do it Yourself! 를 외치던 사람들 참 면목(염치?)없는거죠…
    불여우에서 SEED가 안된다고 투덜댈게 아니라 직접 추가에 나서는게 오픈소스 아닌가요? 윈도우 프로그래머는 투덜대는 대신 ActiveX로 그 문제를 해결했던 거거든요.
    누가 Do it Yourself 인지 모르겠군요.

  • youknowit

    몽몽이/
    VB script 하나로 지금껏 아무 일 없이 잘 나가다가, 갑자기 그 시대가 막을 내리고, 자신이 모르는 앞선 기술로 대체되려는 시점에서 “위기감”을 느끼시는 분들이 없지 않으리라 짐작합니다.

    그러나, 눈을 들어 멀리 보시기 바랍니다. 외국의 트렌드도 살펴보시기 바랍니다. VBscript로 떡을치는 기술적 선택이 도대체 무슨 문제를 일으키는지 조차에 대한 안목이 없는 “발주자”의 단견이 불러일으킨 문제이고, 오픈웹은 바로 그런 발주자를 대상으로 변화를 요구, 강제하고 있습니다.

    시장논리가 요구하는 것이면 무조건 제공하는 인력은 언제나, 어느 사회에나 있어 왔고, 앞으로도 있을 것입니다. 그것을 탓하는 것은 무의미 합니다.

  • 몽몽이

    youknowit/
    무슨 뜬금없는 말씀이신지? 글의 내용이나 제대로 파악하고 쓰시죠.

    윈도우 개발자에 대한 근거없는 우월감을 갖고 계시는가본데요. 무슨 뜬금없는 “위기감”? 생뚱맞네요.
    당신들이 내용도 모르고 성질만 부릴때 윈도우 개발자들이 인프라를 구축한겁니다. 말하자면, 닥치고 열개발.
    그 시간에 youknowit님은 뭘 하셨나요? 허허.

    시장논리를 탓하는 것은 무의미하다고 하셨는데 참으로 youknowit님 같은 분들에게 딱 맞는 말입니다. 시장논리에 의해서 youknowit님이 선호하는 비주류 환경이 외면된 것이 너무나도 당연한 것입니다. 그걸 가지고 억울하다고 해봐야 자기 얼굴에 침뱉는 짓입니다.

    다시 말하지만, 닥치고 Do it Yourself.

  • 몽몽이

    “위기감” 운운하는데 윈도우 기반 보안개발자들은 위기감은 커녕 일거리가 늘어 다행입니다. Vista나 IE 문제도 결국 여기서 성토만 해대는 youknowit님같은 분이 아니라, 그런 분들에 의해서 해결책이 제시되고 구현될 것입니다. 뒷북만 열심히 쳐 대실건지 궁금합니다.

  • 몽몽이

    눈을 들어 멀리 보시기 바랍니다.
    하늘은 스스로 돕는 자를 돕고, 미래는 입이 아니라 손이 좌우합니다. 오랜 불편을 겪는 동안 놀고 있었던 당신의 손이 부끄러운 줄을 아셔야 합니다.

  • http://www.filmstyle.net filmstyle

    뭐 제가 끼어들 여지가 없어보인다만, 몽몽이님이 뭘 잘 못 알고 계신것 같군요. 그리고 여기 그들은 모두 다 읽어보시긴하신건지요?

  • http://openweb.or.kr youknowit

    몽몽이/
    앞선 글에서 제가 “시장논리”를 언급하였는데, 그것은 부정확 한 것이었습니다. 수정합니다.

    VBscript (ActiveX)는 소비자에 의하여 선택되었다거나, 자유로운 경쟁을 거쳐 살아남은 기술이 아닙니다.

    외국에서는 이미 고사(枯死) 상태에 있는, 경쟁에서 패배한, 시장이 버린 기술입니다. 그런데 왜 대한민국에서만 이렇게 판을칠까요? 공인인증서 사용을 의무화 해놓고, 그것을 제공하는 자가 ActiveX로만 제공하므로, 소비자의 선택이 박탈되어있기 때문입니다.

    java, flash, XPCOM, ActiveX 중에서 선택할 수 있도록 해 두었다면, 과연 소비자들이 ActiveX를 자발적으로 선택하였을까요?

    공평한 경쟁이 불가능하도록 제도를 “반칙적”으로 만들어놓고, “시장이 선택했네” 어쩌구 떠드는 것은 무지의 소치이거나, 악의적인 왜곡에 불과합니다.

    제가 앞선 글에서 “시장논리가 요구하는 것이면 무조건 제공하는 인력”을 언급하였는데, 그 뜻은 수만, 수천만의 호주머니에서 돈이 새나가더라도, 우선 자기 호주머니에 돈이 들어오는 기술을 제공하는 인력을 말합니다. 안타깝지만, 그분들을 탓할 이유는 없습니다.

    그런 기술을 요구하는 자(금결원 같은 자)를 탓해야 합니다.

  • http://bluecity.tistory.com 푸른도시

    주제에 대한 토론은 좋지만 ‘닥치라’는 식의 표현은 좀 그렇군요. 삼가해 주시기 바랍니다.

    말씀하신 윈도우 관련 인프라에 저도 어느정도 관여해왔었기에 한말씀 드립니다. 획일적인 기준의 중심때문에 말씀하신 오픈소스등이 전혀 참여 못하게 했던것이 문제여서 그걸 바로 잡자는 것이지 윈도우 관련 개발자들이 잘못되었다는것이 아닙니다. 약간 오해를 하시고 흥분하시는것 같습니다.

    오픈 소스는 뭐했냐고 하시는데, 오픈 소스는 참여의 기회조차 주지 않았습니다. 그것이 문제인것이지요. 정부 솔루션 입찰에서는 아예 처음부터 기준을 잡습니다. 어떤 어떤 솔루션이 아니라, Windows를 기반으로 한 솔루션이라고 찍어서 이야기 하지요. 때문에 다른부분을 설명해저도 막무가네입니다.

    그러니 뭐했었냐는 말씀은 철회해 주시기 바랍니다. 말씀하신것처럼 윈도우 기반의 인프라를 구축하신 개발자분들이 열심히 하신것처럼 오픈 소스 기반의 개발자분들도 무던히 노력하신것이 없지 않습니다. 오픈소스로 개발한 솔루션도 많습니다. 빛을 보지 못하고 안타깝게 사라진 솔루션이 상당히 많습니다.

  • http://bluecity.tistory.com 푸른도시

    헉~ 제가 글을 쓰는동안 교수님이 답글을 다셨군요.
    제가 쓴글은 ‘몽몽이’님께 드리는 글입니다.

  • http://openweb.or.kr youknowit

    몽몽이/
    오픈웹은 개발자 분들을 비난하거나 폄하하는 것이 아닙니다. 이점은 제가 무수히 반복하여 설명드린 바 있습니다. 차분히 이 사이트에 게시된 글들을 읽어 보시면 오해가 풀릴 것입니다.

  • gomibak

    몽몽이님, 해박한 지식을 가지신 분인 듯 하군요. 액티브엑스에 대한 지식은 훌륭한 것이고, 그 기술을 잘 발전시켜 가는 것에 대해 그 누구도 욕을 하거나 하지는 않습니다. 몽몽이님처럼 높은 식견을 가진 분들의 도움을 받아서, IE이외의 브라우저에서도 불편없이 웹을 이용하고자 하는 마음들입니다. 액티브엑스를 선호하는 분은 그 기술을 쓰면 될것이고, 그 외의 다른 대안을 찾는 사람들에게는 그에 맞는 대안을 제시하면 되는 것입니다.
    여기에 글을 쓰는 많은 분들은 몽몽이님처럼 기술적으로 많이 알지를 못합니다. 이 분야와는 거리가 멀지만, 이용하면서 느끼는 불편을 해소하고자 여기저기서 자문을 얻어가며 다양한 환경에서도 불편없이 웹을 이용할 수 있게 되기를 바라는 사람들의 호소입니다. 궁극적으로는 이 운동이 한국 사회에 다양성을 인식하는 계기도 되면서, 또한 한국의 소프트웨어 산업에 더 나은 발전을 가져올 수 있을 것이라는 생각을 하고 있습니다.
    지금 현재가 좋다는 의견도 있을 수 있습니다만, 여기에 조금이라도 더 개선시킬 수 있는 방안이 없을까 함께 고민하는 장소이기도 합니다. 개선방향에 대한 몽몽이님의 의견을 들려주시면 고맙겠습니다.

  • 몽몽이

    너무 자주 글 남겨서 죄송합니다. 답글 잘 보았고요.
    그런데 ‘닥치고’라는 표현에 너무 상심하시는 듯 해서…
    쓰고 나니 안 좋은 표현이라 좀 후회스럽기도 한데 항간에 유행하는 표현을 쓰면 제 생각이 잘 전달될까 해서 쓴 것에 불과하고 악의적인 의도는 아니었습니다. 죄송합니다.

  • 두더딩

    한가지 의문 사항이 생기고 있습니다.
    단지 리눅스 사용자들 때문에 그무겁고 엄청난
    javase를 설치 해야 한다는건데..
    원도우 사용자들이 왜 피해를 입어야 하는지 모르겠군요

  • T. K.

    플랫폼에 구애받지 않는 보.편.성. 그것이 웹의 정신이기 때문입니다. ActiveX는 그 점에 완전히 배치됩니다. 태생부터 문제가 있는 것이었죠. (차라리 닷넷 프레임워크라면 그나마 이해라도 하겠습니다.)
    세계 어느 나라 웹사이트가 우리나라처럼 윈도 아닌 OS에서는 제대로 볼 수조차 없게 만들어져 있던가요?
    윈도 사용자가 피해를 입는 게 아니라 예전에 당연히 이루어졌어야 할 기본이 이루어지지 않아서 그것을 지금이라도 바로잡는 과정입니다.

  • T. K.

    그리고 세상에 윈도+IE 유저만 있다면 모르되 그게 아니잖습니까? 웹을 통해서는 세계 어떤 기종을 쓰는 사람이라도 동일한 서비스를 누릴 수 있어야 합니다. 그게 아니라 윈도+IE만 지원하는 웹이라면 브라우저 자체가 필요없겠지요.

    저보다 뛰어나신 분들께 부연설명을 넘깁니다. ^^

  • BKK

    두더딩 님,
    윈도우 사용자들은 JavaSE를 설치하는 불편함만 감수하면 끝이지만, 리눅스 사용자들에게는 ActiveX를 설치하는 것 자체가 누릴 수 없는 사치입니다.
    우리 리눅스 사용자들이 뭐 큰 보상을 원하는 것도 아니고, 단지 ‘웹 표준을 지키게’해 달라는 지극히 당연한 요구를 하는 것인데, 마치 윈도 사용자들이 피해를 입는다는 식으로 생각하시면 정말 슬픕니다.

  • http://mytears.org/ 정태영

    두더덩// 여러번씩 ‘예’ 를 클릭해가면서 ‘키보드 보안 프로그램’, ‘암호화 프로그램’, ‘피싱 방지 프로그램’, ‘방화벽’ 등 여러 개의 activeX 를 설치하는 것은 괜찮은데 왜 JavaSE 를 설치하는 것은 싫다는 건지 모르겠네요.

    어짜피 싸이월드 등에서도 Java 를 사용하는데 그럼 싸이월드도 윈도우 사용자들에게 피해를 전가시키는 사이트가 되겠군요.

    JavaSE 는 막상 그걸 사용하는 곳이 나타나기 전에는 백그라운드로 돌아가는 것도 없고 그냥 공간을 조금 차지하는 정도밖에 안됩니다. 괜히 백그라운드로 돌면서 다른 프로그램하고 충돌내는 ‘키보드 보안 프로그램’ 보다 100배 나아보이는데요. ;)

  • dkdlzhs

    정태영님의 말씀대로 ActiveX와 JAVA의 가장 큰 차이는 이 사이트 저 사이트를 들어갈 때마다 설치를 강요하는지 아닌지의 차이가 아닌가 싶습니다.

    저는 해외 거주하고 있어 JAVA로 구현된 Internet Banking과 국내용 ActiveX로 구현된 Internet Banking을 모두 사용하고 있습니다. Win or Mac, IE or FireFox 에서 가리지 않고 사용할 수 있는 시스템을 구현하는 해외 Internet Banking이 어떤 이유에서 IT 강국이라 외쳐대는 사람들 눈에는 보이지 않는지 안타깝습니다.

    인터넷 뱅킹이 먼저 풀어야할 문제이겠지만, 주식 거래 프로그램도 한심하기는 마찬가지인 것 같습니다. 하나씩 풀 수 있길 바랍니다. 힘내시길….

  • Freedom

    밑에 기사 아래부분을 보면
    XPCOM(Cross-Platform Component Object Model)이란 기술을 이용해서
    리눅스+파이어폭스에서 인터넷 뱅킹을 하는 스크린샷이 있는데
    이건 저희가 사용해 볼 수 없는 건가요? 테스트라도 해보고 싶은데…

    http://www.zdnet.co.kr/builder/platform/etc/0,39031670,39135644,00.htm

    제 생각은 XPCOM기술로 개발한다면 COM기반이기 때문에
    기존 ActiveX 개발자들도 XPCOM로 개발하는 것에 적응하기 쉬울것 같고
    또 파이어폭스는 다양한 플랫폼에서 사용가능 하기 때문에
    좋은 해결책이 될 것 같다라는 생각이 듭니다.

    물론 윈도우즈 사용자는 파이어폭스를 설치하여야 합니다만
    다른 다양한 플랫폼에서 동일한 사용이 가능하다는
    장점이 더 클것 같습니다.

    뭐 윈도우즈 사용자의 파이어폭스 설치가 부담이라면
    익스플로러에서 XPCOM이 사용가능하도록 애드온 프로그램을
    만들어도 될 것 같습니다.
    반대 상황의 경우는 익스플로러가 다양한 플랫폼 지원을 안하고
    리눅스에서 익스플로러를 사용할수있는 프로그램이 있기는 하지만
    라이센스문제등등이 있기 때문에…

  • T. K.

    제 생각도 그렇습니다. 물론 오픈웹의 정신을 최대한 살리는 방향으로 가야 하지만 정말정말 방법이 없다고 생각된다면 머릿수(?)만 많고 타 OS는 지원하지도 않는 IE 따위는 과감히 내던지고 다양한 OS를 지원하는 파이어폭스 위주로 사이트를 개편해야 한다는 거죠. IE로 접속한 유저에게는 경고 메시지 하나 띄워주고 파이어폭스를 다운로드하도록 유도해 주면 될 일입니다. 일종의 역차별이죠. 오픈 소스 브라우저이니 라이센스 문제도 없을 겁니다. 비록 오픈소스는 아니지만 사파리도 맥과 윈도를 동시에 지원하죠. IE는 절름발이 내지는 왕따 브라우저로 봐야 합니다. 차라리 그게 낫죠. MS에서는 난리부르스를 치겠지만 뭐 상관없습니다. 미국 웹사이트들 중에도 ‘이 페이지는 모질라 파이어폭스에서 가장 잘 보입니다.’는 문구가 있는 경우를 종종 볼 수 있죠.

  • T. K.

    추가…아직도 보안 때문에 ActiveX 컨트롤을 사용하지 않을 수 없다는 헛소리를 지껄이는 작자들이 있는데 이젠 그런 말 같지도 않은 소리 듣기도 지칩니다.

  • BKK

    T.K. 님 지치시는 것에 대해 100% 공감합니다. 그래도 님께는 그런 헛소리라도 해 주지, 제가 딴죽거는 것에 대해서는 대답도 않더군요..

  • T. K.

    http://korea.gnu.org/openweb/1/sterm.html

    그런데 이거 이 사이트에 있는 내용 아니던가요?

  • T. K.

    보안 어쩌구 헛소리하는 것보다 차라리 윗선에서 강요해서 어쩔 수 없다고 하는 편이 더 설득력이 있죠. 제발 무능한 떨거지들은 위에 링크한 글이나 읽어보고 나서 지껄여도 지껄였으면 좋겠습니다.

  • Freedom

    전 USB 키보드 쓰는데 아래 기사를 보면
    여태까지 효과도 없는 키보드 해킹 방지 프로그램 설치 한 듯 합니다.

    그리고 기사 댓글 중 아래 내용이 머리 속에 남는 군요.

    “근본적인 취약점을 벗어나는 방식으로 가야 할텐데 어찌 방패만 두껍게
    만들려고 하는지.”

    USB 키보드, 스니핑 프로그램에 속수무책
    http://www.inews24.com/php/news_view.php?g_serial=270312&g_menu=020200

    해답없는 USB 키보드 해킹, 관련업계 ‘속앓이’
    http://www.inews24.com/php/news_view.php?g_serial=276498&g_menu=020200

    USB 키보드 보안「답이 보인다」
    http://www.zdnet.co.kr/news/network/security/0,39031117,39162366,00.htm

  • Hyun

    위의 “USB 키보드, 스니핑 프로그램에 속수무책”에 보니깐…

    정통부 기반보호담당 이두원 사무관은 “키보드 입력을 해킹당하지 않기 위해서 USB 방식의 키보드 이용자는 ‘PS2(Personal System 2)’ 방식의 키보드로 전환해주는 젠더(Gender)를 이용하라”고 당부했다.

    역시나 정통부 다운 발상이네요…

  • T. K.

    헉, 정말 대~단하군요. 요즘 세상에 웬 PS2?

  • panickros

    T.K.님 // 사파리의 경우 윈도에서는 에뮬레이션 모드로 돌아간다고 보셔야 할 듯 합니다. 윈도에서 돌아가도록 한 이유는 다른 것이라기 보다는 웹사이트와 사파리와의 호환성 확보 측면에서 개발용으로(?) 제공된 것이나 다름 없다고 생각됩니다. 맥보다는 iPhone을 겨냥한 공개정책이지요. (iPhone에는 웹브라우저로 사파리가 탑재되어 있습니다)

    또한, 파폭에 맞춰서 개발하는 것도 엄밀한 의미에서 웹 표준에 위배됩니다. 웹 표준 테스트 중 하나인 acid 2 테스트 사이트에 가 보면 정확하게 표시되는 오페라에 비해 파폭에서는 내용이 깨집니다. (그나마 IE보단 낫습니다)

    웹 표준 ACID 2 테스트
    http://www.webstandards.org/files/acid2/test.html#top

    앞으로 휴대기기에 대부분 인터넷 브라우징이 지원될 것을 생각하면 웹 표준을 준수하는 것은 매우 중요한 일입니다. 특정 브라우저가 아무리 멀티 플랫폼으로 나온다고 해도, 그 브라우저만 지원해서는 일부 기기에서 문제가 생길 가능성을 전혀 배제할 수 없습니다. 그리고 그런 현상이 특정 기기나 메이커의 이익이나 손해에 큰 영향을 끼칠 수 있겠지요.

    근본적인 해결을 위해서는 웹 표준에 무게를 두어야지, 특정 브라우저에 끌려가서는 절대 안된다는 생각입니다.

  • T. K.

    panickros// 네 맞습니다. 저도 특정 브라우저 의존은 기본적으로 반대합니다. 우리나라에서 IE가 하도 판을 치니까 열 받아서 그냥 한번 해 본 넋두리 정도로 이해해 주세요.
    그런데 사파리가 윈도에선 에뮬레이션 모드처럼 돌아간다는 건 몰랐는데 좋은 거 배웠고요 사파리가 가장 먼저 ACID2 테스트를 통과한 것은 알고 있습니다. 그 다음이 오페라일 거고요 불여우도 차기 버전에서는 ACID2 테스트를 통과하도록 하겠다고 한 걸로 알고 있습니다. MS IE에서는 소위 유명한 ‘피바다’ 그림이 나올 정도로 참담한 결과를 보여주고 있고 MS도 그런 것에 신경 안쓴다고 떠들고 있지만 현재 개발중인 IE8에선 완전히 무시하지는 않을 걸로 보입니다. 말씀하신 대로 휴대기기 웹브라우징 등을 생각해서라도 표준으로 가야 한다는 데에는 전면 동의하고요…개인적으로 IE8은 MS도 사실상 손놓아 버린 ActiveX 컨트롤 미지원 등으로 과거 버전과 완전히 단절하고 윈도 백그라운드에서 자동 업데이트되도록 해야 한다는 생각입니다. 대한민국 웹은 한번 뒤집어지겠지만 그렇게 홍역 한번 치르고 나면 확실히 바뀌리라 봅니다.

  • panickros

    에뮬레이션은 좀 부정확한 표현인지도 모르겠네요.
    어쨌든 safari나 iTunes나 퀵타임같은 애플쪽의 어플리케이션류는 MS Windows의 시스템 라이브러리를 쓰는 것이 아니라 별도의 라이브러리를 통해서 동작한다고 하더군요. 그래서 크로스 플랫폼적인 설계가 아니라, 그 라이브러리에서 Mac OS X의 환경을 어느 정도 에뮬레이션 해 주는 것이 아닌가 하는 추측입니다. (전문가가 아니라 정확히는;;;)

    그래서 한글입력이 아에 안된다거나 하는 문제가 발생하기도 하지요. 단순히 문자코드나 폰트 문제라면 입력되는 시늉이라도 되야 할테고, OS X의 비교적 뛰어난 다국어 지원 성능을 생각하면 에뮬레이션에 가까운 형태라서 문제가 생기는 것이 아닐까 하는 게 제 생각입니다. (말이 복잡해서 죄송)

    하지만 뭐 사실 아쉬우면 파폭에서만이라도 제대로 되면 그것만 해도 감지덕지죠..

  • http://mytears.org/ 정태영

    apple 에서 나오는 윈도우용 프로그램들이 mac os x 를 에뮬레이션해주는 것은 아닙니다. 다만 자신들의 그래픽 api 인 quarts 와 멀티미디어 api 인 quicktime 를 윈도우에서도 사용할 수 있도록 구현한게 아닐까 싶네요. (물론 제한적으로 일부 기능만을 구현했겠지만요.)

    용어적인 문제지만 에뮬레이션이라고 하려면 OS X 의 바이너리를 가져다가 그대로 실행시키는 경우여야 합니다. 이런 식으로 일부 기능을 다른 플랫폼용으로 구현한 건 포팅이라고 얘기합니다.

    아 그리고 윈도우용 사파리 제공은 iPhone 등을 위한 개발환경 제공이라는 의견들도 분분하더군요. iPhone / iPod touch 등에서 사용되는 애플리케이션은 webkit + ajax 로 구현되어 있으니까요.

  • T. K.

    에뮬레이션이라 해서 혼동이 왔는데 감 잡았습니다.

  • Pingback: 오픈웹 관련해서 시끄러운 하루하루… | 내 맘대로 보는 세상