그렇게 노력이 필요했던 작업들은 지금은 아주 간단하게 가입만 하면 바로 만들 수 있는 쉬운 도구가 되었다. 이제는 게시판의 형태를 떠나서 게시물의 내용을 목차와 내용을 한번에 볼 수 있는 말 그대로 웹에서 볼 수 있는 로그 (log) 형태를 지향하며 웹 (web) + 로그 (log) 가 되어 블로그 (blog) 가 대중화 되었다. 블로그의 숨겨진 힘은 인터넷 사용자들이 어떤 문제 해결이나 지식을 얻기 위해 특정 장소에 찾던 과정에서 인터넷에 흩어진 (분산된) 정보를 찾는 것이 중요하게 되었고 결국 검색 엔진의 역할이 점점 강조되게 되었다. 예를 들어 개인 블로그가 활성화 되지 않던 시절에 맛집 정보는 특정 커뮤니티의 게시판이 주도적인 역할을 하였지만 이제는 수많은 개인이 올린 블로그의 내용으로 여러가지 살펴볼 수 있게 되었다.
어떤 블로그 서비스를 선택해야 하나?
개인적으로 2004년 이후 10년동안 운영하던 블로그 서비스 업체 (티스토리) 를 벗어나 새로운 둥지를 만들게 되었다. 블로그를 시작한지 얼마 되지 않았다면 쉽게 옮길 수 있겠지만 글의 수가 500개 가까이 되고 나니 다른 곳으로 옮기려 시도를 하다가도 지금까지 해왔던 관성과 옮기는 과정에서 발생할지 모르는 손실의 두려움으로 계속 글을 올리게 되었던 것 같다. 언제 이런 고민을 하게 되었을까? 그때마다 블로그를 쓰면서 불편한 점을 찾아 메모했던 내용을 소개하여 개인적으로 왜 이전을 감행(?)했으며 그동안 불편했던 내용들을 어떤 식으로 해결하려고 했는지 소개하는 것이 the Great World Meson 의 두번째 시즌(?)을 개장하는 첫글로 가장 어울릴 것 같았다. 특정 업체의 단점을 소개하는 목적이 아니라 블로그 서비스를 포함해서 비슷한 서비스를 사용 혹은 제공하려고 한다면 한번쯤 생각해 볼 내용들이 될 것 같아서 정리해 본다. [ 문제점들의 발생 ]
1. 다양한 기기 지원을 생각한다
다양한 기기는 다양한 해상도를 뜻한다. 예전에는 거의 대부분이 1024 x 768 의 해상도이 대부분이었고 대부분 이 해상도에 맞게 서비스를 해주면 별 문제가 없었다. 그러나 스마트폰과 같이 작은 화면에서는 오히려 낮은 해상도도 고려해주어야 한다. 이를 해결하기 위한 기술적 방법은 간단하다. 접속하는 기기의 해상도 정보를 물어보고 해당 해상도에 적당한 페이지 형식을 제공해주는 것이다. 해상도가 적당히 높으면 일반 페이지를 보여주고 해상도가 낮으면 모바일에 적당한 페이지 형식을 보여준다. 아주 괜찮은 아이디어 같지만 또 다른 문제가 발생한다.
소셜 네트워크에 누군가 공유한 링크를 관심있어 클릭해보면 주소가 m. 과 같이 주소 앞부분에 모바일 페이지임을 나타내는 페이지들을 종종 볼 수 있다. 공유한 사용자는 해당 페이지를 들어갔고 사용 기기가 해상도가 낮아 모바일 페이지로 이동 (forwarding) 되었을 것이다. 그리고 그 이동된 (forwarded) 주소를 그대로 공유한 것이다. 그러나 공유된 정보를 보는 다른 사용자들도 높은 해상도에도 불구하고 모바일 페이지를 봐야 한다. 조금만 신경쓴다면 모바일 페이지에도 해상도를 확인하고 해상도가 충분히 높다면 고해상도 페이지로 이동시켜 주면 될텐데 이정도 배려를 보이는 곳은 그리 많지 않다.
 |
