기쁜 마음을 먹고 행사가 열리는 호텔에 도착했습니다. 말씀드린것과 같이 SPLASH(OOPSLA) 와 piggyback 패턴으로 나란히 열린다고 말씀 드렸는데요.  호텔에 도착하자 마자 다음과 같이 큰 사진이 반겨주었습니다. 하지만 바로 옆에 여러명이 담배를 피면서, 슬롯머신을 돌리고 있어서, 분위기가 좀 이질적으로 느껴졌습니다.

여튼  행사장에 들어가니 Linda  아주머니와 Bob 아저씨가 기다리고 있었고, 즐겁게 악수를 하면서 안부를 물었습니다. 시간이 지나 사람들이 하나 둘 모이기 시작하니 15명 정도의 인원이 도착했고, 서로가 무슨을 하고 있고 왜 PLoP에 참여하게 되었는지 얘기를 했죠. 다행히 작년처럼 Ripple Game을 안해서 정말 다행이라고 생각이 들었어요.  🙂

서로의 소개가 마친 다음 Bootcamp가 시작되면서 여러가지 주제들을 나누었습니다. 작년 Bootcamp와는 좀 다른 느낌을 가지게 되었습니다. 왜냐면 후방 지원이 빠방했거든요. 뒷 자리에 Joe Yoder, Linda  아주머니의 남편 Karl, 그리고 Program Chair인 Christian 까지 합세해 여러가지 질문들에 다양한 관점으로 답변을 해주었습니다.

PLoP 이란..

PLoP이라는 행사는 GoF의 Ralph Johnson이 1994년 처음 열었고, Speaker 한명이 발표를 하고 청중들은 듣는 전형적인 Conference의 틀을 깨고, 활발한 상호 커뮤니케이션과 함께 패턴을 전파하는 컨퍼런스 입니다.

그래서 논문을 제출하면, 단순히 accept / reject 통보만 받는 것이 아니고, 그 분야의 전문가인 Sephered(목자)가 붙어 2달동안 논문을 같이 다듬고, 발전 시켜 줍니다. 그리고  Shepherd들이 모여, 논문의 통과 여부를 결정한다고 합니다.   올해는 30개가 넘는 논문들이 제출되었는데 그중에 반만 accept되었다고 하네요.   아마 완벽하지 않더라도, Shepherd가 붙어서 논문을 다듬어 주니 당연히 논문이 좋아 질수 밖에 없죠.

업계 최고의 컨설턴트(아키텍트)에게 자신의 논문을 멘토링 받는다고 생각해 보세요. 아마 이런 경험을 무료로 받을 수 있는 곳은 PLoP이 유일할 것입니다. 열심히 노력해서 논문을 완성시킨다면, 여러분도 좋은 결과가 있으리라 생각이 듭니다. 그러니 여러분도 꼭 지원하시길 권해드립니다.

Pattern이란 무엇인가?

아무래도 Bootcamp이기 때문에, 패턴에 대한 지식이 많이 없는 분도 참여했습니다.   그리고 Bootcamp 행사 자체가 패턴의 본질에 대해서 얘기를 나누는 프로그램이라, 기본기에 대한 이야기드을 많이 들을 수 있었습니다.

• Pattern은 Common Knowledge(범용적인 지식)인가?

Linda :  Pattern은 주어진 상황 (Context)에 반복되는 문제들의  해결책들을 모아 놓은 것이다.  그렇다 보니 패턴 자체는 굉장히 구체적인 ( specific) 문제들에 대한 해결책이다.  물론 해당 도메인이 사람들이 보기에는 범용적인 지식이 될수도 있다.  패턴은 같이 모여서 research study 하는 거다. (study의 어원자체가 공장처럼 여기저기서 꿍짝 꿍짝하면서 만드는 행위에서 파생 되었음).  좋은 패턴을 만들기 위해서는 자신의 생각과 관점을 다른 사람들을 통해 다듬을 필요가 있다.   우리가 Writers Workshop(저자 워크샵)을 진행하는 이유이기도 하다.

• Pattern은 Process인가?

Bob : 패턴은 전문가들의 practice 와  experience를 모아 놓은 것이다. 패턴은 resulting context와 같은 부분에서 패턴을 적용해서 얻는 득과 실까지 설명하고 있다.  process보다 좀더 자세하고 구체화된 지식의 쳬계이다.

• 패턴을 작성하는 스타일(템플릿)은 여러가지가 있는가?  난 GoF 패턴을 참고해 패턴을 만들었는데. Sample Code Section을 보고, 어떻게 Sample Source 코드 세션을 넣어야 하는지 고민했다. 나의 패턴은 소프트웨어 설계보다는 프로세스에 가까워서 실제 코드를 넣기가 힘들었다.

