Vercel 자동 배포 실패 – ERR_PNPM_LOCKFILE_CONFIG_MISMATCH

Next.js 15 프로젝트를 Vercel에 올려 두고 자동 배포를 쓰고 있었는데
어느 날 Vercel에서 보안 관련 메일이 한 통 왔다.

Security Update: Two additional React Server Components vulnerabilities
CVE-2025-55184, CVE-2025-55183 (React Server Components, Next.js 영향)

 

내용을 요약하면

• App Router 엔드포인트로 악의적인 HTTP 요청을 보내면
  • 서버 프로세스가 뻗어 CPU를 소모하게 만드는 DoS 취약점 (CVE-2025-55184)
  • Server Actions의 컴파일된 소스 코드가 응답으로 나올 수 있는 취약점 (CVE-2025-55183)
• React2Shell 사건 이후 RSC 쪽을 집중적으로 검토하다가 외부 연구자가 제보한 이슈
• 실제 악용 사례는 아직 발견되지 않았지만, 관련 버전 업과 패치 적용을 권장

내 프로젝트도 Next.js App Router + Server Actions를 쓰고 있어서
“이참에 버전 올리고, 다시 빌드 한 번 돌려야겠다” 싶어서 손을 대기 시작했다.

그렇게 의존성 정리하고 푸시까지 했는데
정작 Vercel 배포가 엉뚱하게 pnpm 에러로 터졌다.
그게 바로 이번에 정리하는 ERR_PNPM_LOCKFILE_CONFIG_MISMATCH다.

---

1) 문제 직면 – 에러 메시지

Vercel에서 GitHub 레포를 연결해 자동 배포를 돌리던 중,
배포가 갑자기 실패했다. 로그 일부는 대략 이런 느낌이었다.

• Detected pnpm-lock.yaml version 6 generated by pnpm@8.x
• Installing dependencies...
• ERR_PNPM_LOCKFILE_CONFIG_MISMATCH
• Cannot proceed with the frozen installation. The current "overrides" configuration doesn't match the value found in the lockfile
• Update your lockfile using "pnpm install --no-frozen-lockfile"

요약하면

의존성 설치 단계에서 frozen 설치 조건 때문에 막혀서
빌드까지 가지도 못하고 실패한 상황

---

2) 상황 정리 – Vercel 로그 흐름

빌드 로그를 위에서부터 다시 보면 Vercel이 하는 일은 단순하다.

1. GitHub 레포 clone
2. 이전 배포의 build cache 복원
3. vercel build 실행
4. pnpm-lock.yaml 존재 여부 확인
5. pnpm으로 의존성 설치 시도
6. 여기서 frozen 조건 때문에 중단

여기서 중요한 점

• Vercel은 항상
  의존성 설치 → 빌드 순서로 진행한다
• 이번 케이스는 설치 단계에서
  ERR_PNPM_LOCKFILE_CONFIG_MISMATCH에 걸린 것

즉, 빌드를 잘못 짠 문제가 아니라
설치 자체가 frozen 조건 때문에 막힌 케이스였다.

---

3) 원인 – overrides와 lockfile 불일치

에러의 직접적인 원인은 로그에 거의 다 나와 있다.

The current "overrides" configuration doesn't match the value found in the lockfile

정리하면 아래 두 가지가 서로 안 맞는 상태였다.

• 레포에 현재 설정된 pnpm.overrides
  (보통 package.json 또는 pnpm 관련 설정 파일)
• 이미 커밋되어 있는 pnpm-lock.yaml 안의 정보

이 둘이 서로 다른 값을 가지고 있는데
Vercel 쪽 설치가 frozen 모드로 돌고 있었다.

frozen 모드는 이런 느낌에 가깝다.

“lockfile은 수정하지 말고,
지금 lockfile에 적혀 있는 그대로만 설치해라”

현실적인 흐름으로 바꿔 보면

• 로컬에서 overrides를 수정하거나 추가, 삭제했다
• 그런데 그 상태에서 pnpm install을 다시 돌려서
  lockfile을 재생성하지 않았다
