[첫화면으로]블로그포스트저장방식

마지막으로 [b]

블로그 포스트 저장방식에 대해1


"김중태 문화원"이라는 사이트의 문서 중에 "1.3. 블로그 용어" (http://www.help119.co.kr/blog/archives/000042.html) 페이지의 1.3.4 절을 보면 다음과 같은 말이 있습니다.

"지금까지의 블로그 프로그램은 새 글을 쓰면 각각의 문서가 하나의 독립적인 HTML 문서로 저장됩니다. 따라서 이들 문서는 다른 HTML 문서처럼 고유한 주소를 가지게 됩니다. 이 점은 제로보드 게시판의 게시물이 DB의 게시물 번호로 지정되는 점과 다른 점입니다. (중략)

... 블로그는 글을 저장할 때 일반적인 HTML 문서 양식으로 저장합니다. 이 때문에 100개의 글을 작성했다면 100개의 독립적인 HTML 문서가 만들어집니다. 따라서 글을 쓸 때는 블로그 프로그램을 사용했지만 각 게시물을 읽을 때는 프로그램이 필요 없습니다. 웹브라우저 프로그램으로 그냥 주소를 입력해 HTML 문서로 읽으면 됩니다.

이처럼 블로거가 작성한 글 하나하나마다 독립적으로 완성된 문서로 작성하고 주소를 부여함으로써 문서의 활용성을 크게 높였습니다."

당장 위 글의 주소만 봐도 .....archives/000042.html 로 끝나서 개별 html 파일로 저장되었다는 것을 알 수 있습니다.

초창기 블로그 툴이 어떻게 했는지는 모르겠습니다만 현재는 위와 같지 않은 블로그들도 많습니다. [태터툴즈]의 경우 MySQL DB에 포스트를 저장하고 각 포스트는 ......tt/index.php?pl=13&nc=1 와 같이 index.php 뒤에 pl= 의 숫자가 서로 다르게 부여되는 식으로 주소가 구성되어 있고, [이글루스]를 비롯한 많은 블로그 포털 사이트의 경우는 .......egloos.com/426307/ 와 같이 뒤에 일련번호만 적혀 있습니다. 포털 사이트의 글 저장 방식은 모르겠지만 아마도 역시 DB에 저장을 하지 않을까 싶습니다2.

위 김중태 문화원의 주장과는 달리 저는 이런 저장방식의 차이는 어느 한 쪽이 좋다3고 말할 것이 아니라 각기 장단점이 있다고 생각합니다.

예를 들어, html 방식으로 저장될 경우 특정한 글(즉 특정한 html 파일)만 다른 곳에 복사해서 써먹을 수 있다던가 하는 장점이 있지만, 매 글마다 동일한 부분 (상단 로고라던가 하단 배너, 옆의 메뉴 등) 이 중복되어 저장되므로 하드의 용량을 차지하겠죠. 반대로 DB 를 쓸 경우 오직 글 내용만 DB에 저장하고 메뉴 등은 한 번만 저장하면 CGI가 매번 써먹을 수 있으니 용량을 아낄 수 있을 것이고, 내용 검색 시 html 파일들을 일일이 열어서 텍스트 서치를 하는 것보다 DB의 검색 기능을 사용하는 것이 훨씬 효율적일 것입니다. (물론 뒷받침하는 DB가 제대로 된 검색 기능을 제공할 때 얘기지만)

여담으로 "이정환 닷컴"의 [무버블타입과 정보의 가치]라는 포스트에서는 "구글이 html 파일만 검색하지 제로보드와 같이 DB에 저장하는 글들은 검색을 안 해준다, 따라서 html 파일로 저장되는 블로그가 정보 공개와 공유에 더 효과적이다"라는 이야기를 하는데, 저는 과연 그런가 의심스럽습니다. (근데 확실히 KPUG 이나 클리앙 등의 게시물이 전혀 구글에서 검색되지 않는 것은 좀 희한하네요)

여기까지가 제가 평소에 생각해 왔던 겁니다.

그런데...

KPUG의 [백승민님의 글]을 보면 어느 인터넷 신문 사이트의 기사에서 백승민님의 블로그 포스트 하나를 링크해 버리는 바람에 갑자기 접속자가 급격하게 늘어나서 결국 트래픽 초과로 접속불가 상태가 되었다고 합니다.

생각해 보니, 이런 경우에 백승민님이 취할 수 있는 조치가 없습니다! 설령 해당 포스트를 삭제한다 하더라도 어쨌든 백승민님의 그 포스트 (....../tt/index.php?pl=326&nc=1, 태터툴즈로군요) 를 클릭하면 일단 태터툴즈 CGI 스크립트인 index.php 가 불리게 되고, 따라서 최소한의 데이타가 전송이 됩니다. 제 계정에 설치한 태터툴즈로 테스트해보니 존재하지 않는 글을 보려 할 경우 본문에는 그냥 "다음 페이지, 이전페이지"만 나오고 옆에 로고와 메뉴, 최근 댓글과 트랙백 등은 고스란히 나오는군요. 원래 글이 통채로 전송되는 것에 비하면 작은 양이긴 하지만, 이런 작은 데이타라도 계속 전송되면 가랑비에 옷 젖듯이 결국은 트래픽 제한에 걸릴 수밖에 없겠죠.

결국 태터툴즈를 통채로 삭제하거나 디렉토리 주소를 바꿔버리지 않는 이상은 앞으로도 한동안 백승민님의 사이트는 "미디어 다음"이나 기타 뉴스 포털, 또는 원래 기사가 올라온 도깨비뉴스를 따라 들어오는 사용자들에 의해 트래픽 초과 상태를 매일 겪게 되지 않을까 싶습니다.

하지만 만일 백승민님의 블로그가 제일 처음 얘기했던 것처럼 각 포스트가 *.html 로 저장되는 방식이었다면? 그러면 단지 문제의 그 html 파일만 삭제하면 됩니다. 그러면 타인이 그 링크를 클릭해도 웹서버 차원에서 404 Not Found 에러를 낼 겁니다. 이런 경우는 트래픽 계산에 포함하지 않는 것으로 알고 있습니다. 그러면 문제의 글을 찾아온 사람들은 좀 실망하겠지만, 다른 글들은 전혀 지장없이 볼 수 있겠죠.

요즘처럼 인터넷 사용자가 많아서 링크 한 번 잘못 걸리면 (위와 같은 경우나, 디씨인사이드, 하다못해 클리앙 정도에 올리는 것도) 어느 순간 자기 홈페이지에 하루에 수만명이 접속하는 사태가 발생할 수 있고, 웬만한 호스팅 업체의 경우 트래픽 제한을 두고 있는 것을 생각하면, 게다가 자기 홈피를 남이 링크하는 것을 자기가 막을 방법이 없다는 것을 생각하면 이것은 꽤 진지하게 고려해 봐야 하는게 아닌가 싶군요.

P.S. 제가 웹호스팅을 받은 적이 없어서.... 혹시 제가 알고 있는 것과 달리, 웹호스팅 업체의 트래픽 제한 규정은 웹서버 에러 메시지도 트래픽으로 간주를 할지도 모르겠네요. 만일 그렇다면 지금까지 한 얘기가 전혀 의미가 없어집니다만.. -_-;;; 아시는 분은 정확히 리플 좀 달아주세요.

P.S.2 저는 예전에는 학교 전산실 계정을 썼고 지금은 돈 좀 더 들이더라도 그런 제약 없이 살아보자는 생각에 제한 없는 서비스를 사용 중이라 이런 걱정 없습죠. 히히히 :-)

