vlaskos/brief-to-architecture

ASR 분석(Analysis of Architecturally Significant Requirements, ASR 분석)

브리프는 명세가 아닙니다. 브리프는 온갖 바람, 가정, 부분적으로만 명시된 제약 조건이 뒤섞인 더미이며, 그 안에는 시스템의 형태와 비용을 실제로 결정할 몇 가지 요구사항이 숨겨져 있습니다. 이 스킬은 그러한 요구사항을 찾아내어 정밀하게 만들고, 누군가가 추정이나 설계에 착수하기 전에 서로 상충하는지 확인합니다.

**아키텍처적으로 중요한 요구사항(ASR, Architecturally Significant Requirement)**이란 아키텍처에 측정 가능한 영향을 미치는 요구사항입니다. 즉, 이를 충족하려면 구조적 선택을 강제하거나, 기술을 제약하거나, 달성하기 어려운 품질 기준을 설정하거나, 다른 요구사항과 상호작용하여 옵션을 제한합니다. 브리프에 있는 대부분의 요구사항은 아키텍처적으로 중요하지 않습니다. 핵심은 수많은 요구사항 중에서 몇 가지 중요한 것을 분리하고, 각각이 왜 중요한지 설명하는 것입니다.

이 작업의 품질 속성 측면은 국제 표준 제품 품질 모델인 ISO/IEC 25010에 기반을 둡니다. 표준화된 품질 특성 세트를 사용하면 분석이 항상 완전하게 이루어지고(매번 동일한 차원을 확인), 모든 사람이 공유하는 어휘를 제공합니다. references/quality-model.md를 참조하세요.

파이프라인

브리프를 6단계로 실행합니다. 각 단계는 다음 단계에서 사용하는 산출물을 생성합니다.

1. 추출하되, 받아쓰지 마십시오. 원시 입력을 읽고 실제 요구사항(기능, 불만, 또는 우연히 언급된 형태로 명시된 경우도 포함)을 추출해내십시오. "블랙프라이데이 트래픽이 평소의 40배입니다"와 같은 문장은 기능 요청이 아닙니다. 이는 성능 및 확장성 요구사항이 위장된 형태입니다. 해석하십시오. 무엇이 아키텍처적으로 중요한지 인식하는 방법은 references/asr-framework.md를 참조하십시오.

2. 분류하십시오. 추출된 각 요구사항을 다음 세 가지 버킷 중 하나로 분류하십시오:

   • 기능(Functional) — 시스템이 해야 하는 일.
   • 품질 속성(Quality Attribute) — 시스템이 얼마나 잘 해야 하는지 (성능, 신뢰성, 보안, 유지보수성 등). 매번 동일한 영역을 다루도록 ISO/IEC 25010 특성을 사용하십시오 — references/quality-model.md.
   • 제약 조건(Constraint) — 고정되어 있고 협상 불가능한 경계(필수 기술, 규정, 마감일, 기존 시스템). 제약 조건은 설계의 대상이 아닙니다. 다른 모든 것을 결정합니다.

3. 다듬으십시오(Sharpen). 각 중요한 요구사항을 모호함이 없고 테스트 가능하도록 다시 쓰고, 그 아키텍처적 함의(architectural implication) — 요구사항을 진지하게 받아들일 때 발생하는 구조적 결과 — 를 명시하십시오. 작성자가 몰래 집어넣은 해결책은 걷어내십시오("Kafka 사용"은 제안된 메커니즘이지 요구사항이 아닙니다. 그 뒤에 있는 처리량 또는 결합 분리가 진정한 요구사항입니다). 테스트할 수 없는 요구사항은 추정할 수 없습니다.

