워드프레스 블로그에서 사용자를 배려하기

 

△ photo by Heisenberg Media

이 글은 윤지만님이 작성한 독자를 위한 블로그 만들기 게시물을 참고해서 본인이 운영하는 워드프레스를 최적화 시도한 후기이자, 한국 사용자가 이용하기 편하게 워드프레스 블로그를 어떻게 만지면 좋을까 고민하는 사람을 위한 도움말입니다. 워드프레스 처음 설치를 이제 마친, 초보자 분에게 권합니다. 2014년 1월에 처음 작성했는데 2016년 11월에 고쳐 썼습니다.

워드프레스 블로그를 개설하신 분이라면, 포털의 블로그가 줄 수 없는 이 도구의 매력에 대해 생각해보셨겠지요. 그렇다면 블로그 설치를 마친 후 곧 이런 생각을 하게 됩니다.

“운영하는 입장 말고 사용자/방문자 입장에서 정말 쾌적하고 읽기 편한 블로그는 어떻게 만들어야 할까?”

1. 호스팅: 국내 호스팅인가 해외 호스팅인가?

목차

저는 2013년 봄에 티스토리에서 짐을 싸서 워드프레스 설치형으로 이사했는데요. 처음엔 무제한 하드 용량 + 무제한 트래픽의 매력 때문에 블루호스트(Bluehost) 등의 해외 호스팅을 공략했습니다. 검색해보시면 아시겠지만 가격 대비 혜택이 엄청나 보입니다.

그러나 일단 한 달에 4달러 정도라고 생각한 비용은 최초 계약 2–3년 후에는 6–7천원으로 올려받는 곳이 대부분입니다. 또한 꽤 덩치가 크다고 할 수 있어서 회사가 망하거나 할 염려는 없으나, 이용자 입장에서 속도와 안정성이 상당히 떨어지더군요. 서버가 미국에 있어서이기도 하지만 이런 값싼 쉐어드 호스팅이 다 그렇습니다. 화장실 복도에 있는 고시원이랄까요.

최근에는 요즘 뜨고 있는 속도나 기능으로 매력적인 디지털오션 VPS 서비스를 도전해보았죠. 디지털오션 VPS 서버에 워드프레스 블로그 여러 개 설치 사용기를 참고하세요.

결론부터 말하자면, 이 옵션도 결국 버린 상태입니다. 1) 간단한 블로그 하나 굴리기에는 신경쓸 게 꽤 많고, 비용도 결코 저렴하지는 않아서였어요. 지금은 결국 초보 블로거의 처음 마음으로 돌아와 다시 국내 cafe24 호스팅을 이용하고 있네요.

Cafe24의 10Gbps급 광속 호스팅이라고 선전하는 서비스를 이용하고 있는데, 꽤 안정적입니다. 홈페이지 관리자 페이지 디자인이나 마음에 안 드는 것도 많지만요. 기존 해외 서비스 사용하면서 있었던 접속 속도 문제나, 블로그가 간헐적으로 접속되지 않는다든가 등등의 문제가 모두 해결되었고, 문제 발생 때 영어로 관리자와 채팅하려고 기다리거나, 포럼 뒤지는 일 없이 바로 전화하면 되니까 편해요. 제 블로그는 평균 하루에 500명도 방문하지 않는데, 이미지는 플리커/구글앨범에서 링크 걸거나 호스팅 서버에 있는 이미지도 젯팩의 포톤 기능을 통해 트래픽 부담을 줄이고 있어서 현재 한 달에 1,100원 내고 “일반형”(900MB하드/800MB트래픽/DB무제한) 서비스 쓰고 있는데도 자원이 넉넉히 남습니다.

결론: 해외 호스팅이 싸고 좋다는 이야기를 들었다면 다시 고민해보라. 국내 대비 싸지 않으며, 실제 용량과 속도를 국내 수준으로 보장하는 경우 해외 VPS 서비스/단독 호스팅을 써야 하는데 반드시 비용/관리 측면에서 본인이 감당할 수 있는지 고민 후에 시도하는 게 좋다. 신경쓰기 싫고 블로그 운영에만 전념하고 싶으면 국내 호스팅이 가장 스트레스가 적으며 값싸게 운영 가능하다.

2. 폰트 고민 : 나눔고딕인가 기본폰트인가?

컴퓨터 폰트 vs. 웹폰트?

다음으로 한글 이용자를 위해 폰트 지정에 신경써야 할 거 같습니다. 워드프레스 블로거들은 크게 1) 방문자가 자기 컴퓨터의 기본 폰트를 사용하도록 그대로 두거나, 2) 인터넷으로 즉시 ‘나눔고딕’ 같은 예쁜 폰트를 다운로드해서 화면 보기에 강제로 적용하도록 하고 있어요. 각각 장단점이 있습니다.

블로그 글꼴을 그냥 “돋움“이나 “굴림“으로 설정하면, 글만 있는 게시물/페이지 로딩이 매우 빨라지고 따로 폰트 때문에 블로그 다른 부분 설정에 문제가 발생할 일도 거의 없지요. 브라우저나 운영체제에 따른 최적화 부담도 없거나 적습니다. 단점은 일단 안 예쁘죠. 그리고 10 명의 독자가 10 개의 모양으로 내 블로그를 읽고 있다는 경험이 과연 훌륭한 세팅인지 고민이 됩니다.

나눔폰트를 불러들여 사용하게 되면 윈도우 설치한 PC에서 가독성이 높아집니다. 일단 굵기를 조절해서 나눔폰트로 블로그 제목을 지정한 뒤에 인터넷 익스플로러 브라우저로 접속해서 보면 다시는 굴림으로 돌아가기 싫어집니다. 훨씬 보기 좋죠. 폰트의 굵기(font-weight)가 노말(normal)인 상태에서 돋움이나 굴림은 글자 자체가 너무 얇다고 해야 하나요? 고해상도 모니터에서 글자 크기를 키우더라도 뭔가 읽기에 편안한 중량감으로 본문에 뿌려지지 않는 느낌입니다. 예쁜 화면을 강요할 것인가? 고민이 되기 시작합니다. 사용자에게 요구하는 게 많아질수록 내 블로그의 소스는 어지러워지고 무거워집니다.

△ 왼쪽이 돋움 폰트, 오른쪽이 나눔폰트

사용자 컴퓨터의 폰트 사용

저는 칼킨님의 조언을 듣고 웹폰트 적용을 포기했었어요. 이용자가 선택할 수 있게 하자는 거였죠. 너는 꼭 이 폰트를 다운로드 받아서 내 블로그를 읽어야 해~ 라고 말하는 순간 사용자 입장에서는 내용으로 직행하기까지 거쳐야 할 단계가 하나 더 늘어납니다. 이것은 좋지 않고, 이용자를 배려하는 게 아니죠.

