일단 이유를 막론하고 정보
일단 이유를 막론하고
본문
저로 인해 기분 상하신 분들께 죄송합니다.
앞으로는 개발에 관련된 글에는 댓글도 달지 말고, 가급적이면 눈팅만 하고 지내겠습니다. 정말 저로서는 기가막힐따름입니다.
숨숨이 님의 글에
댓글을 단건 단지 G5를 설치해 보지도 않고, 그누보드가 반응형도 아니고, 이건 아닌것 같다, 이런식의 말투로 느껴졌기때문에 기분이 나빠져서 G5 는 그렇지 않다는 걸 말하려 했던 겁니다.
G5를 설치해 봤다면 절대 그렇게 말하지 않았을텐데, sir.co.kr 공홈만 살펴보시고 그렇게 말하시는 것 같았기 때문입니다.
왜 그누보드 사용자도 아닌데 기분이 나쁘냐구요? 그누보드는 대한민국을 대표하는 상징성 있는 게시판 솔루션인데, 더구나 리자님이 얼마나 고심을 하시며 G5를 만드셨는지 G5의 코드들을 보며 그 정성이 느껴졌는데, 누가 G5 대해 조금이라도 나쁘게 말하는 것이 싫었습니다.
왜 그누보드 사용자도 아닌데 기분이 나쁘냐구요? 그누보드는 대한민국을 대표하는 상징성 있는 게시판 솔루션인데, 더구나 리자님이 얼마나 고심을 하시며 G5를 만드셨는지 G5의 코드들을 보며 그 정성이 느껴졌는데, 누가 G5 대해 조금이라도 나쁘게 말하는 것이 싫었습니다.
(더구나 숨숨이 님은 G5 코드도 한번 살펴보지 않고 그렇게 말을 하고 계신거였고...)
그리고 나중에 사과하셨고, RESS 하고 LESS 하고 착각을 하셔서 (사실 어떻게 서버사이드 기능을 이용한 반응형 웹구축 기법과, css pre-processor 와 착각을 할 수 있는지, 지금도 이해가 되지 않습니다. 아무런 연관도 없는 것 들 인데요.)
그런 얘기를 하셨다고 하지만, RESS 하고 LESS 를 착각할 정도의 숨숨이 님이 저를 바로잡아 줘야 겠다고 하시니, 기가막혀서 더 이상 대화도 하기 싫었습니다.
아무튼 다른 분들께 불쾌감을 드릴려고 한게 아닙니다.
////////////////////////////////////////////////////////////////////////////////
이런거 다 떠나서 RWD 와 RESS 와만 놓고 얘기하고 싶습니다.
올해 봄쯤 RWD 와 RESS 를 비교하는 글을 한글로 쓰려고 하다 시간이 없어 그냥 영문으로 방치된 자료글 입니다.
로딩시간과 HTTP request 숫자를 봤을때 RESS 가 월등히 유리하다는 것을 알수 있는 자료 입니다. 각기 다른 사이트들을 비교한건데 객관성이 떨어지는 비교 아니냐? 라고 하실 분이 계실 것 같아서, 제 홈피를 RWD 인 경우와, RESS 인 경우를 비교해 드리겠습니다.
RWD
RESS
단지 모바일 상 RWD 를 RESS 로 바꾸었을 뿐, 동일한 조건입니다.
실제 확인해 보시고 싶으시다면, 제 영문페이지 (현재 RWD 상태) 와 한글 페이지를 비교해 보셔도 됩니다.
https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fhackya.com%2Fus
로딩시간과 HTTP request 숫자를 봤을때 RESS 가 월등히 유리하다는 것을 알수 있는 자료 입니다. 각기 다른 사이트들을 비교한건데 객관성이 떨어지는 비교 아니냐? 라고 하실 분이 계실 것 같아서, 제 홈피를 RWD 인 경우와, RESS 인 경우를 비교해 드리겠습니다.
RWD
RESS
단지 모바일 상 RWD 를 RESS 로 바꾸었을 뿐, 동일한 조건입니다.
실제 확인해 보시고 싶으시다면, 제 영문페이지 (현재 RWD 상태) 와 한글 페이지를 비교해 보셔도 됩니다.
https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fhackya.com%2Fus
엄청난 속도의 차이가 있으심을 알게 되실 것 입니다. 더구나 RESS 가 적용되어 있는 한글 페이지는 슬라이더까지 장착되어 있습니다.
//////////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////
말로 어느쪽이 더 우월하다 계속 논의를 하는 것 보다, 실례를 한번 확인해 보는게 더 확실하지 않겠습니까?
워드프레스는 그누보드와 front-end 쪽 관점에서 볼때 매우 흡사합니다. XE 와 드루팔이 모듈개념이라면, 그누보드와 워드프레스는 테마/스킨 으로 사이트가 구축되는 개념입니다. 그리고 저는 리자님이 옳은 선택을 하셨다고 확신하는 것 뿐입니다.
리자님께서 정말 많은 자료들을 살펴보셨을거고, 현재 그누보드 환경에 맞는 가장 적합한 형태로 새로운 G5를 출시하신거라고 저는 생각하고, 앞으로 10년동안은 대한민국에서 최고의 게시판 솔루션으로 자리할 거라 확신합니다.
그런데 벌써부터, 시도해보지도 않고, 새로운 G5가 개발하기 불편하다니 등의 소리가 나오고, 이 RESS 기법이 적용이 된 core 단의 부분을 주석처리 해서 쓰고 있습니다. 라는 등의 글이 오늘 올라오니 제 심기가 몹시 불편한 것 입니다.
RESS 는 RWD 의 과도기에 임시방편이 아니라, 미래지향적 방식인겁니다. 객관적 data 를 살펴보시니 어떻습니까? 제 말이 틀렸습니까?
워드프레스는 그누보드와 front-end 쪽 관점에서 볼때 매우 흡사합니다. XE 와 드루팔이 모듈개념이라면, 그누보드와 워드프레스는 테마/스킨 으로 사이트가 구축되는 개념입니다. 그리고 저는 리자님이 옳은 선택을 하셨다고 확신하는 것 뿐입니다.
리자님께서 정말 많은 자료들을 살펴보셨을거고, 현재 그누보드 환경에 맞는 가장 적합한 형태로 새로운 G5를 출시하신거라고 저는 생각하고, 앞으로 10년동안은 대한민국에서 최고의 게시판 솔루션으로 자리할 거라 확신합니다.
그런데 벌써부터, 시도해보지도 않고, 새로운 G5가 개발하기 불편하다니 등의 소리가 나오고, 이 RESS 기법이 적용이 된 core 단의 부분을 주석처리 해서 쓰고 있습니다. 라는 등의 글이 오늘 올라오니 제 심기가 몹시 불편한 것 입니다.
RESS 는 RWD 의 과도기에 임시방편이 아니라, 미래지향적 방식인겁니다. 객관적 data 를 살펴보시니 어떻습니까? 제 말이 틀렸습니까?
마지막으로, THIRD 님의 이 도표,
휴.. 뭐라고 말을 해야 할지 모르겠습니다.
RESS 란 어떤 정해진 방식이 있는 것이 아닙니다. 전진님께서 이부분을 확인시켜주실 수 있겠지만, image 나 css, 자스를 optimize 하는 것도 RESS 에 포함되는 것 입니다. 단순하게 RESS, 이 단어의 뜻만 한글로 번역해서 읽어봐도 이해할 수 있는 부분입니다.
Smashing Magazine 에서 RESS 의 개념도 몰라 이런글을 올리겠습니까?
Smashing Magazine 에서 RESS 의 개념도 몰라 이런글을 올리겠습니까?
제가 상대방을 무시하고 말을 함부로 하는게 아니라, 서로 논의/논쟁을 하려면 최소한 개념은 명확하게 갖고 해야 하는 것 아닐까요? 무지한 상대방에게 제가 어떻게 말을 해야 할까요? "개념이 부족하시니 가서 개념부터 탑재하고 오세요." - 이렇게 얘기해야 할까요?
저 나름대로 최대한 말을 조심해서 하려고 한겁니다.
저 나름대로 최대한 말을 조심해서 하려고 한겁니다.
제가 언제 지운아빠님이나 전진님께 말을 함부로 하던가요? 지운아빠님이나 전진님과는 견해차이가 있는거지, 서로 개념을 놓고 왈가왈부 할 일이 없습니다.
아무튼 다른분들이 기분나쁘셨다면 죄송하지만, 저 역시 감정이 상하기는 마찬가지 였습니다.
index.html 에서는 왜 <?php include 가 안되나요? 라고 하는 사람에게 올바른 방법을 말하니, "그건 당신이 잘못알고 있는거야" 라는 답이 돌아온다면 어떤 기분이겠습니까?
index.html 에서는 왜 <?php include 가 안되나요? 라고 하는 사람에게 올바른 방법을 말하니, "그건 당신이 잘못알고 있는거야" 라는 답이 돌아온다면 어떤 기분이겠습니까?
기분이 나쁘거나 어이가 없겠죠?
네. 제가 딱 그런 기분입니다.
앞으로는 개발에 관련된 글에는 댓글도 달지 말고, 가급적이면 눈팅만 하고 지내겠습니다. 정말 저로서는 기가막힐따름입니다.
추천
0
0
댓글 12개
절 언급하셨어 댓글 답니다.
------------------------------
마지막으로, THIRD 님의 이 도표,
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=969997&page=2
휴.. 뭐라고 말을 해야 할지 모르겠습니다.
RESS 란 어떤 정해진 방식이 있는 것이 아닙니다. 전진님께서 이부분을 확인시켜주실 수 있겠지만, image 나 css, 자스를 optimize 하는 것도 RESS 에 포함되는 것 입니다. 단순하게 RESS, 이 단어의 뜻만 한글로 번역해서 읽어봐도 이해할 수 있는 부분입니다.
------------------------------
=> HackYa님이 말씀하시는 http://hackya.com/us/rwd-vs-ress/ 에서 언급하시는것처럼 RWD 대 RESS(대결구도) 로 보시는 관점과 저의 RWD + RESS(서버처리방법을 보기때문에 저는 포함으로 봅니다.) 로 보는 관점의 차이 인듯합니다.
RESS를 제 주관적인 입장에서 번역하자면 반응형 웹디자인을 위한 서버 처리 기법(구현방법 등)이라고 해석할수 있겠네요
optimize 기술 자체를 RESS를 보기에는 어폐가 있는듯합니다.
------------------------------
Smashing Magazine 에서 RESS 의 개념도 몰라 이런글을 올리겠습니까?
http://mobile.smashingmagazine.com/2013/10/08/responsive-website-design-with-ress/
제가 상대방을 무시하고 말을 함부로 하는게 아니라, 서로 논의/논쟁을 하려면 최소한 개념은 명확하게 갖고 해야 하는 것 아닐까요? 무지한 상대방에게 제가 어떻게 말을 해야 할까요? "개념이 부족하시니 가서 개념부터 탑재하고 오세요." - 이렇게 얘기해야 할까요?
------------------------------
=> 다른글에서도 계속 언급하는 내용인데요
제가 계속 토론을 같이 하던 사람도 아니고 그렇다고 님께서 작성하신 모든 글을 읽어보는것도 무리인 관계로 이해나 의견 차이가 있는것 같아 당사자가 이해하고 있는 정의(개념)을 제시좀 해달라는게 잘못인것처럼 말하시네요.
그리고 Smashing Magazine 의 내용은 가벼운 반응형 웹사이트 디자인(RWD)을 위한 서버처리기법(RESS)정도로 이해되는데요
반응형웹(RWD)가 큰 숲이고 RESS는 나무와 같다는 겁니다.
optimize, Minify, Compressor 기술은 RWD가 나오기전에도 존재했고 RESS 구현의 일부라는겁니다.
종합적으로 마무리하면 RWD와 RESS는 근본적으로 비교 대상이 아니라는 겁니다.
순수 부트스트랩과 같은 미디어쿼리 기반의 RWD 와 RESS를 혼합한 RWD는 비교 대상이 될수 있지만 숲과 나무가 어떻게 비교 대상이 될까요?
------------------------------
마지막으로, THIRD 님의 이 도표,
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=969997&page=2
휴.. 뭐라고 말을 해야 할지 모르겠습니다.
RESS 란 어떤 정해진 방식이 있는 것이 아닙니다. 전진님께서 이부분을 확인시켜주실 수 있겠지만, image 나 css, 자스를 optimize 하는 것도 RESS 에 포함되는 것 입니다. 단순하게 RESS, 이 단어의 뜻만 한글로 번역해서 읽어봐도 이해할 수 있는 부분입니다.
------------------------------
=> HackYa님이 말씀하시는 http://hackya.com/us/rwd-vs-ress/ 에서 언급하시는것처럼 RWD 대 RESS(대결구도) 로 보시는 관점과 저의 RWD + RESS(서버처리방법을 보기때문에 저는 포함으로 봅니다.) 로 보는 관점의 차이 인듯합니다.
RESS를 제 주관적인 입장에서 번역하자면 반응형 웹디자인을 위한 서버 처리 기법(구현방법 등)이라고 해석할수 있겠네요
optimize 기술 자체를 RESS를 보기에는 어폐가 있는듯합니다.
------------------------------
Smashing Magazine 에서 RESS 의 개념도 몰라 이런글을 올리겠습니까?
http://mobile.smashingmagazine.com/2013/10/08/responsive-website-design-with-ress/
제가 상대방을 무시하고 말을 함부로 하는게 아니라, 서로 논의/논쟁을 하려면 최소한 개념은 명확하게 갖고 해야 하는 것 아닐까요? 무지한 상대방에게 제가 어떻게 말을 해야 할까요? "개념이 부족하시니 가서 개념부터 탑재하고 오세요." - 이렇게 얘기해야 할까요?
------------------------------
=> 다른글에서도 계속 언급하는 내용인데요
제가 계속 토론을 같이 하던 사람도 아니고 그렇다고 님께서 작성하신 모든 글을 읽어보는것도 무리인 관계로 이해나 의견 차이가 있는것 같아 당사자가 이해하고 있는 정의(개념)을 제시좀 해달라는게 잘못인것처럼 말하시네요.
그리고 Smashing Magazine 의 내용은 가벼운 반응형 웹사이트 디자인(RWD)을 위한 서버처리기법(RESS)정도로 이해되는데요
반응형웹(RWD)가 큰 숲이고 RESS는 나무와 같다는 겁니다.
optimize, Minify, Compressor 기술은 RWD가 나오기전에도 존재했고 RESS 구현의 일부라는겁니다.
종합적으로 마무리하면 RWD와 RESS는 근본적으로 비교 대상이 아니라는 겁니다.
순수 부트스트랩과 같은 미디어쿼리 기반의 RWD 와 RESS를 혼합한 RWD는 비교 대상이 될수 있지만 숲과 나무가 어떻게 비교 대상이 될까요?
"순수 부트스트랩과 같은 미디어쿼리 기반의 RWD 와 RESS를 혼합한 RWD는 비교 대상이 될수 있지만 숲과 나무가 어떻게 비교 대상이 될까요?" - 네 맞는 말씀이십니다.
자세히 숨숨이님 원 글에 대한 논란을 읽어봤더니 그 토론은 전진님 글에서 끝났어야 맞겠더군요.
-----------------------------------------------------------------
@HackYa
지난번 퍼블리셔톡에서 있었던 대화때 남길까 하다가 말았던 의견인데요..
HackYa님의 주장, 즉 반응형으로는 테블릿까지만 처리하고, 모바일 웹사이트는 (RESS로) 별도로 처리하는 것이
news.google.com 등도 사용하는, 최신형이며 가장 권유되는 기법이라는 것에 대한 제 생각을 남깁니다.
저는 두가지 측면에서 다른 의견을 가지고 있습니다.
일단은, 개발과 관리의 측면인데,
구글 정도 되다면 모바일 코드/사이트를 별도로 가져가는 것도 효과적인 해법이겠지만,
대부분의 중소형 사이트의 경우라면 두개의 사이트를 개발/관리하는 것이 더 많은 시간을 요할 수 있다고 생각합니다.
물론 한번 만들어 놓고 내용만 '자동'으로 업데이트 되는 형태라면 상관이 없을수도 있지만,
대부분의 경험을 보면 런칭 이후에도 어느정도 업데이트는 필요하고
또 정기적인 리뉴얼도 필요로 하기도 합니다.
(모바일퍼스트나 반응형을 종종 주장하는) 모바일 사이트와 데스크탑 사이트의 불일치같은 문제인것이죠.
예를 들어, G5로 새로운 사이트를 만들면서, 데스크탑 스킨을 만들었다면 비슷한 기능과 스타일의 모바일 스킨을 만들어야 하는 경우가 생길 수 있다는 것이죠.
두번째는, 성능 부분입니다.
반응형웹의 가장 큰 비판 중에 하나가, 2mb 짜리 반응형 사이트라고 대표되는, 너무 무겁다는 것일것 같습니다.
이런 현상을 반응형웹의 근본 문제로 봐야 할지, 아니면 미성숙한 기술적 한계로 봐야할지에 대한 시각차가 남기는 합니다만,
이런 문제를 해결하기 위한 대안들도 이미 있기에, 그리고 HackYa님이 지적하신대로 모바일에서의 속도문제가 꾸준히 고려되고 있기에 궁극적으로는 해결될 수 있다고 봅니다.
대표적인 반응형 사이트로 알려진 http://www.bostonglobe.com/ 의 경우,
기본으로 제공하는 모바일용 콘텐츠에서 시작해서,
화면이 커지면 더 많은 내용을 점진적으로 추가하는 형태로 구성하여
모바일에서의 전송량과 전송횟수를 최소한으로 유지합니다.
흔히 말하는 모바일 퍼스트+점진적 향상? 형태입니다.
---
HackYa님 말씀대로, 아직까지는 안정된 기술을 이용하여 두개의 사이트를 만드는 것이 나을 수도 있고
새로운 기술을 받아들여 미래친화적 (future-friendly) 인 사이트를 만들어 보는 것도 의의가 있을 수도 있습니다.
결론적으로는, HackYa님의 접근방법이나 제가 생각하는 방법 모두 장단점이 있기에
해당 프로젝트의 내용,예산,기간,목표 등을 고려해서 결정해야 할것 같습니다.
---
사족이지만, 제 주장/의견이 RESS 를 반대하다고 받아들이실까봐..
저는 반응형을 알리던 초기부터 RESS에 긍정적이었습니다. ^^
------------------------------------------------------------------------------
핵이야님? 아니 고객이 그렇게 만들어 달라는데 제가 궂이 차띠고 포띠고 할 필요가 있을까요?
그냥 주석처리하고 통일 시켜주는 겁니다? 간단하게 단일 스킨으로 관리하게 좋게 해달라는 요구에 제가
거기에 구글을 말하고 RESS를 말해야 하나요? 그것도 하루 방문자 100명도 채 안되는 그런 사이트에?
대체 관련 문서를 어디서 털어 보시고 그렇게 확신하고 사는지 그 속을 모르겠군요?
RESS도 그렇죠? 그게 무슨 이미 정해진 수순이고 최고의 지향점인양 설명하는데 웹문서 한번 같이
털어 볼까요? 지금 시점에서는 그 누구도 자신하기 힘든 상황이고 개발자에 따라 또는 웹사이트의
상황에 따라 선택적으로 또는 변칙적으로 이용하고 있는 겁니다. 기술은 이렇게 발전하고 자연스러운
것이지 양쪽 모두가 장점과 단점을 가지고 있는데 어느 한쪽의 유리한 측면만을 강조해 최고다라고
단정짓는 그 자체가 오류죠? 구글은 RESS로 가야할 분명한 이유가 있었고 같은 선상에서 네이버나
야후도 RWD로 가지 말아야 할 분명한 이유가 있었겁니다. 결국 트래픽이고 RWD는 아주 큰 리스크를
떠 안아야할 문제였기에 가급적 피하고 RESS로 발전해 나가고 있는 것이죠. 이것이 미래지향적이라면
그리고 필연적인 미래가 될 수도 있습니다만 이게 전부는 아니라는 것이고 아직 정착이 된 기술 패턴이
아니라는 겁니다.
그리고 G5이전 "gb4s"가 기획될 당시 반응형으로 가느냐 모바일페이지로 가느냐에 대한 설문을
했던 기억이 납니다. 불과 1년 전이지만 반응형은 2, 3년 길게는 5년 이상은 지나야 정착이 될 거란
생각들이 지배적이어서 별도의 모바일 페이지를 만들어 사용하다가 이후 반응형을 모색해야 되지
않겠냐는 설문 결과였고 짐작이지만 리자님이나 지운아버님이나 RESS에 대한 생각보다는
설문 결과를 적용하다보니 얼떨결에 RESS방식을 채택했던 거죠?
글을 더 써봐야 짜증스럽기만 하겠고 이만 줄입니다만 좀 넓게 보시고 논란의 여지가 있는 글에
대한 토론에는 상대방의 의견도 수용하는 자세도 가져보세요.
-----------------------------------------------------------------
@HackYa
지난번 퍼블리셔톡에서 있었던 대화때 남길까 하다가 말았던 의견인데요..
HackYa님의 주장, 즉 반응형으로는 테블릿까지만 처리하고, 모바일 웹사이트는 (RESS로) 별도로 처리하는 것이
news.google.com 등도 사용하는, 최신형이며 가장 권유되는 기법이라는 것에 대한 제 생각을 남깁니다.
저는 두가지 측면에서 다른 의견을 가지고 있습니다.
일단은, 개발과 관리의 측면인데,
구글 정도 되다면 모바일 코드/사이트를 별도로 가져가는 것도 효과적인 해법이겠지만,
대부분의 중소형 사이트의 경우라면 두개의 사이트를 개발/관리하는 것이 더 많은 시간을 요할 수 있다고 생각합니다.
물론 한번 만들어 놓고 내용만 '자동'으로 업데이트 되는 형태라면 상관이 없을수도 있지만,
대부분의 경험을 보면 런칭 이후에도 어느정도 업데이트는 필요하고
또 정기적인 리뉴얼도 필요로 하기도 합니다.
(모바일퍼스트나 반응형을 종종 주장하는) 모바일 사이트와 데스크탑 사이트의 불일치같은 문제인것이죠.
예를 들어, G5로 새로운 사이트를 만들면서, 데스크탑 스킨을 만들었다면 비슷한 기능과 스타일의 모바일 스킨을 만들어야 하는 경우가 생길 수 있다는 것이죠.
두번째는, 성능 부분입니다.
반응형웹의 가장 큰 비판 중에 하나가, 2mb 짜리 반응형 사이트라고 대표되는, 너무 무겁다는 것일것 같습니다.
이런 현상을 반응형웹의 근본 문제로 봐야 할지, 아니면 미성숙한 기술적 한계로 봐야할지에 대한 시각차가 남기는 합니다만,
이런 문제를 해결하기 위한 대안들도 이미 있기에, 그리고 HackYa님이 지적하신대로 모바일에서의 속도문제가 꾸준히 고려되고 있기에 궁극적으로는 해결될 수 있다고 봅니다.
대표적인 반응형 사이트로 알려진 http://www.bostonglobe.com/ 의 경우,
기본으로 제공하는 모바일용 콘텐츠에서 시작해서,
화면이 커지면 더 많은 내용을 점진적으로 추가하는 형태로 구성하여
모바일에서의 전송량과 전송횟수를 최소한으로 유지합니다.
흔히 말하는 모바일 퍼스트+점진적 향상? 형태입니다.
---
HackYa님 말씀대로, 아직까지는 안정된 기술을 이용하여 두개의 사이트를 만드는 것이 나을 수도 있고
새로운 기술을 받아들여 미래친화적 (future-friendly) 인 사이트를 만들어 보는 것도 의의가 있을 수도 있습니다.
결론적으로는, HackYa님의 접근방법이나 제가 생각하는 방법 모두 장단점이 있기에
해당 프로젝트의 내용,예산,기간,목표 등을 고려해서 결정해야 할것 같습니다.
---
사족이지만, 제 주장/의견이 RESS 를 반대하다고 받아들이실까봐..
저는 반응형을 알리던 초기부터 RESS에 긍정적이었습니다. ^^
------------------------------------------------------------------------------
핵이야님? 아니 고객이 그렇게 만들어 달라는데 제가 궂이 차띠고 포띠고 할 필요가 있을까요?
그냥 주석처리하고 통일 시켜주는 겁니다? 간단하게 단일 스킨으로 관리하게 좋게 해달라는 요구에 제가
거기에 구글을 말하고 RESS를 말해야 하나요? 그것도 하루 방문자 100명도 채 안되는 그런 사이트에?
대체 관련 문서를 어디서 털어 보시고 그렇게 확신하고 사는지 그 속을 모르겠군요?
RESS도 그렇죠? 그게 무슨 이미 정해진 수순이고 최고의 지향점인양 설명하는데 웹문서 한번 같이
털어 볼까요? 지금 시점에서는 그 누구도 자신하기 힘든 상황이고 개발자에 따라 또는 웹사이트의
상황에 따라 선택적으로 또는 변칙적으로 이용하고 있는 겁니다. 기술은 이렇게 발전하고 자연스러운
것이지 양쪽 모두가 장점과 단점을 가지고 있는데 어느 한쪽의 유리한 측면만을 강조해 최고다라고
단정짓는 그 자체가 오류죠? 구글은 RESS로 가야할 분명한 이유가 있었고 같은 선상에서 네이버나
야후도 RWD로 가지 말아야 할 분명한 이유가 있었겁니다. 결국 트래픽이고 RWD는 아주 큰 리스크를
떠 안아야할 문제였기에 가급적 피하고 RESS로 발전해 나가고 있는 것이죠. 이것이 미래지향적이라면
그리고 필연적인 미래가 될 수도 있습니다만 이게 전부는 아니라는 것이고 아직 정착이 된 기술 패턴이
아니라는 겁니다.
그리고 G5이전 "gb4s"가 기획될 당시 반응형으로 가느냐 모바일페이지로 가느냐에 대한 설문을
했던 기억이 납니다. 불과 1년 전이지만 반응형은 2, 3년 길게는 5년 이상은 지나야 정착이 될 거란
생각들이 지배적이어서 별도의 모바일 페이지를 만들어 사용하다가 이후 반응형을 모색해야 되지
않겠냐는 설문 결과였고 짐작이지만 리자님이나 지운아버님이나 RESS에 대한 생각보다는
설문 결과를 적용하다보니 얼떨결에 RESS방식을 채택했던 거죠?
글을 더 써봐야 짜증스럽기만 하겠고 이만 줄입니다만 좀 넓게 보시고 논란의 여지가 있는 글에
대한 토론에는 상대방의 의견도 수용하는 자세도 가져보세요.
저도 문외한인데요~ 글에 관심이 가서 주욱 읽다보니, 그런생각이 드네요.
Hackya님 말씀은 전적으로 현재 나와있는 기술에 가장 적절한 방식을 택하는... 글이라 보구요.
다른분 말씀은 반응형과 그렇지 않은형... 두가지의 관점에서 보고 말씀하신거같애요.
이미 Hackya 님은 모든부분을 초반에 언급하시고 제대로 작성을 하셨지만,
생각보다 많은 사람들이 이런 글들을 이해 못합니다...
그 이해 범위에서 판단하기는... 그렇겠죠 ^^;
전 사실 개발자 커뮤니티도 몇년동안 눈팅만 하다가 이제 좀 들여다보고 글을 작성하고있습니다만,
스킨이나 질문답변 게시판을 보다보면 황당하리만큼 어이없는? 질문들도 올라오고 하잖아요?
그게 오프라인 세상에선 훨씬더 많이 느낄수밖에 없다는것이...
자기 분야는 정말 프로인데도 다른분야는 전혀 모르고 받아드리려 하지 않는사람과,
그냥 모든걸 겉핧기 식으로 받아드리는사람... 전 아마 마지막일지도 모르겠습니다. ㅋ
무슨말인고하니~ 걍 넓은 아량으로 넘어가주세요~
아실만한 분들은 모두 다 이미 알고계실듯... 그리고 제일 중요한 정신건강에 좋지않습니다! ㅋㄷ
전 덕분에 좋은 글 많이 읽고 갑니다.
선택적html전송이란 단어조차 모르고 해당부분을 코딩하고있던... 1人입니다...~('.'~)
Hackya님 말씀은 전적으로 현재 나와있는 기술에 가장 적절한 방식을 택하는... 글이라 보구요.
다른분 말씀은 반응형과 그렇지 않은형... 두가지의 관점에서 보고 말씀하신거같애요.
이미 Hackya 님은 모든부분을 초반에 언급하시고 제대로 작성을 하셨지만,
생각보다 많은 사람들이 이런 글들을 이해 못합니다...
그 이해 범위에서 판단하기는... 그렇겠죠 ^^;
전 사실 개발자 커뮤니티도 몇년동안 눈팅만 하다가 이제 좀 들여다보고 글을 작성하고있습니다만,
스킨이나 질문답변 게시판을 보다보면 황당하리만큼 어이없는? 질문들도 올라오고 하잖아요?
그게 오프라인 세상에선 훨씬더 많이 느낄수밖에 없다는것이...
자기 분야는 정말 프로인데도 다른분야는 전혀 모르고 받아드리려 하지 않는사람과,
그냥 모든걸 겉핧기 식으로 받아드리는사람... 전 아마 마지막일지도 모르겠습니다. ㅋ
무슨말인고하니~ 걍 넓은 아량으로 넘어가주세요~
아실만한 분들은 모두 다 이미 알고계실듯... 그리고 제일 중요한 정신건강에 좋지않습니다! ㅋㄷ
전 덕분에 좋은 글 많이 읽고 갑니다.
선택적html전송이란 단어조차 모르고 해당부분을 코딩하고있던... 1人입니다...~('.'~)
결국 RESS 가 순수한 반응형으로 가는 그 중도에 일시적으로 사용되는 기법이냐, 아니면 모든 사이트들이 궁극적으로 채택하게되는 미래지향적인 기법이냐를 놓고 몇년간 전진님과 토론을 해오고 있는 중이고, 저는 제 주장을 굽히지 않고 있는 것 뿐 입니다. ㅎㅎㅎ
제가 넓은 아량으로 이해를 하고 말고 할 문제는 아니죠.
단지 RESS 라는 단어를 처음들어 봤다는 숨숨이 라는 분이, LESS 하고 RESS 하고도 구분을 못한다는 분이, 저에게 "당신은 RESS 에 대해 잘못알고 있으니, 내가 바로잡아주겠어" 라는 소리를 들으니 황당했던 것 뿐 입니다.
php 로 예를 들자면 10년정도 php 를 접해왔고, 최근 1~2년 정도 CI (코드이그나이터) 같은 새로운 기술이 도입이되서 그걸 말하고 있느데, 그리고 그걸로 개발을 하고 있는데, 오늘 php 에 대해 처음 접했다는 사람이, php 하고 mysql 도 구분을 못하는 사람이,
"당신은 코드이그나이터에 대한 이해가 잘못되었으니 내가 바로 잡아주겠어" 라는 소리를 듣는것과 똑같은 겁니다.
너무 황당했던 것 뿐 입니다.
하루 지나고 나니 그냥 웃고 넘어갈 일이었네요. ㅎㅎㅎㅎ
제가 넓은 아량으로 이해를 하고 말고 할 문제는 아니죠.
단지 RESS 라는 단어를 처음들어 봤다는 숨숨이 라는 분이, LESS 하고 RESS 하고도 구분을 못한다는 분이, 저에게 "당신은 RESS 에 대해 잘못알고 있으니, 내가 바로잡아주겠어" 라는 소리를 들으니 황당했던 것 뿐 입니다.
php 로 예를 들자면 10년정도 php 를 접해왔고, 최근 1~2년 정도 CI (코드이그나이터) 같은 새로운 기술이 도입이되서 그걸 말하고 있느데, 그리고 그걸로 개발을 하고 있는데, 오늘 php 에 대해 처음 접했다는 사람이, php 하고 mysql 도 구분을 못하는 사람이,
"당신은 코드이그나이터에 대한 이해가 잘못되었으니 내가 바로 잡아주겠어" 라는 소리를 듣는것과 똑같은 겁니다.
너무 황당했던 것 뿐 입니다.
하루 지나고 나니 그냥 웃고 넘어갈 일이었네요. ㅎㅎㅎㅎ
그러니까요 ㅎㅎ 덕분에 전 좋은 포스팅 많이 접하네요.
감사드립니다. ^^
그리고 두분의 토론은 모두 스크랩되어 모니터링 중입니다.
언어에 주의하세요 +ㅂ+ ㅋㅋㅋㅋ
감사드립니다. ^^
그리고 두분의 토론은 모두 스크랩되어 모니터링 중입니다.
언어에 주의하세요 +ㅂ+ ㅋㅋㅋㅋ
G5의 (RESS 기반) 반응형 웹에 대해서는 계속 얘기해봤으면 좋겠습니다.
일단 아직은 베타니까 더 좋은 방안이 나오면 배포버전에 포함될 수도 있지 않겠습니까? ^^
###
글 중간에 언급하신 http://hackya.com/us/rwd-vs-ress/ 글은, HackYa님 글은 아니시죠?
읽다보니까 굉장히 낯익은 글이어서요..
일단 아직은 베타니까 더 좋은 방안이 나오면 배포버전에 포함될 수도 있지 않겠습니까? ^^
###
글 중간에 언급하신 http://hackya.com/us/rwd-vs-ress/ 글은, HackYa님 글은 아니시죠?
읽다보니까 굉장히 낯익은 글이어서요..
자료글이라고 써놨는데.. 한글로 번역하려던 참고글인데 시간이 없어서 못했다고.... ㅎㅎㅎㅎㅎ
"G5의 (RESS 기반) 반응형 웹에 대해서는 계속 얘기해봤으면 좋겠습니다." - 네 물론 제가 그 논의에 참여할 일은 없지만 계속 공개적으로 논의되는게 바람직 하겠죠.
"G5의 (RESS 기반) 반응형 웹에 대해서는 계속 얘기해봤으면 좋겠습니다." - 네 물론 제가 그 논의에 참여할 일은 없지만 계속 공개적으로 논의되는게 바람직 하겠죠.
출처없이 복사해서 올려놓으셨길래 HackYa님 글인줄 알았죠.. ㅋㅋㅋ
G5 반응형은, hackya님 말씀이 맞을 수도 있어요.
우리끼리 아무리 얘기해봐야 반영되지 않겠죠.. ^^
G5 반응형은, hackya님 말씀이 맞을 수도 있어요.
우리끼리 아무리 얘기해봐야 반영되지 않겠죠.. ^^
아... 비공개글이었었습니다. 보실분 보시라고 어제 공개로 바꿔놓은거구요.
앤토니 라는 제 친구 하나가
http://hackya.com/404.html (올해 20살. 벌써 페이스북 인턴까지 지낸 경력이 화려한 친구입니다. ㅎㅎㅎ)
개인용 프로그램을 하나 만들어 줬는데, 제 관심사 (css, javascript, 워드프레스 등등) 내용을, 웹에서 봇이 긁어다 제PC 폴더에 넣어주거든요.
그런데 기능이 좀 엉망이라 깨지는 글도 종종 있고, 물론 출처가 어디인지 알수 없습니다. 그러면 저는 그 글들 중 keep 하고 싶은 글들을 제가 필요한 부분만 짤라내서 비공개로 보관하고...
그런 글들 중 하나였습니다.
앤토니 라는 제 친구 하나가
http://hackya.com/404.html (올해 20살. 벌써 페이스북 인턴까지 지낸 경력이 화려한 친구입니다. ㅎㅎㅎ)
개인용 프로그램을 하나 만들어 줬는데, 제 관심사 (css, javascript, 워드프레스 등등) 내용을, 웹에서 봇이 긁어다 제PC 폴더에 넣어주거든요.
그런데 기능이 좀 엉망이라 깨지는 글도 종종 있고, 물론 출처가 어디인지 알수 없습니다. 그러면 저는 그 글들 중 keep 하고 싶은 글들을 제가 필요한 부분만 짤라내서 비공개로 보관하고...
그런 글들 중 하나였습니다.
아 그런 경우였군요. ^^;
그 글의 출처는 sixrevisions 인것 같습니다. http://sixrevisions.com/mobile/methods-mobile-websites/
실질적인 수치등이 들어있어서 꽤 유용한 글이었던것으로 기억을 하고 있었어요.
그 글의 출처는 sixrevisions 인것 같습니다. http://sixrevisions.com/mobile/methods-mobile-websites/
실질적인 수치등이 들어있어서 꽤 유용한 글이었던것으로 기억을 하고 있었어요.
맹목적으로 미반영되리라 생각지는 말아주세요. ^^;; 사용자들이 이야기가 없으면 저희도 깨닫기가 쉽지 않습니다.
계속 이야기가 되어야 저희도 살펴보고 생각하게 됩니다. 비록 대부분 반영을 하지 못하더라도요.
(어떤 기술이 자리를 잡아가는 과정에 놓여있다거나, 좋은 아이디어지만 기존 사용자들을 고려해야 하거나 혹은 정말 개발진이 너무 바쁘기 때문...등의 이유로)
하지만 이런 이슈가 계속해서 생산되는 건 긍정적이라고 생각하는 편입니다. (커뮤니티도 활성화되구요. ㅎㅎ)
설령 위에 언급한 이외 어떠한 이유로 배포판에 포함될 수 없더라도, 사용자분들이 계속해서 목소리를 내는 것은 빌더/스킨/플러그인 제작자분들에게도 분명 영감을 주는 일일 겁니다. ^^;;
출근길에 읽은 책에 이런 글귀가 있더군요.
"
내가 보기에 도널드 럼스펠드가 이와 관련해서 아주 좋은 말을 남겼다.
알다시피,
안다고 알려진 것들이 있다.
우리가 안다고 아는 사실이다.
우리는 또 알고 있다.
모른다고 알려진 것들도 있다.
그것은 곧
우리가 알지 못하는
무엇인가가 있다는 사실을 알고 있는 것이다.
하지만 또한 아직 알려지지 않은 모르는 것도 있다.
우리가 모른다는 사실조차 모르고 있는 것들 말이다.
코딩호러의 이펙티브 프로그래밍 中
"
그런데 누구보다 토론에 열정을 가진 전진님께 이런 댓글을 다는게 저로써는 좀 민망하네요. ㅎㅎㅎ;;
계속 이야기가 되어야 저희도 살펴보고 생각하게 됩니다. 비록 대부분 반영을 하지 못하더라도요.
(어떤 기술이 자리를 잡아가는 과정에 놓여있다거나, 좋은 아이디어지만 기존 사용자들을 고려해야 하거나 혹은 정말 개발진이 너무 바쁘기 때문...등의 이유로)
하지만 이런 이슈가 계속해서 생산되는 건 긍정적이라고 생각하는 편입니다. (커뮤니티도 활성화되구요. ㅎㅎ)
설령 위에 언급한 이외 어떠한 이유로 배포판에 포함될 수 없더라도, 사용자분들이 계속해서 목소리를 내는 것은 빌더/스킨/플러그인 제작자분들에게도 분명 영감을 주는 일일 겁니다. ^^;;
출근길에 읽은 책에 이런 글귀가 있더군요.
"
내가 보기에 도널드 럼스펠드가 이와 관련해서 아주 좋은 말을 남겼다.
알다시피,
안다고 알려진 것들이 있다.
우리가 안다고 아는 사실이다.
우리는 또 알고 있다.
모른다고 알려진 것들도 있다.
그것은 곧
우리가 알지 못하는
무엇인가가 있다는 사실을 알고 있는 것이다.
하지만 또한 아직 알려지지 않은 모르는 것도 있다.
우리가 모른다는 사실조차 모르고 있는 것들 말이다.
코딩호러의 이펙티브 프로그래밍 中
"
그런데 누구보다 토론에 열정을 가진 전진님께 이런 댓글을 다는게 저로써는 좀 민망하네요. ㅎㅎㅎ;;
