지금 dev Vite, prod dist 는 trigger 에

"아직 없는 두 번째 유저를 위해 production 파이프라인을 짓지 마."

유저 하나, 컨슈머 하나, 지을 이유 없음

Bonfire 엔진과 UI 는 하나의 always-on 명령으로 돌고, UI 는 production 정적 빌드가 아니라 dev Vite 서버 가 서빙해. 정직하게 상황을 보기 전엔 엉성해 보여: 지금 Bonfire 는 한 머신에서 활발히 개발 중인 단일 유저 앱이야. UI 는 컨슈머가 딱 하나 — 자기 자신 — 고, 같은 사람이 짓고 또 써. 그 상황에서 production dist 는 사주는 게 없고 변경마다 rebuild 비용만 들어. dev Vite 는 HMR 로 매 편집을 즉시 반영해. '엉성한' 선택이 사실 옳은 거야.

조급한 dist 의 교훈담

Bonfire 는 처음에 형제 엔진에서 prod-static-dist always-on 셋업을 베꼈고 — 역효과였어. 서버를 재시작해도 코드 변경이 절대 반영 안 됐어, dist 를 rebuild 하는 게 없었으니까. 그게 조급한 일반화의 서명이야: production 상황이 있기도 전에 production-서빙 인프라를 세우고, 그게 조용히 틀린 일을 해. 수정은 인프라를 더하는 게 아니라 — 덜어내는 거였어: dev Vite 로 떨어뜨리고 HMR 이 제 일 하게 둬.

뒤집을 trigger

이건 '절대 prod 빌드 안 함' 이 아냐. '상황이 실제로 바뀌면 뒤집어' 야. trigger 는 구체적이야: 외부 클라이언트가 엔진 API 를 소비하거나, Bonfire 가 server 에 안정된 prod 엔진으로 배포되는 순간, prod 정적 빌드로 전환해(npm run build → frontend/dist, 이미 잠들어 있고 /api 가 이기게 마지막에 mount 된 StaticFiles mount 가 서빙). 둘 중 하나가 참이 되기 전엔 dev Vite 가 옳아. concrete-first: prod 이유가 있을 때 prod 경로를 지어, 예측해서가 아니라.

Code

구체적 trigger 가 뒤집을 때까지 dev Vite·text

지금 (단일 유저, 활발한 개발):
  dev Vite (:5175, HMR, 빌드 단계 없음) -> 모든 편집 즉시 반영

prod 정적 dist 로 뒤집기 WHEN (둘 중 하나 참):
  - 외부 클라이언트가 엔진 API 를 소비, OR
  - Bonfire 가 server 에 안정된 prod 엔진으로 배포
그러면: npm run build -> frontend/dist
        (StaticFiles mount 이미 잠듦, /api 이기게 LAST 로 mount)

# 조급한 dist 가 한 번 역효과: 재시작해도 코드 반영 안 됨,
# dist 를 rebuild 하는 게 없어서. 인프라를 덜어낸 게 수정이었어.

Exercise

프로젝트의 'production' 인프라 한 조각(빌드 단계, 캐시, 큐, CDN)을 찾아 물어: 그게 오늘 실제로 몇 컨슈머를 섬겨? 답이 하나 — 그리고 그 하나가 개발 중인 너 — 면, 진짜 두 번째 컨슈머가 올 때까지 더 단순한 dev-time 경로가 옳을지 물어.

Hint

조급한 인프라의 표시는 non-production 상황을 지키는 production 메커니즘이야. 저자이기도 한 컨슈머 하나는 prod 파이프라인이 거의 필요 없어 — 그건 현재 의상을 입은 미래 필요야.