78 lines
2.8 KiB
Markdown
78 lines
2.8 KiB
Markdown
---
|
|
title: "솔루션 설계가 중요한 이유"
|
|
description: 다중 에픽 프로젝트에서 솔루션 설계 단계가 중요한 이유
|
|
sidebar:
|
|
order: 6
|
|
---
|
|
|
|
단계 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배 빠릅니다.
|
|
:::
|