The post latest news test appeared first on 클리어픽스.

이 제목을 보고 조금 의아해 하신 분들도 계실겁니다.

RWD에 관심이 있으신 분들은 포털에서 적용중인 다양한 반응형 웹디자인 사례들을 알고 계실테니까요.

하지만 그러한 사례의 대부분은 모바일과 태블릿만을 대응하거나, 데스크탑에서 브라우저창의 너비가 좁을 때와 넓을 때를 분리하여 대응하는 정도입니다.

여전히 모바일과 데스크탑은 별개의 사이트로 분리되어 있고, 분리된 도메인을 사용하고 있습니다.

네이트의 모바일 페이지는 태블릿의 더 넓은 공간을 활용합니다

네이버 영화 페이지는 와이드모니터의 더 넓은 공간을 활용합니다

어떠한 사이즈의 디스플레이를 가지고 있는 환경이라도 하나의 소스로 모두 대응을 해내는 개념을 RWD라고 본다면,

그러한 원칙에 충실하게 RWD가 적용된 국내 포털서비스는 다음 사전이 유일합니다.

다음 사전은 하나의 페이지로 데스크탑과 모바일 모두를 대응합니다

RWD를 사용하여 하나의 사이트로 양쪽을 모두 대응하지 않는 가장 큰 이유는 양쪽을 분리하여 대응하는 방법이 먼저 정착되었기 때문입니다.

너무 뻔한 이야기 일까요?

2007년 아이폰의 등장이후 본격적으로 모바일에서 웹사이트를 사용할 수 있는 모바일 기기들이 상업화 되기 시작했습니다.

이전에도 WAP과 같이 열악한 기기 환경에 맞추어 최소화된 인터넷 서비스가 있기는 했지만,

실제 웹 브라우저를 탑재하여 웹서핑을 할 수 있는 기기들이 나타면서 ‘풀 브라우징’이라는 용어가 몇 년간 사용되기도 했었습니다.

하지만 아이폰외의 초기의 기기들은 데스크탑에 맞추어진 웹사이트들을 이용하기에는 너무도 불편했습니다.

그 때가 잘 기억나지 않으시는 분들도 계시겠지만 저는 확실히 기억합니다. 답답해서 도저히 사용 하기 힘든 환경이었지요.

이를 개선하기 위해 모바일 기기 제조사들과 브라우저 개발사들이 사용성과 속도향상에 매진하는 동안 웹서비스 제공자들은 모바일 시장을 선점하기 위해 모바일 전용 웹사이트를 만들기 시작했습니다. 빠르게 로딩될 수 있도록 내용도 많지 않고, 이미지도 적게 사용하며 글씨도 큼직큼직한 웹 사이트를 만든 것이지요.

국내에선 다음이 먼저 시작했고, 곧 다른 업체들도 같은 방식의 모바일 전용 웹사이트를 만들기 시작했습니다.

그 때의 상황에선 그것이 서비스 제공자로서 할 수 있는 최선이었으니까요. 사용자들에게도 모바일 전용사이트가 이용하기에 편했습니다.

데스크탑 화면 그대로 웹을 이용하던 초기 스마트폰 시장에서 다음은 모바일 전용 사이트를 운영했습니다

그렇게 기존의 웹사이트와 모바일 전용사이트로 나누어진 흐름이 지금까지 이어지게 되었습니다.

그리고 그러한 대응 방식은 대다수의 사용자들을 만족시키기에 충분하기도 했습니다.

네. 저는 ‘충분하다’고 말씀 드렸습니다.

그렇다면 굳이 RWD를 사용할 이유는 없을까요?

솔직히 말씀드리면… 저는 그렇다고 생각합니다. 적어도 포털(대형사이트)에게는요.

RWD는 2010년에야 소개되어 검증되고 개발자들의 확신을 얻기까지 많은 시간이 걸렸습니다.

하지만 포털이 이를 도입하기는 쉽지 않은 문제들이 있었습니다.

시스템 상의 문제

먼저 개발 기술에 포함되지 않는 회사 내부 사정에 대한 측면을 생각해 볼 수 있을 것 같습니다. 이 부분이 개발상의 문제보다는 훨씬 크겠지요. 이에 대해서는 제가 만난 모든 분들이 이견이 없으셨습니다.

