permalink에 대한 진실과 오해 permanant한 퍼머링크에 대한 딴지.
안그래도 저도 요즘 비슷한 주제에 대해 연구중이라 (계속 관심사가 겹치는군요. :)).
일단, 저로서는 "퍼머링크"에 대한 말장난이 이렇게 심각(?)해 진 부분의 일정량은 계통발생중에 중구난방으로 진화해버린 블로그툴들 덕분에 블로그의 엔트리체계가 표준화되지 않아버렸기 때문이라는 생각이 드네요.
작성하신 글에 일정부분 동의하면서도 지적하지 않을 수 없는 것이, 블로그의 기본 엔트리 체계를 Individual Archive에 한정지었을 경우(그리고 국내에서 대부분 사용하는 방식인 한 화면에 한개의 individual entry만 보여줄 경우)에만 유의미한 내용이라는 점입니다.
Individual Archive란 상당히 뒤늦게 나온 개념입니다. 그 전까지는 말그대로 log형태를 띄고 있어서 여러개의 엔트리가 하나의 페이지로 묶여 있었고, 이 각각의 엔트리에 대한 참조링크로 퍼머링크라는 개념이 필요하게 되었다고 봅니다.
메인의 인덱스에 일단 엔트리가 게시되고, 적절한 시간(혹은 게시물의 갯수)이 지나면 해당 엔트리는 메인에서 내려와 archive로 넘어가는 블로깅 메커니즘이 일반적이었던 "그 옛날"에는, 메인에서 내려와 archive로 넘어가더라도 해당 엔트리를 찾아갈 수 있는 "고정된 참조주소"의 필요성이 있었습니다. 여기에서 퍼머링크라는 말이 나오게 된거죠.
잠깐 삼천포로 빠져서, 블로그가 CMS로 활용될 수 있는 가장 좋은 장점이면서 동시에 치명적인 단점이 되는 것이 바로 이 archive라는 존재라고 봅니다. archive라는 개념은 기존의 bbs 시스템과는 달리, 각각의 엔트리에 대한 수직 위계 체계가 아니다보니, 각각의 엔트리의 위치를 애매하게 만드는 주범이 되는거죠. 한 개의 엔트리는 특정 category archive에 속할 수도 있고, 특정 monthly archive에 속할 수도 있습니다. blogger.com 처럼 월별 아카이브를 기본으로 하는 경우라면 큰 문제가 되지 않지만, MT처럼 복수의 archive에 동시 인덱싱/저장되는 경우에는 이 엔트리가 과연 어디에 위치하는 것으로 보아야 하느냐.. 라는 점이 걸리게 되죠. 그래서 MT에서는 "기본 아카이브 형식"을 1가지 지정하도록 되어있습니다. 그게 퍼머링크의 주소체계를 결정짓는데 필요하기 때문이지요.
말씀하신 subject를 이용한 주소체계는 유감스럽게도, 제가 보기엔 역시 pretty link의 범주에서 벗어나지 못한다고 봅니다. 일단 소소하게 지적해보자면, 확장자와 관련된 설명은 무의미한 것 같네요. 어차피 CGI를 쓰든 mode_rewrite든 할거라면, 역시 마찬가지로 웹 서버의 MIME타입을 변경함으로써, .html확장자로 php든 asp든 돌릴 수 있으니까요.
요컨데, 정적으로 빌드되었든, 동적으로 뿌려주든, php든, xml이든, abcdefg.html이 해당 문서를 보일 수만 있으면 된다는 뜻입니다.
거기에 파일이름이 한글이냐 의미를 알 수 없는 숫자냐.. 는 별 논란거리가 안될 것 같습니다. rebuild되더라도 주소체계가 고정될 수 있는 작성시간을 기반으로한 주소명이라면 아무 상관없지요. 제안하신 주소체계(http: //alogblog.com/alog/archives/2005/03/Permalink에_대한_진실과_오해_permanant한_퍼머링 크_만들기/) 역시, "/2005/03/"이라는 작성시간 기반 주소명 때문에 유효한 것이지, 그 다음에 이어지는 subject를 이용한 체계는 숫자아이디를 이용한 체계보다 이해하기 쉽고 검색엔진에 잘 노출되며 기억하기 쉽다는 점을 제외하고는 본질적으로 다를 바가 없습니다.
이미 작성시간 기반의 archive와 그 주소체계의 유효성은 블로그계에서 많이 논의된 내용이지요.(제가 그렇게 쓰지 않는 이유는 순전히 귀찮음 때문입니다. :))
여기에 말씀하신 툴의 교환... 등의 문제가 개입되게 되면 정적 build 타입의 진가가 발휘됩니다. 툴을 교환하든 DB가 날아가든, 일단 build된 문서가 서버에 남아 있는 한, 그 문서는 계속 예전의 그 주소 그대로 접근할 수 있다는 뜻이지요. 이게 오히려 permalink의 원천적인 의미에 더 근접한 예입니다. WP등의 동적 블로그툴들이 "진정한 permalink"를 제공하지 못한다는 비난의 이유입니다.
물론, 제안하신 주소체계 방식을 이용한다면 동적 블로그툴들도 DB를 날려먹지 않고 툴간 임포트/익스포트가 성공한다면 "permalink"를 유지할 수 있겠죠. 그러나 정적 블로그툴들에서는 별 의미없는 이야기입니다.
결론적으로 말하자면, 현재의 퍼머링크들은 완벽한 퍼머링크라고 할 수 없습니다. 그나마 가장 근접한 정적 툴들의 build된 문서조차 말이지요.
제가 생각하고 있는 것은 문서와 서비스의 분리입니다. 각각의 "문서"는 "리소스"들이 모여 publish되며, 이 "문서"의 syndicate는 "서비스"를 통해 제공되는 것..
그러기 위해서는 각각의 문서는 XML포맷(또는 그에 준하는 무언가)으로 archive에 영구히 저장되고, 이것을 html로 변환하여 웹으로 보여주는 서비스, pdf로 변환하여 인쇄하는 서비스, 다른 형태의 XML로 변환하여 machine-feed로 제공해주는 서비스 등등...의 집합이 차후 발달된 블로그 - CMS툴의 모습이라고 예상됩니다. DB와는 별도로 original document로써 XML을 사용하고, DB는 이 XML 문서들에 대한 인덱싱용으로 쓰고, 버전관리가 포함되면 퍼머링크 문제는 해결되지 않을까 생각합니다.
(실은.. 이런 걸 만들어 볼까 하고 있어서 끄적대봤습니다. - 만우절 농담. ^_^)
안그래도 저도 요즘 비슷한 주제에 대해 연구중이라 (계속 관심사가 겹치는군요. :)).
일단, 저로서는 "퍼머링크"에 대한 말장난이 이렇게 심각(?)해 진 부분의 일정량은 계통발생중에 중구난방으로 진화해버린 블로그툴들 덕분에 블로그의 엔트리체계가 표준화되지 않아버렸기 때문이라는 생각이 드네요.
작성하신 글에 일정부분 동의하면서도 지적하지 않을 수 없는 것이, 블로그의 기본 엔트리 체계를 Individual Archive에 한정지었을 경우(그리고 국내에서 대부분 사용하는 방식인 한 화면에 한개의 individual entry만 보여줄 경우)에만 유의미한 내용이라는 점입니다.
Individual Archive란 상당히 뒤늦게 나온 개념입니다. 그 전까지는 말그대로 log형태를 띄고 있어서 여러개의 엔트리가 하나의 페이지로 묶여 있었고, 이 각각의 엔트리에 대한 참조링크로 퍼머링크라는 개념이 필요하게 되었다고 봅니다.
메인의 인덱스에 일단 엔트리가 게시되고, 적절한 시간(혹은 게시물의 갯수)이 지나면 해당 엔트리는 메인에서 내려와 archive로 넘어가는 블로깅 메커니즘이 일반적이었던 "그 옛날"에는, 메인에서 내려와 archive로 넘어가더라도 해당 엔트리를 찾아갈 수 있는 "고정된 참조주소"의 필요성이 있었습니다. 여기에서 퍼머링크라는 말이 나오게 된거죠.
잠깐 삼천포로 빠져서, 블로그가 CMS로 활용될 수 있는 가장 좋은 장점이면서 동시에 치명적인 단점이 되는 것이 바로 이 archive라는 존재라고 봅니다. archive라는 개념은 기존의 bbs 시스템과는 달리, 각각의 엔트리에 대한 수직 위계 체계가 아니다보니, 각각의 엔트리의 위치를 애매하게 만드는 주범이 되는거죠. 한 개의 엔트리는 특정 category archive에 속할 수도 있고, 특정 monthly archive에 속할 수도 있습니다. blogger.com 처럼 월별 아카이브를 기본으로 하는 경우라면 큰 문제가 되지 않지만, MT처럼 복수의 archive에 동시 인덱싱/저장되는 경우에는 이 엔트리가 과연 어디에 위치하는 것으로 보아야 하느냐.. 라는 점이 걸리게 되죠. 그래서 MT에서는 "기본 아카이브 형식"을 1가지 지정하도록 되어있습니다. 그게 퍼머링크의 주소체계를 결정짓는데 필요하기 때문이지요.
말씀하신 subject를 이용한 주소체계는 유감스럽게도, 제가 보기엔 역시 pretty link의 범주에서 벗어나지 못한다고 봅니다. 일단 소소하게 지적해보자면, 확장자와 관련된 설명은 무의미한 것 같네요. 어차피 CGI를 쓰든 mode_rewrite든 할거라면, 역시 마찬가지로 웹 서버의 MIME타입을 변경함으로써, .html확장자로 php든 asp든 돌릴 수 있으니까요.
요컨데, 정적으로 빌드되었든, 동적으로 뿌려주든, php든, xml이든, abcdefg.html이 해당 문서를 보일 수만 있으면 된다는 뜻입니다.
거기에 파일이름이 한글이냐 의미를 알 수 없는 숫자냐.. 는 별 논란거리가 안될 것 같습니다. rebuild되더라도 주소체계가 고정될 수 있는 작성시간을 기반으로한 주소명이라면 아무 상관없지요. 제안하신 주소체계(http: //alogblog.com/alog/archives/2005/03/Permalink에_대한_진실과_오해_permanant한_퍼머링 크_만들기/) 역시, "/2005/03/"이라는 작성시간 기반 주소명 때문에 유효한 것이지, 그 다음에 이어지는 subject를 이용한 체계는 숫자아이디를 이용한 체계보다 이해하기 쉽고 검색엔진에 잘 노출되며 기억하기 쉽다는 점을 제외하고는 본질적으로 다를 바가 없습니다.
이미 작성시간 기반의 archive와 그 주소체계의 유효성은 블로그계에서 많이 논의된 내용이지요.(제가 그렇게 쓰지 않는 이유는 순전히 귀찮음 때문입니다. :))
여기에 말씀하신 툴의 교환... 등의 문제가 개입되게 되면 정적 build 타입의 진가가 발휘됩니다. 툴을 교환하든 DB가 날아가든, 일단 build된 문서가 서버에 남아 있는 한, 그 문서는 계속 예전의 그 주소 그대로 접근할 수 있다는 뜻이지요. 이게 오히려 permalink의 원천적인 의미에 더 근접한 예입니다. WP등의 동적 블로그툴들이 "진정한 permalink"를 제공하지 못한다는 비난의 이유입니다.
물론, 제안하신 주소체계 방식을 이용한다면 동적 블로그툴들도 DB를 날려먹지 않고 툴간 임포트/익스포트가 성공한다면 "permalink"를 유지할 수 있겠죠. 그러나 정적 블로그툴들에서는 별 의미없는 이야기입니다.
결론적으로 말하자면, 현재의 퍼머링크들은 완벽한 퍼머링크라고 할 수 없습니다. 그나마 가장 근접한 정적 툴들의 build된 문서조차 말이지요.
제가 생각하고 있는 것은 문서와 서비스의 분리입니다. 각각의 "문서"는 "리소스"들이 모여 publish되며, 이 "문서"의 syndicate는 "서비스"를 통해 제공되는 것..
그러기 위해서는 각각의 문서는 XML포맷(또는 그에 준하는 무언가)으로 archive에 영구히 저장되고, 이것을 html로 변환하여 웹으로 보여주는 서비스, pdf로 변환하여 인쇄하는 서비스, 다른 형태의 XML로 변환하여 machine-feed로 제공해주는 서비스 등등...의 집합이 차후 발달된 블로그 - CMS툴의 모습이라고 예상됩니다. DB와는 별도로 original document로써 XML을 사용하고, DB는 이 XML 문서들에 대한 인덱싱용으로 쓰고, 버전관리가 포함되면 퍼머링크 문제는 해결되지 않을까 생각합니다.
(실은.. 이런 걸 만들어 볼까 하고 있어서 끄적대봤습니다. - 만우절 농담. ^_^)
RE:퍼머링크의 오해와 진실
Trackback 주소 :
Tracked:Permalink
from:likejazz.COM(2005-04-02 17:17:10)
from:likejazz.COM(2005-04-02 17:17:10)
Tracked:Permalink
from:likejazz.COM(2005-04-02 17:17:04)
from:likejazz.COM(2005-04-02 17:17:04)
RE:퍼머링크의 오해와 진실
이글 마지막에 말씀하신 내용은...^^;;;조금 어렵네요. 이런 블로그 서비스 업계(?)에 계신가 봅니다...