Integrating Structural and Semantic Analysis for Code Smell Refactoring Prediction

소프트웨어는 결코 진정으로 완성되지 않습니다. 수십 년에 걸쳐 유기적으로 성장하는 도시처럼, 컴퓨터 프로그램은 기능의 추가, 패치, 그리고 임시방편적인 수정 사항들이 층층이 쌓여갑니다. 시간이 흐르면서 이러한 유기적 성장은, 마치 벽을 보강하지 않은 채 복도를 넓힌 건물처럼 구조적 약점을 초래할 수 있습니다. 소프트웨어 공학의 세계에서 이러한 국소적인 결함은 '코드 스멜(code smells)'이라고 불립니다. 이는 프로그램이 충돌을 일으키는 오류는 아니지만, 코드를 이해하거나 변경하거나 유지보수하기 어렵게 만드는 나쁜 설계의 징후입니다. 개발자들이 이러한 '냄새'를 발견하면, 그들은 종 often '리팩터링(refactoring)'을 수행합니다. 이는 소프트웨어가 실제로 수행하는 기능은 바꾸지 않으면서 코드의 구조를 개선하기 위해 코드를 재구성하는 신중한 과정입니다. 문제는 개발자들이 발견한 모든 냄새를 항상 고치는 것은 아니며, 어떤 것을 고칠지 예측하는 것은 어렵다는 점인데, 그 결정이 단순히 코드 자체만이 아니라 인간의 의도와 맥락에 달려 있기 때문입니다.

밀라노 비코카 대학교(University of Milano-Bicocca)의 연구팀은 기계가 이러한 인간의 결정을 학습할 수 있는지 알아보기 위해 연구를 시작했습니다. 그들은 컴퓨터가 코드 한 조각을 보고 결함을 식별한 뒤, 개발자가 결국 이를 정리할 것인지를 정확하게 추측할 수 있는지 알고 싶었습니다. 이를 위해 그들은 코드를 바라보는 두 가지 서로 다른 방식을 결합한 시스템을 구축했습니다. 첫 번째 방식은 전통적인 방식으로, 메서드의 길이가 얼마나 되는지 또는 변수를 얼마나 사용하는지와 같은 속성을 세는 것입니다. 두 번째 방식은 더 현대적이고 복결한 방식으로, 코드를 그 논리와 동작의 지도로 변환한 다음, 이 지도를 컴퓨터가 숨겨진 패턴을 분석할 수 있는 수학적 표현으로 변환하는 것입니다. 이 결합된 정보를 머신러닝 모델에 입력함으로써, 연구원들은 컴퓨터가 코드를 정리하려는 개발자의 미묘한 규칙을 학습할 수 있는지 테스트했습니다.

연구진은 79개의 오픈 소스 자바(Java) 프로젝트로부터 데이터를 수집했습니다. 이 프로젝트들은 오랜 시간에 걸쳐 많은 사람에 의해 개발되고 유지보수되어 온 소프트웨어 모음입니다. 그들은 이 프로젝트들의 이력을 스캔하기 위해 자동화된 도구를 사용하였고, 코드 스멜이 존재했던 수천 개의 사례를 식별한 뒤, 변수 이름 변경, 메서드를 더 작은 조각으로 추출, 또는 파라미터 변경과 같은 구체적인 리팩터링 작업을 통해 해당 스멜이 나중에 어떻게 수정되었는지 추적했습니다. 그런 다음 그들은 각 코드 조각에 대해 하이브리드 데이터셋을 생성했습니다. 이 데이터셋에는 메서드의 줄 수와 같은 표준 측정값과 함께 두 가지 유형의 '임베딩(embeddings)'이 포함되었습니다. 한 유형의 임베딩은 제어 흐름을 매핑하여 명령어가 실행되는 순서를 보여주었습니다. 또 다른 더 발전된 유형의 임베딩은 더 깊은 의미론적 관계를 매핑하여, 데이터가 프로그램 내에서 어떻게 이동하는지, 그리고 코드의 서로 다른 부분들이 서로 어떻게 의존하는지를 포착함으로써 코드의 동작에 대한 풍부하고 다차원적인 초상화를 만들어냈습니다.