기본적으로 방향을 결정할 수 있는 권한이 개발자에게 없습니다. 새로운 방법론을 프로젝트에 적용하기 위해 많은 의사결정권자들을 설득해 가는 것은 정말 쉽지 않은 일입니다. 그렇게 하려면 사내의 다른 구성원들에게도 공감을 얻을 수 있어야 하는데, RWD는 그런 매력이 부족합니다.

기술적 이상향으로서는 검색엔진 최적화(SEO)에 유리하고 One Web의 보편적 사용자 배려 정신을 잇는 등 훌륭한 가치를 담고 있지만, 경제적인 논리로 볼 때는 그다지 큰 이익이 없기 때문입니다. 오히려 이제까지 해오던 방식이 아니기 때문에 감수해야하는 리스크 비용도 큽니다. RWD에서 이야기 하는 ‘모든 크기의 화면 대응’은 기존의 웹과 모바일 전용사이트를 분리하는 방식으로도 충분히 대응 가능하기 때문에 그다지 필요를 크게 느끼지도 않습니다.

그럼에도 포털이 RWD를 시도한다면 그 이유는 기술적 이상향으로서 방향에 대한 공감, 보유 기술역량 과시, 새로운 경험을 통한 개발자의 기술 역량 강화 등일 것입니다.

개발에서의 문제

저는 2가지로 이유를 정리 해 보고 싶습니다.

1. 페이지 최적화 문제

2. 소스 오더(소스상 코드 순서)의 문제

1.페이지 최적화의 문제

RWD를 하기로 결정했다고 해도, 여전히 RWD를 실현하는 것은 쉽지 않은 문제입니다. 여러가지 문제가 있지만,

가장 큰 것은 페이지 최적화의 문제입니다. 얼마나 페이지가 빨리 화면에 뜰 수 있게 하느냐 하는 것이지요.

원칙적으로 RWD는 데스크탑에서 보여지는 모든 화면상의 요소들을 모바일에서도 놓치지 않고 볼 수 있는 방식입니다.

데스크탑에서의 넓은 화면을 모바일의 좁은 화면에서 보려면 페이지가 세로로 길어질 수 밖에 없겠지요. 하지만 스크롤을 통해 모두 볼 수 있으니 괜찮습니다.

정말 괜찮을까요? 컨텐츠가 적은 페이지에서라면 괜찮을겁니다.

컨텐츠의 양이 많지 않으면 모바일의 세로 스크롤도 그렇게 길어지지는 않습니다

 
하지만 흔히 볼 수 있는 포털 웹사이트의 메인페이지를 모바일용으로 길게 늘어놓으면….!? 한 화면에 많은 상품들을 늘어놓는 쇼핑몰 페이지를 모바일 용으로 길게 늘어 놓는다면?

엄청난 길이가 될겁니다. 스크롤로 모두 보기에는 너무도 불편해지고 맙니다.

RWD에서 추구하는 가치인 ‘화면상의 모든 요소를 어느 기기에서도 이용가능’하게 하려면 이런 만리장성같은 스크롤을 감수해야합니다.

그렇게 엄청난 스크롤이 UX측면에서 좋지 못하다는데 동의하시나요? 그러면 일단 그 원칙은 접어두고 보이지 않는 요소가 일부 있어도 괜찮다고 생각해보기로 하지요.

모든 요소를 화면에 뿌려놓기엔 너무 페이지가 길기 때문에, 기존의 모바일 전용 웹사이트 처럼 조금 덜 중요한 요소들은 화면상에 표시되지 않도록 숨겨주기로 해봅시다.

불필요한 요소들에 CSS의 display:none 속성을 부여함으로 손쉽게 숨길 수가 있습니다.

그런데 이러한 방법을 사용하는 것은 실제로 화면에 보여지지도 않을 코드와 데이터를 사용자의 기기에 다운로드 받는 셈입니다. 화면상에 표시하는 이미지 또한 Flexible Image 방식을 통해 사이즈를 줄여 보여주기 때문에, 사용자에게 보여지는 이미지의 크기에 비해 너무 큰 용량을 가지게 될 수 도 있습니다.

결국 사용자는 불필요한 리소스를 다운받느라 아까운 시간과 데이터만 낭비하게 된 셈입니다. 특히나 요즘처럼 무제한 데이터 요금제가 아닌 종량제를 사용하는 사용자들이 많은 상황에선 이런 낭비는 반갑지 않습니다. 서비스 제공자 입장에서도 서버와 회선비에 들어가는 비용이 증가하기 때문에 비효율적입니다.

