의존성(Dependency) — npm install 뒤에 쏟아지는 부품의 정체

게시일 2026-04-30수정일 2026-04-30

On this page

npm install을 실행하면 터미널에 수백 줄의 설치 로그가 쏟아진다. 패키지 하나를 설치했을 뿐인데 왜 수백 개가 설치될까. 이 현상의 핵심에 의존성(Dependency)이 있다.

정의

의존성(Dependency)이란 프로그램이 실행되거나 빌드될 때 필요한 외부 라이브러리·패키지·모듈을 가리킨다. 어떤 코드가 특정 기능을 구현하기 위해 다른 코드에 '의존'한다는 뜻에서 유래한 개념이다.

예를 들어 AI API를 호출하는 Python 프로젝트가 openai 패키지를 사용한다면, openai는 이 프로젝트의 의존성이다. 그리고 openai 패키지 자체도 내부적으로 httpx, pydantic 등 다른 패키지에 의존한다. 이렇게 의존성이 의존성을 부르는 구조를 의존성 트리(Dependency Tree)라고 한다. npm install 한 번에 수백 개가 설치되는 이유가 바로 이 트리 구조 때문이다.

의존성 관리 도구

언어마다 의존성을 관리하는 도구와 파일 형식이 다르다:

| 언어 | 패키지 관리자 | 의존성 파일 | |---|---|---| | JavaScript / Node.js | npm, yarn, pnpm | package.json + package-lock.json | | Python | pip, uv, poetry | requirements.txt / pyproject.toml | | Java | Maven, Gradle | pom.xml / build.gradle | | Go | Go Modules | go.mod | | Rust | Cargo | Cargo.toml |

package.json의 dependencies에는 프로덕션 실행 시 필요한 패키지, devDependencies에는 개발·테스트 시에만 필요한 패키지를 나눠 명시한다.

의존성 충돌과 버전 고정

의존성이 많아질수록 버전 충돌(Dependency Conflict) 위험이 높아진다. 패키지 A가 lodash@4.x를 요구하고 패키지 B가 lodash@3.x를 요구하는 경우가 전형적인 예다.

이를 방지하는 수단:

Lock 파일: package-lock.json, yarn.lock은 설치 당시의 정확한 버전을 기록해 재설치 시 동일한 버전 보장
버전 범위 표기: ^1.0.0 (1.x.x 허용), ~1.0.0 (1.0.x만 허용), 1.0.0 (정확히 이 버전만)
가상 환경: Python의 venv, conda는 프로젝트별 의존성을 격리

AI 프로젝트에서는 특히 torch, transformers, cuda 버전 간 호환성 충돌이 자주 발생한다. CUDA 버전과 PyTorch 버전이 맞지 않으면 GPU 가속이 동작하지 않거나 runtime 에러가 발생한다.

AI 프로젝트의 의존성 관리

llm 기반 AI 애플리케이션은 의존성 규모가 크고 버전 민감도가 높다:

openai, anthropic, langchain 같은 AI SDK는 빈번한 업데이트로 API 인터페이스가 바뀔 수 있음
transformers(Hugging Face) 계열은 torch, tokenizers 버전과 강하게 연결됨
서버 배포 시 Docker 컨테이너에 의존성을 고정해 "내 컴퓨터에서는 됐는데..." 문제를 방지

의존성 보안 취약점 스캔도 중요하다. npm audit, pip-audit 같은 도구로 알려진 취약점이 있는 버전을 정기적으로 확인한다.

활용 사례

AI API 프로젝트: anthropic==0.25.0처럼 버전을 고정해 API 변경에 의한 오류 방지
팀 개발: lock 파일을 git에 커밋해 팀원 간 동일 의존성 환경 유지
CI/CD: 빌드 파이프라인에서 npm ci(lock 파일 기반 엄격 설치)로 재현 가능한 빌드 보장

정의

의존성 관리 도구

의존성 충돌과 버전 고정

AI 프로젝트의 의존성 관리

활용 사례

관련 용어