Feeds:
Posts
Comments

RMS?

내가 다루는 여러 정보의 파편들-여기서는 데이터라고 하자-은 대부분 그 크기가 작다.

내가 입수하는 정보들은 대부분의 경우 단편적으로 제공되는 것이 아니라 묶음의 형태로 제공된다. 온라인의 경우 파일, 웹페이지, 오프라인의 경우 책, 리포트, 잡지 등이 바로 그런 것들이다.

하나의 대상에 대해 학습하기 위해 난 이러한 데이터들을 수집하고 이를 읽는다. 각각의 묶음들은 스스로의 구조와 데이터를 가지고 있다. 즉, 책은 책대로, 파일은 파일대로, 스스로가 가지고 있는 정보를 이용자에게 전달하기 위한 데이터와 그 데이터를 잘 표현하는 구조를 가지고 있다. 실제로 전하려는 데이터는 유사하거나 중복되는 경우가 많지만 이러한 구성에 있어서는 보다 다양한 변화와 차이가 존재한다. 이 차이는 매체의 차이, 묶음의 작성자의 의도, 작성자의 능력, 묶음의 목적의 차이등에 기인한다.

이러한 서로 다른 구조와 목적을 가진 여러 정보의 묶음을 읽고 이해하면서 나는 또 내 목적에 맞추어 그 대상에 대한 나름대로의 구조화와 필요한 데이터의 취사선택을 한다. 이건 내 머릿속에서 또하나의 구조를 만들어 가는 것이다. 나의 목적에 맞는, 그리고 내 두뇌가 가장 잘 이해할 수 있는 나만의 구조이다. 이 작업 중에는 기존의 정보의 묶음에서 데이터는 재사용되는 경우가 많지만 그 구조는 데이터보다는 재사용율이 떨어지게 된다. -물론 변형되어 재사용되는 경우는 많다-

데이터는 데이터 자체로는 별 의미가 없다. 데이터를 어떻게 구조화하느냐가 바로 그 데이터에 어떤 의미를 부여하느냐 하는 과정이며 이것이 바로 의미있는 지식의 창조과정이다. 예전에는 데이터 자체가 희박했기에 데이터 자체에도 높은 가치가 있었지만 현재에는 컴퓨터 기술 및 웹의 발전으로 데이터의 입수는 상대적으로 손쉬워졌다. 지식을 습득하는 데 있어 실제로 중요한 작업, 그리고 현재의 컴퓨터 기술로 해결할 수 없는 것이 바로 이 구조를 만드는 것이다. 이 구조만 머릿속에 가지고 있으면 각 구조의 부분을 이루는 세세한 데이터는 어디에 있는지만 알면 된다.-또는 어디서 찾아볼 수 있는지만 알면 된다- 즉 향후에는 데이터를 알고 있는게 아니라 그 데이터를 어떻게 구성하느냐가 더 중요한 능력으로 보다 더 강조되게 되리라고 생각한다.

이 구조는 관점을 조금 달리 하여 보면 메타데이터라는 말로 표현하는 것이 가능하다. -실제로, 최근 읽은 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)이라 명명하는 것도 가능하겠다.

이하 책 내용 중 일부 요약.

컨텐츠 = 데이터 + 메타데이터

데 이터와 컨텐츠(정보)는 다른 것이라는 점을 강조하면서, 컴퓨터는 데이터는 다룰 수 있지만 컨텐츠를 다루기 위해서는 그 컨텐츠를 설명하는 데이터가 있어야 한다고. 이것이 바로 메타데이터. 컴퓨터는 메타데이터를 통해 해당 컨텐츠의 종류를 알고, 어떻게 다루어야 할지를 안다. 즉, 메타데이터는 컨텐츠와 컴퓨터 사이의 중개자. 메타데이터든, 컨텐츠이던 데이터로 이루어진 것은 마찬가지. 결국, 그러한 데이터 파편들에게 규칙성을 부여하는 것이 인간이 해야 할 일.-현재의 패러다임의 컴퓨터(머리는 나쁘지만 힘은 장사)에서는 말이다-

