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

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. 설계는 섬을 걷는 것과 같습니다.

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

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

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

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

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

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

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

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

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

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

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

3. 군도.. 

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

이 의미는 일전에 있었던 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님의 생각을 공유해 보고 싶었습니다.

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