꿈꾸는자의 생각의 파편들... :: [SA강좌1회] 소프트웨어 아키텍처 개론

달력

10

« 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
  •  
  •  
  •  

[소프트웨어 아키텍트의 자격]

 

소프트웨어 공학과 아키텍처에 대한 이야기

소프트웨어 아키텍처 개론

 

소프트웨어 아키텍처는 소프트웨어개발에 있어서, 최고의 방법이 될 수 있을까? 방법이라는 측면에서의 접근방법으로서의 소프트웨어아키텍처. 그것의 기본적인 개념과 기초적인 내용들과 소프트웨어개발의 기본적인 자세에 대해서 생각해보자. 소프트웨어 아키텍처를 알아야 슈퍼프로그래머가 될까? 함께 고민해봅시다.

 

----------------------------------

신현묵 zetlos.tistory.com | 현재 명지병원 정보통신팀 팀장과 헬스로그 이사로 재직하고 있다. 제약, 의료기기 생산업체의 정보시스템 개발 경험과 온라인 게임개발, 대형SI에 이르기까지 경험이 풍부한 자칭 '삽질의 대가'. 현재 기존의 소프트웨어 삽질을 아키텍트로 승화시키려 노력하고 있다. 또한 현재 한국전자정보통신산업진흥회(KEA) 디지털병원수출기획단의 디지털병원 IT관련 실무위원으로도 활동 중이며, 새롭게 출범하는 IT의료융합센터의 자문위원으로도 활동할 예정이며, 독자들과 트위터(@zetlos)를 통한 소통을 즐기고 있다.

 

=========================================

 

원천적으로 가장 중요한 단어인 '소프트웨어'란 과연 무엇일까? 이 가장 기초적인 단어인 '소프트웨어란 무엇인가'에 대해서 다시 한번 생각해보자. 학자나 개인적인 입자에서, 여러가지 설명과 이해가 다르겠지만, 보편적인 부분만 설명한다면. 소프트웨어란 '사용자가 원하는 서비스를 제공하기 위하여 정보기술을 활용하여 정보서비스를 구축하는 것'이라고 규정지을 수 있다. 과연 어떤 단계가 소프트웨어 개발이란 무엇일까? 개발툴을 띄워서 '코딩'을 하는 것만이 소프트웨어개발일까? 소프트웨어 개발을 테스트하고, 품질을 검사하는 단계는 소프트웨어개발이라고 이야기할 수 있는가?

더군다나 '성공적인 소프트웨어 개발'이라는 단계는 어떤 단계일까? 필자는 '성공적인 소프트웨어 개발'을 다음과 같이 표현하고 싶다.

 

소프트웨어 개발자 + 고객 = 성공적인 소프트웨어 개발

 

소프트웨어개발자와 고객간의 의사소통과 필요한 요구사항과 적절한 정보서비스의 개발이 원활하게 이루어진다면, 가장 성공적인 소프트웨어개발이라고 할 수 있겠다. 생각해보면, 고객이 직접 자신이 원하는 소프트웨어개발을 한다면, 더 완벽하지 않을까? (ㅎ.ㅎ) 하지만, 현실적으로는 고객과 개발자의 역할은 분명하게 나뉜다.

하지만, 소프트웨어 개발의 변화가 과거의 1인 중심인 프로그래머가 혼자 모든 것을 다하던 시대에서 설계자와 코더가 나뉘어지고, 다시, 시대의 흐름이나 서비스중심의 구조적인 설계를 하는 아키텍트의 시대에 까지 변화가 많이 발생한다. 소프트웨어 개발의 조직이 정말 방대하고 복잡하게 변했기 때문이다. 고객의 목소리가 실제 개발조직에 전달되어지고, 어떤 단계를 거쳐서 실제 필요한 정보서비스로 변해가는 과정은 정말 블랙박스화 되어버려, 그 누구도 통제하기 어려운 형태로 변했기 때문이다.

이러한 소프트웨어개발과정을 통제하거나 개발자들간의 커뮤니케이션에 대해서 다양한 각도로 생각해보자. 가볍게 설명한다면 이 과정자체가 아키텍팅의 과제이고 단계이다. 이제, 이 지면을 통해서는 소프트웨어 아키텍처의 중요성이 부각된 이유를 설명하고 소프트웨어 아키텍처를 도입함으로써 어떤 목표가 달성될 것인가에 대해서 알아보겠다.

 

소프트웨어개발의 시대를 구분해본다면, 전설의 시대, 고대시대, 중세시대, 근대시대, 현대시대로 나누어서 설명할 수 있게다. 전설의 시대에는 '소스가 곧 라이브러리'이던 시대였다. 그리고, 고대시대는 'binary'기반의 라이브러리 시대라고 할 수 있겠고, 중세시대는 에디터가 존재하던 시대를 거쳐서. 근대시대의 'RAD툴'이 쓰여지면서 소프트웨어 개발을 하던 시대에서. 현대시대는 '서비스'를 중심으로 '프레임웍'의 시대라고 할 수 있겠다.

 

현실적으로 소프트웨어개발이 얼마나 어려운지 몇가지 나열해보자. 현대의 소프트웨어는 정말 많은 기능이 부여되어 있는데다가, 요구되는 기능의 변경은 정말 심하게 발생한다. 또한, 이렇게 구사되어진 소프트웨어 내부구조와 동작은 정말 비가시적이다. 더군다나, 소프트웨어 개발의 진행사항자체가 파악하기가 너무 어렵다. 그래서 일까? 개발비용이나 개발기간의 예측은 거의 도박수준이다. 또한, 정말 다양한 분야의 전문지식과 기술, 경험을 필요로 하는 것이 소프트웨어 개발이다. 거기다가, 컴퓨터 하드웨어/소프트웨어 기술은 정말 급격하게 발전하고 있는데다가, 다른분야의 공학적인 부분이 소프트웨어 공학의 이론단계에서는 아직 미성숙단계에 와있다고 하겠다.

 

좀더 전문적으로 소프트웨어의 특성에 대해서 설명해보자.

첫째. 소프트웨어의 유형적( tangibility )인 형태로 존재한다.

프로그램 코드의 형태로 존재하고 산출물로 가시화할 수 있다는점.

둘째. 소프트웨어의 상호작용 ( dynamic behavior )을 통한 완성

프로그램 자체는 분명 정적인 코드이지만, 소프트웨어자체가 구동되는 동적이고, 프로그램이 하드웨어에 의해 수행되고 사용자와 상호작용할때에 비로소 프로그램이 아닌 소프트웨어가 되는 것.

