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

아키텍처 핵심 요구사항(ASR)이란 아키텍처를 선택하거나 구성할 때 큰 영향을 미치는 요구사항을 말합니다. 어떤 요구사항이 중요한지 선별하는 일이야 말로 아키텍트의 책무 입니다. 요구사항은 크게 4가지로 구분 할 수 있습니다. 

 

1. 제약 : 바꿀 수 없는 결정사항. 대체로 이미 결정된 사항을 받지만, 가끔은 선택권이 있음
2. 품질 속성 : 시스템을 다른 시스템과 구분 짓는, 겉으로 보이는 요소. 구체적인 상황에서 시스템이 어떤 작업을 수행 등
3. 영향력 있는 기능 요구사항 : 아키텍처에서 특히 주목해야 하는 기능
4. 기타 : 시간, 지식, 경험, 능력, 내부 규정, 개인의 개성 등 설계에 영향을 미치는 요소 

5.1 제약으로 설계 선택지 줄이기

저약은 이미 정해져서 변경이 불가능한 설계상의 의사결정을 의미 합니다. 잘 선택된 제약은 문제를 단순하게 만들고 이로써 만족으러운 아키텍처가 나오기도 합니다. 하지만 때도는 요구사항을 도저히 충족시키지 못하는 지옥을 만들기도 합니다. 

 

제약은 기술 또는 비즈니스에도 영향을 미칠 수 있습니다. 비즈니적인 제약은 인력, 프로세스, 비용, 일정에 대한 결정을 제한 합니다. 기술적인 제약은 소프트웨어 시스템에서 사용할수 있는 기술에 대한 결정을 제한 합니다. 

기술적인 제약	비즈니스적 제약
개발언어 : JVM 기반이면 뭐든 상관 없음	팀 구성 : 팀A가 컴포넌트 X를 만들 것이다.
OS, 플랫폼 : 윈도우, 리눅스, BeOS에서 구동되어야 함	일정, 예산 : 7월 전시회가 출시해야 하고, 개발비는 80억원을 넘어서는 안됨
사용 가능한 컴포넌트 : DB2를 가지고 있으므로 이를 활용	법률, 계약 : 구매한 라이센스 하루 데이터 처리량은 최대 5G로 제약되어 있음

 

5.1.1 제약 단순화 하기

결정된 제약은 협상할 수도 없고 돌이킬 수도 없다고 못박습니다. 제약을 받아들일때는 보수적이 되세요. 반드시 하지 않은면 실패하는 일과 그냥하면 좋은일 사이에는 큰 차이가 없습니다.

 

소프트웨어 시스템에서 설계 결정은 제약처럼 변질되기도 합니다. 시간이 지날수록 소프트웨어는 점차 삐걱거리고, 느려지고, 더러워지고, 거칠어 집니다. 결국 아키텍처를 수정하기가 너무 어려워져 초기의 설계 선택이 미래에는 아키텍트에게 제약이 될 수 있습니다.

제약	주체	유형	내용
오픈소스로 개발해야함	반담 시장	비즈니스	시는 오픈 데이터 정책을 공표 했기에 시민들도 언제든 소스를 볼 수 있음
웹 브라우저 기반이 되어야함	반담 시장	기술	소프트웨어 배포과 관리를 용이하게 하고 싶음
3분기에 배포해야함	반담 시장	비즈니스	예산 심사보다 빨라야 함
취신 파이어폭스 브라우저를 지원해야함	시 IT 부서	기술	공식 지원 브라우저임
리눅스 서버를 사용해야함	시 IT 부서	기술	시의 기술 정책은 린눅스와 오픈소스를 권장 함

 

5.2 품질 속성 정의하기

품질 속성은 소프트웨어 시스템의 외부에서 볼 수 있는 특성과 그 시스템에 기대하는 동작이 무엇인지를 설명 합니다. 품질 속성은 시스템이 어떤 작업을 얼마나 잘 수행해야 하는지를 정의 합니다.

설계 시점의 요소	실행 시점의 요소	추상적인 요소
변경 가능성	가용성	관리 용이성
유지 보수성	신뢰성	정비성
재사용성	성능	단순성
테스트 가능성	확장성	교육 편의성
구축 편의성	보안

 

아키텍처에 관한 결정이 이루어지면 품질 속성 중 하나쯤은 꼭 촉진 되거나 억제 됩니다. 아키텍처에 핵심 요구사항은 대부분 품질 속성을 다루는 일 입니다. 품질 속성은 설계 프로세스 전반에 걸쳐 기술, 구조, 패턴을 선택할 때뿐 아니라 의사결정을 알맞게 평가할 때도 사용 합니다.

 

5.2.1 품질 속성을 시나리오로 만들기

