지금은 아무래도 과도기겠죠....
이거 저거 시험하는 시기..

G5 는 구글이 사용하는 RESS 방식의 절충적 반응형식을 따르고 있습니다.  (선별적 html 전송식 이라고도 합니다. )

sir.co.kr 사이트를 보시지 마시고 G5를 설치해 보시고 살펴보시길...

G5 의 모바일기기 대응은 가장 최신 트렌드에 맞춘 방식으로 만들어져 있습니다.

그누보드 사용자가 아닌 저도 이런 걸 알고 있는데. ㅎㅎㅎㅎ

구글이 하는 방식을 간략하게 설명드리자면,

https://news.google.com/

일단 2개의 레이아웃이 존재합니다. (그누보드 G5 처럼)

소스코드를 살펴보시면 알수 있으시겠지만, (크롬 -> F12)

그리고 데스크탑 레이아웃은 아이패드 등 테블렛 resolution 까지 반응을하다가 스마트 폰 resolution 까지 작아지면, 그때는 모바일 용 레이아웃이 "kick in" 합니다. 

이런 방식이 가장 최신의 방식입니다.

구글은 모바일 플랫폼을 상당히 중요하게 여깁니다.

그래서 구글의 PageSpeed 도 모바일에서의 페이지 속도와 데스트탑에서의 속도를 측정합니다.



속도가 느린 사이트들은 구글애드센스 단가까지 낮춰버립니다.  (최근에 이렇게 애드센스 규정이 바뀌었습니다.)

순수 RWD (반응형) 기법의 가장 큰 문제점은, 모바일 플랫폼에서 속도가 나지 않는다는 겁니다.

이래서 현재 그누보드 G5가 채택한 RESS 적 대응책이 가장 최신형/ 가장 권유되는, 기법인 것 입니다.

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

일반 사용자라면 모르셔도 되는 정보이지만, 개발자라면 사실 매우 중요한 정보라서......

RESS 는 hybrid method (절충적) 이라고도 하고, 한국말로는 "선별적 html 전송" 기법 이라고도  합니다.

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

(저는 이 단어를 지운아빠님이 만들어 내신줄 알았더니... 그럴리가 없잖아? ㅎㅎㅎ)

암튼, 다른점은 순수반응형은 두뇌가 없는거에요.  로직없이 그냥 css 의 미디어쿼리로 생각없이 반응하는 겁니다.

반면 RESS 는 로직이 있습니다. (G5 소스코드를 까보시면 나와요.) 그 로직대로 선별적 element 를 전송함으로 해서, 모바일에서 페이지 로딩 속도를 최적화 하는 방식인 겁니다.

php 를 모르신다니 이해가 되지 않으시겠지만, 그냥 아, 구글이 쓰는거구나, 아 리자님이 이런걸 만드셨구나, 아, 그냥 좋은거구나 이렇게 이해하시면 될 것 같습니다.

@HackYa
지난번 퍼블리셔톡에서 있었던 대화때 남길까 하다가 말았던 의견인데요..

HackYa님의 주장, 즉 반응형으로는 테블릿까지만 처리하고, 모바일 웹사이트는 (RESS로) 별도로 처리하는 것이
news.google.com 등도 사용하는, 최신형이며 가장 권유되는 기법이라는 것에 대한 제 생각을 남깁니다.

저는 두가지 측면에서 다른 의견을 가지고 있습니다.

일단은, 개발과 관리의 측면인데,
구글 정도 되다면 모바일 코드/사이트를 별도로 가져가는 것도 효과적인 해법이겠지만,
대부분의 중소형 사이트의 경우라면 두개의 사이트를 개발/관리하는 것이 더 많은 시간을 요할 수 있다고 생각합니다.
물론 한번 만들어 놓고 내용만 '자동'으로 업데이트 되는 형태라면 상관이 없을수도 있지만,
대부분의 경험을 보면 런칭 이후에도 어느정도 업데이트는 필요하고
또 정기적인 리뉴얼도 필요로 하기도 합니다.
(모바일퍼스트나 반응형을 종종 주장하는) 모바일 사이트와 데스크탑 사이트의 불일치같은 문제인것이죠.