페이지 최적화를 위한 서버 솔루션, RESS

이러한 문제를 해결하기 위해 RESS라는 이름으로 RWD에 맞게 서버 환경을 조성하는 방법론이 제기되기도 했습니다. RESS는 Responsive Design 과 Server Side Components의 머릿글자를 따서 만든 약어로, 반응형을 위한 서버측 최적화 작업을 뜻합니다.

하지만 저는 이 글을 연재하는 동안 이후 RESS에 대해서는 자세히 언급하지 않으려고 합니다. 없는 셈 치겠다는 이야기입니다. 제가 잘 모르는 분야이기도 하고, 이런 방식의 서버를 통한 대응은 결국 모바일 전용사이트를 제작하여 대응하는 것과 크게 다르지 않다고 생각합니다. 서버에서 사용자 환경을 판단 할 수 있는 정보는 브라우저에서 페이지를 요청할 때 보낸 User-agent 값 뿐이니까요. 그에 따라 분기처리를 하는 코드를 만들어야 한다면 분리된 모바일 전용 웹사이트를 만드는 수고를 하는 것과 큰 차이가 없는 것 아닌가 싶습니다. 쉽게 작업하기 위해 만든 방법론에 어려운 해결 방식을 도입하는 것도 그다지 반갑지 않습니다.

RWD 방법론에서 해결 할 수 없어서 RESS가 그 역할을 대신하는 문제를 해결 할 수 있게 하기위해 새로운 표준들이 제정되어가고 있습니다. 결국 시간이 지나면 이러한 기능들이 브라우저에 구현되어 탑재될 것이고, 서버의 도움은 필요하지 않게 될 것입니다.

하지만 이것은 어디까지나 이상적인 입장입니다. 실무에 당장 적용해야 하는 상황이라면 RESS를 생각하지 않는 것이 훨씬 이상합니다. 새로운 표준이 브라우저에 도입되기만을 기다리다가는 늙어 죽을지도 모릅니다.

2. 소스오더의 문제

여러분의 사장님이 ‘페이지 최적화는 신경쓰지 않아도 된다’라고 말씀하신다면, RWD를 구현하는데는 문제가 없는 것일까요?

그렇더라 하더라도 소스오더의 문제가 남아있습니다. HTML소스상에서 기록한 코드의 순서대로 컨텐츠를 화면에 나열하려면 아무런 문제가 없지만, 순서를 바꾸고자 한다면 곤란해지는 것이지요.

웹표준을 잘 지키자는 분위기가 조성되면서, CSS를 적용하지 않아도 문서가 잘 보여지도록 컨텐츠를 흐름에 따라 배치하고 잘 구조화 하는 코드작성이 장려되어 왔습니다. RWD는 웹표준을 잘 지켜 작성된 코드를 전제로 합니다. 또한, 그 코드는 당연히 컨텐츠의 중요도와 흐름에 알맞게 배치되어 있을 것으로 간주합니다. 그렇기 때문에 모바일에서는 그 순서 그대로 세로로 길게 나열된 형태로 보여주면 된다고 보는 것이지요.

하지만 실무에서는 이런 저런 이유로(대개는 작업의 편의상) 화면의 흐름과 소스오더가 일치하지 않는 경우가 종종있고, 컨텐츠 배치의 순서를 결정하는 담당자의 판단이 소스오더와 다를 수도 있습니다. 포털의 경우 다양한 서비스 섹션을 담당하는 부서가 나뉘어져 있기 때문에, 컨텐츠의 순서배치 문제는 더욱 민감한 이슈이기도 합니다. 꼭 포털이 아니더라도 규모가 큰 사이트라면 비슷한 문제가 존재할 가능성은 높지요. 쇼핑몰 사이트라면 MD들이 서로 자신이 관할하는 상품이 상단에 노출되길 바랄테니까요.

어떤 이유에서든 모바일 페이지의 컨텐츠 배열 순서를 변경하고자 하는 경우, RWD에선 그 작업이 쉽지 않습니다. 데스크탑 페이지만을 운영할 때는 HTML의 순서를 바꾸어 버리면 그만이지만, RWD의 경우에는 모바일의 순서때문에 HTML 코드 순서를 바꾸고자 하면 데스크탑에서의 순서도 바꿔야 하니까요. RWD를 구현하고자 하는 경우 사이트 전체를 완전히 리뉴얼하게 되는 큰 이유중 하나가 이 때문이기도 합니다.