그래서 △ 컴퓨터에 나눔폰트가 깔려있는 사용자는 자기 컴퓨터의 나눔폰트를 사용하여 블로그 글을 읽도록 하고, △ 사용자가 자신의 컴퓨터에 나눔폰트를 설치해두지 않은 경우엔 돋움이나 굴림 등 기본 폰트로 사이트를 보도록 하는 겁니다. 미적인 일관성을 버리고, 사용자가 나눔폰트를 직접 구해서 설치해두고 살고 있을 정도로 폰트에 관심이 있는 사람이라면 기꺼이 나눔폰트로 블로그를 보여주고, 그게 아니라면 일반 포털 기사 읽을 때처럼 굴림이나 돋움체로 무난하게 내용을 전달하겠다는 전략입니다. 일종의 타협안인 셈인데, 적용한 후 시크릿모드로 블로그 접속해보니 최초 페이지 로딩이 더욱 빨라졌습니다. 쾌적함을 얻고, 아름다움을 버립니다.

이런 설정은 간단합니다. 한글로 “나눔고딕“과 영어로 “NanumGothic” 둘 다 우선순위에서 앞에 위치시켜서 컴퓨터에 있는 폰트를 놓치지 않도록 해주세요. 나눔고딕이 없으면 돋움 글꼴을 사용하도록 설정하면, 나눔폰트를 설치 안 한 사람만 돋움 폰트로 내 블로그 글을 읽습니다. 테마의 sytle.css 에서 기본폰트패밀리 설정하는 곳을 찾아서 수정해주시면 됩니다.

body, input, textarea, select, button, table {

    font-family: '나눔고딕', NanumGothic, '돋움',Dotum;

    font-size:14px;

}

아이폰/아이패드에서 폰트

보통 모바일의 경우 상세히 챙겨주지 않아도 됩니다. 요즘 스마트기기에서는 모바일 화면에서 읽기 좋은 폰트를 이미 채용하고 있기 때문에 가독성에 그리 문제가 없거든요.

나눔폰트 강제 적용

수 개월 전에 블로터닷넷(Bloter.net) 같은 곳에서도 나눔폰트를 강제 적용하기 시작하는 걸 보고 이제는 좀 적극적으로 강제해도 되지 않나 생각이 들더군요. (그러나 블로터 사이트도 폰트를 강제한 후 2014년 이런 적용방식이 없던 때와 비교해 속도와 쾌적함을 잃었습니다.)

그래도 못 견딜 정도는 아니더군요. 국내 사용자 기준으로 폰트 로딩을 강제해도 큰 무리는 없을 속도가 나온다, 혹은 어차피 사진 몇 장 다운받는다고 생각하면 이용자에게 크게 미안한 일은 아니라고 생각하시면 폰트도 연결해서 받아 읽도록 할 수 있습니다.

검색해보면 워드프레스에 구글폰트 적용하는 방법이 많이 나오는데, 폰트를 내 호스팅 서버에 통으로 올려두고 이용자가 그걸 사용하게 하면 매번 오는 사람마다 그걸 건네줘야 하니 부담스럽기 때문에 그렇게는 하지 마시고요. 기본적으로, 구글웹폰트 로더 자바스크립트 라이브러리를 방문자가 불러들이도록 하고, 이를 이용해서 구글 웹폰트에서 직접 제공하지 않는 ‘나눔바른고딕’ 등도 자유롭게 세팅해서 사용하는 방식이 널리 쓰입니다. 나눔바른고딕은 특히 모바일에서 한글을 읽기 좋게 뿌려주기 위해 개발되었다고 하죠. 블로터에서는 자체 서버에 .eot 올려두고 지금 사용중인데, 결국 모든 사용자가 폰트묶음을 내 블로그 서버에서 받아가는 방식이라 추천하지 않습니다. 개인적으로는 바른고딕보다 그냥 나눔고딕이 더 예쁘기도 하고요.

모든 사용자가 똑같이 예쁜 나눔고딕으로 내 블로그를 읽게 하려면 어떻게 하면 될까요?

나눔폰트/웹폰트 – 플러그인으로 적용하기

만약 초보이시면 그냥 플러그인을 사용하는 것도 방법입니다. 아주 쉽습니다. 괜히 테마 구성하는 파일을 건드리지 않아도 되고, 테마를 변경해도 다시 폰트 설정을 하나하나 수정하지 않아도 되니 편리합니다.

워드프레스 한글폰트 플러그인 설명을 참고해서, 서버업로드 방식을 피하면 블로터의 세팅과 유사하게 내 호스팅 부담 줄이면서 세팅이 가능합니다. 플러그인 다운로드 – 한글폰트 나눔고딕 – 구글 페이지를 참고하세요.

WP Google fonts – 구글 웹폰트 플러그인도 널리 쓰입니다. 소개하는 블로그 글을 참고하세요. 저도 꽤 오래 사용하고 있는 플러그인입니다. 상세 설정은 martian 36님의 포스트를 보세요.

결론적으로 플러그인 방식이란 게 별 거 없어요. 커스텀 CSS 영역에 아래와 같은 코드를 추가하는 방식입니다.

@import url("http://fonts.googleapis.com/earlyaccess/nanumgothic.css" ) ; body, h1, h2, h3, h4, h5, h6, li, p { font-family:"Nanum Gothic" !important ; }

나눔폰트/웹폰트 – 기존 테마 수정 직접하기

놀부님이 Use Web Font Loader 관련 설명한 글에서, “웹 폰트 로더는 사이트의 나머지가 로드되기 전에 로드하고, 스타일되지 않은 텍스트가 번쩍되는 것을 확실하게 피해준다.”고 하네요.

아래와 같이 구글에서 웹폰트 로더 자바스크립트 라이브러리를 로딩하도록 코드를 추가하고, 로드하고 싶은 폰트를 적어주면 됩니다. 보통 header.php 의 head 영역에 넣습니다.

<script src="//ajax.googleapis.com/ajax/libs/webfont/1.4.7/webfont.js"></script>
<script>
  WebFont.load({
    google: {
      families: ['Nanum Gothic', 'Nanum Myeongjo']
    }
  });
</script>

그 다음엔 일반적인 css 구문에서, 바로 호출하면 되고요.

font-family: 'Nanum Myeongjo', serif;

위와 같은 코드를 style.css에 직접 추가하거나, 원본을 보관해야 하는 경우를 생각해서 젯팩의 custom css 설정 칸 등에 입력해주면 됩니다. 테마에 따라서는 차일드 스타일시트를 제공하는 곳도 있고요.

결론: 웹폰트를 포기하면 사이트 이용자 입장에서 훨씬 쾌적하다. 하지만 인터넷 환경이 더욱 쾌적해지고 구글을 도움을 얻어 편리하게 적용할 수 있으므로 사용해보는 것도 좋다.

3. 블로그 댓글, 없앨까? 그냥 둘까? SNS 댓글 플러그인 사용할까?

댓글이 없는 블로그

