casaubon

Infinite Loop : Ars covers the world of Apple

Metadata, the Mac, and you

Introduction Metadata is simply "data about data." Within the context of the computer industry, the most common domain of metadata is the file system. Files contain data, which has some amount of associated metadata. The most fundamental property of metadata...

By John Siracusa | Last updated August 20, 2001 3:00 PM CT

Introduction

Metadata는 "데이터에 대한 데이터"이다. 컴퓨터 산업에서 메타데이터의 제일 일반적인 정의는 파일 시스템이라고 볼 수 있다. 파일은 데이터를 담고 있으며 데이터는 메타데이터들의 집합인 것이다. 메타데이터의 제일 근본적인 특성은 데이터 자체와 다르다는 점에 있다. 다시 말해서 메타데이터는 데이터에 대한 데이터이다.

단순하지 않은가. 하지만 그 정의 자체가 논쟁의 대상이라는 점은 놀랄만하다. 맥 오에스 텐의 등장은 맥 플랫폼의 미래에 대한 대규모의 전장으로 이 주제를 옮겨놓았다. 이점을 이해하기 위해서 우선 메타데이터의 근본을 알아보고 맥의 메타데이터의 과거, 현재, 그리고 미래, 또 전체 컴퓨터 산업을 조망해보겠다.

우선 마음에 염두해 두어야할 중요한 가정이 있다. 이 기사는 파일과 파일 시스템의 개념에 국한된다. 객체-관계 스토리지, 혹은 비슷한 파일과 디렉토리의 수렴과 같은 문제는 다른 섹션에서 다룰 것이며 포커스를 맞추기 위해 주요 기사로 다루진 않을 것이다.

피해야할 가정도 있다. 이 기사의 첫 번째 파트에 나오는, 메타데이터의 근본 개념은 구련 문제와는 별개로 알아본다. 메타데이터의 근본에 대해 읽을 때, 기술에 해박한 독자라면 실질적인 실행을 염두에 두지 않을 수 없을 것이다. 하지만 그/러/지/말/라. 판단이나 특정한 실행, 개인에게 친숙한 표준 등은 우선 접어두고 개념에 집중하기 바란다. 후반부에서 다루겠지만 우선은 근본에 대해 알아본 이후이다.

Fundamentals

메타데이터의 근본을 그리려면 우선 가상 파일부터 시작해야한다. 메타데이터없는 파일은 비트로 이뤄진 데이터일 뿐이다. "이 데이터에 대한 데이터"에서는 어떤 종류를 다룰 수 있는가? 우선 리스트를 만들어보겠다.

• The file's name. 메타데이터의 본질적인 부분이며 파일의 이름은 전통적인 파일 시스템 접근 메카니즘의 본질적인 부분이다.



• The file's location. 전통적인 파일 시스템에서 파일 고르기에는 이름 이상의 무엇이 필요하다. 파일의 로케이션은 호스트와 디스크, 디렉토리 구조의 조합이며, 파일은 파일의 이름과 로케이션을 하나의 "패쓰"(identifier; path)로 나타난다.
  
  대부분은 파일의 로케이션을 파일과 연관된 메타데이터의 조각으로 생각하려는 경향이 많다. 자, 여기서 첫 번째 테스트다. 개념적인 수준에서 "데이터에 대한 데이터"에 대해 생각하고 있는가, 아니면 이미 메타데이터로서 파일 로케이션 실행에 대한 생각을 하고 있는가?
  
  생각해보라. 파일 로케이션은 분명 "데이터에 대한 데이터"이다. 사실 파일 로케이션이야말로 데이터에 관한 "본질적인" 데이터이다. (나중에 메타데이터의 서로다른 타입에 대해 살펴보기로 한다)



• The nature of the file's data. 파일 데이터는 무엇을 대표하는가? 파일이란 무엇인가? 이미지인가, 영상인가, 텍스트인가? 이 개념은 파일의 "콘텐트 타입"이나 그냥 "타입"으로 불린다. 기본적으로 파일 분류(이미지, 소리, 영상, 텍스트 등) "포맷(JPEG, AIFF, MPEG2, Microsoft Word, 등)"이라고 알려진 것들이 그것이다. 혹은 매우 특별한 포맷을 가리키기도 한다. (GIF89a, Photoshop document with layers, Microsoft Word 6.0/95 등)



• The file's size. 파일 데이터는 용량이 있으며 제로도 포함한다. 다시 말해서, 메타데이터를 생각할 때 놓치는 점이기도 하지만 분명 용량도 존재한다. 파일 이름이나 로케이션처럼, 파일 정보의 본질적인 부분 중에 하나인 것이다. (파일 용량이 알려지지 않았을 때 파일 시스템의 한계에 대해 생각해보라)



• File dates. 파일과 연관된 여러 유용한 시간 정보를 생각할 수 있다. 생성된 날짜나 최종 수정된 날짜, 접근한 날짜 등이다.



• File permissions. 파일 날짜처럼, 다른 잠재적인 것도 생각해볼 수 있다. 이 파일을 누가 읽을 수 있는가? 누가 작성할 수 있는가? 누가 돌릴 수 있는가? 등이다.

자, 여기서 리스트를 멈추겠지만 완벽해서가 아니다. 특정한 파일에 연관지을 수 있는 다른 성질들도 고려할 수 있겠지만 우리의 목적을 위해 기본적인 개념에만 충실하겠다.

Types of Metadata

파일 메타 데이터와 관련된 또다른 짧은 리스트를 살펴보도록 하자.

• Name


• Location


• Type


• Size


• Dates


• Permissions

이 리스트를 그룹지어야한다면 어떻게 하겠는가? 공통된 특성을 갖는 메타데이터의 특정 분류가 존재하는가? 이점을 우선 생각해보자.



권한부터 시작해보겠다. 전통적으로 친숙한 메타데이터는 바로 권한과 관련이 있다. 권한은 데이터에 대한 접근 권한을 가리킨다. (생각해서는 안되는 실행과 관련된 부분, 기억나는가? :-)

메타데이터에서의 파일 권한의 성격은 변화시키면 자세히 알 수 있다. 파일 권한이 파일 데이터에 대한 데이터라는 것이 사실임에도 불구하고 데이터 자신과 관계없이 그 데이터는 변경시킬 수가 있다.

이런 성질을 갖는 것이 또 무엇이 있을까? 이름과 로케이션도 마찬가지이다. 이를테면 로케이션을 바꾼다 함이 파일 데이터의 변화를 의미하진 않는다.

파일 날짜도 일부분은 이 성질을 충족시킨다. 생성 날짜와 최종 수정 날짜(읽기 전용 접근을 가정해보자)도 또한 완벽한 독립 데이터이다. (다만 수정 날짜는 데이터 자신의 변화를 불러일으킬 수 있다)

우린 이렇게 데이터 자신의 변화와는 독립적인 메테 데이터 이름, 로케이션, 권한, 날짜의 일부)을 "독립 메타데이터"라고 부른다.

여기에 해당되는 메타데이터는 이미 그룹지어놓았다. (6개 중에 3.5개이다) 독립 메타데이터는 메타데이터의 가장 일반적인 타입이다. 거의 모든 메타데이터는 데이터 자신의 변화를 요구하지 않으면서 변할 수 있다. 하지만 독립 메타데이터가 메타데이터의 제일 중요한 부분은 아니다. 첫 번째 예시로서 파일 용량과 같은 다른 타입을 알아보도록 하자.

용량은 메타데이터의 본질적인 부분이지만 로케이션과 비슷하게 메타데이터라고 생각하지 않는 사람들이 많다. 왜일까? 아마도 용량이 너무나 당연시되기 때문은 아닐까. 파일의 용량을 정할 수 없다면 파일은 거의 쓸모가 없다! 예를 들어서, 오퍼레이팅 시스템이 용량에 대한 정보 없이 파일로부터 데이터를 읽어들이기를 멈춰야할 때를 알 수 있겠는가?

파일 용량은 필자가 "불변 메타데이터(immutable metadata)"라고 부르는 사례 중에 하나이다. 즉, 어떠한 데이터 셋의 변화도 시킬 수 없는 메타데이터인 셈이다. 달리 말해서, 불변 메타데이터는 데이타 자신이 변하지 않는한 절대로 변하지 않는다. 즉 "데이터-의존성" 메타데이터라고도 할 수 있겠지만 "불변"이란 단어를 붙임으로써 직접 변화시키지 못한다는 점을 강조하고 싶었다. 불변 메타데이타는 주어진 비트(즉, 데이터)와 관련해서는 영원하다는 것을 의미한다. 변화시키는 방법은 다른 데이터를 불러들이는 수밖에 없다.

불변 메타데이터의 한계를 깨는 것에 대해 생각해보자. 파일 "용량"이 실제 데이터 변화없이 변한다고 상상해보라! 불변 메타데이터는 데이터 자신에 묶여있어야한다.

불변 메타데이터로서 파일 용량의 개념은 용량을 앞서 묘사한 독립 메타데이터처럼 단순히 데이터에 "관련있는" 것, 혹은 데이터 자신으로부터 "딸린" 그 무엇으로 생각하는 것에 익숙해져있기에 받아들이기 어려울 수 있다. 하지만 불면 메타데이터의 정의가 바로 그것이다. 데이터 자체에 가차없이 묶여있기 때문이다.

변경 날짜에 대해서는 앞서 언급했는데, 변경 날짜 또한 불변 메타데이터이다. 날짜 변경은 데이터 자신의 변화를 불러일으키기 때문이다. 파일 변경 날짜를 데이터 자신의 변화 없이 변화시킨다 함은 파일 용량 메타데이터에 같은 일을 하는 것처럼 재앙적이진 않지만 "올바른" 행위도 아니다.

마지막으로, 파일 콘텐트 타입이 있다. 이 역시 불변 메타데이터이다. 파일 콘텐트 타입은 정의상, 데이터 자신의 변화가 없이는 변화하지 않는다.