4. 두 가지 축으로 우선순위를 매기십시오. 모든 ASR이 동등한 주의를 받을 자격이 있는 것은 아닙니다. 각각을 다음 기준으로 평가하십시오:

   • 비즈니스 가치(Business value) — 해당 결과가 고객에게 얼마나 중요한지.
   • 아키텍처 영향도(Architectural impact) — 설계를 얼마나 제약하고, 되돌리기가 얼마나 비용이 많이 드는지. (높은 영향도는 되돌릴 수 없는 정도와 영향 범위에 관한 것이지, 노력이 아닙니다). 두 기준 모두에서 높은 요구사항이 바로 아키텍처가 실제로 결정되는 곳입니다. 분석 시간을 이 부분에 집중하십시오. references/scenarios-and-priorities.md를 참조하십시오.

5. 실현 가능성을 확인하십시오. 무엇이든 설계하기 전에, 우선순위가 높은 요구사항들이 공존할 수 있는지 확인하십시오. 가장 위험한 브리프는 내부적으로 모순됩니다. 즉, 지연 시간 목표, 일관성 목표, 비용 상한선이 모두 동시에 참일 수 없는 경우입니다. 구체적인 방법(숫자 요구사항에 대한 산술적 방법 포함)은 references/feasibility-check.md를 참조하십시오.

6. 시나리오를 명시하고 전략을 선택하십시오. 우선순위가 높은 품질 속성에 대해 측정 가능한 품질 시나리오(트리거, 조건, 측정 가능한 응답)를 작성한 다음, 각각을 만족시킬 설계 전략(design strategies) 을 비용과 함께 선택하십시오. references/scenarios-and-priorities.md 및 references/design-strategies.md를 참조하십시오.

분석을 신뢰할 수 있게 만드는 규율

• 악취(안 좋은 패턴)를 포착하십시오. 브리프에는 반복되는 실패 패턴이 있습니다: 모호한 최상급 표현, 숨겨진 가정, 단위나 출처가 없는 숫자, 서로 모순되는 요구사항 등입니다. references/brief-smells.md는 이러한 패턴의 목록과 해당 패턴이 보일 때 무엇을 질문해야 하는지를 보여줍니다.
• 모든 가정에 표시를 하십시오. 브리프가 침묵하고 당신이 그 공백을 메울 때, 해당 가정에 레이블을 붙이십시오: 채워진 공백(filled gap) (정보가 누락되어 기본값을 제공함)인지, 해석(interpretation) (모호하여 특정 방향으로 읽음)인지, 범위 축소(scope narrowing) (의도적으로 무언가를 제외함)인지 여부를 명시하십시오. 표시되지 않은 가정 위에 세워진 추정은 양복을 입은 추측에 불과합니다.
• 형태를 바꾸는 질문으로 마무리하십시오. 좋은 분석의 결과물에는 그 답변이 아키텍처를 가장 크게 바꿀 수 있는 두세 가지 질문이 포함됩니다. 이 질문들이 다음 고객 대화의 주제가 되어야 합니다.
• 추정은 그 아래에 있는 분석만큼만 방어할 수 있습니다. 이것이 분석이 먼저 이루어져야 하는 이유입니다. 분석은 당신이 고객에게 제시하는 숫자를 신뢰할 수 있는 근거로 만들어 줍니다.

이 스킬을 사용하는 방법

• 브리프를 처음부터 끝까지 분석하기 → 위의 6단계 파이프라인을 실행하십시오.
• 무엇이 아키텍처적으로 중요한지 결정하기 → references/asr-framework.md.
• 품질 속성 선택 및 포괄 범위 결정하기 → references/quality-model.md (ISO/IEC 25010).
• 테스트 가능한 품질 시나리오 작성 및 우선순위 지정하기 → references/scenarios-and-priorities.md.
• 품질 속성별 설계 접근 방식 선택하기 → references/design-strategies.md.
• 모순과 불가능한 조합 발견하기 → references/feasibility-check.md.
• 브리프를 비판적으로 읽기 → references/brief-smells.md.
• 서면 결과물 구성하기 → references/output-template.md.