1. 퍼머링크는 퍼머넌트(permanant)하지 않다?

구글에서 퍼머링크로 검색해서 나온 글들을 쭉 훌터보면, 대충 퍼머링크는 말장난이다! 라는 결론을 자연스레 얻게 됩니다. 퍼머링크에 대한 정의도 간간히 보이곤 하지만, 어느것 하나 딱부러지게 기존의 그냥 링크랑 확실히 차이점을 설명해주는 경우도 드뭅니다. 우리 블로거끼리 딱 깨놓고 하는 소리로, 그냥 예전의 링크랑 똑같은 역할을 하는 것인데 어떤 놈이 처음에 퍼머링크라고 블로그상에선 불러 째기는 바람에, 일반 홈페이지에서는 링크라 부르던 그냥 별다를것 없는 주소를, 블로거들은 퍼머링크~ 라 칭하면서 잘난척 한다...정도가 솔직한 이야기 아닐까요? (적어도 지금 수많은 설치형 블로그에서 퍼머링크라고 찍어놓은 주소체계를 모두 진정한 "퍼머링크"라고 보는 한에서는 100% 맞는 말일 겁니다.)

MT 등에서 퍼블리싱하는 경우의 퍼머링크는 일반적으로 http: //alogblog.com/myblog/this_is_a_permanent_entry.html 식으로 고정적인(?) 형태인데 반해, 여타 DB중심의 동적인 게시판이나 블로그에선 주소꼴이 http: //alogblog.com/myblog/this?is=not&permanant=234 와 같이 조금 지저분한(?) 모양인데, 이 두 스타일을 비교하면서 전자가 진정한(?) 퍼머링크고 후자는 변종(?)으로 보는 견해도 있습니다. 이런 견해에 자연스레 따르는 설명은, 고로 DB형태의 동적인 주소는 DB내의 데이터베이스/테이블 등의 형식이 바뀔 경우, 고정적이지 못하고 주소가 바뀔 가능성이 있다...고로 퍼머넌트하지 못하다 내지는 별 만족할 만한 퍼머링크가 아니다 라는 선까지 발전합니다.

이런 견해에 대해, 그러한 동적 형태의 주소를 찍어주는 블로그툴을 사용하는 블로거들은 가만 있습니까? 당연히 정당한 반론이 따르게 됩니다. 즉 DB의 데이터베이스나 테이블의 형태가 바뀌거나 등등의 이유로 주소꼴이 바뀔 가능성보단, 이런 저런 현실적 이유로 글이 삭제되거나 수정되거나 등등의 이유로 링크가 끊어질 확률이 더 크다! 라는 부정하기 어려운 반론이 따릅니다.

위 반론은 옳습니다.
따라서 결국엔 정적이던 동적이던 둘다 퍼머링크로서, 기능적으로는(그냥 링크) 양자가 전혀 차이없이 작동하고, 동적 주소형태는 단지 MT의 정적인 주소형태에 비해 아주 아주 쬐금 덜 깔끔해 보이는 정도의 차이 정도는 인정할 수 있지만, 그걸 불편으로 느끼는 실제 블로거가 전무하다 보이므로(링크는 단지 대상 페이지로 오는 수단일 뿐!) 이또한 큰 단점은 아니다 라고 수습되어지는 형국입니다.

이런 (오해가 있는)결론을 정리해 표현하자면, "어떤 주소체계 그 자체만으로 퍼머링크니 빠마링크니 구별짓는 것은 무의미하다. 퍼먼넌트하냐 안하냐의 대상은, 링크의 형식에 의해 결정되는 것이 아니라, 그 링크가 실제로 가라키는 대상(엔트리)의 존재여부에 의해 가늠되어 질 뿐이다. 그리고 주소가 좀더 인간 중심이라는 사실과 그 주소가 가리키는 대상의 영속성과는 하등의 연관이 없다.(좀더 발전시키면 MT 등에서 Permalink라 부르는 것은 pemanent link가 아니라 pretty link라 부르는게 더 의미에 부합된다...) 따라서, 특별히 동적인 주소를 더 퍼머넌트하지 않다고 볼 하등의 합리적 이유는 없다! " 끝. 자 이만 하산하십시요.

