# 마이크로 스프린트

> **이 장에서 배우는 것**
> 작업을 어디까지 쪼개는지, 왜 크기보다 독립성이 중요한지, 그리고 의존성을
> 끊는다는 게 실제로 무슨 뜻인지.

## 원자적 의도 단위

작업을 **더 이상 쪼갤 수 없는 단위**까지 내립니다.

```
✗ "회원 관리 기능"                    ← 기능 단위
✓ "프로필 사진 업로드 버튼 추가"       ← 원자 단위
✓ "비밀번호 재설정 메일 발송"          ← 원자 단위
✓ "탈퇴 시 개인정보 마스킹"            ← 원자 단위
```

각각이 **하나의 스프린트**입니다. 분 단위로 끝날 수 있습니다.

## 핵심은 크기가 아니라 독립성

여기서 오해가 자주 생깁니다. **"백로그를 잘게 쪼개면 되는 것 아닌가?"**

쪼개는 것만으로는 부족합니다. 쪼갠 조각들이 **서로 의존하면** 결국 순서대로
처리해야 하고, 병렬성이 안 나옵니다.

```mermaid
graph TD
  subgraph "쪼갰지만 의존적"
    A1["1. DB 스키마 변경"] --> A2["2. API 수정"]
    A2 --> A3["3. 화면 연결"]
  end
  subgraph "독립적"
    B1["사진 업로드"]
    B2["비밀번호 재설정"]
    B3["탈퇴 마스킹"]
  end
```

왼쪽은 세 조각이지만 **한 줄로 서 있습니다.** 1이 끝나야 2를 시작합니다. 쪼갠
의미가 없습니다.

오른쪽은 셋이 서로를 안 기다립니다. **동시에 진행됩니다.**

## 독립적이면 무엇이 좋은가

| 성질 | 결과 |
|---|---|
| **병렬 실행** | 서로 안 기다리니 10개를 동시에 |
| **실패 범위가 작음** | 하나가 틀려도 그 하나만 다시 |
| **대기 시간 0** | 스프린트 경계에서 모두가 모일 이유가 없음 |
| **컨텍스트가 깨끗함** | 각자 [자기 컨텍스트만](/guide/ai-context-window) |

마지막이 실무에서 큽니다. 큰 작업 하나를 통째로 맡기면 컨텍스트가 차서 일관성이
깨지지만, 원자 단위로 나누면 각자 깨끗한 상태에서 시작합니다.

## 의존성을 끊는다는 것

그러면 "DB 스키마 → API → 화면"처럼 **원래 순서가 있는 일**은 어떻게 합니까?

세 가지 방법이 있습니다.

### 1. 세로로 자르기

층(layer)으로 자르지 말고 **기능으로 자릅니다.**

```
✗ 가로: [전체 DB 작업] → [전체 API 작업] → [전체 화면 작업]
✓ 세로: [사진 업로드: DB+API+화면] · [비밀번호: DB+API+화면]
```

각 조각이 **혼자서 끝까지 갑니다.** 서로 안 기다립니다.

### 2. 계약을 먼저 고정하기

정말 나눠야 한다면 **경계를 먼저 정합니다.**

```
1단계: API 응답 형식을 먼저 확정 (이건 짧게 끝남)
2단계: 백엔드와 프론트엔드가 그 형식을 보고 동시에 진행
```

형식이 정해져 있으면 서로를 기다릴 필요가 없습니다.

### 3. 순서가 진짜로 필요하면 인정하기

억지로 나누지 마세요. 마이그레이션처럼 **본질적으로 순차인 작업**이 있습니다.
그건 하나의 마이크로 스프린트로 묶습니다.

> **모든 것을 병렬로 만들려고 하지 마세요.** 병렬이 가능한 것을 병렬로 하는 게
> 목적이지, 억지로 나누는 게 목적이 아닙니다.

## 실무에서 나누는 기준

작업을 앞에 두고 이렇게 물어보세요.

```
□ 이것만 따로 완료할 수 있나?
□ 이것만 따로 테스트할 수 있나?
□ 이것만 따로 배포할 수 있나?
□ 다른 작업이 끝나야 시작할 수 있나?  ← 예면 아직 안 나뉜 것
```

**세 번째(따로 배포)가 가장 강한 기준입니다.** 따로 배포할 수 있으면 확실히
독립적입니다.

## 크기의 감각

| 이 정도면 | 판단 |
|---|---|
| 한 문장으로 설명된다 | 적당 |
| "그리고"가 들어간다 | 아직 큼. 나눌 수 있음 |
| 테스트를 2~3개로 표현할 수 있다 | 적당 |
| 여러 팀이 관여한다 | 큼 |

**"그리고"가 신호입니다.** "사진을 업로드하고 썸네일을 만든다"는 두 개입니다.

## 자주 하는 오해

### "너무 잘게 나누면 관리가 더 힘들지 않나?"

사람이 관리하면 그렇습니다. 스프린트 10개를 사람이 추적하면 그게 일입니다.
**그런데 추적을 자동화하면 개수는 문제가 안 됩니다.** 원자 단위가 성립하는 것은
관리 비용이 낮아졌기 때문입니다.

### "이렇게 나누면 큰 그림을 잃지 않나?"

큰 그림은 **의도**에 있습니다. 마이크로 스프린트는 실행 단위이지 계획 단위가
아닙니다. "회원 관리를 개선한다"는 목표는 그대로 두고, 실행만 원자 단위로
합니다.

---

## 확인

**1. 백로그를 잘게 쪼개기만 해서는 왜 부족합니까?**

<details>
<summary>답</summary>

**쪼갠 조각들이 서로 의존하면 결국 순서대로 처리해야 하기** 때문입니다. 세
조각으로 나눠도 한 줄로 서 있으면 병렬성이 안 나옵니다. 크기가 아니라 독립성이
핵심입니다.
</details>

**2. "가로로 자르지 말고 세로로 자르라"는 게 무슨 뜻입니까?**

<details>
<summary>답</summary>

층(DB/API/화면)으로 자르지 말고 **기능으로 자르라**는 뜻입니다. "사진 업로드"
하나가 DB부터 화면까지 혼자 끝까지 가면 다른 작업을 기다리지 않습니다.
</details>

**3. 독립성을 판정하는 가장 강한 기준은?**

<details>
<summary>답</summary>

**따로 배포할 수 있는가**입니다. 따로 완료·테스트·배포가 가능하면 확실히
독립적입니다.
</details>

---

이제 우리 백로그로 직접 해봅니다. 40분짜리 실습입니다 →
[우리 백로그를 쪼개보기](/guide/ha-try-splitting)