<div id="readability-page-1" class="page"><div>
					Python 웹프레임워크인 Flask를 만든 <a href="https://lucumr.pocoo.org/about/">Armin Ronacher</a>가 최근 faker.js와 colors.js에서 발생한 문제를 보면서 오픈소스 의존성에 대한 글 <a href="https://lucumr.pocoo.org/2022/1/10/dependency-risk-and-funding/">Dependency Risk and Funding</a>을 적어서 나도 생각을 정리할 겸 번역을 해보았다. Armin의 블로그에 명시된 크리에이티브 커먼즈 attribution-noncommercial-sharealike 라이센스에 따라 번역했고 라이센스에 따라 이 글도 <a href="https://creativecommons.org/licenses/by-nc-sa/2.0/kr/">저작자표시-비영리-동일조건변경허락</a> 라이센스를 따릅니다.



<h2><a href="https://lucumr.pocoo.org/2022/1/10/dependency-risk-and-funding/">의존성 위험성과 펀딩</a></h2>

written by Armin Ronacher

저는 의존성과 애증의 관계에 있습니다. 이에 관해 블로그에 많이 작성했습니다. 한번은 <a href="https://lucumr.pocoo.org/2019/7/29/dependency-scaling/">의존성에서 신뢰 확장</a>에 관한 도전에 대해, 그 이전에는 <a href="https://lucumr.pocoo.org/2016/3/24/open-source-trust-scaling/">마이크로 의존성에 관한 문제</a>에 관해 썼습니다. 놀랍지 않게도 지난 5년 동안 개선된 것은 전혀 없습니다. 사실 저는 문제가 더 심각해졌다고 생각합니다. 몇 년 전만 해도 여기서 가장 큰 두려움은 유명한 개발자가 표적이 되는 것이었지만 이제 의존성 논의는 펀딩과 지속 가능성에 대한 논의 겹치고 합쳐졌습니다.

모두가 <a href="https://xkcd.com/2347/">XKCD의 의존성</a>을 기억할 것입니다.

<img src="https://blog.outsider.ne.kr/attach/1/x2426285862.png.pagespeed.ic.GZSF6yrooT.png" width="385" height="489" alt="#2347: Dependency" title="" data-pagespeed-url-hash="169037653" data-pagespeed-onload="pagespeed.CriticalImages.checkImageForCriticality(this);" onload="var elem=this;if (this==window) elem=document.body;elem.setAttribute('data-pagespeed-loaded', 1)">

Comic by XKCD, <a href="https://xkcd.com/2347/">#2347: Dependency</a>. <a href="https://creativecommons.org/licenses/by-nc/2.5/">CC BY-NC 2.5</a>

이 만화가 좋은 점은 머릿속의 여러 프로젝트를 이 만화에 넣을 수 있다는 점입니다. 언급한 프로젝트가 <a href="https://curl.se/">curl</a>이라고 상상해 보겠습니다. curl은 20년 이상 동안 한 명의 사람 Daniel Stenberg에 의해 주로 유지 보수되었습니다. curl은 실제 중요한 의존성의 좋은 예입니다. 이런 의존성은 어디에나 있습니다. 이를 게임 콘솔, 자동차, MP3 플레이어, 스마트 스피커, 블루레이 플레이어, 임베디드 기기, 커맨드라인 유틸리티, 백엔드 서버에서 본 적이 있습니다. 이는 엄청나게 유용한 소프트웨어일 뿐만 아니라 어려운 문제도 해결하고 있습니다. 또한 작은 의존성조차도 아닙니다. curl은 유용한 기능의 전체 패키지입니다. curl이 존재하지 않는다면 우리 사회에 분명히 좋지 않을 것입니다.

하지만 curl이 어떻게 사라질 수 있을까요? curl은 가장 중요한 의존성 중 하나일 뿐 아니라 가장 회복력 있는 의존성 중 하나입니다. 저나 당신이나 curl을 설치할 때 공식 웹사이트에서는 거의 설치하지 않습니다. curl은 우리가 사용하는 라이브러리에서 공급되는 미러에서 설치했을 가능성이 높고 소유권이 있는 코드 베이스에 수많은 포크가 있습니다. Curl은 죽일 수 없는 의존성입니다. 웹사이트가 다운될 수 있을 뿐만 아니라 원래의 개발자가 떠날 수도 있고 누군가 작업을 가져갈 수 있습니다. 그럼에도 유용합니다.

