Fearless Change 두번째 장에서는  조직 변화를 위한 패턴들을 소개하지 않고, 원론적인 이야기인 패턴은 무엇인가? 그리고 어떻게 패턴을 보아야 하는지 설명를 하고 있습니다.

Pattern을 아시는 분이라면 뭐 이정도야 하고  말씀하실 수 있겠지만,   Linda의 Pattern에 대한 철학 ,노력, 패턴 Template의 발전 과정등을 설명해 놓아서, 흥미있게 읽었습니다. (저만 흥미로운 걸수도 있습니다… ). 특히 패턴을 읽는 것이 아닌 패턴을 만들어 본 경험이 있는 저에게는요. 읽으면서 PLoP BootCamp 때가 많이 생각나더군요.

Fearless change가  설명하고 있는 패턴은 소프트웨어 설계 패턴이 아니라, 조직 구조와 관련된 패턴이라는 점을 유의해서 읽어 주세요. 물론 비슷한 면도 많지만요.

Pattern이란 무엇인가?

여기에 대한 대답으로 Linda 는 크게 세가지로 요약해서 전달합니다.

• 지식 관리의 한 형태 (a form of knowledge management)
• 정보를 공유하기 위한 효율적인 수단.
• 전문적인 지식을 기록하는 방법 (is a way of  capture expertise)

Pattern Language란 무엇인가?

특정 영역의 문제를 해결하기 위해 같이 엮여 사용되는 패턴들, 또 다른 말로 Compound Pattern이라고 합니다.

Pattern Template Format

Christpher Alexander의 패턴 Format을 약간 변형하여, Fearless Change에서 사용하고 있습니다.

Name, Context, Force, Problem, Solution, Rationale, Resulting Context(positive and negative consequences) 를 설명하고 있고 Innovator 패턴을 이 Format에 맞추어서 설명하고 있습니다.

위  패턴 포멧은 현재 확장된  PLoP 패턴 포멧의 많은 아이디어를 제공했습니다. 한번 비교해 보세요.

Pattern  구성 요소에 대한 고찰

Linda가 참여한 Software Workshop에서 한 리더가 Software Architecture에 직면한  공통적인 문제들을 살펴보고, 이 문제에 대한 해결책을 기술하고, 이 해결책을 잘 적용할 수 있도록 요소들을 식별하자고 말했습니다. 문서화해서 자산으로 만들자는 것이지요.

만약  저처럼 Pattern계에서 사는 사람이라면, 이것이 바로 Pattern의 구성요소와 매우 비슷하다는 것을 알것 입니다. ( Problem, Solution, Context를 언급하는 말이지요.) 그래서 Linda는 패턴을 이용하여 참가자들의 생각을 문서화 하려고, 참가자 대부분이 패턴이 뭔지 몰랐다고 합니다.

그래서 Linda는 Pattern의 개요를 설명한 후 , Problem, Solution, Context형태로  작성하라고 말을 했습니다.

• Resulting Context의 유래

Do Food 패턴 (과자를 나누어 먹으면서)하면서 부드러운 분위 기속에서 , 패턴을 작성을 하고 있는데 누군가가 Linda에게 질문을 했습니다. “이 패턴의 솔루션을 사용할 다음 사람을 위해, 이 해결책이 수반하는 몇가지 문제도 언급해야 될거 같은데요? 그럼 이러한 부분을 Solution Section에 넣어서 설명해야 되나요?”  Linda는 ” 음.  별도의 세션을 만드는 것이 좋을 것 같습니다!  Resulting Context(패턴의 장,단점을 기술)라고 하는 부가적인 Section을 만들죠“.   (이것이 Pattern  Template에 추가된 Resulting Context 섹션입니다.  다른이에게 많은 도움이 되는 것으로 밝혀져 PLoP 공식 템플릿의 요소로 흡수되게 됩니다.)

• Context의 중요성

여러분이 패턴 작성또는 적용시 꼭  주의 깊게 작성하거나 읽어야 하는 부분입니다. 대부분의 사람이 패턴을 결과물에만 초점을 맞추어 보는데, Context를 주의 깊게 살펴보아야 합니다.

어머니가 말씀하시길

1. “Haste makes waste. – 서두르면 망친다” 라고  우리에게 조언을 합니다. 그런데 이와 반대되는 조언도 가끔씩 하십니다.
2. “A Stich in time saves nine – 적절한 하나의 바느질이 나중에 9번 꿰매야 되는 수고를 덜어준다” 라구요.

엄마의 두 조언들이 매우 좋다라는 것은 누구나 인식합니다. 그런데 자세히 보면 뭔가 상충된걸 느낄수 있으실 겁니다.  (패턴도 서로 상충되는 패턴들을 종종 발견할 수 있습니다. )

즉,  언제 이 조언을 따라야 하는지 부가적인 정보들은 언급해 주지 않았다는 것이죠. 어떠한 상황에서, 어떠한 제약조건과 선행조건이 필요한지등 필요한 정보를 주지 않았다는 것이죠. 여러분이 작성한 문서는 혹시 이렇게 작성되어 있지 않나요?  패턴이든, 어떤 문서든 이러한 정보를 꼭 다루어야 됩니다. 바로 이것이 Context(상황, 정황..)입니다.

우리는 어떤 해결책을 볼때 정말 비판적으로 바라볼 필요가 있습니다. 솔루션이 특정 상황(Context)에서 특정 문제(Problem)를 잘 해결하기 위해 사용할 수 있는 진짜 패턴인지? 아니면 경험적인 지식인지? 가이드라인인지?

