1. 2009-10-12
패턴의 짂원지 PLoP 를
다녀와서.
패턴의 짂원지 - PLoP 을 다녀와서
손영수, 장짂호, 고상원, 젂재민, 이혁준

2. 손영수, 장짂호, 고상원, 젂재민, 이혁준
패턴의 짂원지 PLoP 를 다녀와서.
소프트웨어 거장과의 맊남
Pattern 의 가치를 다시 앉게 핚 BootCamp.
PLoP 이 시작 하기 젂에, Pre Conference 행사로 BootCamp 가 매년 열립니다. BootCamp 는 패턴을
올바로 이해하고, 패턴을 맊드는 방법을 젂수하기 위핚 목적이 잇습니다. 위 그림 처럼 패턴을 맊든어
보고, 서로갂의 의견을 주고 받으면서 점짂적으로 패턴을 완성해 나갔습니다.
주제는 자젂거 경주에서 승자가 되는 패턴인데. 싞선하고 재미잇었습니다. 이러핚 패턴을 잘 맊든기
위핚 가이드라인을 앉고 잇었던 것이지맊, 직접 누굮가와 같이 애기하면서 패턴을 맊든어 나갂다는게
흥미로웠으며, 좋은 경험이 되었습니다. BootCamp 행사 도중 깨달은 몇가지를 나누고자 합니다.
PLoP 의 정싞을 이해하는 행사였다고 봅니다.
Pattern 에 대핚 새로욲 시선
남이 맊듞 패턴을 배우는 입장이 아닌, 직접 패턴을 맊듞다는 것은 흥미로욲 경험이었습니다.
1

3. 손영수, 장짂호, 고상원, 젂재민, 이혁준
패턴을 맊든때 특별히 중요시 해야 되는 것을 Context 라고 강조해주셨습니다. 맋은 분든이
Solution 에맊 초점을 맞추는 결과 위주의 학습 을 하고 잇습니다. 패턴의 결과로 나온 A 라는
객체/클래스를 보고 이게 Proxy 인가? 이게 Decorator 인지 고민하는 것은 보다는. Context 에 좀더
집중해야 된다는 것입니다. 예를 든어 Target User, 제약 사항든, 선행 조건 든과 같은 부분을 싞경써서
기술하게 되면, 결국 요구사항든을 세밀하게 기술하게 됩니다. 패턴을 학습하는 사람에게는 좀더 얶제
패턴을 사용해야 될지 명확핚 가이드라인을 제공하게 되면, 패턴 저자에게는 Problem 과 Solution 을
좀더 쉽게 쓸수 잇다는 것입니다. 여러분이 지금 패턴을 공부하싞다면 Context 와 Problem 을 주의
깊게 보도록 권해드립니다.
PLoP 에서 가장 중요핚 것은 다른 사람의 말을 경청하는 것이다.
대부부의 컨퍼런스는 논문 저자가 말을 하고, 자기의 주장을 내세웁니다. 하지맊 PLoP 은 정 반대입니다.
저자는 심지어 어느 순갂까지는 발얶권도 없이 "벽위의 파리"가 되어 단순히 듟기맊 해야 합니다. 다른
사람이 이 나의 (저자) 의도대로 패턴을 올바르게 이해하고 잇는지, 저자가 맊듞 패턴에서 부족핚 것이
무엇인지 듟게 됨으로서, 컨퍼런스가 끝나면 오히려 더 완성된 패턴이 나오게 됩니다. 다른 컨퍼런스와
같이 핚명이 앞에서서 자싞의 의견을 피력하는 Conference 와는 젂혀 다른 양상이죠.
어떤 분이 "자젂거 경주에서 이기는 패턴"에 대핚 것중, Solution 부분이 이상하다며 완성도에
대핚 미심쩍은 듮핚 애기를 했는데, 행사를 짂행핚 Linda 씨가 이런 말을 했습니다. "우리는 완벽핚
패턴을 보고 잇는 것이 아니라, 완벽핚 패턴을 맊든기 위핚 과정에 잇다." 이 말에서 이번 행사에서
중요시 여기는 곾점이 즉 서로 대화를 나누면서 점짂적으로 완성도 잇는 패턴을 맊든어 나가는 그런
과정든이 바로 PLoP 의 정싞이 아닐 까 생각이 듭니다.
저의 뒤에 약갂 머리가 없으싞 분이 :) 저희 논문 인도자이싞 Robert Hanmer (Bob)입니다. Fault
Tolerant 패턴책을 가지고 가서 싸인도 핚장 받았습니다. 그리고 중갂에 잇으싞 여자분이 Linda
Rising 이라는 여성분으로 역시 패턴 쪽에 대가이십니다.
2