Bob : 패턴을 작성하는 스타일은 여러가지가 있다.  Linda Rising과 Jim Copelin이 쓴 조직을 위한 패턴도 있고, Design 패턴도 있고, Architecture 패턴, Securiy 패턴, Process 패턴, HCI 패턴등 다양한 패턴이 있다.  자신의 패턴에 대한 범주를 보고, 지금까지  도메인 별로, 작성한 스타일을 유지하며 패턴을 작성하면 된다.

• Architecture 패턴과 Design 패턴의 차이는 무엇인가?

Bob : Architecture 패턴은 변경되면 시스템에 매우 넓게 영향을 미친다.  하지만 디자인 패턴이 변경되면 일부 내부적인 영역에만 영향을 미친다. 그러므로 Architecture 패턴을 선정할때는 주의 깊게 선정해야 된다. 잘못 아키텍쳐를 정하게 되면, 다중에 변경시 미치는 Side Effect는 엄청 크다.

Pattern의 구성요소 (Parts) 들에 대해서.

또한 이어서, 패턴의 구성요소 하나하나에 대해서 이야기를 나누었습니다.

Context

Linda :  많은 사람들이 솔루션을 발굴하는 것에만  초점을  맞추었는데. 하지만 Context를 주의 깊게 봐라. Context를 고려하지 않으면, penalty를 얻게 된다.  엄마가 밥을 먹기 전에 손을 씻어라, 등은 솔루션이다. 하지만 왜 씻어야 되는지, 그 상황들을 Context에 설명해야 한다.  그리고 씻은 다음(Resulting Context)에 너에게 어떤 좋은 일이 생기는지 말해주면 좀더 능동적으로 잘 씻게 될것이다.   당신이 만든 패턴이  좋은 솔루션이 되기 위해서는 Context를 잘 작성하는 것이  필수적이다.  또한 왜 이렇게 패턴 구성요소들이 구축되었는지 히스토리를 이야기를 했습니다. (Fearless Change에 나온 이야기들이였더군요. )

가능하면 context에 target user를 명확히 적어라.  어떤 pattern language 논문에서는 다양한 target user를 가진적이 있다.  어떤 패턴은 designer를 위한것이고, 어떤 패턴은 team 전체를 대상으로하는 패턴도 있었다.  패턴 라이팅할때,  target user의 경험과 배경지식을 고려해 논문을 쓰는 것이 중요하다.  Target user가 친숙한 도메인 용어를 사용해야 하며,   Domain을 이해하는 것이 중요하다.

Context에서 여러가지 제약/precondition 을 기술하는 것이 중요하다.  Bob 아저씨께서,  POSA1 서적을 펼치며, 제약 사항들을 잘 설명해 왔다는 것을 보여주네요. 언어에 대한 제약들( C++언어에 익숙한 사람들이 보아야 된다는 얘기들을 ) 그대로 읽어주며  설명해 주었습니다. 그리고 Domain specific한 것도 고려해서 Context에 적으라고 하네요.

Title (Name)

패턴의 이름 정하는게 중요하다. 많은 패턴 Author가 적절한 이름을 찾기 위해 오랫동안 고민하는 것을 보았다. 패턴에 대한 이름은 정말 신중하게 고려해서 정해라. “George Washington은 죽지 않았다. ” ,”Buffalo Moutian” 이라는 패턴이 있는데. 이 패턴이 의미하는 바를 아는 사람이 있을까? 패턴의 이름은 Communication 수단이 되는 중요한 부분이다. 정말 신중히 오랫동안 고민해서 작성해라.

패턴의 적용 범위 와 상세함  그 사이에 균형찾기

인도에서 오신 Shivanshu님이 정말 의미 있는  질문을 해주셨습니다.

Shivanshu: 제약사항을 많이 기술하면, 하나만 구축할 수 있는 사례가 아니냐? 누군가 이 패턴을 적용할려면 너무나 많은 제약으로 인해 패턴을 적용할 수 있는 범위가 줄어들게 된다. 그럼 가치없는 패턴이 되지 않을까?

Christian: 이것은 Trade-Off이다. General  패턴이면 사용성은 높아지지만, 구현/적용할 때 많은 것을 더 고려해야 한다. 하지만 specific하면 할수록, 적용하기가 쉽지만 범용성은 떨어진다.

Shivanshu: 그러한 자세한 부분은 implementation에 자세히 기술하면 안되나?