어떻습니까? 이 결론에 여러분도 동의하십니까? 얼마나 멋진 말입니까? 동의안하는게 더 이상할 겁니다.

다음은 이런 결론의 도출과정이 퍼머링크에 대한 오해(퍼머링크 = 링크 라는) 때문에 나온 잘못 된것이라는 설명입니다.

2.  블로그 생성툴에 독립적인 퍼머링크

그럼 머가 정말로 퍼머넌트한가? 하는 핵심이 남습니다. 일단 앞 1. 에서 살펴본 퍼머링크의 퍼머넌트성에 대한 논의는 기본적으로 가정부터가 잘못된겁니다.

우리가 어떤 링크(혼동을 위해 정확히 해둘 필요가 있습니다. 링크가 가리키는 대상 페이지가 아니라, 링크 그자체를 말합니다.) 를 "그냥 Link다, 아니 Permanent한 Link 다" 라고 할땐 주소 자체로 논해야 합니다. 즉, 그 링크가 가리키는 어떤 대상은 여전히 항상 어떠한 형태로든 존재하고 있는 것을 가정해야합니다. 그 대상이 웹공간에서 사라진다면, 퍼머링크던 파마링크던 사이비링크던 링크로서의 존재의의가 없어집니다. 링크 형식에 다이아몬드를 쳐발랐다 해도, 그 자체(겨우 링크주제에)로 그 링크가 가리키는 대상의 항상성을 유지시킬 아무런 힘은 없으니깐요. 따라서 퍼머링크를 논할 때 그 퍼머넌트성의 여부는, 그 링크가 가리키는 대상의 위치/형태 등이 어떤 이유에 의해 바뀌었을 경우(또 바뀐 다른 모습으로 여전히 웹상에 존재하는 경우)에도 여전히 처음에 가리켰던 대상을 가리킬 능력이 링크형태 자체로 있냐 없냐로 링크의 퍼머넌트성을 판단해야 한다는 것입니다.

몇몇 블로그툴이 퍼머링크라는 명칭으로 표시하고 있는(그러나 기존의 일반링크에 비해 전혀 따로 퍼머링크라 불러줄 아무런 이유도 발견할 수 없는) 주소형태를 예로 들어 보겠습니다.

• 무버블타입 - http: //alogblog.com/blog/archives/2004/03/00012.html
• 태터스툴 - http: //alogblog.com/tt/index.php?pl=12
• 워드프레스 - http: //alogblog.com/blog/?p=12

위의 경우 모두, 링크내에 해당 블로그 '툴'에서의 고유한 값( 글 내용 자체와 무관한 값), 즉 엔트리 ID(12)가 포함되어 있습니다. 이 12는 무엇을 의미할까요? 가장 쉽게 생각해 볼 수 있는 것은 저 주소가 가리키는 글은 아마도 저 블로그 시스템상에서 열두번째로 만든 글일 것이다...라는 겁니다. 

그럼 그 글 자체와 그 글을 매칭시켜주는 위 링크주소에 표시된 "열두번째"라는 흔적은 어떤 관련성이 있습니까? 전혀 없습니다. 위 링크가 가리키는 글 내용 자체는 어디에도 12라는 속성을 가지지 않습니다. 12는 블로거가 만든게 아니라, 블로그툴이 우연히 생성한 값일 뿐입니다. 아니 그게 먼 상관이냐구요?

설명전에, 그에 반해 아래와 같은 주소형태를 먼저 한번 볼까요?

• http: //alogblog.com/alog/archives/2005/03/Permalink에_대한_진실과_오해_permanant한_퍼머링크_만들기/

http: //alogblog.com/alog/archives 까지는 어떤 블로그툴을 사용하더라도 설정에 의해 같은 경로를 가지게 만들어 줄 수 있습니다. 그리고 나머지 이후 주소값은 다름아닌 해당 글 자체의 데이터만을 이용해 만든 주소입니다. 글의 제목과 작성한 년/월 값을 이용한 주소입니다. 주소 전체를 볼 때, 어떤 특정한 블로그툴 상의 값(가장 좋고 흔한 예가 엔트리 아이디)을 전혀 가지지 않는 형태입니다.

