2024년 11월 Spotify가 새로운 앱에 대해 Audio Features, Recommendations, Related Artists 기능을 지원 중단(deprecated)했을 때, 이를 대체하기 위한

알아두면 좋은 두 가지 사항: bpm과 key는 항상 존재하며 null이 아니며, ?wait=10은 바운디드 동기식 모드(bounded synchronous mode)를 활성화합니다 — 최대 25초까지 지원하며, 트랙이 캐시되지 않은 경우 기본값인 202 + Retry-After 대신 분석된 트랙을 인라인으로 200 코드를 반환받습니다.

차별점: 호출할 수 있는 하모닉 믹싱(harmonic mixing)

Camelot 시스템 (Camelot wheel)으로 30초 만에 이해하기

모든 음악적 키는 **카멜롯 휠(Camelot wheel)**의 클락 위치에 매핑됩니다: 숫자 1–12와 알파벳 한 글자(A = 마이너, B = 메이저)로 구성됩니다. 두 트랙은 다음 세 가지 경우에 키 충돌 없이 섞일 수 있습니다: 동일한 키, 상대적인 메이저/마이너(같은 숫자, 반전된 알파벳), 또는 인접한 +1/-1 이웃입니다. 점프 +7은 클래식 에너지 부스트 믹스를 만들어냅니다.

find_compatible_keys는 순수 이론적 기능이며, 카탈로그 검색에 사용하거나 할당량(quota)을 소모하지 않습니다:

// find_compatible_keys(camelot="8A", extended=true)
{
  "camelot": "8A",
...

실제 전환 점수 매기기 (Scoring an actual transition)

어떤 키가 섞일 수 있는지 아는 것은 기본입니다. score_transition은 한 실제 트랙이 다른 트랙으로 얼마나 잘 믹스되는지, 0–100 사이의 점수로 평가합니다. 이 과정에서 카멜롯 키 호환성, 옥타브를 고려한 BPM 근접도(하프/더블 타임도 일치로 간주), 에너지 부드러움 등을 종합하여 인간이 이해할 수 있는 이유까지 제공합니다:

// score_transition(from_track_id="apple_ad1829eeccb70f9a",
//                  to_track_id="apple_7c1120fbe0")  — 쿼터 1 소모
{
...

이러한 쌍별 판단(pairwise judgement)을 제공하는 원시 키/BPM 엔드포인트는 어디에도 없습니다. 이 기능 자체가 제품입니다.

하나의 선택에서 전체 세트 구성까지 (From one pick to a whole set)

suggest_next_track은 현재 재생 중인 트랙을 받아 다음에 재생할 상위 N개의 카탈로그 트랙을 반환합니다. 각 트랙에는 동일한 점수, 구성 요소 및 이유가 포함됩니다(예: `

build_setlist는 전체 크레이트 (2~100개 트랙)를 에너지 arc (곡선) — peak_time (피크 타임), warmup (웜업), cooldown (쿨다운), 또는 flat (플랫) — 에 맞춰 비트 매칭 (beat-matched)된 세트로 정렬하며, 모든 연속적인 전환이 화성적(harmonically)이고 템포가 매끄럽게 유지되도록 합니다. 이 함수는 전체 flow_score (흐름 점수), 재생 순서대로 정렬된 트랙들, 그리고 단계별 전환 정보를 반환합니다.

MCP를 통해 에이전트가 수행하게 하기

이 지점부터 이것은 단순한 API를 넘어 모델에게 부여하는 하나의 기능 (capability)이 됩니다. 어떤 MCP 클라이언트든 다음을 가리키게 하세요:

이를 통해 12개의 도구 — search_catalog, get_audio_features, get_audio_features_batch, find_tracks_by_bpm, find_tracks_by_key, find_compatible_keys, get_recommendations, get_related_artists, score_transition, suggest_next_track, build_setlist, tag_track — 가 노출됩니다. 에이전트는 이 도구들을 스스로 조율(orchestrate)합니다. "이 10개의 트랙으로 90분짜리 peak-time 세트를 만들어줘" 와 같은 단일 프롬프트는 다음과 같이 변환됩니다:

1. 각 모호한 이름에 대해 search_catalog 실행 → 구체적인 itunes_track_id 확보
2. build_setlist(track_ids=[...], arc="peak_time") 실행 → 정렬된 세트 + flow_score 획득
3. 정렬된 itunes_track_id들을 GET /export/rekordbox (traktor, m3u, cuesheet, csv 도 가능)에 전달하여 크레이트를 DJ 소프트웨어에 바로 투입

사용자 측에서 조율(orchestration) 코드를 작성할 필요가 없습니다. 도구 설명(tool descriptions)만으로도 모델이 도구들을 체이닝(chaining)하기에 충분하기 때문입니다. 세트 빌더 도구들은 단순 조회보다 쿼터 (quota)를 조금 더 소모합니다 (score_transition 1, get_recommendations 2, suggest_next_track 3, build_setlist 5). 각 도구가 실제 조합론적 작업 (combinatorial work)을 수행하기 때문입니다.

인증 (Auth), REST, 그리고 가격

인증은 X-Api-Key 헤더를 사용합니다 (브라우저 및 이메일 링크를 위한 ?key= 쿼리 폴백 방식도 존재합니다). MCP 클라이언트를 실행하고 싶지 않다면, 위의 모든 기능은 일반적인 REST 방식으로도 사용할 수 있습니다 — GET /transition, GET /next-track, POST /setlist, GET /similar?track_id=... — RapidAPI에서도 이용 가능합니다. 가격은 £0.17/1k부터 시작하며, 무료 티어는 월 1,000회 요청을 제공하므로 세트 플래너를 프로토타이핑하기에 충분합니다.

솔직한 한계점 (Honest gaps)

• 카탈로그에 종속적입니다 (It's catalog-bound). 세트 빌더 도구는 카탈로그의 itunes_track_id를 기반으로 작동하므로, 트랙이 먼저 조회(search_catalog / /lookup)되어야 합니다. 커버리지는 방대하지만 보편적이지는 않습니다. 니치(niche)하거나 지역적인 카탈로그에는 공백이 있을 수 있습니다.
• Spotify-ID 조회는 매핑된 일부 하위 집합에만 적용됩니다. Spotify ID를 키(key)로 사용한다면 누락이 발생할 수 있습니다. 곡 제목이나 ISRC로 조회하는 것이 훨씬 더 안정적입니다.
• 기능(Features)은 계산된 값이며, 절대적인 진리가 아닙니다. BPM/Key/Energy는 오디오 분석(Essentia)을 통해 도출됩니다. 때때로 조회가 동일한 제목의 잘못된 녹음본과 일치할 수도 있습니다.
• 오디오 호스팅이나 스트리밍을 제공하지 않습니다. 기능(features)과 메타데이터를 반환받으며, 업로드 기반의 /analyze 및 /identify 기능을 제공할 뿐 오디오 자체를 제공하지는 않습니다.
• 비트그리드(beatgrid)나 웨이브폼(waveform) 편집 기능이 없습니다. 세트를 계획하고 순서를 정할 뿐, 큐 포인트(cue points)를 대신 워핑(warp)해주지는 않습니다.

시도해보기 (Try it)

**api.freqblog.com/docs**에서 무료 키와 OpenAPI 문서를 받거나, **freqblog.com**에서 API에 대해 더 자세히 알아보세요. 음악을 추천, 시퀀싱 또는 추론하는 무언가를 구축하고 있다면 — 특히 LLM이 루프(loop)에 포함되어 있다면 — MCP 엔드포인트는 여러분의 에이전트에게 실제로 무엇이 잘 믹싱되는지에 대한 '귀'를 달아줄 수 있는 가장 빠른 방법입니다.