현재 진행 상황은 chapter 5를 마치고 chapter 6를 읽는 중. 11월까지 끝내려고 마음 먹었는데, 그렇게는 안되는 것 같다. 1-2월 정도까지 읽어야하려나… 같이 읽던 ‘리눅스 커널의 이해’는 잠시 쉬고, 이 책에 집중을 해봐야겠다.
그건 그렇고, 상당히 재미있게 보고 있다. 책을 사고나서 내용을 훑고 나서는 그냥 ‘OO introduction 책이잖아?’ 하고 쉽게 보았는데, 지금까지만으로도 몇몇 중요한 meme을 도입하게 만들어, 내 mindset에 상당한 변화를 주고 있다. 번역이 되어서 널리 읽히게 되면 참 좋겠다는 생각이 든다. 그 중에서 가장 인상적인 chapter가 바로 chapter 3이었다.
Chapter 3: From Philosophy to Culture는 object culture를 소개하고 있다. object culture의 특성을 간단히 옮겨보면,
- 정확하게 정해진 형식성보다는 질서를 가진 비형식성으로의 위임
- 전체를 바라보기 보다는 지역적인 초점 (local focus)
- 최소한의 디자인/프로세스 문서의 생산
- 중앙 집중식 관리 스타일보다는 협동적
- 제어보다는 조정과 협조에 기반한 디자인
- 구조화된 개발보다는 빠른 프로토타이핑
- 체계적인 것보다는 창의적인 것에 가치를 둠
- 외부의 과정에 따르기보다는 내부적인 능력에 따름
정확하게 이해할 필요는 없고, 대충의 감만 잡으면 될 것 같다. 뒤에서 계속 반복되면서, 저절로 익숙해지는 일종의 “문화”이기 때문이다.
Four Presuppositions
다음으로 얘기하는 것은 object thinking (object culture의 기반이 되는?) 4가지 전제조건이다. 역시 그대로 옮겨보자.
- 모든 것은 object이다.
- 문제 영역(problem domain)을 시뮬레이션하면 object를 발견하고 정의할 수 있다.
- object는 조합할 수(composable) 있어야 한다.
- organizational paradigm에서 분산된 협동과 통신이 계층적이고 중앙집중적인 제어를 대체해야한다.
각각을 간단하게 설명해보면,
“모든 것은 object이다”라는 가정은 아무리 복잡한 영역(domain)이라고 하더라도, decomposition을 거치면, 상대적으로 적은 수의 object들만이 남는다는 생각이다. 일종의 원자론이다. (모든 물건들은 100개 남짓한 종류의 원자들로 이루어져있다라는 생각과 비슷하고, 이 책에서도 그러한 비유를 활용한다.) 그렇다면 object란 무엇인가? 이 질문에 대한 정확한 답은 더욱 뒤에 나온다.
위에서 얘기했듯이, object가 발생하는 이유는 decomposition이라는 과정을 거치기 때문이다. decomposition은 abstraction을 적용함으로써 수행된다.이러한 abstraction은 특정한 관점(aspect)을 선택하고 그것에 초점을 맞추는 것을 필요로 한다. 이러한 관점(aspect)의 차이가 decomposition을 수행할 때, 그 결과물들 사이의 차이를 구분하는 기준이 된다.
전통적인 컴퓨터 과학자들과 소프트웨어 엔지니어들은 복잡한 domain을 모듈로 decomposition할 때, data와 function (algorithm)으로 분리하는 방법을 사용했다. (CS101을 열심히 배웠다면, 아마 dijkstra의 ‘프로그램’의 정의도 기억날 것이다) 이 때, data와 function은 가상적인 기준이어서 자연스러운 이음매가 아니고, 이 때문에 소프트웨어 엔지니어링의 거의 모든 문제가 발생한다고 얘기한다. 다시 말하면, 프로그램을 data와 function으로 분리하는 것은 일반적으로 우리가 세계를 이해하는 방식과 너무 틀리다는 것이다.
그래서 제안하는 decomposition abstraction의 기준은 바로 행동(behavior)이다. 인간은 세계를 이해할 때, 분류를 하고, 분류를 하기 위해서는 차이를 인식해야하는데, 차이를 인식할 때의 기준은 행동(behavior라는 주장을 하고 있다. object thinking에서는 이처럼 실세계에서의 decomposition 방식을 소프트웨어 개발에 도입하기 때문에, 당연히 소프트웨어 개발자는, 해당 영역의 전문가(domain expert)의 얘기를 들어야한다. 이는 문제 영역(problem domain)의 시뮬레이션이 곧 object의 decomposition이라는 주장으로 이어진다.
“object를 잘 조합할 수(composable) 있다”면 decomposition 역시 잘 된 것이다. 이러한 조합성(composability)은 재사용성(reusability)과 유연성(flexibility)을 포함한다. 이를 획득하기 위해서는 object의 행동을 발견하고 일반화하는 과정이 필요한데, 이것 역시 나중 chapter로 설명을 미룬다.
실세계에서도 그런 것처럼 object는 자율적이어야 한다. 중앙 집중적인 제어는 쪼개서 분산시킬 수 있다.
OO에 익숙하지 않은 사람이 가장 쉽게하는 실수들이 이러한 4가지 조건들에서 자주 발견된다. 자주 볼 수 있는 것 중의 하나는 객체가, problem domain이 아니라 implementation domain의 동작을 노출하는 것이다. 비슷한 것으로는 클래스나 메서드의 이름 problem domain에 대해서 제대로 파악이 안되어서 implementation domain의 용어와 혼재되어 있는 것이다. 다른 한가지는 중앙 집중적인 제어다. 그 사람이 짓는 클래스의 이름에 “*Manager”라는 이름이 많다면 이를 의심해볼 수 있다. 또 다른 예로는, 한 object는 거의 자신의 동작을 가지지 않고, 다른 object가 해당 object의 상태를 심하게 바꾸는 방식이 있다. 분명 OO 언어를 사용해서 만들었겠지만, data/function의 decomposition에 지나지 않는 예다. (이러한 실수들에 대해서 따로 글을 써 볼 예정이다.)
Object Principles – Software Principles
그 다음으로는 Witt, Baker, Merrritt의 Software quality를 정의하는 axiom들을 소개한다.
- Axiom of separation of concerns: 복잡한 문제를 여러 간단한 문제들로 나누어서 해결한다.
- Axiom of comprehension: 인간의 인식한계를 고려한다.
- Axiom of translation: 정확도는 동등한 문맥들간의 이동에 영향받지 않는다.
- Axiom of transformation: 정확성은 동등한 component간의 교체에 영향받지 않는다.
- Principle of modular design: axiom of separation of concerns
- Principle of portable designs: axiom of translation
- Principle of malleable designs: axiom of transformation
- Principle of intellectual control: abstraction의 적절한 사용
- Principle of conceptual integrity
소프트웨어 엔지니어링의 지극히 일반적인 얘기들이지만, 가만히 살펴보면, object thinking과 object는 위의 목적에 상당히 적합하다는 것을 알 수 있다.
그리고 한가지 더, Fred Brooks의 유명한 paper인 ‘No Silver Bullet: Essence and Accidents of Software Engineering’에서 언급한 소프트웨어 개발에 있어서의 본질적인 어려움을 소개하면서, object thinking이 이러한 문제를 해결하고 있다고 주장한다.
- Complexity: 소프트웨어는 인간이 만든 어떤 다른 체계보다도 복잡하다.
- Conformity: 소프트웨어는 실제 세계에 부합해야한다
- Changeability: 세계가 변화하면 소프트웨어도 변화해야한다; 세계는 자주 변화한다.
- Invisibility: 소프트웨어(e.g. 실행하는 프로그램)를 실제로 볼 수 없으므로, 생각하기도 힘들다.
위의 전제조건에서도 보았듯이, object thinking에서 object는 실세계를 반영해야하므로, 당연히 이러한 어려움에 대한 가장 직접적인 대응책일 수 밖에 없다.
Cooperating Cultures
계속 비판해온 전통적인 컴퓨터 과학과 소프트웨어 엔지니어링을 절대적으로 거부하는 것은 아니라고 얘기한다. 그리고, 각각의 culture의 영역을 구분하는 기준을 제시한다.
Natural world – Deterministic world의 축과 Comprehension – Implementation의 축을 교차시키고, Object paradigm은 Natural world/Comprehension의 영역에, Computer science paradigm은 Deterministic world/Implementation의 영역에 둔다. 두 paradigm/culture는 적용하는 영역이 다른 것이다. 흥미로운 것은 deterministic world의 예로, hardware, discrete module, algorithm, small-scale formal system 등을 들고 있다는 것이다. 대체로 data와 function의 구분이 불가피한 영역들이다. 그렇다면 OS를 개발할 때는 대체로 computer science paradigm을 적용하는 것이 좋은가? 약간 더 hardware로부터 멀리 있는 system programming은 어떠한가? 모호하긴 하지만, OS의 상위 layer나 system programming 수준에서는 OO paradigm을 적용하는데에 무리는 없으리라고 생각한다.