ActiveX 방식과 그 대안 방식인 EXE 방식의 문제점에 대한 고찰
현 정부가 들어서기 전에 문재인 대통령이 후보 시절에 대선 공약으로 공공웹서비스에서 공인인증서와 ActiveX를 없애는 방향으로 나가겠다는 내용을 발표했던 적이 있다. 물론 어떻게 없애겠다는 구체적인 내용은 나오지 않았지만 그 공약만으로 많은 사람들이 만세를 외친 것 같았다(뭐 내 주변에서도 그러니). 그리고 최근에 공공웹사이트에서 ActiveX의 대체 기술로 EXE 방식을 일단은 이용하겠다는 뉴스가 나왔다.
ActiveX란?
일단 공인인증서와 ActiveX를 동일하게 생각하는 잘못된 생각은 버리고.. ActiveX에 대해서 먼저 알아야 할 부분이 ActiveX는 웹브라우저를 플랫폼으로 구동하는 어플리케이션이라고 보면 된다. 원래는 ActiveX는 인터넷 익스플로러(IE)라는 MS에서 윈도 OS 기반으로 운영되는 웹브라우저의 플러그인이지만 일반적인 웹브라우저 플러그인이라고 하기에는 실행 권한이나 범위 등이 크롬이나 파이어폭스, 사파리 등의 타 웹브라우저에서 제공하는 플러그인보다는 좀 크기 때문에 문제가 되는 부분이 있다.
일반적인 웹브라우저 플러그인은 웹브라우저 안에서만 동작을 하고 웹브라우저 밖에서는 동작을 하지 않는 방식이다. 즉, 웹브라우저라는 플랫폼 안에서만 동작을 하기 때문에 웹브라우저가 건드릴 수 없는 영역은 웹브라우저의 플러그인 역시 건드릴 수 없다. 하지만 ActiveX는 IE 안에서 구동되기는 하지만 실행 자체가 OS에서 실행되는 실행파일 형식으로 되어있기 때문에(보이는 것 자체가 웹브라우저에서 구동되는 것처럼 보이는 것일 뿐) 웹브라우저가 건드릴 수 없는 영역도 웹브라우저 플러그인인 ActiveX는 건드릴 수 있는 상황이 벌어진다. 그래서 좀 더 심각한 문제를 일으킬 수 있는 것이다.
왜 ActiveX가 문제가 되나?
뭐 ActiveX에 대해서는 이렇게만 얘기하고.. 그렇다면 공공웹서비스에서 ActiveX를 사용하는 것이 왜 문제가 되는가를 좀 살펴보도록 하자. 가장 큰 이유는 ActiveX가 IE에서만 동작하는 방식이기 때문에 웹브라우저를 강제한다는 점이다. 이 세상에는 IE만 존재하는 것이 아닌 이제는 가장 많이 사용하는 웹브라우저가 된 구글의 크롬도 있고 탈 IE의 시작이 되었던 모질라 재단의 파이어폭스도 존재한다. 애플의 사파리라는 웹브라우저도 존재하고 네이버에서 내놓은 웨일이라는 웹브라우저도 있다. 이스트소프트에서 나온 스윙이라는 녀석도 존재한다. 이렇게 다양한 웹브라우저가 있는데도 불구하고 공공웹서비스에서 자기네들의 기능을 제공하기 위해 ActiveX로 기능을 구현해놓은 까닭에 IE만 사용해야 한다는 웹브라우저 강제성이 문제가 된다.
또 하나의 이유는 OS의 문제다. IE는 MS의 윈도 OS에서만 동작하는 웹브라우저다. 하지만 웹브라우저처럼 세상에는 MS의 윈도 OS만 있는 것이 아니다. 윈도 OS는 유료 OS이기 때문에 MS가 싫은 사람들은 우분투(Ubuntu)나 CentOS 등과 같은 리눅스 OS를 사용하는 경우도 있다. 그리고 애플이 만든 맥북이나 맥북프로, 아이맥 등의 맥 계열에서는 macOS라는 맥 전용 OS를 사용한다. 그 외에 구글 크롬 OS를 쓰는 경우도 존재한다. 여하튼 윈도 OS 외에 다양한 OS가 존재함에도 불구하고 ActiveX를 사용했기 때문에 IE를 써야하며 IE가 구동되는 것은 윈도 OS 밖에 없기 때문에 윈도 OS를 설치해서 써야 한다.
웹서비스는 그 방향성이 웹브라우저와 OS에 대해서 독립적이어야 하는데 한국의 공공웹서비스나 인터넷뱅킹 서비스, 결제를 필요로 하는 쇼핑몰 등에서는 ActiveX를 이용하여 필요한 기능을 구현했기 때문에 IE와 윈도 OS 만을 사용해야 한다는 점이다. 웹브라우저와 OS에 의존성이 너무 강하고 웹 호환성이 없다는 것이 가장 큰 문제가 되었다. 이런 문제로 인해 중국에서 한때 유행했던 드라마에서 나왔던 천송이 코트를 중국에서는 못사는 상황이 벌어져서 이른바 천송이 코트 사태가 벌어지기도 했고 말이지.
공공웹서비스에서는 왜 ActiveX를 사용했나?
그렇다면 공공웹서비스나 인터넷 뱅킹 서비스 등에서 ActiveX를 어떻게 사용할까? 가장 많이 사용하는 기능은 공인인증서 적용 기능이다. 솔직히 이 기능으로 인해 'ActiveX = 공인인증서'라는 말도 안되는 등식이 세워지기도 했다(하지만 앞서 얘기했듯 ActiveX = 공인인증서라는 생각은 잘못된 생각이다). 국내에서 사용하는 공인인증서는 일반 서버 인증서가 사용하는 형식(X.509)을 그대로 사용했다. 암호화도 표준 암호화 방식을 그대로 따른다.
그럼에도 불구하고 ActiveX라는 플러그인을 써야만 했던 이유는 인증서 저장 위치가 웹브라우저가 제공하는 인증서 저장소가 아닌 별도의 저장소를 사용하기 때문이다. 웹브라우저에서는 공인인증서의 저장소를 인식 못하기 때문에 플러그인을 써서 강제로 인식시키도록 해야만 했던 것이다. 그렇다면 웹브라우저가 제공하는 저장소에 저장하면 될 일을 왜 별도의 저장소에 저장하도록 했을까? 그건 좀 더 살펴봐야 할 부분이지만 개인적으로 생각했던 부분은(이 내용은 엄밀히 따지면 공인인증서 개발에 참여했던 지인이 썰 식으로 풀어서 얘기했던 내용인지라 100% 맞다고 확신할 수 없다) 공인인증서가 만들어진 시기에는 인증서 저장을 위해서는 세계적인 공인인증기관에서 인증서에 대한 공증을 받아야 했는데 그 시기에는 그것을 받지 못했으며 지금에 와서는 과거에 이어왔던 형식을 하위 호환성이라는 이름으로 유지하기 위해서 그대로 진행을 했기 때문에 웹브라우저의 인증서 보관함에 저장하지 못하고 계속 GPKI, NPKI 폴더를 만들어서 쓰고 있다는 것이다.
그리고 공인인증서 적용과 함께 인증서 내부의 암호화 키를 이용하여 패킷을 암복호화 하는 기능도 ActiveX를 통해서 진행한다. 참고로 공인인증서 적용 및 암호화는 우리가 보통 HTTPS라고 불리는 암호화 통신의 방식과 동일하다. SSL(보안 통신 레이어) 방식을 ActiveX를 통해 구현한 것이라고 보면 된다. 인증서의 인증기관이라 불리는 CA도 일반 서버 인증서는 베리사인이나 코모도 등과 같은 이른바 알려진 루트 인증기관을 통하는데 공인인증서는 KISA에서 인증을 한다는 것이 다를 뿐이다(그래서 KISA를 루트 인증기관으로 승격시켜달라고, 아니면 KISA를 다른 웹브라우저에서도 인증기관으로 인정할 수 있게 등록해달라고 정부에서 웹브라우저 개발사에 요청했다는 루머도 돌고 있는 것이 사실이다).
그 다음에 많이 사용하는 기능이 키보드 보안이다. 공인인증서나 결제 시 보안키, 암호 등을 입력할 때 암호화 통신을 통해 서버에 전송되지만 웹브라우저에서 입력될 때에는 어떤 보안도 진행되지 않았던 것이 사실이다. 그래서 키보드로 암호나 보안키를 입력할 때 보안이 되도록, 즉 키보드에서 입력된 내용이 웹브라우저의 보안 키 입력 부분에 전달될 때 그대로 전달되는 것이 아니라 암호화되어 전달되도록 하는 것이 키보드 보안이다. 여기에 물리적 키보드가 아닌 가상 키보드를 띄워서 입력하도록 하는 방식도 키보드 보안의 일종으로 함께 제공되기도 한다.
여기에 화면 캡쳐를 방지하는 기능 역시 ActiveX를 이용해서 구현하여 보안이라는 명목으로 제공하기도 한다. 그 외에도 프린터 제어 등에도 ActiveX를 사용하기도 하고 문서를 출력하는데 있어서 미려한 출력을 하기 위해 ActiveX로 구현하기도 한다. 여하튼 수많은 보안 모듈 및 그 외에 다양한 기능을 위해 ActiveX를 사용한다.
사람들은 왜 ActiveX를 없애라고 하는가?
그렇다면 ActiveX를 왜 없애려고 하는가? 앞서 얘기했던 웹브라우저 및 OS에 독립적인 웹표준 문제는 둘째로 치더라도 가장 큰 문제는 웹서비스를 이용하기 위해서 설치해야 하는 플러그인이 정말 많다는 것이다. 간단한 예로 민원24에만 들어가면 잘 알 것이다. 설치해야 할 ActiveX가 어마어마하게 많다. 다운로드 받아서 설치해야 하고 또 설치하면 다시 웹브라우저를 재시작 하거나 웹서비스 화면을 재시작해야 하는 경우도 생긴다. 그렇다면 그 화면에 또 다시 이동해야 하는 불편이 생긴다. ActiveX를 10개를 설치하는데 1개만 깔아도 다시 재시작을 해야 하는 상황도 벌어지다보니 웹서비스 이용은 고사하고 ActiveX 설치만 하다가 성질 다 버리는 상황이 연출되곤 한다. 그리고 기껏 다 설치를 해도 어떤 경우에는 제대로 실행이 안되는 경우가 수두룩 하다. 즉, 불편하다는 것이 가장 큰 이유일 것이다.
또 하나의 이유는 귀찮음으로 인해 보안적으로 놓치는 상황이 벌어진다는 것이다. 쉽게 말하자면 웹서비스에서 제공하는 ActiveX를 다 설치를 해야 온전히 해당 웹서비스를 이용할 수 있다보니 사람들은 ActiveX를 설치할 때 그 안의 내용은 안보고 기계적으로 무조건 설치를 누르는 경우가 많다. 그러다보니 정작 필요없는 기능임에도 불구하고 그냥 설치하는 경우도 많고 만약 해당 웹서비스가 해킹을 당해서 웹서비스에서 제공하는 ActiveX가 악성코드인 경우도 있을텐데 그것을 살펴보지도 않고 그냥 다 설치를 기계적으로 눌러서 진행하는 경우에는 그냥 해커가 원하는대로 악성코드에 감염되는 상황이 벌어지곤 한다. 이 ActiveX로 만든 악성코드가 문제가 되는 것은 앞서 언급했던 것처럼 ActiveX는 다른 웹브라우저의 플러그인과 달리 OS 영역을 건드리기 때문에 문제가 될 가능성이 크다. 뭐 요즘은 자바스크립트로 된 악성코드도 비슷한 동작을 하니 ActiveX 문제라고만 보기도 어려운 상황이기는 하다.
즉, 불편함과 보안적으로 위험함, 그리고 웹브라우저 및 OS의 호환성을 고려하지 않은 선택적 강요로 인해 ActiveX는 이제 퇴출 1순위의 웹기술이 되어버린 현실이다. 그런데 문제는 ActiveX를 버린다고는 하지만 대안이 현재로서는 마땅치 않다는 점이다. 위에 문제가 된 기사를 보면 ActiveX의 대안 방식으로 EXE 방식을 제시한 것을 볼 수 있는데 이것 역시 무척이나 위험하다.
ActiveX 방식의 대안점으로 나온 EXE 방식의 문제점
EXE 방식은 웹브라우저의 플러그인 방식이 아닌 윈도 OS에서 실행파일 방식으로 어플리케이션을 실행하는 방식을 얘기한다. 즉, ActiveX가 IE에서 실행이 되는 것에 비해 EXE 방식은 윈도 OS에서 실행이 되는 것이다. 플랫폼이 웹브라우저에서 OS로 변경이 된 것이다. 물론 웹브라우저와 통신을 함으로 데이터는 웹브라우저의 플러그인에서 동작되는 것처럼 주고 받을 수 있다. EXE 방식의 장점은 윈도 OS에서 실행되는 것이기 때문에 IE에서 뿐만이 아니라 크롬이나 파이어폭스 등에서도 실행이 가능하다는 점이다. 이들 웹브라우저는 외부의 어플리케이션을 실행할 수 있는 명령어를 제공해주기 때문에 가능하다. 즉, 웹브라우저의 호환성 문제는 해결이 가능하다. 하지만 여전히 윈도 OS에서만 동작이 된다는 OS 호환성은 해결하지 못하고 있다.
게다가 EXE 방식 역시 ActiveX처럼 설치를 해야 한다. 당연한 것이다. EXE는 실행파일이기 때문에 윈도 OS에 설치를 해야 사용할 수 있다. ActiveX로 제공되던 기능을 EXE 형식의 설치 파일로 변경한 것에 지나지 않는다. 민원24에서 신나게 ActiveX를 설치했던 것처럼 EXE 방식으로 변환한다고 해도 신나게 EXE 파일이 들어있는 설치파일을 실행시켜서 윈도 OS에 설치를 해야 한다. 여러 ActiveX에서 제공했던 기능을 하나의 설치파일로 만들어서 설치하면 좀 설치가 쉬워질 수도 있겠지만 어찌되었던 별도의 설치 과정이 필요한 것은 어쩔 수 없다. 이 역시 ActiveX를 설치해서 실행하는 것 못잖게 귀찮음을 동반한다.
그리고 무엇보다도 ActiveX 방식보다 EXE가 더 위험할 수 있는 것이 ActiveX는 일단 IE에서 구동을 해야만 동작하는 방식이다. 내부적으로는 OS에서 실행되는 방식처럼 되어있지만 어찌되었던 시작점은 IE다. 하지만 EXE 방식은 OS의 실행파일이기 때문에 IE가 아니더라도 실행이 가능하다. 물론 실행할 때 자기와 통신을 해야 하는 웹브라우저의 존재를 확인하고 없으면 실행을 못하게 하는 방어장치 정도는 있겠지만 어찌되었던 실행 자체가 가능한 것이 EXE 형식이다. 그렇다면 문제가 되는 것이 요즘 한참 유행하고 있는 랜섬웨어를 비롯하여 다양한 악성코드가 동작하는데 있어서 기존 ActiveX 방식보다 더 문제가 될 수 있는 방식이 EXE 형식이라고 해도 과언은 아닐 것이다. EXE 형식은 OS에서 동작하는 실행파일이며 권한에 따라서 사용자가 사용하고 있는 PC의 전체를 관장할 수 있기 때문에 문제를 일으킬 소지도 크고 그 범위도 그 넓다. 문제가 되는 상황에서 EXE 방식은 '그냥 악성코드를 실행시켜 주시기 바랍니다'라는 말처럼 들릴 수 있기 때문이다.
즉, ActiveX가 EXE 방식으로 바뀌는 것은 IE에서만 동작되던 ActiveX를 윈도 OS 자체에서 동작할 수 있는 EXE로 바꾸고 IE 뿐만이 아니라 외부의 어플리케이션 실행 및 통신을 제공해주는 웹브라우저에서는 모두 사용할 수 있게 만든다는데 그 의미가 있다. 웹브라우저 호환성은 분명 해결이 되는 것이다. 하지만 OS 호환성은 여전히 해결이 안되며 앞서 언급했던 것처럼 설치라는 귀찮은 작업이 여전히 동반되고 무엇보다도 플러그인 수준이 아닌 OS 위에서의 실행파일 수준으로 권한이 상승함으로 인해 악용될 소지도 더 커졌고 그 위험도와 범위 역시 무시할 수 없게 커졌다는데 그 문제점이 있다고 본다. 관련 업계에 있었던 입장에서 볼 때에는 눈가리고 아웅하는 수준밖에 안된다는 것이다.
ActiveX를 버리지 못하는 속사정?
물론 애로사항이 있다. 공공기관이나 ActiveX로 기능을 만들어 서비스를 해왔던 기업의 입장 역시 생각을 해봐야 하는 것이 당장에 확 바꿀 수 있는 것이 아니다. ActiveX라는 기술 자체가 문제가 아니라 서비스를 이용하기 위해서 기본적으로 제공되어야 할 기능 등에 대해 정책적으로, 혹은 법률적으로 제한을 둔 것이 많다. 공인인증서 역시 그런 부분이고 키보드 보안이나 암호화 통신도 그런 맥락에서 보면 버릴 수 없는, 바꿀 수 없는 상황이라는 것이다. 현 정부의 공약사항 중 하나인 ActiveX, 그리고 공인인증서를 없애기 위해서는 먼저 제도와 법률을 변경해야 하며 변경된 제도와 법률에 따라 시스템을 다시 구축하고 검증하는 기간이 필요하다. 오늘 당장에 시작한다고 하더라도 현 정부가 끝날 때까지 다 못끝낼 수 있는 작업일 가능성도 크다.
다른 대안은 없나?
차라리 이 블로그에서 내가 예전에 얘기했던 것처럼 전용 프로그램을 이용하는 방식으로 변경하면 어떨까 하는 생각도 해봤다. 웹서비스가 아닌 전용 어플리케이션을 이용한 서비스 제공도 나쁜 선택은 아니다. 물론 개발하는 입장에서는 OS별로 다 만들어야 한다는 불편함이 있겠지만 말이다. 하지만 웹브라우저에 덕지덕지 ActiveX든 아니면 EXE 형식이든 붙여서 실행시키는 것보다는 훨씬 더 안정적일 수 있을지도 모른다. 아니면 해외처럼 서버 보안을 강화하고 사전 보안 뿐만이 아니라 사후 검증 및 추적을 통해 처벌을 강화하는 방식을 고민해야 한다. 이 방식은 앞서 언급했던 것처럼 정책 및 법률의 개정이 필요하며 그 내용에 따라 시스템을 다시 구축하고 검증해야 하는 비용적 시간적 투자가 필요하다. 어떤 의미에서 사람들은 후자의 방식을 원하겠지만 기업이나 정부 입장에서는 후자는 자기네들 기준으로 봤을 때 오히려 위험 부담이 더 크다고 생각할 수 있다. 돈은 벌어야 하는데 돈을 더 들이기는 싫다는 얘기다.
어찌되었던 ActiveX가 사라지는 것은 맞는데 현재로서는 그 대체 방안으로 EXE 방식이 추진되고 있고 또 많이 넘어온 상황이다. 하지만 이 역시 해결방안이 아니라는 점, 그리고 ActiveX보다 더 위험요소가 많다는 점을 생각을 해야 할 듯 싶다.
PS) 글을 마무리하면서 드는 생각은 처음부터 웹표준 등을 따른 방식으로 국내 웹서비스를 만들었다면 어땠을까 하는 것이었다. 앞서 언급했듯 2000년대 초반의 웹브라우저는 지금의 다양한 기능을 제공하지 못했기 때문에 제한적이었고 결국에는 웹표준이 아닌 국내만의 표준 방식으로 갔을 듯 싶다. 아니면 그 당시의 기술 수준에 맞게 웹서비스가 만들어졌을테고 지금처럼의 웹서비스가 나오기까지는 지금보다 상당한 시일이 더 걸리지 않았을까 하는 생각도 든다. 물론 기술이 급속도로 발전했는데 우리의 웹서비스는 그 발전 속도에 못쫓아간 것이 문제가 된다. 그런데 이것은 공공기관 자체의 문제나 은행 등의 서비스 제공 기업 자체의 문제도 있었지만 여러가지 상황 등을 고려했을 때 결코 쉬운 결정을 내릴 수 없는 상황이었기에 결과론적으로는 문제가 되었지만 어쩔 수 없는 문제라는 생각도 든다.