# [[Exploratory Refactoring (탐색적 리팩토링)]]

## 📌 Brief Summary
탐색적 리팩토링(Exploratory Refactoring)은 복잡하거나 문서화되지 않은 레거시 코드를 수동적으로 읽기만 하는 대신, 적극적으로 코드를 변경하며 그 동작 방식을 파악하는 기법이다 [1]. 이 과정의 주된 목적은 코드를 영구적으로 정리하는 것이 아니라 시스템에 대한 친숙함과 통찰을 얻는 데 있다 [2]. 종종 '스크래치 리팩토링(Scratch Refactoring)'이라고도 불리며, 코드를 완전히 이해한 후에는 변경 사항을 되돌리고 적절한 테스트와 함께 실제 변경 작업을 다시 시작해야 하는 것이 특징이다 [2].

## 📖 Core Content

* **코드 이해를 위한 능동적 상호작용:** 코드가 어떻게 작동하는지 파악하기 위해 사용하는 방법으로, 코드를 수동적으로 읽기만 하는 것보다 능동적으로 코드를 수정하고 상호작용하는 것이 이해도를 높이는 데 훨씬 효과적이다 [1]. 
* **스크래치 리팩토링(Scratch Refactoring) 기법의 활용:** 마이클 페더스(Michael Feathers)가 제안한 스크래치 리팩토링과 궤를 같이하며, 테스트가 없고 불투명한 레거시 코드를 다룰 때 유용하다 [2]. 함수 추출, 코드 단순화, 변수 이름 변경 등 코드를 파악하기 위한 목적의 변경을 자유롭게 시도해볼 수 있다 [2]. 
* **이해를 위한 리팩토링(Comprehension Refactoring)과의 연관성:** 코드를 분석하면서 구조가 복잡하거나 변수명이 모호한 부분을 발견했을 때 이를 개선하여, 개발자 머릿속에 생긴 이해를 코드 자체에 반영(박제)하는 과정과 일맥상통한다 [3, 4]. 랄프 존슨(Ralph Johnson)은 이를 "창문의 먼지를 닦아내어 그 너머를 볼 수 있게 하는 것"에 비유했으며, 이를 통해 코드를 읽기만 해서는 놓칠 수 있었던 높은 수준의 이해에 도달할 수 있다 [3].
* **적용 시점:** 레거시 코드베이스의 작동 원리를 파악하지 못해 막혀 있을 때나, 짧은 시간을 투자해 코드베이스의 지뢰를 제거하듯 탐색적 접근을 시도할 때 큰 가치를 발휘한다 [2, 5].

## ⚖️ Trade-offs & Caveats

* **변경 사항의 폐기(Revert) 필수:** 탐색적 리팩토링(스크래치 리팩토링)은 주로 테스트가 없는 레거시 환경에서 코드를 파악하기 위해 수행되므로, 안전하지 않은 변경(Unsafe changes)이 포함될 수 있다 [2]. 따라서 파악이 끝난 후에는 반드시 모든 변경 사항을 되돌려야(Revert) 한다는 단 하나의 철칙이 존재한다 [2].
* **운영 코드 적용 불가:** 탐색적 목적으로 얻은 결과물 자체를 운영 코드에 그대로 유지해서는 안 된다 [1]. 자동화된 테스트라는 안전망이 없는 상태에서 리팩토링한 코드를 그대로 반영하려고 시도할 경우, 기존 동작을 훼손하거나 예기치 않은 버그를 도입할 위험이 매우 높기 때문이다 [2, 6].
* **생산성 저하의 착각:** 변경한 코드를 최종적으로 버려야 하므로 일견 시간 낭비처럼 보일 수 있으나, 이 과정을 통해 의존성과 코드의 구조를 완벽히 파악할 수 있다 [2]. 오히려 이후에 테스트를 작성하고 정식으로 안전하게 리팩토링하는 본 작업을 수행할 때 리스크를 극적으로 줄여준다 [2, 6].


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