개발자에서 아키텍트로 - 6. 아키텍처 선택하기2

6.3 품질 속성 끌어올리기

아키텍트는 소프트웨어 시스템에서 품질 속성을 더 촉진할 수 있는 구조를 선택해야 합니다. 구조를 선택하는 가장 일반적인 방법은 패턴을 탐색하는 것입니다. 모든 디자인은 다시 디자인한다. 원하는 품질 속성을 촉진하는 패턴을 찾아 해당 패턴을 아키텍처의 시작점으로 잡으세요.

 

6.3.1 품질 속성을 염두해 두고 패턴 찾기

웹 브라우저용 데이터 기반 애플리케이션을 구축한다고 생각해 봅시다. 이 애플리케이션에 어떤 패턴을 선택할까요? 적절한 선택지는 3가지가 있습니다. 3 계층, 발행/구독, 서비스 지향 패턴이 있습니다. 

위에 패턴은 서로 다른 품질 속성을 촉진합니다. 어떤 패턴을 선택하는 게 좋을까요?

 

3 계층 패턴은 대부분의 경우 적합합니다. 쉽게 테스트할 수 있고, 쉽게 배포할 수 있으며, 쉽게 설명할 수 있습니다. 하지만 비용은 높은 편입니다. 계층이 여러 겹인 멀티 계층 패턴은 확장성이 가용성과 같은 품질 속성에는 적합하지 않습니다. 다른 어떤 품질 속성을 더 중요하게 다룰지는 모르지만, 이 패턴은 아키텍처를 다른 패턴으로 확정하지 않으면 우리의 요구를 채워주지 못할 수도 있습니다. 

 

발행/구독 패턴은 서비스를 여러 번 변경해도 유연하게 대응할 수 있습니다. 이 유연성은 느슨하게 결합된 시스템을 만들 때 적합 합니다. 이런 유연성이 매력적이지만 단점이 될 수도 있습니다. 데이터 위주의 애플리케이션에서는 메시지의 순서가 중요하지만 발행/구독 패턴은 순서를 보장하기 어렵기 때문입니다. 메시지 버스 기술을 제대로 만들면 메시지 순서 문제도 해결할 수 있지만 뭔가 어색한 게 사실입니다. 메시지 순서를 지키도록 만드는 순가 이 아키텍처의 매력이 줄어들기 때문입니다. 

 

다른 패턴과 마찬가지로 서비스 지향 아키텍처도 유연하고 테스트하기 좋습니다. 서비스 지향 시스템은 품질 속성 중 확장성과 가용성을 다른 아키텍처보다 중요하게 다룹니다. 그와 동시에 인프라 관점에서 가장 복잡합니다. 꼭 달성해야 할 품질 속성 때문에 써야 할 경우가 아니라면 이 패턴은 과할 수 있습니다. 

 

어떤 패턴을 사용하든 성공적으로 요구사항을 구현할 수 있습니다. 품질 속성은 기능 구현보다 의사결정을 이끌어냅니다. 품질 속성으로 디자인의 맞고 틀림을 판단할 수 없습니다. 하지만 다른 디자인보다 더 좋고 더 나쁘다는 판단은 할 수 있습니다. 이런 판단을 하려면 몇 가지 분석이 필요합니다. 

6.3.2 의사결정 매트릭스 만들기

의사결정 매트릭스는 아키텍처 설계 시 여러 선택지의 절충안을 분석할 때 쓸 수 있는 간단한 방법 입니다. 이를 통해 패턴부터 컴포넌트의 역할과 기술 선택까지 모든 아키텍처에 대한 결정을 내릴 수 있습니다. 아래는 그 예 입니다.

 

매트릭스를 만드는 과정은 매트릭스 자체보다 더 중요합니다. 의사결정 매트릭스는 이해 관계자들과 토론하면서 요구사항을 발굴하고 요약하기에 꽤 괜찮은 방법입니다. 이해 관계자들은 설계 선택지 사이에서 더 폭넓은 절충안을 생각할 수 있습니다. 이제 매트릭스를 설명하면서 어떻게 점수를 매길지도 준비해야 합니다. 

 

