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

웹 서핑중 괜찮은 자료를 발견했습니다.
Design Pattern Quick Rerference자료 인데요.  맨 아래 그림을 보시면 뭔지 아시겠죠

mcdonald 라는 분이 올려 주신 자료입니다.
이런 분들의 지식 공유에 다시금 감사를 드립니다. 연세에 맞게 글에도 Force가 느껴지는 군요.
지식 나눔의 Force가 항상 함께 하시길..

손 수 GoF Design Pattern에 나오는 패턴들을 손수 컬러링 하시고 간략히 설명해 놓으셨습니다.
시간이 되시는 분은 한글로 번역해 주시면 아주 도움이 될듯 합니다.

그리고 자료에 대해서 직접 접근하실수 있게 url을 걸어 달라고 하시네요.
자기 사이트에 대해서 많은 홍보를 하시고 싶은신가 봅니다. ^^ 
mcdonald 아저씨는 욕심쟁이~~ 우후후~~~

하나의 샘플 파일을 올려 드리죠.
Design Pattern Quick Reference에 있는 PDF, JPG, Visio 포멧의 데이터를 받으실수 있을 겁니다. ^^

풀 버젼을 받고 싶으시면 http://www.mcdonaldland.info/2007/11/28/40/ 로 접근해서 받으시길 권해드립니다.

사용자 삽입 이미지

Design Pattern Quick Reference Sample

Posted by 빵수
GoF의 한분 - Ralph Johnson

Ralph Johnson

사용자 삽입 이미지

Martin Fowler




















여러분은 이 두 분을 아십니까?  한명은 Martin Fowler이고 한명은 Ralph Johnson 입니다.이 둘중에 Martin Fowler는 이름은 아시는데 Ralph Johnson 을 모르신다면,
여러분은 Refactoring이라는 책을 읽으시고, 많은 감명을 받으시거나
그분의 지식에 많은 감탄을 받으신 분입니다.

재미난 것은 Ralph Johnson(GoF Desing Pattern)이라는 책의 저자이며,
Martin Fowler에 직,간접적인 스승이라는 점입니다.
실제로 Ralph Johnson은 Framework 설계에 대가이며,
어떻게 보면 Martin Fowler보다 더 유명한 사람입니다.

그런데 많은 분들이 Martin Fowler를 알지만 Ralph Johnson을 모릅니다.
실제 Refactoring의 초기 아이디어들은
Ralph Johnson의 Framework 에 대한 철학에 상당 부분 베어 있습니다.

Ralph Johnson 아저씨는 대부분 이러한 아이디어들을 대중들이 읽을수 있는 책보다는 논문들에 많이 기술했다는 것입니다.
어떻게 보면 지식 특권층(?)을 위한 지식나눔이었을 겁니다.

하지만 우리는 마틴 파울러를 주목할 필요가 있습니다.
그분은 Ralph Jonson의 아이디어를 잘 다듬어 Refactoring의 개념을 대중화 하고,
구체적인 방향들을 제시함으로써, 지금 현재 많은 이에게 자신의 이름을 각인 시켰다는 것입니다.

또 두분의 Architecture의 생각도 역시 Refactroing과 비슷한 상황에 놓였습니다.

Ralph Johnson이 보는 Architecture
- 아키텍처는 주관적이고 시스템 설계에 대한 전문가(프로젝트 이해관계자들의 대표격)들의 공유하는 이해

Martin Fowler가 보는 Architecture
- The expert developers working on that project have a shared understanding of the system design.

 This shared understanding is called 'architecture'
(팀원간에 서로의 이해를 공유하는 것을 Architecture라고 부른다)

자세한 내용은 마틴 파울러의 글을 참고 바랍니다. http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf 

위 글을 읽어 보시면 알겠지만 재미난 것은 Martin Fowler가
Ralph Johnson의 큰 개념들을 확장하고 현대식에 맞게 바꾸어 나간다는 것입니다.
이렇게 하면 우리도 성공할수 있지 않을까요? ^^

혹시나 Martin Fowler를 어떻게 보면 지식을 훔쳐서 나쁜 사람으로 볼수도 있지만,
절대 그렇게 보시면 안됩니다. 냉정하게 우리를 돌아 보도록 합시다.

제가 드리고 싶은 말은 지식은 처음부터 알고 태어난 것이 아니라는 점입니다.
우리가 알고 있는 지식의 대부분은 책이나 경험 또는 선배들로 부터 획득했기 때문입니다.
자신만의 비밀스러원 경험이나 지식으로 존경 받는것보다는,
부족한 지식이지만 나눌줄 아는 사람이 더 존경받는 것이 바람직하다고 생각합니다.

자신이 알고 있는
독특한 노하우나 지식들은 혼자 사용해서 자기만의 만족으로 끝이 날 뿐입니다.
선배들이 만든 지식들을 더 잘 다듬고 강화 시켜서, 후배들에게 돌려 주도록 합시다.

그리고 지식 나눔에 감사함을 가지는 자세를 모두가 가지는 것도 중요합니다.
남의 지식을 훔치고 자기 것인양 말하는 것은
지식을 공유하는 자에게 상처를 주는 일입니다.

다른 이의 지식 공유에 감사하며,
그 지식을 더 발전 시키고 나간다면 정말 아름다운 사회가 올거 같습니다.
지금 고려 청자를 만들수 있는 사람이 없듯이,
우리 분야에서는 비슷한 사건이 일어나지 않길 바라며 글을 맺겠습니다

'컬럼 및 아티클' 카테고리의 다른 글

지식을 나누는 자가 되자!  (0) 2007.12.24
Posted by 빵수

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

공지사항

카테고리

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

글 보관함

달력

«   2018/10   »
  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,104
Today : 1 Yesterday : 8