요약

  • NuGet.org에서 일반적인 삭제는 목록에서 숨기는 처리다. 정확한 버전을 지정한 다운로드와 복원은 계속 가능하다.
  • 사용 중단 안내와 검색 인기도 이전은 후속 패키지로 가는 길을 보여 준다. 고객 프로젝트의 의존성까지 바꾸지는 않는다.
  • 제품 종료 비용은 고객 전환, 배포 권한 인계, 유지보수 지식 보존에 남는다. 카탈로그 정리를 완료했다고 함께 사라지는 비용이 아니다.

옛 제품의 마지막 회의를 마쳤다. 홍보를 접고 검색 목록에서도 내렸다. 이제 개발자를 새 제품으로 옮길 차례다. 그런데 고객이 프로젝트를 다시 빌드하자 은퇴한 패키지가 멀쩡히 돌아온다. 송별회에 정작 당사자는 참석하지 않은 셈이다.

특정 회사에서 일어난 사건이 아니라 NuGet.org의 운영 규칙을 따라 그려 본 장면이다. 공급업체는 노출을 바꿨고 고객은 이미 쓰던 부품을 요청했다. 시스템은 두 요청을 동시에 처리할 수 있다.

공식 삭제 정책에 따르면 목록에서 내린 패키지도 정확한 버전을 지정하면 내려받거나 설치하고 복원할 수 있다. 버전을 범위로 지정하는 복원에서도 해당 패키지가 조건을 충족하는 최신 버전이면 선택될 수 있다. 카탈로그 복제에도 남는다.NuGet 삭제 정책

공급업체가 없앤 것은 새로운 손님을 끌어오는 간판이다. 기존 고객이 쥐고 있는 부품 번호까지 지워진 것은 아니다. 이 차이는 제품 종료 계획의 비용을 바꾼다. 개발팀을 해산해도 고객의 오래된 의존성은 조직 개편을 읽지 않는다.

삭제라는 말보다 목적지가 중요하다

명령어 이름은 꽤 단호하다. 하지만 nuget delete는 NuGet.org를 대상으로 하면 목록에서 내리고, 로컬 폴더를 대상으로 하면 파일을 삭제한다. 실행 장소에 따라 같은 말이 다른 일을 한다.공식 명령어 설명

구매 담당자가 공급업체의 완료 보고에서 확인할 것도 이 부분이다. 무엇을 어디서 없앴는가. 개발자 컴퓨터의 파일, 공개 검색 결과, 고객 프로젝트의 버전 참조는 각각 다른 대상이다. 앞의 두 가지를 정리했다고 마지막 작업까지 끝나는 것은 아니다.

플랫폼이 오래된 버전을 남기는 이유는 이해하기 쉽다. 어제 만든 프로그램을 오늘 다시 만들 때 어제의 부품이 필요하다. 공급업체의 판매 계획이 바뀔 때마다 그 부품이 사라진다면 재현 가능한 빌드는 약속에 그친다. NuGet은 고객의 연속성을 위해 게시자의 일상적인 삭제 권한을 제한한다.

유해하거나 권리를 침해하는 콘텐츠 등에는 NuGet 팀이 예외적으로 제거하는 절차가 있다. 보통의 제품 정리는 그와 별개다. 수익성이 낮다는 이유만으로 고객의 이전 일정까지 공급업체가 결정할 수 있는 구조는 아니다.

공지문은 고객의 작업표에 자동 등록되지 않는다

NuGet의 사용 중단 안내에는 이유와 대체 패키지 또는 버전을 넣을 수 있다. 목록에서 내리는 조치와 독립적이어서 둘을 함께 적용할 수도 있다. 다만 직접 쓴 안내 문구는 NuGet.org 웹사이트에 표시되며 클라이언트에 그대로 전달되지 않는다.사용 중단과 인기도 이전 규칙