사려깊은 독자라면 이미 불변 메타데이터가 데이터 자신의 변화 없이도 변할 가능성이 한 가지 있다는 점을 눈치챘을 것이다. 불변 메타데이터는 정확성을 늘리거나 줄일 수 있다. 예를 들어서, GIF 이미지로서 정의내리는 파일 타입 메타데이터를 들어보자. 이 파일은 앞으로 인터레이싱이 된 GIF89a이 될 수도 있다. 이런 파일 타입 메타데이터는 데이터 자신의 변화 없이 정확성을 반영시키도록 바뀔 수 있다. 비슷한 예로, 파일의 변경 날짜도 밀리세컨드 정도의 정확성을 변화시킬 수 있다.

여기서 메타데이터의 일반 원칙에 대해 알아볼 수 있다. 다른 형태의 정보들처럼, 더 많은 것은 일반적으로 더 좋은 것이다. 더 자세해진 메타데이터는 좀더 흥미로운 결정을 가능하게 해준다. 이를테면, 메타데이터의 권한 설정이 없다면, 파일 데이터 접근에 대해서는 현명한 결정을 내리기가 매우 어려워진다. 그리고 만약 파일 생성 날짜가 연도만을 포함한다면 1 년 안에 생성된 다른 관계 파일과 구별할 길이 사라져버린다. 즉, 정보는 권력이다.

메타데이터에서 분명한 사실은 다양한 형태의 정보들처럼, 무시하거나 지우기는 쉽지만 한 번 잃어버린 정보를 되살리기란 불가능하거나 굉장히 어렵다는 것이다. 파일이 마지막으로 언제 수정됐는 지 더이상 알 수 없다면(변경 날짜는 데이터 자신에 완전히 묶인 불변 메타데이터임에도 그러하다), 그 정보는 절대로 되살릴 수 없다. 데이터 자신은 남아있지만 데이터에 대한 정보는 완전히 잃어버린 것이다. 압축 손실의 예를 들어보자. CD 트랙을 MP3 파일로 바꿀 수는 있지만 MP3 파일을 다시 CD 음질로 원상복귀하는 것은 불가능하다. 즉 알려지지 않은 정보를 "덧붙일 수는 없다. 정보는 귀중하다.

Implementation

메타데이터의 전형적인 실행에 대해 앞서 언급하고 알아본 근본 개념을 이용해서 알아보겠다.

메타데이터 실행의 첫 단계는 메타데이터의 저장 장소를 정하는 것이다. 우선 데이터 자신은 어떠한 형태로 저장되어있다고 가정한다. 그다음, 메타데이터는 관련 데이터, 즉 메타데이터를 가져야한다. 앞서 언급한 것처럼 우리는 데이터 자신이 전통적인 계층 디렉토리 구조로 파일 형태로 저장된다고 가정하고 있다.

현재 존재하는 데이터 저장에 대한 가정 자체가 메타데이터를 요구하고 있다. 데이터를 어떠한 형태로 저장하려면 파일 로케이션과 이름, 용량 등이 어디엔가 저장되어야하기 때문이다. 이미 세 가지 메타데이터가 나왔다. 각 요소가 어떻게 저장되는 지 알아보자.

파일 로케이션은 전통적으로 각 디렉토리에 분산 저장된다. 이 시나리오에서 파일 로케이션을 읽어들인다 함은 닭이 먼저냐 계란이 먼저냐와 같은 문제이다. 전통적인 파일 시스템에서의 실행을 하려면 미리 파일 로케이션을 알고 있어야 한다. 여기서 독자 여러분은 디렉토리 구조를 올라가거나 내려가면서 파일을 파일 시스템 루트로부터 끌어들여서 구축할 것이다.

대부분의 파일 시스템에서처럼, 메타데이터를 읽어들이려면 파일 이름을 미리 알고 있어야한다. 파일 이름은 보통 디렉토리 안에 담고 있는 아이템 리스트를 저장하는 데이터 구조에 저장된다. 읽거나 쓰기 위해 파일 내부의 실질 데이터에 대해서는 포인터가 필요할 테지만, 이 말이 포인터에만 의존하는 파일 이름을 되불러들일 수 있어야한다 함을 의미하진 않는다. 이 말은 무엇을 생성하건 간에 파일 이름과 로케이션 모두를 파일 포인터가 알고 있었어야 함을 의미한다.

전통적인 파일 시스템에서, 파일 이름과 로케이션의 조합은 파일 아이덴티파이어를 구성한다. 어떠한 데이터이든지 일관적으로 수정되거나 되불러들이려면 나름의 아이덴티파이어를 갖고 있어야한다. 이러한 현실은 메타데이터로서 이름과 로케이션에 대한 논의를 어렵게 만든다. 미리 이 정보를 알고 있지 않는 한, 특정 파일 이름과 로케이션에 대해 말할 길이 없어지기 때문이다. 반면 파일 이름과 로케이션을 이미 알고 있다면 어떻게 논의하고 있는 파일이 어느 것인 지 알 수 있겠는가?

이러한 모순은 파일과 파일 시스템의 전통적인 실행에서 비롯된다. 만약 전통적인 파일 저장 개념을 탈피한다면 우린 또다른 파일 아이덴티파이어를 골라서 파일 이름과 로케이션을 "이미 알려지지 않는 한 절대로 알려질 수 없는 "메타데이터"라는 불편한 정의로부터 해방시킬 수 있을 것이다.

하나의 특정한 아이덴티파이어의 개념은 관계형 데이터베이스에서는 흔한 개념이다. 데이터베이스의 근본 개념 중에 하나는 한 행만 선택할 수 있더라도 하나의 밸루를 갖는다는 것이다. 전통적인 파일 시스템은 두 가지 정보(이름과 로케이션)를 주어진 파일에 접근하는 "열쇠"로 이용하면서 갈라진다. 어떤 파일 시스템(HFS+)은 특정한 상황에서 사용할 수 있는 특정한 파일 아이덴티파이어를 제공하기도 하지만, 파일 이름과 로케이션의 조합은 제일 많이 사용하는 파일 아이덴티파이어로 남아있다.

보통 용량 메타데이터는 두 가지 형태로 저장된다. 파일의 "너비"는 보통 기본 파일 시스템 구조에 파일과 패쓰의 처음과 끝의 형태로서 저장된다. (보통 데이터 "블럭" 사이에 포인터의 형태로 저장된다) 이런 정보에 기반하는 파일의 용량은 보통 요구받을 때마다 넘나들 필요가 없도록 캐시화된다.

이 시나리오에서, 정보의 실제 파일 용량은 처음과 끝 포인트, 패쓰 사이에 저장된다. 이렇게 구별된 파일 용량 가치는 단순히 캐시에 불과하다. 파일 용량 메타데이터를 꼭 없애야한다면, 파일 너비의 트랙을 우선 없애야한다. 더해서, 패쓰 구간으로 넓혀진 너비는 용량 메타데이터의 실질적인 저장 메카니즘이다.

하지만 실제 실행은 다를 수 있다. 각기 다른 곳에 용량 메타데이터를 저장시킬 수도 있고 블럭별로 포인트와 용량, 패쓰 조합을 이용할 수도 있다. 이 시나리오에서 끝점은 필요하지 않지만 이때 용량 정보는 더이상 캐시가 아니게 된다.

파일 이름과 로케이션, 용량은 "본질적인 메타데이터(essential metadata)"이며, 이런 본질적 메타데이터가 없다면 파일은 사용할 수 있는 형태로 남아있을 수 없다. 불면 메타데이터(용량)과 다른 두 가지(이름과 로케이션) 메타 데이터는 파일 아이덴파이어오러서 조합된 역할 때문에 특별히 독립 메타데이터이다.

파일 날짜와 권한은 "비-본질적 메타데이터(non-essential metadata)"의 첫 번째 조각이다. 즉, 이러한 메타데이터가 없어도 전통적인 계층 파일 시스템에서 사용할 수 있는 방식으로 파일이 남을 수 있다는 것이기 때문에 "비-본질적"이라고 부른다. 그렇다 하더라도 거의 모든 전통적인 파일 시스템들은 적어도 파일 날짜 컬렉션을 저장하는 메커니즘은 갖고 있다. 따라서 그러한 파일 시스템들은 반드시 자신의 구조의 일부를 메타데이터 저장에 넘겨야한다. 적어도 두 가지, 생성과 변경 날짜가 저장된다.

권한은 보통 네트웍화되거나, 다중 사용자 오퍼레이팅 시스템일 때 파일 시스템에 저장된다. 파일 날짜 저장은 너무나 일반적이기 때문에 권한이 파일 시스템의 메타데이터 구조와 나란히 저장되도록하는 논리적인 홈이 있게 마련이다.

비록 위의 메타데이터 리스트에 오르진 않았지만, 파일 소유권은 일반적인 실행의 허가와 나란히 움직인다. 이를테면 유닉스는 전통적으로 파일 접근을 파일 소유자와 그룹, 그리고 모든 사람의 형태로 권한을 나눠서 차단한다. 여기에서 메타데이터의 권한은 소유자와 그룹 메타데이터없이는 쓸모없다. 다시 말해서, 이 메타데이터는 생성 날짜와 권한, 그리고 다른 "비-본질적" 메타데이터와 나란히 단일 메타데이터 구조에 저장되기 마련이다.

마지막으로 파일 타입에 대해 알아보겠다. 날짜나 권한, 소유처럼 파일 타입도 비본질적인 메타데이터이며, 저장과 불러들이기에 이름이나 로케이션, 저장과 같은 메타데이터처럼 반드시 순서대로 저장하지는 않는다.

파일 타입 메타데이터의 성질에 대해 알아보겠다.

• 불변메타데이터이다. 데이터 자체가 바뀌지 않는 이상 변화하지 않는다.



• 비-본질적이다. 파일 타입 메타데이터 없이도 저장이나 불러들이기가 가능하기 때문이다.

불운하게도, 파일 타입 메타데이터가 완전히 알려져있지 않는 한 대부분의 파일과 관련된 더 높은 수준의 사용자 인터랙션은 어렵거나 불가능하다. 여기서 모든 문제가 시작된다.

------------------------------------------------------------------------
아직 파일 타입 메터데이터의 실행에 대해 논의하지 않은 채로 이 기사의 설명 부분을 마치겠다. 다음 파트는 이 주제를 다룰 것이지만 몇 가지 사적인 코멘트가 포함될 것이다. 특별히 현대적인 오퍼레이팅 시스템과 네트웍에 관계된 파일 타입 메타데이터를 특별히 맥 플랫폼에 맞춰서 조사해본다.

