Transcript 개발자를 위한 아키텍처 기반 소프트웨어 개발 방법

개발자를 위한 아키텍처
기반 소프트웨어 개발 방
법 및 현대적 개발환경
Architecture & Design sysop in Devpia
김태현
[email protected]
목차

개발자를 위한 아키텍처 기반 소프트웨어 개발 방법











현대적 소프트웨어 개발환경






소프트웨어 아키텍처에 대한 오해
아키텍처의 종류
소프트웨어 아키텍처의 중심적 특성
소프트웨어 아키텍처의 구성
소프트웨어 아키텍처의 등장배경
소프트웨어 아키텍처가 필요한 이유
아키텍트의 역할
아키텍처란?
아키텍처 기반 소프트웨어 개발
아키텍트
현대적 설계 & 개발 환경
현대적 소스관리 환경
현대적 QA 및 문서화 환경
담론
아키텍트 리딩패스
참고도서
이번버전은

객관적인 기술 소개



SAIP, RUP, XP, .. 등에서 아키텍처링 이론 소
개
현실에 맞지 않는 부분 지적
대안 제시
개발자를 위한 아키텍처 기반 소프
트웨어 개발 방법










소프트웨어 아키텍처에 대한 오해
아키텍처의 종류
소프트웨어 아키텍처의 중심적 특성
소프트웨어 아키텍처의 구성
소프트웨어 아키텍처의 등장배경
소프트웨어 아키텍처가 필요한 이유
아키텍트의 역할
아키텍처란?
아키텍처 기반 소프트웨어 개발
아키텍트
소프트웨어 아키텍처에 대한 오해

아키텍처는 ‘설계’ 아닌가요?


아키텍처는 ‘구조’ 아닌가요?


아키텍처는 개발하고자 하는 시스템에 대한 요구사항 분석, 품질
속성 도출, 아키텍처 전략수립, 아키텍처 설계, 분석, 평가 및 구
현단계에서 개발의 가이드라인이 되며 시스템에 관계하는 사람
들과의 커뮤니케이션을 제공하기 위한 것으로써 단순히 ‘설계’만
을 일컫는 것이 아닙니다.
아키텍처는 시스템의 구조를 뽑아내기 앞서 요구분석 및 품질속
성과 전략과 같이 ‘구조’에 대한 근거들을 포함하며, 구조가 만들
어진 다음에도 그것을 잘 유지할 수 있도록 지원하는 기초들입니
다. ‘구조’는 아키텍처가 갖고 있는 구성체 중 하나입니다.
서버구성과 같은 하드웨어 구성도가 아닌가요?

그것은 하드웨어 아키텍처라 불리며 소프트웨어 아키텍처와 분
리하여 다룹니다. (서로의 밀접한 관련성을 부정하는 것이 아님)
아키텍처의 종류








엔터프라이즈 아키텍처
시스템 아키텍처
소프트웨어 아키텍처
조직 아키텍처
정보 아키텍처
하드웨어 아키텍처
어플리케이션 아키텍처
인프라 아키텍처
Peter Eeles works for IBM
(What is a software architecture?)
소프트웨어 아키텍처의 중심적 특성







아키텍처가
아키텍처가
아키텍처는
아키텍처가
다.
아키텍처가
아키텍처가
아키텍처는
구조를
작동을
중요한
결정의
정의한다.
정의한다.
요소에 집중한다.
이론적 근거를 제시한
패턴을 만든다.
팀 구조에 영향을 미친다.
모든 시스템에 존재한다.
소프트웨어 아키텍처의 구성

아키텍처는 다음과 같은 요소로 구성된다.
요구분석
 품질속성과 전략
 시스템구조(뷰)
 아키텍처적 결정사항들(가이드라인)
 미적인 요소


기능과 구조와 아름다움의 3요소
소프트웨어 아키텍처의 등장배경
프로젝트는 시작할 때는 그다지 복잡하지 않게
보이지만 시간이 지날수록 기하급수적으로 복잡
해진다.
Co mp lexity

