엔진이 모델을 소유해

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

생산자와 소비자

Track 3에서는 모델이 하나여야 한다고 했어. 이제 그 모델이 어디에 살고 누가 건드릴 수 있는지 정할 차례야. 답은 엔진이야. 엔진이 음악 모델을 만들고 소유해. UI와 Sidekick, 미래 브리지는 전부 API를 통해 모델을 받는 소비자야. 엔진은 쓰고 클라이언트는 읽어. 이 한 줄짜리 소유 규칙 덕분에 모델을 믿을 수 있어. 모델이 만들어지거나 바뀌는 곳이 딱 하나뿐이니까.

API 표면은 어떻게 생겼나

경계는 작은 엔드포인트 집합으로 드러나. 엔진에 오디오를 넘기면 분석하고 결과 모델을 소유해. 트랙을 요청하면 그 모델을 건네고, easy-mode 버전을 요청하면 계산한 뒤 새 모델을 반환해. 어떤 클라이언트도 이 엔드포인트를 건너뛰어 엔진 내부로 들어가지 않아.

Ember의 패턴을 이식해

Bonfire가 새로 발명한 구조는 아냐. Ember에서 검증된 경계를 그대로 가져왔어. Ember는 이미지 생성을 소유하고 Cinder가 소비할 API를 열어. Cinder는 Ember의 샘플링 내부를 import하지 않아. Bonfire도 음악 분석을 소유하고 UI가 소비할 API를 열어. UI는 엔진의 분석 내부를 import하지 않아. 매체만 다를 뿐 모양은 같아. 이 패턴을 베낄 가치가 있는 이유는, 깨끗한 API 경계를 가진 엔진이 아직 만나지도 않은 소비자까지 받아들일 수 있기 때문이야. 비용은 아래쪽에서 흡수하고 위로 밀어 올리지 않아.

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

네가 짓거나 써본 앱에서 핵심 데이터의 '소유자'가 누구인지 짚고, 또 누가 읽는지 적어. 그다음 위험한 질문을 던져 봐. 읽는 쪽 중에 쓰기도 할 수 있는 게 있어? 소유자의 API를 거치지 않고 핵심을 직접 건드릴 수 있으면 쓰는 쪽이 여럿인 거고, 거기서 데이터 신뢰가 무너져.

Hint

쓰는 쪽이 여럿이면 그게 냄새야. 코드 경로 둘이 다 '진실'을 바꿀 수 있으면 둘 다 못 믿어. 모든 쓰기를 소유자 하나로 깔때기처럼 모으면, 그때 데이터가 읽는 쪽이 기댈 수 있는 것이 돼.