첫 번째 파트에 사적인 코멘트를 배제한 목적은 다음에 나올 논의에 대한 참고자료로서 사용하기 위함이었다. 위에 쓰여진 설명에 대해 강한 거부감을 느낀다면 나머지 기사는 읽을 필요가 없을 것이다. 필자는 논의의 기본으로서 근본 정의를 이용할 것이다.

자, 시작해보겠다.

The FIle Type Dilemma

일반적인 파일 메타데이터 저장 실행과 "근본적인 개념"을 돌이켜보면, 파일 타입 메타데이터가 어떻게 저장되는 지 알겠는가?

이미 우린 여러 가지 메타데이터 타입이 저장되는 지, 본질적 메타데이터와 불변, 독립 메타데이터들이 어떻게 파일 시스템 실행에 관여하는 지를 알아보았으며, 독립 메타데이터와 비-본질적 메타데이터가 파일 시스템에서 주어진 메타데이터 구조에 어떤 방식으로 저장되는 지에 대해서도 알아보았다.

그럼 이제 기술적으로는 비-본질적 메타데이터이면서 불변 메타데이터가 파일, 사용자 인터랙션에서 중요하다는 사실을 알아야한다. 파일 타입의 저장 실행을 알아보기 이전에 왜 이 메타데이터가 그렇게도 중요한 지에 대해 알아보자.

파일타입은 비-본질적 메타데이터로 분류된다. 파일 데이터가 파일 타입에 관계없이 저장하고 돌릴 수 있기 때문이다. 반면 우리가 관심갖는 바는 데이터 그 자체이다. 오퍼레이팅 시스템은 가능한 메타데이터(접속 권한이나 날짜 확인, 백업 확인 등)에 기반하는 결정을 ?뻗?嗤?파일의 콘텐츠는 파일 로케이션과 이름의 조합으로 이뤄진 데이터 그 자체를 요구하고, 파일의 너비와 데이터 패쓰에 기반한다.

파일 타입은 사용자가 특정한 파일 디렉토리를 사용하기로 결정했을 때 들어선다. 오늘날의 주류 컴퓨터 패러다임에서, 애플리케이션은 사용자가 파일을 보거나 편집하려는 지를 알아본다. 애플리케이션 그 자체는 파일의 데이터만을 요구하지만 파일의 타입과 포맷, 콘텐츠의 타입, 혹은 파일의 데이터를 구성하는 비트의 실제 성격을 무엇이건 간에 호출하여 사용하는 것에 의존할 애플리케?抉퓽?고르는 것이다. 그림이 있다면, 이미지 에디터 애플리케이션이 합리적인 선택이다. 음성 파일이라면 다른 애플리케이션이 좀더 적합할 것이다.

사용자가 애플리케이션을 스스로 찾을 수도 있다. 이경우 사용자가 파일 타입을 알아둬야한다. GUI 패러다임에서, 특정 파일을 다룰 애플리케이션을 정하는 과정(보통 "애플리케이션 바인딩"이라고 지칭한다)은 오퍼레이팅 시스템에서 이뤄진다. 사용자는 단순하게 파일을 열려한다는 결정을 비치기만 하면(즉, 전통적인 더블 클릭을 의미한다) 오퍼레이팅 시스템이 파일 타입을 실행에 적합한 애플리케이션을 고른다.

파일 타입에 따라 무엇을 저장할 수 있는 지를 정확히 조사해보는 것은 유용하다. 그저 "그림"이나 "음성"과 같은 막연한 파일 타입으로도 유용한데, "JPEG"나 "WAV"와 같은 좀더 특정한 타입의 메타데이터라면 좀더 정확하게 설명하고 읽어들일 수 있게된다. 좀더 정확한 사양이 필요한 경우도 있다. 예를 들어서 "마이크로소프트 워드 문서"라고 규정짓는다 하더라도, 이 문서 파일이 특정 워드 버전의 파일일 수 있는 것이다.

따라서, 저장 실행을 고려하기 전에, 조정할 것이 정확히 무엇인 지를 결정해야한다. 파일 날짜의 경우 진정한 선택이라고 할 수 있는 요소는 날짜와 초, 밀리세컨드 정도이다. 파일 용량의 경우 블럭과 바이트/비트이다. 파일 이름과 로케이션은 길이와 인코딩(ASCII, 유니코드, MacRoman 등)이다. 권한이나 소유 메타데이터는 OS의 보안 모델이 결정내린다. 그러나 파일 타입 메타데이터에는 엄청난 양의 가능한 저장 포맷이 존재한다.

실질적으로 저장된 데이터는 보통 일반적인 "이미지"와 매우 특정적인 "포토샵 3.0 문서"의 사이에 존재한다. 이정도의 정확성이라면 합리적인 결정으로 애플리케이션을 열고 특정 파일을 이해할 수 있다.

어떤 파일 타입 데이터를 저장할 지를 결정했다면 이제 데이터를 어디에 저장할 지 고려해야한다. 다시 말해서, 파일타입은 불변이며, 유저 인터페이스에서 중요한 역할을 하는 비-본질적 메타데이터이다. 파일 시스템에 관련되는 불변 메타데이터(용량)과 파일 시스템의 메타데이터 구조에 저장되는 메타데이터(변경 날짜)를 봐왔다. 파일 권한이나 생성 날짜와 같은 독리적이면서 비-본질적인 메타데이터도 메타데이터 영역에 저장된다. 그렇다면 파일 타입을 어디에 저장해야할까?

파일 타입 메타데이터를 저장해놓은 파일 시스템의 첫 번째 실행에서는 다른 메타데이터처럼 일단 저장되지만 매우 적은(몇 비트 뿐이다) 파일 시스템 구조일 뿐이다. 용량 제한은 예전에는 메모리와 디스크 공간에 좌우됐으며, 원래 형태의 파일 타입 메타데이터의 명료성에 필요했다.

다른 메타데이터들이 비슷한 제약을 갖기 때문이 이는 문제랄 것도 아니다. 이를테면 파일 소유 메타데이터는 뜻모를 유저 ID로 저장되지만 이 말이 사용자가 유저 ID "157"을 읽고 그게 "샐리"라는 사용자인 지를 기억해야하는 것은 아니다. 어느 곳에서건 사용자는 메타데이터 소유의 표시를 볼 수 있으며 오퍼레이팅 시스템은 실제로 파일 시스템에 저장된 유저 ID 대신 "샐리"라는 텍스트를 찾아서 표시한다.

하지만 초기 오퍼레이팅 시스템은 보통 파일 타입 메타데이터를 저장된 것처럼 정확하게 표현하곤 했다. "TXT", 혹은 "COM"과 같은 캐릭터들로 나오는 것이다. 인간은 정보 조각들을 갖고 장황하게 바꿔나가는 데에 기억력을 합리적으로 잘 사용할 줄 안다. TXT가 텍스트 파일을 의미한다 함은 157이 샐리라고 이해하는 것보다 훨씬 쉽다. 더구나 파일 타입 메타데이터를 "저장된" 메모리나 CPU로 표현하는 것은 좀더 복잡한 확장에 필요하기도 하다. 파일 타입 메터데이터 저장이 독특하게 남아있는동안 표현되는 정보는 기본적인 형태로 나타난다.

뒤어이, 오퍼레이팅 시스템은 파일 타입 메타데이터를 파일 아이덴티파이어(로케이션, 이름과 같이한다)의 세 번째 컴퍼넌트로서 통합한다. 파일을 완전히 정의내리기 위해서는 파일 로케이션과 이름, 타입을 제공해야하기 때문이다. 즉 몇 개의 파일이 같은 이름과 로케이션을 갖는다 하더라도 별다른 타입으로 존재할 수 있다는 의미이다. 이렇게 잠재적으로 혼란스러운 상황에 대한 타개책으로는 파일타입 메타데이터와 파일 이름 메타데이터를 편집과 표시하는 동안에 단순히 조합해서 "."과 같은 종류로 파일 타입 메타데이터를 암묵적으로 무효화시킬 수 있다. 즉, 파일 이름 확장자가 나오는 것이다.

이번 글은 파일 타입 메타데이터를 어떻게 저장하는 가에 대한 글이다. 우선적으로 생각해야할 점은 파일 이름 안에서 몇 가지 문자열로 파일 타입 메타데이터를 생각하는 것인 데, 만약 파일 이름 자체와 같은 것이라면? 그럴 경우 현존하는 실행에 영향을 받는 지를 고려해봐야할 것이다.

파일 이름 확장자를 만드는 과정 중에 일어나는 결정은 합리적이다. 원형 메타데이터의 단축은 그날의 저장 한계에 따른다. 파일 타입 메타데이터를 원형태로 나타내는 선택은 선택한 데이터포맷과의 연관성을 기반으로 나타난다. 표시괴는 파일 타입 메타데이터와 파일 이름 메타데이터는 자연스럽게 디렉토리 리스트의 이름과 타입 표시와 궤를 같이한다.

결과적으로 불변 메타데이터 조각은 독립 메타데이터 일부와 단일 로케이션으로 "in-band" 데이터로 이뤄진 경계기호 안에서 합쳐진다. 파일 이름 확장자는 "hack"으로 묘사되며, 다른 방법으로 빠르게 해결할 수 없는 문제에 대해 합리적인 수단을 뜻한다. 하지만 필자는 이런 식의 정의에는 동의하지 않는다.

파일 이름 확장자는 현존하는 실행에서의 문제를 해결하지 못한다. 파일 타입 메타데이터는 이미 파일 시스템에서 자신의 저장 로케이션을 갖는다. 여기에서는 파일 아이덴티파이어에 대한 파일 타입 메타데이터의 통합의 실행한계가 없으며, 파일 타입 메타 데이터를 파일 이름 안에서 인코딩하는 데 필요한 실행 한계도 없다. 파일 이름 확장자를 만드는 것이 해킹은 아니다. 단순한 실수이다.

The Legacy of FIle Name Extensions

파일 이름 확장자로 알고 있는 중대한 개발 결과에 대해 알아보자. 파일 타입 메타데이터의 저장 영역과 타일 이름안으로의 하위 통합을 지우면, 이제 불변 메타 데이터를 독립 메타 데이터의 변경으로서 바꿀 수 있게된다.

