si.mpli.st v3 - Sketch, Gulp, cssnext

2012년 블로그 디자인을 바꾸고 글을 많이 쓰진 않았지만, 최근들어 다시 글을 쓰기 시작하면서 블로그 테마를 바꾸고 싶다는 생각이 점점 들었다. 이전에 작성했던 CSS가 깔끔하지 않기도 했고, 최근 프론트엔드 작업을 하지 않으니 회사 외적으로 재충전의 기회가 될 것 같다는 이유가 컸다.

폰트 고르기

회사에서는 쭉 Adobe Creative Cloud를 사용하고 있지만, 개인적으로는 디자인을 할 때 쓰는 소프트웨어도 Sketch로 바꿨으니 Lightroom과 Typekit만 그만 사용하면 모든 어도비 제품을 사용하지 않을 수 있게 되는 것이다. Lightroom의 경우에는 바꿀만한 매력이 있는 대체제를 찾기가 힘들어서 보류하고 있지만, Typekit은 기존 블로그에 쓰던 Futura PT와 Myriad Pro만 대체하면 사용할 필요가 없어지는 것이다.

Google Web Fonts 등의 사이트에서 어떤 폰트를 사용할까 찾아보다가, 이전에 Stripe가 사용하는 폰트에서 깔끔하다는 인상을 받은 적이 있어 어떤 폰트를 사용하는지 찾아보았다. Stripe 로고와 웹사이트는 Ideal Sans를 사용하고 있는데, 이 폰트는 Hoefler & Co.라는 파운더리가 제작한 폰트였다. typography.com 라는 도메인부터 범상치 않은 기운이 느껴졌는데, 트위터 등이 사용하고 있는 유명한 폰트 Gotham을 제작한 회사였다. 뛰어난 폰트의 품질만큼 가격 또한 만만치 않았는데, Cloud.Typography라는 웹폰트 프로그램을 운영하고 있었다. 5개의 폰트를 사용할 수 있는 프로그램의 시작 가격이 연간 $99였는데, 기존에 Adobe Creative Cloud에 지불하고 있던 비용을 생각해보면 크게 부담이 되지는 않아 바로 가입하였다.

내가 고른 폰트는 Whitney로, 중립적이면서도 나름의 개성을 가지고 있어 제목과 본문에 모두 사용하였다. 또한 Google Fonts Early Access에서 사용할 수 있는 Noto Sans KR을 fallback으로 지정해 두었다.

디자인

프로토타이핑을 할 때 HTML과 CSS로 바로 디자인을 시작하는 사람들도 있지만, 나는 아이디어를 구체화 시킬 때의 자유도 때문에 그래픽 디자인 소프트웨어에서 목업을 먼저 만들어 보는 것을 선호한다. 최근 포토샵에서 Sketch로 넘어온 만큼 이번에도 Sketch로 디자인을 했다.

키노트를 사용하는 것 처럼 슥슥 만들다보니 스케일이 안 맞았지만, 참고용으로 제작한만큼 따로 수정은 안 했다. 😅

스타일시트

오래 전부터 LESS를 이용하여 깔끔한 스타일시트를 만들고 있었지만, GitHub Pages가 제공하는 빌드 시스템을 그대로 사용해 호스팅을 하기 위해 이전 스타일시트는 별도의 전처리기(preprocessor)를 사용하지 않고 제작했다. 그러다보니 스타일시트가 깔끔하지 않았고, 나중에 작은 부분을 수정하려고 해도 내가 쓴 코드를 이해할 수 없었다. 그래서 이번에는 전처리기를 써서 스타일시트를 작성하기로 했고, 이왕 새롭게 하는 겸 비교적 최근에 나온 전처리기인 **cssnext**를 사용하기로 했다. 표준화 되고 있는 차세대 CSS 문법들을 먼저 사용해볼 수 있는 전처리기인데, PostCSS에 붙여서 사용할 수 있다. 기존 CSS 코드와의 호환성을 유지하기 위하여 다른 전처리기처럼 깔끔한 문법을 사용할 수는 없는데, 가령 variable을 정의하고 사용하는 문법은 다음과 같다.

:root {
  --primary-font-family: Menlo, Consolas, Courier, monospace;
}

.codeblock {
  font-family: var(--primary-font-family);
}

완성된 스타일시트는 **GitHub**에서 확인할 수 있다.

빌드 시스템

cssnext 문법으로 작성된 스타일시트를 그대로 사용할 수는 없으니 배포하기 전에 전처리기를 구동해야 하는데, 그러기 위해서는 기본적인 빌드 시스템이 필요했다. 선호하는 도구에 따라 여러 가지 방법이 있겠지만 내가 고민해 본 방법은 다음과 같다.

postcss-cli를 이용하여 별도의 빌드 도구 없이 구동
Gulp를 사용
Grunt를 사용

postcss-cli를 사용하는 방법이 가장 간단했지만 그러면 Jekyll의 watch 커맨드(bundle exec jekyll serve --watch)와 PostCSS의 watch 커맨드(postcss-cli --watch)를 따로 실행해야 해서 복잡했다. Grunt의 경우 이전에 꽤 많이 쓰기도 했고 최근에는 안 쓰이는 추세라고 해서 Gulp를 선택했다.

Jekyll을 정적 사이트 생성기로 사용해서 루비 의존성을 완전히 없앨 수는 없고, Jekyll 프로세스를 child_process.spawn으로 실행하는 Gulp task를 다음과 같이 만들어서 사용하였다.

gulp.task("jekyll", (cb) => {
  return child_process.spawn("jekyll", ["build"], {stdio: "inherit"})
                      .on("error", (error) => console.log(`Error: ${error}`))
                      .on("close", (code) => {
                        /* ... */
                        cb(code);
                      });
});

완성된 gulpfile.js는 **Github**에서 확인할 수 있다.

빌드 및 배포

기존에는 GitHub Pages가 빌드와 배포를 모두 담당하였다면, Gulp를 섞어 쓰기 시작한 이후로는 GitHub Pages를 사용할 수 없게 되었다. 그래서 Travis CI에서 빌드를 한 후, 정적 웹사이트 호스팅이 켜져 있는 Google Cloud Storage 버킷으로 배포하도록 설정하였다. 빌드에 사용되는 .travis.yml은 다음과 같다.

language: node_js
node_js:
  - 5.11.0

...

before_install:
  - rvm install 2.3.0
  - npm install -g gulp-cli

before_script:
  - bundle install

script:
  - gulp build

deploy:
...

마치며

디자인부터 스타일시트 작성, 배포까지 걸린 시간은 약 이틀 정도. 새로운 기술을 배우는 것 치고는 시간이 짧게 걸려서 만족스럽다. 이제 블로그에 글을 자주 올리는 일만 남았다!