Movabletype의 아카이브를 스태틱페이지로 만드는 것의 장점은 무엇일까. 대부분의 블로그툴은 데이터는 DB에 두고 블로그프로그램이 DB에 가서 엔트리의 내용을 긁어다가 화면에 뿌려주는데 반하여 무버블타입은 완전히 완성된 형태의 HTML문서를 생성해둔다. 즉 블로그프로그램을 거치지 않고 바로 그 HTML문서를 읽어올 수 있도록 되어있는데. 이것이 블로그가 개인에 의한 퍼블리싱이라는 개념에서 본다면 독자적인 HTML문서를 퍼블리싱한다는 의미는 있을수 있겠다. 그러나 이것이 문서를 읽는 사람에게는 어떤 차이점이 있을까. cgi를 한번 거쳐서 화면에 뿌려지는 문서와 순수한 html 문서를 불러오는 것이 그 블로그 사이트를 방문한 “나”에게 어떤 “다른 의미”가 있을수 있겠는가. A라는 무버블사이트에 있는 문서(ㅇㅇㅇ.html)을 다른 블로그툴에서도 완벽하게 같은 모양으로 만들어 낼 수가 있다. 다만 XXX.cgi?id=ㅇㅇ 과 같은 식으로 디비에 있는 자료를 끄집어 내오는 쿼리가 덧붙는다는 점을 제외하고는.
스태틱한 페이지를 읽어오는 것과 다이나믹한 페이지를 만들어 내는 것이 브라우저상에서 내용을 출력하는데 아무런 차이점이 없다면, HTTP가 HTML문서를 브라우저로 전송하기 위한 방법임을 고려해볼때 이 두가지 방법은 “차이가 없다”는 결론을 내려도 무방하지 않을까 싶다. 물론, 브라우저로 보내기 위해서의 내부적인 방법에는 차이가 있다. 내가 말하고자 하는 바는,
1. 보여지는 모습과 보이지 않는 모습.
– 입력양식에 차이가 없다. – 제목필드,내용필드 등의 입력폼을 이용하는 것에서 같다.
– 출력양식에 차이가 없다. – 주소창을 가리고 두개의 문서를 비교했을때 어느것이 HTML문서를 읽은것이고 어느것이 DB에서 꺼내온것인지 구별할수 있을까?
적어도 나는 구별을 할 수가 없다. 그리고 MT와 다른 블로그툴이 어떻게 입력/출력에서 “사람에게 보여지는 모습”이외의 부분에서 우위에 있는지도 확신할 수가 없다.
MT는 파일로 출력파일을 보관하고 (DB에 데이터는 들어있으나 화면에 보이는 것은 미리 만들어둔 HTML문서), 다른 프로그램은 DB에서 그때그때 긁어다가 HTML문서를 만들어서 보여주는데, 이 두가지 방법 모두 “효율적 자원의 이용”의 측면에서 장단점이 있다.
– HTML을 미리 만들어둔 경우 : 문서를 열때 이미 만들어진 문서를 보여주므로 문서를 생성하기 위한 컴퓨팅파워를 소모하지 않는다. 그러나 디스크공간은 상대적으로 많이 사용한다.
– DB에서 읽어오는 경우 : 엔트리의 데이터등 필수항목들은 DB에 두고 그때그때 불러와서 나머지 공통으로 쓰이는 파일에 덧붙여 문서를 생성해낸다. 하드공간의 절약. 그러나 CGI가 돌아야하므로 컴퓨팅파워의 소모.
이 두가지 경우 모두 “디스크가 낭비야!” 또는 “컴퓨팅 파워가 딸려!” 라고 하기엔 그 차이점이 미미하다. 하드웨어 가격이 워낙 많이 내려갔으므로.. (프로그래머 고용해서 프로그램과 디비 튜닝하느니 CPU랑 메모리 늘이는편이 싸게 먹히는 경우가 허다하다.) 두가지 방법 사이에 미미한 차이는 있겠지만 “그래서 어느쪽이 더 낫다”라고 할 정도까지의 차이는 사실상 없다고 봐도 무방하다.
2. 퍼머링크에 대해서.
/archives/0001.html 이라는 퍼머넌트 링크는 index.php?p=1보다 사실 보기에 좀 좋다 -_-;; (인정.)
퍼머링크는, 각 엔트리의 불변의 주소다. 즉 그 엔트리를 외부에서 참조할때 언제 어디서든 변하지 않는 링크라는 의미다. 그렇다면 CGI프로그램의 위치와 이름이 변하지 않고 엔트리의 고유번호가 변하지 않도록 조합한 것 또한 퍼머링크로서의 자격이 충분하지 않을까. 오늘 이 글이 http://사이트주소/index.php?id=1 이었다면 1년뒤에도 2년뒤에도 그리고 10년뒤에도 저 주소가 유지되면 되는것 아니냐는 말이다. 퍼머링크가 고정적인 html문서를 지칭하는 것이 아닌 변하지 않는 URI를 지칭하는 것이라면 제로보드 역시 퍼머링크를 가지고 있다. 아직까지 CGI 프로그램이 망가져서 페이지가 날아간 경우를 거의 보지 못했다. 사용언어의 버젼이 올라가면서 펑션의 사용법이 달라져서 그런 경우는 간혹 있긴하다.
오히려 퍼머링크를 깨지게 하는 가장 큰 이유는 CGI에서 이상하게 변경시키는것보다는 그 사이트(블로그)의 운영자가 블로그의 주소 자체 또는 디렉토리를 변경하거나 또는 폐쇄하는 경우가 더 흔하지 않던가. 어느 사이트로의 퍼머링크를 알고 있었는데 어제는 됐는데 오늘은 안되는 경우라면 CGI가 어떻고 html이 어떻고의 문제가 아닌, 호스팅비를 안냈거나 폐쇄했거나 DNS가 맛이 갔거나 블로그를 지워버렸거나 뭐 등등.. 그런 이유가 아마 99.9999999999999999999999999999%일 것이다.
즉, 퍼머링크의 permanent url 을 유지시켜주는 것은 그 url이 html파일인지 cgi+인자의 형태인지에 좌우되는 것이라기 보다는 운영과 마인드에 영향을 받는 항목으로 봐야한다.
3. 검색엔진이 얼마나 이해하기 쉬운가.
검색엔진이 html페이지를 cgi보다 더 잘 이해한다는 증거가 나에겐 없다. 어느 문서건 링크만 잘 걸려있다면 구석구석 잘 파헤집고 다닌다. 다만 블로그의 특성상 링크를 포함한 문서가 많고, 블로그 툴 중에 MT가 많이 사용되고 있으므로 구글의 검색결과에 상단에 링크될 확률이 높은게 아닌가 하고 추측된다. 구글의 페이지랭크에서 참고로하는 형태가 바로 블로그처럼 글 본문중에 사이트방문 기록(링크)를 포함한 문서이다. Optimizing your MovableType blog for Google에서 말한것처럼 링크의 텍스트가 링크된 페이지의 내용중에 포함되도록 하면 더욱 구글에 노출을 늘일 수가 있는데, (방금 링크한 페이지의 주소를 보라. 숫자.html의 형태가 아닌 엔트리의 제목이 파일이름으로 설정되어있다.) 예를 들어 꽃미남hof 라는 문장에 링크를 걸고 저 링크를 따라갔을때 꽃미남hof라는 텍스트가 검색이 된다면 구글의 페이지랭크에서 유리하게 작용한다는 말이다. “여기”를 누르세요. 하는 것보다는 명확하게 요약된 링크의 텍스트를 제공하는 편이 낫다는 뜻이다. 앞에 언급한 문서에서는 그래서, 아카이브에 쌓인 엔트리의 파일명을 엔트리제목.html로 변경하기를 권장하고 있는데, 한글제목을 쓰는 경우에는 그다지 효과가 클것 같지는 않다. 다만, CGI를 사용하는 블로그 툴은 이 방법이 사실상 불가능하다. (가능이야 하겠지만 엄청난 삽질을 필요로 할듯.)
결론적으로 블로그 자체의 특성상 링크를 많이 포함하고 있고 (포탈의 펌질블로그는 열외! 바쁘실텐데 얼른 가서 계속 저작권침해나 하시오.) 구글의 랭킹시스템에 적합하도록 내용을 작성하고 툴을 최적화 시킬수 있는 방법이 있는 MT는 검색엔진에 대한 노출면에서 다른 블로그툴보다 유용하다. 단, 한글제목을 사용하였을때는 그 효과를 보장할 수 없다.
이 글을 쓴 이유는 MT가 샘나서가 아니다. -_-;; html 문서를 생성해내는 MT의 블로그 퍼블리싱 방식과 퍼머링크에 대해서 나름대로 생각해본 결과를 정리해둔 것이며 미처 내가 깨닫지 못한 다른 뭔가가 있는지에 대해 다른 분들의 의견을 듣고 싶을 뿐이다.
MT만세!! -_-); b2도 만세 -_-;;
블로그를 이용하면서 많이 고심한 부분이 툴의 선택이었죠.
이제는 그런 고민은 버렸습니다.
툴은 툴일 뿐… 내가 아니죠~
저도 비슷한 생각입니다. 꼬물컴터에 리눅스 깔고 블로그를 쓸려다 보니, 정적페이지 생성하는 MT를 깔게 됐지만, 여친 블로그 만들려고 태터툴즈도 설치하게 됐는데…MT하고 속도차이는 느낄 수 없더만요.(저사양이라 걱정했건만.) 오히려 관리메뉴에서 MT가 훨씬~ 느려서리 불편…
결론은 그냥 편한거 쓰는게 좋다는 생각입니다.
이건 정답이 있는 게 아니라, 취향의 선택이죠. 내가 커피를 좋아한다고 녹차보다 커피가 절대적으로 뛰어난 맛을 지녔다고 할 수 없는 것처럼.
html과 php(DB방식)은 얼핏 보기에는 비슷해보입니다. 하지만 당장 눈에 보이지 않지만 확장성과 가능성이라는 점에서는 많은 차이가 있습니다. HTML은 문서 하나 자체가 완성된 것이므로 해당 문서 하나의 내재된 가능성이 훨씬 큽니다. 반면 DB의 글 하나는 그 자체로는 완성되지 않은 DB의 일부이며 항상 프로그램에 의존해야 하는 의존성을 가지고 있습니다. 그런 면에서 템플릿을 이용해 원하는 형태로 완성된 HTML을 만들어주는 MT의 기능은 사실 알고보면 무서운 기능이 될 수 있습니다. ^^;
김중태// 가슴에 안 와닿아요 -_-;; DB의 글 하나가 완성되지 않은 DB데이타지만 html형식이건 cgi를 이용하건 결국 “브라우저에 출력이 되어야” 존재의미(?)가 있는게 아닌가 해서 말이지요. cgi프로그램을 사용하는 것은 한정된 자원을 효율적으로 사용하는데에도 도움이 된다고 생각하는데요. cgi프로그램의 의존(또는 이용)하는 것이 어떤점에서 안좋은지 납득할 수 없습니다. -_-;; cgi 망가져봐라! 라는 경우는 “망가진적 없는데요;;”라는 대답이 가능할것 같구요. 오프라인브라우징이나 아카이브백업같은 경우라면 오프라인브라우징이야 다른이름으로 저장-_-을 해도 되고 백업은 db백업을 하면되고…(webzip으로 긁어도 되네요 -_-) 무엇보다도… 다른 수많은 웹문서들은 cgi방식을 이용해도 되는데 왜 블로그는 html 퍼블리싱이어야 하는가. 또는 왜 그방식이 우월한가 라는 질문이 가장 원초적인 의문점입니다.
초기에 만들어졌던 웹페이지들은 메모장으로 만들어졌고 이후에는 점차로 cgi와 db를 이용해서 만들어지는 비율이 높아지고 있는데요. 아마 점차 그 비율은 높아지겠지요. 우리가 보는 뉴스사이트,포탈,제로보드,유머사이트..아무튼 보이는 대부분의 사이트가 cgi로 다이나믹하게 사용자의 요구에 따라 만들어주는 페이지인데, 왜 유독 블로그는 html …형태의 존재방식이 의의가 있다(고 주장되어지)는 것인지….
블로그가 퍼블리싱..이라는 개념이 있는 것은 사실이지만 그것이 스태택한 페이지를 생성해야한다는 결론을 내리는 것은 다소간의 (블로그계(?)의)정치적 편향이 아닐까 생각해봅니다. cgi는 안된다. html이어야 된다는 말은 없지만 html이 더 우월하다는, 더 강력하다는… 실례를 찾을수가 없어서 그렇습니다.
1. cgi가 효율적이라는 점에 동감합니다.
2. html 방식이 cgi 방식보다 우월하다고 말할 수 있는 것은 아니죠. 목적이 다른 것이니까요. html의 장점은 cgi의 단점이고, cgi의 장점은 html의 단점이니 어느 쪽에 중점을 두느냐에 따른 차이가 있을 뿐입니다.
3. 그러므로 블로그가 정적 문서를 만들어야 할 이유도 없고, html으로 만드는 블로그 도구가 더 우월하다는 것 역시 맞다 할 수 없습니다. html로 만들어서 좋은 점이 있다면 그로 인해 발생하는 단점도 있으니까요. 특히 대부분의 사용자에게는 MT의 html 발행보다는 cgi 방식이 더 효과적인 편입니다.
hof님 의견에 모두 동감합니다.
그럼에도… MT의 html 문서발행 방식은 신선하고 충격적인 방식입니다. 의문은 발행 방식에서 왜 정적 문서를 채택했느냐가 아니라 왜 블로그에서 발행방식을 채택했느냐 하는 점이죠. 이 점에 대해서는 좀더 정리할 것도 있고 글이 길어질 것 같으니 나중에 따로 글을 작성해 제 의견을 말하도록 하겠습니다.
제 생각은,
html 문서발행의 방식은 신선하고 충격적이긴 하나, 효율적이진 못하다.
라고 정리해서 말씀드립니다. ^^
위의 코멘트들도 결론은 그러한 방향으로 흘러가고 있군요.
포스트당 한개의 html, 그것들을 관리하기 위한 관리툴의 필요성.
한 단계 더 진행시켜서, DB 에서 바로 읽어서 동적으로 웹브라우저에 뿌려주는 대신에, 하드 디스크에 그 뿌려주는 결과를 문서로 저장하여 문서를 뿌리는 것. end user 에서 결과물을 눈으로 보여줄 수 있는 것 말고 어떠한 큰 효과를 볼 수 있는 지는 좀 더 생각해 봐야겠습니다.
맞는 비유일 지는 모르겠지만 html 로 만들어져서 저장되는 순간, 이미 가마속에서 구워진 도자기가 되어버리는 건 아닌지 모르겠습니다. 보기에는 이쁘지만 유연하지 못한.
제가 써본걸로는.
wordpress 의 .htaccess 를 이용한
permalink 도 구굴 엔진에 잘 등록 됩니다..(무버블 타입처럼요)
뭐 기타이상한엔진들 네이트나-_- 하자아인가 하는엔진에서도 많이 서치가능하더군요..
어쩌면 무버블 타입을 쓰지 않는게 더 좋을지도 모릅니다.
무버블 타입의 경우 지나친 노출로 인해서
지운 엔트리도 50개 이상 입니다-_-;
Pingback: 김중태문화원 블로그
Pingback: GyparkWiki
GyparkWiki님이 보낸 트랙백 주소 입니다 (서치로 발견…)
허억, GyparkWiki의 주인장인 Raymundo입니다. 트랙백을 보낸 후 따로 트랙백 신고를 할 것 까지는 없다 싶어서 리플을 따로 안 달았는데, 지금 와 보니 URL에 한글이 들어가 있는 경우 제대로 처리되지 않는군요. -.-; mylook님 감사합니다.
어쨌거나 저 트랙백의 요지는, html 방식과 cgi 방식의 차이점들은 거의 대부분 어느 한쪽이 좋다기보다는 서로 장단점으로 작용하는 건데, 포스트 하나가 어떤 이유로 (유명한 곳에 링크가 걸린다던가) 방문객이 너무 많아서 금방 트래픽 초과를 일으키는 경우, html 방식은 그 html 파일만 지워서 404에러를 발생시키면 되지만 cgi 방식은 결국 cgi 프로그램이 호출되어 “페이지 없음” 메시지가 출력되니 여전히 트래픽 초과를 막을 수 없다….는 경우가 있을 수 있겠다는 거였습니다. 🙂
Pingback: alogblog