BLOTER.NET

이곳이 바로 일본에서 보아가 오리콘 차트 1위 했다고 하는 그 오리콘이라는 미디어 그룹 이다.  사실 DRM 이라는 부분이나 사업적인 모습과 다양한 IT 기기들에 DRM 걸린 디지털 콘테츠를 서비스 하는 노력들은 미국보다도 일본이 앞서 있다. 그럼에도 불구하고 항상 2인자를 벗어나지 못하는 이유는 바로 “너무 재기 때문이다.”  지를땐 아무생각 없이 질러야 하는데,,
소니에서 Playstation 아버지라는 쿠다라기겐이 그렇게 아버지로 불리우는 이유는 바로 본인의 철학과 생각을 실천하는데 두려워 하지 않았다는 것 아니가…  

일본 오리콘에서의 여러 사업들을 경험 하면서 난 일본 IT의 강점과 단점을 볼 수 있는 좋을 경험을 가지게 되었다. 자 2회차로 가자.

2. MP3 서비스용 DRM을 통해 본 음악 다운로드 서비스 환경

MP3P(MP3 Player) 포함해서 mp3등의 음악 파일이 재생 가능한 이동형 단말기, 핸드폰등에서 mp3 파일을 합법적으로 이용하는 과정을 통해 유료 음악 서비스에 적용된 DRM Service Platform을 살펴 보기로 한다. 그림 2는 Teruten의 MediaShell DRM Service Platform 구조도인데 Apple 사의 iTunes 서비스 또한 유사한 Service Platform 구조를 가지고 있다.

(1) Packaging

음악을 MP3 형태로 유료 서비스를 하기 위해서는 우선적으로 저작권자나 Contents Holder가 아닌 이상 디지털 배포권 관련 계약을 통해 합법적으로 권리를 선 취득 해야 한다. 흔히들 이분야 종사자가 아닌 경우 혼동하는 부분이, CD를 통한 음반 배급권을 가지고 있다고 해서 CD에 담긴 음악을 MP3 형태로 배급할 수 있는 권리가 반드시 동시에 주어지는 것은 아니라는 것이다. 배급 Channel이 틀리면 당연히 해당 권리도 틀리며 각기 별도 계약을 요한다. 음악서비스가 오직 PC 에서만 허용되는 재생인지 혹은 PC를 통해 개인의 MP3P 로 다운받아 이용하는 이동형 디바이스 지원 서비스인지에 따라서도 당연히 계약 조건이나 Guarantee가 달라지게 된다.

이러한 디지털 배급권 확보시 곡당 혹은 가수당 특정 기간 동안의 배급권을 고정된 일시불로 계약하는 경우도 있지만 대부분은 RS(Revenue Share)방식을 취하며 저작권자와 서비스권자 사이의 투명한 매출 정산을 위해서는 얼마만큼 특정 음악이 고객에게 다운로드 되었으며 고객은 몇 번이나 그 음악을 재생하고 있으며 재생 횟수당 혹은 기간당 얼마를 과금할 건지 그리고 MP3P 같은 이동형 디바이스로의 전송을 허용할 것인지 등에 관한 Service Rule Set(Service Policy)을 사전에 정하고 원본 음악 파일과 Policy 메타데이터를 Packager를 통해 서비스 서버에 전송하게 된다.

이 과정을 Packaging이라고 하고 이때 사용하는 Tool을 통상 Packager라고 한다.

Packaging은 다음 2가지 방식으로 분리 된다.

(1) Pre-Packaing

(2) Real-Packaging

Pre-Packaging과 Real-Packaging의 가장 큰 차이점은 Pre-Packaging의 경우에는 서비스용 서버에 미리 암호화(Encryption)된 음악파일(콘텐츠)을 두는 반면 Real-Packaging의 경우에는 서버에는 암호화 되지 않은 원본 파일을 저장하고 실제 서비스시 실시간으로 암호화 되어 사용자에게 전송 된다는 것이다. 어느 시점에서 암호화 되느냐의 차이인데 그것으로 인한 결과 및 효과는 상당히 많은 차이를 보이게 된다.

몇 가지 장단점을 나열해보면 다음과 같다.

Pre-Packaging의 경우

?  서버에 암호화된 콘텐츠를 저장하기 때문에 원본 유출의 염려가 없다. 참고로 콘텐츠 보안 침해사고의 70%이상이 내부자 소행임을 감안 할 때에 저작권자나 Contents Holder들처럼 직접 서비스는 하지 않고 타 서비스 회사에 서비스 권을 양도 하고자 하는 비즈니스 사업자들에게 유리

?  미리 암호화 되어 있어 Real-Packaging 에 비하여 서버나 클라이언트에 부하를 주지 않는다. 상당히 큰 파일에 적용하여도 End-User 단에서의 부하나 시간 지연등이 없다.

?  원본을 미리 암호화 하기 때문에 만약 Service Rule Set 내지는 Service Policy 변경시 원본과 함께 암호화 되는 Policy 메타데이터의 변경으로 Packaging 작업을 다시 해야 한다.

Real-Packaging의 경우

?  서버에 암호화 되지 않은 원본 콘텐츠가 저장되기 때문에 Pre-Process 즉 별도의 추가 업무를 요구하지 않으나 원본 유출 가능성이 존재한다.

?  암호화 과정이 실시간이기 때문에 서버나 클라이언트에 부하가 가중될 가능성이 있으며 파일 사이즈가 비교적 작아 Real-Packaging시 시간과 부하가 작은 MP3 같은 음악파일에 많이 적용 되고 있다.

?  원본을 미리 암호화 하지 않기 때문에 만약 Service Rule Set 내지는 Service Policy 변경시 Packaging 작업을 다시 하지 않고 Service Policy 메타데이터만 변경하면 된다.

두가지 방식중에서 어느 것이 좋다라고 단정 지어 말할 수는 없으나 일반적으로 파일 사이즈가 작은 디지털 콘텐츠에는 Real-Packaging을 권장하고 파일 사이즈가 큰 콘텐츠에는 Pre-Packaging이 권장된다.

물론 Teruten의 MediaShell같은 두가지 방식을 혼합한 Hybrid-Packaging방식도 존재하여 각 서비스 상황에 맞게 대처할 수 있는 솔루션도 있다.