cshop 님의 반응형 웹 관련 댓글을 토론으로 이어가고자 글로써 올립니다.

저는 RESS 에 대해 특별히 어떤 입장을 이야기한 바는 없었던 것 같은데요. ^^;;
내용이 여러가지 이야기들을 더 덧붙일만하다 여겨져서 글로 새로 등록을 했습니다. 양해해주시고, 한번 좋은 토론의 장이 되었으면 좋겠네요.

예전 반응형 관련 토론글에서도 언급되었지만 기술적인 접근보다는 콘텐츠에 입각한 관점에서 접근하는게 반응형을 가장 효과적으로 구현할 수 있는 방식인 것 같습니다. 말인즉슨 RESS 냐 순수한 반응형이냐 가 문제가 아니라, SIR 의 콘텐츠가 모바일로 이동했을 때 누가 그리고 왜 SIR 에 모바일로 접속하게 될까? 를 고민하는게 우선이라는 생각입니다.

RESS 에 대한 설명을 조금 찾아봤는데, 간단히 요약하면 HTML 의 선택적 전송이라고 할 수 있을 것 같은데요.
솔직하게 말해서 여지껏 제가 노력해 온 부분이 가능한 하나의 코드를 가지고 여러 환경에 대응하려던 것이어서 쉽게 받아들여지지는 않습니다.
SASS 를 선택한 cshop님이 LESS 로 넘어가기가 주저되는 것과 비슷하달까요?
(가능한 한, 최대한 http://minsup.kr 처럼 하나의 코드로 작업하고 싶네요.ㅋㅋㅋ)

그런데 재밌는 건, 이 글을 쓰다 보니 처음에 언급한 콘텐츠 관점에서 바라봤을 때 RESS 가 상당한 이점을 가진 것은 분명하다는 생각이 든다는 것입니다. 직접 구현해보다 보면 보다 명확한 관점이 생길 것 같습니다. 지금은 예열만 하는 상태니까요.

RESS 의 가장 매력적인 장점은 URL 이 분산되지 않는다는 것인 것 같네요. (모바일 버전을 따로 제작하는 것에 비해)
가장 치명적인(개인적으로) 단점은 앞선 댓글에서 언급한 코드가 나뉘는 것이구요.

찾아보니 제가 오래전 주장했던 것은 "RESS 는 절충안 (hybrid) 이고 좋은 방식이라고 생각합니다." 이 부분이네요. 그리고 이 생각은 지금도 동일합니다.

그리고 절충안이라고 해서 완전한 responsive design 으로 넘어가는 단계의 전 과정 기법이 아니냐고 말씀하시는 것 같은데, 아뇨. 완전한 반응형 전 단계가 아닌, 근대 웹의 최종 도착지라고 저는 주장하는 것 입니다.

RESS 에도 여러가지 flavor 가 존재합니다.

일단 "HTML 의 선택적 전송" - 역시 한국어를 참 잘하신다는.. ㅎㅎㅎㅎ

한국어의 위대함을 느낍니다. 너무나 명확한 설명입니다.

header, footer 등, 예를들어 A,B,C,D,E,F 이렇게 6가지의 element 가 존재한다면 접근하는 기기에 따라서 가장 최적화된 asset 을 내보여 주는게 RESS 입니다. 데스크탑에서는 B, C,D,E,F 를 불러다 보여주고, 아이패드에서는 B,C,D 만 골라서 불러오고, 스마트폰에서는 A,B 만 불러오는 식으로..

이때 가장큰 장점은 페이지의 로딩속도 입니다. 필요한것만 불러오니까 빨리 페이지가 로딩됩니다. 두번째로는 디자인적 측면에서 어떤 기기에서든 완벽한 모습을 보여줄 수 있다는 것 입니다.


반면 반응형은, A,B,C,D,E,F 이렇게 6가지 element 를 어떤 기기로 접근하든 상관없이 다 꺼내 보여 줍니다. 한마디로 접근기기에 따른 생각/ 선별적 선택을 못하는 것 입니다. 그리고 모바일에서는 A,B, 만 보여주면 되니까 나머지 4개는 display:none;

이게 얼마나 비효율적 입니까?

이게 기술적으로 들리실지 모르겠지만, 저는 컨테츠 측면에서 얘기를 하는 겁니다. 970px 넓이의 컨텐츠를 320px 넓이의 resolution 에서 보여주려면 결국 어떻게 해야 합니까?

아래로 내리고 내리고 내리고, 데스트탑 PC 에서 보여지는 컨텐츠를 모바일폰에서도 다 보여주려면 페이지가 한도 끝도 없이 길어 집니다. 그러니 어떻게 합니까? 필요없는 요소들은 display:none 할수 밖에 없죠.

이래서 순수한 반응형은 usability 에서도 꽝인겁니다.

RESS 는 어떤 한가지 방법만 존재하는 것이 아닙니다. 각 사이트의 상황에 맞추어서 RESS 기법 (선택과 집중) 을 사용하는 것 입니다.


요즘 구글을 비롯해 모든 사이트들이 이런 선별적 선택과 집중의 전략으로 바뀌고 있습니다. 순수반응형은 대형사이트들이 고려도 하지 않습니다.

http://mobile.smashingmagazine.com/2013/10/08/responsive-website-design-with-ress/

수치까지 제시하면서 왜 사이트들이 이 RESS 기법을 사용해야 하는가를 설명하고 있습니다.

마지막으로 caveat 이라고 하죠. 짚고 넘어가야 할 부분?

순수 반응형은 front-end 개발자/웹디자이너 입장에서 가장 쉽게/안전하게 느껴질 수 밖에 없습니다. 그냥 css 만 열심히 짜면 되는거니까요.


반면 이 RESS 기법을 부분적으로라도 사용하려면 내가 사용하고 있는 CMS 라던지 솔루션에 대한 정확한 이해가 있어야 합니다.

그러니까 제 경우는 워드프레스가 어떤식으로 어떤 element 들이 조합되어 페이지가 만들어지는가를 명확하게 알아야 했습니다.

지운아빠님도 그누보드에 대한 정확한 이해도가 있으셔야 사용이 가능한 기법입니다. 하지만 그누보드의 경우, index.php 에서 head.php 와 tail.php 가 불려와지는 정도로 매우 단순해서 이 문제로는 큰 골머리를 앓게 되시지는 않을 겁니다.

접근기기에 따라서,

if (아이패드나 모바일 폰일 경우)
{
include_once 'header_m.php';
}
else
{
include_once('header.php'); // 원래 대로
}
?>

이런 수준의 간단한 로직이 필요할 뿐 입니다.



제가 생각하는 그누보드는 대한민국을 대표하는 게시판 솔루션이라는 상징성이 있습니다.

저의 바람은 그누보드가 계속 발전하고, 그래서 대한민국에서 최소한 게시판 솔루션 하나 만큼은 그누보드가 쓰여지길 바라는 것 입니다.

////////////////////////////////////////

정말 정말 제가 하고 싶은 얘기는, RESS 기법이, 절대 순수한 반응형 기법보다 더 어렵지 않다는 것 입니다. 더 복잡하지도 않구요.

단지 약간의 server-side 코딩이 필요할 뿐 입니다.

결국 나중에 다 작업해놓고 보면, 오히려 시간이 절약되었음을 느끼시게 될 겁니다. 더구나 기존 사이트/ 기존 빌드가 존재하는 경우, 더욱더 그렇다는 것 입니다.

html 의 선택적 전송은 제 표현이 아니라 신현석 씨의 표현이었습니다. ㅎㅎ
오늘 RESS 를 알아보느라 읽은 글이 세개인데 순서대로,

http://www.lukew.com/ff/entry.asp?1392
http://www.creativebloq.com/responsive-web-design/getting-started-ress-5122956
http://hyeonseok.com/soojung/mobile/2011/10/11/677.html 이렇습니다.

저도 이미 RESS 쪽으로 사실 마음이 많이 기울고 있습니다.

그런데 기법의 어렵고 쉽고보다 URL 이 분산되지 않는다는 점을 빼면 (사실 이점이 가장 중요한 장점일 수 있지만) 모바일 버전을 새로 제작하는 것보다 RESS 가 나은게 무엇일까 하는 의문이 듭니다.
어쩌면 m.~ 도 cshop 님이 말한 RESS 와 유사한 형태이겠군요.

그런데 코드를 하나로 유지하려는 이유는 단순히 CSS 만으로 모든 걸 해결보려는 이유만은 아닙니다.
CSS 만으로 해결보는게 어쩌면 더 빡쎄고 힘들죠. 그마만큼 마크업과 스크립트 구조가 튼튼하면서 유동적이어야 하니까요. (쓰고 보니 이게 가능한 얘기야? 라는 생각이 들지만 ㅡㅡ;;)
다수의 코드는 유지/보수에 있어서 필연적 고충을 내포하게 되기 때문에 가능한 하나의 코드로 제작하려는 노력을 하고 있습니다.

근데 또 쓰고 보니 이래저래 반응형 들어가는 순간 유지/보수는 지옥길이겠구나란 생각이 드네요. 아놔

RESS 를 기술적으로만 치부한 것은 콘텐츠 전략이 확실히 선 다음에 선택 전송을 하든 전부 다 보여주든 결정하는게 낫지 않을까? 라는 생각 때문이었습니다.

조금 더 생각을 발전시켜 보니, SIR의 경우 navigation, 아웃로그인, 인덱스 정도가 반응형에서 주요 이슈가 될 것 같고, 이 부분은 RESS 로 작업을 해야 할 것 같네요.
나머지 게시판 콘텐츠들은 RESS 라기보다는 쿼리수 감소와 밀접할 것 같구요.

http://www.lukew.com/ff/entry.asp?1392

제일 처음 "선택적 전송" 의 개념을 RESS 라는 명사화 한 글이고....

http://www.creativebloq.com/responsive-web-design/getting-started-ress-5122956

이거는 Requires: PHP, Twitter Bootstrap, Modernizr, Swipe.js, WURFL 여기서 웃어야죠.

왜 WURFL 이 필요한데? ㅎㅎㅎ

저로서는 뭐 하나 가르쳐 주는 척 하면서 저 서비스 팔아먹을려고 작성한 악의적 블로그 글, 그냥 광고글 이라고 볼수 밖에.....


http://hyeonseok.com/soojung/mobile/2011/10/11/677.html

이게 한글로 정말 잘 정리 되어 있네요!!!

단지 "UAS 판별 방법" 에서 user-agent search? user-agent service? 어떤 약자를 쓰신건지 명확하게 밝히지 않았는데,

php 로 실수 없이 모든 UA 를 찾아내는 부분은 지운아빠님이 직접짜지 않으셔도 됩니다.


사용하기 쉬운 각종 UA detecting 해주는 php library 들이 존재하기 때문에....

https://github.com/serbanghita/Mobile-Detect/tags

아, 혹시 홍사장님이 다른 library 를 쓰면 안돼! 라고 하신다면, (잘 모르지만, 3rd party library 를 쓰지 말라고 하실수도...) 이런식으로


<?php
// 웹 UA 확인

$iphone = strpos($_SERVER['HTTP_USER_AGENT'],"iPhone");
$android = strpos($_SERVER['HTTP_USER_AGENT'],"Android");
$palmpre = strpos($_SERVER['HTTP_USER_AGENT'],"webOS");
$berry = strpos($_SERVER['HTTP_USER_AGENT'],"BlackBerry");
$ipod = strpos($_SERVER['HTTP_USER_AGENT'],"iPod");

if ($iphone || $android || $palmpre || $ipod || $berry == true)
{

include_once 'header_m.htm';
}
else
{
include_once 'header.htm';
}
?>

하셔도 99% 이상의 모바일 기기는 다 잡아내실 수 있으십니다.

구글로 찾아보시면 더 섬세한 script 들이 나와 있을 겁니다.


결국 server-side 쪽에서 해주는거는 UA 분별해서 UA 에 맞는 asset 들을 찾아 넣어주는 것 밖에 없는겁니다. That's it!!

/////////////////////////////////////////////

마지막으로 이부분을 꼭 생각해주셨으면 좋겠습니다. 지금 각종 resolution 의 모바일기기들이 쏟아져나오고 있습니다.

작년까지만 해도, 순수 반응형이라고 해봐야 3 break-point (3단계?), 로 대응하면 충분했지만, 앞으로는 더욱더 복잡해 집니다.

순수 반응형의 css 부분이 더욱더 복잡해질수 밖에 없습니다. 그래서 css 를 최대한 단순화 하기 위해서라도 서버쪽 도움을 받는게, 유리할거라 생각합니다.

네 예전 전진님 강좌글을 보더라도 break-point 가 점점 늘어날 것이라는 예상 때문에 경계치를 320 480 딱딱 짜르지 않는 경우도 있다는 내용이 있었죠.
사실 cshop님의 표현대로 순수 반응형이라는 게 앞서도 언급했지만 css 작성이나 마크업에서 더 골머리를 앓게 되는 건 사실인 것 같습니다.

토론에 자세히 참여해야 하는데, 막 나가봐야 해서.. 간단히 몇자 남깁니다.

- "지운아빠님 + 전진님 vs. 저, 이렇게 서로 몇년째 동의하지 못하는 부분이 RESS 에 관한 부분이죠."
아마도 이제는 모두들 다르게 생각하는 것은 아니지 않았나 생각합니다.
cshop2님은, "RESS 는 절충안 (hybrid) 이고 좋은 방식이라고 생각합니다." 로 기억하고 계신반면
저는 cshop님의 초기 입장이 "RESS는 엄격한 의미에서 반응형 웹이 아니다" 라고 기억하고 있기는 하지만..
어짜피 초기 생각들이고, 이제는 생각의 차이가 크게 있지는 않는것 같습니다.

- "UAS 판별 방법" 에서 UAS의 원단어는 아마도 user-agent string 일겁니다. 보통은 UA 또는 UA string이라고 하더군요.

- 아주 rough 한 서버측 vs 클라이언트측 반응형 웹 구현의 차이
우선은 서버측의 경우, '선택적 전송'을 하기에 전송량에서 서버측에 장점이 있겠죠.
하지만 그렇다고 기기마다 또는 기기크기마다 (거의) 통째로 다른 코드를 보내주는 것은 아니지 않나 생각됩니다.
현재까지 개인적으로는, "RESS기반 반응형 이미지"가 의미있는 활용이 아닐까 생각합니다.

그럼 다녀와서 저녁에 또 들리겠습니다. ^^