본문 바로가기

Dev.../소프트웨어 아키텍처

[SA강좌] Part 1-1 시작배경

이 문서는 제가 운영하는 SA까페에있는 내용을 정리하여 블로그에 재오픈하는 내용입니다. 몇가지 내용을 첨삭하여서 올리는 내용으로 많은 분들이 읽으시고 참조하신다면 저도 즐겁고 보는 분들도 즐거울듯 합니다.

요즘들어 아키텍트나 SA에 대해서 많이 이야기가 되고 있는데... 그 전반적인 것에 대해서 한번 정리하고 가능하면 쉽게 설명하려고 애썼는데...  문서나 강좌를 해보니... 많이 어렵습니다. ~.~

그래도... 많은 분들이 보셨으면 해서.. 다시 한번 정리합니다. ~.~
 


소프트웨어 아키텍처 Part 1

I
     
시작
배경

문서에는 소프트웨어 아키텍쳐에 대한 전반적인 소개자료와 기초개념에 대해서 설명하고 있다.

먼저, 소프트웨어 무엇인가에 대해서 다시한번 생각해보자.

여러가지 설명과 이해가 다르겠지만, 보편적인 부분만 설명한다면.

소프트웨어란 사용자가 원하는 서비스를 제공하기 위하여 정보기술을 활용하여 정보서비스를 구축하는 이라고 규정지을 있다.

   소프트웨어개발에 있어서 수많은 시간이 흘러왔으며, 그 작업을 하기 위한 다양한 방법론들과 시도들이 진행되어왔었다. 더더군다나,
소프트웨어 개발시의 가장 큰변화는, 과거의 1 중심인 프로그래머가 혼자 모든 것을 다하던 시대에서 설계자와 코더가 나뉘어지고, 다시, 시대의 흐름이나 서비스중심의 구조적인 설계를 하는 아키텍트의 시대에 까지 많은 변화와 발전이 있었다는 점이다.

여기서는 소프트웨어 아키텍처의 중요성이 부각된 이유를 설명하고 소프트웨어 아키텍처를 도입함으로써 어떤 목표가 달성될 것인가에 대해서 알아본다.

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

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

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

아키텍트는 소프트웨어를 개발할 때에 중요한 재료들을 다루어야 한다. 그것은 비용, 적용기술, 조직의 역량, 기능, 목표, 시스템의 복잡도에 대해서 아키텍트의 중요한 판단을 통하여 시스템을 구상하고 추상화하는 방법이다.

이것이 바로 소프트웨어아키텍쳐이다.

! 그렇다면.. 현실은 어떠한가?

1.1 프로젝트의 일반적인 경향

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

대부분 기술적인 결정은 경험에 의해 이루어지는 경우가 많다. 그러나 경험적인 해결책이 현재 진행 중인 프로젝트에서 부적절한 경우 또한 대다수인 경우가 많다. 실제로 경험적인 결정만으로는 프로젝트에서 적용할 기술에 어떤 위험이 따르는지 판단하기 어렵다.

하지만, 보통 프로젝트의 경우 경험이 많은 개발자들을 중심으로 PM PL 구성되어 지고 이들중에 PL들선에서 이러한 문제들을 해결하기 위한 미팅이나 회의가 많이 발생한다.

또한 기술적인 결정을 내릴 비용과 프로젝트 적합성을 따지지 않고 도입하는 경우가 많다. 경우 프로젝트의 기간을 줄이고 품질을 높이기 위해 도입된 기술이 오히려 프로젝트를 지연시키고 시스템의 품질을 떨어뜨린다.

기술적인 의사 결정이 프로젝트 중간에 흔들려서 프로젝트가 지연되는 경우가 종종 발생한다. 이것은 선택된 기술이 프로젝트에서 최적의 선택인지 고민하지 않았기 때문이다.

사용자의 요구사항에 기초하지 않은 의사 결정은 막연한 결과를 만들고 기술적인 의사 결정이 올바른 것인지 프로젝트 후에도 판단하기 어렵다.

의사 결정을 하기 위해 많은 시간을 소요하지만 합리적인 결정을 내리지 못할 때가 많다.

실제 영업적인 이유로 인하여 이와 같은 경우가 발생하는 경우도 다반사이다.

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

프로젝트는 전혀 새로운 환경 일때가 많고 프로젝트의 성격에 따라 최적의 선택을 해야 한다. 기술을 어떻게 선택할 것인지에 대한 정형화된 프로세스가 없으며 기술은 계속 변한다. 따라서 과거의 프로젝트 성공에 대한 경험으로 현재의 문제를 해결할 없다. 이점을 간과하는 경우가 많다.

따라서 많은 기술을 조합하여 현재 프로젝트를 위한 최적의 해결책을 찾아야 한다. 해결책은 사용자의 요구사항에서 논리적으로 도출된 것이어야 하며, 설명가능한 방식이어야 한다.

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

이것은 두번째 경우와 정반대의 경우이다. 과거의 프로젝트의 성공과 실패에서 원인 분석을 하지 못하면 성공한 이유도 실패한 이유도 없다.

프로젝트에서 대부분의 문제는 고객과 개발팀간의 커뮤니케이션 부재 때문에 발생한다. 또한 프로젝트의 범위 관리도 문제가 되며, 사용자의 요구사항을 어떻게 도출하고 관리할 것인가도 문제가 된다.

기술적으로는 시스템의 복잡성이 문제가 된다. 시스템의 복잡성은 개발자의 능력의 한계를 뛰어넘는 것으로 시스템을 복잡성을 줄이고 효율적으로 시스템을 구축하는 방안을 찾아야 한다. 기술적인 복잡성을 줄이고 합리적인 의사결정을 내리기 위해서는 기술적인 의사 결정을 초기에 내리고 적합한지 계속 테스트해야 한다.