HTML의 순서는 유지한채 CSS만으로 배치 순서를 바꾸는 것도 아예 불가능한 것은 아니지만 다양한 꼼수를 동원해야만 합니다. 그 마저도 쉽지 않지 않고 성공했다 하더라도 RWD에서 가장 중요한 특성 중 하나인 가변성을 잃게 된다는 문제점이 있습니다.

물론 flexbox나 grid처럼 소스오더와 무관하게 레이아웃과 배치를 변경할 수 있는 새로운 CSS속성들도 있습니다. 하지만 이 속성들의 경우 지원하는 브라우저가 적고, 표준이 완성되지 않은 문제로 문법이 계속해서 바뀌는 등, 아직 실무단계에 적용하여 사용하기엔 어려움이 있습니다.

작은규모 사이트에 더 적합한 RWD

이렇게 규모가 큰 사이트에 RWD를 적용하기 어려운 문제에 대해서 장황하게 내용을 적어보았습니다. 하지만 제가 정말 전하고 싶었던 말은 ‘규모가 작은 사이트에서는 RWD 적용이 잘 어울린다’는 이야기입니다.

최근 웹기술 이슈의 흐름은 포털위주로 흘러가는 느낌이 있다고 생각합니다.

‘하지 않는데는 이유가 있겠지. 포털에서도 아직 안하는걸 내가 할 필요는 없어. 나중에 하자.’ 라고 생각하는건 아닐까요?

대부분의 작업자들이 업무의 양이 많고 급여가 적은 소규모 기업보다는 대기업을 선호하기 때문에, 규모가 큰 사이트의 운영이나 세부 전문영역으로 다분화된 협업방식 등 웹사업을 선도하는 기업에서 사용될만한 기술을 습득하여 앞으로 자신의 커리어에 도움을 삼으려는 경향도 있는 것 같구요. 그런 이유로 실제 RWD가 가질 수 있는 효용성에 비해 RWD가 좀 소홀히 취급받고 있지 않나 하는 생각이 듭니다.

인력이 모자르면 한 명 더 집어넣으면 그만인 회사 입장에서는 RWD가 별로 매력이 없겠지만, 어떻게든 정해진 기간안에 데스크탑/모바일 양쪽을 대응해야 하는 작업자의 입장이라면 RWD는 큰 매력이 있습니다. 같은 사이트를 두 번 작업하는 것은 피할 수 있으니까요. 협업하는 동료들이 적을 수록 설득이나 의견 조율의 문제들은 수월하고, 페이지 최적화의 문제도 대규모 사이트에 비해서는 조금 더 느슨하게 처리해도 괜찮은 여지가 있다고 생각합니다.

저는 제 경력기간중 상당기간을 중소기업에서 일했습니다. 분업체계도 확실하지 않았고, 작업하는데 있어서 세부적인 결정들을 위해 일일이 상부의 허락을 받아야 할 필요가 없었습니다. 담당 작업자로서 제가 맡고 있는 업무에 대해서는 임의대로 결정 할 수 있는 폭이 지금보다는 비교적 넓은 셈이었지요.

혼자서 처리해내야 하는 업무가 많았던 그 시절로 다시 돌아간다면, 그리고 모바일 등 많은 기기 대응을 함께 해야한다면, 저는 RWD를 적극적으로 적용하여 작업을 할 것 입니다.

원문 : http://tobyyun.tumblr.com/post/57691169768/rwd-2-%EC%9E%91%EC%9D%80%EA%B7%9C%EB%AA%A8-%EC%82%AC%EC%9D%B4%ED%8A%B8%EC%97%90-%EB%8D%94-%EC%A0%81%ED%95%A9%ED%95%9C-rwd

The post 작은규모 사이트에 더 적합한 RWD appeared first on 클리어픽스.

2000년도 초부터 일본 여러기업의 브랜드 마케팅을 맡아오며, 경험을 쌓아온 클리어픽스가 한국에 오픈하게 되었습니다.

클리어픽스는 일본기업뿐 아니라 네이버나 네오지오등 한국 기업의 컨설팅을 전문 디자인 디렉터와 함께 만들어왔으며,
이러한 경험들은 앞으로 클리어픽스의 고객에게 긍정의 미래를 선사하게 될것입니다.

The post 긍정의 경험으로 최상의 미래를 만들어내는 시작 appeared first on 클리어픽스.

The post test appeared first on 클리어픽스.