건축가에 배워야 하는 교훈들을 여러분과 공유하고자 합니다.
“아키텍쳐는 사회적 행동과 인간 활동의 중요한 극장이다. — Spiro Kostof”
명시적, 주도적, 기술적으로 자신의 배역(역할)을 아는 아키텍트가 얼마나 있을까요? 오히려 소프트웨어 아키텍트는 이해 당사자 (stake-holders) 사이에서, 서로 의견이 충돌이 발생하는 파벌들의 중재인, 중개인, 조정자 이지 않을까요?
소프트웨어 아키텍트의 일 중 인적 요소(human-factor)에 적절한 가중치를 부여하지[1] 않고, 순수하게 지적인 정신(소프트웨어 설계)을 요구하는 일이 얼마나 있을까요?
위대한 아키텍트는 머리가 아니라 노력과 풍요로운 마음으로 만들어진다. — Frank Lloyd Wright
여러분 조직에서, 아키텍트 선발 기준은 무엇입니까? 순수한 지적인 능력, 유사한 문제를 겪어봤고, 문제를 간단하게 정리하고(정제), 기술적으로 상세부분까지 기억해 내는 방대한 지식 또는 경험, 그리고 너그러운 마음? 당신은 어떤 분위기에서 일 하는 것이 좋은 가요?
일반적으로 알고 있는 것 과 달리, Namespace의 주 목적은 같은 이름을 가진 타입들의 충돌을 해결하고자 하는 것이 아니다
Namespace의 주 목적은 응집력 있고, 쉽게 찾을수 있으며, 쉽게 이해할 수 있는 계층구조로 타입들을 구성하는 것이다.
하나의 프레임워크 안에 타입 이름의 충돌은 조잡한 디자인을 나타낸다고 생각한다.
동일한 이름을 가진 타입들은 더 나은 통합을 위해 라이브러리의 특정 부분들을 합치거나, 코드의 읽기와 검색을 향상시키기 위해서 새로운 이름을 할당하는 것이 좋다.
출처 – Framework Design Guidelines 2nd Edition.
오늘날의 시스템은 분산되어 있고, 느슨하게 결합되어 있습니다. 느슨하게 결합된 시스템을 구축하는 것은 조금 귀찮은 작업입니다., 우리는 왜 이런 귀찮은 작업을 해야 될까요? 우리는 조그만 변화로 시스템들이 산산이 부서지는 것을 원하지 않기 때문에, 우리의 시스템들이 (변화에) 유연하길 원합니다.
오늘날의 환경에서 유연함은 매우 중요한 자산입니다. 여기서 우리는 어플리케이션의 작은 부분만을 제어할 수 있습니다. 분산 서비스나 써드-파티 패키지들에서 작동하는 나머지 부분들은 다른 부분이나 외부 밴더 들에 의해 제어됩니다.
그래서, 변화에 유연하고 시간이 흐름에 따라 진화할 수 있게 시스템을 구축하는 것은 좋은 노력처럼 보입니다. 하지만, 이것은 우리의 시스템이 시간이 흘러감에 따라 변할 수 있음을 의미합니다. “오늘날의 시스템은 더 이상 어제의 시스템이 아니다.” 라는 것처럼..
불행하게도, 변화는 문서화하는 것도 어렵게 만듭니다. 항상 변경되는 시스템에서는, 문서가 프린터 되는 순간 그 문서는 구식으로 되어 버리고, 이러한 상황들이 심해질 수 있습니다. 게다가, 일반적으로 유연하게 시스템을 구축 하는 것은 아키텍쳐가 좀더 복잡해 지는 것을 의미하며, 잘 알려진 “Big Picture (큰 그림)”[1]을 얻기 어렵습니다.
예를 들어 만약 모든 시스템의 컴포넌트들이 꼭 설정 가능한 채널을 통해 다른 구성요소들과 통신을 한다면, 컴포넌트들은 어떤 행위를 (무엇을 해야) 할지에 대한 정보를 얻기 위하여 채널 설정부만 바라보면 됩니다.
제 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] (재고 검색)라고 이름을 붙입니다.
프로그램들을 연결하는 화살표는 직접적으로 프로그램들과 통신하는 것 같아 보이지만, 사실은 그렇지 않습니다. 박스들 사이에 하얀 공백들은 하드웨어와 소프트웨어 컴포넌트들로 가득 채워져 있습니다.
“패턴을 좀더 쉽게 학습하고 실제 프로젝트에 잘 적용할 방법이 없을까요?” 필자가 강의를 마치고 종종 듣는 질문이다. 부족하지만 필자가 공부한 패턴 지식들과 경험들을 합쳐, 독자 여러분에게 패턴을 학습, 활용하기 위한 시행착오를 조금이나마 줄일 수 있는 지름길을 안내하고자 한다.
손 영수 arload@live.com | 데브피아 Architecture 시삽과 Microsoft MVP로 활동 중이며, 데브피아 소프트웨어 공학 스터디인 Eva팀의 리더이다. 부족한 실력이지만 지식을 나눌 때는 누구보다 ‘부자’라는 자부심을 가지고 지식 나눔에 힘쓰고 있다. Pattern 전도사를 꿈꾸고 있으며, PLoP와 같은 Pattern 학회를 국내에 만들기 위해 힘 쏟고 있다.
요즘은 대학교 학부생의 교과 과정으로 들어갈 정도로 패턴은 많은 이들에게 알려져있다.. 하지만 필자 주위에는 패턴을 잘 활용하여, 성공적으로 프로젝트를 마무리 했다거나 좋은 결과를 보았다는 말보다는, 오히려 많은 불신들과 하소연을 들었다. 왜 이런 상황이 발생했을까? 이 글을 통해 독자들이 패턴에 오해를 풀고, 올바른 시선을 가지길 바라며 글을 적는다.
패턴을 대하기 이전에 마음가짐 – 유연성, 확장성
많은 분들과 패턴을 주제로 애기하다 보면, 패턴에 대한 잘못된 관점을 가진 분들을 종종 만난다. 패턴을 통해, 비약적인 성능 향상, 생산성이 증대 될거라 생각하는 분도 있고 심지어 Silver Bullet (은총알)로 생각하는 분도 있다. 물론 제한적인 도메인 안에서 성능, 생산성 향상을 가져 올 수 있는 패턴도 있지만, 패턴 자체의 목적은 유연성과 확장성에 초점을 맞추고 있다.
초창기 객체 지향(80년대)의 가장 중요시 여기는 패러다임은 “Reuse (재사용)” 이였다. 그래서 Component와 같은 이상적인 패러다임이 나오기도 했다. 마치 Lego와 같이 조립만 하면 만들어지는 Legoware를 꿈꾸어 오면서…
하지만 현재 소프트웨어는 어떠한가? 빈번하게 바뀌는 고객의 요구사항, 몇 명 이서 만들 수가 없을 정도로 거대해진 규모, 길어진 소프트웨어 생명주기를 가진 녀석들이 대부분이다. 그렇기 때문에 소프트웨어가 가져야 할 중요한 설계 방향이 재 사용성 보다는 쉽게 변화를 수용할 수 있는 유연성(Flexibility)과 확장성(Extensibility)이 대두되게 되었다. 만약 여러분이 유연성과 확장성에 초점을 맞춘 설계에 관심이 있다면, 패턴은 좋은 도구가 된다. 하지만, 최적화나 성능 개선이 목적이시라면 패턴보다는 알고리즘을 공부하는 것이 더 낫다.
그리고 패턴을 쉽사리 적용하지 못하는 여러 가지 장벽들이 곳곳에 존재한다. 패턴에 대한 불신들이다. 지면상의 제약으로 이 모든 내용을 언급하기가 한계가 있으니 예전에 필자가 마소 2007년 8월호에 기고한 “미워도 다시 보는 패턴 이야기”를 꼭 읽어보길 권한다. 패턴의 정의, 원칙, 참고할만한 설계구조도 설명하고 있다.
Architecture 101 