Karl : 사람은 생각하는 쳬게가 다른다. 어떠한 것은 추상적으로 생각하기도 원하지만, 또한 어떠한 것은 굉장히 자세히 알기 원한다. 그래서 이 두가지의 관점은 항상 상충되기 마련이다.

Bob : Microsoft의 Pattern&Practice 팀에서 만든 자료에서는 하나의 도메인에만 종속된 패턴이 몇백 페이지가나 된다? 다양한 제약사항들을 Context에 기술하지 않으면, 이렇게 작성될 수도 있다.

Linda : 가능하면 패턴은 specific하게 설명하는게 좋다. 너무 General하게 설명하면, 그 문제에 대한 해결책을 적용하기 아려워 진다.

Christian: 추상화 적인 패턴 + context를 만들고, 좀더 상세적인 여러 패턴 + 여러 context를 만들어서 작성하면 좋을거라고 생각한다. Shivansu는 어떻게 생각하는가.

Shivanshu : 나의 생각으로는 implementation에 좀더 자세히 기술하는 하는게 낫다고 생각한다.

Bob : Microsoft Pattern & Practice 팀이 만든 자료를 보면 하나의 패턴 시스템이 300페이지를 다루고 있다. 그런데 만약 다양한 플랫폼까지 고려하면, 기하급수적으로 늘어날 것이다.  하나의 패턴이 너무나 많은 페이지를 가지고 있다면 누가 읽을 엄두를 내겠느냐?  나의 생각에는 Target Audience가 다르면 context를 따로 만들어야 되고, 결국 패턴을 따로 만들어야 된다.

Linda : 인도 친구 생각이 꼭 틀린 것은 아니다. 하지만 우리가 이렇게 가이드를 하는 것은, 지금까지 2000개의 패턴들이 나왔는데, 그 중에 수많은 Proxy가 있다. Proxy만 보고 이게 무슨 패턴인지 알수 있나?  Proxy 가 워낙 다양한 곳에 쓰이니, Proxy라는 말로 대화를 나누기 힘든 정도까지 왔다. 그래서 좀더 구체적인 Context와 구체적인 Proxy를 만드는 게 낫다는 생각이 들었다. 그래서 이런 가이드라인을 주는 거다. Wrapper라는 것은 굉장히 추상적인 이름이다. 하지만 이  Wrapper로부터 파생되,  Holder, Decorator와 같은 다양한 패턴이 파생되었다.

Problem / Solution

Bob :  Problem 역시 Specific하게 말해라. Context로 상세히 설명하고 구체적으로 Problem을 만들어라.  Problem과 Solution 은 서로 대칭관계다.  마치 시작과 끝점처럼 그러니 두가지는 항상 균형을 맞추어 작성해야 한다.

Bob : 또한 Solution을 구성할 때 하나의 패턴보다는 Pattern Lanuage (패턴 랭귀지) 형태로 구성해라.

A1 : Pattern Lanuage가 뭐냐?

Bob : 그럼 좀더 상세히 설명해주겠다.

이 패턴은 통신을 하는 어플리케이션을 만들때 사용하는 패턴인데, Fault Tolerant한 시스템을 만들기 위해서  다양한 Input/Output을 Check하고 모니터링할 IO Gatekeeper를 만들었다. 이 녀석을 통해서 Monitoring은 용이해 졌지만, 다시 메세지를 적절하게 분배하는게 필요하다. 그래서 나온 패턴이 I/O Triage이다.  I/O Triage를 하기 위해 내부적으로 Timestamp라는 Idiom이 필요하다.

이 패턴과  Idiom의 관계에서 볼수있는 것처럼 IO Gatekeeper의 RC (Resulting Context)이 side effect를 보완하기 위해 I/O Triage가 나왔고, I/O Triage를 만들기 위해 내부적으로 Timestamp가 나왔다. 이 말은 역은 I/O Triage를 말하기 위해, Context에서 I/O Gate Keeper에서 설명이 되어야 한다.  결국 이렇게 패턴은 상호 작용하며 만들어 지는 것이다.

Forces

Joe : 좋은 패턴은 Force 섹션을 잘 작성해야 한다. Force 를 통해서 이게 얼마나 어려운 문제인지 잘 설명해야 한다.  무엇이 Tradeoff 관계인지 어떠한 선택들이 존재하는지 설명하는 곳이다.  Force가 많으면, 나중에 패턴 랭귀지를 만들 때 여러가지 세부적인  세부적인 문제들을 나누어 각각 개별 패턴으로 나눌수 있는 좋은 기반이 된다. 왜 이 솔루션을 적용해야 하는지 이러한 중요한 내용들을 적어야 한다. 이 패턴이 왜 사용해야 하는지, 어떠한 부분이 중요하게 여겼는지 설명하는 일종의 마켓팅과 같은 영역이다.