만약 이런 일에 익숙해져있다면 이보다 좋을 수는 없을 것이다. 이런 디자인 결정에 대한 사례를 하나 보이겠다. 파일 타입 대신에 다른 불면 메타데이터가 파일 이름 안에서 별도로 저장되기보다 인코딩된다고 가정해보자.

DOS 시대에서는 "report.294"나 "EIDT.559"와 같았지만 시대가 흘러가면서 좀더 긴 이름으로 "BooksReport.50K"나 "Microsoft Word.15MB"와 같은 표현도 가능해졌다.

물론 웃기다는 생각도 들 수 있겠다. 파일 이름 확장자에 대해서는 이와 같은 사례가 없다. 다시 말해서, "생각한 데로 움직인다"라는 아이디어로 사례를 메타데이터의 근본 정의를 이용해서 파헤쳐보라.

파일 타입이나 파일 용량이 파일 이름에서 어떻게 인코딩되는지 간에, 상황은 같다. 불면 메타데이터는 파일 이름 안에서 인코딩된다. 파일 타입과 용량 모두 불변 메타데이터로서 데이터 자체에 대한 변화가 수반되지 않고서는 결코 변하지 않는다. 더구나 파일 이름에서 이들이 불변 메타데이터로 인코딩이 가능하게 해주는 행위를 의미한다.

1980년대 퍼스널 컴퓨터의 발전으로 이런 조류에 역행하는 메커니즘도 등장했다. 파일 이름 편집에 대한 인터페이스는 궁극적으로 파일 이름을 편집하고 있을 때, 파일 타입 메타데이터를 바꿀 수 없게 만들었다. 윈도우즈라는 주도적인 그래픽 유저 인터페이스의 발전 아래에서 파일 이름 확장자는 기본적으로 전체가 가려지도록 만들어졌다.

파일 타입 메타데이터를 파일 이름에서 인코딩하는 선택은 유저에게 그 이상의 효과를 미친다. 중요한 것은 산업 전반에 걸쳐 파일 타입 메타데이터에서 저장 영역을 사라지게 만들었다는 것에 있다.

결과적으로 수천만 명이 사용하는 윈도우즈라는 컴퓨터 환경에서 대부분의 사용자들은 메타데이터에 대해 개념없이 받아들이고 있으며 더 나은 방법이 있다는 사실을 모르고 있다.

The Mac Way

퍼스널 컴퓨터 혁명 초창기에 애플은 사실 메타데이터에 대한 더 나은 방법을 생각하고 있었다. 이는 1984년 매킨토시가 주류 컴퓨터 인터페이스로서 그래픽 사용자 인터페이스를 소개했을 때, DOS 또한 주도적인 PC 플랫폼으로서 윈도우즈를 탑재하고 따라오게 되었다.

하지만 PC 플랫폼이 애플의 주도를 따라오지 못했고, 따라갈 수도 없었다. 예를 들어서 매킨토시가 선형 메모리 어드레스 공간을 통합시켰는데, PC는 즉각적으로 선형 메모리 어드레스 공간 확보를 할 수 없었다. PC는 메모리 아키텍쳐와 특정 CPU에 대한 투자에 적어도 단기적으로 발목이 잡혀있었다. 비슷하게, 맥이 개척해나간 GUI를 채택함에 있어서도 윈도우즈는 애플이 개발해낸 파일 메타데이터 시스템에 필적할만한 시스템을 채택할 수 없었다. 하지만 도대체 애플이 무엇을 이뤄냈을까?

이 기사의 주제에 대해 돌이켜보면, 파일 메타데이터에 대한 애플의 접근은 분명 지루하기 짝이 없다. 애플은 저장하고자 하는 메타데이터가 무엇인 지 결정하고 각 메타데이터를 파일 시스템의 메타데이터 구조에 지정한 로케이션으로 배당했다. 애플은 한 가지 형태에 로케이션과 이름, 용량, 타입, 날짜, 권한과 같은 아이템들을 저장했고 매우 직선적인 실행을 하였다.

불운하게도 1984년까지 이런 방식의 메타데이터 실행은 장단점이 공존했었다. 당시 파일 타입 메타데이터는 모든 플랫폼에 걸쳐서 공유하던 메타데이터의 파일 하위집합에서 제거됐었다. 일반적인 메타데이터의 목록은 파일 이름과 용량, 그리고 한 두개의 날짜만으로 이뤄졌었으며 "외부" 플랫폼의 어디에 저장할지 확신할 수 없었다.

사용자와의 관계에 있어서 중요한 파일 타입은 파일 메타데이터를 파일 이름에 인코딩시킨다는 치명적인 결정의 결과로 리스트에서 떨어져나갔다. 이런 결정을 내리지 않았더라면 파일 타입은 아마도 파일 이름이나 용량처럼 가상적으로 모든 플랫폼에서 독립된 저장 영역을 가졌을 것이다.

애플은 파일 타입 정보를 파일 이름에 인코딩시키지 않았다. 이 결정은 맥 플랫폼이 "친숙함"으로 유명해지도록 큰 도움을 주었다. 맥 사용자들은 파일 타입에 상관없이 나름의 합당한 이름을 줄 수 있었고 같은 로케이션 상에서 동일한 이름은 허용되지 않았다. 파일 타입 메타데이터가 표시될 때에는 "마이크로소프트 워드 문서"와 같은, 사람이 읽을 수 있는 형태의 텍스트로 표시가 됐고, 이는 혼란감없이 10여년 동안 32비트의 제한성 안에 저장 포맷으로 남을 수 있도록 도와주었다.

애플은 좀더 많은 메타데이터를 포함해서 다른 플랫폼보다 친숙함을 더해나갔다. 제일 영향력있는 것은 파일 생성을 한 애플리케이션을 표현하는 메타데이터였다. 맥에서의 애플리케이션 바인딩은 파일 생성 메타데이터로 애플리케이션을 선택했다. (필요한 경우 파일 타입으로 대체하는 경우도 있다) 같은 타입의 두 파일의 경우는 두 개의 별다른 애플리케이션에서 열린다는 의미이다. 심플 텍스트 에디터로 열리는 텍스트 파일도 있을 경우도 있을테고, 웹 브라우저나 HTML 편집기에서 열리는 텍스트도 있을 것이다. 애플리케이션 바인딩 과정은 완전히 파일 이름과는 독립적이다.

애플은 타입/크리에이터 애플리케이션 바인딩과 파일 이름에 대한 완전한 사용자 권한 등으로서 친숙함을 이뤄냈고, 이러한 친숙함을 애플은 광고에도 보여주었다. 윈도우즈 95가 나왔을 때 애플의 광고는 다음과 같다.

C:\ONGRTLNS.W95

당시 산업 전문가였던 져프 던컨(Geoff Duncan)의 말이다. "특별했던 이 애플광고의 제일 슬픈 부분은 아마도 사람들이 이해했다는 사실입니다."

물론 어떠한 맥도 섬같은 존재는 아니며 인터넷으로 표현되는 네트워킹의 확산은 과거 메타데이터의 죄악을 맥이 창조해낸 신성한 정원으로 불러들였다.

The Mac in the Internet Age

파일은 언제나 플랫폼을 넘나들지만, 인터넷의 확산은 크로스 플랫폼을 좀더 일반적인 현상으로 만들었다. 여기에서 맥은 두 가지 문제점들을 갖는다.

1. Sending files to another platform: 맥에서 다른 플랫폼으로 보낸 파일들은 메타데이터 조각들로 나뉘어져서 도착 플랫폼에 일정한 저장 영역을 차지한다.



2. Receiving files from another platform: 다른 플랫폼에서 받은 파일은 해당 플랫폼의 메타데이터만을 갖고 파일 타입 메타데이터를 주로 이름에 인코딩시켜놓는다.

이 문제들 때문에 애플은 맥 오퍼레이팅 시스템에 맥 파일 메타데이터(숨겨진 32비트 수치이다)와 파일 이름에 인코딩된 "외부" 파일 타입 정보(보통은 파일 이름 확장자를 의미한다)를 매핑해서 데이터페이스로 추가시켜놓았다. 이 데이터베이스는 사용자화시킬 수 있으며, 어떠한 맥 애플리케이션에서도 API를 통해 접근할 수 있었다.

다른 플랫폼으로 파일을 보내는 기능이 있는 맥용 애플리케이션은 파일 타입 메타데이터를 주어진 맥 파일 타입에 매핑되는 파일 이름 확장자를 인코딩시켜서 파일 이름에 추가시켜서 보낸다. 따라서 해당 플랫폼에 파일이 도착하면 타입 정보는 다른 플랫폼의 네이티브 파일 시스템에 저장할 수 있는 로케이션에 있게 된다.

다른 플랫폼에과 파일을 받는 애플리케이션은 타입 정보를 파일 이름에서 찾아낸 다음 해당하는 맥 오에스 타입 코드와 대응시켜서 파일에 부여한다. (파일 이름은 보통 바뀌지 않는다)

이런 방식으로, 파일은 메타데이터를 사용자가 직접 다룰 필요 없이 플랫폼을 넘나들 수 있었다. 이런 기능은 맥 오에스의 파인더를 포함해서 애플리케이션이 효율적이기를 요구했다. 그러한 지원은 결국 나왔지만 맥은 "파일 이름 확장자를 못이해하는" 플랫폼으로서, 심지어는 인터넷에 어울리지 않는다는 오명도 갖게 되었다. 물론 이런 오명은 맥 파일 메타데이터 저장 메커니즘 이상의 것이긴 하지만 말이다...

The Resource Fork

1980년대 초반 맥을 개발할 때, 개발자들은 파일 시스템에 확장적인 메타데이터 지원을 추가시켰다. 이들은 또한 "데이터"를 위한 별도의 저장 메카니즘도 만들었다. 단순한 비트 스트림을 이용하는 전통적인 데이터 저장과는 달리, 이 새로운 저장 메커니즘은 오퍼레이팅 시스템이 규정짓는 구조를 가졌다. 물론 전통적인 비트 스트림 방식도 남아 있었다. 이러한 두 가지 영역의 데이터 저장을 구분하기 위해 애플은 "포크(forks)"라는 별다른 것을 만들어냈다. 전통적인 데이터 스트림 비트는 "데이터 포크"라고 불렸고 구조적인 저장 영역은 "리소스 포크"라고 불렸다.

