Rittel과 Webber는 고약한 문제를 일반적인 문제와 구별하는 10가지 특성을 제시했으며, 이는 소프트웨어 의존성 관리 작업에 다음과 같이 적용됩니다.
1. 명확한 문제 정의의 부재
-
용어의 모호성: ‘패키지 관리’라는 용어 자체가 npm, Cargo, apt, Homebrew 등 다양한 시스템을 지칭하며, 소프트웨어 빌드 시 의존성 관리와 시스템 도구 설치라는 다른 문제를 의미합니다.
-
이해관계자 간의 정의 불일치: 패키지 관리가 재현성, 최신성, 보안, 편의성 중 무엇을 우선해야 하는지에 대한 합의가 없으며, 각기 다른 답변이 문제 정의를 형성합니다. npm의 록파일(lockfile) 추가나 Cargo의 중앙 레지스트리 도입은 기존 문제 해결이 아닌, 문제 자체를 재정의한 사례입니다.
2. 종결점의 부재
-
지속적인 기능 추가: Bundler(2010년 이후), npm(10번째 주요 버전), UV 등 패키지 관리자는 ‘완료’되는 시점이 없으며, 끊임없이 기능을 추가하고 개선됩니다.
-
외부 요인에 의한 중단: 작업은 문제 해결이 아닌 시간, 자금 부족, 관리자의 번아웃, 새로운 대안의 등장 등으로 중단됩니다.
3. 참/거짓이 아닌 좋음/나쁨
- 주관적인 평가: 해결책은 객관적으로 옳거나 그르지 않으며, 특정 관점에서만 좋거나 나쁘다고 평가됩니다. Homebrew의 Git 데이터베이스 사용 결정이나 Semver의 실제 적용(Hyrum’s Law)은 이러한 주관적 평가의 대표적인 예시입니다.
4. 해결책이 파급 효과를 생성
- 예측 불가능한 결과: Go의 URL 기반 임포트처럼 즉각적으로는 우아해 보였던 해결책이 수년 후 레포 사라짐, 보안 문제, 중앙 프록시 필요성 등의 파급 효과를 낳았습니다. 패키지 관리 설계는 A/B 테스트가 불가능하며, 일단 구축되면 생태계 전체에 영향을 미칩니다.
5. 돌이킬 수 없는 결과
- 영구적인 흔적: PyPI의 네임스페이스 없는 패키지 이름 허용, npm의 버전 범위 의존성 허용 등 한 번 구현된 해결책은 돌이킬 수 없는 흔적을 남깁니다. RubyGems와 같은 레지스트리에는 오래된 패키지가 영구적으로 남아 있으며, 이를 제거하려는 시도조차 새로운 문제를 야기합니다.
6. 명확한 해결책 세트의 부재
- 충돌하는 목표: 레지스트리 운영자(안정성), 보안 연구원(감사 가능성), 라이브러리 개발자(유연성), 애플리케이션 개발자(재현성) 등 이해관계자마다 목표가 충돌하며, 이는 npm/Yarn/pnpm 경쟁처럼 다양한 도구가 공존하는 이유가 됩니다.
7. 본질적인 고유성
- 맥락 의존성: npm의 해결책은 JavaScript의 특정 역사와 문화에서, Cargo는 Rust의 제약에서 비롯됩니다. Python이 npm 스타일 록파일을 도입하려 했을 때, virtualenv, 시스템 패키지 등 Python 생태계의 고유한 특성 때문에 어려움을 겪었습니다.
8. 다른 문제의 증상
- 내재된 문제: 공급망 보안은 단순히 패키지 관리 문제가 아니라 오픈소스 자금 지원, 관리자 지원, 기업의 위험 평가 등과 얽혀 있습니다. 현대 소프트웨어의 의존성 폭발은 개발자 생산성 압박, 시장 경쟁의 증상입니다.
9. 다양한 인과적 설명
- 경쟁하는 이론: npm 보안 사고의 원인에 대해 JavaScript 문화, npm 설계, 기업 투자 부족, 동적 임포트 아키텍처, 공격자 지능화 등 다양한 설명이 존재하며, 각 설명은 다른 해결책을 제시합니다.
1
- 틀릴 권리의 부재
- 실험 불가: 패키지 관리자 설계자는 과학자처럼 가설을 세우고 테스트할 수 없습니다. left-pad 사태처럼 잘못된 결정은 수천 개의 빌드를 망가뜨리고 보안 침해, 신뢰 상실로 이어지며, 돌이킬 수 없는 영구적인 정책으로 남습니다.