셋째. 소프트웨어의 상품성은 기본적인 가치이다.

개발된 프로그램은 제품에 불과하지만, 이 소프트웨어가 포장이되고, 사용자가 사용할 가치가 생기므로 상품이 된다.

넷째. 소프트웨어의 견고성은 유연할 수 없는 현실

소프트웨어 개발의 행위는 정말 예측이 어렵고, 수정이 용이하지 않다. 한번 구조성을 잃어버리면, 유지보수는 점점 어려워지워지게 된다. 말그대로 소프트하지 못하고 유연하지 못한 것이 소프트웨어이다.

다섯째. 소프트웨어의 비마모성 때문에 품질은 점차 저하된다.

소프트웨어는 하드웨어와 다르게 마모되지 않으므로, 시대가 변하면서 그 품질자체는 점차 저하되는 현상을 일반적으로 가지게 된다. 더군다나, 구조성을 잃어버리면서 유지보수과정을 거치면서 점점더 품질이 저하되는 특성이 있다.

 

그렇다면, 소프트웨어 개발과정에서의 특성은 어떤 것이 있을까?

 

하나. 소프트웨어 개발은 비제조성이다.

소프트웨어 개발은 말그대로 '개발'이다. '제조', '생산'되는 것이 아니다. 말 그대로 '개발과정'자체가 결국, 그 소프트웨어의 '품질'이 된다. 이러한 기본적인 원리를 무시한체, '공정'과 '생산계획'에 의한 소프트웨어 개발의 품질은 정말 엉망이된다. 성공적인 소프트웨어를 원하는 개발조직이나 고객이라면, 그 '개발과정'자체를 관리해야한다.

둘. 소프트웨어 개발은 비조립성이다.

말그대로 소프트웨어컴포넌트만 조립해서 소프트웨어가 개발되어진다면. 정말 제조업의 형태를 가지겠지만. 아직까지는 소프트웨어 개발은 '조립'이 불가능한 상황이다. '단순조립'이 가능한 시대가 올 수 있지만, 아직까지 그런 시대는 오지 않았다.

셋. 소프트웨어 개발과정은 정말 비과학적이다.

수학과 과학으로 모든 것이 설명될 수 있다면 얼마나 좋을까? 하지만, 소프트웨어개발은 '조직', '인력', '시간', '비용', '절차'와 같은 관리기술적인 요소를 통해서 만들어지는 정말 비과학적인 분야이다.

 

그렇다면, 이러한 소프트웨어 개발을 바라보는 관리자나 고객의 시야를 한번 살펴보자. 가장 잘못되어진 소프트웨어개발을 바라보는 3대 착각과 망상의 현상이 있다.

 

관리자들의 착각.

소프트웨어 개발방법이 '문서'나 '소스'코드에 상세하게 기록이 되어 있으니 개발자들이 어려움을 느끼지 않는다 라는 착각, 하드웨어를 비롯한 다양한 도구들의 개발환경만 좋아지면 개발자들은 불편하지 않을 것이다 라는 착각. 스케쥴이 지연되면 인력을 추가로 투입시키면 된다는 착각, 교육만 잘 시키면 우수한 소프트웨어 개발인력은 손 쉽게 확보 가능하다라는 착각.

사용자들의 착각

시스템의 정의와 개발목표가 정해지면 언제든지 프로그래밍은 착수가능하다는 착각, 요구사항과 상세내역은 발생할때마다 프로그램에 추가하는 것은 언제든지 가능하다라는 착각. 사용자의 요구는 지속적으로 변할 수 밖에 없는 것은 당연하니, 소프트웨어는 유연해서 언제라도 개발 도중에 변경되는 요구사항을 쉽게 수용할 수 있을 것이라는 착각.

개발자들의 착각

프로그램을 코딩하기 시작하고 테스트가 끝나면 개발자의 작업은 완결된다는 착각, 프로젝트가 완료되었을때의 결과는 작동되는 프로그램이다라는 착각. 개발단계에서의 결과물에 대한 검토회(review)는 정말 번거로운 일이라는 착각, 소프트웨어의 유지보수란 결함을 찾아서 수정하는 작업으로 간단한 일이라고 느끼는 착각.

 

필자가 생각하는 소프트웨어공학적인 형태를 표현하면 다음과 같다.

 

 

 

 

이 그림은 소프트웨어공학을 쉽게 설명하기 위해서 만든 그림이다. '소프트웨어공학'을 한마디로 표현하자면. '최소의 경비로 고 품질의 소프트웨어 상품의 개발, 유지보수 및 관리를 위한 모든 기법, 도구, 방법론'을 총칭하는 것이다.라고 표현할 수 있으며, 소프트웨어공학에서는 기법(technique), 방법(method), 방법론(methodology)의 기본으로써, 중요한 관리기법, 개발기법, 그리고. 사람에 대한 커뮤니케이션까지 포괄한 것이 '방법론'에서 이야기하는 중요한 요소일 것이다.

소프트웨어 생명주기 모델과 개발모델들의 발전단계를 살펴보면 폭포수모델->프로토타이핑모델->나선형모델->반복또는 점증적방법->컴포넌트기법과 모델까지 중요한 관점의 변화는 개발자들간의 의사소통과 관리에 대한 중요성을 점차적으로 늘려왔다는 점이다.

소프트웨어아키텍처는 이러한 방법론을 기반으로 한다. 작업절차, 작업방법, 산출물, 기법, 관리, 도구를 기반으로 소프트웨어를 구조적으로 바라보는 관점을 변화시킨다.

필자가 소프트웨어아키텍처를 강의하면서 가장 자주 말하는 것중의 하나는 다음과 같다.

'우리는 람보가 아니다'라는 점이다. 그래서, 정말 세심한 부분까지 고민하고 실천해야한다.

람보처럼 전쟁터에서 총알만 집어던져도 전투에서 승리하는 슈퍼프로그래머와 같은 프로그래머들만이 우리의 개발세계에 존재하지 않는 다는 점이다. 물론, 이런 '람보'같은 개발자들과 호흡하고 같이 일할 수 있다면 그것도 방법이기는 할 것이다. (이런 사람들은 정말 불가사의한 개발능력을 발휘하곤 한다. )