결과에 따르면, 머신러닝 모델은 높은 신뢰도로 리팩터링을 예측할 수 있는 능력이 있음이 드러났습니다. 모델이 10가지 유형의 리팩터링 작업에 대해 테스트되었을 때, 모델들은 빈번하게 0.70을 훨씬 상회하는 AUC 점수를 기록했으며, 일부 작업에서는 0.80을 넘어서기도 했습니다. 이는 개발자의 정리 의도를 나타내는 감지 가능한 패턴이 코드 안에 실제로 존재함을 시사합니다. 그러나 연구는 중요한 뉘앙스를 밝혀냈습니다. 모든 코드 스멜이 똑같은 것은 아니라는 점입니다. 모델은 메서드에 파라미터를 추가하거나 변수의 타입을 변경하는 것과 같은 구조적 변화를 예측하는 데 매우 뛰어났습니다. 이러한 작업들은 문장의 길이 나 계산의 복잡도와 같이 명확하고 측정 가능한 요인들에 의해 주로 발생합니다. 반면, 모델은 메서드 이름을 변경하는 것과 같은 개념적인 변화를 예측하는 데 어려움을 겪었습니다. 이름 변경은 개발자가 코드의 목적을 어떻게 생각하는지에 기반한 주관적인 결정인 경우가 많으며, 이는 숫자나 구조적 지도만으로는 포착하기 어려운 요소입니다.

아마도 가장 중요한 발견은 사용된 데이터 표현 방식에 관한 것이었을 것입니다. 연구진은 단순히 코드의 실행 흐름을 나타내는 더 복잡한 지도를 추가하는 것만으로 예측 성능이 향와될 것이라고 처음에 예상했습니다. 그러나 그들은 오히려 명령의 순서를 추적하는 특정 유형의 흐름 지도가 모델을 혼란스럽게 하는 노이즈를 유발한다는 사실을 발견했습니다. 이 흐로 매핑이 전통적인 측정값과 결합되었을 때, 컴퓨터가 무관한 세부 사항을 무시하는 데 어려움을 겪으면서 오히려 예측 성능을 떨어뜨리는 경우가 많았습니다. 하지만 연구진이 코드의 구조적 의존성과 실제 텍스트 및 로직을 결합한 더 발전된 표현 방식으로 전환했을 때, 결과는 극적으로 변했습니다. 이 더 풍부한 표현 방식은 모델이 효과적으로 사용할 수 있는 보완적인 신호를 제공했습니다. 실제로 일부 작업에서는 이 고급 표현 방식만으로 훈련된 모델이 전체 데이터셋으로 훈련된 모델과 거의 대등한 성능을 보였는데, 이는 코드의 깊은 구조적 및 의미론적 이해가 그 자체로 강력한 예측 인자임을 입증했습니다.

이 연구는 코드만으로 예측할 수 있는 것의 한계를 강조하기도 했습니다. 모델은 복잡성에 의해 유발되는 기술적 수정은 안정적으로 예측할 수 있었지만, 이름을 변경하거나 명확성을 위해 코드를 재구성하는 인간의 결정은 쉽게 예측할 수 없었습니다. 이는 기계가 소프트웨어의 기술적 유지보수가 시급한 시점을 식별하는 데는 탁월할 수 있지만, 리팩터링을 결정하는 최종 단계는 코드 외부에 존재하는 개발자의 비전과 맥락에 달려 있음을 시사합니다. 연구는 자동화된 소프트웨어 유지보수의 미래가 인간의 판단을 대체하는 것이 아니라, 이러한 예측 도구를 사용하여 가장 시급한 구조적 부채를 강조함으로써 개발자가 가장 중요한 변화에 제한된 시간을 집중할 수 있도록 돕는 데 있다고 결론짓습니다. 어떤 신호가 강한 신호이고 어떤 것이 노이즈인지 이해함으로써, 우리는 우리의 디지털 인프라를 더 건강하고 지속 가능하게 유지할 수 있는 더 나은 도구를 구축할 수 있습니다.