코드 수정 후 언제 다시 빌드해야 할까 (2026-05-01)

서론 (문제 정의)

2026-05-01 기준으로 컨테이너 기반 블로그에서는 코드, 빌드 타임 환경변수, 프록시 설정이 각각 다른 방식으로 반영됩니다.

이 글은 같은 상황을 겪는 독자가 원인을 빠르게 좁히고 다음 행동을 고를 수 있도록 문제, 배경, 개념, 적용 방법을 분리해 정리합니다.

이어 읽을 글은 전체 글 목록과 DevOps 카테고리에서 확인할 수 있습니다.

상황/배경

프론트엔드 코드, 정적 파일, `VITE_*` 값은 빌드 산출물에 박힙니다. 컨테이너를 단순 재시작하는 것만으로는 새 값이 반영되지 않습니다.

백엔드 코드와 Prisma 마이그레이션도 새 이미지 또는 migration 실행이 필요합니다. 운영에서는 `up-nobuild`와 `up`의 차이를 분명히 알고 써야 합니다.

핵심 개념 설명

런타임 환경변수는 컨테이너 재생성으로 반영될 수 있지만, 프론트엔드 build-time 값은 이미지 빌드가 필요합니다. 사이트 이름, canonical origin, API base URL, ads.txt override가 대표적입니다.

도메인 변경이나 HTTPS 전환 뒤에도 예전 제목과 URL이 보이면 프론트엔드 이미지를 다시 빌드했는지 먼저 확인해야 합니다.

실제 적용 방법

코드를 바꿨다면 기본 명령은 재빌드가 포함된 배포입니다. 문서만 바꿨다면 애플리케이션 빌드는 필요 없지만, main push가 배포 워크플로를 트리거하는 구조인지 확인해야 합니다.

중요한 것은 “무엇이 어디에 박히는가”입니다. 이 기준이 잡히면 502, CORS, 메타데이터 불일치 같은 문제를 훨씬 빠르게 좁힐 수 있습니다.

발행 기준과 수정 원칙은 운영 기준 페이지에 연결해 독자가 글의 맥락을 함께 확인할 수 있게 합니다.

체크리스트

• 프론트 코드나 VITE 값 변경 후 frontend image rebuild
• 백엔드 코드 변경 후 backend image rebuild
• Prisma 변경 후 migration 포함 여부 확인
• Nginx upstream 변경 후 proxy reload 또는 재배포

결론

좋은 글은 하나의 답만 제공하지 않고 다음 확인 경로를 함께 남깁니다. 이 글에서 다룬 기준을 적용한 뒤에는 다른 글과 관련 카테고리를 이어서 확인하며 자신의 서비스 상황에 맞게 보완하는 것이 좋습니다.