히포

1. 스레드란

• 프로세스가 할당받은 자원을 이용하는 실행 흐름의 단위
• 모든 프로세스는 한 개 이상의 스레드가 존재하여 작업을 수행
• 두 개 이상의 스레드를 갖는 프로세스의 경우 멀티 프로세스로 표현
  
  
• 스레드를 사용하여 프로그램의 여러 부분을 동시에 수행 가능
• 프로그램의 여러 부분을 수행하는 최소의 실행 단위를 스레드라고 표현
  
  
• 한 프로세스 내에서 동작되는 여러 실행의 흐름으로 프로세스 내의 Heap, Data, Code 영역 공유
• 멀티 스레드의 경우, 스레드 간의 자원을 공유하고 자원의 생성과 관리의 중복성을 최소화하여 수행 능력 향상

2. 스레드 수행 시 필요 정보

• program counter → 프로그램의 어느 부분을 실행하고 있는지에 대한 정보 저장
• stack → 함수를 호출하는 순서(function call)에 대한 정보 저장

3. 스레드 메모리

• 스레드는 각각 stack 영역은 할당 받고 나머지 영역은 공유
• 하나의 스레드에서 오류가 발생한다면 프로세스의 다른 스레드도 모두 강제 종료

4. 싱글 스레드 vs 멀티 스레드

4.1. 싱글스레드

장점	자원 접근에 대한 동기화 X → 멀티스레드의 경우 자원 공유로 인해 동기화 고려가 필요하나 싱글 스레드의 경우 자원 동기화 고려 필요 X 문맥 교환 작업 X → 문맥 교환은 여러 개의 프로세스가 하나의 프로세서를 공유할 때 발생하는 작업으로 많은 비용 필요 단순 CPU만을 사용하는 계산 작업이라면 멀티스레드 보다 싱글스레드로 프로그래밍 하는 것이 효율적
단점	여러 개의 CPU 활용 X 연산량이 많은 작업을 하는 경우 그 작업이 완료되어야 다른 작업 수행 가능 에러 처리를 못하는 경우 정지

4.2. 멀티스레드

장점	응답성 → 프로그램의 일부분이 중단되거나 긴 작업을 수행하더라도 프로그램 수행이 계속 → 사용자 응답성 증가 경제성 → 프로세스 내 자원들과 메모리를 공유하기 때문에 메모리 공간과 시스템 자원 소모 저하 멀티프로세서의 활용 → 다중 CPU 구조에서는 각각의 스레드가 다른 프로세서에서 병렬로 수행 → 병렬성 증가
단점	동기화 구조 → 공유하는 자원에 동시에 접근하는 경우 스레드는 데이터와 힙 영역을 공유하기 때문에 동기화 필요 context switching → 동기화 등의 이유로 싱글 코어 멀티 스레딩은 스레드 생성 시간이 단일 스레드 보다 속도 저하

1. 데몬이란

• 리눅스 시스템이 부팅 시 자동으로 실행되는 백그라운드 프로세스
• 메모리에 상주하면서 특정 요청이 오면 즉시 대응할 수 있도록 대기 중인 서버 프로세스
• 부모 프로세스를 갖지 않으며, 대부분 프로세스 트리에서 init 바로 아래 위치
• 데몬의 명칭은 보통 Daemon을 뜻하는 'd'를 이름 끝에 달고 있음 
  ex) httpd는 아파치 웹 서버 데몬

 2. 데몬 실행 방식

1. 프로그램

 1.1. 프로그램이란

• 프로그램은 실행 파일을 의미
• 주기억 장치에서 상주된 프로그램이 CPU에 의해서 처리되는 상태는 프로세스라고 함
  
  

1.2. 프로그램 실행 과정

1. 사용자가 OS에게 프로그램 실행 요청
2. 운영체제가 프로그램의 정보를 메모리(주기억장치_RAM)에 로드
3. CPU가 프로그램 코드를 관리&명령 실행

2. 프로세스

2.1. 프로세스란(개념, PID, PPID, init, 관련 명령어)

• 메모리에서 CPU를 할당 받아 실행 중인 프로그램
• 각각의 프로세스마다 고유 번호의 프로세스 ID(PID)를 하나씩 증가하면서 부여
  
  
• PPID (부모 프로세스)
  - 선행 프로세스라고도 하며, 자식 프로세스 생성 가능
  - fork() 호출을 통해 자식 프로세스 생성
  - 부모 프로세스는 여러 개의 자식 프로세스를 실행하여 다수의 작은 작업들을 동시에 처리 
  
  
• 자식 프로세스
  - 부모 프로세스가 처리 중인 파일 등을 공유
  - 부모 프로세스에서 fort()하여 생긴 프로세스
  - 프로그램에서는 부모 프로세스의 복사로 부모와 교신하면서 프로세스 진행
  
  
• init
  - 부팅되면서 가장 먼저 실행되는 프로세스는 init, init의 PID는 1
  - init 프로세스는 파일 시스템의 구조 검사
  - 파일 시스템의 마운트하고 서버 데몬을 실행하며, 사용자 로그인을 기다리고 사용자를 위한 셸을 실행하는 역할
  - /etc/initab : 처음 수행해야할 작업들을 설정하는 파일, 시스템의 상태에 따라 해당하는 런레벨에서 init 프로세스가 수행해야할 파일을 지정
  
  

2.2 프로세스 관련 명령어

• ps 명령어 : 현재 작동하는 프로세스 목록, 프로세스의 현재 상태 출력

• kill 명령어 : 현재 작동하는 프로세스 종료

• top 명령어 : 실시간 프로세스 모니터링

2.3. 프로세스 상태

• 프로세스의 상태 종류 : 생성, 준비, 실행, 대기, 종료
  1. new : 프로세스가 생성된 상태
  2. ready : 프로세스가 생성된 후 프로세서에 할당되기를 기다리는 상태
  3. running : 프로세서에 할당되어 CPU를 차지하고 있는 상태
  4. wait : 프로세스가 특정 이벤트를 기다리는 상태 → 프로세서에 할당되어 있지만 프로세서의 클락을 낮추거나 일시적으로 멈춤으로써 에너지 소비를 줄일 수 있는 상태
  5. terminated : 프로세스 종료된 상태

• 프로세스의 상태 전이
  1. Dispatch (ready -> running)
     • 여러 프로세스들 중 한 프로세스를 선정하여 CPU에 할당하는 과정
  2. Interrupt (running -> ready)
     • 할당된 CPU 시간이 지나면 Timeout Interrupt 가 발생하여 CPU를 다른 프로세스에게 양도하고 자신은 ready 상태로 전이되는 과정
  3. Block (running -> waiting)
     • I/O 등의 자원 요청 후 즉시 할당받을 수 없어, 할당받을 때까지 기다리기 위해 running에서 waiting 상태로 전이되는 과정
     • I/O 처리는 CPU가 아닌 I/O 프로세스가 담당하기 때문에 block이 발생함
  4. Wakeup (waiting -> ready)
     • 필요한 자원이 할당되면 프로세스는 waiting에서 ready 상태로 전이되는 과정

