유스풀패러다임

Jekyll 테마(Theme) 다루기

2018-04-30T00:00:00+00:00

지킬(Jekyll)은 정적 웹사이트 빌더(static site builder) 도구입니다. 간단하게 웹사이트나 블로그를 만들 때 유용하게 사용할 수 있죠. Jekyll은 워드프레스나 여타 다른 웹사이트 빌더들에 비해 몇 가지 장점이 있습니다.

사용법이 간단
마크다운(Markdown) 기반
GitHub Pages에서 무료 호스팅 지원
다양한 테마 및 플러그인, 편집기(editor) 생태계 보유
확장 가능한 테마 시스템

이 글에서는 이 중 Jekyll의 테마 시스템과 그 사용법을 소개합니다.

아주 간단한 테마

앞서도 말했듯 Jekyll은 정적인 웹사이트 빌더입니다. 그러니 실은 HTML파일만 있으면 됩니다. 여기에 CSS로 약간의 스타일링을 추가하면 더 좋겠죠.

아무 디렉터리나 하나 골라 다음과 같이 간단하게 index.html 파일을 하나 만들고 jekyll serve 명령을 줍니다.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Hello Jekyll</title>
</head>
<body>
  
  <h1>Hello, Jekyll!</h1>
  
</body>
</html>

그런 다음 Jekyll 서버 기본 포트인 4000번 포트로 접속하면 다음과 같이 웹사이트가 작동합니다.

방금 전 만든 디렉터리에 가보면 아래와 같이 _site라는 이름의 디렉터리가 하나 자동으로 추가된 것을 확인할 수 있습니다.

이처럼 Jekyll은 실행 시점에서 필요한 리소스 파일들을 컴파일하여 디폴트로 _site 라는 디렉터리 아래에 둡니다. 이 디렉터리가 실제로 우리가 웹 상에서 보게되는 파일들이 위치하는 디렉터리입니다. (흔히 “public 폴더”라 부르는 곳인 셈이죠)

이제 간단한 페이지를 하나 추가해 보겠습니다. 파일명을 about.md 라고 주고 이번엔 pages 라는 하위 디렉터리를 하나 만들어 그 속에 두겠습니다. (이 때 파일 앞 부분에 빈 Front Matter 영역을 둔 이유는 이렇게 해야만 Jekyll이 md 파일을 html로 변환하기 때문입니다. Jekyll은 Front Matter가 있는 모든 파일들을 대상으로 변환 처리를 합니다)

---
---
# About Us

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quod dicit Epicurus etiam de voluptate, quae minime sint voluptates, eas obscurari saepe et obrui. Hic, qui utrumque probat, ambobus debuit uti, sicut facit re, neque tamen dividit verbis.

마찬가지로 jekyll serve 명령을 실행한 후 웹 브라우저에서 접속해 보면 다음과 같이 마크다운 파일이 html로 변환되어 _site/pages 디렉터리 아래에 놓여 있음을 알 수 있습니다.

이런 식입니다. Jekyll은 프로젝트 폴더 내의 파일들을 Jekyll의 관례와 규칙에 따라 해석하여 최종적으로 정적인 웹사이트를 _site 디렉터리에 생성합니다. 이게 전부입니다.

루비 젬 기반 테마(gem-based themes)

Jekyll 3.2 버전부터는 새로 젬 기반 테마(gem-based theme)라는 개념이 도입되었습니다. 이 개념이 나오기 전까지는 Jekyll에서 다른 사람이 만든 테마를 가져다 쓰려면 앞서와 같이 프로젝트 디렉터리에 테마 파일 전체를 복사해 넣고 수정하는 방식으로 테마를 관리하는 방법 밖에 없었습니다.

젬 기반 테마의 경우, 테마 파일이 루비 젬(gem) 패키지 파일 형태로 배포되기 때문에 이 테마를 가져다 쓸 사람들은 일일이 복사하여 넣을 필요 없이 루비 젬 설치 명령으로 해당 테마 파일을 설치하면 바로 테마가 작동합니다.

이는 마치 워드프레스 테마 시스템과 유사합니다. 워드프레스에서는 자식테마(Child Theme) 개념을 지원해서 부모 테마를 상속받고 필요한 부분만 수정하여 사용하는 방식을 제공하며 또 권장되기도 합니다. Jekyll의 젬 기반 테마는 이 자식테마와 유사한 개념입니다.

그럼 이번엔 젬 기반 테마 방식으로 테마를 한번 설치해 보겠습니다.

흔히 Jekyll 사이트를 새로 만들 때는 jekyll new 명령을 사용하지만, 여기서는 jekyll new 명령 대신, 앞서 만들던 지점에서 이어나가 보기로 하겠습니다. (참고로 jekyll new 명령으로 생성되는 사이트는 Minima라는 젬 기반 테마를 디폴트로 설치합니다)

여기서는 Minimal Mistakes라는 테마를 한번 설치해 보기로 하겠습니다. Minimal Mistakes는 Jekyll 테마 중 가장 인기 있는 테마 중 하나입니다.

우선 터미널에서 테마 젬 파일을 설치합니다.

$ gem install minimal-mistakes-jekyll

설치가 완료되면 이어 프로젝트 루트 디렉터리에 _config.yml 이라는 파일을 하나 생성하여 다음과 같이 테마를 지정합니다.

title: Hello Jekyll
theme: minimal-mistakes-jekyll

마지막으로 index.html 파일을 열어 다음과 같이 변경합니다.

---
layout: home
---

끝입니다. 이제 다시 jekyll serve 명령을 실행한 후 브라우저에서 보면 그림과 같이 Minimal Mistakes 테마가 정상적으로 적용된 것을 확인할 수 있습니다.

그럼 디렉터리 구조는 어떨까요? 궁금한 분들은 직접 한번 확인해 보시기 바랍니다.

물론 모든 Jekyll 테마들이 젬 기반 테마인 것은 아니며, 이럴 경우 이전 방식(테마 파일 전부를 프로젝트 디렉터리에 붙여 넣는 방식)으로 사용할 수 밖에 없다는 점에 유의해야 합니다. 어떤 테마가 젬 기반인지 여부는 보통 해당 테마의 문서에 적혀 있습니다.

어떤 방식이 좋을까요?

젬 기반 테마를 썼을 때 좋은 점은 무엇일까요? 무엇보다 테마 자체의 업데이트가 쉽다는 게 가장 큰 장점입니다. 테마를 별도의 젬 파일로 관리하기 때문에 테마의 업데이트가 필요할 때면 gem update 명령만 주면 됩니다. 또한 실제 관리하는 사이트의 파일 구조가 간단해 지는 점도 장점일테죠.

그렇지만 젬 기반 테마가 반드시 장점만 있는 건 아닙니다. 일단 시중에 나와 있는 모든 테마가 다 젬 기반을 지원하는 것은 아닙니다. 그리고 테마에서 커스텀 영역이 많아질수록 젬 기반 테마가 갖는 장점은 적어 질 수 밖에 없습니다.

앞서도 말했듯, 젬 기반 테마는 워드프레스의 자식테마와 개념이 비슷합니다. 반면 테마파일을 그대로 가져다 수정하는 방식은, 워드프레스로 치면 테마 파일 자체를 건드리는 방식입니다. 둘 중 어느 게 더 나은 방법인지는 사실 프로젝트의 성격에 따라 다르기 때문에 하나로 이거다 결론 짓기가 애매한 부분이 있습니다만, Jekyll 사이트라면 이렇게 말하는 게 좋을 것 같습니다: “젬을 제공하는 테마라면? 젬 기반으로 쓰고, 그렇지 않으면 직접 복사해서 쓰세요!” 라고 말이죠!

참고자료

Hugo와 Netlify로 '스매싱' 웹사이트 만들기

2017-11-24T00:00:00+00:00

웹 디자이너와 개발자들이 즐겨 찾는 인기있는 웹사이트 중 하나인 스매싱매거진(Smashing Magazine)이 최근 리뉴얼 되었습니다.

이번 리뉴얼은 그간 사용해 오던 WordPress 대신 Hugo라는 CMS 도구를 썼고 또 Netlify라는 서비스를 이용해 호스팅한 점이 특히 눈에 띕니다.

관련 글:

이 글에서는 이 둘의 사용법을 간단하게 정리해 봅니다.

Hugo로 웹사이트 만들기

Hugo는 한마디로 정적 웹사이트 생성기(static website generator)입니다. Jekyll을 접해 보신 분에겐 아마 ‘Go 언어로 작성된 Jekyll’이라고 소개하는 게 더 잘 와닿을 지도 모르겠습니다. (물론 Hugo는 기분 나쁠 수 있습니다. 어디 감히 함부로 대문호의 이름을 한낱 작품 주인공 이름과 비교하다니요?)

어쨌거나, Jekyll이나 Hugo 같은 웹사이트 생성기의 좋은 점은, 간단하게 웹사이트를 만들고 콘텐츠를 바로 바로 퍼블리싱 할 수 있는 구조(틀)와 도구를 제공한다는 점에 있습니다. Hugo 역시 마찬가지구요.

맥OS 사용자라면 터미널 명령으로 다음과 같이 간단하게 사이트의 뼈대를 만들 수 있습니다.

$ brew install hugo
$ hugo new site hello-hugo

성공적으로 사이트가 만들어지면, 친철하게도 Hugo가 다음 단계를 알려 줍니다.

Congratulations! Your new Hugo site is created in /hello-hugo.

Just a few more steps and you're ready to go:

1. Download a theme into the same-named folder.
   Choose a theme from https://themes.gohugo.io/, or
   create your own with the "hugo new theme <THEMENAME>" command.
2. Perhaps you want to add some content. You can add single files
   with "hugo new <SECTIONNAME>/<FILENAME>.<FORMAT>".
3. Start the built-in live server via "hugo server".

Visit https://gohugo.io/ for quickstart guide and full documentation.

위에서 Hugo가 알려준 대로 이제 테마를 하나 설치해 보겠습니다.

Hugo Themes 디렉터리에 보면 Hugo에서 사용할 테마들이 많이 있습니다.

물론 테마를 직접 만들어도 되지만, 여기서는 이 디렉터리에 있는 테마 중 하나를 골라 적용해 보도록 하겠습니다. 제 취향으로 ‘Bilberry Hugo Theme’ 테마를 선택해 보겠습니다.

테마를 클릭해 보면 테마에 대한 자세한 설명 및 데모(demo)와 함께 이 테마의 설치 방법 등이 자세히 소개되어 있기 때문에 그대로 따라하기만 하면 됩니다.

cd hello-hugo/themes
git clone https://github.com/Lednerb/bilberry-hugo-theme.git

(만약 git을 사용하지 않는다면, 테마 파일을 다운로드 받아 themes 디렉터리 아래에 압축을 풀어 놓아도 상관없습니다)

테마 파일을 설치했다면, 이제 마지막으로 프로젝트의 루트 디렉터리에 있는 config.toml 파일을 열어 다음과 같이 테마를 지정해 줍니다. 방금 전 설치한 테마 파일의 디렉터리명과 일치시켜주면 됩니다.

theme = "bilberry-hugo-theme"

이제 터미널에서 hugo server 명령으로 웹서버를 실행한 다음 브라우저에서 http://localhost:1313/ 로 접속해 보면, 다음과 같이 웹사이트가 표시되는 것을 확인할 수 있습니다. (테마의 DEMO에서 보는 것과 같은 좀 더 멋진(?) 디자인을 지금 당장 확인해 보고 싶다면, 테마 속에 들어 있는 exampleSite 폴더를 프로젝트의 루트 내로 복사하여 붙여 넣으면 됩니다)

새 포스트를 추가하려면, 다음과 같이 터미널에서 hugo new 명령으로 간단하게 추가할 수 있습니다.

$ hugo new post/어서와-휴고는-처음이지.md

위 명령으로 새 포스트를 추가한 다음, 프로젝트의 content/post 폴더 아래에 가보면 방금 생성한 새 포스트 파일이 추가되어 있는 것을 확인할 수 있습니다. 파일을 열어 포스트의 내용을 적절하게 채워주면 나머지 작업은 Hugo가 알아서 처리합니다.

금방 뚝딱 새 포스트가 하나 만들어 졌네요.

여기까지 따라했다면, 지금까지의 내용을 GitHub에 저장합니다. (이 단계는 나중에 배포할 때 필요한 부분이며, GitHub에 저장하기 방법에 관한 별도 설명은 생략합니다)

지금까지의 내용은 Hugo의 아주 기본적인 사용법만 보인 것일 뿐, Hugo는 정말이지 그 이름에 걸맞게 멋진 기능들을 많이 갖추고 있습니다. Hugo의 더 자세한 기능과 사용법은 Hugo 문서를 참조하세요!

Netlify로 사이트 배포하기

대부분의 정적 사이트 생성기가 그렇듯, Hugo 역시 사이트 배포(deployment)와 관련해 다양한 옵션들을 제공합니다. (GitHub Pages로 배포도 가능은 하지만, GitHub Pages에 배포할 경우라면 아무래도 Jekyll을 쓰는 게 낫겠죠?)

앞서도 소개했듯 최근 리뉴얼된 스매싱매거진(Smashing Magazine)이 Netlify를 사용 하기에, 여기서도 Netlify를 한번 사용해 보기로 하겠습니다. (사실 웹사이트 생성기는 최종 산출물 디렉터리만 호스팅 서버에 올리면 되기 때문에 웹서버 기능만 갖춘 곳이라면 어디든 배포가 가능합니다)

Netlify는 배포 자동화 기능을 갖춘 호스팅 서비스입니다. 굳이 비교를 하자면 Heroku와 유사한 서비스라고 할 수 있지만, Heroku가 주로 서버측 애플리케이션을 호스팅하는 반면, Netlify는 프론트엔드(frontend) 코드를 호스팅한다는 점에 차이가 있습니다. CDN과 지속적 배포(continuous delivery) 도 지원합니다.

Netlify 서비스에 가입하면 아래와 같이 대시보드가 나옵니다. 아직 아무 것도 없는 빈 대시보드입니다.

좌측 상단의 “New site from Git” 버튼을 클릭합니다 (맞습니다! Netlify에 코드를 배포하기 위해서는 Git 저장소가 필요합니다). 다음과 같이 사이트 생성 화면이 열립니다.

여기서는 GitHub를 사용해 보겠습니다. (앞서 저장해 두었던 것을 기억하나요?) “GitHub” 버튼을 눌러 나오는 인증(authorize) 팝업창에서 인증을 완료하면 저장소를 선택하는 페이지가 나옵니다.

이 때 앞서 미리 저장해 두었던 Hugo 사이트의 git 저장소를 선택합니다. 그러면 설정의 마지막 단계로 몇몇 셋팅값을 입력하는 부분이 나옵니다. 여기서 build settings값을 다음과 같이 설정하고 “Deploy site” 버튼을 누릅니다.

잠시.. 기다립니다. 그동안 Netlify는 GitHub 저장소로부터 파일을 불러와 자동으로 빌드하고 배포합니다. 배포 과정은 Delply log로 확인할 수 있습니다.

정상적으로 배포가 완료되면 아래와 같이 사이트 배포가 완료되었다고 나옵니다.

끝입니다. Netlify가 자동으로 URL도 하나 만들어 주기 때문에, 대시보드에 나와 있는 이 URL로 접속하면 사이트가 인터넷 상에 퍼블리싱된 것을 바로 확인할 수 있을 것입니다. 도메인명은 ‘brave-bohr-eabe89.netlify.com’ 에서처럼 임의로 주어지지만, 나중에 변경할 수 있습니다.

Netlify는 자동 배포(auto publishing) 기능이 기본으로 켜져 있어서, 이후 GitHub 저장소에 추가되는 모든 업데이트는 Netlify에 의해 감지되어 자동으로 배포가 일어납니다. 새로운 컨텐츠를 올릴 경우에도 GitHub에만 올려 주면 됩니다. (물론 이 옵션은 꺼 둘 수 있습니다)

그 밖에 사이트의 도메인명을 변경하거나 커스텀 도메인을 추가하고 HTTPS를 적용하고 하는 과정들은 Netlify에 잘 나와 있어 별도 설명은 생략합니다.

지금까지 본 것처럼, Netlify는 Git 저장소와 연동하여 간단하게 프론트엔드 웹앱(SPA)이나 웹사이트를 배포할 때 사용하면 좋은 서비스입니다. Netlify에 관한 더 자세한 내용은 Netlify 문서를 참조하세요!

※ 몇 가지 유의사항: Hugo 사이트를 Netlify로 배포할 때

Hugo 사이트를 Netlify에 배포하는 경우, Hugo 테마를 위에서 했던 것처럼 clone 하거나 다운로드 방식으로 설치하면 작동하지 않습니다. git의 submodule을 사용해서 테마를 설치해야 하며, 그 이유와 자세한 내용은 여기를 참조하면 됩니다.
이 글을 쓰는 현재, Hugo의 버전을 Netlify에 알려줘야 한다고 되어 있습니다. netlify.toml 파일을 만들어 버전 정보를 적어 주거나 Netlify 콘솔에서 HUGO_VERSION 환경변수를 셋팅하는 방식으로 설정 가능합니다. 자세한 내용은 여기를 참조하세요!

플라타너스트리 2017 Updates

2017-11-04T00:00:00+00:00

책 읽는 좋은 습관! 온라인 책 관리 서비스 플라타너스트리가 업데이트 되었습니다.

이번 업데이트는 새 기능의 추가 보다는 기존에 있던 기능들의 사용성을 개선하는 데 좀 더 초점을 맞췄습니다.

주요 업데이트 내용은 다음과 같습니다.

UI 테마 업데이트

플라타너스트리는 오픈소스 UI 프레임워크인 Twitter Bootstrap을 사용합니다. 이번 업데이트에서는 Bootstrap의 버전을 v3에서 v4 (v4.0.0-beta.2)로 판올림하였으며 이에 따라 지원하는 브라우저가 변경됩니다.

IE8, IE9와 iOS 6은 지원하지 않으며 IE10+ 및 iOS 7+ 만 지원.
Android v5.0 Lollipop’과 WebView.

모바일 우선 디자인

PC(데스크톱) 버전의 서재 목록 구성도 모바일 버전처럼 목록이 일렬로 배열되어 목록 관리가 좀 더 간단해 졌습니다.

책 상세 페이지 UI 개선

책 상세 페이지에서 읽기 상태를 관리하고 노트를 작성하는 부분이 좀 더 편리해 졌습니다.

기타

월별 모아보기. 내 서재에서 책 목록을 월별로 모아 볼 수 있습니다.
❤️ Favorite 버튼. 내가 좋아하는 책만 따로 보관할 수 있습니다. 다른 사람이 Favorite 한 책도 로비에서 확인 가능 합니다.

플라타너스트리는 계속 자랍니다.

즐겁게 사용하세요! ~

Craft CMS로 콘텐츠 중심 웹사이트 만들기

2017-09-22T00:00:00+00:00

요즘은 웹사이트 만드는 일이 별로 어렵지 않다. 시중에는 워드프레스(WordPress) 처럼 쉽고 편리한 도구들이 많이 나와 있고 온라인 상에는 가입만 하면 바로바로 쓸 수 있는 웹사이트 호스팅 서비스들도 많다. 랜딩 페이지(landing page) 처럼 좀 더 가벼운 웹사이트라면 지킬(Jekyll)이나 휴고(Hugo) 같은 정적 페이지 빌더를 사용하면 그만이다.

이렇게 많은 도구들이 세상에 이미 존재하는데 또 무엇이 필요할까?

블로그처럼 웹사이트에 담기는 내용이 간단한 글(post) 이거나 브로셔나 랜딩 페이지처럼 몇 장의 소개 페이지 정도라면 걱정할 게 없다. 워드프레스 설치하고 테마 하나 입혀 뚝딱 만들면 된다. 필요한 기능이 있다면 플러그인 몇 개 찾아 설치하면 그만.

그런데 만약 좀 더 복잡하고 다양한 콘텐츠를 담아야 하는 웹사이트라면? 가령,

다양한 유형의 미디어 콘텐츠들을 담아서 보여주는 미디어 사이트
다양한 강의 내용이 담긴 온라인 강좌 사이트
여러 종류의 음식 레시피를 담고 있는 요리 정보 사이트
다양한 제품에 대한 정보를 제공하는 리뷰 사이트
기업과 채용에 관한 정보를 모아 둔 온라인 채용 사이트

여기서 중요한 것은 콘텐츠(content) 다. 미디어 사이트라면 ‘미디어’가 콘텐츠가 되고 온라인 강좌 사이트는 ‘강의’가 콘텐츠이고 제품 사이트라면 ‘제품’이 요리 사이트에는 ‘레시피’가 콘텐츠인 셈이다. 결국 웹사이트는 콘텐츠를 담는 그릇이고 그 콘텐츠를 얼마나 잘 담을 수 있냐가 관건이 된다.

이런 콘텐츠 중심의 웹사이트를 만들려면 어떻게 하면 좋을까?

워드프레스를 쓰면 되지 않나?

물론 워드프레스로도 못할 건 없다. 혹은 여력이 되면 루비온레일스나 장고, 라라벨 같은 웹 프레임워크를 사용해서 직접 만들어도 된다. 하지만 전자는 필요 이상으로 친절(?)하고 후자는 해야할 일이 너무 많다. 이 둘의 어느 중간 지점 쯤에 있는 도구면 좋지 않을까? 적당히 친절하면서 그렇다고 너무 버겁지도 않은.

안녕하세요, Craft!

Craft CMS(이하 ‘Craft’)는 바로 그 지점, 즉 ‘콘텐츠’ 그 자체에 초점을 맞춘 웹사이트 제작 도구다. 어떻게 하면 다양한 콘텐츠들을 가장 잘 표현하고 가장 잘 담을 수 있을까에 방점을 찍었다.

Craft는 Pixel & Tonic 에서 만든 오픈소스 CMS 솔루션으로 PHP 웹 프레임워크인 Yii framework를 기반으로 하고 있다. 2017년 9월 현재 최신 버전은 2.6.x 이며 버전 3은 베타 버전 상태다.

이 글에서는 Craft를 설치하고 음식 레시피를 만들어 올리는 간단한 레시피 사이트를 한번 만들어 보면서 Craft의 주요 개념과 기본 사용법을 소개하기로 한다. 워드프레스에 익숙한 분들을 위해 중간중간 워드프레스와 비교하면서 설명을 할 예정이니 참고 바란다.

자, 그럼 시작해 보자!

Craft 설치하기

설치는 비교적 간단한 편이며 설치 방법도 워드프레스 비슷하다.

Craft 사이트에서 소스코드를 다운로드 받아 압축을 푼다.
Craft를 위한 데이터베이스를 생성: $ mysqladmin -uroot -p create hellocraft
데이터베이스 연결 설정: craft/config/db.php 파일 편집
서버 실행 $ php -S 0.0.0.0:8080 -t public/
설치 시작 URL 접속: http://localhost:8080/admin

시작 페이지가 나오면, “시작” 버튼을 눌러 설치를 시작한다.

단계별로 하라는 대로 따라 가면,

설치가 완료된다.

Craft CMS에 접속하여 ‘계기판(Control Panel)’이 나오면 설치가 끝난 것이다.

첫 느낌이 어떤가? 워드프레스와 비슷하다. 관리자 화면의 UI도 워드프레스와 비슷하지만 한눈에 봐도 메뉴가 훨씬 단촐하다. 좌측 사이드의 메뉴라고는 ‘계기판’, ‘엔트리’, ‘설정’이 전부다.

테마는 없다

워드프레스와 달리 Craft에는 테마가 없다. 따로 테마(theme)라는 개념이 없다. 처음 설치를 완료하고 웹사이트 URL로 접속하면 아래와 같이 그냥 허접한 Welcome 페이지만 덩그러니 자리잡고 있을 뿐, 워드프레스처럼 테마를 선택하거나 교체하는 그런 건 없다.

Craft에서는 모든 것을 직접 만들어 나가야 한다. 웹사이트 레이아웃을 디자인하고 콘텐츠들을 적절하게 배치하고 하는 모든 일들을 사용자(또는 개발자)가 직접 처리해 줘야 한다. Craft는 다만 한 가지 일, 즉 콘텐츠를 만들고 관리하는 일만 할 뿐이다.

사이트 디자인 변경하기

우선 몸풀기로, 사이트 디자인을 바꾸는 것부터 시작해 보자. 간단하게 Twitter Bootstrap 을 적용할 것이다.

부트스트랩을 다운로드 받아 Craft의 public 폴더 아래에 복사하고, craft/templates 폴더(이하 ‘templates 폴더’) 에 있는 _layout.html 파일을 열자.

기존 인라인(inline) 처리된 style 부분이 보이면 삭제하고 대신 그 자리에 부트스트랩 로딩 코드를 다음과 같이 삽입하자.

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US">
<head>
  <meta charset="utf-8" />
  <title>{% if title is defined %}{{ title }} - {% endif %}{{ siteName }}</title>
  <link rel="home" href="{{ siteUrl }}" />

  <link rel="stylesheet" href="/css/bootstrap.min.css">
  <script src="https://code.jquery.com/jquery-3.2.1.min.js"></script>
  <script src="/js/bootstrap.min.js"></script>
</head>

(여기서는 부트스트랩 소스코드를 다운로드하여 링크를 거는 방식을 택했지만, 다운로드 없이 바로 CDN 링크 방식으로 처리해도 무방하다)

이제 홈페이지에 다시 접속해 보면, 부트스트랩이 적용되어 사이트 디자인이 변경되어 있음을 확인할 수 있다.

이런 식이다. Craft에서는 웹사이트에 필요한 모든 페이지의 디자인을 하나하나 일일이 직접 만들어 줘야 한다. 지금처럼 레이아웃도 그렇고 메인 페이지와 목록 페이지, 각각의 콘텐츠를 표시하는 페이지 등 모든 페이지들을 HTML 코드부터 CSS 스타일링까지 직접 처리해야 한다. 워드프레스로 치면, 커스텀 테마를 직접 만든다고 생각하면 된다.

블로그 포스트 만들기

자, 그럼 이제 Craft의 핵심인 콘텐츠를 한번 만들어 보자. 우선 간단하게 블로그에서 주로 쓰이는 포스트(post)를 한번 만들어 보기로 하자.

어드민 대시보드(Craft에서 이를 Control Panel이라고 하며 흔히 줄여서 ‘CP’라고도 함)에 접속하여 “엔트리” 메뉴를 클릭하면 다음과 같이 보인다. ‘싱글’이라는 게 있고, ‘채널’이라는 제목 아래 ’News’라는 것도 보일 것이다.

News는 Craft가 디폴트로 만들어 놓은 콘텐츠 유형이다.

알다시피 워드프레스에는 기본적으로 2가지의 콘텐츠 유형(content types)이 있다. 포스트(Post)와 페이지(Page). 물론 커스텀 콘텐츠 유형을 추가하는 기능이 제공되지만 이 두 가지 콘텐츠 유형이 중심이며 삭제할 수도 없다.

반면 Craft에는 기본 콘텐츠 유형이라는 게 없다. 사용자가 직접 콘텐츠 유형을 설계하고 만들어야 한다. 방금 전 ‘News’는 기본으로 제공되는 콘텐츠 유형이긴 하지만 Craft가 그냥 샘플로 하나 만들어 둔 것이며 삭제해도 무방하다. 사이트에서 꼭 필요한 콘텐츠 유형을 직접 만들어 사용하는 게 Craft의 기본이다.

포스트 항목 만들기

이런 콘텐츠 유형을 Craft에서는 ‘항목(Entry)’이라고 부른다. 달리 말해 ‘항목’은 Craft에서 콘텐츠의 기본 단위다. 워드프레스에서 ‘글(Post)’이 콘텐츠의 기본 단위인 것처럼.

그럼 ‘포스트’ 항목을 하나 만들어 보기로 하자.

컨트롤 패널(이하 ‘CP’)에서 “설정” 메뉴를 클릭해 보자. 아래와 같은 화면이 보일 것이다.

여기서 항목을 추가하면 될 것 같은데, 아무리 찾아도 ‘항목’이라는 메뉴는 보이질 않는다. 항목을 만들기 위해서는 먼저 ‘섹션(Section)’ 이라는 개념을 알아야 한다.

Craft에서는 섹션이 있고 섹션(Section) 아래에 항목(Entry)이 온다. 즉, 섹션은 항목을 담는 그릇이다. 그리고 이 섹션은 다음 3가지의 유형이 제공된다.

싱글(Singles)
채널(Channels)
구조(Structures)

싱글(Singles) 섹션은 말 그대로 한 페이지 짜리 콘텐츠를 담는데 쓰인다. 예를 들면 메인페이지나 About 페이지 같은. 워드프레스로 치면 페이지(Page) 개념에 해당된다.

한편 채널(Channels) 섹션은 일련의 콘텐츠들을 담는데 사용되는 섹션이다. 블로그나 뉴스스트림, 레시피 목록 등 유사한 콘텐츠들을 한데 담을 때 사용한다. 워드프레스의 포스트(Post) 개념과 같다.

구조(Structures) 섹션은 채널과 유사하지만 일련의 콘텐츠들이 일정한 순서와 계층으로 조직된 경우에 사용되는 섹션이다. 예를 들면, 계층구조를 갖는 매뉴얼 문서라든지 조직체계 같은 콘텐츠를 표현할 때 사용할 수 있다. 워드프레스에는 이 구조 섹션과 동일한 개념은 없다. 다만 페이지를 계층형으로 구성함으로써 구조 섹션과 비슷한 것을 만들어 낼 수는 있을 것이다.

앞서 Craft를 설치하면 바로 보였던 ‘News’ 항목이 무엇인지 이제 조금 이해가 될 것이다. 이 항목은 채널 섹션, 즉 채널 유형이다. 그러니 채널 섹션 아래에 놓여 있었던 것이다.

Craft의 섹션 유형에 관한 더 자세한 내용은 Craft 문서를 참조하면 된다. Sections and Entries | Documentation | Craft CMS

설명이 좀 길었다.

우리가 지금 만들 블로그 포스트 역시 채널 섹션이다. 동일한 유형의 콘텐츠들을 날짜 별로 쌓는 것이니 ‘채널’ 섹션으로 처리하면 된다.

새로 채널 섹션을 하나 만들자. 이름을 ‘Post’로 주고 섹션 타입은 ‘채널’로 맞추고 나머지는 그대로 둔다.

저장하고 밖으로 나가면 새로 Post라는 섹션이 만들어진 것을 알 수 있다.

여기서 “엔트리 유형 편집하기”를 클릭하면 Post 항목 타입도 이미 만들어져 있음을 알 수 있다. 이 때의 Post는 ‘섹션’이 아니라 엔트리, 즉 ‘항목(Entry)’이다. Craft가 섹션을 만들면서 그 섹션에 해당하는 항목도 자동으로 만들었다. (나중에 다시 얘기하겠지만 Craft에서 하나의 섹션에는 반드시 하나의 항목만 들어가는 게 아니다. 하나 이상의 항목을 가질 수 있다. 그래서 섹션 아래에 항목을 둔 것이다. 여기서 Post 항목은 Post 섹션을 만들 때 디폴트로 생성된 항목일 뿐이며, 원하면 얼마든지 새로운 항목을 Post 섹션 내에 추가할 수 있다)

Post 항목을 클릭해 보자. Post 항목에 대한 정보가 표시될 것이다.

항목 보기 하단에는 ‘필드 레이아웃 디자인’ 이라는 영역이 보일 것이다. 이 부분이 항목의 필드 정보를 디자인하는 부분이다. 항목을 하나의 콘텐츠라고 한다면, 바로 여기서 콘텐츠를 구성하는 필드들의 정보를 구성할 수가 있다.

워드프레스에서 글과 페이지를 포함한 모든 콘텐츠의 기본 필드가 제목(title)과 본문(body) 뿐인 것과는 달리, Craft에서는 각각의 항목 별로 그에 맞는 필드를 다르게 가져갈 수 있는 것이다. 진정한 CMS의 면모다. (물론 워드프레스에서도 커스텀 필드 Custom Fields로 필드를 확장할 수 있고, ACF 플러그인 같은 확장을 사용하면 좀 더 편리하게 필드를 관리할 수 있긴 하다)

그럼 필드를 한번 추가해 보자.

“+ 새로운 탭” 버튼을 클릭하여 새 탭을 하나 생성하고 아래와 같이 DEFAULT 레이아웃에 있는 필드들을 드래그하여 새 탭으로 가져다 놓은 다음 저장하자.

방금 우리가 만든 Post 항목은 이제 ‘본문’과 ‘태그’라고 하는 2개의 필드를 갖는다. (‘제목’ 필드는 항상 따라 다닌다)

엔트리 추가하기

Post 항목을 만들었으니 이제 이 항목으로 실제 콘텐츠를 하나 만들어 보자. CP에서 “엔트리” 메뉴를 클릭하자. 채널 메뉴 아래에 ‘Post’ 채널이 추가되어 있을 것이다.

Post 라는 엔트리를 클릭해 보면 아무 것도 없는 빈 목록이 표시된다. 새로 포스트를 하나 만들어 보기로 하자. 상단의 “+새로운 항목” 버튼을 클릭하여 “Post” 를 선택하면 다음과 같이 새로운 엔트리 만들기 화면이 표시된다.

이 부분은 워드프레스 여타 다른 CMS의 편집기 화면과 별로 다를 게 없다. 참고로 Craft는 내부적으로 WYSIWYG 에디터로 Redactor 를 쓴다. (워드프레스는 디폴트로 TinyMCE를 사용)

콘텐츠를 한번 입력해 보자.

여기서 잠깐! 미리 볼 수는 없을까? Craft에는 실제로 콘텐츠 입력할 때 미리보기(Preview)를 할 수 있는 기능이 내장되어 있다. 그런데 아직 템플릿을 만들지 않았기 때문에 이 기능은 사용할 수 없다. 나중에 다시 설명한다.

우선은 저장하고 나가자. 새 콘텐츠가 Post 항목으로 추가된 것을 확인할 수 있을 것이다.

그럼 이게 실제 브라우저에서는 어떻게 보이는지 한번 보도록 하자. 항목 목록 맨 오른쪽에 있는 지구본 아이콘(웹페이지 방문)을 클릭하면 새 브라우저 창이 열리면서 콘텐츠의 내용이 표시될 것이다. 그런데.. 어? 페이지가 없다고 나온다.

맞다. 아직 우리가 이 콘텐츠 항목과 맵핑되는 템플릿을 만들지 않았다. 앞서 말했듯 Craft에서는 모든 페이지를 직접 만들어 줘야 한다. (알다시피 워드프레스에는 템플릿 계층 개념이 있어 해당 콘텐츠 유형에 맞는 템플릿이 없을 경우 템플릿 계층의 상위에 위치한 템플릿이 자동으로 바통을 이어 받게 되어 있지만 Craft에는 이런 개념은 없다. 콘텐츠 유형에 따른 템플릿을 직접 만들어 줘야 한다)

템플릿 추가하기

템플릿을 만드는 일은 워드프레스에 테마 파일 속에서 템플릿 파일을 추가하거나 수정하는 작업과 비슷하다. 다만 워드프레스와는 달리 Craft에서는 직접 PHP를 편집하는 대신 Twig이라는 템플릿 언어를 사용한다. (워드프레스에서도 Twig을 사용할 수 있게 해주는 Timber 라는 플러그인이 있긴 하다)

Craft가 설치된 디렉터리로 가서 앞서 _layout.html 파일을 편집할 때 열었던 templates 폴더를 보면 그 아래에 news라는 폴더가 보일 것이다. 맞다. 이 부분이 바로 Craft 가 설치될 때 함께 만들어진 ‘News’ 항목에 대한 템플릿이 위치한 곳이다.

그 속에 index.html 파일과 _entry.html 파일이 보일 것이다. 파일 이름이 말해주듯 각각 항목의 목록과 항목 그 자체의 내용을 표시해 주는 템플릿 파일들이다. 워드프레스로 치면 아카이브(archive)와 싱글(single) 템플릿인 셈이다.

index.html 뉴스 목록을 표시
_entry.html 개별 뉴스 내용을 표시

이제 templates 폴더 아래에 콘텐츠 유형에 맞는 폴더를 하나 추가하자. 여기서는 Post 항목에 대한 템플릿을 만들 것이기에 폴더명을 ‘post’로 주면 된다. (사실 더 정확하게는 앞서 섹션을 만들 때 엔트리 템플릿을 지정하는 부분이 있었다. 폴더 구성은 이 부분의 정보와 일치시키면 된다)

post 폴더를 만들었다면, 그 아래에 _entry.html 이라는 파일을 하나 추가하자. 그리고 그 내용은 우선 미리 만들어져 있는 news 폴더 속 _entry.html 파일을 그대로 복사해서 붙여 넣자.

{% extends "_layout" %}
{% set title = "Posts" %}

