모든 소프트웨어 아키텍트들은 모든 것을 가질 수 없다는 것을 알고 이해해야 합니다. 높은 성능, 높은 가용성, 고 수준의 보안 그리고 고 수준의 추상화 모두를 동시에 충족하는 아키텍쳐를 설계하는 것은 사실상 불가능합니다.
소프트웨어 아키텍트들이 알아야만 하고, 이해해야 하는, 그리고 고객, 동료와 함께 대화를 나누어야 하는 진실된 이야기가 있습니다.
이 이야기는 Vasa라 불리는 배 이야기입니다. 1620년대에 스웨덴과 폴란드 사이에 전쟁이 발생했습니다. 스웨덴 국왕은 비용이 많이 드는 전쟁을 빨리 끝내고 싶었고, vasa라 불리는 배를 건조[1]할 것을 명령하였습니다. 이 순간부터, 이 배는 더 이상 평범한 배가 될 수 없었습니다.
이 배가 갖춰야 했던 조건(요구사항)들은 그 당시의 어떤 배와도 비교할 수 없었습니다: 선체가 200피트 정도 더 길고, 2개의 갑판에 64개의 총을 적재할 수 있고, 300명의 군사를 안전하게 태워 폴란드로 가는 바다를 가로지를 수 있는 수송 능력을 가져야 했습니다. 배를 건조하는 데드라인(시간)을 엄수해야 했으며, 재정(자금)적으로도 여유롭지 않았습니다.
이번 PLoP 에서 프린터로 받은 Pattern Template을 번역해서 올립니다.
기존 Pattern Template에 달리 추가된 내용이 Resulting Context/Side Effects 입니다. 지금까지 패턴들은 장점만 너무 기술한 경향이 있는데. 이제 이 패턴을 적용할 경우 발생하는 Side-Effect도 기술하길 권하고 있습니다.
영어 원문을 그대로 번역한 것이라. 약간 매끄럽지도 않을 수도 있습니다. 🙂
PLoP 첫번째 날인 오늘은 매우 재미나고 신나는 하루였습니다.
오늘 말로만 듣던 Writer’s Workshop을 직접 체험한 날이였습니다. 하나는 참가자의 역할로 또 하나는 저자의 역할로 진행을 했습니다. 행사가 시작하기 이전에, PLoP의 대표자들이 모여 진행한 Writer’s Workshop 을 어떻게 진행하는지 설명하는 데모 사진을 찍어보았습니다. 김창준 님이 이미 공개한 내용이지만, 그래도 직접 사진과 보시는게 좋을듯 해서 올려드리도록 하겠습니다.
PLoP에서 참가자는 크게 세 부분으로 나뉩니다. 저자, 참가자, 그리고 행사를 진행하며 조정하는 조정자입니다.
PLoP이 시작 하기 전에, Pre Conference 행사로 BootCamp가 매년 열립니다. BootCamp는 패턴을 올바로 이해하고, 올바른 패턴을 만드는 방법을 전수하기 위한 목적이 있습니다. 위 그림 처럼 패턴을 만들어 보고, 서로간의 의견을 주고 받으면서 점진적으로 패턴을 완성해 나갔습니다.
주제는 자전거 경주에서 승자가 되는 패턴인데. 신선하고 재미있었습니다. 이러한 패턴을 잘 만들기 위한 가이드라인을 알고 있었던 것이지만, 직접 누군가와 같이 애기하면서 패턴을 만들어 나간다는게 흥미로웠습니다. 짧은 영어로 인해 후배녀석한테 물어보면서 눈치껏 듣느라 🙂 고생했지만, 좋은 경험이었습니다. 올바른 패턴을 만들기 위한 Pattern Template을 간략히 요약해 나누어 주셨는데, 나중에 집에가서 스캔해서 올리도록 하겠습니다.
오늘 BootCamp행사 도중 깨달은 몇가지를 나누고자 합니다. PLoP의 정신을 이해하는 행사였다고 봅니다.
PLoP에 참여하기 위해 드디어 시카고로 갑니다. 꿈꿔왔던 일을 하나 하러 가네요 :).
행사 중간 중간 사진을 찍어가면서, 경험했던 내용들을 여러분하고 공유하도록 힘쓰겠습니다.
굳이 이 분이 누군지 말 안해도 다들 아실겁니다. 🙂 바로 Grady Booch 입니다. UML을 탄생시킨 3인방 중에 한명이며, 지금의 소프트웨어 공학에 지대한 영향을 끼치신 분이죠 .
Grady Booch의 끊임없는 지적 호기심을 보여주는 좋은 사이트가 있어서 소개합니다.
바로 Handbook of Software Architecture 라는 사이트 입니다. 아마 아실 분은 다 아시겠죠 :). 여기에 Pattern들에 대한 보물이 숨겨져 있습니다.
바로 지구상에 발표된 패턴들을 잘 요약해 놓고, 적절하게 다양한 관점으로 분류하고 잘 요약정리해 놓았습니다. 단순히 GoF, POSA, PLoP 에 나온 분류 보다 훨씬 자세하게 잘 분류되어 있고, 지구상에 많은 패턴을 끊임없이 요약 정리하고 계시다니.. 대단하시네요. 저도 나름대로 분류 작업을 진행해야 겠네요 🙂
Design Patterns의 GoF중 한 사람이자, Framework의 대가인 Ralph Johnson이 내한 합니다.
이번 방문과 함께, Korea Spirng User Group의 안영회님께서 수고해 주셔서 세미나를 여시네요.
비록 5만원의 유료 세미나지만, Ralph Johnson과의 점심 시간도 가질 수 있고, 세미나 정보도 알차니, 참여하시면 매우 값진 것들을 얻으리라 믿습니다.
관심 있는 분은 꼭 참여하셔서 Ralph Johnson의 경험과 지식을 얻어가시길 바랍니다. 자세한 정보는 안영회님에게 요청해주세요!
건축가에 배워야 하는 교훈들을 여러분과 공유하고자 합니다.
“아키텍쳐는 사회적 행동과 인간 활동의 중요한 극장이다. — Spiro Kostof”
명시적, 주도적, 기술적으로 자신의 배역(역할)을 아는 아키텍트가 얼마나 있을까요? 오히려 소프트웨어 아키텍트는 이해 당사자 (stake-holders) 사이에서, 서로 의견이 충돌이 발생하는 파벌들의 중재인, 중개인, 조정자 이지 않을까요?
소프트웨어 아키텍트의 일 중 인적 요소(human-factor)에 적절한 가중치를 부여하지[1] 않고, 순수하게 지적인 정신(소프트웨어 설계)을 요구하는 일이 얼마나 있을까요?
위대한 아키텍트는 머리가 아니라 노력과 풍요로운 마음으로 만들어진다. — Frank Lloyd Wright
여러분 조직에서, 아키텍트 선발 기준은 무엇입니까? 순수한 지적인 능력, 유사한 문제를 겪어봤고, 문제를 간단하게 정리하고(정제), 기술적으로 상세부분까지 기억해 내는 방대한 지식 또는 경험, 그리고 너그러운 마음? 당신은 어떤 분위기에서 일 하는 것이 좋은 가요?
일반적으로 알고 있는 것 과 달리, Namespace의 주 목적은 같은 이름을 가진 타입들의 충돌을 해결하고자 하는 것이 아니다
Namespace의 주 목적은 응집력 있고, 쉽게 찾을수 있으며, 쉽게 이해할 수 있는 계층구조로 타입들을 구성하는 것이다.
하나의 프레임워크 안에 타입 이름의 충돌은 조잡한 디자인을 나타낸다고 생각한다.
동일한 이름을 가진 타입들은 더 나은 통합을 위해 라이브러리의 특정 부분들을 합치거나, 코드의 읽기와 검색을 향상시키기 위해서 새로운 이름을 할당하는 것이 좋다.
출처 – Framework Design Guidelines 2nd Edition.
오늘날의 시스템은 분산되어 있고, 느슨하게 결합되어 있습니다. 느슨하게 결합된 시스템을 구축하는 것은 조금 귀찮은 작업입니다., 우리는 왜 이런 귀찮은 작업을 해야 될까요? 우리는 조그만 변화로 시스템들이 산산이 부서지는 것을 원하지 않기 때문에, 우리의 시스템들이 (변화에) 유연하길 원합니다.
오늘날의 환경에서 유연함은 매우 중요한 자산입니다. 여기서 우리는 어플리케이션의 작은 부분만을 제어할 수 있습니다. 분산 서비스나 써드-파티 패키지들에서 작동하는 나머지 부분들은 다른 부분이나 외부 밴더 들에 의해 제어됩니다.
그래서, 변화에 유연하고 시간이 흐름에 따라 진화할 수 있게 시스템을 구축하는 것은 좋은 노력처럼 보입니다. 하지만, 이것은 우리의 시스템이 시간이 흘러감에 따라 변할 수 있음을 의미합니다. “오늘날의 시스템은 더 이상 어제의 시스템이 아니다.” 라는 것처럼..
불행하게도, 변화는 문서화하는 것도 어렵게 만듭니다. 항상 변경되는 시스템에서는, 문서가 프린터 되는 순간 그 문서는 구식으로 되어 버리고, 이러한 상황들이 심해질 수 있습니다. 게다가, 일반적으로 유연하게 시스템을 구축 하는 것은 아키텍쳐가 좀더 복잡해 지는 것을 의미하며, 잘 알려진 “Big Picture (큰 그림)”[1]을 얻기 어렵습니다.
예를 들어 만약 모든 시스템의 컴포넌트들이 꼭 설정 가능한 채널을 통해 다른 구성요소들과 통신을 한다면, 컴포넌트들은 어떤 행위를 (무엇을 해야) 할지에 대한 정보를 얻기 위하여 채널 설정부만 바라보면 됩니다.
Architecture 101 