소프트웨어아키텍처를 이야기할때에 또하나 빼먹지 않고 이야기하는 관점은 'IT와 건축'에 대한 이야기이다. 현재의 모든 IT의 설명은 건축 메타포어를 통하고 있다. 심지어, 갑을병정의 사업구조와 형태까지 거의 동일하다. 아무래도, 전산학과의 역사가 짧아서인지는 모르겠지만, 전산학과의 기초중심( 코딩, OS, 자료구조, DB, 알고리즘 )의 교육에서 끝내지만, 건축학과는 기초에서( 미술실기, 구조역학, 건축재료와 기법 등)과 공학 ( 건축사, 건축설계 )등을 기본으로 배운다. 앞으로의 전산학과는 좀더 공학적인 기초교육이 좀더 보강될것으로 예측해본다. 기초위에서 기존에 구축된 시스템을 파헤쳐보고 설계중심의 교육이 이루어지는 방향으로 변할것이라고 생각해본다.

 

현재의 IT현장은 정말 건설현장과 비슷하다 하겠다. 새벽시장에 봉고로 필요한 인력을 구하듯이 거래되는 인력시장이 존재하고, 대기업들은 정말 그 노가다 인력으로 IT의 정보서비스들을 제공한다. 이름하여, '노가다'. 일본어인 dokata에서 만들어진. '공사판노동자','노동자','막일꾼','인부'라는 의미이고, 건축일등의 단순한 노동일을 일컫는 말이며, 특별한 직업이 없는 사람들이 흔히 일당제로 하는일을 의미한다.

우리 소프트웨어 개발자들은 과연 이러한 '노가다'와 어떤 차이가 있는가? 필자는 묻고 싶다. 아파트공사현장에서 등짐을 매는 노가다맨들이 과연 그 아파트를 만든 사람들이라고 이야기할 수 있을까? 아니, 실제 노동현장의 목수도 1층 2층 집은 충분하게 지을 수 있다. 요즘의 도구나 건설재료들은 그러한 구조학적인 설계를 하지 않더라고, 기본지식만으로도 그러한 건물을 지을 수 있다. 하지만, 63빌딩을 올리거나 시드니오페라하우스와 같은 건물은 만들 수 없는 것이다. 그래서. 우리에게 소프트웨어아키텍처는 정말 중요하다.

 

소프트웨어 아키텍쳐란 다음의 두가지가 가장 중요하다.

 

하나. 중요한 부분만 다루어야 한다.

둘. 아키텍트의 역할이 중요하다.

 

아키텍트는 소프트웨어를 개발할 때에 중요한 재료들을 잘 다루어야 한다. 그것은 비용, 적용기술, 조직의 역량, 기능, 목표, 시스템의 복잡도에 대해서 아키텍트의 중요한 판단을 통하여 시스템을 구상하고 추상화하는 방법이다. 이것이 바로 소프트웨어아키텍쳐의 기본적인 것이라고 볼 수 있다. '사용자가 원하는 서비스를 제공하기 위하여 정보기술을 활용하여 정보서비스를 구축하는 행위'인 소프트웨어 개발을 구상하고 추상화 하는 것. 그것이 소프트웨어아키텍처 과정이다. 그러므로, 아키텍트는 '소프트웨어 개발과 관련해 기술적인 판단을 내리는 최고책임자'라고 손쉽게 정의할 수도 있겠다.

건축가가 고객에게 이야기하는 것 '채광을 중시하고, 동서로 걸쳐진 건물에 정원을 배치한다'라는 추상적인 표현이 가능한것과 마찬가지로, 소프트웨어의 구상과 추상화를 완성하는 것이다.

그렇다면 이러한 소프트웨어 아키텍처를 프로젝트의 현실과 대입해보자.

현재 일반적으로 SI환경부터, 소규모개발사이던, 대형개발사이든 많은 개발과 관련되어진 여러 문제들이 존재할 수 있다. 다만, 이러한 문제들이 도출되지 않는 조직에 계시다면 정말 행복한 사람이다. 이곳에서는 소규모 프로젝트라기 보다는 대규모 프로젝트인 경우에 한정을 지어서 생각해보도록 하겠다.

각각의 사례들은 그 규모에 따라 그 형태를 달리하는 경우가 많다.

 

프로젝트 A : EJB를 기반으로한 EAI 제품 개발, 개발기간 3년, 투입인원 팀 4개팀 20명

프로젝트 B : SyncML관련 모바일 솔루션 개발, 개발기간 6개월 투입인원 5명

프로젝트 C : 온라인 게임개발, 개발기간 2년 투입인원 12명 ( 디자이너 제외 )

프로젝트 D : 공공기반 프로젝트, 개발기간 3년 투입인원 연인원 60명, 최대 130명

 

프로젝트의 성공여부는 어디에 달려있는것일까? 누가 성공여부를 결정하는가? 과연 프로젝트는 어떻게 진행되는 것이 맞는가? 과연 방법론의 사용여부는 어디까지이며? 산출물의 작성기준은 어디까지인가?

소프트웨어아키텍트는 이러한 것들을 커다란 개념으로 볼 수 있도록 한다. 예를 들어본 프로젝트들을 살펴보면 프로젝트 A와 B는 패키지 개발이고 실제 소프트웨어의 성향이나 목표에 대한 부분을 결정하는 것은 최고 경영자층과 CTO레벨에서 결정하는 내용이므로 오늘 설명할 내용에서 약간 벗어난다고 할 수 있다.

그리고, 프로젝트 C의 경우에는 일반 고객들을 상대로 하는 프로젝트이기 때문에 해당 프로젝트도 일단, 이 범위에서는 제외한다. 프로젝트 A,B,C에 대한 경험으로 별도의 각각 예제를 따로 준비중이고 아마도, 6회쯤에 해당 내용을 발표할 듯. 일단, 프로젝트 D를 기준으로 한다. 사용자들이 정해져 있고 보통 SI라고 불리우는 사업인 경우이므로 이에 대해서 기술한다. 프로젝트 D의 특징을 기술하면 다음과 같다.

 

하나. 프레임워크나 솔루션이 투입되어 일정한 공수로 개발자들이 투입되어 개발한다.

둘. 기존에 정보시스템이 있거나 대체, 혹은 신규 개발하는 형태이다.

셋. 고객이나 사용자들이 일반사용자들에 가까우므로 IT관련 정보기술에 어둡다.

넷. 고급개발자들을 극소수로 밖에 사용할 수 없으며, 초급개발자들을 주로 사용하게 된다.

다섯. 기간이나 비용등이 영업의 힘으로 결정되는 경우가 다반사이며, 생각보다 제약사항들이 많다.

여섯. 고객의 요구조건을 어떻게 관리하고 품질의 영역이 불명확한 경우가 많다.

 

