Beyond Strict Rules: Assessing the Effectiveness of Large Language Models for Code Smell Detection

큰 그림: 코드의 "나쁜 습관" 찾기

거대한 도서관(소프트웨어 코드)을 상상해 보세요. 시간이 흐르면서 어떤 책들은 지저륙해지곤 합니다. 어떤 책은 장(chapter)이 너무 길거나, 페이지마다 똑같은 이야기를 반복하거나, 등장인물이 다른 인물에게 지나치게 의존하기도 합니다. 소프트웨어 공학에서 이러한 지저분한 패턴을 **코드 스멜(Code Smells)**이라고 부릅니다. 이는 프로그램을 중단시키는 버그는 아니지만, 나중에 코드를 수정하거나 업데이트하거나 이해하기 어렵게 만드는 "나쁜 습관"과 같습니다.

수년 동안 우리는 이러한 스멜을 찾기 위해 정적 분석 도구(이것을 "규칙집"이라고 불러봅시다)를 사용해 왔습니다. 규칙집은 엄격하며 체크리스트를 따릅니다. 만약 어떤 메서드가 50줄이 넘는다면, 규칙집은 "이것은 긴 메서드(Long Method)다!"라고 판정합니다. 이 방식은 빠르지만, 다소 멍청할 수 있습니다. 단순히 길다는 이유만으로 멀쩡한 긴 메서드를 문제라고 지적하거나, 겉보기에는 문제가 없어 보이는 짧고 지저분한 메서드를 놓칠 수도 있기 때문입니다.

최 최근에는 대규모 언어 모델(LLM)(이들을 "똑똑한 인턴"이라고 불러봅시다)이 유명해졌습니다. 이들은 인간처럼 코드를 읽고 이해할 수 있는 AI 시스템입니다. 이 논문이 던지는 핵심 질문은 이것입니다: 이 똑똑한 인턴들이 엄격한 규칙집보다 나쁜 습관을 더 잘 찾아낼 수 있을까?

실험: 30개의 라이브러리를 활용한 맛 테스트

이를 알아내기 위해 연구진은 대규모 맛 테스트를 준비했습니다.

1. 메뉴: 연구진은 30개의 인기 있는 Java 소프트웨어 프로젝트(30가지 종류의 서로 다른 레스토랑을 고르는 것과 같습니다)를 선정했습니다.
2. 메뉴 항목: 그들은 다음과 같은 9가지 특정 유형의 나쁜 습관(코드 스멜)을 조사했습니다:
   • Long Method (긴 메서드): 너무 많은 일을 하려고 하는 함수.
   • Large Class (거대 클래스): 너무 많은 책임을 떠안아 비대해진 파일.
   • Feature Envy (특징 질투): 자신의 데이터보다 다른 사람의 데이터로 작업하는 데 더 많은 시간을 쓰는 함수.
3. 심사위원: 연구진은 AI가 그냥 추측하게 두지 않았습니다. 그들은 76명의 인간 개발자(훈련된 학생들)에게 268개의 코드 조각을 직접 검사하게 하여, "이것이 실제로 나쁜 습관인가, 아니면 괜찮은가?"를 결정하게 했습니다. 이것이 "그라운드 트루스(Ground Truth)"(공식 정답지)가 되었습니다.
4. 경연 참가자: 연구진은 4가지 서로 다른 똑똑한 인턴(DeepSeek-R1, GPT-5 mini, Llama-3.3, Qwen2.5-Code)을 규칙집(JDeodorant 및 PMD와 같은 전통적인 도구들)과 맞붙였습니다.

결과: 누가 승리했는가?

결과는 "인턴들은 놀랍다"라는 결과와 "규칙집도 여전히 제 자리가 있다"라는 결과가 섞여서 나타났습니다.

1. 쉬운 문제: 인턴들의 활약

세거나 측정하기 쉬운 스멜에 대해서는 똑똑한 인턴들이 환상적이었습니다.

• 비유: 만약 나쁜 습도가 "이 책은 500페이지다"라면, 인턴들은 규칙집만큼이나 페이지 수를 잘 셀 수 있지만, 맥락(context)을 더 잘 이해합니다.
• 승자: Long Method나 Large Class 같은 스멜에 대해 AI 모델들은 매우 강력한 성능을 보였으며, 종종 엄격한 도구들과 대등하거나 그들을 능가했습니다.