| 티스토리의 모바일 스킨을 활성화하면 낮은 해상도에서는 /m 의 주소로 이동한다. 일반 페이지와 전혀 다른 화면 구성을 보여준다. |
비슷한 문제는 개인 블로그에서도 볼 수 있었다. 블로그 서비스에는 모바일 페이지를 보여주는 서비스를 제공했다. 처음에는 그래! 내가 원하는 기능이야 싶어 활성화 했지만 사용하면서 불편한 점들이 나타났다. 일반 페이지와 모바일 페이지 활자 (폰트) 크기 등이 제대로 나타나지 않는 것은 사소한 불편함이고 일반 페이지의 주소와 모바일 페이지의 주소 체계가 다르기 때문에 모바일 페이지 상태에서 공유한 링크가 일반 주소와 다르게 된다. 예를 들어
myblog.address.com 이 일반 주소라면 m.myblog.address.com 이 모바일 페이지이고 실제로 모바일 페이지로 공유된 통계는 일반 주소와 같이 통계가 잡히지 않는다. 무엇보다 모바일 페이지는 내가 보여주고 싶은 최종적인 글의 모양새 (스타일) 와는 거리가 멀고 블로그 서비스 업체에 따라 모바일 페이지에 자사의 검색 엔진 혹은 검색 순위 심지어 광고 (광고 수익은 블로그 주인과 아무런 연관이 없는) 까지 들어가게 된다. 처음 블로그 서비스를 바꿔야 겠단 결심을 먹은 결정적 계기가 바로 모바일 페이지에 사용자의 동의없이 자사의 서비스를 넣었던 순간이었다.
 |
| 모바일 페이지의 아래부분으로 이동하면 원하지 않는 관련 포털 검색순위 페이지가 표시된다. |
2. 글에 집중하고 싶어진다
아무리 블로그가 개인적인 공간이라도 하나의 완성된 글의 형태로 공개하고 싶기 때문에 자신이 원하는 형태와 모양새로 보여지는 것이 중요하다. 대부분의 블로그 서비스는 사용자들이 특별히 HTML 이나 CSS 의 문법을 몰라도 일반 워드프로세서 쓰듯이 쓰면 어느정도 원하는 수준을 맞추어 주는 편집기 (editor) 를 제공한다. WYSiWYG (What You See is What You Get) 이라 해서 편집한 대로 원하는 결과물을 만들어 준다고 하지만 다양한 사용자들의 사용환경 (브라우저, OS 등) 에 따라 내가 원하는 대로 만들어졌다고 해도 원하는 대로 보여지는 것이 아니다.
이렇게 다양한 사용자에 따라 보여지는 모양이 다르게 되는 가장 큰 이유 중 하나는 편집기에서 제공하는 다양한 기능들이 오히려 다른 사용자에게는 작동하지 않는 불편한 코드를 삽입해서 구현하는 경우가 많기 때문이다. 따라서 내가 보는 환경에서는 잘 작동하는 코드들도 다른 환경의 사용자들에게는 표현되지 않는 경우가 많아진다. 특히 당장 보이는 것에 집중해서 편집기에서 포맷이며 자간, 줄간격 등을 강제로 지정하고 싶은 충동이 종종 생긴다. 문제는 당장은 내가 원하는 대로 만들어 진 것 같지만 그렇게 모양새 (폰트, 크기 등) 가 정해진 경우 발생할 수 있는 문제점은 1. 블로그 내용보다 불필요한 코드가 더 커진다. 2. 다른 블로그로 글을 옮길 때 강제로 지정된 모양새가 문제가 된다.
 |
