제 2회 아키텍트 Summit에 발표 자료입니다. 아키텍트에 ‘아’짜도 따라가지 못하는 저가, 우여 곡절 속에 수많은 쟁쟁한 분과 함게 발표를 맡게 되었습니다.
다른 쟁쟁한 아키텍트 분들에게 누가 되지 않았길 바라며, 발표를 준비했습니다. 주제는 패턴과 EA의 활용에 대해서 간략히 언급해 드렸습니다.
로마인의 세계에서, 야누스는 시작과 끝, 문과 통로의 신입니다. 야누스는 다른 방향의 바라보는 두 개의 머리로 보통 묘사되며, 영화나 동전에서 볼 수 있는 상징입니다. 야누스는 전환과 변화를 나타냅니다. 우리의 삶에서 예를 든다면 과거에서 미래로, 젊음에서 늙음, 결혼, 탄생, 시대의 도래와 같은 것이 있습니다.
소프트웨어 또는 건축물이든 어떤 아키텍트도, 앞과 뒤로, 과거에서 미래로 볼 수 있는 야누스의 능력은 꼭 필요한 능력입니다. 아키텍트는 비전과 현실, 향후 방향과 과거의 성공, 개발 제약과 사업/관리 기대치를 융합하기 위해 노력합니다.
이러한 (간극을 메우는) 다리를 만드는 것은 아키텍트의 중요한 역할입니다. 종종 아키텍트는 프로젝트를 완성하기 까지, 프로젝트에 영향을 미치는 다른 영향력들(예를 들어 접근 용이성 vs 보안, 경영의 미래 비전을 설계하면서 현재 비지니스 프로세스를 만족시키는 것)이 발생시키는 간극을 극복하기 위해 노력할 때, 희로애락을 느끼기도 합니다.
다양한 프로젝트의 이해당사자를 만족시킬 수 있는 소프트웨어(product)를 만들기 위하여, 좋은 아키텍트는 두 가지의 다른 아이디어나 생각, 다른 목표와 비전을 처리할 수 잇는 두 개의 머리를 가져야만 합니다. 아키텍트인 당신은 단순히 두 개의 얼굴이 아닌, 야누스가 가진 두 개의 머리를 주의 깊게 보아야 합니다. 훌륭한 IT 아키텍트는 뛰어난 경청 자[1] 이자 평가자 이어야 합니다.
넬슨 제독이 1805년 트라팔가에서 프랑스와 스페인 함대를 격파한 이후, “분할 후 정복(Divide and Conquer)”은 복잡하고 어려운 문제를 다루는 슬로건(상징)이 되었습니다. 동일한 의미를 가지는 좀더 친숙한 용어로 “걱정 거리의 분리 (Separation of Concern)”가 있습니다.
걱정 거리의 분리로부터 우리는 캡슐화를 얻게 되고, 캡슐화로부터 우리는 경계와 인터페이스를 얻게 됩니다.
아키텍트의 관점에서, 가장 어려운 부분은 동작하는 시스템을 구축하기 위해 필요한 적당한 인터페이스를 정의하고, 경계를 정하는 자연스러운 위치를 찾는 것입니다.
이것은 거대한 엔터프라이즈 시스템에서는 특히 어려운 일입니다. 이런 상황에서, “결합도는 낮추고, 응집도는 높여라”와 “정보 교환이 자주 발생하는 영역들은 나누지 말아라”와 같은 오래된 명언이 몇 가지 지침을 제공합니다. 하지만 명언들은 어떻게 쉬운 방법으로 이해당사자들에게 가능성 있는 해결방안과 문제들을 대해 소통할 수 있는지 알려주지 않습니다.
닐 스티븐슨의 소설인 크립토노미콘[1]에서, 랜디 워터하우스(Randy Waterhouse)는 자신이 만나는다양한 사람들의 유형에 빚대어 자신의 분류 시스템을 설명했습니다.
드워프[2]는 근면한 일꾼으로, 동굴속의 어두운 고독속에서 꾸준히 아름다운 산출물을 생산합니다. 드워프의 장인 정신은 정평이 나있으며, 산을 움직이고, 지구를 형성하는 엄청난 힘을 발휘 합니다.
엘프는 우아하며, 교양 있고, 하루를 새롭고 아름다운 마법을 만들면서 보냅니다. 엘프는 매우 천부적인 재능을 가지고 있어, 다른 종족이라면 실현할 수 없는 마술들을 거의 초자연적인 힘으로 생각해냅니다.
마법사는 다른 종족과 달리 거의 완벽하고 대단히 강력한 종족입니다. 하지만 엘프와는 다릅니다.마법사는 마법, 마법의 힘, 마법의 본질에 대해서 알고 있으며, 놀라운 광경과 함께 마법을 부립니다.
하지만 워터하우스가 특별히 언급하지 않은 네번째 타입의 캐릭터가 있습니다. 바로 왕입니다, 이들은 다른 종족들과 함께 무엇을 해야 할지를 아는, 몽상가(비젼을 제시하는 자)입니다.
안녕하세요 🙂 일전에 약속한 대로 여러가지 패턴 이야기들을 가져 왔습니다!!
사실 이미 많은 분이 접하셨을 겁니다. 바로 마소 5월호에 저희 스터디 팀이 Cover Story를 기고했는데요 그 내용들입니다.
처음 기고를 하신 분들도 있고, 아닌 분도 있지만 모두에게 좋은 경험이 되었다고 생각이 듭니다. 저 역시 저희 커뮤니티 맴버들이 뭉쳐서 이런 좋은 글을 만들었다는 것이 매우 큰 기쁨으로 느껴집니다.
사실 커뮤니티를 운영하면서 가장 만족감을 느끼는 것은, 서로에게 성장할 수 있는 경험과 기회를 주고 나누는 것이죠. 그리고 같이 성장해 가는 것을 보고 느낄때 기쁨은 이루 말할수 없습니다.
이 것이 제가 생각하는 커뮤니티의 올바른 모습이며, 앞으로도 잘 유지될 수 있도록 노력하겠습니다. 🙂 그럼 이번에 저희 EVA 팀이 기고한 글들을 차례대로 간략히 소개하겠습니다.
하나의 시스템은 독립적인 프로그램들로 구성됩니다.
우리는 프로그램들과 이들 프로그램들과의 관계를 정리하는 것을 아키텍쳐라고 부릅니다.
이들 시스템들의 다이어그램을 그릴 때, 종종 개개의 프로그램들과 서버들을 간략하고 조그만 사각형들로, 연결 관계들을 화살표들로 표현합니다.
“HTTP를 통신하는 SOAP-XML을 사용한 동기화/비동기 요청/응답”을 의미하는 하나의 화살표가 있습니다. 단 하나의 그림 문자가 표현하기에는 너무나 많은 정보를 가지고 있습니다. 이러한 모든 것을 표현하기에는 충분한 공간이 없습니다.
그래서 우리는 화살표 위에 내부적인 관점으로는 “XML over HTTP (HTTP 기반의 XML)”, 외부적인 관점으로는 “SKU[1] Lookup”[2] (재고 검색)라고 이름을 붙입니다.
프로그램들을 연결하는 화살표는 직접적으로 프로그램들과 통신하는 것 같아 보이지만, 사실은 그렇지 않습니다. 박스들 사이에 하얀 공백들은 하드웨어와 소프트웨어 컴포넌트들로 가득 채워져 있습니다.
어떤 전문직이든, 전문용어를 사용합니다. 그러므로 같은 전문직에 종사하는 사람들끼리 효율적으로 대화할수 있습니다.
법조인은 인신 보호 영장 (habeas corpus), 예비 심문 (voir dire), 배심원 (venire)에 관해 다른 사람에게 말합니다.
마찬가지로 목수는 맞댐이음 (butt joint), 겹 이음 (lap joint), 플럭스[1] 에 관해 다른 사람에게 말합니다.
그리고 소프트웨어 아키텍트는 ROA(Resource-Oriented Architecture), 2 Step Views[2], 레이어 슈퍼타입[3]에 관해 다른 사람에게 말합니다.
잠시만요! 뭘 이야기 할려는 거죠?
소프트웨어 아키텍트에게 전문용어의 사용은 필수적인 것입니다. 아키텍트가 사용하는 플랫폼에 상관없이, 전문용어는 다른 이들과 대화하는 효율적인 수단입니다.
의사소통(communication)의 이러한 수단들 중에 하나가 아키텍처와 디자인 패턴들입니다. 유능한 아키텍트가 되기 위해서는, 반드시 기본이 되는 아키텍처와 디자인 패턴들을 이해하고, 언제 사용되고,적용할지 알아야 합니다. 그리고 다른 아키텍트/ 개발자와 대화하기 위해 패턴을 사용할 수 있어야 합니다.
이번 제 1회 닷넷 커뮤니티 컨퍼런스에 발표한 TP 자료를 많은 분이 요청하셔서 부득이하게 공유합니다.
- 패턴의 정의
- 패턴에 대한 오해와 진실
- 패턴으로 가는 길
- 패턴 빌드 오더
- 패턴 + 생산성 두마리의 토끼 잡기
제가 이글을 쓴 이유는 저의 아이디와 패턴의 남용에 대해서 같이 언급하셔서, 큰 상처를 받았습니다. 제가 패턴쪽으로 많은 활동을 하고 있었는데요.
직접 대화를 나누어 오해를 풀었습니다.
저를 향한 글인줄 알았습니다. 직접 대화를 통해 그것이 아니었음을 알았습니다. 제가 너무 민감하게 대했던것 같습니다.
toby님에게 모욕을 당했다는 말은 정중히 사과하겠습니다.
다행히 toby님과 대화는 매우 산뜻하게 끝나고, 심지어 여러가지 mission을 주셨습니다. 🙂
이번 논쟁은 결국 몇분이 말씀해주신것 처럼, 각자가 느낀 도메인의 경험의 차이 그리고 생각의 차이라고 이해해 주셨으면 합니다.
디키 님의 말처럼 반론을 다는것 보다는 다시 저의 의견을 말씀 드리는 것이 올바른 글쓰기라고 생각하여 다시 글을 씁니다.
Ripple Effect (파문효과)에 대한 생각들..
SoC와 복잡성에 대한 고찰..
전 왜 이런 소리(Toby님, 안영회님) 를 들어야 할지 모르겠네요. 일단 전 문제 그 자체에 집중해서 포스팅 하겠습니다. 🙂
복잡성(Complexity) 에 대한 생각들..
먼저 Complex (복잡하다)에 대한 명확한 정의를 내리고자 합니다.
어원적으로 보면 Com(Together) + Ple (Tie , Bind) 의 의미로 구성되어 있습니다. 여러개가 묶여 있는 것을 복잡하다고 말을 합니다. 그것이 서로 얽히고 섥혀 있으면 복잡하다는 것이지요. 결국 복잡의 의미는 Toby님과의 말에 별 의견이 없습니다.
우리가 느끼는 복잡성(Complexity)를 숨길 수는 있어도 결코 사라지지는 않는 다는 것입니다. 누군가는 떠 안아야 된다는 거지요..
우리가 심플함의 대명사로 말하는 Apple 제품이 기존 타사 제품의 복잡함과 비교 설명할 때 자주 보여지는 그림이 한 장 있습니다.
Architecture 101 