철수네 소프트웨어 세상 [본점]

소프트웨어와 관련이 있다면 뭐든지 – I no longer work for Microsoft.

“잘못 알려진 디자인 패턴의 두번째 원칙”에 작은 댓글하나

with one comment

잘못 알려진 디자인 패턴의 두번째 원칙 « arload – load to architect

의외로 일반론에서 답을 얻는 것이 더 이해하기 쉬울 수 있다는 생각을 해봤고, 댓글하나 급 적어봅니다.

인간이 수용할 수 있는 복잡성에는 한계가 있다. 그 한계는 관점에 따라서 다양한 편차를 보인다. 감성과 같은 복잡성은 컴퓨터가 인간을 따라올 수가 없다. 하지만, 반대로 컴퓨터는 연산장치지만 인간의 뇌는 연산장치가 아니다. 보통 사람이 암산으로 처리할 수 있는 연산의 한계는 컴퓨터의 그것에 비하면 아주 초라하다. 정확성을 요구하는 연산과 같은 관점에서는 인간이 수용할 수 있는 복잡성의 한계치는 아주 낮다. 어느 시점에서 컴퓨터의 지능이 인간의 지능을 뛰어넘게 되는 Singularity(특이점)이 발생한다고들 하지만, 이는 감성의 복잡성을 뛰어넘는 지점을 이야기하는 것은 아닐 것이다.

우리의 몸은 우리가 사는 이런 한계를 보이는 물리적인 세상에 적응/순응된 상태로 존재한다. 때로는 몸은 새로운 도구에 적응하고, 반대로 몸을 보조하기 위해서 도구가 만들어지고, 이렇게 펜듈럼처럼 왔다 갔다 한다. 마샬맥루한이 주장했던 것처럼 모든게 몸의 확장(Extension)이자, 칼세이건이 주장했던 것처럼 사는데 필요한 방향으로 우리의 뇌가 진화해 온 것이다. 팔이 필요에 의해서 4개가 되는 등의 급진적인 변화는 아니지만, 파충류의 뇌에서 언어를 사용할 수 있는 뇌로 자라온 진화(혹은 적응)말이다. 혹은 작게는 문자메시지를 보내는데 어려움이 없는 세대와 있는 세대간의 적응 말이다.

인간은 영적인 존재가 아니다. 텔레파시로 교신하고, 텔레포트하는 존재가 아니다. 물리적인 세상과 아주 가깝게 엮여서 익숙해져 있기 때문에 상상력의 나래를 펼쳐서 기가차게 멋진 것을 구상해도 이 물리적인 한계에 부합하지 않으면 실패하기 쉬울 수 밖에 없다. 아무도 이해하지 못하는 세기를 뛰어넘는 생각을 하는 사람을 천재로 분류하지만, 근대에는 이 물리적인 세상과 타협할 수 있는 새로운 변화를 캐치하는 사람도 천재로 분류하기도 한다. 사람을 연구하는 학문들이 다양한 과학기술과 융합하는 것은 점차 흔한 현상이 되어가고 있는 점도 인간의 물리적인 한계를 접목하는 트렌드와 상관이 없다 할 수 없을 것이다.

서론이 좀 뜬금없었을지 모르지만, 요는 사람이 이해하기 위해서는 물리적인 현실에 가까운 복잡성으로 관리되는 방향이 좀 더 현실적인 방향이라는 것이다.