| 블로거 편집기, 모양새 지정을 위한 최소한의 태그만 사용한다. 블로그 서비스에 따라 원하지 않는 태그 내용을 추가하는 경우가 있다. |
따라서 가장 좋은 환경은 글에만 (텍스트) 집중하는 것이다. 블로그에 보여지는 모양새에 신경쓰지 않고 편집기는 단순히 내가 원하는 글의 내용을 입력할 수 있는 단순한 텍스트 편집기 수준이면 그만이고 이후 모양새는 블로그가 운영될 때 내용에 따라서 알아서 표시해주는 것이다. 블로그 시작할 때 기억나는 기능은 글의 일부 내용을 숨겼다가 펼칠 수 있는 기능 (folding) 이 있어 자주 사용하게 된 시기가 있었다. 어느 순간 그 기능때문에 전체 글 내용이 꼬여 버린 기억이 생생하다. 가장 중요한 원칙은 기본만으로도 충분하기에 욕심을 버리는 것이 필요한지 모른다.
3. 라벨 (Label) 과 범주 (category) 의 딜레마
쥐메일 (Gmail) 이 시작했을 때 많은 사람들이 불편했던 기능이 바로 라벨 (Label; 레이블) 이 아닐까. 메일 좀 써봤다는 사람들은 이미 폴더 형식에 익숙해져서 폴더는 전혀 없고 무슨 알 수 없는 레이블만 가득했다. 심지어 일부 사람들은 쥐메일에 대한 혹평을 쓰면서 폴더 기능이 없는 기본도 제공안하는 최악의 서비스란 말이 기억난다. 그런데 개인적으로 라벨 기능을 보면서 머리를 크게 맞은 느낌이었다. 아웃룩의 폴더 기능을 쓰면서 가장 불편한 부분이 바로 폴더 기능 자체였던 것이다. 예를 들어 메일이 왔는데 '연구'에도 관련이 되고 '회계' 에도 관련이 된 메일이 있을 수 있다. 즉, 관련된 내용이 많아 어떤 폴더에 넣어야 할지 고민이 되던 순간이 한두번이 아니었다.
결국 다중 선택을 할 수 있는 내용에 대해서 한가지 선택을 강요하는 구성은 항상 사람을 고민에 빠지게 만든다. 블로그를 쓰면서도 나름 기준을 만들어 범주 (category; 카테고리) 를 나누어 보지만 글을 다 마치고 나면 이것이 '몽달이생각' 범주인지 '일상다반사' 범주인지 고민하게 된 적이 한두번이 아니다. 심지어 세가지 범주에 걸친 내용이 아닐까 고민하기도 한다. 처음에는 범주 내용이 10개 정도였다가 정리하고 정리해서 최종적으로 4개로 줄인 것이다. 그러나 불편함은 여전히 발생한다.
오히려 반대의 불편함 혹은 필요성이 발생한다. 범주로 나누었지만 때로는 글을 쓰는 대상이 같은 경우가 있다. 예를 들어 특허에 관한 이야기를 쓰다보면 정치 경제적 배경에 대해 쓰게 되어 '몽달이 생각'에 넣은 글과 기술에 관한 일반적인 철학이 경제에 미치는 영향에 대한 글을 쓰고 '시스템 잡설' 에 넣었지만 글의 내용상 여러 범주에 흩어진 글들을 모아 한 줄기의 글타래 (series) 를 구성하고 싶어진다. 어떤 글을 명확하게 나눌 수 있는 블로그 운영자들도 분명 있지만 많은 경우 '객관적 분류' 란 거의 힘들어진다. 특히 짧은 글로 구성된 것이 아닌 할말이 많은(?) 블로그의 경우 이런 고민은 더욱 더 커지게 된다.
4. 오랫동안 사용할 수 있으면 좋겠다
블로그는 운영 방식에서 크게 두가지로 구분된다. 먼저 사용자 가입을 하고 해당 서비스를 사용하게 된다. 이를 가입형 블로그라 부른다. 두번째는 자신의 서버 (혹은 호스팅 서비스) 에 설치해서 사용하는 '설치형 블로그' 가 있다. 전자의 대표는 국내 주요 포털 서비스, 티스토리, 구글의 블로거 등이 있고, 후자의 대표주자는 워드프레스 (wordpress) 이다. 물론 워드프레스의 경우 가입형 서비스도 가능하다. 그러나 무료 가입자의 경우 많은 서비스의 제약이 있다. 개인적으로 항상 운영할 수 있는 서버도, 호스팅 서비스도 있기 떄문에 설치형 블로그를 선호하였으나 설치형 블로그의 경우 설정 및 업데이트 등 모든 관리도 자신의 몫이 된다. 솔찍히 귀찮다. 서비스해야 하는 서버가 늘어날 수록 관리의 영역은 또다른 노동이 되어버린다.
 |