{% block content %}
  <h1>News</h1>

  {% for entry in craft.entries.section('post').find() %}
    <article>
    <h3><a href="{{ entry.url }}">{{ entry.title }}</a></h3>
    <p>Posted on {{ entry.postDate.format('F d, Y') }}</p>
    {{ entry.body.getPage(1) }}
    <p><a href="{{ entry.url }}">Continue reading</a></p>
    </article>
  {% endfor %}
{% endblock %}

Twig으로 작성된 이 템플릿은 상당히 직관적이다. 얼핏 봐도 post 섹션에 있는 항목들을 불러와 표시하는 것임을 알 수 있다. 워드프레스가 Loop를 자동으로 호출하는 것과 달리, Craft에서는 이렇게 명시적으로 질의(query)를 통해 데이터를 가져 온다.

Twig 템플릿의 사용법과 템플릿에서 에서 사용할 수 있는 함수들에 대한 설명은 Craft Templating 문서를 참조하자.

이제 다시 앞서 404 오류(“Page not found”)가 나왔던 페이지에 접속해 보면 이번엔 포스트의 내용이 정상적으로 표시되는 것을 확인할 수 있을 것이다. 템플릿이 만들어졌고 콘텐츠 항목이 템플릿에 반영된 것이다.

라이브 프리뷰

앞서 잠깐 미리보기 기능이 있다고 말했었다. 이제 다시 엔트리 목록으로 돌아와서 방금 전 만들었던 “안녕하세요” 포스트의 편집 화면으로 가보자. 우측에 “라이브 프리뷰”라는 버튼이 보일 것이다.

이 버튼을 한번 클릭해 보자. 예상은 했겠지만, 화면이 전환되면서 미리보기 화면이 표시될 것이다. 이름 그대로 ‘실시간’ 미리보기이기 때문에 바로 보면서 바로 편집할 수 있는 멋진 기능이다. (물론 워드프레스에도 미리보기 기능이 있다)

느꼈을지 모르지만, Craft는 워드프레스와는 다르게 초기 메뉴가 아주 간단하다. 처음에 간단하게 시작하고 필요한 것들을 추가해 나간다는 게 Craft의 발상이다. 처음부터 모든 걸 갖추고 필요없는 것을 제거해 나가는 워드프레스와는 반대 방향의 접근법이다. (얼핏 생각해 봐도 워드프레스에서 기본으로 제공되는 기능들 중에는 필요 없는 기능들이 제법 많다. 특히 워드프레스를 ‘블로깅 툴’이 아니라 ‘CMS’라는 시각에서 봤을 때 그렇다는 말)

레시피 항목 만들기

워드프레스를 좀 써 본 분들이라면 아마 지금 쯤 이렇게 말할 것이다.

뭐야? 이런 건 워드프레스에서도 다 할 수 있는 거잖아? 그것도 더 쉽게.

맞다. 사실 지금까지의 내용은 그저 맛보기에 불과했다. 아니 맛보기라기 보단 일부러 워드프레스를 따라 했다고 말하는 게 더 맞다. 똑같은 일을 Craft로 해 보면서 워드프레스와의 차이를 보이기 위함이었다.

하지만 지금까지의 내용만으로는 Craft의 진가를 제대로 보일 수 없다. 이번엔 레시피 라는 항목을 하나 더 만들어 보자. 앞서와 마찬가지로 새로 채널 섹션을 하나 만들면 된다. 이름은 ‘Recipe’라고 주자.

이제 우리의 Craft에는 ‘Recipe’라는 섹션이 하나 더 추가되었다.

여기서 잠깐! 앞서도 잠깐 언급했지만 Craft에는 항목(엔트리) 외에 별도로 섹션(Section)이라는 개념이 있다. 그리고 하나의 섹션에는 하나 이상의 항목이 올 수 있다. 예를 들면, 미디어(media) 라는 섹션을 하나 만들었다면 그 섹션 속에 다시 사진 미디어, 보도자료 미디어, 스페셜 미디어 등 여러 종류의 미디어 항목들이 올 수 있는 것이다.

또는 레시피 섹션에서라면 그 속에 한식, 양식, 중식, 일식 등의 레시피 항목을 각각 별도로 만들어 항목별로 템플릿이나 필드 구조를 다르게 가져갈 수도 있다. 같은 섹션의 항목들은 그 항목 유형이 다르더라도 함께 취급된다.

워드프레스에서 이와 유사한 개념을 찾는다면 아마도 포스트 유형(Post Formats)이 될 것이다. 워드프레스에서는 글을 쓸 때 그 글의 포스트 유형을 추가정보(aside), 갤러리(gallery), 링크(link), 이미지(image), 인용(quote), 상태(status), 비디오(video), 오디오(audio), 채팅(chat) 등으로 다양하게 지정할 수 있고 각각 템플릿도 다르게 가져갈 수 있지만 그렇게 많이 쓰이지는 않는 듯 하다.

Recipe 항목을 디자인하기에 앞서 우리가 만들 레시피의 레이아웃을 한번 그려 보자.

우선 레시피 제목(title)이 나온다.
그리고 이 레시피에 대한 간단한 설명(description),
이 레시피를 대표할 만한 대표 이미지(featured image)가 보이고,
이 레시피에 사용될 재료(ingredients) 들이 표시되고,
레시피에 대한 구체적인 지시(instruction)가 나온다.
마지막엔 이 레시피를 직접 따라해 볼 수 있는 동영상(video)이 제공되면 좋을 것 같다.

그림으로 그려보면 대략 이렇게 될 것이다.

이제 이 레이아웃 대로 레시피 항목의 필드로 구성해 보기로 하자.

‘굳이 이렇게 항목을 나눌 필요 있을까? 워드프레스처럼 편집기 속에서 그냥 description / instruction / video 등등의 부분으로 나눠 콘텐츠를 입력하면 되지 않을까? 혹은 Visual Composer 같은 페이지 빌더 플러그인을 사용하면? 페이지 빌더가 이럴 때 사용하라고 있는 것 아닌가?’ 라고 말할 수도 있을 것 같다. 그렇지만 콘텐츠 의 기본 구조 자체를 구조화시키는 것과 단순히 보이는 부분에서만 다르게 보이게끔 나누는 방법은 분명 다르다!

필드 추가하기

레시피 항목에 필드를 추가할 것이다. CP에서 “설정 > 필드” 메뉴를 선택하자.

우선 설명(description) 필드 부터.

이어서 대표이미지(featured image) 필드.

여기서는 약간의 설명이 필요하다. 이 필드는 이미지 파일이 와야 한다. 필드 유형을 ‘에셋’으로 선택하고 허용 파일의 형식을 ‘이미지’로 제한하자. 다른 설정들도 더 있지만 우선은 이 정도만 하고 저장 버튼을 눌러 저장하자.

이어서 재료(ingredients). 그냥 평문으로 처리하자.

이번엔 지시(instruction). 별도 필드로 만들어도 되지만, 이 부분 그냥 기존의 body 필드를 이용하는 걸로 하자.

마지막으로 video URL을 입력하는 부분. 필드 유형은 그냥 평문(디폴트)으로 두자.

그러면 이제 전체 필드가 다음과 같이 추가되었다.

이제 다시 “설정” 메뉴에서 Recipe 항목 유형을 편집해 보자.

앞서와는 달리 필드 레이아웃 디자인의 디폴트 탭에 방금 전 우리가 추가한 필드들이 포함되어 있을 것이다.

새로운 탭을 하나 만들어 필드들을 추가하자.

다 되었다. 이로서 우리는 새 콘텐츠 항목인 Recipe를 하나 만든 것이다.

CP에서 “엔트리” 메뉴에서 새 레시피 항목 만들기를 해 보면 다음과 같은 입력 화면이 보일 것이다.

앞서 포스트를 만들 때와는 완전히 다른, 레시피 항목에 딱 맞는 편집창이 눈앞에 펼쳐진다. 이 정도면 전문 쉐프가 아니라도 레시피 하나 쯤은 입력하고픈 용기가 생긴다. 요리 공부도 할 겸, 레시피를 하나 입력해 보자. 내가 좋아하는 알리오올리오 파스타! 혹은 뭐든 좋다. 입맛 돋우는 음식으로 레시피를 하나 만들어 보기 바란다.

앞서도 말했듯, 워드프레스에서도 커스텀 필드를 사용하면 이렇게 다양한 필드를 구성할 수 있다. 그렇지만 그러려면 제법 많은 노력이 필요하다. 템플릿 파일도 건드려야 하고 관리자 화면에 메타박스도 만들어 넣어야 하고.

참고로, 만약 위 레시피를 워드프레스로 만든다면?

‘레시피’라는 커스텀 포스트 유형(Custom Post Type)을 하나 만들고
여기에 커스텀 필드들을 추가하고 (이때 ACF 같은 플러그인을 활용)
이 커스텀 포스트 유형에 대응하는 템플릿 파일을 작성

워드프레스에서 커스텀 포스트 유형을 사용하여 새로운 콘텐츠 유형을 만드는 방법에 대한 자세한 설명은 WordPress 가이드를 참조하자.

에셋 처리하기

여기서 한 가지. 대표 이미지 부분에서 다음과 같이 오류 메시지가 뜬다.

Craft에서는 이미지 파일이나 PDF 파일 같은 모든 종류의 파일들을 ‘에셋(asset)’이라고 부르고 별도 관리할 수 있게끔 하고 있다. 이 경우 우리가 만들 레시피 항목의 대표 이미지 역시 하나의 에셋이 된다.

CP의 “설정 > 에셋” 메뉴에서 새 에셋을 추가해 보자.

“+ 새로운 자료 소스” 버튼을 눌러 다음과 같이 새로 에셋을 추가하자. 이름은 아무렇게나 줘도 되지만 여기서는 ‘음식사진’이라고 정했다. 핸들값은 나중에 템플릿에서 이 에셋을 참조할 때 사용할 값이다. 파일 시스템 경로는 실제로 이 이미지 파일이 업로드되었을 때 저장될 경로로, 여기서는 public 폴더 아래에 있는 images/foods/ 라는 폴더에 저장할 것이기에 그렇게 지정했다(이 폴더는 실제로 지정된 위치에 존재해야 한다. 없으면 만들어 주자!) 마지막으로 URL은 이 이 에셋(이미지)이 브라우저를 통해 표시될 때 사용될 경로를 지정한다.

저장하고, 다시 “설정 > 필드” 메뉴로 가서 ‘대표이미지’ 필드로 들어가 보자. 소스를 제한하고 기본 업로드 위치를 방금 전 만든 에셋인 ‘음식사진’으로 맞추자.

이제 레시피 항목 편집 창으로 돌아오면 에셋 파일을 추가할 수 있게 업로드 버튼이 보일 것이다.

대표이미지를 한번 추가해 보자. 이미지 파일을 드래그하여 업로드 창에 드롭하면 업로드가 되고, “선택하기”를 클릭하면 업로드한 이미지가 이 레시피의 대표 이미지가 된다.

템플릿에 반영하기

그렇지만 아직 실시간 미리보기를 해 보면 필드의 내용이 반영되지 않았을 것이다. 아직 템플릿을 만들지 않았기 때문이다. 이제 템플릿 파일을 만들 시간이다.

{% extends "_layout" %}

{% block content %}
  <article>
    <h1>{{ entry.title }}</h1>
    <p class="description">{{ entry.description }}</p>
    <img class="featured" src="{{ entry.featured_image.first().url }}">
    <h3>Ingredients</h3>
    <p class="ingredients">{{ entry.ingredients }}</p>
    <h3>Instruction</h3>
    <p class="instruction">{{ entry.body }}</p>
    <a href="{{ entry.video }}" class="video">{{ entry.video }}</a>
    <hr>
    <p>Posted on {{ entry.postDate.format('F d, Y') }}</p>
  </article>
{% endblock %}

다시 미리보기 해보자. 레시피의 모든 필드들이 제대로 반영 되었을 것이다.

참고로, 여기에서 사용한 알리오 올리오 파스타의 내용은 다음 자료들을 참조하였다.

YouTube 비디오 포함 시키기

다만 한 가지가 조금 아쉽다.

방금 레시피에 포함시킨 동영상의 URL은 실은 유튜브(YouTube) 사이트로의 단순 링크에 불과하다. 가능하면 동영상을 직접 레시피 내에 포함시킬 수 있으면 좋겠다.

워드프레스에서라면 이건 일도 아니다. 그냥 동영상 URL을 입력하면 워드프레스가 자동으로 임베딩(embedding) 시켜 주기 때문이다.

하지만 Craft라고 해서 안되는 건 아니다. 유튜브 동영상 URL을 파싱하여 동영상 ID를 추출한 다음 템플릿 속에 임베드 시키는 코드를 간단하게 직접 구현해도 되지만, 여기서는 Craft의 플러그인(Plugin) 기능도 한번 알아 볼 겸, 플러그인을 하나 사용해 보기로 하자.

Video Embed Utility라는 플러그인을 사용할 건데, GitHub에서 내려 받으면 된다.

플러그인을 다운로드 받아 압축을 푼 다음, craft/plugins 폴더 아래에 두자. 그런 다음, “설정 > 플러그인” 메뉴로 가면 방금 복사한 플러그인이 보일 것이다.

“설치하기” 버튼을 누르면 설치가 끝난다. 물론 워드프레스처럼 어드민(CP) 내에서 플러그인을 검색하고 자동으로 설치하는 그런 편리한 기능은 아직 없다.

템플릿 파일에서는 동영상 처리 부분에서 다음과 같이 필터로 추가해 주면 된다.

{{ entry.video | videoEmbed({ width: 600, height: 400 }) }}

이제 다시 레시피로 돌아와 확인하면, 동영상이 보일 것이다.

그 밖의 기능들

오늘 소개할 내용은 여기까지다.

지면(?) 관계상 다 다루지는 못했지만, Craft에는 이 밖에도 많은 기능들이 기본으로 제공되고 있다. 어떤 기능들이 더 있는지는 CP의 “설정” 메뉴에서 보면 힌트를 얻을 수 있다.

그 중 몇 가지만 들면, 다음과 같은 기능들이다.

경로(Routing) 설정 기능
사용자(Users) 및 권한 관리
이메일 처리 기능
다국어 사이트 지원
캐싱 처리
검색 및 백업

이 모든 기능들이 기본으로 제공된다. 사실 이런 기능들 하나하나는 콘텐츠 중심의 웹사이트를 만드는 경우라면 꼭 필요한 기능들이고, 워드프레스를 이용할 경우라 해도 별도 플러그인을 설치하거나 아니면 직접 구현해서라도 만들어 넣어야 하는 것들이다.

참고로, 이들 기능 중 일부는 별도의 라이선스를 구입해야 활성화된다. Craft는 PERSONAL / CLIENT / PRO 3종의 라이선스가 있는데 이 중 PERSONAL을 제외한 나머지 2개는 유료이다. 사이트 라이선스는 Craft의 비즈니스 모델이며, 주로 유료 호스팅 서비스를 통해 수익을 얻는 워드프레스 개발사 Automattic과는 조금 다른 비즈니스 모델이다.

어떤 CMS를 선택할까?

지금까지 이 글을 읽은 독자라면 Craft가 워드프레스와는 조금 다른 도구라는 것을 어렴풋이나마 느꼈을 것이다. (전혀 못 느꼈다면 그건 필자의 부족한 설명 탓이니 자책하지는 말기 바란다)

사실 Craft로 할 수 있는 것은 워드프레스로도 할 수 있다. 그리고 방금 전 문장의 등식은 워드프레스 자리에 다른 솔루션들, 예를 들면 루비온레일스나 라라벨, 혹은 드루팔(Drupal) 같은 이름을 넣어도 마찬가지로 성립한다. 안되는 건 없다. 그렇다면 차이는 무엇일까?

어느 게 좀 더 쉽게 할 수 있는가 (사용성), 어느 게 좀 더 잘 할 수 있는가 (생산성), 어느 게 좀 더 유연한가 (확장성), 어느게 좀 더 빠른가 (성능), 이런 정도의 차이 아닐까?

그리고 그 물음에 한 가지 유일한 답은 없다. 내게(또는 우리 조직에) 놓인 상황과 필요에 따라 그 조건에 가장 잘 맞는 도구(솔루션)을 선택하는 게 답일 것이다.

블로그(혹은 블로그와 유사한 글 중심의 웹사이트)를 만든다거나 이미 시중에 나와 있는 테마를 적용하면 되는 수준의 웹사이트라면 굳이 다른 솔루션 검토할 것도 없이 워드프레스를 집어드는 게 현재로선 최선일 것이다. 랜딩 페이지를 만들거나 간단한 브로셔 혹은 한두 페이지짜리 사이트라면 굳이 워드프레스까지도 필요 없다. 지킬(Jekyll) 같은 정적 웹사이트 저작도구를 쓰거나 그도 귀찮다면 그냥 직접 HTML로 만들면 그만이다. 웹앱(webapp)이나 웹서비스라면 레일스나 라라벨, 익스프레스(Express) 같은, 좀 더 자유도 높은 웹 프레임워크를 선택하는 게 옳은 방향일 것이고.

그렇다면 Craft는?

단순 블로그 글이나 페이지가 아닌 콘텐츠 중심의 웹사이트를 만들어야 할 때
CMS가 필요하긴 한데 웹 프레임워크를 직접 다룰 여력은 없고 워드프레스로는 조금 부족함을 느낄 때
PHP나 기타 프로그래밍 언어에 대한 고민 없이 콘텐츠와 디자인에만 집중하고 싶을 때
보안이나 업데이트에 대한 걱정을 줄이고 콘텐츠 관리에만 신경쓰고 싶을 때
관리할 콘텐츠의 양이 상당히 많을 때

이런 때라면 Craft를 한번 검토해 보자. 좋은 선택이 될 것이다. :)

참고자료

Grid layout을 만드는 몇 가지 기술들

2017-03-31T00:00:00+00:00

그리드 레이아웃(grid layout)은 웹사이트를 디자인할 때 가장 흔히 사용하는 레이아웃이다. 전통적으로 웹사이트 디자인이 인쇄물(브로셔나 잡지) 디자인으로부터 상당 부분 영향을 받은 탓도 있지만, 그리드를 사용하여 흩어져 있는 요소들을 일관성 있게 정렬하여 보여주는 것이 사용자들에게 훨씬 더 잘 와 닿는다.

그리드 레이아웃으로 웹사이트를 만들 경우, 우선 웹사이트를 일정 수의 격자(grid)로 나누고 그 각각의 격자 속에 필요한 디자인 요소들을 적절하게 배치하는 방법으로 디자인을 하게 된다. 그렇지만 웹에서 그리드를 구현하는 방법은 한 가지가 아니다. 여러 가지가 있다. 이 글에서는 그 중 다음 몇 가지 대표적인 방법에 관해 소개한다.

테이블(table) 방식
CSS float 속성을 사용하는 방식
Flexbox 방식
CSS Grid 방식

Table 방식

HTML의 <table> 태그를 사용하여 가로 세로 테이블을 만들고 그 테이블의 행과 열 속에 디자인 요소들을 배치하는 방법으로, 웹 초창기부터 시작해서 소위 ‘웹표준’이라 일컫는 방식이 일반화 되기 전까지 주로 사용되어 왔던 방법이다. 당시의 웹사이트는 거의 데스크톱(PC) 브라우저만을 지원하면 되었고, 고정폭 레이아웃을 사용하는 경우가 대부분이었기 때문에 table 방식의 디자인이 잘 먹혔다. 아주 오래 전에 만들어진 사이트를 제외하면 요즘은 거의 사용하지 않는 ‘유물’ 방식이기 때문에 자세한 구현 방법은 생략한다.

CSS float 속성을 사용하는 방식

현재 가장 일반적으로 사용하는 그리드 레이아웃 구현 방법은 CSS float 속성을 사용하여 구성요소들을 배치하는 방법이다. 예를 들어, 다음과 같은 웹사이트 레이아웃을 만든다고 해 보자.

여기서는 지면 관계와 설명의 편의를 위해 헤더 영역과 푸터 영역은 제외하고, 본문 영역과 그 아래 대표 이미지 영역만 그리드 레이아웃을 적용한다고 해 보자. 그러면 그리드는 다음과 같이 구성될 수 있다. (여기 소개하는 내용은 어디까지나 여러 방법들 중 하나일 뿐이며, 동일한 디자인에 대해서도 그리드 레이아웃을 적용하는 방법은 다양할 수 있음을 미리 밝힌다)

본문 영역은 메인 콘텐츠와 사이드바가 각각 2/3와 1/3 씩 차지하게끔 구성하였고, 그 아래 대표 이미지 영역은 4개의 이미지가 각각 1/4씩 자리를 차지하게끔 하였다.

이 영역에 대한 HTML 마크업이 다음과 같을 경우,

<div class="wrap">
  <main class="content">
    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Qua ex cognitione facilior facta est investigatio rerum occultissimarum. Hoc dixerit potius Ennius: Nimium boni est, cui nihil est mali. Hoc loco tenere se Triarius non potuit. Diodorus, eius auditor, adiungit ad honestatem vacuitatem doloris. Itaque haec cum illis est dissensio, cum Peripateticis nulla sane. Contineo me ab exemplis. Sed ne, dum huic obsequor, vobis molestus sim. Multoque hoc melius nos veriusque quam Stoici. </p>
  </main>
  <aside class="sidebar"></aside>
</div><!--.wrap --> 
<section class="features">
  <a class="feature" href="#"><img src="https://fakeimg.pl/300x200/"></a>
  <a class="feature" href="#"><img src="https://fakeimg.pl/300x200/"></a>
  <a class="feature" href="#"><img src="https://fakeimg.pl/300x200/"></a>
  <a class="feature" href="#"><img src="https://fakeimg.pl/300x200/"></a>
</section>  

CSS float 속성을 사용하여 위 마크업을 그리드 레이아웃으로 만들려면 CSS 스타일을 다음과 같이 주면 된다.

 .content {
    width: 67%;
    float: left;
}
.sidebar {
    width: 33%;
    float: right;
}
.feature {
    width: 25%;
    float: left;
}
.wrap:after, .features:after {
    content: " "; 
    display: block; 
    clear: both;
}

각각의 요소에 width 값을 준 다음 float 속성을 사용하여 왼쪽과 오른쪽으로 띄웠다. 그런 다음, 마지막에서 소위 “clearfix”라고 하는 것을 적용하였는데, 이는 float 속성만 갖는 부모 요소가 영역을 차지하지 못하는 문제를 해결하기 위한 잘 알려진 핵(hack)이다. Clearfix 와 관련한 더 자세한 내용은 아래 문서를 참조하면 된다.

float을 clear하는 4가지 방법

이 CSS float 속성을 이용한 그리드 레이아웃 구성 방법은 오늘날 웹에서 가장 일반적으로 사용되는 방법이다. CSS 프레임워크의 원조라 할 Blueprint부터 시작해서 요즘 가장 인기있는 Bootstrap 과 Foundation 에 이르기 까지 많은 CSS 프레임워크들도 이 방법으로 그리드를 구성한다.

Flexbox

Flexbox의 정식 명칭은 ‘CSS Flexible Box Layout ‘이며 이름 그대로 유연한(flex) 박스 모델을 위한 CSS 스펙이다. Flexbox는 여러 요소들을 플렉스 컨테이너(flex container)로 감싸는 방식으로 구현한다. 이 플렉스 컨테이너 속에 들어간 요소(자식 박스)들은 가로 세로 아주 유연하게 배치될 수 있는 것이 Flexbox의 장점이다.

위 웹사이트 레이아웃 예제를 이번엔 Flexbox를 사용하여 다시 구성하려면 CSS 스타일을 다음과 같이 주면 된다.

.wrap, .features {
    display: flex;
}
.content {
    flex: 2;
}
.sidebar {
    flex: 1;
}

잠깐 부연하면, .wrap과 .features 클래스를 flex 컨테이너로 만들었다. 어떤 요소가 flex 컨테이너가 되면, 그 속의 자식 요소들은 ‘flex 아이템(item)’이 되어 flex box 모델의 적용을 받는다. flexbox 모델의 기본 값은 각각의 자식 요소들이 동일한 크기의 영역을 차지하는 것이기 때문에 여기서 .content와 .sidebar는 flex 속성값을 각각 2와 1로 주어 .content 가 .sidebar 보다 2배 크기의 영역을 차지하게끔 선언하고 있다. .feature 이미지들은 각각 1/4(25%) 씩 균등하게 차지하면 되기 때문에 따로 선언해 주지 않았다(디폴트 값 적용).

앞서 float 속성 방식과 비교하면 훨씬 간단하다. 핵(hack)도 필요없다. 게다가 Flexbox를 사용하면 가로 세로 아주 다양한 방식으로 레이아웃을 구성할 수도 있다. 또한 미디어 쿼리(media query)와 함께 사용하면 다양한 디바이스 폭에 맞춘 반응형 웹디자인 처리도 간단하게 해결된다.

여기서는 Flexbox를 그리드 레이아웃을 만드는데 사용했지만, 사실 Flexbox는 비단 그리드 레이아웃을 구성하는 용도로만 사용되는 것은 아니다. 웹사이트 상에서 여러 요소들을 한 데 묶어 유연하게 레이아웃을 구성할 경우라면 여러 용도로 다양하게 활용할 수 있다. 브라우저 지원성도 좋아, 최신 브라우저들이라면 대부분이 지원한다.

Flexbox 지원 브라우저

자세한 설명과 사용법, 용도(유스케이스)는 아래 자료들을 참조하자.

CSS 레이아웃을 배웁시다 : flexbox
Solved by Flexbox : CSS Flexbox의 다양한 유스케이스
A Complete Guide to Flexbox : 자세한 설명을 곁들인 레퍼런스

CSS Grid Layout

CSS Grid Layout은 그야말로 ‘그리드 레이아웃’만을 위한 CSS 모듈이다. 가로세로 격자를 만들어 그 속에 디자인 요소들을 배치하는 점에서는 앞서 table 방식의 레이아웃과 비슷하다 말할 수도 있지만, 그 구성 방법이나 유연성에 있어서는 차원이 다르다. 또한 Flexbox 처럼 미디어 쿼리와 함께 사용하면 반응형 웹 구성도 쉽게 처리할 수 있다.

앞서 적용한 예제와 동일한 레이아웃을 이번엔 CSS Grid로 구현해 보면, 다음과 같이 할 수 있다. (여기서는 grid-template-columns라는 속성으로 각각의 컬럼 폭을 명시하는 방법을 썼지만, CSS Grid에는 grid-template-areas라는 방식으로 영역에 이름을 지정하여 처리하는 방식도 지원한다)

.wrap {
    display: grid;
    grid-template-columns: 67% 33%;
}
.features {
    display: grid;
    grid-template-columns: repeat(auto-fit, 25%);
}

Flexbox에서는 display 속성을 ‘flex’로 주어 flex 컨테이너로 만들었다면, 이번엔 display 속성을 ‘grid’로 주어 grid 컨테이너로 만들었다. Flexbox와 마찬가지로, 이럴 경우 grid 컨테이너 속 자식 요소들은 ‘grid 아이템(item)’이 되어 그리드 모델의 적용을 받게 된다. 여기서는 grid-template-columns 라는 속성을 사용하여, .wrap 클래스에서는 컬럼(즉 메인과 사이드바) 폭을 각각 67%와 33%로 주었고 그 아래 .features 클래스는 자식 요소들 각 컬럼의 폭을 25%씩 주어 균등하게 나누었다.

CSS Grid vs. Flexbox

흔히 접하는 질문 중 하나는 CSS Grid Layout(이하 ‘CSS Grid’)이 앞서 소개한 Flexbox와 어떤 차이가 있냐 하는 것인데, 기본적으로 Flexbox가 가로 또는 세로 하나의 축(axis)을 기준으로 요소(박스)를 배열하는 개념인 반면, CSS Grid는 가로x세로 2차원 매트리스를 기준으로 그 속에 요소들을 배치한다는 점에서 접근 방식 자체가 다르다.

* 그림 출처: W3C CSS Grid Layout Module 명세 (적색 선 추가)

물론 앞서 소개한 예제의 경우, 간단하게 가로x세로 = 1x2의 간단한 그리드를 만들어 사용한 관계로 Flexbox와의 차이를 잘 느끼지 못할 수도 있지만, 가로 세로 행열의 개수가 많을수록 Flexbox와의 차이가 분명하게 드러난다.

또한 Flexbox와 CSS Grid가 서로 대체 관계에 있는 것도 아니다. 둘은 함께 사용할 수 있고 또 함께 사용할 때 진정한 효과가 나올 수 있다. 예를 들어, 전체 사이트의 레이아웃은 CSS Grid로 잡고 그 속에 들어가는 갤러리 영역이나 카드 목록 같은 부분은 Flexbox를 써서 만드는 식이다.

물론 CSS Grid는 아직 모든 브라우저에서 사용할 수 있는 것은 아니다.

CSS Grid 지원 브라우저

크롬(Chrome) 57, 파이어폭스(Firebox) 52 이상에서 지원되며, 이 글을 쓰는 시점에서 이틀 전인 2017년 3월 29일, 사파리(Safari) 브라우저 10.1 버전에서 CSS Grid 지원이 발표되었다. 그렇지만 지금과 같은 지원 속도라면, 아마 모든 브라우저에서 CSS Grid를 쓸 수 있는 날이 머지 않을 듯 싶다.

CSS Grid와 미래의 웹

인기있는 CSS 프레임워크인 Foundation을 개발하는 ZURB는 최근 블로그를 통해 CSS Grid가 가져올 미래 웹의 변화를 낙관하면서 다음과 같이 말하고 있다.

The term “web page” is starting to feel very, very… inadequate. CSS Grid opens up layout in ways that were not possible before, and our minds are racing with the opportunity in front of us. We hope these experiments will get you as excited as we are, and demonstrate a little of what’s possible with this new tool.

지금 당장은 아니라 할지라도, CSS Grid는 Flexbox와 함께 웹사이트와 웹서비스, 그리고 웹 애플리케이션 개발에 있어 새롭고 멋진 도구가 될 것임에 분명하다.

CSS Grid와 관련해서 더 자세한 내용은 아래 자료들을 참조하자.

Grid by Example
A Complete Guide to CSS Grid
Practical CSS Grid: Adding Grid to an Existing Design : CSS 전문가 Eric Meyer가 최근 자신의 사이트에 CSS Grid를 적용한 내용을 소개한 글
CSS 그리드를 사용하여 적응 레이아웃을 만드는 방법 : MSDN 문서. 마이크로소프트 IE 11 및 Edge 14 버전부터 CSS Grid를 지원하지만, MS 브라우저가 지원하는 CSS Grid Layout은 예전 버전이며, 이 글은 그 명세에 따른 것임에 유의하자.

Facebook Page를 RSS Feed로 받아보기

2017-02-06T00:00:00+00:00

이 글은 페이스북 사용자들을 위한 간단한 팁(tip)입니다.

“RSS 피드(Feed)”라고 하면 아주 오래된, 호랑이 담배 먹던 시절의 유물이라고 생각할 수도 있겠지만, 실은 아직도 RSS 피드는 많은 곳에서 사용되고 있습니다. 블로그나 웹사이트들은 여전히 RSS 피드로 내보내기 기능을 제공하는 경우가 많고 시중에는 RSS 구독기들도 여럿 존재합니다. 구글(Google)이 제공하던 대표적인 RSS 구독 서비스인 구글 리더(Google Reader)는 진즉에 종료되었지만, 구글 리더를 물러 받은 Feedly 같은 서비스는 여전히 성업 중입니다.

– 참고: Google Reader 서비스 중단 이유 by techNeedle

페이스북(Facebook)도 초창기(?)엔 서비스 곳곳에서 RSS를 지원했었죠. 하지만 어느 순간부턴가 RSS와 관련된 기능들은 서비스에서 하나씩 둘씩 사라졌습니다. 페이스북 페이지의 내용을 RSS로 구독할 수 있는 기능도 2015년 중순부터 폐기 되어 이제 페이지의 피드를 RSS를 통해 받아 볼 수 없게 되었습니다.

페이스북이 페이지 피드를 RSS로 제공하지 못한다 해서, 페이지 피드를 RSS로 받아볼 방법이 전혀 없는 건 아닙니다. 시중에는 페이스북 페이지를 RSS로 받아 볼 수 있도록 해주는 서비스들이 여럿 존재합니다. 아래는 그 중 몇몇 서비스들입니다.

그 밖에도 여러 방법들이 가능합니다. 예를 들면, Zapier 같은 워크플로 자동화 도구를 이용하는 방법도 있고, 아래와 같은, 오픈소스로 공개된 툴들을 사용하는 방법도 있습니다.

rss-bridge 는 RSS를 제공하지 않는 웹사이트에서 ATOM 피드를 생성해 주는 PHP 프로젝트.
facebook-rss-parser Facebook Graph API 결과를 RSS로 변환.

물론 간단하게 직접 하나 만들어 쓰는 것도 어렵지 않습니다. 페이스북의 페이지 정보를 Graph API로 추출한 다음 그 결과를 RSS/Atom 형식으로 변환시키기만 하면 되기에 코드 몇 줄이면 간단하게 구현할 수 있습니다. 아래는 루비 언어로 구현한 예시입니다.

def get_page_posts(page_id)
  feed_url = "https://graph.facebook.com/#{page_id}/posts?access_token=#{access_token}&fields=#{POST_FIELDS}"
  result = fetch(feed_url)
  halt result["error"]["message"] if result["error"]
  result["data"]  
end

def fetch(url)
  res = Net::HTTP.get URI(url) rescue nil
  JSON.parse(res) if res
end

def access_token
  ENV["FACEBOOK_ACCESS_TOKEN"] || %Q(#{ENV["FACEBOOK_APP_ID"]}|#{ENV["FACEBOOK_APP_SECRET"]})
end

이렇게 만든 프로그램을 Heroku 같은 클라우드 플랫폼에 설치해 두고 사용하면 별다른 비용 없이 유용하게 사용할 수 있을 것입니다.

~~PageFeed 데모~~ (Heroku Dyno 용량 초과로 중단)
소스코드

엘릭서(Elixir)로 JSON API 서버 만들기

2017-02-03T00:00:00+00:00

엘릭서(Elixir)는 얼랭(Erlang) VM에서 작동하는 프로그램을 만드는 함수형 언어다. 스크립트 언어인 루비(Ruby)와 유사한 문법을 갖고 있지만 스크립트 방식과 컴파일 방식을 모두 지원하며, 특히 컴파일된 바이너리 코드는 얼랭과 완전히 호환되기 때문에 얼랭의 다양한 라이브러리와 도구들을 Elixir에서도 그대로 사용할 수 있는 장점이 있다. 게다가 동시성(concurrency) 지원이나 무정지(fault tolerance) 시스템과 같은, 얼랭 VM의 장점들도 고스란히 이어받을 수 있기 때문에 안정적이고 가용성 높은 서버 시스템을 구현하려 할 때 Elixir는 좋은 선택이 될 수 있다고 할 것이다.

이 글에서는 엘릭서를 이용하여 간단한 JSON API 서버를 한번 만들어 보기로 한다(말이 ‘API 서버’지만 정말로 간단하니, 큰 기대는 접자).

엘릭서를 처음 접하는 분들이라면 Elixir가 어떤 언어이고 웹에서는 어떻게 사용되는지 개념을 잡을 수 있는 글이 되었으면 좋겠고, JSON API 서버를 포함한 서버측 개발을 하는 분들이라면 엘릭서에 대해 좀 더 관심을 가질 수 있는 계기가 되면 좋겠다.

프로젝트 시작하기

엘릭서를 설치하면 Mix라고 하는 작업 관리툴이 함께 설치된다(Node로 치면 grunt나 gulp와 비슷한 도구라고 생각하면 된다). 통상적으로 엘릭서 프로젝트는 이 Mix를 사용하여 새 프로젝트 구조를 만드는 것으로부터 시작한다. 터미널에서 다음과 같이 mix new 명령으로 새 프로젝트를 생성하자(Mix는 다양한 용도를 갖고 있는데 자세한 내용은 mix help로 확인할 수 있다).

$ mix new my_app

my_app 이라는 프로젝트 디렉터리가 만들어 졌으면 이 디렉터리로 들어가서 디렉터리 구조를 한번 살펴보자.

mix.exs 파일은 프로젝트의 설정과 관련된 파일이며 lib 디렉터리 아래에 프로그램의 소스코드가 위치한다. config 디렉터리 아래의 config.exs 파일은 애플리케이션의 설정에서 사용하는 파일이다.

의존 라이브러리 추가하기

우리가 만들 프로그램은 어떤 임의의 URL을 입력하면 JSON 형식의 텍스트를 반환하는 간단한 API 서버다. 이를 위해 이 프로그램에서는 엘릭서에서 웹 애플리케이션 기능을 제공할 때 사용하는 표준 라이브러리인 Plug과 JSON을 처리하는 Poison 라이브러리를 사용할 것이다.

mix.exs 파일을 열어 끝 부분에 있는 deps 함수를 다음과 같이 수정하자. 이 부분은 프로젝트에서 의존하는 라이브러리를 추가하는 부분이다. 이 때 함께 추가한 Cowboy는 실은 Erlang HTTP Server이며, Plug에서 필요로 하기 때문에 함께 추가한 것이다.

defp deps do
  [
    {:cowboy, "~> 1.0.0"},
    {:plug, "~> 1.3"},
    {:poison, "~> 3.1"}
  ]
end

이 상태로 명령행에서 아래 mix 명령을 실행하면 원격의 라이브러리 소스가 로컬 프로젝트 속으로 import 된다(npm install 이나 go get 명령을 떠올리면 된다).

$ mix deps.get

다음으로, 같은 파일에 있는 application 함수를 아래와 같이 수정하자. 마찬가지로 이 프로젝트에서 사용될 애플리케이션들을 선언하는 부분이다(엘릭서에서는 각각의 라이브러리가 하나의 독립된 애플리케이션이며 따라서 Elixir 프로젝트는 결국 여러 애플리케이션들이 서로 어울려 작동하는 구조가 된다).

def application do
  [applications: [:logger, :plug, :poison]]
end

Hello, Elixir!

이제 프로그램을 만들기 위해 필요한 준비는 끝이 났다. 실제 API 부분을 구현하는 일만 남았다. lib 디렉터리 아래에 있는 my_app.ex 파일을 열자. 프로그램에서 필요한 코드는 이 파일 속에 추가하면 된다.

여기서 잠깐! 바로 API 서버를 구현하기에 앞서, 우선 Elixir와 간단하게 인사부터 나누자!

먼저 간단하게 my_app.ex 파일 속에 다음과 같이 코드를 한번 추가해 보자. MyApp이라는 모듈 내에 init/1 이라는 함수와 call/2 라는 함수를 추가하고, call 함수 속에서 다시 Plug.Conn.send_resp/3 함수를 호출하였다.

defmodule MyApp do
  
  def init(options) do
    # initialize options
    options
  end

  def call(conn, _opts) do
    Plug.Conn.send_resp(conn, 200, "Hello, Elixir!")
  end

end

여기까지 작성하였으면, 이제 명령행에서 다음과 같이 IEx를 통해 Elixir의 인터랙티브 환경에 접속하자. IEx는 Elixir의 대화형 콘솔이며(루비의 irb 같은), 이 때 -S 옵션은 iex를 실행할 때 mix.exs 스크립트도 함께 로드하라는 의미다.

$ iex -S mix

잘 따라 왔다면 다음과 같이 콘솔이 열렸을 것이다.

Interactive Elixir (1.3.4) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)>