2.4. 프로세스의 구성

2.4.1. 프로세스 메모리 

• 운영체제는 프로세스마다 고유의 가상 메모리 공간 제공
• 프로세스 메모리 공간은 다시 코드, 데이터, 스택, 힙 영역으로 세분화

• text section instruction(text section)
  - 컴파일된 기계어가 저장되는 영역
  - compile time에 크기 결정
  
  
• data section
  - 사전에 선언된 데이터가 저장되는 영역
  - compile time에 크기 결정
  - 내부 data&bbs 영역으로 구분 
    • initalized data section → 초기화된 전역 변수가 저장되는 영역 (DATA)
    • uninitialized data section → 초기화되지 않은 전역 변수가 저장되는 영역 (BBS)
  
  
• heap 
  - new, delete, malloc, free 등을 호출하여 데이터를 저장 & 관리하는 영역
  - runtime에 크기가 결정
  
  
• stack
  - 매개변수, 지역변수, return 주소 등과 같은 데이터를 저장하는 영역
  - 컴파일러에 의해 run time 도중 크기가 결정되며, 함수가 호출 & 종료되는 시점에 생성 & 제거
  
  

2.4.2. PCB (Process Control Block)

• PCB는 특정한 프로세스를 관리할 필요가 있는 정보를 포함하는, 운영체제 커널의 자료구조
  
  • 운영체제가 프로세스 스케줄링을 위해 프로세스에 관한 모든 정보를 가지고 있는 데이터베이스
  • 운영체제에서 프로세스는 PCB로 나타냄
  • PCB는 프로세스에 대한 중요한 정보를 가지고 있는 자료 구조
    
    
• 각 프로세스가 생성될 때마다 고유의 PCB가 생성되고, 프로세스가 완료되면 PCB는 제거됨
  • 프로세스는 CPU를 점유하여 작업을 처리하다가도 상태가 전이되면, 진행하던 작업 내용들을 모두 정리하고 CPU를 반환 필요
  • 진행하던 작업들을 모두 저장하지 않으면 다음에 자신의 순서가 왔을 때 어떠한 작업을 해야하는지 알 수 없는 상태에 빠짐
  • 프로세스는 CPU가 처리하던 작업의 내용들을 자신의 PCB에 저장하고, 다음에 다시 CPU를 점유하여 작업을 수행해야 할 때 PCB로부터 해당 정보들을 CPU에 넘겨와서 계속해서 하던 작업을 진행할 수 있음

• PCB는 다른 프로세스들이 쉽게 접근할 수 없고, kernel 영역에 저장
• PCB 저장 정보 : process state, PID, PPID, CPU registers, program counter, CPU scheduling 정보, Memory 관리 정보, accounting 정보, I/O 상태 정보

• 참고 자료 : OS & Process, Thread (velog.io)

• 오늘날 스마트폰, PC와 같이 인터넷에 연결된 디바이스만 있으면 원하는 실시간 인터넷 방송을 언제 어디서든 시청하고 마음만 먹으면 직접 방송까지 할 수 있는 시대에 도달하였습니다.
• 최근에는 인터넷 방송 플랫폼의 발전과 네트워크 품질의 개선으로 인터넷 방송을 진행하는 BJ(Broadcasting Jockey)와 시청자들 간의 소통이 방송 중 거의 실시간으로 가능한 수준까지 되었습니다.
• 실시간으로 인터넷 라이브 방송을 하기 위해서는 인터넷 라이브 방송 뒷단에서 방송을 가능하게 하는 다양한 기술들이 사용되고 있습니다.

원본 영상이 시청자들의 동영상 플레이어 까지 전달되는 과정

• 구현에 따라 조금 달라질 수는 있지만 각 구성 요소들이 수행하는 기능은 반드시 필요
  원본 영상 → 라이브 인코더 → 미디어 서버 → 전송 서버(CDN) → 동영상 플레이어 → 시청자
  
  
• 구성 요소가 어떤 역할
  1. 영상 송출 : 원본 영상 → 라이브 인코더
  2. 영상 변환 및 전송 : 미디어 서버 → 전송 서버(CDN)
  3. 영상 재생 : 동영상 플레이어→ 시청자

라이브 인코더

• 라이브 인코더는 원본 영상을 정해진 방식으로 압축(인코딩) 하고, 압축한 콘텐츠를 미디어 서버로 전송
• 인코더에서 미디어 서버로 컨텐츠를 전송하는 것을 송출이라고 함

1. 인코더의 종류

1. PC에 설치해서 사용할 수 있는 소프트웨어 인코더
2. 박스 형태의 하드웨어 인코더
3. 촬영하면서 송출까지 할 수 있는 모바일 앱 인코더
4. 오픈소스인 ffmpeg을 이용하여 구현한 인코더

2. 압축(인코딩)

• 카메라로 촬영한 원본 영상을 그대로 미디어 서버에 전송하기에는 데이터 용량이 너무 크기 때문에 압축하는 과정이 반드시 필요
• 미디어 서버에서 해석할 수 있는 압축 방식(코덱, Codec)을 사용
• 인터넷 방송에는 H.264/AAC 코덱이 주로 사용, 최근에는 더욱 압축 효율이 좋은 H.265 코덱을 사용하는 경우 늘어남
• 인코딩은 CPU를 많이 쓰는 작업 → 인코딩 작업에 평균 CPU 사용률이 80% 를 넘을 경우 출력 영상의 품질이 나빠짐
• CPU 부하로 인해 송출 중인 영상이 계속 끊기거나 버벅거린다면 출력 해상도나 비트레이트를 줄여야 함
• 소프트웨어 인코더를 사용할 경우 안정적인 방송을 위해서 쿼드코어 CPU 가 탑재된 PC 사용을 권장

3. 송출

• 미디어 서버로 영상을 보낼 때는 인터넷 스트리밍에 최적화된 RTMP 프로토콜을 이용
• 과거에는 UDP 기반의 RTSP 프로토콜을 많이 사용했으나 최근에는 RTMP 프로토콜이 거의 표준처럼 사용
• 안정적인 송출을 위해서는 충분한 인터넷 업로드 대역폭이 확보 필요
• 가정이나 일반 사업장에서 사용하는 인터넷 품질은 상황에 따라 변하게 됨 → 중요한 방송이라면 별도 전용 회선을 설치하여 송출 권장
• 인터넷 업로드 대역폭은 출력 비트레이트의 두 배 이상 확보되는 것이 안정적
• 송출 중인 영상이 계속 끊기거나 버벅거릴 경우 출력 해상도와 비트레이트를 낮춰주면 출력 품질 개선에 도움이 됨

미디어 서버

