7. 아키텍처

큰 문제를 이루는 각 조각들을 알아내는 것만으로는 충분하지 않다. 이러한 조각들이 어떻게 연결되는지 그리고 어떤 조각들이 다른 것들에 비해 더 중요한지에 대해서 좀 알아야 한다. 쓸데 없는 일로 시간을 낭비하지 않아야 한다.

우리는 아키텍처가 필요하다.

아키텍처는 디자인의 구조이고, 프로그램의 가장 중요한 부분들과 그들 사이의 관계를 명확히 보여준다.

디자인의 구조

디자인의 유연성을 앞서 살펴보았다. 이렇게 아키텍처는 커다란 시스템들의 설계에 도움이 된다.

가장 중요한 부분들

이것이 우리가 필요한 것인데... 가장 중요한 것이 무엇인지 알아가보자.

그들 사이의 관계

유스케이스 다이어그램으로 부분들의 관계에 대해 다루기는 했지만, 여전히 모듈간의 연경방식은 명확하지 않다.

학자코너

아키텍처란? 아키텍처는 시스템의 분할, 나뉜 부분들 사이의 연결과 상호 작용 메커니즘, 그리고 시스템의 디자인에 사용된 원리와 결정 사항들을 담고 있는 시스템의 구조이다.

쉽게 말해, 아키텍처는 크고 복잡하고 뒤죽박죽인 내용을 가져와 잘 정리된 프로그램으로 바꾸는데 도움을 준다.

위대한 소프프트웨어의 3단계

여러분이 작은 프로젝트에서 일하든, 큰 프로젝트에서 일하든 상관없이, 위대한 소프트웨어는 같은 방식으로 만든다. 1장에서 얘기했던 위대한 소프트웨어의 3단계를 큰 프로젝트에서도 적용할 수 있다.

기능부터 시작하자.

첫번째 단계는 항상 프로그램이 고객이 원하는 일을 하게 하는 것이다. 작은 프로젝트에서는 요구 사항 리스트를 사용하여 기능을 정리했다. 큰 프로젝트에서는 특징 리스트를 사용하여 기능들을 알아내자.

하지만 특징 리스트 중에서 어느 것이 가장 중요한가?

아키텍처는 프로그램의 구성요소간의 관계에 대한 것만은 아니다. 중요한 부분을 먼저 만들기 위해 어떠한 부분들이 가장 중요한지 알아내는 것도 관련 있다.

아키텍처에 관한 세가지 질문

어떤 것이 아키텍처적인 의미에서 중요한지 알아내려고 할 때, 다음 세가지 질문을 할 수 있다.

1. 시스템의 본질이 되는 부분인가?
2. 이것은 도대체 무슨 의미죠?
3. 도대체 어떻게 해야 하죠?

시스템의 본질이 되는 부분인가?

정말 그 특징이 시스템의 핵심인가? 그 특징이 없는 시스템을 생각할 수 있는가? 아니라면 아마도 시스템의 본질이 되는 특징을 찾은 것이다.

이것은 도대체 무슨 의미죠?

어느 특징에 대한 설명이 무슨 뜻인지 확신이 서지 않으면, 그 특징에는 관심을 기울일 필요가 있다. 어떤 일인지 확실치 않을 때, 그 일은 시간이 오래 걸리거나 시스템의 나머지 부분에 문제를 야기시킬 수 있다. 그러한 특징들은 빨리 알아봐야 한다.

도대체 어떻게 해야 하죠?

다음으로 초기부터 관심을 기울일 부분은 구현하기 정말 어려워 보이거나 여러분에게 완전히 새로운 프로그래밍 작업인 경우이다. 특정 문제를 어떻게 해결할지 잘 모르겠으면, 처음에 그 특징에 시간을 들여 문제의 발생을 미리 막아야 한다.

특징 리스트에 아키텍처에 관한 세가지 질문을 사용해서 중요한 특징(핵심 특징)이 무엇인지 알아보자.

