Next.js 클라이언트 다섯 개가 Vercel 에 있었습니다. 백엔드는 이미 클러스터에 있었으므로, 프론트만 밖에 있는 상태였습니다. 배포 경로가 둘로 갈리고, 환경 변수와 접근 제어도 두 곳에서 따로 관리해야 했습니다.
앱당 건드린 파일은 넷입니다. next.config 에 output: 'standalone' 을
추가하고, Dockerfile 과 빌드·배포 스크립트를 넣는 것으로 끝입니다. 앱
코드는 손대지 않았습니다.
템플릿을 그대로 복사하면 안 되는 이유
두 개를 먼저 옮기고 그 패턴을 나머지 셋에 적용했는데, 셋이 각각 다른 지점에서 걸렸습니다.
하나는 패키지 매니저가 달랐습니다. 템플릿 Dockerfile 이 한쪽 전제로 짜여 있어 별도 변형이 필요했습니다. 여기서 "이참에 통일하자"는 유혹이 있었는데, 이번 작업은 이관이지 빌드 방식 변경이 아니므로 하지 않았습니다. 잠금 파일을 갈아치우면 전이 의존성 버전이 조용히 움직입니다. 이관 중에 그런 변수를 더할 이유가 없습니다.
하나는 스테이징 브랜치가 아예 없었습니다. 기존 배포 브랜치를 스테이징으로 돌려 쓸 수도 있었지만, 다른 앱에서 그 이름이 운영을 뜻하고 있어서 의미가 엇갈립니다. 새로 만들었습니다.
하나는 백엔드를 아예 호출하지 않는 앱이었습니다. 다른 앱마다 필요했던 출처 허용 목록 작업이 여기서는 통째로 없었습니다.
다섯 개가 같아 보였지만 같지 않았습니다. 미리 표로 정리해 두지 않았다면 템플릿을 복사해 붙이다가 하나씩 터졌을 겁니다.
덤으로 취약점 8 건이 0 건이 됐다
컨테이너 스캔에서 높은 등급 취약점 8 건이 잡혔습니다. 전부 베이스 이미지에 딸려 오는 패키지 관리자 자신의 번들 의존성이었습니다. 앱 의존성이 아니라 의존성 업데이트로는 한 건도 고쳐지지 않습니다.
standalone 빌드는 실행할 때 패키지 관리자가 필요 없습니다. 런타임
스테이지에서 지우는 한 줄로 8 건이 전부 사라졌습니다. 나머지 세 앱에는
처음부터 넣었습니다.