• 미디어 서버는 인터넷 라이브 방송의 핵심적인 역할
• 인코더가 보내준 영상을 여러 가지 화질 및 비트레이트로 변환(트랜스 코딩)
• 화질별로 변환된 영상을 다시 HLS 형식으로 변환 (트랜스먹싱 혹은 패킷타이징이라고 함)

1. 화질 및 비트레이트 변환

• 인터넷 방송 서비스는 사용자의 다양한 디바이스 크기, 네트워크 환경에 맞는 영상을 시청하도록 하는 것이 중요 → 불필요한 데이터 사용과 - - 배터리 소모를 방지하고 최적의 화질을 보장할 수 있어야 함
• 미디어 서버에서 원본 영상을 여러 화질로 변환해 주어야 함
• 화질 및 비드레이트 변환은 라이브 인코더와 동일하게 CPU를 많이 사용 → 라이브 인코더가 압축해서 보내준 영상을 압축 해제(디코딩) 하고 화질 변환 후 다시 압축(인코딩) 함
• 인코딩 작업에 GPU 가속을 이용하면 CPU의 인코딩 부하를 상당 부분 줄일 수 있음

2. HLS 변환

• HLS(HTTP Live Streaming)는 전 세계에서 가장 널리 사용하고 있는 실질적인 표준 HTTP 스트리밍 프로토콜
• M3U8 확장자의 재생목록 파일과 영상을 잘게 쪼갠 TS 청크 파일들을 전송 → 모바일과 PC 등 다양한 디바이스에서 영상을 재생 가능
  
  ※ HLS 지연(latency)
  • 카메라가 촬영하는 시간과 그 영상이 시청자에게 표시되는 시간의 차이를 지연(latency)이라고 함
  • 시청자와 실시간 소통이 필요할수록 짧은 지연(low latency) 이 필요
  • 과거에는 10초 ~ 15초 분량의 TS 청크를 재생 목록에 3개씩 담아 사용 → 미디어 서버 입장에서 30초~45초 정도 분량을 버퍼에 담아두었다가 전달
  • 위 경우 사용자 입장에서는 전송에 소요되는 시간까지 포함하여 최소 30초, 최대 1분에 가까운 지연이 발생
  • 버퍼가 클수록 재생이 안정적이지만 지연 시간은 길어짐
  • 버퍼를 짧게 가져가면 지연은 적지만 네트워크 상황에 민감해져 재생 품질이 불안정해짐
  • 최근에는 네트워크 환경이 좋아져 보다 공격적으로 튜닝하여 사용
  • 1~2초 정도의 TS 청크를 사용 → 지연 시간을 10초 미만으로 줄일 수 있어 low latency를 구현 가능

3. 미디어 서버 솔루션

• 3.1. Wowza Media Server (유료)
  • 유료이지만 다양한 기능과 우수한 인코딩 성능으로 널리 사용
  • 안정적인 운영을 위해 평균 CPU 사용률이 60% 를 초과하지 않도록 관리해 주는 것이 중요
  • 720P HD 화질을 포함하여 3~4 종류의 품질로 트랜스코딩을 해야 한다면 쿼드코어는 약간 불안
  • 쿼드 코어 이상의 코어를 탑재한 CPU를 사용하는 것이 안정적
    
    
• 3.2. Nginx-rtmp (오픈소스)
  • Nginx-rtmp는 nginx의 모듈로 동작하는 미디어 스트리밍 서버
  • RTMP 소스를 Pull 혹은 Push 방식으로 입력받을 수 있고 RTMP/HLS/MPEG-DASH 출력을 지원
  • 오픈 소스인 ffmpeg을 연동하면 트랜스코딩을 비롯하여 기타 다양한 기능들을 구현 가능할 수 있어 유료 솔루션의 좋은 대안 가능

전송 서버 (CDN)

• 미디어 서버에서 실시간으로 생성한 HLS 영상 조각 파일을 사용자에게 전달하려면 전송 서버가 있어야 함 → 일반적인 미디어 서버는 전송 서버의 역할까지 수행
• 동시 시청수가 많은 방송일 경우 대규모 트래픽을 안정적으로 처리하기 위해 CDN을 사용하는 것이 좋음
• CDN에서 캐싱을 하지 않으면 동시에 많은 시청자가 접속했을 때 미디어 원본 서버로 많은 요청이 들어갈 수 있음
• 무작정 캐싱 기간을 늘려놓는 것도 위험
• 최근 영상의 지연을 최소화하기 위해 TS 청크의 길이를 수초 단위로 사용
• HLS 재생목록 파일이 TS 청크의 재생 시간 내에 갱신되지 않으면 버퍼링이 발생하거나 플레이어가 영상 재생이 중단됨
• 재생 목록 파일은 TS 청크의 절반 정도 시간만 캐싱하고 갱신되도록 설정해야 함
• 콘텐츠 보호 차원에서 CDN 캐시 남아있는 과거 영상을 다운로드하는 것을 방지하기 위해 정해진 시간 이후에 들어온 요청은 캐시가 되어 있더라도 콘텐츠를 응답하지 않도록 설정 필요

동영상 플레이어

• 동영상 플레이어는 말단말에서 영상 컨텐츠를 재생하는 역할
• 미디어 서버에서 최종적으로 만든 HLS 형식은 모바일 단말이라면 안드로이드, 아이폰 구분 없이 내장된 플레이어를 통해 문제없이 재생 가능
• HLS는 Apple에서 만든 방식으로 맥 OS에서도 재생을 지원
• Windows PC에서 HLS를 재생하려면 별도의 외부 플레이어가 필요 → Window PC의 버전에 따라 다르지만 IE 11 이하에서는 HLS 재생을 지원하는 Flash 플레이어를 사용해야 함
• Chrome이나 Edge 같이 MSE (Media Source Extensions)를 지원하는 최신 브라우저라면 Javascript로 구현된 플레이어를 사용 → hls.js, video.js 사용
• 동영상 플레이어를 사용할 때 브라우저의 보안적 제약으로 재생이 불가능한 상황이 발생 가능
• 서비스 페이지의 도메인과 영상이 전송되는 도메인이 다르면 재생 X → 전송 서버나 미디어 서버에서 적절한 크로스 도메인 설정 필요
• HTTPS 페이지 내에서 HTTP 프로토콜로 전송되는 영상을 재생을 하려고 할 때, 재생이 되지 않을 수 있으니 영상도 HTTPS 프로토콜로 전송 필요

참고 자료

• https://medium.com/naver-cloud-platform/%EC%9D%B8%ED%84%B0%EB%84%B7-%EB%9D%BC%EC%9D%B4%EB%B8%8C-%EB%B0%A9%EC%86%A1%EC%9D%80-%EC%96%B4%EB%96%A4-%EA%B8%B0%EC%88%A0%EB%A1%9C-%EB%A7%8C%EB%93%A4%EC%96%B4%EC%A7%88%EA%B9%8C%EC%9A%94-98423dc7fcd4

