오래된 SW 엔지니어의 평생 공부

여러 다른 글에서도 썼지만, 소프트웨어 아키텍처 설계에서 품질 속성(Quality Attribute)은 중요하게 간주되며 시스템의 성공과 연결된다고 이야기 된다. 그러나 이러한 품질 요구사항을 효과적으로 도출하는 것은 쉽지 않다. 이를 위해 품질 속성 워크숍을 진행한다. 하지만, 이 과정은 최소로 해도 하루에서 2주 가까이 소요되는 큰 작업이다.  이러한 것을 조금 더 작게 할 수 있는 '미니 품질 속성 워크숍(Mini Quality Attribute Workshop, Mini QAW, 미니 QAW)'이 유용한 도구로 활용될 수 있다.

미니 QAW 개요

미니 QAW는 전통적인 품질 속성 워크숍(Quality Attribute Workshop, QAW)의 간소화된 버전으로, 짧은 시간 내에 효율적으로 품질 요구사항을 도출하기 위해 고안되었다. 특히 애자일(Agile) 팀이나 경험이 적은 퍼실리테이터에게 적합하며, 몇 시간에서 반나절 정도의 시간으로 진행할 수 있다[1].

목적

미니 QAW의 주요 목적은 다음과 같다.
- 품질 요구사항 도출: 시스템의 주요 품질 속성을 이해하고, 이를 기반으로 아키텍처 설계에 반영합니다.
- 이해관계자 참여 촉진: 다양한 이해관계자의 의견을 수렴하여 시스템의 품질 목표를 명확히 합니다.
-효율적인 시간 활용: 짧은 시간 내에 핵심 품질 요구사항을 도출하여 프로젝트 진행 속도를 높입니다.

워크숍 구성 요소

미니 QAW를 성공적으로 진행하기 위해서는 다음과 같은 요소가 필요하다.

- 이해관계자: 시스템의 주요 사용자, 개발자, 관리자 등 다양한 관점을 제공할 수 있는 참여자들
- 퍼실리테이터: 워크숍을 이끌고 논의를 조율하는 역할을 담당하는 진행자
- 품질 속성 분류표: 성능, 보안, 가용성 등 다양한 품질 속성을 정리한 자료
- 시나리오 작성 도구: 시나리오를 작성하고 공유할 수 있는 도구나 템플릿

진행 방법

미니 QAW는 다음과 같은 단계로 진행된다.
1. 소개 및 품질 속성 이해: 퍼실리테이터가 워크숍의 목적과 품질 속성 분류표를 소개한다.
2. 이해관계자 공감 지도 작성: 참여자들이 부재 중인 이해관계자의 관점에서 품질 요구사항을 추정하여 작성한다.
3. 시나리오 브레인스토밍: 참여자들이 시스템의 품질 속성과 관련된 다양한 시나리오를 제시한다.
4. 시나리오 우선순위 결정: 제시된 시나리오에 대해 투표를 통해 우선순위를 정한다.
5. 시나리오 정제: 우선순위가 높은 시나리오를 구체화하고 상세하게 작성한다.

간단 사례

예를 들어, 온라인 도서 판매 시스템을 개발한다고 가정해보자. 이해관계자 공감 지도 작성 단계에서, 참여자들은 고객 서비스 담당자의 관점에서 "시스템이 24시간 안정적으로 운영되어야 한다"는 요구사항을 도출할 수 있다. 이러한 요구사항은 이후 시나리오 브레인스토밍과 정제 과정을 통해 구체화된다.

1. 소개 및 품질 속성 이해

퍼실리테이터는 워크숍의 목표를 소개하고, 품질 속성 분류표(예: 성능, 가용성, 보안 등)를 설명한다.

- "이 워크숍은 온라인 도서 판매 시스템의 품질 목표를 정의하고, 우선순위가 높은 품질 속성을 도출하는 것이 목적입니다."
- "품질 속성 예로는 페이지 로드 시간(성능), 시스템의 24시간 무중단 운영(가용성), 그리고 결제 정보 보호(보안)가 있습니다."

2. 이해관계자 공감 지도 작성

참여자들은 시스템과 관련된 이해관계자를 식별하고, 그들의 관점에서 품질 요구사항을 도출한다.

- **이해관계자 식별**: 고객, IT 운영팀, 서드파티 결제 제공자 등.
- **예시**: 고객 서비스 담당자 역할을 맡은 참여자는 다음과 같은 요구사항을 도출한다.
   - "고객은 사이트가 항상 사용 가능하길 원한다." → **가용성**
   - "결제 실패 없이 빠르게 완료되길 바란다." → **성능 및 신뢰성**
   - "고객 정보가 안전하게 보호되어야 한다." → **보안**

3. 시나리오 브레인스토밍

참여자들은 각 품질 속성에 대한 구체적인 시나리오를 제안한다.

