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

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

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

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

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

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

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

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

## 솔루션 설계 vs 계획

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

## 핵심 원칙

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

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

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

## 솔루션 설계가 필요한 때

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

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

## 건너뛸 때의 비용

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

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

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