I      연구배경

연구배경에서는 소프트웨어 아키텍처의 중요성이 부각된 이유를 설명하고 소프트웨어 아키텍처를 도입함으로써 어떤 목표가 달성되는지 설명한다. 마지막으로 본 문서의 목적을 설명한다.

1  프로젝트의 현실

이 장에서는 프로젝트의 진행 중에 발생하는 현실적인 문제들을 나열한다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.2 국내 프로젝트의 경향

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

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

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

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

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

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

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

2  소프트웨어 아키텍처를 도입함으로써 달성되는 목표

소프트웨어 아키텍처를 도입함으로써 다음과 같은 목표를 달성할 수 있다.

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

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

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

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /?>

그림 Ⅰ- 1. 아키텍처 적용 시 장점

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

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

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

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