# [[Red-Green Refactoring]]

## 📌 Brief Summary
Red-Green Refactoring은 애자일 소프트웨어 개발에서 가장 널리 사용되는 코드 리팩토링 기법으로, 테스트 주도 개발(TDD) 워크플로우에 깊이 뿌리를 두고 있습니다 [1, 2]. 실패하는 테스트를 먼저 작성하는 'Red' 단계, 최소한의 코드로 테스트를 통과시키는 'Green' 단계, 그리고 코드를 개선하는 'Refactor' 단계의 세 가지 반복적인 주기로 구성됩니다 [3-5]. 기능 추가와 구조 개선을 엄격히 분리하여, 기존 동작을 훼손하지 않으면서도 시스템의 유연성과 유지보수성을 지속적으로 높이는 데 목적이 있습니다 [3, 5].

## 📖 Core 소스
Red-Green Refactoring은 "테스트 우선(test-first)" 접근법을 따르며, 이는 모든 형태의 리팩토링의 기초를 형성합니다 [1]. 이 전략은 기능 구현과 리팩토링을 위한 세 가지 명확한 단계로 수행됩니다.

*   **RED (실패하는 테스트 작성):** 특정 소프트웨어 동작이나 기능을 검증하기 위한 실패하는 테스트(red-test)를 가장 먼저 작성합니다 [3, 5]. 아직 실제 코드가 작성되지 않았기 때문에 이 테스트는 의도적으로 실패하도록 설계됩니다 [5]. 이 단계를 통해 개발자는 무엇을 개발해야 할지 명확히 확인하게 됩니다 [3].
*   **GREEN (테스트 통과를 위한 최소한의 코드 구현):** 개발이 테스트를 통과(green)할 수 있도록 가장 단순하고 충분한 코드를 작성합니다 [3]. 이 단계의 핵심 목표는 코드의 품질보다는 속도에 있으므로, 테스트를 통과하기 위한 최소한의 코드만을 작성합니다 [5].
*   **REFACTOR (코드 개선 및 최적화):** 테스트가 통과하는 상태(green)를 유지하면서 코드를 개선하고 향상시키는 데 집중합니다 [3]. 소프트웨어의 동작은 그대로 보존하면서, 코드를 더 깨끗하고, 명확하며, 효율적으로 다듬어 최적화합니다 [4, 5].

이 기술은 본질적으로 새로운 기능을 시스템에 추가하는 첫 번째 파트(Red, Green)와 그 기능을 수행하는 코드를 개선하는 두 번째 파트(Refactor)로 나뉩니다 [3]. 가장 중요한 원칙은 워크플로우 중에 이 두 가지 작업(기능 추가와 리팩토링)을 동시에 수행해서는 안 된다는 것입니다 [3].

## ⚖️ Trade-offs & Caveats
*   **Green 단계에서의 품질 저하 감수:** Green 단계에서는 고품질의 완벽한 코드를 작성하는 것보다 빠른 시간 내에 테스트를 통과하는 '속도'를 우선시합니다 [5]. 이는 기능 구현을 빠르게 달성하는 대신 의도적으로 엉성한 코드를 임시로 남기게 되며, 후속 Refactor 단계를 거치지 않으면 기술 부채로 전락할 위험이 있습니다.
*   **기능 추가와 리팩토링의 동시 수행 금지:** 워크플로우를 진행할 때 새로운 기능 추가(코드 작성)와 리팩토링을 절대 동시에 진행해서는 안 됩니다 [3]. 이 엄격한 분리를 따르지 않으면 디버깅이 어려워지고, 테스트의 신뢰성이 떨어지는 부작용이 발생합니다 [3, 6].
*   **초기 테스트 작성의 한계:** 코드를 작성하기 전에 실패하는 테스트를 먼저 구현해야 하므로(Red 단계), 테스트를 작성하는 데 추가적인 시간적 제약과 노력이 요구됩니다 [3, 5]. 테스트 인프라가 부족한 상황에서는 리팩토링에 앞서 테스트부터 구축해야 하므로 적용이 어려울 수 있습니다 [7].

## 🔗 Knowledge Connections

### Related Concepts

#### [방법론/개발 프로세스]
- [[TDD (Test-Driven Development)]]
  - 연결 이유: Red-Green Refactoring은 테스트 주도 개발(TDD) 워크플로우에 내재되어 있으며, TDD 사이클 그 자체를 의미하기 때문입니다 [2, 5, 8].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 테스트 작성이 어떻게 소프트웨어 구현 및 리팩토링을 주도하고 안정성을 부여하는지 시스템 개발 관점에서 이해할 수 있습니다 [5, 8].
