플러그인 지원을 중단하기 시작한 웹브라우저들, 플러그인 중심의 웹서비스 시대에서 웹표준 중심의 웹서비스 시대로 가고 있는데..

며칠 전 블로그를 통해서 MS과 구글이 윈도 10의 엣지 브라우저와 크롬 브라우저의 최신 버전에서 ActiveX와 NPAPI를 지원하지 않겠다고 발표한 후 국내의 금융권 관계자들이 무척이나 난감해하고 있다는 내용을 쓴 적이 있다. 이유는 국내 금융권에서 사용하고 있는 보안 어플리케이션들과 그 외의 시스템들이 웹브라우저 상에서 ActiveX와 NPAPI를 이용해서 만든 플러그인으로 동작되기 때문이다. 세계적으로 웹표준을 향해 웹서비스들이 변모하고 있으며 HTML5로 거의 통일되다시피 하고 있는 상황에서 플래시도 퇴출되는 마당에 보안적인 부분에 문제가 있다고 알려진 ActiveX와 NPAPI를 국내 기업이 아닌 글로벌 기업인 MS와 구글이 지원할 필요는 없다고 판단한 듯 싶고 그 판단에 대해서 이래저래 왈가왈부할 수 있는 상황도 아니다.

앞서 얘기했듯 플래시도 퇴출 수순을 밟고 있고 ActiveX와 NPAPI도 퇴출 수순을 밟고 있는 중이다. 즉, 플러그인 시대는 저물어가고 있다는 얘기다. 모든 것을 웹표준에 맞춰서 HTML로만 구현해야 하는 시대가 왔다. 웹브라우저에서 따로 설치하는 뭔가가 없이 웹서비스가 동작한다면 PC 뿐만이 아니라 이제는 서비스의 표준이 되고 있는 모바일 환경에서도 문제없이 돌아갈 것이다. 즉, 크로스 플랫폼, 크로스 웹브라우징이라는 컨셉에 제대로 맞아 떨어지는 서비스를 만들어야 앞으로 웹서비스로서의 명맥을 유지할 수 있겠다는 생각이 든다.

그러다보니 국내의 경우 무수히 많은 서비스들이 자체적인 기능을 구현하기 위해 플러그인을 많이 사용했는데 이제는 더 이상 그런 플러그인을 사용하는 기능을 사용할 수 없게 될 것으로 보인다. 일반적으로 서비스의 구조가 서비스를 제공하는 서비스 서버(웹서버와 그 아래에 운영되고 있는 각종 서비스 서버들)와 내용을 제공받아서 보여주는 클라이언트, 즉 웹브라우저로 되어 있을 때 플러그인 구조는 클라이언트에서 제어되는 구조로 서비스를 사용하기 위해 사용자의 클라이언트를 제어하는 시대는 저물어가고 있다는 얘기다. 물론 꼭 필요하다면 클라이언트 제어를 사용해야 하지만 지금처럼 대부분의 보안 및 제어, 확장을 클라이언트에게 맡기는 것은 더 이상 의미가 없다는 얘기다. 앞으로는 서버 부분에서 클라이언트에서 했던 보안 및 제어 부분을 담당하는 시대가 될 듯 싶다.

보안 관점에서의 차이

보안 관점에서 봤을 때 클라이언트에서 사용자 확인을 하는 것과 서버에서 사용자 확인을 하는 것은 그 접근 방식 및 컨셉이 다르다. 클라이언트에서의 사용자 확인을 한번 살펴보자. 예를 들어 로그인 후의 통신에 대해서 얘기할 때 지금의 국내 서비스와 같은 방식을 본다면 공인 인증서(아니면 표준 인증서)를 먼저 인증해야 하고 인증 후 인증서 안에 있는 암호화 키를 이용하여 서버와 보안 연결을 한다. 인증 때 키보드의 입력이 가로채지면 안되니 키보드 보안도 함께 진행한다. 공인 인증서를 이용할 경우 앞서 얘기한 모든 작업들이 대부분 웹브라우저 자체의 기능이 아닌 플러그인을 통해서 진행된다. 표준 인증서를 이용할 경우에는 적어도 인증서 인증 부분과 암호화 통신은 웹브라우저에서 제공하는 SSL 기능 등으로 대체할 수 있어도 키보드 보안의 경우에는 무조건 플러그인을 이용해야 한다(아직 웹브라우저가 키보드 보안 기능을 제공하고 있지 않기 때문이다).

