소프트웨어 프로젝트는 한 번 지으면 끝나는 것이 아니라, 시간이 지나며 계속 리모델링을 합니다. 여기서 **'의존성 (Dependency)'**이란 이 집에 필요한 가구나 도구들입니다.
예를 들어, '부엌용 칼 (Core)'은 살 때부터 있어야 하고, '수리용 망치 (Dev)'는 공사할 때만 쓰며, '손님이 가져오는 접시 (Peer)'는 손님이 직접 챙겨와야 합니다.
하지만 개발자들은 처음에 이 도구들을 어디에 두어야 할지 완벽하게 정하지 못합니다. 시간이 지나며 "아, 이 망치는 공사 때만 쓰는 게 아니라 살 때도 써야겠다"거나 "이 칼은 사실 필요 없네"라고 깨닫게 됩니다. 이때 도구들의 위치를 옮기거나 버리는 행위를 **'의존성 재분류 (Reclassification)'**라고 합니다.
이 논문은 3 만 3 천 개 이상의 자바스크립트 프로젝트를 조사하여, 개발자들이 이 도구들을 어떻게 재배치하는지 분석했습니다.
🔍 주요 발견 사항 (3 가지 핵심 이야기)
1. "처음 정한 위치는 절대적이지 않다" (재분류는 매우 흔함)
현상: 연구 결과, 조사된 프로젝트의 **약 80%**에서 개발자들이 도구들의 위치를 다시 정했습니다.
비유: 집을 지을 때 "이건 부엌에 두자"라고 정해뒀던 식탁이, 나중에 "아니, 이건 거실로 옮겨야겠다"거나 "이건 아예 버리자"라고 바뀌는 것과 같습니다.
통계: 프로젝트의 79.1% 에서 적어도 한 번은 이런 재배치 작업이 일어났습니다.
2. "버렸다가 다시 꺼내거나, 위치를 오가는 도구들" (세 가지 패턴)
개발자들은 도구들을 어떻게 처리할까요? 크게 세 가지 패턴이 발견되었습니다.
A. 과감한 정리 (삭제):
필요 없는 도구를 통째로 치웁니다. 특히 '공사 도구 (Dev)'나 '부엌 도구 (Core)'는 여러 개를 묶어서 한 번에 치우는 경우가 많습니다.
재미있는 점: 가끔은 "너무 많이 치웠네"라고 생각해서 다시 꺼내기도 합니다. (약 33% 의 프로젝트에서 버렸던 도구를 다시 가져왔습니다.)
B. 역할 변경 (이동):
"이건 공사 때만 쓰는 게 아니라, 살 때도 써야겠다"며 Dev(공사용) 에서 Core(생존용) 로 옮기거나 그 반대로 옮기는 경우가 많습니다.
특히 **빌드 도구 (Webpack, Babel 등)**들이 자주 위치를 바꿉니다. 처음엔 공사 도구로 썼는데, 나중에 살 때도 필요해서 부엌으로 옮기거나, 반대로 살 때 필요 없으니 공사 도구로 내리는 식입니다.
C. 위치 오실레이션 (오래된 고민):
어떤 도구는 Core → Dev → Core처럼 위치를 왔다 갔다 하기도 합니다.
비유: "이건 거실에 둘까? 아니면 부엌에 둘까?" 고민하다가 거실에 뒀다가, "아니야 부엌이 맞네" 하고 옮기다가, 다시 "거실이 더 편한데?" 하며 되돌리는 과정입니다. 이는 개발자가 도구의 정확한 역할을 고민하는 과정입니다.
3. "결정은 하루아침에 나지 않는다" (시간이 걸림)
현상: 도구를 한 번 정했다가 위치를 바꾸는 데는 **평균 1 년 이상 (약 408 일)**이 걸립니다.
비유: "이 가구를 어디에 둘까?" 고민하다가 1 년이 지나서야 "아, 여기가 맞네" 하고 옮기는 것입니다.
의미: 개발자들은 실수를 바로 고치는 것이 아니라, 도구를 오랫동안 써보면서 "아, 이거 원래 용도가 아니었구나"라고 깨닫고 천천히 정리합니다.
💡 이 연구가 우리에게 주는 교훈
이 논문은 개발자들에게 다음과 같은 메시지를 줍니다.
완벽한 시작은 없다: 처음에 도구를 어디에 두든 나중에 고칠 수 있다는 사실을 인정해야 합니다.
도구 관리도 중요하다: 단순히 버전을 업데이트하는 것만 중요한 게 아니라, "이 도구가 정말 필요한가?", "어떤 역할로 써야 할까?"를 계속 고민하고 정리하는 과정이 프로젝트 건강에 필수적입니다.
도구 (소프트웨어) 가 도와야 한다: 현재는 개발자가 실수한 위치를 스스로 찾아내야 하지만, 앞으로는 **"이 도구는 보통 공사용으로 쓰는데, 왜 살 때 쓰는 거야?"**라고 알려주는 스마트한 관리 도구가 필요하다는 것입니다.
📝 한 줄 요약
"소프트웨어 프로젝트는 한 번 정해진 도구 배치가 영원한 것이 아니라, 개발자들이 시간이 지나며 실수를 고치고 역할을 재정의하며 계속 '리모델링'해 나가는 살아있는 집이다."
논문 개요
이 논문은 JavaScript 프로젝트의 종속성 (Dependency) 관리에서 종속성 재분류 (Dependency Reclassification) 현상을 대규모로 종단적 (Longitudinal) 으로 분석한 연구입니다. 기존 연구가 주로 종속성의 버전 업데이트나 보안 문제에 집중했다면, 본 연구는 프로젝트가 진화함에 따라 개발자가 종속성을 Core(런타임), Dev(개발용), Peer(소비자 제공) 역할 사이에서 어떻게 재정의하고, 제거하며, 다시 도입하는지에 초점을 맞추고 있습니다.
1. 연구 배경 및 문제 정의 (Problem)
종속성 역할의 불확실성: JavaScript 프로젝트 (package.json) 에서는 종속성이 런타임에 필요한지 (dependencies), 개발 도구에 불과한지 (devDependencies), 혹은 하위 프로젝트가 제공해야 하는지 (peerDependencies) 명시됩니다.
현실적 문제: 개발 초기에 할당된 역할이 프로젝트의 진화와 함께 부정확해지거나, 개발자가 실제 사용처를 파악한 후 수정해야 하는 경우가 빈번합니다.
연구 공백: 기존 연구는 종속성 추가나 버전 변경에 집중했으나, 역할 재분류 (Reclassification) 는 프로젝트 역사 전반에 걸쳐 지속적으로 발생하는 중요한 유지보수 활동임에도 불구하고 그 패턴과 빈도가 잘 알려져 있지 않았습니다.
위험성: 잘못된 역할 선언은 불필요한 프로덕션 환경의 용량 증가 (Bloat) 와 공격 표면 확대를 초래할 수 있습니다.
2. 연구 방법론 (Methodology)
데이터셋 구성:
GitHub Search Engine(GHS) 에서 26 만 개 이상의 저장소를 수집했습니다.
포크 제외, 10 개 이상의 스타, 최소 10 개 커밋, 2020 년 이후 활동, 유효한 package.json 존재, 종속성 변경 이력 존재 등의 필터링을 거쳐 33,087 개의 JavaScript 프로젝트를 최종 선정했습니다.
재분류 이벤트 식별:
각 프로젝트의 기본 브랜치 (default branch) 에 있는 커밋을 추적하여 package.json 의 구조적 차이를 분석했습니다.
재분류 (Reclassification) 를 종속성 이름이 동일하게 유지된 상태에서 역할 (Core, Dev, Peer, Void/제거) 이 변경되는 사건으로 정의했습니다.
버전 업데이트만 있는 경우, 초기 도입, 또는 멀티패키지 프로젝트 내의 파일 이동은 제외했습니다.
패턴 분류 (Taxonomy):
291,741 개의 재분류 커밋을 분석하여 종속성 진화 시퀀스를 추출했습니다.
이를 제거 관련 (Removal) 및 역할 재할당 관련 (Reassignment) 두 가지 주요 카테고리로 분류하고, 단계적 제거, 되돌림 (Reversion), 진동 (Oscillation) 등의 하위 패턴을 정의했습니다.
3. 주요 연구 질문 (Research Questions)
RQ1: 개발자가 종속성을 재분류하는 보편성 (Prevalence) 은 얼마나 되는가?
RQ2: 개발자는 실제로 종속성을 어떻게 제거하는가? (단일 단계 vs 다단계, 일괄 제거 등)
RQ3: 개발자는 종속성 역할을 어떻게 재할당하는가? (Core ↔ Dev, Peer ↔ Core 등)
RQ4: 종속성 재분류가 완료되기까지 얼마나 시간이 걸리는가?
4. 주요 결과 (Key Results)
RQ1: 재분류의 보편성
연구 대상 프로젝트의 79.1% 가 적어도 한 번 이상 종속성 재분류 (제거 또는 역할 변경) 를 수행했습니다.
제거 (Removal): 97.2% 의 프로젝트에서 종속성 제거가 발생했습니다.
역할 재할당 (Reassignment): 38.0% 의 프로젝트에서 역할이 변경되었습니다.
불안정성: 제거된 종속성의 33.1% 가 나중에 다시 도입되었고, 11.2% 의 프로젝트는 역할이 여러 번 오가는 진동 (Oscillation) 현상을 보였습니다.
RQ2: 제거 패턴
일괄 제거 (Batch Removal): Core 및 Dev 종속성은 주로 여러 개를 한 번에 제거하는 '정리 (Cleanup)' 형태로 제거되었습니다 (Core 의 61.9%, Dev 의 79.6% 가 2 개 이상 제거). 반면 Peer 종속성은 개별적으로 제거되는 경향이 강했습니다.
부분적 되돌림 (Partial Reversion): 일괄 제거 후 다시 도입될 때, 전체가 아닌 62% 의 경우 일부 종속성만 다시 추가되었습니다. 이는 개발자가 과도한 제거를 수정하는 과정에서 신중한 접근을 취함을 시사합니다.
다단계 제거 (Multi-step Removal): 약 17.8% 의 프로젝트는 종속성을 바로 제거하지 않고, 먼저 다른 역할 (예: Core → Dev) 로 이동시킨 후 나중에 제거하는 단계를 거쳤습니다.
RQ3: 역할 재할당 패턴
Core ↔ Dev: 가장 흔한 재분류입니다. 개발 도구 (Babel, Webpack 등) 가 실수로 Core 에 포함되거나, 반대로 런타임에 필요한 도구가 Dev 에만 있는 경우 수정이 이루어집니다.
Peer 재분류: Peer(소비자 제공) 로 선언된 종속성이 프로젝트 자체 관리 (Core 또는 Dev) 로 변경되는 경우가 많았습니다. 이는 설치 복잡성을 줄이기 위해 개발자가 직접 종속성을 관리하려는 경향을 보여줍니다.
역할 진동 (Oscillation): 11.2% 의 프로젝트에서 종속성 역할이 여러 번 변경되며 안정화되지 않는 현상이 관찰되었습니다.
RQ4: 시간적 패턴
재분류는 즉각적인 조치가 아니라 장기적인 유지보수 활동입니다.
재분류 패턴의 전체 지속 기간 중앙값은 408 일입니다.
단일 단계 (One-step): 종속성이 원래 역할로 유지된 후 제거되거나 변경되기까지 평균 200~500 일 이상 소요됩니다.
다단계 (Multi-step): 역할 변경 (Step 1) 과 최종 제거 (Step 2) 사이에 상당한 시간 간격이 존재합니다. 예를 들어, Core 에서 Dev 로 변경된 후 제거되기까지 수백 일이 걸리기도 합니다.
5. 의의 및 시사점 (Significance & Implications)
도구 및 패키지 매니저에 대한 시사점
역할 이력 시각화: 현재 package.json 은 현재 상태만 보여주므로, 도구 개발 시 종속성의 과거 역할 변경 이력을 제공하여 개발자가 잘못된 할당을 인지하도록 지원해야 합니다.
일괄 제거 검증: 대량 제거 시, 어떤 종속성이 실제로 필요한지 동적/정적 분석을 통해 검증하는 기능이 필요합니다.
Peer 의존성 경고: 개발 도구 (Build/Test) 가 Peer 로 잘못 선언되거나, 반대로 프로덕션에 불필요한 Dev 도구가 포함될 경우 패키지 매니저가 경고해야 합니다.
연구적 시사점
종속성 관리 연구는 단순한 버전 업데이트를 넘어, 역할의 진화와 재정의를 포함해야 합니다.
개발자가 왜 초기에 잘못된 역할을 할당하고, 왜 그 오류가 장기간 방치되는지에 대한 정성적 연구 (커밋 메시지, 이슈 토론 분석) 가 필요합니다.
6. 결론
이 연구는 JavaScript 생태계에서 종속성 선언이 고정된 것이 아니라, 프로젝트의 진화와 함께 지속적으로 수정되고 재분류되는 동적인 유지보수 과정임을 실증적으로 증명했습니다. 개발자들은 종속성을 제거하거나 역할을 변경하는 과정에서 시행착오를 겪으며, 이는 수개월에서 수년에 걸쳐 이루어집니다. 이러한 발견은 종속성 관리 도구와 패키지 매니저가 '역할 인식 (Role-aware)' 기능을 강화하여 개발자를 지원해야 함을 시사합니다.