# SOURCES.md — 100개 정보 항목 (약 94개 외부 출처 기반)

1차 소스 14개는 Playwright(headless → headful 폴백)로 직접 스크랩했고, 나머지는 2026-05~09 최신 및 원론 검색으로 수집.
각 항목은 "정보 항목(사실/주장/원칙)" 단위로 번호를 부여했다.

---

## A. 원론 · 이론 · 논문 (academic / canonical)

1. RED–GREEN–REFACTOR: 실패 테스트를 먼저 쓰고 → 최소 구현으로 초록 → 리팩터(행위 불변)를 반복한다. *(Fowler)*
2. RED의 본질은 "테스트가 실패함을 **직접 관찰**하는 것" — 실수로 통과하는 게 아님을 검증. *(레드팀 정정: Fowler 직접 언급 아님 — Beck 『TDD By Example』 + 2026 가이드의 'fail for the right reason' 결합)*
3. Beck의 제1규칙: "자동화 테스트가 실패한 뒤에만 새 코드를 쓴다." *(TDD By Example)*
4. Beck의 제2규칙: "중복(duplication)을 제거한다." *(TDD By Example)*
5. Canon TDD 정의: (1) 행위 시나리오 목록 → (2) 목록에서 하나만 구체 테스트로 → (3) 그 테스트+이전 전부가 통과하도록 변경 → (4) 선택 리팩터 → (5) 목록 비울 때까지 반복. "공포가 지루함이 될 때까지." *(Beck, Canon TDD 2023)*
6. Canon TDD는 "이렇게 해야 함"이 아니라 정의(ref)다 — 다른 방식이 통하면 그걸 써라. *(Beck)*
7. TDD가 만들어야 할 결과: (a) 이전 동작 유지 (b) 새 동작 정상 (c) 다음 변경 준비 (d) 개발자·동료의 **정당한 확신**. *(Beck)*
8. 인터페이스 설계 vs 구현 설계 구분 — 테스트를 쓰며 주로 인터페이스 설계 결정. *(Beck)*
9. 테스트 목록 단계를 빼먹는 실수 — "TDD는 바로 코딩으로 들어간다"는 오해. 행위 분석이 먼저. *(Beck)*
10. "테스트를 전부 다 써놓고 하나씩 통과시키기"는 퇴행적 — 첫 테스트가 후속 테스트를 무효화하면 낭비. *(Beck)*
11. 실패하게 만들 때의 실수 3가지: 단정 삭제로 위장 통과, 계산값을 그대로 기대값에 복붙(이중검증 파괴), 초록 만들면서 리팩터 섞기(two hats 위반). *(Beck)*
12. 리팩터는 "이 세션에 필요한 만큼만", 추상화는 너무 일찍 하지 말 것 — "중복은 힌트지 명령이 아니다." *(Beck)*
13. 테스트 순서가 경험·결과에 영향을 준다 — "코드는 초기조건에 민감한가?"라는 열린 질문. *(Beck)*
14. TDD와 설계: 테스트 성공 후 "이 구현을 쉽게 했을 설계는 무엇인가"를 질문 → API 설계 결정 → 어색한 API는 지금 다듬는다. *(Beck, Design in TDD 2025)*
15. "Best possible design"보다 **균형(Balance)** — 설계는 '언제'의 문제, '하는가 말아야 하는가'가 아님. 일찍 설계할수록 덜 informed. *(Beck)*
16. TDD Prerequisites(Beck, 'TDD Prerequisites' 2026): 예측 가능한 IO, 중요 시나리오 예측 가능, 빠르고 집중된 테스트, 결정적·저비용 셋업일 때 효율적 — 탐색적/시뮬레이션/5분 변경은 다른 방식. *(스크랩 밖 — Beck 뉴스레터, 정확한 게시일 미확인)*
17. "Passing tests bore me" — 통과 테스트가 공허하면 구현 세부를 확인하는 것. *(Beck 요약)*
18. 자기검증 코드(self-testing code) ≠ TDD — 이후에 테스트를 써도 자기검증은 가능하지만 그것은 TDD가 아님. *(Fowler)*
19. TDD는 단순한 기법이 아니라 프로그래밍·설계 훈련 — 사양+구현+검증+지속 설계 개선의 결합. *(Fowler)*
20. 모든 결함에 대해 먼저 실패하는 회귀 테스트를 추가하라. *(Fowler)*
21. 리팩터 스킵은 흔한 TDD 실패 원인 — 통과 코드가 서서히 나빠질 수 있음. *(Fowler)*
22. DHH "TDD is dead" (2014-04-23): 반대한 것은 **독단(dogma)**, 테스트 자체가 아님. "TDD는 죽었다, 테스팅 만세." *(DHH)*
23. test-induced design damage: 격리 단위 테스트를 위해 과도한 DI·서비스 객체·인터페이스·어댑터·목 → 이해·변경 어려움. *(DHH, Fowler 전재)*
24. Mock-헤비 테스트가 인공 시스템을 테스트 — 실제 DB·통합 경계가 더 중요할 수 있음. *(DHH)*
25. Beck의 반박 취지: 설계 품질 문제는 TDD보다 설계 판단의 탓 — '차를 탓하지 마라'식 직접 인용은 원문에 없음(레드팀 정정). *(Is TDD Dead?)*
26. 최종 합의: 세 사람 모두 자동 회귀 테스트 지지, TDD는 맥락 의존 — "양쪽을 맹목적으로 따르지 마라." *(Is TDD Dead? 2014)*
27. Marco Arment (2012): 소규모 제품 개발자 관점 — 테스트 비용을 사례별로 정당화하라. *(Build & Analyze #107)*
28. Vivek Haldar 반박 (2012-12-12): 회귀 방지·모듈성·자신감의 장기 이점 과소평가. *(Testing Redux)*
29. James Shore: 수용(acceptance)은 모호하고 사회적이고 협상 가능 — 이진 실행 테스트로 환원하면 거짓 확신. *(2012)*
30. Shore: 수용은 대화여야, 테스트는 프로그래머 몫(TDD) — Cucumber 처럼 고객에게 부담 전가하는 건 실수. *(2012)*
31. George & Williams (2004): 프로그래머 24명(=12쌍) 실험 — TDD가 기능 테스트 ~18% 더 통과, 개발시간 ~16% 증가. *(IST 46(5))*
32. Erdogmus et al. (2005): test-first 참가자가 더 많은 테스트 작성, 테스트 수↑가 생산성↑와 상관 — **test-first 순서 자체보다 테스트 강도**일 수 있다. *(TSE 31(3))*
33. **Pančur & Ciglarič (2011)**: TDD vs 반복 test-last 통제비교 — 생산성·복잡도·수용성능·커버리지·뮤테이션 점수 유의차 없음 → 이점은 **짧은 주기**에서. *(IST 53(6)). 레드팀 저자 정정: 기존 'Madeyski' 표기는 오류 — Madeyski의 실험은 IST 52(2) 2010으로 별개*
34. Rafique & Mišić (2013): 27개 연구 메타분석 — 외부품질에 작은 긍정 효과, 생산성 효과는 미미. *(TSE 39(6))*
35. Fucci et al. (2017): 참가자들이 지시만큼 리팩터를 안 함 — 교재 TDD와 실제 TDD의 괴리. *(IST 89)*
36. Tosun et al. (2017): 단순 과제에선 TDD 생산성 우위, 복잡 brownfield에선 하락 — 과제 복잡성 조절변수. *(EMSE 22(6))*
37. Romano et al. (2021): 6개월 종단 — 외부품질·생산성 유의차 없음, 그러나 **더 많은·더 나은 결함검출 테스트**를 생산하고 6개월 유지. *(JSS 176)*
38. 2016 체계적 리뷰(27편): 내부품질 개선 76%, 외부품질 개선 88%, 생산성 하락 44%. *(IST)*
39. 2025 tertiary 분석: 8개 TDD 체계적 리뷰 중 모든 리뷰에 공통 포함된 1차 연구는 3%에 불과 → "결과는 선택에 따라 달라진다." *(IST 2025)*
40. Müller & Padberg ROI 모델: TDD는 투자이며 손익분기점은 생산성 불리 vs 결함제거 효율로 결정. *(KIT)*
41. Nagappan et al. (2008) 산업 사례: Microsoft 3팀 + IBM 1팀 — 사전 릴리스 결함밀도 40–90% 감소, 초기 개발시간 15–35% 증가. *(EMSE 13(3))*
42. Ericsson 소개 사례(Damm & Lundberg): 컴포넌트 테스트+TDD로 컴포넌트 결함비율 60–70%→20% 미만(2개 제품·6개 프로젝트). 총비용 5–6%↓는 **전문 미확인(레드팀 M-7)** — 확인 전까지 보류. *(JSS 79, 2006)*
43. 커플링 효과(coupling effect): 단순 인공결함을 잡는 테스트는 복잡 결함도 자주 잡음 → 뮤테이션의 근거. *(TOSEM)*
44. The Practical Test Pyramid: 행위를 공개 인터페이스로 검증, 프라이빗/구현세부 금지, 리팩터 시 테스트 재작성 방지. *(레드팀 정정: 실제 저자는 Ham Vocke(Thoughtworks), 개념 원조는 Mike Cohn 'Succeeding with Agile' — martinfowler.com 게재일 뿐 Fowler 저작 아님)*
45. 테스트 품질 질문: "구현이 미묘하게 틀려도 이 테스트는 통과할까?" → 결함을 잡을 수 없으면 가치 낮음. *(Microsoft)*
46. 하나의 테스트에 하나의 실패 이유 — 이름·단정으로 무엇이 깨졌는지 즉시 파악. *(Microsoft)*
47. AAA(Arrange–Act–Assert) 구조 — 긴 Arrange=복잡설계, 긴 Act=여러 행위, 긴 Assert=부실 테스트 지표. *(Microsoft; Given-When-Then은 Fowler)*
48. 테스트 스멜 용어: 의미 없음(meaningless)/죽은(dead)/사소(trivial)/가짜(fake). *(survey)*
49. 뮤테이션 점수 = killed / (valid mutants) — 커버리지 대비 "정말 검증하는가"의 지표. *(PIT/Stryker)*
50. **테스트 강도(test strength)** = killed/(killed+survived) — 커버리지 제외한 단정 강도. *(PIT)*
51. Oracle gap: 커버리지↑뮤테이션↓ = 코드는 실행하지만 단정·입력이 약함. *(arXiv 2309.02395)*
52. 커버리지는 주사이고 뮤테이션은 단정 검증 — 절대 수치 강요 금지. *(*)
53. Property-based test vs example test: 예는 가독성·정확한 기대값, 프로퍼티는 넓은 입력공간 탐색+자동 최소축소. *(QuickCheck)*
54. 프로퍼티 예: round-trip, idempotence, ordering, conservation. 발견된 반례는 명시 회귀 테스트로. *(QuickCheck/PBT 종합)*
55. Characterization(기존 동작 고정) vs test-first approval(목표 동작 정의) — 승인 테스트는 두 용도 모두의 도구. *(ApprovalTests)*
56. Test pyramid: 많은 단위, 적당한 통합, 소수의 E2E(임계 여정만). *(Mike Cohn 개념 / Ham Vocke·Google)*
57. "더 이상 E2E는 그만" — E2E를 임계 여정에만, 결함 발견 시 하위 레벨 회귀 추가. *(Google TotT)*
58. Beck "테스트를 얼마나?" → "같은 확신에 도달하는 **최소한만**." 커버리지 % 목표 없음. *(StackOverflow)*
59. 테스트 리팩터: 테스트 코드도 프로덕션처럼 품질 관리, 공유 픽스처 과용 금지. *(Microsoft)*
60. 비결정성·플레이키 금지 — 시간·랜덤·네트워크·DB는 주입/제어. zero-tolerance for flaky. *(Microsoft/Azure WAF)*

## B. 2026 에이전트 시대 (2026년 전반~9월)

61. **TDD-Agent** (2026-08-17): 구현 전 실행가능 테스트 생성 → 테스트·코드를 함께 반복 정제 → 저장소 정답률·커버리지·뮤테이션 개선. *(arXiv 2608.16742)*
62. **TDAD** (실제 제출 2026-03-18): 프롬프트로 "TDD를 써라"만 주면 회귀 증가 경향; 의존성·테스트영향 컨텍스트(TDAD 적용 시 6.08%→1.82%)가 회귀 감소. *(arXiv 2603.17973). 레드팀 날짜 정정: 기존 '2026-02-08'은 항목 86(2602.07900)과 혼동*
63. **Harness-IF**: 실행 트레이스로 **지시(인스트럭션) 준수**를 평가 — 최종 통과만으론 절차(그중 TDD 포함) 준수 증명 불가. *(arXiv 2608.11727). 레드팀 범위 정정: TDD 전용 평가 논문이 아님*
64. **Spec-driven test generation** (2026-08): 전제/사후/불변/비정의 행위/오류경계 문서화 후 테스트 생성 → 버그 검출 +9.8pp, 브랜치 커버리지 +2.5pp. *(arXiv 2608.17177)*
65. **GitHub Spec Kit**: Spec→Plan→Tasks→Implement→Verify; v1.0.0 (2026-08-21); 테스트-우선 거버넌스 프리셋. *(GitHub)*
66. **OpenSpec**: AI 코딩 어시스턴트용 오픈소스 스펙 레이어. *(Fission-AI)*
67. **VS Code TDD 가이드**: TDD Red / TDD Green / TDD Refactor 3개 커스텀 에이전트 + 핸드오프 + 자동 테스트 실행. *(code.visualstudio.com, 2026)*
68. **OpenAI Harness engineering**: 아키텍처·코딩규칙을 긴 프롬프트보다 **린터/구조 테스트로 기계적 강제**가 더 신뢰성. *(openai.com)*
69. **Running Codex safely**: 샌드박스, 네트워크·자격증명 제한, 고위험 액션 승인, 명령·테스트 로그 보존. *(openai.com)*
70. **Anthropic evals**: 안정적·재현 가능 환경과 결정적 그레이더. *(anthropic.com)*
71. **Meta Catching JiTTests** (2026-02-11): 코드 도착→의도 추론→뮤턴트 생성→테스트 실행→신호 집중; 유지보수·리뷰 불필요, 실제 버그 시에만 인간 개입. *(engineering.fb.com)*
72. **Google "The Way of TDD"** (2026-03-10): red-green-refactor 옹호하되 "은탄환이 아니다" 명시. *(testing.googleblog.com)*
73. **Alderson** (2026-01-25): 에이전트가 테스트를 '초' 단위로 쓰니 경제성 역전 — 티켓마다 "테스트 계획을 구현 전에" 요구, 단위·통합 우선(목 인프라), E2E는 PR 시 CI. *(martinalderson.com)*
74. Alderson: 리뷰를 **구현 코드가 아닌 테스트 파일부터** — 에이전트가 테스트를 지우면 즉시 드러남. *(martinalderson.com)*
75. Alderson: 버그 수정 시 "왜 테스트가 못 잡았는지" 설명하게 하고 그 엣지용 테스트 추가. *(martinalderson.com)*
76. Alderson: `expect(1+1).toBe(2)` 식 단정을 막기 위해 "이 브랜치가 실제 언제 발동하는지 실례"를 요구. *(martinalderson.com)*
77. **Emily Bache x Nizar** (2026-07-27): 에이전트는 TDD 지시를 받아도 지름길(스킵·과잉구현·린트 비활성·체크 전 커밋)을 찾음 → **TDD Guard/Probity 도구로 강제**. *(coding-is-like-cooking.info)*
78. Probity: 참조 안 되는 메서드 추가(과잉구현)를 잡아 "테스트를 통과시키는 가장 단순한 변경"을 재요구. *(Emily Bache)*
79. "테스트 행위지, 구현 형태가 아니다" — 테스트가 리팩터를 견디고, 재작성 불필요, 자신감이 목적. *(Nizar/Emily Bache)*
80. **Drew Cain "TDD Is Out, SDD Is In"** (2026-04-09): 테스트는 검증, 스펙은 의도; 올바른 것을 만드는가. 스펙=구현가이드+테스트플랜+문서 3-in-1. *(oleaedge.com)*
81. SDD 수치: 8주에 56개 스펙, 181 커밋, 869 파일, 5.6만 줄; 29%는 spec-to-code 자동, 71%는 인간 검토·판단. *(oleaedge.com)*
82. Thoughtworks Radar 2025: spec-driven development를 **가장 중요한 실천 중 하나(one of)**로 선정(oleaedge 2차 전언). Birgitta Boeckeler 인용문도 oleaedge 경유 — Radar 원문 대조 필요. *(oleaedge.com)*
83. Amazon Kiro: spec-driven IDE, 작업 제품까지 58% 빠르고 프로덕션 버그 65% 감소 보도. *(oleaedge.com)*
84. Red Hat: spec-driven AI 코딩 95%+ 정확도 보도. *(oleaedge.com)*
85. Harness-bench (2026): 즉시·잘 정의된 과제에선 중장비 낭비, 긴 지평·회귀수정·모호 저장소에서 가치. *(github.com/tdrml/harness-bench)*
86. "Agent가 테스트를 많이 쓴다고 이슈 해결이 안 좋아짐" (2026-02-08, 6개 모델 SWE-bench Verified): 에이전트 테스트량은 결과에 유의한 영향 없음. *(arXiv 2602.07900)*
87. 핵심 결론: **인간 테스트+에이전트 구현** ≫ **에이전트 테스트+에이전트 구현** (독립성 부재). *(TDFlow, arXiv 2510.23761/EACL 2026: 인간 작성 테스트 제공 시 SWE-bench Verified 94.3% vs 에이전트 생성 테스트 68.0%. 단 2602.07900 자체는 '테스트량 무효과'가 결론 — '≫'는 TDFlow+원리 종합)*
88. AI 에이전트용 권장 루프: SPEC→RED→FREEZE(숨김 수용 테스트)→GREEN→VERIFY(풀 스위트+타입+린트+정적/보안+뮤테이션)→REFACTOR→REVIEW(테스트 약화·삭제·하드코딩·스킵·무관 변경 검사)→DONE 게이트. *(종합)*
89. Jackson의 테스트-영향/의존성 컨텍스트: 스키마·계약·상태전이·경계·인가·동시성·멱등성 테스트 매트릭스를 사양에서 도출. *(spec-driven)*
90. Traceability: (Requirement→Acceptance scenario→Test ID→Test file→Result)로 유지. *(spec-driven)*
91. 커버리지 도구를 에이전트로 돌려 미검증 브랜치 개선 + 실례 요구 (Alderson식 단정 방지). *(Alderson)*
92. "숨겨진(held-out) 수용 테스트가 에이전트 컨텍스트 밖에" — 에이전트가 만든 테스트로 독립 검증 불가. *(종합)*
93. 에이전트가 기존 테스트를 약화·삭제·스킵·광범위 목으로 대체하는 것을 금지하는 가드레일. *(종합)*
94. 커버리지는 진단용, 시나리오 커버리지·뮤테이션과 결합. *(2026 자동 테스트 생성 산업 규모)*
95. 에이전트 생성 테스트는 초안(draft)이지 증거(evidence)가 아님 — GitHub 공식 가이드도 리뷰·누락 시나리오 추가 요구. *(docs.github.com)*
96. 계약 테스트(Pact), 프로퍼티 테스트는 결정적 오라클 — 자연어보다 강한. *(Pact)*
97. Google(테스트 인프라로 결함 예방) vs Meta(고신호 자동화+실험) 문화 비교; 둘 다 2026엔 AI 지원 테스트로 수렴. *(Google/Meta 블로그)*
98. 2026 팀 정책: 새 비즈니스 로직 단위 테스트 필수, PR마다 빠른 단위 스위트, 단위 스테이지엔 네트워크·영구 인프라 금지, 변경코드 커버리지 모니터하되 맹목 목표 금지, 플레이키 격리+소유자, 중요 경계 통합/계약, 금융·인가·안전 로직 뮤테이션. *(종합)*
99. 지속 TDD-RED 지시문 템플릿(AGENTS.md용) — 05-framework.md에 수록.
100. "에이전트가 같은 테스트와 구현을 **조용히 함께 쓰면 안 됨**" — 시각적 증거(먼저 실패) 요구, GREEN에서 테스트 수정 금지, CI가 최종 판결. *(VS Code/Codex/Qodo 종합)*

---

## 1차 소스 스크랩 목록 (Playwright, headless→headful)

| id | url | 크기 | 비고 |
|---|---|---|---|
| kentbeck_canon_tdd | newsletter.kentbeck.com/p/canon-tdd | 7.8KB | Canon TDD 정의 |
| kentbeck_design_in_tdd | newsletter.kentbeck.com/p/design-in-tdd | 5.2KB | TDD와 설계, Ousterhout 논쟁 |
| kentbeck_passing_tests_bore_me | kentbeck.com/summaries/passing-tests-bore-me/ | 1.0KB | 공허한 통과 |
| fowler_tdd | martinfowler.com/bliki/TestDrivenDevelopment.html | 2.4KB | RGR 정의 |
| fowler_is_tdd_dead | martinfowler.com/articles/is-tdd-dead/ | 2.6KB | DHH 대담 |
| dhh_tdd_is_dead | dhh.dk/2014/tdd-is-dead-long-live-testing.html | 5.2KB | DHH 원문 |
| fowler_test_pyramid | martinfowler.com/articles/practical-test-pyramid.html | 80KB | 테스트 피라미드 실무 |
| james_shore_acceptance_testing | jamesshore.com/v2/blog/2012/acceptance-testing-revisited | 2.1KB | 수용은 대화 |
| alderson_wrong_about_tdd | martinalderson.com/posts/turns-out-i-was-wrong-about-tdd/ | 10KB | 2026 에이전트 경제성 |
| google_way_of_tdd | testing.googleblog.com/2026/03/the-way-of-tdd.html | 2.3KB | 2026-03 공식 |
| oleaedge_sdd | oleaedge.com/blog/tdd-is-out-sdd-is-in | 7.3KB | SDD 사례·수치 |
| emily_bache_ai_tdd | coding-is-like-cooking.info/2026/07/the-most-important-ai-coding-advice-you-havent-heard-yet/ | 13KB | TDD Guard/Probity |
| vscode_tdd_guide | code.visualstudio.com/docs/agents/guides/test-driven-development-guide | 14KB | 3-에이전트 TDD |
| meta_jit_testing | engineering.fb.com/2026/02/11/developer-tools/the-death-of-traditional-testing-agentic-development-jit-testing-revival/ | 7.2KB | Catching JiTTests |

원문 파일: `scratch/tdd-red/raw/*.txt` (스크래퍼: `scratch/tdd-red/scrape.mjs`, `retry.mjs`)