EINTEGRITY는 받은 파일의 해시가 package-lock.json의 integrity와 다를 때 납니다. 레지스트리 값과 같으면 캐시를 비우고, 다르면 락을 다시 만들어 커밋합니다. 피어 충돌과 얼린 락 거절은 다른 줄입니다. 깨끗한 액션까지 실패하면 락을 고칩니다. npm, 액션, 패키지, 한국 1인 개발. 2026년 9월 npm 문서.
EINTEGRITY는 패키지 이름이 없어서가 아니라, 받은 파일의 해시가 package-lock.json에 적힌 값과 달라 설치가 풀기를 거절할 때 납니다. 캐시를 비워도 같은 해시가 틀리면 락의 그 줄을 보세요.
로컬 설치는 되는데 액션의 npm ci만 체크섬에서 멈추는 일이 있습니다. 피어를 한 트리로 못 맞추는 실패와는 순서가 다릅니다. 버전은 정해졌는데 받은 바이트가 다른 칸입니다.
로그의 패키지로 레지스트리 해시를 조회해 락과 비교하세요. 같으면 캐시, 다르면 머지로 락이 섞인 쪽입니다. 근거는 npm cache와 락 파일 문서입니다.
락에 적힌 체크섬과 받은 파일이 다르면 설치가 멈춥니다. package-lock.json의 integrity 필드는 그 위치에 풀린 산출물의 sha512 또는 sha1 서브리소스 무결성 문자열이라고 문서가 적습니다. npm은 받을 때마다 이 값으로 전송 중 손상이 없었는지 확인합니다.
터미널에는 code EINTEGRITY 와 함께, 어떤 패키지의 체크섬이 실패했는지가 나옵니다. 그 이름을 지우지 말고 복사해 두세요. node_modules 전체 삭제는 그 다음입니다. 이름이 없으면 캐시를 비운 뒤에도 같은 줄을 다시 읽게 됩니다.
CI의 npm ci는 락을 고치지 않습니다. 문서상 package.json과 락이 어긋나면 락을 갱신하지 않고 실패하고, 이미 node_modules가 있으면 지운 뒤 락대로만 설치합니다. 그래서 해시가 틀린 락을 올리면 로컬의 npm install은 락을 고쳐 넘어가고, ci만 같은 해시를 고집하다 멈춥니다.
먼저 갈라 둘 것 | 레지스트리의 integrity와 락이 같으면 캐시입니다. 다르면 락입니다. 둘을 보기 전에 npm cache clean --force 만 반복하지 마세요.
같은 코드라도 손대는 파일이 둘로 갈립니다. 캐시가 상하면 로컬에만 실패하고 다른 컴퓨터의 npm ci는 통과합니다. 락이 상하면 깨끗한 러너까지 같은 패키지에서 멈춥니다. 깃허브 액션만 실패하면 락을 먼저 의심하고, 내 노트북만 실패하면 캐시를 먼저 의심하면 됩니다.
npm doctor는 캐시 안의 압축 파일이 발행 때 만든 체크섬과 맞는지 검사한다고 문서가 안내합니다. 손상된 항목이 있으면 npm cache clean --force 로 캐시를 비운 뒤 다시 설치합니다. 캐시 위치는 npm config get cache 로 확인합니다.
락이 틀린 경우에는 캐시를 비워도 레지스트리에서 다시 받은 파일이 락의 옛 해시와 또 다릅니다. 그때 clean을 열 번 해도 코드는 같습니다. 락의 그 패키지 블록을 레지스트리 값으로 맞춰 커밋해야 합니다.
| 비교 | 캐시가 상함 | 락이 상함 |
|---|---|---|
| 어디가 실패하나 | 그 컴퓨터만 | 깨끗한 CI도 |
| npm view와 락 | 같음 | 다름 |
| 고칠 곳 | 로컬 캐시 | package-lock.json 커밋 |
| 캐시 삭제 후 | 통과 | 같은 코드가 반복 |
레지스트리 해시와 락을 비교# 로그에 찍힌 이름과 버전으로 바꾼다 npm view left-pad@1.3.0 dist.integrity # 락에서 같은 버전의 integrity 한 줄을 찾는다 # 두 문자열이 같으면 캐시, 다르면 락
레지스트리와 락이 같을 때만 캐시를 지웁니다. npm cache verify 로 캐시 인덱스를 먼저 검사하고, 실패한 패키지가 그 안에 있으면 npm cache clean --force 후 저장소 루트에서 npm ci를 다시 돌립니다. ci는 락을 다시 쓰지 않으므로, 해시가 맞는 락이라면 깨끗한 캐시에서 같은 트리가 만들어집니다.
프록시나 사내 미러를 거치면 미러가 다른 바이트를 줄 수 있습니다. 오류에 받은 주소가 찍히면 registry.npmjs.org 인지 확인하세요. 미러가 이미 발행된 버전을 덮어쓰는 저장소라면, 락이 맞아도 받는 파일이 달라집니다. 그때는 미러를 고치거나 공식 레지스트리로 한 번 받아 비교합니다.
사설 피드의 같은 버전을 재발행하는 습관이 있으면 이 코드가 반복됩니다. npm 공개 레지스트리의 버전은 내용을 바꾸지 않는 것이 전제라, 같은 버전의 해시가 바뀌면 공급 경로를 의심하는 편이 맞습니다. 버전을 올려 새 해시를 락에 남기는 쪽이 재발행보다 안전합니다.
캐시가 원인일 때만 비우기npm config get cache npm cache verify npm cache clean --force rm -rf node_modules npm ci
resolved 주소는 새 버전인데 integrity는 옛 버전의 해시로 남은 락이 있습니다. 충돌을 손으로 합치면서 한쪽의 해시만 남기면 생깁니다. 마커를 지웠어도 두 필드가 서로 다른 버전을 가리키면 EINTEGRITY로 나타납니다.
고치는 방법은 그 패키지를 락에서 추측해 고치지 않는 것입니다. 메인과 맞는 상태에서 해당 의존성을 package.json 범위에 맞게 다시 설치하고, npm이 쓴 새 락을 통째로 커밋합니다. 한 줄만 레지스트리 해시로 바꿔도 인접한 dependencies 블록이 옛 트리면 다음 패키지에서 또 실패할 수 있습니다.
락 파일은 생성 결과이므로 리뷰에서 해시 한 줄을 사람이 계산하지 않아도 됩니다. 대신 "충돌 마커가 없는지"와 "npm ci가 깨끗한 폴더에서 통과하는지"를 보면 됩니다. 통과한 락만 머지하면 액션이 같은 해시를 받습니다.
pnpm의 ERR_PNPM_TARBALL_INTEGRITY도 받은 파일의 해시가 기대와 다르다는 뜻입니다. pnpm 문서는 공개 레지스트리라면 락의 무결성 값이 틀린 경우가 많고, 머지가 엉켰을 때 그렇다고 적습니다. 버전을 덮어쓰는 레지스트리면 로컬 메타데이터 캐시가 옛 해시일 수 있어 pnpm store prune 후 다시 시도하라고 합니다. npm EINTEGRITY와 고치는 파일은 같고, 명령 이름만 다릅니다.
ERR_PNPM_OUTDATED_LOCKFILE는 해시 이전입니다. 락을 갱신해야 설치가 진행된다는 코드라 얼린 설치가 락을 거절하는 글의 자리입니다. 피어를 못 맞추면 ERESOLVE이고, 설치는 끝났는데 실행이 파일을 못 열면 Cannot find module입니다. exports가 하위 경로를 닫은 경우는 ERR_PACKAGE_PATH_NOT_EXPORTED입니다.
서명 검사는 또 다른 명령입니다. npm audit signatures 는 레지스트리 서명과 프로비넌스를 보고, EINTEGRITY는 락에 적힌 해시와 바이트를 봅니다. 서명이 없다는 출력으로 이 코드를 지우려고 하지 마세요. 설치가 해시에서 멈추면 락과 캐시만 보면 됩니다.
| 코드 | 언제 | 먼저 |
|---|---|---|
| EINTEGRITY | npm 해시 불일치 | npm view와 락 비교 |
| TARBALL_INTEGRITY | pnpm 해시 불일치 | 락 머지 또는 store prune |
| OUTDATED_LOCKFILE | 락 갱신이 필요 | install 후 락 커밋 |
| ERESOLVE | 피어 트리를 못 짬 | 요구 버전과 설치 버전 |
한국에서 맥으로 설치하고 리눅스 액션에서만 깨진다면, 대소문자 문제일 수도 있지만 해시 문구가 있으면 플랫폼보다 그 값을 먼저 봅니다. 액션이 예전 캐시 폴더를 매 잡마다 되돌리고 있다면, 깨끗한 컴퓨터에서는 통과하는데 잡만 같은 줄에서 멈춥니다. 캐시 키를 한 번 무효화한 뒤 깨끗한 설치가 통과하는지 보면, 락을 고칠지 캐시를 버릴지가 갈립니다. 리뷰에서는 충돌 마커를 지운 락을 사람이 해시까지 계산하지 않아도 됩니다. 대신 빈 폴더에서 설치 명령이 통과한 락만 머지하면 다음 잡이 같은 바이트를 받습니다.
대소문자까지 의심된다면, 해시 문구가 없을 때만 파일 이름을 보면 됩니다. 글자 크기만 다른 경로는 해시 실패와 다른 칸이니, 문구를 먼저 읽고 파일을 나중에 여세요. 빈 폴더에서 한 번 통과한 락만 올리면 다음 잡도 같은 바이트를 받습니다.
내부 연계: 피엔피엠 얼린 설치, 피어 충돌, 모듈을 못 찾는 줄, exports 하위 경로
필드 설명은 2026년 9월 npm 문서 기준입니다.
락의 integrity가 레지스트리와 다른 경우입니다. npm view 이름@버전 dist.integrity 와 락의 그 버전 줄을 비교하세요. 다르면 그 의존성을 다시 설치해 락을 새로 쓰고 커밋합니다. 캐시 삭제는 두 값이 같을 때만 효과가 있습니다.
npm ci는 락을 고치지 않고, 로컬 npm install은 어긋나면 락을 갱신할 수 있습니다. CI가 받은 커밋의 package-lock.json이 푸시됐는지, 그 안의 해시가 레지스트리와 같은지 확인하세요. 갱신된 락을 올리면 ci가 그 해시를 받습니다.
충돌 마커를 없애는 수준을 넘으면 옆 블록이 옛 트리로 남기 쉽습니다. 깨끗한 트리에서 그 패키지를 다시 설치하고, npm이 생성한 락을 커밋하는 편이 다음 패키지 실패를 줄입니다.
같은 버전 번호를 다른 파일로 다시 올리는 미러일 수 있습니다. 오류에 찍힌 주소가 공식 레지스트리인지 확인하고, 덮어쓰기 정책이 있으면 버전을 올려 새 해시를 락에 남기세요.
받은 파일과 락의 해시가 다르다는 점은 같습니다. npm은 캐시 clean과 락 재생성이고, pnpm 문서는 엉킨 락을 고치거나 덮어쓰는 레지스트리면 pnpm store prune 을 안내합니다. OUTDATED_LOCKFILE 처럼 락 갱신 거절과는 코드가 다릅니다.
트리를 못 짜서 멈춘 것이면 ERESOLVE가 앞입니다. 해시 검사는 받을 파일이 정해진 다음에 돕니다. 피어를 맞춘 뒤에도 EINTEGRITY가 남으면 그때 락의 integrity를 보면 됩니다.