가장 중요한 요소인 '소프트웨어 품질'에 대해서 아키텍트는 착각하면 안된다. 모든 소프트웨어는 100% 고품질로 만들 수 없다는 점을 깨달아야 한다. 그리고, 고민해야 한다. '과연 모든 모듈을 고품질화 시킬 필요가 있을까?' '유지보수성이 정말 필요한 부분은 어디인가?' '정말 고성능이 필요한 부분은 어디인가?' '기본 규칙만 지키도록 하고 대다수는 자동화하여 템플릿 형태에서 구현이 가능한 부분들은 어디인가?'

또한, 품질의 형태에 따라서 모두 같은 산출물과 문서화가 필요한가? 필자의 경험으로는 20%의 고성능과 80%의 단순함으로 승부하고, '고객'에게 '사용경험'을 어떻게 경험하게 할 것인가를 디자인해야한다는 것이다. 이러한 문제는 바로... '비용', '인력', '솔루션'에서 발생하기 때문이다. 언제나 적절한 비용, 인력, 기간, 솔루션과 기술은 완비되지 않기 때문이다.

또한, 가능한 아키텍트에게 UI와 UX에 대해서 준비하라고 언제나 이야기한다. 모든 정보서비스의 완성은 사용자의 경험에서 얻어지는 비기능적이인 경험에서 결론이 나기 때문이다. 이 부분은 이 소프트웨어아키텍처를 좀더 세분화하여 설명할 기회에 이야기해보도록 하자.

 

프로젝트의 일반적인 경향

 

첫째, 기술적인 결정을 내릴 때 비합리적인 결정을 내리는 경우가 많다.

대부분 기술적인 결정은 경험에 의해 이루어지는 경우가 많다. 그러나 경험적인 해결책이 현재 진행 중인 프로젝트에서 부적절한 경우 또한 대다수인 경우가 많다. 실제로 경험적인 결정만으로는 프로젝트에서 적용할 기술에 어떤 위험이 따르는지 판단하기 어렵다. 하지만, 보통 프로젝트의 경우 경험이 많은 개발자들을 중심으로 PM과 PL이 구성되어 지고 이들중에 PL들선에서 이러한 문제들을 해결하기 위한 미팅이나 회의가 많이 발생한다. 또한 기술적인 결정을 내릴 때 비용과 프로젝트 적합성을 따지지 않고 도입하는 경우가 많다. 이 경우 프로젝트의 기간을 줄이고 품질을 높이기 위해 도입된 기술이 오히려 프로젝트를 지연시키고 시스템의 품질을 떨어뜨린다. 기술적인 의사 결정이 프로젝트 중간에 흔들려서 프로젝트가 지연되는 경우가 종종 발생한다. 이것은 선택된 기술이 프로젝트에서 최적의 선택인지 고민하지 않았기 때문이다. 사용자의 요구사항에 기초하지 않은 의사 결정은 막연한 결과를 만들고 기술적인 의사 결정이 올바른 것인지 프로젝트 후에도 판단하기 어렵다. 의사 결정을 하기 위해 많은 시간을 소요하지만 합리적인 결정을 내리지 못할 때가 많다. 실제 영업적인 이유로 인하여 이와 같은 경우가 발생하는 경우도 다반사이다.

 

둘째, 새로운 프로젝트에서 과거의 경험을 답습하는 경우가 많다.

프로젝트는 전혀 새로운 환경 일때가 많고 프로젝트의 성격에 따라 최적의 선택을 해야 한다. 기술을 어떻게 선택할 것인지에 대한 정형화된 프로세스가 없으며 기술은 계속 변한다. 따라서 과거의 프로젝트 성공에 대한 경험으로 현재의 문제를 해결할 수 없다. 이점을 간과하는 경우가 많다. 따라서 많은 기술을 조합하여 현재 프로젝트를 위한 최적의 해결책을 찾아야 한다. 이 해결책은 사용자의 요구사항에서 논리적으로 도출된 것이어야 하며, 설명가능한 방식이어야 한다.

 

셋째, 과거의 프로젝트에서 배우지 못한다.

이것은 두번째 경우와 정반대의 경우이다. 과거의 프로젝트의 성공과 실패에서 원인 분석을 하지 못하면 성공한 이유도 실패한 이유도 알 수 없다. 프로젝트에서 대부분의 문제는 고객과 개발팀간의 커뮤니케이션 부재 때문에 발생한다. 또한 프로젝트의 범위 관리도 문제가 되며, 사용자의 요구사항을 어떻게 도출하고 관리할 것인가도 문제가 된다. 기술적으로는 시스템의 복잡성이 문제가 된다. 시스템의 복잡성은 개발자의 능력의 한계를 뛰어넘는 것으로 시스템을 복잡성을 줄이고 효율적으로 시스템을 구축하는 방안을 찾아야 한다. 기술적인 복잡성을 줄이고 합리적인 의사결정을 내리기 위해서는 기술적인 의사 결정을 초기에 내리고 적합한지 계속 테스트해야 한다. 또한 초기에 어떻게 프로젝트 조직을 구성할 것인가도 프로젝트 성공에 많은 영향을 끼친다. 역할 분담이 명확하지 않아서 책임 소재를 따지는데 많은 문제가 발생한다. 조직 구성도 프로젝트의 성격과 기술 Set에 따라 달라진다. 프로젝트 팀원들이 도메인을 잘 알고 사용하는 기술에 익숙한 경우와 프로젝트 팀원들이 도메인을 모르고 사용하는 기술도 모를 경우는 조직 구성이 달라져야 한다. 대부분 설계자가 요구사항을 정리하는 것 외에는 제 역할을 하지 못한다. 설계자가 어떤 일을 해야 하며 개발자에게는 무엇을 주어야 하는 지도 결정해야 한다.

 

넷째. 일정의 진실

소프트웨어 개발을 계획하고 관리하는 방법과 시스템은 많다. 정말 많다. 특정결과를 얻으려는 기법들을 모은 집합들. 이 기법들은 모두 조직문제와 프로젝트관리문제를 해결하려 애쓴다. 각 기법들에 각각의 장단점이 모두 다르다. 다만, 아키텍트는 어떤 방법론을 사용하던지, 프로젝트에 성공하려면 기본적으로 익혀야할 개념과 전술이 있다. 그것은, 어느 상황이든, 프로젝트와 팀에 맞게 방법론을 고치고 조율해야 한다는 점이다. 방법론에 치중하기 보다는 더 근본적인 지식에 근접해야한다는 점이다. 소프트웨어개발에 있어서 프로세스와 방법론이 매우 중요하기는 하지만, 프로세스와 방법론 자체가 만병통치약이거나 성공적인 결과를 보장하지는 않는다는 점이다. 필자가 자주쓰는 말이 있다.

 