Matt Gemmell는 댓글이 전혀 쓸모없다고 얘기합니다. 블로그에서 과감히 댓글 기능을 삭제하면 여러 장점이 생깁니다. △ 정말 하고 싶은 말이 있는 사람만 메일이나 기타 수단으로 연락을 하게 되므로 피드백의 빈도는 떨어지지만 질은 올라갑니다. △ 글을 작성하면서 타인을 덜 의식하게 되고 주제에 더 집중할 수 있게 됩니다.

원래 댓글 시스템

댓글이 아주 많은 것도 아니고 제가 쓴 글의 피드백 성격이라기보다는 추가 질문을 해당 포스트 아래에 이어서 받는 용도로 워드프레스에서 기본 제공되는 댓글 시스템을 그대로 사용하는 것도 좋습니다. 꼭 댓글이 필요하다면 말이죠.

SNS 댓글 시스템

따로 댓글 전문 플러그인을 달아주는 방식입니다. 게중에선 Disqus 좋습니다. 워드프레스와 통합하는 플러그인도 상당히 잘 작동하는 편입니다. 기존 워드프레스 댓글을 디스쿠스로 임포트하는 기능도 있고, 플러긴 설치 후 누군가 disqus로 댓글을 달면 워드프레스 내부 댓글 시스템으로 복사본을 밀어넣어주기도 하죠. 하지만 생각해보면 단지 이용자가 자신의 sns 계정으로 더 편하게 댓글을 달 수 있게 마당에 멍석 깔아주느라 블로거 입장에서는 일이 두 배가 됩니다. 무엇보다 댓글에 대한 답글을 워드프레스 앱에서 작성해도 디스쿠스로 밀어넣기가 자동으로 안 되는 문제로 .. 블로그에 댓글이 달리면 워드프레스 앱이 아니라 디스쿠스 앱이나 웹페이지 또는 이메일을 이용해야 하는 불편이 생기죠. 처음에 교통정리를 잘 해놓고 사용해야 엉키지 않습니다. 블로그의 소통 시스템과 SNS을 연계시키고 싶은 마음은 계속 들기는 하지만, 과연 이게 일을 더 만드는 건 아닌지 생각해본 후 시도해야 합니다.

그래도 저는 지금 Disqus를 사용하고 있는데요. 이유는, △ 해당 글에 대한 질문을 다시 이메일이나 트위터를 통해서 받는 것보다 스트링으로 게시물 아래 달아서 받는 방식은 논의가 어떻게 전개되는지 볼 수 있다는 점에서 여전히 유효하다. △ 디스쿠스는 새로운 댓글이 달리면 이메일을 보내주는데, 스마트폰에서 그 메일에 답장하는 것 만으로도 댓글에 대한 댓글을 달 수 있어서 관리하는 입장에서 크게 불편하지 않다. △ 블로그 포스트 자체와 분리하여 댓글 자체만으로도 하나의 컨텐츠가 될 수 있다는 생각을 하고 있어서 따로 플러그인을 사용하는 게 그다지 나빠 보이지 않는다.

스팸 관리

Akismet 설정은 반드시 해야 합니다. 네이버, 다음 티스토리의 지긋지긋한 스팸에 비하면 비교할 수 없을 정도로 매우 훌륭하게 차단해주고 있습니다. 또한 승인 후 댓글이 표시되는 설정이 승인 없이 바로 노출되는 설정보다 좋은 거 같습니다. sns처럼 긴급하게 메시지가 대화형으로 노출되야 할 필요는 거의 발생하지 않습니다.

결론: 댓글이 없으면 글쓰기에 집중할 수 있고 필요없는 에너지 소모를 줄일 수 있다. 그러나 내가 게시한 정보에 대한 추가 의견을 일관성 있게 축적하고 싶다면 댓글은 여전히 좋은 시스템이다.

4. 블로그 통계 도구는 뭘로?

운영자 입장에서는 이미 Jetpack 통계만으로도 충분한 통계 정보가 제공되고 있으니 활용하면 됩니다. 구글 분석도구를 이중으로 설치하면 더욱 자세한 통계를 얻을 수 있지만, 그럴 필요가 있는지 생각해보세요. 우리나라의 경우 카톡이나 네이버 밴드 등을 통해서도 많은 방문자가 발생하는데, 통계도구가 이를 잘 분석해주는 데 한계가 있어요. 따라서 참고할 수 있는 유사치 정보로 이해하는 게 좋겠습니다.

Jetpack, 구글분석도구

원래는 테마의 footer에 구글분석도구 코드를 삽입해서 블로그 자체 통계와 함께 이중으로 통계를 받아봤는데, 언제부턴가 Jetpack 통계 자체에서 제공하는 기능만으로 충분해서 구글분석도구는 사용하지 않게 되었습니다. 하루 방문자, 최근 방문자 동향, 리퍼러 정도를 자주 검토합니다. 사실 그냥 재미로 보는 거죠.. 원하면 Google Analytics for WordPress 플러그인 등을 활용해서 헤더에 추적코드를 삽입할 수 있고, Google Analytics Dashboard 플러그인으로 워드프레스 대시보드에서 Jetpack Stats와 함께 통계 정보가 표시되도록 설정 가능합니다. 하지만 전 … 지금은 젯팩만 씁니다.

통계정보 위젯

가끔 카운터, 또는 실시간 접속자 수를 사이드바 등에서 제시하는 블로그가 있는데 없는 게 좋다고 생각합니다. 우리나라는 홈페이지 붐 초기부터 방문자 자랑하는 게 유행처럼 되어 있었죠. 하지만 현재 어떤 한 개의 글을 읽으러 들어온 방문자에게 이 블로그가 오늘까지 몇 명이 방문한 유명 블로그인지 어필해야 하는 어떤 실용적 이유가 없습니다.

결론: 통계는 기본 Jetpack 도구로 충분하고, 원하면 구글분석도구를 사용할 수 있다. 하지만 방문자에게 통계정보를 여기저기에 자랑할 필요는 없다.

5. 글 분류: 카테고리인가 태그인가?

사실 글 작성하는 입장에서는 카테고리보다는 태그가 편하지만, 태그는 매번 태그 이름을 기억해서 타이핑해야 하기 때문에 내가 작성할 컨텐츠 분류 기준이 복잡하지 않다면 카테고리가 편합니다. 워드프레스는 카테고리도 복수로 설정이 가능하고, 카테고리명을 자유롭게 조합해서 새로운 메뉴 구성을 복수로 생성할 수 있기 때문에 카테고리 생성, 삭제에 따른 부담도 적습니다. 어떤 분은 글의 발행량이 매우 많고 주제가 너무나 광범위하거나 의식의 흐름에 따라? ㅋㅋ 글을 쓰게 되면서 태그 방식을 주력으로 사용하시죠.