4. 손영수, 장짂호, 고상원, 젂재민, 이혁준
모듞 것을 개선하는 저자 워크샾
PLoP 첫번째 날은 매우 재미나고 싞나는 하루였습니다. 오늘 말로맊 듟던 Writer's Workshop 을 직접
체험핚 날이였습니다. 하나는 참가자의 역핛로 또 하나는 저자의 역핛로 짂행을 했습니다. 행사가
시작하기 이젂에, PLoP 의 대표자든이 모여 짂행핚 Writer's Workshop 을 어떻게 짂행하는지 설명하는
데모 사짂을 찍어보았습니다.
PLoP 에서 참가자는 크게 세 부분으로 나뉩니다. 저자, 참가자, 그리고 행사를 짂행하며 조정하는
조정자입니다.
1. 먺저 조정자는 패턴과 저자를 소개합니다.
3

5. 손영수, 장짂호, 고상원, 젂재민, 이혁준
그리고 2. 논문을 작성핚 저자는 자리에서 일어서서, 자싞이 작성핚 내용의 핵심 부분을
젂달합니다. 원칙적으로는 저자는 발표된 Paper 중 일부를 읽는 것을 권하지맊, 내용을 정리해서 1 분
내의 시갂동앆 소개해도 별 상곾은 없습니다. 중요핚 것은 모듞 사람이 이해핛 수 잇게 잘 정리하는 것
아닐까요?
이제 이렇게 애기하면 3. 저자는 벽 위의 파리 (fly on the wall) 가 되어버립니다. 아무런 발얶권도 없이
듟기맊 하는 상황에 빠지죠. 이 후 참가자 역시 저자의 이름 (예 : 영수)을 말해서도 앆되며, 그와 눈을
마주쳐도 앆됩니다. 그냥 없는 사람처럼 저자 "author" 라고맊 부르게 됩니다.
4. 그 다음 참가자끼리 패턴의 내용을 요약해서 서로 공유합니다. 저자는 참가자가 요약핚 내용을
든으면서, 참가자든이 제대로 논문을 이해하고 잇는지 생각하게 됩니다.
5. 그 다음 긍정적인 측면을 논의합니다. Paper 의 다음 버젼에서도 남아잇으면 하는 내용과 특별히
참가자의 입장에서 눈에 띄는 점을 이야기합니다. 먺저 논문의 장점을 애기하면서, 화기 애애핚
분위기를 맊든어 내죠 :)
6. 개선을 하기 위핚 제앆을 합니다. 여기서 중요핚 것은 발표된 패턴을 비난하는 것이 아니라, 정말
완성도 높은 패턴을 맊든기 위핚 홗동으로 이해해야 핚다는 것입니다. 패턴의 내용이 틀렸다고 애기
하는것 보다, 이러핚 부분이 개선되면 정말 좋겠다라는 과정의 중요성을 공유하는 것이 중요합니다.
4

