개발자에서 아키텍트로 - 5. 아키텍처 핵심 요구사항 알아내기2

5.3 기능 요구사항 찾아내기

기능 요구사항은 성공적인 소프트웨어 시스템을 만드는 데에 필수적이지만 모든 기능이 아키텍처에 중요한 것은 아닙니다. 어떤 기능 요구사항이 아키텍처의 의사결정을 주도할 정도로 중요하다면, 우리는 이를 '영향력 있는 기능 요구사항'이라고 부릅니다. 

영향력 잇는 기능 요구사항은 아키텍처 킬러라고도 불립니다. 아키텍처가 높은 가치와 높은 우선순위를 가진 기능 중 하나라도 소화하지 못하면, 아키텍처를 해체하고 다시 만들어야 합니다. 

영향력 있는 요구사항을 만들어 내는 방법

1. 먼저 현재의 생각을 요약한 추상적인 수준의 아키텍처를 간단히 작성해 보세요.
2. 비슷한 문제끼리 묶은 후 일반적인 요구사항을 분류합니다.
3. 앞서 작성해 본 아키텍처로 해결 가능한지 분류별로 살펴봅니다. 만약 요구사항이 모호하고 해결 방법도 즉시 떠오르지 않는다면, 그 요구사항은 아키텍처에 중요한 영향을 미칠 가능성이 높습니다.

요구사항 목록을 줄이는 일

• 하나의 아키텍처 요소로 구현할 수 있는 공통적인 요구사항을 파악합니다. 예를 들어, 데이터 불변성을 다루는 요구사항끼리 묶고 사용자 인터랙션을 다루는 요구사항끼리 묶을 수 있습니다.
• 구현하기 어려운 요구사항을 찾아봅니다. 이런 요구사항들이 아키텍처에 중요한 영향을 미칩니다.
• 가치가 높고 우선윈도 높은 기능 요구사항을 파악합니다.

예시 - 과거의 기록이 보이는 계산기 개발

예를 들어 계산기를 개발하고 있는데 마케팅 팀에서 "과거의 기록이 보이면 좋을 겁니다"라며 우리에게 요구사항을 내었다고 가정하여 봅니다. 해당 요구사항의 경우 작업을 원격데이터 베이스에 저장하고 가용성, 확장성, 동기화 등 요구사항이 쭉쭉 늘어나게 됩니다.

 

단순해 보이는 기능 요청하나 가 복잡도를 기하급수 적으로 늘어나게 했습니다. 이 간단한 계산기의 예에서 우리는 계산 작업을 그저 하나의 일반적인 요소로 취급할 수 있습니다. 하지만 새롭게 요청받은 기록 기능을 만들려면 원격 스토리지가 필요합니다. 이 기능은 기존의 아키텍처와 요구사항만으로는 충족하지 못하므로 새로운 방향으로 발전해야 합니다.

 

5.4 아키텍처에 영향을 미치는 다른 요소 찾기

아키텍처 핵심 요구사항 외에 에도 아키텍처에 직간접적으로 영향을 미칠 수 있는 요소가 많습니다. 다음은 아키텍처에 영향을 미칠 수 있는 몇 가지 요인입니다. 

 

 

아키텍트로서의 능력과 경험에 따라 설계 접근 방식과 사용 가능한 아키텍처의 옵션이 천차만별입니다. 아키텍트의 지식과 팀의 지식이 곧 설계의 표현력과 상상력을 정의합니다. 루비온 레일즈를 잘 알고 있다면, 아키텍처의 이곳저곳 틈새를 노리는 방법을 통원할 수 있습니다. 여러분이 가진 도구가 망치뿐이라면, 눈에는 못만 보일 뿐입니다.

 

아키텍처가 항상 최신 기술 동향을 따라야 할 필요는 없습니다. 새로운 하드웨어, 소프트웨어 및 설계 패러다임이 등장함에 따라 일부는 소프트웨어 엔지니어링 환경을 완전히 바꾸고 있습니다. 하지만 대부분은 오래된 아이디에어 좋은 포장만 씌운 경우가 많습니다. 여러분의 아키텍처도 1980년대 헤어스타일에 버금가는 디자인을 자랑스럽게 뽐내고 있을지도 모릅니다.

5.5 콘웨이 법칙

설계 조직의 커뮤니케이션 구조는 곧 제품을 설계할 때의 한계를 정의한다.

 

팀이 셋이면 컴포넌트로 결국 세 개로 만들어집니다. 사람들 사이의 의사소통 경계가 아키텍처에서 컴포넌트 간의 경계로 나타납니다. 콘에 법칙은 양방향으로 작용합니다. 아키텍처 위에서 그려진 커뮤니케이션 경로는 팀을 구성하는 방식에도 영향을 미칩니다. 최고의 소프트웨어를 설계하고 싶다면 팀을 재정비해야 합니다.

5.6 필요한 정보 깊이 들어가기

이해관계자와 대화하고, 무엇을 걱정하는지 알아내세요. 이해관계자들에게 더 좋은 반응을 이끌어낼 부분을 찾아보세요. 살펴보고 있는 위험을 공유하고 질문을 받아보세요. 핵심요구사항(ASR)을 더 찾아낼 수 있는 방법은 아래와 같습니다.

 

• 목표, 질문, 메트릭을 구체화합니다. 구체적인 데이터 요구사항을 가지고 비즈니스 목표와 품일 속성에 따른 반응의 측정치를 연결합니다.
• 이해관계자와 인터뷰합니다. 이로써 숨 펴진 품질 속성 시나리오와 제약을 찾아냅니다. 인터뷰는 기술 이해 관계자들과의 대화할 때 특히 효과적입니다.
• 가정하고 있는 사항을 나열합니다. 이로써 암시적인 요구사항을 명료하게 합니다.
• 미니 품질 워크숍에 따라 작은 품질 속성 워커숍을 엽니다. 우선순위가 높은 품질 속성 시나리오를 빠르고 효율적으로 정의할 수 있습니다. 이 워크숍은 서로 다른 분야의 이해관계자 들과 함께 할 수 있으므로 어떤 형태의 프로젝트에도 잘 어울립니다.
• 인셉션 덱을 사용해 새 프로젝트의 킥오프 체크리스트를 만듭니다. 아키텍처는 인셉션 덱의 핵심 주제로 활약하게 됩니다.

5.7 핵심요구사항(ASR) 워크북 만들기

ASR 워크북은 개발자, 테스트는 물론 아키텍트에게 프로젝트의 맥락과 더불어 다양한 정보를 제공합니다. ASR을 이해하는 사람이 많아질수록 아키텍트를 감독할 일이 줄어듭니다.

 

아래는 ASR 워크북 목차 예시입니다. 아래 목차를 요구사항을 도축하는 체크리스트로 활용해 보세요.