IT분야에 대해 올라오는 글 중에는 엑티브X를 성토하는 글들이 심심치 않게 올라오고 있습니다.
저 또한 엑티브X를 싫어합니다. 저는 엑티브X를 이렇게 비유하고 싶습니다.
운동선수가 금지된 약물을 복용하여 뛰어난 성적을 거뒀더라도 부작용은 언제나 그를 따라 다닐 것입니다. 그리고 운동선수의 건강을 해칠것이며, 그가 이룬 성과와 명예 역시 퇴색될 것 입니다.
액티브X도 마찬가지입니다. 오직 인터넷 익스플로러에서만 작동하고 고객의 PC환경을 지저분하게 만드는 기형적인 서비스 촉진 기술은 우리나라가 IT분야에 이룬 성과에 물을 흐리는 대표적인 골치 아픈 기술입니다.
이렇게 액티브X의 폐해를 예전에는 사용자/고객 관점에서 지적했지만 저는 액티브X가 왜 골치 아픈 기술인지, 액티브X 서비스를 어쩔 수 없이 제공해야 하는 '서비스 제공자/공급자' 입장에서 쓰려고 합니다.
공급자 입장에서도 액티브X는 최악의 기술 이었습니다.
+ 액티브X가 무엇인가? 그리고 액티브X가 우리나라에서 범람한 이유?
제가 정의한 액티브X는,
웹에서 제공하지 못하는 서비스를 마지못해 제공해야 했기에 쓰인 기술이 액티브X입니다. 웹에서 제공하지 못하는 서비스를 무리하게 제공하다 보니 인터넷 익스플로러에 의존하고 설치 방식이 번거롭고 지저분한 액티브X를 무리하게 사용하게 된 것입니다.
사실 무리하게 액티브X를 웹에 적용하게 된 출발점은 여기에 있다고 합니다.
기사를 보시면 아시겠지만 정부기관에서 웹이 제공하지 못하는 암호화 기술을 꼭 보완해야 했기에 당시 표준성 보다는 성능 향상을 위해 액티브X를 사용하게 되었습니다.
지금은 웹표준에 어긋나고 설치가 복잡한 액티브X이 문제점이 크게 부각되면서 정부도 문제점을 자각하고 웹표준을 지키는 기술을 쓰도록 유도하고 있습니다만,
당시 액티브X가 우리나라에서 많이 쓰이게 된 계기는 정부주도의 금융 보안 강화, 한마디로 금융 분야 때문에 많이 쓰이게 된 것입니다.
+ 액티브X 덕분에 금융 분야 서비스 개발자로 겪은 고초
여지껏 액티브X의 폐해를 성토하는 글은 대부분 사용자/고객 입장이었습니다. 그런데 액티브X는 사용자 뿐만 아니라 공급자 입장에서도 최악의 기술 이었습니다.
저는 금융분야 IT개발자로 액티브X 제품을 유지보수, 또는 액티브X 제품을 이용하여 개발을 진행한 경험으로 액티브X가 사용자 입장 뿐만 아니라 공급자 입장에서도 쓰면 안되는 이유를 알려드릴려고 합니다.
1. 액티브X 제품 유지보수시 문제점
저는 인터넷 뱅킹 사이트 유지보수를 담당했는데 특히 유지보수에 비용이 많이 드는 것을 많은 분들이 알고 계실 것 입니다.
유지보수를 하다 보면 고객 민원 전화가 자주 오는데 고객민원 전화의 대부분은 바로 ‘액티브X 보안모듈 설치 문제’입니다.
사용자들은 빠르고 간단하게 자신이 원하는 일을 마치고 싶어하는 무서운 고객님들 입니다. 이 분들이 액티브X 보안모듈 설치와 관련된 여러 해결법을 알기는 어렵습니다. 조금이라도 안되면 고객센터에 전화를 합니다.
일단 “인터넷 뱅킹이 안되요~” 라고 전화가 오면 대부분 보안모듈이 설치가 안되어 있는 문제입니다.
보시는 것처럼 인터넷 뱅킹 유지보수시 고객민원의 대부분은 액티브X 보안모듈 설치 문제 였는데, 그 경우가 눈감고도 쉽게 해결하는 것부터 해결하기 어려운 문제까지 '각 고객의 성격과 고객 PC의 특성'을 너무도 많이 타기 때문에 유지보수를 어렵게 만들었던 요소가 바로 액티브X입니다.
액티브X 제품이 유지보수 하기 어려운 이유는 한마디로, 기하급수적으로 늘어나는 고객PC의 수많은 장애 발생 경우의 수 때문 입니다.
[공급자 입장에서 웹표준 준수할 경우와 액티브X 사용시의 장애 발생 경우의 수를 보면 액티브X 공급자의 고초가 한눈에 보일 것이다. OS별, 브라우저버전별, 각 고객PC별로 장애 발생 경우의 수가 기하급수적으로 증가한다.]
그림에서 보시다 싶이 어쩔수 없이 액티브X 제품을 쓰게된 후 떠안게 되는 부담이 만만치 않습니다. 고객민원의 대부분을 액티브X 제품 관련 문제 해결로 보내고는 했습니다. 상당한 유지보수 비용의 낭비라고 볼 수 있습니다.
특히 고객 PC 특성을 타서 액티브X 제품이 설치가 안될 경우는 윈도우를 다시 설치하라고 할수도 없이 끙끙앓으며 문제 해결에 몇시간을 보내고는 했습니다.
회사 입장에서도 액티브X를 어쩔 수 없이 썼지만 부작용이 만만치 않기 때문에 유지보수 비용이 많이 늘어나게 되는 골치 아픈 기술 인 것입니다.
2. 액티브X 제품 이용 개발 진행시 문제점
작년 연말에 액티브X제품을 이용하여 웹 프로젝트 개발을 진행했습니다. 이때 저는 아이고~ 나 죽네~ 했었는데요. 그 이유중의 하나가 ‘두더지 게임’ 하듯이 여기 막으면 저기서 터지고, 저기 막으면 엉뚱한 곳에서 또 터지는 변화무쌍 다양한 액티브 엑스의 버그와 수많은 테스트 경우의 수 때문에 고생했기 때문입니다.
[개발자 입장에서 웹표준 준수할 경우와 액티브X 사용시의 기능 테스트 발생 경우의 수를 보면액티브X 개발자의 고초가 한눈에 보일 것이다. 역시 OS별, 브라우저버전별, 각 고객PC별로 테스트 경우의 수가 기하급수적으로 증가한다.]
예를들어 내 개발 PC인 XP에서 잘되면 윈도우 비스타에서 안되고, 내 PC의 XP에서 안되는 것은 다른 XP에서는 또 잘되고, 익스플로러 6에서 잘 되면 익스플로러 7에서는 안 되고, 기능 하나 추가할 때마다 이런 특성 타는 문제점들이 우리 개발자들을 괴롭혔으며,
액티브X 기능 추가시 다시 배포하고 테스트 하는 ‘빌드/배포’ 과정 역시 만만치 않게 번거로웠습니다.
한마디로 액티브X는 그림에서 언급한 수많은 상황의 특성을 골고루 타는 최악의 불안함을 보여주는 기술이기 때문에, 사용자/고객 뿐만 아니라 공급자/회사 도 힘들게 하는 대표적인 골치 아픈 기술 인 것입니다.
+ 그렇다면, 대책은 없는가.
그렇다면 대안 기술은 과연 존재할까요? 액티브X가 쓰이는 이유를 크게 2가지로 나눴습니다.
이 중 1.번 그래픽적인 측면은 과거 수준 높은 고객의 요구사항을 처리하기 위해 액티브X를 썼지만 최근에는 Ajax라는 비동기 기반 자바스크립트가 대부분 처리 할 수가 있다고 합니다. 요즘에는 워드나 엑셀 같은 고급UI를 필요로 하는 애플리케이션도 액티브X를 전혀 안쓰고 Ajax를 이용하여 개발할 수 있다고 하며, 구글이 Ajax를 이용하여 웹표준을 지키는 많은 서비스를 출시하고 있습니다.
그러나 문제는 2. 번입니다. Ajax도 UI측면에서만 액티브X를 대체할 수 있고, 보안 등의 시스템 내부에서 돌아가는 핵심 기술은 대체하기 어렵다고 합니다.
2.번과 관련된 액티브X 대체 기술은 자바 애플릿, 플래시, XPCOM등의 다양한 기술들이 출연하고 있지만 각각 장단점이 뚜렷하여 액티브X를 대체할 확실한 기술은 아직 부각되지 않은 것 같습니다.
저는 웹표준을 무시하고 사용자와 공급자를 괴롭히는 액티브X는 사장되어야 된다고 생각하지만, 이런 단점을 알고도 어쩔수 없이 쓰여야 되는 경우도 아직은 있다고 생각합니다.
그러나 UI(사용자 인터페이스) 같이 액티브X를 대체할 수 있는 기술이 존재한다면 최대한 대체 기술을 활용하여 웹표준을 준수하고 사용자를 편하게 하고 공급자 자신도 개발 비용과 유지보수 비용을 절약해야 겠습니다.
표준이 기술력입니다. 공급자 입장에서도 액티브X는 사라져야 합니다.
저 또한 엑티브X를 싫어합니다. 저는 엑티브X를 이렇게 비유하고 싶습니다.
“운동선수가 금지된 약물을 복용하여 뛰어난 성적을 거두는 상황과 비슷하다. 액티브X 서비스는 금지된 약물 촉진제를 복용한 것이다.”
운동선수가 금지된 약물을 복용하여 뛰어난 성적을 거뒀더라도 부작용은 언제나 그를 따라 다닐 것입니다. 그리고 운동선수의 건강을 해칠것이며, 그가 이룬 성과와 명예 역시 퇴색될 것 입니다.
액티브X도 마찬가지입니다. 오직 인터넷 익스플로러에서만 작동하고 고객의 PC환경을 지저분하게 만드는 기형적인 서비스 촉진 기술은 우리나라가 IT분야에 이룬 성과에 물을 흐리는 대표적인 골치 아픈 기술입니다.
이렇게 액티브X의 폐해를 예전에는 사용자/고객 관점에서 지적했지만 저는 액티브X가 왜 골치 아픈 기술인지, 액티브X 서비스를 어쩔 수 없이 제공해야 하는 '서비스 제공자/공급자' 입장에서 쓰려고 합니다.
공급자 입장에서도 액티브X는 최악의 기술 이었습니다.
+ 액티브X가 무엇인가? 그리고 액티브X가 우리나라에서 범람한 이유?
제가 정의한 액티브X는,
웹에서 지원하지 못하는 서비스의 한계를 극복하고, 고객PC의 자원을 활용하여 고품질의 서비스를 제공하기 위해 활용하는 MS기반 인터넷 익스플로러에서만 작동하는 서비스 확장 기술이다.
웹에서 제공하지 못하는 서비스를 마지못해 제공해야 했기에 쓰인 기술이 액티브X입니다. 웹에서 제공하지 못하는 서비스를 무리하게 제공하다 보니 인터넷 익스플로러에 의존하고 설치 방식이 번거롭고 지저분한 액티브X를 무리하게 사용하게 된 것입니다.
사실 무리하게 액티브X를 웹에 적용하게 된 출발점은 여기에 있다고 합니다.
"바야흐르 전자상거래의 본격적인 태동이 시작되었다. 전자상거래를 이용하여 금융거래를 안전하게 할 수 있으려면 강력한 보안이
필수적이었다. 하지만 그 당시의 브라우저는 요즘처럼 강력한 128bit 암호화 기능을 자체적으로 제공하고 있지 않았다.
결국 보안 기술을 따로 만들어야 했지만, 미국은 선뜻 128bit 암호화 기술을 내주지 않았다. 보안상의 이유로 128bit 암호화 기술은 수출 금지 품목이었기 때문이다. 이에 정통부 산하 기관인 KISA(한국정보보호진흥원)에서는 시드(Seed)라는 128bit 대칭키 블록 암호화 알고리즘을 개발하였고 이를 브라우저에 탑재하기 위하여 액티브X 컨트롤을 사용였다. 이는 곧 국내 표준이 되었고, 결국 액티브X 확산에 단단히 한 몫을 하게 되었다.” - 마이크로소프트 2007년 6월호 기사 발췌
결국 보안 기술을 따로 만들어야 했지만, 미국은 선뜻 128bit 암호화 기술을 내주지 않았다. 보안상의 이유로 128bit 암호화 기술은 수출 금지 품목이었기 때문이다. 이에 정통부 산하 기관인 KISA(한국정보보호진흥원)에서는 시드(Seed)라는 128bit 대칭키 블록 암호화 알고리즘을 개발하였고 이를 브라우저에 탑재하기 위하여 액티브X 컨트롤을 사용였다. 이는 곧 국내 표준이 되었고, 결국 액티브X 확산에 단단히 한 몫을 하게 되었다.” - 마이크로소프트 2007년 6월호 기사 발췌
기사를 보시면 아시겠지만 정부기관에서 웹이 제공하지 못하는 암호화 기술을 꼭 보완해야 했기에 당시 표준성 보다는 성능 향상을 위해 액티브X를 사용하게 되었습니다.
지금은 웹표준에 어긋나고 설치가 복잡한 액티브X이 문제점이 크게 부각되면서 정부도 문제점을 자각하고 웹표준을 지키는 기술을 쓰도록 유도하고 있습니다만,
당시 액티브X가 우리나라에서 많이 쓰이게 된 계기는 정부주도의 금융 보안 강화, 한마디로 금융 분야 때문에 많이 쓰이게 된 것입니다.
+ 액티브X 덕분에 금융 분야 서비스 개발자로 겪은 고초
여지껏 액티브X의 폐해를 성토하는 글은 대부분 사용자/고객 입장이었습니다. 그런데 액티브X는 사용자 뿐만 아니라 공급자 입장에서도 최악의 기술 이었습니다.
저는 금융분야 IT개발자로 액티브X 제품을 유지보수, 또는 액티브X 제품을 이용하여 개발을 진행한 경험으로 액티브X가 사용자 입장 뿐만 아니라 공급자 입장에서도 쓰면 안되는 이유를 알려드릴려고 합니다.
1. 액티브X 제품 유지보수시 문제점
저는 인터넷 뱅킹 사이트 유지보수를 담당했는데 특히 유지보수에 비용이 많이 드는 것을 많은 분들이 알고 계실 것 입니다.
유지보수를 하다 보면 고객 민원 전화가 자주 오는데 고객민원 전화의 대부분은 바로 ‘액티브X 보안모듈 설치 문제’입니다.
사용자들은 빠르고 간단하게 자신이 원하는 일을 마치고 싶어하는 무서운 고객님들 입니다. 이 분들이 액티브X 보안모듈 설치와 관련된 여러 해결법을 알기는 어렵습니다. 조금이라도 안되면 고객센터에 전화를 합니다.
일단 “인터넷 뱅킹이 안되요~” 라고 전화가 오면 대부분 보안모듈이 설치가 안되어 있는 문제입니다.
예1) XP에서 익스플로러 위의 노란 보안경고창도 인식 못하는 컴퓨터 초보 사용자
-> 금방 해결은 하지만 다소 아쉬운 자원 낭비성 문제이다.
예2) 보안모듈이 엉킬 때, 이때 보안모듈을 삭제 후 다시 설치하면 되지만 대부분의 사용자가 알리가 없다.
예3) 보안모듈이 다른 윈도우 프로그램과 충돌날 때, 고객PC 특성을 타는 이런 경우 점점 해결이 어려워 진다.
-> 금방 해결은 하지만 다소 아쉬운 자원 낭비성 문제이다.
예2) 보안모듈이 엉킬 때, 이때 보안모듈을 삭제 후 다시 설치하면 되지만 대부분의 사용자가 알리가 없다.
예3) 보안모듈이 다른 윈도우 프로그램과 충돌날 때, 고객PC 특성을 타는 이런 경우 점점 해결이 어려워 진다.
보시는 것처럼 인터넷 뱅킹 유지보수시 고객민원의 대부분은 액티브X 보안모듈 설치 문제 였는데, 그 경우가 눈감고도 쉽게 해결하는 것부터 해결하기 어려운 문제까지 '각 고객의 성격과 고객 PC의 특성'을 너무도 많이 타기 때문에 유지보수를 어렵게 만들었던 요소가 바로 액티브X입니다.
액티브X 제품이 유지보수 하기 어려운 이유는 한마디로, 기하급수적으로 늘어나는 고객PC의 수많은 장애 발생 경우의 수 때문 입니다.
그림에서 보시다 싶이 어쩔수 없이 액티브X 제품을 쓰게된 후 떠안게 되는 부담이 만만치 않습니다. 고객민원의 대부분을 액티브X 제품 관련 문제 해결로 보내고는 했습니다. 상당한 유지보수 비용의 낭비라고 볼 수 있습니다.
특히 고객 PC 특성을 타서 액티브X 제품이 설치가 안될 경우는 윈도우를 다시 설치하라고 할수도 없이 끙끙앓으며 문제 해결에 몇시간을 보내고는 했습니다.
회사 입장에서도 액티브X를 어쩔 수 없이 썼지만 부작용이 만만치 않기 때문에 유지보수 비용이 많이 늘어나게 되는 골치 아픈 기술 인 것입니다.
2. 액티브X 제품 이용 개발 진행시 문제점
작년 연말에 액티브X제품을 이용하여 웹 프로젝트 개발을 진행했습니다. 이때 저는 아이고~ 나 죽네~ 했었는데요. 그 이유중의 하나가 ‘두더지 게임’ 하듯이 여기 막으면 저기서 터지고, 저기 막으면 엉뚱한 곳에서 또 터지는 변화무쌍 다양한 액티브 엑스의 버그와 수많은 테스트 경우의 수 때문에 고생했기 때문입니다.
예를들어 내 개발 PC인 XP에서 잘되면 윈도우 비스타에서 안되고, 내 PC의 XP에서 안되는 것은 다른 XP에서는 또 잘되고, 익스플로러 6에서 잘 되면 익스플로러 7에서는 안 되고, 기능 하나 추가할 때마다 이런 특성 타는 문제점들이 우리 개발자들을 괴롭혔으며,
액티브X 기능 추가시 다시 배포하고 테스트 하는 ‘빌드/배포’ 과정 역시 만만치 않게 번거로웠습니다.
한마디로 액티브X는 그림에서 언급한 수많은 상황의 특성을 골고루 타는 최악의 불안함을 보여주는 기술이기 때문에, 사용자/고객 뿐만 아니라 공급자/회사 도 힘들게 하는 대표적인 골치 아픈 기술 인 것입니다.
+ 그렇다면, 대책은 없는가.
그렇다면 대안 기술은 과연 존재할까요? 액티브X가 쓰이는 이유를 크게 2가지로 나눴습니다.
1. 웹이 하지 못하는 고급 UI(사용자 인터페이스) 개발
2. 클라이언트 자원을 활용, 웹이 하지 못하는 보안등의 핵심 엔진을 탑재하여 서비스의 성능 확장
2. 클라이언트 자원을 활용, 웹이 하지 못하는 보안등의 핵심 엔진을 탑재하여 서비스의 성능 확장
이 중 1.번 그래픽적인 측면은 과거 수준 높은 고객의 요구사항을 처리하기 위해 액티브X를 썼지만 최근에는 Ajax라는 비동기 기반 자바스크립트가 대부분 처리 할 수가 있다고 합니다. 요즘에는 워드나 엑셀 같은 고급UI를 필요로 하는 애플리케이션도 액티브X를 전혀 안쓰고 Ajax를 이용하여 개발할 수 있다고 하며, 구글이 Ajax를 이용하여 웹표준을 지키는 많은 서비스를 출시하고 있습니다.
그러나 문제는 2. 번입니다. Ajax도 UI측면에서만 액티브X를 대체할 수 있고, 보안 등의 시스템 내부에서 돌아가는 핵심 기술은 대체하기 어렵다고 합니다.
2.번과 관련된 액티브X 대체 기술은 자바 애플릿, 플래시, XPCOM등의 다양한 기술들이 출연하고 있지만 각각 장단점이 뚜렷하여 액티브X를 대체할 확실한 기술은 아직 부각되지 않은 것 같습니다.
저는 웹표준을 무시하고 사용자와 공급자를 괴롭히는 액티브X는 사장되어야 된다고 생각하지만, 이런 단점을 알고도 어쩔수 없이 쓰여야 되는 경우도 아직은 있다고 생각합니다.
그러나 UI(사용자 인터페이스) 같이 액티브X를 대체할 수 있는 기술이 존재한다면 최대한 대체 기술을 활용하여 웹표준을 준수하고 사용자를 편하게 하고 공급자 자신도 개발 비용과 유지보수 비용을 절약해야 겠습니다.
표준이 기술력입니다. 공급자 입장에서도 액티브X는 사라져야 합니다.
올블로그 추천은 http://link.allblog.net/7966003/http://mckdh.net/202 입니다.
