# 01 · 원론·이론·논문·주요인물 — RED 전모 파악

"RED가 무엇인가"를 원론 정의 → 이론·실증 → 주요 인물 견해 → 2026 요약 순서로 정리한다.
(근거 출처는 `SOURCES.md`의 1~100번 참조. 괄호 안 숫자는 해당 항목 번호.)

---

## 1. RED의 원론 정의 (가장 좁고 정확한 정의)

**RED = "구현 전에, 한 가지 관찰 가능한 행위를 사양으로 명세한 자동화 테스트가, 그 행위의 부재로 인해 **예상된 이유로 실패**함을 증명하는 단계."**  
(종합 정의다 — "예상된 이유로 실패" 표현은 Beck 『TDD By Example』과 2026 VS Code 가이드의 "fail for the right reason"를 결합한 것. Fowler는 실패 관찰을 직접 명문화하지 않았다 — 레드팀 H-1 정정.)

핵심 요소 (3):
- **사양**: 테스트 = 실행 가능한 요구사항 (실행 가능 사양, executable specification)
- **방법**: 실패를 **직접 관찰·검증** (실수로 통과가 아님)
- **결과**: 인터페이스 설계 결정 (Beck 8, 14) 및 회귀 누적

Beck의 Canon TDD (5): 테스트 목록 나열 → 하나만 구체 테스트→실패 → 최소 구현으로 초록 → (선택) 리팩터 → 목록 빌 때까지.
*"공포가 지루함으로 바뀔 때까지."*

RED는 "테스트를 먼저 쓰는 일(order)" 이상이다 — **행위 분석(1단계 목록)+실패 증명(2단계)**이 함께 정의된다 (9, 10).

---

## 2. 이론·실증 (무엇이 효과를 만드는가)

**프로세스 메커니즘 (이론)**:
- RED: 요구를 구현 전 실행 가능 예제로 → 요구 명확화·테스트 가능성
- GREEN: 작은 행위 증분 → 인지 부하↓·피드백↑
- REFACTOR: 중복 제거 + 회귀 안전망 → 유지보수성↑
- 반복: 빈번한 검증 → 조기 결함 검출

**핵심 실증 결론 — "test-first 순서 자체의 효과는 제한적"** (32, 33, 36, 37):
- 짧고 규칙적인 피드백 주기 + 테스트 강도 + 회귀 누적이 대부분의 이점을 설명.
- 메타분석: 외부품질에 작은 긍정 효과, 생산성 효과 미미 (34).
- 6개월 종단: 최종 품질 차이는 없어도 **더 많고 더 나은(결함검출력) 테스트**를 생산·유지 (37).
- **결론**: RED가 유효한 이유는 '순서'가 아니라 '행위 명세 + 빠른 실패 + 단정 강도 + 회귀'.

**TDD 위협 요인**:
- 리팩터 생략 (35; Fowler 21)
- 테스트 품질(단정·경계) 저하 — 개수·커버리지가 아님
- 과제 복잡성·경험·환경 (36)

**ROI 기준**: 투자 모델(손익분기)이며 절대 상수가 아님 (39, 40). ERICSSON 총비용 5–6%↓ (42, 단 수치 확인 필요), Microsoft+IBM 4팀 결함 40–90%↓·시간 15–35%↑ (41 — 실제 Microsoft 3팀+IBM 1팀).

---

## 3. 주요 인물 견해 지도