이 상태에서 앞서 mix 설정에서 추가한 웹서버인 Cowboy HTTP 서버를 실행하자.

iex(1)> Plug.Adapters.Cowboy.http MyApp, []
{:ok, #PID<0.180.0>}

{:ok, #PID<xxx>} 가 떨어지면 정상이다. 앞서 우리가 만든 MyApp 모듈이 Cowboy 웹서버와 연동되어 실행되었다. 이 상태에서 웹브라우저나 curl 명령으로 http://localhost:4000/ 에 접속하여 확인해 보면 예상대로 “Hello, Elixir!”가 출력되는 것을 확인할 수 있을 것이다.

웹 애플리케이션과 Plug!

생각보다 간단하게 끝났다. 기대한 것보다 너무 시시했다면 아마도 Plug를 사용한 탓일 것이다. 지금까지는 별 말 없이 Plug 라이브러리를 사용했지만, 여기서는 잠깐 간단하게라도 Plug에 대해 소개하고 넘어가기로 하자.

Plug 소개 페이지에서는 Plug을 다음과 같이 소개하고 있다.

즉, Plug은 1) 엘릭서 기반 웹 애플리케이션들 간 상호 호환가능한 모듈을 만들기 위한 명세이자 2) 다양한 웹서버들과의 연결을 위한 어댑터 역할을 하는 라이브러리이다.

비슷한 냄새를 맡았다면, 맞다! 바로 루비의 Rack과 유사한 개념이다(실제로 엘릭서 언어를 만든 José Valim은 Rails Contributer이기도 하다). Rack과 다른 점이라면, Plug은 라우터(router) 기능까지 제공한다는 점이다(Sinatra의 router 기능을 Plug에서는 기본으로 제공한다).

Plug에 대한 더 자세한 설명은 Plug 문서에 잘 소개되어 있으니 여기서는 생략하기로 하고, 방금 소개한 Plug의 라우터 기능을 이용해 우리의 구현 목표인 API 서버로 한 발짝 더 나가 보자.

API 서버 구현하기

우리가 만들 API 서버는 예컨대 URL /users/tom 을 호출하면 사용자 프로필 정보를 JSON 형식으로 출력하는 간단한 API 서버가 될 것이다. 이제 이를 위해 my_app.ex 파일의 코드를 약간 수정하자.

Plug Router를 사용하면 코드는 다음과 같이 간단해 진다.

defmodule MyApp do
  use Plug.Router
  
  plug :match
  plug :dispatch

  get "/users/:name" do
    conn
    |> put_resp_content_type("application/json")
    |> send_resp(200, Poison.encode!(%{:name => name}))
  end
  
  match _ do
    send_resp(conn, 404, "oops")
  end
  
end

코드를 잠깐 부연하면, get "/users/:name" do 부분에서 URL 맵핑을 통해 웹요청을 처리하고 있으며, 마지막 match _ do 부분은 이도 저도 아닌 나머지 요청에 대한 처리(catch-all) 루틴이다. 코드 중간의 약간 이상한 모양의 ‘|>‘는 Elixir의 파이프(pipe) 연산자다(Unix의 파이프와 같은 개념이다).

루비 개발자라면 코드가 왠지 좀 익숙하게 느껴질 것이다. Plug Router는 실제로 루비의 Sinatra 라우터와 상당히 유사한 DSL을 갖는다. Elixir는 매크로(macro) 라는 방식으로 메타 프로그래밍을 지원하기 때문에 위와 같이 DSL 스타일의 코드를 간단하게 만들어 낼 수 있는 것이다.

명령행에서 API 서버 실행하기

이제 마무리다. 지금까지는 API 서버를 실행하려면 IEx에 접속하여 Cowboy 어댑터를 호출해야 했다. 이제 명령행에서 직접 API 서버를 실행할 수 있도록 변경해 보자.

우선 mix.exs 파일을 열어 application/0 함수를 다음과 같이 변경하자.

def application do
  [applications: [:logger, :cowboy, :plug, :poison], mod: {MyApp, []}]
end

mod 키를 추가하여, 애플리케이션이 시작될 때 실행할 시작 모듈을 MyApp으로 지정하였다.

이제 메인 코드로 와서 파일 속 적당한 곳에 다음과 같이 start/2 함수를 추가하자(이 함수는 애플리케이션이 시작될 때 호출되는 콜백callback 함수다). 그런 다음 이 함수 속에서 Cowboy 웹서버를 실행한다.

def start(_type, _args) do
  Plug.Adapters.Cowboy.http(__MODULE__, [])
end

마지막으로 터미널에서 다음과 같이 mix run 명령을 실행하면,

$ mix run --no-halt

굳이 IEx로 접속하지 않고도 API 서버가 작동되는 것을 확인할 수 있을 것이다. 프로덕션(production) 환경에서라면 Nginx 같은 웹서버를 이 API 서버 앞단에 리버스 프록시(reverse proxy)로 두는 방식도 가능하다.

이것으로 간단한 엘릭서 기반 API 서버 구현에 대한 설명을 마친다. 이 글은 Elixir 웹 개발에 필요한 기본을 따라가려다 보니 미처 설명하지 못한 부분들이 더러 있다. 예를 들면,

데이터 저장소와의 연동. 실제로라면 API 호출 시에 결과값을 반환하기 위해 RDBMS나 NoSQL 등 여러 유형의 데이터 저장소로부터 데이터를 추출하여 결과를 반환해야 할 것이다.
Supervisor 처리. Erlang/OTP에는 수퍼바이저(Supervisor) 라고 하는 기능(이를 ‘비헤비어behaviour’라 부른다)이 제공되며, Elixir에서도 이 수퍼바이저 기능을 지원한다. 이를 이용하면 supervisor/worker 방식의 프로세스 구성을 쉽게 처리할 수 있지만, 여기서는 이 부분은 생략하였다.

여기서는 Elixir 웹 개발의 기본 툴이라 할 수 있는 Plug을 가지고 API 서버를 구현했지만, 만약 좀 더 다양한 기능을 갖춘 서버를 좀 더 쉽게(?) 만들려면 다음과 같은 도구들도 고려해 볼만 하다.

Phoenix Framework: Ruby on Rails 같은 범용 Elixir 웹 프레임워크
Maru: Elixir REST API Framework

이 글에서 사용한 소스코드와 이렇게 만든 앱을 Heroku에 배포하는 방법은 GitHub에서 확인할 수 있다.

참고자료

Elixir와 Plug에 대해 좀 더 깊게 공부해 보고 싶은 분들이라면, 앞서 본문에서 소개한 문서들 외에도 아래 자료를 참고하면 좋을 것 같다.

Elixir Crash Course
Elixir School Plug 튜토리얼: 영문, 국문

AWS Lambda와 API Gateway로 Slack Bot 만들기

2016-04-06T00:00:00+00:00

슬랙(Slack)은 팀이나 프로젝트 단위에서 널리 사용되고 있는 대표적인 협업 메시징 서비스다. 통상적인 메신저 서비스들이 갖는 기본적인 메시징 기능에 더하여 자료를 저장하고 검색하는 등 협업에 필요한 여러 기능들을 갖추고 있고, 또한 모바일과 데스크톱 환경을 아우르는 편리하고 다양한 접점을 제공하기 때문에 많은 사용자층을 확보하고 있는 인기있는 서비스이기도 하다. 게다가 슬랙은 사용자나 개발자가 직접 기능을 확장하고 용도를 변경할 수 있는 다양한 통합(integration) 방법들도 제공한다.

이 글에서는 슬랙이 제공하는 다양한 확장 방법들을 간단히 소개하고 그 중 하나인 슬래시 명령(slash command)을 만들어 보려 한다. 뒤에서 다시 설명하겠지만, 슬래시 명령을 만들기 위해서는 슬래시 명령을 처리할 별도의 호스팅 환경이 필요한데, 여기서는 Amazon 웹서비스(이하 ‘AWS’)에서 제공하는 AWS Lambda와 API Gateway를 사용하여 호스팅을 처리하려 한다.

Slack을 확장하는 방법들

슬랙은 “통합(Integration)” 이라는 이름으로 다양한 확장 방법들을 제공한다.

Incoming Webhooks : 외부 서비스나 앱에서 슬랙으로 웹요청을 보낼 수 있다.
Outgoing Webhooks : Incoming Webook과는 반대로, 특정 슬랙 채널 또는 메시지 내에서 특정한 단어가 나올 경우 슬랙에서 외부로 웹요청을 보낼 수 있다.
Slash Commands : 슬래시(/) 문자로 시작하는 슬랙 명령을 추가로 만들어 넣을 수 있다.
Bot Users : 제목 그대로 ‘봇 사용자’이다. 일반적인 (사람) 사용자와 마찬가지로 슬랙의 사용자 목록에 상주해 있으면서 다른 사용자의 질문에 답을 하거나 서로 대화할 수 있다.

기본적으로 이런 통합은 자신이 관리하는 슬랙 계정 내에 설치하여 사용할 수 있지만 필요한 경우에는 앱(Slack App)으로 만들어 다른 팀 사용자들도 사용할 수 있도록 공개도 가능하며 더 나아가 슬랙의 앱 디렉터리에 등록할 수도 있다. 또한 슬랙에서 할 수 있는 대부분의 작업들은 별도의 Web API로 공개되어 있기 때문에 이 API를 이용하면 여러 가지 더 다양한 슬랙 확장을 구현할 수도 있다.

슬래시 명령(Slash Command) 만들기

슬랙에서 사용자는 슬랙의 대화창에서 슬래시(/) 문자로 시작하는 명령을 호출할 수 있으며 이 때 사용하는 명령을 슬래시 명령이라고 부른다. 예를 들어, 슬랙에서 어떤 채널에 다른 사용자를 초대할 경우 대화창에서 /invite @name 이라고 명령하면 된다. 슬랙에서는 이런 슬랙이 기본적으로 제공하는 명령(Built-in Commands) 말고도 자신의 팀에서만 사용할 명령(Custom Commands)을 추가로 만들어 넣을 수 있는 확장 기능을 제공한다.

슬래시 명령을 만들려면 다음과 같은 절차를 따르면 된다:

슬랙에서 자신의 계정에 로그인한 다음, “Apps & Integrations” 메뉴로 들어가 “Build a Custom Integration” 창에서 새 슬래시 명령을 만든다.
이 슬래시 명령을 받아서 처리할 웹 서버를 구현한 다음, 그 URL값을 슬랙의 슬래시 명령 설정 창에 추가한다.

구현은 아주 간단하다. 예를 들어, /hello 라는 슬래시 명령을 하나 추가로 만들려면 이 명령에 대응하는 웹 URL만 하나 만들어 맵핑시키면 된다. 그러면 슬랙에서 /hello 라는 명령이 들어오면 슬랙은 해당 명령과 연결된 URL로 웹요청을 보내고 그 결과값을 받아 슬랙의 대화창에 다시 표시한다.

이 때 슬랙이 외부 URL로 HTTP 요청을 보낼 때 실어 보내는 데이터는 다음과 같은 형식이다. 아래 데이터는 슬랙의 대화창에서 ‘/weather 94070‘이라고 주었을 때 슬랙이 보내는 데이터의 샘플인데, 슬래시 명령 /weather 뒤에 추가되는 값 94070이 HTTP 데이터 상에는 text라는 키값으로 잡힌다는 데 유의하자(나중에 이 값을 받아 사용할 것이다).

token=gIkuvaNzQIHg97ATvDxqgjtO
team_id=T0001
team_domain=example
channel_id=C2147483705
channel_name=test
user_id=U2147483697
user_name=Steve
command=/weather
text=94070
response_url=https://hooks.slack.com/commands/1234/5678

이 값을 전달받은 웹서버 측에서는 Slack의 메시지 형식에 맞춰 메시지를 구성하여 다음과 같이 JSON 형식으로 다시 슬랙에 반환하면 된다.

{
    "text": "I am a test message http://slack.com",
    "attachments": [
        {
            "text": "And here's an attachment!"
        }
    ]
}

이 때 HTTP 요청은 GET/POST 방식 모두 가능하며(단, 슬랙 앱으로 만들 경우에는 반드시 POST 방식을 써야 함), POST 방식으로 보낼 경우 헤더의 Contet-Type은 application/x-www-form-urlencoded로 지정된다. 더 자세한 내용은 슬래시 명령 API 문서를 참조하면 된다.

그럼 실제 만들어 보자. 슬래시 명령을 만들려면 우선 Slack에 로그인한 다음 Slack에서 제공하는 새 슬래시 명령 만들기 창에 접속하여 필요한 정보를 입력하는 것부터 시작하면 된다. 이 창에서 만들고자 하는 슬래시 명령을 입력하고 “Add Slash Command Integration” 버튼을 클릭하면 나만의 커스텀 슬래시 명령이 생성된다. 여기서는 간단하게 검색어를 위키피디어와 연결하는 /wiki 라는 명령을 하나 추가해 보기로 하겠다.

이어 나오는 페이지에서는 슬래시 명령에 대응하는 URL을 적어주면 된다. 아직 우리는 웹서버를 만들지 않았기 때문에 일단 이 부분은 비워 두자. 나중에 채울 것이다.

이걸로 끝이다. 참고로, 이 때 함께 제공되는 토큰(Token)은 등록된 URL로 들어오는 요청이 슬랙에서 보낸 것이 맞는지 확인하는 용도로 사용하면 된다.

슬랙 봇 호스팅하기

이제 앞서 비워둔 URL 칸을 채워 보자. 이를 위해서는 어딘가에 웹서버를 하나 만들어 두고 슬랙에서 넘어오는 슬래시 명령을 받아서 슬랙 메시지 형태로 반환하는 코드를 작성해야 한다. 웹서버는 웹요청을 받아 처리할 수 있는 환경이라면 뭐든 상관 없지만, 여기서는 아마존 웹서비스에서 제공하는 AWS 람다(Lambda)를 사용하여 슬래시 명령을 호스팅해 보기로 한다.

Lambda 함수 만들기

AWS Lambda는 “이벤트에 응답하여 코드를 실행하고 자동으로 기본 컴퓨팅 리소스를 관리하는 컴퓨팅 서비스“라고 소개되어 있다. 지금과 같이 경량의 함수 수준의 간단한 로직을 만들어 올리고 즉시 실행하는데는 제격인 서비스다. 그럼 AWS Lambda Console에 접속하여 새로운 람다 함수(Lambda function)를 하나 만들어 보자(Lambda는 현재 US East와 EU를 포함한 몇몇 리전에서만 제공된다). Lambda에는 슬랙 앱을 만들 때 사용할 템플릿(Blueprint)도 제공되지만, 여기서는 템플릿 없이 직접 만들기로 한다.

“Create a Lambda function” 버튼을 눌러 시작하고 “Select blueprint” 창은 그냥 Skip 하면 다음과 같이 Lambda 함수를 추가하고 설정할 수 있는 창이 나온다. 여기서 적당한 함수 이름을 주고 코드를 추가한 다음 저장하면 람다 함수가 만들어 진다.

이제 코드를 작성할 차례다. 2016년 4월 현재 AWS Lambda는 3개의 프로그래밍 언어(Node.js, Python, Java)만 지원한다. 여기서는 그 중 Node.js를 사용하기로 한다. 다음에서 보듯 코드는 아주 간단하다. 요청을 받아 응답을 반환하는 게 전부다.

// The entry point of this lambda function.
exports.handler = function(event, context) {
  console.log(event);

  context.succeed({
    "response_type": "in_channel",
    "text": "I found some about \"" + event.text + "\"",
    "attachments": [
        {
            "text": "For more info please visit to \nhttps://ko.wikipedia.org/wiki/" + event.text,
            "color": "#7CD197"
        }
    ]
  });

};

앞서 설명한 대로 슬랙에서 넘어오는 값인 text를 받아서 메시지를 구성하였다. context.succeed() 함수는 AWS Lambda에서 사용하는 반환 함수이며, 이 함수의 인자로 슬랙의 메시지를 담아 반환하면 된다. 이 때 반환값은 JSON 형식으로 작성하면 되고, 슬랙의 메시지 형식에 맞추면 된다. 슬랙에서는 메시지 출력을 미리 보고 테스트해 볼 수 있도록 Message Builder도 제공하기 때문에 더 쉽게 메시지를 테스트해 볼 수 있다.

Lambda에 관한 더 자세한 내용은 AWS Lambda 문서를 참조하면 된다.

API Gateway 연동하기

Lambda 함수는 기본적으로 이벤트에 반응한다. 여기서 말하는 이벤트는 아마존 웹서비스에서 발생하는 어떤 것이다(예를 들면 S3에 어떤 파일을 추가하는 것과 같은 이벤트). 그렇지만 우리에게 필요한 것은 웹 URL이다. AWS Lambda를 웹 호출을 통해 실행시키려면 또다른 아마존 웹서비스 중 하나인 Amazon API Gateway를 연결해야 한다.

역시 이번에도 AWS API Gateway Console로 접속하여 새 API를 하나 만들자. “Create API” 버튼을 누르고 새로 만들 API의 이름을 입력하면 API 리소스(Resources) 설정 창이 나온다. 이 때 새로 Resource와 Method를 추가해 주면 간단하게 지금 사용할 API가 만들어진다. 여기서 말하는 리소스와 메서드는 흔히 사용하는 REST 방식의 API에서 말하는 그 리소스와 메서드 개념을 생각하면 된다. 앞서 우리는 Slack에서 슬래시 명령을 설정할 때 POST 방식으로 호출하기로 정했기 때문에 여기서 메서드도 POST로 맞춰 생성하였다. 그런 다음, Integration Type을 “Lambda Function”으로 맞추고 방금 전 만든 람다 함수를 연결시켜 주면 API Gateway와 Lambda 함수 간의 연결이 완료된다.

여기까지 하면 API와 람다 함수 간의 연결 작업은 완료되지만, 한 가지 남은 일이 있다. Slack이 API를 통해 보낸 값을 람다 함수가 제대로 받아서 처리하게 하려면 약간의 데이터 변환이 필요하다. Slack은 API를 호출할 때 HTML Form 형식으로 데이터를 전달하지만 API Gateway를 통해 람다함수로 전해지는 데이터는 기본적으로 JSON 형식이기 때문에 Slack으로부터 받은 POST 데이터를 Lambda 함수가 처리할 수 있도록 변환하는 작업을 해 줘야 한다. 이 작업은 API Gateway의 Method Execution 설정 창에서 할 수 있다.

이 Method Execution 창에 나와 있는 4가지 변환 과정 중 우리가 건드릴 부분은 “Integration Request” 영역이다. 이 단계는 API로 들어온 요청을 Lambda 함수로 보내기 직전 단계이며, 이 단계에서 다음과 같이 “Mapping Template”을 추가해 주면 된다. 이 때 Content-Type을 “application/x-www-form-urlencoded” 로 설정한 이유는, 앞서 잠깐 언급했듯이, Slack이 슬래시 명령을 호출할 때 이 방식을 사용하기 때문이며, 아직 Amazon API Gateway에서는 폼 방식의 데이터를 JSON 형식으로 변환하는 부분을 제공하지 않기 때문에 폼 방식의 POST 데이터를 JSON으로 변환시키는데 필요한 맵핑 루틴을 직접 만들어서 추가한 것이다(아마 조만간 API Gateway에서 이 부분은 자동화시킬 것으로 예상되지만). API Gateway의 Mapping Template과 관련된 더 자세한 내용은 Amazon API Gateway 문서를 참조하자.

지금까지의 모든 작업을 완료했으면 이제 API를 배포하는 일만 남았다. (물론 그 전에 API가 제대로 작동하는지 테스트하는 일이 남았지만 테스트 단계 부분의 설명을 생략한다) API의 배포는 AWS 콘솔에서 Deploy API 메뉴를 실행하면 된다.

배포가 성공적으로 완료되면 API의 URL이 발급된다. 이 URL을 앞서 만든 슬랙의 슬래시 명령 설정 창의 URL 입력란에 붙여 넣으면 하나의 슬래시 명령이 완성되는 것이다.

Hello, 슬랙 봇!

이제 이 모든 작업이 끝났으면 Slack으로 돌아오자. 슬랙의 대화창에서 다음과 같이 방금 우리가 만든 슬래시 명령을 입력하면 Slack 봇이 반갑게 우리를 맞아 줄 것이다.

Add to Slack 버튼 만들기

Slack 봇(이 경우 슬래시 명령)을 내 슬랙 계정의 팀 내에서만 사용한다면 여기까지가 끝이다. 그렇지만 공들여 만든 Slack 봇을 세상에 공개하여 다른 팀에서도 활용할 수 있게 하고 싶은 경우에는 지금까지 만들었던 슬랙 봇을 앱(Slack Apps)으로 만들어 공개할 수도 있다. 이 때 다른 팀에서 자신의 슬랙 계정에 내 슬랙 봇(앱)을 쉽게 추가할 수 있도록 해 주는 방법이 바로 “Add to Slack” 버튼을 만들어 웹사이트나 서비스 홈페이지에 공개하는 것이다. (아마 웹을 돌아다니다 보면 이 버튼이 달려 있는 사이트나 서비스들을 종종 보게 될 것이다. 앞으로 점점 더 많이^^)

슬랙은 Add to Slack 버튼(이하 ‘슬랙 버튼’)을 간단하게 만들어 사이트에 붙일 수 있도록 해 주는 자동 코드 생성기를 제공하기 때문에 슬랙 버튼을 만들어 붙이는 일은 전혀 어려울 게 없다. 그저 복사해서 붙여 넣으면 그만이다.

다만 이 슬랙 버튼이 제대로 작동하려면 OAuth 인증을 거쳐야 한다. 슬랙 앱은 OAuth 2.0 기반의 인증을 사용하며 인증 플로(flow)는 OAuth 2.0의 코드 기반 인증 방식을 따른다. 그러므로 슬랙 버튼을 만들기 위해서는 이 OAuth 인증 처리 부분을 별도로 만들어 주어야 한다.

이 부분도 물론 앞서 사용했던 AWS Lambda와 API Gateway를 이용해 만들 수도 있겠지만, OAuth 인증을 통해 받은 액세스 토큰(Access Token) 값이나 기타 다른 정보들을 저장하였다가 다시 사용하고 하기 위해서는 Lambda 보다는 EC2나 구글 클라우드 또는 Heroku 같은 전통적인(?) 호스팅 플랫폼을 사용하는 것이 더 좋을 것 같다.

OAuth 인증의 처리는 Google이나 Facebook, Twitter 등 여타 다른 OAuth 기반의 서비스에서 사용하는 방식과 크게 다르지 않고 이미 많은 자료들이 공개되어 있기 때문에 여기서 구현 설명은 생략하기로 한다.

참고자료

모바일 웹사이트에 구글 AMP 적용하기

2016-02-24T00:00:00+00:00

최근 모바일 콘텐츠 플랫폼을 둘러 싼 속도(speed) 경쟁이 뜨겁다. 작년 초 페이스북(Facebook)이 자사의 모바일 앱에 최적화된 콘텐츠를 제공하는 인스턴트 아티클(Instant Articles)을 출시한 것을 시작으로, 이어 애플이 애플뉴스를, 그리고 지난해 하반기에 구글이 AMP(Accelerated Mobile Pages, 우리말로는 “빠른 게재 모바일 페이지”)라는 모바일 콘텐츠 최적화 표준을 들고 나오면서 소위 “인스턴트(instant)”한 콘텐츠를 앞세운 플랫폼 간의 경쟁이 가속화된 듯 하다.

이 중 구글이 제시한 모바일 콘텐츠 최적화 표준인 AMP에 대해 조금 알아보기로 하자.

AMP란?

AMP는 한마디로 말해 모바일 콘텐츠 최적화 표준이다. 뉴스나 블로그 같은 정적인 콘텐츠를 만들어 배포하는 온라인 매체가 이 AMP 표준에 맞춰 콘텐츠를 작성하여 게시하면 기존의 모바일 콘텐츠보다 약 15% ~ 85%의 성능 향상을 가져올 수 있다고 구글은 주장한다. 이를 위해 AMP는 웹 콘텐츠 제작에 사용되는 기술에 제약을 가한다. 한마디로 속도를 떨어뜨리는 기술의 사용을 배제함으로써 속도의 향상을 꽤하는 방법인 셈이다.

예를 들어, 아래 2개의 링크는 같은 워싱턴포스트의 기사를 각각 일반적인 HTML 페이지와 AMP로 나눠 보여준 것이다.

보면 알 수 있듯, AMP 페이지는 일반적인 HTML 페이지에서 광고나 자바스크립트, CSS 애니메이션 등과 같은 동적인 요소들을 제거하여 “알맹이”만 남겨 둔다. 물론 그렇다고 광고나 자바스크립트를 삽입하지 못한다는 의미는 아니고, 구글 AMP에서 정한 규약에 맞춰야 한다는 말이다. 통상적으로 웹사이트에서 속도를 느리게 만드는 요소들에 제약을 가하니 당연히 속도는 빨라 질 밖에 없다.

– 출처: Washington Post

구글 공식 문서에 다르면 AMP는 다음 3가지 요소로 구성된다.

AMP HTML
AMP JS
Google AMP Cache

이 중 AMP HTML은 기존의 HTML 문서에서 속도에 부담을 주는 요소를 배제하고 몇몇 확장 속성들을 추가한 일종의 HTML 확장이고, AMP JS는 이런 AMP HTML을 읽고 렌더링하는 런타임(Runtime) 이다. 그리고 Google AMP Cache는 구글이 제공하는 AMP HTML 문서의 캐싱 서비스이다. 즉 AMP 문서를 만들어 올리면 구글이 자체 CDN을 통해 더 빠른 액세스를 할 수 있게 해주는 것이다.

이렇게 작성된 AMP, 즉 “빠른 게재 모바일 페이지”는 모바일 디바이스 환경에서 구글 검색(Google Search)을 수행할 경우 기존의 웹페이지를 대체하여 보여지게 되고, 따라서 사용자는 보다 빠른 모바일 사용자 경험을 얻게 되는 것이다.

물론 속도를 얻기 위해 희생해야 하는 것들도 많다. 예를 들어, 외부 자바스크립트를 사용할 수 없다거나 CSS도 하나만 링크를 걸 수 있고 인라인 스타일이나 속도에 부담을 주는 요소들을 쓸 수 없다. 또한 이미지나 미디어 파일의 경우 기존의 HTML 방식과는 다른 AMP 표준에서 제시하는 별도의 커스텀 요소를 써야 하는 식이다.

AMP에 대한 더 자세한 내용은 아래 참고자료를 참고하면 되며, 특히 구글 AMP가 어떤 방식으로 웹페이지의 속도를 개선하는지에 대한 더 자세한 내용은 구글이 공개한 How AMP Speeds Up Performance 문서를 참고하면 좋을 것이다.

AMP 문서 만들기

AMP 문서는, 그 문서만도 만들 수 있지만, 통상적인 경우 기존 웹문서(원본 문서)가 있고 그에 대한 대응으로, 별도 문서 즉 원본 문서에 대한 모바일 최적화된 버전의 문서로 만드는 것이 일반적일 것이다. 예를 들어 기존에 온라인 매체가 있어서 콘텐츠를 게시하고 있는 경우 이들 각각의 콘텐츠에 대해 AMP 문서를 만들어 기존의 문서와 1:1로 대응하는 AMP 문서를 한 벌로 만드는 방식이다.

AMP 문서는 AMP HTML 규격을 따라야 하며 AMP HTML은 다음과 같은 형식을 갖는다.

<!doctype html>
<html amp lang="en">
  <head>
    <meta charset="utf-8">
    <link rel="canonical" href="http://example.com/original-article.html" >
    <meta name="viewport"
          content="width=device-width,minimum-scale=1,initial-scale=1">
    <style>body {opacity: 0}</style>
    <noscript>
      <style>body {opacity: 1}</style>
    </noscript>
    <script async src="https://cdn.ampproject.org/v0.js">
    </script>
  </head>
  <body>
    Hello, Mobile World!
  </body>
</html>

HTML 문서의 형식은 일반적인 문서와 다를 게 없어 보이지만 html 태그에 커스텀 속성으로 amp(또는 이모지 ⚡)가 추가되어 이 문서가 일반 HTML 문서가 아닌 AMP HTML 문서임을 표현하고 있으며, 공식 링크(canonical link) 값을 원래의 웹문서로 향하게 만들어 이 AMP 문서의 원 출처와 연결시키고 있다. style 부분에서는 AMP 문서 렌더링 과정에서 발생할 수 있는 FOUC를 방지하기 위해 시작 시점의 opacity 값을 0으로 두고 있다. 마지막으로 script 태그에서 AMP 런타임 자바스크립트 모듈을 비동기 방식으로 호출하면 AMP JS에 의해 문서가 처리된다. 그 밖에도 여러 가지 마크업에 대한 제약사항들이 있는데 더 자세한 내용은 구글의 공식 문서를 참조하면 된다.

이미지 파일 같은 경우는 다음과 같이 amp-img 라고 하는 AMP 표준에서 제공하는 별도의 커스텀 태그를 사용해야 하고 width값과 height값을 반드시 명시해야 한다. AMP 런타임이 이미지의 렌더링 위치와 시점을 정확하게 제어할 수 있게 하기 위함이다.

<amp-img src="welcome.jpg" alt="Welcome" height="400" width="800"></amp-img>

비디오나 트위터 박스, 또는 구글 분석기 코드나 광고 태그 같은 것들도 마찬가지로 AMP 표준에서 제공하는 커스텀 태그를 이용하여 처리하여야 한다. 예를 들어, 동영상 파일을 웹페이지 속에 삽입할 경우에는 다음과 같이 amp-video 태그를 써야 하며,

<amp-video width=400 height=300 src="https://yourhost.com/videos/myvideo.mp4"
    poster="myvideo-poster.jpg">
  <div fallback>
    <p>Your browser doesn’t support HTML5 video</p>
  </div>
  <source type="video/mp4" src="foo.mp4">
  <source type="video/webm" src="foo.webm">
</amp-video>

트위터 트윗을 임베드시킬 경우는 써드파티 컴포넌트인 amp-twitter 태그를 사용 하는 식이다.

<amp-twitter width=390 height=50
    layout="responsive"
    data-tweetid="638793490521001985">
</amp-twitter>

문서 간 연결

앞서도 잠깐 언급 했듯이 AMP 문서와 기존 웹문서 간에는 공식 링크(canonical link)를 통해 서로 연결된다. 예를 들어, AMP 문서에서는 다음과 같이 link 태그를 이용해 공식 문서(원본 문서)로의 링크를 삽입하고,

<link rel="canonical" href="https://www.example.com/url/to/full/document.html">

원본 문서에는 다음과 같이 amphtml 문서의 위치를 지정함으로써 서로 연결된다.

<link rel="amphtml" href="https://www.example.com/url/to/amp/document.html">

AMP 문서 검증하기

이렇게 만든 AMP 문서는 구글 크롬 브라우저의 개발자 도구 콘솔을 통해 검증(validation)할 수 있다. AMP 문서 URL 뒤에 #development=1 해시문자열을 추가하면 검증 결과가 콘솔에 표시된다.

CMS에 AMP 적용하기

