PLoP에서 수많은 거장들을 만났습니다. 거장들중 우리나라에 그리 많이 알려지지 않은 분들을 하나씩 소개할려고 합니다. 왜냐면 이들의 연구분야들을 하나씩 소개하는 것이 어떤 분들에게는 귀중한 정보다 될것이고, 많은 도움이 될거라고 생각이 듭니다.
Robert Hanmer씨는 이번에 저희 Half-Push/Half-Polling 패턴의 목자 (Shepherd) 이셨습니다. (PLoP에서는 패턴을 제출하면 완성도 있는 패턴을 한번 거른다음, 각 패턴다마 패턴을 잘 쓸수 있게 목자(멘토)를 지정해 줍니다. 그럼 목자와 함께 계속 애기를 나누면서, 패턴들을 수정해 나가는 거죠. 그 이후 저자 워크샾을 통해 한번 더 다듬게 되고, 최종 논문이 완성됩니다.)
PLoP의 BootCamp를 수년간 Linda Rising과 이끌고 있었고, 상당히 부드럽고 배려심이 많으신 분입니다. 이하 Bob 아저씨(Robert를 다 Bob이라고 부릅니다)는 현재 Alcatel-Lucent (Lecent Technolgies and AT&T)라는 Telecomunication 회사에서 Consulting Member로 근무중이며, 고 수준의 가용성(availiability)를 보장하는 시스템을 꾸준히 만들어 오셨습니다.
이러한 패턴들은 고수준의 품질을 요구하는 제조업과 아주 밀접한 연관이 있으므로, 국내 제조업에 종사하는 소프트웨어 개발자에게는 상당히 도움이 될만한 서적이라고 생각됩니다. 그리고 인사이트에서 판권을 확보하고 현재 번역중이라고 하니 조만간 번역서를 만나 보실 수 있으리라 생각이 듭니다.
저희 EVA 네 식구 (현종님, 지원군, 민정님, 희정양, 정민군)와 함께 Half-Push/Half-Polling 패턴에 대해서 또 한번의 저자 워크샾을 가졌습니다. POSA2에 대한 이해도가 PLoP에 있는 분들보다는 높기 때문에, 좀더 수월하게 Writer’s Workshop이 진행될 수 있었던 것 같습니다.
재미난 것은 PLoP에서 받은 피드백과 유사한 내용도 많았고, 다양한 의견도 많이 나와 도움이 많이 되었습니다.
모든 소프트웨어 아키텍트들은 모든 것을 가질 수 없다는 것을 알고 이해해야 합니다. 높은 성능, 높은 가용성, 고 수준의 보안 그리고 고 수준의 추상화 모두를 동시에 충족하는 아키텍쳐를 설계하는 것은 사실상 불가능합니다.
소프트웨어 아키텍트들이 알아야만 하고, 이해해야 하는, 그리고 고객, 동료와 함께 대화를 나누어야 하는 진실된 이야기가 있습니다.
이 이야기는 Vasa라 불리는 배 이야기입니다. 1620년대에 스웨덴과 폴란드 사이에 전쟁이 발생했습니다. 스웨덴 국왕은 비용이 많이 드는 전쟁을 빨리 끝내고 싶었고, vasa라 불리는 배를 건조[1]할 것을 명령하였습니다. 이 순간부터, 이 배는 더 이상 평범한 배가 될 수 없었습니다.
이 배가 갖춰야 했던 조건(요구사항)들은 그 당시의 어떤 배와도 비교할 수 없었습니다: 선체가 200피트 정도 더 길고, 2개의 갑판에 64개의 총을 적재할 수 있고, 300명의 군사를 안전하게 태워 폴란드로 가는 바다를 가로지를 수 있는 수송 능력을 가져야 했습니다. 배를 건조하는 데드라인(시간)을 엄수해야 했으며, 재정(자금)적으로도 여유롭지 않았습니다.
I Need Feedback.
이번 PLoP 2009에서 받았떤 저희 Half-Push/Half-Polling 패턴의 저자 워크샾에서 받았던 실제 피드백 내용을 정리했습니다. 몇 개가 더 있지만, 영어적인 문제라 뺐습니다. Eduardo 교수님께서 일일이 잡아주셨습니다. Eduardo 교수님 정말 감사합니다.
이걸 참고하셔서 좀더 피드백을 주시거나, 아래의 리스트와 다른 새로운 피드백을 주시면 감사하겠습니다.
이번 PLoP에서 인상 적인 화면 하나는 바로 이것입니다. 바로 실시간으로 행사에 대한 피드백을 주고 받았다는 것입니다.
대부분의 행사는 행사가 끝난후에, A4 종이 한장에 조그만 칸에 불만 사항을 적습니다. 그리고 조금 더 진보한 상황은 이렇게 포스트 잇을 붙여서 자유롭게 그 의견을 말하게 해주는 겁니다. 몇몇 행사가 이런 형태를 취하고 있더라고, 바로 바로 그 피드백을 받고 대응하지는 않습니다. 물론 하는 분이 있으시다면,정말 멋있는 방법을 사용하시고 잇는 겁니다.
PLoP에서는 불만 사항들을 될수록 수정하도록 노력했으며, 못하는 상황에서는 이유를 충분히 설명해 주었습니다. 조그만 3시간 짜리 세미나라면 적용하기 어렵겠지만, 1~2일을 통째로 쓰는 워크샵이라면 충분히 의견을 주고 받는데 도움이 될거 같습니다. 그때 그때 피드백을 바로 받을 수 있으니깐요. 🙂
나중에 PaperMeeting이나 KPLoP 같은 행사를 진행할 때 꼭 써봐야 겠습니다.
PLoP에 같이 참여했던 후배 이 혁준 군이 보내준 소감문입니다. 아무래도 저말고 다른 사람의 소감도 같이 공유하는것이 좋을듯 해서 공유합니다. 🙂
PLoP는 패턴에 관한 한정된 주제에 대해서만 다루고 있어서, 다른 분야의 사람들에게는 잘 알려지지 않은 학회지만 16년 동안 꾸준히 전 세계의 패턴 전문가들과 패턴을 공부하는 사람들이 참가해 서로의 의견을 교환하고 서로의 논문을 향상시켜 왔다. 컴퓨터 공학 분야에서는 두말 할 것도 없이 유명한 ACM에서 활동하는 여러 패턴 전문가들이 패턴 분야에 새로 입문하거나 패턴을 연구하는 사람들을 이끌어주고 있고 제출된 논문을 더욱 다듬어 최선의 패턴을 만들고 있다.
Writer’s workshop에서 논의된 논문들은 Springer’s에서 발간하는 TPLoP(Transactions on Pattern Languages of Programming) 저널에 실리고 여기서 논의된 다수의 논문들이 ACM에 등록된다. 그만큼 writer’s workshop의 효과가 대단하다고 할 수 있다.
이번 PLoP 에서 프린터로 받은 Pattern Template을 번역해서 올립니다.
기존 Pattern Template에 달리 추가된 내용이 Resulting Context/Side Effects 입니다. 지금까지 패턴들은 장점만 너무 기술한 경향이 있는데. 이제 이 패턴을 적용할 경우 발생하는 Side-Effect도 기술하길 권하고 있습니다.
영어 원문을 그대로 번역한 것이라. 약간 매끄럽지도 않을 수도 있습니다. 🙂
저자 워크샾을 벽위의 파리 (저자) 입장에서 보았을 때의 느낌을 공유합니다.
회고로 보시면 좋을듯 합니다. 저자 워크샾( Writer’s Workshop) 진행 방식은 바로 이전 포스트인 저자 워크샾 Demo를 보시길 바랍니다.
저희 그룹의 좌장은 GoF의 Ralph Johnson이 였으며, 조정자(Moderator) 역할을 해주셨습니다. BootCamp때 진행한 Linda 아주머니와는 약간 다른 진행방식을 취했습니다. Rinda 같은 경우는 끊임없이 서로의 의견을 주고 받으며, 적절히 시간 조절을 잘 해주었는데, Ralph Johnson 박사님은 토론을 좋아하는 분이신지라 🙂 거기에 깊게 뛰어든 나머지,조정자 의 중요한 역할 중 하나인 시간 배분을 잘못해서, 저희 Pattern 뒷 부분을 다루지 못하게 되었습니다. 상당히 아쉽더군요 …
사실 저자 워크샾에 참석하기 전에 패턴을 정독해서 읽어가야 하지만, 몇몇 참가자들이 패턴을 읽지 않고 왔습니다. 그래서 Implementation 부분에 다루는 애기들을 앞에서 많이 하는 경향이 보이더라구요. 저자 워크샾을 참석하는 참가자들은 꼭 논문을 사전에 정독하시길 권해드립니다.
그래도 많은 피드백을 받았기 때문에, 이 부분도 수정을 하고 저희 스터디 그룹과 같이 MiniPLoP 형태로 진행해서 남은 부분을 보완할 생각입니다.
PLoP 첫번째 날인 오늘은 매우 재미나고 신나는 하루였습니다.
오늘 말로만 듣던 Writer’s Workshop을 직접 체험한 날이였습니다. 하나는 참가자의 역할로 또 하나는 저자의 역할로 진행을 했습니다. 행사가 시작하기 이전에, PLoP의 대표자들이 모여 진행한 Writer’s Workshop 을 어떻게 진행하는지 설명하는 데모 사진을 찍어보았습니다. 김창준 님이 이미 공개한 내용이지만, 그래도 직접 사진과 보시는게 좋을듯 해서 올려드리도록 하겠습니다.
PLoP에서 참가자는 크게 세 부분으로 나뉩니다. 저자, 참가자, 그리고 행사를 진행하며 조정하는 조정자입니다.
Architecture 101 