'개발에 있어 형식에 얽매이는 행위야 말로 삽질이다-꿈꾸는자', 필자의 트위터에 걸려있는 프로필에 있는 말이며, 필자가 운영하는 아키텍트까페에서 이야기하는 첫 번째 교훈이기도 하다. 이론은 이론일뿐, 사람과 커뮤니케이션이 중요성을 잊어버리고, 절차에만 매달리는 행위에 대한 경고이기도 하다.

 

다섯째. 테일러주의를 벗어나지 못한다.

프레드릭 테일러라는 최초의 산업공학자를 대부분 아실 것이다. 공장의 효율성을 연구하여 '산업공학'이라는 분야를 만들었으며, 그의 제자들은 프랭크 길브레스, 릴리어 길브레스, 헨리 갠트와 같은 분들이 있다. 그의 주장의 핵심은 다음과 같다 '과학적 관리'를 중요시한 것이다. 테일러주의식 사회공학의 첫 번째 단계는 '계획'과 '실행'을 분리하는 것이다. 일하는 방법과 일하는데 걸리는 시간을 결정하는 것은 교육받은 공학자들을 통해서 한다. 그들은 작업자들에게 주어진 과업을 할당된 시간 동안 충실히 따르게 하면 모든 일은 잘 된다고 믿는다. 작업자들 자체를 기계부품으로 보는 방법이다. 두 번째 단계에서는 '품질부서'를 두게한다. 테일러는 작업자들은 할 수만 있다면 작업자들은 '꾀'를 부린다고 생각하여 품질부서를 통해서 적절한 속도, 정해진 방식으로 일하는지 확실하게 체크하는 방법을 사용하게 한다. 이런 방식으로 '기획/실행'을 분리하고 '품질부서'를 두게하는 방법은 현재의 소프트웨어 개발에서도 흔하게 쓰는 방식이다. 이 방식자체는 '개발과정'이 단순하다면 의미가 있다. 하지만, 고성능이나 기술지향적인 곳에서는 이런 방식자체는 문제가 있다. 앞에서도 이야기 하였지만, 소프트웨어 개발을 그런 제조업의 공장라인돌리듯이 생각하는 것 자체가 문제이기 때문이다.

 

자. 그렇다면. '성공적인 프로젝트'는 방법론을 잘 지켰는가에 대한 질문에 대해서 어떻게 답해야할까? '그렇다'라고 이야기하는 정답이겠다. 그것은 '방법론'의 '기본'에 충실하였기 때문이라고 이야기하는 것이 많다.

 

국내 프로젝트의 경향

 

첫째, 신기술을 도입하여 무조건 쓰는 경우가 많다.

J2EE가 프로젝트의 성격에 맞는지, CBD가 프로젝트의 성격에 맞는지 고민하여 프로젝트를 위한 최적의 선택을 한 경우가 많지 않으며 신기술에 대한 막연한 기대를 가지고 프로젝트를 시작한다.

둘째, 프로젝트의 복잡성이 증가되고 관리되지 않으면 어느 순간 통제할 수 상황에 빠진다. 이 경우 개발자들이 자체적으로 communication을 통해 해결하는 경우가 많다.

셋째, 프로젝트 초기에 드러나지 않았던 문제들이 프로젝트 마무리 시점에서 드러나는 경우가 많다. 많은 오류가 프로젝트 마무리 시점에서 발생한다.

넷째, 설계자가 제 역할을 못하는 경우가 많음. 단순히 사용자의 요구사항을 정리하여 개발자에게 전달하는 역할만을 함.

다섯째, CASE 툴의 사용이 개발 생산성 향상에 큰 도움이 되지 않음. 개발자들이 시스템을 구축하기 위해 미리 준비되어야 할 많은 사항들을 개발자 스스로 만들어 가는 경우가 많다. 시스템 환경 셋팅, 테스트, 각종 툴 사용 기법, utility 공통 코드, 코딩 표준 등을 개발자 스스로 결정한다.

여섯째, 몇몇 능력 있는 개발자들의 도움을 받아 프로젝트가 진행된다. (결과적으로 프로젝트에서 누군가는 아키텍트의 역할을 함) 그러나 능력 있는 개발자가 자신의 능력을 발휘하는 시점은 프로젝트의 문제가 발생하는 시점에서 이루어지고 개발자의 능력만으로 해결할 수 없을 정도로 이미 문제가 심각해진 경우가 많다. (왜 프로젝트 초기 의사 결정에 이런 사람들을 참여시키지 않는가?) 프로젝트 팀원들이 프로젝트 관리자에게 의사결정을 요구하지만 기술적인 문제는 프로젝트 관리자가 의사결정을 내릴 수 없으며 몇몇 사람들의 의견을 구하거나 의사결정이 이루어지지 않은 채 프로젝트가 진행되는 경우도 있다.

일곱째, 요구사항에 대한 관리가 이루어지지 않는다. 요구사항이 시스템에 얼마 정도의 영향을 미칠 것인지, 아키텍처에는 얼마 정도의 영향을 미칠 것인지 판단하지 못함.

그렇다면 위와 같은 프로젝트의 경우에는 어떻할것인가?

프로젝트를 포기하는 것도 하나의 방법일 수 있다. 혹은, 제약사항을 머릿속에 두고 그와 같은 아키텍쳐를 그려낼 수 있는 방법을 도출하는 것도 방법이다. 어떤 프로젝트이던 최고의 방법은 없다. 최선의 방법만 존재할 뿐. 실제 프로젝트에서는 최고의 비용, 최고의 기간, 최고의 프로그래머와 일하는 것이 아니기 때문이다. 이러한 것들을 해결하기 위하여 무수히 많은 것들이 존재하지만, 이곳에서는 이러한 문제들의 구조를 파악하고 소프트웨어를 제작하기 위한 소프트웨어 아키텍쳐에 대해서 서술해보자. 그리고. 아주 보통 간과하고 넘어가는 경우가 많은데. 다음의 예를 하나 살펴보자. 사용자들이 요구하는 아주 비기능적인 요소들이 있다.

 

'동일 조회업무 화면을 여러 개 보이게 해주세요'

 

자.. 이러한 요구조건을 어떻게 해결해야 하는가? 생각보다 복잡하고 미묘한 문제들이 걸려있다. 어떤 부분인지 살펴보자. 일단, 어떤 사람이 개발한 업무화면이 "N개 동작한다라는 것은 그 업무화면에서 여러 개 동작시키는 매커니즘을 활용하는 방법도 있을것이고, 해당 프레임워크를 제공할 수도 있을 것이고, 아니면, 웹과 마찬가지로 세션을 유지하지 않는 방법을 고려할 수도 있다. 사용자의 기능하나에 의하여 구조적인 모습이 전혀 엉뚱한 모습으로 변할 수 있다.