Sketch

Bob : 알랜산더가 직접 그린 Hand Sketch가 모태가 되었다. 그래서 우리도 사람들을 이해하기 쉽게 하기 위해, 직관적인 그림 또는 sequence diagram 을 그려 놓으면 좋다.  많은 사람들이 이 패턴이 무엇인지 쉽게 이해할수 있는 그림들을 그려 놓아라.

Resulting Context

Linda : 솔루션을 적용해서 얻었던 좋은 것 외에 사이드 이펙트를 기술해야 한다. 그리고 가능하면 위에서 Bob이 말한 사이드이펙트를 해결하기 위한 방법도 추가적으로 기술해야 한다.Happy Ending을 만들기 위한 섹션이다.

Author

논문 저자외에 , 도움을 준 사람도 추가적으로 기술할 것. 그리고 shepherd의 감사의 메시지를 적는 곳이다.

그 외 이야기들.

세션 중간 중간에 나왔는데 공유합니다.

Bob : 좋은 패턴이 되기 위해서는 interaction에 좀더 치중해서 작업해라 (interaction 을 잘 정리해라.) 다양한 개체/대상간에 어떠한 interaction이 있는지 잘 기술하는게 중요하다.  그게 사람이든 객체이든 Known Use와 Solution 부분에 잘 기술하는게 중요하다.

Linda : 아키텍쳐 솔루션 컨퍼런스에서 너무나 많은 정보들이 돌아 다니느 것을 보았다. 하나의 솔루션을 만들기 위해 여러가지 정보들이 뒤죽 박죽 섞여 있었다. 그래서 이러한 정보들을  problem / context / forces / solution / resulting context로 나눠서 정리했다. 이렇게  분류해다 보니, 문서가 되고, 곧 진정한 솔루션이 된다.

Linda : 그리고  별도의 Revision history도 작성해서, 패턴의 진화 과정을 공유하는 것이 좋다.

마치며..

Bob Hanmer와 Linda알고 행사를 들어서 인지 작년 행사와는 정말 다른 느낌이었습니다. 아마 작년에는 너무 긴장하고 가서 그런거 같애요 :).

이번 행사를 하면서 느낌점은 국내에 많은 개발자들이 단순히 패턴을 솔루션으로만 바라 본다는 느낌이 강했습니다. 당장 이 패턴을 쓰겠다는 관점에서 바라보는 것과, 패턴을 만드는 입장에서 바라보는 패턴의 관점은  정말  다릅니다. 그래서 패턴을 사용하기 위해 바라볼때도, 전체적으로 보이는 눈이 더 성장해졌다고 볼수 있습니다.   국내에서 몇번 패턴 라이팅에 대한 강의를 했지만, 아마도 직접 패턴 라이팅을 하지 않은 분을 대상으로 하다 보니, 이 정도의 감명이 전달되지 않는거 같습니다.  물론 제가 못해서 그런 거도 있겠죠 🙂

이번 행사중 놀라운 경험은 Linda  Rising에게 책에 싸인을 받은것 뿐만 아니라,번역하느라 고생이 많다며, 포옹도 해주시더라구요.  마치 할머니께서 손자 포옹해 주는 느낌? 🙂

그리고 정말 굉장하면서 신선한 경험을 했습니다.  Bootcamp  중간에 Joe Yoder와 1:1  Peer Pattern Writing을 했습니다. Writing Group이라는 프로그램인데요.  저의 논문을 Joe Yoder가 읽으면서 하나 하나 수정해주고, 다듬어 주었습니다. 여튼 이 경험도 추후 공유하겠습니다. 그래서 Bootcamp 중간 2시간 정도를 듣지 못했지만, 정말 이건 이전에 Joe’s Pattern Writing보다 더 Intensive한 느낌이었습니다.  감사합니다. Joe Yoder!! 커피도 잘 얻어 먹었어요. 내년에 꼭 선물 준비해 갈께요!!   음 미국 시간으로 벌써 3시군요. 8시반 까지 가야 하는데. 역시 블로깅은 ㅋㅋ 시간 잡아먹는 괴물이에용 ㅋㅋㅋ

내일은 Refactoring to Pattern의 저자 Joshua Kerivsky의 멋진 강연이 있습니다. 그리고 Wirter’s Workshop도 열리구요. Writer’s Workshop 데모 내용을 동영상으로 찍어 올때니 기대 많이 하세요 🙂