일반적으로, 리소스 포크는 메타데이터를 포함하지 않는다. (분명히 위에 제기한 메타데이터들, 이름, 용량, 타입, 생성자 등을 의미한다) 애플리케이션의 경우 리소스 포크는 애플리케이션이 읽거나 할 수 있는 파일 타입이 무엇인 지를 담아서 해당하는 애플리케이션을 가리킨다. 그러나 대부분의 경우 파일의 리소스 포크는 데이터이지 메타데이터는 아니다.

리소스 포크는 애플리케이션 리소스와 코드 간에 확실한 구분과 효율성을 증진시키기 위해 만들어졌다. 로컬라이즈된 스트링이나 이미지, 사용자 인터페이스 요소, 다른 리소스들이 구조와된 리소스 포크에 저장되며, 전체 리소스 포크를 메모리로 불러들일 필요 없이 개별적으로 사용할 수 있다.

메타데이터가 주제라는 점을 상기해 볼 때, 필자가 왜 리소스 포크만 언급하고 있는 지에 의문을 품을 수 있다. 우선, 필자는 리소스 포크가 어느정도 메타데이터를 담는 경우가 있지만 표준화된 파일 시스템의 메타데이터 구조에서 저장 로케이션을 가질만큼은 아니기 때문에 리소스 포크라고 언급했다. 두 번째로, 맥 메타데이터에 대한 제일 광범위한 오해 때문에 그렇다.

첫 번째 오해는 타입과 생성 메타데이터가 리소스 포크에 저장된다고 생각하는 것이다. 그렇지 않다. 타입과 생성자 메타데이터는 나머지 메타데이터들과 함께 파일 시스템의 메타데이터 구조에 저장된다.

두 번째 오해는 맥 파일의 타입과 메타데이터가 플랫폼간에 융통성이 없다는 것이다. 대부분의 다른 플랫폼들이 "싱글 포크" 파일 시스템을 갖추고 있기 때문에 리소스 포크를 갖고 있는 맥 파일을 리소스 포크와 데이터 포크를 싱글 비트 스트림으로 합체하지 않고 보내기란 불가능하다. 이러한 인코딩 스킴이 바로 "맥바이너리"이며 제일 많이 사용되고 있기도 하다. 맥 바이너리는 리소스포크나 파일의 메타데이터를 같이 인코딩시킨다.

만약 맥 파일을 이런 식으로 인코딩시키지 않는다면, 네트웍간 이동은 불가능하다. "싱글 비트 스트림"은 인터넷 시대의 국제어이기 때문에 설사 다른 맥으로 보낸다 할지라도 인터넷을 통한 이동에는 인코딩이 필요하다.

리소스 포크가 메타데이터가 아닌 데이터를 담는 다는 사실을 기억하라. 파일의 생성 날짜와 같은 메타데이터가 아니라는 중요한 정보이다. 리소스 포크는 본질적으로 데이터이며, 메타데이터가 없는 파일이란 보통 쓸모없는 파일이다.

"맥이 파일 이름 확장자 대신 타입과 생성자 코드를 사용하기 때문에 인터넷을 통해 맥은 파일을 공유할 수 없다."라는 통상의 오해는 바로 위의 내용들 때문에 나왔다. 물론 이 말은 틀린 말이며 인코딩이 없다면 위의 말은 맞다. 타입과 생성자 메타데이터는 위에 언급한 것처럼 다룰 수 있다.

Enter Mac OS X

애플의 차세대 오퍼레이팅 시스템인 맥 오에스 텐은 맥의 상호 운영의 문제를 해결하도록 디자인되어있다.

리소스 포크를 다루는 것은 선택적인 메타데이터가 아닌 본질적인 데이터이기 때문에 가장 큰 도전이었다. 맥 오에스 텐에서 애플의 리소스 포크 솔루션은 리소스 포크를 문서가 아닌 애플리케이션에서 발견하도록 했다는 사실에서 찾을 수 있다.

리소스 포크를 포함하는 맥 문서들(이를테면, 워드 프로세서의 문서인데, 단순 텍스트 데이터 포크를 저장하고 리소스 포크에는 서체 스타일 정보를 저장해서 다른 텍스트 에디터에서 읽을 수 있게 만들어진 문서를 말한다)도 있다. 크로스 플랫폼 파일 교환의 확산은 맥 리소스 저장 방식에 대한 해결을 요구했고, 인터넷은 리소스 포크를 포함하는 맥 문서 포맷을 급격히 감소시켰다. 대부분의 주류 맥 애플리케이션들은 현재 네트웍간에 지장없이 이동시킬 수 있도록 "합쳐진" 문서를 만들어낸다.

다행히도, 넥스트가 이전에 똑같은 문제를 "번들(bundle)"로서 해결한 적이 있었다. 일반적으로는 번들이며, 특별히 말하자면 애플리케이션 번들인 이 번들은 모든 리소스를 표준 파일 시스템 디렉토리 구조 안에서 은닉시킨다. 사용자 인터페이스에서 이런 디렉토리 구조는 단일 아이템으로 나타난다.

클래식 맥 오에스 리소스에 대한 지원이 완전히 없어진 것은 당연히 아니다. 하지만 애플리케이션 번들이 하나의 애플리케이션에 여러 개별 파일을 담을 수 있게 했기 때문에 현재 애플은 "리소스 포크"보다는 "리소스 파일"을 사용하기를 권장하고있다. 리소스 파일은 한때 리소스 포크에 저장되었던 구조화된 데이터들을 가리키는 단순한 파일이다. 따라서 리소스 파일은 어떠한 데이터 침식의 우려 없이 네트웍 간에, 플랫폼 간에 옮겨질 수 있다.

애플리케이션 번들과 리소스 파일의 콤비는 모든 맥 개발자들에게 이식성에 대한 문제 없이 클래식 맥 오에스 리소스를 사용하면서 애플리케이션을 만들 수 있게 해주었다. 달리 말해서, 맥 오에스 텐 애플리케이션은 리소스 포크를 사용 하지 않은 채 클래식 맥 오에스의 리소스로 채울 수 있다.

숨겨진 파일을 이용하여 "합체된" 파일 시스템 상에서 리소스 포크를 저장하는 맥 오에스 텐 파인더의 능력 덕분에 맥 오에스 텐의 상호 운영성은 크게 확장되었다. 특별히 크로스 플랫폼 이식성을 도운 것은 아니지만 오래된 맥 애플리케이션도 넥스트(UFS)라는 유닉스 파일 시스템에도 저장할 수 있게 한 것이다. 맥 오에스 텐 파인더는 어떠한 맥 파일도 UFS로 옮기거나 복사시킬 수 있다. 파인더가 사용하는 API는 다른 맥 애플리케이션에도 동일하게 적용된다.

문제가 있던 리소스 포크과 클래식 맥 리소스가 리로스 파일로 바뀌면서 맥의 상호 운영 딜레마는 해결된 것처럼 보인다. 이 문제의 해결을 위해 맥 오에스 텐은 단지 클래식 맥 오에스 메타데이터의 이식 기능이 필요했을 뿐이었다.

한 때, 맥은 넥스트가 만든 애플리케이션 번들과 애플이 맥 오에스 텐 용으로 만들어낸 리소스 파일, 애플이 클래식 맥 오에스 용으로 만든 파일이름 확장자 타입/생성자 코드 매핑 표, 이 모두가 맥 오에스 텐을 첫 번째 가는 네트웍 시민으로 만들어주었다.

하지만 불행히도, 이 솔루션이 맥 오에스 텐을 선택하게된 결정적인 계기는 아니다.

맥 오에스 텐에서의 리소스 포크는 앞서 쓴 방식으로 다루지만 파일 타입 메타데이터는 그렇지 않다. 버그일까, 기능일까? 상황에 따라 다르다. 맥 오에스 텐에서의 파일 타입 메타데이터에 대한 가장 기본적인 질문은 본 기사의 처음 부분으로 돌아간다. 맥 오에스 텐의 파일 타입 메타 데이터 저장 메커니즘은 무엇인가? 맥 오에스 텐의 기본 볼륨 포맷이 HFS+이기 때문에 메타데이터 저장 메커니즘이 클래식 맥 오에스와 다르지 않을 것으로 예상할 수 있다. 모든 파일 메타데이터가 HFS+ 볼륨 포맷에 내장된 메타데이터 구조에 저장된다. 하지만, 사실 맥 오에스 텐에서는 파일 타입을 "제외한" 모든 파일 메타데이터가 해당된다.

File Type Metadata in Mac OS X

맥 오에스 텐(본 기사를 작성할 때는 맥 오에스 텐 시스템 오버뷰 문서를 참조했다)의 파일 타입 메타데이터 저장 방식에 대해 애플의 공식 권장은 다음과 같다.

맥 오에스 텐에서, 두 가지를 특화시킴으로써 문서 타입을 표시할 수 있다.

• (만약 HFS, HFS+ 볼륨에서 만들어진)파일의 경우 타입과 생성자 코드는 파일의 속성으로서 저장된다.



• (.html이나 .htm을 예로 들 수 있다)관계된 파일 확장자 하나, 혹은 그 이상.

우선, 필자는 위에 제시한 파일 생성자 메타데이터에 대해 언급할 것이다. 생성자 메타데이터는 파일 타입 메타데이터와는 별개의 존재로서 애플의 파일 타입에 대한 묘사에는 포함되어있다. 생성자 메타데이터는 파일 타입을 정하는 데에는 어떠한 영향도 끼치지 않으며, 애플리케이션 바인딩 과정에서 맥 오에스 텐이 사용한다.

맥 오에스 텐에서의 파일 타입 메타데이터는 하나라기보다는 두 가지로 나타낼 수 있지만, 이것이 두 가지 정보의 조합으로 파일 타입을 나타내는 것인가? 아니면 단순히 파일 타입 메타데이터의 풍부한 저장만을 의미하는 것인가? 달리 말해서, 한 파일이 텍스트 파일임을 알기 위해서 파일 이름 확장자(.txt)와 파일 타입 코드(TEXT)를 모두 다 알아야 하는가? 아니면 한 가지만으로도 족한가? 둘 중 하나만 알아도 된다면 하나는 생략시켜도 될까?

