지금은 dev Vite, prod dist는 조건이 될 때

"아직 없는 두 번째 유저를 위해 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를 다시 빌드하는 게 아무것도 없었으니까. 이게 조급한 일반화가 남기는 지문이야. production 상황이 생기기도 전에 production을 서빙하는 인프라를 세워 두면, 그게 조용히 틀린 일을 해. 고치는 방법도 인프라를 더하는 게 아니라 덜어내는 거였어. dev Vite로 내려오고 HMR이 제 일을 하게 두는 거.

무엇이 이 결정을 뒤집나

이건 'prod 빌드는 절대 안 한다'가 아냐. '상황이 실제로 바뀌면 뒤집는다'야. 뒤집는 조건은 구체적이야. 외부 클라이언트가 엔진 API를 소비하거나, Bonfire가 server에 안정된 prod 엔진으로 배포되는 순간 prod 정적 빌드로 갈아타. npm run build로 frontend/dist를 만들면, 이미 잠들어 있는 StaticFiles mount가 그걸 서빙해. 그 mount는 /api가 이기도록 맨 마지막에 붙여 뒀어. 둘 중 하나가 참이 되기 전까지는 dev Vite가 옳아. concrete-first가 여기서도 그대로야. prod로 갈 이유가 생겼을 때 prod 경로를 짓는 거야. 미리 내다보고 짓는 게 아니라.

Code

구체적인 조건이 뒤집을 때까지 dev Vite·text

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

prod 정적 dist로 뒤집는 조건 (둘 중 하나 참):
  - 외부 클라이언트가 엔진 API를 소비, 또는
  - Bonfire가 server에 안정된 prod 엔진으로 배포
그러면: npm run build -> frontend/dist
        (StaticFiles mount는 이미 잠들어 있고, /api가 이기도록 맨 끝에 mount)

# 조급한 dist로 한 번 역효과를 봤어. 재시작해도 코드가 안 바뀌었고,
# dist를 다시 빌드하는 게 없어서였어. 인프라를 덜어낸 게 수정이었어.

Exercise

프로젝트에서 'production' 인프라 한 조각을 찾아봐. 빌드 단계든 캐시든 큐든 CDN이든. 그리고 물어. 그게 오늘 실제로 몇 명을 상대하고 있어? 답이 하나고, 그 하나가 개발 중인 너라면, 진짜 두 번째 소비자가 올 때까지는 더 단순한 dev 경로가 옳은 게 아닐까 물어봐.

Hint

조급한 인프라의 표시는, production이 아닌 상황을 지키고 있는 production 장치야. 소비자가 하나뿐이고 그 하나가 저자이기도 하면 prod 파이프라인은 거의 필요 없어. 그건 지금의 필요가 아니라 미래의 필요가 지금 옷을 입고 앉아 있는 거야.