CMS를 사용하고 있는 경우라면, 아마도 곧 많은 CMS가 AMP를 지원하는 모듈을 만들어 제공하지 않을까 싶다. 여기서는 전세계 25% 이상의 CMS 점유율을 자랑하는 [워드프레스(WordPress)][https://wordpress.org/]와 인기있는 정적(static) 웹사이트 저작도구인 Jekyll에서 AMP를 적용하는 방법만 간단히 소개한다.

Jekyll의 경우는 플러그인을 통해 사이트를 빌드하는 과정에서 AMP를 적용할 수 있다. 구글의 AMP 프로젝트 공식 문서 사이트가 Jekyll을 사용하여 작성되었기 때문에 이를 참조하면 좋을 것이다.

워드프레스는 AMP가 출시된 이후로 계속해서 AMP 프로젝트와 보조를 맞추어 오고 있다. 워드프레스 개발사인 Automattic이 참여하여 최근 출시한 AMP 플러그인 같은 경우, 플러그인을 설치하는 것만으로 AMP 문서를 자동 생성해 준다. 또한 워드프레스닷컴(wordpress.com) 사이트의 경우 워드프레스가 이미 자동으로 AMP 문서를 생성하기 때문에 사용자가 별도로 할 일은 없다.

또한 일반적인 워드프레스 사용자들이라면 구글 AMP 뿐 아니라 페이스북 Instant Articles와 애플의 Apple News 포맷까지 모두 지원하는 PageFrog라는 플러그인도 이미 나와 있기 때문에 이를 검토해 봐도 좋을 듯 싶다.

AMP의 현재와 미래

구글 검색엔진은 어떤 웹문서가 AMP 버전의 문서를 가질 경우 이 문서를 처리하여 모바일 웹 검색결과에 AMP 문서임을 표시하고 사용자가 AMP 문서가 딸린 웹문서를 모바일 디바이스를 통해 클릭했을 경우 기존 웹문서가 아닌 AMP 문서를 보여준다(2016-02-24 현재, 구글 검색에 이미 적용되었다고 보도되고 있지만, 아직 국내에는 적용되지 않은 듯 하다). 번개마크 달린 AMP 아이콘이 표시(아래 그림) 되는데, 공교롭게도 페이스북의 인스턴트 아티클도 포스팅 위에 번개마크를 표시하고 있어 재밌다.

아직 국내에서는 AMP를 적용한 사례는 없어 보이지만 아마도 곧 많은 언론사 사이트와 온라인 매체가 AMP를 적용할 것으로 보인다. 게다가 페이스북이 올 4월에 있을 F8 컨퍼런스에서 인스턴트 아티클을 모든 매체에 개방하기로 이미 선언한 상태이기에 두 “빠름” 간의 경쟁도 더욱 가속화될 듯 싶다.

다만 AMP가 W3C 표준은 아니라는 점, 다른 콘텐츠 관련 벤더들의 참여와 지원이 얼마나 되느냐 하는 점, 원본 문서와는 별개로 또 하나의 문서를 만들어야 한다는 온라인 매체(콘텐츠 제공자)들의 부담 등은 AMP가 앞으로 풀어야 할 숙제로 보인다. 물론 앞으로 모바일 디바이스 성능이 더 좋아져 AMP 같은 해법이 필요 없어질 날이 오면 더 좋겠지만.

마침 지난 해 가을에 서울에서 열린 “Google for Mobile 2015” 컨퍼런스 동영상이 최근 공개가 되었다. 그 날 세션 중 AMP를 소개한 세션 영상이 들어 있으니, 시간나는 분들은 한번 보는 것도 좋을 듯 싶다.

참고자료

Accelerated Mobile Pages Project (프로젝트 공식 웹사이트)
AMP: Accelerated Mobile Pages 네이버 D2 News

Calypso와 WordPress의 미래

2015-11-25T00:00:00+00:00

엊그제(2015/11/23), WordPress.com의 개발사이자 운영사인 Automattic에서 코드명을 ‘칼립소(Calypso)‘로 명명한 새로운 워드프레스 어드민 인터페이스를 선보였습니다. 이미 WordPress.com에 적용되었고 설치형 워드프레스를 사용하는 경우도 JetPack 플러그인을 연동한 사이트라면 마찬가지로 이 새 인터페이스를 사용할 수 있습니다. 여기에 더해 칼립소 코드 자체는 오픈소스로 GitHub에 공개하였고 맥 사용자들을 위한 데스크톱용 앱도 함께 출시하였습니다.

얼핏 생각하면, 하루가 멀다하게 새로운 기능과 업데이트들을 쏟아내고 있는 워드프레스가 새 인터페이스를 하나 선보인 게 뭐 그리 대수로운 일일까 생각할 수 있습니다. 혹은 갑작스런 인터페이스의 변화에 짜증이 나거나 조금 당황스러워하는 사용자들도 있을 것입니다. 인터페이스가 좀 변하긴 했지만 예전보다 기능도 좋아졌고 또 더 빨라졌다고 하니 그냥 새 인터페이스에 적응하면서 쓰면 되지 하고 생각하면 그만입니다.

그런데 워드프레스라는 하나의 플랫폼(platform) 입장에서 바라보면 이번의 이 변화는 기존의 여느 판올림들과는 성격이 조금 다른, “제법 중요한” 시도입니다. 왜 그런지, 그리고 이번의 이 칼립소 프로젝트가 이미 전 세계 웹사이트의 약 25%를 장악하고 있는 워드프레스의 미래에 어떤 영향을 미칠 수 있을지 한번 생각해 보기로 하겠습니다.

우선 칼립소 프로젝트가 무엇인지부터 정확하게 알 필요가 있습니다. 오픈소스로 공개된 칼립소 프로젝트의 GitHub에는 칼립소를 다음과 같이 소개하고 있습니다.

즉, 칼립소는 싱글페이지 웹앱(Single Page Webapp) 방식으로 제작된 WordPress.com의 새로운 관리자 대시보드로, WordPress.com의 REST API를 기반으로 동작합니다. 기술적으로는 Node나 Express, React와 Flux 같은 최근 프론트엔드 중심의 웹개발에서 흔히 사용하는 인기있는 오픈소스 기술들을 사용하였습니다.

그럼 뭐가 바뀐걸까요? 알다시피 기존의 워드프레스는 PHP 기반이었습니다. 물론 프로그램 여기저기에서 자바스크립트(특히 jQuery)가 사용되고 있었지만, 주는 어디까지나 서버측 웹 개발 언어인 PHP를 기반으로 하고 있었습니다. 그런데 이번의 칼립소 프로젝트에는 PHP가 단 한줄도 사용되지 않았습니다. 대신 서버측 구현에는 Node/Express를 사용하여 thin 서버 방식으로 처리하고 실제 모든 기능들은 React와 JavaScript, 그리고 워드프레스의 REST API를 사용하여 클라이언트 측에서 처리하는 것으로 바뀌었습니다.

얼핏 생각하기엔, 최근 새로운 블로깅 플랫폼으로 각광받는 미디엄이나 워드프레스의 대안으로 떠오르는 Node 기반의 CMS 플랫폼인 ghost를 따라한건가 하는 생각도 들 것입니다. 워드프레스가 지금껏 10년 넘게 써오던 PHP를 버리고 Node 기반으로 갈아탄 건가하는 의문도 생길 수 있습니다. 물론 전혀 아닙니다. 워드프레스(엔진) 자체는 여전히 PHP 기반으로 동작하고 그 사실은 앞으로도 변화가 없을 것입니다. 다만 이번 칼립소 프로젝트의 시도는 워드프레스가 기존의 웹사이트 제작 도구에서 한걸음 더 나아가 웹애플리케이션을 위한 기반 플랫폼으로서의 변화를 시도한 것이라고 보는 것이 맞을 것입니다.

즉, 지금까지의 워드프레스가 PHP를 기반으로, 어드민 대시보드와 플러그인 시스템, 그리고 테마가 모두 한데 결합되어 있는 방식이었다면(아래 그림),

앞으로의 워드프레스는 아마도 이런 그림이 될 듯 싶습니다. 즉 워드프레스는 콘텐츠를 저장하고 관리하는 API 서버로 동작하고, 대시보드와 테마를 포함한 모든 프론트엔드는 이 API 서버의 클라이언트로서 독립해서 동작하는 방식입니다. 이번의 칼립소 프로젝트는 이에 기반한 워드프레스의 공식적인 첫 번째 시도구요.

어떻게 보면 이번 실험은 이미 시장을 완전히 장악한 벤더가 시도하기엔 조금 무모한 실험 같아 보이기도 합니다. 그래서인지 Automattic의 CEO인 매트 뮬렌웨그((Mattew Mullenweg)는 칼립소 프로젝트를 소개하는 그의 블로그를 다음과 같은 말로 시작하고 있습니다.

One of the hardest things to do in technology is disrupt yourself.

스스로를 뒤엎는 일. 아마도 쉬운 결정은 아니었을 것입니다. 이미 10년의 역사를 가진, 게다가 지금 현재 세상에서 가장 높은 시장점유율과 인기를 구가하고 있는 제품이 채택하기엔 더더군다나 쉬운 결정이 아니었으리라 짐작됩니다. 그렇지만 변화하는 웹과 기술 환경에서 오래도록 살아남기 위해 워드프레스가 취한 이번 결정은 아마도 워드프레스, 그리고 워드프레스 생태계에 속해 있는 많은 개발사들과 개발자들에게 새로운 도전과 함께 새로운 기회들을 던져 줄 것이라 생각이 듭니다.

물론 여러 가지 해결할 문제들도 남아 있습니다. 얼핏 생각해도 PHP 기반으로 되어 있는 워드프레스의 확장시스템을 어떻게 새 시스템으로 교체할 건지, 아직 SEO 측면에서 완전한 해결책이 제시되고 있지 않은 SPA환경을 워드프레스가 어떤 식으로 해결할지, 기존의 플러그인과 테마 시스템과의 관계는 어떻게 가져갈지 등등. 하지만 칼립소가 세상에 나오기 훨씬 이전부터 워드프레스를 웹 애플리케이션 개발을 위한 도구로 활용하려는 움직임들이 워드프레스 개발자들 사이에는 여기저기서 있어 왔고, 이제 워드프레스에서 조차 공식적으로 ‘새로운 방향’을 제시한 셈이니, 앞으로는 지금까지와는 완전히 차원이 다른 새로운 생각 더 좋은 시도와 실험들이 워드프레스와 오픈소스 커뮤니티에서 생겨날 것은 분명해 보입니다.

아래 표는 워드프레스 개발자 블로그에서 제공하는, 칼립소가 기존의 WordPress.com과 비교해 무엇이 바뀌었는지를 보여주는 표입니다. 정말이지, 누구 말처럼, “바뀐 건 오직 하나, 전부!” 이로군요.

출처: The Story Behind the New WordPress.com

공교롭게도 이번에 칼립스가 발표된 날이 WordPress.com이 세상에 나온지 꼭 10년이 되는 날이라는군요. 10년이면 긴 세월이죠. 오랜 시간을 워드프레스와 함께 해 온 워드프레스 개발자들에겐 새로운 숙제와 먹거리가 가득 생긴 날이기도 합니다. :)

워드프레스로 웹서비스(온라인 모임) 만들기

2015-10-21T00:00:00+00:00

통상적으로 워드프레스는 웹사이트를 만드는 도구로 알려져 있으며 지금도 개인이나 기업의 블로그나 정적인 웹사이트를 만드는데 주로 쓰이고 있는 것이 사실입니다. 그렇지만 최근 워드프레스는 강력한 CMS 기능과 유연한 확장성 등을 기반으로 사용자 기반 웹서비스나 동적인 웹애플리케이션 개발에도 사용되고 있습니다. 특히 최근 업데이트된 WP REST API는 워드프레스를 웹서비스의 기반 플랫폼으로도 사용할 수 있는 가능성을 분명하게 보여줍니다.

유스풀패러다임에서는 워드프레스로 웹서비스 만들기 튜토리얼을 수 회에 걸쳐 저희 [디지털 마케팅의 기술](http://blog.usefulparadigm.com/) 블로그를 통해 연재하려고 합니다. 연재 순서는 아래와 같으며 글이 올라오는대로 이 페이지는 계속해서 업데이트할 예정입니다. 많은 관심 부탁 드립니다.

1. 모임목록 만들기

워드프레스의 커스텀 포스트 유형(Custom Post Type) 기능을 활용하여 “모임” 유형을 만들고 메인 화면에 모임 목록을 표시합니다.

2. 새 모임 개설하기

사용자가 프론트엔드(frontend)에서 직접 모임을 만들고 저장할 수 있는 기능을 구현합니다.

3. 사용자 로그인하기

로그인한 사용자만 모임을 만들 수 있도록 사용자 로그인 기능을 추가합니다.

4. 모임 참가신청 받기

사용자가 모임에 참가 신청을 하고 참가신청자 목록을 볼 수 있는 기능을 구현합니다.

5. 지도와 지역별 메뉴

모임에 날짜와 장소 정보를 추가하고 장소 정보에 기반한 지역별 메뉴를 구현합니다.

UPDATE(2016-06-30) 워드프레스로 모임서비스 만들기는 WordPress 가이드로 자리를 옮겼습니다.

소스코드:

https://github.com/usefulparadigm/moiming-twentyfifteen

웹앱을 위한 REST API 서버 솔루션들

2015-09-08T00:00:00+00:00

모바일 환경이 사용자 경험의 중심으로 자리잡으면서 애플리케이션 개발에서도 프론트엔드(frontend) 영역이 차지하는 비중이 갈수록 커지고 있습니다. iOS나 Android 같은 모바일앱은 말할 것도 없고 웹앱 영역에서도 ‘한페이지 앱(Single Page Application)’의 필요성은 점점 증가하고 있습니다. 이런 추세는 당연히 프론트엔드 웹개발 프레임워크들에도 반영이 되어 Backbone.js 를 필두로 Angular나 Ember, 그리고 최근 hot한 바람몰이를 하고 있는 React에 이르기까지 대부분의 프레임워크들이 모두 한페이지 내에서 처리되는 웹앱을 만드는데 초점이 맞춰져 있습니다.

이런 프론트엔드 중심 개발 흐름은 기존의 서버 중심 웹개발을 상당 부분 ‘무력화’시킵니다. 웬만한 렌더링(rendering)은 서버에서 모두 처리되어 클라이언트는 그저 서버로부터 받은 “화면”을 잘 뿌리기만 하면 되던 때는 이제 아련한 옛추억이 되어가고 있습니다. 오늘날 서버는 갈수록 API 서버, 특히 REST 기반의 API 서버로 탈바꿈하여 클라이언트의 요청에 맞춰 JSON 데이터를 제공하는 역할을 담당하는 쪽으로 변했습니다.

사실 서버를 개발하는 입장에서는 웹 브라우저나 여러 가지 렌더링 이슈들에 신경쓸 필요 없이 단순하게 데이터를 클라이언트로 넘기기만 하면 되기 때문에 예전보다 훨씬 할일이 줄어들었다고도 할 수 있습니다. 그렇지만 다양한 프론트엔드 측의 처리를 효과적으로 지원하기 위해서는 REST API의 비중 또한 커지기 마련입니다. ‘그저’ JSON 데이터를 보내는데 그치는 게 아니라 API의 설계부터 HTTP 연동, 데이터 패킷 구성이나 API 인증과 같은 다양한 이슈들의 처리가 중요해집니다.

그렇다면 이런 프론트엔드 웹앱을 지원하기 위한 REST API 서버로 사용할 수 있는 솔루션에는 어떤 것들이 있을까요? 더 다양한 방법들이 많이 있겠지만 여기서는 크게 구축형과 설치형, 그리고 클라우드 서비스로 나눠 간단하게 몇 가지만 소개해 보기로 합니다. 웹앱이 중심이지만 여기서 소개한 REST API 서버 솔루션들은 모바일앱의 백엔드(backend)로도 동일하게 사용될 수 있습니다.

구축형 솔루션

구축형 솔루션은 말 그대로 API 서버를 직접 구축하는 것입니다. 지구 상에 존재하는 거의 대부분의 프로그래밍 언어는 웹개발을 지원하기 때문에 그 중 선호하는 언어를 사용하여 API 서버를 구성할 수 있겠지만, 그 전에 시중에 나와있는 툴킷(toolkit)이나 프레임워크(framework)들은 없는지 먼저 검토하는 것이 “바퀴를 새로 만들지 않는” DRY한 방법입니다. 저희는 주로 서버측 API 개발에 루비(ruby)를 사용하기 때문에 루비를 중심으로 소개하면 다음과 같은 솔루션들이 있습니다.

Sinatra

시나트라(Sinatra)는 간단한 웹 애플리케이션을 신속하게 만들 수 있게 해주는 루비기반 웹개발 툴킷입니다. 시나트라 자체는 특별히 API 서버를 염두에 두고 만들어지지 않았지만 웹요청의 결과물을 JSON으로 출력하기만 하면 바로 간단한 JSON 서버가 됩니다. 비슷한 개념의 도구로 파이썬 기반의 Flask나 PHP 기반의 Slim 같은 도구들이 있습니다.

Grape

다른 많은 프로그래밍 언어들과 마찬가지로 루비에서도 API 서버 구현을 도와주는 많은 오픈소스 라이브러리들이 있으며 Grape도 그 중 하나 입니다. Grape는 앞서 소개한 Sinatra를 비롯한 다양한 웹 개발 환경에서 사용 가능 합니다. 그 밖에 Rabl, Praxis, FastAPI 등도 검토해볼만 합니다.

Rails

루비온레일스(Ruby on Rails)는 별도의 설명이 필요없는 인기있는 웹 개발 프레임워크입니다. 레일스는 오래 전부터 REST를 지원해 왔고 컨텐츠 협상(content negotiation)을 통해 다양한 포맷으로 데이터를 내보낼 수 있습니다. 레일스를 웹앱이 아닌 REST API 서버로만 사용하도록 해주는 Rails API 프로젝트도 있으며 이 프로젝트는 Rails 5에서 Rails Core 속에 통합될 예정 입니다.

설치형 솔루션

구축형 솔루션이 API 설계부터 구현까지 직접 처리해야 하는 솔루션이라면 설치형 솔루션은 이미 갖춰진 API 서버를 설치하여 사용하기만 하면 되는 솔루션입니다. 물론 입맛에 맞게 사용하려면 약간의 ‘양념(customizing)’이 필요할 수 있지만, 바로 설치해서 신속하게 사용할 수 있는 점은 큰 장점입니다.

LoopBack

엄밀히 말해 LoopBack은 Node.JS 기반의 웹 프레임워크입니다. Node 기반에서 작동하는 다양한 웹 프레임워크들이 있지만, 특히 LoopBack은 다른 웹 프레임워크들과는 달리 REST API 서버 개발에 그 용도가 특화되어 있고 또 CLI를 통해 간단한 명령만으로 바로 API를 구성할 수 있다는 점에서 설치형 솔루션이라고 해도 무방할 듯 합니다.

WordPress

워드프레스가 REST API 서버라구요? 맞습니다. 워드프레스는 주로 웹사이트 제작에 사용하는 CMS 도구입니다. 그렇지만 최근 워드프레스의 인기와 함께 활용도가 높아지면서 워드프레스를 웹사이트 제작 이외의 용도로 사용하려는 움직임이 커지고 있습니다. (어쩌면 웹개발의 자연스런 흐름을 반영한 것이겠지만) 최근 출시된 WP REST API 는 왠만한 REST API 서버로 쓰기에도 손색 없는 수준입니다.

클라우드 솔루션

구축도 설치도 필요 없고 그저 가입만 하고 인증절차만 거치면 바로 사용할 수 있는 솔루션이 클라우드 솔루션입니다. 소위 “Paas” 또는 “Baas“라고 불리우는 이들 솔루션들은 REST API 서버 개발의 부담은 줄이면서 프론트엔드 개발에만 집중할 수 있다는 점에서 특히 모바일앱 개발자들에게 인기가 많은 솔루션입니다.

대표적인 서비스로 페이스북이 인수하여 운영하는 Parse와 구글이 인수한 Firebase가 있습니다. 국내에서도 KT에서 운영하던 ‘바스아이오’(bass.io) 라는 서비스가 있었고 저희 블로그에서도 한번 소개한 적이 있지만 현재는 서비스가 종료된 상태입니다.

최근의 웹개발 흐름이 모바일앱과 웹앱 등 주로 프론트엔드 부분에 많은 초점이 맞춰진 것이 사실이고 또 사용자 UI의 중요성이 커짐에 따라 갈수록 프론트엔드 개발의 중요성은 더 커지겠지만 이런 프론트엔드는 탄탄한 백엔드의 뒷받침 없이는 지속가능한 서비스로 이어질 수 없다는 점에서 ‘묵묵히(?)’ 뒤에서 떠받치는 REST API 서버는 없어서는 안 될 웹서비스의 진정한 핵심입니다. 또한 이미 완성되어 더 이상 풀어야할 문제가 남지 않은 영역이 아니라 계속해서 새로운 시도와 혁신들이 이뤄지고 있는 ‘진화하는’ 영역이기도 합니다. 최근 페이스북이 공개한 GraphQL이나 Netflix의 데이터 추출 도구인 Falcor, API를 위한 토큰인증 표준인 JWT(JSON Web Tokens) 등은 모두 이런 진화의 반증일테죠.

다음에 기회가 되면 이들 솔루션들도 하나하나 소개해 나가기로 하겠습니다.

P.S. 마침 서점에 REST API를 다룬 좋은 책이 한권 나왔네요. 비록 번역서이긴 하지만, 프론트엔드 개발 일변의 책들이 쏟아지는 속에서 반가운 소식이 아닐 수 없습니다(저희는 이 책의 역자 또는 이 책의 출판사와는 아무런 이해관계도 없답니다. 그저 반가운 마음에^^).

RESTful Web API (웹 API를 위한 모범 전략 가이드)
레오나르드 리처드슨, 마이크 애먼슨 외 1명 저 | 박세현 외 1명 역 | 인사이트 | 2015.09.09

Backbone 앱에 React 컴포넌트 추가하기

2015-07-31T00:00:00+00:00

알다시피 React는 페이스북에서 공개한 오픈소스 자바스크립트 UI 라이브러리다. Angular 또는 Ember와 같은 다른 자바스크립트 라이브러리들이 주로 UI와 데이터 처리, 그리고 URL 라우팅까지 아우르는 소위 “풀스택(full stack)”의 프레임워크 구성을 가져가는 반면, React는 사용자 인터페이스 부분만 다룬다는 점에서 이들 프레임워크와 차이가 있다. 게다가 컴포넌트(web components) 개념을 갖추고 가상 DOM(Virtual DOM)을 이용한 렌더링 방식을 사용하는 탓에 사용하기 쉽고 UI 처리 속도도 빨라, 아직 v0.13.x 라는 낮은 버전임에도 이미 많은 저변을 확보하고 있다.

이에 비하면 Backbone은 제법 오래된 축에 속한다. 웹 개발에서 프론트엔드와 자바스크립트의 비중이 커지고 SPA(Single Page App) 개념이 일반화될 무렵, 그때까지 주로 jQuery로만 작업하던 “기존의 방식”에서 한걸음 더 나아가 프론트엔트 측에도 서버 측의 웹개발과 유사한 MVC(Model-View-Controller) 기반의 패턴을 적용한 시도 중 가장 성공한 케이스 중 하나다. 그러다보니 이미 많은 적용 사례를 갖고 있고 또 Angular나 Ember 같은 다른 프레임워크들에 비해 상대적으로 관례가 적고 “가벼워서” 요즘도 계속 사용되고 있는 자바스크립트 라이브러리의 “고전(classic)”이다.

그렇지만 Backbone 라이브러리가 그 자체로는 너무 “기본적인” 내용들만 담고 있다 보니 종종 까다로운 문제를 처리해야 할 때는 여러 가지 직접 해결해야 할 문제들이 생기곤 할 때가 많다. 특히 뷰 처리와 관련해서는, 뷰 템플릿(template)을 처리하거나 중첩된 뷰(nested view)를 다룰 때 또는 뷰와 연결된 여러 이벤트들을 관리하거나 뷰의 상태를 다룰 때 등에서 종종 복잡한 문제와 맞닥뜨릴 때가 있다. 이럴 경우 Backbone 앱의 기본 구조는 그대로 남겨두고 뷰(View) 부분만 React로 교체해 보는 것도 좋은 방법이다. Backbone의 뷰는 렌더링(rendering)에 있어 특별한 관례를 갖고 있지 않기 때문에 React와 연동하여 가상돔(Virtual DOM)을 렌더링하는 것도 얼마든지 가능하기 때문이다.

알다시피 Backbone 앱은 모델(Model)과 뷰(View)를 중심으로 구성된다. Backbone 모델에서 발생한 변경 사항은 Backbone의 자체 이벤트 시스템을 통해 뷰에서 받아서 처리(render)하고, 반대로 사용자 입력은 뷰를 통해 모델로 전달하는 구조다(아래 그림 참조). 다만 Angular나 Ember에서와 같은 소위 ‘2-way binding’은 지원하지 않는다.

(그림 출처: http://backbonejs.org/ )

Backbone 앱에 React를 적용하려면 기존에 Backbone 뷰로 작성한 부분을 React 컴포넌트로 교체하면 된다. 아래 코드에서는 기존의 Backbone 뷰 골격은 그대로 두고 뷰의 render 메서드 부분만 React#render 호출로 변경하였다.

// home_view.js

var HomeView = Backbone.View.extend({
  el: '#home',

  initialize: function() {
    this.render();
  },
  
  render: function() {
    var entryList = React.createElement(EntryList, {collection: this.collection});
    React.render(entryList, this.el);
    return this;
  }
});

실제 UI 처리는 모두 React 컴포넌트에서 이루어진다. 아래 코드는 위의 HomeView#render 메서드 속에서 사용한 EntryList의 예제이며, React의 프로퍼티(property)로 Backbone의 컬렉션(Collection) 데이터를 받아 React 컴포넌트의 렌더링을 처리하는 간단한 JSX 파일이다.

// entry_list.jsx

var EntryList = React.createClass({

  render: function() {
    return (
      <div className="entry-list">
        <h1>Listing Entries</h1>
        <EntryForm collection={this.props.collection} />
        <hr />
        <ul className="entries">
        {this.props.collection.sort().map(function(entry) {
          return <li key={entry.cid}>{entry.get('title')}</li>;
        })}
        </ul>
      </div>
    );
  }
});

이제 남은 문제는, Backbone의 모델(또는 컬렉션)에서 발생한 변경을 어떻게 하면 React 컴포넌트에서 받아 (자동으로) 렌더링되게 하냐 하는 것이다. 얼핏 모델이나 컬렉션이 변경되는 부분에서 React#render 메서드를 명시적으로 호출해 주면 간단할 듯 보인다. 다행히 React에서는 이를 위해 React#forceUpdate라는 메서드를 제공한다. 따라서 React 컴포넌트의 라이프사이클(Life-cycle) 콜백 함수 속에서 다음과 같이 Backbone의 모델/컬렉션의 변경 이벤트를 바인딩(binding)하여 React#forceUpdate를 호출해주면 모델/컬렉션의 변경 사항이 자동으로 React UI에 반영된다.

아래에서는 React의 componentDidMount와 componentWillUnmount 콜백에서 각각 컬렉션의 이벤트를 바인딩/언바인딩 처리하고 있다.

// entry_list.jsx

var EntryList = React.createClass({

  componentDidMount: function() {
    this.props.collection.on('add remove change', this.forceUpdate.bind(this, null));
  },

  componentWillUnmount: function () {
    this.props.collection.off(null, null, this);
  },
  
  render: function() {
    return (
      // 생략
    );
  }
});

물론 React는 선언적(declarative) 방식으로 렌더링을 처리하기 때문에 지금처럼 React#forceUpdate를 호출하는 방식보다는 모델이나 컬렉션의 변경이 이루어지는 부분에서 “변동이 생겼음”을 React에게 넌지시 알려 주어 React가 “알아서” 렌더링하게 하는 게 더 좋은 방법이긴 하다. 이 점은 React API 문서에도 나와 있다:

Normally you should try to avoid all uses of forceUpdate() and only read from this.props and this.state in render(). This makes your component “pure” and your application much simpler and more efficient.

그렇지만 지금과 같이 Backbone 앱에 React를 적용할 때에는 Backbone의 구조도 고려할 필요가 있기 때문에 앞에서처럼 직접 React#forceUpdate를 호출하는 방식이 유용할 수 있으며 또한 가장 간단한 방법이기도 하다.

물론 여기서는 설명의 편의를 위해 React 컴포넌트 속에 직접 콜백을 두는 방식을 사용했지만, 실제로는 React의 믹스인(mixin)으로 처리하는 것이 더 편리할 것이다. 물론 이미 이 기능을 (믹스인으로) 구현해 놓은 많은 솔루션(플러그인)들이 나와 있기 때문에 굳이 “바퀴를 직접 만들” 필요는 없을 듯 하다. 이들 중 대표적인 것 몇몇만 소개하면 다음과 같다:

ReactBackbone 앞서 소개한 React#forceUpdate 방식을 사용한 Mixin
Backbone React Component Wrapper를 사용하여 백본 모델/컬렉션의 상태를 React state와 맵핑
ReactBone React 컴포넌트와 연동할 수 있게 Bakbone 모델/컬렉션을 확장

이 글에서 사용한 예제의 전체 소스코드는 Github에서 내려 받을 수 있습니다.

워드프레스와 Cron

2015-03-24T00:00:00+00:00

cron은 시스템의 백그라운드에서 정해진 시간 또는 시간 간격으로 어떤 작업을 처리할 때 사용하는 UNIX 명령이다. 주기적으로 반복해서 수행해야 하는 작업들을 미리 스케줄링(scheduling)해 두면 지정된 시간에 해당 작업이 자동으로 실행되기 때문에, 백업이나 시스템 업데이트 같은 반복 작업이나 이메일 발송 등 시간이 제법 오래 걸리는 배치(batch) 작업 등에 폭넓게 사용되는 요긴한 명령이다.

워드프레스(WordPress)를 사용하거나 관리하는 경우에도 이런 cron과 유사한 작업들이 필요한 경우가 알게 모르게 생긴다. 예를 들어 포스팅 시간을 예약해 둔 글을 배포(publish)하거나 새 글이 올라오면 뉴스레터를 발송하거나 테마나 플러그인의 새로운 업데이트가 있는지 검사하는 것과 같은. 이런 경우에 사용할 목적으로 워드프레스도 UNIX의 cron과 유사한 개념의 도구를 제공하고 있는데, UNIX의 cron과 비교하는 의미로 흔히 ‘WP-Cron‘이라 불린다.

WP-Cron의 동작

통상적인 cron이 스케줄에 맞춰 지정된 시간에 정확하게 수행되는 것과 달리 WP-Cron은 PHP기반의 웹기반 시스템인 워드프레스의 특성 상, 웹요청이 들어 올 경우에만 실행된다. 즉 사용자가 워드프레스 사이트를 방문할 경우에 매번 cron이 실행되는데, 이 때 워드프레스는 자체 cron 스케줄 시스템에서 현재 수행해야 할 cron 작업이 있는지 검사하고 있으면 해당 작업을 백그라운드로 실행시키게 된다. 따라서 만약 (관리자를 포함) 아무런 방문도 없는 사이트라면 WP-Cron은 ‘결코’ 실행되지 않는다 (이렇게 실행되지 않는 cron 작업들은 계속 모였다가 언젠가 한 사람의 방문자가 방문했을 때 그동안 미뤄 뒀던 cron 작업들이 모조리 한번에 실행되어 접속속도가 느려 보이는 결과를 초래하기도 한다).

워드프레스 내부적으로 cron은 다음 2개의 파일이 담당한다:

/wp-includes/cron.php : 모든 cron 처리 관련 API 함수들이 들어 있음
/wp-cron.php : cron 호출에 사용되는 스크립트 파일

WP-Cron의 내부 작동 메커니즘은 위 소스코드를 참조하기로 하고, 여기서는 이들 WP-Cron 관련 API의 간단한 사용법만 소개하기로 한다.

WP-Cron 사용하기

WP-Cron은 크게 cron 이벤트(event)라고 부르는 cron 작업 부분과 이들 작업을 실행하는 주기인 스케줄(schedule) 부분으로 나눠 볼 수 있는데, cron 이벤트 처리와 관련된 API 함수에는 다음과 같은 것들이 있다.

wp_schedule_event() : cron 이벤트 추가
wp_schedule_single_event() : 1회 실행 cron 이벤트 추가
wp_next_scheduled() : cron 이벤트의 다음 번 수행시간
wp_unschedule_event() : cron 이벤트 제거

예를 들어, 1시간 간격으로 수행해야 할 어떤 작업을 cron 이벤트로 추가하려면 다음과 같이 그 작업을 액션 훅(hook)으로 처리한 다음 wp_schedule_event()로 추가하면 된다.

// 새 cron 이벤트 생성
add_action( 'prefix_hourly_event_hook', 'prefix_do_this_hourly' );
function prefix_do_this_hourly() {
	// 1시간 간격으로 수행될 어떤 작업
}
// 앞의 cron 이벤트를 스케줄에 추가
wp_schedule_event( time(), 'hourly', 'prefix_hourly_event_hook' );

이 때 wp_schedule_event()의 두 번째 인자로 전달된 ‘hourly’는 cron의 실행간격을 의미하는데, 워드프레스에는 기본으로 hourly, twicedaily, 및 daily의 3가지 간격(intervals)이 등록되어 있으며, cron_schedules 필터 훅을 통해 얼마든지 확장 가능하다. 다음은 cron 스케줄에 새로 weekly라는 스케줄을 추가하는 코드다.

function my_add_weekly( $schedules ) {
	// 새로 'weekly' 스케줄을 추가
	$schedules['weekly'] = array(
		'interval' => 604800,
		'display' => __('Once Weekly')
	);
	return $schedules;
}
add_filter( 'cron_schedules', 'my_add_weekly' ); 

참고로, 워드프레스 사이트 내에서 실제로 어떤 cron 작업들이 등록되어 어떻게 실행되고 있는지를 확인해 보려면 WP Crontrol 같은 플러그인을 사용하면 편리하다. 이 플러그인은 실행 중인 cron 작업을 확인할 뿐 아니라 변경/삭제할 수 있는 기능도 제공한다.

WP-Cron 죽이기

앞서도 말했지만 WP-Cron은 이름은 같은 ‘cron’이긴 하지만 ‘토종 cron(UNIX cron)’과는 다른 성격의 cron이다. 따라서 다음과 같은 경우에는 제대로 작동하지 않을 수 있다.

방문자가 거의 없는 사이트(앞서 설명)
캐시(cache) 시스템이 적용된 사이트
인증, IP 필터링, 쿠키 필터링 등으로 wp-cron.php 호출 자체가 차단된 사이트

또한 방문자가 아주 많아 트래픽이 높은 사이트인 경우에도 마찬가지로 WP-Cron은 문제가 될 수 있다. 방문자가 사이트를 방문할 때마다 매번 실행되는 cron의 성격 상, 동시에 여러 사용자가 접속하면 여러 개의 프로세스가 동시에 백그라운드에서 실행될 수 있기 때문이며, 이는 사이트의 리소스를 차지하고 성능에도 영향을 미칠 수 있다. 물론 워드프레스가 기본적으로 cron 처리에 락(lock) 시스템을 적용해 두고 있기 때문에 지나친 우려는 하지 않아도 되겠지만.

그렇다면 아예 WP-Cron을 죽이는 건 어떨까? 좋은 방법은 아니다. 왜냐면 cron은 워드프레스 속 여러 군데에서 사용되고 있기 때문에 이 기능을 완전히 끄게 되면 cron이 필요한 기능들은 동작하지 않게 되기 때문이다.

이런 경우에 우리는 WP-Cron에서 벗어나 진짜 cron으로 갈아탈 수 있다. 우선 WP-Cron은 끄자. /wp-config.php 파일에 다음 상수를 추가하면 된다.

// 내부 WP-Cron 비활성화
define('DISABLE_WP_CRON', true);

그런 다음, 진짜 cron을 깨우자. 만약 5분 단위로 호출하려면, crontab에 다음과 같이 wp-cron.php를 호출하는 스크립트를 추가하면 된다. (crontab의 사용법은 생략한다)

*/5 * * * * wget -q -O - http://www.your-site.com/wp-cron.php

이 때 wget 명령에서 사용한 -O 옵션은 출력 결과를 파일이 아닌 표준출력(STDOUT)으로 보내는 옵션이며, wget 대신 예를 들면 curl 같은, HTTP 웹요청을 수행하는 명령이면 어떤 것을 사용하든 무방하다.

참고자료

반응형웹과 Responsive Image 처리

2014-11-03T00:00:00+00:00

반응형웹(responsive web)이 대세가 된지 오래다. 국내외를 막론하고 새로 만들어지는 웹사이트 중 반응형웹을 지원하지 않는 곳은 찾아보기 힘들 정도다. 알다사피 반응형웹 혹은 반응형웹 디자인(responsive web design, 줄여서 RWD)이란, 마치 예전에 Ajax가 그랬듯, 기존에 나와 있던 몇몇 개념들이 결합되어 만들어진 개념으로, 하나의 웹페이지만으로 모바일과 데스크톱을 아우르는 다양한 디바이스에 효과적으로 대응하기 위해 만들어진 프론트엔트 웹개발 방법이다.

알다시피 이런 “반응형”의 웹사이트를 만들기 위해서는 주로 다음 3가지 기술(기법)을 사용하게 된다. 물론 이 외에도 여러 가지 기법들과 핵(hack)이 적용되기는 하지만 기본적으로는 아래 3가지가 반응형웹의 토대를 이룬다.

유동 레이아웃(flexible layout)
CSS3 미디어쿼리(media query)
반응형 이미지(responsive image)

이 셋 중 유동 레이아웃이나 미디어 쿼리 부분은 CSS 명세에 맞게 사용하면 크게 문제될 게 없지만, 유독 이미지를 처리하는 부분은 조금 까다롭다. 왜 까다로운지 그리고 어떤 해결책들이 있는지 지금부터 알아보기로 하자.

반응형 이미지 처리

2010년의 어느 날 웹 디자이너인 Ethan Marcotte가 처음 반응형웹이란 개념을 소개했을 때만 해도 반응형웹에서 이미지를 어떻게 다루어야 할지에 대해서는 크게 문제가 되지 않는 듯 했다. 통상적으로 반응형웹은 유동(fluid) 레이아웃에 기반하고 유동 레이아웃에서 어떤 요소를 가변적으로 구성하려면 비율값 즉 퍼센트(%) 값을 사용하는게 일반적이므로, 흔히 (그리고 지금까지도) 반응형웹에서 이미지 처리의 기본패턴은 CSS 스타일시트에 다음과 같이 비율폭을 추가하는 것이다.

img { max-width: 100%; }

사실 반응형 이미지를 위해 처리해줘야 할 부분은 이게 전부이기도 하다. 이렇게만 해도 하나의 이미지가 웹사이트의 가로폭에 맞춰 크기가 가변적으로 조정되고 당연히 페이지의 최대폭을 넘지 않기 때문에 모든 디바이스에서 이미지가 “제대로(넘치지 않고)” 표시되는 것을 보장할 수 있다. 여기에 페이지 레이아웃에 맞춰 미디어별로 이미지 크기를 다르게 설정하는 미디어쿼리(media query)를 가미하면 좀 더 나은 반응형웹을 구현할 수 있다.

몇 가지 문제들

그런데 위의 방식만으로 반응형 이미지를 처리할 경우 다음과 같이 몇 가지 문제가 남는다.

이미지 크기(size)와 관련한 성능/속도 및 대역폭 문제
고밀집도(High-DPI) 디바이스 대응
소위 “아트 디렉션(art direction)” 처리
다양한 이미지 포맷 대응

하나씩 살펴 보기로 하자.

우선 이미지 크기(size)와 관련한 문제다. 반응형웹에서는 디바이스에 따라 레이아웃이 달라지고 이에 맞춰 이미지 크기 또한 가변적으로 변하기 때문에 통상 가장 큰 사이즈의 이미지를 하나 만들어 모든 디바이스에 대응하는 경우가 많다. 이럴 경우 굳이 그럴 필요가 없는 작은 사이즈의 화면을 가진 디바이스에도 똑같이 큰 사이즈의 이미지를 불러와야 하기 때문에 불필요한 대역폭의 낭비가 생기고 또 결과적으로 페이지 로딩 속도도 디바이스에 맞는 적은 용량의 이미지를 썼을 때보다 떨어지게 된다. 데스크톱에서 잘 보이게 만든 큰 용량의 이미지를 굳이 작은 화면의 아이폰에도 똑같이 불러올 필요는 없다.

실제로 2014년 10월 현재 HTTP Archive에 집계된 통계 상으로 웹 페이지 용량에서 이미지가 차지하는 부분은 절반을 훨씬 넘는 것으로 나타났다. 아무런 다른 조치 없이 단지 이미지 용량만 줄이더라도 웹사이트의 속도가 크게 개선될 수 있다는 말이다.

( * 출처: HTTP Archive )

두 번째 문제는 이른바 “레티나(Retina)” 디스플레이라고도 불리는 고밀집도 디바이스에 대한 대응 이다. 요즘 새로 출시되는 디바이스들 중에는 밀집도(density)가 높은 디스플레이를 장착한 디바이스가 많고 그러다보니 이미지 처리도 이들 고밀집도(high-density) 디바이스에 대응해야 하는 문제가 생기게 된다. 아래 그림처럼 통상적인 밀집도의 디바이스에서 정상적으로 보이던 이미지가 레티나 기반의 디바이스에서는 흐릿하게 보이게 된다. 레티나를 필두로 한 고밀집도 디바이스에 대한 문제와 이에 대한 대응에 관한 더 자세한 내용은 참고자료를 참조하면 좋겠다.

(* 사진출처: http://greatfridays.com/blog/images-in-responsive-web-development/ )

소위 “아트 디렉션(art direction)” 처리도 문제가 될 수 있다. 이미지를 일률적으로 배율에 맞춰 확대/축소할 경우 데스크톱에서는 분명한 의미를 전달하던 이미지가 화면 크기가 적은 모바일 디바이스에서는 도무지 무슨 이미지인지 알아보지 못해 의미 전달을 놓치게 되는 경우가 많다. 이 경우 해결책은 디바이스 특성에 맞춰 크기 뿐 아니라 이미지의 내용도 다른 이미지를 제공하는 것이다. 예를 들어 아래 사진 이미지의 경우 배율에 맞춰 크기를 줄이기보다는(우측 상단) 이미지가 표시되는 상황(context)에 맞게 잘라진 사진을 사용하는 것이(우측 하단) 더 효과적으로 의미를 전달할 수 있다.

( * 사진출처: http://24ways.org/2012/responsive-images-what-we-thought-we-needed/ )

마지막으로 고려할 문제는 다양한 이미지 형식(format)에 대한 대응 문제다. 전통적으로 웹 상에서 사용하는 이미지 파일의 형식은 주로 GIF, JPEG, PNG 인 경우가 대부분이었지만 최근에는 좀 더 효율적이고 압축률을 높인 다양한 유형의 이미지 파일 형식들이 나오고 있고 이들 새로운 형식을 지원하는 브라우저들도 속속 등장하고 있기 때문에, 새로운 이미지 파일 형식에 대한 대응도 문제가 된다. 이미 대부분의 브라우저에서 지원하고 있는 SVG나 구글에서 제안한 WebP, 마이크로소프트의 JPEG-XR, 그리고 FlashPix 같은 형식이 대표적이다.

해결책들

웹커뮤니티, 특히 그 중에서도 프론트엔드 개발자들은 이 문제에 대해 이미 “반응형웹”이란 말이 세상에 나오기 전부터 많은 고민을 해왔고 그만큼 많은 해법과 트릭들을 만들어 왔다. 그렇지만 이 모든 방법들을 여기서 전부 소개하기는 쉽지도 않을 뿐더러 이미 어느 정도 표준적인 방법이 등장한 이후인지라 여기서는 현재의 모습을 중심으로 몇 가지 대안들만 소개하려 한다.

srcset과 sizes 속성

처음 소개할 방법은 srcset 과 sizes 속성이다. 이 방식은 HTML의 <img> 태그에 새로운 속성을 추가하여 반응형 이미지를 처리하는 방식으로 Apple이 처음 제안하여 현재의 웹표준에 이른 방식이며, 예제는 다음과 같다.

<img src="small.jpg"
     srcset="large.jpg 1024w, medium.jpg 640w, small.jpg 320w"
     sizes="(min-width: 36em) 33.3vw, 100vw"
     alt="A rad wolf">

(* 예제 출처: RICG)

<img> 태그는 이미 기존부터 사용해오던 그 <img> 태그지만 여기에 새로 srcset과 sizes 속성이 덧붙었다. 여기 예제의 srcset 속성에서는 각각 가로폭 1024px, 640px, 320px인 3개의 이미지를 쉼표로 분리된 문자열 형식으로 적었다. 이럴 경우 브라우저(srcset을 지원하는 브라우저)는 이 값을 읽어 현재의 화면 상태에 맞는 적절한 이미지를 불러오게 된다. sizes 속성도 추가할 수 있는데, 이 속성은 미디어쿼리의 중단점(breakpoint) 별로 필요한 이미지의 정보를 추가로 제공함으로써 역시 브라우저로 하여금 현재의 상태에 가장 잘 맞는 이미지를 불러오는데 도움을 주게 된다. 위 예제에서는 미디어쿼리의 중단점으로 가로폭이 36em 이상인 경우에는 33.3vw (‘viewport width’를 의미)의 이미지가 필요함을 브라우저에 알리고 있으며 뒤의 100vw는 디폴트값이다. 물론 srcset과 sizes를 지원하지 않는 브라우저에서는 기존의 src 속성이 폴백(fallback)으로 사용된다.

srcset과 sizes 속성을 사용하면 앞에서 제기한 네 가지 문제들 중 적어도 처음 두 가지 문제는 손쉽게 해결된다. 브라우저가 화면 크기에 맞춰 적절한 용량의 이미지를 불러오고 또한 고밀집도 디스플레이 화면에 대한 대응도 브라우저가 판단하여 대응하기 때문이다(여기서 소개하진 않았지만 srcset에는 w 대신 x 속성으로 밀집도를 지정하는 옵션도 있는데, 아래의 예제에 나온다).

`<picture>` 엘리먼트

srcset/sizes 속성만으로 해결할 수 없는 문제들, 예컨대 아트 디렉션 처리나 여러 이미지 포맷 지원 등은 <picture> 엘리먼트로 해결할 수 있다. <picture> 엘리먼트는 Mat Marquis에 의해 처음 제안되어 현재 W3C의 Responsive Images Community Group에 의해 관리되는 웹표준에 이른 반응형 이미지 처리 방법이다. (<picture> 엘리먼트가 오늘에 이르기까지의 우여곡절과 웹커뮤니티의 노력은 참고자료 참조)

<picture>
  <source media="(min-width: 40em)"
    srcset="big.jpg 1x, big-hd.jpg 2x">
  <source 
    srcset="small.jpg 1x, small-hd.jpg 2x">
  <img src="fallback.jpg" alt="">
</picture>

(* 예제 출처: RICG)

<picture> 엘리먼트는 하위 요소로 <source> 엘리먼트를 두어 각각의 이미지 소스를 처리한다. 위 예제에서는 미디어쿼리로 min-width값이 40em 이상인 경우는 big.jpg 파일을, 그 이하인 경우는 small.jpg 파일을 각각 로드하게끔 설정되어 있다. 이 때 각각의 <source> 엘리먼트 내에는 srcset 속성을 추가하여 밀집도(여기서는 1x와 2x를 사용했는데, 2x는 196 DPI 이상을 일컫는다)에 따라 각기 다른 이미지 파일을 로드하게끔 설정하는데, 이 부분은 앞서의 <img> 태그에 붙은 srcset 속성과 동일하다.

이 <picture> 엘리먼트를 이용하면 앞서 <img> 태그에 붙여 사용했던 srcset/sizes 방식보다 조금 더 다양한 처리가 가능해 진다. 예를 들어, 아트디렉션(art direction) 은 다음과 같이 처리할 수 있다. 여기서는 미디어쿼리로 width값이 800px 이상인 경우(lighthouse-landscape)와 그 이하인 경우(lighthouse) 각각 다른 이미지를 사용하며 그 결과 좁은 폭의 화면에서는 넓은 폭과는 다른 모양의 이미지가 보여짐을 알 수 있다.

<picture>
  <source media="(min-width: 800px)"
          sizes="80vw"
          srcset="lighthouse-landscape-640.jpg 640w,
                  lighthouse-landscape-1280.jpg 1280w,
                  lighthouse-landscape-2560.jpg 2560w">
  <img src="lighthouse-160.jpg" alt="lighthouse"
       sizes="80vw"
       srcset="lighthouse-160.jpg 160w,
               lighthouse-320.jpg 320w,
               lighthouse-640.jpg 640w,
               lighthouse-1280.jpg 1280w">
</picture>

(* 예제 출처: HTML5Rocks)

<picture> 엘리먼트는 다양한 이미지 형식을 처리하는 데도 사용될 수 있다. 아래 예제를 보면 webp를 지원하는 브라우저인 경우 jpg 파일이 아닌 webp 파일을 표시하도록 하고 있다.

<picture>
  <source type="image/webp" srcset="images/butterfly.webp">
  <img src="images/butterfly.jpg" alt="a butterfly">
</picture>

<picture> 엘리먼트 관련 더 자세한 내용은 W3C Draft 문서 참조.

브라우저 지원과 폴리필(polyfill)

웹에서는 아무리 좋은 기능이라도 브라우저에서 그 기술을 지원하지 않으면 무용지물이다. 다행히 크롬(Chrome), 사파리(Safari) 등 주요 브라우저들이 <picture>엘리먼트와 srcset/sizes 속성을 지원하거나 또는 지원을 준비 중이다(아래 표 참조).

(* 출처: RICG)

또한 IE 등 아직 이 기능을 지원하지 않는 브라우저를 위한 폴리필(polyfill) 자바스크립트 라이브러리도 나와 있기 때문에 지금 당장 프로젝트에 적용하더라도 크게 무리는 없을 듯 하다.

그 밖의 방법들

지금까지는 주로 클라이언트(브라우저)측 기술, 즉 웹표준으로 자리잡은 srcset/sizes 속성과 <picture> 엘리먼트를 중심으로 소개했지만 이게 전부는 아니다. 다른 방법들도 존재하고 또 여전히 새로운 방식들이 시도되고 있다. 그 중 몇 가지만 소개하면 다음과 같다.

Adaptive Image 이 방식은 방문자의 웹요청으로부터 디바이스 정보를 감지하여 그에 알맞는 적절한 이미지를 서버측에서 제공하는 서버측 반응형 이미지 처리 방식이다. SLIR (Smart Lencioni Image Resizer) 도 이와 유사한 방식이다.
HTTP Client-Hints HTTP 요청 헤더에 브라우저 정보를 실어보내 서버측에서 적절한 이미지를 내보낼 수 있게 하는 일종의 콘텐츠 협상(content negotiation) 방식으로 현재 draft RFC 상태다.
HiSRC 네트워크 속도를 감지하여 서로 다른 이미지를 취하는 조금 독특한 adaptive image 솔루션이다.

그 밖에 jQuery Picture, Doubletake, Foundation Interchange, Retina.js, Response 등도 참고할만 하다.

최근 애플(Apple)이 레티나 디스플레이가 장착된 새로운 데스크톱용 PC를 발표하면서 앞으로 모바일 디바이스 뿐 아니라 데스크톱 PC에도 레티나와 같은 고화질 디스플레이를 장착한 제품들이 늘어날 것으로 보인다. 또한 모바일 디바이스도 더욱 다양한 크기와 화질을 가진 디바이스들이 등장함에 따라 웹에서 이미지를 처리하는 방법은 더욱 다양해질 것 같다. 이 말은 곧 이제 더 이상 예전의 그 익숙한 <img> 태그 하나만으로 이미지를 처리하던 시대가 끝나가고 있다는 말이기도 하다.

이미지 파일 하나 하나까지도 다양한 디바이스와 다양한 화면 상황을 고려하여 처리해야 하는 일은 웹 개발자들에겐 쉽지 않은 도전이다. 물론 포토샵(Photoshop)이나 스케치(Sketch) 같은 이미지 편집 도구들은 이미 이런 점들을 고려한 기능들을 갖추고 있고 또 시중에는 다양한 크기의 이미지를 처리할 수 있는 유틸리티 도구들도 여럿 나와 있긴 하지만, 무엇보다도 변하는 기술에 대한 이해를 바탕으로 적절히 도구를 사용하는 것이 도전에 대한 대응책이 될 것 같다.

끝으로 CMS에 대해 한마디. 요즘 웹사이트는 CMS로 만드는 게 보통이다. 그러니 CMS가 이들 반응형웹과 반응형 이미지에 대한 처리를 많은 부분 자동화시켜 주어야 한다. 예를 들어 워드프레스를 사용한다면, 워드프레스의 다양한 썸네일(thumbnail) 생성 기능을 이용하면 쉽게 반응형 이미지 처리에 대응할 수 있을 것이다. Hammy나 Simple Responsive Images 같은 플러그인들도 참고할만 하다.

참고자료

Responsive Images: Use Cases and Documented Code Snippets to Get You Started by Andreas Bovens
Use Cases and Requirements for Standardizing Responsive Images by RICG
Srcset and sizes by Eric
A Complete Guide to the <Picture> Element by Scott Gilbertson
Built-in Browser Support for Responsive Images by Pearl Chen (우리말 번역 by 도창욱)
On Responsive Images by Chris Coyier
The State Of Responsive Web Design by Stephanie Walter (우리말 번역: 반응형 웹 디자인의 현재 by Webactually)
레티나 웹(Retina Web)에 대응하는 우리들의 자세 : “래스터 이미지 편” by UXD
How a new HTML element will make the Web faster by Scott Gilbertson

워드프레스에 카카오 계정 로그인 추가하기

2014-07-15T00:00:00+00:00

UPDATE(2016-01-19) thisgun님이 별도의 코딩 작업 없이 카카오와 네이버 로그인 기능을 추가할 수 있는 Wordpress Social Login 확장 플러그인을 개발하셨다고 댓글로 알려 주셨습니다. 감사드리며, 필요하신 분들은 참고 바랍니다: 워드프레스에서 네이버 와 카카오 로그인 사용하기

UPDATE(2015-06-12) Inho Ahn님이 Wordpress Social Login 플러그인에서 사용하고 있는 라이브러리인 hybridauth의 Kakao Provider와 Naver Provider를 구현한 소스를 댓글로 알려 주셔서 공유합니다. 카카오와 네이버 로그인 연동이 필요하신 분들은 참고 바랍니다: hybridauth providers for Kakao and Naver

간혹 워드프레스에 카카오(톡)이나 네이버 계정을 이용한 로그인을 추가하려면 어떻게 해야하는지 문의 주시는 분들이 계셔서 오늘은 카카오 계정 로그인 연동하는 법을 간단하게 소개합니다.

소셜 로그인 플러그인

우선 워드프레스에 소셜 로그인(social login) 기능을 추가해주는 플러그인을 하나 설치합니다. 여기서는 WordPress Social Login 이라는 플러그인을 사용하기로 하며, 플러그인은 이미 설치되어 있다고 가정합니다.

이제 이 플러그인에 카카오톡 로그인 부분을 추가해 보기로 하겠습니다. 우선 아래의 다운로드 URL로 접속하여 Kakao.php 라는 파일을 찾아 다운로드하여 WordPress Social Login 플러그인(이하 ‘WSL’)이 설치된 디렉터리 아래의 hybridauth/Hybrid/Providers 디렉터리에 복사해 넣습니다.

Kakoa.php 다운로드 바로가기

그 다음으로 워드프레스 테마의 functions.php 파일에 다음 코드를 추가합니다.

add_action( 'init', 'my_add_kakao_provider_to_wsl' );

function my_add_kakao_provider_to_wsl() {

    //if ( function_exists ('wsl_version') ) {

        global $WORDPRESS_SOCIAL_LOGIN_PROVIDERS_CONFIG;

        $WORDPRESS_SOCIAL_LOGIN_PROVIDERS_CONFIG[] = ARRAY(
            "provider_id"       => "Kakao",
            "provider_name"     => "Kakao",
            "require_client_id" => true,
            "callback"          => true,
            "new_app_link"      => "https://developers.kakao.com/apps/new",
            "cat"               => "socialnetworks",
        );
    //}
}

이제 워드프레스의 어드민 대시보드에서 Settings > WP Social Login 메뉴에 접속하면 아래 그림과 “Add more providers” 창에 Kakao 버튼이 추가된 것을 확인할 수 있습니다(이 때 버튼의 이미지가 깨지는 이유는 버튼 이미지 파일을 따로 만들지 않은 탓입니다. 적절한 크기의 Kakao버튼 이미지를 만들어 WSL 플러그인의 assets 폴더 아래에 있는 img 폴더에 넣어주면 됩니다).

이제 이 버튼을 클릭하면 아래와 같이 카카오 계정을 설정하는 부분이 추가된 것을 확인할 수 있을 것입니다.

여기에 나온 내용 대로 빈칸만 채워주면 설정은 끝입니다. 나와있는 내용 대로 Kakao Developers 페이지로 가서 새 앱을 하나 만들고 필요한 정보를 추가한 다음 Application Key 값(REST API 키)을 받아 빈칸에 넣어주면 됩니다(아래 그림 참고).

계정의 설정 방법은 페이스북이나 트위터 등 다른 SNS 서비스들과 다르지 않기 때문에 큰 어려움은 없을 것입니다.

이것으로 끝입니다. 이제 워드프레스 로그인 창에 다음과 같이 카카오 로그인 아이콘이 추가된 것을 확인할 수 있습니다. 물론 로그인도 되구요!

몇 가지 유의사항

카카오 서비스는 OAuth 2.0 인증방식을 따릅니다만 통상적인 OAuth2 기반 서비스들과는 달리 Application Secret 값을 요구하지 않습니다. 그렇지만 WSL 플러그인에서는 이 값을 반드시 필요로 하기 때문에 아무 값으로라도 하나 채워주어야 합니다. 공란만 아니라면 어떤 값이든 상관 없습니다.
카카오 서비스에서는 통상적으로 실명을 사용하고 이 값은 한글 이름인 경우가 많습니다만 WSL 플러그인에서는 사용자 등록을 하는 과정에서 한글이름을 제대로 처리하지 못합니다. 이 문제는 테마의 functions.php 파일 속에 다음 코드를 추가하면 해결됩니다.
```
  add_filter( 'validate_username', 'usefulpa_validate_username_fix' );
  function usefulpa_validate_username_fix( $valid, $username ) {
      if ( empty($username) ) return false;
  }
```
로그인 아이콘 (또는 어드민 대시보드에 들어가는 아이콘)은 카카오 사이트에서 내려받아 WSL 플러그인 디렉터리 내의 아이콘 이미지 디렉터리 속에 이름을 맞춰 넣어 주면 됩니다.

여기서는 카카오 서비스를 이용한 로그인 방법을 소개하였지만 네이버나 다음 같은 국내 다른 포털 서비스의 계정을 이용한 로그인도 이와 같은 식으로 처리하면 어렵지 않게 추가할 수 있으리라 생각됩니다.

워드프레스 기반 안드로이드 앱 만들기

2014-02-13T00:00:00+00:00

이 글은 같은 제목으로 블로터닷넷에 게재된 글의 원문입니다.

아직도 워드프레스(WordPress)를 그저 블로그 만드는 툴 쯤으로 생각하고 계신 분들이 계실지 모르지만, 워드프레스는 이미 블로깅 도구를 넘어 범용 콘텐트 관리 시스템(Content Management System)으로 자리매김한지 오래입니다. 해외는 물론 국내에서도 워드프레스를 기반으로 자사의 홈페이지나 웹사이트를 제작하려는 곳이 늘고 있다는 것은 이미 오래 전에 소개해 드린 적이 있습니다만, 최근엔 여기서 한발 더 나아가 단순 웹사이트 용도가 아니라 일정한 기능을 갖추고 온라인 서비스를 제공하는 웹 애플리케이션으로까지 그 용도가 확장되는 추세입니다. 아예 워드프레스를 웹 개발 프레임워크(framework)로 사용하는 케이스도 생기고 있구요. 맞습니다. 흔히 사용되고 있는 레일스(Ruby on Rails) 나 장고(Django)와 같은 바로 그 프레임워크입니다.

워드프레스와 모바일

요즘은 모바일 세상입니다. 워드프레스라고 예외가 될 순 없겠죠. 그래서인지 최근 워드프레스의 행보도 모바일을 지원하는 방향으로 발빠르게 움직이고 있습니다. 물론 워드프레스는 아주 오래 전부터 모바일 환경에 대응해 왔습니다. 모바일 페이지 전용 플러그인부터 반응형웹(responsive web)을 지원하는 테마까지 즐비합니다. iOS나 Android 운영체제에서 워드프레스 사이트를 손쉽게 관리할 수 있도록 모바일 앱들이 이미 출시되어 있고, 최근의 워드프레스 판올림(3.8버전)에서는 어드민 페이지까지 모바일 환경에 맞춰 최적화시켜 두고 있으니(아래 사진) 아마도 워드프레스는 현존하는 콘텐트 관리 도구들 중 모바일 환경을 가장 잘 지원하는 도구라 해도 거짓은 아닐 정도입니다.

여기에 반응형웹 테마도 빠질 수 없겠죠. 반응형웹 기반 테마를 사용하면 소위 “One Source Multi Use” 가 쉬워집니다. 요즘 나오는 거의 모든 워드프레스 테마들이 반응형웹 지원을 기본으로 하고 있으니 워드프레스에서 모바일 디바이스를 지원하는 웹사이트를 제작하는 것은 일도 아닙니다. 그만큼 쉽고 이보다 더 간단할 수 없습니다. 더 이상 뭐가 필요할까요?

워드프레스와 안드로이드가 만나면?

그럼에도 가끔은 이런 니즈(needs)가 생길 때도 있습니다.

“지금 우리가 사용하는 이 워드프레스 사이트의 콘텐트를 기반으로 안드로이드 앱을 만들 순 없을까?”

네, 물론 가능합니다. 플러인들도 있고 이미 해외에는 (자동화 서비스를 포함) 이 작업을 대행해주는 서비스들도 여럿 있습니다. 그렇지만 직접 만드는 것도 별로 어려운 일은 아닙니다. 쓸 수 있는 도구들이 이미 다 갖춰져 있기 때문에 간단한 안드로이드앱 정도라면 별로 어렵지 않게 뚝딱 만들어 Google Play 스토어에 바로 올릴 수 있습니다. 이게 오늘 소개하려는 내용입니다.

워드프레스를 기반으로 안드로이드(Android) 앱을 만드는 방법에는 여러 가지가 있습니다만, 여기서는 다음과 같은 방식(+단계)로 만들어 나가기로 하겠습니다.

워드프레스에서 API 공개하기
간단한 모바일 웹 페이지 만들기
사용자 인터페이스 꾸미기
하이브리드 앱으로 변경하기
Play 스토어에 올리기

이 중 4번(하이브리드 앱으로 변경)과 5번(Play 스토어 올리기) 부분은 이미 다른 곳에 많은 자료들이 나와 있고 또 별로 설명할 부분이 없기 때문에 주로 1~3번 중심으로 설명을 이어 가도록 하겠습니다.

워드프레스 API 공개하기

워드프레스로부터 안드로이드나 iOS같은 모바일 앱을 만들기 위해서는 우선 워드프레스로부터 콘텐트만을 추출해 낼 수 있어야 합니다. 이 작업은 주로 API라는 방식을 통해 이루어지게 되는데, 워드프레스는 이미 공개할 수 있는 API를 갖추고 있습니다. 워드프레스에서는 XML-RPC라는 방식을 사용하는데 주로 이 기능은 외부 블로깅 도구에서 워드프레스를 액세스할 때 많이 사용됩니다. 워드프레스 3.5 버전 부터는 디폴트로 켜져있기 때문에 사용자가 따로 설정하거나 할 부분은 없습니다. XML-RPC의 자세한 내용은 워드프레스 문서 저장소인 Codex에서 확인할 수 있습니다.

다만 이 XML-RPC 방식은 웹 페이지에서 사용하기엔 조금 까다롭습니다. 그래서 웹 상에서 API를 다룰 때는 이 XML 방식보단 JSON 포맷으로 데이터를 받을 수 있는 방식을 주로 사용하게 됩니다. 워드프레스는 아직 자체적으로는 이 JSON 방식의 API는 제공하지 않지만, 워드프레스 플러그인들 중에는 이미 이 기능을 제공하는 것들이 많이 나와 있습니다. 여기서는 그 중 하나인 JSON API 플러그인을 사용하기로 하겠습니다. 플러그인 설치는 여타 다른 플러그인들과 다를 게 없으므로 생략합니다. 이 플러그인을 설치한 후 API를 호출하면 워드프레스의 포스트들이 다음과 같이 JSON 형식으로 추출됩니다. 이 플러그인이 공개하는 JSON API의 자세한 사용법은 아래 참고자료의 문서를 참조하면 됩니다.

프론트 페이지 구성하기

워드프레스로부터 JSON 데이터를 추출하였으면, 이제 이 데이터를 읽어서 보여줄 페이지가 필요합니다. 하이브리드(hybrid) 방식의 모바일 앱으로 만들 것이기 때문에 여기서 만든 웹 페이지가 앱의 화면이 됩니다. 모바일웹 페이지를 만드는 방식은 워드프레스라고 해서 다를 게 없습니다. 일반적으로 모바일웹(앱)을 만드는 방식 대로 만들어 주면 됩니다. 여기서는 자바스크립트 라이브러리 중 Backbone.js를 사용하여 워드프레스로부터 JSON API를 불러 화면에 표시하는 방법을 썼지만, 이 부분은 어디까지나 취향 문제입니다. 여러분 취향에 맞게 가져가면 됩니다. 굳이 Backbone.js를 쓴 까닭은 이 라이브러리가 비교적 간단하게 모듈화된 구조를 만들 수 있는 자바스크립트 MVC 프레임워크 중 하나이기 때문입니다.

웹페이지의 구조나 내용은 아래 참고자료의 데모 소스를 참고하면 되니, 사용법만 간단히 소개합니다. 아래 코드는 이 프로그램의 시작 부분인 main.js 파일인데, 이 부분에서 apiURL 값만 변경해 주면 됩니다. 여기서는 저희가 운영 중인 워드프레스 사이트인 쿠킹페이스북 으로부터 API를 불러오고 있습니다.

window.chocosteak = {
    Models: {},
    Collections: {},
    Views: {},
    Routers: {},
    appConfig: {
        // Your WordPress Home URL
        apiURL: 'http://cookinfacebook.com/api'
    },
    init: function () {
        'use strict';
        this.appRouter = new this.Routers.AppRouter();
        Backbone.history.start();
    }
};

$(document).ready(function () {
    'use strict';
    chocosteak.init();
});

UI 프레임워크 적용

뼈대를 만들었으니 예쁘게 꾸미는 일만 남았습니다. 디자인 작업입니다. 물론 직접 그래픽 도구로 디자인 시안을 작성하고 이 시안에 맞춰 UI를 만들어 내는 게 정석(?) 이겠지만, 여기서는 오픈소스 UI 프레임워크 중 하나인 ChocolateChip-UI 를 사용하기로 하겠습니다. 앞서와 마찬가지로, 이번에도 꼭 ChocolateChip-UI를 사용할 필요는 없습니다. 다른 좋은 UI 프레임워크 도구들도 많이 나와 있으니 그 중 취향에 맞는 것으로 골라 쓰면 됩니다. 저희가 ChocolateChip-UI를 선택한 이유는 무엇보다 제목이 달콤해 보였기 때문입니다.^^

ChocolateChip-UI는 npm을 제공하고 Grunt나 Gulp 같은 빌드 도구들도 지원하기 때문에 자바스크립트에 익숙한 분들이라면 조금 더 쉽게 설치하고 구성할 수 있습니다. Bower로도 설치할 수도 있구요. 안드로이드 뿐 아니라 iOS와 Windows Phone 8의 룩앤필에 맞는 각각의 UI 스타일도 제공하기 때문에 이들 디바이스에 맞는 UI를 구성하는 일도 어렵지 않습니다.

여기서는 이 UI 프레임워크를 Backbone.js의 템플릿으로 사용하였습니다. 템플릿 적용 방법은 아래 참고자료에 나와 있는 문서와 소스코드를 참고하면 될 것입니다.

하이브리드 앱으로 포장하여 Play 스토어로!

여기까지 작업이 끝나면 이제 이렇게 만든 웹페이지(모바일웹앱)을 하이브리드(hybrid) 앱으로 만들어 앱스토어에 올리기만 하면 됩니다. 하이브리드 앱을 만드는 도구들 역시 여럿 나와 있기 때문에 그 중 하나를 사용하면 되지만, 여기서는 그 중 오픈소스 Apache Cordova(흔히 PhoneGap이라 불리웠고, 지금은 조금 다른 길을 걷고 있는)를 사용하였습니다. 이미 모바일웹앱으로 만들어 놓은 코드를 Cordova 에서 지정한 디렉터리로 복사하여 안드로이드 앱으로 빌드한 다음 테스트하고 Play 스토어에 올리면 되는 과정입니다. 작업이 다소 복잡할 수도 있지만, 이미 이에 관한 부분들은 인터넷 상에 좋은 문서들이 많이 나와 있기 때문에 지면관계상 설명은 생략합니다.

사실 이런 생각을 가질 수도 있습니다. 반응형웹을 지원하는 웹사이트 정도면 충분하지 않을까? 굳이 이렇게 하이브리드 형태로 앱을 만들 필요가 있을까? 그렇지만 워드프레스를 일종의 콘텐트 “플랫폼(platform)”이라고 생각하고 모바일 디바이스들을 하나의 “브랜치(branch)” 개념으로 본다면, 디바이스마다 그에 적합한 별도의 앱을 만들어 사용자 저변을 확대하고 사용자들의 다양한 니즈에 부합하는 것도 좋은 전략이라 생각이 듭니다. 특히 지금처럼 별로 어렵지 않게 디바이스를 확장해 나갈 수 있다면 말이죠. 게다가 여기서는 어디까지나 모바일웹을 하이브리드 형태로 옮기는 부분까지만 소개했지만, 하이브리드 앱에서는 그 밖에도 모바일 디바이스에서만 사용할 수 있는 다양한 기능들을 추가해 나갈 수 있기 때문에 모바일 앱만의 특유한 방식으로 사용자 경험을 확장해 나갈 수도 물론 있구요.

여기서부터 시작입니다!

참고자료

OSX에서 Docker로 개발환경 구성하기

2014-02-10T00:00:00+00:00

Docker는 리눅스 기반의 가상화 솔루션입니다. Docker가 다른 가상화 솔루션들과 다른 점은 리눅스 LXC를 기반으로 가상화 환경을 구성하는 탓에 기존 가상화 솔루션에 비해 훨씬 가볍게 가상화 환경을 구성할 수 있다는 점입니다. Docker에서는 이 가상화 공간을 “컨테이너(container)”라고 부르는데, Docker 소개 페이지에도 나와 있듯 마치 물류 환경에서의 화물 컨테이너와 같은 역할을 합니다.

Docker가 아직 세간에 소개된지 얼마 안되는 솔루션이긴 하지만 하루가 다르게 업데이트가 이루어지고 있는 “인기있는” 솔루션이다 보니 Docker의 모든 면면을 여기서 다 소개할 수는 없고, 대신 여기서는 저희 유스풀패러다임에서 주로 사용하는 개발환경인 OSX에서 Docker로 개발환경을 구성하는 방법만 간단하게 소개할까 합니다. OSX를 주 타겟으로 하지만 Windows 환경에서도 거의 똑같이 적용됩니다.

Docker의 기본 개념

Docker는 기본적으로 클라이언트/서버 아키텍처로 동작합니다. 서버측에 docker 데몬(daemon)이 떠 있고, 클라이언트 측에서 tcp 프로토콜로 서버에 액세스하는 구조입니다. 이 때 서버(데몬)는 앞서 말한 가상화 컨테이너(“docker container”) 들을 관리합니다. REST API도 제공하기 때문에 REST 방식으로 컨테이너를 관리할 수도 있습니다.

가상화 컨테이너는 “이미지(image)” 형태로 저장되고 관리됩니다. 이 때의 이미지는 프로그램이 동작하는 환경이 저장된 바이너리 이미지이며, Docker가 LXC 기반 위에서 작동하기 때문에 기존 VM 방식의 가상화 이미지들과는 다른 경량의 이미지입니다. 예를 들어, 기존 VM방식에서 이미지는 프로그램 + 라이브러리 + OS 까지 모두 저장되는 형태지만, Docker 이미지는 프로그램 (및 라이브러리)만 저장한 작은 이미지입니다. Docker에서 이 이미지들은 통상적으로 Dockerfile이라는 설정파일로부터 빌드되어 만들어지게 되고 빌드 시에는 git과 유사한 형태로 증감분만 저장되는 방식을 따릅니다. 이들 컨테이너 이미지는 Docker에서 공개한 퍼블릭 저장소에 저장할 수도 있고 또한 private 공간에 저장 할 수도 있습니다.

이렇게 빌드한 컨테이너 이미지는 어디에서나 실행 가능합니다. 예를 들어, OSX에서 만든 앱서버 docker 이미지를 그대로 Ubuntu에 올려 사용할 수 있습니다. 이미지가 경량이다 보니 이미지를 새로 만들거나 구성하는데 시간이 거의 걸리지 않기 때문에 가볍게 만들고 쉽게 붙였다 뗐다 할 수 있습니다.그러다 보니 Docker를 기반으로 한 PaaS 형태의 서비스들도 벌써 여럿 생기고 있구요. 한마디로 git이 소프트웨어 개발 환경을 변화시킨 것과 유사하게 docker가 또 한번 그 길에 도전장을 내밉니다.

OSX에서 Docker 사용하기

앞서도 얘기했듯 Docker는 리눅스 컨테이너(LXC)를 기반으로 하기에 LXC를 사용할 수 없는 OSX이나 Windows 환경에서는 결국 VirtualBox나 VMware 같은 다른 가상화 머신을 먼저 설치하고 그 위에 docker 환경을 구성할 수 밖에 없습니다. OSX에서 가장 많이 사용되는 방법은 VirtualBox와 Vagrant를 사용하여 리눅스 환경을 구성하고 그 환경 위에 docker 컨테이너들을 올리는 방법입니다. 최근(지난 주) Docker가 0.8 버전으로 업데이트되면서 boot2docker 라는 OSX을 지원하는 좀 더 간단한 방법을 소개하고 있지만 이 역시 기본적으로는 VirtualBox나 VMware 위에서 작동할 수 밖에 없습니다. 현재 시점에서 OSX에서 Docker를 사용하는 방법에는 대체로 다음과 같은 것들이 있습니다:

Vagrant 방식: Vagrant로 가상화 머신을 띄우고 그 위에 Ubuntu 또는 LXC가 지원되는 리눅스 OS를 설치한 다음 그 속에 docker를 설치하여 사용하는 방법입니다.
docker-osx: docker-osx은 위의 Vagrant 방식을 조금 더 자동화시켜 OSX에서 쉽게 사용할 수 있도록 만들어주는 도구입니다.
boot2docker: boot2docker 는 docker에 최적화된 Tiny Core Linux 기반의 VM을 만들어 OSX에서 쉽게 docker에 액세스할 수 있게 도와주는 도구입니다.

어느 방법을 쓰던 작동 원리는 동일합니다. 즉, OSX에 docker 클라이언트를 설치하고 docker CLI로 VM 상의 docker 데몬과 통신하는 방식으로 docker 컨테이너들을 관리하는 형태를 취합니다.

참고로, Homebrew를 사용한다면 docker 클라이언트는 brew 명령으로 간단하게 설치할 수 있습니다.

$ brew tap homebrew/binary
$ brew install docker

Docker로 Node.js 개발환경 구성하기

Docker의 용도는 한 가지가 아니며, 사용하기에 따라 여러 형태로 사용될 수 있습니다. 아직 버전이 낮은 관계로 production 환경에서는 사용이 권장되지 않지만 이미 docker를 production 환경에서 사용하는 곳도 여럿 있을 정도입니다. 그렇지만 가장 대표적인 Docker의 유스케이스는 뭐니뭐니해도 개발환경을 구성하는 것일 겁니다. Docker를 이용하면 production 환경과 동일한 환경을 쉽게 만들고 변형하면서 소프트웨어를 테스트해 볼 수 있습니다.

여기서는 간단한 Node.js 앱을 하나 빌드하여 docker 컨테이너에 올려 실행해 보겠습니다. VirtualBox와 Vagrant는 이미 설치되어 있다고 가정합니다.

우선 Vagrant로 VirtualBox에 Ubuntu OS를 설치하고 그 속에 docker를 설치합니다. 이 작업은 Vagrant를 이용하면 간단하게 처리할 수 있습니다. 이 작업에 사용된 Vagrantfile은 소스코드를 참고 바랍니다. 완료되면 vagrant box를 띄웁니다.

$ vagrant up

Docker는 기존에 빌드된 이미지를 바로 불러와서 사용할 수도 있지만, 여기서는 간단하게 Dockerfile을 하나 작성하여 새로 docker 이미지를 빌드하는 방식을 따르겠습니다. 우선 프로젝트 디렉터리에서 다음과 같이 Dockerfile을 하나 작성합니다. Dockerfile 자체는 기존의 설치 스크립트들과 다르지 않은 간단한 구조를 가지기 때문에 설명을 생략합니다.

FROM ubuntu

# Install Node.js
RUN sudo apt-get update
RUN sudo apt-get install -y python-software-properties # python g++ make
RUN sudo add-apt-repository ppa:chris-lea/node.js
RUN sudo apt-get update
RUN sudo apt-get install -y nodejs

RUN echo "export PATH=$PATH:/opt/node/bin" >> ~/.bashrc
RUN . ~/.bashrc

# Bundle project source
ADD . /opt/src

## Install project dependencies
RUN cd /opt/src; npm install

EXPOSE  8080

# Run the node server
CMD ["node", "/opt/src/app/index.js"]

이제 이 Dockerfile을 빌드하면 새로 docker 이미지가 하나 생성됩니다. 이 때 빌드는 Dockerfile의 각 단계별로 진행되며 별도 옵션을 주지 않는 한 자동으로 캐시되기 때문에 Dockerfile이 변경되면 변경된 부분만 다시 빌드할 수 있습니다.

$ docker build -t ubuntu-node-demo .

빌드된 Docker 이미지들은 docker images 명령으로 확인할 수 있으며, 이렇게 빌드된 이미지는 퍼블릭 저장소에 업로드할 수 있고 프라이빗 저장소를 만들어 저장할 수도 있습니다(git 저장소와 같은 원리). 빌드된 이미지를 docker 컨테이너에서 실행시킬 때는 docker run 명령을 사용합니다. 참고로 이 모든 작업들은 OSX 로컬 환경에서 docker CLI로 처리하면 되기 때문에 굳이 VM에 접속할 필요는 없습니다.

$ docker run -p 8080:8080 ubuntu-node-demo

여기서 -p 옵션은 포트 포워딩 설정을 하는 부분이며, 이 Node.js 앱에서는 8080번으로 웹접속을 설정했고 또 컨테이너 바깥(호스팅 VM)에서도 8080번 포트로 액세스하려 하기 때문에 이렇게 설정한 것입니다. 이제 정상적으로 작동하면 브라우저에서 접속하여 확인할 수 있습니다. 이 때 유의할 점은, OSX에서는 컨테이너로의 접속을 위해 실제로 2번의 포트 포워딩이 이루어진다는 점입니다. 한번은 OSX에서 호스팅 VM으로의 포워딩이고, 나머지 한번은 호스팅 VM에서 다시 docker 컨테이너로의 포워딩입니다. 이 중 하나라도 접속이 막히면 물론 웹접속은 이루어지지 않습니다.

마무리

여기까지 Docker의 기본개념과 OSX에서의 개발환경 구성을 중심으로 간단한 사용법을 소개했지만, 어디까지나 수박 겉핧기에 불과합니다. 실제로 Docker는 여기 소개된 것보다 훨씬 다양한 기능들을 갖추고 있으며 다양한 생태계를 만들어 나가고 있습니다.

Docker는 이제 겨우 걸음마를 시작한 솔루션입니다. 그렇지만 이미 올해의 오픈소스 수퍼루키 10선에 포함될 정도로 벌써 유명세를 치루고 있는 “devops 계의 루키”이기도 합니다. 물론 그만한 대접을 받을 자격이 있다 생각도 듭니다. 무거운 짐을 지고 항해하는 고래를 상징하는 로고 마스코트처럼, 올 한해 Docker의 멋진 순항을 기대해 봅니다.

앞서 소개한 예제는 github에 올려 두었으니, 필요한 분들은 참고 바랍니다.

터보링크(Turbolinks)와 레일스 4.0

2013-06-28T00:00:00+00:00

엊그제 레일스(Ruby on Rails) 4.0 파이널 버전이 공식적으로 릴리즈 되었다. 2.x 버전에서 3.0 버전으로 넘어올 때 만큼 눈에 띄는 큰 변화는 없지만 그래도 프레임워크 전반에 걸쳐 작은 부분까지 놓치지 않고 세심하게 가다듬은 흔적들이 눈에 띄어 반갑다. 4.0 릴리즈 소식을 전하는 루비온레일스 블로그에서 특히 눈에 띈 부분은 터보링크(Turbolinks)를 비중있게 소개하고 있다는 점. 다음은 블로그에서 적힌 터보링크에 대한 소개다:

Speed-up the client-side with Turbolinks, which essentially turns your app into a single-page javascript application in terms of speed, but with none of the developmental drawbacks (except, maybe, compatibility issues with some existing JavaScript packages).

터보링크를 쓰면 별다른 기술적 문제 없이 속도(speed) 측면에서 싱글페이지 자바스크립트 앱 효과를 낼 수 있다고 되어 있다.

Pjax와 터보링크

도대체 터보링크가 뭐길래? 레일스를 다루지 않는 분들을 위해 간단히 터보링크가 무언지부터 소개해 보자.

터보링크를 이해하려면 터보링크의 아이디어 소스가 된 pjax부터 알아보는 편이 간단할 것 같다. Pjax는 pushState와 Ajax의 결합어다. 말 그대로 HTML5 pushState 와 Ajax을 함께 사용하여 pushState 기능이 지원되는 브라우저에서 사용자가 웹페이지의 통상적인 링크를 클릭할 경우 전체 페이지를 갱신(full page refresh)하는 대신, 클릭 이벤트를 가로 채 자동으로 해당 URL에 대해 Ajax 호출을 하고 그 결과로 받은 웹페이지의 일부분(fragment)만으로 기존 웹페이지의 특정 영역을 대체(replace)하는 기법이다.

Pjax를 쓰면 큰 노력 없이 정적인 웹페이지를 좀 더 빠르게 만들 수 있다. 그저 자바스크립트 라이브러리 하나 추가하는 것만으로 웹페이지 속 링크를 클릭할 때마다 매번 전체 페이지를 새로 갱신해야 하는 부담을 줄여주어 성능을 개선 시킬 수 있는 효과가 있기 때문이다.

(사진출처: ntotten.com)

레일스 터보링크는 여기서 한발 더 나간다. Pjax처럼 클릭 이벤트를 가로 채 자동으로 Ajax 호출하는 부분까지는 똑같지만, 아예 요청 결과를 파싱하여 title 태그와 body 태그를 추출한 다음 기존 페이지에서 상응하는 부분만 대체 시킨다. 과히 설정 보단 관례(convention over configuration)를 우선하는 “레일스 스러운” 발상이다. 실제로 터보링크는 37signals의 대표적인 웹서비스인 Basecamp의 모바일 버전에 적용되어 상당한 성능 개선 효과를 거둔 것으로 알려져 있기도 하다.

호불호(好不好)

이 터보링크가 과연 레일스 4.0을 대표할 만큼 중요한 것일까? 굳이 프레임워크 속에 디폴트로 집어넣을만한 것이었을까? 레일스 3.1로 넘어올 때 새로 프레임워크에 추가된 에셋 파이프라인(asset pipeline) 만큼은 아니지만, 그래도 터보링크를 프레임워크 속에 넣는 것을 두고 레일스 커뮤니티에서 갑론을박이 있었던 것으로 기억한다. 그래서인지 레일스 블로그에는 아래와 같은 재밌는 댓들도 눈에 띈다.

터보링크를 사용함으로써 얻는 가장 큰 잇점은, 터보링크 페이지에도 소개되어 있듯, 매번 링크를 클릭할 때 마다 페이지 속 여러 에셋들, 즉 자바스크립트나 CSS 파일들을 다시 다운로드하여 리로딩하지 않아도 된다는 점이다(그럼으로써 애플리케이션의 속도를 향상시킬 수 있다).

그리고 또 한 가지는, 이렇게 매번 자바스크립트 파일을 새로 로드하지 않아도 되기 때문에, 싱글페이지앱 구현이 가능해 진다는 점이다. 물론 Backbone.js 나 Ember.js, Angular.js 같은 자바스크립트 MV* 프레임워크를 사용하여 웹앱을 구성하는 것과는 방식이 다르지만, 전체 페이지가 한번만 로드된다는 점, 그에 따라 브라우저 속에서 상태(state)가 보존될 수 있다는 점 등에서는 싱글페이지 앱(SPA) 이다.

앞서의 자바스크립트 MV* 프레임워크를 사용할 경우, 백엔드 처리를 위해 서버측(레일스 포함)에서 별도의 데이터 포맷(대개는 JSON)을 지원하는 API 엔드포인트(endpoint)를 구성해야 하는데 터보링크는 그냥 기존 방식대로 HTML로 렌더링하면 되니 편리하기도 하다.

편리함만 있는 게 아니라 문제점도 있다(이런 문제들이 레일스 커뮤니티에서 반론과 비판의 이유가 된다).

무엇보다도 가장 근본적인 문제는 터보링크가 HTML 페이지 속에서 자바스크립트가 처리되는 방식을 흔들어 놓는다는 점이다. 그리고 이것은 기존의 많은 자바스크립트 라이브러리들과 충돌하는 문제를 일으킬 수 밖에 없다는 게 유명한 오픈소스 개발자 Yehuda Katz의 설명이다:

This is not a mere quibble: a lot of existing JavaScript operates under the assumption of a clean scope, and a single DOMContentLoaded event. In a perfect world, popular JavaScript plugins would be architected to work well with a solution like Turbolinks, but the assumption of a clean global scope per server-rendered HTML page is baked into a lot of the JavaScript and jQuery libraries that people tend to use.

물론 레일스 역시 이런 문제점을 인지하고, 특히 jQuery와의 충돌에 대해서는, 솔루션도 제시하고 있긴 하지만, 결국 이 문제는 case by case로 해결할 수 밖에 없는 문제로 보인다. 터보링크와 다른 자바스크립트 라이브러리들 간의 호환성에 관한 정보를 제공하는 Turbolinks Compatibility 같은 곳도 있다.

자칫 잘못 사용할 경우 자바스크립트 전역 스코프가 초기화되지 않거나(body 태그 속에 동적으로 삽입되는 자바스크립트가 그 예), 메모리를 계속해서 잡아먹을 가능성도 안고 있다.

레일스 기반 오픈소스 포럼 솔루션 Discourse 공동창업자 Robin Ward는 자신의 블로그에서 프라하 어느 카페에서 인터넷에 접속하는 것을 예시로 들면서 터보링크 보다는 CDN과 자바스크립트 MV* 프레임워크를 사용하는 것이 올바른 접근이라고 말하기도 한다.

“터보(Turbo)”의 의미

조금 경력이 있는 개발자들이라면 “터보”라는 말을 들으면 떠오르는 단어가 있을 것이다. 바로 “터보 파스칼”, “터보 C” 등 앞에 “터보” 글자가 붙는 볼랜드(Borland)사의 컴파일러/IDE 제품군 이름이다. 지금은 컴퓨팅 역사 속으로 사라졌지만, 파스칼과 C언어가 세상을 주름잡던 당시만 하더라도 프로그래밍 언어 앞에 “터보” 가 붙으면 그야말로 “터보 엔진”을 단 것처럼 빠른 컴파일과 빠른 개발 속도를 선사했었다.

터보링크 앞에 붙은 “터보” 역시 그런 의미로 붙여졌을 것이다. 새 레일스 프로젝트를 생성하는 바로 그 순간부터 터보링크가 적용되니 빠르다고 하지 않을 수 없다. 그렇지만 터보링크는 옛날 볼랜드 제품군이 주름잡던 시절의 그 “터보”만큼 강력한 것 같지는 않다.

그렇다면 언제 사용하면 좋을까?

국내에서 만들어지는 웹서비스들의 경우 아직은 SPA 방식 보다는 전통적인 서버측 HTML 렌더링 방식을 사용하는 쪽의 비중이 훨씬 높은 것이 사실이다. 자바스크립트 MV* 프레임워크나 CDN을 적용하는 곳도 그렇게 많지는 않은 것 같다. 이런 전통적인(?) 방식의 웹 개발 환경에서라면 터보링크는 분명 “최소 노력으로 최대 효과”를 얻을 수 있는 실용적인 접근이 될 수 있을 것 같다. 특히 기존에 레일스로 만들어진 웹사이트의 모바일 버전을 새로 만드는 경우가 터보링크를 적용하기에 가장 적합한 유스케이스가 아닐까 생각된다. 37signals가 그랬듯이.

레일스 개발자들은 대부분 실용주의 개발자들이다. 필요하면 쓰고 아니면 안쓰면 된다. 터보링크를 레일스 디폴트로 두면서 DHH가 했던 생각도 아마 그런 게 아니었을까. “내가 써 봤는데 좋더라구. 너도 한번 써 봐!” 맘에 안들면? 혹은 필요 없으면? 안쓰면 그만이다.

터보링크의 사용법은 Rails Guides와 터보링크 README 파일에 잘 나와 있으니 참조하면 된다.

"한국형" 웹사이트와 워드프레스 게시판

2013-06-21T00:00:00+00:00

워드프레스에 대한 관심이 높아짐에 따라 국내에서도 요즘은 워드프레스로 웹사이트를 만들려는 분들이 많아지고 있습니다. 워드프레스로 웹사이트를 제작하려는 분들이 갖는 워드프레스에 대한 공통적인 “느낌”은 대략 이런 것들인 것 같습니다.

만들기 쉽고 관리하기도 편하고 검색도 잘되고 또 무엇보다도 “공짜”!

맞는 말입니다. 그리고 또 워드프레스로 웹사이트를 제작하려는 분들이 갖는 공통적인 “요구사항”이 하나 있는데 그건 바로 웹사이트에 “게시판”을 몇 개 달고자 한다는 것입니다. 우리가 아주 오래 전 호랑이 담배피던 시절 – bbs시절 – 부터 봐 왔던 바로 그 “게시판” 말입니다. 그런데 그 간단할 것 같고 낡디 낡고 흔하디 흔한 “게시판”이 워드프레스에서는 안된다는 말을 접하고는 조금 당황하게 됩니다.

“아니 그 간단한 게 왜 안되나요?”

맞습니다. 결론부터 말하면 “안됩니다.” 개그콘서트 정여사 버전을 빌리자면 “안되도 너~무 안됩니다.” 하지만 세상에 안되는 건 없다고 믿는 분들도 계십니다. 워드프레스 게시판도 마찬가지입니다. 워드프레스 기본엔진을 뜯어 고쳐 게시판을 우겨 넣기로 한다면 완전 안될거야 또 없습니다. 그렇지만 워드프레스라는 오픈소스는 기본적으로 블로깅 엔진으로 출발했고 지금은 CMS라 우기고 있는 솔루션입니다. 솔루션은 정해진 목적에 맞춰 사용하는 게 효율적 입니다. 말하자면 맞춤옷에 대비되는 기성복인 셈이죠. 워드프레스로 게시판을 만드는 게 왜 안되는지 그 기술적인 이유는 여기서 주절이 늘어 놓지 않겠습니다. (궁금하면 5백원!)

“한국형” 워드프레스 게시판들

안된다구요? 이미 워드프레스 게시판 플러그인들이 많이 있잖아요?

라고 반문하실 수도 있습니다. 맞습니다. 이미 국내에는 여러 종류의 한국형 워드프레스 게시판 플러그인들이 나와 있습니다. 인터넷 검색만 해 봐도 다음과 같은 플러그인들이 있으며, 이들 모두 통상적인 워드프레스 플러그인들과 마찬가지로 설치하여 활성화시키면 바로 사용할 수 있습니다.

그런데 뭐가 문제냐구요? 문제는 “한국형” 이라는 수식어에 있습니다. 우리가 생각하는 “게시판”의 수준은 아주 높습니다. 그리고 워드프레스 게시판 플러그인들이 제공할 수 있는 수준은 여기에 비하면 턱없이 낮을 수 밖에 없습니다. 제로보드(XE)나 그누보드 같은 설치형 게시판이나 혹은 포털사이트의 인터넷 카페에서 쓰던 게시판 수준 생각하고 접근하면 낭패를 보기 십상입니다. 아직 그 수준에 이른 플러그인들은 없으며 앞으로도 나오기가 쉽지 않을 테니까요.

한국의 워드프레스 개발자들이 실력이 없어 그런 건 아닙니다. 그 근본적인 이유는 워드프레스 엔진의 기술적 구조에 있습니다. 워드프레스 엔진은 한국형 게시판을 100% 구현해 넣기엔 부적합한 구조를 갖고 있습니다(나쁘다는 의미가 아니라 다르다는 의미에서). 그러니 이런저런 꼼수(?)를 찾아 다닐 수 밖에요. 이와 관련해서 국내 한 블로그에 소개된 분투기를 읽어 보셔도 재미있을 것 같습니다.

워드프레스에 게시판 추가하기

눈높이를 조금 낮추면 문제는 한결 수월해 집니다. 이제 워드프레스에 맞는 “가벼운” 게시판을 하나 만들어 추가해 보기로 하겠습니다. 통상적으로 워드프레스에 게시판을 추가하는 것은 글(포스트)들을 특정한 카테고리로 묶고 해당 카테고리의 글 목록을 워드프레스 페이지(page)에 표시하는 방식으로 하게 됩니다. 예를 들어, “자유게시판” 이란 제목의 게시판을 하나 만든다고 하면 다음과 같은 순서를 따릅니다.

우선 “자유게시판”이란 이름의 카테고리를 하나 만듭니다.
이번엔 “자유게시판”이란 이름의 페이지를 하나 생성합니다(이름은 뭐든 상관 없습니다).
“자유게시판” 페이지에 “자유게시판” 카테고리로 작성된 글들의 목록을 게시판 형태로 표시합니다.
“자유게시판” 페이지를 메뉴에 추가하여 게시판으로 접근할 수 있게 만듭니다.

페이지 속에 글 목록을 넣는 방법은 여러 가지입니다만, 흔히 사용되는 방법은 플러그인에서 제공하는 단축코드(shortcode)를 활용하는 방법입니다. 예를 들어, 위의 게시판 플러그인들 중 하나인 MH보드를 사용한다면, MH보드에서 제공하는 단축코드인 ‘[mh_board]‘를 페이지 본문 속에 넣어주면 이 부분이 게시판으로 치환되어 화면에 표시되는 식입니다(아래 그림).

기술적으로는, 페이지 속에 글 목록을 넣는다는 것은 워드프레스에서 커스텀 쿼리를 사용하여 루프(loop)를 구성하는 것을 의미합니다. 그리고 이 경우 그 쿼리의 조건값은 특정 카테고리에 속한 모든 글들을 추출하여 목록으로 표시하는 것이구요. 따라서 굳이 게시판 플러그인을 사용하지 않더라도 페이지 속에서 커스텀 쿼리를 구성할 수 있는 방법이라면 뭐든 가능합니다. 예를 들어 List category posts나 Display Posts Shortcode 같은 플러그인을 사용할 수도 있고, 간단하게 직접 커스텀 쿼리가 들어간 템플릿을 작성해도 됩니다.

말이 나온 김에 간단한 템플릿을 하나 만들어 보겠습니다. 특정 카테고리의 글들을 게시판 형태로 보여주는 템플릿인데, 페이지명(slug)과 일치하는 카테고리명(slug)을 가지는 모든 글들을 보여주는 간단한 페이지 템플릿입니다. 일종의 관례(convention)을 만든 것인데요. 이럴 경우, 사용자는 이 템플릿 파일을 테마 디렉터리 속에 넣어 두고, 게시판이 필요할 경우 새 페이지를 하나 생성하고 그 페이지의 템플릿을 이 게시판 템플릿으로 지정하면 자동으로 게시판이 하나 만들어지게 됩니다. 게시판에 글을 쓸 때는 글(포스트)의 카테고리만 게시판 페이지명과 일치하게 주면 자동으로 해당 게시판에 글이 게시가 되는 식입니다.

커스텀 쿼리는 다음과 같이 주었습니다:

$args = array(
	'category_name' => get_query_var('pagename'), 
	'posts_per_page' => 5, 
	'paged' => get_query_var('paged')	
);

// The Query
query_posts( $args );

위 코드가 적용된 페이지 템플릿을 얼마 전 소개한 적이 있는 다음 Dough 기반 워드프레스 테마인 도넛(Doughnut)에 적용하면 아래와 같은 결과가 만들어 집니다. 어떠세요? 제법 게시판 같아 보이나요?

이렇게 직접 템플릿을 구성하면 사용자 인터페이스 변경이 수월해지는 장점이 있습니다. UI를 입맛에 맞게 마음대로 커스터마이징할 수 있습니다. 여기에 사용된 페이지 템플릿 소스는 도넛(Doughnut) 코드 속에 들어 있으니 참고하시면 되겠습니다.

이 글에서 따로 소개는 하지 않겠지만, 사용자들이 직접 글을 작성할 수 있도록 “글쓰기” 기능을 추가하는 것도 마찬가지입니다. 여러 가지 방법이 있고 그 중 적절한 것을 고르면 됩니다. 예를 들어 WP User Frontend 같은 플러그인을 사용하는 것도 간단한 한 가지 방법이 될 수 있습니다.

펄(Perl) 프로그래밍 격언 중에 “TMTOWTDI“라는 말이 있습니다. 어떤 일을 하는데는 한 가지 이상의 방법이 있다(There’s more than one way to do it)는 말인데요. 이 말은 워드프레스에도 그대로 적용되는 것 같습니다.

업데이트

이 글을 포스팅한 후에 댓글 또는 이메일, 트위터 등을 통해 몇몇 분들께서 좋은 정보를 더해 주시고 또 여기에 추가해 주면 좋겠다고 말씀하시는 내용들이 있어 아래에 간략하게 덧붙입니다.

HwangC의 착한 워드프레스 블로그에는 bbPress 등 워드프레스 게시판으로 사용할 수 있는 여러 가지 국내외 플러그인과 테마들이 잘 정리되어 있습니다.
Cosmosfarm에서 개발한 오픈소스 게시판 플러그인 KBoard는 워드프레스에서 기본으로 제공하는 데이터 구조를 사용하는 대신, 게시판과 댓글 처리를 위해 기본 워드프레스 엔진에 4개의 추가적인 DB테이블을 덧붙이는 방식을 씁니다. 때문에 여늬 “한국형” 게시판들 같은 수준높은 게시판을 구성할 수 있는 장점이 있습니다. 워드프레스를 굳이 이렇게까지 확장해서 쓸거면 차라리 XE나 그누보드를 써서 웹사이트를 만드는 게 낫지 않나 생각할 수도 있지만, 아무튼 워드프레스로 게시판 달린 웹사이트를 굳이 만들어야만 하는 “한국형” 개발사 현실에서는 고마운 솔루션이 아닐 수 없습니다.

도넛(Doughnut), 다음 Dough 기반 워드프레스 테마

2013-06-04T00:00:00+00:00

구글링을 하다 보면 아주 좋은 오픈소스 CSS 프레임워크들을 많이 만나게 됩니다. 대표적인 것이 트위터가 만들어 공개한 Bootstrap이고, 그 밖에도 Foundation이나 Pure 등 멋진 라이브러리들이 즐비하기 때문에 무엇을 선택할까가 오히려 고민인 경우가 많습니다. 아! 물론 이건 어디까지나 CSS3와 반응형 웹 디자인 등 최신 프론트엔드 디자인 흐름을 반영한 CSS 프레임워크들을 말하며, Blueprint나 960gs 같은 예전 그리드 방식의 CSS 프레임워크는 논외입니다.

워드프레스 테마 개발자의 입장에서 보면 좋은 CSS 프레임워크들은 좋은 테마 개발의 재료가 됩니다. 예를 들어, 트위터 부트스트랩 같은 경우는 이 프레임워크에 기반하여 만들어진 테마가 이미 아주 많이 나와 있습니다. ZURB의 파운데이션도 마찬가지구요.

이렇게 좋은 프레임워크들과 여기에 기반한 워드프레스 테마들의 생태계를 보면서 우리나라에도 이런 좋은 CSS 프레임워크들이 많이 나왔으면 좋겠다는 바램을 늘 가지고 있었습니다. 그러다 최근 우연히 다음에서 Dough 라는 이름으로 멋진 CSS 라이브러리를 만들어 공개하였다는 사실을 알게 되었습니다. 물론 이전에 네이버 XE엔진에서 사용된 OUIF(Open User Interface Framework) 라는 공개 UI 프레임워크가 있긴 했습니다만, 최근엔 업데이트가 안되는 듯 해 보입니다.

Dough(도우)는 다음커뮤니케이션 웹표준기술팀에서 제작한 CSS 기반 UI Framework 입니다. 버전은 아직 0.2.0에 불과하지만, 사용해보면서 느낀 점은, 꼭 필요로 하는 기능들은 왠만큼 다 들어가 있어 보이는 데다 또 사용법도 아주 간단하다는 것이었습니다. 물론 아주 디테일한 부분이나 좀 더 다양한 컴포넌트 지원 등은 추가로 필요한 부분이겠지만, 적어도 지금 수준이라도 간단한 사이트에 적용하는데는 별 문제가 없어 보였습니다.

그래서 이 멋진 “반죽(dough)”을 발판삼아 간단하게 워드프레스 테마를 하나 만들어 보았습니다. 이름은 반죽에 “nut”을 붙여 “도넛(doughnut)”으로 정했으며, github 페이지에서 다운로드 받으실 수 있습니다.

단, 아직은 그저 적용만 시킨 단계인지라 부족한 부분이 많이 있습니다. (언제나 그렇듯) 차츰 개선시켜 나갈 수 있으면 좋겠습니다. 시작이 반이니까요.^^

워드프레스 사이트에 결제모듈 연동하기

2013-05-28T00:00:00+00:00

작년 초에 워드프레스로 웹사이트 만들기를 포스팅할 때만 해도 국내에는 워드프레스와 관련하여 참고할만한 자료나 문서가 많이 부족했지만, 요즘은 서점에만 나가도 워드프레스 관련 책들이 넘친다. 불과 1년 여만에 정말이지 놀라운 변화다. 그만큼 관심도 많아졌고 또 저변도 넓어졌다는 얘기니 워드프레스를 좋아하는 한 사람으로 즐거운 변화가 아닐 수 없다.

워드프레스로 쇼핑몰 만들기

그래서인지 요즘 워드프레스와 관련한 문의 중에는 워드프레스로 쇼핑몰을 구축하려고 하는데 어떻게 하면 되는지를 묻는 문의들이 많다. 워드프레스로 쇼핑몰을 구축하는게 과연 합리적인 방법인지 아닌지는 논외로 하고, 실제로 워드프레스로 간단한 쇼핑몰을 만들어 사용하는 사례들도 많이 있으니 못할 것도 아니다.

일반적으로 쇼핑몰 하면 떠오르는 몇몇 주요한 기능들이 있는데, 워드프레스라고 해서 별반 달라질 건 없다. 예를 들어 상품 정보를 관리하고, 쇼핑카트를 만들고, 사용자가 주문을 할 수 있게 하고, 결제와 배송처리 등을 수행하는 게 통상적인 쇼핑몰의 주요 기능이라면, 워드프레스로 쇼핑몰을 만든다고 해서 이들 기능이 달라진다거나 하지는 않는다는 말이다.

다만 워드프레스가 기본적으로 블로깅 도구로 부터 출발했고, 또 현재도 콘텐츠 관리 시스템(CMS)으로 주로 불리고 사용되는 탓에 쇼핑몰은 워드프레스가 “잘 하는” 분야는 분명 아니다. 이 점은 워드프레스를 구성하는 데이터베이스 테이블의 구조만 보면 바로 알 수 있다. 워드프레스는 포스트(Post)를 중심으로 하는 비교적 간단한 데이터베이스 구조를 갖는 탓에 워드프레스에 쇼핑몰 기능을 추가하기 위해서는 결국 워드프레스 엔진을 확장해야 한다. 새로운 데이터 모델의 추가가 불가피하는 말이다.

다행히 워드프레스 커뮤니티에는 워드프레스 기본 엔진에 이런 “쇼핑몰 기능”을 추가해주는 플러그인들이 많이 나와 있고, 상당히 완성도 높은 플러그인들도 많기 때문에 이들 중 하나를 선택하여 설치하면 워드프레스를 바로 “쇼핑몰”로 변신시킬 수가 있다. 다음 몇몇이 그 중 대표적인 플러그인들이다.

이들 플러그인 대부분이 기본 기능은 무료로 제공하면서 조금 더 고급이나 확장 기능은 유료인 가격정책을 가져가고 있기 때문에 설치해서 사용해 보고 그 중 가장 마음에 드는 것을 골라 추가 기능을 구매하는 방식으로 사용하면 된다. 다만 한 가지 아쉬운 점은 이 모든 플러그인들이 국내에서 제작된 것이 아니기 때문에 국내 환경을 기반으로 서비스하는 쇼핑몰을 제작하려고 할 경우에는 아무래도 걸리는 부분들이 있다는 점이다. 그 중 대표적인 문제 하나가 바로 “결제 연동”하는 부분이다.

결제 연동하기

알다시피 국내에서 결제를 처리하기 위해서는 주로 PG사와 계약을 맺고 PG사에서 제공하는 모듈을 받아서 결제 처리를 하게 된다. 국내 주요 PG사 (LG데이콤 U+, 올더게이트, 이니시스, KCP, 페이게이트 등)들은 제각각 자신들만의 연동 모듈을 제공하기 때문에, 결국 위의 플러그인들 중 하나를 선택하여 사용하게 되더라도 결제 처리 부분은 이들 PG사의 모듈 중 하나와 연동해야 하는 문제가 남게 된다. 위의 플러그인들이 여러 종류의 결제 옵션을 제공하고 있기는 하지만 아직 국내 PG사 연동을 지원하는 플러그인은 없기 때문이다.

여기서는 위에 소개한 플러그인들 중 가장 많이 사용되고 있는 WP e-Commerce 플러그인에서 국내 PG사 중 한 곳인 올더게이트의 PG모듈과 연동하는 방법을 간단하게 소개한다. 올더게이트를 선택한 데 특별한 이유가 있는 것은 아니며, 다른 PG사들 역시 기본 연동 방식에는 특별하게 다를 게 없기 때문에 다른 PG모듈과의 연동 시에도 참고할 수 있을 것이다.

올더게이트 연동에 필요한 모듈들은 올더게이트 자료실에서 다운로드 받을 수 있으며, 자세한 사용법은 함께 따라오는 설치매뉴얼을 참고하면 된다. 설치 매뉴얼에서 보면 올더게이트의 PG연동 모듈은 다음과 같은 처리 흐름을 갖는다.

따라서 WP e-Commerse 플러그인(이하 ‘wpsc’)에서는 우선 사용자의 주문정보를 받아 PG의 AGS_pay 모듈까지 넘겨주어야 하는데, wpsc 플러그인은 사용자가 커스텀 PG를 추가하고 연동할 수 있는 방법을 이미 만들어 두고 있다. wpsc에서는 wpsc-merchants 디렉터리 속에 두는 것을 권장하고 있지만, 간단하게 플러그인을 하나 만들어 그 속에 다음 코드를 추가해도 된다.

$nzshpcrt_gateways[$num]['name'] = '올더게이트PG';  // 게이트웨이명
$nzshpcrt_gateways[$num]['internalname'] = 'pg_allthegate'; 
$nzshpcrt_gateways[$num]['function'] = 'gateway_pg_allthegate';

이제 관리자 페이지의 wpsc 플러그인 설정에서 보면 다음과 같이 “올더게이트PG”가 Payment 옵션에 추가된 것을 확인할 수 있다. 이 옵션을 선택하면 올더게이트 PG가 활성화된다.

이제 남은 일은 실제로 PG와 연동하는 부분을 만들어 주는 것이다. 앞서 작성한 코드 중 function 부분을 만들어 채워주면 되는데, 결제창을 팝업으로 띄우고, 주문에 관한 정보를 읽어 팝업창으로 넘기는 방식을 사용해 간단하게 구현해 보았다.

<?php 

function gateway_pg_allthegate($seperator, $sessionid) {

	global $wpdb, $wpsc_cart;

	$purchase_log = $wpdb->get_row(
	"SELECT * FROM `".WPSC_TABLE_PURCHASE_LOGS.
	"` WHERE `sessionid`= ".$sessionid." LIMIT 1"
	,ARRAY_A) ;

	$order_id 	= $purchase_log['id'];
	$amt 		= $wpsc_cart->total_price;

	$pay_url = plugins_url( "source/AGS_pay_1.php?OrdNo=$order_id&amt=$amt" , __FILE__ );
	echo "<script>window.open('$pay_url', '', 'toolbar=no,location=no,directories=no,status=no,menubar=no,scrollbars=no,resizable=no,top=0,left=350,width=527,height=543');</script>";
} 

?>

이제 사용자가 상품을 장바구니에 담고 체크아웃하여 “구매하기(Purchase)” 버튼을 클릭하면 다음과 같이 결제창이 팝업으로 표시된다. (여기서는 올더게이트에서 제공하는 샘플 폼을 그대로 사용하였으며, 실제 사용할 때는 필요에 맞게 폼 양식을 적절히 변경하면 될 것이다)

마무리

지금까지 설명한 것은 어디까지나 원리를 중심으로 한 간단한 데모일 뿐이다. 실제로 프로덕션 환경에서 사용하기 위해서는 몇 가지가 더 추가되어야 한다. 예를 들면, 올더게이트가 EUC-KR 인코딩 방식을 채택하고 있기 때문에 UTF-8을 기본으로 하는 워드프레스에서 한글을 제대로 처리하기 위해서는 인코딩값을 변환해 주어야 한다. 또 위에서는 설명하지 않았지만, PG사로 부터 받은 결과값을 바탕으로 주문 정보를 업데이트하는 처리도 추가되어야 할 부분이다.

국내에는 아직까지 워드프레스 기반 쇼핑몰을 지원하는 플러그인은 나와 있지 않은 것 같다. 이미 국내에 많은 좋은 쇼핑몰 솔루션들이 나와 있으니, 요즘과 같은 관심과 저변이 계속된다면 아마 조만간 워드프레스 기반에 맞춘 좋은 플러그인들도 많이 등장할 것이라 예상된다. 그러면 결제 처리와 관련된 문제들도 자연스레 해소되리라 기대해 본다.

업데이트

이 글을 포스팅한 후에 댓글 또는 이메일 등을 통해 많은 분들께서 좋은 정보들을 제공해 주셨고, 또 그간 국내에서도 쓸만한 쇼핑몰/결제처리 관련 오픈소스들이 제법 공개된 탓에 참고로 정리해 보았습니다. 아래 목록은 계속해서 업데이트할 예정입니다. 혹시라도 빠졌거나 더 추가할만한 내용 알려 주시면 반영하겠습니다.

워드프레스 쇼핑몰 솔루션

아직 워드프레스 기반 쇼핑몰 솔루션(플러그인)은 국내에 나와 있는 것이 없는 것으로 보입니다.

결제처리(PG연동) 솔루션

WooCommerce Paygate JT 스튜디오 제이티에서 개발한 WooCommerce용 결제모듈이며 Paygate 연동을 지원합니다. 다운로드
WooCommerce Paygate Sunnysidesoft에서 만든 결제 플러그인이며, WooCommerce 기반에 Paygate 연동을 지원합니다. 다운로드
그 밖에도 플레닛메이트, 옵티안 같은 곳에서도 결제 솔루션(플러그인)을 제작/판매하고 있습니다.

baas.io 단상

2013-05-23T00:00:00+00:00

오전에 잠깐 짬을 내어 baas.io 서비스를 한번 사용해 보았습니다. 알다시피 baas.io는 KTH에서 운영하는 클라우드 기반 애플리케이션 백엔드 플랫폼 서비스입니다. 흔히 PaaS라고 부르는 이 서비스의 가장 대표격은 최근 Facebook에 인수된 미국 회사 Parse라고 할 수 있습니다. 아마 baas.io도 이 Parse를 상당부분 벤치마킹한 서비스가 아닐까 생각이 듭니다. 다만, Parse와는 다르게 아직 오픈베타버전이라 확정된 가격정책은 나와있지 않으며, 누구든지 무료로 사용해 볼 수 있습니다.

baas.io가 제공하는 주요 기능에는 다음과 같은 것들이 있습니다. 자세한 내용은 baas.io 사이트에 잘 소개되어 있습니다.

사용자 정보관리: 사용자 인증과 권한관리 등을 포함한 사용자 정보 관리 기능을 baas.io에서 대신 처리해 줍니다. 사용자 정보관리는 거의 대부분의 앱서비스에서 꼭 필요로 하는 기능입니다. 요즘 많이들 사용하는 페이스북 인증과의 연동 기능도 제공하고 있어 편리합니다.
데이터 관리: 사용자 데이터 외에도 앱/웹 서비스에는 보관하고 관리해야 할 여러 종류의 데이터들이 있기 마련입니다. 예를 들어, 간단한 뉴스 앱을 만든다고 하더라도 어딘가에 뉴스 데이터를 관리해야 합니다. baas.io에서는 엔티티(Entity)와 컬렉션(Collection) 이라는 개념으로 쉽게 관계형 데이터 구조를 생성하고 관리할 수 있게 해 줍니다. 게다가 REST 기반 API를 제공하기 때문에 아주 쉽게 액세스가 가능하다는 장점이 있습니다.
이 밖에도 파일관리(사진 업로드 등을 할 수 있습니다), POI(위치기반 서비스를 만들 때 사용됩니다), PUSH(모바일 앱에서는 꼭 필요한 기능이죠?), 고객센터 등의 기능을 제공합니다.

현재 iOS, Android, 그리고 Mobile Web 이렇게 3가지 플랫폼을 지원하지만, 제 생각엔 JavaScript를 이용하는 웹앱 보다는 iOS나 Android 앱을 개발할 때 조금 더 유용할 듯 합니다.

baas.io의 기본 타깃은 모바일(웹)앱에서 필요로 하는 백엔드 단의 공통 서비스들을 baas.io가 제공해 줌으로써, 프론트엔드 앱 개발자들의 앱개발 프로세스를 쉽게 만든다는 측면입니다만, 사실 baas.io에서 제공하는 수준의 백엔드 기능들은 요즘 이런저런 오픈소스 도구나 프레임워크들 덕에 구현이 그렇게 까다롭거나 오랜 시간을 요하는 부분은 아닙니다. 따라서 오히려 baas.io의 장점은 대용량의 트래픽을 커버해 줄 수 있다는 부분이 아닐까 싶습니다만, 아직 가격정책이 책정되지 않아 얼마만큼의 효용이 있을지는 조금 더 두고봐야 할 부분 같습니다.

나머지 하나는 서비스의 안정성인데, 비록 KT(H)라는 대기업에서 제공하는 서비스라고는 하지만, 최근 아임IN이나 푸딩 같은 서비스를 갑작스레 closing하는 사례 등을 감안할 때 언제까지 이 서비스가 유지될지 하는 것은 이 서비스를 사용하는 사람들에겐 중요한 리스크 측면이라 할 것입니다. 뭐 이건 3rd-Party 서비스를 사용하는 모든 프로젝트들의 공통적인 리스크 요인이라 말한다면 특별히 할 말은 없습니다만.

아직 준비 중인 기능들도 더러 있어 보입니다. 데이터 모델에서는 Activity나 Event 등이 그렇고, Parse와 비교하면 사용자(개발자)가 직접 애플리케이션 로직을 추가할 수 있는 Cloud Code 같은 부분도 필요할 것입니다. 이런 좋은 서비스가 무럭무럭 자라 오래오래 만수무강하길 바랄 뿐.

워드프레스 웹사이트 제작 가이드

2012-08-13T00:00:00+00:00

워드프레스 기반의 웹사이트를 만들 때 필요한 프로세스와 방법들을 간단하게 STEP BY STEP으로 정리한 자료입니다.

워드프레스 웹사이트 제작 가이드 from Sukjoon Kim

워드프레스로 웹사이트 만들기

2012-03-17T00:00:00+00:00

워드프레스 웹사이트에 관한 더 많은 정보들은 WordPress 가이드를 참고 바랍니다.

워드프레스의 인기가 높다. 그래서인지 요즘은 국내에서도 워드프레스를 이용하여 웹사이트를 구축하려는 시도들이 늘고 있다. 그런데 워드프레스는 원래 블로깅 도구로 출발한 탓에 웹사이트와 어울리는 디자인을 만들려면 조금 “손질”이 필요하다. 워드프레스를 블로그로 사용하는 방법은 이미 널리 알려져 있기 때문에 여기서는 워드프레스를 이용하여 웹사이트(흔히 기업이나 단체에서 “홈페이지”라 부르는)를 만드는 법을 소개하려 한다.

우선 아래 웹사이트를 한번 보자. 이 사이트는 Building a Website with WordPress라는 사이트인데, 워드프레스로 만들었지만 보기에 통상적인 블로그 처럼 보이진 않는다. 워드프레스를 콘텐츠 관리 시스템(CMS) 내지는 그야말로 “정적인 웹사이트(static website)” 만드는 용도로 사용하고 있기 때문이다.

웹사이트 모드로 변신!

이렇게 워드프레스를 웹사이트로 사용하기 위해서는 몇 가지 기본적인 설정을 해 주어야 한다. 워드프레스가 설치된 상태에서 관리자 페이지의 Settings > Reading 메뉴로 가면 다음과 같이 프론트 페이지 표시를 어떻게 할건지 하는 부분이 나온다.

기본값은 최근 포스트들을 나열하는 방식으로 설정되어 있는데, 블로그라면 이 방식이 적합하다. 그렇지만 웹사이트로 만든다고 하면 정적 페이지(static page)로 설정해 주어야 한다. 옵션 값을 변경하고 프론트 페이지(Front Page) 선택하는 부분에서 Sample Page를 선택한 다음 저장하면 이제 워드프레스가 “블로그 모드”에서 “웹사이트 모드”로 변경된다(일부 테마는 테마 자체에서 이 기능을 활성화시키기도 한다). 참고로 여기 Sample Page는 워드프레스가 그야말로 샘플로 넣어 둔 테스트용 페이지로, 나중에 다른 것으로 바꿀 것이다.

테마 선택하기

워드프레스의 힘은 테마에서 나온다. 어떤 테마를 선택하냐에 따라 워드프레스는 각양각색의 모양새를 만들어 내기 때문이다. 따라서 웹사이트의 용도에 맞는(또는 고객의 요구사항에 부합하는) 적합한 테마를 선택하는 것이 중요하다. 테마는 WordPress Themes에서 무료 테마를 검색해도 좋고 themeforest나 StudioPress 같은 유료 테마 사이트를 이용해도 된다. 여기서는 워드프레스의 2010년 기본 테마인 Twenty Ten을 사용하기로 하겠다.

테마를 활성(activate) 시키면 다음과 같은 프론트 페이지가 보일 것이다.

포스트 vs. 페이지

워드프레스에서 만들어 낼 수 있는 콘텐츠에는 여러 가지가 있지만 크게는 포스트(post)와 페이지(page)로 나눌 수 있다. 포스트는 ‘블로그 포스트’ 처럼 말 그대로 계속 새로운 내용으로 채워 나가는 콘텐츠를 만들 때 사용하는 반면, 페이지는 한번 만들어 두면 잘 변하지 않는 콘텐츠에 주로 사용한다. 웹사이트에서 흔히 볼 수 있는 회사소개 페이지나 컨택 페이지 같은 “페이지”들이 바로 워드프레스에서 말하는 그 “페이지”다. 블로그에서는 주로 “포스트”가 중심이 되지만, 정적인 콘텐츠들이 많은 웹사이트에서는 페이지의 비중이 높아진다. 페이지를 만들고 페이지를 커스터마이징 해야 할 일이 많아진다는 말이다.

우선 앞서 임시로 연결해 둔 프론트 페이지 대신 새 페이지를 하나 만들어 보자. 페이지는 워드프레스 관리자로 가서 새 페이지 추가하기를 하면 추가할 수 있다. 여기서는 간단하게 페이지 제목을 “Welcome” 이라 두고 내용에 “환영합니다” 라고 한 줄 적었다.

이제 관리자 대시보드의 Settings > Reading 에서 앞서와 같이 프론트 페이지를 방금 전 작성한 Welcome 페이지로 변경해 보자. 그러면 사이트의 메인 페이지가 변경된 것을 확인할 수 있을 것이다. 또한 이전에 있던 Sample Page가 메인 페이지의 메뉴 항목에 새로 추가되어 있는 것도 알 수 있을 것이다. 워드프레스 기반 웹사이트에서 페이지들은 기본적으로 이렇게 메뉴 항목에 추가된다.

또한 워드프레스는 유연한 페이지 템플릿 기능을 제공하기 때문에 원한다면 각각의 페이지마다 다른 페이지 템플릿을 만들어 적용할 수 있다는 점도 참고하면 좋을 것이다.

‘새소식’ 페이지 추가하기

아무리 페이지 중심의 정적인 웹사이트라고는 해도 포스트가 없다면 방문자들에게 별 재미가 없을 것이다. 매번 똑같은 페이지만 보일 바에야 굳이 워드프레스를 사용할 이유가 어디 있을까. 메인 메뉴에 “새소식” 메뉴를 하나 추가하고 이 곳에는 새로운 포스트들이 올라오게 해보자. “새소식”이라는 제목으로 새 페이지를 하나 만들자. 이 때 내용에는 아무 것도 쓰지 말고 그냥 빈 채로 둔다.

이제 관리자 대시보드로 가서 Settings > Reading의 프론트 페이지 표시 부분에서 지금까지 비워두었던 두 번째 Posts Page 부분을 방금 만든 빈 “새소식” 페이지로 설정하자. 그런 다음 저장하고 다시 메인 페이지로 와서 보면 “새소식” 메뉴가 추가된 것을 알 수 있다. 이 메뉴를 클릭하면 콘텐츠들이 보일 것이다. 바로 우리가 작성한/그리고 앞으로 계속해서 작성해 올리게 될 새소식 “포스트” 들이다.

‘블로그’ 흔적 지우기

그런데 여기 한 가지 문제가 있다. 원래 워드프레스의 많은 부분이 블로그를 전제로 구성되어 있는 탓에, 워드프레스를 웹사이트 모드로 전환하면 여기저기 조금 어색한 부분들이 생기게 된다. 예를 들어 앞서 만든 메인 페이지에 댓글은 굳이 필요가 없다. 마찬가지로 컨택 페이지나 회사소개 페이지 같은 곳에서도 굳이 댓글을 달게 할 필요는 없을 것이다.

이 때는 테마를 수정해 주면 된다. 알다시피 워드프레스 테마는 여러 개의 테마 파일들로 구성되는데, 그 중 페이지 처리를 담당하는 테마 파일이 페이지 템플릿(page.php) 이다. 이 템플릿 파일을 열어 그 속에 있는 댓글 출력과 관련된 코드를 제거해 주면 이제 페이지에서 댓글이 사라진다. 이 때 테마를 수정하는 방법으로는 테마 자체를 직접 수정해도 되지만, 자식테마를 사용하여 관리하는 것도 좋은 방법이다. 참고로, 지금 사용하고 있는 TwentyTen 테마의 경우 loop-page.php 파일을 열어 그 속에서 comments_template() 함수 호출 부분을 제거해 주면 된다.

이 밖에도 처리해야 할 일들이 많이 있다. 예를 들면, 워드프레스의 기본 기능인 카테고리(category)나 태그(tag) 기능도 조금 더 웹사이트에 맞춰 변경해 주어야 하고, 페이지의 URL 들도 웹사이트에 맞게 조정해 주는 것이 좋다. 관리자용 대시보드의 경우도 불필요한 것들은 제거해 주어서 글을 작성하는 사람들이 조금 더 편하게 입력할 수 있게 해 주는 것이 좋고, 필요한 위젯이나 플러그인들도 설치해 주어야 한다. 참고자료에 몇 가지 도움이 되는 플러그인들을 소개하였으니 참고하면 좋을 것이다.

다른 방법들

지금까지는 워드프레스의 페이지 기능을 사용하여 정적인 웹사이트를 만드는 법을 알아 보았다. 그렇지만 워드프레스에서 웹사이트를 만들 때 꼭 이 방법만을 사용해야 하는 건 아니다. 앞서는 워드프레스에서 기본으로 제공하는 프론트페이지 설정 기능을 이용하였지만, 이 밖에 index.php 템플릿 파일을 직접 수정(권장하진 않는다)하거나 홈페이지용 템플릿인 home.php 파일을 추가하는 방식으로도 가능하다.

또한 경우에 따라서는 기존 블로그 스타일을 유지하면서도 얼마든지 웹사이트 “스럽게” 보이는 사이트를 만들 수도 있다. 그 대표적인 방법이 매거진(magazine) 스타일의 테마와 같은, 적합한 용도의 테마를 사용하는 것이다. 아래는 상용 워드프레스 테마 중 하나인 PageLines의 데모 화면들인데, 보다시피 블로그라기 보다는 훨씬 더 웹사이트에 가까워 보인다.

이상으로 워드프레스를 웹사이트 용도도 사용하는 방법을 간단하게 소개했다. 지금까지 살펴 본 것만으로도 워드프레스가 얼마나 자유롭게 변형이 가능한 강력한 도구인지 가늠이 되었을 것이다. 그렇지만 이게 전부가 아니다. 차라리 맛보기 정도라고 불러야 맞을 것이다. 이 밖에도 워드프레스를 용도에 맞게 변경해서 사용할 수 있는 방법들은 헤아릴 수 없을 정도로 많다. 한마디로 “Sky is the limit” 이다.

참고자료

참고문서

웹사이트 만들 때 사용하기 좋은 테마들

Genesis Framework
PageLines
Thematic
기타 각종 유/무료 테마들은 구글 등 검색엔진에서 “wordpress magazine theme“이나 “wordpress website theme” 등의 검색어로 검색하면 쉽게 찾을 수 있다

웹사이트에서 사용하면 좋을 유용한 플러그인들

WP-CMS Post Control 관리자 페이지를 CMS 용도에 맞게 수정
My Page Order 드래그드롭 방식으로 페이지 정렬
Fold Page List 중첩 페이지 목록 표시
Page Links To 워드프레스 페이지에서 외부 URL 링크
PageMash 드래그드롭으로 페이지 구조 관리
Flutter 커스텀 페이지 패널 작성
Pods CMS 범용 워드프레스 CMS 확장
Rich Text Widget 위젯에 리치 텍스트 추가
Exec-PHP 페이지나 포스트 속에서 php 코드 사용

자식테마를 이용한 워드프레스 테마 관리하기

2012-03-09T00:00:00+00:00

워드프레스를 사용하다보면 테마(theme)를 수정해야 할 일들이 종종 생기게 된다. 이 때 워드프레스 테마를 수정할 수 있는 방법은 크게 두 가지인데, 하나는 직접 테마 자체를 수정하는 것이고 나머지 하나는 바로 지금 소개할 자식테마(child theme)를 만들어 사용하는 것이다. 자식 테마는 다른 테마의 기능을 상속(inherit)받아 새로운 테마를 만들고 그 위에 필요한 기능만 덧붙이는 것으로, 이 때 상속받는 대상을 부모테마(parent theme)라 부른다. 마치 실세계에서 자식이 부모의 유전자를 상속받는 것이나 객체지향 프로그래밍에서 자식객체가 부모객체를 상속받는 것과 유사한 개념으로 워드프레스 2.7부터 새로 도입되었다.

자식테마를 만들어 사용하는 것은 테마의 호환성 관리 차원에서도 좋은 선택이다. 예를 들어, 내가 어떤 테마를 수정해서 쓰고 있는데, 그 테마가 어느날 업데이트되었다고 하자. 그러면 내가 지금껏 직접 테마에 가했던 변경사항들을 고스란히 다시 새 테마에 반영해 주어야 하는 문제가 생긴다. 혹은 지금 쓰고 있던 테마가 구닥다리라서 새로운 테마로 갈아타려고 할 때에에도 기존에 테마에 가했던 이런저런 여러 가지 변경들 때문에 발목이 잡히기 일쑤다. 자식테마를 사용하면 이런 “과거의 미련”으로부터 자유로울 수 있다.

부모테마 고르기

그럼 자식테마를 한번 만들어보기로 하자. 어렵지 않다. 우선 부모가 될 테마를 하나 선택해야 한다. 어떤 테마든 부모테마가 될 수 있지만, 가급적 워드프레스의 새로운 버전의 기능들이 잘 반영된 테마를 부모테마로 삼는 게 좋다.

그런 테마에는 어떤 것들이 있을까? 몇 가지만 추려보면 다음과 같다. 그 밖에 더 많은 테마들은 구글에서 ‘wordpress theme framework’로 검색해 보면 쉽게 찾을 수 있을 것이다. (테마 프레임워크는 자식테마와는 조금 다른 개념이지만, 테마 프레임워크를 부모테마로 사용해도 나쁠 건 없다)

Twenty Eleven 워드프레스 3.0의 디폴트 테마
Notes Blog Core Smashing WordPress로 유명한 Notes Blog에서 사용하는 테마
Thematic 인기있는 테마 프레임워크

여기서는 Notes Blog Core 테마를 사용하기로 한다. 자식테마를 만들기 위해서는 먼저 부모테마가 설치되어 있어야 하니 설치가 안되어 있다면 설치하고 다음으로 넘어가자.

자식테마 만들기

자식테마를 만드는 일은 간단하다. 워드프레스의 테마 디렉터리(wp-content/themes/) 아래에 적당한 이름으로 테마 폴더를 하나 생성해 주고 그 속에 style.css 파일만 하나 만들어 주면 끝이다. 그리고 style.css 맨 위에 다음과 같은 주석으로 이 테마가 Notes Blog Core 테마를 부모테마로 하는 자식테마임을 선언해 주면 된다. Template 란에 부모테마의 디렉터리명을 적어주는 것이 중요하다.

/*
Theme Name: 자식 테마 이름
Theme URI: http://your-theme-homepage.com
Description: 뭐든 테마를 기술할 수 있는 말을 적으세요!
Author: 누구?
Author URI: http://your-website.com
Template: notes-blog-core-theme
Version: A version number
.
기타 일반적인 정보들. 예를 들면, 라이선스 정보라든가 플러그인 요구사항, 호환성 정보, 기타 사용자들과 나누고픈 내용들
.
*/

이제 워드프레스 대시보드로 가서 방금 전 만든 테마로 변경하자. 처음 만들어진 자식테마는 물론 아직 부모테마와 똑같은 모양이 아닐 것이다. 부모테마로부터 모든 기능을 물러 받았지만, 외모(look & feel) 부분은 아직 물러받지 못했기 때문이다.

테마 변경하기

그럼 이제 style.css에 몇 가지 변경을 가해 보자. 우선 부모테마의 스타일부터 상속받자. style.css 에 다음 한 줄을 추가하고 나면 이제 부모테마와 똑같아 졌을 것이다.

@import url("../notes-blog-core-theme/style.css");

부모에 의존하는 것은 여기까지가 끝이다. 이제부터는 자신만의 길을 가야한다. 지금부터 style.css에 추가하는 내용은 부모테마와 달라지는 부분이다. 예를 들어, 부모테마의 글꼴을 나눔고딕체로 변경하고 싶다면 다음과 같은 식으로 자식테마에서 변경해 주면 된다.

body {
	font-family: NamumGothic;
}

만약 style.css 외에 테마의 다른 부분을 변경하고 싶다면? 마찬가지다. 부모테마에 있는 테마 파일과 동일한 이름의 테마 파일을 자식테마 디렉터리에 만들어 두고 그 속에서 필요한 변경을 해 주면 된다. 예를 들어, 페이지 테마에 변경을 가하고 싶으면, 부모테마 디렉터리에 있는 page.php 파일을 자식테마 디렉터리에 복사하고 그 복사한 page.php 파일을 변경하면 된다. 언제나 자식테마가 우선이다. 워드프레스는 자식테마인 경우 자식테마의 디렉터리를 먼저 참조하고 없을 경우만 부모테마를 찾는다.

고려해야 할 점들

그렇지만 자식테마가 만병통치약은 아니다. 과다하게 자식테마를 사용하는 것은 결국 부모테마를 직접 고치는 것과 별반 다른 게 없다. 게다가 자식테마를 사용할 경우 워드프레스가 부모테마와 자식테마 간을 상호참조해야 하기 때문에 복잡도가 조금 더 높아지고 약간의 성능감소도 따르는 것이 사실이다. 그렇지만 부모테마를 그대로 쓰되 스타일링 부분만 변경하려 하거나 아니면 funtion.php를 수정하여 약간의 기능변경을 하려 하는 경우라면 자식테마는 좋은 솔루션이 될 수 있을 것이다.

자식테마와 관련해 더 자세한 내용은 아래 참고자료를 참고하자.

참고자료

git-scribe로 전자책 만들기

2012-02-17T00:00:00+00:00

요즘 전자책 시장이 다시 활기를 띠고 있는 듯한 느낌이다. 아마존이나 애플, 구글 등 세계적인 IT기업들이 전자책 시장에 뛰어들어 속속 멋진 제품들을 쏟아내고 있고, 국내에서도 여러 업체들이 전자책 단말기부터 전자책 유통 플랫폼, 전자책 콘텐츠에 이르는 여러 가지 아이디어와 상품들을 출시하고 있다.

게다가 아이패드나 갤럭시탭 등 스마트 기기의 보급과 정부의 디지털 교과서 정책 등이 맞물려 앞으로도 계속해서 전자책 시장은 그 규모가 커지리라는 사실을 누구나 예상할 수 있다. 특히 최근에는 애플이 iBooks Author라는 전자책 저작 도구를 만들어 무료로 배포함으로써 이제 명실공히 “누구든 책을 출간할 수 있는 시대”의 서막을 열었다. 물론 아직도 가야할 길은 멀지만 그렇다고 무작정 기다릴 수만은 없는 일.

이 글에서는 git-scribe라는 간단한 오픈소스 전자책 저작도구을 사용하여 전자책을 직접 한번 만들어 보기로 하겠다.

설치하기

git-scribe는 루비 젬이다. 따라서 당연히 루비가 설치되어 있어야 하며, 또한 git을 데이터 저장소로 사용하는 관계로 git도 설치되어 있어야한다. 이 두 프로그램은 많은 사용자들의 컴퓨터에 이미 설치되어 있는 경우가 많고 또 설치 방법도 비교적 간단하기 때문에 여기서 따로 설명은 생략한다. 이 밖에도 몇 가지 추가적인 라이브러리를 설치해야 하는데, 필요한 라이브러리들은 각각 다음과 같다.

asciidoc : 소스문서 작성을 위해 필요
xsltproc : 소스문서의 html 변환을 위해 필요
a2x : epub 파일 생성을 위해 필요
source-highlight : 소스코드 구문 강조(syntax highlight)를 위해 필요
fop : PDF 파일 생성을 위해 필요
kindlegen : mobi 파일 생성을 위해 필요

우선 터미널에서 아래 명령으로 이들 라이브러리가 설치되어 있는지 확인하자.

$ git scribe check asciidoc - ok xsltproc - ok a2x - ok highlighting - ok fop - ok

설치되어 있지 않다면 설치해야 한다. 맥을 사용하고 있고 Homebrew가 설치되어 있다면 다음과 같이 간단한 명령만으로 쉽게 설치할 수 있을 것이다.

$ brew install asciidoc source-highlight fop
$ brew install https://raw.github.com/adamv/homebrew-alt/master/non-free/kindlegen.rb

책 만들기

자, 이제 준비가 끝났으면 책을 한번 만들어 보기로 하자. 터미널을 열어 책을 쓸 디렉터리를 하나 만들자. 디렉터리명이 mybook이라면 다음과 같이 명령을 주면 된다.

$ git scribe init mybook

이제 mybook이라는 디렉터리가 생성되는데, 이 디렉터리에 들어가 보면 필요한 몇 개의 파일과 디렉터리들이 이미 만들어져 있음을 확인할 수 있을 것이다. 이것으로 끝이다. 이것으로 책을 쓸 모든 준비는 끝이 났다. 이제 책 “쓰는” 일만 남았다.

그렇다면 책은 어디에다 써야 할까? 디렉터리 구조를 들여다 보면 이미 book 이라는 이름의 디렉터리가 만들어져 있는 것을 확인할 수 있을 것이다. 이 디렉터리가 책을 담을 곳이다. 이 디렉터리 속에 보면 book.asc 라는 파일이 있는데 이 파일이 모든 책의 시작점이 된다. 마치 웹사이트에서 index.html 파일이 시작점이 되는 것과 마찬가지다.

파일을 열어보면 샘플로 작성된 문서가 있을테니 그 문서를 참조하여 글을 작성하면 될 것이다. 파일명에서 알 수 있듯 git-scribe는 AsciiDoc 이라는 문서 포맷을 사용한다. AsciiDoc 사용법은 AsciiDoc 홈페이지나 또는 AsciiDoc cheatsheet을 참고하면 된다.

전자책 파일로 변환하기

책을 다 만들었다면 이제 전자책으로 변환하는 일만 남았다. 역시 간단하다. 터미널에서 다음 명령만 주면 된다. (중괄호 속의 단어 중 필요한 것 하나만 선택하면 된다. 예를 들어, epub 포맷으로 만들고 싶다면 git scribe gen epub 와 같은 식으로 주면 된다는 말이다)

$ git scribe gen [site|html|pdf|epub|mobi|all]

이제 output 디렉터리를 열어보면 요청한 전자책 포맷대로 파일이 생성되어 있음을 확인할 수 있을 것이다.

전자책 출간을 축하드린다!

Facebook Page에 iFrame Tab 추가하기

2011-11-28T00:00:00+00:00

페이스북 사용자가 증가함에 따라 최근 기업들도 앞다퉈 페이스북Facebook 플랫폼을 기업의 마케팅 기반에 추가하는 사례가 늘어가고 있다. 페이스북 마케팅의 시작은 통상적으로 페이스북에 페이지를 만드는 것에서부터 출발하는 경우가 많은데, 페이스북 페이지를 운영하다 보면 페이스북에서 기본으로 제공하는 페이지 만으로는 필요한 니즈를 충족하지 못해 새로운 탭을 만들어야 하는 경우가 생기게 된다. 이 때 가장 간단한 방법은 시중에 나와 있는 페이스북 탭 애플리케이션들(유/무료)을 이용하는 것이지만, 경우에 따라서는 이런 솔루션들만으로 니즈를 충족시키지 못하는 경우도 있고, 또 간단한 페이지 탭인 경우는 굳이 솔루션의 도움을 받지 않아도 되는 경우도 생긴다.

여기서는 별도 솔루션을 사용하지 않고, 직접 만드는 방법을 소개한다. 기존 솔루션의 종류나 사용법에 대해서는 페이스북에서 “static html” 또는 “static iframe”으로 검색하면 자세한 목록을 얻을 수 있다.

1. 페이스북 앱 등록하기

페이스북 Page Tab도 일종의 페이스북 앱(App) 이기 때문에 아주 간단한 탭이라도 Facebook 개발자 사이트에 접속, 앱을 등록하는 절차를 거쳐야 한다. 만들려고 하는 것이 페이지 탭이기 때문에 페이지 탭 메뉴를 활성화시킨 다음, 탭과 연결할 사이트(통상적으로는 이벤트 페이지가 될 것이다)의 페이지 URL을 등록해 주면 된다. 이 때 유의해야 할 점은, 페이스북이 2011년 10월부터 모든 캔버스 앱(및 페이지 탭)에 대해 HTTPS를 적용함에 따라 반드시 https:// 로 시작하는 보안 URL을 등록해 줘야 한다는 점이다.

2. 콘텐츠 페이지 만들기

앱 등록을 하였으면 실제 페이지 탭 속에 들어갈 콘텐츠 페이지를 만들어야 한다. 콘텐츠 페이지는 사용자가 페이지에서 탭을 클릭할 경우 보여지는 페이지이며, 실제로는 페이스북 페이지 내에서 iframe으로 렌더링(rendering)되기 때문에, 어떠한 HTML페이지든 상관없이 가능하다. 다만 통상적으로 이 페이지에는 페이스북의 각종 플러그인들을 얹혀 사용하는 경우가 많기 때문에 간단한 템플릿을 하나 작성해 두고 재사용하면 편리하다. 다음은 페이스북 탭 페이지용으로 사용할 수 있는 간단한 HTML 파일 템플릿이다.

이 템플릿 파일을 앞서 앱 등록 시에 설정했던 페이지 탭 URL과 맞추어 주면 콘텐츠 페이지가 완성된다. 이 때 APP_ID를 앞서 등록한 페이스북 APP ID로 채우는 것을 잊지 말자. 만약 담벼락에 올리기나 댓글 처럼 추가 플러그인이 필요한 경우는 페이스북 플러그인 페이지에서 코드를 가져다 붙이면 된다.

3. 페이지에 탭 추가하기

마지막은 페이스북 페이지에 방금 제작한 탭을 추가하는 것이다. 앱 등록 페이지 좌측 하단에 있는 관련 링크 중에서 앱 페이지 보기를 클릭하면 방금 생성한 앱의 페이지가 표시되는데, 이 앱 페이지의 좌측에 있는 내 페이지에 추가 메뉴를 클릭하여 추가하고 싶은 페이지를 선택하면 해당 페이지에 방금 생성한 탭이 추가된 것을 확인할 수 있을 것이다.

Updated(2011/12/13) 최근 페이스북이 앱 페이지(앱 프로파일 페이지)를 없애기로 결정함에 따라 이제 신규로 생성하는 앱은 위와 같은 방식으로 페이지에 앱을 추가할 수 없게 되었다. 대신 페이스북에서는 다음과 같은 스크립트를 앱의 소스코드에 추가함으로써 “내 페이지에 추가하기” 기능을 쉽게 구현할 수 있도록 해 놓고 있다.

물론 직접 링크를 호출하는 방식으로도 가능하다. 브라우저의 URL 창에 다음 주소를 입력하면 예전과 같은 페이지에 추가하기 대화창이 나온다.

http://www.facebook.com/dialog/pagetab?app_id=YOUR_APP_ID&next=http://facebook.com

문서화되지 않은 방법: 또는 다음 URL을 호출하여도 탭 추가가 가능하다.

https://www.facebook.com/add.php?api_key=YOUR_APP_ID&pages

Updated(2012/03/16) 최근 페이스북이 앱페이지(앱 커뮤니티 페이지)의 관리자 메뉴 속에 앱을 페이지에 추가하기 메뉴를 추가했다. 앱페이지를 만들었다면 이 메뉴 기능을 이용해도 된다. 자세한 내용

참고자료

Introducing iframe Tabs for Pages (Facebook 개발자 블로그)
Page Tab Tutorial (Facebook 개발자 문서)
Add Page Tab Dialog (facebook 개발자 문서)

클라우드 기반에 Facebook App 호스팅하기

2011-11-23T00:00:00+00:00

최근 페이스북이 클라우드 플랫폼인 Heroku를 자사의 애플리케이션 배포 플랫폼에 추가함에 따라 이제 페이스북 개발자들은 별도의 호스팅 절차 없이도 간단하게 페이스북 앱( 웹사이트 방식이든 캔버스앱이든)을 개발할 수 있게 되었다.

물론 굳이 이런 밀겹합(deep integration) 방식을 사용하지 않더라도 페이스북 앱을 장착할 수 있는 다양한 클라우드 기반들이 이미 많이 존재한다. 클라우드 기반에서 페이스북 앱을 호스팅할 수 있는 몇 가지 방안을 소개한다.

Heroku에 호스팅하기

가장 간단한 방법은 페이스북 앱 등록 페이지에서 제공하는 클라우드 서비스를 이용하는 방법이다. 이 때 클라우드 서비스를 추가하면 실제로는 클라우드 기반 앱 플랫폼인 Heroku와 연동된다. Heroku는 이전에는 루비 기반 앱만 호스팅할 수 있었지만 최근 Java, PHP, Node.js 등 다양한 개발 언어를 지원하는 ‘Polyglot Platform‘으로 전환하였다.

Facebook 앱 등록 페이지에서 호스팅 서비스 추가를 클릭하면 다음과 같이 페이스북 앱 개발 시에 사용할 언어를 선택하는 옵션이 나오고 이 때 적절한 언어를 선택하고 나서 클릭하면 바로 디폴트 앱이 생성되는 것을 확인할 수 있다.

다음과 같이 디폴트 앱이 생성되어 브라우저에 보여진다.

이제 다시 페이스북 앱 등록 페이지로 와서 보면 페이스북 앱과 연동된 클라우드 서비스의 Hosting URL이 등록된 것을 확인할 수 있을 것이다. 물론 이 URL은 Heroku로 접속하여 변경할 수 있고, 기존에 Heroku에서 제공하는 다양한 부가서비스들도 동일하게 이용할 수 있다. 참고로 페이스북 앱 등록 페이지를 통해 설치되는 Heroku의 디폴트 앱에 대한 소스코드는 아래 github에서 확인할 수 있다.

아마존 웹서비스 클라우드(AWS cloud)에 호스팅하기

아마존 웹서비스 클라우드 환경에 Facebook 앱을 호스팅하는 방법은 여러 가지 있지만 가장 간단한 방법 중 하나는 아마존 웹서비스 중 하나인 AWS CloudFormation 서비스를 이용하는 것이다.

다음과 같이 AWS CloudFormation 관리 콘솔에서 Facebook 앱용 템플릿의 URL을 지정하면 바로 페이스북 앱을 생성할 수 있다. 이 때 Facebook AppId, Secret 정보와 AWS 계정 정보 등을 앱 실행에 필요한 정보들을 추가로 입력해 주어야 한다.

EC2 스택이 새로 생성되고 Facebook PHP SDK 등 관련된 파일이 셋팅되는 동안 잠시 기다리면 다음과 같이 설치가 완료되고 CREATE_COMPLETE 메시지가 출력된다. 이때 생성되는 SiteURL 값을 페이스북 앱 등록 페이지에서 설정해 주면 AWS와 Facebook 간의 연동이 완료된다.

이 때 사용된 페이스북 앱의 소스코드는 다음 URL에서 확인할 수 있다.

http://aws-facebook.s3.amazonaws.com/aws-facebook-php-v1.tar.gz

Google App Engine에 호스팅하기

Facebook 캔버스 앱이라고 해서 구글 앱 엔진에 앱을 호스팅하는데 달라지는 점은 전혀 없다. 통상적인 Google App Engine(GAE) 사용 절차에 따라 앱을 개발하여 배포하고 페이스북 개발자 페이지에서 앱 URL을 등록해 주면 된다. 다만 GAE가 현재 Python, Java, Go 언어만을 지원하기 때문에 PHP로 된 앱은 배포할 수 없다. 페이스북 개발자 문서에서 GAE에 Python 기반 Facebook Canvas App을 만드는 튜토리얼이 소개되어 있으니 자료로 참조하면 좋을 것이다.

참고자료

Play 프레임워크와 Heroku를 이용한 웹앱 개발

2011-11-17T00:00:00+00:00

최근 Java 기반 웹 프레임워크 중 하나인 Play!가 주목받고 있다. Java야 이미 오래 전부터 수많은 웹서비스와 엔터프라이즈 환경에서 검증된 웹 개발 언어로 그리고 주력 플랫폼으로 사용되고 있었기 때문에 다른 어떤 웹 개발 환경 보다도 다양하고 광범위한 기술 기반을 보유하고 있다. 이미 웹 개발과 관련한 많은 기술 표준들이 나와 있고 많은 훌륭한 웹 개발 프레임워크들이 존재하기 때문에 새로 무언가 필요할까 싶은 생각도 들지만, Play!를 접하고 나면 조금 다른 느낌이 든다. “아~ 자바로도 이런 게 가능하구나. 역시 언어 문제는 아니었군.” 하는 생각.

Play!의 특징을 몇 가지만 들어 보면 다음과 같다.

MVC 아키텍처를 채택
서블릿 컨테이너를 사용하지 않고 자체 서버로 직접 배포하는 방식을 취함 (container-less)
JBoss의 Netty 라이브러리를 사용, 비동기 방식으로 IO를 처리하여 서버의 성능을 높임 (nonb-locking I/O)
JUnit 기반 테스팅 프레임워크를 내장
JPA 기반 ORM

시작하기

이 밖에 더 자세한 내용은 아래 참고자료를 참고하기로 하고, 우선 간단하게 Play!를 시작해 보기로 하자. 설치는 파일을 다운로드하여 적당한 디렉터리에서 압축을 풀어주면 완료된다. (Mac OSX에서 Homebrew를 사용한다면 명령행에서 brew install 하면 된다).

$ play new myplay
$ cd myplay
$ play run

이제 브라우저에서 http://localhost:9000/ 으로 접속하면 이미 Play가 시작된 것을 확인할 수 있을 것이다.

MVC 디렉터리 구조

Play framework의 디렉터리 구조는 다음과 같다. app 디렉터리 아래에 각각 model, controller, view 디렉터리가 위치하고 conf에는 애플리케이션 설정 및 routes 설정 등 각종 설정파일이, lib에는 외부 jar 파일이 담기고, public은 자바스크립트나 스타일시트, 이미지 같은 정적인 파일들이 담기는 공간이다.

이 때, 예를 들어, app/models 디렉터리 속에 담긴 User.java는 다음과 같은 형태의 코드로 구성된다. 이 클래스는 User모델로서 데이터베이스의 User 테이블과 OR 맵핑된다. (참고로 개발환경에서 이 소스코드의 컴파일은 동적으로 처리되며 tmp/ 디렉터리 아래에 자동으로 생성된다는 점이 특이하다).

package models;
 
import java.util.*;
import javax.persistence.*;
 
import play.db.jpa.*;
 
@Entity
public class User extends Model {
 
    public String email;
    public String password;
    public String fullname;
    public boolean isAdmin;
    
    public User(String email, String password, String fullname) {
        this.email = email;
        this.password = password;
        this.fullname = fullname;
    }
 
}

배포하기

애플리케이션이 만들어 졌다면 배포해야 한다. Amazon EC2 기반의 앱 클라우드 플랫폼인 Heroku가 최근 Play framework을 지원하기 때문에 Heroku를 이용하면 간단히 배포할 수 있다. 소스 버전 관리는 git으로 한다는 가정 하에, 명령행에서 다음 명령으로 배포가 완료된다.

$ heroku create --stack ceder
$ git push heroku master
$ heroku open

참고자료

루비 기반 오픈소스 CMS 솔루션들

2011-10-31T00:00:00+00:00

요즘 웹사이트나 블로그 만드는 일은 더 이상 별로 어려운 작업이 아니다. 불과 몇 년 전만 하더라도 조금 근사한 수준의 사이트를 만들 경우 비싼 비용을 지불하고 또 전문 업체에 의뢰하는 경우가 많았지만 최근에는 굳이 그럴 필요가 많이 없어졌다. 이제 누구든 손쉽고 빠르게 자신의 웹사이트나 블로그를 만들고 지우고 할 수 있는 세상이 된 것이다.

이렇게 된 데에는 여러 이유가 있겠지만 그 중 쉽게 콘텐츠를 만들어 웹 상에 올릴 수 있게 도와주는 좋은 콘텐츠 관리 도구(Content Management System) 들이 많이 출시된 것도 직접적인 원인 중 하나일 것이다.

소스가 공개된 콘텐츠 관리 도구 중 대표적인 것으로는 WordPress, Drupal, XE, Zoomla 등이 있겠지만, 이들 도구/솔루션에 대해서는 이미 많은 곳에서 자세히 소개하고 있기에 여기서는 루비 기반의 오픈소스 CMS 도구를 몇 가지 소개해 본다.

Radiant

Radiant CMS는 루비 기반 CMS 중에서는 비교적 오랜 축에 속한다. 간단한 관리자 화면을 통해 페이지와 레이아웃을 관리할 수 있기 때문에 간단한 웹페이지나 사이트를 만드는데 좋다. 루비온레일스 프레임워크 기반으로 확장(extention) 시스템을 제공한다. 현재 버전은 0.9.0로 MIT 라이선스를 따른다.

RefineryCMS

Refinery CMS 역시 루비온레일스 프레임워크 기반에서 작동하며 주로 루비온레일스 기반 애플리케이션에 CMS 기능을 추가하는 용도로 사용하기 쉽게 설계되었다. 콘텐츠는 WYSIWYG 에디터를 통해 쉽게 편집할 수 있게 되어 있으며 간단한 관리자 UI를 제공한다. “Engine” 이라는 이름의 확장 플러그인 기반에서는 제법 많은 확장 모듈들을 제공하고 있다. 현재 버전은 1.0.8이며 MIT 라이선스를 따른다.

Locomotive

Locomotive 역시 루비온레일스 기반의 오픈소스 CMS 솔루션이다. Locomotive는 하나의 CMS 속에 여러 개의 사이트를 호스팅할 수 있고 설계부터 Heroku나 Amazon S3를 호스팅 플랫폼으로 상정하고 개발되었기 때문에 클라우드 기반 CMS 호스팅이 필요한 경우에도 사용할 수 있을 것이다. 확장 모듈을 제공하며 MIT 라이선스를 따른다.

BrowserCMS

BrowserCMS는 단순히 CMS라기 보다는 루비온레일스 프레임워크의 CMS 확장이라고 보는 것이 좋겠다. 이 솔루션은 루비온레일스 기반에 엔터프라이즈 급의 CMS 기능들을 추가해 주기 때문에 루비온레일스 애플리케이션을 강력한 CMS 도구로 만들어 준다. 현재 버전은 3.3.2이며 GPLv3 라이선스를 따른다.

기타

그 밖에도 많은 루비 기반 CMS 솔루션들이 나와 있다.

Nesta는 정말이지 가벼운 CMS인데 다른 CMS 솔루션들처럼 데이터베이스를 저장소로 사용하지 않고 git 저장소를 CMS 저장소로 사용하는 Sinatra 기반의 앱이다.
Jekyll 역시 데이터베이스가 아닌 git 저장소 기반의 CMS 솔루션이며, 특히 Jekyll은 github page에서 사용할 수 있으며, 이 경우 github를 간단하게 자신의 웹사이트 또는 블로그로 만들 수 있다.

WordPress에서 Sass/Compass 사용하기

2011-07-28T00:00:00+00:00

이전에도 한번 소개한 것처럼 Sass와 Compass는 CSS 개발의 생산성을 높여주는 유용한 도구들이다. 부연하자면, Sass는 변수(variable), 믹스인(mixins) 같은 개념들을 통해 CSS를 모듈화시켜 코드의 재활용성을 높여주는 반면, Compass는 이런 Sass의 강력한 기능들을 플러그인 형태의 확장 구조로 다시 한번 추상화 시킴으로써 HTML5/CSS3 같은 복잡한 최신 CSS 개발 환경에서도 쉽고 일관되게 CSS 개발을 가능하게 도와주는 강력한 개발 도구(authoring framework) 인 셈이다.

Sass와 Compass는 주로 루비/레일스 커뮤니티에서 공유되고 사용되는 것으로 알려져 있지만 반드시 루비 환경에서만 동작하는 건 아니다. 실은 특정 개발 환경에 중립적이기 때문에 오히려 루비가 아닌 다른 환경에서도 그 진가를 발휘하는 좋은 CSS 개발 도구라 할 것이다. 예컨대 WordPress 의 테마(theme)를 개발할 때도 이 Sass/Compass 콤비네이션을 활용할 수 있다. 여기서 간단히 그 방법을 소개한다.

기본 전제

Sass/Compass는 이미 설치되었다고 가정한다. (설치에 관해서는 여기를 참조)
작업할 워드프레스 테마 디렉터리가 이미 만들어져 있다고 가정한다.

단계별 절차

워드프레스 테마의 루트 디렉터리에서 다음과 같은 compass 명령으로 설정파일을 하나 생성한다.

$ compass config --css-dir=.

디폴트로 이 파일은 config/compass.rb 로 생성되는데, 이 파일을 열어 보면 다음과 같이 기본적인 설정이 선언되어 있다. (물론 설정값은 프로젝트에 맞게 조정할 수 있다)

http_path = "/"
css_dir = "."
sass_dir = "sass"
images_dir = "images"
javascripts_dir = "javascripts"

이제 위의 설정에 맞게 테마 프로젝트의 디렉터리 경로들을 조정했다면 sass 디렉터리를 하나 주가하고, 그 속에 sass파일을 하나 만들자. 여기서는 style.scss 라고 하였고, 그 속에 다음과 같이 간단하게 몇 줄의 코드를 추가해 보았다. (참고로 여기 코드는 어디까지나 샘플이며, 실제 프로젝트에서는 조금 더 모듈화가 필요할 것이다. 자세한 내용은 Comass BestPractice 문서를 참조)

@import "compass";

#box {
  text-align: justify;
  background-color: #dedede;
  @include border-radius();
}

위의 코드를 간단하게 설명하자면, 우선 1행에서 compass 모듈을 로드한다. 이 모듈은 compass의 기본 모듈인데, 그 속에는 CSS3 처리나 타이포그래피(typography), 기타 각종 유틸리티 모듈들이 포함되어 있기 때문에 프로젝트에서는 별도의 CSS 코딩 없이 바로 이 모듈에서 미리 만들어 제공하고 있는 CSS 코드들을 활용할 수 있는 것이다. 예를 들어, 위의 sass 파일에서는 6행에서 ID가 #box인 DOM 문서 객체에 대해 border-radius() 라는 믹스인을 적용하고 있다. 이 단 한 줄의 코드 삽입만으로 모든 CSS3 지원 브라우저에서 호환되는 둥근모서리 스타일링이 간단하게 처리된다.

방금 전까지 작성한 파일은 CSS 가 아닌 sass/scss 파일이었다. 그렇다면 이제 이 파일을 브라우저가 인식할 수 있는 CSS로 컴파일하는 일만 남았다. compass에서 제공하는 다음 명령을 띄워 놓으면 sass 파일의 변경을 자동으로 감지하여 css 파일로 컴파일시켜준다.

$ compass watch

이제 브라우저에서 확인해 보면 방금전 우리가 만든 style.scss 파일이 컴파일 되어 자동으로 style.css 파일이 생성된 것을 확인할 수 있을 것이다. 나머지 작업들은 통상적인 워드프레스 테마 개발 과정을 따르면 된다.

참고자료

WordPress와 페이스북 OpenGraph 연동하기

2011-07-22T00:00:00+00:00

페이스북 OpenGraph 프로토콜은 웹 상의 콘텐츠를 페이스북 속 소셜 그래프(social graph)와 연결할 때 사용하는 일종의 메타 데이터(meta data)라고 할 수 있다. 이 프로토콜을 사용하게 되면 웹 상의 어떤 콘텐츠에 대한 메타 정보들, 예를 들면 제목이라든지 URL, 또는 썸네일 이미지나 설명 같은 것들을 그대로 페이스북으로 전달할 수가 있는데, 실제 이런 정보의 전달은 사용자가 웹 페이지에 있는 ""좋아요(Like)" 버튼을 클릭할 때 일어나게 된다. 이 때 페이스북은 전달받은 URL의 페이지를 읽어서 OpenGraph 프로토콜에 맞는 메타데이터 정보가 있는지를 검사하게 되고, 있을 경우 이들 정보를 사용자의 프로파일(담벼락) 등에서 표시할 때 사용하게 된다(그림1).

뿐만 아니라 이렇게 OpenGraph를 통해 연결된 웹사이트의 콘텐츠가 업데이트될 경우 그 업데이트 정보가 해당 콘텐츠를 좋아요(Like)한 사용자에게 곧바로 알려지기 때문에 마치 실시간으로 PUSH를 보내는 것과 같은 기능을 만들어 낼 수도 있다. OpenGraph 프로토콜에 대한 자세한 내용은 페이스북 개발자 문서를 참고하길 바라며, 이 글에서는 이런 페이스북 OpenGraph 프로토콜을 오픈소스 CMS툴인 워드프레스(WordPress)에서 사용하는 방법만 간단히 소개한다.

[그림1] OpenGraph 프로토콜 소개

워드프레스에서 OpenGraph 프로토콜을 사용하는 것은 다른 통상적인 웹사이트에서 OpenGraph를 사용하는 것과 전혀 다를 것이 없다. 통상적으로 어떤 웹사이트에 OpenGraph 프로토콜을 적용하려면 다음과 같은 절차를 거치게 된다.

웹페이지의 <head> 영역에 페이스북 OpenGraph에서 필요로 하는 일련의 메타 태그를 삽입한다. 이 때 각각의 페이지마다 달라지는 정보들(예: 제목, URL, 썸네일, 설명 등)은 그에 맞게 동적으로 처리해 준다.
페이스북에서 제공하는 Like 버튼과 같은 플러그인을 웹페이지에 추가한다.
페이스북 개발자 페이지에 들어가서 웹사이트를 등록하고 app_id를 받아서 앞서 OpenGraph 메타 태그에 적어 준다.

이렇게 해서 만들어진 통상적인 OpenGraph 태그의 구조는 아래와 같다. (자세한 설명은 페이스북 문서 참조)

워드프레스라서 달라지는 점이 있다면 이 메타 태그들을 워드프레스의 템플릿 페이지(통상적으로는 header.php) 에 삽입한다는 정도일 것이다.

참고자료

OpenGraph 프로토콜을 적용한 후에는 페이스북에서 제공하는 URL Lint 도구를 이용하여 페이지에 OpenGraph 프로토콜이 제대로 설정되었는지 확인하는 것이 좋다.
Like 버튼 플러그인을 직접 적용하지 않고 AddThis 같은 소셜 버튼 위젯과 함께 사용해도 무방하다.
워드프레스 플러그인 중에는 페이스북 OpenGraph 데이터를 직접 내장시켜 주는 여러 종류의 플러그인들이 이미 나와 있다. 이들 중 하나를 사용하면 위의 작업을 직접하는 수고를 덜 수 있어 편리하다. 그 중 Open Graph Pro를 추천함.

기업용으로 활용가능한 오픈소스 SNS 솔루션들

2011-06-21T00:00:00+00:00

트위터나 페이스북 같은 소셜 네트워킹 서비스의 인기와 효용성에 힘입어 기업에서도 이런 솔루션들을 도입하여 조직 내부에서 수평적이고 자유로운 커뮤니케이션 문화를 조성하고 보다 격의없고 창의성 있는 생각과 아이디어를 조직원들 간에 서로 공유하려는 움직임들이 생겨나고 있다. 해외에서는 이미 오래 전에 yammer 같은 기업용 SNS 서비스들이 출시되어 인기를 끌었고, 국내에서도 몇몇 업체들이 기업용 SNS 솔루션을 만들어 제공 중이다. 또한 작년부터 주로 대기업을 중심으로 하여 사내 SNS 서비스를 구축한 사례들이 등장하고 올해에는 공공기관에서도 이런 사내 SNS망을 구축하여 사용하는 움직임이 보인다. 기업 또는 조직 내에서 소셜 네트워킹을 구축하여 사내의 새로운 문화로 정착시키려는 움직임은 향후에도 계속 확산될 것으로 보인다.

기업용 SNS를 위해 가장 많이 사용하는 서비스는 아마도 야머(yammer)일 것이다. 알다시피 yammer는 이메일 주소를 식별코드로 사용하여 같은 이메일 도메인을 사용하는 사람들만의 네트워크를 형성해 주고 그 속에서 소셜 네트워킹을 할 수 있게 만들어주는 서비스이다. 국내에서도 이미 많은 기업과 공공기관에서 도입해서 사용 중인 서비스이기도 하다.

그런데 이런 "호스팅 방식"의 서비스에서는 종종 보안과 관련된 우려가 제기되곤 한다. 물론 yammer 같은 서비스는 이런 사용자들의 우려를 감안하여 보안에 많은 신경을 쓰고 있지만, 그래도 "DMZ" 안에서 돌아가는 것과 밖에서 돌아가는 것 간에는 최소한 사용자들이 인식하는 심리적인 안정감에서라도 차이가 날 수 있다. 그래서 이런 호스팅 방식의 서비스를 쓰는 기관들도 종종 보안을 위해 별도의 솔루션을 가져가기도 한다.

여기서 소개할 솔루션들은 이런 경우에 사용할 수 있는 오픈소스 SNS 솔루션들이다. 이미 검색엔진으로 검색해보면 헤아릴 수도 없을 만큼 많은 솔루션들이 시장에 출시되어 있고, 또 그 중에서 오픈소스 형태로 제공되는 솔루션들도 많은 것이 사실이다. 너무 많아 오히려 선택하기가 어려울 지경이라고 해야 할 것이다. 물론 "SNS" 라고 하는 것이 별로 "만들기 어려운" 솔루션도 아닌데다 사내 인트라넷 등 타 시스템과의 연동도 필요한 부분이 있고 또 조직 문화의 문제도 있는 탓에 직접 구축해서 사용하는 경우도 많겠지만, 지금 소개할 몇 가지 솔루션들도 기업용 SNS를 구축할 경우에 검토해 볼만 할 것이라 생각한다.

1. StatusNet

첫번째로 소개할 솔루션은 StatusNet이다. 이미 identi.ca 라는 서비스에서 실전 서비스를 하고 있고, 스마트폰과 데스크탑용 앱도 가지고 있는 이 SNS 솔루션은 oStatus라는 표준 스펙을 따르는 분산형 SNS(Federated SNS)이기도 하다. 트위터와 유사하 마이크로 블로깅(microblogging)을 기본으로 하지만 그룹을 생성할 수도 있고 메신저와의 연동도 가능한 장점이 있다. 분산형 SNS이기 때문에 여러 SNS 간에 서로 연결될 수도 있는 것도 장점이라 하겠다. PHP/MySQL 기반이며 현재 버전은 0.9.7로 곧 1.0 버전이 나올 예정인 이 솔루션은 AGPL 라이선스를 따른다.

2. Diaspora

다음으로 소개할 솔루션은 디아스포라(diaspora)라고 하는 SNS 솔루션이다. StatusNet과 마찬가지로 역시 분산형 SNS를 표방하는 이 솔루션은 얼마 전 페이스북의 창업자 마크 쥬커버그로부터 지원금을 받아 화제가 되기도 했던 솔루션인데, 작년 가을에 알파버전을 오픈하면서 서비스를 개시했다. 특히 이 솔루션은 애스팩(aspect) 이라는 그룹 기능을 두어 그룹 간에서만 서로 커뮤니케이션을 하는 방법을 지원하기 때문에 사내에서도 어느 정도의 프라이버시 수준을 유지할 수 있는 장점이 있다. Ruby on Rails 기반이며, AGPL 라이선스를 따른다.

3. 기타

기존의 인트라넷이나 사이트를 가지고 있는 조직에서 소셜 기능을 추가하고 싶다면 elgg 같은 SNS 엔진(engine)을 검토해 보는 것도 좋겠다. 페이스북 같은 플랫폼이 만들어진다.

버디프레스(BuddyPress)는 오픈소스 블로깅 솔루션인 워드프레스(WordPress)에 호감이 있는 조직이라면 관심을 가져볼만한 솔루션이다. 이 솔루션은 WordPress의 플러그인 형태로 제공되는 솔루션으로 워드프레스의 강력한 확장성을 잘 보여주는 솔루션이라 할 것이다.

마지막으로, Ruby on Rails 기반 솔루션을 두어 가지 소개하고 끝을 맺기로 한다. StatusNet과 같은 oStatus 프로토콜을 사용하면서도 RoR로 된 솔루션을 찾는다면 rStat.us 가 답이 될 수도 있다. 정확하게 SNS 만을 겨냥한 것은 아니지만, 작은 조직이나 팀 단위에서 프로젝트 관리도 하고 마이크로블로깅 기반 커뮤니케이션도 함께 할 수 있는 솔루션을 찾는다면 팀박스(Teambox)도 고려해 볼만 한다.

CSS 개발의 생산성을 높이는 도구들

2011-03-18T00:00:00+00:00

CSS는 웹사이트 디자인에 사용하는 도구다. 개념도 복잡하지 않고 문법도 간단하기 때문에 Box 모델이나 플로팅(floating) 같은 몇 가지 기본 개념만 익히고 나면 약간의 코딩 만으로 웹사이트에 멋진 비주얼 요소를 집어넣을 수가 있다. 그렇지만 매번 웹사이트를 만들 때마다 일일이 처음부터 CSS 작업을 하는 일은 경우에 따라서는 제법 성가시고 품이 많이 가는 일이기도 하다. 특히 IE의 비정상적인 작동을 바로잡기 위한 핵(Hack) 까지 고려한다면 더욱 그렇다. CSS 개발의 생산성을 높여주는 몇 가지 도구들에 대해 알아보자.

1. CSS 프레임워크

CSS 프레임워크(framework)는 미리 만들어 놓은 일종의 CSS 모듈이다. CSS 프레임워크를 사용하면 페이지의 기본 레이아웃에서부터 타이포그라피, 폼 디자인, 버튼 등 많은 부분의 디자인을 "날로 먹을 수"가 있다. 물론 모든 "프레임워크"가 그러하듯, CSS 프레임워크도 언제나 "최선"의 선택인 것은 아니며, 어떤 디자이너나 개발자들은 CSS 프레임워크 자체에 거부감을 가지기도 한다. 그렇지만 CSS 프레임워크가 개발 생산성을 높여줄 수 있다는 점에서는 이론의 여지가 없다. 그만큼 그 종류도 다양하기 때문에 오히려 어떤 것을 선택하느냐가 더 고민이 되는 경우가 많지만, 몇 가지 대표적인 것들만 소개하면 다음과 같다.

이들 중 대부분의 CSS 프레임워크는 소위 "그리드(grid) 디자인"에 기반하지만, 자바스크립트와 함께 사용하여 UI 효과를 내는 것들도 있고, 또 최근에는 HTML5/CSS3를 이용한 CSS 프레임워크들이 많이 등장하고 있다.

2. SASS와 LESS

SASS와 LESS는 일종의 CSS 전처리기(pre-processor)다. 조금 더 간단하고 구조화된 문법으로 코드를 작성하면 자동으로 CSS 파일을 생성해 주기 때문에 CSS 개발의 생산성을 폰이는 데에 꼭 필요한 도구이기도 하다. 특히 믹스인(Mixin)이라는 개념은 일종의 '모듈'을 만드는 것으로서, CSS 코드 재활용을 높이고 생산성을 높여주는 좋은 개념이다. SASS는 루비(ruby) 언어로 작성되었고, 그래서 주로 루비/레일스 프로젝트에서 많이 사용되지만 반드시 그래야 하는 건 아니다.

LESS(앞서 소개한 Less Framework과는 별개)도 SASS와 개념은 유사하지만, CSS파일의 생성이 자바스크립트 파서(parser)를 통해 클라이언트 측에서 이루어진다는 점에서, 서버측에서 컴파일이 이루어지는 SASS와 구별된다. 물론 LESS는 Node.js 환경에서도 작동한다. 이들 도구의 홈페이지는 각각 다음과 같다.

SASS http://sass-lang.com/
LESS http://lesscss.org/

3. Compass

마지막으로 소개할 도구는 일종의 CSS 개발 자동화 도구인 Compass다. 이 도구를 이용하면 앞서 소개한 CSS Framework를 명령행에서 바로 설치할 수도 있고, SASS 컴파일을 자동화 시킬 수도 있으며, 무엇보다도 SASS와 결합하여 CSS의 구성요소를 모듈단위로 쪼개서 SASS 모듈의 재활용성을 높이는 역할을 하는, 일종의 메타(meta) CSS 프레임워크라 할 수 있다. Compass의 사용법은 Compass 사이트에 자세히 소개되어 있으니 참조하면 된다.

루비/레일스 인증처리 라이브러리

2011-03-15T00:00:00+00:00

사용자 인증(Authentication)은 한마디로 사용자 본인이 맞는지를 확인하는 절차다. 웹의 경우, 상태를 유지하지 않는 HTTP 프토토콜의 특성에 기인하여 다양한 인증방식이 존재하지만, 우리가 통상적으로 사용하는 방식은 ID와 비밀번호를 입력하도록 하는 로그인 폼을 보이고 그 폼에 사용자 자신의 신원 정보를 채우도록 해서 인증을 처리하게 된다. 얼핏 간단해 보이는 처리이지만, 사실 웹 개발을 할 때에 이 인증만큼 다양한 '변종'이 존재하는 영역도 드물 것이다. 루비/레일스로 개발을 하는 경우도 마찬가지다. 한 가지 표준 라이브러리가 있어 "이것만 있으면 끝!" 해 버리면 좋겠지만 현실은 그렇지가 못하다. 아래에서 루비/레일스를 이용한 웹 개발에 있어 대표적으로 사용할 수 있는 몇 가지 인증 라이브러리를 소개한다.

restful-authentication 원래 authentication-fu 라는 이름으로 있다가, 레일스가 REST 기반으로 변경되면서 restful-authentication으로 업그레이드되었다. 가장 단순하면서도 커스터마이징에 너그러운 라이브러리로, 지금도 많이 쓰이고 있다.
clearance 재미있는 작품들을 많이 내기로 유명한 thoughtbot의 작품으로, 이메일과 비밀번호 인증만 필요한 경우라면 이보다 더 쉬울 순 없다.
authlogic 인증을 모델(model) 객체 수준으로 끌어올린 멋진 라이브러리이다. 다양한 설정 옵션을 지원하면서도 사용하기가 어렵지 않다.
devise 요즘 가장 "인기있는" 인증 라이브러리로 사용하기 쉽고 플러그인을 통한 확장이 용이하다. rack 기반 인증모듈인 warden에 기반한다.
omniauth intridea 에서 만든 이 작품은 영역이 조금 다르다. 통상적인 인증이 아닌 OpenID나 Twitter/Facebook 같은 소위 '서드파티3rd party' 인증을 처리한다.
socery 마지막으로 소개할 라이브러리는 신예다. 이전 라이브러리들의 장점을 모두 합했다고 하며 oauth 인증까지 지원한다. 아직 버전이 낮지만 완성도는 높다.

대부분의 오픈소스 영역이 그렇지만, 특히 루비/레일스가 재미있는 부분은 이렇게 서로 영감과 아이디어를 주고 받으면서 계속해서 새로운 제품들이 등장하고 또 등장하고 한다는 점이다. 내년 이 맘때는 또 어떤 라이브러리들이 어떤 아이디어를 갖고 나올지 기대되는 이유다.

참고자료:

http://ruby-toolbox.com/categories/rails_authentication.html

페이스북 소셜 앱 개발 가이드 자료

2011-03-10T00:00:00+00:00

2011.2.18 소셜 앱 개발 성공 전략 컨퍼런스 2011에서 발표한 "페이스북에서의 소셜 앱 개발 가이드" 발표자료를 공유합니다.

페이스북 소셜 앱 개발 가이드 2011 from Sukjoon Kim

OAuth 인증으로 다음 요즘 API 액세스하기

2011-03-09T00:00:00+00:00

최근 들어 국내에서도 오픈 API 접근 시에 인증 표준인 OAuth를 적용하는 서비스들이 하나 둘 생겨나고 있다. OAuth는 이미 Facebook이나 Twitter, Google, Yahoo 같은 글로벌 인터넷 서비스에서는 제법 오래 전부터 적용되어 오고 있었지만, 국내에서 OAuth 서비스 제공자를 찾기는 쉽지 않았는데, 이제 다음이나 네이트 같은 대형 포털 사이트에서 OAuth를 적용하기 시작한 것은 반가운 일이 아닐 수 없다. 다음(Daum)에서 제공하는 OAuth 서비스에 대해 간단히 알아보고 이를 이용하여 다음의 SNS 서비스인 요즘(yozm) API에 접근해 보자.

Daum은 OAuth 1.0을 지원하며 아래 URL로 접근 가능하다.

Request 토큰 URL: https://apis.daum.net/oauth/requestToken; request 토큰 요청시 oauth_callback 값이 컨슈머의Callback 경로와 동일해야 합니다.
사용자 인증 URL: https://apis.daum.net/oauth/authorize
Access 토큰 URL: https://apis.daum.net/oauth/accessToken
서명 메소드는 HMAC-SHA1만 지원됩니다.

OAuth dance

OAuth 인증 절차는 흔히 "OAuth dance"라고 부르는, 아래 그림과 같은 3단계의 인증 절차를 거친다.

* 출처: 다음 튜토리얼 자료

Yozm API 액세스하기

OAuth 인증을 거쳐 액세스 토큰(access token)을 획득했다면 이제 오픈 API에 접근할 수 있다. 예를 들어, 인증을 "수락"한 본인의 요즘(yozm) 개인 정보를 얻어오려면 다음 URL로 REST 호출하면 된다.

http://apis.daum.net/yozm/v1_0/user/show.xml

참고자료:

OAuth 소개 http://oauth.net/documentation/getting-started/
다음 OAuth 서비스 https://apis.daum.net/oauth/main/welcome
yozm 사용자 정보보기 http://dna.daum.net/apis/yozm/ShowUser

워드프레스 테마 커스터마이징: 두 가지 방법

2011-03-08T00:00:00+00:00

WordPress는 이미 블로깅(blogging) 도구라는 이미지에서 벗어나 멋진 CMS 플랫폼으로 자리매김한지 오래다. 그리고 이렇게 WordPress가 멋진 플랫폼으로 발전하게 된 데는 뭐니뭐니해도 유연한 확장성을 갖춘 테마(theme) 시스템이 큰 견인차 역할을 해 왔다. WordPress에서 테마를 변경하는데는 크게 두 가지 방법이 있다.

첫 번째 방법: 테마 템플릿 수정하기

첫 번째 방법은 테마 템플릿 파일 자체를 수정하는 것이다. 여기에는 기존의 다른 테마를 가져다가 수정하거나 아니면 아예 처음부터 새로 테마 시스템을 개발하는 것을 포함한다. WordPress의 테마 작성법에 대해서는 너무 많은 사용법과 문서들이 나와 있기 때문에 여기서는 따로 다루지 않기로 한다.

두 번째 방법: 테마 상속하기

워드프레스 2.7 버전부터 새로 도입된 이 방식은 말 그대로 어떤 테마를 상속하는 방법이다. 예를 들어, A라는 테마가 있다고 하면 이 테마를 그대로 사용하고 그 중 커스터마이징이 필요한 부분만 부분 수정하는 방식으로 테마를 변경하는 것이다. 이럴 경우 두 개의 테마 간에는 일종의 부모-자식 관계가 성립하며, 따라서 원래의 테마를 부모 테마(mother theme)라 부르고, 부모 테마로부터 상속받은 테마를 자식 테마(chile theme)라고 부른다.

자식 테마를 만드는 방법은 간단하다. 새로운 테마 디렉터리를 하나 생성한 다음 sytle.css 파일의 주석에 Theme 값으로 부모 테마 디렉터리의 이름을 지정해 주면 끝이다. 예를 들면 다음과 같다.

/*
Theme Name:     Twenty Ten Child
Theme URI:      http: //example.com/
Description:    Child theme for the Twenty Ten theme
Author:         Your name here
Author URI:     http: //example.com/about/
Template:       twentyten
Version:        0.1.0
*/

이제 이 테마는 고맙게도 부모 테마(여기서는 twentyten)의 모든 것을 물러 받는다. 그 다음 부터는 맘에 들지 않는 부분만 고치면 그만이다. 예를 들면, CSS 스타일의 일정 부분만 고칠 수도 있고, 부모 템플릿 파일 중 필요한 부분만 변경할 수도 있다.

둘 중 어느 방법을 사용하느냐는 물론 상황에 따라 다르다. 경우에 따라서는 아예 새로 테마를 작성하는 첫 번째 방식이 더 효과적일 때도 있다. 그렇지만, 메인 테마를 그대로 두고 필요한 부분만 개선하는 두 번째 방법은, 메인 테마를 계속 유지하면서 자식 테마만 조금씩 변경하면서 운영할 때 아주 효과적인 방법이다.

참고자료:

http://codex.wordpress.org/Child_Themes
메인 테마로 사용하기 좋은 Theme Framework
- Thematic, A WordPress Theme Framework
- Notes Blog Core Theme

톡팟tokpot 서비스 베타 오픈

2010-11-09T00:00:00+00:00

유스풀패러다임의 새 웹서비스인 톡팟tokpot 을 오픈하였습니다.

톡팟tokpot은 트위터twitter 기반 게시판 위젯widget 서비스입니다. 톡팟을 이용하면 여러분 사이트나 블로그에 간단하게 트위터 기반 게시판을 붙여 넣을 수 있습니다.

톡팟은 특히 이런 분들께 유용합니다.

나만의 브랜드를 가진 홈페이지나 블로그를 운영하면서 방문객들이 트위터로 이동하지 않고 내 사이트 내에서 소통을 이어가고자 할 때.
사업체 또는 공공단체, 학교 등 홈페이지 속에서 트위터로 대화를 주고 받고자 할 때.

아직 베타 버전이라 부족한 부분이 있지만, 사용자들의 피드백을 받아 꾸준히 업데이트해 나갈 계획입니다.

많은 관심과 격려 부탁 드립니다.

레일스3 환경에서 레일스2 애플리케이션 생성하기

2010-09-25T00:00:00+00:00

최근 레일스가 버전 3으로 업그레이드되면서 프레임워크 안팎으로 기존의 버전 업그레이드와는 차원이 다른 많은 변화가 생겼다. 레일스가 Merb와 합병한다는 소식을 공개한 것이 지난 2008년 말. 그 후로 약 2년간 거의 4,000회의 커밋과 250여 명의 커미터가 함께 한 ‘리팩터링 대장정’. 그래서인지 혹자는 이를 두고 마치 예전 마이크로소프트가 ASP에서 ASP.NET으로 갈아 탔을 때의 느낌을 연상하기도 하지만, 결과야 좀 더 두고 볼 일.

업그레이드에 따른 가장 큰 이슈는 물론 기존의 레일스 애플리케이션을 새 버전으로 업그레이드시키는 것이겠지만, 경우에 따라서는 이미 레일스3을 설치하고서 갑자기 이전 버전의 레일스 애플리케이션을 생성해야 할 경우도 생긴다. 문제는 레일스3에서는 애플리케이션 생성 명령이 변경되어 기존의 rails 명령이 그대로 작동하지 않는 것.

두 가지 방법이 있다.

방법 1 - RVM을 이용하는 방법

RVM을 사용 중이라면 간단하게 루비 VM을 전환하여 레일스 환경을 변경할 수 있다.

# 루비 1.9.2에서 레일스 3 사용하기
$ rvm install 1.9.2
$ rvm 1.9.2
$ rails new app-name

# 다시 이전 버전(레일스 2)으로 돌리기
$ rvm system
$ rails app-name

방법 2 - Bundler를 이용하는 방법

Bundler를 이용하면 굳이 RVM을 사용하지 않고도 간단하게 이전 버전의 레일스 애플리케이션을 생성할 수 있다.

1) 새 프로젝트 디렉터리를 만든다.

2) Gemfile을 만들고 다음과 같이 생성할 레일스 버전을 준다.

gem "rails", "2.3.8"
gem "sqlite3-ruby", :require => "sqlite3"

3) 다음 bundle 명령을 차례로 수행.

$ bundle install
$ bundle exec rails .

페이스북 앱 개발 가이드

2010-07-20T00:00:00+00:00

Facebook과 연동한 웹 개발 방식은 크게 두 종류로 나눌 수 있다. 하나는 기존의 웹 사이트와 페이스북을 연동하는 Facebook Connect 방식의 웹 개발이고, 다른 하나는 페이스북 페이지 내에 사이트를 내장시키는 Facebook Canvas App 방식이다. Facebook Canvas App은 다시 내장 방식으로 IFrame을 사용하냐 혹은 페이스북에서 제공하는 FBML을 사용하냐에 따라 IFrame Canvas와 FBML Canvas로 나눌 수도 있다.

Facebook은 잘 정리된 개발문서와 개발자 지원 페이지를 제공하고 있고, 또한 위에서 소개한 각각의 개발 방식에 맞춰 여러 종류의 개발 언어로 작성된 SDK를 제공하기 때문에 어떤 개발환경을 사용하든 손쉽게 페이북과 연동되는 웹 애플리케이션/서비스를 개발할 수 있다.

Facebook 개발자 페이지
Facebook 개발 문서
Facebook SDKs: JavaScript, PHP, Python, iPhone, Android, C#

Open Graph API와 OAuth

최근 페이스북은 기존의 REST 방식의 API를 버리고 Open Graph라는 오픈 프로토콜에 기반한 API로 서비스 접근 방식을 변경하였다. 또한 서비스 인증(authentication & authorization)도 오픈 표준인 OAuth2를 채용함으로써 이전보다 훨씬 표준적인 개발 방식으로 접근할 수 있는 길을 열어 놓고 있다.

특히 Facebook JavaScript SDK와 FBML의 클라이언트 확장인 XFBML을 이용하게 되면 기존의 Facebook Connect 이나 IFrame Canvas 방식의 Facebook App의 성능도 향상시킬 수 있게 되었다.

Facebook App 개발 절차

Facebook App의 개발 절차를 간략히 정리하면 아래 단계와 같다. 자세한 내용은 페이스북 개발문서를 참조.

Facebook 개발자 페이지에서 새 App을 추가한다.
Facebook JavaScript SDK를 페이지에 추가한다.
OAuth access_token으로 Graph API를 액세스한다.
FBML/XFBML, FQL을 적절히 이용한다.

루비/레일스와 Facebook App

아쉽게도 아직 페이스북에서 루비/레일스 개발자들을 위한 공식 SDK는 제공하지 않는다. 그렇지만 이미 루비 커뮤니티에서는 페이스북 개발을 지원하는 많은 라이브러리와 도구들이 나와 있다. 대표적인 것은 다음과 같다.

Facebooker: Rails 플러그인. 가장 오래되고 사용자 기반이 넓지만 Old REST 방식이며 다소 무겁다는 단점이 있다.
Facebooker2: 기존 Facebooker를 새 API에 맞게 리모델링한 것으로, Graph API 라이브러리인 mogli를 기반으로 한다.
sinbook: Sinatra 확장 라이브러리. 300줄 정도의 적은 코드로 되어 있으며, Old REST API 방식.
Koala: 새 API 기반이며 Connect과 App 개발 모드 모두를 지원한다. 주목할만한 신예 라이브러리.