| 설치형 블로그의 대표주자인 WordPress, 가입형 블로그도 제공하지만 개인 도메인 (custom domain) 설정시 추가 비용이 발생한다. |
결국 개인적 선호도는 점점 가입형 블로그가 되었고 처음에는 텍스트큐브, 티스토리 등이 있었고 그 중 블로그 서비스가 제공하는 도메인이 아닌 ( userid.tistory.com ) 개인 도메인 ( myblog.meson.kr ) 을 설정할 수 있는 서비스를 선택했다. 다양한 블로그 서비스가 있지만 초반에 생각했던 최소 충족 조건은 다음 정도였다.
a. 개인 도메인 설정 지원 / b. 다양한 템플릿 디자인 제공 / c. HTML / CSS 사용자 편집 가능 / d. 편리한 추가 기능 (통계, 글목록 등) 지원 / e. 서비스의 안정성
정도였다. 초반의 생각은 일단 기능이 많으면 많을수록 좋고 지금과는 생각이 많이 다르지만 다양한 모양새를 지원해주는 편집기도 결정하는데 중요한 요소였다. 당시에 가입형 블로그 서비스는 유행이었다. 수많은 업체들이 존립했지만 그만큼 회사 운영의 어려움 등의 이유로 서비스가 중단된 경우도 많았다. 결국 믿을 수 있는 서비스 업체의 선택도 큰 부분이었다.
블로그 서비스 옮기기
기존 블로그를 사용하면서 다양한 불편함이 발생하면서 오래전부터 옮겨야 겠다고 마음 먹었다가 결국 결심하게 된 결정적 계기는 기존 블로그 서비스에서 XML 백업을 지원하지 않기로 결정했다가 사용자들의 반발로 취소하기로 했던 때였다. 개인적으로 중요하게 생각하는 것은 개방성 (openness) 이다. [ 개방성 - 표준을 통한 산업의 발전은 가능한가 ]
개방성: 사용자 데이터의 손실없이 언제든 플랫폼을 떠날 수 있음을 뜻한다.
이 간결한 정의 속에 인터넷 서비스가 지향해야 하는 방향을 보여준다고 믿는다. 사용자는 언제라도 서비스가 맘에 들지 않으면 떠날 수 있다. 그때 사용자가 만든 데이터는 서비스 업체의 소유가 아니라 사용자에게 제공되어야 하고 그 제공된 데이터는 동일한 서비스 (여기에서는 블로그 서비스) 에 바로 옮길 수 있어야 한다. 즉, 개방성이 보장된 서비스 업체는 표준을 지켜서 타 서비스에서 나온 (exported) 데이터도 쉽게 옮길 수 (importing) 있어야 한다. [문제 해결의 시도]
서비스 업체가 아무리 화려한 기능을 제공해도 표준 (XML) 에 따른 백업 / 복구 기능을 제공하지 않으면 시작하고 싶지 않은 이유가 바로 여기에 있다. 개방성이 존재하지 않는 서비스는 결국 사용자의 데이터를 볼모로 자신들의 서비스를 지속시키려 하기 때문이다.
1. 이전 준비 - 블로그 서비스 선택
우선 설치형 블로그는 제외이다. 요즘 호스팅 서비스에서는 쉽게 설치해주는 경우도 있지만 이 또한 관리의 귀찮음은 존재한다. 결국 가입형 블로그 중 내가 원하는 최소 기능만 제공해 주기를 바라며 구글의 블로거 (blogger) 서비스를 선택했다. 사용해보면 알지만 블로그를 만드는 것은 쉽다.
2. 이전 준비 - 블로그 디자인 선택
아무리 블로그가 공개된 공간이라도 지극히 개인적인 공간이고 개인적 취향을 만족해야 한다. 블로그 디자인의 고민은 몇가지 기존의 불편함과 연결된다. 첫번째는 해상도에 따른 일반 페이지 / 모바일 페이지 문제, 두번째는 과도한 모양새의 지정으로 글에 집중할 수 없는 불편함이다.
결론적으로 두가지 모든 문제를 해결하는 방법은 CSS 를 적절하게 사용하는 것이다. 주요한 키워드는 반응형 페이지 (responsive web design) 이다. 해상도에 따라 일반 / 모바일 페이지를 결정하는 것이 아니라 해상도에 따라서 표현하는 페이지의 포맷 (화면 표시 너비, 블로그 구성 순서 등) 을 변경해 모든 해상도에서 보기 좋은 블로그를 표시하는 동시에 블로그 글의 주소는 항상 동일하다. 결국 모바일이나 고해상도 컴퓨터에서 공유를 해도 동일한 주소를 공유하게 된다.
 |
