Universal Namespace
유니버설 네임스페이스(universal namespace)1를 만들고 관리하는 것은 매우 어렵다. 하지만 유니버설 네임스페이스가 필요한 경우는 많다. 이를테면 도서를 위한 ISBN이나 우리가 인터넷을 하면서 흔히 접하는 도메인 네임, URI 따위가 바로 유니버설 네임스페이스인데, 이걸 개인이나 소규모 표준 위원회가 정의하고 관리하는 것은 거의 불가능하다.
특히 숫자 등의 코드로 된 식별자가 아닌, 사람이 비교적 쉽게 알아볼 수 있으면서도 정규화(normalization)가 용이하게 알파누메릭컬(alphanumerical)한 네임스페이스를 정의하고 관리하는 것은 더욱 힘들다. 왜냐하면 사람이 알아볼 수 있게 하는 것이 네임스페이스 디자인의 의도 중 하나라면, 모든 이름이 똑같이 사람에게 알아보기 쉬울 수는 없기 때문에2 충분히 권위적인 사람이나 자원에 더 알아보기 쉬운 이름을 우선적으로 할당해주는 관리 작업이 들어가야 하기 때문이다. 도메인 네임은 그것을 꽤 잘 정의하고 관리한 편인데, 이를테면 마침표(.)로 구분하는 위계(hierarchy)를 만들고 국가 등의 공인된 기관에 그 관리 구역을 위임하는 식으로 이루어졌기 때문이다. 이렇게 되면 관리 비용의 총량이 변하는 것은 아니지만, 관리 비용은 전체적으로 분산되기 때문에 어느 누가 크게 부담하는 일은 피할 수 있다. 그럼에도 대부분의 도메인 네임은 현금에 의해 거래되기 때문에 권위를 측정하는 일을 경제 시스템에 위임했다고 볼 수 있다. 현존하는 가장 잘 정의되고 관리되는 유니버설 네임스페이스라고 할 수 있는 도메인 네임도 현실적으로 모든 것을 통제하지는 못하고 있다는 뜻이다.
URI나 이메일 주소 같은 경우도 유니버설 네임스페이스라고 할 수 있지만, 사실은 둘 모두 도메인 네임에 이미 크게 위임을 한 상태이기 때문에, 도메인 네임 안쪽에서의 네임스페이스를 관리하는 정도의 부담이다.
글을 읽으면서 느낀 사람도 있겠지만, 이 네임스페이스라는 것은 관리 책임을 위임할 수 있다는 특징이 있다. 이것은 굉장히 중요한 특성인데, 이 위임이라는 것을 잘 엮으면 적은 비용(혹은 분산된 비용)으로 충분히 쓸만한 유니버설 네임스페이스를 누구나 얻을 수 있기 때문이다.
예를 들면 Java 언어의 경우 패키지의 고유성을 위해 유니버설 네임스페이스가 필요했는데, 이를 위해 패키지 네임을 도메인 네임의 역순으로 정의하길 권고하는 것으로 어느 정도 해결했다. 이를테면 내가 어떤 패키지를 만든다면 kr.dahlia.xxx와 같은 이름을 쓰면 되는 것이다. 하지만 도메인 네임의 규칙과 Java 식별자의 규칙은 서로 다르기 때문에3 개인적으로는 썩 좋은 위임이라고 생각하지 않는 사례이다.
또 예를 들자면 OpenID 표준은 개인 식별자의 고유성을 확보하기 위해 URL을 그대로 위임한 바 있다. 그 외에도 많은 웹 서비스들이 사용자 계정 이름으로 이메일 주소를 사용하는 것으로 서비스 내에서의 이름 중복 문제를 위임해버리는 경우는 흔히 찾아볼 수 있다.
사실 내가 갑자기 유니버설 네임스페이스에 대해 썰을 푼 이유는, 내가 만드는 언어의 패키지 네임스페이스를 어떻게 관리할지 고민하고 있기 때문이다. “방금 네가 말했잖아. 네임스페이스는 위임하면 된다며”라고 말할 수 있겠지만, 그게 말처럼 쉬운 문제는 또 아니다. 앞서 말했다시피 도메인 자체는 권위를 평가하고 높은 권위에 좋은 이름을 주는 관리 책임을 자본에 어느 정도 위임하여 회피했기 때문에, 도메인 네임을 사용할 경우 그러한 문제도 고스란히 가져오게 된다. 즉 좋은 라이브러리 이름을 얻기 위해서는 돈이 필요해지는 것이다. 또한 Java의 사례를 보면 알 수 있는 것인데, 애초에 도메인 네임은 특정 언어로 작성된 라이브러리 패키지를 위해 디자인된 네임스페이스가 아니기 때문에 필요 이상으로 이름이 길어지게 된다. 웬만하면 xxx라고 할 수 있는 것을 kr.dahlia.xxx라는 식으로 늘려 써야 하는 경우가 많다.
Perl의 CPAN의 경우 프로그래밍 언어 중에서는 그러한 문제를 가장 열심히 해결하려고 시도한 경운데, 대신 CPAN 모듈들은 재치있고 특이한 이름을 가지지 못하는 경우가 많다. 또한 CPAN 같은 방식으로 가려면 공동체의 관리 비용이 든다.
그래서 결론이 뭐냐하면, 사실 결론은 없고 그냥 내가 요즘 이런 고민을 하고 있다는 얘기를 써보고 싶었다.
최근에 짬짬이 시간을 내서 만들었다. 전부터 스스로 필요하다고 생각했던 서비스다. Markdown 문서 전용 붙여넣기(pastebin) 서비스다. 붙여넣기 서비스가 무엇이냐면, 여러줄로 된 긴 글을 쓰기는 곤란한 IRC 같은 채팅이나 Twitter 같은 마이크로블로그 등에서 인용을 위해 따로 본문 URL을 만들어 링크하는 서비스다.1
로그인을 할 경우 자신의 글을 수정할 수 있게 된다. 그리고 모든 수정 사항은 위키처럼 이력 관리가 된다. 다만 아직 차이점을 보기 위한 diff는 구현하지 않았다. 로그인은 VLAAH 계정으로 하면 된다.
문서를 포크(fork)할 수도 있다. 수정 권한이 없는 문서에 대해 나만의 변경을 가하고 싶을 때 쓰면 된다. 다만 원본 문서에는 누가 포크를 했다고 링크가 걸리고, 포크한 문서에도 원본 문서에 대해 링크가 생기긴 한다.
아직 디자인은 완성되지 않은데다 내가 직접 한 거라서 좀 촌스럽다. 하지만 문서를 보는데는 별 지장이 없다. (IE6에서는 지장이 있을지도…)
서비스 URL은 다음과 같다.
소스 코드도 AGPL 라이센스 하에 제공한다.
http://bitbucket.org/lunant/pastedown/
덧. 참고로 Google App Engine 위에서 돌아간다.
-
아는 사람은 알겠지만, 처음에는 프로그램 소스 코드를 인용하기 위한 것이었다. ↩
플레인 텍스트의 미덕은 제약이다. 아주 먼 옛날, 플레인 텍스트의 실질적인 형태가 타자기 출력이었던 때는 약간 아니었지만, 지금의 플레인 텍스트로 복잡한 효과를 넣으려고 하는 사람은 ASCII 아트 만드는 사람 빼고는 없다. 대신 그들은 오로지 제한된 문자만으로 효과적으로 글의 내용을 전달하는 방법을 배우고, 어떻게 단순한 구조화가 글의 내용을 이해하는 데 굉장한 도움을 주는지 알게 되며, 글을 쓸 때 글의 내용에만 집중하는 방법을 익히게 된다. 플레인 텍스트의 제약을 기계가 이해할 수 있도록 정형화하면 마크다운 같은 경량 마크업 언어나 TeX 같은 조판 언어가 나오지만 기본 원칙은 변하지 않는다: 플레인 텍스트로 좋은 글을 쓸 수 없다면 워드프로세서 나부랭이로도 좋은 글을 쓸 수는 없다. 아이들에게 글쓰기보다 워드프로세서를 먼저 가르치면 안 되는 이유 중 하나이다.
서식이 글쓰기의 마(魔)이다. 서식에 신경을 쓰다보면 주화입마(走火入魔)에 빠져 정작 글의 내용은 형편없게 된다.
28일(토요일) 어제 UXCamp Seoul에서 CREVATE의 박성연 대표님과 같은 슬롯을 공유하며 함께 발표했던 내용에서 내가 준비했던 부분의 발표 자료다. 처음으로 SlideShare를 써서 공유해본다.
기조(基調)는 대충 이랬는데, 박성연 대표님께서 UX 이노베이션을 주제로,
사람들이 창의성에 대해 너무 대단한 것으로 여기는 편견을 가지고 있다. 다행히 YouTube와도 같은 것들이 아마추어 아티스트(일반 사용자)와 프로 아티스트의 구분을 모호하게 하고 있다. 개발 직군에서도 기획자와 개발자, 디자이너의 구분도 모호해지는 것이 이노베이션을 만들어낼 수 있다.
라는 식으로(엉터리 요약) 발표를 하셨고, 이어서 “그렇다면 프로그래밍은 어떨까?”하는 식으로 약간 어색하기도 하고 자연스럽기도 한 바톤 터치를 했다. 그 이후의 내용이 내가 한 발표.