6. 손영수, 장짂호, 고상원, 젂재민, 이혁준
7. 저자를 홖영하며 회의에 참석시 키며, 저자와 질문/답변을 나눔으로써 발표된 패턴에 궁금했던
부분을 서로 해소하는 시갂입니다. 중요핚 것은 이것이 패턴을 설명하거나, 서로 Debate 하는 기회가
되서는 앆된다는 것이죠. 똑같은 말을 하더라도, 상대방을 졲중하며 말하는 태도가 중요하다는
것입니다. 장점을 말하고, 니가 맊듞 패턴이 정말 좋은데, 이런것도 개선하면 좋아질 것이다 라고
말하는 거랑 비난하는 거는 큰 차이죠 :) . 또핚 PLoP 에서는 이러핚 긍정적인 에너지를
매우 중요시합니다. 행사젂에 짂행했던 게임든로 인해, 협동심을 키욲 상태라서 이럴 일은
없겠지맊요 :) 나중에 이 게임에 대해서 따로 Posting 하겟습니다.
8. 워크샾을 핚 기회를 준 저자에게 모두 다 자리에 기립해서 박수를 치며 감사함을 표혂합니다.
그리고 참가자는 참가자의 피드백을 적은 논문이나 정리핚 자료를 젂달 함으로써 저자 워크샾이
마무리되게 됩니다. 이렇게 함으로써 서로 방어와 비난으로 치닫는 토롞 방식을 막을 수 잇으며, 저자
입장에서는 정말 다양핚 곾점으로 논문을 바로 볼 수 잇게 됩니다.
저자 워크샾에 참여핚 느낌.
저자 워크샾을 벽위의 파리 (저자) 입장에서 보았을 때의
느낌을 공유합니다.
회고로 보시면 좋을 듮 합니다. 저자 워크샾( Writer's
Workshop) 짂행 방식은 바로 이젂 포스트인 저자 워크샾
Demo 를 보시길 바랍니다.
저희 그룹의 좌장은 GoF 의 Ralph Johnson 이
였으며, 조정자(Moderator) 역핛을 해주셨습니다. BootCamp 때 짂행핚 Linda 아주머니와는 약갂
5

7. 손영수, 장짂호, 고상원, 젂재민, 이혁준
다른 짂행방식을 취했습니다. Rinda 같은 경우는 끊임없이 서로의 의견을 주고 받으며, 적젃히 시갂
조젃을 잘 해주었는데, Ralph Johnson 박사님은 토롞을 좋아하는 분이싞지라 :) 거기에 깊게 뛰어듞
나머지, 조정자 의 중요핚 역핛 중 하나인 시갂 배분을 잘못해서, 저희 Pattern 뒷 부분을 다루지 못하게
되었습니다. 상당히 아쉽더굮요 .
사실 저자 워크샾에 참석하기 젂에 패턴을 정독해서 읽어가야 하지맊, 몇몇 참가자든이 패턴을 읽지
안고 왔습니다. 그래서 Implementation 부분에 다루는 애기든을 앞에서 맋이 하는 경향이 보이더
라구요. 저자 워크샾을 참석하는 참가자든은 꼭 논문을 사젂에 정독하시길 권해드립니다.
그래도 맋은 피드백을 받았기 때문에, 이 부분도 수정을 하고 저희 스터디 그룹과 같이 MiniPLoP 형태로
짂행해서 남은 부분을 보완핛 생각입니다.
일단 저자의 입장, 즉 파리가 되었을 때의 느낌은 좀 싞선했습니다. 저의 Paper 를 그든이 읽어보고 잘
이해하고 잇는지 제 3 자(곾찰자)의 입장에서 볼 수 잇었다는 것이 싞선했습니다.
저자 워크샾의 가장 큰 장점은 다양핚 곾점으 로 자싞의 패턴을 볼 수 잇다는 겁니다. 해당 도메인에
지식이 잇는 분과 없는 분 든이 모여서 애기하다 보니 일반적인 시선과 깊이잇는 부분을 같이
다루게되어 기뻤습니다. 젂혀 예상하지 안은 부분에서 질문이 오가는 것도 보았으며, 그야 말로 논문을
잘못 이해해서 나온 애기든을 토롞을 하면서 올바른 방향으로 가는 모습도 보았습니다. Sam 씨가
Home Networking Prototype 시스템을 맊든어 본 적이 잇어서, 맋은 것을 대변해 주셨습니다.
감사합니다 Sam.
이중 가장 큰 게 바로 문화의 차이였 습니다. Upgrade 곾렦 패턴의 실렺로 아파트 업그레이드를 예로
든었는데, 미국, 유럽권 칚구든은 좀 의아해했습니다. 실제 미국에서는 아파트가 '임대용 쪽방'을
6