태그를 주력으로 쓰면 우선 메뉴 구성 시 특정 카테고리가 메뉴 버튼 하나가 되도록 만들기는 쉽지만, 특정 태그를 메뉴로 삼고자 할 때에는 커스텀으로 링크를 만들어주어야 한다는 불편함이 있어요. 예를 들어 writemonkey 태그가 붙은 글을 메뉴바에 넣고 싶을 때에 http://seoulrain.net/?tag=writemonkey 같이 링크를 걸어주는 방식으로 만들어야 하죠.

또한 특정 카테고리를 묶어서 첫 화면에 예쁘게 뿌리거나 하는 테마에서 태그묶음은 따로 표시할 수 있도록 지원하지 않는 경우도 많으니 특별히 태그라는 이름에 집착할 필요가 없고 글 분류 기준 자체가 아주 복잡하지 않을 것으로 예상되면 카테고리를 적극적으로 사용하시는 걸 추천합니다.

사용자에게는 플러그인 등을 통해 Footer 등에 카테고리나 페이지를 재구성해서 메뉴판처럼 다시 제시할 수 있습니다. 또한 보통 글의 제목 아래에 카테고리나 태그가 표시되는데, 최소 1개에서 2개, 아무리 많아도 3개 이하로 제시하는 게 좋은 거 같습니다. 특히 6,7개의 태그 리스트를 줄줄이 달아서 표시하는 경우는 독자 입장에서는 혼란스러울 뿐입니다.

결론: 특정 주제를 수 회 이상 포스팅할 생각이면 카테고리로 과감히 배정해보기를. 메뉴 재구성에도 편리하고 활용상 유리한 측면이 많음. 그러나 글이 산발적이라면 태그도 괜찮음.

6. 미디어 관리

트래픽 부담을 줄이기 위해 저는 실제 본문에 삽입되는 고화질 이미지나 영상은 모두 플리커, 구글, 유튜브 등에서 링크합니다. Featured Image도 URL에서 끌어오거나 합니다.

마크다운 + 외부이미지/영상을 임베드하는 방식으로 원고를 작성하면 처음엔 좀 불편할 수 있어도 여러가지 장점이 많아요. 우선, 꼭 내 블로그가 아니라도 다른 커뮤니티나 사이트에 원고를 그대로 포스팅하기 좋죠. 또 호스팅 용량을 잡아먹지 않으니 좋고요.

젯팩의 Photon 기능도 강추입니다. 이 기능은 워드프레스 자체 업로드 이미지를 다른 서버에 복사해 올려두고 그 이미지로 방문자에게 서비스하여, 결과적으로 트래픽 할당량을 절약하게 해줍니다.

결론: Featured Image를 고화질로 사용하려면 내가 사용하는 호스팅의 용량/가격을 살펴볼 것. ShareX 등의 프로그램으로 외부에 미디어를 올려서 링크하는 방식으로 원고를 작성하면 여러모로 경제적인 운영이 가능. 젯팩의 Photon 확장기능은 강력 추천.

7. 워드프레스 테마 설치/관리

테마는 ThemeForest.net에서 몇 개 구매했네요. 지금까지 WordPress에서 ‘블로그’ 분류나 minimal한 디자인 위주로 검색하면서 골라서 몇 가지를 사용해보았네요. 다운로드할 때는 라이센스까지 포함된 오리지널 파일 모두를 다운로드해서 따로 백업해두시고, 실제 올릴 자료는 항상 서버의(wp-content/themes)와 동기화할 수 있도록 따로 마련하여 복사해두시는 게 좋습니다. 설치 초기에는 sytle.css 를 자주 수정하게 되기 때문이죠. 수정할 때는 Notepad++ 로 편집하고, FileZilla FTP로 올립니다. 기본 편집기로 지정하면 FTP만 실행 후 바로바로 편집하고 수정해서 업데이트할 수 있습니다.

처음에는 무료 테마를 구해서 사용하는 것도 좋지만, 사용하면서 흥미와 욕심이 생기면 근사한 유료 테마를 시도해보는 것도 괜찮습니다. 이미 국내에 있는 많은 워드프레스 기반 사이트들은 유료 테마를 개성있게 고쳐서 사용하고 있죠.

유의할 점은 1) 영어폰트로 멋있어 보이는 테마를 실제로 다운로드 받아 한글 폰트를 적용하면 무척 다른 느낌이 들 수 있으므로 유의해야 하고 2) 각종 슬라이더와 사이드바의 전용 위젯의 현란한 기능을 강조하는 테마가 많은데 기능에 혹하기보다는 전체 화면 배색과 구조가 효율적이고 내용 전달에 효과적으로 짜임새가 갖춰졌는지 살펴보시기를, 3) 또한 shortcode에 너무 혹하지 마시길. 어차피 테마 갈아타거나 나중에 플래폼 자체를 혹시나 갈아탈 경우에 문제 발생 소지가 있는 shortcode를 너무 남용하는 건 좋은 컨텐츠 관리 방식이 아닌 거 같습니다.

결론: 복잡하고 현란한 테마보다는 기본에 충실한 테마를 골라보자.

8. 위젯/사이드바는 필요한가?

현재는 거의 위젯을 쓰고 있지 않는데요… Matt Gemmell 또한 위젯, 사이드바에 강박적으로 혐오를 드러내며 다 치워버리라고 조언하더군요 ㅋ 저 또한 현란한 칼라로 여기저기 있는 위젯들이 싫어요. 내가 어떤 글을 읽기 시작했을 때에는 그 글의 내용만 보여야지 한참 스크롤을 내리고 있는데 계속 주의를 분산시키는 위젯이 화면 어딘가에 있는 건 사용자에 대한 테러라고도 할 수 있죠.

보통 유료 테마 중 많은 수가 상세한 설정 옵션 페이지를 따로 제공합니다. 로고 이미지 플리커에서 불러오기, 파비콘 설정 등등이 가능하고 피드버너 리다이렉팅 등도 가능하고요. 레이아웃 자체를 1단, 2단, 좌측 사이드바, 우측 사이드바 등등으로 제공하는 것도 많죠. 3단은 정말 최악인 거 같고, 긴박하게 기사가 들어오고 특집 주제를 상시적으로 계속 다뤄야 하는 언론사급이 아니라면 개인 블로거의 경우에는 1단이 가장 좋은 거 같습니다. 최소 2단으로 사이드바를 유지하는 경우에도 사이드바에 너무 어지럽게 이것저것을 늘어놓지 않도록 해야 하겠습니다.

결론: 위젯과 사이드바를 모두 청소해보자. 내가 보여주고 싶은 거 말고, 이용자가 꼭 필요한 것만 골라서 남겨두자.

9. SNS 공유 버튼

방문자가 내 글을 공유하고 싶을 때 sns 공유 버튼이 있으면 좋은 서비스가 되겠지요. 하지만 나름 SNS를 많이 하는 제 습관을 생각해보면 사람들은 사이트에서 일부러 제공하고 있는 버튼보다는 그냥 URL을 복사해서 페이스북이나 트위터 글 작성 화면에 붙여넣는 경우가 더 많다는 걸 알게 될 겁니다. 또 공유를 일상적으로 하는 사람은 이미 크롬의 확장도구 등을 통해 개인적으로 편리한 도구를 갖추고 있어서 굳이 사이트에서 제공하는 버튼을 이용하지 않는 경우가 더 많습니다.

