이하의 글은 2010년에 쓴 것입니다. 오래된 글인 만큼, 현재의 생각과 전혀 다른 내용도 많이 포함되어 있고, 당시와는 상황이 많이 달라진 점도 있습니다. 또한, 그 당시에 잘못 알려졌던 정보도 포함되어 있을 수 있습니다. 어찌됐든 저는 제 오래된 글이 회자되는 것을 저어합니다. 읽기에 앞서 양해를 부탁드립니다.

Universal Namespace

유니버설 네임스페이스(universal namespace)¹를 만들고 관리하는 것은 매우 어렵다. 하지만 유니버설 네임스페이스가 필요한 경우는 많다. 이를테면 도서를 위한 ISBN이나 우리가 인터넷을 하면서 흔히 접하는 도메인 네임, URI 따위가 바로 유니버설 네임스페이스인데, 이걸 개인이나 소규모 표준 위원회가 정의하고 관리하는 것은 거의 불가능하다.

특히 숫자 등의 코드로 된 식별자가 아닌, 사람이 비교적 쉽게 알아볼 수 있으면서도 정규화(normalization)가 용이하게 알파누메릭컬(alphanumerical)한 네임스페이스를 정의하고 관리하는 것은 더욱 힘들다. 왜냐하면 사람이 알아볼 수 있게 하는 것이 네임스페이스 디자인의 의도 중 하나라면, 모든 이름이 똑같이 사람에게 알아보기 쉬울 수는 없기 때문에² 충분히 권위적인 사람이나 자원에 더 알아보기 쉬운 이름을 우선적으로 할당해주는 관리 작업이 들어가야 하기 때문이다. 도메인 네임은 그것을 꽤 잘 정의하고 관리한 편인데, 이를테면 마침표(.)로 구분하는 위계(hierarchy)를 만들고 국가 등의 공인된 기관에 그 관리 구역을 위임하는 식으로 이루어졌기 때문이다. 이렇게 되면 관리 비용의 총량이 변하는 것은 아니지만, 관리 비용은 전체적으로 분산되기 때문에 어느 누가 크게 부담하는 일은 피할 수 있다. 그럼에도 대부분의 도메인 네임은 현금에 의해 거래되기 때문에 권위를 측정하는 일을 경제 시스템에 위임했다고 볼 수 있다. 현존하는 가장 잘 정의되고 관리되는 유니버설 네임스페이스라고 할 수 있는 도메인 네임도 현실적으로 모든 것을 통제하지는 못하고 있다는 뜻이다.

URI나 이메일 주소 같은 경우도 유니버설 네임스페이스라고 할 수 있지만, 사실은 둘 모두 도메인 네임에 이미 크게 위임을 한 상태이기 때문에, 도메인 네임 안쪽에서의 네임스페이스를 관리하는 정도의 부담이다.

글을 읽으면서 느낀 사람도 있겠지만, 이 네임스페이스라는 것은 관리 책임을 위임할 수 있다는 특징이 있다. 이것은 굉장히 중요한 특성인데, 이 위임이라는 것을 잘 엮으면 적은 비용(혹은 분산된 비용)으로 충분히 쓸만한 유니버설 네임스페이스를 누구나 얻을 수 있기 때문이다.

예를 들면 Java 언어의 경우 패키지의 고유성을 위해 유니버설 네임스페이스가 필요했는데, 이를 위해 패키지 네임을 도메인 네임의 역순으로 정의하길 권고하는 것으로 어느 정도 해결했다. 이를테면 내가 어떤 패키지를 만든다면 kr.dahlia.xxx와 같은 이름을 쓰면 되는 것이다. 하지만 도메인 네임의 규칙과 Java 식별자의 규칙은 서로 다르기 때문에³ 개인적으로는 썩 좋은 위임이라고 생각하지 않는 사례이다.

또 예를 들자면 OpenID 표준은 개인 식별자의 고유성을 확보하기 위해 URL을 그대로 위임한 바 있다. 그 외에도 많은 웹 서비스들이 사용자 계정 이름으로 이메일 주소를 사용하는 것으로 서비스 내에서의 이름 중복 문제를 위임해버리는 경우는 흔히 찾아볼 수 있다.

사실 내가 갑자기 유니버설 네임스페이스에 대해 썰을 푼 이유는, 내가 만드는 언어의 패키지 네임스페이스를 어떻게 관리할지 고민하고 있기 때문이다. 방금 네가 말했잖아. 네임스페이스는 위임하면 된다며라고 말할 수 있겠지만, 그게 말처럼 쉬운 문제는 또 아니다. 앞서 말했다시피 도메인 자체는 권위를 평가하고 높은 권위에 좋은 이름을 주는 관리 책임을 자본에 어느 정도 위임하여 회피했기 때문에, 도메인 네임을 사용할 경우 그러한 문제도 고스란히 가져오게 된다. 즉 좋은 라이브러리 이름을 얻기 위해서는 돈이 필요해지는 것이다. 또한 Java의 사례를 보면 알 수 있는 것인데, 애초에 도메인 네임은 특정 언어로 작성된 라이브러리 패키지를 위해 디자인된 네임스페이스가 아니기 때문에 필요 이상으로 이름이 길어지게 된다. 웬만하면 xxx라고 할 수 있는 것을 kr.dahlia.xxx라는 식으로 늘려 써야 하는 경우가 많다.

Perl의 CPAN의 경우 프로그래밍 언어 중에서는 그러한 문제를 가장 열심히 해결하려고 시도한 경운데, 대신 CPAN 모듈들은 재치있고 특이한 이름을 가지지 못하는 경우가 많다. 또한 CPAN 같은 방식으로 가려면 공동체의 관리 비용이 든다.

그래서 결론이 뭐냐하면, 사실 결론은 없고 그냥 내가 요즘 이런 고민을 하고 있다는 얘기를 써보고 싶었다.