아키텍트가 되기 위해서 우리에게는 어떠한 덕목이 필요할까요?

2007년 10월에 소프트웨어 아키텍쳐 이론과 실제 (Software Architecture in Practice)의 저자인 Rick Kazman이 한국을 방문해 ATAM에 대한 강연을 하였습니다.

세미나가 마친후 어떤 분이 “당신과 같이 휼룡한 아키텍트가 되기 위해서는 어떠한 소양과 지식이 필요한지 설명해 주시겠습니까?” 라는

질문을 했고, 이에 대한 멋진 답변을 해 주셨는데  제가 알고 있는 지식을 덧 붙여 여러분과 함께 공유하고자 합니다.  

1. 소통과 협상 능력

설계 능력 못지 않게 중요한 능력이 Social Skill입니다. 다양한 이해 당사자들이 모두 다 만족할 수 있는 시스템을 만든다는 것은 어쩌면 불가능에 가까운 일입니다.

이해 당사자들의 요구사항들에는 종종 서로의 요구가 충돌나는 것도 경험할수 있습니다.

 빠른 메세지 전송 뿐만아니라 높은 보안 수준을  요구한다거나, 자원의 제약이 심한 임베디드 시스템에서 고성능 PC에서나 가능한 퍼포먼스를 요구하는 것들을 예로 들수 있습니다.

아주 적은 금액으로 모든 문제를 해결하여 엄청난 효과를 누릴려는이해 당사자에게 정말 기간내 구현가능하고 필요한 기능을 뽑아 현실에서 실현가능한 상황에 대해서 이해 시키는 것이 중요합니다.

만약 여기서 이해 당사자들과의 합의를 이끌어내지 못하거나, 정확한 요구사항을 파악되지 못한다면 프로젝트는 초창기부터 산으로 가게 됩니다. 흔히 우리가 알고있는 이러한 나무 그림이 되기도 합니다.

그 만큼 소통과 협상 능력은 설계 능력만큼 중요한 요소라는 점을 기억해 주시길 바랍니다.

Rick Kazman은 이해당사자들간에 서로 상충되는 QoS를 잘 우선순위화 하고 평가하기 위해 ATAM (Architecture Tradeoff Analysis Method)이라는 평가, 검증 방법을 제시했는데 한번 읽어보시길 권해드립니다.

추후 여력이 될때 ATAM에 대한 이야기를 여러분과 공유해 보는 시간을 가져 보겠습니다. ^^ 

2. Process와 평가 모델

예전 포스트인 땅콩 버터와 마천루나 Conway의 법칙에서  언급한 것과 같이 우리가 설계하고자 하는 최종 S/W를 고려한 형태로 조직과 프로세스가 선택되어야 됩니다.   하지만 국내의 대부분 조직은 이러한 것들을 무시하고 있죠.

단순히 Agile의 바람이 불어서, 또는 RUP가 좋다더라 그러니 이걸 사용해 보자 라는 것보다는 소프트웨어의 특성, 조직의 문화 등을 고려하여 적용하는 것이 중요합니다.

UML의 창시자 Ivar Jacobson 역시 RUP를 넘어 EssUP (Essential Unified Process)라는 것을 새로운 것을 내놓았는데,핵심은 역시 적합한 프로세스를 고려하여 사용해야 된다는 것입니다. 

Ivar Jacobson 이 직접 마소에 기고한 글들을 읽어보시길 권해드립니다. (한국어 입니다 ^^)

• 프로세스의 쇠퇴 (Enought of Processes)
• 프렉티스의 시대 (Times for Practices)
• 프랙티스를 프로젝트로 (Bringing Practices to Life)

이외에 EssUP에 대한 풍부한 자료를 원하시면 Ivar Jacobson International 의 Resource를 참고하시길 권해드립니다.

3. Pattern (패턴)

현재 지구상에서는 존재하는 수 많은 패턴들이 존재합니다.  아직도 많은 개발자들이 GoF의 패턴들 만으로 많은 문제를 해결할려다가,

패턴은 쓸모 없어라고 말하며 실제 활용하기 부족하다라고 말합니다. 또한 어떤 분들은 패턴을 몰라도 휼룡한 아키텍트가 될수 있다고 말합니다. 

틀린말은 아니지만, 이미 선배들이 잘 만들어 놓은 좋은 지식 노하우를 이용하지 않고, 많은 시행착오를 겪는 일은 그리 효율적인 방법이 아닙니다.

지구상에 있는 무수한 패턴들 링크를 따라가 보시면 놀라시겠지만, 언제 이것을 다 익히나 할 정도로 무수한 패턴이 있습니다.

시간이 되실때 마다 관련 분야의 패턴을 틈틈히 익히고 공부하시는 것이 매우 중요합니다.

• PLoP 2007 [Online proceedings]
• PLoP 2006 [Online proceedings]
• PLoP 2005 [Online proceedings]
• PLoP 2004 [Online proceedings]
• PLoP 2003 [Online proceedings]
• PLoP 2002 [Online proceedings]
• PLoP 2001 [Online proceedings]
• 2000 [Online proceedings]
• 1999 [Online proceedings]
• 1998 [Online proceedings]
• 1997 [Online proceedings]
• 1996
• 1995
• 1994

이외에도 유럽, 일본, 호주등 다양한 곳에서 대륙권별 PLOP가 열립니다. 여기 있는 패턴들도 읽어봐야 겠지요 ^^

4. Tatcis (전술)