그러므로 공유버튼은 사실 없어도 크게 욕먹을 일이 없고, 있더라도 매우 조용하고 얌전하게 놓아두는 게 좋겠습니다. 잘 쓰지도 않는 구글플러스 공유버튼을 포함해서 5개 이상의 서비스로 보내기 버튼을 매 글마다 상단, 하단에 늘어놓는 일은 피해야 하겠습니다.

결론: 공유하고 싶으면 알아서들 하니까 너무 걱정 말자.

10. 주소표시 : 숫자 쿼리 vs. 고유주소(Permalinks) 방식

티스토리에서 쓰던 숫자 방식이 편하지만 글을 작성하면 순차적으로 숫자를 매겨서 URL을 만들어주는 방식과, 매번 글을 작성할 때마다 제목을 포함하여 글의 주소 자체를 직접 만들어주는 방식은 각각 장단점이 있습니다.

숫자쿼리 방식

장점은 글 작성하면서 주소 만들기에 신경을 쓸 필요가 없고, 주소가 짧고 간단해 보이죠.

단점은 블로그 플래폼을 옮기거나 할 때 글의 고유주소가 훼손될 수 있습니다. 예를 들어 티스토리에서 http://example.com/123 으로 작성한 어떤 글이 있는데 이 글을 워드프레스로 옮겨오고 도메인도 이사했는데, 똑같은 글을 http://example2.com/123 으로 만들 수 없는 경우가 발생할 수 있습니다. 쿼리 방식이 달라서 http://example.com/?p=123 과 같은 방식만이 가능하거든요. 만약 해당 글이 이미 널리 인용되고 있는 상황이라면 상당히 혼란이 생기게 되지요.

또한 http://example.com/123 이라는 주소 자체에는 내용에 대한 어떤 힌트도 없기에 클릭하기 전에 해당 URL의 중요성이나 가치에 대한 선전이 전혀 불가능하죠.

퍼머링크 방식

장점은 http://example.com/iphone-review 와 같이 쓰면 해당 글이 어떤 내용인지 가늠할 수 있고, 글에 하나의 이름이 붙이는 것처럼 플래폼이나 서비스를 옮겼을 때에도 수동으로 주소를 다시 지정해주면 이전에 해당 게시물을 인용했던 사람들에게 혼란을 주지 않을 수 있습니다.

단점은 매번 글 작성할 때에 한글 사용자 입장에서는 영작이 필요하다는 것과 과연 한국 독자에게 이러한 영작하기가 어느 정도의 효과를 지니는가 의심이 든다는 것입니다. 또한 시간상으로도 꽤 귀찮은 일이 하나 더 늘어나는 거니까요.

또 하나 드는 생각은 … 요즘 뉴욕타임즈의 기사 URL을 페이스북에 붙여넣으면 url이 아니라 글의 이미지와 기사의 제목이 미리보기로 자동으로 표시되지요. 또한 트위터나 buffer에 붙여넣어보면 트위터나 버퍼에서 쓰는 단축주소 방식으로 url이 단축되거든요. 즉, 퍼머링크를 유지하는 게 식별상 유리한 건 많지만 활용과 유통 면에서 딱히 우위에 있는 건지는 모르겠습니다. 구글에서 더 잘 긁어갈 거라는 예상도 가능하지만 그건 글의 제목과 내용만으로도 이미 잘 긁어가기 때문에 걱정할 이유가 거의 없어요. 블로터닷넷 이나 ZDNet Korea의 경우를 보시면 그냥 숫자 쿼리 방식을 쓰고 있다는 걸 알 수 있습니다. 영어가 모국어가 아닌 상황에서 퍼머링크를 고집할 이유는 없어보입니다.

결론: 귀찮으면 그냥 숫자 쿼리 방식 써라. 별 문제 없다. 하지만 글 이름이 들어간 링크를 부여하면 더욱 예뻐 보이기는 하다.

11. 가독성을 높이기 위한 세팅

텍스트 크기 너무 작지 않게

평소 네이버 카페의 본문 쓰기/읽기 기본 글자 크기가 불만입니다. 요즘은 모니터가 거의 19인치 이상인 경우가 많죠. 특히 텍스트가 많은 블로그에서 10px 는 이제 너무 작은 크기인 거 같습니다. 최소 12px는 되어야 할 거 같고, 저는 14~16px로 설정하여 사용하고 있습니다. 유명 언론 블로터닷넷은 13pt인 거 같네요.

본문 확대 문제

어떤 사용자는 브라우저의 확대 기능을 이용하기를 원합니다. 눈이 안 좋거나, 기타 본문만 추려내고 싶다든가 등등의 필요로 말이죠. 이럴 때 레이아웃이 확대되어가면서 블로그 본문 텍스트가 잘려나가거나, 화면에 배치된 이미지 등과 엉망으로 섞여버리든가 등의 문제가 발생되지 않도록 해야 하죠. 보통, 이 문제는 반응형 테마를 구입하여 사용하는 경우에는 거의 걱정할 필요가 없습니다.

본문 가로 폭

과거 1단형 스킨을 사용하고 싶었는데, 이유는 가끔 가로폭이 큰 사진이나 영상을 포스팅하고 싶었기 때문이죠. 보통 사진의 경우 가로 800px 이상은 되어야 좋은 화질도 돋보이고 감상하기에도 좋죠. 영상도 전체화면 전환하기 전에 이미 상당히 크게 삽입해주는 블로그들이 많이 있습니다. 그런데 본문 가로폭을 이렇게 800px보다 크게, 때로 1000px이나 1100px까지 설정하면 텍스트 읽기엔 불편해지는 거죠. 읽으면서 눈이 아니라 고개가 좌우로 왔다갔다 해야할 수준이 됩니다. “ABCDEFGHIJKLMNOPQRSTUVWXYZ“가 두 번 이상, 세 번 미만이 되도록 줄 길이를 설정하라는 조언은 적절해보입니다. 14pt 나눔고딕 기준으로 550px 이하는 너무 좁고, 850px 이상은 긴 글을 읽을 때 불편할 겁니다. 현재 이 블로그는 750px 내외로 설정되어 있습니다.

줄 간격은 150~170%

줄 간격을 180~200%로 크게 하면 가독성이 더 좋아진다고 생각하는 사람이 있습니다. 실제로 130% 정도로 설정해도 문단 구분만 적절히 해주면 가독성에 큰 영향이 없습니다. 현재 저는 150%로 설정했습니다.

배경색/ 본문색