또한 초기에 어떻게 프로젝트 조직을 구성할 것인가도 프로젝트 성공에 많은 영향을 끼친다. 역할 분담이 명확하지 않아서 책임 소재를 따지는데 많은 문제가 발생한다. 조직 구성도 프로젝트의 성격과 기술 Set 따라 달라진다. 프로젝트 팀원들이 도메인을 알고 사용하는 기술에 익숙한 경우와 프로젝트 팀원들이 도메인을 모르고 사용하는 기술도 모를 경우는 조직 구성이 달라져야 한다.

대부분 설계자가 요구사항을 정리하는 외에는 역할을 하지 못한다. 설계자가 어떤 일을 해야 하며 개발자에게는 무엇을 주어야 하는 지도 결정해야 한다.

1.1 국내 프로젝트의 경향

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

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

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

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

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

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

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

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

프로젝트를 포기하는 것도 하나의 방법일 있다. 혹은, 제약사항을 머릿속에 두고 그와 같은 아키텍쳐를 그려낼 있는 방법을 도출하는 것도 방법이다.

어떤 프로젝트이던 최고의 방법은 없다. 최선의 방법만 존재할 . 실제 프로젝트에서는 최고의 비용, 최고의 기간, 최고의 프로그래머와 일하는 것이 아니기 때문이다.

이러한 것들을 해결하기 위하여 무수히 많은 것들이 존재하지만, 이곳에서는 이러한 문제들의 구조를 파악하고 소프트웨어를 제작하기 위한 소프트웨어 아키텍쳐에 대해서 서술해보자.

그리고. 아주 보통 간과하고 넘어가는 경우가 많은데. 다음의 예를 하나 살펴보자.

사용자들이 요구하는 아주 비기능적인 요소들이 있다.

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

.. 이러한 요구조건을 어떻게 해결해야 하는가? 생각보다 복잡하고 미묘한 문제들이 걸려있다. 어떤 부분인지 살펴보자.

일단, 어떤 사람이 개발한 업무화면이 ‘N’ 동작한다라는 것은 업무화면에서 여러 동작시키는 매커니즘을 활용하는 방법도 있을것이고, 해당 프레임워크를 제공할 수도 있을 것이고, 아니면, 웹과 마찬가지로 세션을 유지하지 않는 방법을 고려할 수도 있다.

사용자의 기능하나에 의하여 구조적인 모습이 전혀 엉뚱한 모습으로 변할 있다.

이러한 요구조건들이 품질요구사항으로 변하고 실제 소프트웨어의 아키텍쳐와 프레임워크, 솔루션의 도입, 개발자들의 가이드라인, 컴포넌트의 구성방식, 유지보수 방법등에 많은 영향을 주게된다.

부분을 간과하고 넘어간 경우를 살펴보자.

업무 분석을 하고 설계, 개발, 단위테스트, 통합테스트, 배포까지 무난하게 넘어갔다고 보자. 그런데, 실제 사용자가 요구한 것은 전체 업무의 형태를 위와 같이 N 동작하게 해달라 요구사항이었다고 나중에 밝혀졌다고 보자.

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

과연 누구의 잘못인가?

이것이야 말로 아키텍트가 초기에 소프트웨어 아키텍쳐를 잘못설계한 케이스이다.

처음부터 이러한 상황을 고려하여 동작 가능한 구조로 만들어 주었다면, 문제가 발생하지 않았을 것이다.

개발자가 컴포넌트 개발도 할줄 모르는 공통함수개념과 화면별 단위 프로그램밖에 만들줄 모르는 개발자였다면, 해당 개발자들이 해당 요구조건을 모르고 코딩을 해도 실제 수행시에 아무 문제 없도록 시스템 메커니즘을 구현하였어야 했다.

해결방법은 아주 많은 방법들이 있다.


 


1  프로젝트의 현실

현재 일반적으로 SI이든 소규모개발사이던, 대형개발사이든 다음과 같은 문제들이 존재할 있다. 다만, 이러한 문제들이 도출되지 않는 조직에 계시다면 정말 행복한 사람이다.

이곳에서는 소규모 프로젝트라기 보다는 대규모 프로젝트인 경우에 한정을 지어서 생각해보도록 하겠다. 각각의 사례들은 규모에 따라 형태를 달리하는 경우가 많다.

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

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

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

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

프로젝트의 성공여부는 어디에 달려있는것일까?
   
누가 성공여부를 결정하는가?
   
과연 프로젝트는 어떻게 진행되는 것이 맞는가?

과연 방법론의 사용여부는 어디까지이며?
  
산출물의 작성기준은 어디까지인가?

소프트웨어아키텍트는 이러한 것들을 하나의 관점으로 바라 있도록 한다.

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

그리고, 프로젝트 C 경우에는 일반 고객들을 상대로 하는 프로젝트이기 때문에 해당 프로젝트도 일단, 범위에서는 제외한다. 프로젝트 A,B,C 대한 경험으로 별도의 각각 예제를 따로 준비중이고 아마도, 차후에 해당 내용을 발표할 듯 하다.

일단, 프로젝트 D 기준으로 한다. 사용자들이 정해져 있고 보통 SI라고 불리우는 사업인 경우이므로 이에 대해서 기술한다.

프로젝트 D 특징을 기술하면 다음과 같다.

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

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

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

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

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

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

이러한 프로젝트들을 기준으로 세부적인 내용을 기술한다. 강의에서 이야기하는 프로젝트 이러한 부분들을 중심으로 기술한다.