Each language version is independently generated for its own context, not a direct translation.

🏙️ 비유: 소프트웨어는 거대한 도시입니다

소프트웨어를 하나의 거대한 도시라고 상상해 보세요.

코드 (Code): 도시의 건물과 도로.
모듈 (Module): 도시의 구역 (예: 주거 지구, 상업 지구).
의존성 (Dependency): 구역과 구역을 잇는 도로나 전선.
코드 냄새 (Code Smell): 건물의 설계가 잘못되었거나, 관리가 안 된 **'나쁜 이웃'**이나 '불량 건물'.

예를 들어, '신경질적인 이웃 (Feature Envy)'은 자기 집 일은 안 하고 옆집 물건을 훔쳐 쓰려 하거나, '거대 괴물 건물 (God Class)'은 도시의 모든 일을 혼자 다 하려고 하죠.

🔍 이 연구가 발견한 놀라운 사실

연구진들은 "나쁜 이웃이 하나만 있을 때와, 나쁜 이웃들이 서로 만나서 뭉쳤을 때 어떤 차이가 있을까?"를 궁금해했습니다.

1. 나쁜 이웃들은 서로 잘 어울립니다 (빈도)

연구 결과, 나쁜 이웃들 (코드 냄새들) 은 혼자 있는 경우보다 서로 만나서 뭉치는 경우가 매우 많았습니다.

비유: 도시에서 '신경질적인 이웃'이 '거대 괴물 건물' 옆에 살 가능성이 매우 높다는 뜻입니다. 서로가 서로의 문제를 부추기며 함께 존재합니다.

2. 뭉치면 교통 체증이 심해집니다 (의존성 증가)

가장 중요한 발견은 이것입니다. 나쁜 이웃들이 서로 연결되어 있을 때, 그들 사이의 '도로 (의존성)'가 훨씬 더 많아집니다.

비유: 나쁜 이웃 A 와 나쁜 이웃 B 가 서로 연결되어 있으면, 그들 사이를 오가는 차량 (데이터나 명령) 이 평소보다 훨씬 많이 몰립니다.
결과: 36 가지 경우 중 28 가지에서 전체 도로의 수가 급격히 늘어났습니다. 이는 곧 "나쁜 이웃들이 뭉치면 도시 전체의 교통 체증 (유지보수 비용) 이 훨씬 더 심해진다"는 뜻입니다.

3. 연결되는 방식에도 규칙이 있습니다 (방향성)

단순히 도로만 늘어난 게 아니라, 어떤 방향으로 도로가 늘어나는지도 규칙이 있었습니다.

비유: 어떤 나쁜 이웃은 '물건을 가져가는' 도로를 늘리고, 어떤 나쁜 이웃은 '물건을 주는' 도로를 늘리는 식입니다.
예시: '데이터를 많이 쓰는 이웃 (Feature Envy)'은 '데이터를 많이 가진 이웃 (Data Class)'과 만날 때, 데이터를 가져가는 도로가 훨씬 더 많이 생깁니다.

💡 이 연구가 우리에게 주는 교훈 (실용적인 조언)

이 연구는 개발자들에게 다음과 같은 구체적인 조언을 줍니다.

1. 혼자 있는 나쁜 이웃보다 '뭉친 나쁜 이웃'을 먼저 고치세요.

이유: 혼자 있는 나쁜 이웃은 도로가 적어서 고쳐도 큰 영향이 없지만, 뭉쳐 있는 나쁜 이웃들은 서로를 통해 **교통 체증 (리플 효과)**을 일으키기 때문입니다.
해결책: "저기 저 두 건물이 서로 너무 많이 연락하고 있네? 이 둘을 먼저 분리하거나 구조를 고쳐야 도시가 원활해지겠다!"라고 판단할 수 있습니다.

2. '누가 누구를 부르는지'를 보면 나쁜 이웃을 찾을 수 있습니다.

이유: 연구진은 나쁜 이웃들이 서로 만날 때 도로가 어떻게 변하는지 패턴을 만들었습니다.
활용: 만약 어떤 건물이 평소보다 훨씬 더 많은 '물건 가져오기' 도로를 가지고 있다면, 그 건물은 '신경질적인 이웃 (Feature Envy)'일 확률이 높습니다. 이렇게 도로의 흐름을 분석하면 숨겨진 나쁜 이웃을 찾아낼 수 있습니다.

3. 고칠 때 '함께' 고쳐야 합니다.

이유: 두 나쁜 이웃이 서로 얽혀 있다면, 하나만 고쳐도 다른 하나가 다시 문제를 일으킬 수 있습니다.
해결책: 두 건물의 관계를 끊고, 각각의 역할을 명확히 분리하는 '재건축 (리팩토링)' 전략이 필요합니다. 예를 들어, '데이터를 훔쳐 쓰는 이웃'을 '데이터를 가진 이웃' 건물 안으로 옮겨서, 더 이상 훔쳐갈 필요가 없게 만드는 것입니다.

