# 프로세스 4단계 지도

> **이 장에서 배우는 것**
> 다음 네 장이 각각 무엇을 다루는지, 그리고 익숙한 분석·설계·구현·시험이 이
> 안에서 어디로 갔는지.

여기까지 개념을 봤습니다 — [남은 병목](/guide/ha-agile-limits),
[바뀌는 지점](/guide/ha-what-changes),
[마이크로 스프린트](/guide/ha-micro-sprint),
[IntentOps](/guide/ha-intentops),
[유동적 소프트웨어](/guide/ha-fluid-software).

이제 실제 프로세스입니다. 네 장으로 이어지는데, 들어가기 전에 전체를 한 장에서
봅니다.

## 4개 프로세스

```mermaid
graph TD
  P1["프로세스 1<br/>의도 포착"] --> P2["프로세스 2<br/>에이전트 오케스트레이션"]
  P2 --> P3["프로세스 3<br/>자동 검증"]
  P3 --> P4["프로세스 4<br/>즉시 배포"]
  P3 -.->|"테스트 실패"| P2
  P3 -.->|"재시도 초과 — 명세가 문제"| P1
  P4 -.->|"모니터링 신호"| P1
```

점선 셋이 이 그림의 내용입니다.

- **프로세스 3 → 2 (자가 치유)**: 테스트가 실패하면 사람을 부르지 않고 코드를
  다시 만듭니다. 이게 루프의 기본 동작입니다.
- **프로세스 3 → 1 (되돌아감)**: 몇 번 고쳐도 안 되면 코드가 아니라 **명세나
  테스트가 틀린 것**입니다. 여기서 사람이 들어옵니다.
- **프로세스 4 → 1 (루프가 닫힘)**: 배포 후 모니터링 신호가 다음 사이클의 의도가
  됩니다.

한 바퀴가 **분·시간 단위**입니다. 2주가 아닙니다.

## 각 프로세스가 답하는 질문

| 프로세스 | 핵심 질문 | 산출물 |
|---|---|---|
| 1. 의도 포착 | **무엇을 만드는가** — 해석의 여지 없이 | 명세 + 완료 판정 테스트 |
| 2. 오케스트레이션 | **어떻게 만드는가** | 동작하는 코드 |
| 3. 자동 검증 | **정말 됐는가** | 전부 통과한 테스트 결과 |
| 4. 즉시 배포 | **실제로 쓰이는가** | 배포된 변경 + 모니터링 신호 |

## 익숙한 4단계는 어디로 갔나

분석 → 설계 → 구현 → 시험. 이 순서로 일해온 조직이라면 위 그림이 낯설 것입니다.
사라진 게 아니라 **자리가 바뀌었습니다.**

| 익숙한 단계 | 어디로 갔나 | 무엇이 달라졌나 |
|---|---|---|
| **분석** | 프로세스 1 | 회의가 아니라 PM 에이전트의 문답. 회의록이 아니라 **문답이 그대로 명세** |
| **설계** | 프로세스 2 안의 아키텍트 | 별도 단계가 아니라 **구현·리뷰와 동시에 도는 역할** |
| **구현** | 프로세스 2 안의 코딩 | 사람이 아니라 에이전트가 씀. 코드는 자산이 아니라 [파생물](/guide/ha-fluid-software) |
| **시험** | 앞(IntentOps) + 프로세스 3 | 맨 뒤가 아니라 **명세와 함께 앞에서 정해지고**, 뒤에서는 자동 판정만 |
| (배포) | 프로세스 4 | 단계 밖의 이벤트가 아니라 **루프 안** |

가운데 두 줄을 조금 더 봅니다.

### 설계는 사라지지 않았습니다

[프로세스 2](/guide/ha-phase2-orchestration)에 아키텍트 에이전트가 있고, 시스템
구조와 변경 범위를 설계하는 일이 그대로 있습니다. 다만 **구현이 끝나기를
기다렸다가 리뷰가 시작되는 순서가 아닙니다.** 셋이 동시에 돌고, 문제가 발견되면
되돌아갑니다.

그리고 사람이 설계에 개입하는 지점이 정해져 있습니다.

1. **설계 방향이 명세와 어긋날 때**
2. **되돌릴 수 없는 결정** — 스키마 변경, 외부 계약 변경

이 둘은 사이클이 아무리 짧아져도 사람이 봅니다.

### 시험은 앞으로 당겨졌습니다

전통적으로 시험은 마지막 관문이었습니다. 여기서는
[IntentOps](/guide/ha-intentops)에서 **명세와 함께 테스트를 먼저 정하고**,
프로세스 3은 그걸 돌려 판정만 합니다.