두 링크주소 체계의 차이점을 아시겠습니까? 그져 보기좋고 깔끔한 차이가 아닙니다 (첫번째 MT의 주소도 소위 pretty link는 될 지언정, 진정 퍼머넌트한 링크는 아닙니다).  단순히 더 링크가 설명적이라는 차이만도 아닙니다. 더 근본적인 차입니다.

저 링크가 가리키는 글(링크 대상)이 웹공간에  어떤 툴로, 어떤 파일 형식으로, 혹은 디비의 변경에 의해 모습을 바꿔어 존재하더라도 존재만 한다면, 항상 그 글은 원래의 저 주소를 가질 수 있다 (저 주소를 가지게 만들어 줄 수 있다) 라는 것입니다. 그것이 가능한 이유는 링크의 대상이 되는 글 자체가, 이미 자신의 주소를 온전히 가지고 있고 또 그것만 이용해 만들었기 때문입니다.

전 무버블타입 플럭인도 만들고 해서 엠티에 깊숙히(?) 빠져 있는 상태지만, 1년 후, 5년 후, 10년 후에도 여전히 이 툴을 이용하리란 보장은 못합니다.  여러분은 지금 사용하고 있는 블로그툴을 언제까지 사용하실꺼라 확신하십니까?  WordPress는 딥따 좋아서 앞으로 20년은 뒤도 안보고 그것만 사용하실꺼라 확신하십니까? 혹 내년쯤에 호환되지 않는Word-Super-Ultra-Capshong-ExPress가 나오면 어쩌실건데요?

위 두 주소형태는 단지 동적/정적 주소형태의 차이가 아닙니다. 설사 PHP를 이용한 블로그 상에서 주소가 동적으로 생성되는 시스템이라손 치더라도, 얼마든지 그 블로그툴에 종속적인 값을 감추고 오로지 해당 글에만 종속적인 데이터를 이용한 주소를 만들어 줄 수 있습니다.(mod_rewrite 아파치 모듈사용하는것 맞죠?) MT도 퍼머넌트하지 못한 퍼머링크로 주소를 발행할 수도 있고, WP도 퍼머넌트한 퍼머링크 형태로 만들어 줄 수 있습니다.

결국 퍼머링크의 퍼머넌트성 여부는 주소 형태 그 자체로 완연히 판가름이 납니다. 위 퍼머넌트한 주소의 경우 그어떤 다른 블로그로 옮길 경우에라도 그 방법의 쉽고 어려움은 차치하고 언제나 일괄 변환/임포팅에 의해 기존의 주소를 계속 사용할 수 있다는 것입니다. 맞나요? 불가능할까요? 현재 글들을 진정 퍼머넌트한 주소로 만들어 배포하지 않으면서, 다른 툴로의 전환 등을 위해 DB백업에만 신경쓴다면 밑빠진 독에 물붇기 아닐까요?

위의 경우에 블로그 툴 자체를 바꾼 경우를 가정했지만, 같은 블로그툴 내에서도 MT의 경우 HTML로 퍼블리싱해주느냐 PHP,CGI 혹은 향후 10년 후에 등장할 아주 멋진 PX6(그냥 지은 말입니다)로 퍼블리싱하느냐 하는 변경이 있을 수 있습니다. 제 경우엔 HTML로 퍼블리싱하고 있습니다만, 동적인 다른 기능 적용을 위해 PHP로 퍼블리싱할 수도 있을 것입니다.

그럼 그땐 어떻게 됩니까?

전에는 http: //alogblog.com/blog/이것은_예제입니다.html 로 만들던 링크 형태가 앞으로는, http: //alogblog.com/blog/이것은_동적인_페이지입니다.php 식으로 생성될 것입니다. 물론 이전에 만들었던 페이지도 리빌딩하게되면 php 확장자를 주소에 가지게 됩니다.