전술이란, 전략에 비해 단기적인 의미를 가지는 것으로 소프트웨어의 큰 구성요소들을 나누고,  구성 요소 내에서 어떻게 구현,실행해 나갈지 계획을 세워나가는 것을 의미합니다.

이러한 전술을 많이 알고 있어야, 내실이 튼튼한 소프트웨어가 나오겠죠.  이러한 전술을 많이 알기 위해서는 경험 못지않게, 패턴(간접 경험)을 익히는 것도 중요합니다.

간략히 패턴에서 전술의 예를 든다면 마샬링에 대한 예를 들어보도록 하죠

Loosely Coupling하게 마샬링하기 위해 Protocol 기반의 설계를 사용함으로써 확정성이나 관리의 용이성을 획득하지만 응답 속도나 처리량을 포기해야 됩니다.

반면에 Tightly Coupling하게 마샬링하기 위해서는 Simple Object를 만들어서 사용하는 방법이 있는데,  System에 Dependency한 단점이 생기고 변화에 유연하지 못한 단점이 있는 반면 위 방법에 비해 응답속도나 처리량이 더 뛰어나죠.

흔히 CORBA(IIOP에 의한 Protocol 전송 방식)과 COM+ (Simple Object ) 의 데이터를 주고 받는 경우라고 할수 있습니다.

구체적인 부분은 Composite Message라는 논문을 공부한후 직접 제가 동영상 강의로 찍어 놓은 것이 있으니 참고해 주시길 바랍니다.

 그리고 여러분이 패턴 기반의 전술을 익히기 좋은 서적을 하나 추천합니다.  우리나라에서는 거희 알려지지 않은 서적입니다.

바로 POAD (Pattern Oriented Analysis Design) 이라는 책입니다.

패턴을 이용해 요구사항, 설계, 구현 하는 것을 설명하구요. 설계시 패턴간의 Trade-Off 를 고려해 적합한 패턴을 선택하는 Case를 보여줍니다.

GoF, POSA1 정도만 아시명 충분히 읽을수 있는 책이므로 꼭 읽어보시길 권해드립니다.

5. 과학적인 검증

설계된 아키텍쳐와 여러가지 기술들이 과학적으로 타당한지 검증하는 것들이 필요합니다.

실험을 통해서 결과적으로 증명하거나 이론적으로 검증하는 시간을 거쳐 나의 아키텍쳐가 효율적임을 검증해야만 비로서 나의 아키텍쳐가 휼룡한지 알수가 있죠.

제가 존경하는 POSA2의 저자 Douglas C. Schmidt 교수님이 쓴  JAWS : An Application Framework for High Performance Web Systems 라는 자료를 보시길 권해드립니다.

어떠한 환경에서는 최적화된 웹서버는 존재하지 않기 때문에, 상황에 맞게 적합한 아키텍쳐를 선택할 수 있게 만들어진 웹서버 입니다.

(제가 녹화한 한국어 강의가 있습니다. 참고하세요  JAWS – 패턴을 이용한 웹서버 만들기)

이 논문 뒷 부분에 아키텍쳐 검증을 위해 테스트를 하게됩니다.

이 테스트는 우리가 알고 있는 비동기 모델의 환상을 단번에 깨주는 재미난 결과를 보여줍니다. 비동기 모델이나 IOCP와 같은 기술들은 IO 사이즈가 작을 경우 오히려 성능이 더 안 좋아진다는 결과를 보여줍니다.

우리가 주고 받는 메세지의 크기가 5kb 정도 밖에 안되는 상황에서는 동기모드가 훨씬 우수한 성능을 보여준다는 것입니다. 

물론 Connector-Acceptor 패턴을 통해 주고 받는 메세지나, 이벤트의 성격에 따라 비동기, 동기를 선택하는 것이 옳지만  여러분의 메세지가 주고 받는 프로토콜의 사이즈가 소규모인 경우 동기 모드가 더 낫다는 것입니다.

저 역시 실제적으로 테스트를 해보았습니다.

물론 Microsoft .NET Framework의 BeginXXX, EndXXX 메소드 같은 경우 사이즈가 작은 경우 비동기 데이터를 내부적으로 동기로 처리하게 하는 기능이 숨겨져 있으므로, 비동기도 성능이 괜찮은데 라고 반문하시는 분도 있으실수 있습니다.  위 동영상 강좌를 한번 보시고 꼭 관련 논문을 보시길 권해드립니다. 

6. 끊임없는 지식 습득

끊임없는 배움의 자세가 바로 위에 있는 모든 것들을 가능하게 해줍니다. 

아키텍트는 단기간에 될수 있는 것이 아니라 끊임없는 공부와 경험을 쌓아야  좋은 아키텍트가 될수 있다 라는  말을 했습니다.

이건 너무나 당연한 애기입니다.

많은 회사에서 아키텍트가 실력이 아닌 년차, 즉 직급의 상징이 되는 그런 상황이 씁쓸합니다. 

(물론 저는 아키텍트의 아도 못미치는 사람입니다. ^^) 

겸허하게 좋은 소프트웨어 아키텍쳐에 대해 고민하고 실천하는 그런 노력이 필요한것 같습니다. 끝으로 좋은 지식 나눔 행사인 Paper Meeting을 소개함으로 이번 POST을 마무리하겠습니다. 

많은 분들과 만나 새로운 지식과 경험을 나누고 습득하는 것만큼 좋은 일은 없겠죠 ^^