순서가 바뀐 이유는 하나입니다. 사람이 완료를 판정하지 않으려면 **판정 기준이
시작 시점에 있어야** 하기 때문입니다.

## 순서가 아니라 조율이 바뀐 것입니다

이 지도를 보고 "결국 워터폴을 빠르게 도는 것 아닌가"라고 읽기 쉽습니다. 그렇지
않습니다.

```mermaid
graph TD
  W["순차 모델"] --> W1["설계가 끝나야 구현<br/>구현이 끝나야 리뷰"]
  H["프로세스 2"] --> H1["아키텍트 · 코딩 · 리뷰가<br/>동시에 돌며 주고받음"]
```

[바뀌는 지점](/guide/ha-what-changes)에서 본 대로 이 방법론이 바꾸는 것은 단계의
순서나 길이가 아니라 **조율의 주체**입니다. 위 매핑 표는 익숙한 이름이 어디에
들어갔는지 보여주는 지도일 뿐이고, 네 프로세스를 **순차 게이트로 읽으면
안 됩니다.**

## 사람은 어디에 있나

네 프로세스 어디에도 "사람이 코드를 쓴다"가 없습니다. 대신 세 곳에 있습니다.

| 위치 | 하는 일 |
|---|---|
| 프로세스 1 **앞** | 무엇을 만들지 정하는 판단 |
| 프로세스 2 **안** | 설계 방향, 그리고 되돌릴 수 없는 결정의 승인 |
| 프로세스 3 **의 기준** | 테스트가 진짜 합격 기준인지 보는 눈 |

세 번째가 가장 자주 빠집니다. 루프의 목표는 테스트 통과라서 [기준이 얕으면 빈틈을
정확히 파고듭니다](/guide/ha-phase3-validation).

## 넷을 다 도입해야 하나

아닙니다. 프로세스 4(즉시 배포)는 전제 조건이 가장 많습니다 — 자동 배포
파이프라인, 분 단위 롤백, 실시간 모니터링. 갖춰지지 않았다면 **프로세스 1~3만
쓰고 배포는 기존대로 사람 승인**으로 두는 것이 맞습니다.

## 자주 하는 오해

### "그럼 설계 문서는 안 쓰나?"

문서의 자리에 **명세와 테스트**가 들어갑니다. 사람에게 설명하려고 쓰던 문서는
줄고, 사람과 에이전트가 같이 읽는 명세가 남습니다.
[유동적 소프트웨어](/guide/ha-fluid-software)에서 본 "지켜야 할 자산이 코드에서
명세+테스트로 옮겨간다"와 같은 이야기입니다.

### "단계별 산출물 검토가 필요한 조직인데요"

프로세스마다 산출물이 있으니 검토 지점 자체는 만들 수 있습니다. 다만 **거는 위치가
다릅니다.** 사이클이 분·시간 단위로 도는데 사이클마다 사람 검토를 걸면 없앴던 조율
비용이 그대로 돌아옵니다. 검토는 개별 사이클이 아니라 **명세와 테스트 기준** 쪽에
겁니다 — 그게 [가드레일](/guide/ha-guardrails)의 주제입니다.

---

## 확인

**1. 익숙한 "설계" 단계는 어디로 갔습니까?**

<details>
<summary>답</summary>

**프로세스 2 안의 아키텍트 역할**로 갔습니다. 없어진 게 아니라 별도 단계가 아니게
된 것이고, 구현·리뷰와 **동시에** 돕니다. 다만 되돌릴 수 없는 결정(스키마 변경,
외부 계약 변경)은 사람이 승인합니다.
</details>

**2. 시험이 앞으로 당겨진 이유는?**

<details>
<summary>답</summary>

**사람이 완료를 판정하지 않기 때문**입니다. 자동으로 판정하려면 판정 기준이 시작
시점에 있어야 해서, IntentOps에서 명세와 함께 테스트를 먼저 정합니다.
</details>

**3. 프로세스 3에서 테스트가 계속 실패하면 무엇을 의심해야 합니까?**

<details>
<summary>답</summary>

몇 번 고쳐도 안 되면 코드가 아니라 **명세나 테스트가 틀린 것**입니다. 그래서
재시도 한계를 걸고 초과하면 사람을 부릅니다 — 그림의 프로세스 3 → 1 점선입니다.
</details>

---

이제 각 프로세스를 하나씩 봅니다 →
[프로세스 1 — 의도 포착](/guide/ha-phase1-intent)