관련하여, 이런 글들이 있군요.
-- Raymundo 2005-3-31 3:29 pm

순전히 제 추축입니다만, 제로보드의 게시물 목록 페이지에 링크된 각 게시물의 URL이 너무 복잡하기 때문에 Page Rank를 조작하려는 시도로 해석되어 검색에서 제외되는 것은 아닐까요? 구글이 중요한 검색 엔진이고 보드류의 게시물에도 쓸만한 정보가 많으므로 구글이 바뀌거나 보드가 바뀌거나 해야 할 것 같습니다. 그리고 검색 엔진 입장에서 본 블로그의 트랙백 기능은 어떤가요? 계속 구글의 예를 듭니다만, A 페이지를 B 페이지를 링크한 경우를 일종의 투표로 보더군요. 중요한 정보이므로 링크했다라고 보는 것은 합리적인 것 같습니다. 트랙백은 이와 반대로 트랙백을 보낸 페이지의 URL이 트랙백을 받은 페이지에 노출됩니다. 결국 페이지 스스로 자신에게 투표하는 형국이랄까요? 문득, 트랙백을 이용하면 협력자 없이도 구글 폭탄 놀이를 할 수 있을 거라는 생각이 드네요. ;-) 정보 저장 형식보다는 서로 어떻게 링크되냐가 더 근본적인 문제인 것 같습니다.
-- NovaKim 2005-3-31 7:12 pm

그럴 수도 있겠죠. 방금 구글에서 명시적으로 site:kpug.net을 주니까 몇 개 찾아주긴 하네요. 그리고 트랙백을 무차별적으로 보내어 자신에게 향한 링크를 늘린다...(물론 나중에 욕은 무지 먹겠지만 ^^) 이것도 조만간 성인사이트들을 선두로 나올 것 같기도 하군요. 위키를 타겟으로 한 UseMod:WikiSpam처럼요.
-- Raymundo 2005-3-31 11:06 pm

이름:  
Homepage:
내용:  

컴퓨터분류 잡담분류
각주:
1. KPUG에 Raymundo가 올렸던 [글]을 정리해서 다시 올립니다
2. 다른 분들의 지적에 따르면, 대형 웹사이트의 경우는 DB와 html로 각각 저장을 하고 일단 html 로 보여준다고 하는군요. cache 같은 거겠죠
3. 몇 년 전의 개인 홈페이지들은 전부 일일이 html 파일을 만들어 저장했었는데, 그럼 그 이후의 제로보드 류의 CGI들은 전부 "더 나쁜" 쪽을 택했다고 말할 수 없는 거죠

마지막 편집일: 2012-2-11 12:25 am (변경사항 [d])
2255 hits | Permalink | 변경내역 보기 [h] | 페이지 소스 보기
0.111 sec 처음으로 [t]