같은 프로세스는 핑계가 안 돼

"UI 랑 엔진이 한 프로세스를 공유해. 그건 편의지, API 를 건너뛸 면허가 아냐."

유혹적인 지름길

Bonfire 의 내장 UI 와 엔진은 같이 돌아 — 서버 하나, 엔진은 포트에, UI 가 거기 말 걸어. 너무 가까워서 끊임없는 유혹이 있어: 엔진 객체가 같은 코드베이스 바로 거기 있는데 왜 모델을 HTTP 로 가져와? 그냥 import 해. 더 빠르고, 줄도 적고, 그 순간 완벽히 작동해.

근데 그게 엔진을 지을 가치 있게 만드는 그것을 조용히 파괴해. UI 가 엔진 내부를 import 하는 순간, 엔진의 API 가 아니라 모양 에 결합돼. 엔진을 리팩터하면 API 계약이 약속한 적 없는 방식으로 UI 가 깨져. 더 나쁜 건, 이제 모델이 다른 클라이언트가 쓸 수 없는 경로로 UI 에 도착할 수 있어 — 그래서 나중에 짓는 Live 브리지, 모바일 앱, CLI 가 전부 그 경로에서 잠겨.

in-process 를 remote 처럼 다뤄

규율은 말하긴 쉽고 지키긴 짜증나: 내장 UI 는 엔진이 다른 머신에 있는 것처럼 API 를 불러. 함수 호출이 될 텐데도 HTTP 요청을 해. 비용은 약간의 레이턴시와 약간의 예식. 보상은 UI 가 매 요청마다 API 가 충분하다는 걸 증명한다는 거야 — UI 가 API 만으로 필요한 모든 걸 할 수 있는 클라이언트라는 살아 있는 증거니까.

Code

같은 프로세스는 API 를 건너뛸 핑계가 안 돼·typescript

// 틀림 — 내장 UI 가 엔진 내부를 import:
import { MusicModel } from "../../backend/model";  // 결합!
const song = MusicModel.load(trackId);             // 다른 클라이언트엔 없는 경로

// 맞음 — UI 가 원격 클라이언트와 같은 API 를 부름:
const song = await fetch(`/api/v1/tracks/${trackId}`)
  .then((r) => r.json());

// UI 가 모델을 API 로만 닿을 수 있으면,
// 미래 Live 브리지가 동일한 표면을 공짜로 얻어.

Exercise

프로젝트에서 두 부분이 프로세스를 공유하고 하나가 다른 하나로 직접 손 뻗는 자리를 찾아(공유 import, 전역, 직접 DB 읽기). 물어: 이 둘이 다른 머신에 있었다면 그 손 뻗음을 무슨 API 호출이 대체할까? 그 호출을 못 짚으면 경계가 아직 없는 거고 — 미래의 제3자를 그걸 발명하지 않고는 못 더해.

Hint

테스트는 '다른 머신' 사고 실험이야. 두 부분이 메모리를 공유하니까만 작동하는 건 어차피 API 경계가 대체해야 할 결합이야. 지금 긋는 게 나아.