• 코드만 커밋하고 GitHub에 푸시했다
• Vercel은 옛날 pnpm-lock.yaml을 믿고
  frozen 모드로 설치를 시도했다
• 결국 설정과 lockfile 내용이 다르니까 에러 발생

이렇게 정리할 수 있다.

---

4) 해결 – 현재 설정 기준으로 lockfile 다시 만들기

정석 해결 방법은 생각보다 단순하다.

1. 로컬에서 현재 overrides 설정 기준으로
   pnpm-lock.yaml을 다시 생성한다
2. 업데이트된 pnpm-lock.yaml을 커밋 후 푸시한다

4-1) 실행

pnpm install --no-frozen-lockfile

이 명령으로

• 기존 lockfile과의 불일치를 허용하고
• 현재 package.json / pnpm.overrides 기준으로
  lockfile을 다시 만들어 준다.

4-2) 커밋

git add pnpm-lock.yaml
git commit -m "chore: update pnpm lockfile"
git push

여기까지 하고 나면

• Vercel에서 다시 배포를 돌릴 때
• --frozen-lockfile 옵션이 걸려 있어도
• 이미 lockfile이 최신 상태라서

의존성 설치가 정상적으로 진행되고
그 다음 빌드까지 문제 없이 넘어간다.

---

5) 임시 우회 – Vercel에서 frozen 끄기 (비추천)

정석대로 처리할 시간이 없고
“일단 지금 이 배포만 어떻게든 통과시키고 싶다”는 상황이라면
Vercel에서 설치 명령어를 바꿔서 우회하는 방법도 있다.

Install Command 변경

Vercel 프로젝트 설정에서 Install Command를 다음처럼 지정한다.

pnpm install --no-frozen-lockfile

이렇게 하면 배포 환경에서도

• lockfile과 설정의 불일치를 허용하고
• 필요한 경우 lockfile을 갱신하면서 설치를 진행

하게 된다.

다만 이 방식은

• 배포 환경에서 lockfile이 바뀔 수 있고
• 로컬과 lockfile 상태가 엇갈릴 수 있어서

재현성이 떨어지는 문제가 있다.
그래서 개인적으로는 정말 급한 상황이 아니면
우회용으로만 쓰고, 이후에 반드시 정석 방식으로 정리하는 게 좋다고 느꼈다.

---

6) 재발 방지용 체크리스트

다음에 같은 에러를 다시 보지 않으려면
대략 아래 정도만 습관으로 가져가면 될 것 같다.

• package.json에서 pnpm.overrides를 수정했다면
  → 반드시 pnpm install로 lockfile도 같이 업데이트
• PR이나 배포 전에 로컬에서 한 번 체크
  • pnpm install을 실행했을 때
    pnpm-lock.yaml 변경이 발생하는지 확인
• 팀 작업일 경우
  • overrides를 건드리는 PR이라면
    lockfile 변경이 함께 포함되도록 룰을 잡는 것도 방법

결국 한 줄로 줄이면

설정이 바뀌면 lockfile도 같이 바꾸고 커밋한다

 

이걸 잊지 않는 것.

---

7) 짧은 회고

이번 Vercel 자동 배포 실패는

• Vercel이 이상해서가 아니라
• RSC 보안 이슈로 인해 의존성 정리 작업을 시작했고
• 그 과정에서 pnpm overrides 변경
• lockfile 업데이트 누락
• --frozen-lockfile 정책

이 세 가지가 한 번에 겹치면서 생긴,
꽤 전형적인 pnpm 관련 문제였다.

해결 과정은 어렵지 않았다.

• 로컬에서 pnpm install --no-frozen-lockfile로 lockfile을 갱신하고
• 변경된 pnpm-lock.yaml을 커밋
• 다시 푸시 후 배포 재시도

이렇게 했더니 자동 배포가 예전처럼 다시 잘 돌아갔다.

다음에 비슷한 에러 메시지를 만나면

“아, overrides랑 pnpm-lock.yaml부터 확인하자”

이 글을 떠올릴 수 있으면 충분히 성공한 기록이라고 생각한다.