Next.js 보안 패치를 3개 저장소에 같은 날 적용한 기록

프레임워크 보안 공지는 늘 계획에 없던 날 떠요. 혹시 이런 적 없나요? 오늘 하려던 일을 다 적어 뒀는데, 릴리스 노트 한 줄 때문에 전부 뒤로 밀리는 날이요. 얼마 전 제 하루가 그랬어요.

미루기 어려운 종류의 업데이트였어요

이번에 올린 버전은 Next.js 16.3.3이에요. 인증 없이 원격 코드를 실행할 수 있는 취약점 수정이 포함된 릴리스였어요. 보안 패치는 "나중에 몰아서"가 통하지 않는 영역이라, 하던 작업을 멈추고 업그레이드부터 진행했어요.

같은 패치를 세 번 적용했어요

혼자 운영하는 서비스가 하나가 아니라는 게 이럴 때 티가 나요. 플랜비(plan-b)는 농구 동호회 운영 매니저고, 플랜씨(plan-c)는 로그인 없이 쓰는 무료 금융계산기, 플랜엘(plan-l)은 법령·판례를 찾아주는 서비스예요. 성격은 제각각인데 셋 다 Next.js 위에서 돌아가요.

그래서 같은 날 3개 저장소에 같은 패치를 적용해 봤더니, 손을 움직이는 시간보다 확인하는 시간이 더 길었어요. 저장소마다 바뀐 파일은 package.json, pnpm-lock.yaml, pnpm-workspace.yaml 이렇게 3개씩이었어요. 커밋 메시지도 세 곳 모두 같은 문장으로 남겼어요. 나중에 이력을 볼 때 이유를 다시 조사하지 않으려면, 보안 수정 때문이라는 사실을 제목에 박아 두는 편이 나아요.

보안 공지 확인→영향 저장소 파악→버전 업그레이드→lockfile 검토→저장소별 커밋

lockfile은 눈으로 한 번 봐요

버전을 올려 보니 명령어 자체는 금방 끝나요. 대신 커밋 전에 lockfile 변경분을 직접 확인해 보니, 의도한 패키지 외에 딸려 오는 변경이 있는지 거르는 단계가 제일 오래 걸렸어요. 의존성 업그레이드에서 제 실수는 대부분 확인 없이 커밋했을 때 나왔거든요.

세어 보니 이번 패치 절차는 다섯 단계였어요. 공지 확인, 영향 저장소 파악, 버전 업그레이드, lockfile 검토, 커밋. 단계는 단순한데 저장소 수만큼 곱해진다는 게 1인 개발의 현실이에요.

• ✓보안 패치는 미루지 않기
• ✓lockfile 변경분은 눈으로 확인
• ✓커밋 제목에 이유 남기기

반복을 줄일 수 있을까 고민 중이에요

같은 작업을 세 번 하면서 든 생각은 하나예요. 이 반복은 언젠가 작은 도구로 줄여야 한다는 것. 다만 자동화를 붙이기 전에, 지금은 보안 패치를 미루지 않는 원칙부터 지키고 있어요.

혼자 여러 서비스를 운영한다면, 의존성 업그레이드 절차를 한 번 글로 적어 두는 걸 권해요. 다음 보안 공지가 떴을 때 고민할 거리가 하나 줄어요.