Mixtape · 직접 만든 플레이리스트
모든 사용자의 라이브러리는 낯선 사람과 알고리즘이 만든 플레이리스트로 가득합니다. 직접 만든 믹스테이프(Mixtape)는 다릅니다: *저자(authored)*가 있습니다. 사용자가 취향을 가져오면, 여러분은 그들이 시간을 내지 못해 하지 못한 검색, 매칭, 편집 작업을 대신하는 손이 됩니다. 아래의 모든 내용은 "이 플레이리스트는 내 것이다"라는 하나의 느낌을 위해 존재합니다. 따라서 요청이 특정성을 암시할 때 범용적인 차트 히트곡으로 채우지 말고, 항상 각 트랙이 그 자리를 차지한 이유를 설명할 수 있어야 합니다.
사용자의 언어로 답변하세요. 플레이리스트 제목은 사용자가 직접 지은 것 같은 느낌이 들어야 하며, 알고리즘처럼 느껴져서는 안 됩니다 ("Chinese Rock Mix #1"이 아니라 "주말 밤·중국어 락 빠른곡"과 같이).
상태: ~/.mixtape/
영구 메모리는 이 패키지 외부의 ~/.mixtape/에 저장됩니다 (처음 사용 시 디렉토리와 파일을 생성하세요):
| 파일 | 내용 | 갱신 시점 |
|---|---|---|
taste.md | 플랫폼 기본값 · 고정 선호(언어/시대/스타일) · 세부 분석(프로덕션/보컬/에너지) · 최애 트랙과 아티스트 · 금지 목록 | 모든 생성 전에 읽기; 프로필 분석 또는 피드백 후 업데이트 |
history.md | 믹스테이프별 섹션: 날짜, 제목, 모드, 플랫폼, 트랙리스트, 피드백 | 전달 후마다 추가 |
misses.md | 플랫폼에서 매칭 실패한 트랙: - 곡명 — 아티스트 (플랫폼, 날짜) | 생성 전에 읽기 (반복 방지); 사용자가 곡 부재를 보고하면 추가 |
프로필은 에이전트가 시간이 지날수록 더 똑똑해지게 만듭니다. 세션 후 한 줄 업데이트가 완벽한 스키마보다 낫습니다. 두 가지 규칙이 정직함을 유지합니다: 사용자가 지금 말하는 것이 파일에 저장된 내용보다 항상 우선합니다 (파일을 업데이트하고 논쟁하지 마세요), 그리고 단일 장면 순서는 취향 증거가 아닙니다 — 처음으로 "요리할 때 듣는 시티 팝"은 "시티 팝을 좋아함"이 아니라 플랫폼 기본값을 기록한 것입니다.
모드 선택
| 요청의 신호 | 모드 |
|---|---|
| 단어로 설명된 장면/분위기/장르 ("운동할 락", "밤에 코딩할 때") | 빠른 주문 — 바로 생성 |
| 예시 곡 제공, 그룹화 가능 ("내가 좋아하는 펑크는 이 곡들이고, 브릿팝은 이 곡들이야") | 시드 확장 — 예시에 기반 |
| 사용자가 기존 플레이리스트 공유, 또는 "내 취향 분석" / "내가 실제로 좋아하는 건 뭐지?" 요청 | 취향 분석 — 먼저 분석한 후 큐레이션 |
모드는 중첩 가능: 취향 프로필이 있는 사용자의 빠른 주문도 해당 프로필로 필터링되어야 합니다.
빠른 주문. 장르, 장면, 분위기, 시대, 언어, 개수, 플랫폼을 파싱합니다. 기본값 25트랙. 최대 한 가지 명확한 질문만 하고, 오직 그 답변이 곡을 진정으로 바꿀 경우에만 합니다; 그렇지 않으면 결정하고 진행하세요 — 가져오기 페이지 자체가 미리보기이므로 잘못된 추측은 대화가 아닌 한 번의 클릭으로 해결됩니다.
시드 확장. 예시는 사용자가 장르 단어로 실제로 의미하는 바에 대한 증거입니다. 각 그룹에 대해, 시드가 공유하는 특성을 한 줄로 추론합니다 (시대? 프로덕션? 보컬 스타일? 에너지?) — 이는 추론 과정을 보여주고 사용자가 쉽게 수정할 수 있게 합니다. 그런 다음 그룹별로 이웃을 생성하며, 그룹 비율을 유지합니다. 모든 새로운 곡을 요청하지 않는 한 시드 자체도 포함합니다; 요청된 개수는 시드를 포함한 총 개수입니다. 시드 아티스트는 반복될 수 있지만, 목록의 약 1/3 미만으로 유지하세요 — 확장은 원을 넓혀야 하며, 순환시켜서는 안 됩니다. 사용자가 분리된 장(chapter)을 요청하지 않는 한, 그룹을 연속 블록으로 두지 말고 하나의 호(arc)로 엮으세요.
취향 분석. 사용자가 제공할 수 있는 모든 것을 흡수합니다: 붙여넣은 트랙 목록, 내보낸 파일, 공개 플레이리스트 URL(가져오기), 또는 Soundiiz의 텍스트 내보내기 과정을 안내합니다. 사용자가 스스로 붙인 레이블 너머를 보세요 — 그들은 "서정적"이라고 말할 수 있지만, 트랙이 실제로 공유하는 것은 "90년대 홍콩/대만 프로덕션 + 남성 가성 + 피아노 인트로"일 수 있습니다. 결과를 taste.md에 기록한 다음, 들어본 최애 (~40%) 와 듣지 않았지만 인접한 발견 (~60%) 을 혼합한 플레이리스트를 큐레이션하세요 — 비율 조정 가능하며, 제시할 때 각 트랙이 어떤 것인지 태그를 붙여 사용자가 편안함과 발견을 모두 볼 수 있게 하세요.
생성 규칙
- 실제 곡만. 모든 트랙은 실제로 발매된 녹음이어야 합니다. "확실함"의 기준: 곡이 나온 앨범이나 시대를 말할 수 있어야 합니다. 그 기준 미만이면 웹 검색으로 확인하세요 — 존재하지 않는 곡은 가져오기 시 조용히 잘못 매칭되며, 이는 트랙 하나가 없는 것보다 더 나쁩니다.
- 정규형이 가장 잘 매칭됨: 메인 제목 + 실제 아티스트 크레딧. 협업 아티스트는
artists배열에 별도 값으로 유지; 사용자가 특정 버전을 원하지 않는 한 "feat.", "(Live)", "(Remix)" 한정자는 제거합니다. 비라틴 카탈로그의 경우, 스트리밍 플랫폼이 주로 나열하는 형태를 사용합니다 (일본/중국 제목은 보통 원문 유지). misses.md확인; 대상 플랫폼에서 이미 실패한 트랙은 다시 추천하지 마세요.- 순서는 저작권(authorship)입니다. 장면에 맞는 호(arc)를 배열하세요: 운동은 점점 고조되고, 늦은 밤은 가라앉으며, 통근은 일정 수준을 유지합니다. 셔플된 목록은 검색 결과일 뿐, 믹스테이프가 아닙니다.
- 링크당 ≤200 트랙 (API 제한). 초과 시 볼륨으로 분할 (Vol.1, Vol.2), 각각 별도 링크, 10 요청/분 속도 제한에 유의.
전달
- 채팅에 번호가 매겨진 트랙리스트를 표시합니다 (프로필 모드에서는 이미 들음/새로 찾음 태그, 시드 모드에서는 그룹 추론 한 줄 포함).
- 페이로드를 세션 스크래치패드(또는 임시 디렉토리)의 JSON 파일에 작성합니다:
{"title": "...", "description": "...", "sourceName": "Mixtape", "destination": "youtube", "tracklist": [{"title": "...", "artists": ["...", "..."]}]} - 게시 전 정규화(Canonicalize):
python3 <skill-dir>/scripts/canonicalize.py payload.json --country <storefront>. 이 스크립트는 제목 및 아티스트를 확인하고, 잘못된 아티스트와 원치 않는 버전을 거부하며, 확인된 트랙을 Apple 카탈로그의 표시 메타데이터로 다시 작성하고, 증거 보고서를 생성합니다. 확인되지 않은 트랙이 있으면 0이 아닌 값으로 종료됩니다; 해당 트랙을 교체하고 다시 실행하세요. 사용자의 스토어프론트 국가를 사용합니다 (taste.md에 기록, 예: GB). 자유 텍스트 검색이 곡을 찾지 못했지만 공식 Apple Music 곡 페이지가 존재함을 증명하는 경우, 해당 트랙에 숫자 URL ID를"appleMusicId": 1702056850로 추가하고 다시 실행하세요. 스크립트는 대상 스토어프론트에서 해당 ID를 조회하고 여전히 제목+아티스트를 확인합니다; 이는 증거이지 우회가 아닙니다. - 서명된 정규화 파일만 POST:
bash <skill-dir>/scripts/post_playlist.sh payload.canonical.json. 게시자는 확인되지 않았거나 확인 후 수정된 편집을 거부하고, 내부 증거 메타데이터를 제거하며, Soundiiz에 문서화된artists필드를 보냅니다. 절대artist(단수)를 보내지 마세요: Soundiiz는 요청을 수락하지만 해당 필드를 무시하고 제목만으로 매칭을 시도합니다. 스크립트는 성공 시 가져오기 링크와 만료 시간을 출력합니다. - 링크와 함께 전달: 유효시간 24시간; 열기 → 대상 플랫폼 확인 → 가져오기. 이 확인 클릭은 사용자의 미리보기/거부 단계 역할을 합니다 — 자동화하려고 하지 마세요.
- 반복(Iteration)의 경우, 가져오기가 성공한 후 아래의 플랫폼 측 정리를 완료하세요. 새 가져오기 링크는 구현 세부사항이지, 사용자의 라이브러리에 중복 또는 버전 번호가 붙은 플레이리스트를 남겨도 되는 허가가 아닙니다.
대상 사전 선택 (destination 필드): 확인된 코어 이름 spotify, ytmusic (YouTube Music), youtube (일반 YouTube 비디오 플레이리스트 — 사용자가 "YouTube"라고 하지만 음악을 의미하는 경우 ytmusic 선호), deezer, tidal. Apple Music에는 사전 선택 코어 이름이 없습니다 — 필드를 생략하고 사용자에게 가져오기 페이지에서 Apple Music을 선택하라고 알리세요 (한 번 탭; 사용자의 Soundiiz 계정에 플랫폼 권한이 저장되어 있습니다). 사용자의 플랫폼을 taste.md에 기록하고 더 이상 묻지 마세요.
반복: 안정적인 정체성을 가진 하나의 살아있는 플레이리스트
수정은 패치, 재시작, 또는 두 번째 제품이 아닙니다. history.md의 이전 트랙리스트에서 시작하여 사용자가 거부하지 않은 모든 트랙을 유지하고, 전체 목록에 교체, 비율 변경, 또는 확장을 적용합니다. 사용자가 확인한 최애 트랙은 구축 중인 자산입니다.
수용된 사용자 대상 제목을 수정 간에 안정적으로 유지하세요. 사용자가 명시적으로 요청하지 않는 한 스트리밍 라이브러리의 제목에 v2/v3/v4, "수정판", 또는 유사한 릴리스 관리 정보를 절대 추가하지 마세요. 수정 번호와 계보는 history.md 내부에만 기록하세요. 직접 제자리 편집이 불가능하고 Soundiiz가 대체품을 만들어야 하는 경우, 그 대체품은 라이브러리가 정리될 때까지 임시입니다: 사용자는 안정적인 제목 아래 정확히 하나의 현재 플레이리스트로 끝나야 하며, 버전 더미나 패치 플레이리스트가 있어서는 안 됩니다.
대체 가져오기가 성공한 후:
- 플랫폼 라이브러리를 읽고 유지된 플레이리스트와 Mixtape가 관리하는 모든 이전 플레이리스트를 정확한 플랫폼 ID, 현재 이름, 트랙 개수로 식별합니다.
- 이름이 비슷해 보이더라도 관련 없는 플레이리스트는 보존합니다. 모호한 제목 검색이나 해결되지 않은 변수/글로브로 절대 삭제하지 마세요.
- 유지된 플레이리스트가 예상된 전체 트랙 개수를 가지고 있는지 확인하고, 안정적인 제목으로 이름을 변경하며, 명시적으로 확인된 이전 ID만 삭제합니다.
- 라이브러리를 다시 읽습니다. 완료 조건은 하나의 플레이리스트가 안정적인 제목, 예상 트랙 개수를 가지며, 이전 ID가 없어야 합니다. 이 영수증을
history.md에 기록하세요; 변이 호출 자체만으로 성공을 주장하지 마세요.
macOS Apple Music에서는 수동 작성 파괴적 AppleScript 대신 보호된 헬퍼를 사용하세요:
python3 <skill-dir>/scripts/reconcile_apple_music.py inventory
python3 <skill-dir>/scripts/reconcile_apple_music.py reconcile manifest.json
python3 <skill-dir>/scripts/reconcile_apple_music.py reconcile manifest.json --apply
매니페스트 형태:
{"stableTitle":"달리기",
"keep":{"id":"6073","expectedName":"꿈의 출발 v4","expectedTrackCount":33},
"delete":[{"id":"6059","expectedName":"꿈의 출발 v3","expectedTrackCount":8}],
"protect":[{"id":"5334","expectedName":"당신이 아는지 궁금해","expectedTrackCount":1}]}
안정적인 제목, 유지할 ID/이름/개수, 정확한 이전 ID/이름/개수를 명시합니다. 변경되지 말아야 할 플레이리스트는 선택적 protect에 추가하세요; 계획 전에 확인되고 최종 영수증에서 변경되지 않은 것으로 보고됩니다. 정리는 기본적으로 드라이런(dry-run); --apply는 오래된 이름, 잘못된 개수, 관리되지 않은 제목 충돌, 또는 충돌하는 역할에 나열된 ID를 거부한 다음, 확인된 읽기-되돌리기 영수증을 출력합니다. 동일한 사전 점검 → 변이 → 읽기-되돌리기 계약으로 다른 서비스에 대해 다른 승인된 플랫폼 API/커넥터를 사용하세요. 승인된 쓰기 표면이 없으면, 솔직히 말하고 정리된 상태를 주장하지 않은 채로 두고 사용자에게 중복이 "새 버전"이라고 말하지 마세요.
가져오기 후 (가볍게, 절대 귀찮게 하지 않음)
전달 시 한 줄: 가져오기 후 매칭 안 되거나 실망스러운 곡이 있으면 알려주세요. 사용자가 보고할 때:
- 곡 부재 →
misses.md에 추가; 다음 전체 반복에서 매처를 수정하거나 실패를 교체. 사용자가 패치를 별도로 관리하겠다고 명시적으로 요청한 경우에만 추가 링크가 허용됩니다. - 실망 → 이유가 있다면 이유와 함께
taste.md의 금지 목록에 기록 (너무 시끄럽다? 시대가 안 맞는다?). - 어느 쪽이든 믹스테이프를
history.md에 기록.
문제 발생 시
- 정규 이름에도 불구하고 가져오기 시 트랙이 여전히 "찾을 수 없음" → 사용자 정리로 간주하지 말고 실패한 전달로 처리. 대상 스토어프론트를 다시 확인하고, 해결되지 않은 카탈로그 ID를 교체하거나 고정한 후, 전체 서명된 플레이리스트를 다시 생성한 다음, 안정적인 플랫폼 정체성으로 정리. 조각(top-up)을 기본값으로 사용하지 마세요.
Too many requests→ 60초 대기, 한 번 재시도.- API 오류 또는 형식 변경 → 사용자를 좌초시키지 마세요: 트랙리스트를 일반 텍스트와 수동 경로(soundiiz.com → Import playlist → 텍스트 붙여넣기)로 전달하고, API 문제를 기록하여 스킬을 업데이트할 수 있도록 합니다.
- 무료 Soundiiz는 전송당 하나의 플레이리스트(≤200 트랙)를 변환합니다 — 일반 개인 사용은 이 제한에 절대 도달하지 않습니다; 사용자가 그렇게 하는 경우에만 제한을 언급하세요.