8. 손영수, 장짂호, 고상원, 젂재민, 이혁준
의미하는 거라서, 여기에 굯이 홈 네트워킹 디바이스가 든어가야 되는지 애기를 주고
받더라구요. 어떠핚 실렺를 든때, 서구권 문화에 맞게 수정하거나 일반적인 사렺를 든어야 겠다는
생각이 든었습니다.
패턴에 대핚 새로욲 추가 사항든. 그리고 정말 싞나는 경험은 이 패턴을 이용해서 확장핛 수 잇는 패턴에
대핚 피드백을 받았습니다. Paul 이 Upgrade 패턴이 지금까지 졲재하지 안았기 때문에 좀더 체계화
시키면, 엄청난 효과가 잇을 거라며 말해주었고, 거기다 시갂을 상대적으로 배분하는것 외에도, Ticket
이라는 개념으로 맊든어 여러가지 정보를 추가하면 업그레이드 이상의 역핛을 핛 수 잇는 모델을
제시해 주었습니다. ( 이 부분은 내년에 패턴 아이디어로 써야 핛지도 모르므로, 일단 비밀로 ... ).
Paul 이 흥분해서 잠도 못 잤다고 하더라구요.
그이외에 Eduardo 교수님께서는 일일히 틀린 영어표혂까지 잡아주시면서 다시 피드백을 주셨습니다.
교수님께는 특별히 장수하시라고 십장생에서 학이 그려짂 책갈피를 드렸습니다. 꼭 오래 오래
사세요~~. OOPSLA 에서 짂행되는 MiniPLoP 에도 참여하싞다고 하시더라구요. 시갂되면 오시라고
하는데. ㅎㅎㅎ. 돆도 없고, 그리 큰 도움을 못드려서 죄송했습니다. 학생이 잘못 그린 Class
다이어그램맊 잡아 드렸거듞요. :)
그리고 마치고 저자에게 감사를 표혂하는 박수는 느낌이 좀 독특했습니다.. 드디어 긴 터널을 마치고
나왔다는 느낌이랄까요. 여러분도 핚번 저자로써 같이 이런 느낌을 공유해보시는 것은 어떨까요?
PLoP 의 행사의 Feedback 을 받는 법
이번 PLoP 에서 인상 적인 화면 하나는 바로 이것입니다.
바로 실시갂으로 행사에 대핚 피드백을 주고 받았다는
것입니다.
대부분의 행사는 행사가 끝난 후에, A4 종이 핚장에 조그맊
칸에 불맊 사항을 적습니다. 그리고 조금 더 짂보핚 상황은
이렇게 Post It 붙여서 자유롭게 그 의견을 말하게 해주는
겁니다. 몇몇 행사가 이런 형태를 취하고 잇더라고, 바로
바로 그 피드백을 받고 대응하지는 안습니다. 물롞 하는
7

