기술 레퍼런스

음원 릴리스 메타데이터: 한글 표기와 유통 체인을 통과하는 법

검토일 2026-09-07

아티스트명, 트랙 제목, 참여 아티스트, 버전 표기 — 그리고 한글 정규화라는, 아무도 설명해 주지 않는 실패.

짧은 답

메타데이터는 음악에 붙은 서류가 아니라, 유통 체인 아래쪽의 모든 시스템에게는 그 자체가 음악입니다. 스트리밍 서비스는 당신의 음원을 듣지 않고 당신의 딜리버리를 읽습니다. 한국어 릴리스에서 가장 비싸고 가장 덜 알려진 결함은 한글 정규화입니다 — 화면에는 똑같이 "가야금"으로 보이지만 메모리에는 3코드포인트(완성형)일 수도, 7코드포인트(조합형)일 수도 있고, 이 둘은 어떤 검색·매칭·정렬 시스템에서도 영원히 만나지 않습니다. 그 다음이 로마자 표기입니다: 김/Kim/Gim, 이/Lee/Yi/Rhee — 한 사람이 네 개의 라틴 표기를 쓰면 스토어에는 네 개의 아티스트가 생깁니다. 그리고 작곡·작사 필드는 스토어 화면에 절대 노출되지 않기 때문에, 틀려도 아무 증상이 없는 채로 몇 년씩 저작권료가 미분배 상태로 남습니다. 메타데이터는 모든 플랫폼이 읽고 어떤 청취자도 보지 않는 유일한 영역이며, 바로 그래서 조용히 실패합니다.

왜 나중에 고칠 수 없는가

메타데이터 오류의 비용은 시간에 대해 비대칭입니다. 딜리버리 전 10분 동안은 거의 공짜로 예방되고, 딜리버리 후에는 느리고 흔히 불가능합니다. 이유는 단순합니다 — 당신이 오류를 발견할 무렵이면 이미 수십 개의 시스템이 그것을 복사해 갔기 때문입니다.

한 번의 딜리버리는 각 목적지의 카탈로그 DB로 들어가고, 거기서 검색 색인, 추천 시스템의 학습 데이터, 정산 원장, 파트너 API를 통한 서드파티 서비스, 가사 제공사, 메타데이터 애그리게이터로 퍼집니다. 나중에 유통사를 통해 수정을 보내면, 그 수정은 원본이 갔던 모든 곳에 같은 속도로 도달하지 않습니다. 어떤 목적지는 며칠 만에 반영하고, 어떤 목적지는 특정 필드를 발매 후 수정 대상으로 받지 않으며, 어떤 필드는 애초에 불변으로 설계되어 있습니다.

그리고 가장 비싼 오류는 반려되지 않습니다. 문법적으로 유효한 아티스트명, 유효한 제목, 유효한 ISRC는 검증을 통과합니다. 검증은 문자열이 규격에 맞는지를 볼 뿐, 그것이 당신이 의도한 문자열인지는 볼 수 없습니다. 조합형으로 들어간 아티스트명은 완벽하게 유효한 유니코드 문자열입니다.

완전한 음원과 망가진 메타데이터를 가진 릴리스는, 상업적으로는 발매되지 않은 릴리스와 같게 행동합니다. 존재하고, 재생되고, 그리고 아무것도 올바른 사람에게 쌓이지 않습니다.

1. 메타데이터가 놓이는 세 층위

릴리스는 하나의 덩어리가 아니라 계층입니다. 릴리스(release) 라는 상품 안에 레코딩(recording), 즉 트랙이 들어 있고, 각 레코딩은 하나 이상의 작품(work), 즉 곡을 구현합니다. 층마다 식별자가 다르고 — UPC/EAN, ISRC, ISWC — 층마다 돈의 경로가 다릅니다. 비싼 메타데이터 사고의 거의 전부는 사실을 엉뚱한 층에 기입한 것입니다. 전송 규격은 표준화되어 있습니다. DDEX의 ERN(Electronic Release Notification Message Suite) 이 릴리스와 그 메타데이터를 서비스에 전달하는 메시지 형식입니다.

각 필드가 실제로 통제하는 것:

메인 아티스트(Primary artist). 이 필드가, 오직 이 필드만이, 트랙이 어느 아티스트 페이지에 붙을지, 누가 청취자 수·팔로워·알고리즘 이력을 축적할지 결정합니다. Spotify의 공개 가이드는 명시적입니다: "List each artist's name in a separate field."(각 아티스트 이름을 별도 필드에 기입하라.)
참여 아티스트(Featured artist). 같은 레코딩 위의 별도 역할입니다. Apple 스타일 가이드는 참여 아티스트를 트랙 레벨에서 Featuring 또는 With 역할로 넣도록 하며, "not as Primary"(메인으로 넣지 말 것)라고 못박습니다.
리믹서(Remixer). 역시 역할입니다. Apple: "Remix tracks...must list the original artist as Primary with the remixer assigned the remixer role." 리믹서를 메인 아티스트로 올리는 것이 리믹스 카탈로그가 원 아티스트 페이지를 오염시키는 경로입니다.
작곡가·작사가. 작품을 서술하는 필드이며 레코딩을 서술하지 않습니다. 저작권료(공연·복제 사용료)의 추적은 전적으로 여기서 시작합니다.
프로듀서. 기여자 역할. 페이지도 아니고 음원 측 수익 배분도 아닙니다.
버전/부제. 같은 제목을 가진 두 레코딩을 구별하는 괄호 안의 문자열. 8장에서 다룹니다.
19금(Explicit) 플래그. 단어가 아니라 불리언입니다. Apple: "Explicit content must be flagged Explicit with a parental advisory tag. Terms like (Explicit)...must not be used for album...or track titles." Spotify도 "you shouldn't add it to your track title." Music Biz 가이드는 그 반대 방향도 금지합니다 — 제목에 "Clean"이나 "Non-explicit"을 쓰지 마십시오.
가사 언어(무엇이 불리는가)와 제목 언어(제목 문자열의 언어와 문자 체계)는 서로 다른 필드이고, 정당하게 서로 다를 수 있습니다. 가사 없는 가야금 산조 연주곡은 가사 언어가 없지만 제목 언어는 한국어입니다. 제목 언어는 스토어가 당신의 텍스트를 어떻게 정렬하고 색인하고 렌더링할지를 지시합니다. 비라틴 문자 딜리버리에서 가장 결과가 큰 필드 중 하나입니다.
P라인은 연도 + 음원의 권리자이고, 그 연도는 그 레코딩이 최초로 공표된 해이지 당신이 업로드한 해가 아닙니다. C라인은 연도 + 아트워크와 패키지의 권리자입니다. 서로 바꿔 쓸 수 없는데도 습관적으로 복사·붙여넣기 됩니다.
장르. 취향의 서술이 아니라 라우팅 신호입니다. 어떤 에디토리얼·알고리즘 맥락에 노출될 자격이 생기는지를 좌우합니다. 국내 릴리스에서는 트로트, 국악, 인디, 발라드처럼 실제로 서비스가 운용하는 분류와 당신이 쓰고 싶은 말이 어긋나는 일이 잦습니다.
발매일은 이 상품이 서비스에 열리는 날, 최초 발매일(original release date) 은 그 레코딩이 어디서든 처음 공표된 날입니다. 2016년에 녹음·발표한 판소리 음원을 2026년 최초 발매일로 올리면, 하류의 모든 시스템은 그것을 신보로 취급합니다.

식별자, 정확히. ISRC는 12자입니다: 국가 2 + 등록자 3 + 참조연도 2 + 지정번호 5. 하이픈은 표시 관례일 뿐 코드의 일부가 아니며, ISRC에는 체크디짓이 없습니다. UPC-A는 12자리, EAN-13은 13자리이고, 앞에 0을 붙이면 UPC-A가 EAN-13이 되며 체크디짓은 바뀌지 않습니다. ISRC는 레코딩을 식별하므로 동일 음원의 재발매에는 새 ISRC가 필요 없고, 유통사를 바꿔도 코드는 그 레코딩에 남습니다. 반면 리믹스, 편집본, 라이브 버전, 연주(Instrumental) 버전은 실질적으로 다른 레코딩이므로 각자의 코드가 필요합니다. 리마스터는 좁은 경우입니다. IFPI ISRC 핸드북 §A.10.1은 새 코드를 요구하는 조건을 "the processes applied to a recording during re-mastering involve the application of creative input to the recording itself"(리마스터링 과정에 그 녹음 자체에 대한 창작적 개입이 적용되는 경우)로 한정하고, 단순 레벨 조정, 불변 EQ, 불변 컴프레션, 노이즈 제거, 클릭 제거, 속도·피치 보정, 샘플레이트 변환, 디더링은 명시적으로 제외합니다. 안전하게 말할 수 있는 실무 단서 하나: 리마스터를 원본과 나란히 별도 트랙으로 판매한다면 그것은 별도 상품이므로 자체 코드가 필요합니다.

어떤 사실이 릴리스·레코딩·작품 중 어느 층에 속하는지 말할 수 없다면, 아직 그것을 기입할 준비가 되지 않은 것입니다.

2. 한글 정규화 — 이 문서의 핵심

한국어 릴리스에서 발생하는 메타데이터 사고 중 가장 파괴적이고 가장 이해되지 않은 것이 이것입니다. 아랍 문자권의 양방향 텍스트 문제, 라틴 문자권의 발음부호 문제에 해당하는 한국어의 고유 문제가 바로 완성형과 조합형의 이중 표현입니다. 그리고 이 문제의 잔인한 점은, 눈으로는 절대 감사(audit)할 수 없다는 것입니다.

2.1 완성형 음절과 조합형 자모

유니코드에는 한글을 담는 방식이 둘 있습니다.

완성형(precomposed) 한글 음절은 Hangul Syllables 블록, U+AC00 ~ U+D7A3 에 있습니다. 이 영역은 U+AC00 HANGUL SYLLABLE GA 에서 U+D7A3 HANGUL SYLLABLE HIH 까지 정확히 11,172자이고, 한 음절이 정확히 1코드포인트입니다.

조합형(decomposed) 결합 자모(conjoining jamo) 는 Hangul Jamo 블록, U+1100 ~ U+11FF 에 있습니다. 초성(choseong)은 U+1100부터, 중성(jungseong)은 U+1161부터, 종성(jongseong)은 U+11A8부터입니다. 여기서는 한 음절이 초성+중성 2코드포인트, 받침이 있으면 3코드포인트로 표현됩니다.

두 표현은 유니코드가 정의하는 정준 등가(canonical equivalence) 관계입니다. UAX #15는 정준 등가를 "which when correctly displayed should always have the same visual appearance and behavior"(올바르게 표시되었을 때 언제나 동일한 시각적 외형과 동작을 가져야 하는 관계)로 정의하고, 그 예시 표에서 한글을 직접 들고 있습니다: "Hangul & conjoining jamo 가 ↔ ᄀ+ᅡ".

"올바르게 표시되었을 때 동일한 외형" — 이것이 문제의 전부입니다. 화면에서는 같습니다. 바이트에서는 다릅니다. 그리고 스토어의 매칭·검색·정렬 로직은 화면이 아니라 바이트를 봅니다.

2.2 직접 확인한 것

주장이 아니라 실측이 필요합니다. Python 3.11의 unicodedata 모듈(유니코드 데이터베이스 버전 14.0.0)로 네 가지 정규화 형식을 한글에 직접 적용해 확인한 결과는 다음과 같습니다.

단일 음절 "한" (U+D55C):

형식	코드포인트 수	코드포인트	UTF-8 바이트
NFC	1	U+D55C	3
NFD	3	U+1112 U+1161 U+11AB	9
NFKC	1	U+D55C	3
NFKD	3	U+1112 U+1161 U+11AB	9

"가야금" (3음절):

형식	코드포인트 수	UTF-8 바이트
NFC	3	9
NFD	7	21
NFKC	3	9
NFKD	7	21

("가"와 "야"는 받침이 없어 2자모, "금"은 받침이 있어 3자모 — 합계 7입니다.)

성씨 세 개: 김 = U+AE40 → NFD U+1100 U+1175 U+11B7. 박 = U+BC15 → NFD U+1107 U+1161 U+11A8. 정 = U+C815 → NFD U+110C U+1165 U+11BC. 모두 완성형 1코드포인트 3바이트, 조합형 3코드포인트 9바이트입니다.

여기서 정확히 읽어내야 할 사실 네 가지:

NFC와 NFKC는 한글 음절에 대해 결과가 같습니다. NFD와 NFKD도 서로 같습니다. 즉 완성형 한글 음절에 대해서는 호환 분해(K)가 추가로 하는 일이 없습니다. UAX #15가 표로 명시하는 그대로입니다: "Hangul syllables are maintained under normalization."(한글 음절은 모든 정규화 형식에서 유지된다.) 이는 우연이 아니라 설계입니다 — UAX #15의 각주는 유니코드 2.1.9에서 자모 문자의 호환 매핑을 제거했다고 밝힙니다: "These mappings were removed in Unicode 2.1.9 to ensure that Hangul syllables would be maintained."
NFD는 바이트 길이를 정확히 3배로 만듭니다. 받침 있는 음절 기준 3바이트 → 9바이트. 받침 없는 음절은 3 → 6바이트. 실제 제목 "산조 아리랑 (해금 버전)"으로 재보면 NFC 14코드포인트·32바이트 → NFD 27코드포인트·71바이트입니다. 바이트 길이 제한이 걸린 필드에서 조합형 문자열은 완성형보다 두 배 넘게 자리를 먹고, 잘림(truncation)은 자모 중간에서 발생합니다. 잘린 조합형 문자열은 렌더링하면 홀로 남은 종성이 깨진 네모로 보입니다.
정렬 순서가 완전히 갈립니다. 조합형 문자열은 U+1100대에서 시작하고 완성형은 U+AC00대에서 시작하므로, 코드포인트 정렬에서 조합형 "가야금"은 완성형 "나비"보다도 앞에 오고, 완성형 "가야금"보다도 앞에 옵니다. 실측: NFD "가야금"의 첫 코드포인트 U+1100 < 완성형 "나비"의 첫 코드포인트 U+B098. 즉 조합형 항목들은 트랙 리스트에서 한글 구역 앞의 별도 블록으로 뭉쳐 앉습니다. 앨범 트랙 순서가 이상하게 뒤집혀 있다면 이것이 원인일 수 있습니다.
문자열 비교와 부분 문자열 검색이 실패합니다. 실측: 완성형 "김"은 조합형 "김광석" 문자열 안에서 찾아지지 않습니다. 정규화하지 않는 검색 레이어에서 이는 곧 "검색해도 안 나옴"입니다.

2.3 왜 조합형 문자열이 당신의 작업 폴더에 이미 들어와 있는가 — macOS

이것이 한국 제작 현장에서 조합형이 유입되는 압도적 1번 경로입니다.

Apple의 기술 문서 Technical Note TN1150 (HFS Plus Volume Format) 은 명시합니다: "HFS Plus stores strings fully decomposed and in canonical order."(HFS Plus는 문자열을 완전히 분해된 형태로, 정준 순서로 저장한다.) 대소문자 구분 변형인 HFSX 절에서도 되풀이합니다: "The names are fully decomposed and in canonical order."

즉 맥에서 "가야금 산조 01.wav"라는 파일명을 만들면, 파일 시스템에 기록되는 것은 조합형입니다. 당신이 완성형으로 타이핑했더라도 그렇습니다. 그리고 그 파일명을 ls, Finder, DAW의 파일 브라우저, 파이썬 스크립트, 엑셀 붙여넣기 중 어느 경로로든 텍스트로 꺼내면 조합형 문자열이 따라 나옵니다.

정확히 말해 HFS+가 쓰는 분해는 표준 NFD와 완전히 동일하지는 않습니다(Apple은 일부 코드포인트 구간을 분해 대상에서 제외합니다). 그러나 한글 음절 영역에 대해서는 실질적으로 NFD와 같게 동작하며, 실무에서 문제가 되는 것은 오직 이 부분입니다. APFS로 넘어오면서 동작이 바뀌었고 Apple이 APFS의 정규화 처리를 TN1150만큼 명확하게 문서화하지는 않았지만, 현장에서 맥을 거친 파일명이 조합형으로 도착하는 현상은 여전히 관측됩니다. 이 문서는 APFS의 내부 동작을 단정하지 않습니다 — 단정할 필요도 없습니다. 실무 규칙은 어느 쪽이든 같습니다: 출처가 파일명인 문자열은 무조건 정규화한 뒤에 쓰십시오.

2.4 실제 사고: 트랙 시트와 입력 폼이 만나는 지점

이것이 현장에서 벌어지는 모습입니다.

엔지니어가 맥에서 믹스를 뽑고, 파일명을 정리합니다: 01 산조 아리랑.wav, 02 장구 인터루드.wav. 트랙 시트를 만들려고 터미널에서 파일 목록을 뽑아 스프레드시트에 붙여넣습니다. 이 시점부터 시트 안의 모든 한글은 조합형입니다.

레이블 담당자는 유통사 입력 폼에 아티스트명 "달빛사물놀이"를 키보드로 직접 타이핑합니다. 윈도우와 macOS의 한글 IME는 완성형 음절을 만들어 냅니다. 폼에 들어간 것은 완성형입니다.

이제 두 문자열이 존재합니다. 화면에서는 동일합니다. 폰트를 바꿔도, 확대해도, 다른 사람이 검토해도 동일합니다. 하지만 시트의 "달빛사물놀이"로 폼의 "달빛사물놀이"를 검색하면 0건이 나옵니다. 스프레드시트의 =A2=B2는 FALSE를 반환합니다. VLOOKUP은 #N/A를 반환합니다. 담당자는 "엑셀이 이상하다"고 결론 내리고 수작업으로 넘어갑니다.

더 나쁜 경로는, 조합형 아티스트명이 그대로 딜리버리에 실려 나가는 경우입니다. 스토어의 매칭 로직에게 그것은 기존 아티스트와 다른 문자열입니다. 신규 아티스트 페이지가 생깁니다. 이전 릴리스의 팔로워는 따라오지 않고, 새 페이지는 알고리즘 이력이 0인 상태로 시작합니다. 저작인접권료는 지급되지만 두 개의 누적 이력에 나뉘어 지급되고, 카탈로그 단위로 측정되는 모든 것 — 에디토리얼 검토, 애널리틱스, 아티스트 인증 — 은 반토막 난 커리어 위에서 측정됩니다.

갈라진 아티스트 페이지는 고치는 버그가 아니라, 스토어마다 따로 접수하고 결과를 기다리는 청구입니다. 유통사는 각 스토어에 병합을 요청하고, 스토어마다 별도의 대기열과 별도의 증빙 요건으로 처리합니다. 빨리 되는 곳도 있고, 끝내 되지 않는 곳도 있습니다.

공개되지 않은 사항으로 표시함. 스토어가 어떤 임계값과 어떤 증빙으로 아티스트 페이지 병합을 승인하는지, 그리고 어떤 내부 매칭 로직으로 딜리버리를 기존 아티스트에 붙일지 새로 만들지 결정하는지 — 이것을 공개한 서비스는 없습니다. 업계에서 널리 회자되지만 서비스가 공표한 사양이 아닙니다. 이 문서는 그 값을 제시하지 않습니다.

2.4.1 왜 아무도 이것을 발견하지 못하는가

이 결함군이 특별히 오래 살아남는 이유는 검출 수단이 전부 무력하기 때문입니다.

눈은 무력합니다. 완성형과 조합형은 정상적으로 렌더링되면 동일합니다. 폰트를 바꿔도, 확대해도, 다른 사람이 봐도 같습니다.

복사·붙여넣기 검증도 무력합니다. 시트의 문자열을 복사해 폼에 붙여넣으면 조합형이 그대로 들어갑니다. 사람은 "똑같은 걸 붙여넣었다"고 확신하는데, 실제로는 폼에 원래 있던 완성형 문자열을 조합형으로 바꿔치기한 것입니다.

스토어 화면 확인도 무력합니다. 릴리스가 나간 뒤 스토어 페이지를 열어 보면 아티스트명이 정확히 맞게 보입니다. 다만 그것이 새로 만들어진 페이지라는 사실은 페이지만 봐서는 알 수 없습니다. 팔로워 수가 0인 것을 보고서야 이상하다고 느끼는데, 신인 아티스트라면 그것조차 이상하지 않습니다.

발견되는 시점은 보통 몇 달 뒤, 누군가가 "왜 내 앨범이 내 페이지에 없지?"라고 물을 때입니다. 그때는 이미 여러 목적지에 복제된 뒤입니다.

따라서 유일하게 작동하는 검출 방법은 문자열을 사람이 아니라 기계에 보여 주는 것입니다. 코드포인트를 출력하거나, NFC 정규화 결과가 원본과 같은지 비교하거나, 도구를 쓰십시오. 한 줄이면 됩니다.

2.5 반각 자모 (U+FFA0~)와 NFKC

Halfwidth and Fullwidth Forms 블록에는 반각 한글 자모가 있습니다. U+FFA0부터 시작하며, 예를 들어 U+FFA1은 HALFWIDTH HANGUL LETTER KIYEOK입니다. 옛 단말 에뮬레이션, 일부 자막 워크플로, 오래된 일본어·한국어 혼용 시스템에서 흘러나옵니다.

실측 결과입니다. 반각 자모 세 개 U+FFA1 (반각 ㄱ) + U+FFC2 (반각 ㅏ) + U+FFAB (반각 ㄻ) 를 각 형식으로 처리하면:

NFC: 변화 없음. 3코드포인트 그대로.
NFD: 변화 없음. 3코드포인트 그대로.
NFKC: U+AC0A "갊" 한 글자로 바뀝니다. 3코드포인트 → 1코드포인트.
NFKD: U+1100 U+1161 U+11B1 — 결합 자모 3개.

즉 반각 자모를 치우는 것은 오직 호환 정규화(NFKC/NFKD)뿐입니다. 정준 정규화(NFC/NFD)는 반각 자모를 손대지 않습니다. 반각 자모가 남아 있는 아티스트명은 그 자체로 별개의 문자열이고, 아무도 그렇게 타이핑하지 않으므로 검색으로 영원히 도달되지 않습니다.

그런데 NFKC를 전면 적용하는 것은 다른 대가를 치릅니다. UAX #15의 경고를 그대로 옮기면: "Normalization Forms KC and KD must not be blindly applied to arbitrary text. Because they erase many formatting distinctions... they may remove distinctions that are important to the semantics of the text."(KC와 KD를 임의의 텍스트에 무분별하게 적용해서는 안 된다. 많은 서식 구분을 지워 버리므로, 텍스트의 의미에 중요한 구분을 제거할 수 있다.) 실제로 NFKC는 전각 라틴 문자 "ＭＡＺＵ"를 반각 "MAZU"로 바꾸고, 로마 숫자 Ⅳ를 "IV"로 바꾸며, 위첨자와 합자를 평평하게 만듭니다. 앨범 제목에 의도적으로 쓴 전각 표기가 있다면 그것도 사라집니다.

실무 결론: 저장·전송용 정규 형식은 NFC로 통일하고, 반각 자모는 NFKC로 일괄 변환하는 대신 별도로 탐지해서 개별적으로 고치십시오. 즉 NFKC는 "청소 도구"가 아니라 "탐지 결과를 확인하는 참조"로 쓰는 것이 안전합니다. 문자열에 NFKC를 적용한 결과가 원본과 다르다면, 그 문자열에는 호환 문자가 들어 있다는 뜻입니다 — 그때 무엇이 들어 있는지 눈으로 확인하고 손으로 고치십시오.

2.6 호환용 자모 (U+3131~) — 한국어 키보드가 만들어 내는 것

Hangul Compatibility Jamo 블록, U+3131 ~ U+318F 는 결합 자모와 별개의 문자 집합입니다. U+3131은 HANGUL LETTER KIYEOK ("ㄱ"), U+314F는 HANGUL LETTER A ("ㅏ"), U+3160은 HANGUL LETTER YU ("ㅠ")입니다.

한국어 사용자는 이것을 매일 만듭니다. 한글 자판에서 자음이나 모음 하나만 입력하고 확정하면 나오는 문자가 이 블록입니다. "ㅋㅋ", "ㅠㅠ", "ㅎㅇ" — 트랙 제목이나 부제에 이런 표기를 넣는 릴리스가 실제로 있습니다.

실측 결과입니다.

"ㅋㅋ" (U+314B U+314B): NFC는 변화 없음. NFKC는 U+110F U+110F — 결합 자모 초성 키읔 두 개로 바뀝니다. 화면에는 여전히 비슷하게 보이지만, 코드포인트는 완전히 다른 블록으로 옮겨갔고, 이제 그것은 "완성되지 않은 음절을 기다리는 초성"입니다.

"ㅠㅠ" (U+3160 U+3160): NFKC는 U+1172 U+1172 — 결합 자모 중성 유 두 개.

단일 문자 "ㄱ" (U+3131): NFC·NFD는 변화 없음, NFKC·NFKD 모두 U+1100 HANGUL CHOSEONG KIYEOK.

그리고 가장 위험한 경우입니다. 자모를 하나씩 나열해서 "한"을 흉내 낸 문자열 "ㅎㅏㄴ" (U+314E U+314F U+3134) 에 NFKC를 적용하면:

결과는 "한"이 아닙니다. 2코드포인트 U+D558 U+1102 — 즉 "하" + 홀로 남은 초성 니은이 됩니다. 앞의 두 자모는 음절 "하"로 합쳐지고, 마지막 니은은 종성이 아니라 초성으로 매핑되었기 때문에 결합되지 못하고 떨어져 나갑니다.

이것이 왜 중요한가: 호환용 자모로 쓴 한글은 정규화로 "고쳐지지" 않습니다. 잘 되는 것처럼 보이다가 조용히 다른 글자가 됩니다. 유통 폼에 자모 나열을 넣지 마십시오. 그리고 만약 예술적 의도로 "ㅋㅋ" 같은 표기가 제목에 반드시 들어가야 한다면, 그 문자열은 NFC로 저장하고 NFKC를 절대 통과시키지 마십시오 — 파이프라인 어딘가에서 NFKC가 걸리면 U+3131 계열이 U+1100 계열로 바뀌고, 그 순간 원본과 매칭이 끊깁니다.

2.7 정규화를 파이프라인의 어디에서 할 것인가

"NFC로 통일하라"는 규칙은 옳지만, 어디에서 하느냐에 따라 효과가 완전히 달라집니다. 흔히 저지르는 실수는 딜리버리 폼에 붙여넣기 직전에만 정규화하는 것입니다. 그 시점이면 이미 문자열이 여러 벌 복제된 뒤입니다.

정규화가 들어가야 할 지점은 세 곳입니다.

첫째, 문자열이 시스템에 처음 들어오는 곳. 파일명에서 뽑을 때, 스프레드시트를 읽을 때, 외부에서 받은 크레딧 시트를 열 때. 여기서 정규화하면 그 뒤로는 오염원이 없습니다. 반대로 여기서 놓치면, 뒤에서 아무리 정규화해도 이미 조합형 상태로 비교·조인·중복 제거가 수행된 뒤라서 결과가 틀린 채로 남습니다.

둘째, 정본(canonical) 문자열을 확정하는 곳. 아티스트명, 로마자 표기, 레이블명, 반복 등장하는 작곡가 실명 — 이것들을 한 번 확정해서 파일에 적을 때, NFC로 적으십시오. 그 파일이 이후 모든 릴리스의 단일 출처(single source of truth)입니다.

셋째, 딜리버리 직전 최종 검증. 여기서의 정규화는 고치기 위한 것이 아니라 확인하기 위한 것입니다. 이 지점에서 NFC 정규화 결과가 원본과 다르다면, 그것은 앞의 두 단계 중 하나가 새고 있다는 신호입니다. 조용히 고치고 넘어가지 말고 어디서 들어왔는지 찾으십시오. 같은 경로로 다음 릴리스에도 들어올 것이기 때문입니다.

한 가지 더. 정규화는 청소가 아닙니다. NFC는 탭이나 줄바꿈을 지우지 않고, 이모지를 지우지 않고, 앞뒤 공백을 없애지 않고, 비분리 공백을 일반 공백으로 바꾸지 않고, 반각 자모나 호환용 자모를 손대지 않습니다. 정규화와 정제(sanitisation)는 별개의 두 단계이며, 둘 다 필요합니다.

2.8 실무 규칙 일곱 줄

저장·전송의 정규 형식은 NFC. 예외 없이. 딜리버리 직전에 모든 텍스트 필드에 NFC를 적용하십시오.
파일명에서 뽑은 문자열은 전부 오염된 것으로 간주하십시오. 맥에서 만든 트랙 시트가 대표적입니다. 시트를 만들 때 첫 단계로 정규화하십시오.
아티스트명은 한 번 확정해 파일에 저장하고, 그 뒤로는 영원히 복사·붙여넣기만 하십시오. 다시 타이핑하는 순간 변종이 태어납니다. 이는 정규화 문제만이 아니라 띄어쓰기, 영문 대소문자, 앰퍼샌드까지 모두 해당됩니다.
반각 자모(U+FFA0~)와 호환용 자모(U+3131~)는 탐지해서 손으로 고치십시오. NFKC 일괄 적용으로 밀어 버리지 마십시오.
바이트 길이 제한이 있는 필드는 NFC 기준으로 세십시오. 조합형은 3배입니다.
눈으로 검수하지 마십시오. 이 결함군은 시각적으로 검출이 불가능합니다. 코드포인트를 출력해서 보거나, 도구를 쓰십시오.
정규화 결과가 원본과 다르면 로그를 남기십시오. 어떤 필드가 어느 단계에서 조합형으로 들어왔는지 기록해 두면, 같은 경로가 다음 릴리스에서 반복되기 전에 막을 수 있습니다.

검수용으로: mazufa.com 에 브라우저 안에서만 동작하고 아무것도 업로드하지 않는 무료 메타데이터 검사기가 있으며, 위의 여러 경우 — NFC가 아닌 문자열, 반각 자모, 호환용 자모, 보이지 않는 제어 문자, 중복 공백 — 를 표시해 줍니다.

두 표준 참조 문헌이 아티스트명 일관성에 대해 말하는 것도 같은 방향입니다. Music Biz: "Artist name spelling should remain consistent for all content for an artist, where possible." Spotify: 릴리스마다 철자와 서식을 일관되게 유지하라, "including any punctuation, abbreviations, or acronyms."

3. 인코딩 유산: EUC-KR, CP949, 그리고 엑셀에서 열린 CSV

정규화가 유니코드 안에서 벌어지는 문제라면, 이것은 유니코드 밖에서 들어오는 문제입니다. 한국의 제작 현장은 유니코드 이전 인코딩을 아직 완전히 떠나지 못했고, 유통 워크플로에서 그 흔적을 정기적으로 만납니다.

KS X 1001은 한글 음절 11,172자 중 2,350자만 담고 있습니다. 이것은 추정이 아니라 셀 수 있는 값입니다 — KS X 1001 기반 인코딩으로 U+AC00부터 U+D7A3까지 11,172자를 하나씩 인코딩해 보면, 성공 2,350자, 실패 8,822자입니다. 실패하는 첫 글자들이 갂, 갃, 갅, 갆, 갋, 갌 입니다. 이른바 "완성형 2350자"의 실체입니다.

CP949(확장 완성형, UHC) 는 KS X 1001을 확장해 11,172자 전부를 담습니다. 그래서 윈도우 한국어 환경의 기본 인코딩인 CP949에서는 "쀍"도 "펲"도 문제없이 저장됩니다.

여기서 실제로 벌어지는 사고는 두 가지입니다.

첫째, CSV 인코딩 사고. 유통사에 제출하는 트랙 시트를 엑셀로 만들어 "CSV로 저장"하면, 한국어 윈도우 환경의 엑셀은 오랫동안 UTF-8이 아니라 CP949로 저장해 왔습니다. 그 파일을 UTF-8로 읽는 시스템에 넘기면 한글이 통째로 깨집니다 — 유명한 "占쏙옙", "�" 패턴입니다. 반대로 UTF-8 CSV를 엑셀이 CP949로 열면 역시 깨집니다. 이 사고의 특징은 일부만 깨지는 경우가 있다는 것입니다. 아티스트명은 멀쩡한데 작곡가 실명 한 명만 깨진 채로 딜리버리에 실려 나갑니다.

둘째, 옛 카탈로그 이관. 2000년대 이전 음원을 재발매할 때 원본 메타데이터가 EUC-KR 텍스트 파일이나 구형 DB에 들어 있는 경우가 있습니다. KS X 1001에 없는 음절이 그 시절에 어떻게 처리되었는지는 시스템마다 다르며, 조합형으로 우회 저장했거나, 대체 문자로 바꿔 두었거나, 아예 다른 글자로 바뀌어 있을 수 있습니다. 재발매 전에 원본 문자열의 코드포인트를 확인하십시오 — 화면에 정상으로 보이는 것이 정상이라는 뜻이 아니라는 점은 2장에서 본 그대로입니다.

실무 규칙: 유통 체인에 들어가는 모든 텍스트 파일은 UTF-8(BOM 없이)로 저장하고, 스프레드시트에서 CSV를 내보낼 때 인코딩을 명시적으로 확인하십시오. 엑셀에서 확신이 서지 않으면 CSV 대신 유통사가 제공하는 템플릿 형식(xlsx)을 그대로 쓰거나, 텍스트 에디터로 인코딩을 확인한 뒤 제출하십시오. 그리고 제출 직전에 파일을 한 번 UTF-8로 읽어서 한글이 온전한지 눈으로 확인하는 데는 몇 초밖에 걸리지 않습니다.

3.1 ID3 태그: 참고 자료이지 정본이 아니다

한국 스튜디오에서 넘어오는 mp3 참고 파일의 ID3 태그도 같은 인코딩 지층 위에 있습니다. ID3v1은 인코딩 지정 자체가 없어 한글은 사실상 CP949로 밀어 넣은 바이트열이고, ID3v2.3은 ISO-8859-1과 UTF-16만 규정하며 UTF-8은 ID3v2.4에서야 정식으로 들어왔습니다. 그 결과 같은 파일이 플레이어에 따라 한글로 보이기도 하고 깨져 보이기도 합니다.

여기서 도출되는 규칙은 하나입니다. ID3 태그에서 메타데이터를 복사해 딜리버리 폼에 붙여넣지 마십시오. 태그는 스튜디오 안에서 파일을 구분하기 위한 편의 장치이지 정본이 아닙니다. 정본은 여러분이 확정해 파일에 적어 둔 문자열이고, 폼에 들어가는 것은 언제나 그 파일에서 나와야 합니다. 마스터 WAV에 붙은 iXML이나 BWF 메타데이터도 마찬가지입니다 — 유용한 참고이지만, 그것이 유통 체인에 그대로 실려 나가서는 안 됩니다.

4. 띄어쓰기와 공백: 한글 아티스트명의 조용한 변종

한국어 아티스트명에서 정규화 다음으로 흔한 분열 원인은 공백입니다. 한글에는 라틴 문자 같은 대소문자가 없기 때문에 대소문자 변종은 발생하지 않지만, 대신 띄어쓰기가 그 자리를 차지합니다.

같은 이름의 변종이 이렇게 만들어집니다:

달빛 사물놀이 / 달빛사물놀이 — 띄어쓰기 유무
달빛 사물놀이 — 공백 두 개(복사·붙여넣기 과정에서 생김)
달빛사물놀이 — 뒤에 붙은 공백(폼 입력에서 가장 흔함)
달빛 사물놀이 — 일반 공백이 아닌 비분리 공백(U+00A0). 워드나 웹페이지에서 복사하면 딸려 옵니다. 눈으로는 일반 공백과 구별되지 않습니다.
달빛　사물놀이 — 전각 공백(U+3000). 한글 IME나 일본어·중국어 혼용 환경에서 들어옵니다.

이 다섯은 모두 서로 다른 문자열이며, 스토어에게는 잠재적으로 다섯 명의 아티스트입니다. 그리고 NFC 정규화는 이 중 어느 것도 고치지 않습니다 — U+00A0에는 정준 분해가 없고, U+3000의 분해는 호환 분해라서 NFKC에서만 일반 공백으로 바뀝니다.

점검 규칙: 아티스트명 문자열에 대해 (1) 앞뒤 공백 제거, (2) 연속 공백을 하나로 축약, (3) U+00A0과 U+3000을 일반 공백 U+0020으로 치환. 이 세 가지를 정본 문자열을 만들 때 한 번 수행하고, 그 뒤로는 그 문자열만 복사하십시오.

영문 병기 이름에는 여기에 대소문자와 구두점 변종이 더해집니다: DJ 도현 / DJ도현 / Dj 도현, 그리고 앰퍼샌드 대 "and". Spotify의 지침이 "including any punctuation, abbreviations, or acronyms"라고 명시한 것이 정확히 이 지점입니다.

5. 로마자 표기: 한 사람, 네 개의 철자, 네 개의 프로필

한글 문자권 아티스트는 세계의 시스템 안에 이름을 두 개 가집니다 — 한글 표기와 로마자 표기. 그리고 둘 다 단일 값이어야 합니다.

한국어의 로마자 표기는 셋이 경쟁합니다.

국어의 로마자 표기법(Revised Romanization, RR). 대한민국의 표준이며, 문화체육관광부 고시 제2014-42호로 시행 중입니다. 제1장 제1항은 원칙을 명시합니다: "국어의 로마자 표기는 국어의 표준 발음법에 따라 적는 것을 원칙으로 한다." 제2항: "로마자 이외의 부호는 되도록 사용하지 않는다." 모음은 ㅓ = eo, ㅡ = eu, ㅢ = ui 로 적고, 파열음은 어두·모음 앞에서 ㄱ = g, ㄷ = d, ㅂ = b, 자음 앞이나 어말에서 k, t, p 입니다.

매큔-라이샤워(McCune-Reischauer, MR). 1984년부터 2000년까지 한국의 공식 표기법이었고, 지금도 해외 학술 문헌과 도서관 목록에서 널리 쓰입니다. 반달표와 어깨점을 씁니다: ㅓ = ŏ, ㅡ = ŭ, ㅊ = ch'. 국악·판소리 연구 문헌에서 여전히 표준입니다 — 산조가 sanjo(RR)와 sanjo(MR)로 같아도, 거문고는 geomungo(RR)와 kŏmun'go(MR)로 갈립니다.

그리고 실제로 그 사람이 쓰는 철자. 이것이 셋 중 가장 강력합니다.

로마자 표기법 제3장 제4항의 마지막 단서가 이 상황을 그대로 인정합니다: "(2) 성의 표기는 따로 정한다." 성씨의 로마자 표기는 이 고시가 규정하지 않습니다. 그 결과가 현실입니다.

한글	RR대로라면	실제로 쓰이는 표기
이	I	Lee, Yi, Rhee, Rhie, Ree
박	Bak	Park, Pak, Bahk, Back
김	Gim	Kim, Ghim
정	Jeong	Jung, Chung, Jeong, Chong
최	Choe	Choi, Choe

한 사람이 네 개의 라틴 철자를 쓰면, 매칭 시스템에게 그것은 네 명입니다.

전형적인 붕괴 경로는 이렇습니다. 아티스트 정하람은 데뷔 싱글을 "Jung Haram"으로 냅니다. 두 번째 EP를 다른 유통사로 내면서 담당자가 여권 표기를 보고 "Chung Ha-ram"으로 씁니다. 세 번째 릴리스는 해외 레이블 컴필레이션에 실리면서 편집자가 로마자 표기법대로 "Jeong Haram"으로 고칩니다. 한글 표기 "정하람" 릴리스는 한 페이지에 모이는데, 로마자 릴리스는 세 페이지로 흩어집니다. 아티스트는 "스트리밍이 생각보다 안 나온다"고 느끼지만 원인을 찾지 못합니다 — 각 페이지는 따로 보면 아무 문제가 없기 때문입니다.

선택의 우선순위:

이미 공개적으로 쓰고 있는 표기. SNS 핸들, 도메인, 인쇄된 앨범, 여권. 기존 발자국과의 일관성이 언어학적 정확성을 이깁니다.
그것이 없으면 가장 큰 기존 릴리스에 실린 표기.
그것도 없으면 타깃 시장의 청취자가 실제로 칠 법한 철자. 흔한 것이 학술적인 것을 이깁니다. MR의 반달표(Chŏng)는 정확하지만 아무도 입력하지 못합니다. 로마자 표기법 제1장 제2항 "로마자 이외의 부호는 되도록 사용하지 않는다"가 실무적으로도 옳은 이유입니다.
모호한 자리마다 하나의 고정된 선택. eo/u, eu/u, j/ch, g/k, b/p — 한 번 정하고 절대 바꾸지 마십시오.
하이픈을 쓸지 말지도 한 번만 정하십시오. 로마자 표기법 제4항은 둘 다 허용합니다: "이름은 붙여 쓰는 것을 원칙으로 하되 음절 사이에 붙임표(-)를 쓰는 것을 허용한다." 예시로 "민용하 Min Yongha (Min Yong-ha)"를 듭니다. 둘 다 맞지만, 둘 다 쓰면 아티스트가 둘이 됩니다.

로마자 표기는 두 번째 법적 이름입니다. 그것을 정하지 않은 아티스트는 이미 여러 개를 정한 것입니다.

여권 표기를 기본값으로 삼는 것이 실무적으로 가장 안전한 경우가 많습니다. 이유는 언어학이 아니라 서류입니다 — 해외 정산, 세금 서식(W-8BEN 등), 계약서, 항공권, 공연 비자에 쓰이는 이름이 여권 표기이기 때문입니다. 아티스트명의 로마자 표기와 서류상의 이름이 다르면, 저작권료 지급 단계에서 수취인 확인이 걸리는 일이 생깁니다. 예명으로 활동하는 경우라면 이 문제는 없지만, 본명을 아티스트명으로 쓰는 경우에는 여권 표기와 아티스트 표기를 일치시키는 것이 나중에 문제를 하나 줄여 줍니다.

로마자 표기를 바꿔야만 하는 상황이 왔다면, 그것은 단순한 필드 수정이 아니라 이관 작업으로 계획해야 합니다. 이전 표기로 나간 모든 릴리스를 목록화하고, 유통사를 통해 각 스토어에 페이지 병합을 요청하고, 새 표기로 나가는 릴리스를 병합 요청이 처리되기 전까지는 만들지 않는 것이 순서입니다. 새 표기 릴리스를 먼저 내보내면 병합해야 할 대상이 하나 더 늘어납니다.

데이터 모델이 지원한다면 한글은 기본 필드에, 로마자는 로컬라이제이션 또는 발음(phonetic) 필드에 넣는 것이 원래 설계 의도입니다. Apple이 키릴 문자에 대해 규정한 방식이 그 모델을 보여 줍니다: "Content in languages that use the Cyrillic alphabet should not be submitted with transliterated titles. Use Cyrillic in the native title field, English in the English localization field, and transliteration in the available phonetic field." 한국어에도 같은 구조가 적용됩니다 — 한글 원제를 기본 제목 필드에, 영문 제목을 영어 로컬라이제이션에 넣으십시오. 유통사가 그 필드를 노출하지 않는다면, 청중이 검색하는 문자 체계를 골라서 그대로 가십시오.

6. 이름 순서: 성이 먼저인 언어, 이름이 먼저인 스토어

한국어는 성-이름 순입니다. 로마자 표기법 제3장 제4항이 그렇게 규정합니다: "인명은 성과 이름의 순서로 띄어 쓴다."

그런데 대부분의 스토어와 그 데이터 모델은 서구식 given-family 순서를 전제로 만들어졌습니다. 여기서 두 가지 손상이 발생합니다.

첫째, 스토어가 순서를 뒤집는 경우. "Kim Seoyoon"을 성-이름 순으로 제출했는데 스토어가 이를 given="Kim", family="Seoyoon"으로 파싱하면, 표시는 "Seoyoon Kim"이 되고 정렬은 S 항목에 들어갑니다. 다음 릴리스에서 다른 유통사가 다르게 파싱하면 같은 사람이 K와 S 두 군데에 생깁니다.

둘째, 아티스트명 필드와 기여자 필드의 규칙이 다른 경우. 아티스트명 필드는 보통 하나의 표시 문자열이므로 파싱되지 않습니다 — "Kim Seoyoon"이 통째로 이름입니다. 반면 작곡가·작사가 필드는 저작권 단체 등록과 매칭되어야 하므로 성과 이름이 분리되는 경우가 있습니다. 한 딜리버리 안에서 같은 사람이 아티스트 필드에는 "Kim Seoyoon", 작곡가 필드에는 "Seoyoon Kim"으로 들어가는 일이 실제로 벌어집니다.

Apple 스타일 가이드는 한국·중국 아티스트를 명시적으로 다룹니다. §12.2 "Chinese or Korean Artists Without Western Names": "If the artist does not have a Western name, the phonetic artist name may be listed in localizations in the order of 'Family Name Given Name.' The phonetic artist name may be listed in English localization." 그리고 가이드가 직접 드는 예시는 다음과 같습니다 — Album Artist 필드: 한국어 박지윤, 영어 Park Ji Yoon.

이 예시를 두 번 읽을 가치가 있습니다. Apple 자신의 공식 예시가 로마자 표기법대로의 "Bak Jiyun"이 아니라 관습 표기 "Park" 을 쓰고 있고, 성을 앞에 두고 있으며, 이름의 두 음절을 띄어 썼습니다. 즉 스토어가 요구하는 것은 "규범을 따르라"가 아니라 "성-이름 순서를 지키고, 하나를 정해 일관되게 쓰라"입니다.

띄어쓰기 결정도 한 번만 하십시오. 로마자 이름의 두 음절을 어떻게 쓸지에는 최소 세 가지 방식이 있습니다 — Park Jiyoon(붙여쓰기), Park Ji-yoon(붙임표), Park Ji Yoon(띄어쓰기, Apple 가이드의 예시가 쓰는 방식). 로마자 표기법은 앞의 둘을 규정하고 허용하며, Apple의 예시는 셋째를 보여 줍니다. 셋 다 현실에서 통용되므로, 옳고 그름의 문제가 아니라 하나를 고르는 문제입니다. 고르지 않으면 세 개의 아티스트가 생깁니다.

실무 규칙: 한글 필드는 성-이름 붙여 쓰기(박지윤), 로마자 필드는 성-이름 띄어 쓰기(Park Ji Yoon), 그리고 이 두 문자열을 파일에 적어 두고 모든 릴리스에서 복사하십시오.

7. K-pop 구조: 그룹명, 멤버명, 솔로 프로젝트

한국 대중음악의 릴리스 구조는 다른 어떤 시장보다 이름의 층위가 많고, 그만큼 잘못 놓이기 쉽습니다.

그룹은 하나의 아티스트 개체입니다. 그룹명이 메인 아티스트 필드에 들어갑니다. 그게 전부입니다.

멤버 이름은 아티스트 필드에 들어가지 않습니다. 그리고 — 이것이 훨씬 흔한 사고인데 — 제목 필드에도 들어가지 않습니다. 트랙이 그룹 내 특정 멤버들만 참여한 유닛 곡이라 하더라도, 멤버 크레딧이 갈 자리는 기여자(contributor) 필드입니다: 보컬리스트, 래퍼, 작사가, 작곡가 역할로.

전형적인 잘못된 딜리버리:

메인 아티스트: 세븐라인
트랙 제목: 밤의 끝 (유진, 도현 ver.)

이렇게 하면 유진과 도현은 크레딧 링크를 얻지 못하고, 자기 페이지에 이 트랙이 뜨지 않으며, 자기 애널리틱스에 아무것도 잡히지 않습니다. 그러는 동안 스토어는 "(유진, 도현 ver.)"를 곡 이름의 일부로 취급해서, 그 곡은 영원히 그 이름으로 남습니다.

올바른 구조:

메인 아티스트: 세븐라인
트랙 제목: 밤의 끝
버전 필드(정말 별도 버전이라면): 유닛 버전
기여자: 유진 (보컬), 도현 (래퍼)

솔로 프로젝트는 별개의 아티스트 개체입니다. 멤버가 자기 이름으로 솔로 싱글을 내면 메인 아티스트는 그 개인의 이름이고, 그룹명은 어디에도 들어가지 않습니다. 그룹명을 붙여서 "세븐라인 유진"으로 내면, 그것은 세 번째 아티스트 개체를 만드는 문자열입니다 — 그룹도 아니고 유진도 아닙니다.

두 개체가 실제로 함께 참여한 곡은 그때 비로소 메인 아티스트 두 개, 또는 메인 + Featured 구조입니다. Spotify: "List each artist's name in a separate field."

7.1 리패키지, 유닛, 그리고 ISRC

국내 릴리스에는 다른 시장에 흔하지 않은 구조가 하나 더 있습니다. 리패키지 앨범 — 기존 정규 앨범의 수록곡 전부 또는 대부분에 신곡 몇 개를 더해 새 상품으로 내는 형식입니다. 여기서 식별자 규칙이 정확히 적용되어야 합니다.

리패키지는 새로운 릴리스입니다. 새 UPC가 필요합니다. UPC는 상품을 식별하기 때문입니다.
재수록된 기존 트랙은 같은 레코딩입니다. 새 ISRC를 발급하지 마십시오. ISRC는 레코딩을 식별하며, 유통사를 바꾸거나 상품을 바꿔도 그 레코딩에 그대로 남습니다. 여기서 새 코드를 발급하면 같은 녹음이 서로 다른 두 개의 레코딩으로 집계되어, 스트리밍 실적과 저작인접권 정산이 갈라집니다.
신곡과, 리패키지를 위해 새로 편집·재녹음한 트랙은 새 레코딩입니다. 각자의 ISRC가 필요합니다.
재수록 트랙의 최초 발매일은 원 앨범의 발매일입니다. 리패키지 발매일이 아닙니다. 이것을 바꾸면 하류의 모든 시스템이 3년 된 곡을 신보로 취급합니다.

유닛 곡도 같은 논리를 따릅니다. 그룹 안의 일부 멤버만 참여한 트랙이라 해도, 그것이 그룹 앨범의 수록곡이라면 메인 아티스트는 여전히 그룹입니다. 유닛에 독자적인 이름이 있고 독자적인 릴리스로 나간다면, 그때 비로소 그것은 별개의 아티스트 개체입니다. 판단 기준은 하나입니다: 이 이름으로 앞으로 릴리스를 계속 낼 것인가, 아니면 이번 한 트랙의 구성을 설명하는 말인가. 앞이면 아티스트, 뒤면 버전 필드 또는 기여자 필드입니다.

소속사가 바뀌거나 그룹명 표기가 바뀔 때가 가장 위험한 순간입니다. 새 담당자가 새 유통사 폼에 아티스트명을 새로 타이핑합니다. 띄어쓰기가 하나 다르거나, 영문 표기의 대소문자가 다르거나, 2장에서 본 대로 정규화 형식이 다릅니다. 그 순간 카탈로그가 갈라집니다. 이관 시점에 반드시 해야 할 일은 단 하나입니다 — 이전 딜리버리에서 아티스트 문자열을 그대로 복사해 오는 것.

8. 참여 아티스트와 버전 표기

8.1 제목 필드는 참여 아티스트가 들어갈 자리가 아니다

독립 유통에서 가장 흔하고 가장 손해가 큰 입력은 제목 필드에 "아티스트A feat. 아티스트B"를 치면서 참여 아티스트 역할 필드를 비워 두는 것입니다.

제목 필드는 표시 문자열이며 아무런 신원(identity)도 담지 않습니다. 그래서 참여 아티스트는 크레딧 링크도, 자기 페이지 노출도, 자기 애널리틱스도 얻지 못합니다. 동시에 스토어는 "feat. 아티스트B"를 곡 이름의 일부로 취급합니다. 결과는 아마추어 딜리버리의 표식인 중복 표시입니다: 곡제목 feat. B (feat. B) — A, B.

스토어의 문구는 분명합니다. Spotify: "You shouldn't include any artists' names in your track or release titles." 그리고 유통사용 문서에서: "Spotify strongly recommends against including additional information, such as references to 'Featured Artists' in track and product titles." Music Biz는 참여 아티스트를 "at the Artist role level and not add this data to the track or album release title"로 크레딧하라고 안내합니다.

계약상 제목에 병기가 요구되는 경우의 표기 관례도 일관됩니다. Music Biz는 "feat."와 "with"에 대해 "when included in the title are generally lowercase and in English"라고 씁니다. Apple: "Formatting of 'feat.' and 'with' must be lowercase, in English, not localized, and in parentheses or brackets."

"not localized" — 이 지시가 한국어 릴리스에서 특히 중요합니다. 제목 필드 안의 "feat."를 "피처링", "피쳐링", "with" 대신 "와 함께" 로 바꾸지 마십시오. 그것은 단어가 아니라 기계가 읽는 토큰입니다. 스토어의 파서는 "feat."를 알아보고 "피처링"은 알아보지 못합니다. 알아보지 못한 것은 곡 이름의 일부가 됩니다.

역할은 신원이고 제목은 표시입니다. 신원을 표시 필드에 넣으면 신원이 파괴되고 표시도 망가집니다.

8.2 버전 필드

버전 필드는 제목이 같은 두 레코딩을 구별하기 위해 존재합니다. 그것이 이 필드의 유일한 일이고, 채울지 말지를 판단하는 기준입니다. 릴리스에 원본만 있다면 버전 필드는 비워 두는 것이 어디서나 옳습니다.

Apple의 지침: "To differentiate multiple versions of the same track title, use terms in parentheses or brackets such as: Alternate Take...Live, Instrumental, Single Version, Radio Edit." 구두점은 Music Biz가 규정합니다 — 괄호를 먼저 쓰고, 추가 정보가 있으면 대괄호를 씁니다.

한국어 릴리스에서 반복되는 두 가지:

"Radio Edit"은 "19금 뺀 버전"이 아닙니다. Music Biz는 이 용어를 실제로 방송용으로 준비된 버전에만 쓰도록 하고, 비속어를 걷어낸 편집본에는 "Edited Version"을 쓰라고 지시합니다. Radio Edit은 보통 길이 편집이고, Edited Version은 내용 편집입니다.

"Original Mix"는 어디서나 안전하지 않으며, 이것은 스토어 간의 실제 차이입니다. Apple의 공개 가이드는 이를 금지합니다: "The standard, original version of an album, track, or music video must not include any additional information in the title unless it is needed to identify the content." 금지 용어 목록에 "Exclusive, Limited Edition, Album Version, Original Mix, Tone, Alert Tone...Dolby Atmos, lossless, high-resolution audio"가 들어 있습니다. Spotify의 공개 메타데이터 가이드는 "Original Mix"를 지목하는 규칙을 발표하지 않았습니다 — 제목에 부가 정보를 넣지 말라는 일반 원칙만 공표되어 있습니다. Apple의 공개 가이드는 "Original Mix"를 금지 용어로 명시하고, 다른 서비스들은 이를 지목하는 규칙을 어느 방향으로도 공표하지 않았으며, 처리는 스토어와 유통사의 사전 검증에 따라 달라집니다.

그리고 버전 필드가 있는 곳에서는 반드시 버전 필드를 쓰십시오. 제목에 손으로 타이핑하면, 자체 표시 문자열을 생성하는 스토어에서 산조 아리랑 (해금 버전) (해금 버전) 이 나옵니다.

한국어 버전 표기는 한글로 쓰는 것이 청중에게 자연스럽습니다 — (해금 버전), (연주 버전), (라이브). 단 "feat."와 달리 버전 용어는 로컬라이즈해도 됩니다. 차이는 명확합니다: "feat."는 파서가 읽는 토큰이고, 버전 명칭은 사람이 읽는 구별자입니다. 다만 하나만 지키십시오 — 한 카탈로그 안에서 한글 버전 표기와 영문 버전 표기를 섞지 마십시오. 어떤 앨범은 (연주 버전), 어떤 앨범은 (Instrumental)로 나가면 같은 종류의 트랙이 검색에서 서로 만나지 않습니다.

9. 한글 제목 표기: 영문 병기, 부제, 대소문자

한국어 릴리스의 제목에는 라틴 문자권에 없는 결정이 몇 가지 더 붙습니다.

영문 병기를 제목 안에 넣지 마십시오. 밤의 끝 (The End of Night) 같은 표기는 국내 음원 사이트에서 오랫동안 관습이었지만, 국제 유통에서는 제목 필드에 부가 정보를 넣지 말라는 규칙과 정면으로 충돌합니다. 영문 제목이 갈 자리는 영어 로컬라이제이션 필드입니다. Apple이 키릴 문자에 대해 규정한 구조 — 원어는 기본 필드, 영어는 로컬라이제이션 필드 — 가 한국어에도 그대로 적용됩니다. 유통사가 로컬라이제이션 필드를 노출하지 않는다면, 병기를 제목에 밀어 넣는 대신 한글 제목 하나만 내보내는 쪽이 안전합니다. 괄호 안의 영문은 스토어의 버전 파서에게는 버전 표기처럼 보이고, 검색 색인에게는 곡 이름의 일부로 보입니다.

부제는 버전 필드가 아닙니다. 아리랑 연작 - 제2번 같은 부제는 곡의 이름 일부이지 두 레코딩을 구별하는 표지가 아닙니다. 버전 필드는 같은 제목의 서로 다른 녹음이 존재할 때만 채웁니다. 부제가 필요하면 제목 안에 붙임표나 콜론으로 넣되, 한 앨범 안에서 구분자를 하나로 통일하십시오 — 어떤 트랙은 하이픈, 어떤 트랙은 콜론, 어떤 트랙은 전각 붙임표로 나가면 정렬과 그룹핑이 모두 어긋납니다.

한글에는 대소문자가 없지만 영문 병기 부분에는 있습니다. Music Biz의 타이틀 케이스 규칙 — 소문자로 유지하는 목록 "a, an, and, as, but, for, from, nor, of, or, so, the, to, yet" 및 4자 이하 전치사 — 는 영문 제목과 영문 로컬라이제이션에 적용됩니다. 전부 대문자로 쓴 영문 제목은 반려 사유가 될 수 있습니다.

괄호와 대괄호의 종류를 섞지 마십시오. 한글 IME는 전각 괄호 （）를 쉽게 만들어 냅니다. 반각 괄호 ()와 전각 괄호는 서로 다른 코드포인트이고, NFC는 이를 통일하지 않습니다(전각 괄호의 분해는 호환 분해이므로 NFKC에서만 반각으로 바뀝니다). 반각 괄호로 통일하십시오.

아트워크와 제목의 띄어쓰기가 다른 경우가 한글 릴리스에서 특히 흔합니다. 디자이너는 자간과 줄바꿈을 보고 제목의 띄어쓰기를 바꾸고, 메타데이터 담당자는 원래 표기를 씁니다. 커버에는 밤의끝, 필드에는 밤의 끝 — 이것은 실제로 반려되는 사유입니다.

10. 장르 라우팅: 트로트, 국악, 그리고 "그 외"

장르 필드는 설명이 아니라 라우팅 신호입니다. 어떤 에디토리얼·알고리즘 맥락에 노출될 자격이 생기는지, 어떤 차트에 집계되는지를 좌우합니다. 그리고 한국 음악은 국제 장르 분류 체계에 잘 맞지 않는 영역을 여럿 가지고 있어서, 여기서 정보가 손실됩니다.

트로트. 국내 서비스에서는 독립된 장르로 운용되지만, 국제 표준 장르 목록에는 대응 항목이 없거나 있어도 목적지마다 다릅니다. 유통사가 제공하는 장르 목록에 트로트가 있으면 그것을 쓰고, 없으면 목적지가 실제로 인식하는 상위 분류(예: 국내 서비스용 K-Pop 계열, 또는 World/Traditional 계열)로 매핑되는 것을 유통사에 확인하십시오. 임의로 "Pop"을 고르지 마십시오 — 트로트 청취자에게 도달하는 경로가 그 순간 끊깁니다.

국악. 여기서 가장 흔한 손실은 장르 필드가 아니라 하위 분류와 악기 정보입니다. 산조, 판소리, 사물놀이, 시나위는 서로 다른 형식이고, 가야금 산조와 거문고 산조는 다른 상품입니다. 대부분의 유통 폼은 이 구분을 담을 장르 항목을 제공하지 않습니다. 그럴 때 정보를 넣을 자리는 기여자 필드의 악기 역할입니다 — 가야금, 거문고, 해금, 대금, 장구, 북을 연주한 사람을 각각 해당 악기 역할로 기입하십시오. Apple 스타일 가이드가 인도 고전음악 릴리스에 대해 트랙 아티스트를 악기별로(Sitar player, Tabla player) 나열하는 예시를 드는 것이 바로 이 구조입니다. 국악 릴리스에도 같은 구조를 쓸 수 있습니다.

판소리 완창 음반은 트랙 구조 자체가 문제입니다. 한 바탕을 여러 트랙으로 나눌 때, 각 트랙의 제목은 대목 이름이고 전체 작품명은 앨범 제목입니다. 이것을 뒤집어서 트랙마다 춘향가 - 사랑가, 춘향가 - 이별가처럼 작품명을 반복해 넣으면, 스토어 화면에서 앨범 제목과 트랙 제목이 이중으로 표시되고 검색 색인에도 같은 문자열이 중복 등록됩니다. 앨범 제목에 이미 있는 정보를 트랙 제목에 반복하지 마십시오. 그리고 고수(북)와 소리꾼은 서로 다른 역할이므로, 각각 기여자 필드의 해당 역할로 기입하십시오 — 고수를 빼놓는 것이 판소리 릴리스에서 가장 흔한 크레딧 누락입니다.

보조 장르(secondary genre)를 반드시 채우십시오. 주 장르 하나만으로 국악 크로스오버나 트로트 리메이크를 설명할 수 없습니다. Apple은 인도 고전 릴리스 예시에서 주 장르와 보조 장르를 함께 지정합니다 — 연주곡이면 Instrumental을 보조 장르로 두는 식입니다. 같은 원칙이 대금 독주나 가야금 독주 릴리스에 적용됩니다.

장르는 릴리스 단위가 아니라 트랙 단위로 다를 수 있습니다. 국악 연주 트랙과 보컬 트랙이 섞인 앨범에서 전체를 하나의 장르로 밀어 넣으면, 절반의 트랙이 잘못된 맥락으로 라우팅됩니다.

11.1 한국의 관리 단체 지형 — 사실만

국내에는 역할이 다른 단체들이 나란히 존재하며, 어느 것이 어느 권리를 다루는지 구분하는 것이 실무의 출발점입니다.

한국음악실연자연합회(FKMP, 음실련) — 실연자(연주자·가창자)의 저작인접권을 다루는 단체. fkmp.kr
한국음반산업협회(RIAK) — 음반제작자의 저작인접권을 다루는 단체이며, 자체 홈페이지에서 "UCI, ISRC, UPC" 등 표준코드 관리를 자기 업무로 명시하고 국내 ISRC 안내 사이트 isrc.or.kr을 운영합니다. riak.or.kr

이 문서는 각 단체의 내부 절차 — 가입 요건, 심사 기준, 등록 처리 순서, 분배 주기의 세부 — 를 서술하지 않습니다. 이런 사항은 단체별 규정에 따라 달라지고 시간에 따라 개정되므로, 각 단체의 공식 안내를 직접 확인해야 합니다. 커뮤니티에서 회자되는 요건과 실제 규정이 어긋나는 경우가 흔합니다.

실무에서 확실하게 말할 수 있는 것은 다음입니다.

작곡가·작사가 필드에는 예명이 아니라 실명(법적 이름)을 넣습니다. 관리 단체는 등록된 저작자명으로 매칭합니다. "DJ 도현"은 저작자가 아니고, 그 뒤에 있는 사람이 저작자입니다.
모든 저작자를 빠짐없이 기재해야 합니다. 한 줄만 쓴 사람도 포함됩니다. 빠진 저작자는 빠진 크레딧이 아니라 매칭되지 않는 지분입니다.
지분 합계는 100%여야 하고, 발매 전에 서면으로 합의되어야 합니다. 메타데이터는 합의를 표현할 뿐이고, 합의가 없으면 그것은 나중에 분쟁이 되는 추측입니다.
리믹스는 곡을 바꾸지 않습니다. 새로운 창작이 더해진 것이 아니라면 원 저작자가 그대로 저작자입니다. 새로운 창작이 있다면 그것은 협의된 지분이지 당연한 전제가 아닙니다.

콜라보와 게스트 연주자. 국악 세션이 참여한 대중음악 트랙에서 해금이나 대금 연주자를 아무 필드에도 넣지 않는 경우가 매우 흔합니다. 이들은 메인 아티스트가 아니지만 실연자이고, 기여자 필드의 악기 역할이 그들의 자리입니다. 여기에 이름이 없으면 실연자 관련 권리 처리의 출발점이 되는 기록 자체가 남지 않습니다.

11.2 "Traditional"의 비용 — 국악과 민요 편곡

여기서 한국 음악에 고유하고 반복적인 손실이 발생합니다.

유통 폼의 작곡가 필드는 비워 둘 수 없는 경우가 많고, 담당자가 국악 계열 트랙을 마주하면 손쉬운 선택지가 하나 있습니다: "Traditional" 또는 "전통민요".

문제는 릴리스되는 것이 선율 그 자체인 경우가 거의 없다는 것입니다.

민요 편곡. 아리랑, 정선아리랑, 새타령을 가야금·해금·장구 편성으로 새로 짠 것은 편곡물입니다. 편곡에는 편곡자가 있습니다. "Traditional"로 신고하면 그 편곡자의 몫이 사라집니다. 이것이 가장 흔한 손실 경로입니다.
연주자의 즉흥과 구성. 산조는 장단 구성과 가락 운용에 연주자의 창작이 개입하는 형식입니다. 어디까지가 전승이고 어디부터가 새 창작인지는 개별 판단의 문제이며, 이 문서는 그 경계를 단정하지 않습니다. 단정할 수 있는 것은, 그 판단을 하지 않은 채 "Traditional"을 고르는 것이 판단을 내린 것과 같은 결과를 낳는다는 사실입니다 — 미분배 쪽으로.

실무 규칙: 트랙에 편곡·재구성·창작이 조금이라도 들어갔다면, "Traditional"이 아니라 편곡자를 편곡자 역할로 명시하십시오. 그리고 공개 자료로 작곡가가 확인되는 작품은 그 작곡가를 기입하십시오. 확인이 안 되면, "확인되지 않았다"가 "저작자가 없다"와 같은 뜻이 아니라는 점을 기억하고 조사부터 하십시오.

끝으로, 조사부터 하라는 말의 구체적 의미. 민요 편곡 릴리스에서 실제로 해야 할 확인은 셋입니다. (1) 이 선율의 원 형태가 저작권 보호기간이 만료된 전승 선율인가, 아니면 특정 시기에 특정인이 작곡한 신민요인가 — 20세기 초중반 신민요 중에는 작곡가가 확인되는 작품이 상당수 있습니다. (2) 이번 녹음에 사용한 편곡은 누가 했는가 — 연주자 본인일 수도, 별도의 편곡자일 수도 있으며, 어느 쪽이든 이름이 필요합니다. (3) 참고한 선행 편곡이 있는가 — 다른 사람의 편곡을 그대로 연주했다면 그 편곡자가 저작자입니다. 이 세 질문에 답하지 않은 채 "Traditional"을 선택하는 것은 답을 모른다는 표시가 아니라, 저작자가 없다는 적극적 신고입니다.

대금 독주곡, 거문고 산조, 사물놀이 합주 — 이런 편성의 릴리스는 국내 스트리밍 지분에서 큰 비중이 아니고, 바로 그렇기 때문에 아무도 오류를 발견해 주지 않습니다. 여기서의 미분배는 몇 년 뒤에도 발견되지 않습니다.

12. 실제로 반려되는 사유, 그리고 사전 차단

제목 필드 안의 아티스트 이름 — "feat.", "with", 리믹서 이름을 제목에 넣고 역할 필드를 비워 둔 경우. (8.1)
제목 안의 19금/클린 표기 — "(Explicit)", "(Clean)", "(19금)". 플래그를 쓰십시오. Apple과 Music Biz 모두 텍스트 형태를 금지합니다.
제목 안의 홍보·설명 문구 — "Exclusive", "Limited Edition", "Album Version", "Original Mix", 그리고 "Dolby Atmos", "무손실", "고음질" 같은 포맷 주장. Apple 가이드가 열거하는 항목들입니다.
대소문자 규칙 위반 — 영문 제목의 전부 대문자, 전부 소문자, 무작위 대소문자. 진짜 예술적 의도이고 일관될 때만 예외입니다. Music Biz가 타이틀 케이스 규칙과 소문자 유지 목록("a, an, and, as, but, for, from, nor, of, or, so, the, to, yet" 및 4자 이하 전치사)을 규정합니다.
아트워크와 불일치하는 메타데이터 — 커버에 인쇄된 제목·아티스트명·버전이 필드와 글자 단위로 같아야 합니다. 한글 릴리스에서는 커버의 띄어쓰기와 필드의 띄어쓰기가 다른 경우가 특히 흔합니다.
언어 필드 누락 또는 오기 — 특히 한글 릴리스의 제목 언어.
작곡가 또는 작사가 누락 — 일부 목적지는 그 자체로 반려합니다.
금지 문자 — 이모지, 장식 기호, 중복 공백, 보이지 않는 제어 문자. 반각 자모와 호환용 자모도 여기 속합니다.
잘못된 식별자 — 실질적으로 다른 레코딩에 재사용한 ISRC, 체크디짓이 맞지 않는 UPC.
기존 카탈로그와 불일치하는 아티스트명 — 대개 반려되지 않습니다. 그래서 이 목록에서 가장 손해가 큽니다.