프로그래밍의 OO(Object Oriented, 객체지향)의 역사에 있어서 클래스 상속(Inheritance)이 예상보다 선전하지 못하고(overrated) 컴포넌트라는 가지치기를 하게 된 이유도 이런 복잡성에 기인할 것이라 생각된다. 컴포넌트라고 하는 “결과가 immutable한 엔티티”를 사용하는 것은 설계시의 계약(Contract)을 통해 만든, 물리적으로 우리가 사용하는 (프로토타입을 포함하는) 부품을 대변한다. 현실에서는 설계시에 상속의 속성을 사용할지언정 물리적인 부품들을 모핑(Morphing)하는 것은 불가능하고, 대체(Replace/Reuse)를 한다. 즉 부품을 갈아끼운다는 이야기다. 부품을 갈아끼우는 것과 비현실 속에서 모양을 마구 바꿔대는 것과의 복잡성의 차이는 꽤 크다. 최소한 일반적인 종사자들이라도 이해하기 쉬운 것이 아니란 것이다. 아버지가 바뀌었다고 자식이 바로 바뀌는 것은 물리적인 현실의 이야기가 아니란 것이다. 그것이 가능했다면 사람들이 이해하는 것이 더 쉬웠고 복잡성을 관리하는 것에도 문제가 없지 않았을까. 한마디로 다양한 복잡성은 물리적인 현실과 가까울수록 관리가 쉬워진다는 것.

초기 OO의 복잡성을 그나마 간직한 C++을 일반 프로그래머들이 제대로 활용하지 못하는 것도 그런 연장선상에 있을 것이다. 이런 저런 예외 상황과 장치와 테두리(규칙)을 만들어서 상속의 복잡성을 관리(Managing)하려고 한 시도들은 이런 것을 배우는 사람에게 있어서 장벽이 될 수 밖에 없지 않을까. 물론 잘 관리된 진화로 훌륭한 언어임에는 틀림 없지만 말이다. (물론 계속 진화하면서 Best Practice를 만들어가면서 사람들의 수준을 높이고 있기 때문에 점차 장벽은 낮아진다고 할 수 있겠다.) 그러니 현실에서는 (이해하기 힘들거나 복잡할 수 있는) 상속을 활용하는 것이 필요한 부분은 이를 이해하고 사용하는 일부 전문가들에게 맡기고 거기서 나온 결과물(프레임웍, 제품, 컴포넌트)를 사용하는 방향으로 권장을 하는 것이라 생각된다. 상속을 잘못 사용하여 벌받는(문제가 생기는) 경우가 조합(Composition)을 잘못 사용하여 벌받는 것보다 아마도 페널티가 많을 확률이 높을 것이란 의미로 말이다.

초보 개발자들이 인스턴스(Instance)라는 개념이 확고히 머릿속에 들어가기 위해서 무단한 노력을 해야되는 것도 물리적인 현실에 있어서는 인스턴스와 객체는 다른 것이 아니기 때문일 것이다. 혹은, 다중 상속은 정말 필요한 경우가 아니면 되도록이면 사용하지 말라고 권장했던 조언들도 물리적인 현실과는 사뭇 다른 그 복잡성을 이해하지 못하면 쓰지 말라는 말일게다. 복잡성만 놓고 보면, 이전 EJB vs POJO의 도래도, 너무 다양해진/맹신되는 패턴에 대한 저항도, 혹은 더 넓게 나아가 애자일이라는 움직임도, 다수가 모두 수용하고 교신할 수 있는 복잡성의 정도가 한계에 다다르면 저항이 생기는 그런 예일 것이다.

여하튼 상속은 최대한 그 복잡성을 관리할 수 있는 한도내에서 사용하도록 진화했고 계속 진화하고 있다. 전에 이해하던 방식의 틀을 벗어나는 복잡성이라면 혼자 이해하면 되는 경우라면 상관 없지만 여러 사람들이 사용하는 어떤 것을 만들고 있는 경우라면(이 시대에는 다수의 경우겠지), 이해에 도움이 되는 방향으로 프로그래밍을 하는 것으로 권장을 하는 것은 당연한 것이지 않을까?

…하는 생각.

Written by charlz

2009년 2월 18일 , 시간: 오후 4:48

Uncategorized에 게시됨

One Response

Subscribe to comments with RSS.

  1. 요약하면… 작은 나사 같은 부품도 규격(인터페이스)에 맞는 걸 가져다 쓰듯이… 프로그래밍에서의 조합도 그렇게 하는게 당연하다는 의미인가요? ^^;

    kebie

    2009년 2월 18일 at 오후 7:02


답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

%d 블로거가 이것을 좋아합니다: