클라이언트 셋, API 하나

"내장 UI 는 내부자가 아냐. 모두랑 같은 줄에 서서 기다려."

엔진 하나, 클라이언트 세 종류

Bonfire 엔진은 API 가 딱 하나고, 세 종류가 그걸 소비해:

내장 Konva UI — 시각 클라이언트. 모델을 fretboard, waveform, 노트 그리드, voicing 다이어그램으로 바꿔.
Pippa Sidekick — 대화 클라이언트. 모델을 읽고 설명하고 코치하고 즉흥을 제안해. (뇌는 cwkPippa 에 — Sidekick 은 표면이지 두 번째 Pippa 가 아냐.)
미래 Live 브리지 — DAW 클라이언트. 아직 안 지었지만, 분석하러 MIDI 클립을 끌어오려고 같은 API 를 소비할 거야.

UI 한텐 특별 접근이 없어

이걸 진짜로 만드는 규율이 여기 있어: 내장 UI 는 특권이 없어. 같은 repo 에 실린다고 모델로 가는 더 빠른 내부 경로를 받지 않아. 원격 클라이언트가 쓸 정확히 같은 엔드포인트로 모델을 읽어. 자기 UI 를 '그냥 또 하나의 클라이언트' 로 다루는 건 두 번째 클라이언트가 나타나기 직전까진 현학적으로 느껴져 — 그러고 나면 그게 두 번째 클라이언트가 작동하는 유일한 이유야.

왜 미래 클라이언트가 지금 중요한가

Live 브리지는 아직 없지만 오늘 진짜 일을 해: 경계를 정직하게 지키는 상상의 두 번째 소비자야. UI 가 질러가게 두고 싶을 때마다 — 편하니까 API 를 지나치고 싶을 때마다 — 물어: 'Live 브리지도 이걸 할 수 있나?' 답이 아니오면, 그 지름길이 조용히 엔진을 재사용 불가로 만들었을 거야. 안 지은 클라이언트가 API 의 양심이야.

Code

클라이언트 셋, 표면 하나·text

   Konva UI (시각)       ─┐
   Pippa Sidekick (대화) ─┤──→  Bonfire 엔진 API  ──→  음악 모델 하나
   Live 브리지 (DAW)*    ─┘

   * 아직 안 지음 — 근데 경계를 정직하게 지키는
     상상의 두 번째 소비자야.

# 내장 UI 도 다른 것들과 SAME 엔드포인트를 써.
# 사설 뒷문 없음.

Exercise

아는 엔진/서비스의 클라이언트를 적어. 이제 아직 없는 그럴듯한 클라이언트를 하나 발명해(CLI, 모바일 앱, 서드파티 연동). 진짜 기능 하나를 걸으며 물어: 상상의 클라이언트가 공개 API 만으로 이걸 할 수 있나? 답이 아니오인 곳마다, 기존 클라이언트가 질러가는 자리를 찾은 거야.

Hint

지름길은 한 클라이언트가 '안에' 사는 곳에 숨어 — 같은 repo, 같은 프로세스, 같은 언어. 그게 정확히 API 를 건너뛰고 싶은 클라이언트고, 그 지름길이 제일 아픈 클라이언트야.