c3ddd36c6f
Some checks failed
deploy-site / deploy (push) Failing after 40s
Release notes for 1.1.0 were split between an Unreleased section and the version section, so the published notes would have omitted the update-feed and desktop changes. Everything shipping in this version now sits under one `## [1.1.0]` heading. `docs/map/` becomes the entry point for what infrastructure exists per platform and how far each feature is developed, with a documented update protocol so feature work and this map do not drift apart again. The release guide now states that installer binaries live in the update feed rather than the repository.
91 lines
6.4 KiB
Markdown
91 lines
6.4 KiB
Markdown
# 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`(프레임워크).
|