균형 잡힌 아키텍처 결정을 위하여

안녕하세요 주간SaaS 입니다. 

시스템 아키텍처 형태는 비즈니스와 조직을 반영하고 있다고 생각 합니다. 그래서 단순한 컴포넌트 하나를 추가하는데도 많은 고민을 하게 됩니다.

특히나 SaaS는 기술과 비즈니스 모델이 긴밀하게 결합된 형태다 보니 여러 상황을 고려한 아키텍처 설계가 요구 됩니다. 어렵습니다.

오늘은 On making architectural decisions 이라는 글에는 여러 상황이 고려된 균형 잡힌 아키텍처 설계를 위한 접근 방법에 관해서 조언 합니다. 뻔히 알고 있는 이야기라고 볼수 도 있지만 균형 잡힌 아키텍처 결정을 위한 구조화된 방법을 알려줘서 개인적으로 좋은 공부가 되었습니다. 여러분들에게도 도움이 되는 글이면 좋겠습니다.🙏🏼

동일한 목표를 다른 방법으로 달성할 수 있다고 주장하기란 어렵습니다. 왜냐면 제한이 없다면 특정 기술, 개발 접근 방식, 활용 패턴 및 플랫폼 공급업체의 선택에 관해 어떤 결정이든 받아들일 수 있을 뿐더러, 이런 결정들이 목표를 달성하는데 근본적으로 영향을 미치지 않습니다. 하지만 실제로는 시간, 예산, 팀 경험, 사용 가능한 리소스, 취득한 라이선스 등 항상 이러한 제한이 존재합니다. 목표를 달성하기 위한 특정 접근 방식의 선택 과정이 항상 균형이 잘 잡혀 있나요?

아키텍트들은 종종 직감을 사용합니다. 이는 개인적인 경험, 선호도, 직관이 의사 결정의 핵심 요소가 된다는 의미이고, 다른 중요한 상황은 간과될 수 있음을 의미합니다:

게다가, 관련 요소의 구성은 관점에 따라 다를 수 있습니다. 예를 들어, 프로젝트 사무실에서 내리는 결정은 기술적인 문제는 충분히 고려하지 않고 비즈니스, 예산 및 시간 제한, 가용 리소스와 같은 비기술적인 요소를 고려하는 경우가 많습니다. 마찬가지로 특정 영역별 기술 전문가는 기술적 측면만 고려하는 동시에 비기술적인 뉘앙스를 간과할 수 있습니다. 동기 부여가 부족한 결정들은 종종 프로젝트 실패의 주요 원인이 됩니다. 그 이유는 동기 부여가 부족한 상태에서 내려진 의사 결정 결과 만들어진 아키텍처가 이해관계자의 필요성, 존재하는 제한 사항, 사용 가능한 대안 등을 전체적으로 고려하지 않기 때문입니다. 따라서 균형 잡힌 결정을 내리려면 기술적 및 비기술적 성격의 내부 및 외부 요인을 모두 고려하는 것이 중요합니다. 아키텍처 설계의 프로세스는 그림과 같이 고려할 수 있습니다. 신중한 결정을 내리기 위해서는 요구사항과 상황(context) 살피는것이 필요하며, 이전에 대안으로 내려진 결정들을 평가해야 합니다.

아주 간단하지 않나요? 하지만 실제로 대안을 개발하고 평가에 '올바른' 기준을 세우는건 매우 어려운 작업입니다. 이 어려운 작업을 하기 위해 준비작업이 필요한데, 저희의 권고 사항을 활용하는것도 좋습니다.

일반적으로, 대안들의 평가는 표 형식으로 나타내며, 옵션들은 가로로, 기준들은 세로로 표시됩니다. 각 셀에는 평가 점수가 들어가며, 이는 각 기준의 중요도에 따라 가중될 수 있습니다.

예를 들어, 구성 요소 간 통신 방법에 대한 세 가지 방법의 비교 표를 살펴보겠습니다. 상황과(context) 임무(task)를 충분히 이해하지 않으면 각각 장단점을 갖고 있는 옵션들 사이에서 좋은 선택을 하는 것이 불가능하다는 점을 명심해야 합니다. (*그림은 설명을 위한 예시 이며, 모든 평가 점수는 임의로 설정된 것입니다.)