자 이젠 링크에 그 글자체 내용과 무관한 어떤 요소가 개입합니까? 바로 확장자입니다. 글 내용자체와 무관하다는 것은 나중에 확장자가 바뀌면 주소까지 바뀐다는 의미가 되므로( 된장, 확장자 하나 바꿨을 뿐인데...), 이또한 링크의 퍼머넌트성을 방해하는 요소입니다. 만약 위 주소가 http:// alogblog.com/blog/확장자가_없군요/ 와 같다면 향후 필요에 의해 HTML로도 PHP로도 또 리눅스서버에서 윈도서버로 옮기게 되어 ASP로 할 경우에도 원래의 퍼머링크는 여전히 해당 글을 가리킬 것입니다.

누구나 자신이 현재 사용하고 있는 블로그시스템이 가장 좋다고 여깁니다. 그래서 자신은 다른 툴로의 변경이나 혹은 한 툴 내에서 다른 확장자로의 변경 혹은 DB구조의 변경 등을 절대 안할것이라 생각할 수도 있습니다.(물론 결과적으로 그리 될 수도 있긴 합니다.)  근데 만약 1년후, 5년후, 10년후라도 바꾸게 된다면, 위와 같이 퍼머넌트하지 않은 주소를 퍼머링크라 믿은 죄때문에(더 정확히는 퍼머링크의 퍼머넌트성에 대해 제대로 전달받지 못한 관계로), 기존의 1년치,5년치,10년치 웹에 뿌린 주소가 공수표가 되는 것입니다. DB백업요? 그거 하면 머합니까? 이미 기존의 빠마링크는 꼬부라져 다시 사용할 수도 없는 1년전글, 5년전글이 1년후 5년후에 바뀐 주소로 얼마나 역할을 하리라 보십니까? 그냥 그 글들은 로컬피씨상의 디비에 보관해두는게 더 나을지도 모릅니다.

여기에 묘한 함정이 있다고 전 봅니다. 왜 우리 블로거들은 그리 퍼머넌트하지 않은 링크를 퍼머링크라 부르고 사용하고(차리리 그냥 링크라 불러도 아무 문제없고 오히려 그리 불러주는게 덜 속는 것임에도), 퍼머넌트한 링크에 대한 확실한 이해를 전달받지 못했을까? 하는 문제입니다.

물론 블로그툴 개발자들도 제가 보기엔 이 퍼머링크에 대한 이해가 완전한건 만은 아니다...라는 의심을 가지곤 있습니다.(몇몇 툴을 예로 들고 싶지만...) 블로그툴/파일 형식에 독립적인 링크라는 원래적 기능설명에 다들(블로그개발사이트) 너무 인색합니다. 이게 의도적인것인지 어떤지 확신할 순 없지만, 다들 주변만 두들기는 설명입니다. 어떤 곳은 단지 좀더 이쁘고 보기좋은 링크라는 식으로 넘어가기도 합니다. 변하지 않는 무언가에 대한 링크다라는 무지무지 추상화한 설명을 제공하는 곳도 있습니다. 말 자체로 맞는것 같기도 한데, 그것만으론 도저히 기존의 그냥 링크를 다를바가 없는데도 두리뭉실 넘어갑니다. 저만 그런건가요?

이런 퍼머넌트한 링크생성은 블로그 툴에의 종속성을 완전 차단하는 결과를 주는 것입니다. 툴을 사용하는 사용자의 입장에서는 쌍수를 들고 환영할 만한 것이지만,,,, 툴 개발자의 입장에선 어떨까요? 만약 기존에 1년, 5년 10년간 어떤 툴을 이용해 웹공간에 뿌린 주소가 tt/index.php?1234 혹은 wp/?p=1234 와 같이 되어 있었다면, 시간이 갈 수록 툴을 변경하기 어려워지지 않을까요?

새로운 툴이 나와 좀더 자신의 환경에 맞다고 여겨지고, 또 양자간에 임포팅도 가능함에도 불구하고, 기존에 발행한 글들의 주소를 온전히 유지할 일괄방법이 없다면? 불가능하다면? 그냥 죽치고 그것만 사용하게 되지 않을까요? 겨자를 먹긴 먹는데 울면서 먹는 꼴이죠. 지금도 주위에서 퍼머넌트하지 못했던 퍼머링크를 사용하다 블로그 툴을 바꾼 후, 이전의 트랙백/퍼머링크 주소가 다 깨져서 속앓이를 하는 분이 어디 한두분이십니까? 퍼머넌트하게 사용했다면, 블로그툴을 바꾼후에도 방법의 쉽고 어려움은 있겠으나 분명 온전히 유지가 가능합니다.

