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 빵수

초등학교를 다녔을때 선생님이 국보 1호가 뭐야? 라고 물었을때 자랑스럽게 대답하던 숭례문(남대문).
한국을 대표하던 Landmark가 화마로 소실되어 많은 분이 슬퍼하고 계십니다.

사용자 삽입 이미지

화재로 읽어 버린 숭례문

우리가 만든 소프트웨어와 숭례문의 사건과 연결지어 생각해보고자 합니다.
제가 잘알고 있는 패턴 이야기로 풀어 보고자 합니다.

숭례문이 600년간 유지 되어왔던 것은 선조들부터 숭례문을 지키고 보호해 왔기 때문입니다.
끊임없이 숭례문을 지키고 감시하는 시스템이 유지되었기 때문이지요.

하지만 숭례문이 민간인에게 개방되면서,
많은 분이 기뻐했지만 결국 한명의 과오로 인해 숭례문이 불타 소실되어 버렸습니다.

아마 일반인에게 공개를 했는 만큼 보안을 신경쓰지 않아서 그랬다고 할수 있겠지만,
이런 사태는 소프트웨어의 기술적으로 보면 약간 시각이 달라집니다.

보안이라는 것은 특정 패스 카드 같은 것을 지니고 문에서 검문을 하는 것에 비유할수 있습니다.
쉽게 말해 인증서나 키와 같이 패스카드와 같은 것들이 있어야만 되는 거죠

일반인에게 다 개방을 했기 때문에 우리나라 국민이라면 다 접근을 할수 있습니다.
그러니 어떻게 보면 소프트웨어 적으로는 이러한 문제를 보안으로 풀기보다
처음부터 방어적인 프로그래밍 또는 Fault Tolerant 한 구조로 설계가 될 필요가 있습니다 .

그럼 소프트웨어가 이러한 상황이라면 어떻게 해결하는 것이 좋을까요?

해결책은 아래에 있습니다.

사용자 삽입 이미지

WatchDog



Fault Torelant 패턴 중에 WatchDog이라는 패턴이 있습니다.
이 WatchDog이라는 것은 우리가 흔히 말하는 Observer , Interceptor 패턴들과 종종 같이 사용됩니다.

WatchDog은 특정 상황을 계속 모니터링할때 사용되는 패턴으로 정책과 룰을 가지는 Agent적인 성격이 강한 패턴입니다.

 가장 쉽게 보여질수 있는 예가  Thread Pool을 관리할때 입니다.
많은 클라이언트의 접속으로 ThreadPool안에 있는 Thread가 임계점 이하로 줄어들면,
다시 Thread를 생성하라는 명령을 내리기도 합니다.
또는 시스템의 리소스를 더 생성할수 없을 경우 클라이언트의 동시 접속자수를 제한한다거나,
아니면 Message Queue에 쌓아 놀수도 있을 겁니다.

 WatchDog이라고 하니 머리속에서 번뜩하고 떠오르는 재미난 기술이 있습니다.
Microsoft의 COM+ (DCOM의 진화모델)에는 내부적으로 WatchDog을 이용해 Recycling이라는 재미난 기능을 지원합니다.  
이상하게 제가 만든 소프트웨어가 100일 정도 지나면 Thread들이 가끔 먹통이 되어서 시스템이 중지 된다고 합시다.
가장 좋은 것은 제가 Thread 의 반환하는 부분들을 잘못했기 때문인데. 도대체 어디에 있는지 찾을수 없는지 매우 난감할때가 많습니다.

우리가 정한 주기마다 Thread Pool의 Thread들을 시스템에 반환하고, 새로운 Thread를 생성하는 것인데요.
잘못 만든 정책에 의해 종종 Thread가 일정 시간이 지나면 먹통이 될 경우를 대비해 이러한 전략들을 구성해 놓았습니다.


 견고한 소프트웨어를 만들기 위해서는 로그를 남기면서 수동적으로 대처하기 보다는 로그 정보를 잘 활용해 WatchDog으로 어떻게 문제를 해결해 갈지 생각해 보는게 더 견고한 소프트웨어를 만드는 방법일 겁니다.

숭례문의 사건으로 우리의 소프트웨어도 어떤지 한번 돌아보는 시간을 가지는 것을 어떨까요?

WatchDog의 정의 (Wikipedia)
http://en.wikipedia.org/wiki/Watchdog 

관련 샘플
http://www.codeproject.com/KB/IP/watchdogmanagement.aspx 
http://www.koders.com/java/fidFB44476831876A0203C34CF6F66639231692AA7D.aspx
http://www.koders.com/ 에서 WatchDog으로 검색 해보세요.

Posted by 빵수

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

공지사항

카테고리

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

글 보관함

달력

«   2018/12   »
            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 31          
Total : 13,179
Today : 0 Yesterday : 0