매트릭스에 숫자를 넣고 싶은 마음이 들 수 있습니다. 하지만 숫자로 점수를 매기지 마세요. 숫자는 그릇된 자신감을 주고 부정확한 분석을 하게 됩니다. 게다가 누군가가 이해관계자의 입맛에 맞게 가중치를 조정할 수도 있고 몇 개의 열을 뭉뚱그릴 수도 있고, 애써 평균을 내려고 노력할 수도 있습니다. 

 

6.4 구성 요소에 기능별로 역할 할당 하기

아키텍처 안에 어떤 요소든 자기만의 역할이 있습니다. 아키텍처에 맞는 적당한 구조를 선택한 후에는 요소별로 고유한 기능을 할당하고 이를 모아서 필수적인 요구사항을 충족할 수 있도록 합니다. 

 

라이언하트 프로젝트 예시 - 요구사항

• 과거와 현재의 계약서를 검색할 수 있어야 한다. 
• 모든 결과를 페이지별로 넘겨볼 수 있어야 한다.
• 회사의 기본 정보를 조회할 수 있어야 한다.(이름, 전화번호, 주소, 그 회사와 맺는 과거와 현재의 계약 정보)
• 계약서의 기본정보를 조회할 수 있어야 한다.(유형, 상태, 만료일, ID 등)
• 계약서가 갱신될 때마다 알림을 받을 수 있어야 한다. 

위에 요구사항을 토대로 유추한 기능

• 검색할 수 있으므로 색인도 필요하다.
• 계약서와 회사 정보를 보여줘야 하므로 어딘가에 저장해야 한다.
• 알림을 받아야 하므로 이메일 주소를 저장해야 한다.
• 갱신될 때 알림을 받아야 하므로 갱신을 알아내는 방법이 있어야 한다.

라이언하트 프로젝트 컴포넌트 구성

구성 요소별 역할

구성 요소별 역할 목록은 각 요소별로 가져야 할 필수적인 사항을 기록하고 있으며, 아키텍처에 어떤 책임을 가져야 하는지를 나타냅니다. 이 목록을 작성할 때 아키텍처에 영향을 미치는 기능 요소를 파악해 가면서 하나의 역할에 대해 단 하나의 구성 요소만 가질 수 있도록 했습니다. 게다가 아키텍처에서 하나의 구성 요소는 적어도 하나의 역할을 맡게 했습니다. 다시 말해 목적이 없는 구성요소는 없도록 했습니다.

 

6.5 변화에 대응하는 디자인

위대한 아키텍처는 피할 수 없는 변화에 꾸준히 대응한 결과입니다. 변화하는 여러 사항에 대응하려면, 주도적으로 의사결정할 시기를 정하는 방법과 아키텍처를 흔들지 않으며 설계하는 방법이 있습니다.

 

6.6 결정은 미룰 수 있을 때까지 미룬다.

결정은 일단 내리면 되돌리기 어렵습니다. 특히 아키텍처에 관한 결정은 더욱 그렇습니다. 의사결정 시기를 최대한 늦출 수 있다면 잘못된 길로 가거나 막다른 골목에 가지 않을 수 있습니다. 결정을 해야만 하는 순간까지 설계에 대한 의사결정을 미루면서 연구와 탐색을 위한 시간을 벌 수 있습니다.

 

현재 의사결정을 하기 좋은 시간인지 파악하는 방법

• 결정을 못 해서 더 나아갈 수 없는가?
• 더는 기다릴 수 없이 당장 결정해야만 하는 문제인가?
• 의사결정이 더 많은 선택지나 기회를 만드는가?
• 결정은 미루면 위험이 매우 커지는가?
• 결정을 내릴 때 영향력을 충분히 숙지하고 있는가?
• 지금 왜 결정을 내려야만 하는지 논리적 근거는 명확한가?
• 잘못되었을 경우 되돌릴 만한 시간은 있는가? 실수를 감당할 수 있는가?

6.6.1 아키텍처에 영향을 주지 않게 의사결정하기

SOLID 원칙은 단일 책임, 개발/폐쇄, 리스코프 치환, 인터페이스 분리, 의존관계 역전 등의 설계원칙을 말합니다. 추상화 원칙에 따라 깨끗한 인터페이스를 요소별로 만들면 구조가 더욱 유연해집니다.