| 반응형 디자인을 적용하여 모바일 해상도에서 화면 구성만 변경되고 동일한 주소 (URL) 을 가질 수 있게 된다. |
글에 집중하고 싶다는 내용은 실질적으로 이전 (previous) 블로그에서 새로운 블로그로 이전 (transfer) 하면서 실질적으로 발생한 문제였다. 우선 백업한 XML 파일을 블로거에서 지원하는 복구 (import) 하는 방법은 불가능했다. 결국 기존 블로그에서 백업한 XML 파일 내용 중 제목, 본문, 키워드 (라벨) 등의 내용을 추출하였지만 본문 내용에 너무 많은 HTML 코드와 형식 (CSS) 코드가 포함되어 그대로 사용하는 것이 더 어려웠다. 결국 기존 블로그 글을 일반 텍스트 (plain text) 로 추출해서 새로운 블로그에 옮기고 모든 형식 (폰트, 크기) 등이 제거된 체 옮겨지고 새로운 블로그에서 스타일 지정 (CSS) 을 통해서 본문, 제목 등에 따라서 폰트, 크기 등 형식을 정하는 방법을 이용하게 되었다.
 |
| 본문의 모양새 (style) 은 CSS 정의 파일을 통해 편집기에서 모양새 지정을 최소화 한다. |
결국 반응형 웹 디자인 중 블로거 (blogger) 서비스를 위해 설계된 괜찮은 템플릿 디자인을 인터넷에서 구해서 (사실 5 USD 에 구매) 해서 웹폰트 ( [ Google webfont 서비스 ] 및 [ 모빌리스 웹폰트 ]) 를 사용자에게 보여지는 폰트와 크기를 지정하였다. 예전에는 폰트, 크기 등 형식 지정에 꽤 많은 수고를 했지만 옮기는 과정에서 깨달은 중요한 내용이 바로 '데이터' 와 '형식' 의 분리였다.
3. 이전 준비 - 블로그 데이터 이전
기존 블로그 글을 새로운 블로그로 옮겨야 하나 아니면 기존의 글은 그대로 남기고 새로운 블로그를 운영해야 하나 고민을 하다가 결국 옮기기로 결정하게 되었다. 옮기는 과정은 조금 복잡하고 생각보다 손이 많이 가는 과정이었지만 모든 과정이 문제 / 해결 의 과정이었다.
a. 주소 체계의 문제 : 새로운 블로그 서비스로 옮기면 주소를 그대로 옮겨가기 어렵다. 블로그 주소는 일련 번호로 blog.meson.kr/567 과 같이 순차적으로 번호로 주어지는 경우와 제목 내용을 주소로 만들어 blog.meson.kr/this-is-my-blog-article.html 과 같이 만들어 주는 체계가 있다. 블로거 서비스는 후자의 체계만 허용한다. 또한 한글 제목에 대해서는 blog1.html , blog2.html 과 같이 붙여지고 앞에는 년도 와 월이 표시된다. 즉, myblog.blogger.com/2014/09/this-is-my-first-blog.html 과 같은 형태로 붙는다. 우선 기존 블로그 글을 새로운 블로그로 옮기기로 결정했다.
 |