메타데이터의 정의를 위해서는 컨텐츠의 단순화-책에서는 단순화이지만, 내 개념에서는 추상화가 맞다-가 필요하다. 이러한 단순화된 특징을 정의함으로 인해 컴퓨터는 동일한 사용형식을 취할 수 있게 된다. 즉, 컴퓨터는 컨텐츠에 대해서 아무것도 모른다. 단지 처리대상의 데이터와 처리방법을 지정한 데이터를 알고 있을 뿐.
세상에, 또는 컴퓨터상을 흘러다니는 정보에 대해 누군가가 조작을 가함으로써 컨텐츠가 된다. 그 조작이란 메타정보의 추가인 경우가 많다.

컨탠츠에는 표현용의 포맷과 보존용의 포맷이 있고, 이 두가지의 분리가 중요하다.
(좋 은 말이지만, 현실적으로는 거의 불가능에 가깝다고 하겠다. 참고로 이러한 니즈는 이미 기업시장에 구체적으로 나타나고 있고, 각각의 어플리케이션에 의존적인 기존의 문서, 데이터를 표현용 포맷과 분리된 독립적이고 표준적인 보존용 포맷으로 변환해 주는 툴에 대한 수요가 팽배하지만 공급이 없다고 하는 얘기를 최근에 스즈키상이 하더군. 그거 만들기만 하면 대박이라고 유혹하더라만, 그게 얼마나 삽질인 줄 알고 있으므로 웃으면서 무시했다.)

표현용 포맷에는 디자인적인 요소도 포함된다. 배치, 크기, 색상, 순서 등은 그 자체로 의미를 지닌다.

컨탠츠에는 구조가 있다. 그러한 구조는 이용자의 니즈에 따라 달라질 수 있다.
CMS는 지도에 비유할 수 있다. 동일한 지역에 대해 목적에 따라 다양한 지도가 존재하듯이 사용자의 목적에 맞는 복수의 구조와 뷰의 제공이 중요하다.

메타터(Metator)라는 새로운 Role의 필요성. 컨탠츠의 본체를 메타데이터의 구조의 관점에서 편집하는 정보 아키택트.

기능도 컨탠츠다.
(이건, 좀 과잉이다. 일부 기능에 대해서는 그렇게 말할 수 있겠지만, 그건 결과적으로 컨탠츠를 제공한다는 점에 있어서는 컨탠츠의 또 하나의 보존포맷의 얘기에 다름 아니지 않을까?)

CMS는 Context Management System이라고도 한다.

컨텐츠와 컨택스트의 관계는..
- 컨택스트의 제거에 의해 컨탠츠는 그 의미의 상당부분을 손실하게 된다. (경우에 따라서는 전부도..)
- 컨택스트의 제거에 의해 컨탠츠를 강조하는 경우도 있다. (신문기사를 오려내서 스크랩하는 경우. 그 기사는 며칠자, 어느 신문의 어느 란의, 어떤 위치에 배치되었던 기사라는 컨택스트를 잃어 버린다. (근데, 이러한 정보도 여기서 말하는 컨택스트라고 할 수 있을까?))
- 양자는 서로 보완관계에 있다.

CMS는 수집, 관리, 발행 시스템으로 구성된다.

——–

이하는 개인적인 생각들.

그 외에 이 책을 읽으면서 전체적인 개념을 책의 여백 페이지 한장에 쭈욱 그려 놓았는데, 이건 아날로그의 데이터라 이 곳에다가는 올리지 못하겠다. 역시, 아직은 디지털과 아날로그 사이의 벽이 높다.

