DDEX 피드 생성

DDEX 피드 생성은 음원 발매작과 그 메타데이터를 스트리밍 플랫폼이 자동으로 받아들일 수 있는 표준 XML 메시지로 변환하는 과정입니다. 이 포맷은 DDEX의 ERN(Electronic Release Notification)으로, DSP가 음원을 게시하는 데 필요한 모든 정보를 담습니다. 제목, 아티스트, ISRC, 아트워크 참조, 오디오 리소스, 지역, 거래 조건이 여기에 포함됩니다. 이 피드를 정확하게 생성해야 수작업으로 다시 입력하지 않고도 음원이 전송됩니다.

DDEX(Digital Data Exchange)는 디지털 음악 공급망 전반, 즉 레이블, 유통사, DSP, 퍼블리셔, 저작권 관리 단체 사이에서 쓰이는 XML 메시징을 정의하는 표준 기구입니다(DDEX ERN 문서). 표준을 구현하기 위해 DDEX 회원이 될 필요는 없습니다. 정작 손이 많이 가는 일, 그리고 대부분의 레이블이 직접 맡고 싶어 하지 않는 일은 유효한 ERN 피드를 생성하고 DSP마다 달라지는 요구 사항에 맞춰 계속 최신 상태로 유지하는 것입니다.

이 가이드에서는 ERN 메시지에 무엇이 담기는지, 피드 생성이 단계별로 어떻게 진행되는지, ERN 3.8.2와 4.3은 어떻게 다른지, 이 작업을 대신 맡는 제공업체를 어떻게 따져 보면 좋은지 설명합니다. LabelGrid의 자리도 함께 짚어 봅니다.

DDEX ERN 피드란 무엇인가요?

ERN 피드는 하나의 발매작이 어떻게 제공되어야 하는지를 기술하는 XML 문서입니다. 핵심 메시지는 NewReleaseMessage입니다. 이 메시지는 DSP에 필요한 세 가지, 즉 자산과 발매작과 거래 조건을 한데 묶습니다.

• ResourceList에는 음원, 영상, 이미지가 들어가며, 각각에 식별자(트랙의 경우 ISRC)와 기술 정보가 붙습니다.
• ReleaseList는 발매작 자체입니다. 제목, 표기 아티스트, 레이블명, UPC, 장르, 발매일이 담깁니다.
• DealList는 상업적 조건을 정합니다. 어느 지역과 플랫폼에 제공할지, 발매 시점, 사전 예약이나 사전 저장 기간 등이 포함됩니다.

음반사와 유통사는 이 메시지를 DSP에 전송하고, DSP는 피드를 해석한 뒤 거래 조건에 따라 음원을 게시합니다(DDEX ERN 문서). 게시 중단, 메타데이터 수정, 신규 지역 추가도 각각 같은 포맷의 별도 메시지가 됩니다. 필수 항목 하나만 잘못되어도 DSP는 피드 전체를 거부하기 때문에, 생성만큼이나 검증이 중요합니다.

DDEX 피드 생성은 어떻게 이루어지나요?

피드 생성은 발매작 데이터를 받아 DSP에 바로 전송할 수 있는 ERN 패키지로 만들어 줍니다. 일반적인 처리 과정은 다음과 같습니다.

1. 메타데이터를 수집합니다. 발매작·트랙 항목, 참여자, 식별자(ISRC, UPC), 지역, 명시적 표현 여부를 모읍니다.
2. 자산을 연결합니다. DSP별 사양에 맞게 트랜스코딩한 오디오 파일과 규격(보통 최소 3000×3000px)을 충족하는 아트워크를 리소스로 첨부합니다.
3. 검증합니다. 전송 전에 DDEX 스키마와 대상 DSP의 자체 프로필을 기준으로 피드를 점검합니다. 누락된 저작권 표기, 형식이 잘못된 ISRC, 규격에 못 미치는 아트워크가 이 단계에서 잡힙니다.
4. ERN XML을 생성합니다. 전송 대상에 맞는 버전(3.8.2 또는 4.3)으로 NewReleaseMessage를 구성합니다.
5. 전송합니다. 패키지를 각 DSP로 보내고 수신 확인을 받습니다.
6. 업데이트를 처리합니다. 수정, 게시 중단, 신규 지역 추가는 같은 발매작에 연결된 후속 메시지로 전송합니다.

이 작업이 만만치 않은 이유가 있습니다. 2024년에는 하루 평균 약 99,000개의 신규 트랙이 스트리밍 서비스로 전송되었습니다(Luminate 2024 연말 보고서). 이 정도 물량의 XML을 손으로 코딩하는 사람은 없습니다. LabelGrid은 DDEX 피드 생성을 처음부터 끝까지 처리합니다. 각 DSP의 최신 프로필을 기준으로 ERN을 생성·검증하고 모든 주요 플랫폼에 전송하므로, 레이블과 유통사는 피드 엔진을 직접 만들고 관리하는 대신 음원을 발매하는 데 집중할 수 있습니다.

ERN 3.8.2 대 ERN 4.3: DSP는 어떤 버전을 쓰나요?

