Post on 20-Oct-2014
description
소프트웨어 아키텍트가 알아야 할 12/97 가지
2
Architect(ure) 란 ?
Architect in Korea...
Architect 를 위한 조언들 .
Architect(ure)
어원으로 보는 Architect(ure)
Archi First / Chief / Govern
Tect/Test Build/Prove
Architect ?= GOD
그 누구의 일도 아니면 ..
네 ( 아키텍트 ) 탓이오 !!
여러분이 만난 S/W Architect.
Architect ??
Application Architect
Business Architect
Service Ar-chitect
Data Archi-tect
UX Archi-tect
Enterprise Architect
Test Archi-tect
Security Architect
Infrastructure Architect
…
아키텍트가 알아야할 12/97 가지
요구사항
Vasa 호 이야기
아키텍팅은 균형에 관한 것 .
걸어다니는 해골
설계
A 와 B 의 사이의 결정
1000 피트의 뷰
구현 가능한 것만 설계해라 .
개발 / 운영
가장 큰 문제는 기술이 아니다 .
반복 작업과 싸워라 !
드워프 . 엘프 , 마법사 그리고 왕
자세
정경유착
소문자 i 로써의 아키텍트
사과와 컨설팅 이야기
왜 우리에겐 이런 일이 발생할까 ?
# 조언 1 Mark Richards 의 Vasa 호 이야기
Vasa 호 이야기
아돌프 구스타프 2 세
스웨덴 왕실의 위엄을 온 세계에 알리고
덴마크와 동유럽을 침공하기 위해 국왕이 직접 Vasa 호의 설계에 참여 .
국왕으로 인해 변경된 요구사항
함포 64 문
원래는 32 문 !
세계최초로 상하 2열로 함포 배치
하는 김에 화려한 장식도 달자 !
금으로 도금한 병사 조각상 1000 여개 !
스웨던 왕실 상징 !! 두마리의 사자 등 ..
사람을 많이 태워야 겠어 ! 갑판 확장 !!
호화로운 장식 채우기
많은 탑승인원 450 명 !
결국은 ..
사상 최대의 사망자 ? 왜 ?
배 출항식 탑승인원 구성
귀족 100 명선원 50 명
수영을 못하는 귀족들 !
대부분 익사 !!
오히려 다행 !
덕분에 , 전수식 후 항해하기로 했던
선원과 군인 450 명은 목숨을 건짐 .
결론
Vasa 호와 같이 모든 요구사항을 충족시키려는 시도는 궁극적으로 아무것도 수행할 수 없는 불완전한 아키텍처를 만들게 됩니다
재미난 이야기 !
세계에서 제일 가는 배
- 서버린 오브 더 씨 (Sovereign of the
Sea)
여러 전투에서 승승장구
반복되는 역사 ..
# 조언 2 - Randy Stafford 의“아키텍팅이란 균형에 관한 것이다 .”
요구사항 정하기 .
출처 - IEEE1471 Korean Extension – 소프트웨어 아키텍처 정의(안)
P
Quality Attributes Workshop
QAW Roadmap
QAW Roadmap
Context
단 , QAW, ATAM 은 구축하고 하느 시스템이 명확하고 , 이해당사자들이 시스템을
이해하고 있을 때 적용 가능하다 .
Context
이해 당사자들간의 정치관계를 조심해라 .
또한
투표권을 전체 팀원에 적절히 배분해라 .
# 조언 3 – Alistair Cockburn
요구사항이 명확하지 않을 때 .걸어 다니는 해골로 시작해라
Rainy Day..
고객도 나도
무엇을 만들어야 할지 모를 때 .
사례 .
신사웅님 - 요구사항이 명확하지 않을 때..
경영 이론 시스템을 적용해
의사 결정 도구 시스템을
구축하는 프로젝트
문제 발생고객• 경영 이론을 시스템으로 구축한
경험 전무• 단지 경영진으로부터 방향성만
제시 받음
전산팀• 안정화된 시스템에 새로운 기
능 / 프로세스를 추가해본 경험밖에 없다 .
• 구체적인 요구사항이 없어 설명한 경영 이론에만 의존해 시스템 구축
갈등 발생 !!
• 진행과정을 리뷰 하면서 , 갈등 시작
• 전산팀은 나름대로 요구사항 정리 후 개발– 시연을 하게 되면 전혀 다른 요구사항이 발생– 고객이 원하는 시스템이 아니었다는 결론– 전산팀에서 아이디어를 고민해 제시해 달라 !!
• 업무적인 갈등을 넘어 감정의 갈등으로 ..
신사웅님의 해결책• 커뮤니케이션 문제가 시급하다고 판단
– 업무별 커뮤니케이션 창구를 확정
– 실제 피드백을 받을 수 있는 단위로 요구사항을 잘게 쪼개어 리스트 확정
– 각 요구사항마다 완료일과 매일 진행상항 공유
– 완료된 사항으로는 거의 실시간으로 확인 및 테스트를 할 수 있도록 변경 .
상황정리 .
고객의 입장에서는 최종 보이는 결과는 UI
실제 필요한 요구사항 파악 불가QoS – (비기능적인 요구사항 ) 파악 불가
선정한 Framework 의 사용성 , 적합성 모름 .비즈니스 도메인에 대한 정보 예측 불가
구축 후 발생하는 여러 문제들을 파악 불가
Walking Skele-ton
걸어 다니는 해골 .
Prototyping 보다 한 단계 앞선 모델 .
종단 (예를 들면 UI~DB 까지 ) 간을 오가며 수행되는 가벼운 구현체 .
모든 호출 경로를 실험할 수 있게 작동하는 작은 시스템 .
걸어 다니는 해골 .
모든 종단을 다 관통하는 주요 시나리오를 몇 개 만들어라 .
그러다 보면 , 시스템의 외적 /내적인 요구사항을 자연스럽게
도출할 수 있다 .
# 조언 4 – Kevlin Henney“ 설계의 기준으로
불확실성을 사용해라 !!”
A 와 B 사이 ..
A 와 B 두 가지 선택 중 하나를 결정하려고 시도하는 대신 ,
“A 와 B 사이의 결정을 덜 중요하게 만들기 위해 어떻게 설계해야 할까 ?”
고민해라 !!
다른 의미
선택 / 결정에 따라 발생할 수 있는 비용이 있다면 그 비용을 줄이기
위해선 어떻게 해야 할까 ?
Cavin 님 블로그 - http://cavin.egloos.com/5078906
즉 ..
선택한 최선의 전략이 언제나 최초의 효율이나
최선의 효율을 유지 하지 않는다 .
실제 세계에서는 ..
시간 , 환경 , 하는 일 등이 원인에 의해 효율적일 수 있는
구간이 시시각각 달라진다 .
풀이 .
최선을 확신치 못한다면 ,굳이 하나로 밀고 가지 말아라 !
그런 구간이 있다는 것을 염두해라 !
당장 의사결정을 성급히 내릴 필요가 없다 .
당신의 아키텍쳐 ( 결정 ) 은 변한다 .
어떤 컴포넌트 ( 분할 또는 캡슐화 ) 가 결정에 의존적인 코드로부터 쉽게 변화를 수용할 수 있게 잘 나뉘어져 있는지 파악해라 .
변화를 수용할 수 없다면 ..( 돌팔이 왈 !)
•이건 예외적인 경우야 !!
•어쩔 수 없는… .
•통계에 의하면 이게 가장 좋아 !
풀어 말하면 .
당신의 결정 ( 아키텍쳐 ) 가 올바른지 알아보려면 ,
비용을 줄일 수 있게 분할 가능한지 살펴봐라 !
# 조언 5 – Erick Doernen-burg
“1000 피트의 뷰를 가져라”
높이 (30000 feet)봐야 할까 ?
높이 봐야 할까 ?
자세히 (0 feet) 봐야 할까 ?
자세히 봐야 할까 ?
3 만 피트 vs 0 피트의 뷰 .
3 만 피트• 다이어그램의 Line 의 의미는 ?
• 의존성 ?• 데이터 흐름 ?• 버스와 같은 공유자원 ?
0 피트• 너무 상세한 정보임 .• 전체적인 구조를 보지 못함 .
해결책은 ..적절한 1000 피트의 뷰
또 하나의 도구 – Code Metrics
Demo
STAN (Structure Analysis for Java)
STAN - http://stan4j.com/eclipse/eclipse-integration.html
Demo
Robert C. Martin 의 그래프
Instability
•패키지의 안정성을 측정
•다른 패키지에 영향을 미치지 않고 , 해당 패키지를 쉽게 변경 수 있는가 ?
•Instability I = Ce / (Ca+Ce)
•Ce = Efferent Coupling (Outgoing Dependencies)•Ca = Afferent Coupling (Ingoing Dependencies )
Instability
Instability I = Ce / (Ca+Ce)
당신의 패키지가 다른 사람이 많이 쓴다면, 즉 Outgoing, Ce가 많다면, 여러분의 패키지는 변경하기 어렵다.
반대로 Outgoing하는 Ce가 적다면, 여러분의 패키지는 쉽게 변경해도 된다.즉 0.0에서 0.3이면 안정적인 버전, 0.7에서 1.0이면 불안정적인 상태다
당신의 패키지를
누군가 많이 쓰고 있다면
바꾸기 쉽지 않다 .
Abstractness
Interface(Abstract) 와 Concrete Class 를 비교
A = (#abstract classes / total # of classes)
•Abstract class = interface, abstract 다 포함•Total # class = abstract class + concrete class
•0 이면 concrete class 만 있다 . •1 이면 abstract class 만 있다 .
다시 보는 그래프
조금 더 ab-stract 를 높여야 돼 !
그 외 용어
•Tangled Complexity•순환 참조가 있어 Boundary 를 깰 때
•Cyclomatic Complexity• 분기 문이 많아 hotspot 이 될 가망성이 높은 곳
경고 !!!
환자의 외부 증상만 고치는 의사가 되지 말자 !!
이러한 정보는 좋은 가이드일뿐 !! 숫자에 의존하다가 오히려 아키텍쳐가 무너진다 .
# 조언 6 – Mike Brown“ 구현 가능한 것만 설계해라”
주어진 문제를 우아하게 해결하기 ..
•정교한 설계와 추상화 적용
•프로젝트에 신기술 적용
•새로운 패턴 과 프레임워크 적용
많은 부작용을 수반한다 .
•개발자의 새로운 학습곡선 .
•데모처럼 과연 신기술이 잘 될까 ?
•개발자의 신뢰를 잃게 된다 .
•불필요한 위험요소를 수반 .
사례 .
유명 컨설턴트 A 와의 경험
차세대 시스템 경험담
기술을 모르는 영업 상무• 기술을 모르는 영업 상무
–비행기에서 유명 컨설턴트와 만나다 .• CBD 에 대해서 이야기를 나눔 .• 당신의 솔루션이 재사용 , 확장 가능해 진다 .
– 귀국 후 차세대 시스템 구축 • 기존 시스템 유지보수에 지친 개발자들도 환호• 개발자의 추천으로 전문가 A 를 아키텍트로 섭외 .
전문가 A 컨설턴트와의 마찰 !
• 새로운 신기술을 적용해야 밴더 사에 잘 보이겠지 .– 맞지 않는 패턴 적용
• Enterprise Pattern 을 임베디드 시스템에 적용 .
– 정식 버전이 나오지 않은 신기술을 적용• 실시간성이 보장되어야 하는 시스템에서 첫 통신시 14 초가
걸림 .• 개발자들 왈 : “임베디드 시스템 특성을 몰라 ? … “
– 기존 기술에 익숙한 개발자들의 반발• 무엇이 좋아질지 모르는데 왜 바꿔 ?• 과연 이렇게 잘게 나누면 좋아질까 ?
결과 !
• PM 은 왜 일정이 연기되냐며 개발자 윽박 지르기 !
• 컨설턴트 조직은 계약만료 후 나 몰라라 사라짐 .
• 결국 프로젝트 6 개월 연기 !• 시스템 오픈 후 여기 저기 문제 떠짐 .
# 조언 7 – Mark Ramm가장 큰 문제는 기술이 아니다 .
지금도 어디선가 실패하고 있는 프로젝트 .
•기술의 잘못된 선택 ?• Java 대신 Ruby 를 선택해서 ..• Linux 대신 Windows 를 사용해서 ..
•문제가 정말 어려워서 ?
모든 것은 ..
It’s all about people.사람에 관한 것이다 .
구체적인 기법은 부록에 있는 Fearless Change 를 참조 .
대화를 해라 .
• 대화의 기술– 정면 대결이 아니라 대화라는 관점에서 접근해라
• 사람들의 장점을 고려하고 대화해라 .
– 여러분의 태도가 올바로 갖춰진 후에만 대화를 시도해라
• 화가 나거나 짜증난 상태에서 대화하지 말아라
– 회의 시 침묵하는 사람들의 의견을 이끌어 내라 .• 특정 사람에게만 발언권이 모이지 않게 해라 .• 모든 사람의 관점을 다 들어보아라 .
# 조언 8 – Niclas Nilsson“ 반복 작업과 싸워라 !”
생산성을 저해하는 이유 ..
•복제는 악이다 .
•반복되는 작업 .
계속되는 반복과의 싸움 ..
김국현의 낭만 IT - 후기
Architect 가 줄여줘야하는 반복 작업
전 Architect 입장에서 개발자에게
박수받을 만한 기법들을 전달하겠습니다 .
80
EA 의 간략한 소개 .• UML 2.1 Full 지원• 모델링 정보를 다양한 DBMS 와 연동하여 저장가능• 형식을 파괴하는 모델링 지원
– Use Case 에서도 Class Diagram 의 요소들을 사용가능• 다양한 언어를 지원
– C++, C#, Delphi, Java, VB, VB.NET, PHP, Python
• 강력한 코드 탬플릿 생성 기능• 테스팅 생성및 관리 ( 기존 Unit Testing 과 연동됨 )• 강력한 역공학 기능• 다양한 Plug-in 지원• 가장 저렴한 가격 1 Copy 당 20 만원 ~ 30 만원 사이
81
EA 의 장점 .
강력한 코드 템플릿 생성 기능
몇 가지 Plug-in 소개
Legacy System 을 위한 역 공학
문서 자동 생성 템플릿 소개
통합 개발 환경 구축 방법
82
Code Template
83
1. StreoType 생성• Setting – UML – Streotypes
84
2. 클래스 설계 후 StreoType 할당
85
3. 메소드 속성에 맞는 태깅생성• 예를 들어 현재 재고를 파악하는 메소드는
Database 에서 데이터를 가져오는 (Get) 타입인 경우 .
86
4. 코드 생성 탬플릿 작성• Settings – Code Generation Templates
다양한 언어 선택
생성할 코드 템플릿
Namespace, Class, Opera-
tion 등
스트레오 타입별 템플릿을 지정
생성할 코드 입력
87
스트레오 타입 코드 템플릿 추가
88
스트레오 템플릿 추가
• Import Section– DLL 이나 Namespace 를 추가하는 부분
• Operation Body–메소드 구현 부에 사용자 코드를 추가 함
89
간단한 예 - OperationBody%if opTag:"DataAccessType" =="get" % //데이터를 얻어오는 쿼리IDataReader reader = null;%opReturnType% retVal = new %opReturnType%();try{
// 1. Create the Database object, using the default database service.Database db = DatabaseFactory.CreateDatabase();
log.Debug("Create Database Factory");
// 2. Create DB Command string sqlCommand = "$queryName"; dbCommand = db.GetStoredProcCommand(sqlCommand); log.Debug("GetStoredProcCommand(" + sqlCommand + ")"); ….} %elseIf opTag:"DataAccessType" =="set"% //데이터를 쓰는 쿼리DbConnection connection = null;UInt32 retVal = 0;try{ ……..
89
90
Reverse Engineering
91
통합 개발 환경 구축하기
92
통합 개발 환경 구축하기
93
개발 환경 구축 – 프로세스로 디버깅 하기
94
프로세스로 디버깅하기
95
디버깅 내용을 Sequence Diagram 으로 생성
96
디버깅 내용을 Sequence Diagram 으로 생성
97
Documentation
98
다양한 포멧의 문서 제공
99
문서 – Class및 Sequece
100
UNIT TESTING
101
Unit Testing 과 연동됨• 현재 xUnit (JUnit, Nunit) 형태로
생성및 관리가 가능함 .• 다른 Unit Test 는 Package Script 로
연동가능 .
102
Visual Studio 내장 UnitTest 셋팅법
103
연동된 Unit Test
104
문서 – Testing Report
# 조언 9 – Evan Cofsky“드월프 , 엘프 , 마법사 그리고 왕”
사람의 유형 .
사람의 유형 .
드워프 - 근면한 일꾼 , 동굴 속의 어두운 고독 속에서 꾸준히 산출물을 만드는 자
엘프 – 천부적인 재능우아 , 교양있으며 , 다른 종족이 하지 못하는 마법을 만들어 냄 .
사람의 유형 .
마법사 – 강력한 종족 , 엘프와 달리 마법의 강력함과 속성을 깊이 파악해 , 놀라운 능력을 발휘
왕 – 보잘 것 없는 왕단 , 다른 종족과 무엇을 해야 할지 아는 몽상가 (비전을 제시 )
왕의 역할• 왕 ( 아키텍트 ) 는 모든 종족과 친해야 함
• 아키텍쳐가 하나의 캐릭터 ( 팀원 ) 에게만 흘러가지 않도록 균형을 맞추어야 함
• 한가지 퀘스트 ( 도전과제 ) 를 위해 모든 종족 ( 이해 당사자 ) 를 이끌어 , 같이 일할수 있도록 도와야 한다 .
왕의 역할• 왕 ( 아키텍트 ) 는 • 모든 종족 ( 팀원 ) 이 • 한마음이 될수 있는 퀘스트 (좋은 아키텍처 ) 를 만들어야 하며 , • 각 종족 ( 팀원 ) 이 서로 배워가며 , • 각자 적합한 일을 할 수 있는 가이드 제시 .
# 조언 10 – 김동열“정경유착 ( 政經癒着 )”
아키텍트의 정치• 아키텍트는 비즈니스 목표에 맞는 시스템을
만들기 위해 , 기술과 관련된 수많은 의사결정을 하는 사람입니다 .
• 이해관계자 사이에서 정당성 (rightness),
타당성 (rational) 을 바탕으로 이해관계를 조율하고 설득해야함 .
제품 영업 담당자• 효과적인 마케팅과 판매활동을 통해 이윤을
창출해야 하는 " 경제 " 적인 역할을 담당 .
• 맨발로 지내온 아프리카 원주민에게 구두를 팔고 , 에스키모 인에게 냉장고를 파는 영업인에게 ' 사기 쳤다 ' 고 이야기 하지는 않습니다 .
• 오히려 새로운 시장을 개척했다고 말함 .
사례 .
아키텍트와 영업간의 이해관계가 맞을 경우 .
영업 부장의 압력 .
• EJB 기반의 WAS – EJB 와 관계형 기반의 DB 시스템에 유리
– 요구사항• CORBA 도 넣어라• 최신제품이니 , 객체 지향 DB 도 쓰자
– 결론 “넣긴 넣었다 . 하지만 ..”• CORBA 를 어디에 적용했는지 기억도 안남 .• 객체지향 DB 일부만 적용
또 다른 Vasa 호• 미션이 완전히 동일한 시스템은 없다 .• 모든 시스템의 목표를 만족시켜줄 아키텍쳐 , 솔루션은 존재하지 않는다 .
• 만들수 있겠지만 , 새로운 장애물이 나올경우 침몰하는 또다른 Vasa 호가 될 뿐이다 .
결론 .
• 아키텍트는 올바른 “정치”를 하기 위해 , 정경유착의 고리를 끊고 , 특정 제품에 자유로울 필요가 있습니다 .
# 조언 11 – Dave Quick“소문자 i 로써의 아키텍트”
개발자를 무시하는 아키텍트 유형• 고객보다 요구사항을 더 잘 이해한다 .
• 개발자를 자신의 아이디어를 구현하는 사람으로 본다
• 자신의 아이디어가 도전 받거나 , 무시 당할 때 방어적으로 변한다 .
왜 이렇게 되었나 ?
• 난 지금까지 성공 해왔다 !!
• 사람들은 우리를 존경한다 .
• 설계는 곧 나 자신이다 .
올바른 자세를 갖는 방법• 요구사항은 거짓말을 하지 않는다 .
– 고객과 같이 일해라
• 팀에 집중해라 .– 팀은 자원이 아니다 . – 설계 협력자이며 , – 여러분의 진가를 인정하게 만들어 줄 사람들이다 !!
올바른 자세를 갖는 방법
• 업무를 점검해라 .– 아키텍쳐가 각 요구사항을 어떻게 지원하는지 검증해라 .
• 나 자신을 돌아봐라– 팀원들이 여러분을 존경하고 있는가 ?– 선의의 참여에 부정적으로 대답하지 않는가 ?– 왜 그 사람이 나의 방식에 불응했을까 ?
# 조언 12 – ???“컨설팅과 사과 이야기”
컨설턴트와 컨설팅 받는 사람
컨설턴트는 이해당사자들 모두를 이해하고어떠한 benefit 을 줄수 있는지 설명해야 한다 .
컨설팅 받는 사람은 무조건 적인 저항보다는더 도메인 전문가이니 , 협상을 해 나가야 한다 .
감사합니다 .