좋은 패턴으로 인정 받기 위해서 Pattern의 창시자인 Christopher Alexander가 했던 것처럼 실세계의 구체적인 변화(정황)를 들어 설명하면 좋겠지만, 우리가 지금 만들려는 패턴은 조직적인 문제를 해결하기 위한 패턴이기 때문에 건축물처럼 설명할 수 없습니다. 그래서 Pattern의 Intent(의도)를 설명하고 있는 Opening Story와  구축하고자 하는 것이 무엇인지 설명하는 (부가적으로 적용시 발생하는 장,단점까지 ) 것들도 덧붙여서 설명해야 된다는 것입니다.

Context는 작성한 패턴의 전후 관계를 설명하고,  패턴의 의미를 정확히 판단하는데 도움을 줍니다. 그리고 여러개의 패턴을 묶어 하나의 Pattern Language를 만든 경우, 각각의 개별적인 패턴의 Context는   Pattern Language로 결합하여 사용할 수 있는 정보와 이 패턴을 가장 잘 적용할 수 있는 상황에 부합하는지 설명해야 합니다.

• Known Use로 실패와 성공을 이야기 해라.
  

인지 과학 연구에서 인류는 이야기(story)를 들으면서 계속 발전해왔다고 합니다.  Pattern은 전문가에게 듣는  이야기(story)입니다.  그렇기 때문에 이 패턴뒤에 숨겨져 있는 놀랄만한 성공과 충격적인 실패사례와 같은 Behind Story를 다루지 않는다면 Pattern의 가치는 떨어지게 됩니다.

• Name의 중요성
  

Pattern은 커뮤니티나 그룹에서 사용되는 공용어 역할을 하기도 합니다. Do Food 라는 패턴을 들으면 음식을 나눠먹음으로써, 딱딱한 분위기의 회의(Meeting)를 부드럽게 하는 패턴이라는 것을 알수 있습니다. 모두가 이 패턴의 의미를 알고 있다면, 부가적인 설명없이 대화에서 쉽게 사용할 수 있다는 것이죠. 그래서 다른 사람이 Pattern을 직접 찾아 내부에 자세한 내용을 읽지 않더라도, 그 의미를 알수 있는 직관적인 이름을 정하는 것이 중요합니다.  정 안되면 별명 (alias)라도 사용하셔야 됩니다.

간단한 예를 들어보죠. 변화를 가져올 세계전역에 있는 Change Agent가 , 새로운 아이디어들을 도입하는 전략을 말하기 위해 우리의 패턴을 사용하고 있습니다.   대부분의 Change Agent가  그들 스스로 Evangelist (전도사) 역할을  수행해야 하며, Brown Bag(점심 식사와 함께 아이디어를 전파) 도중 애기를 나누거나, Big Jolt (권위있는 사람)  한 사람을 초청해서 애기를 나누어야 합니다. 그리고 이러한 상황속에서 Local Sponsor (나를 도와 주는 동료)나 Cooperate Angel(협력해서 도와 주는 친밀도 높은 동료)를 찾아야 합니다.

이렇게 Pattern 이름이  직관적이어서, 대화에 공용어처럼 사용될 수 있게 만들어야 된다는 것이죠.

• Problem을 잘 설명해라.

Pattern은 문제에 대한 해결책을 제공합니다.  해결책을 사용하기 원하는 사람들이 그들이 직면한 문제를 이해하지 못하고 있다거나, 무엇이 문제인지 모른다면 패턴을 사용하기는 매우 어렵습니다. 한 예로 조직의 정책을 변화시킬려고 시도했던 한 Change Agents는 “문제가 무엇인지 설명하는 시간을 내가 가졌다면, 내가 제안한 (해결책을 포함하고 있는)정책에 대한 반발이 훨씬 줄었을 것이고, 정책이 통과되었을 것이다”라고 언급했습니다.  얼마나  Problem을 명시적으로 잘 정의하고 파악하는가가 중요합니다. 이러한 문제는 Requirment Engineering이나 6 Sigma와 같은 것들을 이용해야 겠지요 🙂

• Pattern은 상식 (common sense)를 다룬다.
  

몇몇 사람들을 패턴을 읽고  “뭐야 이 패턴은 누구나 아는 상식이잖아!’  말합니다. 그리고 많은 시간이 지나도  그 사람들이 맞다고 생각합니다. Pattern은 반복되는 문제에 대한 전문가들의 해결책이기 때문에 이 말이 맞는것 처럼 보입니다. 특히 동일한 도메인에서 일하고 있는 사람들에게는요. 상식을 문서화 것이 바로 패턴의 힘입니다.  만약  패턴이 다루고 있는 내용이 전혀 범용적이지 못하다면, (“Common sense 가 uncommon 하다면) 패턴으로써 가치가 있을까요? 만약 상식을 다루지 않는 다면, 동일한 문제를 겪는 사람도 적을 것이고 동일한 실수를 하는 사람도 적을 것입니다.

그 외의 내용들

그 외의 내용들은 하나의 문제를 너무 깊숙하게 생각한 나머지 다른 문제를 전혀 못다루는 상황이 발생했을때 15-miniute 패턴을  이용해서 15분만 생각하는 패턴과 Part 2에서는 실 사례를 다루니 그것을 보고 여러분 조직에 적합한 사례를 찾아서 사용하라는 말이 있습니다. 그리고 48개의 패턴을 index 카드를 만들어 서로 익히는 방식을 제안합니다. 정리하느라 제법 많은 시간이 걸렸습니다.  많은 분들에게 도움이 되길 바라며, 여력이 될때 또 3장을 정리하죠 🙂