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

소프트웨어 아키텍처 설계란 불확실함 속에서 의사결정을 내리는 일입니다. 이 결정에는 절충과 타협이 있으며 좋은 것을 포기하는 대신 나쁜 것을 받아들임으로써 다른 것을 더 좋게 하는 결정을 하기도 합니다. 받아들일 수 있는 수준의 절충안을 선택하다 보면 아키텍처 핵심 요구사항을 충족하고 이해관계자들의 비즈니스 목표도 달성할 수 있습니다.

 

6.1 대안 위한 분기, 결정을 위한 융합

무언가를 결정한다는 말은 선택할 수 있는 여러 가지 대안이 있다는 뜻이기도 합니다. 만약 옵션이 하나뿐이라면 결정할 필요가 없습니다. 아키텍처 설계 시 다양한 대안을 보려면 설계 공간을 살펴볼 필요가 있습니다.

설계를 위한 탐색은 분기와 융합을 반복하는 여정입니다. 먼저, 문제를 파악하면 여러 갈래로 생각을 뽑아보고 문제를 해결할 수 있는 다양한 대안을 만들어 봅니다. 몇 가지 대안이 나왔으면 현재 문제에 맞지 않는 대안은 지우면서 남은 아이디어를 목으로 공감대를 만들어 갑니다. 

 

 

인간의 뇌는 선택을 갈망합니다. 여러 가지 대안을 보면 결정할 때 신뢰도가 높아집니다. 유감스럽게도 소프트웨어 시스템을 설계할 때에는 가능한 모든 대안과 경우의 수를 고려할 시간이 없습니다. 그러므로 아키텍트는 품질 속성, 구조, 그리고 이에 영향을 미치는 설계에 집중해야 합니다.

6.1.1 설계에 중요한 사항을 찾아내기

모든 아키텍처는 설계지만, 모든 설계가 아키텍처는 아니다 - 그래디 부치

 

소프트웨어 아키텍처는 품질 속성을 비롯한 여러 가지 요소의 수준을 끌어올리려는 설계 의사결정 집합이라고 했습니다. 아키텍트는 설계 시 중요한 의사결정을 주도적으로 파악해야 하고, 소프트웨어 구성을 적극적으로 선택해서 품질 속성을 원하는 수준까지 올려야 합니다. 

 

아래는 통상적으로 소프트웨어 시스템 설계에서 아키텍트가 파악해야 하는 것입니다.

 

아키텍처에서 구조를 어떻게 조합할지 결정하기 위한 각 구성요소와 그 역할

아키텍처는 요소들의 조합으로 이루어져 있습니다. 잘 설계된 아키텍처에는 요소마다 명확한 역할이 있습니다. 명확한 역할이 없는 요소는 제거돼야 합니다. 설계 시 어떤 대안이 가능한지 알아내려면 요소 간의 조합으로 만들어지는 다양한 역할을 알고 있어야 합니다. 

 

구성요소 간의 상호작용 방식을 결정하기 위한 관계와 인터페이스

아키텍처에서 관계란 하나의 작업을 완수하기까지 두 요소가 어떻게 함께 작동하는지를 말합니다. 인터페이스는 관계의 한 예입니다. 통신 메커니즘(HTTP, TCP, 공유 메모리 등)과 통신 규칙(예 : API, 응답개체, 필수 데이터 등)은 모두 인터페이스를 정의하는 지식으로 알고 있어야 합니다. 인터페이스와 구성 요소를 아우르는 규칙은 한 지점에서 상속받는 형태로 일과성이 이어야 합니다. 다만 세부 규칙은 느슨하게 만들 수도 있습니다. 메서드 이름이나 응답 값의 필드는 세부를 구현하는 아키텍트에게 맡기는 경우가 있습니다.

 

아키텍처가 모델로 삼은 세상을 이해하기 위한 도메인

도메인에서 나온 개념, 그에 속한 개체, 이벤트에 대한 설명이 아키텍처의 어딘가에 있어야 합니다. 문제를 잘 이해할수록 아키텍처에서 구성 요소를 알맞게 분할하고 요소 간의 역할도 의미 있게 나눌 수 있습니다. 

 

품질속성을 끌어올리기 위한 기술과 프레임워크

오늘날의 소프트웨어 개발 기술을 적용할 아키텍처를 미리 가정한 채로 개발되었습니다. 프레임워크, 미들웨어, 라이브러리도 다 그렇습니다. 그러므로 기술을 정확히 파악해 언제 어떻게 사용하는지 알아야 합니다. 독선적인 기술은 아키텍처를 특정한 형태로 강요합니다. 

 

기술이 우리의 요구에 부합하면 아름다운 결말로 끝나겠지만 기술이 우리가 생각하는 범위에 있다면 프레임워크와 힘든 싸움을 해야 합니다.

 

아키텍처를 온전히 릴리스하기 위한 설치와 배포방법

아키텍처에 따라 소프트웨어 구성과 배포방법이 달라질 수 있습니다. 지속적인 배포(CD) 방법을 사용하고 싶거나, 다수의 개발자가 병렬적으로 작업하는 방법을 원하거나, 특정한 테스트 전략을 사용하고 싶다면 아키텍처가 이러한 요구사항을 적용할 수 있도록 설계해야 합니다.

 

과거의 설계에서 얻은 관점과 의사결정 과정

하늘아래 새로운 설계는 없습니다. 대부분의 아키텍처 탐색은 이미 알고 있는 설계를 살펴보면서 시작합니다. 설계에 관한 지식은 코드나 문서로 존재합니다. 하지만 때로는 자신의 경험에서 나올 수 있고, 오랜 세월 동안 아키텍트들 사이에서 전해오는 전설적인 이야기에서 나올 수 있습니다.

 

6.2 제약 수용하기

제약이란 설계할 때 이미 결정되어서 이미 바꿀 수 없는 사항을 의미합니다. 제약은 기술적인 제약과 비즈니스적인 제약 두 가지가 있습니다. 기술적인 제약은 기술을 선택할 때, 비즈니스적인 제약은 사람, 프로세스, 비용, 일정을 선택할 때 주어지는 제약입니다. 

 

초기에 설계 결정이 제약이 될 수 있지만, 이를 제약이라고 하지는 않습니다. 단지 건물 지을 때 이곳저곳에 버팀목을 세워둔 정도라고 볼 수 있죠. 버팀목을 옮기는 일이 힘들긴 하지만 그래도 옮길 수는 있습니다. 주어진 제약과 스스로가 만들어낸 제약을 구분할 줄 알아야 합니다. 

 

제약은 아키텍처에 심대한 영향을 미치지만 그럼에도 아키텍처의 의사결정은 품질 속성을 올리는 데에 초점을 맞춰야 합니다.