• 문자셋(Character set) : 문자 코드 집합
• 인코딩(Encoding) : 문자 코드 집합을 표현하는 방법 → 인코딩 방법은 문자셋에 종속적임

1. 인코딩(Encoding)

• 컴퓨터 안에서는 문자든 숫자든 모두 숫자(‘01010001110011…’)로 나타냄
• 일반적으로 우리가 사용하는 언어(텍스트)를 기계가 이해하는 언어로 표현하는 방법을 인코딩(encoding)
• ASCII 코드는 미국에서 만든 최초의 문자열 인코딩 방법
  1. 대문자 A → 65로 ASCII 코드 표시
  2. 소문자 a → 97로 ASCII 코드 표시

• 영어, 중국어, 프랑스어 등 많은 언어마다 인코딩의 방법이 다름
• 한글을 기계가 이해시키는 인코딩 방법 → 여러개가 있는데 그 중 가장 많이 사용되는 것이 CP949와 UTF-8(Unicode).
  
  
  

2. ksc5601과 cp949

• ksc5601과 cp949은 문자셋이기는하나, 각각 조금은 다른 인코딩 방법

2.1. ksc5601

• 92년도에 국가에서 정의한 표준으로 2바이트를 사용
• 한글 2,350자 표현 가능
• 전각문자/기호/자소/선문자 0xA180 ~ 0xAFFF
• 한글영역 0xB0A1 ~ 0xC9FF
• 한자영역 0xCA80 ~ 0xFDFF

2.2. cp949

• cp949는 윈도95에 마이크로소프트가 독자적으로 제정한 규격
• 한글 11,172자 표현 가능
• cp949 인코딩은 확장된 euc-kr임 → 기존의 euc-kr에 추가적으로 지원하는 문자셋을 덧붙인 형태
• 현재는 윈도우가 유니코드도 지원하며, 요즘 개발되는 윈도우는 유니코드를 베이스 사용

2.3. windows, linux, java, web 정리 → 최근은 Unicode를 사용하기에 큰 의미는 없지만 혹시나 정리

• html 문서에 charset=cp949 등으로 지정된 웹페이지가 있기는 한데, 이것은 엄연히 표준을 위반
• W3C에서는 IANA에서 공인된 문자셋만을 표준 → CP949 혹은 MS949은 포함 X
• java에서 ksc5601가 cp949로 표시되는 지 모름, cp949는 또 ms949로 표현
• 윈도우는 CP949방식을 사용
• 윈도우를 개발한 마이크로 소프트에서 EUC-KR 방식에서 확장 → MS949
  

  

  
  
  
  

3. 유니코드(Unicode)

3.1. 한글의 문자 집합

• 문자를 표현하기 위해서 가장 먼저 ‘문자 집합’을 정의 필요
• 문자 집합은 표현해야 할 문자를 정하고 순서를 지정
• 예시
  1. 한글 표현 방법 중 조합형 : 한글의 원리에 기반하여 초성, 중성, 종성에 각각 코드를 할당하는 방식
  2. 한글 표현 방법 중 완성형 : ‘가’,’각’,’간’과같이 완성된 문자에 코드를 할당하는 방식으로, 한글 표준안
  3. 영어: ‘A’ ~ ‘z’ (대문자에서 소문자까지)
  4. CCS(coded character set) : 문자 집합을 행렬로 표기한 형태
  5. CES(character encoding scheme) : 문자 집합을 컴퓨터에 저장하기 위해서 8비트 단위 형태로 표현한 인코딩 방식

3.2. 유니코드

• 각 나라 언어에는 컴퓨터에서 해당 언어를 표현할 수 있는 독자적인 문자 집합이 있음
• 하나의 문자 집합을 사용하는 문서에서는 다개국어를 동시에 표현 X
• 유럽어의 문자도 마찬가지로 같은 문자지만 문자집합에 따라 코드가 다름
• 전 세계적으로 사용되는 모든 문자 집합을 하나로 모아 탄생시킨 것이 유니코드.

3.3. 유니코드 인코딩 방식

• 문자 인코딩은 문자들의 집합을 부호화(정보의 형태나 형식을 변환하는 처리)하는 방법
• 유니코드의 인코딩 방식
• 코드 포인트를 코드화한 UCS-2와 UCS-4
• 변환 인코딩 형식(UTF, UCS Transformation Format)인 UTF-7, UTF-8, UTF-16, UTF-32
• 위 인코딩 방식 중에 ASCII와 호환이 가능하면서 유니코드를 표현할 수 있는 UTF-8 인코딩이 가장 많이 사용

3.4. 코드포인트

• 유니코드의 값을 나타내기위해서는 코드포인트를 사용 → 보통 U+를 붙여 표시
• A의 유니코드 값 표기 방법 (아래 2가지 중 1가지 방법으로 표시)
  1. U+0041
  2. \u0041

• U+1100~U+11FF 사이에 한글 자모 영역
• U+AC00~U+D7AF 사이에 한글 소리 마디 영역

3.5. 유니코드 범위 목록에서 한글 관련 범위

3.6. 한글표현의 대표적 두 개의 코드영역

• 한글 소리 마디와 한글자모, 한글 자모 확장 이렇게 두 개의 코드 영역이 있다는 것은 같은 글자를 표현하는 서로 다른 두 개의 방법이 있음
• 같은 ‘가’의 글자여도, 표현법에 따라 코드 값이 다름

• 한글 소리마디
  • 초성, 중성, 종성으로 이루어진 한글을 표현하기 위한 영역
  • 현대 한글에서 표현 가능한 11,172자를 모두 포함 (‘가’ ~ ‘힣’)
  • ‘가’(U+AC00) ~ ‘힣’(U+D7A3)
  • 완성된 글자 하나하나에 코드를 매칭
  • 각 음절은 초성, 중성, 종성 순으로 정렬
  • 확장 완성형과 다른 점은, 초성, 중성, 종성의 분리가 가능
  • 초성은 19개, 중성은 21개, 종성은 28개로 이루어져 있음
  • 유니코드 한글의 각 음소를 분리하기 참고 URL : https://soooprmx.com/%ec%9c%a0%eb%8b%88%ec%bd%94%eb%93%9c-%ed%95%9c%ea%b8%80%ec%9d%98-%ea%b0%81-%ec%9d%8c%ec%86%8c%eb%a5%bc-%eb%b6%84%eb%a6%ac%ed%95%98%ea%b8%b0/
    

    

• 한글 자모, 한글 자모 확장
  • 초성/종성을 구별하는 자음과 모음으로 구성
  • 완성(조합 전) 문자 하나하나에 코드 매칭
  • 이를 이용하여 조합형 한글을 표현할 수 있음
  • 한글 자모 영역에는 옛한글에서만 사용된 초성, 중성, 종성이 있으므로, 옛한글을 표현할 수 있음
  • U+1100부터 U+115E까지는 초성, U+1161부터 U+11A7까지는 중성, U+11A8부터 U+11FF까지는 종성

3.7. 유니코드 정규화(Unicode equivalence)

