요즘 대세는 플랫
제가 만든 1번째 스킨인 Congnocenti가 플랫도 아니고 그런지도 아니고 어정쩡했었고, 2번째 스킨인 TA는 부트스트랩2 기반으로 세미 플랫한 스타일을 가졌었습니다. 3번째 스킨인 프로토타입은 파운데이션 기반으로 스큐어모픽 틱한 디자인을 구현했었죠. 다중 레이어와 그림자 사용으로 거의 3D 가까운 모습을 보여줬었습니다. 11월에 만든 스킨인데 계속 쓰려고 했지만 막상 안 쓰는 기능을 좀 빼고 코드를 정리하려고하니 너무 마크업이 개판이라서 그냥 새로 만드는 방향으로 가게 되었습니다.
스킨을 새로 만들면서 계획했던것은 요즘 유행하는 완전 ‘플랫 스타일을 구현하자’ 였습니다. 그래서 주요 디자인 키워드는 flat&simple 이었습니다. 하지만 중간 중간에 그림자 요소를 넣어서 너무 지루한 플랫이 되지 않게 했습니다. 구글이 처음 개편(이라쓰고 사상 최초로 디자이너를 고용했다고 읽는다) 하면서 플랫 스타일을 도입했는데 이에 질세라 애플도 이어서 플랫 스타일을 웹사이트 뿐만 아니라 iOS7이라는 존나 개쓰래기 운영체제에 전반적으로 도입하게 되었죠.
플랫으로 디자인 할 때 가장 큰 관건은, 지루하지 않아야 된다 입니다. 플랫도 너무 극단적으로 치우치면 지루하고 단조로워서 보기 싫어지죠. iOS7은 이를 반투명 레이어와 hierarchy 지정을 통해서 극복했고, 구글 같은 경우에는 플랫한 그림자를 통해 스큐어모픽한 요소를 완전히 버리지 않는 시도를 했습니다.
영감을 얻은 곳
제 생각에 이 스킨을 디자인 할 때 가장 크게 영향을 받은 사이트는 애플 공식 홈패이지 입니다. 사이트를 들어가보면 가장 앞선 기술과 스타일을 자랑합니다. 애플 홈패이지의 스큐어모픽한 스타일이 2000년대 웹사이트의 교과서나 다름 없었던 것에서 그 진가를 확인 할 수 있습니다. 그 이외에도 테마 포레스트에서 여러 워드프래스 스킨을 보면서 요즘 잘 나가는 트랜드 요소를 도입했습니다. 플랫만큼 선호 되는 요소로 패럴랙스가 있고, 스크롤시 변형되는 탑 메뉴바와 대형 hero이미지 위에 아주 얇은 폰트로 쓰여지는 제목을 들 수 있겠내요.
구글 플러스로 거의 대세가 된 hero 이미지 중간에 프로필 이미지를 걸치는 방식도 차용했습니다. 뒤에 쓰인 히어로 이미지는 OS X 매버릭스에 기본으로 포함된 배경화면 입니다.
타이포
폰트는 마음 같아서는 헬베티카 뉴이 울트라 라이트를 쓰고 싶었지만 유료 폰트 호스팅을 받을 생각은 없었기에 구글에서 제일 폰트 웨이트 옵션이 많은 산세리프 폰트 하나를 골랐습니다. Raleway 폰트는 제가 가장 처음 스킨을 제작할 때 전반적인 인터페이스용 폰트로 사용 한 것 이어서 감회가 새로웠습니다. 그 때에 비해서 코딩 실력은 아주 많이 발전해서 이 폰트를 더 이쁘게 표현할 수 있게 되었으니까요.
Cursive한 폰트를 얇은 산세리프체와 혼용하는 스타일을 도입했습니다. 아마 GTA V 이후로 유행하기 시작했는데, 워드프레스 테마 중 에서도 이런 폰트 구성을 사용하는 테마가 많습니다. 자유분방한 필기체와 정갈한 산 세리프체가 서로 조화를 이루는 모습이 아주 보기 좋습니다.
폰트는 요즘 디자인 유행인 얇은 폰트를 적용 했습니다. thin이나 light나, Extra thin이나 그놈이 그거 같은데 말이죠 -ㅅ-
저는 포토샵을 이용해 실제 크기로 디자인을 하고 거기서 스타일을 따와서 디자인 하는 방식을 사용하고 있습니다. 이렇게 하는게 디자인의 방향이 잡히고, 스타일의 수치나 크기도 바로바로 파악이 가능하기 때문에 상당히 좋습니다.
그러나 한 가지 문제점은 포토샵의 폰트 구현 방식과 웹 브라우저별 폰트 렌더링 방식이 미묘하게 다르다는 것입니다. 이게 굵은 폰트일 때는 그렇게 차이가 별로 안 나는데, 폰트가 얇아지게 되면 폰트 웨이트 100이나 200이나 차이가 엄청나게 됩니다. 포토샵에서 보이는 폰트보다 브라우저에서는 한 단계 낮춰야 원래대로 뜨는게 상당히 불편했던 것 같습니다. 한 가지 염려되는 것은 현재 윈도우에서는 테스트 해보지 않아서 얇은 기본 시스템 폰트가 없는 윈도우에서는 아마 그리 썩 보기 좋지 않게 글자가 뜰 것 같습니다.
폰트라는게 시스템에 따라서도 편차가 심합니다. 폰트 구현에 가장 최악은 단연 윈도우죠. 제일 갑은 맥입니다. 물론 비스타 이후로 클리어 타입을 도입한지라 조금 나아지긴 했지만요.
삽질과 우회
이번 스킨은 스크립트의 향연이라고 해도 과언이 아닙니다. 거의 모든 곳에 스크립트가 사용되었으니까요. 게시글 날짜 부분도 스크립트 구현이고, 스타일 분할도 스크립트, 홈 화면도 스크립트 전부 스크립트입니다. 여담이지만 테스트 블로그 하나를 스크립트 잘 못 작성해서 아주 말아먹었습니다. -_-; (복구불능)
아마 티스토리 스킨으로서는 처음 시도 되는 방법이라고 생각되는데요, 티스토리 스킨의 경우 제작의 용이성과 스타일의 일관성을 위해서 단일 페이지에 모든 요소를 넣고 스타일을 하는 방식으로 되어있습니다.
사실 일반적인 웹사이트 제작 방식은 인덱스 페이지를 만들고 부수적인 페이지를 트리 형식으로 만들어가는 방식으로 되어있기 때문에 페이지마다 다른 모습을 적용하기가 그리 어렵지 않습니다. 하지만 티스토리는 애초부터 단일 css를 사용하는 구조로 만들어졌기 때문에 그것을 구현하기가 쉽지 않습니다.
저는 역발상으로 각각의 화면에 해당하는 페이지를 따로 만든 다음에 조립하는 방식으로 갔습니다. 오히려 모든 요소를 따로 통제가 되며 하나의 요소의 스타일이 다른 요소에 영향을 미치지 않기 때문에 스타일 자체를 작성하는데 머리를 좀 덜 써도 됐던 것 같습니다. 하나의 요소 스타일 지정해도 이 요소가 다른 페이지에서 어떻게 보일지도 생각을 했어야 하는데 그런게 없어서 좋았던 것 같네요.
문제는 다시 재조립시 터졌습니다. 최적의 스타일을 이끌어내기 위해 마크 업을 약간씩 건드렸는데 이게 전부 달라서 일관되게 하느라 좀 애를 먹었네요. 파트별로 별도의 css가 존재해서 쉽게 스타일이 변경 가능하고 각각의 스타일시트 길이가 짧기 때문에 편집도 용이하다는 장점이 있습니다. 단점은 파일의 갯수가 무지막지 하게 늘어나고 하나로 통일 되게 만드려면 번거로운 작업이 필요하다는 것 이겠네요. 이 스킨도 이전과 마찬가지로 파운데이션 기반입니다. 이전에 썼던 프로토타입 스킨도 역시 파운데이션 기반인데, 제가 마크업을 너무 복잡하게 작성해서 속도가 아주 느려터지게 되어버렸죠. 파운데이션 자체는 정말 말도 안되게 빠른 프레임웍 입니다. 단지 제가 마크업을 개판으로 해서 느렸던 것이죠. 현재 마크업은 에개? 소리가 나올 정도로 간단하게 작성이 되어있는데요, 거기에 프로토타입 스킨보다 더 많은 스타일 시트와 스크립트를 올렸는데도 속도는 오히려 향상 된것을 보면 제 마크업 실력이 아주 븅신이라는 것을 뼈저리게 느낍니다.
웹사이트 속도에 대해서 연구를 하다가 알게 된 것인데, 하나의 엘리먼트에 ID나 클래스가 많아도 속도 저하의 원인이 됩니다. 클래스 하나가 나올 때마다 브라우저가 해당되는 클래스의 css를 look up 하게 되는데 이게 브라우저에 부하를 주게 됩니다. 그래서 정석은 “아이디나 클래스는 둘 중에 하나만쓴다. “, “클래스는 2개 이상 사용하지 않는다.” 라는 방법론이 있습니다. 프로토타입 스킨의 문제 중 하나는 제가 파운데이션에 익숙하지 않아서 기본으로 주어지는 클래스로 css 작성을 줄였다는데 있습니다. 컬럼/플로트/클리어/컬럼/스타일 까지 전부 클래스가 들어가니 속도가 안 느려지는 것이 더 이상하죠.
속도에 관련해서 폰트 문제도 있습니다. 영문 폰트 같은 경우 아무리 많은 폰트웨이트를 가지고 있더라도 1메가를 넘는 일이 잘 없는데 한글 폰트는 11270 완성형 폰트 같은 경우에는 단일 스타일 만해도 1메가를 넘고, 스타일 별로 들어 있다면 거의 10메가가 넘어갈 수도 있습니다. 그래서 자신의 블로그에 한글 웹 폰트를 쓸 때는 신중해야 합니다. 왜냐면 한글 폰트가 너무 용량이 크고 무겁기 때문이죠.
이 스킨의 티에디션 같은 경우에는 거의 갈아 엎었다고 해도 과언이 아닙니다. 기존 티에디션 같은 경우에는 블루프린트라는 그리드 시스템 위에 만들어져 있습니다. 이게 처음 티에디션이 등장할 시점만 해도 최신 프레임 웍이었지만 지금은 낡디 낡은 프레임 웍입니다. 블루프린트를 끄고 켜게 해주면 좋을텐데 그런 것은 전혀 신경을 안 쓰는 티스토리 때문에 스킨 제작자가 직접 해결해야 하는 상황이 발생합니다. 저는 스크립트를 이용해서 블루프린트 관련 요소를 전부 꺼버리고 제가 만든 요소로 대체를 했습니다. 티에디션을 한번 수정 하려먼 스크립트를 끄고 티에디션을 수정하고 다시 스크립트를 켜는 아주 개삽질을 해야 하지만 일단 결과물이 만족스럽다보니 크게 불만은 없습니다. 문제는 이렇게 된 이상 이 스킨의 배포 가능성은 거의 0에 수렴한다는 것이죠. 저야 익숙하니까 쉽게 관리와 조정이 가능한데, 이걸 그냥 일반인에게 던져주면 백이면 백으로 구조의 복잡성 때문에 포기 할 겁니다.;
티스토리의 단점은 어떤 시도를 하려다 보면 항상 원터치 인스톨이 불가능하게 된다는 점이네요. 그래도 이만한게 수정이 되는 블로그를 용량 무제한으로 쓸 수 있다는 것이 항상 감사할 따름 입니다. 저는 가난한 학생이라서 서버를 호스팅 받고 도매인을 사서 워드프레스를 돌리기에는 부담이 크니까요.
일단 티스토리에 자리잡은 이상 최대한 뽕을 뽑고 마음에 안 드는 것은 열심히 프로그램 실력으로 극복한다가 일종의 신념처럼 되어 버렸습니다.
이번 스킨은 ‘그냥 멋지고 이쁜 스킨을 만들어야 겠다’라는 마음보다는 실험을 해봐야 겠다는 목적이 짙었습니다. 스킨 제작에 약 3일이 소요되었는데, 첫 번째 날은 티스토리의 기본스킨을 CSS싹 걷어내고 코드로 이런저런 시도를 해보느라 하루를 다 보내었습니다. 주요 태스트 한 항목은 어떻게 구조를 짤까 라는 것이었죠. 오만 삽질을 한 끝에 별도의 스킨을 적용 할만한 구조로 마크 업을 짰습니다.
마크업 경량화
마크업도 이번 스킨의 중요 요소중 하나 입니다. 제가 자리를 비우는 동안은 블로그 관리가 안 될 것이기 때문에 거지 같은 티스토리의 댓글 기능이나 방명록, 트랙백 기능은 신뢰하지 않았습니다. 그래서 필요 없다 싶은 요소는 전부 버렸습니다.
티스토리 블로그는 정말 기능이 많지만 (그렇다고 쓸만한건 거의 없지만) 현재 블로그 스킨에서는 매인화면, 포스팅, 검색, 방명록만 작동하게 만들었습니다. (심플함의 수준의 거의 이글루스급) 나머지 위치로그, 키로그, 미디어로그, 태그로그는 전부다 제거 해버렸습니다. 지금은 들어가면 기본 스타일만 적용된 페이지가 뜨는데 조만간 404 페이지로 바꿀 예정입니다.
그렇게 쓸데없는 것은 가차 없이 제거하다보니 기본 마크업은 300줄이 체 되지 않습니다. 여태까지 스킨을 4개 만들었는데 그중에 가장 마크업이 복잡했던 프로토타입이 1700줄인걸 감안할때 정말 경이로운 감량이라고 볼만합니다. 게다가 아직 최적화나 코드 정리를 하지 않았는데도 300줄인걸 감안하면 정리 후에는 200줄 대로 접어들 수도 있을거라고 생각됩니다.
그래서 이 삽질의 주요성과는 무엇인가하면… 페이지마다 다른 레이아웃 적용이 가능 하는 것과, 단일 CSS만으로도 여러 카테고리 별 스킨을 구현 할 수 있다는 것이 핵심입니다.
지금은 딱 기본 요소만 만들었지만 추가로 확장팩 처럼 제가 자주 포스팅하는 부분에는 카테고리별 스킨을 적용 해볼 계획을 갖고 있습니다. 레이아웃 별 스킨 덕분에 css의 크기는 평소의 5배 정도 될듯합니다. -ㅅ- 그런데 브라우저라는 놈은 css가 아무리 커도 여러개 있는것보다 빨리 불러온다는게 함정이죠 -_-;;; 상식적으로 생각하면 대빵 큰 똥을 한번에 싸는거랑 토끼똥을 여러번 누는거랑 비슷한데(비유가 졸라 더럽죠?) 이상하게도 브라우저는 전자가 빠릅니다. -_-;;;;
플랫 디자인은 절대로 쉬운게 아니다
둘째날 부터 포토샵으로 목업뜨고 바로 코딩으로 들어갔습니다. 플랫 디자인으로 넘어온 뒤의 가장 큰 특징은 별로 디자인 할게 없다는 겁니다. 사실 이게 스큐어모픽 한 디자인보다 더 골때리는 점이죠. 보여줄게 없으니 타이포나 요소간의 간격/ 황금비 같은 아주 골때리는 부분을 생각해야 합니다. 플랫 디자인이 쉬워보이면서 결코 쉬울 수 없는 이유가 바로 이런 문제 때문이죠.
처음 Article 부분을 만들 때 신경 써서 만들었지 나머지 검색이나, 방명록 부분은 기존 요소 재활용이라서 그리 어렵지 않게 작업했습니다. 공지사항 용으로 1단형 스타일도 만들었는데, 특정 카테고리 글에는 1단형 스타일을 적용 시켜볼 생각입니다.
더 이상 웹사이트 크기에 절대 진리는 존재 하지 않는다.
이번에 한 쓸데없는 짓 중 하나는 초대형 레이아웃을 실험적으로 시도 해봤다는 것 입니다. 불과 2년 전만 해도 웹디자인의 절대 진리는 960픽셀이었고 그후 2010년대가 넘어가면서 슬슬 1170이나 1280등 적당히 타협을 보려는 움직임이 일어나고 있습니다. 컴퓨터의 화면은 갈수록 대형화, 고화질화 되어가고 있음에도 일반 웹사이트는 이런 대세에 전혀 발 맞추지 못하고 여백만 잔뜩 남기는 결과를 초래하고 있죠. 제가 쓴 방법은 초대형 레이아웃에서도 실험적으로 도입한 부분으로 하단 부까지 전부 일렬로 나열해 버리는 방식입니다. 아쉽게도 하단 부는 그리드에 넣지 않아서 저렇게 오른쪽 정렬만 하고 치웠습니다. 혹시나 해상도가 1920을 넘어가는 가로 폭 2880의 모니터를 가지고 계신 분은 최대 크기로 했을때 저런 모습을 볼 수 있을 겁니다.
N 스크린의 시대와 스마트 티비의 등장으로 더 이상 웹사이트 크기의 절대 진리는 없어져 버렸습니다. 미디어 쿼리로 다시 한번 또 중복 코딩을 해야 하기 때문 귀찮기는 했지만 그나마 2880 이상의 초대형 스크린까지 지원 했다는 것에 의의를 둡니다.
이전 스킨은 진짜 솔직히 말해서 미디어 쿼리는 손도 안 댔습니다. 미디어 쿼리 자체가 너무 지저분한 방식으로 작성을 해야 되고 크기 별로 놓다보면 햇갈리는지라 저는 별로 안 좋아 합니다. 그래서 모조리 클래스로 때웠더니 브라우저 요청이 너무 많아져서 속도가 개판이 되는 참사가 일어났습니다. -_- 그래도 이렇게 느려터진 구조를 어찌 됐든 빠르게 움직이려고 발악을 하다보니 속도 향상 용 트릭을 여럿 알게 되었네요.
참고하면 좋은글: 960px 이후의 세상: 대형 스크린을 위한 디자인
트롤링
스킨 전반을 보시면 CSS3의 향연입니다. 애니메이션, 그라디언트, 등등등 전부다 CSS3 요소이며 거의 스타일에 애니메이션으로 도배를 했습니다. 심지어 미디어 쿼리에도 애니메이션을 넣었죠. 그래서 이 스킨은 IE9는 고사하고 IE10이상은 되어야 정상적으로 돌아 갈 것 같습니다.
그래서 방문자의 50%에 육박하는 IE사용자는? 이라고 물어보신다면 제게도 생각이 있습니다. 일단 IE만의 독자적인 표준에 맞추기 위해서 IE5를 가지고 CSS1로 스타일을 작성할 계획입니다. 스타일은 1995년도 웹사이트를 기준으로 짤 계획입니다. 웹폰트 대신 gif 이미지를 잔뜩 쓸 계획이고요. CSS1 기반이니 대한민국 사람들이 정말 좋아하는 IE6에서는 아주 잘 돌아갈 것이라 생각됩니다.
왜 이런 짓을 하냐고 물어보신다면… 최신 브라우저 설치하라고 뭐라하는 것도 솔직히 지쳤습니다. 격리수용소 삼아서 똥밭을 하나 만들어주면 IE5,6,7,8 사용자들은 거기 따로 모여서 잘 지낼게 분명하므로 이런 조치를 취하는 것입니다. IE전용 페이지에는 최신 브라우저를 쓰라는 권유를 한마디도 넣지 않을 겁니다. 그 대신에 굴림과 궁서, 반짝이는 gif이미지, 1024px용 폰트 사이즈, 테이블 테두리 같은 요소로 빈티지의 향수를 느끼게 해드리겠습니다.
현재 Life is Journey 스킨은 100% 완성이 아닙니다. 아직 압축도 하지 않았으며, 추가 레이아웃도 넣지 않았습니다. 그리고 IE 전용 지원도 되지 않았고요. 기본 틀을 가장 빠른 시간 안에 잡았다는 것만 기념으로 삼으려고 합니다.
바로 이 이유 때문에 후기를 릴리즈 노트 보다 먼저 적는 것입니다. 사실 후기라고 하기도 뭐하죠. 스킨이 다 완성된게 아니니… 그러니까 ‘이러이러한 시도’를 해봤는데 ‘결과가 이렇더라’ 라는 보고서? 정도로 생각하시면 될 것 같습니다.
결론은 간단 합니다.
티스토리에서 화면 별 레이아웃을 적용 할 수 있다 → 참
티스토리에서 카테고리 별 스킨을 적용 할 수 있다 → 참
티에디션을 꺼버리고 자신만의 티에디션을 만들어 넣을 수 있다. → 참
배포용 스킨도 이런 기능을 가질 수 있다. → 거짓