예를 들어, G5로 새로운 사이트를 만들면서, 데스크탑 스킨을 만들었다면 비슷한 기능과 스타일의 모바일 스킨을 만들어야 하는 경우가 생길 수 있다는 것이죠.

두번째는, 성능 부분입니다.
반응형웹의 가장 큰 비판 중에 하나가, 2mb 짜리 반응형 사이트라고 대표되는, 너무 무겁다는 것일것 같습니다.
이런 현상을 반응형웹의 근본 문제로 봐야 할지, 아니면 미성숙한 기술적 한계로 봐야할지에 대한 시각차가 남기는 합니다만,
이런 문제를 해결하기 위한 대안들도 이미 있기에, 그리고 HackYa님이 지적하신대로 모바일에서의 속도문제가 꾸준히 고려되고 있기에 궁극적으로는 해결될 수 있다고 봅니다.
대표적인 반응형 사이트로 알려진 http://www.bostonglobe.com/ 의 경우,
기본으로 제공하는 모바일용 콘텐츠에서 시작해서,
화면이 커지면 더 많은 내용을 점진적으로 추가하는 형태로 구성하여
모바일에서의 전송량과 전송횟수를 최소한으로 유지합니다.
흔히 말하는 모바일 퍼스트+점진적 향상? 형태입니다.

---
HackYa님 말씀대로, 아직까지는 안정된 기술을 이용하여 두개의 사이트를 만드는 것이 나을 수도 있고
새로운 기술을 받아들여 미래친화적 (future-friendly) 인 사이트를 만들어 보는 것도 의의가 있을 수도 있습니다.

결론적으로는, HackYa님의 접근방법이나 제가 생각하는 방법 모두 장단점이 있기에
해당 프로젝트의 내용,예산,기간,목표 등을 고려해서 결정해야 할것 같습니다.

---
사족이지만, 제 주장/의견이 RESS 를 반대하다고 받아들이실까봐..
저는 반응형을 알리던 초기부터 RESS에 긍정적이었습니다. ^^

이부분에 대해서는 아무래도 리자님이 말씀해 주시는 것이 가장 좋겠지만, 일단 저는 이 discussion 을 그누보드에서만 국한해서 말하는 것 임을 밝힙니다.

그누보드의 G5 가 RESS 적 기법을 이용하고 있다고 해서, 게시판 query 가 두배로 늘어나는게 아니고, 게시판 갯수가 2개로 늘어나는게 아닙니다.

다시말해 리자님께서 RESS 의 로직을 다 많들어 넣어두셨기 때문에, 그누보드 G5를 이용해서 사이트를 구축하는 개발자는 결국 css (미디어쿼리포함) 만 작성해주면 되는 것 입니다.

단언컨데, 제한적인 반응만을 하는 그러니까 데스크탑 resolution - 테블렛 resolution, 이 범위내에서만 (1000 px ~ 700 px 라고 합시다.) 반응을 해주는 레이아웃 하나,

그리고 320 px 에서 부터 각종 다른 모바일 기기들 (테블렛 보다 resolution 이 작은) 에 제한적으로 반응하는, (max 가 600px 라고 하죠.) 레이아웃 하나,

이렇게 두개의 레이아웃의 css 를 짜는게,

하나의, 1000px 부터 320px 까지 반응하는, css 를 짜는 것 보다, 시간이나 기술적으로 훨씬 더 쉽다는 것 입니다.

그리고 말씀하신 http://www.bostonglobe.com/

성능적인 면에서 매우 바람직 하지 않습니다.

https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fwww.bostonglobe.com%2F

구글뉴스의 script 양과, 보스턴글로브의 script 양은 비교도 안되죠.

구글 뉴스의 pagespeed 결과 입니다.

https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fnews.google.com%2F

이래서 순수 반응형은 비용면이나 성능면에서 좋지않다는걸 얘기하는 겁니다.

그리고 사실 이렇게 왈가왈부 하는 것도 사실 아무런 의미가 없습니다.

리자님이 벌써 RESS 로 가시기로 결정하시고 G5를 내 놓으셨는데, 이런 토론자체가 아무런 의미가 없지 않겠습니까?

게시판이 쿼리, 갯수가 두배로 늘어나지는 않지만, 코드를 두개로 (부분적으로라도) 분리해놓는 것은 유지/개발면에서 마이너스 요소인 것은 맞습니다.

