클라이언트 셋, 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도 다른 것들과 똑같은 엔드포인트를 써.
# 사설 뒷문은 없어.

Exercise

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

Hint

지름길은 클라이언트 하나가 '안쪽에' 살고 있는 자리에 숨어. 같은 repo, 같은 프로세스, 같은 언어. 그게 바로 API를 건너뛰고 싶어 하는 클라이언트고, 그 지름길이 가장 아프게 돌아오는 클라이언트야.