이러한 요구조건들이 품질요구사항으로 변하고 실제 소프트웨어의 아키텍쳐와 프레임워크, 솔루션의 도입, 개발자들의 가이드라인, 컴포넌트의 구성방식, 유지보수 방법등에 많은 영향을 주게된다. 이 부분을 간과하고 넘어간 경우를 살펴보자. 업무 분석을 하고 설계, 개발, 단위테스트, 통합테스트, 배포까지 무난하게 넘어갔다고 보자. 그런데, 실제 사용자가 요구한 것은 '전체 업무의 형태를 위와 같이 N개 동작하게 해달라'는 요구사항이었다고 나중에 밝혀졌다고 보자.

설계자는 요구조건에 맞는 프레임워크가 아니었다고 이야기 할 것이고, 개발자는 세션을 유지하는 C/S 프로그램으로 만들어 놨고, 공통 함수로 처리되는 방식으로 빠르게 개발할 것만 고려하고 플밍이 되었다고 보자.

과연 누구의 잘못인가? 이것이야 말로 아키텍트가 초기에 소프트웨어 아키텍쳐를 잘못설계한 케이스이다. 처음부터 이러한 상황을 고려하여 동작 가능한 구조로 만들어 주었다면, 문제가 발생하지 않았을 것이다. 개발자가 컴포넌트 개발도 할줄 모르는 공통함수개념과 화면별 단위 프로그램밖에 만들줄 모르는 개발자였다면, 해당 개발자들이 해당 요구조건을 모르고 코딩을 해도 실제 수행시에 아무 문제 없도록 시스템 메커니즘을 구현하였어야 했다. 해결방법은 아주 많은 방법들이 있다.

 

그렇다면, 설계와 SA의 차이점은 과연 무엇일까?

물론, 공통점은 '요구사항을 만족시키기 위한 해법을 제시한다'라는 측면에서는 같다. 차이점은 '아키텍트의 관점은 좀더 큰 그림을 보고, 설계는 미시적인 관점이다'라고 쉽게 설명할 수 있겠다. 아키텍트는 좀더 기능적인 요구사항이나 품질요소등에 대해서 구분하고 있게 된다. 이러한 관점의 차이는 설계나 방법론, 산출물에게도 영향을 준다.

바로, 품질속성(Quality Attribute)를 결정하고 그 품질속성을 관리하는 것이 SA가 가지는 가장큰 차이점이라고 하겠다. PM과 SA에 대한 차이점도 몇가지 언급해보자.

 

 

소프트웨어 아키텍처를 도입하면서 달성되는 목표

 

소프트웨어 아키텍처를 도입함으로써 다음과 같은 목표를 달성할 수 있도록 한다. 그 목표는 크게 다음의 세가지로 들 수 있다.

 

첫째, 견고하고 안정적이며 고품질의 시스템을 구축할 수 있다.

둘째, 시스템 구축 시 발생하는 문제들을 초기 단계에서 해결할 수 있다.

셋째, 아키텍트의 역할을 명확히 정의하여 20%의 고급 인력으로 80%의 프로젝트 인원을 리딩할 수 있다.

 

아키텍트는 비용과 목표에 대해서 가장 많은 고민을 하여야 한다. 최고의 개발자들로만 구성하여도 프로젝트는 실패할 수 있다. 튼튼하고 품질 좋고 나중에 문제 발생하지 않고, 비용이 적게든다면 최선이지 않은가?

 

 

그림2는 소프트웨어 아키텍처 도입 시 시스템 개발 프로젝트에서 어떤 도움을 받을 수 있는지를 한눈에 보여준다.

 

첫째, 소프트웨어 아키텍처 도입 시 아키텍처의 품질을 평가하여 비합리적인 의사 결정이 합리적인 의사 결정으로 변경된다.

둘째, 과거의 경험을 답습하거나 과거의 사례에서 배우지 못했던 것에서 소프트웨어 아키텍처를 재사용함으로써 과거 프로젝트의 성공과 실패 사례를 배우는 것으로 변경된다.

셋째, 프로젝트의 복잡성을 아키텍처를 통해 관리하는 것이 가능해진다.

넷째, 프로젝트 마무리 시점에서 발생하는 문제들을 아키텍처를 도입하여 프로젝트 초기에 해결할 수 있다.

다섯째, 설계자가 단순히 요구사항을 개발자에게 전달하는 것을 아키텍처를 통해 설계자가 요구사항 분석뿐 아니라 기술적인 문제도 모델링 할 수 있게 하며 개발자는 더욱 효율적으로 시스템을 구현하는 것이 가능하다.

 

소프트웨어 아키텍처의 목적

첫째, 아키텍트가 프로젝트 시작 시점에서 투입되어 무엇을 하는지 시나리오를 작성할 수 있게 하며

둘째, 소프트웨어 아키텍처가 개발 프로젝트에 정착될 수 있도록 하고

셋째, 아키텍트의 역할에 대해서 정의를 하며

넷째, 아키텍트와 프로젝트의 구성 요소 사이의 관계에 대해서 이해를 한다.

다섯째, 소프트웨어 아키텍처가 포함된 개발 프로젝트의 프로세스는 무엇인가에 대해서 알아보고

여섯째, 아키텍트가 프로젝트에서 결정해야 할 항목은 무엇인가에 대해서 고민하는 것이다.

 

소프트웨어 아키텍처 란?

 

본격적인 소프트웨어 아키텍쳐의 개념에 대해서 알아보도록 하자. 소프트웨어 아키텍쳐란 무엇이며, 아키텍트란 누구이며, 그의 역할과, 소프트웨어 아키텍쳐를 통하여 개발 프로세스와 어떤 영향을 가지며, 소프트웨어 아키텍쳐와 다른 아키텍쳐가 어떤 관계를 가지는가에 대해서 알아봐야 한다. 이 부분은 다른 필자들이 좀더 자세하게 설명할 것이다.

 

소프트웨어 아키텍처의 정의

가장 먼저 다른 사람들의 소프트웨어 아키텍쳐에 대한 정의에 대해서 알아보고 이 곳에서 사용할 소프트웨어 아키텍쳐의 정의에 대해서 알아보도록 한다. 아직도 소프트웨어 아키텍쳐에 대한 "정의는 무수히 많은 곳에서 정의되고 정답자체가 아직은 모호한 분야라고 할 수 있으므로, 각자 머릿속에 그 "정의를 선택하거나 정의할 수 있고, 그 부분들에 대해서 생각해 봐야 한다.

 