지금 사용하는 블로그툴을 죽을 때까지, 툴내에서의 변경조차 없이 주구장창 이것만 사용할 "확신"이 있으시다면 굳이 퍼머링크 생성에 관심을 둘 필요는 없겠죠. 그냥 기존의 링크로도 충분히 제 역할을 할 것입니다. 하지만 그런 불확실한 확신/가능성 문제는 차치하고라도, 기왕에 가능한 것이라면 좀더 유연하고 블로그 툴에 독립적인 주소로 자신의 글을 배포하고 싶지 않으십니까? 쓸데없는 오버로들까요?

네? 지금까지 만든 빠마링크땜시 곤란하다구요??? 그것 보세요. 빠마링크로 하셨으니 벌써 이런 문제가 발목을 잡지 않습니까? 판단은 기존의 빠마링크 양과 앞으로 살아가면서 만들어낼 퍼머링크의 양을 잘 생각하셔서 결단을 내리셔야, 앞으로 1년뒤 5년뒤에 대략낭패~를 외치는 불상사를 막는 길입니다.

조금 늦었다고 생각할 때가 오히려 지나고 보면 결코 늦지 않은 경우가 태반입니다. 기존 빠마링크에 대한 미련과 저울질보단, 이 퍼머링크 자체의 필요성에 대한 고려만을 기준하시는게 좋으리라 봅니다. 그리고 기존의 디비 형태의 빠마링크만을 제공하던 툴 개발자님들은, 필히 사용자가 원한다면, 각종 모듈을 이용해 쉽게 사용자가 퍼머넌트한 링크생성을 할 수 있도록 방법을 모색/공지해주시길 바랍니다.

3. 한글제목을 이용한 주소 문제

정말 주소형태 자체로 퍼머넌트한 퍼머링크를 가짐으로써 많은 잇점이 생김니다. 퍼머링크 원래의 특성상, 툴과 파일형식에 독립적인 주소 생성의 잇점은 기본입니다.

http ://alogblog.com/blog/2005/01/123456/

위 주소는 퍼머넌트합니까? 123456은 글 내용과 상관없이 블로그툴이 부여한 페이지 고유의 ID값입니다. 아마도 저런 주소는 blog/$year/$month/$entry_id 정도의 템플릿 룰로 만든거겠죠. 어떻습니까? 저것도 퍼머링큽니까?

깔끔한(pretty) 링크이긴 한데, 퍼머넌트한 링크는 아니겠죠? 근데 우리 한국(물론 외국도 마찬가지지만 영어명이라는 이유로 상대적으로는 덜합니다.) 설치형 블로거의 경우 저런 식으로 많이들 사용하십니다.

바로 한글제목명 때문이죠. 이에 대한 회피책으로 또 다른 모습의 퍼머링크는,

http: //alogblog.com/blog/2005/01/12_12_00/
http: //alogblog.com/blog/archives/2005_01_12_12_00/

같은 모습이 있을 수 있겠죠. 제일 뒤의 숫자는 해당 글이 포스팅된 시간(날짜_시_분)을 이용한 경웁니다. 이때 이 값도 당연히 블로그툴에 독립적인 값이므로 퍼머넌트한 링크이긴 합니다. 만약 한글문제 처리를 깔끔히 할 방도가 해당 툴 커뮤니티내에서 제시되지 못한다면, 저런 식으로 사용할 수도 있겠죠.

주변환경에 독립적인 퍼머넌트링크를 만드실 생각이시라면, 가능한 방법을 강구해 한글제목을 이용하시라고 권합니다. 외산 블로그툴의 경우 대부분 템플릿 등에서 주소를 제목으로 설정하면, %CD%2F.. 와 같이 한글은 URL encoded된 모습으로 생성이 됩니다. 해당 링크 생성 루틴을 적당히 손보면 깔끔한 한글 주소가 나올겁니다.