| 포워딩 (forwarding) 주소를 .js 스크립트로 지정하고 이를 Dropbox 에 올려놓아 호출을 한다. 드랍박스의 파일을 편집하고 저장하면 기존 블로그에서 호출하여 이전된 주소로 이동시킨다. |
문제는 바로 이전 주소를 어떻게 새로운 주소로 옮기는가이다. 체계 자체가 다르기 때문에 체계적으로 (systematic method) 알려주는 것은 불가능하다. 결국 prev.blog/420 은 새로운 블로그 new.blog/what-a-wonderful-day.html 과 같은 내용이라는 것을 알려주어야 한다. 이 방법을 해결하기 위해서 javascript 를 이용해서 특정 주소 ( /420 ) 이 호출되면 이전된 새로운 주소로 이동 (forwarding) 해주는 방법을 제공해 주었다. 즉, 이전 주소와 새로운 주소의 데이터를 저장해놓고 이를 스크립트로 호출해서 이동시켜주는 것이다.
b. 이미지 호스팅 문제 : 참고로 기존 블로그의 불편한 점 중 하나는 블로그의 이미지가 표시되지 않아 정말 순진한 곰 한마리가 대신 나온다는 점이다. 이미지가 보조적인 역할을 하기 때문에 개인적으로 이미지가 나오지 않아도 별 문제없지만 자주 발생한다는 것은 서비스의 신뢰도에 영향을 줄 수 밖에 없었다. 또한 기존 이미지 주소는 기존 블로그 서버 주소가 포함된다. 따라서 이미지는 결국 내려받기 해서 새로운 서비스에 올려야 한다.
c. 블로그 데이터 이전 문제 : 결론적으로 옮기는 과정은 다음과 같았다. ① 기존 글을 일반 텍스트 (plain text) 로 추츨 ② 페이지 내 이미지를 모두 내려받아 12자리 랜덤 문자열 (string) 과 일련 번호 ( e.g.: a597UiZBvgcjpjX0shGlrg1y01.jpg ) 로 저장한다. ③ 내려받은 이미지를 구글 포토에 올린다. (구글 포토 / 드라이브 이미지는 블로거와 연동 가능하다.) ④ 일반 텍스트 중 강조 / 이탤릭체 / 인용문 / 링크 등을 지정하고 내려받은 이미지를 한꺼번에 불려들여 원래 위치에 배치한다. ⑤ 기존 주소와 새로운 주소를 스크립트에 저장 ⑥ 제대로 작동하는 확인
 |
| 필요한 이미지를 한번에 올린 후 호출하여 사용가능하다. 구글 포토 서비스에서 관리, 편집 후 변경된 이미지를 사용할 수도 있다. |
글 내용과 이미지 데이터 추출, 이미지의 내려받기까지 자동으로 할 수 있도록 했지만 그 이후 최종 편집 및 확인 과정 그리고 예상하지 못한 문제들 (외부 객체 등) 이 발생하기 때문에 손이 많이 가는 작업이지만 초반 추출 과정을 통해서 링크가 포함되지 않은 글의 경우 2~3 분이면 최종 결과물로 새로운 블로그로 이전할 수 있었다.
블로그를 옮기다 보니 생기는 생각들
무엇보다 '불편함은 변화하게 만드는 원동력' 이란 생각이다. 여기에 언급한 내용이외에도 많은 불편함이 존재했었다. 그리고 찾아보면 그 불편함을 느끼는 다른 사람들, 그 불편함을 해결하려는 사람들, 해결한 사람들이 존재하다는 것을 알게 된다. 필요할 떄마다 그 불편함을 해결하는 것도 필요하지만 때로는 모든 불편함을 모아서 한꺼번에 해결할 수 있는 방법을 찾아내는 것도 필요하다는 생각이 든다. 이전하면서 가장 좋은 점은 나의 데이터가 다른 서비스에도 별 수고없이 이전될 수 있다는 점이다. 그리고 그동안 아무 생각없이(?) 예쁘게 꾸미려고 온갖 폰트, 크기, 줄간격을 강제로 지정했던 일들이 오히려 더 독이 될 수 있다는 점이다.
대학교때 Technical writing 에 대한 강의를 들으면서 그때 논문을 가장 못쓰는 사람은 글을 쓰면서 폰트, 크기 등을 지정하면서 완성시키는 사람이라고 했다. 본문, 대제목, 중제목, 소제목 으로 형식을 지정해 놓고 글을 쓰는 사람이 정말 논문을 잘 쓰는 사람이란 말이다. 왜냐하면 모양새(스타일)는 언제든 바뀔 수 있기 때문이다. 즉, 데이터 (data) 와 형식 (property) 를 잘 구별해서 분리하는 것이야 말로 데이터를 잘 관리하는 사람의 덕목이 된다. 결국 지금 이글도 편집기에서 어떤 모양새도 넣지 않고 그냥 글만 집중해서 쓸 수 있다. 글을 다 쓰고 나면 템플릿 디자인이 알아서 내가 원하는 모양새로 만들어서 표시해주기 때문이다. (CSS 의 가장 기본적 장점)
라벨 (키워드) 의 문제를 생각한다. 현재는 ▨몽달이생각, ▨일상다반사, ▨사람들생각, ▨시스템잡설 의 네가지 범주로 나누었다. 그러나 블로거 서비스에는 별도의 범주가 없다. 모두 라벨 (키워드)로 표현된다. 결국 글 안에도 이 네가지의 범주를 포함시킨다. 네가지의 구분 기준은 글을 쓰게 만든 원천 (source) 가 어딘가이다. 각각 개인적 생각, 일상의 대상 (object), 다른 이들의 생각, 시스템 & 기술적 내용이다. 그러나 이와 별도로 글의 주제는 따로 존재할 수 있다. 이를 위해 라벨에는 네가지의 범주와 함께 글의 주제를 같이 표현하였다. 예를 들어 '정치의 동물' 이란 주제어는 몽달이생각을 통해 복지에 대한 정치경제적 생각을 표현할 수도 있고 다른이들의 의견을 통해 의견을 표시할 수도 있고 내가 오늘 경험한 일상에 대한 내용으로 표현할 수 있을 것이다. 이처럼 범주와 다르게 글의 중심 주제를 통해 범주와 상관없는 주제 글들을 모을 수 있도록 했다.
 |
