Next.js 보안 패치, 저장소 3개를 하루에 업그레이드한 기록

혼자 서비스 여러 개를 돌리다 보면 의존성 업데이트가 자꾸 뒤로 밀려요. 기능 개발이 늘 더 급해 보이거든요. 혹시 보안 공지를 읽고도 "다음 주에 하지"라며 넘긴 적 없나요? 저는 이번에 그 유혹을 참고 하루를 패치에 썼어요. Next.js에 인증 없이 원격 코드를 실행할 수 있는 취약점(unauthenticated RCE) 수정이 포함된 16.3.3이 나왔기 때문이에요.

저장소 3개에 같은 커밋이 나란히

라이프케어로그에서 운영하는 웹 서비스는 전부 Next.js 기반이에요. 로그인 없이 쓰는 무료 금융계산기 플랜씨(plan-c), 법령·판례를 월 3건 무료로 검색하는 플랜엘(plan-l), 농구 동호회 운영 매니저 플랜비(plan-b)까지 저장소 3개가 같은 스택을 씁니다. 8월 30일 커밋 로그를 열어 보니 세 저장소에 "upgrade next to 16.3.3" 커밋이 같은 날 나란히 찍혀 있어요. 한 번 정리한 절차를 세 번 반복한 결과예요.

실제 절차는 3단계였어요

과정 자체는 화려하지 않아요. 저장소 하나 기준으로 3단계면 끝납니다.

보안 공지에서 수정 버전 확인→버전 올리고 설치→빌드 확인 후 커밋

직접 돌려 보니 저장소마다 바뀐 파일은 package.json, pnpm-lock.yaml, pnpm-workspace.yaml 세 개였어요. 코드 수정은 한 줄도 없었고, 대부분 lockfile 갱신이었습니다. 패치 버전 업그레이드라 이 정도로 끝났지만, 그래도 각 저장소에서 빌드가 깨지지 않는지 확인해 보고 나서야 커밋했어요.

세 곳에 적용해 봤더니 커밋 메시지까지 똑같이 맞추게 되더라고요. 나중에 로그만 봐도 이날 전부 패치했다는 사실이 한눈에 들어오게요.

스택을 통일해 둔 게 이렇게 돌아와요

이번에 새삼 느낀 건, 서비스마다 스택이 달랐다면 이 패치가 하루로 안 끝났을 거라는 점이에요. 프레임워크가 하나면 보안 공지도 하나만 추적하면 되고, 업그레이드 절차도 한 번만 검증해서 재사용할 수 있어요.

• ✓공지 추적 창구 단일화
• ✓검증한 절차 재사용
• ✓커밋 메시지 통일로 이력 파악

혼자 운영하면 보안 담당자도 저 하나예요. 그래서 규칙을 하나 두고 있어요. 보안 수정이 포함된 릴리스는 기능 개발보다 먼저 처리한다는 규칙이에요. 반복을 줄이는 작은 절차가 쌓이면 이런 날도 하루면 지나가요.

서비스가 하나뿐이라도 프레임워크 보안 공지는 구독해 두세요. 패치는 미룰수록 비싸지고, 오늘 하면 세 파일짜리 커밋으로 끝나요.