SeeAlso FreeChargeFunction, WikiWiki
자동성이 낮고 유연성이 높은 시스템에서는 참여 객체들이 똑똑해질 여지가 많다. 시스템 전체의 Evolution을 촉발하는 것이다(이 진화의 전제 조건은 객체 각각의 자율성autonomy과 상호소통intercommunication의 자유로움의 보장이다). 또한 자신들만의 문화를 형성하고 공유할 수 있게된다. 자동성이 높고 유연성이 낮은 시스템은 어떤 새로운 EmergentProperty도 가져오지 못하며, 낮은 유연성으로 조만간 도태되고 폐기되어진다. 자동성이 높다는 허울아래 器的 성질이 강한, 즉 어느 한쪽으로의 쓰임을 강요하는 하이테크 제품일 수록 그 생명주기가 짧을 수 있다. 자동성이 높고 유연성도 높은 시스템은 일단 한방에 존재하는 경우가 극히 드물뿐더러, 그 시스템에는 새로움에 대한 모티베이션이 부재한다. 자동성과 유연성 모두 낮은 시스템은 고정화되고 이미 죽은 시스템이다.
일반적으로 시스템의 변화 주기는 다음의 단계를 거친다.
- 저자동저유연(藏)
- 저자동고유연(生)
- 고자동고유연(長)
- 고자동저유연(收)
- (다시 "새로운" 저자동저유연으로)
> > fffffff aaaaaaa > f af a > f a f aa > f a f a >-------ff-------a--------f--------a--------- >a f a f a > a ff a f a f > fa aa f fa >ff aaaaaa ffffff aaaaa > 자동성 유연성 > >유연성은 자동성 비해 1/4 위상(phase) 앞서 간다
시스템의 지속과 발전, 진화의 문제는 결국, 어떻게 하면 이 싸이클을 끊임없이 부드럽게, 면면히 이어지도록(참여 객체들이 멸종하지/전체이주/해산 하지 않도록) 할 수 있을 것인가와, 어떻게 하면 다음번의 싸이클(한바퀴 돌고난 후)에서는 이전보다 좀 더 수준 높은 차원의 자동성과 유연성을 획득할 수 있을까, 또, 이 획득된 문화와 패턴을 다음 싸이클까지 축적하고 전달할 수 있을까(참여 객체들이 물리적으로 계속 남아있어야만 하는 것은 아니다)하는 것이 핵심이다.
--JuneKim
<질문1> 위의 그래프는 순수가정인 이론적이기만 한 것인지 아니면 실제 측정과 경험적 자료에 바탕을 둔 것인지, 만일 후자라면 자동성과 유연성의 측정(measures)은 어떻게 이루어진 것입니까?
가정과 개인적 경험, 직관 등에 기반한 가설입니다. 측정은 여러가지 방법이 있을 수 있겠죠. 시스템 내에 자율적 참여 개체가 상호적으로 참여하지 못하지만, 이런 예가 될 수 있는 것으로 OperatingSystem의 변화를 볼 수 있습니다. 자동성의 측정은 사용자가 한 두 번의 단순한 동작으로(혹은 명시적 동작 없이) OS의 디자이너가 의도했던 기능(1차적으로 이런 기능이 사용자에게 명확하게obviously 노출되어야 함, 반면 사용자의 명시적 지시없이 자동으로 동작하는 기능은 노출되지 -- 사용자의 주의를 절대 끌지 않음 -- 않고 내부적으로 실행됨)을 사용하는 경우의 수로 대신 할 수 있고, 유연성의 측정은 orthogonality라고도 하는 것, 즉 단순한 기능들을 별 제약없이 서로 결합해서 새로운 기능을 창발해 낼 수 있는 정도로 측정할 수 있겠지요. 실증적인 연구가 필요합니다. 워드프로세서(정확하게 말하자면 텍스트 에디터)의 경우를 보죠. 처음 에디터는 라인 에디터입니다. 여기선 수정의 단위가 "라인"입니다. 예컨대 세번째 줄과 네번째 줄 사이에 뭘 넣으려면, 예컨대, "/i{3}/아자차카/" 뭐 이런 식이죠. 거의 모든 명령을 사용자가 직접 지시를 해야하고 에디터가 알아서 해주는 것은 없습니다. 즉, 사용자의 명시적 동작없이 자동으로 작동하는 기능이 거의 없습니다. 자동성이 낮은 것이죠. 또한, 유연성도 낮습니다. 이 명령과 저 명령을 결합해서 새로운 기능을 창출해 내지 못하고, 자신이 사용하는 에디터가 요구하는 道를 무조건 따라야 합니다. 여기서 발전한게 소위 프로그래밍 가능한 에디터(Programmable editor)입니다. 매크로 기능을 극적으로 확대한 경우죠. 에디터 자체가 제공하는 자동성은 거의 없지만 -- 너무 단순합니다 -- 명령과 명령을 붙이고, 수정하고 조정해서 자신이 원하는 기능을 거의 모두 만들어 낼 수 있습니다. 이게 발전하면 자동성이 점점 높아지게 되죠. 고자동고유연의 시대가 오는 겁니다. 그러면 고자동저유연의 제품이 등장합니다. 우리가 요즘 흔히 보는 초보자용, 대중적 워드프로세서들이 되겠죠. 이건 일종의 하향 평준화입니다. 즉, 자신이 초보자거나 전문가거나 상관없이 그 에디터가 제공하는 기능의 수준에 얽매여야 합니다. 자신과 에디터로 구성된 그 시스템은 전체적 발전이 거의 없습니다. 반면, 아까 말한 저자동 고유연 시스템인 경우, 초보자들은 "초보자 수준"에서 그 에디터를 사용할 수 있고, 자신이 점점 똑똑해지면서 "전문가 수준"으로 쓸 수 가 있습니다. 시스템(유저+에디터)이 함께 진화하는 것이지요. 그런데, 요즘의 워드프로세서는 유연성이 떨어지기 때문에 새로운 문제가 발생했을 때 해결을 잘하지 못합니다. 조만간 이 시스템은 저자동저유연의 죽은 시스템이 될 겁니다. 이 때 누군가가 새로운 유연성을 제공하게 되겠죠. 그러면 그 시스템은 그 새로운 문제를 거의 "자발적"으로 해결할 수 있게 될 겁니다.
> [자동성] > > hi > I > I > I > I (3) 유저 + p-editor > (4) 대중적워드 > I >lo---------------------I---------------------hi [유연성] > I > I (2) 프로그래머블 에디터 > (1) 라인에디터 > I > I > I > lo
이 그래프에서 각각 (1),(2),(3),(4)는 특정 위치를 나타내는 것이 아니고 원점을 중심으로 원을 상정했을 때 해당 부근의 일정 곡선을 점유합니다. 그리고, 여기서 (1)번은 죽음이자 동시에 탄생의 공간입니다. 그리고 원점을 중심으로 lo, hi의 구분은 잠재적potential 구간과, 실재적actual 구간의 구분으로 볼 수 있습니다. 유연성이 lo인 영역에서는 유연성이 잠재적으로 그 가능성이 내재해 있는 것이고, 실재적 구간에서는 외부로 그 유연성이 드러나는 겁니다. 자동성도 마찬가지가 됩니다.
<질문2> 여러가지 연관은 안되지만 소소한 궁금증들... 이 원이 시계반대방향으로 돈다는 말씀이지요? 네. 하지만 번호에 따라 시간순서적으로chronologically 꼬리를 무는 방식으로 변화발전해가는 거지요?
네.
WikiWiki는 여기서 프로그래머블 에디터에 해당하는 시스템인가요?
네.
만일 앞의 질문에 다 예스라면 마지막으로 덧붙여 궁금한 건 이 기술들이 실질적으로 발명 내지는 진화해온 순서도 역시 이런 가요?
일반적으로 그러합니다. 다시 말해서 프로그래머블 에디터가 대중적인 워드보다 먼저 나온 것인가 말입니다. 네.
만일 저자동고유연한 시스템이 훌륭하다면 왜 그것이 도태되고 또 다른 것으로 이동하게 되는 거지요? 말하자면 저자동고유연 시스템에서 극복되어야하는 것으로 잠재돼있는 문제는 무엇이 될까요? 그리고 각 유형들의 세로높이는 일부러 차이를 두신 건가요? 즉 같은 고자동성 내, 그리고 같은 저자동성 내에서도 그 자동성의 정도에 차별화를 두기 위해서? 만일 저자동고유연한 시스템이 훌륭하다면 왜 그것이 도태되고 또 다른 것으로 이동하게 되는 거지요? 말하자면 저자동고유연 시스템에서 극복되어야하는 것으로 잠재돼있는 문제는 무엇이 될까요?
저자동고유연한 시스템은 초기 학습비용이 높습니다. 잘하는 사람의 수준에까지 올려놓기 위해서는 그 사람이 거친 진화의 긴 과정을 거쳐야만 합니다. 위키위키를 처음 접했을 때를 떠올려보세요. 일단 저자동고유연 시스템이 사용자와 함께 공진화coevolution를 하게 되면 고자동고유연으로 됩니다. 다음 단계가 고자동저유연 시스템입니다. 저자동고유연 시스템에서 극복되어야 할 것을 물으셨는데, 그건 차라리 인간 본성에서 극복되어야할 무언가일 수 있겠다는 생각을 해봅니다. 그리고, 정확히 말하면, 저자동고유연이 아니고 고자동고유연이 되겠죠. 고자동고유연이면 인간의 "편리함 추구"나 "경제성의 원리" 등으로 고유연성이 존재의미가 없어집니다. 있어도 쓰질 않는 것이죠. 처음부터 그 자동성에만 길들여집니다.
각 유형들의 세로높이는 일부러 차이를 두신 건가요? 즉 같은 고자동성 내, 그리고 같은 저자동성 내에서도 그 자동성의 정도에 차별화를 두기 위해서?
네. 그렇습니다. 또, 완전히 정형적인 틀로 오인을 하지 않으실까 하는 생각에 일부러 어긋난 듯 그린 의도도 있습니다.
일단, 자동성은 한가지 작업(task)이 주었졌을 때 이 작업을 수행해 내기 위해 밟아 나가야할 개념적 단계(Conceptual Steps, 물리적 단계가 아니고)의 숫자에 반비례한鳴?보고, 유연성은 그 작업을 완수하기 위해 거칠 수 있는 유의미한 과정의 "경우의 수"에 비례한다고 보면 이해하기 쉬울지 모르겠습니다. 물론 한가지 척도에 불과합니다. (ProgrammingLanguage에서는 유연성을 Orthogonality와 비슷하게 보아도 될 것 같습니다.)
참고할만한 서적은 아쉽게도 별로 없습니다. 이런 식으로 자동성과 유연성을 대비한 건 별로 없는듯 합니다. ComputerScience분야에서 ProgrammingLanguage의 Orthogonality에 대한 논문들이나 SystemsEngineering쪽에서 좀 관련있는 내용을 있을런지 잘 모르겠군요.