Next.js 보안 패치, 저장소 3개에 새벽에 적용한 기록

새벽 0시 48분에 커밋 3건을 남겼어요. 내용은 전부 같았어요. Next.js를 16.3.3으로 올리는 보안 패치였죠. 혹시 이런 적 없나요? 자기 전에 릴리스 소식을 훑다가 "인증 없이 원격 코드 실행"이라는 문구를 보고 잠이 확 깨는 경험이요.

왜 같은 커밋을 세 번 했을까요

혼자 운영하다 보니 Next.js로 만든 서비스가 어느새 3개가 됐어요. 무료 금융계산기 플랜씨(plan-c), 농구 동호회 운영 매니저 플랜비(plan-b), 법령·판례 검색 플랜엘(plan-l)이에요. 프레임워크에 보안 패치가 나오면 세 저장소를 전부 올려야 해요.

이번 건은 미룰 수 있는 종류가 아니었어요. 인증 없이 원격 코드 실행이 가능한 취약점을 고친 릴리스라서, 확인한 그 밤에 바로 작업을 시작했어요.

실제 절차는 저장소당 5단계였어요

직접 올려 보니 절차 자체는 단순했어요. 한 저장소에 5단계면 끝나요.

릴리스 노트 확인→package.json 버전 변경→pnpm install→빌드·화면 확인→커밋

1. 릴리스 노트에서 보안 수정 포함 여부를 확인해요.
2. package.json의 next 버전을 16.3.3으로 바꿔요.
3. pnpm install을 돌려 잠금 파일을 갱신해요.
4. 로컬 빌드와 주요 화면이 뜨는지 확인해요.
5. 커밋을 남겨요.

커밋마다 바뀐 파일은 3개였어요. package.json과 잠금 파일, 그리고 워크스페이스 설정 파일이요. 패치 버전 업그레이드라 코드 수정은 없었고, 돌려 보니 빌드 확인까지가 작업의 대부분이었어요.

세 번 반복해 보니 남는 것

같은 작업을 세 번 반복해 보니, 절차를 머리로만 기억하면 저장소를 옮길 때마다 처음부터 다시 더듬게 되더라고요. 그래서 위 5단계를 메모로 남겼고, 이 글도 그 기록의 연장이에요.

한 가지 더 느낀 점이 있어요. 새 패키지는 며칠 지켜보고 들이는 게 제 원칙인데, 보안 패치는 반대로 빨리 적용할수록 좋아요. 같은 의존성 관리라도 방향이 다른 두 규칙이 공존하는 셈이에요.

적용해 봤더니 결국 핵심은 속도보다 준비였어요. 어떤 파일이 바뀌는지, 무엇을 확인하고 커밋할지 미리 정해 두면 새벽에 하는 작업도 허둥대지 않아요.

마무리하며

보안 패치는 새 기능이 아니라 빚 갚기에 가까워요. 미룰수록 부담만 커지니, 여러분도 의존성 보안 알림을 켜 두고 패치 절차를 한 번 글로 정리해 보세요. 저장소가 하나일 때 만든 습관이 3개가 됐을 때 시간을 벌어줘요.