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

혼자 서비스 여러 개를 운영하다 보면 가장 긴장되는 알림이 프레임워크 보안 공지예요. 서비스가 하나면 금방 끝나지만, 저는 같은 프레임워크로 만든 웹이 셋이거든요.

이번에 Next.js에서 인증 없이 공격할 수 있는 원격 코드 실행(RCE) 취약점을 고친 16.3.3 버전이 나왔어요. 플랜비(plan-b), 플랜씨(plan-c), 플랜엘(plan-l) 웹이 전부 해당돼서 저장소 3곳을 같은 날 업그레이드했습니다.

특히 플랜씨(plan-c)는 로그인 없이 쓰는 무료 금융계산기예요. '인증 없이'라는 말이 남 일처럼 들리지 않았어요. 로그인 장벽이 없다는 건 사용자에게 편한 만큼, 공격자에게도 문이 하나 덜 닫혀 있다는 뜻이니까요.

실제로 한 일은 단순했어요

절차는 세 저장소 모두 같았어요. 릴리스 내용을 확인하고, 버전을 올리고, CI가 통과하는지 보는 흐름이에요. 차례로 적용해 봤더니 두 번째 저장소부터는 거의 손이 기억하는 수준이었어요.

보안 공지 확인→버전 업그레이드→잠금파일 갱신→CI 게이트 통과→머지

직접 올려 보니 저장소마다 바뀐 파일은 package.json, pnpm-lock.yaml, pnpm-workspace.yaml 3개였어요. 애플리케이션 코드는 한 줄도 안 바뀌고 의존성 선언과 잠금파일만 갱신된 셈이라, 변경 내역을 눈으로 검토하는 부담도 적었어요.

지난주의 내가 도와줬어요

이번 업그레이드가 무섭지 않았던 이유는 따로 있어요. 지난주에 세 저장소의 CI를 정비해 뒀거든요. 품질 게이트를 재사용 가능한 워크플로로 묶고, 알림과 롤백, 커버리지 검사까지 붙여 놨어요.

덕분에 버전만 올리고 CI를 돌려 보니 테스트와 빌드가 각 저장소에서 알아서 검증됐어요. 급한 보안 패치일수록 "올려도 안 깨진다"를 사람 눈이 아니라 자동 게이트가 보증해 주는 게 큽니다. 최근 7일 커밋 11건을 돌아보니 이런 기반 정비가 여럿이었는데, 그 투자가 바로 이번 주에 돌아왔어요.

혼자 여러 서비스를 지키는 요령

이번 일로 다시 확인한 원칙은 셋이에요.

• ✓스택 통일로 반복 줄이기
• ✓CI 게이트 미리 정비
• ✓보안 패치는 미루지 않기

스택을 통일해 두면 패치 절차가 복사되듯 반복돼요. 저장소 3곳을 올리는데 절차서는 하나면 충분했어요. 그리고 보안 패치는 미룰수록 위험이 이자처럼 붙어요. 기능 개발 중이더라도 순서를 바꿔 먼저 처리하는 편이에요.

비슷하게 여러 프로젝트를 혼자 운영하고 있다면, 다음 보안 공지가 오기 전에 CI 게이트부터 점검해 보세요. 급할 때 기댈 곳은 결국 미리 만들어 둔 자동화더라고요.