이를 npm의 상황과 잠시 비교해 보겠습니다. 라이브러리에서 가장 의존적인 것 중 하나는 사실 <a href="https://www.npmjs.com/package/colors">colors</a>입니다. colors는 색상화를 위해 ANSI 코드를 효과적으로 내보내는 라이브러리입니다. 유용한 기능인 것은 확실하지만 세상을 뒤흔들만한 것은 아닙니다. 비난받을 수도 있지만 이러한 종류의 기능은 의존하는 대신 직접 구현하는 경우가 더 많다고 말하고 싶습니다. 예를 들어 제가 <a href="https://click.palletsprojects.com/">click</a>을 작성할 때 의도적으로 무언가에 의존하지 않고 제 라이브러리에서 바로 ASNI 색상화를 구현하기로 했습니다. 제 직감은 해당 라이브러리를 뜯어내고 교체하는데 시간이 오래 걸리지 않을 것이라고 말했습니다.

며칠 전 해당 라이브러리의 개발자는 기존에 홍보한 기능을 더는 수행하지 않는 새로운 버전을 릴리스하기로 했습니다. 마이너 업데이트였기 때문에 아주 적은 수의 사람만 해당 버전의 영향을 받았습니다. 하지만 그들은 "그 하나의 패키지"에 의존하고 있다는 사실조차 몰랐습니다. 아마도 의존성 체인의 무언가가 그 패키지가 필요했기 때문에 다운로드받았을 것입니다.

해당 개발자의 GitHub 저장소에 가면 두 가지를 발견할 수 있습니다. 저장소의 readme에 약간 음모론적인 내용과 이 라이브러리가 왜 원래 하기로 했던 일을 하지 않는지에 대한 정당화입니다. 이 개발자는 이 라이브러리의 코드를 무료로 사용하는 "포춘 500" 기업에 불만이 있었기에 1억 원 상당의 계약을 하거나 포크하도록 요청했습니다.

사람들이 이러한 문제에 관해 실제로 논의했으면 하는 것은 npm(및 다른 패키지 매니저)이 놀라운 수단으로 발전되었다는 것입니다. 다수가 의존하는 패키지를 가진 누군가는 쉽게 모든 현대 디지털 인프라스트럭처의 일부를 쉽게 무너뜨릴 수 있습니다. curl의 Daniel Stenberg는 그 힘을 휘두르지 않습니다.(그리고 아마 그렇게 하고 싶지도 않을 것입니다)

의존성이 제기하는 위험은 파악되지 않은 한 명의 개발자가 작성한 작지만, 더 일반적으로 사용하는 의존성을 npm, cargo, pypi 등과 같은 패키지 매니저를 통해 설치되었을 때 더 높습니다. 하지만 무언가 잘못되었을 때 모두가 바로 알아차리고 사람들은 펀딩을 빠르게 요청합니다. 하지만 이는 우리 경제를 실제로 지원하는 의존성이 아닙니다. 이러한 의존성의 다수는 기본적인 것이 되었는데 이들이 어려운 문제를 해결했기 때문이 아니라 우리가 집단으로 다른 모든 것보다 게으름을 받아들이기 시작했기 때문입니다. 그다음 이러한 종류의 의존성에 대한 펀딩 논의에 집중하게 되면 암시적으로 실제로 중요한 패키지에 집중하지 못하게 됩니다.

GitHub이 스폰서와 함께 하는 것에 감사하고 멋진 아이디어라고 생각합니다. 또한 GitHub이 이슈가 있는 오픈소스에 펀딩하는데 손가락을 대는 것에 감사하지만 안타깝게도 여기에는 어두운 면이 있습니다. 손가락은 쉬운 곳을 가리킵니다. npm처럼 GitHub은 컴퓨터가 쉽게 설명한 수 있는 것을 손가락으로 가리킵니다. <a href="https://github.blog/2021-04-19-open-source-goes-to-mars/">내 코드는 화성에 갔습니다</a>. 이는 엄청납니다. 하지만 내 GitHub 프로필에 붙은 이 영광의 배지는 Python 의존성 목록을 크롤링했기 때문에 받은 것입니다. 내 배지와 함께 lxml을 만든 사람들은 배지를 받았습니다. 하지만 기본 libxml2 라이브러리를 유지보수하는 Daniel Veillard는 이러한 배지를 받지 못했습니다. 사실 많은 사람은 libxml2가 존재한다는 것조차 혹은 사용하고 있다는 것을 잊어버렸을 것입니다. 왜냐하면 libxml2는 libxml2를 감추는 훨씬 더 고급스러운 고수준 퍼사드에 숨겨져 있기 때문입니다. npm 패키지와는 달리 lxml을 설치할 때 어딘가에 libxml2를 다운로드하지 않습니다. curl처럼 libxml2는 수단이나 가시성을 가지고 있지 않습니다. 하지만 라이브러리에 투입된 작업량과 헌신은 상당합니다. 그리고 Daniel은 우리가 아직 사용 중인 놀라운 라이브러리를 만든 수천 명의 개발자 중 한 명일 뿐입니다.