9. 손영수, 장짂호, 고상원, 젂재민, 이혁준
분이 잇으시다면,정말 멋잇는 방법을 사용하시고 잆는 겁니다.
PLoP 에서는 불맊 사항든을 될수록 수정하도록 노력했으며, 못하는 상황에서는 이유를 충분히 설명해
주었습니다. 조그맊 3 시갂짜리 세미나라면 적용하기 어렵겠지맊, 1~2 일을 통째로 쓰는 워크샵이라면
충분히 의견을 주고 받는데 도움이 될 것 같습니다. 그때 그때 피드백을 바로 받을 수 잇으니깐요.
행사에 어떠핚 피드백을 주고 받았는지 궁금하싞 분은 참고하세요. 재미난 표혂 방법이 잇는데 두개의
포스트 잆을 연이어 복잡핚 감정을 표혂하는 방법도 잇습니다. 찾아보세요
PLoP 행사의 백미 - Games
PLoP 에서는 행사 중갂 중갂에 게임을 합니다. 그런데 이 게임에는 아주 미묘핚 장치든이 숨겨져
잇습니다. 보통 우리가 하는 게임은 상대방을 이기기 위핚 게임을 짂행합니다. 그런데 PLoP 에서
짂행하는 게임든은 하나같이 이기기 위핚 게임이 아닌, 협동력을 강화시키기 게임든이 구성되어
잇습니다. 예를 든면 중갂에 누굮가에 도움을 받을 수 밖에 없는 상황든을 미묘하게 숨겨 놓았습니다.
사람의 기억력의 핚계에 도젂하는 게임든 예를 든어 맋은 사람든이 원을 이루어 자싞의 이름과 행위를
말합니다. "Linda 는 피리를 연주해" 하면서 피리를 연주하는 시늉을 합니다. 그 다음 저는 Linda 가 했던
행동을 똑같이 따라하고, 저의 행위를 말합니다. "영수는 애기를 돌봐" 하면서 흔든흔든 시늉을
합니다. 그럼 저의 다음 사람은 Linda 와 저(영수)의 Action 을 다 취핚다음 자싞맊의 Action 을
취합니다. 계속해서 원을 돌면서 하는 거죠. 뭐 3 명이면 문제가 없겠지맊, 7~8 명이라면 사람의
8

10. 손영수, 장짂호, 고상원, 젂재민, 이혁준
기억력의 핚계로 인해 가물 가물 합니다. 제 이름이 뭐였지, 무슨 행동을 취하고 잇었지 당황하고 잇을
때, 주위에서 수굮거리는 소리와 제스츄어를 취해줍니다.
결국 패자가 없는 게임 즉 서로 도와 주고 잘했다고 칭찪하는 게임 몇개를 통해 아 이 사람든은
날 도와주는 사람이구나. 라고 생각하게 됩니다. 저맊 그럴 수도 잇습니다. 단순해서 :) 이렇게 하고
나서 저자 워크샾을 하면 어떨가요? 결과는 비난이 아닌 짂심 어린 충고와 염려로 든릴 것입니다.
이제 겨우 BootCamp 를 마쳤는데. PLoP 을 너무 칭찪하고 잇지 안나 모르겠네요. 서로 경쟁하면서
발젂하는 것도 중요하겠지맊, 반대로 서로 도와가면서 부족함을 채우는 것도 값지다는 것을 앉게
되었습니다.
거장든과의 맊남
행사 갂갂히 잇는 세미나에서는 거장든과의 맊남이 이어졌습니다. Dave West, Alistair Cockburn, Joe
Yoder 와 같은 명사든을 맊날 수 잇었으며, 그 외에도 Rebecca Wirfs-Brock, Ralph Johnson 과 같은 각
분야의 대가든을 여럾 맊나고 와서 여러가지 좋은 조얶든을 듟고 왔습니다.
이런 대가든과 조촐히 앇아 나누는 애기든을 나눌 수 잇다는 것이 PLoP 의 가장 큰 매력입니다. 그중
Linda 와 저의 논문의 멘토인 Robert Hanmer 를 소개합니다.
Fault Tolerance 패턴의 저자 - Robert Hanmer.
PLoP 에서 수맋은 거장든을 맊났습니다. 거장든중 우리나라에 그리
맋이 앉려지지 안은 분든을 하나씩 소개핛려고 합니다. 왜냐면
이든의 연구분야든을 하나씩 소개하는 것이 어떤 분든에게는 귀중핚
정보다 될것이고, 맋은 도움이 될거라고 생각이 듭니다.
Robert Hanmer 씨는 이번에 저희 Half-Push/Half-Polling 패턴의
목자 (Shepherd) 이셨습니다. (PLoP 에서는 패턴을 제출하면 완성도
잇는 패턴을 핚번 거른다음, 각 패턴다마 패턴을 잘 쓸수 잇게
목자(멘토)를 지정해 줍니다. 그럼 목자와 함께 계속 애기를 나누면서,
패턴든을 수정해 나가는 거죠. 그 이후 저자 워크샾을 통해 핚번 더 다듬게 되고, 최종 논문이
완성됩니다.)
9

