두줄짜리 라이브러리는 필요한가

들어가며

is-promise 의 ES6 modules 지원을 위한 export 설정을 변경하여 이를 사용하던 react-create-app 등 700개가 넘는 라이브러리가 빌드가 실패하는 일이 발생했다.

변경사항은 다음과 같다 https://github.com/then/is-promise/compare/2.2.1…2.2.2

거의 5년만에 이루어진 업데이트에서 의존하고 있던 프로젝트들이 빌드가 실패한다는 레포팅을 받자 패치를 내놓지만 수정에 실패하고, 결국 Breaking Changes를 알리며 메이저 버전을 업데이트 한다.

이 사건은 사람들로 하여금, 두 줄의 라이브러리를 위해 디펜던시 그래프를 만드는게 맞는가? 하는 성토의 장을 열게 된다. 그중 몇가지 인상깊었던 코멘트들과 개인적인 생각을 남겨두려 한다.

이번 일은 두줄짜리 라이브러리를 사용해서 생긴 일이 아니다.

두줄짜리 라이브러리를 사용해서 생긴 일이 아닌, 라이브러리를 배포함에 있어 충분한 테스트를 거치지 않은것이 문제이고 이로 인해 쉽게 깨져버린 자바스크립트 패키지 에코시스템의 문제라고 얘기한다.

https://github.com/then/is-promise/issues/17#issuecomment-620600431

만약 이 라이브리러리의 메인테이너가 더 큰 규모의 라이브러리의 메인테이너였다면, 동일한 패키징 에러를 일으켰을 것이다.

https://github.com/then/is-promise/issues/17#issuecomment-620638655

어느정도 동의한다. 작은 규모의 라이브러리를 사용하지 않고, 큰 규모의 라이브러리를 사용한다고 하더라도 그러한 큰 규모의 라이브버리에서 똑같은 일이 발생하지 않을 것이라는 보장은 없다. 다만, 작은 기능을 위해 더 많은 라이브러리의 의존할수록 확률은 높아지고 이러한 경우에 취약해진다 생각한다.

결국은 트레이드오프

작은 기능을 위한 의존하는 라이브러리가 많아질수록, 이런 리스크를 안고 가야하는건 자명하다. 하지만 개인적으로는 이러한 리스크를 감당하더라도 그리고 고작 두줄이더라도 라이브러리를 사용하는 편이 가져다 주는 이점이 더 많다고 생각한다.

이 의견에 전적으로 동감하는데, 요약하자면 다음과 같다.

• 모듈이 한줄이든, 수백줄이든 상관없다. 복잡성을 숨기고 추상화하는데 의미가 있다. 개발자는 해당 구현에 자세한 내용을 알 필요가 없어진다.
• is-promise는 주어진 객체나 함수가 promise처럼 다루어질 수 있는지 체크한다. “promise처럼 다루어질 수 있는지” 에 대한 스펙은 예상과는 조금 다르게 되어 있다. 표준에 promise가 추가되기전 promise 구현체들에 대한 호환성을 유지하기 위해서 그렇단다.
• 하지만 이 두줄의 라이브러리를 사용함으로써, 우리는 “그래서 스펙에서 요구하는 promise로 다루어 질 수 있는지가 뭔데?”에 대해서 신경쓰지 않아도, 자세히 알지 못해도 된다.
• 또한 공유의 가치를 믿는다. 공개되고 많은 사람들이 사용하고, 기여하며 다양한 케이스에 대응할 수 있는 견고한 코드가 된다고 믿는다.

결국 장점과 단점을 잘 저울질해서 결정하면 되는 문제이다. 정답은 없다.

이러한 사고는 일어날 수 밖에 없다.

위의 코멘트에서 이 부분이 제일 인상깊었다.

Accidents happen. It happens quite¹ often^{2</sup?. It’s a part of software development. It’s a part of any engineering field.}

Complaining helps nothing.

그래서 우리는 이러한 사고에도 영향을 덜 받기 위한 노력을 해야한다. 위 코멘트를 작성한 Qix-는 다음과 같은 방법을 권한다.

• .npmrc에 save-exact=true을 주어서 의존하는 패키지들의 버전을 고정한다.
• lockfiles 를 사용하지 않는다. 이는 많은 논쟁의 여지가 있지만, 의존성을 고정시키는데 유용하다.
• 패키지 저장소의 mirror를 구축하여 사용한다.

마치며

그 대상이 두줄이든, 수백줄이든 기능을 모듈화하는건 유용하다. 코드의 재사용성을 높일 수 있으며, 복잡한 내용을 추상화하여 코드를 개발자로 하여금 자세한 구현내용에 신경쓰지 않을 수 있도록 해준다. 즉, 이 코드가 ‘어떻게’가 아닌 ‘무엇을’ 하는지에 대해서만 집중할 수 있게 한다. 표현력이 높아진다.

작은 기능을 위해 라이브러리를 활용하는것도 유용하다. 물론 의존하는 라이브러리가 많아짐에 따라, 이번처럼 사고의 여파에 휘말릴 리스크는 증가한다. 하지만 공유의 가치가 더 크다고 생각한다. 여러 개발자들이 사용하고, 기여함으로써 라이브러리는 내가 생각치 못한 여러 엣지 케이스도 대응 가능한 탄탄한 블럭으로 발전한다.

소프트웨어 개발에 있어, 사고는 언제나 일어날 수 밖에 없는 요소이다. 우리가 해야 할 일은 이 사실을 인정하고, 우리가 할 수 있는 일들을 하는것이다.

Written on May 18th, 2020 by genie-youn