제품을 선전하기 위한 목적이 아니라면 흰 바탕에 검은 색이 가장 좋습니다. 특히 완전한 검은색보다 아주아주 살짝 살짝만!!! 진하기를 줄여주면 읽기에 좋지요. 그래서 완전한 검은색 #000000 대신에 #676767 로 수정하여 본문 글자색으로 사용하고 있습니다. 특히 아이폰/아이패드 Reeder2 의 화면 배색을 본따 배경색도 약간 누런 색인 것도 좋아요. 하얀색 #FFFFFF 대신에 #F8F7F4 또는 #F5F5F5 등의 배색 추천합니다.

Meta-elements 최소화

글이 속한 카테고리, 태그, SNS 공유버튼이 너무 크거나 또는 심지어 글을 읽기 시작하여 스크롤링을 시작했는데도 화면 어딘가에서 독자를 방해하는지 생각해야 하겠죠. 현재 사용중인 테마에서 이런 요소들을 너무 지저분하게 표시하고 있는지 살펴볼 필요가 있습니다. 가령 단 두 개의 카테고리로 글을 쓰는 블로거의 경우 모든 글에 지금 이 글이 어느 카테고리에 속해 있는지를 반드시 알려줘야 독자가 편해할런지 생각해보는 거죠.

광고 배치

현재 광고는 없고, 앞으로도 달지 않을 생각.

12. 하이퍼텍스트 에티켓

링크 구분

링크가 적용된 텍스트인지 아닌지 표시 안 해주는 건 에티켓이 아니겠죠. 물론 제목이나 사이드바의 메뉴 등은 예외입니다. 저는 시퍼렇게 글자가 뜨는 게 싫어서 이전까지 점선 밑줄 + 본문보다 살짝 연한 색으로 링크를 표시했었는데, 장단점이 있습니다.

파란색이나 파란색에 가깝게 링크를 표시해주면 사용자 입장에서 아주 좋습니다.기존에 이미 파란색 계열이 뭔가 누르면 이동하는 하이퍼텍스트라는 사실이 이미 널리 인식되어 있거든요. 또한 실선보다 점선에 비해 좀 글 읽기 흐름을 방해하는 측면이 있긴 해도, 확실히 이건 누르면 이동하는 링크라고 알려주는 지시성이 큽니다. 하이퍼링크에서 파란색 글자색 + 실선을 사용하면서 다시 강조하는 용도로 실선을 재차 사용하는 건 피해야 합니다. 이탤릭체+굵게 정도로 강조 의도는 분명히 표현될 수 있으니 헷갈리게 밑줄 표시를 혼용하여 혼란을 만들지 말라는 거죠.

그러나 제 경우에는 이런 조언도 무시하고 점선을 하이퍼링크를 표시하는 약속으로 사용하고 있습니다. 텍스트도 본문 텍스트 색깔을 바꾸지 않고 있는데요. 이유는, △ 파란색이 자주 나타나면 글 읽기에 방해가 된다 △ 사용자 입장에서 점선 정도의 표시로 이것이 하이퍼링크라고 표시하는 데 큰 무리가 없다 △ 밑줄(실선/점선)을 가급적 다른 용도로 사용하는 일이 없다

결정을 했으면, .single-post a 등으로 되어 있는 스타일 지정 부분의 컬러와 텍스트 꾸밈을 지정해주면 됩니다.

(예시 – 밑줄 실선을 사용하는 경우)

.single-post .post-wrap .entry-content-wrap .entry-content a{

color:#0061D3;

text-decoration:underline;

}

페이지 본문에도 적용 시.

.single-page .entry-content a{

        color:#0061D3;

        text-decoration:underline;

}

방문 링크 구분

방문한 링크가 다른 색으로 표시되는 건 여러 하이퍼링크를 소개하는 글을 읽으면서 사용자가 자신의 행동을 추적할 수 있는 중요한 근거가 됩니다. 보통 방문했던 링크는 보라색으로 표시되죠. 이 조언을 무시하는 경우도 많은데, 배려해주면 좋습니다. 마우스를 올려두었을 때 색이 변하는 (hover) 스타일링은 사용하지 않습니다. 어파치 스마트폰/패드의 터치스크린에서는 사용할 수도 없고요.

(예시 – 밑줄은 유지하고 방문한 텍스트의 색깔을 변경)

.single-post .post-wrap .entry-content-wrap .entry-content

a:visited {

        color:#954343;

        text-decoration:underline;

}

페이지 스타일에도 적용 시.

.single-page .entry-content

a:visited {

        color:#954343;

        text-decoration:underline;

}

새창 열기

링크 클릭 시 저는 무조건 새창열기를 강제하여 사용해왔습니다. 구체적으로는 링크가 무조건 새 창이나 새로운 탭에서 열리도록 설정해두는 것은 독자 입장에서 짜증날 수 있는 문제라는 걸 잘 알고 있고, 독자가 컨트롤키나 쉬프트 키와 조합하여 클릭하여 새 창이나 새 탭에서 해당 링크를 열기로 선택할 수 있는 권한 자체를 차단한다는 점에서 못된 짓이기도 하죠. 일종의 ‘딴 데 가지 마!‘라고 떼쓰는 동작 같은 건데…

이 문제에 대해서 좀 다른 생각도 듭니다. 우선 본문이 모두 끝난 상태가 아니라 본문의 읽기 도중에 등장하는 어떤 참조 성격의 링크의 경우 사용자가 이 링크를 클릭할 때 의도하는 것은 무엇인가라는 거죠. 아마도 이동보다는 참조에 가까울 것입니다. 저도 블로그 글을 다 읽은 후가 아니라 읽는 도중에 어떤 본문의 링크를 클릭하면서 읽기를 중단하고 해당 링크에 머물기를 원했던 적은 거의 없었습니다. 또한 이동한 이후에 다시 본문 읽기를 계속하기 위해서 일부러 앞으로 갔다가 뒤로 갔다가를 반복하는 사용자가 의외로 많습니다. 쉬프트+클릭을 모르는 분들이죠. 오히려 새 창을 닫는 행위보다 계속 하나의 탭에서 앞으로 뒤로 왔다갔다 하는 불편이 더 크가도 호소하는 경우도 많습니다. 새 탭에서 열리면 참조 후 간편하게 탭 닫기를 수행하고 본문 읽기 스크롤을 계속할 수 있기 때문이죠.

새 창 열기 플러그인을 사용해서 새창 열기를 강제할 수 있는데, 제 경우는 일단 보류하고 있습니다.

기능 막기

마우스 우클릭을 막는다든가, 뒤로 가기를 금지하거나 등등 기본적인 브라우저의 기능성을 제한하거나 수정하는 것을 가능하면 지양해야 하겠습니다.

14. 반응성(Responsiveness)

모바일 최적화

별도의 모바일 사이트를 구축하지 않아도 요즘에는 모바일 화면에 잘 보이도록 화면을 배치해주는 반응형 테마가 많이 나와있습니다.