첫 번째 질문에 대한 대답은 분명하다. 파일 코드와 파일 이름 확장자 모두를 아는 것은 맥 오에스 텐에서 파일 타입을 분별하는 데 충분하다. 다른 경우에 있어서 애플의 답변은 다음과 같다.

애플은 애플리케이션이 문서 타입의 두 가지 형태 모두를 사용할 수 있게 하는 것을 권장합니다.[...] 애플리케이션은 특별히 파일 확장자, 그리고 모든 가능한 타입의 문서 설정을 모두 갖춰야합니다.

메시지는 명확하다. 애플리케이션은 파일을 저장할 때 파일 확장자는 물론 파일 타입 코드도 설정해야한다. 파일 확장자대해 애플이 개발자들에게 특별히 주문한 부분을 눈여겨보도록 하자. 애플은 맥 개발자들이 파일 이름이 파일 타입 정보를 인코딩시켜하지 않을 것임을 알고 있으며 그 문제에 대해서는 다음과 같이 답변한다.

Why even have extensions?

파일 확장자에 대해서 환멸을 느끼는 매킨토시 소프트웨어 개발자들도 있다. 문서 타입과 소유를 지정하는 수단으로서 확장자는 타입과 생성자 코드에 비하면 원시적으로 보이며 다른 풍부한 메타데이터는 멀티-포크 HFS와 HFS+ 볼룸 포맷으로 가능해진다. 확장자를 사용한다 함이 퇴보처럼 보이는 것이다.

애플은 파일 타입 메타데이터 뿐만이 아니라 파일의 "소유" 개념도 포함시켰다. 또한 리소스 포크가 본래 데이터 저장 메카니즘으로서 타입과 생성자 코드의 저장 장소로 쓰이지 않음에도 리소스 포크도 포함시켰다. 애플의 말을 들어보자.

사실, 매킨토시 사용자들은 맥만으로 이뤄진 세계에 살고 있지 않습니다. 인터넷 시대에서 문서는 여러 네트웍을 넘나들며, 매킨토시에서 리눅스 네트웍 서버로 가거나 윈도우즈 컴퓨터로 갈 수 있습니다. 각 컴퓨터는 문서 타입 뿐만이 아니라 파일을 구성하는 것에 대해 각기 다른 접근을 할 것입니다. 대부분의 컴퓨터 시스템은 문서 타입을 잘 알려진 확장자 (.MP3, .html, .jpg 등)로 규정짓기 때문에 확장자가 없는 파일일 경우 알려지지 않은 타입으로 여겨버릴 것입니다. HFS+ 메타데이터도 무시하여 데이터를 읽어버릴 수 있습니다.

본 기사의 독자들을 위해서, 위의 정보가 그리 새로운 정보는 아님을 먼저 지적하고자 한다. 하지만 주의깊은 독자라면 다른 플랫폼의 파일 타입 정보가 파일 이름에 있다 는 말이, 맥 애플리케이션이 맥 자체에서 파일을 저장할 때도 그렇게 저장하라는 명령이 아님을 알 수 있다. 보다시피, 애플은 맥 애플리케이션 파일 타입 코드를 맥 플랫폼에서 알아보기 충분할 정도로 포함시키기를 권장하고 있다. 파일을 다른 플랫폼으로 보낼 때, 오퍼레이팅 시스템은 적합한 파일 이름 확장자에 맞는 정보를 갖는 것이다.

파일 이름을 "곧바로" 파일 타입 메타데이터에 인코딩하는 것 대신에 파일을 크로스 플랫폼으로 보낼 때, 애플은 애플리케이션이 해당 작업을 파일이 처음 만들어질 때 하게 하는 것을 권장한 셈이다.

이러한 권장에 모든 맥 사용자들과 개발자들이 찬동한 것은 아니다. 그동안 애플 소비자들은 파일 이름의 "소유권"에 대해 적응해오고 있었기 때문이다. 이러한 맥의 까다로운 메타데이터 저장 메커니즘은 파일 메타데이터에 대해 우려할 필요없이 파일 이름을 고를 수 있게 해주었다. 이름과 파일 타입은 관계가 없었기 때문이다. 이제 애플은 모든 맥 오에스 텐 애플리케이션들이 파일 이름을 갖추고 파일을 저장할 때 확장자를 자동으로 부착시키는 것을 권장하고 있다.
C:\ONGRTLNS.MOSX

여러분도 추측했듯이, 필자는 어떠한 맥 애플리케이션도 사용자에게 파일 확장명을 이름에 붙이도록 강요해서는 안된다고 생각하는 사용자 중 하나이다. 만약 파일 타입 정보가 32비트 타입 코드에 저장됐다면 이는 필자의 맥에서 파일 타입을 알아보는 데에 충분하다. 여기에서 왜 필자가 파일 이름을 굳이 바꿔줘야한단 말인가? 확장명은 맥 친숙함의 제일 큰 장점 중에 하나를 제거하는 것이다.

More from Apple:

사용자는 나중에 확장자를 바꾸거나 제거할 수 있지만 애플리케이션은 파일을 저장할 때, 확장자를 포함해서 모든 가능한 문서 타입을 언제나 적용할 수 있어야한다.

파일 이름 확장자를 제거하는 과정은 맥 오에스 텐이 아닌 그 애플리케이션이 실질적으로 결정한다. 만약 필자가 "Logo?(Second Revision)"라는 이름의 포토샵 문서를 윈도우즈 사용자에게 보낸다면 필자의 이메일 애플리케이션은 파일 타입 정보를 ".psd"이라는 확장자로 인코딩시키지 않는다. 즉, 수신자가 파일을 여는 데에 문제가 생긴다는 의미이다.

불행히도, 애플은 이런 방식으로 플랫폼 간의 이동에 대한 권장은 하지 않는다. 대신 우리가 본 바와같이, 맥 오에스 텐 애플리케이션이 파일 타입 메타데이터를 파일을 처음 만들자마자 이름에 인코딩시키는 것을 권장한다. 그렇게 하면 상호 이동에 대한 문제를 해결할 수 있다. 파일 타입을 따로 인코딩할 필요가 없게되는 것이다. 하지만 그대신 맥 사용자는 영원히 파일 이름 확장자와 같이 살아야한다.

이런 해결책은 필자로서는 받아들일 수 없으며 다른 맥 사용자들도 마찬가지일 것이다. 물론 애플도 알고 있으며, 앞으로 나올 맥 오에스 텐 10.1에서 상황을 바꿀 계획이지만, 해결책이 문제 자체보다 더 악화된 것처럼 보인다. 애플 웹 사이트에서 다음 글을 읽어보라.

파일 확장자는 맥 오에스 텐을 완벽한 인터넷 호환으로 만들어주지만 확장자 없이 살아가길 원하는 맥 사용자들에게 복잡한 레이어를 하나 추가시켰다. 이제 선택이 남았다. 이런 확장자를 화면 상에서 표시하지 않게 나타낼 수 있기 때문이다.

확장자를 가리는 것이 얼마나 도움이 될 지 알아보자. 파일 이름에 대한 소유권을 사용자에게 완전히 돌려준 것일까? 아니다. 보이게, 안보이게 하는 것은 이름 편집에 대해 사용자의 접근에 제한을 가져온다.

이런 해결책에는 문제가 있지만 "우선, 피해를 주지 말라"는 히포크라테스 선서도 충족시키지 못한다. 더해서 파일 확장자를 안보이게 하는 것은 실질적으로 다음과 같은 문제점들을 갖고 있다.

첫 번째 문제는 "Funny.txt.vbs"로 나타낼 수 있다. PC 지원을 한다면 누구나 이 유명한 바이러스 확산 트릭을 알고 있다. 윈도우즈가 기본?岵막?확장자를 가릴 수 있게 했음에도 불구하고 윈도우즈 사용자들은 어쩔 수 없이 확장자를 보이게 하고 사용하는 데에 익숙해져있다. 따라서 "Funny.txt"와 같은 문서가 윈도우즈 이메일 문서에 첨부되 나타난다면 사용자는 재미나는 문서로 인식하고 열려고 한다. 만약 이메일 애플리케이션이 비주얼 베이직 프로그램을 의미하는 ".vbs"라는 파일 이름 확장자를 가린다면 이 파일이 비주얼 베이직 프로그램인지 사용자는 알 도리가 없는 것이다. 만약 열게되면, 바이러스 확산 프로그램이 재미나는 문서 대신 돌려진다.

두 번째 문제는 제한된 형태이긴 하지만 맥 오에스 텐 10.0의 출하에서부터 실질적으로 존재해왔다. 아래 스크린 컷을 보라.


Will the real Finder please step forward

이를테면 같은 디렉토리 안에 "Finder"라는 이름의 두 가지 파일이 존재할 수 있다. 그중 하나는 ".app" 확장자가 가려져 있다. 맥 오에스 텐에서 ".app" 확장자는 디렉토리가 실제로 애플리케이션 번들임을 나타낸다. 같은 정보가 다른 방법(번들 안의 XML 프로퍼티 리스트는 물론 실제 HFS, HFS+ 메타데이터로도)으로 가능하기 때문에 파일 이름에 인코딩된 또다른 경우라고 할 수 있겠다.

맥 오에스 텐 10.0.x에서 ".app" 확장자를 "숨길 수 없게"하는 옵션도 없기 때문에 사용자는 같은 로케이션에 같은 이름의 두 가지 아이템을 가질 가능성이 없잖아 있다. 만약 파일 이름 확장자가 애플리케이션이 아닌 파일에서 숨겨진다면, 이런 복잡성은 더욱 커질 것이다.

다음에는 맥 오에스 텐에서 다른 파일 메타데이터 애플리케이션을 알아보자.

Application Binding in Mac OS X

"애플리케이션 바인딩"은 특정한 애플리케이션에 파일을 엮는 과정이다. 파일이 파인더 안에서 열릴 때(즉, 더블 클릭을 할 때), 맥 오에스 텐은 파일을 다루기 위해 애플리케이션을 선택해야한다.

클래식 맥 오에스에서, 애플리케이션 바인딩은 매우 단순했다. 파일이 생성자 메타데이터(32비트 생성자 코드의 형태)를 갖고 있고 생성 애플리케이션을 발견하면, 파일은 그 애플리케이션에서 열렸다. 그렇지 않다면, 사용자는 해당 타입을 열 수 있는 애플리케이션의 리스트에서 사용자가 골라야했다.