| 해당글의 주제와 동일한 다른 글을 볼 수 있다. 페이지 아래 Related Posts 를 통해서도 볼 수 있다. |
항상 생각하는 것이지만 블로그 서비스의 폐쇄성, 혹은 강제성은 사용자 (최소한 필자) 를 불편하게 만든다. 앞서 예를 들었던 것과 같이 원하지 않는 검색 순위를 넣는 것, 관련 회사의 서비스를 강제로 사용하도록 만드는 것, 외부 검색 엔진에서 검색이 되지 않도록 막는 것 등을 생각할 수 있다. 누군가는 무료로 사용하기 때문에 그것은 당연하다고 할 수 있다. 만약 모든 서비스가 그렇다면 개인적으로 일정 금액을 지불하서라도 그 폐쇄성, 강제성을 나오려 할 것이다.
요즘은 어떤 블로그도 대부분 광고를 붙여 놓고 있다. 그런 개인적 선택에 특별히 나쁘다라고 판단할 수 없다. 개인의 선택이기 때문이다. 처음 블로그를 시작했던 2004년 6월부터 항상 지향했던 한가지는 블로그는 누군가에게 보여주고 싶은 내 글이기도 하지만 내가 만들고 싶은 '항상 진행중인 완성품'이란 생각이었다. 매 글이 하나의 완성품이고 그렇지만 인간의 불완전함에 완성될 수 없는 부족함을 계속해서 다른 글로 채워가는 그런 공간 말이다. 그냥 개인적으로 그런 의미의 공간에 광고가 들어가는 것이 싫었을 뿐이다.
혹시 블로그 서비스를 이전하고 싶은 분들에게 도움이 되기를... 바라는 마음에 그동안 블로그 옮기는 과정에 정리했던 작업 일지 (workflow log) 를 정리해서 하나의 글로 여기에 정리한다. + 어떤 의미에서 새로운 블로그에 대한 짧은 가이드 북이 될 것 같다.
글 잘 봤습니다. 덕분에 저도 블로거에서 새로 시작하게 됐네요. 감사합니다. ^_^
ReplyDelete대공사 하셨군요.
ReplyDelete티스토리 이용자인데 요즘 티스토리 블로그 서비스 지속성에 대해 말들이 많아 혹시나 하고 다른 블로그 서비스 둘러보는 중입니다.
가장 큰 문제는 아무래도 주소라고 생각됩니다. 검색해서 오는 분들이 엉뚱하게 접속되지 않으면 큰 일이니까요.