확실히 우리는 오픈소스 프로젝트의 펀딩 문제를 해결해야 하고 GitHub 스폰서가 있다는 것은 좋습니다. 하지만 얼마나 많은 사람이 npm이나 다른 패키지 매니저에 의존하는지보다 라이브러리의 영향을 평가하는 더 나은 방법을 찾아야 한다고 생각합니다. 왜냐하면 이는 전체 그림이 아니기 때문입니다.

 </div></div>

Outsider's Dev Story

Outsider

Python 웹프레임워크인 Flask를 만든 Armin Ronacher가 최근 faker.js와 colors.js에서 발생한 문제를 보면서 오픈소스 의존성에 대한 글 Dependency Risk and Funding을 적어서 나도 생각을 정리할 겸 번역을 해보았다. Armin의 블로그에 명시된 크리에이티브 커먼즈 attribution-noncommercial-sharealike 라이센스에 따라 번역했고 라이센스에 따라 이 글도 저작자표시-비영리-동일조건변경허락 라이센스를 따릅니다.
faker.js와 colors.js에서 벌어진 일이 궁금하면 Twiiter에서 Amy님이 정리한 글에서 처음 faker.js를 없애면서 발생한 상황을 알 수 있다. 더 자세한 내용은 snyk에서 정리한 Open source maintainer pulls the plug on npm packages colors and faker, now what?에서 볼 수 있다.
의존성 위험성과 펀딩
written by Armin Ronacher
저는 의존성과 애증의 관계에 있습니다. 이에 관해 블로그에 많이 작성했습니다. 한번은 의존성에서 신뢰 확장에 관한 도전에 대해, 그 이전에는 마이크로 의존성에 관한 문제에 관해 썼습니다. 놀랍지 않게도 지난 5년 동안 개선된 것은 전혀 없습니다. 사실 저는 문제가 더 심각해졌다고 생각합니다. 몇 년 전만 해도 여기서 가장 큰 두려움은 유명한 개발자가 표적이 되는 것이었지만 이제 의존성 논의는 펀딩과 지속 가능성에 대한 논의 겹치고 합쳐졌습니다.
모두가 XKCD의 의존성을 기억할 것입니다.
Comic by XKCD, #2347: Dependency. CC BY-NC 2.5
이 만화가 좋은 점은 머릿속의 여러 프로젝트를 이 만화에 넣을 수 있다는 점입니다. 언급한 프로젝트가 curl이라고 상상해 보겠습니다. curl은 20년 이상 동안 한 명의 사람 Daniel Stenberg에 의해 주로 유지 보수되었습니다. curl은 실제 중요한 의존성의 좋은 예입니다. 이런 의존성은 어디에나 있습니다. 이를 게임 콘솔, 자동차, MP3 플레이어, 스마트 스피커, 블루레이 플레이어, 임베디드 기기, 커맨드라인 유틸리티, 백엔드 서버에서 본 적이 있습니다. 이는 엄청나게 유용한 소프트웨어일 뿐만 아니라 어려운 문제도 해결하고 있습니다. 또한 작은 의존성조차도 아닙니다. curl은 유용한 기능의 전체 패키지입니다. curl이 존재하지 않는다면 우리 사회에 분명히 좋지 않을 것입니다.
하지만 curl이 어떻게 사라질 수 있을까요? curl은 가장 중요한 의존성 중 하나일 뿐 아니라 가장 회복력 있는 의존성 중 하나입니다. 저나 당신이나 curl을 설치할 때 공식 웹사이트에서는 거의 설치하지 않습니다. curl은 우리가 사용하는 라이브러리에서 공급되는 미러에서 설치했을 가능성이 높고 소유권이 있는 코드 베이스에 수많은 포크가 있습니다. Curl은 죽일 수 없는 의존성입니다. 웹사이트가 다운될 수 있을 뿐만 아니라 원래의 개발자가 떠날 수도 있고 누군가 작업을 가져갈 수 있습니다. 그럼에도 유용합니다.
이를 npm의 상황과 잠시 비교해 보겠습니다. 라이브러리에서 가장 의존적인 것 중 하나는 사실 colors입니다. colors는 색상화를 위해 ANSI 코드를 효과적으로 내보내는 라이브러리입니다. 유용한 기능인 것은 확실하지만 세상을 뒤흔들만한 것은 아닙니다. 비난받을 수도 있지만 이러한 종류의 기능은 의존하는 대신 직접 구현하는 경우가 더 많다고 말하고 싶습니다. 예를 들어 제가 click을 작성할 때 의도적으로 무언가에 의존하지 않고 제 라이브러리에서 바로 ASNI 색상화를 구현하기로 했습니다. 제 직감은 해당 라이브러리를 뜯어내고 교체하는데 시간이 오래 걸리지 않을 것이라고 말했습니다.
며칠 전 해당 라이브러리의 개발자는 기존에 홍보한 기능을 더는 수행하지 않는 새로운 버전을 릴리스하기로 했습니다. 마이너 업데이트였기 때문에 아주 적은 수의 사람만 해당 버전의 영향을 받았습니다. 하지만 그들은 "그 하나의 패키지"에 의존하고 있다는 사실조차 몰랐습니다. 아마도 의존성 체인의 무언가가 그 패키지가 필요했기 때문에 다운로드받았을 것입니다.
해당 개발자의 GitHub 저장소에 가면 두 가지를 발견할 수 있습니다. 저장소의 readme에 약간 음모론적인 내용과 이 라이브러리가 왜 원래 하기로 했던 일을 하지 않는지에 대한 정당화입니다. 이 개발자는 이 라이브러리의 코드를 무료로 사용하는 "포춘 500" 기업에 불만이 있었기에 1억 원 상당의 계약을 하거나 포크하도록 요청했습니다.
사람들이 이러한 문제에 관해 실제로 논의했으면 하는 것은 npm(및 다른 패키지 매니저)이 놀라운 수단으로 발전되었다는 것입니다. 다수가 의존하는 패키지를 가진 누군가는 쉽게 모든 현대 디지털 인프라스트럭처의 일부를 쉽게 무너뜨릴 수 있습니다. curl의 Daniel Stenberg는 그 힘을 휘두르지 않습니다.(그리고 아마 그렇게 하고 싶지도 않을 것입니다)
의존성이 제기하는 위험은 파악되지 않은 한 명의 개발자가 작성한 작지만, 더 일반적으로 사용하는 의존성을 npm, cargo, pypi 등과 같은 패키지 매니저를 통해 설치되었을 때 더 높습니다. 하지만 무언가 잘못되었을 때 모두가 바로 알아차리고 사람들은 펀딩을 빠르게 요청합니다. 하지만 이는 우리 경제를 실제로 지원하는 의존성이 아닙니다. 이러한 의존성의 다수는 기본적인 것이 되었는데 이들이 어려운 문제를 해결했기 때문이 아니라 우리가 집단으로 다른 모든 것보다 게으름을 받아들이기 시작했기 때문입니다. 그다음 이러한 종류의 의존성에 대한 펀딩 논의에 집중하게 되면 암시적으로 실제로 중요한 패키지에 집중하지 못하게 됩니다.
GitHub이 스폰서와 함께 하는 것에 감사하고 멋진 아이디어라고 생각합니다. 또한 GitHub이 이슈가 있는 오픈소스에 펀딩하는데 손가락을 대는 것에 감사하지만 안타깝게도 여기에는 어두운 면이 있습니다. 손가락은 쉬운 곳을 가리킵니다. npm처럼 GitHub은 컴퓨터가 쉽게 설명한 수 있는 것을 손가락으로 가리킵니다. 내 코드는 화성에 갔습니다. 이는 엄청납니다. 하지만 내 GitHub 프로필에 붙은 이 영광의 배지는 Python 의존성 목록을 크롤링했기 때문에 받은 것입니다. 내 배지와 함께 lxml을 만든 사람들은 배지를 받았습니다. 하지만 기본 libxml2 라이브러리를 유지보수하는 Daniel Veillard는 이러한 배지를 받지 못했습니다. 사실 많은 사람은 libxml2가 존재한다는 것조차 혹은 사용하고 있다는 것을 잊어버렸을 것입니다. 왜냐하면 libxml2는 libxml2를 감추는 훨씬 더 고급스러운 고수준 퍼사드에 숨겨져 있기 때문입니다. npm 패키지와는 달리 lxml을 설치할 때 어딘가에 libxml2를 다운로드하지 않습니다. curl처럼 libxml2는 수단이나 가시성을 가지고 있지 않습니다. 하지만 라이브러리에 투입된 작업량과 헌신은 상당합니다. 그리고 Daniel은 우리가 아직 사용 중인 놀라운 라이브러리를 만든 수천 명의 개발자 중 한 명일 뿐입니다.
확실히 우리는 오픈소스 프로젝트의 펀딩 문제를 해결해야 하고 GitHub 스폰서가 있다는 것은 좋습니다. 하지만 얼마나 많은 사람이 npm이나 다른 패키지 매니저에 의존하는지보다 라이브러리의 영향을 평가하는 더 나은 방법을 찾아야 한다고 생각합니다. 왜냐하면 이는 전체 그림이 아니기 때문입니다.
댓글 쓰기