맥 오에스 텐에서 애플리케이션 바인딩은 좀더 복잡하다. 애플의 개발자 문서에 보면 완전한 설명이 나와있는 데, 간단히 말해서, 맥 오에스 텐에서 특정 타입의 문서를 "주장"하기 위해서는 애플리케이션에게 다중의 방법이 존재하며, 개별 파일을 열게되는 애플리케이션 사용자에 따라 무효로 할 수도 있다.

이런 고정된 애플리케이션 바인딩 전략의 문제는 특정 사용자의 작동에 맞지 않다는 것이다. 웹 개발자가 클래식 맥 오에스 바인딩 전략을 생성자 메타데이터(HTML 페이지를 텍스트 에디터나 웹브라우저에서 열 수 있게 해주는 예를 들 수 있다)에 기반해서 사용하는 것에는 합리적일 테지만 다른 사용자가 파일 타입 메타데이터(모든 HTML 파일은 같은 애플리케이션에서만 열리게 하는 예가 있다)만으로 애플리케이션 바인딩을 선택하길 원할 수 있다는 것이다. 세 번째 사용자는 애플리케이션 바인딩이 다른 파일 메타데이터의 조합에 기반하기를 원할 수 있다.

맥 오에스 텐 커뮤니티에서 애플리케이션 바인딩에 대한 끈질긴 논쟁중에 일어나는 제일 일반적인 논리 일탈이 바로 특정 파일 메타데이터와 애플리케이션 바인딩 전략의 존재 사이에서 일어나는 잘못된 연관성이다. 예를 들어서, 애플리케이션 바인딩 전략이 파일 타입 메타데이터에만 기반하기 바란다면, 맥 오에스 텐에서 모든 파일의 생성자 메타데이터를 지우길 원할 것이다. 파일 생성자 메타데이터의 존재는 생성 날짜 메타데이터의 존재보다 파일 타입에 기반하는 애플리케이션 바인딩 전략에는 전혀 피해가 없다.

더구나, 오퍼레이팅 시스템에서 더 많은 파일 메타데이터가 있다면 더 많은 애플리케이션 바인딩 전략도 가능하다. 하나의 애플리케이션 바인딩 전략으로는 모든 사용자를 만족시키진 못하므로, 될 수 있는 한 많은 전략이 필요할 것이다. 마지막으로 맥 오에스 텐은 애플리케이션 바인딩을 사용자가 조절할 수 있게 해야한다.

현재, 맥 오에스 텐 시스템 오버뷰 문서에 나온 애플리케이션 바인딩 전략은 하나의 전략만이 있다. 상당한 융통성을 제공하긴 하지만 모든 사용자들의 입맛에 맞진 않을 것이다. 예를 들어서, 생성자 메타데이터를 무시하는 애플리케이션 바인딩은 지원하지 않다. 애플리케이션이 "끝없이" 사제화시킬 필요가 없음은 당연하다. 그저 대부분의 사용자를 지원할 수 있어야한다. (파일 타입에 기반하는 "윈도우즈 스타일"이나 파일 생성자에 기반하는 "클래식 맥 스타일", 시스템 오버뷰에 기반하는 "맥 오에스 텐 스타일" 등등이 있을 것이다.)

필자는 파일 메타데이터의 존재에 대한 앞서의 주장을 되풀이하면서 좀더 높은 수준의 사용에 대해 논하고자 한다. "생성자 코드는 다중 사용자 오퍼레이팅 시스템"에서 돌아가지 않는다고 절대적으로 믿는 이들을 많이 봐왔다. 필자는 그런 사람들은 이 기사의 "fundermentals" 섹션을 다시 읽어보기 바란다. 파일 생성자 메타데이터는 단순히 파일을 생성한 애플리케이션만을 나타낸다. 특정한 저장 메커니즘이나 아이덴티파이어와 정확한 포맷에 대해 논하자면, 오퍼레이팅 시스템의 메타데이터의 존재에 대해 헷갈리지 말아야한다.

Metadata Miscellany in Mac OS X

파일 메타데이터에 기반하여 결정을 내리는 사용자 인터페이스에는 다른 면모도 많다. 파인더에 표시되는 아이콘을 예로 들자면, 이는 파일 메타데이터에 기반해서 결정된다. 맥 사용자는 아이콘이 파일 타입과 생성자를 모두 나타내기를 원하며, 파일 생성자 메타데이터에 기반하는 애플리케이션 바인딩이 파일을 더블 클릭했을 때, 특정 애플리케이션이 열리리라 예측할 수 있게 해주기를 바란다.

그러나 결정 과정에서 다른 파일 메타데이터를 사용하기 위해 애플리케이션 바인딩 전략이 바뀌고, 아이콘 표시 전략이 파일 타입과 생성자 메타데이터에 묶여있다면, "포토샵 문서" 아이콘을 가진 파일도 다른 애플리케이션(Preview같은 애플리케이션)에서 열릴 수 있다. 따라서 아이콘 표시가 애플리케이션 바인딩 전략에 묶여서는 안된다. 즉 아이콘 표시는 파일 메타데이터에 간접적인 기반을 가져야한다는 것이다.

보면 알겠지만, 가능한 상호작용은 매우 빠르게 돌아간다. 이러한 일을 생각하고 있을 때, 기초를 잘 염두에 두기 바란다. 메타데이터는 단순한 정보이며 사용자 인터페이스는 그러한 정보의 조합에 기반하고 있다. 결정 과정에 사용되는 정보의 객체화를 혼동하지 말기 바란다.

The Future of Metadata in Mac OS X

그렇다면 맥 오에스 텐에서의 파일 메타데이터의 미래 애플 계획은 무엇일까? 그런 계획이 있다는 가정 하에서의 말이다.

애플리케이션 바인딩 메커니즘은 미래에 필요한 경우 몇 가지 고쳐야 할 점을 만들고 있다. 애플리케이션 바인딩이 사용자화에 있어서는 상당한 이점을 제공하지만, 현재 형태에서는 보다 전통적인 맥 사용자들의 기대를 충족시키고 있다고 생각한다. 하지만 다른 플랫폼에서 맥 오에스 텐으로 이주해올 사용자의 기대는 못미치는 것 같다.

파일 타입 메타데이터 저장은 그렇게 장미빛은 아니다. 필자에게는 애플이 맥 오에스 텐 파일 이름에 메타데이터를 인코딩시키는 것을 권유하는 이유는 딱 두 가지 같다.

첫 번째 가능성은 애플이 생각하기에 애플리케이션 개발자들이 이식성을 고려할 때, 파일 타입 메타데이터를 파일 이름에 인코딩시키기를 할 수도 없을 뿐더러 원하지도 않는다고 여기는 것이다. 필자는 이런 누명에 동의하지 않는다.

애플리케이션은 인코딩하는 데에 필요한 모든 정보를 분명히 갖고 있다. 파일 이름 확장자와 함께 파일을 저장할 때, 애플리케이션은 같은 메커니즘을 사용하는 파일 타입에 근거해서 적합한 확장자를 찾을 수 있다. 언제 그러는가도 다루기 쉬운 문제이다. 대부분의 경우, 애플리케이션은 파일 이름 외부(즉, HFS, HFS+, 심지어는 맥 오에스 텐 파인더에서 같은 API를 사용하는 UFS도 포함한다)의 파일 타입 메타데이터를 저장하기 위한 볼륨 포맷으로 저장할 지 안할 지 분명히 결정할 수 있다.

확실하지 않은 경우에는, 상당한 옵션이 존재한다. 확실하지 않은 상황에 대해서, 애플리케이션은 사용자 프리퍼런스를 제공할 수 있다. (이를테면 네트웍 디스크로 저장할 때는 언제나 파일 확장자를 붙인다를 지정할 수 있겠다) 또한 동작을 저장할 시간을 정하도록 할 수도 있으며, 시스템 전반에 걸친 프리퍼런스(시스템 프리퍼런스에서 언제나 파일 확장자를 붙이거나, 절대로 붙이지 않는 옵션도 선택할 수 있다)를 초기화시키거나, 위의 모든 방법들을 조합시킬 수도 있다.

개발자들이 권고 사항을 따르려 하지 않는다는 우려는 개발자들이 애플의 어떠한 권고도 따르지 않을 것이라는 우려만큼이나 가치가 있다. 필요할 때에만 파일 타입 메타데이터를 파일 이름에 인코딩시키는 권고가 현재의 권고만큼 따르지 않을 것이라고 생각하진 않는다. 필자는 두 방법 모두 따르려 하지 않을 개발자도 있을 것임을 확신한다.

애플이 파일 타입 메타데이터를 맥 오에스 텐의 파일 이름에 인코딩시키려는 권고에 대한 두 번째 이유는 맥 오에스 텐의 네이티브 불륨 포맷의 파일 타입 메타데이터 저장 영역을 결국 없애기 위한 준비를 하기 위함이다.

이러한 결론에 대한 증거는 많다. 우선, 파일 이름에 파일 타입 메타데이터를 인코딩시키지 않는 것이 시스템 오버뷰에 묘사된 메커니즘에 어떠한 영향이 없음에도 파일 타입 메터데이터를 파일 이름에 인코딩시키지 못할 경우의 결과에 대한 애플의 지속되는 우려때문이다. 파일 타입 메타데이터는 오퍼레이팅 시스템에서 계속 호출가능하며 애플리케이션 바인딩도 영향받지 않는다. 진정한 결과는 애플의 파일 타입 메타데이터 정책 그 자체이며, 파일 타입 정보를 잃을 수 있을 때 파일 이름에 파일 타입 메타데이터를 인코딩시키는 애플리케이션에 대한 권고는 없다.

두 번째로, 현재의 파일 이름 확장자의 보존은 맥 오에스 텐에서는 불필요하다. 예를 들어서, 애플리케이션 번들은 맥 오에스 텐 10.0일 때부터(.app 확장자의 형태인데, 파인더에선 숨겨져있다) 파일 이름에 인코딩시킬 필요가 없는 파일 타입 메타데이터를 갖고 있다.