- 예시 시나리오:
   - 가용성: "시스템이 예상치 못한 서버 다운타임 발생 시, 1분 이내에 복구되어야 한다."
   - 성능: "사용자가 도서 검색을 실행할 때 결과는 2초 이내에 표시되어야 한다."
   - 보안: "사용자의 결제 정보는 암호화된 채널로만 전송되어야 한다."

4. 시나리오 우선순위 결정

참여자들이 제안된 시나리오 중 가장 중요한 항목에 투표한다.

- 우선순위 예시:
   1. "결제 정보 보호(보안)" → 온라인 결제 시스템의 핵심.
   2. "2초 이내의 검색 응답(성능)" → 고객 만족도에 큰 영향.
   3. "1분 이내 서버 복구(가용성)" → 사업 지속성에 필수.

5. 시나리오 정제

우선순위가 높은 시나리오를 구체화하여 시스템 요구사항으로 전환한다.

   - 결제 정보 보호 시나리오:
    - 시나리오: 사용자가 도서를 결제할 때, 모든 결제 정보는 HTTPS 프로토콜을 사용해 암호화되어 전송된다.
    - 요구사항: 모든 결제 트랜잭션은 PCI DSS 표준을 준수해야 한다.
   - 검색 성능 시나리오:
    - 시나리오: 사용자가 도서 제목을 입력하고 검색 버튼을 누르면 2초 이내에 검색 결과가 반환된다.
    - 요구사항: 데이터베이스 쿼리 성능 최적화와 캐싱 시스템을 도입한다.

결과물

미니 QAW를 통해 다음과 같은 결과물을 얻을 수 있다.

- 우선순위가 매겨진 품질 속성 시나리오 목록: 시스템 설계 시 고려해야 할 주요 품질 요구사항
- 이해관계자들의 품질 속성에 대한 공통된 이해: 팀 내에서 품질 목표에 대한 일치된 인식
- 아키텍처 설계의 방향성 확보: 도출된 품질 요구사항을 기반으로 한 아키텍처 설계 지침

마무리

미니 QAW는 짧은 시간 내에 효율적으로 품질 요구사항을 도출하고, 이해관계자들의 참여를 촉진하는 유용한 워크숍이다. 이를 통해 시스템의 품질 목표를 명확히 하고, 아키텍처 설계의 방향성을 확보할 수 있다.

미니 QAW에 대해 더 자세히 알고 싶다면, [1], [2] 를 참고하도록 하자. 이러한 자료를 통해 미니 QAW의 구체적인 진행 방법과 실제 사례를 더욱 깊이 이해하실 수 있을 것이다.

참고 문서

[1] Discover Quality Requirements with the Mini-QAW, https://re-magazine.ireb.org/articles/discover-quality-requirements-with-the-mini-qaw
[2] SATURN 2016 Talk: Discover Quality Requirements with the Mini QAW, https://www.youtube.com/watch?v=YGeqqYrCHHg

최근에 Facebook에서 Netflix Architecture[1]라는 포스팅을 본 적이 있다.  이미 댓글에서도 언급했지만, 실재로는 기술 스택(Tehcnology Stack)을 표현한 것이었고 아키텍처 혹은 시스템 아키텍처라고 보기는 어려웠다. 이 두 용어는  자주 사용되지만, 이 두 용어는 서로 다른 개념을 지칭한다. 아마도 이 둘을 혼동하는 이유는 밀접하게 연관되어 있기 때문일 것이다. 

Technology Stack (기술 스택)

기술 스택은 특정 소프트웨어 프로젝트 또는 애플리케이션을 구축할 때 사용되는 기술들의 집합을 의미한다. 이는 프로그래밍 언어, 프레임워크, 데이터베이스, 서버 환경, API 등을 포함할 수 있다. 기술 스택은 주로 개발에 사용되는 도구와 기술들의 "목록"으로 볼 수 있다. 종종 기성 상용품(Commercial Off The Shelf, COTS)인 경우도 많다.

예를 들어, 웹 애플리케이션을 개발하기 위해 다음과 같은 기술 스택을 사용할 수 있습니다:

• 프론트엔드: React, Angular
• 백엔드: Node.js, Ruby on Rails
• 데이터베이스: PostgreSQL, MongoDB
• 서버 환경: AWS, Azure

System Architecture (시스템 아키텍처)

시스템 아키텍처는 소프트웨어 시스템의 구조적 설계를 말한다. 일반적으로는 구조를 설명하기 위해 시스템의 컴포넌트와 그들이 서로 상호 작용하는 방식을 설명하는 것을 가리킨다. 이러한 설명은 시스템의 요구 사항을 어떻게 만족하는지를 보여 주기 위한 것이 하나의 용처이다. 