• 유니코드 정규화(Unicode equivalence)란 연속적인 코드를 사용하여 표현한 어떤 글자를 처리하는 방법
• 프로그래밍 언어의 유니코드 정규화 기능을 사용하여 문자열을 분석 가능
• 다양한 인코딩 방식이 있기에 환경에 따라서 다른 인코딩을 만날 수 있음
• 웹의 경우에 어딘가에서 한글이 깨진다면, 그 이유는 브라우저 인코딩 값과 서버 인코딩 값이 다른 이유
• 웹에서 여러 인코딩을 지원하려면, 인코딩된 URL 문자열과 사용한 인코딩 정보를 파라미터로 전달
  

  

4. 인코딩 간의 문제점 → 인코딩방식에 따라 표기할 수 있는 관계

• 완성형 중에서 EUC-KR의 경우, 빠져있는 문자가 있어 모든 문자를 표현 불가능 → 웹을 사용하지 않는 윈도우 환경에서는 불편함 X
• 확장 완성형인 CP949의 경우에는 유니코드(UTF-8)에서 표현할 수 있는 모든 문자를 표현 가능
• 웹에서의 UTF-8이면 UTF-8, EUC-KR이면 EUC-KR끼리 밖에 제대로 표현 X →각종 웹 소스들을 사용할 때 인코딩 부분 해결해야함
• 웹에서 인코딩을 변환하도록 하는 함수도 있고, 서버 자체의 인코딩을 바꾸는 방법도 있음
• 환경마다 가지고 있는 문제들이 제각각이기 때문에, 한글 부분에 문제가 발생하면 인코딩을 먼저 확인 필요
  

  

1. 포렌식 워터마킹의 필요성과 기술에 대한 이해

• DRM이 적용된 콘텐츠는 암호화된 상태로 배포되기 때문에, 동영상 파일을 다운로드하여 배포하더라도 사용 권한(DRM 라이선스)이 없는 사람은 해당 동영상을 재생하지 못하게 됨
• 하지만 DRM 기술만으로는 콘텐츠를 불법 유출로부터 완벽하게 보호할 수 없음
• 암호화된 DRM 콘텐츠도 권한이 있는 사용자의 기기에서 최종적으로 재생되기 위해서는 복호화 과정을 통해 원본 형태로 전환 → 재생 과정에서 여러 가지 기술적인 한계로 인해 콘텐츠가 유출될 가능성이 있음
• 하나 콘텐츠가 유출되는 경우에 해당 유출자가 누구인지 추적해서 더 이상의 콘텐츠 유출을 방지할 수 있는 기술 → '포렌식 워터마킹'
  
  
  

2. 포렌식 워터마킹란

• 포렌식 워터마킹(Forensic Watermarking)은 '디지털 워터마킹'이라는 기술의 한 분야
• '디지털 워터마킹'은 사진이나 동영상과 같은 각종 디지털 데이터에 저작권 정보 같은 비밀 정보를 삽입하여 관리하는 기술
• 콘텐츠 저작권자 또는 콘텐츠 서비스 제공자는 불법으로 유통되는 콘텐츠를 발견했을 때 워터마크를 검출해 유출 경로와 사용자를 추적
• 추적을 통해 해당 사용자에게 서비스를 중지하거나 법적인 조치를 취하는 등의 방법으로 불법 유출을 막을 수 있음

• 디지털 워터마킹과 포렌식 워터마킹의 차이
  1. 디지털 워터마킹 → 저작권자의 정보를 콘텐츠에 삽입해 저작권을 주장하는 용도로 사용
  2. 포렌식 워터마킹 → 콘텐츠 사용자의 정보를 삽입해 불법 유포를 추적할 수 있도록 해줌
     
     
     

3. 포렌식 워터마킹의 필요성

• 콘텐츠를 DRM으로 암호화해 보호한다고 해도 현실적으로 불법 유출을 100% 방지하는 것은 어려움
• 암호화된 상태로 안전하게 클라이언트(재생 기기)까지 콘텐츠를 전달한다고 해도 사용자가 콘텐츠를 이용(재생) 하기 위해서는 결국 복호화를 할 수밖에 없기에 유출하는 순간이 발생

• 최종 단계의 안전하지 않은 구간에 암호화되지 않은 상태의 콘텐츠가 노출되는 것을 보완하는 기술
  1. 하드웨어 기반 DRM
  2. Trusted Execution Environment (TEE)
  3. High-bandwidth Digital Conent Protection (HDCP)
     
     
     

4. 컨텐츠 유출

4.1. 유출 경로 1 - 캠코더를 이용한 화면 녹화

• 가장 전통적인 콘텐츠 유출 경로 중 하나
• 캠버전 영상으로 화면에 재생되는 영상을 별도의 캠코더나 스마트폰 카메라 등으로 촬영해 녹화본을 만들어 내는 것 → DRM 기술로는 콘텐츠 유출을 막을 수 없음
• 화면을 별도 기기로 촬영하는 것을 Digital-to-Analog (D2A) 또는 Analog-to-Digital (A2D) 변환이라고 하며, 워터마킹에 대한 다양한 공격 방식 중 하나로 사용됨
• 소형화, 고성능화되는 촬영 기기들로 인해 최근에는 Full HD를 넘어 4K/UHD 해상도로 원본과 거의 유사한 화질의 영상을 쉽게 촬영 가능
• 물리적으로 통제가 가능한 영화관보다 넷플릭스와 같이 가정에서 이용하는 OTT 서비스들에게 더 심각한 문제

4.2. 유출 경로 2 - 스크린 레코더를 통한 영상 캡처

• PC 웹 브라우저와 HTML5 플레이어를 통한 DRM 콘텐츠 재생 지원은 OTT 서비스의 가장 중요한 타겟 플랫폼 중 하나
• 일부 웹 브라우저의 경우에는 소프트웨어 기반의 DRM이 적용 → 각종 스크린 레코딩 툴을 이용하면 브라우저에서 재생되는 DRM 영상을 일반적인 MOV나 MP4 형태의 동영상 파일로 쉽게 저장이 가능
• 윈도우 OS의 IE11(윈 8.1 이상)과 에지(윈 10) 브라우저에는 PlayReady DRM이 적용 → OS와 하드웨어 레벨의 스크린 캡처 방지 기능이 적용되어 스크린 숏이나 동영상 캡처가 불가능
• 맥 OS의 경우에도 사파리 브라우저에서 재생되는 FairPlay Streaming DRM 콘텐츠 → 스크린 레코더를 이용한 영상 캡쳐가 방지
• 크롬과 파이어폭스 브라우저는 윈도우, 맥 OS, 리눅스 등 대부분의 지원 OS 지원 → 소프트웨어 레벨의 Widevine DRM이 적용되어 영상 캡처 방지 X
  

  

  
  
  
  

5. 포렌식 워터마킹 기술의 기본 원리