📝 한 줄 요약

"나쁜 코드 (코드 냄새) 하나하나가 문제라면, 서로 만나 뭉친 나쁜 코드는 '교통 체증'을 유발하여 소프트웨어를 훨씬 더 고치기 어렵게 만듭니다. 그래서 우리는 나쁜 코드들이 서로 어떻게 연결되어 있는지 분석해서, 가장 먼저 끊어야 할 연결고리를 찾아내야 합니다."

이 연구는 개발자들이 단순히 "코드가 지저분하다"고 느끼는 것을 넘어, **"어떤 지저분한 부분들이 서로 연결되어 문제를 키우고 있는지"**를 과학적으로 증명하고, 이를 해결하는 전략을 제시했다는 점에서 매우 의미 있습니다.

Each language version is independently generated for its own context, not a direct translation.

코드 스멜 상호작용에 의한 의존성 분포 변화 분석: 기술적 요약

본 논문은 소프트웨어 유지보수 복잡성을 유발하는 주요 원인인 **코드 스멜 (Code Smell)**과 모듈 간의 정적 의존성 (Static Dependencies) 간의 관계를 심층적으로 분석한 연구입니다. 특히, 개별적인 코드 스멜이 아닌 여러 코드 스멜이 상호작용할 때 의존성 분포가 어떻게 변화하는지에 대한 실증적 증거를 제시합니다.

1. 연구 배경 및 문제 정의

문제: 모듈 간의 과도한 의존성은 변경 시 파급 효과 (Ripple Effect) 를 일으켜 유지보수 비용과 복잡성을 증가시킵니다.
기존 연구의 한계: 기존 연구들은 개별 코드 스멜이 유지보수성에 미치는 영향을 조사했으나, 그 영향이 통계적으로 유의미하지 않거나 미미하다는 결과가 많았습니다. 반면, 여러 스멜이 공존할 때 (Co-location) 는 유지보수성이 현저히 저하된다는 보고가 있었습니다.
연구 동기: 코드 스멜 간의 상호작용 (특히 정적 의존성을 통한 연결) 이 유지보수성 저하의 핵심 메커니즘일 수 있음이 제기되었으나, 이를 정량적으로 분석한 연구는 부족했습니다. 본 연구는 코드 스멜 상호작용이 정적 의존성의 수와 유형 분포에 어떤 변화를 일으키는지를 규명하는 것을 목표로 합니다.

2. 연구 방법론 (Methodology)

2.1 데이터 수집

대상: GitHub 의 인기 있는 오픈소스 Java 프로젝트 116 개를 선정했습니다.
선정 기준: 포크 수 100 개 이상, Java 코드 비율 80% 이상, 교육용/비실무 프로젝트 제외 등.
분석 대상 코드 스멜 5 가지:
1. Feature Envy (FE): 다른 클래스의 데이터에 과도하게 의존하는 메서드.
2. Brain Method (BM): 과도하게 크고 복잡한 메서드.
3. God Class (GC): 시스템 기능을 집중화하고 낮은 응집도를 가진 클래스.
4. Brain Class (BC): 시스템 기능을 집중화한 과도하게 큰 클래스 (BM 포함).
5. Data Class (DC): 행위를 캡슐화하지 않고 데이터만 노출하는 클래스.

2.2 분석 도구 및 접근법

도구: 정적 분석 도구인 CodeQL을 사용하여 커스텀 쿼리를 개발하여 의존성, 아티팩트 (클래스, 메서드, 필드 등), 코드 스멜을 추출했습니다.
상호작용 정의: 두 아티팩트 사이에 정적 의존성이 존재하면 '상호작용'이 발생한 것으로 정의합니다.
- 상호작용 유형: 스멜 - 스멜 (CS1-CS2), 스멜 - 비스멜 (CS1-nonCS2), 비스멜 - 스멜 (nonCS1-CS2).
- 상대적 위치: 같은 클래스 내 (Same) vs 다른 클래스 간 (Different).
통계 분석:
- Mann-Whitney U Test: 의존성 수 분포의 유의미한 차이 검정.
- Cliff's Delta ( $\delta$ ): 효과 크기 (Effect Size) 측정 및 변화 방향 (증가/감소) 확인.
- Benjamini-Hochberg Procedure: 다중 검정 보정 (False Discovery Rate 제어).

2.3 연구 질문 (RQs)

RQ1: 코드 스멜은 얼마나 빈번하게 상호작용하는가?
RQ2: 코드 스멜 상호작용으로 인해 의존성 분포는 어떻게 달라지는가? (전체 의존성 수 및 특정 의존성 유형별 변화)

3. 주요 결과 (Key Results)

3.1 상호작용 빈도 (RQ1)

대부분의 코드 스멜 쌍이 빈번하게 상호작용합니다.
전체 20 가지 쌍 중 약 50% 가 40% 이상의 상호작용 빈도를 보였습니다.
특히 Brain Class (BC) 와 Brain Method (BM) 간의 상호작용 빈도가 99.7% 로 매우 높았으며, **Data Class (DC)**는 다른 스멜들과 높은 상호작용 빈도를 보였습니다 (데이터 제공자 역할).