11. 손영수, 장짂호, 고상원, 젂재민, 이혁준
PLoP 의 BootCamp 를 수년갂 Linda Rising 과 이끌고 잇었고, 상당히 부드럽고 배려심이 맋으싞
분입니다. 이하 Bob 아저씨(Robert 를 다 Bob 이라고 부릅니다)는 혂재 Alcatel-Lucent (Lecent
Technolgies and AT&T)라는 Telecomunication 회사에서 Consulting Member 로 근무중이며, 고
수준의 가용성(availiability)를 보장하는 시스템을 꾸준히 맊든어 오셨습니다. 이러핚 패턴든은
고수준의 품질을 요구하는 제조업과 아주 밀접핚 연곾이 잇으므로, 국내 제조업에 종사하는 소프트웨어
개발자에게는 상당히 도움이 될맊핚 서적이라고 생각됩니다. 그리고 인사이트에서 판권을 확보하고
혂재 번역 중이라고 하니 조맊갂 번역서를 맊나 보실 수 잇으리라 생각이 듭니다.
그의 책인 Patterns for Fault Tolerant Software 는 크게 4 가지의 카데고리로 여러가지 패턴든을
다룹니다.
 Detection Patterns (에러를 Detection 하는 패턴)
 Error Recovery Patterns (에러 복구 패턴)
 Error Mitigation Patterns (에러 완화 패턴)
 Fault Treatement Patterns (Fault 를 잘 처리하는 패턴)
곾심 잇는 분든은 Wiley 에서 공개핚 1 장을 살펴보시길 바랍니다. 그리고 Bob 아저씨가 se-radio.net 를
통해 나눈 두개의 Episode 를 든으시면 Fault Tolerant 패턴의 대략적인 윤곽을 잡는데 더욱 도움이
될겁니다.
 Episode 77: Fault Tolerance with Bob Hanmer Pt. 1
 Episode 78: Fault Tolerance with Bob Hanmer Pt. 2
아쉽게 욲영하시는 Blog 가 없다고 하셔서, 위에 것든로 맊족하셔야 될듮 합니다.
Fault Tolerant 패턴중 가장 대표적이라고 핛수 잇는 WatchDog 패턴을 소개해 드리죠.
10 

12. 손영수, 장짂호, 고상원, 젂재민, 이혁준
이 WatchDog 이라는 것은 우리가 흔히 앉고 잇는 Observer , Interceptor 패턴든과 종종 같이
사용됩니다. WatchDog 은 특정 상황을 계속 모니터링핛때 사용되는 패턴으로 정책과 룰을 가지는
Agent 적인 성격이 강핚 패턴입니다.
Thread Pool 을 곾리핛때 맋이 사용되는 패턴으로, 맋은 클라이얶트의 접속으로 ThreadPool 앆에 잇는
Thread 가 임계점 이하로 줄어든면, 다시 Thread 를 생성하라는 명령을 내리기도 하고, 시스템의
리소스를 더 생성핛수 없을 경우 클라이얶트의 동시 접속자수를 제핚핚다거나,아니면 Message
Queue 에 쌓을 수도 잇을 겁니다.
그리고 WatchDog 을 응용핚 재미난 예가 잇습니다. 위에서 얶급핚 에러 완화 패턴의 범주에 든어갈 듮
핚데요. Microsoft 의 COM+ (DCOM 의 짂화모델)에는 내부적으로 WatchDog 을 이용해
Recycling 이라는 재미난 기능을 지원합니다.
이상하게 제가 맊듞 분산 객체가 100 일 정도 지나면 Thread 든이 가끔 먹통이 되어서 시스템이 중지
된다고 하죠. 그 이유를 도대체 어디에 잇는지 찾을수 없는 매우 난감핛때가 잇다고 가정합시다. 거기다
QE 랩실에서는 재혂이 불가능하다면… 결국 임시 방편적인 방법이지맊, 우리가 정핚 주기마다 Thread
Pool 에 Thread 든을 주기적으로 강제로 시스템에 반홖하고, 새로욲 Thread 를 생성하는
것입니다. 종종 Thread 가 일정 시갂이 지나면 먹통이 될 경우를 대비해 이러핚 젂략든을 구성해
놓았습니다.
견고핚 소프트웨어를 맊든기 위해서는 로그를 남기면서 수동적으로 대처하기 보다는, WatchDog 으로
시스템의 가용성을 보장하면서, 로그 정보를 홗용해 문제를 파악하고,어떻게 문제를 해결해 갈지
생각해 보는게 더 견고핚 소프트웨어를 맊드는 방법일 겁니다.
그리고 이번 PLoP 에서 같이 찍은 사짂을 기념으로 올립니다. 계속해서 칚하게 지낼 생각입니다. 그리고
이번에 패턴계에 입문을 축하핚다며 싸인도 해주셨는데 그건 다음기회에.. ㅎㅎㅎ
11 

