반응형 웹의 진실 트렌드 따라가다 내실 놓친다
뉴딜코리아 홈페이지 | 뉴딜코리아
http://cafe.naver.com/rapid7/2548
반응형 웹의 진실
트렌드 따라가다 내실 놓친다
반응형 웹’, IT트렌드라 불러다오!반응형 웹은 어떻게
트렌드가 됐나
국내에 스마트폰이 도입된 지 불과 7년. 셀 수 없이 등장한 다양한 디바이스들은 시공간 제약을 무의미하게 만든 채 언제 어디서나 정보로의 접근을 가능하게 만들었다. 기술은 시각을 다투며 급속도로 발전했고, PC뿐만 아니라 스마트폰, 태블릿, 심지어 TV에서도 웹에 접속할 수 있는 IT환경이 만들어졌다.
웹에 접근할 수 있는 디바이스의 폭이 넓어진 만큼, 개발자 들은 각각의 디바이스에 적합한 해상도와 레이아웃을 일일이 대응해야 한다는 골칫거리가 생겼다. 이런 이슈의 해결방안으 로 대두된 것이 바로‘반응형 웹(Responsive Web)’이다.
반응형 웹은 웹디자이너 매거진‘A List Apart’2010년 5월 호에 실린‘Responsive Web Design’에서 처음 소개됐다. 반 응형 웹은 우리가 여러 채널을 통해 지겹도록 들어온‘스마트 기기의 파편화’문제를 깔끔하게 해결해줄듯, 그렇게 한줄기 빛처럼 등장했다.
‘스마트한 웹 페이지’구현이 가능하다는 점에서 최신기술 로 인정받는‘반응형 웹’은 한 번의 개발로 디스플레이 종류에 따라 화면의 크기 및 해상도가 자동으로 조절돼‘최적화된 화 면’을 보여주는 웹 구현방법이다. 즉, 반응형 웹은 단 하나의 소스코드로 N스크린(N-Screen)에 맞춰 화면이 자동으로 최 적화되는 것을 목표로 삼아, 사용자 환경 변화에 즉시 반응할 수 있도록 구현된다.
반응형 웹을 사용하는 입장에서는 어느 기기에서든 동일한 웹페이지를 제공받을 수 있고, 기업 및 개발자 입장에서는 기 기마다 따로 코드를 개발/관리하지 않아도 되기 때문에 초기 개발비용을 절감할 수 있을 뿐만 아니라 유지관리까지도 용이 해진다. 국제 웹표준화 기구인 W3C에서 웹표준으로 지정한 HTML, CSS3로 소스코드가 작성된다는 점 또한 반응형 웹의 장점으로 거론된다.
반응형 웹은 앞서 말한 매력 포인트들로 인해 IT시장에서 인 기급상승 물결을 탔고, 어느새 IT트렌드로 자리매김하게 됐다. 반응형 웹이 분명 매력적인 장점들을 갖고 있는 것은 분명하 다. 하지만 하루가 멀다 하고 쏟아져 나오는 수많은 기기에 대 응하기 위한‘유일무이한 해결책이 반응형 웹인가?’라는 의문 은 떨칠 수가 없다.
이에 필자는 발상의 전환을 시도해보기로 한다. 앞서 말한 반응형 웹의 지향점은 참으로 이상적인 듯하나, 단순히 해상도 와 화면 사이즈를 조절해 많은 정보를 압축해 한 화면에 담아 내는 것이 사용자에게‘진정한 만족감’을 줄 수 있을지는 생각 해봐야 할 문제다.
모바일 시장의 성장과 모바일 기기가 갖고 있는 무수한 기능 들로 인해 현재‘모바일’을 빼놓고는 웹을 논할 수 없는 상황이 다. 이에 웹 기획의 핵심 지침은‘모바일 퍼스트 전략(Mobile First Strategy)’이 됐다.
모바일 퍼스트 전략은 최소 단위인 모바일을 기준으로 삼아 태블릿, 데스크톱(PC) 순의 더 큰 해상도로 점차 웹페이지를 변형·확장하는 방법이다. 기획자는 이 전략을 바탕으로 사용 자 환경 변화에 퍼센트(%)로 반응하게 할 것인지, 물리적 사이 즈(해상도)로 반응하게 할 것인지 등의 기준을 잡고 웹의 레이 아웃을 설계하게 된다. 이때‘레이아웃 단순화’를 핵심으로 삼 는다.
또한 레이아웃 안을 채울 콘텐츠는 일관된 형태여야 하며 디 자인 또한 통일감 있게 표현돼야 하는데, 화면 사이즈에 따라 바뀌는 유동적 레이아웃을 최소 사이즈의 디바이스에서도 어 느 정도 가독성 있는 형태로 유지해야 하기 때문이다.
이렇게 기획된 반응형 웹은 화면이 커짐에 따라 콘텐츠 영역을 넓히는 방식을 택하기 때문에 복잡한 화면 설계를 필요로 하지 않는 다.
그런데 이 전략은 우리나라 IT시장에서 난항을 겪을 수밖 에 없다. 우리는 많은 정보를 압축해 한 화면에 표현하는 것을 선호하는 편이다.
이는 국내기업이 운영하는 대표 포털사이트 ‘네이버’와 미국 기업이 운영하는 포털사이트‘구글’첫 페이 지만 비교해봐도 쉽게 이해할 수 있을 것이다.
예를 들어, 많은 정보를 한 화면에서
보고 싶어 하는 우리나 라의 사용자는 콘텐츠 양이 적거나 이미지 사용이 적은 웹을 ‘완성도가떨어진다’고평가하고,‘ 정보가없네’,‘ 내가원하는
사이트가 아냐’라고 판단해 더 이상 사용하지 않게 된다는 것 이다. 이러한‘웹 구현 방식’과‘사용자 만족도’간의 인과관계 는 기업 업무용
시스템에서 더욱 명확하게 드러난다. 웹 구현 방식이 사용자 기호, 즉 사용자 편의성에 부합하느냐에 따라 생산성 및 업무효율성에 극명한 차이를
보이기 때문이다.
반응형 웹이 해결해야 할 이슈가 단순히 사용자 기호에 국한 된 것이라면 그나마 다행이련만, 반응형 웹은 더 큰 숙제들을 떠안고 있다. 현실적으로 반응형 웹 구현에 있어 기획자가 처 음 기획했던 대로 원하는 가독성을 얻기란 많은 경우 불가능하 다.
물론 모든 텍스트의 가독성이 떨어지는 것은 아니다. 그러나 표를 이용한 텍스트 설명이나 이미지 텍스트를 사용해야 할 경 우, 반응형 웹의 기본 논리에 따라 디바이스 해상도에 맞춰 강 제로 크기를 축소시키기 때문에 가독성이 떨어지고 결국 정보 전달력이 약해질 수밖에 없다.
PC나 태블릿에 비해 가독성이 떨어지는 모바일 기기에서 로 딩속도까지 느리다면 어떨까? 아마도 사용자는 반응형 웹으로 구현된 사이트를 이용하고 싶지 않을 것이다. 그런데 실제로 반응형 웹은 로딩속도 이슈도 갖고 있다.
반응형 웹은 HTML5로 코딩하고 CSS3에 각 디바이스별로 레이아웃을 지정하는 미디어쿼리를 전부 불러오게 되는데, 이 때 모든 장치를 위한 CSS를 로드하게 된다. 불필요한 수백 개 의 소스를 미리 불러들이는 이 작업으로 웹 로딩속도는 현저히 느려지게 되고, 이는 결국 사용자가 불편함을 느끼게 되는 요 인이 된다. 반응형 웹의 로딩속도 이슈는 PC와 태블릿에서도 발생하지만, 이들에 비해 암묵적으로 더욱 빠른 속도를 요구받 는 모바일에서는 특히 부각돼 문제시된다.
이뿐만이 아니다. 오래된 웹사이트들은 PC용으로만 제작된 경우가 많아, 기존 사이트를 반응형 웹으로 변경할 경우 사이 트를 전부 새로 구축하는 경우가 대다수다. 업데이트상의 문제 도 있다. 미디어쿼리를 이용해 웹을 구축한 후 페이지 내 새롭 게 콘텐츠를 추가해야 하는 경우, 브라우저, OS(운영체제), 기 기, 속도 등과 같은 다양한 변수들에 대해 일일이 테스트를 거 쳐야 한다는 번거로움이 발생한다.
간단한 텍스트 수정 정도는 용이할 수 있겠으나, 정보를 담 고 있는 콘텐츠의 추가/삭제는 레이아웃을 변경해야 하는 대대 적인 작업이 수반된다. 반응형 웹이 무조건 유지보수가 편리하 다는 주장은 해상도와 크기에 구애받지 않을 정도의 아주 단순 한 콘텐츠만을 보유하고 있거나, 향후 콘텐츠의 추가·삭제가 발생하지 않는 경우에만 해당된다고 보면 된다.
반응형 웹 언어인 CSS3는 애니메이션과 캔버스 등과 같이 새로운 스타일을 통해 이미지나 플래시(Flash), 자바스크립트 (JavaScript)를 사용하지 않고도 웹사이트를 구축할 수 있다는 장점이적용하는 것은 불가능하다. CSS3의 경우 브라우저 종류나 버전에 따라 지원 상태가 다르다는 점이 가장 큰 이유이다. 미디어쿼리를 사용하 는 반응형 웹은 CSS3 기술이 적용되기 때문에 인터넷익스플로 러(IE) 9부터 지원하고 있고, 타 브라우저도 버전별로 일부 태 그들은 지원하지 않는 경우들도 많다.
이런 문제는 하위버전을 사용하는 유저를 버리고 갈 것인지, 하위버전 전용 페이지를 추가로 만들어 별도로 제공할 것인지, 하위버전 전용 라이브러리를 추가할 것인지 등을 선택해야만 하는 상황을 초래한다. 기업이나 공공기관, 금융권에서는 아직 까지 IE7,8을 사용하는 곳이 적지 않기 때문에 반응형 웹을 모 든 브라우저에 최적화시키기란 불가능하고, 반응형 웹을 꼭 구 현해야 하는 경우라면 IE9 이하는 포기해야 하는 것이 현실이 다. (2015년 1월부터 현재까지를 기점으로 국내 브라우저 버전 별 점유율 통계에서 IE8 사용자들이 13% 이상을 차지한다) 상위 버전 브라우저라 할지라도 각 브라우저별로 적용되는 스타일 태그들이 상이하며, 실제 화면에서 보이는 디자인 또한 달라 크로스 브라우징이 쉽지 않다. 반응형 웹에서 크로스 브 라우징은 기본인데, 다양하고 방대한 문제점들로 인해 기획단 계에서 제한을 두고 작업하는 경우들이 빈번하다.
반응형 웹이 해결해야 할 이슈가 단순히 사용자 기호에 국한 된 것이라면 그나마 다행이련만, 반응형 웹은 더 큰 숙제들을 떠안고 있다. 현실적으로 반응형 웹 구현에 있어 기획자가 처 음 기획했던 대로 원하는 가독성을 얻기란 많은 경우 불가능하 다.
물론 모든 텍스트의 가독성이 떨어지는 것은 아니다. 그러나 표를 이용한 텍스트 설명이나 이미지 텍스트를 사용해야 할 경 우, 반응형 웹의 기본 논리에 따라 디바이스 해상도에 맞춰 강 제로 크기를 축소시키기 때문에 가독성이 떨어지고 결국 정보 전달력이 약해질 수밖에 없다.
PC나 태블릿에 비해 가독성이 떨어지는 모바일 기기에서 로 딩속도까지 느리다면 어떨까? 아마도 사용자는 반응형 웹으로 구현된 사이트를 이용하고 싶지 않을 것이다. 그런데 실제로 반응형 웹은 로딩속도 이슈도 갖고 있다.
반응형 웹은 HTML5로 코딩하고 CSS3에 각 디바이스별로 레이아웃을 지정하는 미디어쿼리를 전부 불러오게 되는데, 이 때 모든 장치를 위한 CSS를 로드하게 된다. 불필요한 수백 개 의 소스를 미리 불러들이는 이 작업으로 웹 로딩속도는 현저히 느려지게 되고, 이는 결국 사용자가 불편함을 느끼게 되는 요 인이 된다. 반응형 웹의 로딩속도 이슈는 PC와 태블릿에서도 발생하지만, 이들에 비해 암묵적으로 더욱 빠른 속도를 요구받 는 모바일에서는 특히 부각돼 문제시된다.
이뿐만이 아니다. 오래된 웹사이트들은 PC용으로만 제작된 경우가 많아, 기존 사이트를 반응형 웹으로 변경할 경우 사이 트를 전부 새로 구축하는 경우가 대다수다. 업데이트상의 문제 도 있다. 미디어쿼리를 이용해 웹을 구축한 후 페이지 내 새롭 게 콘텐츠를 추가해야 하는 경우, 브라우저, OS(운영체제), 기 기, 속도 등과 같은 다양한 변수들에 대해 일일이 테스트를 거 쳐야 한다는 번거로움이 발생한다.
간단한 텍스트 수정 정도는 용이할 수 있겠으나, 정보를 담 고 있는 콘텐츠의 추가/삭제는 레이아웃을 변경해야 하는 대대 적인 작업이 수반된다. 반응형 웹이 무조건 유지보수가 편리하 다는 주장은 해상도와 크기에 구애받지 않을 정도의 아주 단순 한 콘텐츠만을 보유하고 있거나, 향후 콘텐츠의 추가·삭제가 발생하지 않는 경우에만 해당된다고 보면 된다.
반응형 웹 언어인 CSS3는 애니메이션과 캔버스 등과 같이 새로운 스타일을 통해 이미지나 플래시(Flash), 자바스크립트 (JavaScript)를 사용하지 않고도 웹사이트를 구축할 수 있다는 장점이적용하는 것은 불가능하다. CSS3의 경우 브라우저 종류나 버전에 따라 지원 상태가 다르다는 점이 가장 큰 이유이다. 미디어쿼리를 사용하 는 반응형 웹은 CSS3 기술이 적용되기 때문에 인터넷익스플로 러(IE) 9부터 지원하고 있고, 타 브라우저도 버전별로 일부 태 그들은 지원하지 않는 경우들도 많다.
이런 문제는 하위버전을 사용하는 유저를 버리고 갈 것인지, 하위버전 전용 페이지를 추가로 만들어 별도로 제공할 것인지, 하위버전 전용 라이브러리를 추가할 것인지 등을 선택해야만 하는 상황을 초래한다. 기업이나 공공기관, 금융권에서는 아직 까지 IE7,8을 사용하는 곳이 적지 않기 때문에 반응형 웹을 모 든 브라우저에 최적화시키기란 불가능하고, 반응형 웹을 꼭 구 현해야 하는 경우라면 IE9 이하는 포기해야 하는 것이 현실이 다. (2015년 1월부터 현재까지를 기점으로 국내 브라우저 버전 별 점유율 통계에서 IE8 사용자들이 13% 이상을 차지한다) 상위 버전 브라우저라 할지라도 각 브라우저별로 적용되는 스타일 태그들이 상이하며, 실제 화면에서 보이는 디자인 또한 달라 크로스 브라우징이 쉽지 않다. 반응형 웹에서 크로스 브 라우징은 기본인데, 다양하고 방대한 문제점들로 인해 기획단 계에서 제한을 두고 작업하는 경우들이 빈번하다.
반응형 웹을 적용하 기 위해 많은 양의 콘텐츠를 축소시키고, 하나의 소스로 기기 별 코드를 관리하면 되기 때문에 유지 보수 비용도 줄어든다. 소스뿐 아니라 콘텐츠 내용 자체를 최대한 단순화시켜 야 하므로 보이는 화면 자체의 관리도 훨씬 수월해진다.
그런데 사용자는 반응형 웹이 뭔지, 웹표준이 적용됐는지, 유지보수는 용이 한지 등 어렵고 복잡한 내용에는 관심 이 없다. 단지 빠르게 접속할 수 있고, 원하는 정보를 최대한 많이 정확하게 파악할 수 있는 웹사이트를‘유용한 사 이트’혹은‘잘 구축된 사이트’로 여길 뿐이다.
반응형 웹은 사실 운영자나 개발자의 편의를 위한 것이나, 이상적인 목표와 장점만을 강조해 마치 사용자에게 이점을 주는듯 그럴싸하게 포장돼왔다. 많은 클라 이언트들은 반응형 웹을 둘러싼 이 예쁜 포장에 현혹돼 사용자 입장에서 고려해야 할 많은 부분들을 간과하게 된다. 바로‘웹 사이트의 목적’과‘사용자 편의성’이다.
웹사이트의 목적을 충분히 반영하고 사용자 입장을 고려한 사례는 국내 대표 포털사이트‘네이버’와‘다음’이다. 이들은 반응형 웹으로 사이트를 구현하지 않았다. 국내 굴지의 기업에 서 기술력이 부족해 반응형 웹을 적용하지 못한 것일까? 아니 다. 이 웹사이트들은‘정보 공유 및 제공’이라는 포털사이트 목 적에 충실했고, 주요 사용자인 한국인의 특성을 고려하며, 관 리자의 편의보다 사용자의 편의를 우선시해 궁극적으로 UX(사 용자 경험) 만족도를 높이고자 했다. 그리고 이들은 모바일 시 장에서도 굳건히 자리를 지키며 제 역할을 다하고 있다.
‘네이버’와‘다음’의 웹 구현방식은‘적응형 웹(Adaptive Web)’이다. 반응형 웹과 적응형 웹은 모두 근본적으로는 웹사 이트가 모바일 기기 등 여러 다양한 디바이스 화면에서 원활한 정보를 제공하고, 더 나은 UX를 제공하고자 한다.
‘반응형 웹’은 미디어쿼리를 사용해 화면크기를 확인하고, 유연한 그리드로 화면 크기 변화에 따라 그에 알맞은 크기로 최적화된다는 특징이 있으나, 앞서 언급한 많은 문제점들을 갖 고 있다. 반면, 적응형 웹은 모든 스크린 사이즈에 최적화된 화 면을 구현하는 정교함은 떨어진다. 하지만 디바이스에 최적화 된 이미지를 사용하고, 자바스크립트를 통해 장치를 분석하고 그에 맞는 동작을 적용해 화면을 구현한다.
이 방식은 서버나 클라이언트에서 웹에 접근한 디바이스를 확인하고 그 디바이스에 최적화된 마크업을 호출하게 되는데, 이때 마크업은 필요한 정보만을 노출시켜 보다 빠른 속도로 모 바일에서 웹사이트를 이용하게 도와준다. 디바이스에 최적화 된 화면을 보여주는 것이 아니라, 최적화된 성능을 가져오는 방식인 것이다.
당신은 개발자일 수도, 관리자 혹은 기업 IT담당자일 수도 있다. 당신은 눈앞에 닥친 웹사이트 구축 프로젝트를 수행해야 혹은 책임져야 한다. 당장 눈앞에 봉착한 이 프로젝트를 모바 일 퍼스트 전략을 바탕으로 반응형 웹을 적용해 단순하게 기 획·구축하고, 향후에도 편리하게 관리하고 싶은 마음이 굴뚝 같을 것이다. 그런데 이렇게 만들어진 당신의 웹사이트를 사용 자들이 이런저런 불편함을 호소하며 이용하지 않는다면, 그 웹 사이트를 만든 의미가 있을까?
필자는 개발자, 관리자, 사용자의 입장을 상호 배려하면서도 실효성 있는‘적응형 웹’을 상기 질문에 대한 해답으로써 컴퓨 터월드 6월호를 통해 집중 조명해볼 예정이다. 적응형 웹에 대 한 이론은 많이 접해봤을 독자들을 위해 실질적이고 현실적인 사례를 통한 접근을 시도해보도록 하겠다. 필자의 다음 글을 접하기전까지,‘ 반응형웹이최고’라는잘못된상식이부디당 신의 머릿속에서 깨끗하게 지워지기를 바라본다
출처 : 디비가이드
댓글 없음:
댓글 쓰기