만약 기본 테마의 모바일 화면 맞춤이 싫으면 WPTouch 플러그인 등을 통해 스마프폰 화면을 디자인해주는 것도 좋아요. 가령 이미지나 유튜브 동영상의 가로화면을 강제로 화면에 맞게 재조정해주는 기능이 기존 사용하고 있는 테마에서는 제대로 지원되지 않는다거나 세세한 문제 해결이 귀찮은 경우 모바일 테마를 따로 마련하게 되지요.

물론 그런 경우 디자인의 일관성을 해치게 됩니다.

조언하는 블로그에서는 본인의 블로그가 아래 세 가지 상황에서 잘 보이는지 반드시 체크해보라고 합니다.

  1. 큰 모니터가 있는 PC나 노트북 화면에서
  2. 아이패드에서 세로 / 가로 화면
  3. 스마트폰에서 세로 / 가로 화면

브라우저 고려

구글분석도구를 사용하면 내 블로그에 접속하는 사람들이 사용하는 브라우저를 통계낼 수 있습니다. 본인이 크롬을 좋아하고 늘 그것으로 접속하기 때문에 자기 모니터 화면만 기준으로 생각하면 안 됩니다. 사용자가 가장 많이 사용하는 브라우저 기준으로 내 블로그가 문제 없이 구현되고 있는지 체크할 필요가 있습니다.

관리자 모드

또 어떤 테마에서는 광고영역이 관리자 모드에서는 표시되지 않거나, 관리자모드에서는 보이지 않는 버튼 등이 포함된 경우가 있기 때문에 크롬이나 IE에서 로그아웃 상태(incognito)로 접속해보고 방문자 입장에서 내 블로그가 어떻게 보이는지 체크해보는 것도 필요합니다.

15. 독자를 위한 도구

검색 기능 제공

사람들이 쉽게 내 블로그 내용을 찾을 수 있도록 검색 필드를 제공해야 합니다. 구글검색엔진을 블로그와 통합하여 사용하는 분들도 있습니다. search.php(검색결과 호출)에서 기존 워드프레스 코딩을 주석처리하거나 삭제하고 구글 CSE의 검색결과 코드로 대체하면 됩니다. HwangC의 착한 워드프레스 강좌를 참고하세요.

그러나 좀 지저분해지는 코드가 싫으면 워드프레스 자체의 검색 기능을 내버려 두는 것도 좋아요. △ 웬만한 한글 검색어로도 포스트 자체는 찾아낼 수 있고 △ 키워드로 특정 포스트를 겨냥해서 찾을 때 블로그 내 검색이 아니라 이미 구글에서 검색하면서 특정 포스트로 직행해서 들어오기 때문에 의외로 내 블로그 도메인에 한정해서 구글검색을 시도하는 사람이 많지 않더라고요.

RSS 피드 연결

상단에 버튼으로 표시했던 것을 치워버리고 맨 하단으로 뺐습니다. 가끔 블로그 툴을 사용하면서도 피드 주소를 직접적으로 알려주지 않는 블로그가 있는데 불편을 초래합니다. 하지만 엄청난 크기의 주황색 아이콘을 사이드바에 박아넣은 블로그 또한 기피 대상입니다. 실제로 RSS가 뭔지 알고 구독해서 블로그 글을 리더로 받아보는 사람이 아주 적다는 걸 알아야 합니다.

파비콘

파비콘이 없으면 피드 구독자가 여러 다른 소스의 글과 섞여있는 리스트에서 글을 소스별로 구분하기가 힘들어집니다. 파비콘 ico 파일은 공짜로 변환하거나 제작할 수 있는 사이트가 구글링하면 많이 있고, 테마 설정 화면이나 스타일시트를 직접 만져서 적용할 수 있습니다.

16. SEO 검색엔진 최적화

고유주소(permalink)

현재 제 블로그에서는 숫자 쿼리 방식 대신 고유주소를 직접 만들어주어 쓰고 있는데 사용자 입장에선 이게 더 편하지 않나 하네요. 글의 주소 자체에 제목이 들어가면 주소 자체가 외부에 공개되었을 때 클릭하기 전에 해당 내용을 유추할 수 있고, 작성자 입장에서는 일종의 요약을 URL 안에 담아 유포할 수 있다는 장점이 있죠. 그러나 위에서도 얘기했지만 귀찮은 일이기도 하고 요즘처럼 주소 줄이기를 많이 하는 환경에서 효용도 꼭 크다고 할 수는 없어요. 또한 게시물의 주소가 고유주소방식이 아니라도 글의 제목과 내용으로 검색엔진에서 잘 검색이 되고 있으니까요.

아카이브 페이지

과거의 글에 접근할 수 있도록 모든 글을 주르륵 펼쳐주는 페이지가 있으면 사용자 입장에서 땡큐입니다. 저는 메뉴에 “Archive(전체글)“이라는 버튼으로 해당 페이지로 바로 갈 수 있는 링크를 제공하였습니다. 아카이빙은 플러그인을 사용해서 자동으로 페이지 본문에 표시되게 했습니다.

구글 Authorship information

구글 검색 결과에 어떤 사이트는 더욱 풍부한 정보와 함께 표시되는데, 구글플러스 프로필 정보와 내 사이트를 연동시키는 게 가능했었어요. 하지만 현재 이 연동을 구글이 포기한 상태. 더 이상 신경쓸 필요 없음.

17. 옵션으로 하고 싶으면 해도 되는것들

소셜 공유 : 소셜공유 버튼은 공유하고 싶어하는 사용자들을 위한 배려가 되지요. 저는 사용하지 않아요. 지저분해서.

카테고리 목록 제공

카테고리를 사용한다면 카테고리가 표시되게 하면 좋죠. 이 글의 성격과 방향을 짐작하게 합니다. 워드프레스는 복수의 카테고리를 하나의 글에 적용할 수 있지만, 그렇다고 너무 많은 카테고리가 나열되지 않도록 하는 게 좋겠고, 최대 2개 정도가 적절해보입니다. 다 관련있는 거 같아도 가장 관련있는 카테고리 쪽으로 우선순위를 두고 몰아주는 게 나아보입니다.

메타 데이타

어떤 글을 쓸 때 글의 본문에 호랑이라는 단어가 있으면 구글검색에서 누군가 호랑이를 검색하다가 얻어걸려 내 블로그에 들어올 수도 있겠죠. 그런데 이런 방식 말고 본문에는 보이지 않지만 메타데이터에 검색엔진이 이 글을 긁어갈 수 있도록 키워드 등을 추가해줄 수도 있습니다. 그러나 요즘은 태그와 본문에 포함된 내용만으로도 이미 검색이 잘 되는 거 같아 일반 사용자의 경우 굳이 검색엔진의 인덱싱 능력을 걱정하며 너무 신경쓸 필요는 없을 거 같습니다.

18. 없애야 하는 것들

삭제 – 데이터 기반 인덱스 페이지