• 포렌식 워터마킹 기술에 필요한 요구 사항 중에서 가장 중요한 두 가지 요구 사항
  1. 비가시성
  2. 강인성

• 공격으로부터의 '강인성'을 위해 높은 강도의 워터마크를 적용하다 보면 '비가시성'이 떨어져 워터마크가 눈에 보이게 될 수 있음
• 강인성과 비가시성을 모두 만족시킬 수 있도록 적절한 수준으로 워터마크를 적용하는 것이 포렌식 워터마킹의 주요 기술

5.1. 비가시성(Imperceptibility)

• 원본 영상과 워터마크가 삽입된 영상의 차이를 시각적으로 인지할 수 없어야 함
• 눈에 보이는 '가시성(Visible)' 워터마킹의 경우, 원본 콘텐츠의 품질을 떨어뜨리고 영상 편집을 통해 쉽게 제거 가능하기 때문에 포렌식 워터마킹 솔루션으로 적합하지 않음
• 비가시성을 만족하기 위해 대부분의 포렌식 워터마킹 기술은 프레임 이미지의 눈에 보이지 않는 영역에 워터마크 정보를 삽입
• 비가시성을 만족하는 워터마킹 솔루션은 아래 이미지에서 비교 가능 → 왼쪽 이미지와 오른쪽 이미지의 차이를 확인 X
  

  

5.2. 강인성(Robustness)

• 재인코딩, 크롭, 필터링 등 다양한 공격에도 워터마크 정보가 손상되지 않아야 함
• 최종 사용자를 추적하기 위해서 워터마크 '고유성'이 요구됨
• 각 재생 세션(Session)마다 고유한 사용자 정보를 워터마크로 삽입하는 세션 기반 워터마킹 기술이 필요
• 세션 기반 워터마킹 기술은 세부적으로 클라이언트 기반과 서버 기반 기술로 나누어짐

• 5.2.1. 클라이언트 기반 (Client-side) 워터마킹
  • 콘텐츠를 재생하는 사용자 기기(클라이언트)에서 워터마크의 삽입이 수행되는 방식
  • 워터마킹 도입에 필요한 서버 백엔드의 수정이 최소화 가능
  • 특정 클라이언트만 지원 가능한 단점이 있음

• 5.2.2. 서버 기반 (Server-side) 워터마킹
  • 콘텐츠 서비스의 서버 측에서 워터마크 삽입이 처리되는 방식
  • 서버의 콘텐츠 워크플로우에 연동 작업이 필요
  • 클라이언트 플레이어의 제약이 없다는 장점이 있음
    
    
    

6. 포렌식 워터마킹 적용 분야

• 위동영상 콘텐츠의 불법 유출을 추적하기 위해, 다양한 방식의 포렌식 워터마킹 기술이 개발되어 여러 분야에서 사용

6.1. 스크리너(Pre-release)

• 영화 개봉 전에 리뷰를 위해 스튜디오 내부/외부 관계자들에게 파일이나 디스크 등의 형태로 사전에 배포되는 영화 콘텐츠를 말함
• 불법 유출 시 저작권자에게 큰 피해가 발생
• 배포되는 채널과 대상에 대한 워터마크 정보를 삽입해 유출을 방지

6.2. 디지털 시네마

• 디지털 필름 형태로 극장에서 상영되는 콘텐츠에 워터마킹을 적용해 불법 촬영에 의한 유출에 대응
• 주로 상영관과 상영 시간 등의 정보를 워터마크로 삽입
• 디지털 시네마 시스템과 연동이 필요

6.3. OTT VOD 서비스

• 온라인 영화 서비스(넷플릭스, 푹 등)의 프리미엄 콘텐츠에 포렌식 워터마킹을 적용
• 서비스의 최종 사용자 정보를 실시간으로 삽입해 불법 유출을 추적 가능

6.4. 라이브 서비스

• 월드컵 중계와 같은 실시간 이벤트를 서비스
• 불법적인 스트림 재전송을 감지해 즉각적으로 차단하기 위하여 포렌식 워터마킹이 사용

7. 멀티 DRM과 포렌식 워터마킹

• DRM이 '허가되지 않은 사용자의 콘텐츠 불법 사용을 방지'하는 기술
• 워터마킹은 '허가된 사용자에 의한 콘텐츠 불법 유출을 추적'하는 기술
• 'DRM'과 '워터마킹'은 상호 보완적인 역할로, 최신 할리우드 영화와 같은 높은 수준의 보안이 필요한 프리미엄 콘텐츠에는 필수적으로 함께 적용 필요
  

  

참고 URL : https://pallycon.tistory.com/entry/%EB%84%B7%ED%94%8C%EB%A6%AD%EC%8A%A4%EB%8A%94-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%BD%98%ED%85%90%EC%B8%A0%EB%A5%BC-%EB%B3%B4%ED%98%B8%ED%95%98%EB%8A%94%EA%B0%80-%EC%A0%9C2%EB%B6%80

1. 콘텐츠 보안과 멀티 DRM에 대한 이해

• 넷플릭스와 같은 유료 콘텐츠 사업자의 입장에서 가장 우려되는 부분은, 서비스하는 콘텐츠가 불법으로 유출되어 유료 가입자의 수가 줄거나 성장이 둔화되는 것
• 콘텐츠 불법 유출을 막기 위해서 넷플릭스를 비롯한 여러 OTT 서비스들은 'DRM'과 '워터마킹'이라는 기술을 이용해 콘텐츠를 보호

2. DRM이란?

• 디지털 권리 관리(Digital Rights Management, DRM)는 저작권자가 그들이 배포한 디지털 자료의 사용을 제어하고, 의도한 용도로만 사용하도록 제한하는 데 사용되는 모든 기술을 지칭하는 용어
• 주로 전자책, 음원, 동영상 등의 디지털 콘텐츠를 인증된 사용자가 인증된 기간 동안만 사용 가능하도록 통제 → 정당한 비용을 지불하지 않은 불법적인 사용을 방지하기 위해 사용

• DRM의 기능
  1. 콘텐츠의 암호화 및 복호화
  2. 암호 키 관리

• 원본 콘텐츠는 DRM 패키징이라는 과정을 거쳐 암호화된 상태로 사용자에게 전달 → 콘텐츠 암호화에 사용된 암호 키 정보가 없이는 해당 콘텐츠를 복호화해 재생할 수 없음
• 넷플릭스를 예로 들면, 넷플릭스 iOS/Android 앱에서는 '저장' 기능을 통해 일부 TV 프로그램 및 영화 콘텐츠를 모바일 기기에 다운로드하고 나중에 오프라인 상태에서도 시청할 수 있도록 지원
• 다운로드되는 영상 콘텐츠는 DRM이 적용되어 암호화 되어있기 때문에, 해당 파일들을 별도로 복사해 배포하더라도 권한이 없는 사용자가 일반적인 동영상 플레이어로 재생하는 것은 불가능
• 콘텐츠 사용 권한을 가진 사용자에게는 '암호 키'와 '사용 권한 정보'가 콘텐츠와 별도로 전달 → DRM 라이선스(암호 키 + 콘텐츠 사용 권한 정보)를 안전하게 전달하고 관리하는 것이 DRM 솔루션의 핵심 기술