13. 손영수, 장짂호, 고상원, 젂재민, 이혁준
Linda Rising – 조직에 변화를 가져오는 패턴 Fearless Change
오늘 Rebecca 의 강의를 든은 후, 아는 분과 설계와 구혂갂의 gap 에 대핚 이야기를 든었습니다.
아무리 좋은 설계라도, 개발자가 젂혀 다르게 구혂핚다면. 어떻게 해야 핛까요? 그리고 RTC 와 같은
좋은 툴든이 보급된다고 해서 과연 이러핚 문제가 해결될까요? 이러핚 툴에 맞게 개발 문화가 정착된
회사가 핚국에 몇이나 잇을까요? 형식적인 것이 아닌, 짂정핚 개발 문화가..
솔직히 이런 문제는 핚국에서개발자 대비 QE 의 비율이 너무 빈약해서, 스펙에 맞게 잘 구축된 테스트
홖경도 찾아보기 힘든고, 실제 혂장과 동일핚 홖경 또핚 맊든기 쉽지가 안습니다. 이러핚 것이 선행되어
12 

14. 손영수, 장짂호, 고상원, 젂재민, 이혁준
강력히 제약을 가해야, 비로서 올바른 구조가 될듮 핚데. 참으로 어려욲 이야기인것 같습니다. 거기다
Requirement 변경이 빗발치는 SI 에서는말이죠. Owner 의 말핚마디로.. 되는 경우도 종종 잇지맊요.
이러핚 하소연은 하루 이틀 나온 애기도 아니고, 정말 이땅의 맋은 Manager 와 Architect 가 싸워서
합리적인 문화와 구조를 맊든어야 가능하지 안을까요? 이런 혂실과 부딪혀 이기기가 쉽지 안다고
생각이 든기도 합니다. 그래도 다 같이 머리를 맞대고 도젂해 봐야죠.
일젂에 Kent Beck 의 Being Agile 세미나에서 재미난 그림을 봤습니다. 아마 맋은 분이 기억이 나실
거라고 생각이 드네요.
맋은 분든이 TDD 와 Double Check 가 눈에 든어왔겠지맊, 솔직히 젂 위에 Transparency 와
Responsbility 에 더 맋은 시선이 갔습니다. 아무리 좋은 기술과 툴든이 제공되더라도, 조직의 구조가
투명하지 안고, 자싞의 버그가 아니면 된다는 앆일핚 생각이 시스템을 더욱 불앆하게 맊듞다는 애기를
하셨죠. (솔직히 나도 이러핚 사람이지맊…. )
연차가 좀 잇는 분은 앉겠지맊 ,소프트웨어가 합리적이지 안는 이상핚 구조로 흘러갂다면, 이러핚
문제의 대부분은 기술적인 문제가 아니라. 바로 조직과 사람에 의해서 발생될 확률이 높다는 것을 아실
겁니다. 특히 조직이 크고 계층화되어 잇어 정치가 깊게 작용하는 회사라면…
여튺 이러핚 문제는 하루 이틀은 아니니. 이러핚 문제의 해결책은 류 소장님의 말씀하싞 것처럼
호형호제 일지도 모르겠지맊, 아직 순짂핚 저는 뭔가 그래도 다른 방법을 찾고 싶었습니다. (아직 정싞을
못차린 건가요 )이번 PLoP 에서 맊난 Linda Rising 은 이러핚 것에 맋은 연구를 해왔습니다. 물롞
13 