소프트웨어 아키텍처의 정의들

 

고전적인 정의

 

Rational Unified Process, 1999 Perry and Wolf, 1992 Garlan and Shaw, 1993 Bass, er al., 1994 Hayes-Roth, 1994 Garlan and Parry, 1995 Boehm, et al., 1995 Soni, Nord, and Hofmetster, 1995 Shaw, 1995

 

ANSI/IEEE Std 1471-2000정의

 

Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. This de.nition is intended to encompass a variety of uses of the term architecture by recognizing their underlying common elements. Principal among these is the need to understand and control those elements of system design that capture the system's utility, cost, and risk. In some cases, these elements are the physical components of the system and their relationships.

 

Bass, Clements, Kazman의 정의

 

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

The term also refers to documentation of a system's software architecture. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects

Bass, Len; Clements, Paul; & Kazman, Rick. Software Architecture in Practice, Second Edition. Boston, MA: Addison-Wesley, 2003 "프로그램 또는 연산 시스템의 소프트웨어 아키텍처는 소프트웨어 구성요소와 구성요소의 외부로 보이는 속성 그리고 그 구성요소간의 관계로 이루어진 구조 또는 시스템의 구조이다. " " 그리고 아키텍처의 문서화와 관련된다. 상위단계의 디자인에 관한 초기 의사 결정 사항과 프로젝트간의 패턴과 디자인의 재사용을 허용하기 위해 기록한 아키텍처의 문서화는 이해당사자간의 의사소통을 진행시킨다. "

 

Dewayne E. Perry, Alexander L. Wolf의 정의

소프트웨어 아키텍처는 특별한 형태를 가진 아키텍처 구성 요소들의 집합이다. 아키텍처 구성 요소는 세가지로 구분된다. 프로세스 구성 요소, 데이터 구성 요소, 연결 구성 요소로 구분된다.

 

 Galarn and Perry의 정의

소프트웨어 아키텍처는 프로그램이나 시스템의 구성 요소들 사이의 구조, 관계, 설계와 시스템 업그레이드를 통제하는 지침과 원칙이다.

 Booch의 정의

소프트웨어 아키텍처는 소프트웨어의 구조에 대한 중요한 의사 결정의 집합이다. 이 의사 결정에는 소프트웨어 구성 요소에 대한 선택, 인터페이스에 대한 선택, 이 구성 요소들 사이의 상호작용, 더 큰 서브시스템을 구성하기 위한 구성 요소와 상호작용의 결합으로 이루어진다.

 Myron Ahn의 정의

소프트웨어 아키텍처는 모듈, 프로세스, 데이터, 이들의 구조, 구성 요소들 사이의 관계, 이 구성요소와 관계들이 어떻게 확장되고 수정될 수 있는지, 사용하는 기술은 무엇 인지로 이루어져 있으며 소프트웨어 아키텍처를 통해 시스템의 유연성과 성능을 판단 할 수 있고 시스템을 어떻게 구현하고 수정할 수 있는지를 판단할 수 있다.

 

위의 같은 다양한 정의가 존재하므로 자신만의 정의를 만들거나 선택해보라, 실제적으로 이 개념들은 하고자하는 프로젝트에 따라 다르게 존재할 수 있다. 소프트웨어아키텍처에 대한 정의는 결국, 아키텍트들이 가지고 있는 정의에 따라서 다양한 관점으로 해석될 수 있는 것이지 정해져있는 '개념'과 '단어'가 아니다. '건축설계'를 '단어'로 설명할 수는 있겠지만, 그 행위 자체를 정의할 수 없기 때문이다. 그래도, 필요하다고 한다면, 약간의 정의를 해보자.

 

소프트웨어 아키텍처에 대한 정의

위의 정의들을 요약하여 소프트웨어 아키텍처를 다음과 같이 정의하여 보자. 소프트웨어 아키텍처는 시스템의 핵심 구성 요소와 구성 요소들 사이의 연결 관계로 이루지므로. 핵심 구성 요소는 시스템이 가지고 있는 모듈, 모듈 사이의 연결, 시스템의 변경, 진화하기 위한 기술적인 원칙, 모듈들 사이의 상호작용, 시스템이 동작하기 위한 기술을 모두 포함하는 것으로 정의한다. 즉 소프트웨어 아키텍처는 구현할 시스템에 대한 top-down view이며 시스템에 대한 기술적인 명세서이며 공학적인 청사진이다. 기본적인 개념은 MDA에서 취하고 있는 방향과 유사하다.

 

소프트웨어 아키텍처의 구성 요소

소프트웨어 아키텍처의 구성요소에 대해서 상세하게 살표보면 다음과 같은 구성 요소로 이루어짐을 알 수 있다.

 시스템의 구성요소와 구성 요소 들 사이의 연결 관계

 시스템의 설계와 진화를 통제하는 원칙과 가이드라인

 시스템 구성 요소들의 collaboration ( 성과 )

 시스템이 어떻게 확장되고 수정될 것인가에 대한 결정

 시스템의 구성 요소들이 가지고 있는 기술

다음 그림은 소프트웨어 아키텍처의 구성요소를 보여준다.

 

 

그림5를 보면 소프트웨어 아키텍처는 세가지로 구분된다.

 

Meta-Architecture는 아키텍처를 설계하기 위한 일반적인 지침이다. Meta-Architecture는 소프트웨어 아키텍처가 무엇인지 결정하고 아키텍처를 설계하기 위한 일반적인 의사 결정 트리와 아키텍트의 역할에 대한 정의, 아키텍처 문서에 대한 템플릿으로 구성된다.

소프트웨어 아키텍처는 네 가지 View인 module view, component&connector view, allocation view, code view로 구성된다. 또한 아키텍처 설계의 결과로 컨텍스트 다이어그램, 컴포넌트 명세, 인터페이스 명세가 도출되어야 한다.

View에 대해서는 사람마다 정의하는 방법이 다양하므로 이에 대한 논란은 나중에 하도록 하고, 먼저 그냥 서술해보자. 이 View는 사람들마다 서술하는 방법, 기술하는 방법, 다이어그램의 형태, 박스/라인/인터페이스/컴포넌트의 수준과 깊이/의미등이 다 다르다.

다만, View의 선정 기준과 기술할 때 주의점만 살펴보면된다.