3. DRM과 웹 브라우저 지원

• '화면이 있는 모든 기기에 넷플릭스 서비스를 제공한다'는 것이 넷플릭스의 비전 선언문
• 넷플릭스 서비스는 다양한 클라이언트 기기들을 지원
• PC와 노트북 사용자들을 위하여 웹 브라우저를 지원하는 것은 대부분의 온라인 동영상 콘텐츠 서비스에 매우 중요한 사항
• DRM이 적용된 비디오 콘텐츠를 웹 브라우저에서 재생하기 위해서는 다양한 기술이 필요 → 관련된 동영상 스트리밍, DRM 및 웹 표준 기술의 발전에 따라 여러 변화를 거쳐왔음

3.1. 과거 - 싱글 DRM과 플러그인

• 넷플릭스가 온라인 콘텐츠 서비스를 시작한 2000년대 초반부터 약 10여 년 간, 대부분의 콘텐츠 서비스들은 특정 DRM 업체가 제공하는 단일 DRM 솔루션을 적용해 콘텐츠를 보호
• 마이크로소프트 PlayReady, 구글 Widevine Classic, 어도비 Access, 인터트러스트 Marlin, 잉카엔트웍스 Netsync DRM 등의 다양한 DRM 솔루션들이 콘텐츠 서비스 업체의 선택에 따라 사용
• 다양한 DRM 솔루션을 싱글 DRM'솔루션이라고 하며, 모두 플러그인 방식 브라우저 지원이라는 공통의 문제점 발생

• ActiveX 컨트롤 설치 경고 메시지
  

  

• ActiveX 컨트롤 보안 경고는 대부분의 인터넷 사용자들에게 익숙할 정도로 많은 보안 솔루션에서 웹 콘텐츠와 애플리케이션 보안을 위해 사용
• 기존의 단일 방식 DRM 솔루션들도 웹 브라우저에서 재생되는 오디오/비디오 콘텐츠를 보호하기 위해 플래시와 같은 별도의 브라우저 플러그인을 사용해야 했음
• 각종 보안 이슈와 성능 등의 문제로 웹 브라우저들의 플러그인 지원이 중단되어 플러그인 방식의 DRM 솔루션은 시장에서 사라져 가고 있음

3.2. 현재 - 멀티 DRM, 플러그인으로부터의 해방

• HTML5 표준에는 플러그인 문제를 해결하기 위한 여러 규격들이 추가됨
• 인크립티드 미디어 익스텐션(Encrypted Media Extension, 이하 EME) 규격은 웹 브라우저 상에서 실행되는 HTML / Javascript 기반 웹 애플리케이션이 콘텐츠 보호 시스템(DRM)과 상호 작용할 수 있게 하는 API를 제공해 암호화된 오디오와 비디오를 재생할 수 있도록 함
• EME 규격과 미디어 소스 익스텐션(Media Source Extension, 이하 MSE) 규격을 통해 기존에는 별도의 플러그인으로 지원되던 DRM 콘텐츠의 재생이 웹 브라우저 자체적으로 지원

• 멀티 DRM이라는 용어가 사용되는 이유
  1. 크롬, 사파리, IE/엣지 등 각 브라우저마다 서로 다른 DRM을 기본 지원
  2. 마이크로소프트의 IE와 엣지 브라우저는 마이크로소프트에서 제공하는 PlayReady DRM을 지원
  3. 구글 크롬은 구글의 DRM인 Widevine Modular DRM을 지원
  4. 애플의 사파리는 FairPlay Streaming이라는 애플의 DRM을 지원
  5. 모질라 재단의 파이어폭스 브라우저는 크롬과 동일하게 Widevine Modular DRM을 지원

• 윈도우, 맥 OS 등 다양한 환경의 PC 사용자들에게 편리한 서비스를 제공하기 위해서는 기본적으로 PlayReady, Widevine Modular, FairPlay Streaming 이렇게 세 가지 서로 다른 DRM을 콘텐츠에 적용해야함
• 각 DRM에서 지원되는 스트리밍 방식에도 차이가 있음
  1. PlayReady와 Widevine → MPEG-DASH
  2. FairPlay DRM → HLS(HTTP Live Streaming)

• 브라우저 별 지원 DRM과 콘텐츠 형식
  

  

• 멀티 DRM 콘텐츠는 웹 브라우저뿐만 아니라 스마트폰, 태블릿, 스마트 TV 등 멀티 DRM을 지원하는 다양한 모바일 및 OTT 클라이언트 기기에서도 사용
• 멀티 DRM 적용으로 대부분의 사용자 환경을 지원할 수 있으며, 넷플릭스와 같이 멀티 DRM이 지원되지 않는 오래된 기기들까지 지원하기 원하는 경우에는 기존 방식의 DRM도 함께 사용

3.3. 미래 - CMAF을 통한 멀티 DRM의 콘텐츠 단일화

• 멀티 DRM을 통해 플러그인 없이 브라우저를 지원 가능 → 하나의 원본 콘텐츠를 두 가지 서로 다른 스트리밍 포맷으로 준비해야 하는 불편함 발생
• MPEG-CENC(Common Encryption) 규격에 따라 PlayReady와 Widevine DRM은 하나의 DASH 콘텐츠에 적용되지만, FairPlay DRM은 별도로 HLS 콘텐츠가 필요
• DASH/HLS 두 벌 콘텐츠가 필요한 문제점을 해결하기 위해, 단일 콘텐츠로 모든 브라우저와 플랫폼을 지원하는 CMAF(Common Media Application Format) 규격이 발표.
  

  

• CMAF 단일 콘텐츠가 현실화되기 위해서는 각 DRM과 플랫폼에서의 지원이 필요 → 마이크로소프트와 애플, 구글 등 관련 업체들의 협력에 의해 대부분의 문제점들이 해결
• 2019년 현재 시점에도 CMAF을 지원할 수 없는 클라이언트 기기들(구 버전 안드로이드 단말 등)이 시장에 존재하기 때문에, CMAF 단일 콘텐츠를 실제 서비스에 적용하기 위해서는 아직 더 많은 시간이 필요
• DRM 콘텐츠의 단일화 외에도 CMAF의 주요 장점으로는 'Chunked Transfer Encoding'이라는 기술을 통한 'Ultra Low Latency' 기능