서버에서의 사용자 확인은 좀 다르다. 기본적으로 서버에 접속할 때 HTTPS와 같은 표준 암호화 방식을 이용하며 인증서 로그인보다는 ID / PW 방식에 2차 인증 방식, 예를 들어 OTP(One Time Password)나 그림문자(CATCHA)를 함께 해서 이른바 기계적인 로그인을 막는 정도로만 진행한다. 대신에 사용자의 패턴 등을 분석하여 해당 사용자가 맞는지 아닌지를 판단하고 그 결과에 따라서 서버가 액션을 취하는 방식을 많이 이용한다. 최근 빅데이터 시스템을 활용하는 부정사용방지시스템(FDS)이 많이 활성화 되고 있는데 서버에서의 사용자 인증 및 확인 방식의 대표적인 케이스라고 보여진다. 현재의 방식은 클라이언트에서 한번 인증되면 결제 등에서 재차 인증을 하기는 하지만서도 사용자의 인증 과정 중 따로 행위 패턴을 본다던지 하는 과정 없이 그냥 입력되는 부분에 대한 검증만 진행한다. 결국 현재의 방식은 많약 액션을 취하고 있는 클라이언트가 사용자 본인이 아닌 해커라고 하더라도 입력되는 값이 저장된 값과 동일하다면 다 허용하는 시스템인 셈이다. 서버에서의 확인 방식은 적어도 어느 정도는 그런 부분을 막을 수 있는 여지는 있다.

웹 접근성에서의 차이

웹 접근성 부분에 있어서도 클라이언트 중심보다 서버 중심이 더 유리한 것은 클라이언트 중심이 되다보면 웹브라우저의 특성을 많이 타게 되고 앞서 얘기했던 것처럼 뭔가 웹브라우저에서 제공하지 않는 기능을 제공해야 할 경우 플러그인을 제작해서 배포해야 하는데 그것이 플랫폼마다 웹브라우저마다 다 다르기 때문에, 게다가 모바일의 경우 플러그인이 지원안되는 경우도 있기 때문에 많은 공수가 들어가야 한다는 부담감이 있다. 하지만 서버 중심의 경우에는 그런 기능들이 서버에서 다 이뤄지기 때문에 클라이언트, 즉 웹브라우저는 서버에서 제공하는 내용만 표시해주면 된다. 물론 웹브라우저에서 제공하는 표준 기능들을 최대한 활용하여 각 서비스가 원하는 별도의 기능들을 만들 수 있지만 그것 역시 표준 기능 안에서 만들어졌기 때문에 어떤 플랫폼에서도, 또 어떤 웹브라우저에서도 다 동작이 가능해서 웹 접근성이 무척이나 좋아진다는 장점이 있다. 물론 클라이언트에서 어떻게 보면 쉽게 구현할 수 있는 부분을 서버에서 구현하려고 하다보니 다른 접근 방식과 기술이 필요하게 되며 그만큼 기획이나 개발 입장에서는 무척이나 머리아픈 일이 될 수도 있다. 공수가 들어가는 것은 어떻게 보면 클라이언트 중심의 웹 서비스를 만드는 것과 비슷하지 않겠는가 싶다만 그래도 모든 플랫폼에서, 또 모든 웹브라우저에서 다 동작할 수 있다는 그 장점이 충분히 부담감을 덮어주고도 남지 않겠는가 싶다.

이제는 플러그인 없는 웹브라우저들이 대세가..

뭐 어찌되었던 앞으로는 클라이언트 중심보다는 서버 중심의, 그리고 플러그인 중심보다는 웹표준 중심의 웹 서비스가 대세를 이룰 것이라고 생각이 든다. 당장에 향후에 나올 대부분의 웹브라우저가 MS의 엣지나 구글 크롬과 같이 플러그인을 더 이상 지원하지 않을 것으로 보이기 때문이다. 참고로 크롬에서 제공하는 확장 모듈과 플러그인은 다르다. 확장 모듈의 경우 어떤 서비스를 사용하는데 있어서 있어도 되고 없어도 동작하는데 문제가 없지만 플러그인의 경우 해당 플러그인이 없을 경우 서비스가 동작하지 않는다는데 차이가 있다. 아직 모질라의 파이어폭스가 언제쯤 NPAPI의 지원을 중단할지는 모르겠지만(파이어폭스의 전신이 NPAPI가 있었을 때의 넷스케이스이기 때문에 바로 지원 중단을 선언하거나 그러지는 않을 듯 싶다) 어찌되었던 플러그인을 제공하는 방식을 줄여나가는 것이 추세라고 본다면 향후 IE도 ActiveX 지원 중단을 선언할 것으로 보이며 파이어폭스도 NPAPI 지원 중단을 선언할 것으로 보인다. 앞으로 웹서비스를 기획하고 개발하는 입장에서 볼 때에는 어떻게 하면 표준 HTML을 통해 서비스를 만들 수 있을까를 고민해야 한다는 얘기다. 물론 HTML5로 넘어오면서 플러그인 없이도 다양한 기능을 구현할 수 있도록 막강해졌기 때문에 큰 문제는 되지 않겠다만 보안 파트의 경우 꽤 고민이 많을 것으로 보인다.

이제 플러그인 시대는 저물었다. 플러그인의 도움 없이 표준 웹 기술만으로 서비스를 만들어서 타 서비스와 차별점을 바탕으로 마케팅을 하고 운영을 해서 사용자들에게 선택을 받아야 할 시기가 도래한 것이다.