2. 까다로운 문제: 인턴마다 다르다

코드가 왜 그렇게 작성되었는지 그 '이유'를 이해해야 하는 스멜의 경우, 결과는 엇갈렸습니다.

• 비유: 이야기 속의 한 캐릭터가 이웃과 너무 많이 대화한다고 가정해 봅시다. 이것이 "특징 질투(Feature Envy, 나쁜 것)"일까요, 아니면 그저 좋은 팀워크일까요? 규칙집은 이를 완전히 놓칠 수 있습니다. 어떤 똑똑한 인턴은 "네, 이건 나쁩니다!"라고 말하는 반면, 다른 인턴은 "아니요, 이건 괜찮습니다!"라고 말할 수 있습니다.
• 발견된 사실: 서로 다른 AI 모델들은 각기 잘하는 분야가 달랐습니다. 예를 들어, 어떤 모델은 "Feature Envy"를 찾는 데 뛰어났고, 다른 모델은 "Intensive Coupling"을 찾는 데 더 나았습니다. 모든 것을 완벽하게 해내는 단 하나의 "슈퍼 AI"는 없었습니다.

3. 가장 어려운 문제: 둘 다 고전하다

Refused Bequest(자식 클래스가 부모의 규칙을 무시하는 경우)나 Shotgun Surgery(작은 변화가 곳곳에서 문제를 일으키는 경우)와 같이 가장 주관적인 스멜에 대해서는, 규칙집과 똑똑한 인턴 모두 어려움을 겪었습니다.

• 비유: 이것들은 단체 채팅방에서의 미묘한 사회적 어색함과 같습니다. 그것이 정확히 언제 문제가 되는지 정의하기 어렵습니다. 가장 똑똑한 AI와 가장 엄격한 규칙집 모두 이 지점에서 의견을 모으는 데 애를 먹었습니다.

비밀 병기: "투표 위원회"

연구진은 영리한 기술을 시도했습니다. 단 하나의 AI나 단 하나의 규칙집에게 묻는 대신, 모두에게(4가지 AI + 2가지 규칙집) 모든 코드 조각에 대해 투표를 요청했습니다. 만약 6명 중 최소 3명이 "이것은 스멜이다"라고 말하면, 그것을 스멜로 간了습니다.

• 결과: 이 "위원회" 방식은 모든 것을 찾아내는 데(높은 재현율, Recall) 가장 뛰어났습니다. 거의 모든 나쁜 습관을 잡아냈으며, 까다로운 것들까지도 잡아냈습니다.
• 주의점: 너무 적극적으로 나쁜 습관을 잡으려다 보니, 깨끗한 코드를 "스멜이 있다"라고 잘못 표시(거짓 양성, False Positives)하기도 했습니다.
• 교훈: 만약 단 하나의 문제도 놓치고 싶지 않다면, 위원회를 사용하십시오. 만약 팀원들에게 잘못된 알람을 주어 귀찮게 하는 것을 피하고 싶다면, 특정 작업에 가장 적합한 최고의 전문가를 선택하십시오.

결론

• 단순한 구조적 문제(코드가 너무 길거나 너무 큰 경우 등)에 대해서는, AI가 강력한 도구가 될 수 있으며 전통적인 도구만큼 혹은 그보다 더 나은 성능을 보여줍니다.
• 복잡하고 맥락이 중요한 문제에 대해서는, 범용적인 "원사이즈(one-size-fits-all)" 접근 방식보다는 특화된 도구나 특정 AI 모델이 여전히 더 낫습니다.
• 최선의 전략: 여러분이 무엇을 가치 있게 여기느냐에 달려 있습니다.
  • 만약 안전성(가능한 모든 문제를 찾는 것)을 원한다면, AI와 도구를 결합하십시오 (위원회 방식).
  • 만약 정밀도(잘못된 알람을 피하는 것)를 원한다면, 해당 특정 스멜에 가장 적합한 도구나 AI 모델을 선택하십시오.

요약하자면, 똑똑한 인턴들은 도울 준비가 되어 있지만, 어떤 일을 맡길 때 어떤 인턴에게 물어야 할지, 혹은 기존의 규칙집들과 함께 일하게 하는 법을 알고 있을 때 가장 효과적입니다.