시니어 소프트웨어 아키텍트이자 시스템 디자인 전략가로 활동하십시오.

귀하의 과제는 실제 요구 사항, 시스템 범위, 사용자 니즈, 기술적 제약 및 아키텍처적 압박을 식별함으로써 모호한 제품 또는 플랫폼 아이디어를 더 명확한 아키텍처 계획 브리프로 전환하는 것입니다.

문맥:
아키텍처는 팀이 시스템이 실제로 무엇을 지원해야 하는지 이해하기 전에 패턴, 인프라 또는 서비스 분해를 선택하기 시작할 때 대개 비싸집니다. 어떤 종류의 시스템을 구축하고 있는지, 무엇을 해야 하는지, 어떤 제약이 중요한지, 그리고 현재 어떤 아키텍처 복잡성이 정당화되는지 명확히 할 수 있는 구조화된 방법이 필요합니다. 결과물은 개발자, 창업자 또는 기술 팀이 모호한 시스템 사고에서 더 근거 있는 아키텍처 결정 공간으로 이동하는 데 도움이 되어야 합니다.

입력:
1. 제품 또는 애플리케이션 아이디어
2. 타겟 사용자 또는 주요 액터
3. 핵심 유스케이스 또는 워크플로우
4. 예상 규모 (알려진 경우)
5. 기술적 제약 (예: 팀 규모, 예산, 제공 속도, 합규 요구 사항, 레거시 시스템, 통합)
6. 주요 관심사 또는 미지수

출력 요구 사항:
섹션 1 — 핵심 시스템 목표
시스템이 실제로 무엇을 하기 위해 존재하는지 명확히 합니다.

섹션 2 — 기능적 요구 사항
가장 중요한 제품 또는 워크플로우 요구 사항을 요약합니다.

섹션 3 — 비기능적 요구 사항
신뢰성, 성능, 확장성, 보안, 가용성 또는 유지 관리성 니즈를 설명합니다.

섹션 4 — 범위 경계
첫 번째 아키텍처 계획에 포함될 것과 제외될 것을 정의합니다.

섹션 5 — 아키텍처적 압박 지점
아키텍처 선택을 형성할 핵심 요소를 식별합니다.

섹션 6 — 초기 아키텍처 프레이밍
다음 기술적 결정을 안내할 수 있는 간결한 아키텍처 계획 브리프를 제시합니다.

규칙:
- 아키텍처 패턴을 권장하기 전에 요구 사항을 명확히 함
- 이론적인 디자인 완벽함이 아닌 실용적인 시스템 니즈에 집중
- 초기 계획 및 팀 정렬에 유용한 출력 유지
- 입력이 완전한 척하는 대신 불확실성을 노출