결코 이 포스트의 제목은 중2병 걸린 한 초보 프로그래머의 허세 섞인 장탄식이 아닌 "The Object-Oriented Thought Process"라는 책의 번역서 제목임을 밝히며 글을 시작한다. 굉장한 사족이지만 이 책의 영어 제목의 앞글자를 따면 OOTP가 되는데 이는 메이저리그 팬이라면 누구나 한 번쯤 접한 뒤 정교함과 그에 비례하는 복잡함에 혀를 내두르게 되는 어느 게임의 이름이 된다. 대단한 이야기는 아니라는 말이다.
맷 와이스펠드가 지은 《객체지향적으로 생각하라!》는 애플리케이션단의 프로그래밍에 눈을 뜬 뒤 (여러 정황상) 가장 처음 나의 멘토 역할이 되어 준 사람에게 객체지향이라는 개념을 이해하기 위한 입문서로 추천을 받은 책이다. 그 전까지 다루던 코드이그나이터나 레일스 등 기반 언어가 객체지향적이기는 하나 프레임워크의 구조상 객체적인 이해가 약하더라도 전반적인 그림을 그려나가는데 무리가 없는 친구들과 친분이 있을 때만해도 객체란 그저 인터페이스와 임플리멘테이션이 조금 더 에르고노믹하게 구성된 구조라고 이해했지만, 안드로이드처럼 객체라는 개념을 굉장히 비중 있게 다루는 프레임워크(또는 OS)를 다루게 되니 내가 얼마나 비객체적 사고 구조를 가진 인간인지 뼈저리게 느끼게 되었다. 바로 그 때 이 책이 다시 눈에 띄었고 적당한 시간을 들여 완독했다.
실제로 내용을 서술하는 부분에서는 자바를 예로 들지만 그렇게 예제로 나온 코드를 다른 언어들로도 어느 정도 풀어주고 있기 때문에 메이저한 객체지향 언어를 다루는 사람들이라면 모두가 좋은 가르침을 얻을 수 있으리라 본다. 난이도는 중하 정도라 판단이 되고 프로그래밍 언어라는 심오한 개념에 대해 아주 깊은 이해를 시도한다기보다 객체지향 언어의 특성을 이해하고 실제 프로젝트에서 그 개념이 어떻게 적용되며 어떠한 패턴과 기술들이 거기에 가미될 수 있는지에 대한 이야기가 더 주를 이른다. 예를 들면 아래와 같은 현업의 진리가 책에 생뚱맞게 들어가 있는 것이다.
간단히 말해서 초기에 요구 사항을 확인하고 설계 변경을 최소화해야 하는 이유는 다음과 같다.
- 설계 단계에서 요구 사항/설계 변경을 하는 비용은 상대적으로 적다.
- 구현 단계에서 설계를 변경하는 비용은 상당히 높아진다.
- 배포 단계 이후에 설계를 변경하는 비용은 첫 항목과 비교하면 천문학적이다.
하지만 아무리 저 문장이 만고의 진리임을 안다하더라도 무슨 의미가 있겠는가, 항상 현실은 개발자가 배포 단계 이후의 모든 천문학적 비용을 짊어지고 가는 것을.
각설하고 본론으로 다시 돌아가면, 객체지향이라는 개념이 그렇지 않은 패러다임(보통들 절차지향이라고 하는 것 같은데 사실 절차지향이 객체지향과 대척점에 있는 것이냐라고 묻는다면 나의 얕은 지식으론 전혀 그렇지 않은 것 같다.)보다 더 진보한 개념이라고 평가받을 수 있는 이유는 객체지향이라는 개념이 더 복잡한 시스템을 만드는데 비교적 쉬운 진입로를 만들어주기 때문인 것 같다. 객체지향이라는 개념이 어디선가 갑자기 튀어나왔기 때문에 복잡한 것을 좀 더 쉽게 만들게 도와주었다기보다는 그렇게 복잡한 녀석들을 더 쉽게 다루기 위해 고안된 개념이 객체지향일 것이라는 말이다. (확실한 이야기는 아니다.)
"노벨상 수상자인 시몬(Herbert Simon)"이 "복잡성의 구조(The Architecture of Complexity)라는 1962년 논문에서 다음과 같이 안정적인 시스템을 설명"한 내용을 보자. 간단하게나마 객체지향 언어와 그렇지 않은 언어를 다뤄본 사람이라면 객체가 궁극적으로 나아가고자 하는 방향이 어떤 것인지 조금은 이해가 가리라 본다. 사실 나는 조금도 이해를 하지 못했다.
- "안정적이고 복잡한 시스템은 보통 각 시스템이 보다 단순한 하위 시스템으로 구성되고 각 하위 시스템이 보다 더 단순한 하위 시스템으로 구성되는 그런 계층 구조의 형태를 취하고 있다" - 이 원칙은 절차지향 소프트웨어 개발 방법론인 기능적 분해의 기초를 형성하기 때문에 이미 익숙할 수도 있다. 객체지향 설계에서 동일한 원칙을 조합에 적용하여 보다 단순한 부분으로 복잡한 객체를 구성할 수 있다.
- "안정적이고 복잡한 시스템은 대부분 분해 가능하다." - 이 말은 시스템을 구성하는 부품을 확인하고 부품 간의 상호작용과 부품 내부의 상호작용의 차이를 알 수 있다는 의미이다. 안정적인 시스템은 부품 내부보다 부품 간 연결이 더 적다. 그러므로 스피커, 턴테이블, 앰프 사이에 간단하게 연결된 모듈화된 스테레오 시스템은 본질적으로, 쉽게 분해할 수 없는 통합 시스템보다 더 안정적이다.
- "안정적이고 복잡한 시스템은 거의 항상 상이한 조합으로 정돈된 소수의 하위 시스템으로 구성된다." - 일반적으로 그런 하위 시스템은 또 다시 소수의 다른 종류의 부품으로만 구성된다.
- "작동하는 안정적인 시스템은 거의 항상 작동하는 단순한 시스템에서 진화한다." - 처음부터 운전대를 재창조하는 것처럼 새로운 시스템을 구성하기보다는 새로운 시스템은 이전에 있던 검증된 설계를 기반으로 구성된다.
'CODE' 카테고리의 다른 글
코드스쿨(CodeSchool.com)에서 제안하는 웹디자인의 기초 중 알맹이들 (0) | 2015.09.14 |
---|---|
팩토리 메소드를 사용할 때 빈 기본 생성자가 필요한 이유 (0) | 2015.04.03 |
동적 컨텐츠의 무한 스크롤 방식을 구현할 때 고려해야 할 점 (0) | 2015.03.17 |
이클립스(Eclipse) 안드로이드 프로젝트를 그레이들(Gradle) 안드로이드 프로젝트로 바꾸는 이야기 (1) | 2015.03.11 |
비동기 방식에서는 절대 플래그(flag)로 문제를 해결하려 들지 말라 (0) | 2015.03.06 |
Rails로 다중 언어 지원 애플리케이션 만들기 (0) | 2015.01.18 |
프로그래밍 숙제에서 발리지 않는 법 (0) | 2014.12.13 |
Ssign.net 서버 개발기 (0) | 2014.11.15 |
COMODO 보안서버 SSL 인증서 설치하기 (0) | 2014.11.03 |
워드프레스를 재설치할 때는 꼭 기존의 데이터베이스를 날려주자 (0) | 2014.10.31 |