일종의 사이트맵? 같은 걸 자동으로 구성하거나 하는 행동이 적어도 블로그에는 오히려 노이즈를 유발할 수 있다는 지적입니다. 혹시 내 블로그에 뭐가 있는지 구글이 모르면 어떻게 하나 노심초사하면서 이것저것을 주렁주렁 설치하지 마세요. 또한 복잡한 메뉴 구조를 파악하라고 독자에게 강요하지 마세요. 한 달 전에 무슨 글을 썼는지가 특별히 궁금한 사람은 없고, 다들 검색엔진이나 타인의 소개 때문에 특정 글을 읽기 위해 바로 들어와서 그 글을 읽고 나가므로 내 사이트의 펼침 메뉴를 다 보여주는 건 별로입니다. 짜장면 먹으러 갔는데 메뉴판 정독하라는 꼴이랄까.

삭제 – 헤더에 소셜사이트

자리만 차지하는 본인의 소셜미디어 사이트 링크/버튼을 헤더에서 과감히 지우라는 조언. 매번 사용하는 기능성 버튼이 아닌데도 늘 자리를 차지하고 있는 거 자체가 기능적 후퇴. 블로그 주인장의 글이 좋으면 알아서 찾아가도록 차라리 소개 페이지 등에 몰아놓는 게 낫고, 모든 글의 상단에 매일 표시하는 건 피하자는 거죠. 그래서, 과감히 지웠습니다!

삭제 – 백그라운드 색상/텍스쳐

백그라운드에 모눈종이 배경을 넣는다거나 유색 배경을 넣은 사이트는 가독성을 저해하는 경우가 많습니다. 배경색을 넣기로 결정했더라도 반드시 텍스트 읽기에 도움을 주는지 고민해야 하겠습니다.

삭제 – 사이드바

사이드바 자체가 필요없다는 조언. 일종의 “쓰레기 서랍장“이라고까지 표현. 보통 사용자를 위한 것이 아니라 블로그 운영자가 이것저것 챙겨서 보관해두고 싶은 마음에 사이드바에 이것저것 넣을 때가 많다는 겁니다. 만약 절대 포기하지 못할 어떤 모음이 있다면 차라리 페이지 하단으로 옮기세요.

하지만, 저는 역시 유지하기로. 검색창을 비롯해서 인기글 선전 등의 목적이 분명히 있을 때 사이드바는 훌륭한 광고 자리가 됩니다. 다만 너무 현란하고 정신 사납지 않은 범위에서 유지하려고 합니다.

삭제 – 소셜미디어 타임라인

트위터나 페이스북 글이 실시간으로 블로그 어딘가에 노출되도록 설정해둔 사람들이 있고, 저도 해봤는데요. 오히려 블로깅을 방해하는 요소이고, 맥락에서 동떨어진 블로그라는 공간에서 그런 글을 읽게 되어 더 어색해보이는 단점도 있는 거 같네요.

삭제 – 인스타그램 자랑질

플리커 사진을 불러와서 표시한다든가, 인스타그램 사진 자랑하기, Github 보관소 표시 등등. 자랑하고 싶은 것들을 글의 본문과 나란히 배치하면 집중하기 어려워집니다. 특히 칼라 버튼이나, 칼라 사진을 나란히 본문과 배치하는 걸 피하라고 권유하네요. 저도 사진 자동으로 불러와서 사이드바에 넣어둔 걸 하단으로 옮겼습니다.

삭제 – 프로필/블로그 소개

이 블로그를 소개하는 페이지는 메인 메뉴에 두어도 누구나 어쩌다 궁금하면 한 번 읽고 말 내용이니, 큰 메뉴에 넣거나 사이드바에 넣기보다는 원하면 찾을 수 있게 역시 페이지 하단에 따로 링크를 마련해두고, 보통 게시물 주변에는 이런 링크/메뉴/바로가기를 빼는 게 좋겠습니다.

네이버 첫 화면에 네이버란 어떤 회사인지가 매일 큰 버튼으로 나온다고 생각해보세요. …. 저도 빼는 걸 고려중입니다.

삭제 – 최근 포스트

이미 메인페이지에 최근 포스트가 나오고 있으므로 과감히 삭제하라는 충고. 저는 고민중.. 왜냐하면 첫페이지에는 포스트들의 미리보기가 함께 표시되고 있어서 그래도 다섯 개 정도의 최근 포스트가 사이드바에 나오는 게 나쁘지 않은 거 같아서요.

삭제 – 인기있는 글

인기있다고 강요하지 말고, 좋으면 찾아읽게 그냥 없애버리라는 충고. 만약 추천 글이 있으면 따로 블로그 소개 글 같은 곳에서 설명과 함께 소개할 것. 보통 다른 글을 읽고 있는데 옆에서 깔짝대며 이것도 인기 있으니 읽어보라고 강요하지 말라는 소리겠죠…

하지만 저는 아직 지우지 못하고 있습니다..

19. 사용중인 플러그인(2016년 11월 현재)

부록으로 현재 제가 사용중인 플러그인 정리해봅니다.

  • Akismet : 스팸 댓글 차단. 필수.
  • JetPack by wordpress.com : 기본으로 반드시 설치. 통계, 사진트래픽 줄여주는 Photon, 커스텀 css 기능 등이 유용.
  • Links/Problem Reporter : 링크 깨지거나 했을 때 사용자가 운영자에게 쉽게 신고할 수 있도록 장치 마련.
  • mb.miniAudioPlayer : 외부나 내부의 mp3파일을 본문에 삽입하여 재생 가능하게 해주는 플레이어 플러그인은 아주 많음. 그 중 이 녀석은 따로 shortcode를 사용하지 않고 <a href=”http://ift.tt/1cgU5Jy; 형식으로 본문에 삽입해도 플레이어 형태로 바로 바꿔주고, 모양도 크게 후지지 않아서 마음에 드는 도구. 다운로드 버튼 제공.
  • WP Super Cache : 초보자 입장에서 가장 편하게 시도할 만한 캐쉬 플러그인이 아닌가 생각. 약간이지만 캐쉬 플러그인이 있고 없고의 차이는 분명 있음. 사이트 로딩 속도 높이고 부하 줄이는 데 필수.
  • Smart Archives Reloaded : 블로그의 모든 포스트를 한 페이지에 표시해주는 서비스 정도는 해주는 게 좋다. 아카이브 플러그인 여러 종류가 있지만, 그 중 꽤 괜찮은 플러그인이라고 생각. 옵션이 무척 다양해서 원하는 방식으로 페이지를 구성할 수 있음.
  • WP-Typography : SmartyPants 방식으로 구두점 바르게 표시하도록 도와주는 플러그인. 이에 관해서는 이전 포스트 워드프레스에서 Smartypants 사용에서 이미 다룬 바 있음.

20. 마치며

정답은 없다. 나도 다 안 지킨다. 하지만 계속 고민해보세요.

지금 이 기능/디자인/요소가 나 좋자고 하는 건가 방문자에게 도움이 되는 건가?

(2014년 1월 처음 작성. 2016년 11월 고쳐씀.)