3.2 의존성 분포 변화 (RQ2)

전체 의존성 증가: 36 가지 가능한 경우 중 28 가지에서 코드 스멜 상호작용이 존재할 때 전체 의존성 수가 통계적으로 유의미하게 증가했습니다.
특정 의존성 유형의 변화:
- 데이터 접근 (Data Access): 다른 클래스 간 접근 (Accessor 호출) 및 동일 클래스 내 필드 사용.
- FM 호출 (Function Method Call): 기능 메서드 간의 호출.
- 이 두 가지 유형의 의존성에서 상호작용 시 **유의미한 변화 (증가 또는 감소)**가 가장 빈번하게 관찰되었습니다 (검정 건수의 25%~67% 에서 작은 효과 크기 이상).
일관된 변화 방향: 특정 스멜 쌍과 역할 (제공자/소비자) 에 따라, 의존성 수의 변화 방향 (증가 또는 감소) 이 일관되었습니다.
- 예: Feature Envy (FE) 는 다른 클래스 간 데이터 접근 의존성을 증가시키는 경향이 있으나, 같은 클래스 내에서는 감소하는 경향을 보였습니다.

3.3 프로젝트별 분석 (Per-System)

개별 프로젝트별로 분석했을 때에도 전체 데이터 (Union dataset) 에서 관찰된 경향과 일치하는 변화 방향을 보였습니다.
일부 프로젝트에서는 통계적 유의성이 낮거나 변화 크기가 달랐으나, 전반적인 방향성 (Direction) 은 일관되었습니다.

4. 주요 기여 및 시사점 (Contributions & Implications)

4.1 다차원 분류 체계 (Multi-Dimensional Typology)

연구 결과에 기반하여 코드 스멜을 **의존성 유형 (FM 호출, 데이터 접근)**과 **역할 (제공자, 소비자)**에 따라 **강함 (Strong)**과 **약함 (Weak)**으로 분류하는 체계를 제안했습니다.

Strong: 상호작용 시 의존성 수가 증가하는 스멜 (예: GC, BC 는 FM 제공자/소비자로서 Strong).
Weak: 상호작용 시 의존성 수가 감소하거나 변화가 미미한 스멜 (예: FE, BM 은 FM 제공자로서 Weak).
이 분류는 코드 스멜 상호작용 시 의존성 변화 방향을 예측하는 데 활용 가능합니다.

4.2 실용적 활용 방안

코드 스멜 탐지 및 우선순위 결정:
- 상호작용을 통해 다른 스멜의 존재를 추론할 수 있습니다 (예: GC 와 상호작용하는 메서드에서 FM 호출 수가 적으면 FE 일 가능성이 높음).
- 상호작용하는 스멜 쌍을 우선적으로 리팩토링해야 합니다. 이는 더 많은 의존성을 제거하고 파급 효과를 줄일 수 있기 때문입니다.
효과적인 리팩토링 전략 수립:
- FE 와 DC 상호작용: FE 가 DC 의 데이터를 과도하게 접근하는 경우, FE 를 DC 내부로 이동시키는 전략이 유효합니다.
- GC 와 BC 상호작용: 두 클래스 간 의존성이 복잡하게 얽혀 있는 경우, 공통 책임을 가진 새로운 클래스를 추출하여 두 클래스 모두에서 분리하는 전략이 효과적입니다.

5. 결론 및 의의

본 연구는 코드 스멜 간의 상호작용이 정적 의존성 분포를 유의미하게 변화시킨다는 최초의 대규모 실증적 증거를 제시했습니다. 개별 스멜의 영향보다는 **스멜 간의 상호작용 (Interactions)**이 유지보수성 저하의 핵심 요인임을 입증했습니다.

이 연구 결과는 다음과 같은 의의를 가집니다:

도구 개발자: 코드 스멜 탐지 도구의 정확도를 높이고, 상호작용 기반의 스멜 우선순위 결정 로직을 구현할 수 있음.
실무자 (Practitioners): 단순한 스멜 제거가 아닌, 상호작용하는 스멜 쌍을 식별하여 리팩토링함으로써 유지보수 비용을 절감할 수 있는 구체적인 전략을 제공받음.
연구자: 의존성 분포 패턴과 유지보수성 지표 (변경 빈도, 결함 발생률 등) 간의 인과 관계를 규명하기 위한 기초 데이터를 제공함.

결론적으로, 소프트웨어의 모듈성을 유지하고 유지보수성을 향상시키기 위해서는 개별 코드 스멜의 제거뿐만 아니라, 스멜 간의 상호작용과 이로 인한 의존성 구조의 변화를 체계적으로 분석하고 관리해야 함을 강조합니다.

Analyzing Dependency Distribution Changes Arising from Code Smell Interactions