마지막으로, 친숙함을 늘리려는 애플의 의도가 파일 이름에 언제나 인코딩되는 파일 타입 메타데이터의 가정 하에서 벌어지고 있다. (현재 어디에 있건 상관이 없다) 이런 가정 하에서의 사용자 인터페이스의 "향상"은 문제가 있을 수 있다. 파일 이름 확장자를 숨겼을 때, 근본적인 문제를 풀 수 없다. (사용자는 파일 이름에 대한 완전한 권한을 원한다) 근본적인 문제는 파일 이름 확장자가 언제나 존재한다는 가정과 모순되기 때문이다!

말할 필요도 없이, 필자는 바깥의 컴퓨터들이 지난 과거에 벌여왔던 실수(바로 파일 타입 메타데이터의 저장 영역을 지우는 것이다)를 되풀이하려는 것은 엄청난 실수라고 생각한다. 지난 10년은 거의 모든 파일 시스템에 있어서 메타데이터 저장 영역의 첨가로 점철되어왔다. 이 기능에 대한 유명 오퍼레이팅 시스템의 사용은 미래 방향에 비해 뒤쳐져있다. 미래에는 좀더 많은 메타데이터가 필요하다. 경쟁자들이 10년동안 벌여왔던 실수를 되풀이하는 것은 너무나 근시안적이며 자기 파괴적이다.

맥을 사용한다는 장점이 맥 오에스 텐에서는 둔화되고 있다는 느낌이 맥 커뮤니티 안에 감도는 형편이다. 애플의 적은 시장을 감안할 때, 상호 운용을 위한 협상은 필요하지만 맥 친숙함의 일면을 희생없이 상호 운용성을 향상시켜야하며 애플은 여기에 최선을 다해야한다. 맥 오에스 룩앤 필의 어떠한 부분이건 다른 플랫폼을 그대로 베낀다면 결국 맥에 대한 매력을 감소시킬 것이다.

The Future of Metadata

메타데이터의 미래는 확실하다. 좀더 정확하고 많은 수의 메타데이터가 필요하다. 이런 경향이 추측하기 어려운 것은 결코 아니다. 파일 시스템이 바로 쉬운 예이다. 가상적으로 모든 새로운 파일 시스템은 현존하는 파일 시스템의 단순한 반복이 아니며 이전 파일 시스템보다 좀더 많은 메타데이터 영역을 갖고 있다. 파일 시스템이 좀더 "깔끔해"질 수록 더 많은 메타데이터 지원이 이뤄질 것이다.

BeFS는 바로 좀더 많은 메타데이터를 향한 "깔끔한" 첫 번째 예였지만 이렇게 코너에 몰린 예를 들 것도 없을 것이다. 최신 마이크로소프트 NTFS는 엄청난 양의 파일 메타데이터를 지원할 뿐만이 아니라 맥의 리소스포크와 닮은 다중 데이터 스트림도 지원한다. NTFS는 윈도우즈 XP의 기본 파일 시스템이며 윈도우즈 로고 프로그램의 공식적인 권장 사양이다.

파일 시스템 메타데이터의 사용은 많이 뒤쳐진 형편이다. (예를 들어서, HFS+는 맥 오에스가 255자 파일 이름을 지원하기 이전부터 그러한 다중 이름 스트림을 지원해왔다) 방향은 분명하다. 메타데이터는 친숙함을 더해주고 새로운 상호작용을 가능하게 해줄 것이다. 다다익선이다.

메타데이터 정확성을 늘리는 것은 저장할 수 있는 메타데이터 가짓수를 늘리는 것과 궤를 같이한다. 파일 타입 메타데이터가 좋은 예이다. "텍스트"라는 파일 타입이 충분해보인다면 메타데이터에 대한 풍부한 지원은 파일이 유니코드와 HTML, XML을 지원하는 애플리케이션에서만 열린다는 "UTF-8 text formatted as XML following the XHTML 1.0 spec" 표시를 허용할 것이다.

BeFS는 MIME 타입("text/html", 혹은 "image/gif")을 사용해서 이런 방향으로 움직였다. 다른 메타데이터들도 비슷하게 향상시킬 수 있다.

무한한 소원처럼, 제일 이상적인 메타데이터의 실행은 바로 확장가능한 메타데이터일 것이다. 확장가능한 메타데이터는 주어진 데이터에서 어떠한 타입이건 연관지을 수 있으며, 어떤 타입이 앞으로 필요할 지, 얼마나 필요할 지 당장 알 수는 없기 때문에 중요하다. 지정된 장소에 정해진 수의 메타데이터만을 지원하는 것은 너무나 제한적이며 근시안적이다.

확장가능한 메타데이터는 모든 메타데이터가 일정한 저장 로케이션을 가지면서 어떠한 플랫폼에서도 가능한 상호 운용성을 지원한다) 그러나 각 플랫폼의 메타데이터 모음으로 해결하는 것은 미봉책이다. 풍부한 메타데이터의 완전한 장점을 갖는 진정한 상호 운용성은 메타데이터의 표준을 정하는 일이다.

오늘날, 파일 타입 메타데이터는 일반적으로 네트워크 파일이 서로 다른 저장 메커니즘을 갖는 플랫폼 간을 이동할 때 MIME 타입으로 대표된다. MIME 표준이 Multipurpose Internet Mail Extensions을 표현하긴 하지만, HTTP와 같은 수많은 프로토콜에서 이용된다. 공개 표준이면서 중앙집중화된 등록 절차를 갖기 때문이다. 마이크로소프트와 애플은 파일 메타데이터 인코딩에 비슷한 등록 데이터베이스를 유지하고 있다. 공개 표준은 상호 운용에 대한 장벽을 줄이기 위해 디자인되어있기 때문에 성공적인 미래의 메타데이터는 분명 공개 표준에 근거할 것이다.

마지막으로 우리가 알다시피 "파일"의 정확한 개념은 궁극적으로 덜 중요해질 것이다. 표준화되고 충분히 확장가능한 메타데이터가 가능해진다면, 데이터는 로케이션이나 이름과 같은 전통적인 정보보다는 어떠한 메타데이터 하위집합으로도 접근가능할 것이다. 이런 시나리오라면, 데이터 탐색과 데이터 선택의 차이점은 중요성을 잃을 것이다.

컴퓨터 산업에서 파일 메타데이터를 지원하는 오퍼레이팅 시스템만큼 진보가 더딘 분야도 거의 없으며, 심지어는 마이크로소프트도 헤어나는데 어려워하고 있다. 지난 20여년 간의 컴퓨터 산업에 있었던 거대한 도전들을 돌이켜보고, 메타데이터 지원에 대한 믿을 수 없는 느린 진보에 대해 생각해보라.

심지어는 제일 보수적이고 모든 표준을 둘러싸고 있는 네트워크 프로토콜도 메타데이터에 대한 지원에 대해서는 오퍼레이팅 시스템보다 한 수 위이다. 현재 인터넷 기능을 구성하는 거의 모든 프로토콜들은 HTTP에서 SMTP, IPv6에 이르기까지 메타데이터를 확장 지원하고 있다.

실로, 오퍼레이팅 시스템이 메타데이터 영역에서 보인 일반적인 실수는 인터넷을 구성하는 네트웍 프로토콜이 메타데이터와 타협할 수 없는 면이 있다는 일반의 오해에서 비롯되었다. 이를테면, "파일 확장자가 웹에서 꼭 필요하다"라는 말을 얼마나 많이 들었는가?

HTTP 프로토콜을 안다면, "웹"이 분명히 HTTP 헤더의 형태로 메타데이터를 확장적인 형태로 지원한다는 사실을 알 것이다. 파일 타입 메타데이터는 그러한 헤더로 전송할 수 있다. 하지만 유명 오퍼레이팅 시스템들은 웹서버 소프트웨어에서 만든 파일을 기본적으로 파일 이름에서 끄집어낸 정보에만 기반하여 인코딩된 파일 타입 메타데이터만을 저장시키고, 가끔은 HTTP 헤더로 전송된 파일 타입 메타데이터를 무시해버리는 웹브라우저 소프트웨어도 있다.

오퍼레이팅 시스템이 메타데이터에 대한 지원을 늘린다면, 이미 사용되고 있는 풍부한 메타데이터 네트웍 프로토콜과의 상호작용은 좀더 복잡해질 것이다.

Conclusion

이 기사는 파일 메타데이터의 근본을 탐색하고, 맥 플랫폼에서 메타데이터의 과거, 현재, 미래에 대해 알아보았으며, 일반적인 메타데이터의 미래에 대해 생각해보았다. 전체에서 주제를 잡는다면, 메타데이터에 대한 지원의 증가가 이뤄져야한다는 것이며, 이는 친숙함을 늘려주고 새로운 일을 가능하게 해준다. 즉 산업계를 완전히 한 단계 진보시켜주는 것이다.

메타데이터의 지원은 제일 완고한 소프트웨어 기술 중 하나이다. 다른 산업계가 진보를 거듭하는 동안 오퍼레이팅 시스템의 메타데이터 지원은 계속 암흑 시대에 머물러있다. 만약 파일 메타데이터에 대한 상황이 이대로라면, 결국 손해는 사용자들의 몫이다. 문제는 혁신적인 컴퓨터 업체가 메타데이터 기술을 후퇴시킬 기술을 추진하고 있다는 데에 있다.

여러분이 맥 사용자이건, PC 사용자이건, 전문가이건, 초심자이건, 프로이건, 취미로 컴퓨터를 다루건 간에, 적어도 파일 메타데이터에 대해 생각해보길 바란다. 근본에 초점을 맞추되 크게 생각하라. 파일 메타데이터는 거의 모든 컴퓨팅 생활에 관계가 있다. 파일 메타데이터에 대한 작은 향상이라도 그 효과는 눈사태처럼 클 수 있다. 정말이지, 필자는 손자들에게 파일 이름 확장자에 대해 설명하고 싶지 않다. 모두 도와달라.

__________________

dasomcom

늘 감사하며 올려주신글 읽고있습니다 ^^;
저에게 많은 도움이 되는군요.
매우 긴글 번역하시느라 고생많으셨겠네요?
확장자와 메타데이터 정말 좋은 정보네요.
글을 읽으니 확장자를 써야한다는게 참 안타깝네요.

__________________
반갑습니다.