저희 Eva팀이 드디어 두 번째 프로젝트인 “97 things every software architect should know (가제 – 모든 아키텍트라면 알아야 할 97가지 이야기)” 에 대한 1차 번역을 마쳤습니다.
2 달만에 번역하기 프로젝트를 시도했지만, 예상외로 아키텍트 특유의 고급적인 문체, 시와 같이 운율을 살리는 비유, 해당 도메인의 지식 부재등으로 약간의 난전을 겪었습니다.
그래서 3달 만에 1차 번역이 마치게 되었네요. 내부적으로 1차 리뷰를 마치고 출판사에 맡겼지만 아직 손봐야 할 것이 여러군 데 있는 건 사실입니다. 어느정도 책의 형태가 나오면 베타리더를 모아 더 다듬어야 겠죠.
둘 중 하나를 선택해야 한다면. 대부분의 사람들은 해야 될 가장 중요한 것을 선택합니다. 하지만,설계(소프트웨어 또는 다른 것들)에서는 그렇지 않습니다. 두 가지 선택사항의 존재는 당신이 설계 시 불확실성을 고려할 필요가 있다는 것은 알려주는 지표(indicator)입니다.
불확실성을 가능한 마지막 순간에 설계에 자세한 부분(defer commitment[1])을 결정할지, 설계 결정들의 중요성을 감소시키기 위해 분할하고 추상화할지 결정하는 기준으로 이용하십시오. 만약 당신의 마음을 첫 번째(가능한 나중에 결정하는 것 – defer commitment)에 고정시킨다면 이 첫 번째 원칙에 갇히고 종속될 수 있습니다. 그 결과 부수적인 결정이 굉장히 중요해 지고 소프트웨어의 유연성이 줄어듭니다..
아키텍쳐에 있어서 가장 간단하고 구조적인 정의중 하나는 Grady Booch의 말에서 인용됩니다.
“모든 아키텍쳐는 설계지만 모든 설계가 아키텍쳐는 아니다. 아키텍쳐는 시스템을 구체화하는 중요한 설계 결정들을 나타낸다. 여기서 중요한 것은 변화의 비용에 의해서 측정된다.”
이 정의에 따르면 효과적인 아키텍쳐는 일반적으로 설계 결정의 중요성을 감소시키는 것입니다. 비효율적인 아키텍쳐는 설계 결정의 중요성을 확대시킵니다. 설계 결정이 합리적으로 두 가지 방법 중 하나로 진행될 수 있다면, 아키텍트는 한 걸음 물러설 필요가 있습니다.
Fearless Change를 읽으면서 여러가지 생각할 거리를 많이 얻었습니다. 그리고 좋은 아키텍팅을 하기 위해선, 기술 못지않게, 다른 부분(조직 구조, 협력, 대화법등..)도 중요하다는 것을 더욱 알게해주며, 저의 예전과 현재의 모습을 바라볼 수 있는 서적이기 때문입니다.
세계에서 내놓아라는 유명 컨설턴트와 1년 같이 프로젝트도 진행해 보고, 국내의 유명 컨설턴트와도 차기 버젼을 개발했을때 느꼈던 점은 컨설턴트가 자신의 생각을 관철하려고 하지, 정작 우리 개발자의 이해나 생각을 많이 물어보지 않으려고 했다는 겁니다. 마치 자기가 새로 정립한 이론을 테스트하기에 급급하지 않았나 생각이 들더군요.
전 이해를 구하는 컨설턴트를 만나고 싶었습니다. 하지만 대부분이 그렇지 않더라구요. 그리고 이 책을 읽으면서, 왜 짧은 시간에는 위에서 아래로 변화를 내려찍는 방식을 취할 수 밖에 없었는지 알게되었습니다. 시간이 없다 보니 점진적이면서 모두를 변화시킬수 있는 Bottom-Up 보다는, 내려찍는 Top-Down 방식이 진행될 수 밖에 없고, 조직 구조도 상명 하복을 잘 받아들이수 있게 계층화되어 있다는 것이지요. 관리자 입장에서는 강점이지만, 아래있는 사람들이 주체적으로 변화의 주역이 되기는 힘든 구조라고 생각이 듭니다.
지하철에서 1장을 읽으면서 연습장에 쓱싹 쓱싹 정리해 봤습니다. Fearless Change 에서 조직를 어떻게 변화해야 하는지 큰 명분(motivation)을 내세우는 장이라고 할수 있습니다. 왜 변화가 어려운지 설명하는 장이지요. 하나 하나 세밀하게 다 설명 드리고 싶지만, 아무래도 제가 느낀 감동은 다 말로하긴 힘들듯 합니다. 전 큰 핵심만 전달해 드려야 될 듯 하네요.
저와 같이 PLoP을 참여한 고 상원 군이 저와 는 다르게 저자 워크샾을 지켜 보았다고 합니다.
더 나은 저자 워크샵 진행 방법을 만들기 위해 참가자와 조정자의 진행 방식등을 분석했다고 합니다. 파리(저자)의 또 다른 시선이니 저자 워크샵을 진행하시는 분은 참고하시면 도움이 될듯 합니다.
아래의 메세지는 고상원 군의 포스트인 “저자 워크샾에 대한 관찰”에서 가져왔습니다. 참고하시길 바랍니다.
고상원 군 says…
얼마 전, 또 한번의 저자 워크샵을 가졌습니다. 이번엔 논문 내용에 대한 것보다 저자 워크샵 자체에 포커스를 맞춰서 메모를 했습니다. 저자 워크샵을 도입하려면 어떻게 반응하고, 어떤 문제점을 가지는지 고민할 필요가 있다고 생각했기 때문입니다.
오늘 Rebecca의 강의를 들은 후, 아는 분과 설계와 구현간의 gap에 대한 이야기를 들었습니다.
아무리 좋은 설계라도, 개발자가 전혀 다르게 구현한다면. 어떻게 해야 할까요? 그리고 RTC와 같은 좋은 툴들이 보급된다고 해서 과연 이러한 문제가 해결될까요? 이러한 툴에 맞게 개발 문화가 정착된 회사가 한국에 몇이나 있을까요? 형식적인 것이 아닌, 진정한 개발 문화가..
솔직히 이런 문제는 한국에서개발자 대비 QE의 비율이 너무 빈약해서, 스펙에 맞게 잘 구축된 테스트 환경도 찾아보기 힘들고, 실제 현장과 동일한 환경 또한 만들기 쉽지가 않습니다. 이러한 것이 선행되어 강력히 제약을 가해야, 비로서 올바른 구조가 될듯 한데. 참으로 어려운 이야기인것 같습니다. 거기다 Requirement 변경이 빗발치는 SI에서는말이죠. Owner의 말한마디로.. 되는 경우도 종종 있지만요.
이러한 하소연은 하루 이틀 나온 애기도 아니고, 정말 이땅의 많은 Manager와 Architect가 싸워서 합리적인 문화와 구조를 만들어야 가능하지 않을까요? 이런 현실과 부딪혀 이기기가 쉽지 않다고 생각이 들기도 합니다. 그래도 다 같이 머리를 맞대고 도전해 봐야죠.
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 교수님 정말 감사합니다.
이걸 참고하셔서 좀더 피드백을 주시거나, 아래의 리스트와 다른 새로운 피드백을 주시면 감사하겠습니다.
저자 워크샾을 벽위의 파리 (저자) 입장에서 보았을 때의 느낌을 공유합니다.
회고로 보시면 좋을듯 합니다. 저자 워크샾( Writer’s Workshop) 진행 방식은 바로 이전 포스트인 저자 워크샾 Demo를 보시길 바랍니다.
저희 그룹의 좌장은 GoF의 Ralph Johnson이 였으며, 조정자(Moderator) 역할을 해주셨습니다. BootCamp때 진행한 Linda 아주머니와는 약간 다른 진행방식을 취했습니다. Rinda 같은 경우는 끊임없이 서로의 의견을 주고 받으며, 적절히 시간 조절을 잘 해주었는데, Ralph Johnson 박사님은 토론을 좋아하는 분이신지라 🙂 거기에 깊게 뛰어든 나머지,조정자 의 중요한 역할 중 하나인 시간 배분을 잘못해서, 저희 Pattern 뒷 부분을 다루지 못하게 되었습니다. 상당히 아쉽더군요 …
사실 저자 워크샾에 참석하기 전에 패턴을 정독해서 읽어가야 하지만, 몇몇 참가자들이 패턴을 읽지 않고 왔습니다. 그래서 Implementation 부분에 다루는 애기들을 앞에서 많이 하는 경향이 보이더라구요. 저자 워크샾을 참석하는 참가자들은 꼭 논문을 사전에 정독하시길 권해드립니다.
그래도 많은 피드백을 받았기 때문에, 이 부분도 수정을 하고 저희 스터디 그룹과 같이 MiniPLoP 형태로 진행해서 남은 부분을 보완할 생각입니다.
Architecture 101 