- [[Agile Methodology]]
  - 연결 이유: Red-Green 기법은 애자일 소프트웨어 개발 프로세스에서 가장 인기 있고 널리 사용되는 기술이기 때문입니다 [1, 2].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 짧은 주기의 반복적(iterative)인 전략이 어떻게 지속적인 리팩토링을 가능하게 하고 변화에 민첩하게 대응하게 하는지 학습할 수 있습니다 [5].

#### [리팩토링 원칙/규율]
- [[Two Hats (두 개의 모자)]]
  - 연결 이유: 기능 추가의 단계(Red, Green)와 리팩토링 단계(Refactor)를 섞어서 진행하면 안 된다는 Red-Green Refactoring의 기본 규정은 마틴 파울러의 '두 개의 모자' 원칙을 완벽히 실천하는 형태이기 때문입니다 [3, 6].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 리팩토링 과정 중 기존 코드의 구조 개선과 새로운 기능 추가를 심리적, 절차적으로 철저히 분리하여 디버깅 효율을 높이는 원리를 파악할 수 있습니다 [6].

### Deeper Research Questions

- Red-Green Refactoring의 'Green' 단계에서 속도를 우선하여 작성된 최소한의 코드가, 후속 'Refactor' 단계의 설계 결정에 어떠한 인지적 편향을 일으킬 수 있는가?
- TDD 기반의 Red-Green 주기를 도입할 때, 테스트 커버리지가 거의 없는 방대한 레거시 시스템(Legacy System)에서 이 기법을 점진적으로 적용하기 위한 효과적인 시퀀스는 무엇인가?
- Red-Green-Refactor 단계를 매우 짧은 간격(마이크로 커밋)으로 반복할 경우, 소프트웨어 아키텍처의 지속 가능성과 모듈성에 미치는 정량적 변화는 어떠한가?
- 테스트 코드가 외부 API나 데이터베이스와 강하게 결합된 환경에서 Red-Green Refactoring을 안전하게 수행하기 위해 테스트 더블(Mock, Stub)은 어느 단계에 어떻게 설계되어야 하는가?
- 'Refactor' 단계에서 리팩토링을 멈추고 다시 'Red' 단계로 돌아가야 하는 시점(Stopping Condition)을 판단하는 경험적, 객관적 기준은 무엇인가?

### Practical Application Contexts

- **Implementation:** 새로운 기능 구현 시, 해당 요구사항을 명세하는 실패하는 테스트를 가장 먼저 코드로 작성하고, 테스트가 통과될 때까지 가장 무식하지만 빠른 코드를 구현한 뒤, 최종적으로 중복 코드를 제거하고 구조를 우아하게 다듬어 완료합니다 [3, 5].
- **System Design:** 소프트웨어 설계에 앞서 테스트 가능한 구조를 강제함으로써, 결합도가 낮고 응집도가 높은 아키텍처가 점진적이고 반복적으로 도출될 수 있도록 팀의 설계 워크플로우를 구성합니다 [2, 5].
- **Operation / Maintenance:** 운영 중 발견된 버그를 수정할 때, 버그를 재현하는 실패하는 테스트(Red)를 먼저 만들어 버그를 고치고(Green), 주변의 코드 스멜을 개선(Refactor)하여 추후 동일한 버그가 발생하지 않도록 유지보수 체계를 강화합니다 [9].
- **Learning Path:** 주니어 개발자가 객체지향 설계와 클린 코드를 학습할 때, 단순히 예쁘게 코딩하는 것을 넘어 TDD 환경에서 동작 보존과 구조 개선을 단계적으로 달성하는 실전 훈련 파이프라인으로 활용됩니다 [5, 10].
- **My Project Relevance:** 현재 진행 중인 프로젝트에 Red-Green-Refactor 사이클을 적용하여, 기능 추가와 리팩토링 작업을 동시에 수행하다 발생하는 예기치 못한 사이드 이펙트를 차단하고, 항상 테스트로 보호받는 안정적인 코드베이스를 확보합니다 [3, 5].

### Adjacent Topics

- [[Technical Debt (기술 부채)]]
  - 확장 방향: 정기적인 Refactor 단계를 무시하고 Red-Green만 반복하거나 편법을 사용했을 때 쌓이는 기술 부채가 장기적인 프로젝트 비용에 미치는 영향과 관리 전략을 확장하여 학습합니다 [11-13].
- [[Automated Testing (자동화된 테스트)]]
  - 확장 방향: Red-Green 리팩토링의 성공을 좌우하는 테스트 피라미드, 단위 테스트(Unit Test) 작성법 및 레거시 코드에 테스트 하네스를 구축하는 방법론으로 이해를 확장합니다 [4, 14, 15].

---
*Last updated: 2026-05-03*