| 인물 | 입장 | 한 줄 |
|---|---|---|
| **Kent Beck** (창시자) | Canon TDD 정의 제공, 독단 반대, 맥락 의존 | "정의는 정의일 뿐. 행위 하나씩 공포→지루함으로." |
| **Martin Fowler** | RGR 정의, 자기검증≠TDD, 리팩터 중시 | "테스트를 먼저 쓰고, 깨지면 수정한다"(실패관찰은 Beck·2026 가이드 의 것 — 직접 인용 아님) |
| **David Heinemeier Hansson** | 독단·목-헤비·설계 왜곡 반대 | "TDD는 죽었다, 테스팅 만세" (2014) |
| **James Shore** | 프로그래머 몫 테스트 옹호, 수용은 대화 | "수용을 이진 테스트로 환원하면 거짓 확신." |
| **Marco Arment** | 소규모 제품 관점, 테스트 비용 사례별 정당화 | "과잉 테스트 경계" (2012) |
| **Vivek Haldar** | 장기 회귀·모듈성 이점 강조 | Arment에 반박 |
| **John Ousterhout** | TDD가 설계에 역행한다는 비판 | "작은 설계 증분은 best design을 막는다" |
| **Beck ↔ Ousterhout 논쟁** | 설계는 '언제'의 문제, 균형이 best | "일찍 설계할수록 덜 informed, 늦게 하라" (15) |
| **Emily Bache × Nizar** (2026) | 에이전트는 TDD 위반 → 도구 강제 | "TDD Guard/Probity" (77–79) |
| **Martin Alderson** (2026) | 회의론자였다가 에이전트 경제로 전향 (단 test-first 순서는 명시 안 함) | "TDD 쪽이 맞았다, 로봇 주니어 덕분에"; 정작 '테스트를 먼저 쓰라고는 안 했다' (73–76) |
| **Drew Cain** (2026) | TDD→SDD 전환 | "테스트는 검증, 스펙은 의도" (80–84) |
| **Birgitta Boeckeler** (Thoughtworks) | SDD | "에이전트는 코드엔 강하고 장기 일관성엔 약하다"(Boeckeler 단독 발언, oleaedge 경유) |
| **Dave Farley** | ATDD | Bache 글에서 ATDD 관련 간접 언급 (SOURCES 근거 약함) |
| **Google(TotT 2026)** | TDD 옹호하되 비-은탄환 명시 | "The Way of TDD" — Bartosz Papis (72) |

**역사적 궤적**: 1994 SUnit·1995 OOPSLA 데모(Beck) → 2012 Arment 논쟁 → 2014 "Is TDD Dead"(DHH×Beck×Fowler) → 2017–2025 실증 다기화 → **2025–2026 SDD·에이전트 게이트 시대**.

---

## 4. 2026 (2026년 전반~9월) 합의 — 이전 관점과의 차이

| 차원 | 전통적 관점 | 2026 관점 |
|---|---|---|
| RED의 역할 | 프로그래머의 설계 훈련 | **행위 명세 + 독립 검증 + 완료 게이트** |
| 주체 | 인간 개발자 | 인간이 사양·리뷰, 에이전트가 구현·테스트 생성 |
| 순서의 강조 | test-first 강조 | **보호 수용 테스트 + 독립 검증 + 짧은 주기** (92, 87–88) |
| 테스트 생산 | 수작업 | 에이전트가 초 단위 생성 (73) — 품질·독립성만 필수 |
| 테스트 유지비 | 상시 유지 | JiT 즉시 테스트로 유지비 제거 시도 (Meta 71) |
| 도구 | IDE·프레임워크 | Spec Kit(SDD·립 계) · VS Code 3-에이전트 · Probity 가드레일 |
| 실증 | 순서 효과 논쟁 | **품질·독립성·실행 피드백 > 수량** (61–63, 86–87) |

---

## 5. 하나의 종합 정의 (이 프레임워크의 RED)

> **"의미 있는 RED" = 긴 시나리오(행위 사양)에서 하나를 뽑아, 관찰 가능한 결과를 강한 단정으로 명세하고,
> 구현 없는 상태에서 **예상된 이유로 실패함을 증명**하여 (a) 사양을 명확히 하고 (b) 인터페이스를 설계하며 (c) 이후 구현·회귀를 **게이트**하는 단계.
> — 에이전트 시대에는 이 '게이트'가 인간이 결정한 수용 기준으로서 **구현 에이전트 밖**에서 강제된다.**

상세 산출물: `02`(분류) / `03`(정리·통합) / `04`(긴 시나리오) / `05`(프레임워크).