docs: ~21 장 완료

21. Dependency Management.md

@@ -187,3 +187,47 @@
   - (지나친 구속과 지나친 약속을 피하기 위해) 의존성들이 충분히 세분화되어 있다.
   - (직간접적으로 사용하는 의존성에서 호환된다고 가정하고 진행한 변경임에도 코드가 예기치 못한 방식으로 오작동하는 일을 피하기 위해) 모든 API를 제공자의 의도대로 사용한다.
 - 이상의 조건을 세심하게 고려하여 철저히 관리되는 소수의 의존성만 신중하게 선택해 네트워크를 구성한 경우라면 SemVer가 완벽한 해법이 되어줄 것이다.
+
+## 21.5 자원이 무한할 때의 의존성 관리
+
+- 현재 업계가 SemVer에 의지하는 이유
+  - 내부 정보만 있으면 된다(API 제공자가 다운스트림 사용자가 어떻게 이용하는지까지 알 필요 없다).
+  - 충분한 테스트를 수행할 컴퓨팅 자원, 테스트 결과를 모니터링 해줄 CI 시스템이 존재하지 않아도 된다(아직 업계 전체에 퍼지지는 않았지만 향후 10년 안에는 반드시 달라질 것이다).
+  - 관행이다.
+- 만약 더 많은 컴퓨팅 자원을 쓸 수 있고 다운스트림 의존성 정보를 더 쉽게 얻을 수 있다면 소프트웨어 업계는 분명 이 정보를 이용할 방법을 찾을 것이다.
+- OSS 생태계 전체를 책임지는 CI를 도입하지 않더라도 의존성 그래프와 테스트를 이용하여 의존성 관리라는 목적에 더 잘 부합하는 프리서브밋 분석을 수행할 수 있다.
+- 리팩터링부터 기능 수정까지 모델을 적용하기 위해 변화시켜야 할 OSS 생태계
+  - **모든 의존성이 단위 테스트를 제공해야 한다.** 단위 테스트가 점점 널리 받아들여지고 품질도 높아지고 있지만 아직 충분하지 못하다.
+  - **OSS 생태계 대부분이 의존성 네트워크를 이해해야 한다.** 이 거대한 네트워크에서 그래프 알고리즘을 수행해줄 메커니즘이 존재하는지 확실치 않다. 네트워크 정보는 공개되어 있지만 적절한 형태로 인덱싱되어 있지 못하다. 많은 패키지 관리 시스템 혹은 의존성 관리 생태계가 각 프로젝트가 무엇을 의존하는지는 알려주지만, 반대로 그 프로젝트에 무엇이 의존하는지까지는 말해주지 못한다.
+  - **CI를 수행하기 위한 컴퓨팅 자원이 부족하다.** 대다수 개발자가 빌드와 테스트에 컴퓨팅 클라우드를 이용하지 않는다.
+  - **의존성을 고정해놓는 경우가 많다.** 예를 들어 liba와 libb가 특정 버전의 libbase만을 이용하게끔 고정해뒀다면 libbase 메인테이너는 liba와 libb가 신버전 libbase에서도 잘 작동하는지 테스트해볼 수 없다.
+  - **CI 이력과 평판을 명시하는 것도 좋은 방법일 수 있다.** 새로 제안된 변경이 오랜 기간 아무 문제없던 프로젝트를 실패하게 한 것과, 알 수 없는 이유로 자주 실패해온 신생 프로젝트를 실패하게 한 것은 다르게 취급할 수 있다.
+- 네트워크를 이루는 각 의존성의 어느 버전들까지 프리서브밋 검사를 해야하는가? 가장 간단한 전략은 '현시점의 안정 버전을 테스트해라'이다(결국 트렁크 기반 개발로 귀결된다). 따라서 자원이 무한할 때의 의존성 관리는 사실상 '헤드에서 지내기' 모델로 수렴한다.
+
+## 21.5.1 의존성 내보내기
+
+- 다른 이들이 이용할 수 있는 소프트웨어를 빌드하는 방법에 대해서도 생각해봐야 한다.
+- 우리 자신과 잠재적인 고객들이 우리가 제공한 소프트웨어를 이용할 때의 이점, 비용, 위험에 대해서까지 생각해봐야 한다.
+- 선한 의도로 라이브러리를 오픈 소스로 공개했는데 오히려 조직에 해를 끼치는 방식
+  1. 구현 품질이 떨어지거나 제대로 관리하지 못하면 조직의 평판을 떨어뜨린다.
+  2. 동기화를 유지할 수 없다면 선의의 릴리즈가 엔지니어링 효율을 떨어뜨릴 것이다.
+- 외부 사용자는 내부 사용자보다 관리 비용이 훨씬 크다.
+- 오픈 소스 형태로든 소스는 공개하지 않는 라이브러리 형태로든, 코드를 외부 세계와 공유하는 일은 단순히 커뮤니티 기여나 비즈니스 기회로만 보고 접근할 문제가 아니다. 다른 조직에서 다른 우선순위를 가진, 감시할 수 없는 사용자들이 결국 어떤 형태로든 코드를 하이럼의 법칙으로 옭아맬 것이다.
+- 무언가를 릴리즈할지 판단할 때는 장기적인 위험을 반드시 고려야해 한다. 외부에 공개한 의존성은 날이 갈수록 비용이 더 빠르게 증가한다.
+
+## 21.6 마치며
+
+- 현재 의존성 네트워크를 관리하는 업계 표준 방법은 유의적 버전, 즉 SemVer이다. 하지만 변경에 수반되는 위험을 요약해 제공하다 보니 때로는 중요한 내용을 빠뜨린다는 한계가 있다.
+- SemVer는 작은 규모에서는 훌륭히 제 역할을 해낸다. 최소 버전 선택(MVS) 방식까지 수용한다면 더욱 효과적이다. 하지만 의존성 네트워크가 커지면 하이럼의 법칙과 정보를 누락한다는 SemVer 자체의 문제 때문에 버전을 선택하기가 점점 어려워진다.
+- 메인테이너가 추정한 호환성(SemVer 버전 숫자)을 버리고 실제로 확인할 수 있는 증거(영향 받는 다운스트림 패키지들의 테스트 수행)를 십분 활용한다면 이상적인 세계에 한 걸음 다가 설 수 있다. 사용자들이 하던 호환성 테스트를 API 제공자가 더 많이 떠안고 앞으로 어떤 유형의 변경이 이루어질 수 있는지 명확하게 알려준다면 더 거대한 의존성 네트워크도 더 충실하게 관리할 수 있을 것이다.
+
+## 21.7 핵심 정리
+
+- 의존성 관리보다는 되도록 버전 관리가 되도록 한다. 더 많은 코드를 조직 내로 가져와 투명성과 통제력을 높인다면 문제가 훨씬 단순해진다.
+- 소프트웨어 엔지니어링 프로젝트에서 의존성 추가는 공짜가 아니다. 의존성 네트워크에서의 신뢰 관계를 지속하는 문제는 매우 복잡하다. 조직에 의존성을 임포트 할 때는 장기 지원 비용까지 고려해서 신중하게 결정해야 한다.
+- 의존성 역시 하나의 계약이다. 계약에서는 제공자와 소비자 모두 일정한 권리와 의무를 갖는다. 제공자가 제시하는 내용에는 지금 당장뿐 아니라 미래에 대한 약속도 명확하게 포함되어야 한다.
+- SemVer는 변경이 얼마나 위험할지를 사람이 추정하는, 간단하지만 정보가 일부 손실되는 표현법이다. SemVer와 SAT 솔버 방식의 패키지 관리자는 이 추정이 틀릴 리 없다고 가정하고 동작한다. 그 결과 과잉 구속(의존성 지옥)이나 과소 구속(잘 연동되어야 하지만 그렇지 못함)으로 이어진다.
+- 이에 비해 테스트와 CI는 새로운 버전들이 잘 어울려 돌아가는지를 실제로 보여준다.
+- SemVer 기반 패키지 관리에 최소 버전 선택 전략을 가미하면 충실성이 올라간다. 버전업의 위험성을 추정하는 일은 여전히 사람에 의지하지만, API 제공자가 테스트한 구성과 소비자가 사용할 구성이 비슷해질 가능성이 확실히 높아진다.
+- 단위 테스트, 지속적 통합, (저렴한) 컴퓨팅 자원이 의존성 관리를 이해하고 처리하는 방식에 변화를 가져올 수 있다. 이 혁신적인 변화는 의존성 관리 문제와 제공자/소비자가 맡을 책임을 바라보는 업계의 시각이 근본적으로 달라져야 가능하다.
+- 의존성을 제공하는 일 역시 공짜가 아니다. 담벼락 너머로 던지고 잊어버리는 방식은 평판을 떨어뜨리고 호환성 문제를 일으키기 쉽다. 공개한 의존성을 안정성 있게 지원한다면 마음대로 수정하는 게 어려워진다. 심지어 내부 용도와 맞지 않는 방향을 선택하도록 강요받을 수도 있다. 안정성을 포기한다면 선의가 제대로 평가받지 못할 것이다. 하이럼의 법칙 때문에 주요 고객들이 위험에 노출되어 안정성 포기 계획 자체를 강행하기 어려워질 것이다.