BMAD-METHOD/docs/ko-kr/explanation/why-solutioning-matters.md

title	description	sidebar
솔루션 설계가 중요한 이유	다중 에픽 프로젝트에서 솔루션 설계 단계가 중요한 이유	order 5

단계 3(솔루션 설계)은 계획 단계의 무엇을 만들지를 어떻게 만들지로 바꿉니다. 구현이 시작되기 전에 아키텍처 결정을 문서화해 다중 에픽 프로젝트에서 에이전트 충돌을 방지합니다.

솔루션 설계가 없을 때의 문제

에이전트 1은 에픽 1을 REST API로 구현
에이전트 2는 에픽 2를 GraphQL로 구현
결과: 일관되지 않은 API 설계와 통합 난이도 증가

여러 에이전트가 공유 아키텍처 지침 없이 시스템의 서로 다른 부분을 구현하면 서로 충돌하는 독립적 기술 결정을 내릴 수 있습니다.

솔루션 설계가 있을 때의 해결책

아키텍처 워크플로가 결정: "모든 API에 GraphQL 사용"
모든 에이전트가 아키텍처 결정을 따름
결과: 일관된 구현, 충돌 없음

기술 결정을 명시적으로 문서화하면 모든 에이전트가 일관되게 구현하고 통합이 단순해집니다.

솔루션 설계 vs 계획

측면	계획 (단계 2)	솔루션 설계 (단계 3)
질문	무엇을, 왜?	어떻게? 그리고 어떤 작업 단위로?
출력	FRs/NFRs(요구사항)	아키텍처 + 에픽/스토리
에이전트	PM	아키텍트 → PM
대상	이해관계자	개발자
문서	PRD(기능/비기능 요구사항)	아키텍처 + 에픽 파일
수준	비즈니스 로직	기술 설계 + 작업 분해

핵심 원칙

기술 결정을 명시적으로 문서화해 모든 에이전트가 일관되게 구현하도록 합니다.

이것은 다음을 방지합니다.

• API 스타일 충돌(REST vs GraphQL)
• 데이터베이스 설계 불일치
• 상태 관리 방식 차이
• 이름 규칙 불일치
• 보안 접근 방식 차이

솔루션 설계가 필요한 때

트랙	솔루션 설계 필요 여부
빠른 흐름	아니요 - 완전히 건너뜁니다
BMad Method 단순	선택 사항
BMad Method 복잡	예
엔터프라이즈	예

:::tip[경험칙] 서로 다른 에이전트가 구현할 수 있는 여러 에픽이 있다면 솔루션 설계가 필요합니다. :::

건너뛸 때의 비용

복잡한 프로젝트에서 솔루션 설계를 건너뛰면 다음으로 이어집니다.

• 스프린트 중 발견되는 통합 이슈
• 충돌하는 구현으로 인한 재작업
• 전체적으로 더 긴 개발 시간
• 일관되지 않은 패턴에서 생기는 기술 부채

:::caution[비용 배율] 방향이 어긋나는 문제를 솔루션 설계에서 잡는 것이 구현 중 발견하는 것보다 10배 빠릅니다. :::