패키지 매니저

패키지 매니저란?

패키지 매니저가 실제로 바꾸는 것은 라이브러리를 '가져오는' 방법이 아니라 '적어두는' 방법입니다. 예전에는 필요한 파일을 각자 내려받아 프로젝트 폴더에 복사해 넣었고, 몇 달 지나면 누가 어떤 버전을 왜 넣었는지 아무도 설명하지 못했습니다. 지금은 저장소에 부품 실물 대신 필요한 부품의 목록 파일만 두고, 실제 설치는 명령이 대신합니다. 그래서 신입 개발자가 첫 출근한 날 저장소를 내려받고 설치 명령 한 번만 치면 선배와 똑같은 개발 환경이 만들어집니다.

실무에서 가장 많이 헷갈리는 지점은 선언 파일과 잠금 파일의 차이입니다. package.json에 `^4.17.1`이라고 적으면 '4점대 안에서 최신이면 무엇이든'이라는 뜻이라, 같은 명령을 어제와 오늘 실행해도 다른 버전이 깔릴 수 있습니다. 이를 한 줄 한 줄 고정해 주는 것이 package-lock.json·poetry.lock 같은 잠금 파일이고, 배포 서버에서는 install 대신 ci 계열 명령을 써서 잠금 파일 그대로만 설치하게 막습니다. 여기에 테스트 도구처럼 개발할 때만 쓰는 패키지와 운영에 실제로 올라가는 패키지를 나눠 적고, 보안 심사를 받는 회사라면 사내 프록시 저장소(Nexus·Artifactory)를 두고 승인된 패키지만 통과시킵니다.

사고는 대개 세 곳에서 납니다. 첫째, 잠금 파일을 자동 생성물이라 여겨 .gitignore에 넣어버리는 경우입니다. '제 PC에서는 되는데 서버에서만 안 됩니다'의 상당수가 여기서 나옵니다. 둘째, AI가 실제로 존재하지 않는 패키지 이름을 자신 있게 제시하는 경우입니다. 공격자는 그 그럴듯한 이름을 미리 선점해 악성 코드를 올려두기도 하므로, 설치 전에 주간 다운로드 수와 최종 업데이트 날짜는 눈으로 확인해야 합니다. 셋째는 라이선스입니다. GPL 계열 라이브러리를 고객사에 납품하는 제품에 넣으면 소스 공개 요구를 받을 수 있어 계약 단계에서 문제가 됩니다. 명령 한 줄이 수백 개의 간접 의존성을 함께 끌고 들어온다는 점을 잊으면, 내가 쓴 적 없는 코드가 우리 제품의 책임 범위가 됩니다.