MIR은 framework가 아니라 parts library

"librosa, Essentia, Demucs는 서랍 속 부품이지, 그 안에 들어가 살아야 할 틀이 아냐."

framework가 아니라 후보 부품

템포·비트·특징 추출·pitch·stem 분리 같은 MIR 문제에는 이미 여러 오픈소스 구현이 있어. 중요한 건 라이브러리 이름을 미리 확정하는 일이 아니라 Bonfire가 그 능력을 어떤 계약으로 쓰느냐야. 엔진을 특정 라이브러리 안에 짓지 않고, 후보 구현을 parts library로 취급해 Bonfire 인터페이스 뒤에 감춰. 엔진은 Demucs가 아니라 Bonfire의 StemSeparator에 의존해. 정확도, 유지보수 상태, 라이선스, 실행 비용을 비교해 구현을 바꿔도 위쪽 흐름은 그대로여야 해. 인터페이스는 소유하고 구현은 빌리는 거야.

Demucs로 살펴보는 stem 분리

Demucs v4 계열은 완성된 믹스를 드럼, 베이스, 보컬, 그리고 나머지 반주를 담는 'other' stem으로 나눌 수 있어. 다만 Meta의 원본 저장소는 지금 archived 상태고 적극적으로 유지되지 않아. 그러니 Bonfire의 영구 기반으로 이름부터 박을 게 아니라, 유지되는 fork나 다른 분리기와 함께 평가할 후보 구현으로 보는 게 맞아. 그 능력 자체는 학습 도구에 큰 가치를 줄 수 있어.

배울 파트를 분리해. 베이스 라인을 배우고 있다면 베이스 stem을 solo해 다른 소리를 줄일 수 있어.
대신 연주할 파트를 죽이고 나머지 위에서 쳐. 연습할 파트를 낮추고 나머지 stem을 남기면 반주 트랙처럼 쓸 수 있어.
stem별 분석을 시험해. 분리된 stem이 어떤 분석에는 더 나은 입력이 될 수 있지만, 분리 artifact도 생겨. 실제 곡 corpus로 정확도가 좋아지는지 검증해야 해.

무거운 일의 배치는 측정해서 정해

stem 분리는 연산과 메모리를 많이 쓸 수 있으니 첫 배치는 Python 백엔드가 자연스러워. 브라우저는 요청과 결과 재생에 집중하고, 가속기를 쓸 수 있는 서버가 분리를 맡는 구조야. 하지만 특정 Mac 사양이나 '절대 브라우저에서 안 돈다'는 말까지 제품 불변식으로 만들 필요는 없어. 구현과 하드웨어가 바뀌면 benchmark로 다시 정하면 돼. 지금 확정할 건 배치가 아니라 StemSeparator 계약과 평가 기준이야.

Code

분리기는 갈아 끼울 수 있는 adapter·python

class StemSeparator(Protocol):
    def separate(self, audio: AudioBuffer) -> dict[str, AudioBuffer]: ...

class DemucsAdapter:
    def separate(self, audio: AudioBuffer) -> dict[str, AudioBuffer]:
        return demucs_apply(audio)  # -> {drums, bass, vocals, other}

# 같은 corpus로 후보 구현을 비교:
#   품질 / artifact / 실행 시간 / 메모리 / 유지보수 / 라이선스
#
# 엔진은 StemSeparator 계약을 알아. 특정 분리기는 adapter 안에 갇혀.

Exercise

많이 의존하는 라이브러리 하나를 골라. 내년에 위쪽을 건드리지 않고 갈아 끼우려면 코드가 어떤 얇은 인터페이스를 불러야 할지 써 봐. 그다음 후보 구현을 비교할 기준도 적어. 정확도만 말고 유지보수 상태, 라이선스, 실행 비용까지 넣어.

Hint

같은 인터페이스 뒤에서 완전히 다른 구현으로 바꿔도 호출자가 그대로인지 확인해. 호출자가 곳곳에서 라이브러리 고유 타입과 관용구를 쓴다면 부품으로 감싼 게 아니라 그 framework 안에 들어가 산 거야.