한글 주소를 사용할 경우 분명 검색엔진에서도 영문주소와 같이 똑같은 작용을 받습니다. 또 링크가 다른 이유로 끊어질 경우에도 링크에 포함된 한글 제목을 이용해, 검색페이지로 연결해 주거나 등의 처리도 가능합니다.

한글명을 사용할 경우 발생하는 문제는, 바로 브라우져에서 UTF로 강제로 보내기 혹은 아니기의 경우에 제대로 찾지 못하는 경웁니다.(종종 이런 문제를 겪어보셨겠죠?) 이런 문제를 웹서버 자체에서 처리해주면 제일 따봉이겠지만, 그게 안된다해도 간단한 CGI로 바로 Not Found Error대신에 원 페이지를 찾는 법이 있습니다. 참고로 전 MT상에서 초기에 나타난 몇몇 문제점을 잡아서, 나름대로 그런 문제없이 잘 사용하고 있습니다.

추가 1.

eouia님이 트랙백해주신 글을 보고 몇자 더 붙여봅니다.제가 이글을 쓰면서 은근쓸쩍 명확히 하지 않고 넘어간 부분에 대한 euoia님의 지적에 대한 해명 정도될 것입니다.

• 제가 이글에서 링크가 퍼머넌트하냐 안하냐, 이게 퍼머링크가 맞냐 아니냐 하는 것은, 이 글에서 주장하는 퍼머넌트성에 오로지 입각한 결과이지, 어떤 표준 기관에서 정의한 기준(퍼머링크는 이런 이런 링크 요소를 갖춰야 한다...식의)에 따른 건 아니라는 것입니다. 무버블타입에서 말하는 퍼머링크의 정의(?)와도 사실 상관이 없습니다. 무버블타입에서는 그냥 여러 아카이브에 속한 글을, 현재 아카이브 페이지(엔트리링크)내의 앵커부분(엔트리퍼머링크)까지 꼭찝어 기술하는 링크에 불과합니다. 이 말의 출발 자체에서 제가 주장하는 퍼머넌트성에 대한 고려는 전혀 없는 게 사실입니다. 다른 툴들도 마찬가지로 봅니다.
  
• euoia님이 지적하신대로, Individula Archive Entry(우리가 그냥 엔트리라 부르는 페이지) 를 사용하지 않는 경우나, 개별엔트리를 사용하더라도 정작 퍼머링크는 다른 아카이브를 경유한 부분을 사용할 경우에는(그런 바보는 없겠지만) 위에서 주장하는 내용이 해당되지 않냐 하는 점입니다. 
  
  만약, Individual Archive를 생성치 않고, Monthly Archive만 생성한다고 가정해봅니다. 그럼 예를 들어, 2005년 3월 어느날의 어느 엔트리는 다음과 같은 두가지 주소를 가질 수 있습니다. 2005/03/index.html(MTEntryLink) 혹은 2005/03/index.html#1234 (MTEntryPermalink, 1234는 일반적으로 엔트리 ID)
  
  후자가 엠티에서 말하는 퍼머링크식입니다. 제가 위 글에서 엔트리의 제목을 이용하는 것은, 주소에 블로그툴이 만든 우리가 컨트롤할수 없는(퍼머넌트성을 방해하는) 요소를 제거하자는 목적아래의 한 수단일 뿐입니다.
  
  그렇게 본다면, 위와 같이 자신은 Individual을 생성치 않는다면, 퍼머넌트성을 유지시켜주기 위해, 해당 템플릿을 수정해서 2005/03/index.html#1210 (1210은 12시 10분에 생성한 엔트리) 혹은 이경우에 그 한글제목의 의미가 제대로 작용할지에 대한 의문은 있지만(또 링크의 앵커부분에 한글이 제대로 문제없이 작동하냐에 대한 부분) 2005/03/index.html#한글_제목 식으로 앵커를 삼게 표현해주면 될 뿐입니다. 제가 말하는 것은, 퍼머넌트한 링크를 위해선 개별엔트리나 한글제목 등을 이용해야만 한다는 것은 아닙니다. 기본적인 퍼머넌트성을 충족하는 여러 수단 중에, 기왕이면 다홍치마라는 입장에서 제목사용을 설명한 것일 뿐입니다.
  