예를 들어, 시스템 아키텍처 설계에는 기술 스택 뿐 아니라, 앞에서 이야기 한 것 처럼 시스템의 요구 사항을 어떻게 만족하는지 보여 주기 위한 고려사항이 포함될 수 있다.

- 구성 요소의 배치: 서비스 지향 아키텍처(SOA), 마이크로서비스
- 데이터 흐름: 동기식 API 호출, 비동기식 메시징 시스템
- 보안 구조: 인증 및 권한 부여 방식

결론

기술 스택은 "무엇을" 사용할지에 대한 결정인 반면, 시스템 아키텍처는 "어떻게" 시스템을 구성하여 요구 사항을 만족하는지에 대한 계획이나 설명이다.  개발자와 설계자가 이 두 개념을 혼동하는 것은, 두 분야가 각각 다루는 세부사항과 전반적인 설계가 서로 긴밀히 연결되어 있기 때문일 수 있다. 아키텍처 설명하는데 기술 스택이 사용될 수 있고, 기술 스택이 아키텍처에서 설명하는 것이 부족할 수 있다는 것을 이해한다면 복잡하고 어려운 개발 업무를 효과적으로 진행할 수 있는 기반이 된다.

참고 문서

[1] Netflix Architecture, https://www.facebook.com/tipsbykavindu/photos/netflix-architecture-/536074732617368/?_rdr

[1]의 4장은 패턴 언어 개요를 다루고 있다. 여기서는 기본 메시지 구조 관련한 패턴에 대해 살펴 보자

1. 아토믹 파라미터 (Atomic Parameter)

• 설명: API 메시지에서 사용되는 가장 기본적인 단위로, 단순한 비정형 데이터(예: 숫자, 문자열, 불리언 등)를 표현.
• 주요 특징:
  • 메시지 교환의 기본 전송 단위로 사용.
  • 단일 값으로 명확하게 정의되어 있음.
  • 이름, 타입, 선택성 등을 명시하여 데이터의 의미를 전달.
• 포스의 충돌:
  • 과도한 사용 시 API의 효율성이 떨어질 수 있음.
  • 단일 값만으로 표현할 수 없는 복잡한 구조의 데이터 요구에 대응하기 어려움​

2. 아토믹 파라미터 리스트 (Atomic Parameter List)

• 설명: 여러 개의 아토믹 파라미터가 밀접하게 연관되어 있을 때 이를 하나의 그룹으로 결합해 표현하는 방식.
• 주요 특징:
  • 관련된 데이터 엘리먼트를 논리적 그룹으로 묶음.
  • 클라이언트가 특정한 데이터 필드만 선택적으로 요청할 수 있도록 허용.
  • 리스트는 위치 인덱스 또는 키로 식별되며, 필요 시 반복적으로 사용할 수 있음.
• 포스의 충돌:
  • 과도한 중첩으로 인해 데이터 파싱과 처리의 복잡도가 증가할 수 있음.
  • 특정 플랫폼에서 스칼라 값의 제한으로 인한 구현 문제 발생 가능.

3. 파라미터 트리 (Parameter Tree)

• 설명: 아토믹 파라미터와 리스트만으로 표현할 수 없는 복잡한 데이터를 계층적 구조로 정의.
• 주요 특징:
  • 복잡한 데이터 구조를 계층적으로 표현해 데이터의 포함 관계를 명확히 함.
  • 각 노드는 단일 아토믹 파라미터, 리스트, 또는 또 다른 트리로 구성될 수 있음.
  • 재귀적으로 정의되며, JSON 등에서 객체의 중첩 구조를 표현하는 데 유용.
• 포스의 충돌:
  • 중첩 구조가 지나치게 복잡해지면 대역폭과 성능 저하 우려.
  • 복잡한 구조의 데이터 트리로 인해 API 간 상호운용성이 떨어질 수 있음.

4. 파라미터 포리스트 (Parameter Forest)

• 설명: 여러 개의 파라미터 트리를 그룹화해 최상위 레벨에서 관리하는 패턴.
• 주요 특징:
  • 여러 트리들을 하나의 구조로 결합하여 사용자가 필요한 데이터를 쉽게 참조 가능.
  • 다양한 파라미터 트리를 독립적으로 관리할 수 있도록 함.
  • 요청이나 응답 본문에서 복수의 파라미터 트리를 노출.
• 포스의 충돌:
  • 복잡한 데이터 구조로 인해 직렬화와 역직렬화의 부담이 커질 수 있음.
  • 구조적 복잡성으로 인해 메시지 교환 시 불필요한 데이터 전송이 발생할 위험.

참고 문헌
[1]  올라프 짐머만 , 미르코 스토커 , 다니엘 뤼브케 , 우베 즈둔 , 세자레 파우타소 , "마이크로서비스 API 디자인 패턴: 쉬운 통합을 위한 결합도 최적화 전략" 에이콘. 이승범 역