G5를 놓고 보자면,
코드를 더 들어다 보셨는지 모르겠지만
모바일 기기의 경우 모바일 <!--사이트로 이동하도록 되어 있습니다.--> 스킨을 사용하도록 되어 있습니다.
그러니 css 만 별도로 짜는 것과는 질적으로 다른 수준의 개발과 관리가 필요하죠.
리자님도 '(RESS를 이용한) 반응형웹'을 목표로 하셨다기 보다는
모바일 사이트를 같이 포함하고 자동으로 리디릭션 하는 기능을 넣으셨다고 보는 것이 더 적합할 것 같고요..

news.google.com과 일반적인 신문사 웹사이트를 직접 비교하기는 쉽지 않을것 같습니다.
게다가 나쁜 점수를 받은 대부분의 항목이, 반응형웹 개발관련이라기 보다는 웹 서버나 헤더 설정 등입니다.
물론 이런 부분이 굉장히 중요하기는 하지만, 반응형웹과 상관없이 언제든지 고려되어야 할 부분이죠.

리자님만 세

지운아빠님..오타났네요..

리자님만 세 -> 리자님만 새

아이고 오타가 난 줄도 모르고 있었네요. 감사합니다.

리자 님만 세

아하..저도오타였군요..

리자 님만 새

@숨숨이님,

그러니까 제가 제일 처음에 "hybrid" 라고 써놨잖아요.  반응형인데 절충형이라고.... -......-;;;;;

단언컨데 반응형으로 안갑니다(단언은 무슨 개인적인 생각^^).
일종의 유행 사조 같은 걸 겁니다. 자바의 지배력에 미치지 못하고 플래시 정도의 영향력이 있을 뿐일 겁니다.
이유는 폰이나 타블릿의 해상도 증가로 인한 선명성에 있지 않는가 싶습니다.

반응형이라는 과도기를 거쳐서 모바일로 수렴이 되든지 PC=모바일로 가게 될 것 같습니다.
제 생각으로는 모바일로 틀지 않을까 싶습니다.
지금은 모바일로 제공할 수 있는 서비스가 한정이 되어서 PC가 여전하게 위력을 발휘하지만 PC가 산업용으로 축소되고 모바일(타블릿이 되겠지요)로 모든 것을 할 수 있는 시간이 올겁니다.

바로 시간.
구글의 번역이 날로 좋아지는 것처럼 데이터 베이스와 필드 테스트를 거치면 모바일만으로 대부분의 일을 할 수 있는 시간이 오지 않을까요?

그래도 개발자들은 계속 PC 를 쓰지 않을까요? 

뭐 아주 오랜시간후에는 일반인들은 데스트탑을 쓰지 않게 될지도 모르겠지만, 너무 먼 미래를 생각하고 계신 건 아닌가 싶습니다.

제 생각이 틀릴수도 있지만, 저는 당분간은 그래도 계속 데스탑이 이용되지 않을까 하는 생각입니다.

PC는 살아남겠죠. 단지 지금처럼 만능은 아니겠죠. 아직 산업용으로 386, 486 CPU도 쓰이니까.

@숨숨이님,

댓글 중에 궁금한 점이 있는데요..
bootstrap 에 RESS 가 적용되었나요?
서버쪽 코드가 필요할텐데, bootstrap은 클라이언트쪽 코드만 있지 않나요? ^^;

"bootstrap 에 RESS 가 적용되었나요? "  그렇다네요. ㅎㅎㅎㅎ  뭔 말을 더 하겠습니까?

HackYa님은 영어로 쓰셔야 할것 같아요. ^^;
지난번에 남기신 영어로 쓴 댓글을 보니까, 그렇게 시니컬 하지도 않으시던데..
한글로 쓰시면 항상 .. 너무 차가워요.. ^^

저는 정말 몰라서 여쭤본것입니다. ^^

아. less와 혼동하셨나 보네요. ^^;

이보세요!!!!

정말 보자 보자 하니까, 이게 무슨 장난도 아니고.

RESS 라는 css pre-processor 는 없습니다.  LESS 는 있어도 RESS 라는 css pre-processor 는 없습니다.

그리고 css pre-processor 하고 지금 얘기하는 RESS (Responsive Design Server Side) 와 무슨 상관입니까?