확정성, 가용성, 성능 등은 그 단어만으로 의미가 없습니다. 이 단어에 의미를 부여해야 무엇을 설계하는지 이해 할 수 있습니다. 품질 속성 시나리오는 만들어보면 품질 속성을 더 명확하게 설명 할 수 있습니다. 품질 속성 시나이오는 특정 상황에서 소프트웨어 시스템이 동작하는 방식을 설명 합니다.  품질 속성 시나리오의 경우 반응을 측정하고 그 값으로 반응을 검증하므로 기능 요구사항과는 다릅니다. 단지 올바르게 반응하는 것만으로는 충분하지 않습니다. 

• 자극 : 시스템이 어떤 식으로든 반응하도록 요구하는 일종의 이벤트 입니다. 자극은 시나리오를 시작하는 신호 입니다. 자극은 품질 속성의 유형에 따라 여러 가지가 있을 수 있습니다. 예를 들어 가용성 시나리오의 자극은 노드가 접속 불능 상태가 될 때까지 트래픽을 상정한다면, 변경 가능성 시나리오의 자극은 여러 값에 대한 경하는 명령을 상정할 수 있습니다.
• 자극원 : 자극을 발생시키는 사람이나 시스템 입니다. 예를 들어 사용자, 시스템 컴포넌트, 외부 시스템 등이 있습니다.
• 산출물 : 시나리오를 특정할수 있게 하는 시스템의 한 부분을 일컫습니다. 산출물은 시스템 전체일 수도 있고 컴포넌트 일 수도 있습니다.
• 반응 : 자극 때문에 시스템 외부로 산출물을 드러내는 동작 입니다. 자극이 반응을 만듭니다.
• 반응측정 : 반응 측정은 시나리오가 성공했을 경우 반응이 어떠할지를 기준으로 성공의 기준을 정합니다. 반응 측정은 구체적이고 측정 가능해야 합니다.
• 주변상황 : 주변상황이란 시나리오는 실행하는 동안 시스템이 놓인 실행환경을 의미 합니다. 주변 상황이 '이상 없음'이라 할지라도 항상 기록해야 합니다. 트래픽이 최고로 몰려 있는 비정상적인 상황도 흥미로운 시나리오가 될 수 있습니다.

화성 로버의 이동성 시나리오

원시 시나리오 : 프로세서와 플랫폼은 여러 프로젝트를 거치면서 조금씩 변경될 수 있습니다. 프로젝트를 진행할 때 어느 프로세서와 플랫폼을 선택하든 애플리케이션에 미치는 영향을 최소화하는 방향으로 시스템을 최적화 합니다.

원시 시나리오는 품질속성 시나리오는 정교하게 다듬기 전에 거치는 간단한 설명 입니다. '원시'라고 하는 이유는 좋은 시나리오가 되려면 몇번의 요리를 해줘야 하기 때문 입니다. 다시 말해, 시나리오를 만들기 전에 먼저 원시 시나리오부터 만듭니다.

 

품질 속성 시나리오를 만들 때 여섯가지 부분을 모두 상세하게 정의할 필요는 없습니다. 자극, 자극원, 반응, 반응 측정 정도만 정의하는 경우도 많습니다. 여기에 실행 환경이 특수하다면 주변 상황을 추가 하기도 합니다. 

라리언하트 프로젝트 품질 속성 시나리오

잘 작성된 품질 속성 시나리오는 요구사항을 명확하게 투영하며 모두가 이해할 수 있습니다. 정교하고 측정 가능하다면 더 바람직 합니다. 두 사람이 품질 속성 시나리오를 읽었다면 시스템 확장성이든 성능이든 유지 보수성이든 동이랗게 이해하고 있어야 합니다.

 

5.2.2 측정 가능하고 명료하게 기술하는 방법

측정하기 좋을 수록 테스트로 수월하게 할 수 있습니다. 시스템 초기에는 아키텍처가 문서만으로만 존재하지만, 이내 동작하는 시스템을 마주해야 합니다. 시나리오로 테스트를 작성할 수 없으면 그 시나리오는 명료하거나 축정 가능하지 않다는 의미 입니다.

 

5.2.3 직접해보기 : 메모를 품질 속성 시나리오로 재 구성하기

라이언 하트 이해관계자들과 미팅을 진행하면서 아래와 같은 몇가지 문장을 작성해 공유했습니다.

 

• 보고받은 질문이나 문제는 (아무리 소수의 사용자의 것이라 할지라도) 1영업일 안에 답장해야 합니다.
• 릴리스는 한달에 최소 한번은 해야 합니다. 바람직하게는 코딩을 끝내자마자 릴리즈할 수 있어야 합니다.
• RFP 인덱싱이 제대로 되었는지 확인해야 하며, 이 작업은 자동화 해야 합니다.
• 현재 개발팀의 계약이 만료되면 이 프로젝트만 담당하는 개발 팀을 신속하게 새로 구성해야 합니다.