건축물을 설계할때의 조감도 및 설계도, 세부 설계도, 투시도 등등의 형태와 동일하다고 보면 된다, 필요수준까지만 각자 알아서 그리면 되는 것이다. 일반적인 view는 3가지이다. Allocation View, Component & Connector View, Module View라 이야기하지만 저는 Code view를 하나 더 구분해야 한다고 본다. 너무 상세한 설명은 나중에 거론하기로 하고 하여간 4개의 View가 있다고 보자. 이 부분은 적어도 1개 이상에 대해서 기술하고 몇 개가 적절한 가는 개발자들의 역량과 도메인에 대한 이해, 이전 프로젝트의 경험 및 주요 이슈 사항등의 요소에 의해서 좌우되어진다. 다만, 시스템의 큰 기능, 품질 속성 ( 가용성, 변경성, 보안성, 성능 )의 판단 근거가 되어야 하며, 주요 모둘의 기능이 내/외부와 어떤 연관성을 가지는지 보여야 하고, 시스템의 규모와 범위를 파악할 수 있으면 된다. 또한, 위와 같은 아키텍쳐 기술 정의서를 구축할 때에 타당한 근거를 서술할 수 있으면 된다. 다만, 이 View를 UML 1.x영역에서는 표현하기 힘들었다. 너무 기술에 종속적인 패턴의 설계 혹은 컴포넌트의 배치 레벨에서의 작성이 주였기 떄문이다. UML 2.0울 구성할때에 OMG에서 카네기 멜론 SEI의 아키텍쳐 정의를 상당부분 도입하여서 이 부분들에 대한 기술이 이젠 수월해진 편이다. OMG는 재미있는 기관이다. 좌우당간… 가이드라인과 정책은 소프트웨어 아키텍처를 결정한 후 아키텍처를 기반으로 프로젝트를 진행하기 위한 가이드라인과 정책을 말한다. 아키텍트는 설계, 코딩, 배포, 통합, 테스트, 툴, 유지보수, 시스템 확장, 시스템 운영에 대한 가이드라인과 정책을 마련해야 한다. 정말 포괄적인 개발정책 부분을 모두 서술하고 결정한다는 것이다. 소프트웨어 아키텍처는 시스템 개발의 여러 구성요소와 관련을 갖는다. 프로젝트 조직, 프로젝트 스케줄, 형상 관리 계획은 소프트웨어 아키텍처에 근거하여 결정된다. 소프트웨어 아키텍처를 설계하는 데는 프로토타입, 프레임워크, 유틸리티 프로그램 등이 영향을 끼친다.

 

소프트웨어 아키텍처의 특징

소프트웨어 아키텍처의 특징은 다음과 같다. 첫째, 소프트웨어 아키텍처는 시스템에 대한 추상화이다. 따라서 지엽적인 정보는 포함하지 않는다. 큰 그림만을 가지고 있는다.

둘째, 소프트웨어 아키텍처는 한가지 다이어그램으로는 결정되지 않으며 여러 관점의 다이어그램으로 이루어진다. 각각의 세부적인 것이 아니라, 건축물의 투시도와 같으며, 옷 디자이너의 스케치와 유사한 성격을 가진다.

 

소프트웨어 아키텍처의 역할

 

소프트웨어 아키텍처가 시스템 개발에서 담당하는 역할은 다음과 같다고 볼 수 있다. 첫째, 관련 당사자들 사이의 의사 소통의 수단이다. 둘째, 개발 프로젝트 초기 단계에서 의사결정 도구이다. 아키텍처는 품질 요소를 결정하며 프로젝트 조직에 영향을 끼친다. 셋째, 시스템의 전체 구조를 결정한다. 넷째, 개발 프로젝트의 조직을 결정하는데 참고할 수 있다. 다섯째, 시스템이 가져야 할 품질 요소를 결정한다. 따라서 아키텍처를 통해 시스템이 어떤 품질을 가질 것인지 예측할 수 있다. 여섯째, 아키텍처를 통해 시스템 개발자들에게 어떤 교육을 시킬 것이지 결정할 수 있다. 일곱째, 소프트웨어의 변경 사항을 어떻게 관리할 것인지를 알려준다. 상당한 역할이지 않은가? 이를 도식화 하면 다음과 같은 그림이 만들어진다.

 

 

소프트웨어 아키텍처가 시스템 구축 시 담당하는 역할을 보여준다.

기능적, 비기능적 요구사항은 소프트웨어 아키텍처를 설계하는데 입력 산출물로 작용한다. 소프트웨어 아키텍처가 결정되면 설계패턴과, 설계 가이드라인을 사용하여 소프트웨어를 설계할 수 있다. 또한 소프트웨어 아키텍처가 결정되면 코드 작성시 코드 표준, 코드 가이드라인을 제공할 수 있다. 또한 소프트웨어 아키텍처는 소프트웨어를 시스템에 배포 시에 가이드라인을 제공한다. 이를 반복에 의해서 구조적으로 안정적인 소프트웨어 아키텍쳐를 구성할 수 있다

 

소프트웨어 아키텍처에 포함되지 않는 것

소프트웨어 아키텍처는 하드웨어, 네트워크, 물리적인 시스템에 대한 아키텍처를 포함하지 않는다. 따라서 소프트웨어 아키텍처 설계서는 시스템 안에 포함된 소프트웨어 만을 보여주며 시스템은 컨텍스트로서만 표현된다. 예를 들어 하드웨어 모델명, 하드웨어 구성, 라우터, 랜카드에 대한 정보는 소프트웨어 아키텍처에 포함되지 않는다. 이를 그린다는 것은 그 것에 종속된다는 의미이므로 "추상화하려면 해당 정보가 표시되면 안된다는 것이

다. 세부적인 구현 사항은 소프트웨어 아키텍처에 포함되지 않는다. 예를 들어 컴파일러 옵티마이제이션, DLL을 shared로 할 것인지, static으로 할 것인가는 소프트웨어아키텍처에 포함되지 않는다. 이는 별도의 의사결정과정과 후반부에서 처리한다.

 

맺음말...

 

소프트웨어아키텍처에 대해서 아주 기본적인 정의 몇가지를 이야기하는 시간을 가져봤다. 보다 본격적인 내용들은 향후 지면을 통해서 좀더 자세하게 설명할 기회를 가질것으로 생각해본다. 마지막으로 필자의 트위터 프로필에 있는 말로 마무리하고 싶다.

 

'개발에 있어 형식에 얽매이는 행위야 말로 삽질이다.'

Posted by 꿈꾸는자의 생각의파편들