Time
소프트웨어 아키텍처의 등장배경

개 집은 혼자서 만들 수 있다.
고층 빌딩은 여러 명이 함께
만든다. 규모가 크고 복잡도
가 높을 수록 ‘준비’와 ‘약속’
이 중요해진다.
소프트웨어 아키텍처의 등장배경

골목대장이 될 것인
가?

효도르가 될 것인
가?
우리의 삶에 강한 영향을 주는 작품이 기능과 품질만 좋은 것은 아님.
뛰어난 제품은 단순하면서도 임펙트가 있고, 그것은 ‘철학’으로 부터 나옴.
소프트웨어 제품의 ‘철학’은 아키텍트로 부터 나옴.
얼마나 아이디어가 좋은가 보다 얼마나 아이디어가 적절한가의 문제.
아키텍처링은 더하기가 아닌 빼기 같은 것.
소프트웨어 아키텍처가 필요한 이유



서로 다른 관점을 가
진 이해관계자들과 의
사소통 할 무엇이 필
요하다.
다양한 소프트웨어 속
성들의 복잡성을 관리
할 무엇이 필요하다.
경험을 지식으로 축적
하여 재사용할 수 있
어야 한다.
소프트웨어 아키텍처의 역할

이해당사자(stakeholder)간에 원활한 의사소통 수단.



프로젝트 초기에 결정된 설계 사항을 기재해 놓은 산출
물.





이해당사자에게 보이는 시스템의 모습은 그들의 관점에 따라서
달라질 수 있다.
소프트웨어 아키텍처는 스테이크홀더들간에 의사소통을 통해,
서로를 이해하고, 합의를 도출할 수 있게 해주는 공통적인 시스
템의 추상이다.
소프트웨어 아키텍처는 시스템 설계의 초기 결정.
초기 결정은 설계, 개발, 테스트, 유지보수 등에 지속적으로 영향
을 줌.
프로젝트상의 세부적인 의사결정에 근거가 됨.
프로젝트 개발의 가이드라인이자 버팀목
여러 시스템들을 위해서 재사용할 수 있는 시스템의 추
상적 모습(abstraction).
소프트웨어 아키텍처의 역할
기획
아키텍처는
3영역의 연
결고리
소프트웨어 개발의 복잡성을 무엇으로 관리해야 하는가?
그 답이 아키텍처.
기술
사업
아키텍처란?

SAIP

(Len Bass, Paul Clements, Rick Kazman)
소프트웨어 아키텍처는 프로그램이나 컴퓨터
시스템을 만드는 소프트웨어 구성요소와 이
구성요소들이 외부에 드러내는 속성과 이 구
성요소들 사이의 관계로 이루어진 시스템의
구조이다.
속성
요소
관계
요소
아키텍처란?

IEEE 1471


소프트웨어 아키텍처는 시스템에 대한 기본 조직 체
계로 시스템을 이루는 구성요소와 이 구성요소들 사
이의 관계, 이 구성요소들과 주변 환경 사이의 관계,
시스템의 설계와 진화방향을 지배하는 원칙들로 실체
화된다.
ESA - 르 코르뷔지에

