Live는 API를 주지만 핵심으로는 안 맞아

"진짜 API는 필요조건이지 충분조건이 아냐. 열린 범위와 제품의 핵심 일이 맞아야 해."

Live는 공식 object model을 열어

Ableton Live가 흥미로운 이유는 Max for Live를 통해 공식 Live Object Model(LOM)을 제공하기 때문이야. LOM은 Live Set의 트랙, 클립, 장치, 파라미터를 탐색하고 일부 값을 읽고 쓰거나 관찰하게 해. 오디오 클립의 파일 경로와 warp marker 같은 정보도 공식 모델에 들어 있어. 다만 LOM의 공식 실행 문맥은 Max for Live고, ableton-js 같은 외부 Node 연결은 그 위에 놓인 제3자 bridge야. 둘을 같은 수준의 공식 API라고 부르면 안 돼.

열린 문과 Bonfire의 핵심 일은 별개야

Ableton Live                 범위 / 맞음                    판정
------------                 ----------                    ----
LOM via Max for Live         세션·트랙·클립·장치 접근       공식 API 있음
오디오 clip file_path        MIR로 넘길 입력 경로           adapter 후보
코드·키·stem 분석 서비스     Bonfire 핵심 분석              LOM 제공 아님
아빠의 주 작업 호스트        실제로 어디서 일하나           Logic

LOM이 오디오를 전혀 못 본다는 말도 틀려. 오디오 클립의 파일 경로와 재생·warp 정보를 읽을 수 있으니 Bonfire 분석으로 넘기는 adapter 후보는 될 수 있어. 하지만 LOM 자체가 오디오를 코드·키·stem으로 분석해 주는 건 아냐. 그 핵심 일은 여전히 Bonfire의 MIR 레이어가 맡아야 해. 게다가 아빠의 주 작업 호스트는 Logic이니, Live를 Bonfire의 필수 집으로 삼을 이유도 없어.

교훈. 공식 범위, 값어치, 실제 작업 자리를 따로 봐

Live는 'API가 있으면 곧 호스트다'라는 결론이 왜 성급한지 보여줘. 먼저 공식 API와 제3자 bridge를 구분하고, 그 표면이 제품의 핵심 기능을 직접 주는지 아니면 입력만 건네는지 나눠 봐. 마지막으로 실제 유저의 작업이 거기서 돌아가는지도 확인해. 이 세 질문을 거치면 Live는 Bonfire의 핵심 의존성보다 선택 입력 adapter 후보에 가까워져.

Code

Live 채점표. 공식 API와 제품에 맞는지를 갈라 봐·text

Ableton Live                 범위 / fit                    판정
------------                 ----------                    ----
LOM via Max for Live         세션·트랙·클립·장치 접근       공식 API 있음
오디오 clip file_path        MIR로 넘길 입력 경로           adapter 후보
코드·키·stem 분석 서비스     Bonfire 핵심 분석              LOM 제공 아님
아빠의 주 작업 호스트        실제로 어디서 일하나           Logic

# API가 있다고 핵심 호스트로 채택되는 건 아냐.
# Live는 필수 거처보다 선택 입력 adapter 후보에 가까워.

Exercise

문서화된 API가 있는 도구 하나를 골라 세 칸으로 나눠 봐. 공식 API가 직접 주는 것, 제3자 bridge가 덧붙이는 것, 네 제품이 여전히 직접 해야 하는 것. 마지막으로 실제 유저의 주 작업이 그 호스트에서 돌아가는지도 적어. 그러고 나서야 핵심 의존성인지 선택 adapter인지 판정할 수 있어.

Hint

API가 풍부해도 제품의 핵심 일을 대신하지 않고 입력만 건넬 수 있어. 그건 실패가 아니라 역할이 다른 거야. 호스트와 adapter, 분석 엔진을 같은 칸에 넣지 마.