PLoP 첫번째 날인 오늘은 매우 재미나고 신나는 하루였습니다.
오늘 말로만 듣던 Writer’s Workshop을 직접 체험한 날이였습니다. 하나는 참가자의 역할로 또 하나는 저자의 역할로 진행을 했습니다. 행사가 시작하기 이전에, PLoP의 대표자들이 모여 진행한 Writer’s Workshop 을 어떻게 진행하는지 설명하는 데모 사진을 찍어보았습니다. 김창준 님이 이미 공개한 내용이지만, 그래도 직접 사진과 보시는게 좋을듯 해서 올려드리도록 하겠습니다.
PLoP에서 참가자는 크게 세 부분으로 나뉩니다. 저자, 참가자, 그리고 행사를 진행하며 조정하는 조정자입니다.
PLoP이 시작 하기 전에, Pre Conference 행사로 BootCamp가 매년 열립니다. BootCamp는 패턴을 올바로 이해하고, 올바른 패턴을 만드는 방법을 전수하기 위한 목적이 있습니다. 위 그림 처럼 패턴을 만들어 보고, 서로간의 의견을 주고 받으면서 점진적으로 패턴을 완성해 나갔습니다.
주제는 자전거 경주에서 승자가 되는 패턴인데. 신선하고 재미있었습니다. 이러한 패턴을 잘 만들기 위한 가이드라인을 알고 있었던 것이지만, 직접 누군가와 같이 애기하면서 패턴을 만들어 나간다는게 흥미로웠습니다. 짧은 영어로 인해 후배녀석한테 물어보면서 눈치껏 듣느라 🙂 고생했지만, 좋은 경험이었습니다. 올바른 패턴을 만들기 위한 Pattern Template을 간략히 요약해 나누어 주셨는데, 나중에 집에가서 스캔해서 올리도록 하겠습니다.
오늘 BootCamp행사 도중 깨달은 몇가지를 나누고자 합니다. PLoP의 정신을 이해하는 행사였다고 봅니다.
여러분!! 인기 있는 Framework를 만들고 싶으신 가요? 저 역시 그렇습니다.
인기 있는 Framework를 만들기 위해 Framework Design Guidelines에서 나온 내용(.NET Framework 설계자인 Krzystof Cwalina의 조언)들을 일부 여러분과 공유하고자 합니다.
- 사용성 테스트
- 점진적인 학습 곡선
- 캡슐화의 오해
이번 포스트에서 다룰 주제는 이렇습니다. 자 그럼 하나씩 살펴 보도록 하죠 🙂
꿈을 찾아 달리는 두 청년을 소개합니다.
아시는 분들은 다 알겠지만요. 워낙 유명해 져서 🙂 바로 이번 Imagine Cup에서 우승을 거머쥔 영웅들 중 두명 (오른쪽 신상, 중간 동훈)입니다. (자세한 정보는 위 링크를 따라 류한석 님의 Smartplace를 방문해 주시면 될듯 합니다.)
사실 작년에 제가 멘토로 Imagine Cup에 같이 참석했지만, 아쉽게 국내 2위로 쓰디 쓴 잔을 마셔야 했습니다. 그때 1위를 했으면 하며 아쉬움이 너무 많았었는데…
저의 아들(동완)이 5월 28일날 수술을 앞두고 있다가, 부득이한 사정으로 연기되었습니다. 집도 하시는 의사분께서 교통사고를 당하셔서, 그만 6월 중순 이후로 수술이 연기되었습니다. 다소 황당한 상황이라고 느껴질수도 있지만, 왜 이런 일이 생겼는지 오히려 저를 자책하게 됩니다. 저의 기도가 부족해서 그런거겠지요. 그리고 여러가지 생각이 드네요 많은 분이 기도해주시고, 걱정해주셔서 너무 감사드립니다. 너무 염치없지만, 여러분의 기도가 필요합니다. 정말 정말 […]
“패턴을 좀더 쉽게 학습하고 실제 프로젝트에 잘 적용할 방법이 없을까요?” 필자가 강의를 마치고 종종 듣는 질문이다. 부족하지만 필자가 공부한 패턴 지식들과 경험들을 합쳐, 독자 여러분에게 패턴을 학습, 활용하기 위한 시행착오를 조금이나마 줄일 수 있는 지름길을 안내하고자 한다.
손 영수 arload@live.com | 데브피아 Architecture 시삽과 Microsoft MVP로 활동 중이며, 데브피아 소프트웨어 공학 스터디인 Eva팀의 리더이다. 부족한 실력이지만 지식을 나눌 때는 누구보다 ‘부자’라는 자부심을 가지고 지식 나눔에 힘쓰고 있다. Pattern 전도사를 꿈꾸고 있으며, PLoP와 같은 Pattern 학회를 국내에 만들기 위해 힘 쏟고 있다.
요즘은 대학교 학부생의 교과 과정으로 들어갈 정도로 패턴은 많은 이들에게 알려져있다.. 하지만 필자 주위에는 패턴을 잘 활용하여, 성공적으로 프로젝트를 마무리 했다거나 좋은 결과를 보았다는 말보다는, 오히려 많은 불신들과 하소연을 들었다. 왜 이런 상황이 발생했을까? 이 글을 통해 독자들이 패턴에 오해를 풀고, 올바른 시선을 가지길 바라며 글을 적는다.
패턴을 대하기 이전에 마음가짐 – 유연성, 확장성
많은 분들과 패턴을 주제로 애기하다 보면, 패턴에 대한 잘못된 관점을 가진 분들을 종종 만난다. 패턴을 통해, 비약적인 성능 향상, 생산성이 증대 될거라 생각하는 분도 있고 심지어 Silver Bullet (은총알)로 생각하는 분도 있다. 물론 제한적인 도메인 안에서 성능, 생산성 향상을 가져 올 수 있는 패턴도 있지만, 패턴 자체의 목적은 유연성과 확장성에 초점을 맞추고 있다.
초창기 객체 지향(80년대)의 가장 중요시 여기는 패러다임은 “Reuse (재사용)” 이였다. 그래서 Component와 같은 이상적인 패러다임이 나오기도 했다. 마치 Lego와 같이 조립만 하면 만들어지는 Legoware를 꿈꾸어 오면서…
하지만 현재 소프트웨어는 어떠한가? 빈번하게 바뀌는 고객의 요구사항, 몇 명 이서 만들 수가 없을 정도로 거대해진 규모, 길어진 소프트웨어 생명주기를 가진 녀석들이 대부분이다. 그렇기 때문에 소프트웨어가 가져야 할 중요한 설계 방향이 재 사용성 보다는 쉽게 변화를 수용할 수 있는 유연성(Flexibility)과 확장성(Extensibility)이 대두되게 되었다. 만약 여러분이 유연성과 확장성에 초점을 맞춘 설계에 관심이 있다면, 패턴은 좋은 도구가 된다. 하지만, 최적화나 성능 개선이 목적이시라면 패턴보다는 알고리즘을 공부하는 것이 더 낫다.
그리고 패턴을 쉽사리 적용하지 못하는 여러 가지 장벽들이 곳곳에 존재한다. 패턴에 대한 불신들이다. 지면상의 제약으로 이 모든 내용을 언급하기가 한계가 있으니 예전에 필자가 마소 2007년 8월호에 기고한 “미워도 다시 보는 패턴 이야기”를 꼭 읽어보길 권한다. 패턴의 정의, 원칙, 참고할만한 설계구조도 설명하고 있다.
많은 분이 기다리셨던 The Productive Programmer가 현재 1차 교정 작업을 마쳤습니다.
(어쩔수 없이 블로깅하게 되네요.. 참 민망합니다. 아무래도 저의 사적인 일이 아니니, 이해해 주시길 부탁드립니다. 🙂 )
지식 공유와 큰 열정을 가지시고 번역관련 개론 서적까지 읽으시면서 고생해 주신 김현수 님 덕분에 드디어 이 서적이 한국에 나오네요.
좋은 서적이 국내에 나오게 되어 너무 기쁩니다.
김 현수님이 베타리더를 모으고 직접 베타리더 분들과 대화를 나누는게 맞지만, 현재 호주로 이민을 가셔서 부득이하게 제가 베타리더를 모으고, 가교의 역할을 하고자 합니다.
사실 번역 거리를 제가 현수님에게 드려서, 책임감을 가지고 할수밖에 없네요.
에전 More Joel on Software에서 많은 분이 참여해 주신것 처럼, 이번에도 활발한 신청 부탁드립니다.
제가 이글을 쓴 이유는 저의 아이디와 패턴의 남용에 대해서 같이 언급하셔서, 큰 상처를 받았습니다. 제가 패턴쪽으로 많은 활동을 하고 있었는데요.
직접 대화를 나누어 오해를 풀었습니다.
저를 향한 글인줄 알았습니다. 직접 대화를 통해 그것이 아니었음을 알았습니다. 제가 너무 민감하게 대했던것 같습니다.
toby님에게 모욕을 당했다는 말은 정중히 사과하겠습니다.
다행히 toby님과 대화는 매우 산뜻하게 끝나고, 심지어 여러가지 mission을 주셨습니다. 🙂
이번 논쟁은 결국 몇분이 말씀해주신것 처럼, 각자가 느낀 도메인의 경험의 차이 그리고 생각의 차이라고 이해해 주셨으면 합니다.
디키 님의 말처럼 반론을 다는것 보다는 다시 저의 의견을 말씀 드리는 것이 올바른 글쓰기라고 생각하여 다시 글을 씁니다.
Ripple Effect (파문효과)에 대한 생각들..
SoC 에대한 애기를 그만두길 원했으나, 영회님이 또 글을 포스팅 하셔서 저의 생각을 적습니다. 일단 잠이 오지 않습니다. 🙂 누워도 누워서 잘려고 해도 계속 마음이 아파옵니다.
일단 SoC 애대한 애기는 어느 정도 마무리 해야 될듯 합니다. 더 글을 적는다고 해도. 참 이게 소모적인 논쟁만 될까하고 생각이 듭니다.
영회님이 적은포스트 입니다. SoC – Separation is not components.
이 글을 보면 저의 의견과 약간 대치 됩니다. Concern이라는 것은 Component가 될수도 있고 아닐수도 있습니다.
Component라는 단어에 대한 정의를 무얼로 보느냐에 중요하겠죠. 솔직히 말해서 Separation의 단위를 배포의 문제가 중요시 되는 경우 얼마든지 Component 단위로 볼수가 있다는 것이 저의 생각입니다.
.NET Framework Design Guidelines에 언급한 것처럼, Component를 하나의 진화되는 유닛 (a evolving unit)으로 정한 경우죠.
그리고 Separation에 영향을 미치는 Concern들은 결국 그 프로젝트에서 가장 적합한 요소들이 상호 균형을 맞추어 정해진다고 봅니다.
그게 생각의 범위든, 부하의 분리든, 배포의 문제든 기타 등등.
저 같은 경우는 배포가 중요시 되기 때문입니다. Robert C. Martin의 Principles of Package Architecture가 제가 하고 있는 프로젝트와는 밀접한 관련이 있기 때문입니다.
많은 사람들은 자신이 가진 것을 놓지 않을려고 합니다.
계속해서 갖기 위해서 싸우고, 서로를 짖밟는 세상이 된거 같습니다.
전 너무나 욕심이 많았던것 같습니다.
데브피아의 시삽, Microsoft MVP, EvaCast의 리더, 저의 수많은 글들 ….
이제 좀 비울때가 온거 같습니다.
가지고 있는것을 비우지 않으면, 성장할 수 없음을 잘 알기에…
당분간 번역과 집필활동에 전념하겠습니다. 마음이 정리되면 돌아오겠습니다…
Architecture 101 