리팩터링 활동 실증 연구

초록

세 개의 Java 오픈소스 프로젝트를 대상으로 리팩터링 빈도, 유형, 개발자 책임, 테스트 검증 정도 등을 분석한 실증 연구로, 릴리즈 전후 리팩터링 차이가 프로젝트마다 다르고, 테스트와 프로덕션 코드에서 다른 리팩터링 패턴이 나타나며, 플로스 리팩터링이 가장 흔하고, 리팩터링 후 테스트가 충분히 이루어지지 않는다는 결론을 제시한다.

상세 분석

본 연구는 세 개의 대규모 Java 오픈소스 프로젝트를 대상으로 리팩터링 활동을 정량·정성적으로 분석하였다. 연구자는 기존 연구에서 제시된 ‘주요 릴리즈 전후의 리팩터링 빈도 차이’, ‘테스트 코드와 프로덕션 코드 간 리팩터링 유형 차이’, ‘특정 개발자에 의한 리팩터링 집중도’, ‘리팩터링 후 테스트 커버리지’ 등 네 가지 가설을 검증하기 위해, 각 프로젝트의 Git 커밋 로그와 RefactoringMiner 도구를 활용해 리팩터링 메서드 호출, 추출, 인라인, 메서드 이동 등 12가지 리팩터링 유형을 자동 추출하였다. 이후 추출된 리팩터링 사건을 릴리즈 일정과 매핑하고, 코드 베이스 내 악취(코드 스멜) 발생 및 지속 여부를 추적하였다. 분석 결과, 주요 릴리즈 전후에 리팩터링 빈도가 반드시 높아지는 것이 아니라 프로젝트마다 차이가 존재함을 확인하였다. 특히 한 프로젝트에서는 릴리즈 직후 급격한 리팩터링 증가가 관찰되었으며, 다른 두 프로젝트에서는 릴리즈 전후 차이가 통계적으로 유의미하지 않았다. 테스트 코드와 프로덕션 코드 간 리팩터링 유형 차이는 일관되게 나타났으며, 테스트 코드에서는 메서드 추출과 리네임이, 프로덕션 코드에서는 메서드 이동과 인라인이 주로 수행되었다. 또한, 리팩터링을 수행한 개발자는 전체 리팩터링 중 약 30%를 차지했으며, 이들 개발자는 프로젝트 내에서 높은 커밋 빈도와 코드 소유권을 보이는 것으로 드러났다. 흥미롭게도, 리팩터링 후에 추가된 테스트 케이스는 전체 리팩터링 중 12%에 불과했으며, 이는 리팩터링이 충분히 검증되지 않은 채 적용될 위험성을 시사한다. 플로스(Floss) 리팩터링, 즉 기능 구현과 동시에 수행되는 리팩터링이 전체 리팩터링의 55%를 차지해 가장 흔한 형태임을 확인하였다. 마지막으로, 악취가 한 번 발생하면 대부분의 경우 이후 버전에서도 지속되는 경향이 강했으며, 이는 리팩터링이 기존 악취를 제거하기보다 새로운 악취를 생성하거나 기존 악취를 그대로 유지하는 경우가 많음을 의미한다. 이러한 결과는 기존 연구의 일반화 가능성을 부분적으로 뒷받침하면서도, 프로젝트 특성에 따른 리팩터링 전략의 차별화 필요성을 강조한다.