결국, 컨텐츠 관리에 있어서, 인간이 개입하는 곳은 논리적으로는 두군데이다. 최초의 컨텐츠의 정의부분. 이는 여러 데이터를 목적에 부합되게 의미있는 순서, 조합으로 구성하는 것. 이로 인해 컨텐츠가 생성된다. 두번째는 이렇게 만들어진 컨텐츠를 적당한 곳에 배치함으로써 다른 컨텐츠들과의 관계, 즉 컨택스트를 부여하는 것이다. -맥에서는 DevonThink와 같은 일부 툴들이 이 두번째 행동을 부분적으로나마 지원하고 있다.- 물론 이러한 행동들은 컨텐츠의 크기에 따라 작은 컨텐츠에서 큰 컨텐츠로 이행하면서 계속해서 반복되게 된다.

위에 언급한 두개의 행동 외의 나머지 부분들은 컴퓨터의 프로그래밍으로 쉽게 자동화하는 것이 가능하다. 그리고 그게 바로 CMS이다.

Leopard에서 도입된 퍼포먼스 측정 툴. 어플리케이션의 가동상황을 실시간으로 보여준다.
백문이 불여일견. 아래 링크를 참조.

Instruments의 동작예

Leppard와 동시에 Objective-C도 2.0으로 업그레이드 되었다. 구체적으로 변경된 내용은 다음과 같다.

- Protocols and categories

- Fast Enumaration

- Garbage Collection

- Properties 의 도입

변경내용의 대부분은 개발생산성을 향상하기 위한 것들이다. 같은 처리를 기술하기 위한 기술내용이 그만큼 더 적어졌다. 특히 Garbage Collection의 도입에 의한 메모리 관리의 자동화와 Properties의 도입에 따른 Setter/Getter 코드의 자동생성은 피부에 와 닿는 개선점들이다.

각각의 변경내용의 상세에 대해서는 따로 정리할 예정.

이건 일전에 내 블로그에 Ha상이 적었던 댓글인데, 지금 내가 만들려는 녀석과 상당히 비슷한 개념이 되겠다. 이런 니즈를 다른 사람도 가지고 있다는 얘기!

自分の場合はビジュアルばかり見ているのでね
レペードの最新機能もいいですが自分としてはフォルダの中を自由に落書きできればなと思います。
例えば特定のファイルだけ一か所に集めてメモを付けたり色を塗ったりとファイル名のみよりは
見やすくなると思いますが・・・
また、僕は現在Winオンリーですがそろそろマックに戻ろうかと画策しています。
その日が来ましたらぜひ今までのノウハウをご伝授願います。

For the rest of us!

Apple의 슬로건이다. 거지같은 윈도우즈는 무시하고라도, 현재의 맥은 The rest of us, 즉 비 엔지니어인 일반 사용자가 사용하기에 적절한가?

내 대답은 아니다! 이다. 모두가 당연히 생각하는 파인더, 그것은 정말 최고의 작업환경인가? 작업? 어떤 작업?

사람에 따라 사용하는 어플리케이션이 다를 것이고, 또 어떤 직업군에 있느냐에 따라 다를 것이다. 그리고 또 어떤 직업군에 있던 공통적으로 사용하는 것도 있을 것이다. 자, 그럼 이런 생각은 어떨까?

영업맨 용 환경이 적용된 컴, 또는 작가용 환경이 적용된 컴, 또는 엔지니어용 환경이 적용된 컴. 노인용 컴. 아이들용 컴.

그런 환경이 각자의 사용자들이 정말 편하게 사용할 수 있게 되어 있어야 정말 The rest of us를 위한 컴이라 할 수 있지 않을까?

현대의 컴퓨터란 이른바 범용기이다. 범용기는 넓은 수비범위를 갖는 대신 최적화되어 있지 않다. 이대로 좋은가? 범용기와 전용기의 차이란 무엇인가?

기존의 OS와 어플리케이션 만으로는 메우지 못하고 있는 틈이 있다. 그곳이 기회의 땅이 될지도 모른다.

« Newer Posts