이렇게 찾은 특징은 시스템의 본질이며, 시스템의 본질은 가장 기본적인 수준이 완성되었을 때의 시스템 모습이다. 이것을 핵심 특징이라 하자.

이제 위험 요소를 찾아보자.

프레젝트의 성공의 위험 요소를 줄이는 방향으로 진행된다면 어느 것을 먼저 하는지 상관없다. 위험 요소는 여러가지 문제를 일으키거나 프레젝트의 일정을 연기할 수 있다.

간단한 시나리오는 위험 요소를 줄이는데 도움이 된다.

원래 시나리오는 유스케이스에 포함되어 있다. 하지만 지금은 큰 그림을 보고 있기 때문에 유스케이스를 작성하지 않았다. 이럴 때는 유스케이스를 작성하지 않고 간단한 시나리오를 작성해서 중요한 요구사항을 잊지 않게 도와줘서 위험요소를 줄일 수 있다. 간단한 시나리오는 대체경로 등을 생각하지 않고 본질이 가지는 하나의 시나리오를 만들면 된다.

왜 완벽한 유스케이스를 사용하지 않고 간단한 시나리오를 사용할까?

지금은 위험을 줄이는데 필요한 정도만 있으면 된다. 너무 구체적인 내용까지 생각하면, 이 단계에서는 중요하지 않는 세세한 내용에 대해 일하느라 오히려 프로젝트에 위험을 추가할 수도 있다.

유스케이스, 다이어그램, 시나리오 등.. 왜 사용할까?

결국 이런 도구들은 고객이 원하는 시스템을 만들기 위해서 사용한다. 좋은 요구 사항이 없으면, 잘못된 시스템을 개발하여 고객을 실망시키고 당황하게 할 위험이 있다.

특징의 의미가 확실치 않거나 그 특징을 어떻게 구현할지 막연할 때...

1. 고객에게 묻는다.
2. 공통점 분석 "특징이 무엇을 의미하는가?"
3. 구현 계획 "어떻게 그 특징을 내 시스템에 구현할 것인가?

위대한 소프트웨어는 위대한 코드만을 얘기하는 것이 아니다.

고객은 위대한 코드가 아니라 위대한 소프트웨어를 위해 여러분께 보수를 지급하는 것이다. 위대한 코드는 잘 설계되고 의도된 대로 작동한다. 하지만 위대한 소프트웨어는 잘 설셰되었을 뿐 아니라 스케줄에 맞게 제작되는, 그리고 고객이 원하는 기능을 하는 소프트웨어이다. 지금까지 배운 핵심 특징 리스트, 클래스 다이어그램, 요구사항 등은 소프트웨어 개발 일정이 늦춰지는 위험과 고객이 원하는대로 동작하지 않는 위험을 줄이기 위해서 사용되었다.

핵심정리

• 아키텍처는 모든 다이어그램, 계획, 특징 리스트들을 잘 정돈된 애플리케이션으로 만드는 데 도움을 준다.
• 프로젝트에 매우 중요한 시스템의 특징들은 아키텍처적으로 중요하다.
• 시스템의 본질인 특징, 의미가 명확하지 않는 특징, 또는 처음에 어떻게 구현해야 할지 명확하지 않는 특징에 초첨을 맞춰라.
• 프로젝트의 아키텍처 설계 단계에서 하는 모든 일은 프로젝트 실패와 위험을 줄여야 한다.
• 유스케이스의 세부 사항이 필요하지 않을 경우, 소프트웨어가 어떻게 이용될 수 있는지를 설명하는 시나리오를 작성하면 요구 사항을 빠르게 수집하는데 도움이 된다.
• 특징이 무엇인지 확실히 모를 때, 고객에게 묻고, 그런 후 얻은 답을 일반화하여 특징을 잘 이해하도록 한다.
• 공통점 분석을 사용해서 유연한 소프트웨어 솔루션을 만들어라.
• 고객은 여러분 생각에 정말 멋지게 짜여진 코드에 관심이 있기보다는 그들이 원하는 일을 하고, 시간에 맞게 만들어지는 소프트웨어에 관심이 있다.