지원되는 Visual Studio에서는 설치된 패키지 화면에서 관련 정보를 볼 수 있고, dotnet 명령으로 사용 중단된 의존성을 조회할 수 있다. 결국 누군가 그 화면을 보거나 조회를 실행해야 한다. 기존 복원 절차가 계속 성공한다면 고객팀은 자기 일정표에 적힌 일을 먼저 한다.

그래서 공지의 품질과 이전의 성과를 따로 봐야 한다. 대체품을 고르고, 변경 범위를 파악하고, 테스트 시간을 확보하는 데는 사람의 시간이 든다. 공급업체가 설명에 쓰지 않은 시간을 고객이 조사에 쓰고, 나중에는 고객지원팀이 같은 질문에 답하며 다시 쓸 수 있다.

보낸 이메일 수를 세면 일이 많이 진행된 것처럼 보인다. 고객 코드에서 무엇이 바뀌었는지 세면 아직 남은 일이 드러난다. 제품을 끝내려는 기업에 필요한 숫자는 후자다.

검색의 인기는 상속해도 설치 기반은 따라오지 않는다

NuGet은 예전 패키지의 내부 인기도 점수를 새 패키지로 옮기는 신청을 받는다. 승인되면 후속 패키지는 검색 순위에서 과거의 축적을 활용할 수 있다. 실제 다운로드 수는 변하지 않고, 고객 프로젝트의 참조 역시 자동 수정되지 않는다.

신청에는 조건이 따른다. 모든 소유자가 같아야 하고 이름이나 기능의 관계가 분명해야 한다. 옛 버전들은 대체품을 지정해 사용 중단 상태로 표시해야 하며 후속 패키지에는 안정 버전이 있어야 한다. 검색에 혼란을 주어서도 안 된다. 한 패키지의 점수는 최대 다섯 개로 나눌 수 있지만 균등 배분된다. 이미 다른 패키지의 점수를 받은 패키지가 다시 전달하는 연쇄 이전은 허용되지 않는다.

제품을 여러 모듈로 쪼개려는 회사에는 이 균등 배분이 특히 현실적이다. 기술팀은 기능에 따라 경계를 긋지만, 검색에서 이어받을 평판의 몫은 플랫폼 규칙이 정한다. 매출 계획에서 가장 중요한 모듈이라고 더 큰 몫이 배정되는 것은 아니다.

인수 검토에서도 구분이 필요하다. 패키지 이름을 확보하는 일, 검색에서 잘 발견되는 일, 기존 사용자가 후속 제품으로 옮겨 오는 일은 별개의 과제다. 이를 모두 확보한 고객 기반이라는 한 항목으로 적으면 아직 수행하지 않은 일을 자산처럼 평가하게 된다.

저자 이름과 배포 열쇠는 다르다

NuGet.org는 패키지 소유자에게 게시와 소유자 관리 권한을 준다. 패키지 메타데이터의 저자 표시는 이 권한을 결정하지 않는다. 새로운 소유자를 추가하고 상대가 초대를 수락한 뒤, 필요하면 이전 소유자를 제거하는 방식으로 인계할 수 있다. 초대장을 보낸 상태만으로 열쇠가 넘어간 것은 아니다.게시 및 소유자 관리

문서를 넘기고 팀 이름을 바꿔도 실제 배포 권한이 옛 담당자에게 남으면 다음 수정 때 다시 그 사람을 찾아야 한다. 권한만 넘기고 호환성 지식을 버리면 고객의 이전 테스트가 막혔을 때 비슷한 일이 벌어진다.

특정 업체의 남은 비용을 계산하려면 고객이 쓰는 버전, 지원 약정, 완료된 전환 기록이 필요하다. 공식 정책은 그 회사의 고객 수나 유지비를 알려 주지 않는다. 자료가 모이면 어떤 고객에게 도움을 집중하고 어떤 지식을 더 남겨야 할지 결정할 수 있다.

오래된 패키지가 계속 제공되는 것은 고객에게는 보험 같은 연속성이다. 공급업체에게는 아직 회수하지 못한 작업 목록이다. 둘을 한 장의 종료 공지로 정리하려 하면 비용은 없어지지 않고 담당자만 잃는다.