엔진이 모델을 소유해

"쓰는 자 하나, 읽는 자 여럿 — 그리고 쓰는 자는 엔진이야."

생산자와 소비자

Track 3 은 모델이 하나라고 했어. 이 트랙은 그게 어디 살고 누가 건드릴 수 있는지를 말해. 답: 엔진이 음악 모델을 생성하고 소유해. 나머지 전부 — UI, Sidekick, 미래 브리지 — 는 API 로 모델을 받는 소비자 야. 엔진은 쓰고, 클라이언트는 읽어. 그 소유 한 줄이 모델을 믿을 수 있게 만들어: 생성되거나 바뀔 수 있는 곳이 딱 하나거든.

API 표면이 어떻게 생겼나

구체적으로, 경계는 작은 엔드포인트 집합이야. 엔진한테 오디오를 넘기면 분석을 해(결과 모델을 소유), 트랙을 달라 하면 모델을 건네, easy-mode 버전을 달라 하면 계산해서 새 모델을 반환해. 클라이언트 쪽 어떤 것도 이 엔드포인트를 지나 엔진 속으로 들어가지 않아.

Ember 의 패턴, 이식

Bonfire 의 새 발명이 아냐 — Ember 에서 그대로 들어 올린 거야. Ember 는 이미지 생성을 소유하고 Cinder 가 소비하는 API 를 열어; Cinder 는 Ember 의 샘플링 내부를 import 안 해. Bonfire 는 음악 분석을 소유하고 UI 가 소비하는 API 를 열어; UI 는 엔진의 분석 내부를 import 안 해. 같은 모양, 다른 매체. 베낄 가치가 있는 이유: 깨끗한 API 경계를 가진 엔진은 아직 만나지도 않은 소비자를 먹일 수 있어(Rule 2 — 비용은 다운스트림에서 흡수, 위로 안 밀어).

Code

API 표면 — 엔진이 소유, 클라이언트는 읽어·bash

# 엔진이 분석하고 결과 모델을 소유:
POST /api/v1/tracks                      # 오디오 업로드 -> 엔진이 모델 빌드

# 클라이언트는 API 로 모델을 읽어:
GET  /api/v1/tracks/{id}                 # 음악 모델 받기
GET  /api/v1/tracks/{id}/audio           # waveform 용 디코드된 오디오
GET  /api/v1/tracks/{id}/easy?level=1    # 엔진이 NEW(단순화) 모델을 계산

# 내장 UI 도 같은 엔드포인트를 때려.
# 엔진 내부는 절대 import 안 해.

Exercise

네가 짓거나 써본 앱에서 핵심 데이터의 단일 '소유자' 를 짚고 누가 또 읽는지 적어. 그다음 위험한 질문을 던져: 어떤 reader 가 쓰기도 할 수 있어? reader 가 (소유자의 API 가 아니라) 핵심을 직접 변형할 수 있으면 writer 가 여럿이고 — 거기서 데이터 신뢰가 무너져.

Hint

writer 여럿이 냄새야. 두 코드 경로가 둘 다 '진실' 을 바꿀 수 있으면 둘 다 못 믿어. 모든 쓰기를 소유자 하나로 깔때기 통과시키면 데이터가 reader 가 기댈 수 있는 게 돼.