패턴계에서는 절대적으로 내려오는 한가지 격언이 있습니다.

Pattern isn’t an island.  패턴은 섬이 아니다.  

패턴이라는 것은 크게는 Architecture을 결정하기도 하며, 그 밑에 Design을 결정하는 중요한 역할을 합니다. 즉 패턴간에 서로 깊은 연관성을 가진다는 것 입니다.

일전에 제가 다녀왔단 PLoP Bootcamp 포스트에서  Fault Tolerance 패턴의 저자인 Bob Hanmer가 Problem/Solution에서 언급한 패턴 언어를 참고하시기 바랍니다.

위 그림을 예로 들면 통신시 신뢰성을 확보하기 위해 IO GateKeeper라는 Monitor를 통해 데이터를 거쳐가게 만들었지만, Source/Destination/메세지의 순서등을 구분하기 위해 Token (Time + Mac Address + Handler 정보) 인 IO Triage 이용하게 되고, IO Triage를 구축하기 위해 내부적으로 Timestamp를 사용하는 모습이 보입니다.

즉  거대한 아키텍쳐적인 결정이든, 그 밑에 세분화된 설계에 대한 결정들이 개별적으로 결정되는 것이 아니라, 서로 간에 영향을 미치며 결정된다는 것입니다.

작년에 Kent Beck님은 세미나에서 이러한 말을 했습니다.

Design is an island‘  (설계는 섬이다.)

패턴을 몰랐다면 이러한 말이 별로 도발적으로 들리지 않았겠지만, 패턴계에서 늘 원칙처럼 언급하던 패턴이 가져오는 Side Effect를 중화시키기 위해 다른  해결책으로 또 다른 패턴들이 도입되는 그림을 늘 봐온 저로서는 도발적인 정의였습니다.

하지만 이것은 Kent Beck이 정말 고심 끝에 나온 의미있는 metaphor(비유)였습니다.  Nature Of Order를 아마 알지 못했다면, Kent Beck의 비유의 깊이를 이해하지 못했으리라 생각이 듭니다.

Kent Beck은 어떻게 보면 극단적으로 정제되고, 심플한것을 유지할려고 애를 씁니다. 왜냐면, 그래야 다양한 사람들에게 이해를 시킬 수 있으니 깐요. 정말 그 만의 철학에서 나온 아주 멋있는 metaphor 입니다.

1. 설계는 섬을 걷는 것과 같습니다.

http://www.toptenz.net/top-10-most-remote-places-on-planet-earth.php 에서 발췌

우리는 해변을 걷다가, 파도가 쳐서(요구사항이 바뀌어서) 발이 젖을수도 있습니다(소프트웨어 설계를 변경해야 됩니다). 만약 발을 젖지 않는다면, 현재의 설계는 좋은 것입니다.  (즉 변화를 흡수할 수 있는 구조이므로 좋은 설계라는 말 입니다).

하지만 해수면(조석 tide,  기압, 바람상태 때문에) 은 계속해서 변경됩니다. ( 즉 요구사항의 변화는 계속해서 발생합니다.).  그러므로 현재의 설계가  항상 좋다고 말할수 없습니다.  2,3월에는 변화를 수용할수 있는 설계가 10,11월에 발생할 변화를 수용할 수 있는 설계구조라고 장담을 할수 없기 때문입니다.

그래서 우리가 익사하지 않는 범위에서 잠시 발을 물에 담아볼수도 있습니다. 즉, 시스템의 설계가  완전히 뒤엎어지지 않는 범위에서,  변화를 받아들일 수 있게 한 단계씩( Safe Step ) 바꾸어 볼 필요가 있습니다.

우리가 변화가 발생하는 것에 신경을 쓰지 않으면,  (하루 밤만 유효한) 설계가 되어 버리니, 발생하는 변화를 수용할수 있는 설계로 계속해서 변경해 나가야 합니다. 코드만 Refactoring의 대상이 아니라, 설계 역시 그렇다는 것이죠🙂

이러한 지표를 분석할 수 있는 기법들의 일부를 말씀드렸습니다.

2. 섬의 높은 곳에 올라 가는 것은 많은 노력(effort)이 필요합니다.

즉 설계를 개선 시키는 것은 많은 노력이 들지만, 다른 어떤 것보다,  설계에 투자하는 것이 좋다고 말합니다.

이 말뒤에는 심오한 의미가 담겨져 있습니다 .

Kent Beck님은 현재 우리 프로젝트에서도 겪고 있는 빌드 시간 문제로 부터, 테스트 작성이 이려운 문제, 팀 워크 문제 등 설계와는 조금은 동떨어진 문제들이 모두 설계에 주요 원인이 있고, ..  ( Xter님의 블로그 에서 발췌) 

많은 문제들이 설계와 연관이 되어 있다고 말하고 있습니다.

결론을 말하면,  끊임없이 문제점을 찾고, Clean(Clear)한 상황이 될때까지 계속해서 섬의 정상을 찾아 나가라고 말하고 있습니다.

3. 군도.. 

kent beck님 블로그에서.

군도란 섬이 모여 있는 것을 말하는데, 결국 기존의 설계에서 감당할 수 없는 변화가 오면, 우리는 다른 섬( 즉 기존의 설계를 버리고 완전히 새롭게 설계함) 으로 갈아 타야되는 상황을 말하고 있습니다.

