pnpm minimumReleaseAge 7은 7분입니다 — 단위와 설정 위치 함정

프론트엔드 작업에서 라이브러리 하나 추가하는 일은 너무 쉬워요. 날짜 피커, 토스트, 드래그 앤 드롭까지 pnpm add 한 줄이면 끝나니까요. 그래서 갓 올라온 버전이 화면 코드에 그대로 섞여 들어갑니다.

그걸 막으려고 pnpm의 minimumReleaseAge를 켰어요. 공개된 지 일정 시간이 지난 버전만 설치되게 하는 옵션입니다. 저는 당연히 "7일"이라고 생각하며 7을 적었어요.

7을 적었더니 7분이었어요

어제 올라온 버전이 그대로 설치되길래 이상해서 확인해 봤는데, 이 값의 단위는 분이었습니다. 7은 7일이 아니라 7분이에요. 사실상 아무 대기도 없는 상태로 몇 주를 보낸 셈이죠.

7일을 원하면 이렇게 계산해야 해요.

# pnpm-workspace.yaml
minimumReleaseAge: 10080 # 단위: 분 (= 7일)

주석에 단위를 안 적으면 반년 뒤의 제가 또 똑같이 착각합니다. 숫자만 남은 설정은 항상 다시 오해받아요.

글로벌 설정은 조용히 무시됐어요

더 당황스러운 건 그다음이었어요. 처음엔 글로벌 설정 파일에 넣어 뒀는데, 프로젝트에서는 반영이 안 되더라고요. 에러도 경고도 없이요. 그냥 설치가 잘 되니까 잘 걸린 줄 알았던 거죠.

그래서 프로젝트의 pnpm-workspace.yaml로 옮겼습니다. 모노레포가 아니어도 이 파일을 만들어 두면 돼요. 저장소에 들어가니 팀원도, 미래의 저도, CI도 같은 값을 씁니다.

화면 코드에서 왜 더 중요한가

프론트엔드 의존성은 대부분 빌드 타임에 번들로 들어가고, 설치 스크립트가 로컬에서 먼저 돕니다. 컴포넌트 한 줄 바꾸려고 받은 패키지가 가장 먼저 닿는 곳이 제 노트북이에요.

그래서 저는 두 가지를 같이 걸어 둡니다.

# 프로덕션 빌드에서는 설치 스크립트 차단
pnpm install --ignore-scripts

대기 기간이 모든 걸 막아주진 않아요. 처음엔 멀쩡하다가 나중에 문제가 생기는 경우도 있으니, 설치 시점 한 번으로 끝내지 말고 주기적으로 다시 확인해야 합니다.

설정을 믿지 말고 결과를 보세요

이번 일의 교훈은 단위 실수 그 자체보다, 설정을 넣었다는 사실을 동작 확인으로 착각했다는 데 있어요. 에러가 없으면 잘 돌아간다고 믿게 되는데, 이 옵션은 잘못 써도 조용합니다.

그래서 저는 설정을 바꾼 뒤 방금 올라온 버전 하나를 일부러 설치해 봤어요. 설치가 거부되는 걸 눈으로 확인하는 데 2분이면 충분했습니다. 이 확인 한 번이 빠지면 몇 달 동안 안전하다고 착각하게 돼요.

라이프케어로그에서 플랜씨나 플랜비 같은 서비스를 혼자 만들다 보면 리뷰해 줄 사람이 없어서, 이런 조용한 실패가 제일 무섭습니다. 그래서 요즘은 설정 파일을 고칠 때마다 "이게 실제로 막히는지 한 번 깨뜨려 보자"를 습관처럼 붙여요.

작은 숫자 하나지만, 단위를 적어두고 위치를 옮기고 한 번 확인하는 데 10분이면 됩니다. 그 10분이 반년치 착각을 없애줘요. 🙂