디자인과 속도. 웹 페이지를 만들 때 항상 충돌하게 되는 요소 입니다. 디자인에 신경을 쓰다 보면 웹 페이지 속도가 서서히 감소하는 것이 눈에 보일 것이고, 속도에 신경을 쓰다보면 정말 흰화면에 글자와 사진만 몇 개 떠다니는 수준이 되어버릴 수도 있습니다. 보통 스킨을 제작하게 되면 항상 고민하는 것이 바로 속도와 디자인 입니다. 늘 좀 더 새롭고 좋은 모습을 추구하면서도, 바라는 대로 무턱대고 만들어버리면 속도에 치명적인 영향을 미쳐버리고 맙니다. 그래서 스킨을 처음 만들 때 부터 지금까지도, 좋은 디자인을 가지면서 속도가 빠를 수는 없을까 라는 생각을 늘 상 하곤 했습니다. 이런 고민을 항상 하면서 스킨을 제작하다 보니 이전에는 단순한 구조임에도 속도가 한심할 정도로 느렸지만 지금은 숙련도가 쌓였는지 구조를 복잡하게 짜도 브라우저가 처리할 수 있도록 순서만 부여해준다면 오히려 단순한 구조와 맞먹는 속도를 낼 수 있는 것을 깨닫고 있습니다.
본론으로 들어가서, 사실 뭐 버전2라고 거창하게 이름 붙이긴 했는데 저한테나 의미 있는 버전2이지 일반사용자 분들에게는 그냥, ‘어 쬐끔 빨라졌네’라는 생각이 들것 같습니다. 백조가 우아하게 수면 위에 떠있지만 물속에서는 발이 미친듯이 움직이고 있듯, 외관 보다는 속을 뜯어 고치다 보니 업데이트 이후에도 외관상 그 다지 달라진 것은 많이 없습니다. 버전2 업데이트를 통해서 어떤 신기술이 적용되었고 적용시에 어떤 문제를 만났는지 상세하게 적어보려 합니다.
2월 초순쯤에 제작이 끝났던 이 Life is a Journey 스킨도 어느 덧 수많은 수정을 거쳐 거의 버전 1.5.9까지 왔습니다. 업데이트라고 해봤자 세부 카테고리 스타일 추가나 아니면 버그 잡기, 새로운 플러그인 추가와 같은 아주 소소한(?) 작업만 했습니다. 물론 버전 1일때 사이트 구조도 그렇게 흠 잡을 곳이 없지만 몇 가지 치명적인 문제가 있었습니다.
일단 괴상한 HTML 구조입니다. 믿기진 않으시겠지만1 현재 블로그 스킨인 Life is a Journey는 티스토리 기본스킨인 Basic을 기반으로 하고 있습니다. 제가 여태까지 티스토리 스킨을 3개 만들었는데, 앞의 3개는 전부 제가 바닥부터 마크업을 했습니다. 그런데 그렇게 하고보니 검색이 안 된다던지, 아니면 게시글의 순서가 엉킨다던지 하는 웃지 못할 상황이 발생하였습니다. 그래서 최대한 티스토리에서 제공하는 기본 마크업 구조를 따라가기 위해서 Basic 스킨의 마크업을 가져다가 필요한 부분만 HTML5 시맨틱 구조로 변경해서 사용 중입니다. 그런데 이 변경 과정에서 footer와 nav, header만 도입을 했습니다. 이는 몇 가지 이유가 있는데요, 일단 구버전 IE를 지원하기 위해서는 기본적인 div 태그 안에 들어갈 수 있는 요소에만 시맨틱 태그를 적용 했습니다. 즉, 자신이 몸체가 되는 div 요소에는 시맨틱 태그를 쓰지 않았습니다. 왜냐면 IE는 xml구조로 된 비표준 요소에는 스타일이 적용이 안되는 치명적인 단점이 있기 때문입니다. 스킨이야 어찌됐든2 일단 화면에 출력은 시켜야 하기 때문에 시멘틱 구조를 완전하게 도입할 수가 없었습니다.
그러나 이번 업데이트 부터는 스킨 전반에 시멘틱 구조를 도입 하였습니다. 즉, header, nav, aside, article, footer가 모두 포함 되었습니다. HTML5 시멘틱 구조가 가지는 장점으로는 좀 더 나은 SEO와 검색엔진의 크롤링이 쉬워지는 장점이 있습니다. 물론 이 시멘틱 구조를 도입한다는게 원하는 요소만 시멘틱 태그를 부여한다고 끝나는 것이 아닙니다. html 구조와 스크립트 css를 전부다 뜯어고쳐야 합니다. 그래서 현재 업데이트가 된 V2 스킨이 적용 되어있으나 V1 부터 제 블로그에 들어와 보신 분들은 “그다지 바뀐게 없는데?” 라는 기분이 드실겁니다. 그러나 화면너머의 소스코드는 정말 엄청나게 변경되었습니다. 간단히 말해 “그냥 밑바닥 부터 코드를 싹 갈아 엎었습니다.”
아까 IE에서는 시멘틱 구조가 안 먹힌다고 했는데 그러면 어떻게 구버전 IE지원을 할것이냐 라고 묻고 싶으실텐데, 그 부분은 아직도 연구 중입니다. 이론상 html5shiv를 사용하면 구버전 IE도 시멘틱 태그를 표준 태그로 인식하긴 하나, IE tester 자체가 워낙 일관성 있는 화면 표시가 되지 않기 때문에 구버전 IE 전용스킨 제작에 애로사항이 많습니다. 이번에는 진짜 진지하게 IE용 스킨을 만드려고 준비 중인데요,3 가로폭 960px에 해상도 1024x768에 최적화 된 레이아웃을 적용해보려 합니다. html5shiv가 정상작동한다면 구버전 IE에서도 문제 없이 블로깅이 가능하게 하겠습니다. 그리고 모더나이저라는 요소도 추가가 되었기 때문에 SVG와 같은 새로운 요소와 충돌도 피할 수 있을 것으로 봅니다.
요즘 디자인이 잘 된 웹사이트들을 많이 돌아다니면서 html5와 함께 등장한 신기술들을 맛 보며 감탄하곤 합니다. 특히 SVG라는 요소에 푹 빠져있습니다. SVG는 Scalable Vector Graphics의 약자로, 브라우저의 엔진을 이용해서 벡터 그래픽을 그릴 수 있게 되었습니다. 아직은 IE9+ 부터 지원이 가능해짐에 따라 그렇게 광범위 하게 쓰이고 있는 기술은 아니지만 그래픽 툴의 결과물을 브라우저에서 바로 활용하고 스크립트와 스타일시트를 이용해서 변경할 수 있기 때문에 발전 가능성이 무궁무진한 기술입니다. 제 스킨에도 이 SVG요소를 처음 도입 하였습니다. SVG로 그림이나 타이포를 만들어 본 적은 있지만 실제 웹페이지에 활용해보는 것은 이번이 처음이다보니 많은 문서를 찾아서 읽어야 했습니다.
일단 ‘왜 SVG를 도입해야 하는가’라는 것 부터 짚고 넘어가 보도록 하겠습니다. 일반 사진들, 그러니까 jpg,bmp,png,gif 이미지는 레스터 그래픽 입니다. 픽셀이라는 단위로 그림을 표시하는 방식으로, 1px의 크기를 나타내는데 한계가 있던, 과거에는 그다지 문제가 되지 않는 포맷 이었습니다. 그래서 웹패이지를 디자인할때 이런 이미지로 아이콘과 여러가지 요소들을 집어 넣게 되었습니다. 그러나 기술이 점점 발달하면서 기기들의 해상도가 높아지기 시작했습니다. 1px의 크기는 그대로 이지만 이를 4배의 해상도를 가진 화면에서 구현한다고 가정을 하면, 1px을 4px로 표현하게 됩니다. 그러나 이렇게 하면 픽셀의 크기만 커졌지 이미지의 크기는 증가하지 않았기 때문에 흔히들 말하는 뿌연사진이 나타나게 됩니다. 그에 비해 벡터 그래픽은 이미지를 픽셀 데이터가 아닌 일종의 수식 데이터로 환산을 해서 저장을 하게 됩니다. 그리고 파일을 불러올때마다 그 수식 데이터를 바탕으로 화면에다가 그림을 그려버리죠. 덕분에 벡터 그래픽은 해상도의 영향을 받지 않습니다. 사실 이전에는 이렇게 까지 할 필요가 없었으나 앞서 말했듯 모니터의 고해상도 화로 간단한 아이콘에서는 더 이상 사진 파일이 아니라 백터그래픽을 사용하는 것이 불가피 해졌습니다.
물론 웹킷이나 파이어폭스에서는 고해상도 디스플레이를 위해서 4배 해상도 짜리 이미지를 화면해상도에 맞춰서 뿌려주는 옵션이 있으나 그렇게 해버리면 사이트는 점점더 무거워지고, 별도의 요청으로 인해서 로딩속도는 더욱 느려지게 됩니다. 사실 CSS3에서 추가된 효과만 해도 다 써먹기 벅찰판에 SVG까지 건드리는 것은 다들 힘든지 그렇게 많이 관심은 받지 않고 있습니다. 물론 관심의 문제보다도 브라우저의 성능이 많이 영향을 미치긴 합니다. 일단 SVG는 일반적인 사진이 아니라 벡터 “그래픽" 이기 때문에 브라우저 스스로가 랜더링을 해야 합니다. 현대적인 브라우저의 경우 간단한 구조일 경우에는 큰 문제가 되지 않으나 복잡한 랜더링이나 스타일, 그리고 애니메이션이 사용 되었을 경우 사양에 따라 여전히 버겁습니다. 그에 비해 CSS3는 적은 리소스 만으로도 효과 구현이 가능하고, 이전에 자바스크립트를 통해 구현해야 되었던 효과들이 모두 가능해 지면서 상대적으로 쉽고 사용하기 용이하기에 관심이 그쪽으로 많이 쏠리고 있습니다.
SVG가 가지는 장점은 매우 많습니다. 첫번째로 더 이상 이미지가 아니고 xml문서이기 때문에 엄청나게 고압축이 가능해집니다. 소셜 아이콘 같은 경우에 이미지 파일일 경우 몇 kb대이고 아무리 스프라이트를 적용해서 압축을 돌린다고 하더라도 xml 문서의 몇 byte 단위까지는 내려가기 힘듭니다. 게다가 SVG는 css로 스타일링을 적용 할수 있습니다. 그러니까 이전에는 정적인 이미지 였다면 이제는 랜더링의 개념이 되어 스타일시트를 통해 마음대로 조정할 수 있다는 것 입니다. 이번 업데이트를 통해서 SVG가 적용 된 곳은 하단 footer의 소셜 아이콘입니다. 둥근 육각형 모양의 이 아이콘들은 SVG 그래픽이며 스타일시트를 통해서 색상과 애니메이션이 적용 되어있습니다. 물론 제 블로그 특성에 맞게 특정 카테고리에서는 색상이나 형태가 조금씩 바뀝니다.
-
V.1 페이지 스피드 스코어
-
V.2 페이지 스피드 스코어
게다가 SVG는 일련의 코드 이기 때문에, 흔한 텍스트와 비슷한 성질을 가져서 브라우저의 요청 수도 줄일 수 있습니다. 버전1일때와 버전2일때의 동일한 페이지 태스트 결과입니다. 요청 수가 감소한 것을 보실 수 있습니다. 아직은 대중화 되지 않은 요소이지만 이리저리 삽질하고 갖고 놀다보니 재밌는 요소가 상당히 많았습니다.
두번째로 “새로 도입된 요소이지만 다른거 재밌는게 많아서 별 관심이 없는 요소”는 flex-box입니다. 플랙스 박스 모델은 이름 그대로 유동성이 있는 박스 모델입니다. 웹이 모바일과 데스크톱 페이지를 별도로 놓는 것을 넘어 반응형 웹이라는 이름으로 N스크린에 대처를 하고 거의 모든 사이트들이 이 반응형 웹페이지를 지원하도록 되어가는 수순을 밟고 있습니다. 이에 맞춰 등장한 것이 플랙스 박스 입니다. 기존의 CSS 박스 모델이 이리저리 옮기기가 상당히 불편하고 맨날 float과 clearing으로 홍역을 치러야 했다면, 플랙스 박스 모델은 아주 간단한 코드 몇 번으로도 구현이 가능합니다. 이번 스킨에서는 티에디션을 플랙스 박스 모델로 짜려고 했고, 이미 구현을 해보았으나, 기존 css2 만으로도 별 탈 없이 구현이 되어서 그쪽 방향으로 다시 코드를 이전 방식으로 짰습니다. 사실 플랙스 박스의 사용이 꺼려지는 것은 아직도 최신 브라우저4가 지원하는 것이 정말 적습니다. 게다가 몇 가지 요소라도 쓰려면 오만가지 prefix를 붙여야 하는데 이것도 여간 불편한게 아니더군요. 실험 삼아서 한번은 해보았는데, 정말 편하고 좋습니다. 지금 대다수의 프레임 웍들이 그리드라는 이름을 가지고 박스모델의 위치지정을 position과 여러가지 여백 조정으로 밀고 당기고를 하는데 플랙스 박스 모델은 코드 몇 줄 만으로 그 모든게 끝나버립니다. 물론 역시나 변수는 브라우저도 지원을 못하고, 주변 플러그인도 당황하는 기색이 역력하다는 것을 들 수 있겠내요. 기대되는 기술이나 아직 까지도 무슨 용도인지 의 문가는 요소도 많고, 지원 안되는 태그가 많아서 1년쯤 있다가 전면 도입해볼 생각을 하고 있습니다.
최신 웹사이트에는 안 쓰이는 곳이 없다고 해도 과언이 아닌 것이 바로 글리피콘 입니다. SVG가 생각보다 스타일링이 구질구질하고 다루기가 힘든 반면에 글리피콘은 그냥 말 그대로 문자와 같이 움직이기 때문에 기존 택스트에서 적용 되던 스타일이 모두 적용이 되어서 아주 사용이 편리하다는 장점이 있습니다. 게다가 폰트이기 때문에 브라우저에서 소프트웨어적으로 랜더링이 되는지라 일반 레스터 이미지 처럼 크기를 키우거나 줄여도 깨지거나 자글자글 해지지 않는 다는 장점도 있습니다. 글리피콘은 SVG와 함께 고해상도 화에 대처하는 현명한 방법중 하나로 꼽히고 있습니다. 일부는 ‘유니코드 문자를 그딴식으로 활용해도 되는거냐’, ‘웹 접근성이 문제가 있다’ 라고 하지만 어짜피 남아도는 유니코드 문자, 몇 개 쓴다고 그렇게 문제시 되지는 않을 것 같습니다. 버전2에서는 게시글 하단 부에 있는 소셜 아이콘에 글리피콘을 전면 적용 하였습니다. 사실 소셜 공유 버튼은 각각의 회사들의 약관에 커스텀이 금지되어있습니다. 저처럼 그런 것 마저도 일관성있게 하지 않으면 미치는 사람들이 꽤 많은지 이중으로 호스팅을 거쳐 공유버튼을 커스텀 할 수 있는 방법이 생겨나고 있습니다. 여러가지 대행 플러그인이 나와있는데요, 저 같은 경우에는 simple share button 을 사용했습니다. 보통 카운터도 넣을 수 있으나 이는 php 문서를 인라인으로 넣어야 되고 티스토리는 정책상 php는 자동으로 주석처리를 해버리기 때문에 아쉽지만 카운터 없이 버튼만 넣었습니다. 보통 소셜 버튼이라는게 해단 소셜 네트워크 사이트에서 아이프레임으로 끌어오는 구조로 되어있습니다. 보안 상 문제도 있고, 조작이나 불법적인 사용을 막기 위한 점도 없지 않아 있습니다. 하지만 서비스 업체의 서버 응답시간이 아무리 빠르다고 해도 아이프레임은 웹로딩 속도에 현저한 영향을 미칠 수 밖에 없습니다. 게다가 요청 수가 많아져서 모바일에서는 약간 버거울수도 있는 부분입니다. 그다지 잘 쓰지는 않지만 다들 달길레 저도 애드디스 쉐어버튼을 꾸준히 사용해오고 있었습니다. 그러나 그것이 로딩 시간에 미치는 부분에 상당한 불만을 가지고, 커스터마이징도 불가능한 것도 짜증이 나서 하단에 좋아요 버튼을 누르면 위젯이 보이도록 설정을 해놓았다가 이번에 커스텀 버튼을 설치 하면서 과감히 제거 했습니다. 이 방식이 좋은 점은 아이프레임이 없으니 로딩시간 저하도 많이 줄 뿐더러 버튼을 클릭할때만 해당서버로 전송이 요청되기 때문에 모바일 브라우저에서도 부담이 없습니다.
rem 사이즈라는 것은 root em 사이즈 라는 뜻입니다. em은 활자판 시절에 대문자 M이 모든 문자 수치의 기준이 되었다는 것에서 유래한 것으로 웹에서 1em은 16px이라는 단위를 가집니다. rem은 이 1em의 수치를 별도로 지정하여5 rem 수치의 조절을 통해 모든 문자요소의 크기를 일괄 변경하고, 미디어 쿼리 사용시 화면별로 폰트 사이즈를 하나하나 조절하는게 아니라 일괄 조절이 가능한 아주 유용한 요소입니다. 문제는 모든 사이트의 폰트가 한번에 움직이기에 다루기가 상당히 까다롭습니다. 저도 전면 도입을 하려고 했지만 이건 뭐 별도로 폰트 사이즈 입력하는 것보다 더 복잡하고 까다로워서 본문 부분만 적용이 되어있고 나머지 부분은 그냥 직접 입력 방식으로 했습니다.
외부 스크립트는 매력적이지만 동시에 블로그 로딩속도를 떨어뜨리는 주범이기도 합니다. 요즘 티스토리 블로고스피어에서 떠들썩한 악성코드 경고 문제도 이 스크립트가 주범입니다. 스크립트는 그 무엇보다도 블로그 로딩속도에 치명적인 영향을 미치는 요소이기 때문에 아주 신중하게 다뤄야 합니다. 특히 가장 기본적인 블로그 속도 향상 팁중 하나가 스크립트는 </body>위에 놓아라 입니다. 대부분 설명없이 그냥 이런 말을 적곤 하는데, 간략히 알아보면 브라우저라는 놈은 웹페이지가 있으면 맨 윗줄부터 차례대로 읽습니다. 막 사람처럼 중간에 건너뛰거나 결말보기 전에 병걸려 죽지 않을까 두려워하면 맨 끝부분이랑 첫 부분을 같이 보진 않지요. 바로 이 때문에 스크립트를 하단에 위치시킵니다. 경우에 따라서 스크립트가 로드되지 않으면 아예 본문을 볼 수 없는 블로그들이 있으나 극히 드문 사례이기에 제외합니다. 스크립트가 상단에 있으면 본문 내용을 불러오기도 전에 브라우저는 스크립트를 열심히 읽고 있습니다. 사실 페이지가 예쁘게 뜨건 못 나게 뜨건 간에 방문자는 일단 뭐라도 써져있는 것들 읽어야 사이트에 계속 접속하고 있게 됩니다. 그러나 사이트 내용물이 뜨기도 전에 스크립트를 읽어버리면 내용물이 로드되는 시간이 그 만큼 지연이 되고 결과적으로 방문자 이탈까지 가기도 합니다. 이렇게 가장 기초적인 방법으로 스크립트를 다루는 것이 하단부 에 위치하는 것입니다. 하지만 여기서 끝이 아닙니다. 스크립트를 다루는 방법은 이것 말고도 많습니다. 그 대표적인 것중 하나가 비동기식 로드 입니다. 비동기식이란 말 그대로 현재 웹페이지의 내용물과는 별도로 움직인다는 뜻입니다. 현재 스킨의 경우 아웃브래인, 디스커스, 애드센스등 여러가지 스크립트 기반 요소들이 추가되어있습니다. 애드센스의 경우 최신 코드는 비동기식을 지원하기 때문에 이전 구식 코드에 비해서 페이지 자체의 로딩속도가 향상되는 것을 볼 수 있습니다. 이는 그냥 코드를 교체하면 되기 때문에 적용 안 하신 분들은 하시는 게 좋습니다. 사용자가 별도로 비동기식을 적용할 수 도 있습니다. 제 블로그 같은 경우 디스커스 플러그인으로 기본댓글을 완전 대체하고 있는 방식입니다. 디스커스는 매우 강력한 소셜 댓글 플랫폼이지만 로딩에 걸리는 시간이 기본 댓글보다는 느리기 때문에 페이지 속도에 영향을 미치게 됩니다. 그래서 스크립트를 통해 사용자가 스크롤을 맨 상단 기준으로 1000px을 내리면 그때 디스커스 플러그인을 불러오도록 설정을 해놓았고 덕분에 사용자가 본문을 읽고 있는 동안 알게 모르게 코맨트 플러그인이 로드가 되게 하였습니다. 구현은 쉽지 않으나 로딩시간에 많은 이득을 보고 있습니다.
티스토리 에디터는 정말 많은 기능을 제공합니다. 네이버나 이글루스와 비교해보아도 수식이나 슬라이더, 주석등 잘 사용하면 굉장히 편리한 기능들이 많습니다. 하지만 이런 다양한 기능들에는 단점이 한 가지 있습니다. 바로 스타일 수정이 용이하지 못 합니다. 이런 부분은 스킨 가이드라인에서 안내를 해주고, 접기 펴기 기능 처럼 별도로 스타일 지정이 가능하도록 배려해주면 좋겠으나 티스토리 측에서는 전혀 그럴 마음이 없어보입니다. 사용자가 개발자가 되는 티스토리에서는 자력으로 해결하는 수밖에 없습니다. 특히나 저 같이 지랄 맞은 성격은 뭔가 일관성이 없거나 아니면 보기 싫은 것을 그냥 냅두지 않습니다. 티스토리 기본 요소들은 편리해서 자주 사용하고 싶으나 그놈의 90년대 스타일 디자인 때문에 상당히 꺼러질때가 많습니다. CSS2 시절에야 군소리 없이 써야 됐으나 CSS3에서 추가된 다양한 셀렉터를 이용해서 티스토리에서 제공하는 기본 요소들의 스타일 적용이 가능해졌고, 현재 거의 모든 요소의 스타일을 적용 완료한 상태입니다.
가장 까다로웠던 상대는 테이블 입니다. 티스토리 자체는 테이블 레이아웃이 아니지만, 티스토리 자체에서 제공하는 사진 2개 배치나 3개 배치는 테이블 안에 넣어버립니다. 게다가 글 레이아웃도 테이블로 나오기 때문에 반응형 스킨에서는 여간 성가신 존재가 아닙니다. 여러 사이트들의 도움을 받아 반응형 웹에서도 테이블을 그럭저럭 사용하는 방법을 깨달았고 일부 적용된 상태입니다.
특히 요번 스킨 업데이트의 목표중하나가 터치 기기 친화적으로 구성을 하는 것이었는데, 티스토리 기본 요소도 터치 친화 적으로 만들기 위해서 많이 노력을 했습니다. 슬라이더 같은 경우 PC에서는 마우스를 호버하면 컨트롤이 뜨는 방식이나 이게 모바일에서는 잘 안 먹힙니다. 그리고 끄고 켜는 애니메이션이 안 그래도 경량화 된 모바일 브라우저 엔진에 부하를 주기도 하고요. 그래서 모바일 버전에서는 항상 슬라이더가 떠 있도록 하였습니다.
블로그 스킨을 제작하기 전에 항상 포토샵으로 목업을 만듭니다. 목업을 통해서 폰트 두께나 색상 배치를 정합니다. 이렇게 하는 것이 나중에 디자인이 갑자기 바뀔 확률도 적고 정말 그대로 보고 만들면 되기 때문에 상당히 편합니다. 문제는 타이포입니다. 포토샵과 같은 그래픽 툴에서의 폰트 랜더링과 브라우저의 폰트랜더링은 많이 다릅니다. 게다가 한술 더 떠서 브라우저 끼리도 폰트 구현 하는 방식이 다르며, 해당 브러우저가 어떤 운영체제에서 실행되느냐에 있어서도 폰트의 구현이 달라집니다. OS X에서 크롬 기반으로 사이트를 제작했더니 윈도우에서는 폰트가 너무 얇아서 못 읽고 사파리에서는 희미해서 못 읽는 상황이 발생했습니다. 이는 브라우저 마다 안티얼라이징이 다르게 들어가서 그런데, 이도 몇 가지 꼼수를 통해서 어느 정도 극복을 했습니다. 그러나 여전히 절 괴롭히는 요소중 하나 입니다. 크로스 브라우저 & 운영체제 타이포 그래피를 일관성있게 하는 것은 멀고도 험합니다.
스킨을 부분 수정하거나 새로 제작할때마다 항상 신경 쓰는 부분이 색상 배치입니다. 개인적으로도 그렇게 생각하고 웹에서도 비슷한 의견을 많이 보았는데, 웹디자인에서 특히 플랫디자인에서는 색상을 많이 쓰게 되면 치명적입니다. 더군다나 블로그는 상품을 홍보 또는 판매하거나 하는 공간이 아니기 때문에 게시글에 집중되게 하는 것은 더욱더 중요한 요소입니다. 이 모든 것은 색과 관련 됩니다. 본문 보다 주변이 튀어보이면 집중도가 떨어지게 됩니다. 가끔 엄청난 양의 색상을 사용하시는 분들이 간혹 계신데, 물론 그것도 그런지(grunge) 스타일이라고 하나의 디자인 요소가 있긴 하지만, 그런지도, 스큐어모픽도 플랫도 아니고 어중간하게 색을 많이 쓰는 것은 그다지 보기 좋지 못합니다. 물론 극단적으로 줄이라는 말도 아니며 무조건 적당한게 가장 좋은 것입니다. 자신의 기준에서 가장 적당하다 싶은 선을 찾는 것도 좋습니다. 버전1까지만 해도 형광 초록 하이라이트를 부분부분 많이 사용하였으나 이번 업데이트로 많이 제거를 하였습니다.
이번 업데이트 에서 가장 큰 변화가 바로 티에디션 일겁니다. 기존의 정사각형 그리드 레이아웃에서 직사각형 방식으로 전환을 하였습니다. 뿐만 아니라 검색창과 메뉴도 살려내서 메인화면에서도 카테고리를 고르거나 게시글 검색을 할 수 있도록 하였습니다. 모바일에서는 전환 애니메이션 사용시 프레임 드랍이 있기 때문에 모바일에서는 뜨지 않도록 하였으며, 그리드에 맞는 이미지 중 가장 작은 해상도의 이미지를 사용해서 로딩 속도도 소폭 감소했습니다. 이전에 비해서 티에디션 스크롤시 프레임 드랍이 많이 완화 된편입니다. 속도 향상은 업데이트 된 파운데이션의 영향도 있습니다. 기존 5.1.0에서 5.2.1로 업그레이드 하였는데, 오르빗 슬라이더가 상당히 부드러워졌습니다. 5.2.0은 슬라이더가 두번째 이미지로 넘어가지 않는 웃지 못할 버그가 있었지만 5.2.1 긴급 수정으로 해결되었습니다. 슬라이더 프레임이 꽤 잘 나오는지라 이제는 터치기기에서도 슬라이더가 뜨도록 하였습니다. 현재 기준으로 똥이 아니라 산업폐기물인 아이폰4에서도 그럭저럭 잘 됩니다.
기본 마크업을 갈아 엎으면서, 카테고리 별 스킨의 구조도 많이 바뀌었는데요, 이에 맞춰 카테고리 스킨의 스타일도 세부적으로 변경하였습니다.
우선 기본 본문 스타일에서는 파도 이미지 대신 눈산을 넣었습니다. 그리고 상단바의 색상을 제거해서 답답해 보이지 않도록 하였습니다. 모바일 뷰에서 가장 큰 변화면 MENU라는 영문 버튼에서 리스트 아이콘 형태로 변환을 했으며, 게시글 이외의 부분은 회색으로 처리 하며 구분을 지었습니다. 그리고 맨위로 가기 버튼도 왼쪽에서 하단부로 이동하였습니다. 기능은 완전히 같습니다.
자동차 관련 카테고리의 경우 베너 이미지가 하단 게시글을 일부 침범하도록 했습니다. 꽤 새로운 시도인데요, 막상 만들어 놓고 보니 보기 상당히 좋습니다.
카테고리 뷰는 사이드바에 약간 투명도를 주어 답답하지 않게 하였으며, 디스커스 댓글의 개수도 표시가 됩니다.
이제 변경사항을 간략하게 나열해 보겠습니다.
아웃브레인의 경우 제목 택스트를 사진 속으로 넣어 공간을 최소화 하였습니다.
티스토리 슬라이더의 캡션기능을 부활시켰습니다.
페이지 별로 이전의 파도 사진 대신 여러가지 배경화면이 추가 되었습니다.
이전 티스토리 기본 댓글 내용만 나타납니다. 추가 삭제 수정은 안 됩니다.
접기 펴기의 스타일이 개선되었습니다.
이번 스킨 업데이트의 주 목표는 구조의 현대화 였습니다. 리다이랙션, 요청수, 페이지 용량등 눈에 보이지는 않지만 속도에 영향을 미치는 요소를 대폭 개선했습니다. 특히 v1의 용량이 6.5mb였던데 비해 v.2의 용량은 1.83mb 입니다. 약 3분의 1로 줄어들었습니다. 외계인이라도 갈아 넣었냐고 물어보신다면, 그냥 제 몸을 갈아넣었다고(...) 대답하고 싶습니다.
끝으로 스킨에 이스터 애그를 몇 개 넣어놓았습니다. 직접 찾아보시는 것도 재밌습니다. ㅎㅎ