한글 필드와 영문 필드의 불일치 — 한글 아티스트명은 그대로인데 영문 표기가 릴리스마다 달라지는 경우. 반려되지 않고, 영문권 스토어에서만 조용히 갈라집니다.
버전 표기 언어의 혼용 — 같은 카탈로그 안에서 (연주 버전)과 (Instrumental)을 섞어 쓰는 경우. 역시 반려되지 않고, 검색과 그룹핑에서만 손해를 봅니다.

10~12번은 공통점이 있습니다. 셋 다 반려되지 않습니다. 유통사의 사전 검증도, 스토어의 수신 검증도 이것을 잡아내지 못합니다. 검증은 "이 문자열이 규격에 맞는가"를 묻지 "이 문자열이 지난번과 같은가"를 묻지 않기 때문입니다. 그 질문을 할 수 있는 유일한 주체는 카탈로그를 가진 여러분입니다. 그래서 정본 문자열 파일 하나가 이 목록 전체보다 실질적으로 더 많은 손실을 막습니다.

딜리버리 직전 루틴 (10분이면 됩니다):

아티스트 문자열을 타이핑하지 말고 정본 파일에서 붙여넣기
모든 텍스트 필드에 NFC 정규화 적용
반각 자모·호환용 자모·중복 공백·앞뒤 공백 탐지
제목 필드에 곡 이름 외의 것이 없는지 확인
모든 역할에 필드가 있고, 모든 필드에 역할이 있는지 확인
로마자 표기가 정본과 글자 단위로 같은지 확인
가사 언어와 제목 언어 둘 다 설정
P라인과 C라인 확인 (연도와 권리자가 서로 다른 대상임을 확인)
최초 발매가 아니라면 최초 발매일 설정
아트워크와 필드를 글자 단위로 대조 (띄어쓰기 포함)
CSV로 제출한다면 UTF-8인지 확인 (CP949로 저장되지 않았는지)
괄호가 전부 반각인지 확인
비분리 공백(U+00A0)과 전각 공백(U+3000) 탐지

받은 반려는 싸고, 검증을 통과한 오류가 비쌉니다.

13. 요약

메타데이터는 릴리스·레코딩·작품 세 층에 기입되며, 비싼 오류의 대부분은 사실을 엉뚱한 층에 넣은 것입니다. 아티스트명은 라벨이 아니라 키이고, 역할은 신원, 제목은 표시입니다.
한글 정규화가 한국어 릴리스의 최대 단일 결함입니다. 완성형(U+AC00~U+D7A3, 음절당 1코드포인트·3바이트)과 조합형(U+1100~U+11FF, 음절당 2~3코드포인트·6~9바이트)은 화면에서 동일하고 바이트에서 다릅니다. 실측 확인: "한"은 NFC/NFKC에서 1코드포인트 3바이트, NFD/NFKD에서 3코드포인트 9바이트입니다. macOS의 HFS+는 파일명을 완전 분해 형태로 저장한다고 Apple이 문서화하고 있으므로, 파일명에서 만든 트랙 시트는 조합형입니다. 저장 형식은 NFC로 통일하십시오.
반각 자모(U+FFA0~)는 NFKC로만 제거되고 NFC/NFD는 손대지 않습니다. 호환용 자모(U+3131~)는 한국어 자판이 일상적으로 만들어 내며, NFKC를 통과시키면 결합 자모로 바뀌면서 다른 글자가 됩니다.
로마자 표기는 두 번째 법적 이름입니다. 국어의 로마자 표기법은 "성의 표기는 따로 정한다"고 명시하며, 그 공백에서 Lee/Yi/Rhee, Park/Pak/Bak, Kim/Gim, Jung/Jeong/Chung이 갈라집니다. 하나를 정하고 파일에 적어 두십시오.
이름 순서는 한글 필드에서 성-이름입니다. Apple 가이드는 로컬라이제이션에서도 "Family Name Given Name" 순서를 허용하며, 직접 든 예시가 박지윤 / Park Ji Yoon 입니다.
그룹명은 아티스트 필드, 멤버 크레딧은 기여자 필드, 솔로 프로젝트는 별개의 아티스트 개체입니다. 멤버 이름은 제목 필드에 들어가지 않습니다.
인코딩 유산도 남아 있습니다. KS X 1001은 한글 음절 11,172자 중 2,350자만 담고 8,822자를 담지 못하며, 한국어 윈도우 환경의 스프레드시트가 CSV를 CP949로 내보내는 순간 UTF-8 파이프라인에서 한글이 깨집니다. 유통 체인에 들어가는 텍스트는 UTF-8로 통일하십시오.
공백도 아티스트명을 가릅니다. 앞뒤 공백, 중복 공백, 비분리 공백(U+00A0), 전각 공백(U+3000)은 서로 다른 문자열이고 NFC는 이를 고치지 않습니다.
영문 제목은 제목 필드가 아니라 영어 로컬라이제이션 필드에 넣으십시오. 제목 안의 괄호 병기는 버전 파서와 검색 색인 둘 다를 혼란시킵니다.
장르는 라우팅입니다. 트로트를 임의로 "Pop"에 넣지 말고, 국악 릴리스는 가야금·거문고·해금·대금·장구·북 연주자를 악기 역할로 기여자 필드에 넣어 정보를 보존하십시오.
리패키지 앨범은 새 UPC를 받되, 재수록 트랙에 새 ISRC를 발급하지 마십시오. 재수록 트랙의 최초 발매일은 원 앨범의 발매일입니다.

마지막으로, 이 문서가 다루지 않은 것. 한국어 릴리스에는 여기서 다루지 않은 영역이 더 있습니다 — 가사 등록과 싱크 가사(LRC) 제출, 국내 음원 사이트별 심의 표기, 앨범 소개글의 언어별 로컬라이제이션, 그리고 뮤직비디오의 국내 등급 표기(Apple 스타일 가이드 §8.8은 한국에서 제작·심의된 뮤직비디오에 영상 시작부에 등급 정보를 burnt-in 하도록 요구합니다). 각각은 별도의 규칙 체계를 가지고 있으며, 이 문서의 원칙 — 신원은 역할 필드에, 표시는 표시 필드에, 정본 문자열은 한 번만 만든다 — 이 그대로 적용되지만 세부는 다릅니다.

출처

Unicode Standard Annex #15, Unicode Normalization Forms (Revision 57, Unicode 17.0.0, 2025-07-30) — https://www.unicode.org/reports/tr15/
Unicode Standard Annex #9, Unicode Bidirectional Algorithm — https://www.unicode.org/reports/tr9/
Unicode Character Database — 코드포인트 속성, 분해 매핑, Hangul Syllable Type — https://www.unicode.org/ucd/
Unicode 코드 차트: Hangul Jamo (U+1100–U+11FF), Hangul Compatibility Jamo (U+3130–U+318F), Hangul Syllables (U+AC00–U+D7A3), Halfwidth and Fullwidth Forms (U+FF00–U+FFEF) — https://www.unicode.org/charts/
Apple, Technical Note TN1150: HFS Plus Volume Format — https://developer.apple.com/library/archive/technotes/tn/tn1150.html
문화체육관광부 고시 제2014-42호, 「국어의 로마자 표기법」 (시행 2014.12.5) — https://www.korean.go.kr/kornorms/regltn/regltnView.do?regltn_code=0004 / 조문 전문: https://ko.wikisource.org/wiki/국어의_로마자_표기법
Apple Music Style Guide (§11.5 Cyrillic Languages, §12.2 Chinese or Korean Artists Without Western Names) — https://help.apple.com/itc/musicstyleguide/en.lproj/static.html
Spotify for Artists, Music metadata guidelines — https://support.spotify.com/us/artists/article/metadata-formatting-guidelines/
Spotify Provider Support, Featured artist in a product or track title — https://providersupport.spotify.com/article/featured-artist-in-a-product-or-track-title
Music Business Association, Music Metadata Style Guide v2.1 — https://www.musicbiz.org/wp-content/uploads/2016/04/MusicMetadataStyleGuide_V2.1.pdf
IFPI, International Standard Recording Code (ISRC) Handbook (§A.10.1 리마스터링과 창작적 개입) — https://www.ifpi.org/wp-content/uploads/2021/02/ISRC_Handbook.pdf
DDEX, Standards (ERN 포함) — https://ddex.net/standards/
함께하는음악저작인협회(KOSCAP) — https://www.koscap.or.kr/
한국음악실연자연합회(FKMP) — http://www.fkmp.kr/
한국음반산업협회(RIAK) — https://www.riak.or.kr/ / 국내 ISRC 안내 — http://isrc.or.kr/

검증 방법에 관하여. 이 문서의 정규화 수치 — 코드포인트 수, UTF-8 바이트 수, NFC/NFD/NFKC/NFKD 각 형식의 결과, 반각 자모와 호환용 자모의 변환 결과, 정렬 순서 — 는 Python 3.11의 unicodedata 모듈(유니코드 데이터베이스 버전 14.0.0)로 직접 실행해 얻은 것입니다. 한글의 분해·조합은 UAX #15 §14.1.4가 밝히듯 알고리즘으로 정의되어 있어 유니코드 버전 간에 안정적이지만, 직접 확인하는 데 한 줄이면 충분합니다: python3 -c "import unicodedata as u; s='가야금'; print(len(u.normalize('NFC',s)), len(u.normalize('NFD',s)))".

공개되지 않은 것의 경계에 관하여. 이 문서에서 스토어 규칙으로 제시한 것은 모두 해당 스토어의 공개 문서에서 인용했습니다. 아티스트가 사실처럼 전해 듣지만 어떤 서비스도 공표하지 않았고 따라서 여기서 주장하지 않는 것이 셋 있습니다: 아티스트 페이지 병합의 임계값과 증빙 요건, 딜리버리를 기존 아티스트에 붙일지 새로 만들지 결정하는 내부 매칭 로직, 그리고 Apple이 명시적으로 금지한 것을 제외한 각 스토어의 "Original Mix" 처리 방침. 국내 신탁관리 단체의 내부 심사·분배 절차도 마찬가지로 서술하지 않았습니다 — 각 단체의 공식 안내를 확인하십시오.