솔루션 설계가 중요한 이유
단계 3(솔루션 설계)은 계획에서 정한 무엇을 만들 것인가를 어떻게 만들 것인가라는 기술 설계로 구체화합니다. 구현이 시작되기 전에 아키텍처 결정을 문서화해 다중 에픽 프로젝트에서 에이전트 충돌을 방지합니다.
솔루션 설계가 없을 때의 문제
섹션 제목: “솔루션 설계가 없을 때의 문제”에이전트 1은 에픽 1을 REST API로 구현에이전트 2는 에픽 2를 GraphQL로 구현결과: 일관되지 않은 API 설계와 통합 난이도 증가여러 에이전트가 공유 아키텍처 지침 없이 시스템의 서로 다른 부분을 구현하면 각자 기술 결정을 내리다가 서로 충돌할 수 있습니다.
솔루션 설계가 있을 때의 해결책
섹션 제목: “솔루션 설계가 있을 때의 해결책”아키텍처 워크플로가 결정: "모든 API에 GraphQL 사용"모든 에이전트가 아키텍처 결정을 따름결과: 일관된 구현, 충돌 없음기술 결정을 명시적으로 문서화하면 모든 에이전트가 일관되게 구현하고 통합이 단순해집니다.
솔루션 설계 vs 계획
섹션 제목: “솔루션 설계 vs 계획”| 측면 | 계획 (단계 2) | 솔루션 설계 (단계 3) |
|---|---|---|
| 질문 | 무엇을, 왜? | 어떻게? 그리고 어떤 작업 단위로? |
| 출력 | FRs/NFRs(요구사항) | 아키텍처 + 에픽/스토리 |
| 에이전트 | PM | 아키텍트 → PM |
| 대상 | 이해관계자 | 개발자 |
| 문서 | PRD(기능/비기능 요구사항) | 아키텍처 + 에픽 파일 |
| 수준 | 비즈니스 로직 | 기술 설계 + 작업 분해 |
핵심 원칙
섹션 제목: “핵심 원칙”기술 결정을 명시적으로 문서화해 모든 에이전트가 일관되게 구현하도록 합니다.
기술 결정을 명시하면 다음 문제를 방지할 수 있습니다.
- API 스타일 충돌(REST vs GraphQL)
- 데이터베이스 설계 불일치
- 상태 관리 방식 차이
- 이름 규칙 불일치
- 보안 접근 방식 차이
솔루션 설계 깊이 선택하기
섹션 제목: “솔루션 설계 깊이 선택하기”| 작업 특성 | 솔루션 설계 지침 |
|---|---|
| 기존 패턴이 분명한 국소 변경 | 대체로 필요하지 않음 |
| 제약을 알고 있는 여러 관련 컴포넌트 | 조율 위험에 따라 선택 |
| 여러 에픽 또는 시스템 간 의사결정 | 구현 방향을 맞추기 위해 필요 |
| 규제 대상, 고위험 또는 엔터프라이즈 이니셔티브 | 필수 거버넌스를 따르며 일반적으로 솔루션 설계가 필요 |
솔루션 설계는 bmad-build가 사용할 수 있는 컨텍스트를 바꿀 뿐, 구현 워크플로를 바꾸지는 않습니다.
건너뛸 때의 비용
섹션 제목: “건너뛸 때의 비용”복잡한 프로젝트에서 솔루션 설계를 건너뛰면 다음 문제가 생깁니다.
- 스프린트 중 발견되는 통합 이슈
- 충돌하는 구현으로 인한 재작업
- 전체적으로 더 긴 개발 시간
- 일관되지 않은 패턴에서 생기는 기술 부채