우리는 돌, 나무, 시멘트를 사용하여 집을 짓고 건물
을 만든다. 이것은 건축(Construction)이다. 그런데
문득 그것이 내 마음을 사로잡고, 나를 감동시킨다.
그 순간 행복한 나는 이렇게 말한다. “아~ 아름답군!”.
아키텍처(Architecture)이란 그런 것이다.[
아키텍처 기반 소프트웨어 개발

소프트웨어 개발 프로세스 [RUP]
아키텍처 기반 소프트웨어 개발

소프트웨어 개발 프로세스 [XP]
아키텍처 기반 소프트웨어 개발

아키텍처 활동







요구사항 분석
품질속성 도출
품질속성별 전략수립
아키텍처 설계 및 문서화
아키텍처 분석 및 평가
아키텍처 유지 (아키텍처 기반 시스템 구현)
아키텍처 활동은 개발 프로세스 상 초반에 집중
되며, 구현과 QA 및 릴리즈 단계를 거쳐 마무리
되고 개발된 시스템은 다시 아키텍처에 영향을
미친다.
아키텍처 기반 소프트웨어 개발

품질?
아키텍처 기반 소프트웨어 개발

다양한 품질속성의 분류







ISO/IEC 9126
SAIP
McCall 모델
Boehm
FURPS (hp)
CUPRIMDSO (IBM)
실전에서 특정 모델에 집착할 필요 없음. 여러
품질속성 중에서 팀의 환경과 상황, 프로젝트의
성격에 맞는 속성을 뽑아내는 것이 중요.
아키텍처 기반 소프트웨어 개발

품질속성을 도출했다면 각각의 전략을 수립
품질속성
전략
성능성
자원최소화, 동시성확보, 우선순위조정
사용성
GUI, UNDO
보안성
인증, 권한, 부인방지, 감사
안전성
독립프로세스, 무결성
검증성
TDD, 내부모니터링, 로그
가용성 & 안정성
오류감지, 오류복구, 오류예방
변경성 & 확장성
모듈화, 응집도, 추상화, 인터페이스
아키텍처 기반 소프트웨어 개발


패턴이란?
아키텍처 패턴 [POSA]








Blackboard
Layers
MVC
Pipe & Filters
Reflection
Broker & Microkernel
Etc..
패턴은 문제해결의 템플릿일 뿐. 은탄환이 아님.
집착보다 통찰을 얻는 데에 집중할 것.
아키텍처 기반 소프트웨어 개발


아키텍처의 산출물은 아키텍처 문서
아키텍처 문서화(DSA)

모듈



컴포넌트-커넥터(component-connector)



분할, 사용, 레이어, 클래스
구현단위의 입장
프로세스, 동시성, 공유데이터, 저장소, 클라이언트-서버
실행시간의 입장
할당(allocation)


배치, 구현, 작업 배정
소프트웨어 구현과 실행의 환경에 대한 입장
아키텍처 기반 소프트웨어 개발







요구분석 중 혹은 후 기능적, 비기능적 품질속성을 도출
한다.
아키텍처적으로 중요한 점들을 뽑아내고 소프트웨어 아
키텍처[요소+속성+관계+미]를 설계한다.
하드웨어 아키텍처와 함께 평가 검증한다.
아키텍처 문서화를 완료하고 세부적 소프트웨어 설계를
지원한다.
개발 중 중요한 의사결정 필요 시 아키텍처가 결정 근거
가 되도록 지원한다.
개발완료(반복의 한단계) 시점에 아키텍처로 결과물을
검증하고 개선점을 찾는다.
참고




아키텍처 문서를 통해 스테이크홀더들과 지속적으로 커뮤니케이션 해야 함.
생성된 아키텍처는 미래 시스템의 패턴으로 재활용 될 수 있음.
아키텍처 문서는 스테이크홀더들, 특히 개발자들의 접근성이 용이해야함.
아키텍처 개발 방법 자체가 개발 프로세스가 아니며, 프로세스에 녹여내야함.
아키텍트

아키텍트란?



아키텍처를 만드는 사람
아키텍처를 수행하는 사람
아키텍트의 역할은?

아키텍처 만들기


아키텍처 유지시키기




아키텍처 설계와 구현
개발자들과 커뮤니케이션
개발 결과물들의 아키텍처 확인
아키텍처를 수정하되 정갈한 상태를 유지
이해당사자와 커뮤니케이션

기획/개발/사업/경영/고객 및 유관자와 끝없
는 대화
아키텍트

개발팀장이란?
일선 개발팀장에게 요구되는 것
 기술리더 + 사람관리 + 프로젝트관리 + 개발
자 + 분석가 + 설계자 + 아키텍트 = ?
 정말 뛰어난 인재가 있다면 개발팀장이라는
시스템이 좋다고 볼 수 있음.
 개발팀장, PM, 아키텍트가 분리되면 만점, 팀
장과 아키텍트만 분리되어도 훌륭.

현대적 소프트웨어 개발 환경



현대적 설계 & 개발 환경
현대적 소스관리 환경
현대적 QA 및 문서화 환경
현대적 설계 & 개발 환경






설계언어로 UML 사용 권장.
UML 툴을 하나로 통일할 것. (StarUML/로즈/투게더/비
지오 등등 중 택일)
단, 실전에서 UML 만으로 모든 설계 행위를 할
수는 없음.
슈도코드(pseudocode)도 좋은 설계적 행위이자
문서.
서브시스템 명세서, 컴포넌트 명세서 등 문서화
템플릿을 갖출 것을 권장.
단, 문서양식을 강제하지 말 것. 대신 양식 풀을
만들어 공유하고 지속적으로 변경되도록.
현대적 설계 & 개발 환경

A3 프린터


UML 설계 내용을 확인하기 위해
최소 A3 규격 요구됨.
전자칠판

판서 내용을 프린트하거나 그림파
일로 저장.
현대적 설계 & 개발 환경

듀얼 or 트리플 LCD 모니터
한쪽에는 설계를, 한쪽에는 코딩을.
 트리플 모니터로 설계,코딩,일반업무 배열.
 데스크탑 1대, 노트북 1대 권장.
 Synergy 같은 프로그램을 이용하여 마우스,키
보드 공유
 세로 모니터가 많은 코드를 볼 수 있음.

현대적 설계 & 개발 환경
듀얼모니터 (세로모니터)
트리플모니터 (PC2대)
현대적 소스관리 환경

혼자 개발을 하더라도 소스 리파지토리를
구성할 것을 권장.
소스백업
 브랜치 및 버전 관리
 변경 추적 가능
 동시작업 지원




CVS
SVN
VSS
현대적 QA환경 & 문서화 환경

QA는 BTS (Bug Tracking System) 를 이용.





Mantis [http://www.mantisbt.org/]
Bugzilla [http://www.bugzilla.org/]
그 외 [http://testingfaqs.org/t-track.html]
완벽은 있을 수 없음. 병적인 QA 압박은 결벽증. 핵심은 절충할 선을 찾는 것.
소스 문서화



가급적 함수이름으로 설명되도록 하여 설명의 양을 줄인다.
설명이 필요하다면 ‘예제’ 를 기입하는 것이 좋다.
소스를 문서화하는 일은 고통스러운 작업이므로 자동화 할 것.


문서를 공유하고 담아둘 공간이 필요



Doxygen [http://www.doxygen.org]
Wiki [http://www.wikimatrix.org]
MS SharePoint
문서는 추적성 확보가 중요

기획서(요구사항) – 설계서(아키텍처) – 구현(코드,코드문서) 의 상호 링크로 탐
색이 자유로와야 함.
담론


소프트웨어 아키텍처는 공학적 접근
단, 원칙과 변칙을 유연하게 구사한다.



산전수전 다 겪어봐라.




동네축구 VS 프로축구
신예를 공격수로, 노장을 수비수로.
엄하게 나누고 따뜻하게 협력한다.
주장만 하지 말고 되는걸 먼저 보여준다.


병신이 성공할 확률은 지극히 낮다.
공격수와 수비수가 할 일이 따로 있다.


실전 없이 실무를 설명할 수 없다.
아기가 보고 싶다고 10개월 전에 낳게 하면 병신 된다.


태권도 철학으로 싸움하려는 깡패
힘과 덩치만으로 싸움하려는 깡패
의심의 왕국. 맹신의 왕국. = 한국
쾌도난마로 어설픈 반대와 불안을 종식한다.

충분한 내공이 있는 상태에서 해야 함.
아키텍트 리딩패스
참고도서








Software Architecture in Practice Second Ed
Documenting Software Architecture
Evaluating Software Architecture
The Unified Software Development Process
Applying UML and Patterns
Design Patterns GoF
Pattern-Oriented Software Architecture I
Extreme Programming Installed