기존에 프론트엔드 서비스들은 외부 호스팅 플랫폼에, 백엔드 API 서비스들은 사내 쿠버네티스 클러스터에 분리되어 있었습니다.
이로 인해 배포 파이프라인이 이원화되고, 환경 변수와 내부 접근 제어(CORS, 방화벽)를 두 곳에서 중복 관리해야 하는 운영 비효율이 존재했습니다. 이를 해결하기 위해 프론트엔드 서비스들을 사내 클러스터로 통합 이전했습니다.
겉보기엔 같아 보여도 모든 앱에는 각자의 사연이 있다
공통 템플릿을 만들어 5개 프론트엔드 앱에 일괄 적용하려 했으나, 실제로는 앱마다 빌드 특성이 모두 달랐습니다:
- 패키지 매니저의 차이(pnpm, yarn, npm)
- 브랜치 전략의 차이
- 백엔드 의존성 유무에 따른 환경 변수 주입 방식의 차이
이 과정에서 "이참에 패키지 매니저도 통일하자"는 유혹이 있었지만 의도적으로 참았습니다. 마이그레이션 중에 락파일을 새로 생성하면 하위 의존성 버전이 미세하게 바뀌어, 배포 후 문제가 생겼을 때 원인이 '인프라 이전' 때문인지 '패키지 버전 변경' 때문인지 규명할 수 없기 때문입니다. "마이그레이션 중에는 한 번에 하나의 변수만 바꾼다"는 원칙을 철저히 지켰습니다.
뜻밖의 수확: 런타임 이미지 경량화로 취약점 8건 제거
도커 컨테이너 빌드 보안 스캔 과정에서 베이스 이미지에 내장된 패키지 관리자로 인해 높은 위험도의 취약점 8건이 감지되었습니다.
Next.js 독립 실행 빌드(standalone) 결과물은 런타임 실행 시 패키지 관리자가 전혀 필요하지 않습니다. 최종 런타임 스테이지에서 패키지 관리자를 완전히 제거하여 보안 취약점 0건 및 초경량 컨테이너 이미지를 달성했습니다.
요약
프론트엔드 컨테이너화 마이그레이션의 본질은 무작정 템플릿을 복사하는 것이 아니라, 각 앱의 고유한 빌드 특성을 존중하면서 안전하게 배포 파이프라인을 일원화하는 것입니다.