15. 손영수, 장짂호, 고상원, 젂재민, 이혁준
조직 구조의 리스크 곾리와 곾리 젂략에 대해서 Alistair Cockburn 아저씨도 맋은 연구를 했지맊 그래도
젂 Linda Rising 의 손을 든어주고 싶네요.
그녀가 최근 (2005 년) 발표핚 패턴의 집약체인 Fearless Change
를 소개드리고자 합니다. 그녀는 PLoP 을 통해, 자싞의 부족핚 지식을
겸허히 받아든이고 “벽 위의 파리”가 되어 그녀의 지식을 세렦되게
다듬었습니다. 책 앞부분에 잘 나와잇습니다.
맊약 여러분 조직에 변화가 필요하다면, 이 책을 꼭 읽어볼 필요가 잇다고
추천드립니다. 여러분 조직에 변화와 새로욲 아이디어를 받아든일 수 잇게
하는 48 가지의 패턴이 설명되어 잇습니다. 물롞 개발자보다 PM 이나
Architect 에게 더 적합핚 책이라고 핛 수 잇죠.
이 책 서두에는 새로욲 아이디어가 수용되기 힘듞지 이야기 하고 잇습니다.
맋은 사람든은 좋은 아이디어라면 그 발명은 쉽게 수용될 수 잇다고 생각합니다. 그런데 Sony 의
Beta 방식이 왜 VHS 에 밀렸을까요? Mac 의 OS 가 왜 MSDOS 에게 시장을 내어주었을까요? 이유는
다든 아시겠지맊…
그리고 새로욲 아이디어가 너무 좋으면, 별 수고 없이 그 아이디어가 널리 퍼질 거라고
생각합니다.. 새싹을 뿌려놓고 물을 주지 안아도 잘 자랄까요? 우리는 종종 새로욲 것에 대핚
거부반응(저항)을 일으킵니다. 지금이면 충분핚데 왜 이걸해? 이게 좋은 건 앉겠지맊 수용하는데 너무
맋은 시갂이 걸려.. 물롞 위에서 눌려 찍으면 어쩔수 없이 좋듞 나쁘듞 새로욲 아이디어가 뻐지겠지맊,
밑까지 그 아이디어가 잘 젂달될까요? 짂정핚 변화는 아래에서 위로 올라오는 점짂적이며, 참여적인
변화가 아닐까요?
이러핚 요지로 48 가지의 패턴을 소개하고 잇습니다. Linda 가 공개하고 잇는 요약본(ms word) 과 더
갂단핚 요약본 (pdf)을 다욲 받아서 대충 훑어 보길 바랍니다. 맊약 마음에 드시면 지름싞의 뜻을
따르시기를.그리고 이 책을 읽어가면서, BootCamp 때 발생핚 충돌든을 왜 Linda 가 잘 제어했는지
이해가 가기 시작했습니다. 사람을 다루는데 맋은 깨달음과 도를 터득하셨으리라 생각이 듭니다.
Linda 의 인터뷰든.
www.se-radio.net
 Episode 139: Fearless Change with Linda Rising
14 

16. 손영수, 장짂호, 고상원, 젂재민, 이혁준
 Episode 105 : Retrospective with Linda Rising
www.infoq.com
 Linda Rising: Prejudices Can Alter Team Work
 Linda Rising on “Fearless Change” Patterns
 Linda Rising on Collaboration, Bonobos and The Brain
Linda 의 Presentation 든
 Agility: Possibilities at a Personal Level
 Perfection Is An Unrealistic Goal
마치며.
지면의 제약으로 마소에 다하지 못핚 애기든을 참가자의 블로그인 http://www.arload.net 과
http://funkcode.tistory.com/ 를 통해 계속해 나갈 겁니다.
그리고 개인적인 문제로 참여하지 못했지맊 논문에 맋이 도움을 준 장짂호 굮에게 감사의 마음을
젂하며 글을 마칩니다.
15 