가중치와 평가 점수가 반드시 숫자일 필요는 없습니다. 왜냐하면 이런 값들을 해석하고, 어떻게 이 점수가 나왔는지 논리적으로 해석하기 꽤 어렵기 때문입니다. 예를 들어, 기능성 - 3.7, 가격 - 2.3, 팀 경험 - 4.1과 같은 평가는 좋은 것인지 나쁜 것인지 판단하기 어렵습니다.

"나쁨", "좋음", "훌륭함", "해당 없음" 등과 같은 정수 값을 사용하는 것이 좋습니다. 이렇게 하면 점수와 최종 선택을 해석하기가 훨씬 쉬워집니다.

가장 큰 문제는 평가 기준의 "완전한" 구성을 정의하는 것입니다. 이를 위해서는 상황(context) 경계를 설정해야 하는데, 상황(context)이 바로 평가 기준의 원천이기 때문입니다. 아래 그림에서는 아키텍트의 관점에 따라 상황(context) 내용이 어떻게 달라질 수 있는지 보여줍니다.

가장 간단한 경우에, 의사결정을 할 때 두 가지 요소가 고려됩니다: 요구사항의 설명과 아키텍트의 경험. 많이들 사용하는 공식적인 방법대로 요구사항에 쓰여진 대로 접근하는 것은 예상과 전혀 다른 결과를 낳을 수 있습니다. 이러한 상황은 여러 가지 이유로 발생할 수 있습니다. 예를 들어, 요구사항이 다른 사람에 의해 정의 되었을 경우가 그렇습니다. 이 경우에는 문서가 "완벽"하더라도 분석가와 아키텍트가 문제를 다르게 이해할 수 있습니다.

이것이 바로 "비즈니스 문제"와 다른 개념들이 "좁은"상황(Narrow Context)에서 벗어나 위치한 이유입니다. 요구 사항에 만 기반하여 아키텍처적 결정을 내리는 것은 이해관계자와의 소통을 제한하며, 이는 불가피하게 위험을 증가시킵니다.

예를 들어, 클라우드 기술을 기반으로 한 "아름다운" 해결책이 스케일링과 관련된 여러 문제를 즉시 해결할 수 있어 보일지라도, 운영 비용 제한이 있거나 특정 법적 요구사항을 준수해야 하는 의무가 있다면 전혀 솔루션으로 받아들일 수 없을 수도 있습니다.

고려되야 하는 상황(context)이 확장됨에 따라, 공식에 새로운 변수들이 추가됩니다. 따라서 한편으로는 결정이 더 균형 잡히게 되지만, 다른 한편으로는 분석을 수행하기 위한 추가적인 노동 비용이 발생되기도 합니다.

현재 과제에 따라 최적의 상황(context) 경계를 정의하는 것이 필요합니다. 아래 그림에서 보이듯이, 예를 들어 비즈니스에 중요한 시스템이며 회사의 미래에 성공적인 구현이 중요한 경우, 자원이 허락하는 한 상황(context)을 가능한 한 확장해 보는 것이 합리적입니다. 반면, 비즈니스에 미치는 영향이 제한적인 시스템의 개발은 최소한의 분석만으로 제한될 필요도 있습니다.

그렇습니다, 결론적으로 의사결정을 할 때 아키텍트의 주요 임무는 균형 잡힌 아키텍처적 결정을 내릴 수 있게 해줄 포괄적인 상황(context)(평가 기준의 집합)을 정의하는 것입니다.

비즈니스에 중요한 결정들의 경우, 대안을 분석하고 아키텍처적으로 중요한 요구사항을 검토하는 데 추가 시간을 할애하고, 균형 잡히지 않은 결정을 내릴 위험을 최소화하기 위해 분석의 범위를 여러 상황(context)로 확장하는 것이 권장됩니다.

이러한 접근 방식은 의사결정 과정에서 발생할 수 있는 리스크를 줄이고, 프로젝트의 성공 가능성을 높이는 데 도움이 됩니다. 아키텍트는 다양한 이해관계자의 관점과 요구사항을 종합적으로 고려함으로써, 보다 효과적이고 합리적인 아키텍처적 결정을 내릴 수 있게 됩니다.

주간 SaaS 에 대한 피드백(익명)을 남길 수 있어요