왜 node_modules를 커밋해야 하는가?

MoonCha, 2020-03-18

일반적인 개발 상식과 달랐던 것들

실제로 개발을 하다보면 일반적인 개발 상식이나 컴퓨터 공학적 지식에 반대되는 방향으로 처리되는 것들이 있었다.

대표적으로 Relational DB 디자인이 있을 수 있는데, DB 수업때는 Consistency 등의 이유로 Normalization을 해야 하는 것으로 배우지만,

실제로는 퍼포먼스를 이유로 Join을 피하기 위해 중복 저장을 허용한다던지, 한 Column에 많은 정보를 뭉텅이로 넣는다던지 그런 것들이 있을 수 있을 것 같다.

이제 보니 이런 사용 경향이 No SQL DB가 나온 이유중 하나던가? 아무튼.

node_modules의 경우

마찬가지로 일반적으로는 Node JS에서 코드를 작성할 때, node_modules를 repo에 커밋하지 않는 것이 일반적인 상식인 것으로 보인다.

하지만, 내가 다녔던 회사에서는 node_modules 전체를 repo에 커밋하여 사용했다.

처음 막 들어 왔을때는 그닥 신경쓰지 않았고, 일을 하면서 경험을 통해 node_modules를 커밋해야 하는 이유에 대해서 알게 되긴 했지만 굳이 그 이유에 대해 설명할 상황은 없었기에 머릿속에 제대로 정리가 되어 있지는 않았다.

그런데, 회사가 합쳐지면서 기존의 코드를 포크하여 다른 팀에서 사용하는 일이 있었는데, 그 때 왜 node_modules를 커밋해놓았냐는 질문을 받았던 것으로 기억한다.

그 당시에는 인식하고 있던대로 어떻게든 대답했는데, 지금 생각해보니 정리해두어도 나쁘지 않은 내용인 것 같다.

먼저, node_modules를 커밋하지 않아야 하는 이유를 간단히 말하면

package.json 및 package-lock.json에 명시된 dependencies들을 다시 다운받아 node_modules를 재구성할 수 있다.

라는 이유 때문이라고 생각한다. 이 근거를 바탕으로 “따라서 node_modules를 커밋하는 것은 불필요한 파일을 커밋하는 것이으로, 해서는 안된다.” 라고 주장할 수 있겠다.

하지만, 실제로 일을 하다보니 위 근거에는 숨은 가정이 있다는 것을 알게 된다.

NPM 서버가 정상 작동중일 것
Dependencies에 명시된 패키지들이 서버에 올바르게 남아있을 것

이러한 이유로, 위 가정중 하나라도 깨지면 정상적으로 node_modules를 받아올 수 없게 되고, 서버 디플로이가 불가능해지거나 기존에 작성해 둔 툴을 실행시킬 수 없어 다른 사람에게 해당 툴의 node_modules를 복사해 달라고 요청해야 하는 상황이 발생할 수 있다. 물론 이런 예를 드는 이유는 실제로 있었던 일이기 때문이다.

디플로이가 불가능해지는 것은 직접 경험하지는 못했지만, 기존에 작성된 툴의 Dependencies 중 하나가 npm 에서 삭제되면서 사용할 수 없게 되는 불상사는 당황스러운 경험이었다.

전해들은 바로는 기존에 업로드 된 package의 내용도 버전 변경 없이 새로 퍼블리시 되면서 내용이 바뀌어 버리는 상황도 있을 수 있다고 들었던 것 같다. 조금 조사해보니 지금은 unpublish후 다시 publish하면 발생할 수 있는 듯하고, 과거에는 force 옵션을 통해 가능했던 것 같다. 참고링크

정리하자면,

package.json 및 package-lock.json에 명시된 dependencies들을 다시 다운받아야만 node_modules를 재구성할 수 있다.

현재 이용하고 있는 node_modules 데이터가 npm 서버에 그대로 남아있다는 보장이 없다.

라고 할 수 있겠다.

다만, 모든 방식에는 장단점이 있듯 node_modules를 커밋해서 사용하는 경우 편의를 위해 임시로 일부 코드를 커스터마이징 해서 커밋해 쓰는 등의 향후 알기 어려운 문제로 이어질 수 있는 행동도 허용하게 되는 문제가 있다고 생각이 든다.

MoonCha's Notepad

일반적인 개발 상식과 달랐던 것들

node_modules의 경우

Other Posts