내가 다루는 여러 정보의 파편들-여기서는 데이터라고 하자-은 대부분 그 크기가 작다.
내가 입수하는 정보들은 대부분의 경우 단편적으로 제공되는 것이 아니라 묶음의 형태로 제공된다. 온라인의 경우 파일, 웹페이지, 오프라인의 경우 책, 리포트, 잡지 등이 바로 그런 것들이다.
하나의 대상에 대해 학습하기 위해 난 이러한 데이터들을 수집하고 이를 읽는다. 각각의 묶음들은 스스로의 구조와 데이터를 가지고 있다. 즉, 책은 책대로, 파일은 파일대로, 스스로가 가지고 있는 정보를 이용자에게 전달하기 위한 데이터와 그 데이터를 잘 표현하는 구조를 가지고 있다. 실제로 전하려는 데이터는 유사하거나 중복되는 경우가 많지만 이러한 구성에 있어서는 보다 다양한 변화와 차이가 존재한다. 이 차이는 매체의 차이, 묶음의 작성자의 의도, 작성자의 능력, 묶음의 목적의 차이등에 기인한다.
이러한 서로 다른 구조와 목적을 가진 여러 정보의 묶음을 읽고 이해하면서 나는 또 내 목적에 맞추어 그 대상에 대한 나름대로의 구조화와 필요한 데이터의 취사선택을 한다. 이건 내 머릿속에서 또하나의 구조를 만들어 가는 것이다. 나의 목적에 맞는, 그리고 내 두뇌가 가장 잘 이해할 수 있는 나만의 구조이다. 이 작업 중에는 기존의 정보의 묶음에서 데이터는 재사용되는 경우가 많지만 그 구조는 데이터보다는 재사용율이 떨어지게 된다. -물론 변형되어 재사용되는 경우는 많다-
데이터는 데이터 자체로는 별 의미가 없다. 데이터를 어떻게 구조화하느냐가 바로 그 데이터에 어떤 의미를 부여하느냐 하는 과정이며 이것이 바로 의미있는 지식의 창조과정이다. 예전에는 데이터 자체가 희박했기에 데이터 자체에도 높은 가치가 있었지만 현재에는 컴퓨터 기술 및 웹의 발전으로 데이터의 입수는 상대적으로 손쉬워졌다. 지식을 습득하는 데 있어 실제로 중요한 작업, 그리고 현재의 컴퓨터 기술로 해결할 수 없는 것이 바로 이 구조를 만드는 것이다. 이 구조만 머릿속에 가지고 있으면 각 구조의 부분을 이루는 세세한 데이터는 어디에 있는지만 알면 된다.-또는 어디서 찾아볼 수 있는지만 알면 된다- 즉 향후에는 데이터를 알고 있는게 아니라 그 데이터를 어떻게 구성하느냐가 더 중요한 능력으로 보다 더 강조되게 되리라고 생각한다.
이 구조는 관점을 조금 달리 하여 보면 메타데이터라는 말로 표현하는 것이 가능하다. -실제로, 최근 읽은 Content Management Perfect Guide에서는 메타데이터를 데이터를 집어넣는 박스로 표현하기도 한다. 그리고 이 얘기는 2007년도에 내가 줄곧 집착해 온 ‘메타의 중요성’이라는 개념과도 일치한다-
여기까지는, 일반적인 얘기들이고, 이제부터가 내가 생각하는 문제점인데,
1: 제공되는 데이터의 묶음의 크기는 내가 이용할 묶음의 크기보다 크다.
- 대부분의 경우, 책이나 파일, 문서로 제공되는 데이터 중에 실제로 내게 가치가 있는 것은 전체 양의 10%를 초과하는 경우가 드물다. 결국 난 이 중에서 유용한 일부를 발췌해서 보관하고 관리해야 한다.
2: 구조와 데이터의 결합도가 강하다.
- 우리가 손에 넣을 수 있는 대부분의 정보는 이미 각자의 컨택스트를 가지고 그 안에 구조화되어 있는데, 그 구조와 데이터의 분리가 쉽지 않다. 즉, 책 한권 또는 하나의 PDF파일에서 실제 필요한 것 극히 일부에 지나지 않지만 그걸 자유로이 분리해서 재활용할 수 있는 충분한 여건이 주어져 있지 않다. -이건 Content Management Perfect Guide에서 말한 보존포맷과 표현포맷의 분리에 대한 얘기가 되겠다-
3: 구조를 표현할 수 있는 수단이 미비하다.
- 기존의 어플리케이션에 이러한 지식의 구조를 표현하기에 적합한 것이 없다. 컨셉트맵, 토픽맵, 마인드맵 등이 이러한 목적에 부합할 수 있는 어플리케이션들이라 하겠는데, 이들은 구조의 표현에는 강하지만 데이터의 관리에는 적합하지 않다. 더불어 기존의 태그나 디렉토리를 이용한 분류와 구조화는 지식의 구조화라는 관점에서는 무척이나 부족한 솔류션이다. 구조에는 분류보다 더 중요한 개념, 즉 관계라는 개념이 있는데, 태그도 디텍토리도 관계의 정의와 관리에 대한 솔루션이 아니기 때문이다.
그래서 내가 생각하는 바람직한 변화는,
1. 데이터 제공 및 사용의 단위는 아마 미래에는 조금 더 그 크기가 작아져야 할 것이다. 물론 수백페이지의 문서도 계속 존재할 것이다. 하지만 그러한 문서는 각각의 수없이 많은 정보 단위로 쪼개어 새로운 구조 및 묶음 속에서 자유로이 재사용이 가능해야 할 것이다. (이걸 OOP에서는 MVP Model이라고도 한다. 그 관점에서는 내가 말하고 있는 것은 Model과 View의 분리라고 하겠다)
2. 지식의 구조와 그 구조를 구성하는 데이터를 관리할 수 있는 새로운 형태의 어플리케이션이 필요하다. 이것은 내가 Yojimbo, MiniManager, OmniPlanner 등 여러 어플리케이션을 조합해서 사용하면서 얻고 있는 형태의 기능인데, 이러한 기능들을 하나로 통합한 조금 새로운 성격의 어플리케이션이 필요하게 될 것이다. 이 어플리케이션은 무엇보다 ‘관계’로써의 구조를 능숙하게 다룰 수 있어야 한다. 이 녀석을 CMS의 변형이라고 해야 할지, KMS의 변형이라고 해야 할지는 이 녀석을 어떤 관점에서 활용할 것인가에 대한 얘기이기에 굳이 지금 규정하고 싶지는 않다. 어쩌면 관계를 중요시한다는 점에서는 RMS(Relationship Management System)이라 명명하는 것도 가능하겠다.