'아키텍트가되기위한덕목'에 해당되는 글 1건

  1. 2008.03.13 Rick Kazman이 말하는 Architect가 되기 위해 필요한 덕목들

Rick Kazman
2007 년 10월경에 Software Architecture in Practice의 저자인 Rick Kazman이 한국을 방문해 ATAM 에 관련된 강연을 하셨습니다.

ATAM은 시스템아키텍쳐가 우리가 원하는 시스템과 부합하는지에 대한 여러가지  관점에서 평가를 하는 모델입니다.

 실제 필자의 회사를 비롯해 많은 외국계 기업들이 내부적으로 ATAM을 사용하고 있으며,  시스템에 맞게 내재화를 하고 있는 실정입니다.

하지만 정작 중요한 부분인 ATAM을 통해 아키텍쳐가 잘못 설계되었다고 하면이것을 올바른 아키텍쳐로 바꾸어 줄수 있는 지식과 경험을 가진 아키텍트가 매우 부족한 실정입니다. 잘못은 지적할수 있으나 바로 고쳐줄수 있는 아키텍트가 부족한 사실이 안타깝습니다.

세미나가 끝난후 누군가가 휼룡한 아키텍트가 되기 위해서 어떠한 지식을 갖추어야 되는지 질문을 했습니다. 아키텍트 이야기에서 나오는 추상적인 아키텍트 보다는 구체적으로 어떠한 소양들이 필요한지 언급해 주셨습니다. 저의 지식을 조금 붙여 설명해 드리도록 하겠습니다.

1. 소통과 협상능력
이해 당사자이 원하는 봐를 무엇인지를 대화속에서 얻어내고, 모든 이해당사자들을 완벽하게 요구하는 시스템을 만들기는 불가능합니다. (비용, Trade-Off되는 QoS 등)
아키텍트는 이들과의 대화속에서 우선순위를 찾아내고 정말 핵심적이 무엇인지를 파악하고, 이해시키고 설득시키는 능력이 필요하다고 했습니다.

2. Process 와 평가 모델
Agile 한것은 변황에 유연하고 서로 화합하는 모델을 추가하고 작은 프로젝트에 Bottom-Up에 유리하지만RUP와 같은 방법은 Top-Down이고 한방향으로 갈수 있는 Top-Down에 적합하다고 할수 있습니다. 이것들을 극단적으로 별개의 것으로  바라보기 보다 프로젝트와 팀의 성격에 맞게 잘 융합하고 적용하는 능력이 있어야 합니다.

그리고 ATAM같은 모델을 아키텍쳐를 검증하고 아주 적은 금액으로 모든 문제를 해결하여 엄청난 효과를 누릴려는 이해 당사자에게 정말 기간내 구현가능하고 필요한 기능을 뽑아 현실에서 실현가능한 상황에 대해서 이해 시키는 것이 중요합니다.  물론 1번과 밀접한 관련이 있겠죠.

3. Pattern (패턴)
현재 지구상에 존재하는 패턴은 무수히 많습니다.. PLOPD (Pattern Language of Program Design) 같은 학회의 패턴 자료나 POSA 같은 주옥같은 서적들 등 전문가들의 경험을 간접체험하고 획득하는 것이 중요합니다. 물론 아키텍트가 되기위해 꼭 패턴이 필요하지 않다라는 분들도 있습니다. 물론 직접 그 경험을 획득하는 것도 나쁘진 않지만, 시간 절약상 다른이의 잘 정리된 경험을 배우는것이 더 낫지 않을까요?  경험과 패턴 습득 이 두가지는 같이 공존해야만 됩니다.

4. Tactics  (전술)
어떠한 문제가 발생하면 여러가지 해결책들이 존재하게 됩니다.
그것이 여러분만의 경험이든 아니면 여러분이 알고 있는 패턴들 또는 패턴의 변종, 또는 조합으로 해결해든 문제가 되지 않습니다.

간략히 예로 누군가 여러분에게 마샬링 할수 있는 Infrastructure를 설계하라고 했습니다.
크게 마샬링은 Loosely Coupling  하게 하는 방법과 Tightly Coupling하게 하는 방법이 있는데요.

Loosely Coupling하게 마샬링하기 위해선 Protocol 기반의 설계를 사용합니다.
확장성이나 관리가 용이한 장점이 있지만 응답 속도나 많은 처리량(Throuput)을 포기해야만 됩니다.

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

흔히 우리가 알고 있는 분산 시스템에서 CORBA(IIOP에 의한 Protocol 전송 방식)와 COM+ (Simple Object ) 이 이 두가지 예라고 할수 있습니다.

문제는  시스템의 상황을 고려해 위 두가지 중에 적합한 전술을 선택해야 될것입니다.
이것은  상황에서 패턴 + 경험이 결합되어야 비로서 적합한 전술을 선택할수 있는 능력이 생길것입니다.

5. 끊임없는 지식 습득
단기간에 아키텍트가 될수 있는 것이 아니라 끊임없는 공부와 경험을 쌓아야  좋은 아키텍트가 될수 있다 라는  말을 했습니다.
이 건 너무나 당연한 애기죠 ^^ 회사에서 아키텍트가 실력이 아닌 직급의 상징이 되는 그런 상황이 아닌 겸허하게 좋은 소프트웨어 아키텍쳐에 대해 고민하고 실천하는 그런 자세가 필수 인거 같습니다.

6. 과학적인 증명과 검증
설계된 아키텍쳐와 여러가지 기술들이 과학적으로 타당한지 검증하는 것들이 필요합니다.
실험과 이론적인 검증을 통해서  이 아키텍쳐가 현재 효율적인지를 검증해야 됩니다.

예를 들면 네트워크 Application 개발중 많은 부분이 성능상의 문제로 비동기 (Asynchronous)  모델을 선호하고 있습니다. 문제는 비동기가 모든 상황에서 좋은 성능을 약속하지 못한다는 것입니다.

이전에 포스팅한 JAWS : 패턴을 이용한 고성능 웹서버 만들기에 있는 동영상 강의나 TP 자료에 나와 있듯이 적은 사이즈 (6KB)의 데이터 전송시에는 오히려 비동기 메커니즘이 성능이 더 떨어짐을 알수 있습니다. 이러한 검증 작업을 통해야만 적재 적소에 맞는 아키텍쳐를 여러분 시스템에 구현할수 있을 겁니다.

후추 전술에 대해서 깊게 언급하는 시간을 약속드리며 글을 맺도록 하겠습니다.

Posted by 빵수

BLOG main image
Eva네의 소프트웨어 이야기
Devpia Eva 팀입니다. 소프트웨어 설계,패턴, 최신 이슈들을 공유하는 장이 될것입니다. by 빵수

공지사항

카테고리

전체보기 (11)
아키텍쳐 (2)
패턴 (6)
새로운 기술들 (0)
소공이야기 (0)
컬럼 및 아티클 (1)
Eva네 (2)
문래예술 (0)

글 보관함

달력

«   2018/11   »
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
Total : 13,142
Today : 0 Yesterday : 0