이 의미는 일전에 있었던 Joel의 TDD에 대한 비판과 연관지어 생각할수 있을듯 합니다. Joel이 자신이 운영하는 회사에서, TDD를 기반으로 시스템을 구현했지만, 워낙 요구사항의 변경이 거서, 구축한 Test Case를 다 날려 버려야 하는 경우가 발생했다고 합니다.

이 것에 대해서 많은 이야기들이 나오고 있습니다.  어떤 분은 TDD는 모든 프로젝트에 적용하기에는 한계가 있다고 하는 분도 있고, TDD를 통해서 코드 품질의 안정화를 얻고, 이로 인해 더 높은 생산성을 얻을 수 있다는 분도 있습니다.🙂

저의 경험은 약간 중립적인 입장으로,  시간 제약이 큰 상황에서는, 정말 중요하다고 생각하는 부분과 변화의 냄새가 심하게 나는 곳에 집중해서 TDD를 적용하고, 가능한 Code Inspection으로 다양한 생각과 경험을 들어보자고 생각하고 있습니다.

기존의 설계에서 변화를 흡수할 수 없을 정도르 큰 지진이 일어나면, 다른 섬(다른 설계)로 옮겨 타야 되지만 섬을 옮겨 타는 것은 여러가지 안 좋은 상황을 만들수 있다고 합니다.

중복이 여기저기서 나오고, 효율성이 떨어지고, 코드 가독성은 떨어지는등의 문제가 야기됩니다. 그러니 안전히 Step by Step으로 설계를 옮기라고 말하고 있습니다.

저의 경험으로는 안전히 옮기기 위해서는 1번에서 링크를 걸은 여러가지 지표들을 사용할수 있습니다.

  • Dependency Structure Matrix
  • Code Metrics
  • Complexity (특히 Cycle Complexity – 냄새가 심하게 나는 곳 ) 등..
아키텍트가 이러한 지표를 명확히 인식을 해야만, 설계를 안전히 옮길수 있다고 생각이 듭니다. 물론 문제가 있다는 것을 발견하더라도, 적절한 해결책을 제시하는 것 역시 쉽지 않는 것이 국내의 현실이지만..🙂

 

맺으며.

별로 와 닿지 않는 이야기 일수도 있지만  island(섬) 이라는 메타포로 정말 적절히 설계에 대한 자세를 가르켜 준 Kent Beck님의 생각을 공유해 보고 싶었습니다.

다들 도움이 되셨기를 바라며..

Join the conversation! 6 Comments

  1. 안녕하세요. 오랫만에 이 블로그에 들립니다.

    다름이 아니라 PBE ( Patterns Based Engineering ) 관련 PDF 파일을 보다가 Architecture Pattern,Design Pattern,Idioms 라고 나오던데 Idioms 의 의미가 궁금해져서 글 남깁니다.

    그라고 제 개인적으로 스터디를 하고 싶은데 패턴 공학관련 서적
    추천을 부탁드립니다.

    열심히 공부해서 데브피아 아키텍트 마을에도 포스팅하겠습니다.

    응답
    • 안녕하세요. 기선님 오랜만이네요.
      paper meeting으로 얼굴을 못 뵈었군요🙂 잘 지내시죠.

      글에도 적었든이 일종의 scope의 범위로 보시면 됩니다.
      거대한 아키텍쳐에 수많은 디자인이 있고, 그 디자인 안에 Idiom이 있다고 보시면 됩니다.

      http://c2.com/cgi/wiki?IdiomOrPattern 에서 여러가지 말이 있는데요.
      요점만 말씀 드리면,

      I’d like to offer up this pragmatic definition of both Idiom and Pattern:
      Idioms relate to code
      Patterns relate to design

      이구요. 차이점은..

      What’s the difference between an idiom and a pattern? I have a hypothesis that:

      idioms are smaller
      idioms are language-specific

      Consequently, I have another hypothesis that patterns are big idioms.
      입니다.

      도움이 되셨는지 모르겠네요🙂

      응답
    • 패턴 공학관련서적이라 함은 패턴으로 전체를 다루는 서적을 말씀하시는 건데 POAD가 유일합니다.

      Pattern Oriented Analysis and Design.. 하지만 절판되어버렸구요..

      사견이지만, 패턴 공학이라는 것 보다는 다양한 패턴 언어를 습득하시고 그 들간에 어떠한 연관관계를 가지고 서로 사용되는지 보길 권해드립니다.🙂

      좋은 하루 되시구. 다음에 뵈용!!

      응답
  2. 좋은 글 잘 읽었습니다.
    개발자인 저에게는 아직까지는 현실적으로 쉽지 않은 문제로 느껴지네요.
    무엇보다도 개발 문화가 없는 환경이라서 그런지 요즘엔 참 고민스럽네요.
    좋은 기획자와 설계자가 있는 환경에서는 더 나은 경험을 할 수 있을까요?

    패턴이던 설계던 참으로 심오하고 깊은것 같습니다
    마치 철학 그 자체 같아요 ^^

    응답
    • 안녕하세요 레몬에이드님!!🙂

      그렇죠..
      이상과 현실은 항상 다른듯 합니다.
      하지만 끊임없는 요구사항이 발생하는한 끊임없는 refactoring은 숙명인듯 합니다 .

      참으로 어려운 일인듯 합니다.!!

      응답

답글 남기기

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

WordPress.com 로고

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

Twitter 사진

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

Facebook 사진

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

Google+ photo

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

%s에 연결하는 중

카테고리

My Thinking, News, Software Architecture, Study

태그

, , , , , ,