• 제목 이용부분이 pretty link라는 부분에는 반만 동의합니다. 지금 논의하고 있는 부분의 밑바탕에는, 지금까지 특히 DB기반의 게시판/포럼류가 생성하던 무의미한 링크표현( 즉 오로지 기계가/포르그램이/데이터베이스 엔진이 이해하기 좋은)에 익숙해져, 그냥 그 표현이 어떠하든 링크해서 그 대상만 찾아주면 "링크"의 원 기능은 만족한것 아니냐는 단계에서 한걸음 더 나아가, 기왕 어떤 형태로든 그 1:1맵핑이 가능하다면(또 기계/프로그램/디비는 그 형태가 어떠하든 잘 알아 먹는다면), 이제는 검색엔진(조금더 똑똑한 프로그램)이/사람이 주소만으로 내용을 짐작할수 있는(오용의 가능성은 물론 있음에도) 형태로의 링크 표현으로 전환하는(혹은 할 수 있는, 개인적으로는 하길 강력히 원하는) 단계라고 보여집니다. mod_rewrite나 엠티의 정적 주소체계도 그런 연장선일 겁니다.
  
  한글주소부분은 그것이 URL encoded로 꼬여 페이지에 나타나지만 않는다면 분명 pretty합니다. 하지만 그것은 0001.html나 index.php?id=1 보다 조금 더 이쁘다는 개념을 뛰어넘는 것이라 생각합니다.

추가 2

yser님이 주신 코멘트 내용에 관해 한글주소와 관련해 조금 덧붙여 로깅차원에서 적습니다.

2.1 URI and non-ASCII characters

   The relationship between URI and characters has been a source of confusion for characters that are not part of US-ASCII. To describe the relationship, it is useful to distinguish between a "character"
   (as a distinguishable semantic entity) and an "octet" (an 8-bit byte). There are two mappings, one from URI characters to octets, and a second from octets to original characters:

   URI character sequence->octet sequence->original character sequence

   A URI is represented as a sequence of characters, not as a sequence of octets. That is because URI might be "transported" by means that  are not through a computer network, e.g., printed on paper, read over the radio, etc.

   A URI scheme may define a mapping from URI characters to octets;   whether this is done depends on the scheme. Commonly, within a  delimited component of a URI, a sequence of characters may be used to  represent a sequence of octets. For example, the character "a"  represents the octet 97 (decimal), while the character sequence "%",  "0", "a" represents the octet 10 (decimal).

이부분의 설명을 볼땐, 그래 그거야 싶더니, 실제 구현(?)부분에선 여지없이 West-world Wide Web에서 해서 실망.^^ 하지만 저 정의자체만으로 자연스레 I(Internationalized)RI의 출현을 뒷받침한다고 보입니다.

URIs Aren't So Universal After All
http://www.xml.com/pub/a/2003/05/07/deviant.html 의 서두부분.

IETF의 URI 표준과 IRI 권고 표준 지지
http://www.w3c.or.kr/Press/uri-iri-pressrelease.html.ko

ftp://ftp.rfc-editor.org/in-notes/rfc3987.txt
This document defines a new protocol element called Internationalized  Resource Identifier (IRI) by extending the syntax of URIs to a much  wider repertoire of characters.

다행히(그러나 필연적으로) 그들 또한 World-wide가 US-ASCII만의 세계가 아니라는것을 깨닫고(?) 여타 모국어 사용도 고려하는 단계로 더디지만 진행되고 있는것 같습니다.

한글 등 2바이트 주소가 %표시로 나타나면 URI/IRI의 "의미"(실제 구현이 아니라)를 만족시키지 못하는건 사실입니다. 즉 URI/IRI는 그 개념자체에, 어떤 대상을 가리키는 표식(identifier)이 단지 의미없는 숫자/문자의 조합을 가정하기보단, easier to memorize, easier to interpret, easier to transcribe, easier to create, and easier to guess 한 표식으로 그 표식을 사용할 인간/기계 모두에게 원할한(기계는 전송/변환/생성 편리, 인간은 기억/추측/생성 편리) 어떤 방벙의 표준을 정하는 것이니까요, 다만 URI에서는 아스키만으로 초기에 잘못 그 구현을 정의한 한계가 있긴 합니다만...IRI로 결국엔 나가지 않을까요? (자세한건 잘 모르겠습니다.)

URI(의미론적인)로서의 어떤 주소가(꼭 웹주소말고라도) 영문자로만 표시되어야 할 어떤 "기술적" 원인은 없습니다. 단지 그들이 익숙한 체제로 처음에 그리 출발했기 때문일 뿐입니다. 한글문서를 가리키는 주소에 한글설명적 파일이름(URI의 일부로서)이 포함되는 것은 너무나도 당연한겁니다.

이렇게 잘못(?) 염려하는 경우도 있을 수 있습니다. 영문/숫자로만의 주소일 경우, 한국어가 가능하지 않은 지역/사람도 정말 말 그대로 world-wide하게 접근이 가능하지만, 한글/일어/중문 등으로 표시된 각각의 주소는 world-wide한 접근을 방해하지 않을까? 하는 생각입니다. 동의하십니까?

이런 생각은 본말이 전도된 기우라 봅니다. 한글이 포함된 URI를 가진 대상문서는 "한국어"를 사용가능한/이해가능한 사람을 위한 문서라는 소립니다. 그걸 Ascii주소로 표시했다고 달라질건 하나도 없습니다. 마치 산속 깊은 곳에서 왕래도 없는 이가, 외국인이 자기 이름부르기 편하라고 Steve라고 자신의 별명을 정하는 모습이랑 다를 바 없다 봅니다.

만약 정말 그 URI가 가리키는 문서를 월드와이드하게 하고 싶다면, 그 문서를 월드아이드한 표현(현실적으로 영어?, 중국인에게 직접 알리고 싶다면 중국어...식으로)으로 작성하면 됩니다. 그 경우에 의도하든 안하든 URI에 한글이 포함될 이유가 전혀 없기 때문입니다.

브라우져에서 한글주소가 %로 표시되는건 현재로선 브라우져 상의 문제입니다.(한글 주소 등 비ASCII 포함 주소가 %로 escape되어 전송되고 전송 양단 주체가 이를 escape된 상태로 받아들이고 이해하는건 표준으로, 이 단계가 끝난 후 그 주소자체를 어떻게 표시할것이냐의 문제) 

http: // alogblog.com/한글주소/ 라는 부분이 실제 전송단계에선 http: //alogblog.com/%AA%BB%CC%DD/ 와 같이 escape되어 이루어집니다. 그럼 저 주소를 받은 브라우져(서버측은 논외)가 저 받은 주소형태를 그냥 받은 저 형태대로 주소창/페이지에 표시하고 끝낼것이냐, 아니면 자기만의 어떤 방법에 의해 저 주소를 원래의 어떤 문자로 전환해 보여주는 "선의/편의/배려(아직 표준으로 요구하는 것이 아니므로)"해 주느냐의 문제인데, 이게 IE와 Firefox 등이 당연히 다릅니다.

만약 주소창으로 전송하는 URI가 모두 어떤 표준/강제에 의해 UTF-8등의 정해진 인코딩 기준이라면 받은  % 형태 문자열을 UTF-8의 해당 글자로 바꿔서 쉽게 브라우져는 표시해줄 수 있을 겁니다. 문제는 아직 이게 강제된게 아니므로, 브라우져는 나름대로의 방법으로 선의를 베풀려고 하긴 합니다.

예를 들어, UTF-8에 인코딩된 페이지에 삽입된 URI의 일부에 %AA%BB 등이 포함된 주소를 Firefox에선 해당 페이지의 인코딩으로 가정하고 원래 인코딩된 문자로 변환해 "상태창"에 보여주는 식입니다.

반면 주소창에 나타난 URI의 경우 Firefox에선 디폴트로는 모두 %AA%BB식으로 표시합니다. 이는 그럴수 밖에 없는게 주소창 자체는 페이지내처럼 어떤 인코딩을 알 수 있는 방법이 없기 때문입니다. 그에 반해 IE 에선, 그 주소창의 주소가 나타난 원인을 찾아서 알수 있다면, 그 인코딩으로 변환해 표시해주는것 같습니다.