레거시 자바스크립트 클래스를 ES6 클래스로 리팩터링: 좋은 점, 나쁜 점, 그리고 못된 점

초록

본 논문은 ES5 기반으로 구현된 레거시 자바스크립트 코드에서 클래스‑유사 구조를 ES6 네이티브 클래스 문법으로 자동·수동 마이그레이션하는 과정을 제시한다. 8개의 실제 프로젝트에 적용한 결과, 규칙에 따라 바로 변환 가능한 “좋은 부분”이 전체 코드의 16‑77%를 차지했으며, 함수 호이스팅·this 사용 제한 등으로 수동 조정이 필요한 “나쁜 부분”과 ES6가 지원하지 않는 정적 필드·특수 프로토타입 조작 등으로 변환이 불가능한 “못된 부분”이 각각 존재함을 확인했다. 개발자 설문을 통해 마이그레이션에 대한 인식도 조사하였다.

상세 분석

이 연구는 자바스크립트가 프로토타입 기반 언어임에도 불구하고 ES6에서 도입된 클래스 문법이 실제 현업 코드에 얼마나 적용 가능한지를 실증적으로 검증한다. 먼저, 기존 ES5 코드에서 함수와 프로토타입을 이용해 구현된 클래스‑유사 구조를 자동 변환하기 위한 세 가지 규칙을 정의하였다. Rule #1은 생성자 함수와 프로토타입 메서드를 ES6 class와 constructor 형태로 매핑하고, Rule #2는 프로토타입 체인을 extends 구문으로 바꾸며, Rule #3은 super 호출을 삽입해 상속 관계를 유지한다. 이러한 규칙은 코드 패턴이 명확히 구분될 때(예: 메서드가 생성자 내부, 프로토타입에 할당, 혹은 정적 함수 형태) 자동 적용이 가능하도록 설계되었다.

데이터셋은 이전 연구에서 클래스‑유사 구조가 존재한다고 확인된 50개 프로젝트 중 8개를 선정했으며, 각 프로젝트는 1 KLOC에서 24 KLOC까지 규모가 다양하고, 클래스 밀도(class density)도 0.16‑0.95 범위에 걸친다. JSClassFinder 도구를 이용해 클래스‑유사 구조를 식별하고, 정의된 규칙을 순차 적용해 자동 변환을 수행한 뒤, GitHub 커밋 로그를 통해 churn(추가·변경·삭제된 LOC)와 파일 변동을 정량화하였다. 결과적으로, 전체 코드 중 평균 0.46 (최소 0.16, 최대 0.77)의 비율이 자동 변환(“좋은 부분”)에 해당했으며, churn 대비 삭제 비율이 0.15‑0.75 사이로 변환에 따른 코드 부피 변화가 거의 없음을 보여준다.

그러나 자동 변환이 불가능한 “나쁜 부분”도 존재했다. 주요 사례는 ES5 함수 호이스팅 특성으로 인해 super 호출 이전에 this를 참조하는 패턴, 동적 프로토타입 수정, 클로저 내부에서 this를 전달하는 경우 등이다. 이러한 경우는 개발자가 직접 setter 메서드를 도입하거나, super 호출 순서를 재조정하는 등 수동 리팩터링이 필요했다.

또한 ES6 클래스 문법이 지원하지 않는 “못된 부분”도 발견되었다. 예를 들어, 정적 필드·메서드가 프로토타입에 직접 할당되는 패턴, Object.defineProperty 로 구현된 게터·세터, 그리고 다중 상속을 흉내내는 mixin 방식은 ES6 문법으로는 정확히 표현할 수 없었다. 이러한 경우는 레거시 프로토타입 코드를 그대로 유지하거나, 별도 유틸리티 모듈로 추출하는 방식을 택해야 했다.

개발자 설문 결과, 마이그레이션에 대한 긍정적인 인식(가독성·유지보수성 향상)과 부정적인 인식(런타임 호환성·테스트 비용 증가)이 혼재했으며, 특히 “못된 부분”에 해당하는 코드는 변환을 포기하거나 부분적으로만 적용하려는 경향이 나타났다. 연구는 자동화 도구의 한계와 함께, ES6 클래스 도입이 레거시 코드베이스에 미치는 실질적 영향을 정량·정성적으로 제시함으로써, 향후 마이그레이션 전략 수립에 실용적인 가이드라인을 제공한다.