2024. 8. 12. 07:50ㆍUX Engineer 이야기
들어가며
저는 프런트엔드 개발을 하며 종종 mock 데이터가 필요해 손쉽게 mock 데이터를 만들어주는 faker.js라는 오픈소스 라이브러리를 즐겨 사용합니다.
이 faker.js를 사용하면 각종 프로젝트를 진행하면서 필요한 이름, 이메일, 회사명, 주소, 랜덤 한 이미지 등 원하는 형태의 데이터를 손쉽게 생성할 수 있었기에 Api가 준비되지 않은 상태에서도 개발과, 테스트를 진행할 수 있고, 최근에도 종종 요긴하게 잘 사용하고 있습니다. 그런데 이 faker.js라는 라이브러리로 인해 수많은 기업들과 인터넷 커뮤니티가 난리가 났던 적이 있습니다. 바로 2021년 말 발생한 faker.js와 colors.js 사태인데요.
이 사태를 통해 당시 해당 라이브러리를 사용하던 여러 기업들과 사용자들은 큰 혼란에 빠졌으며, 각종 JavaScript 커뮤니티에 이 사건으로 인해 오픈 소스 소프트웨어와 그 유지 관리에 대한 중요한 논의가 시작되었습니다.
이번 포스트에서는 faker.js와 colors.js 사태를 통해 오픈소스의 양면성과 개발자로서 오픈소스를 보다 잘 활용하기 위해서 생각해봐야 할 부분에 대해 알아보고자 합니다.
faker.js와 colors.js?
faker.js
faker.js는 위에서 이미 간단하게 이야기한 것처럼 개발자들이 mock 데이터를 손쉽게 생성하기 위해 도와주는 유용한 JavaScript 라이브러리입니다. 이 라이브러리는 테스트를 위한 데이터, 데이터 시각화 등 다양한 목적으로 활용될 수 있으며, 라이브러리의 API 제공을 통해 프로젝트에 필요한 이름, 이메일, 회사명, 주소, 랜덤 한 이미지, 날짜, 시간, UUID 등 다양한 유형의 mock 데이터를 쉽게 생성할 수 있습니다.
colors.js
colors.js는 Node.js에서 로그 및 텍스트의 콘솔 출력에 다양한 색상을 추가하는 기능을 제공해 아주 널리 사용되던 라이브러리입니다.
그럼 대체 기능과 역할만 살펴보았을 때 유용하기만 할 것 같은 이 두 오픈소스 라이브러리에 무슨 일이 있었던 것일까요?
faker.js와 colors.js 사태
Marak Squires라는 개발자가 만든 오픈소스 라이브러리인 faker.js와 colors.js를 의도적으로 훼손한 사건으로
faker.js는 GitHub 레포에서 모든 코드를 삭제하고 버전을 업데이트했으며,
colors.js의 최신 버전에는 무한 루프 코드와 "LIBERTY! LIBERTY! LIBERTY!”라는 단어가 출력되는 코드를 의도적으로 추가해 해당 라이브러리들을 사용하는 수천 개의 프로젝트들에 문제가 발생되도록 일종의 테러를 감행한 사건입니다.
이후 해당 사태는 colors.js의 문제가 되는 버전은 npm에서 삭제되었고,
또한 GitHub에서는 해당 사건의 주동자인 Marak Squires의 GitHub 계정을 중단시키면서 일단락되었습니다.(이후 해당 계정을 다시 복원하는 결정을 내렸다고 합니다.)
이렇듯 faker.js와 colors.js 사태는 한 명의 오픈소스 개발자에 의해 수많은 기업과 수많은 사용자들이 피해를 입었던 사건입니다.
해당 사태의 가장 큰 이유는 Marak Squires 개인의 경제적 문제에 대한 불만이 가장 크게 작용했다고 알려져 있으며, 대기업들이 자기가 개발한 라이브러리를 사용하면서도 경제적으로 어려워진 본인에게 금전적 지원이 없자 홧김에 이런 일을 저질렀다고 밝혀져 있습니다.
오픈소스의 양면성
오픈소스는 오늘날 소프트웨어 개발에서 필수적인 부분으로 자리 잡고 있습니다.
오픈소스를 잘 사용할 수 있다면 보다 빠른 개발을 통해 시간 절약과 비용 절감 등의 효과를 얻을 수 있겠지만 위의 faker.js와 colors.js 사태를 통해 보듯 프로젝트의 중대한 문제로 이어질 수 있습니다.
오픈소스 라이브러리의 양면성에 대해 조금 더 살펴보면
장점
1. 비용 절감: 대부분의 오픈소스는 무료로 사용할 수 있어 개발 비용을 절감할 수 있음.
2. 확장성: 오픈 소스 코드에 접근할 수 있어 필요에 따라 수정하거나 확장하는 것이 가능.
3. 시간과 속도: 전 세계 개발자들의 기여로 새로운 기능이 빠르게 추가되고, 버그가 신속하게 수정되며, 이미 구현된 오픈소스를 개발에 사용함으로써 시간적으로 많은 부분을 단축할 수 있음.
4. 커뮤니티 지원: 오픈소스와 관련한 커뮤니티가 존재한다면 문제 해결에 도움을 받거나 지식을 공유할 수 있음.
단점
1. 보안에 취약: 소스 코드가 공개되어 있어 취약점이 악용될 가능성이 있음.
2. 유지관리 문제: 프로젝트의 주 개발자가 지원을 중단하거나, colors.js와 faker.js 사태처럼 악의를 가지고 오픈소스를 훼손한다면 문제가 발생할 수 있음.
3. 라이선스 문제: 오픈소스 라이브러리의 라이선스를 잘못 이해하거나 준수하지 않을 경우 법적 문제가 발생할 수 있음.
4. 호환성 문제: 다양한 오픈소스 라이브러리를 함께 사용할 때 의존성 충돌이나 호환성 문제가 발생할 수 있습니다.
마치며
colors.js와 faker.js 사태와 위에 정리한 내용을 통해 보듯 항상 개발자에게 유용하게만 사용될 것 같은 오픈소스들도 분명 문제점을 가지고 있습니다.
이에 따라 오픈소스를 사용하기에 앞서 유의할 점에 대한 개인적인 생각을 정리해 보겠습니다.
첫째 새 패키지들을 설치 또는 의존성을 관리할 때 무조건 최신 버전을 선호하는 것이 아니라 (‘^’, ‘~’ 사용은 지양) 실제로 테스트해 보았거나, 안전성이 입증된 버전을 선택하여 사용하는 것이 좋겠습니다.
둘째 사용 중인 혹은 사용 예정인 오픈소스 프로젝트의 커뮤니티에 참여 또는 주기적인 확인을 통해 보안 취약점, 이슈들을 주기적으로 확인하고 상황에 맞는 업데이트를 적용해야 한다고 생각합니다.
셋째 개발을 하다 보면 자주 사용해서 이미 익숙한 라이브러리들을 다음번에도 다시 찾아 사용하게 됩니다. 이렇게 매번 사용하던 라이브러리만을 고집한다면 해당 라이브러리에 이슈가 생겼을 때 빠르게 대응할 수 없을 겁니다. 이에 따라 자주 사용하는 라이브러리에 대한 대체 라이브러리도 한 가지쯤은 생각하고 프로젝트를 진행한다면 라이브러리 이슈에도 빠르게 대응할 수 있을 거라 생각됩니다.
마지막으로 대부분의 오픈소스 개발자들은 그들의 무수히 많은 커밋과 노력에 대한 대가를 원하고 오픈소스를 개발하지 않습니다. 하지만 내가 매번 유용하게 사용하고 있는 오픈소스 라이브러리가 있다면 고생한 개발자들을 위해 커피 한 잔 정도 donation 해보는 건 어떨까요? 또는 더 나아가 해당 오픈소스 프로젝트에 기여자로 참여해 무엇인가를 개선해 보는 것도 아주 좋은 방법이라고 생각됩니다.
이외에도 생각해 봐야 할 포인트들이 무수히 존재하겠지만 위 내용들만 다시 한번 생각해 보며 개발을 해도 훨씬 더 유용하게 오픈소스들을 사용하며 개발을 할 수 있을 것이라 생각합니다.
긴 글 읽어주셔서 감사드리며, 추후에 기회가 된다면 이번 포스트의 내용과 연관하여 오픈소스 라이브러리의 라이선스에 대해 정리한 포스트도 준비해 보도록 하겠습니다.
감사합니다.
이 글은 pxd XE Group Blog에서도 보실 수 있습니다.