• Low Latency
  1. 스포츠 중계와 같이 실시간으로 스트리밍 되는 라이브 콘텐츠에 가장 중요한 요소
  2. 최근 라이브 OTT 서비스 업계에서는 CMAF Low Latency 기술이 화두가 되고 있음
  3. CMAF을 통한 DRM 콘텐츠 단일화와 Ultra Low Latency 지원에 대한 내용은 별도의 글 → 참고 URL : https://pallycon.com/ko/blog/%EB%A9%80%ED%8B%B0-drm-%EC%BD%98%ED%85%90%EC%B8%A0-cmaf%EC%9C%BC%EB%A1%9C-%EB%8B%A8%EC%9D%BC%ED%99%94%ED%95%A0-%EC%88%98-%EC%9E%88%EC%9D%84%EA%B9%8C
     
     
     

4. 편리하지만 복잡한 멀티 DRM

• 플러그인 없이 브라우저를 지원할 수 있고 다양한 모바일과 OTT 기기들을 지원 가능한 멀티 DRM은 최종 사용자 입장에서 기존 방식의 DRM보다 훨씬 편리한 기술
• 멀티 DRM을 도입하는 콘텐츠 서비스 업체의 입장에서는 멀티 DRM은 여러 가지 서로 다른 DRM과 스트리밍 포맷을 적용해야 하는 복잡하고 어려운 기술
• 복잡한 멀티 DRM 기술을 쉽고 빠르게 적용하려면, 여러 DRM 기술을 통합해 단일화된 API를 제공하고 인코더/플레이어 등 각종 미디어 관련 솔루션들과 연동되어 있는 멀티 DRM 솔루션 업체를 이용하는 것이 좋음

참고 URL : https://pallycon.tistory.com/entry/%EB%84%B7%ED%94%8C%EB%A6%AD%EC%8A%A4%EB%8A%94-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%BD%98%ED%85%90%EC%B8%A0%EB%A5%BC-%EB%B3%B4%ED%98%B8%ED%95%98%EB%8A%94%EA%B0%80-%EC%A0%9C1%EB%B6%80

• DRM은 Digital Rights Management의 줄임말로 우리말로는 ‘디지털 저작권 관리’라고 해석
• 저작권자가 배포한 디지털 자료(문서, 파일 등)나 하드웨어의 사용 제한
• 특정 자료를 저작권자가 의도한 용도로만 사용하도록 제한하는데 사용되는 모든 기술(복사 방지, 기술보호 장치 등)
  

  

DRM이란

• 디지털 환경에서 콘텐츠를 만들어낸 지적 재산권 보호와 창작물을 사용하고자 하는 사용자의 의무와 권리를 보호하기 위한 기술
• 오프라인에서 내가 만든 제품이 있다고 하면 수공예품이건 공장에서 생산된 물건이건, 구매자의 손에 전달되기까지 유통 구조를 거치게 되고 더 나아가 판매한 제품에 대한 관리도 됨
• 온라인을 이용하게 될 때, 유사한 절차를 거치게 되는데, 만약 지적 재산권이 문제가 되지 않는다면 일반적인 온라인 마켓을 이용
• 창작한 콘텐츠에 대한 보호∙판매∙운영을 위해서는 DRM 솔류션 제품이 포함된 서비스를 사용
  

  

• 서비스를 제공하는 업체에서는 보통 원본 콘텐츠의 불법 유통 막기 위해 콘텐츠 보호 처리를 우선함
• 창작한 원본 콘텐츠가 예를 들어 도서, 책, 음반, 영화 필름과 같이 아날로그 콘텐츠인 경우, 디지털 콘텐츠로 변환하는 작업을 하게 되고, 다음으로 디지털 콘텐츠를 DRM 처리하여 변환하는 작업을 함 → 작업 과정을 패키징(packaging) 한다고 하며 패키징 하는 도구는 패키저(packager)
• 패키징 과정에서 불법 복사를 차단하기 위해 암호화와 불법 유통 시 복제 경로를 감지하기 위해 소유자의 정보를 삽입하는 워터마크 같은 기술이 콘텐츠에 적용되며, 저작권자가 설정한 콘텐츠 사용 규칙(라이선스 정보)이 라이선스 서버에 포함함
• 콘텐츠 사용 규칙은 콘텐츠 구매자에게만 해당하는 것이 아니라 콘텐츠 온라인 유통방법에 따라 서비스 제공자에 대한 유통 규칙이 포함될 수 있음

패키징은 시점을 기준으로 보통 두 가지 방법으로 구분

1. 사용자가 콘텐츠를 요청한 시점에 진행하는 방법(on-the-fly packaging)
   • 콘텐츠 크기가 비교적 작은 경우 예를 들어 문서파일이나 음원 파일 같은 경우에는 실시간 패키징

2. 사전에 패키징을 해 놓는 방법(pre-packaging)
   • 동영상이나 게임 설치 프로그램과 같이 콘텐츠 크기가 큰 경우에는 사전에 패키징

DRM 절차

1. 보호된 콘텐츠를 구매한 고객이 사용하기 위해서는 단말 기기에 DRM 복호화 모듈이 존재해야함
2. DRM 복호화 모듈의 역할은 서버로부터 사용자 인증과 라이선스 정보를 발급받아 콘텐츠를 복호화하는 것
3. 사용자가 콘텐츠를 사용하려는 시점에 DRM 콘텐츠 모듈은 인증서버를 통해 사용자 인증을 하게 되고 라이선스 서버를 통해 콘텐츠 사용 권한(지불 여부 확인) 여부 등을 판단하여 권한이 있는 경우 라이선스 정보를 제공
4. 라이선스 정보에는 콘텐츠를 복호화 하기 위한 키와 콘텐츠 사용 권리 중 제약 조건이 일반적으로 포함
5. 제약 조건의 주요 항목으로 권리 유효 횟수나 권리 유효기간 정보가 존재하는데, 사용자가 콘텐츠를 사용할 수 있는 횟수나 사용 만료 일자 정보를 의미
6. 정보를 받아 DRM 클라이언트 모듈은 복호화를 하게 되며 사용자는 콘텐츠를 사용할 수 있게 됨
7. 해당 콘텐츠를 웹 브라우저 상에서 볼 수 있는 환경이라면 웹 브라우저에서 지원하는 플러그인 형태로 DRM 클라이언트 모듈이 내장된 뷰어가 온라인 업체에서 제공될 것이며 그것을 받아 DRM 콘텐츠를 사용

DRM 흐름

1. 사용자가 문서를 작성
2. 문서를 암호화
3. 문서를 다른 사용자에게 배포
4. 열람 시 DRM Server로 부터 인증
5. 인증이 되면 문서 열람

DRM의 장점

1. 각 문서 단위로 권한제어
2. 문서 생성자가 적절한 권한을 부여하여 문서가 삭제 될때 까지 유지
3. 문서는 암호화 되어 권한을 가진 사용자만 접근 가능
4. 외부 유출 시에도 문서가 암호화되여 보호됨
5. 모든 로그가 DRM 서버에 기록이 됨

DRM의 단점

1. 암호화 해제 권한자에 의한 도면 유출을 차단할 방법이 없음
2. 어플리케이션(프로그램)에 종속적
3. 어플리케이션(프로그램) 버전이 변경 될때마다 추가 작업이 필요