오늘날 현장에서는 두 세대의 ERN이 함께 쓰이고 있습니다. ERN 3.8.2는 여전히 가장 널리 적용되어 있고, ERN 4.3.x는 DDEX가 신규 구현에 권장하는 버전입니다. 두 버전은 서로 호환되지 않습니다. 피드 엔진은 각 DSP가 요구하는 버전이 무엇이든 그에 맞춰 작동해야 합니다.

실무적인 결론은 이렇습니다. 적지 않은 중견 유통사가 ERN 3.8.2에 머물러 있는데, DSP가 여전히 이를 수용하는 데다 ERN 3에서 4로 넘어가려면 지역 데이터 모델 전체를 재구성해야 하기 때문입니다. 하지만 Dolby Atmos 메타데이터 기본 지원이나 PartyList 중복 제거 같은 새로운 기능은 ERN 4.x에만 존재합니다. 쓸 만한 제공업체라면 두 버전을 모두 지원하고 전송 대상마다 알맞은 버전을 골라 줍니다. LabelGrid은 전송과 가져오기 모두에서 DDEX ERN 3.8.2, 4.3.0, 4.3.1, 4.3.2를 지원합니다.

전송을 제대로 해내는 일의 중요성은 갈수록 커지고 있습니다. 2025년 스트리밍은 전 세계 녹음 음악 매출의 69.6%를 차지했고, 유료 구독자는 8억 3,700만 명에 달했습니다(IFPI 글로벌 뮤직 리포트 2026). 피드가 거부되거나 형식이 잘못되면, 지금 가장 많은 돈이 오가는 채널에서 노출 기회를 잃게 됩니다.

DDEX 피드 생성 서비스에서 무엇을 살펴봐야 하나요?

피드를 직접 만들지 않고 생성해 줄 제공업체를 고른다면, 다음 항목이 판단 기준이 됩니다.

DDEX로 음원을 전송하는 방법: 단계별 안내

1. 직접 구축할지, 외부에 맡길지 정합니다. ERN 엔진을 운영하고 모든 DSP 프로필 변경을 추적하는 일은 끊임없이 손이 가는 엔지니어링입니다. 대부분의 레이블과 유통사에게는 제공업체를 쓰는 편이 합리적인 선택입니다.
2. 버전 지원 범위를 확인합니다. 제공업체가 ERN 3.8.2와 4.3.x를 모두 생성하고, 각 DSP에 알맞은 버전을 보내는지 확인하세요.
3. 깔끔한 메타데이터를 준비합니다. 정확한 ISRC와 UPC, 올바른 저작권 표기, 규격에 맞는 아트워크가 필요합니다. 검증을 통과하려면 입력 데이터부터 깔끔해야 합니다.
4. 전송 전에 검증합니다. 스키마와 DSP별 점검을 거쳐 피드를 확인하세요. 무엇이든 보내기 전에 지적된 부분을 고칩니다.
5. 전송하고 확인합니다. 각 DSP로 보낸 뒤 수신 확인을 살핍니다. 어느 플랫폼이 발매작을 수용했는지 추적하세요.
6. 카탈로그를 관리합니다. 수정, 신규 지역, 게시 중단을 후속 메시지로 전송하고, DSP 사양이 바뀔 때는 피드를 잘 살펴봅니다.

LabelGrid은 ERN 3.8.2, 4.3.0, 4.3.1, 4.3.2를 아우르는 완전한 DDEX 피드 생성, 전송 전 검증, 오디오 트랜스코딩, 모든 주요 DSP로의 전송으로 이 과정에 들어맞습니다. 프로그래밍 방식으로 운영하려는 팀이라면 동일한 처리 과정을 LabelGrid의 REST API로 이용할 수 있으며, 샌드박스와 공개 문서도 함께 제공합니다. Spotify Preferred Provider이자 Merlin Network 회원사로서, LabelGrid은 플랫폼 요구 사항이 바뀌어도 피드를 최신 상태로 유지합니다.

DDEX 피드 생성: 핵심 정리

DDEX 피드 생성은 발매작을 표준 ERN 메시지로 바꾸는 일입니다. 리소스, 발매 데이터, 거래 조건을 담은 NewReleaseMessage가 그것이며, DSP는 이를 자동으로 받아들입니다. 현장에서 쓰이는 버전은 둘입니다. 가장 널리 적용된 ERN 3.8.2, 그리고 더 작고 중복이 없으며 공간 음향까지 지원해 DDEX가 권장하는 4.3.x입니다. 좋은 제공업체라면 이 두 버전을 모두 다루면서 전송 전에 검증하고, DSP 사양이 바뀔 때마다 그 변경을 빠짐없이 따라갑니다. 엔진을 직접 만들면 관리 부담이 끊이지 않습니다. 거의 모든 경우에는 생성, 검증, 전송을 한꺼번에 처리하는 제공업체가 더 나은 선택입니다. LabelGrid은 레이블과 유통사를 위해 DDEX 전송을 처리합니다. 지원하는 네 가지 ERN 버전 전체를 아우르며, API 접근과 직접 계약 카탈로그를 위한 SOBO도 제공합니다.