개발 아키텍처 소개
소프트웨어가 복잡해지면서 알고리즘과 자료 구조 수준을 넘어서 소프트웨어의 구조, 즉 아키텍처가 중요한 문제가 되었습니다. 아키텍처는 애플리케이션을 어떻게 분할하고 분할된 컴포넌트에 어떤 기능을 할당하며, 컴포넌트 사이의 커뮤니케이션 방법, 컴포넌트의 물리적 배치 등 설계안을 결정하는 작업입니다. 아키텍처는 시스템의 타입에 따라 다르며 많이 사용되는 유 형(스타일)이 있습니다. 설계 작업은 문서로 잘 정리되어야 하며 이는 구현을 위한 도면이 됩니다.
요구사항 분석 작업을 통하여 무엇을 개발할 것인가를 결정한 후에는 도메인 영역의 문제에 집중하여 모델링 할 수 있습니다. 설계 단계로 넘어가면서 솔루션 영역의 과제들, 예를 들면 소프트웨어의 내부 구조를 어떻게 할 것인지, 자료와 사용자 인터페이스를 어떻게 만들 것인지를 정해야 합니다. 즉 요구 분석 명세서에 기술된 기능을 여러가지 제한 요건(이를 비기능적 요구라 함)에 맞도록 설계하는 일이 필요하다.
요구 분석서는 시스템이 해결하려는 문제에 대하여 기술한 것입니다. 설계는 분석서에 기술된 문제를 해결 방안으로 바꾸는 작업입니다. 분석과 설계의 차이를 이해하기 위하여 다시 건축 설계 작업을 상상해 봅시다. 집주인의 요구는 침실 셋, 거실, 서재, 주방, 냉난방 시설, 수도와 전기, 욕실 등이었다. 설계사는 이러한 요구를 받아 집을 설계합니다. 거실은 아래층 중앙, 침실은 위층, 주방과 서재는 북쪽 아래층, 다용도실을 추가하는 등 설계 도면이 만들어졌습니다. 완성된 설계는 요구를 만족하는 특정한 솔루션이라 할 수 있습니다. 여러 가지 다른 솔루션이 있을 수 있습니다. 예를 들어 거실을 크게 하기 위하여 방을 작게 할 수도 있고 주방을 더 넓게 하기 위하여 거실을 축소할 수도 있습니다. 또한 건축 구조의 스타일을 달리할 수도 있습니다. 2층의 벽돌집 형태로 설계할 수도 있고 스틸 구조의 단층, 또는 타운 하우스 형태의 구조를 채택할 수도 있습니다. 제안된 설계는 모두 문제에 대한 솔루션입니다.
소프트웨어 설계도 같은 관점으로 생각할 수 있습니다. 문제를 정의하기 위하여 요구 명세서를 작성합니다. 모든 요구를 만족한다면 문제에 대한 솔루션이라고 할 수 있습니다. 문제에 대하여 솔루션이 되는 설계 방안은 제한이 없습니다. 결국 설계는 여러 가지 대안 중에 여러 가지 제약 조건을 잘 만족시킬만한 하나의 솔루션을 선택하는 작업입니다.
여러 방안에서 선택하는 일이나 다른 방안으로 변경하는 것은 정해진 원칙이나 필요에 기초하여야 합니다. 집주인이 식구가 더 늘어날 것을 예상하여 설계 변경을 요구했다면 요구의 변경에 의한 것이다. 또한 여러 건축설계 방안 중에서 최종안을 결정할 때는 특정한 구조가 비용이 적게 든다든지 확장이 용이하다는 원칙을 반영하여야 합니다.
분석된 요구를 실행 시스템으로 바꾸기 위하여 설계사는 사용자와 개발자를 동시에 만족시켜야 합니다. 사용자는 설계를 보고 시스템이 어떤 기능을 하는지 이해하여야 하며 동시에 개발자는 시스템이 어떻게 동작하는지 이해하여야 합니다. 마치 시공자가 전기배선, 배관, 지붕설치, 보온 및 방화재 설치를 위하여 설계도면을 보듯이 프로그래머가 소프트웨어 설계서를 보고 시스템을 구현할 수 있어야 합니다.
설계는 일반적으로 창조적인 작업이라 할 수 있습니다. 하지만 원리적인 접근과 체계적인 개념이 없는 것은 아닙니다. 음악이나 무용, 그림, 글 쓰는 일과 같은 창작 작업도 일정한 틀과 원리 안에서 창조가 이루어집니다. 예를 들면, 심포니는 음악 창작의 표준화된 형태의 하나이며, 초상화는 그림 창작의 한 형태이고, 수필은 문학 창작의 한 가지 표준화된 형태입니다. 스케치는 화가가 그림을 설계할 때 쓰는 표기법입니다. 소프트웨어를 설계하는 과정에도 설계 기법과 도구가 필요하다. 특정 설계 기법의 선택이 품질 좋은 소프트웨어 개발의 필수 요건은 아닙니다. 그러나 설계 기법을 잘 적용시키면 소프트웨어 설계는 분명히 개선된다.
대규모 소프트웨어를 설계하기 위한 작업은 다음과 같이 분류할 수 있다.
- 소프트웨어 아키텍처 설계 전체 시스템을 이루는 서브시스템, 또는 모듈이 무엇이며 서브시스템 사이의 관계를 파악하는 작업
- 인터페이스 설계 서브시스템 사이의 인터페이스를 설계하고 정의하는 작업
- 자료저장소 설계 파일이나 데이터베이스를 설계하는 작업
모듈 설계 시스템의 컴포넌트가 되는 모듈, 즉 프로그램의 알고리즘에 대한 설계 작업
사용자 인터페이스 설계 메뉴나 입력 양식, 출력 화면 및 인쇄물을 설계하는 작업
설계 작업은 분석 단계에서 파악한 요구를 구현 가능한 설계안으로 바꾸는 작업입니다. 요구는 개념적이고 추상적인 성격이 많으나 설계는 구체적이고 프로그램과 보다 가까운 실제적인 것이 되어야 합니다.
소프트웨어가 수행하는 여러 가지 기능은 각 서브시스템 또는 컴포넌트에 적절히 할당되어야 합니다. 이를 소프트웨어 아키텍처 설계라 하며 품질 좋은 소프트웨어 시스템을 개발하기 위하여 중심이 되는 단계입니다. 소프트웨어 아키텍처는 소프트웨어 시스템의 골격 또는 조직이라고 할 수 있기 때문입니다. 소프트웨어 아키텍처를 설계한다는 것은 소프트웨어를 이루는 모듈들을 정 의하고 모듈 사이의 인터페이스를 기술하는 것을 의미합니다. 만일 소프트웨어의 구조가 잘 설계되지 못한다면 구현, 시험, 유지 보수에 큰 어려움이 뒤따릅니다. 수십년 동안 사용되는 소프트웨어가 많이 있습니다. 예를 들면 1970년대 개발된 은행 시스템이 아직도 사용됩니다. 물론 업그레이드나 엔지니어링으로 개선되어 왔을 것입니다. 이런 시스템의 유지보수 작업을 해보면 시스템의 구조가 성능, 효율성, 보안, 유지보수에 얼마나 영향을 주는지 알 수 있습니다. 마치 건축에서 아키텍처가 그 건물의 편리성, 경제성, 보수성, 보안 등에 영향을 주는 것과 같습니다. Booch에 의하면 “소프트웨어 아키텍처를 조기에 개발하고 기본 골격으로 만들면 개발하는 시스템을 모델링하거나 구축하거나 관리하는 데 참고가 되는 중요한 결과물이 될 수 있다.”고 합니다. 그만큼 아키텍처는 소프트웨어 개발의 여러 단계에서 중심 역할을 합니다. 다음 포스팅에서는 다음과 같은 내용을 다루어 봅시다.
- 소프트웨어 아키텍처란 무엇이며 아키텍처 설계는 어떤 작업인가?
- 왜 아키텍처 설계가 중요한가?
- 소프트웨어 설계 원리는 무엇이며 어떻게 이런 원리를 아키텍처 설계에
- 적용할 수 있는가?
- 아키텍처 스타일은 무엇이며 어떤 스타일이 많이 사용되고 있는가?
- 설계 문서화는 어떻게 하는가?
참고자료 출처 : 새로쓴 소프트웨어 공학 (저자 : 최은만)