동영상 UCC 서비스의 주요 기술 및 적용 사례

최근 불어 오는 UCC 열풍이 아주 뜨겁습니다. 신문이건 뉴스건 어디서나 UCC라는 말이 안 나오는 날이 없을 정도지요. 현재 언론에서 이야기되는 UCC는 주로 동영상 UCC를 가리키고 있습니다. 텍스트, 음악과 같은 컨텐츠를 너무 배제하고 있다는 느낌이 들게 할 정도지요.
 
하지만 한편으로 그렇게 치우치는 것이 당연하다 느껴질 정도로 동영상 UCC는 매력적입니다. 그래서 이번 글에서는 동영상 UCC 제작에 사용되는 기술에 대해 간단히 알아 보고, 주요 업체들의 기술 사용 방식에 대해 살펴 보고자 합니다
 
동영상 UCC 서비스의 핵심 기술 : 트랜스코딩
트랜스코딩(Transcoding)이란 한 코덱에서 다른 코덱으로의 디지털 to 디지털 변환을 말합니다. 기본적으로는 raw 포맷으로의 decoding/decompressing을 수행한 후 타겟 포맷으로의 re-encoding으로 구성 됩니다.
 
트랜스코딩이 핵심 기술이 되는 이유는 동영상 UCC의 주요 용도 중 하나가 컨텐츠의 공유이기 때문입니다. 공유할 컨텐츠의 포맷이 스트리밍이 지원되지 않거나, 컨텐츠 크기가 너무 크거나 하면 컨텐츠의 공유는 꽤 어려운 일이 되어 버립니다.
 
이런 경우 트랜스코딩 과정을 통해 대부분의 사용자가 기본적으로 사용할 수 있는 포맷으로 변경하고, 스트리밍 서비스를 이용하여 쉽고 빠르게 컨텐츠를 즐기도록 할 수 있습니다.
 
모두 아시겠지만 현재 동영상 UCC 서비스의 양 축을 이루는 포맷은 FLV(Flash Video)와 WMV(Windows Media Video) 포맷입니다. 두 포맷 다 스트리밍을 지원하며, 대부분의 사용자가 사용할 수 있는 포맷이라는 장점을 가지고 있습니다. 물론 서로 상이한 점도 있지요.
 
동영상 UCC 포맷의 큰 축 : FLV와 WMV
FLV의 경우 거의 모든 사용자가 활용할 수 있는 포맷이라는 장점이 있습니다. Windows를 사용하건, Mac을 사용하건 간에 Flash가 지원 되는 플랫폼이라면 FLV의 재생이 가능합니다. Flash 플레이어가 거의 모든 플랫폼을 지원하기 때문에, 컨텐츠의 공유란 측면에서 매우 큰 장점을 가지고 있습니다. 또한 개성적이고 편리한 Flash UI를 추가할 수 있다는 것 역시 멋진 점이지요.
 
FLV 포맷을 채택한 서비스들은 이러한 장점을 최대한 살리기 위해 가능한 표준적인 웹 기술만을 사용하는데, 그 결과로 한가지 단점이 생겨납니다. 바로 트랜스코딩 작업이 모두 서버 사이드에서 진행된다는 것입니다.
 
트랜스코딩은 엄청나게 많은 시스템 자원을 요구하는 작업입니다. 예를 들어 1분짜리 동영상을 다른 포맷으로 변환한다면, 현 시점에서는 하드웨어 기반의 트랜스코더를 사용한다 하더라도 최소한 1분 정도의 시간은 필요합니다. 그런데 서버 사이드에서 모든 사용자의 동영상 파일을 변환하게 되니 그 부하는 엄청난 것이죠.
 
결국 동영상 업로드 후 상당한 시간을 기다려야 하는 결과를 가져 오게 되고, 이를 줄이기 위해서는 시스템 구축에 많은 비용을 지불해야 합니다.
 
반면 WMV 포맷은 컨텐츠 공유의 측면에서 상대적으로 제약이 있습니다. Windows 계열의 플랫폼에서는 문제가 없지만, 다른 플랫폼에서는 해당 컨텐츠를 브라우저를 통해 감상하기 어려운 점이 많다는 것이죠. 조금 단정적으로 표현하자면 Windows + IE 브라우저에 최적화 된 포맷이라고 봐도 되겠습니다.
 
하지만 이러한 단점을 감수하면, 얻을 수 있는 장점도 있습니다. ActiveX를 충분히 활용할 수 있다는 것이죠. ActiveX 때문에 최근 여러 이슈가 나오고 있는데 이게 뭔 소린가 하실 수도 있겠습니다. 하지만 ActiveX를 사용하게 되면 사용자의 PC에서 애플리케이션을 구동할 수 있기 때문에, 트랜스코딩 작업을 사용자의 PC에서 할 수 있게 됩니다. 서버는 트랜스코딩이 완료된 컨텐츠를 받기만 하면 되는 것이죠.
 
이 점은 서비스 운영자에게는 구축 비용 감소라는 큰 혜택을 줄 수 있습니다. 또한 사용자 입장에서도 상대적으로 적은 시간만 기다리면, 내가 업로드 한 컨텐츠를 공유할 수 있다는 장점을 줍니다. 물론 이미 말했듯이 이 혜택을 누릴 사용자가 플랫폼의 제약에 묶여 버린다는 단점이 있지만 말이죠.
 
이러한 장단점이 있기 때문에 동영상 UCC서비스 업체들은 나름대로 전략을 세워 기술을 채택하게 됩니다. 이제 주요 업체들의 적용 포맷을 살펴 보도록 하죠.
 
FLV를 채택한 YouTube와 Daum의 TV팟
YouTube와 Daum의 경우 FLV 포맷을 채택하고 있습니다. 그렇기 때문에 FireFox와 같은 브라우저에서도 전혀 문제 없이 서비스를 이용할 수 있습니다. 또한 Flash를 이용한 편리하고도 매력적인 UI를 추가할 수 있습니다. 
 

[ 그림 1 : 다음 TV팟의 인터페이스 : 시간대별 썸네일 표시 등의 부가적 인터페이스를 가집니다 ]
 
하지만 서버 사이드에서 트랜스코딩이 진행되기 때문에, 사용자는 동영상을 업로드 한 후에 실제 감상까지 상당한 시간을 기다려야 합니다. 이미 서버에는 수 많은 동영상이 줄 지어 자기 차례를 기다리고 있기 때문입니다.
 
Daum의 경우 Digital Rapids사StreamZ 솔루션이 납품된 것으로 알려져 있습니다만, 이 솔루션이 TV팟에 적용되었는지는 확인하지 못 했습니다.  (글에 혼선을 주고 Daum 출처의 정보가 아니기 때문에 삭제하였습니다)

하지만 어떠한 솔루션을 사용하였건 간에, 트랜스코딩을 위해 상당히 많은 비용을 투자하였을 것이라는 것은 명백합니다. 물론 YouTube의 경우 훨씬 더 많은 비용이 사용되었을 것이라 예상할 수 있습니다.
 
WMV를 채택한 네이버 플레이
네이버의 플레이 서비스는 WMV 포맷을 채택하고 있습니다. 그 결과 FireFox나 Opera 같은 브라우저로는 정상적인 활용이 불가능합니다.
 
하지만 동영상 업로드시에는 Daum의 서비스에 비해 훨씬 유리합니다. Windows 기반의 사용자 PC에서 인코딩을 수행하기 때문이죠. 동영상을 업로드 할 때 작업 관리자를 띄워 프로세스들을 살펴 보면 SelfMV.exe가 실행되면서 동영상을 인코딩하는 것을 알 수 있습니다.
 
최근에는 사용자 PC의 퍼포먼스가 서버 못지 않기 때문에, 상당히 빨리 컨텐츠를 공유할 수 있게 된다는 장점이 있습니다.
 
게다가 네이버 플레이의 경우, WMV 포맷 자체로는 UI를 추가할 수 없다는 점을 극복하기 위해 약간의 아이디어를 추가했습니다. 업로드 과정에서 썸네일을 추출해 낸 후, 해당 썸네일 위에 플래시 버튼을 얹은 것이죠.
 
그래서 얼핏 보기에는 Daum이나 YouTube와 유사한 느낌을 주고 있습니다. 그리고 사용자가 가운데의 재생 버튼을 클릭하는 순간, 화면은 wmv 플레이어로 변경되어 동영상을 재생하게 되는 것이죠.
 

[ 그림 2 : 네이버 플레이 스크린샷. 가운데의 재생 버튼만 플래시이고 배경 화면은 이미지 ]
 
어쩌면 네이버는 국내 서비스에서는 이 정도로 충분하다는 판단을 내리고, 소수 사용자들에 대해서는 포기한 것인지도 모르겠습니다. 그렇게 절약한 돈을 해외 진출에 사용할 수도 있겠지요.
 
마치며
이번 글에서는 트랜스코딩 기술과 포맷을 중심으로 주요 서비스들의 서비스를 비교해 보았습니다. 컨텐츠의 자유로운 공유를 위한 표준 지향이라는 과점에서는 Daum과 YouTube가 강점을 가지고 있고, 서비스 운영 비용 측면에서는 네이버가 조금 더 유리한 위치에 서 있다는 것을 알 수 있습니다.
 
현재로서는 FLV를 적용한 사이트가 점점 더 힘을 얻어 가는 추세이긴 합니다. 특히 해외의 경우 더욱 그렇습니다. 아마 국내에서도 FireFox나 Mac의 보급율이 높아진다면 FLV가 더욱 힘을 얻을 수 있을 것입니다.
스마트플레이스의 글을 편리하게 구독하세요. 한RSS 추가 구글추가
크리에이티브 커먼즈 라이센스
Creative Commons License이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

트랙백 (1) | 덧글 (11)
트랙백 주소: http://www.smartplace.kr/trackback_post_111.aspx
스마트플레이스의 트랙백은 스팸방지를 위해 관리자 승인 후 등록됩니다.
UCC 동영상 파일 포맷에 대한 단상
UCC 동영상 파일 포맷에 대한 단상   Daum은 On2 TrueMotion VP6기반의 flv를 사용하면서 업체에 솔루션을 구매했지만 Youtube는  H.263 기반의 이전버전 flv를 ffmpeg기반의 오픈소스를 사용해서 재작업했습니다. 따라서 해상도에 차이가납니다. 그리고 트랜스코딩이 1분짜리가 10분이상 걸릴 수도 있습니다...

덴디 2007-02-25 10:05:38     답글 삭제
뭔가 잘못생각하고 계시는군요 Daum은 On2 TrueMotion VP6기반의 flv를 사용하면서 업체에 솔루션을 구매했지만 Youtube는 H.263 기반의 이전버전 flv를 ffmpeg기반의 오픈소스를 사용해서 재작업했습니다.
따라서 해상도에 차이가납니다. 그리고 트랜스코딩이 1분짜리가 10분이상 걸릴 수도 있습니다. 네이버의 장점은 인질이 많다는 것 뿐이지 결국 화질이 떨어지는 영상을 보고싶어 하지는 않다라는 느낌입니다. 왜 ActiveX를 설치해서 내가 인코딩해서 보내야하는지 ^^ 단순히 빨리 올려서 결과물 보기위함 이라면 조급증좀 버렸으면 합니다. 그리고 네이버의 YouTube견제가 좀 심하더군요 Copy&Paste로 복사해서 컨텐츠 등록도 못하게 하고 있으니...
앤디 2007-02-25 20:59:28     삭제
안녕하세요. 답글이 늦었습니다.

제 글에서는 코덱의 스펙 레벨을 세세하게 이야기하기보다는 아래의 내용을 이야기하고 싶었습니다.

1. 플랫폼에 종속되지 않기 위한 포맷 선정
2. 그 결과로 나타나는 장/단점

물론 포맷 선정 자체가 서버사이드/클라이언트 사이드를 결정하지는 않습니다. 플랫폼에 종속되지 않으려 하다 보니 클라이언트 사이드의 잡을 배제하게 되고, 가장 많이 사용되는 포맷을 사용하게 되는 것이지요.

네이버는 네이버 입장에서 최선의 선택을 했을 것이라고 생각합니다. 사용 가능한 브라우저가 제약되고, 일부 사용자느 사용하지 못 하겠지만 그 것을 감수할 만한 이유를 발견한 것이었겠지요.

말씀하신 것과 같은 폐쇄성은 저 역시 불만이지만요. 좋은 정보 감사 드립니다. ^^

PS) StreamZ 솔루션에 관한 부분은 최근 제가 진행중인 프로젝트를 위해 자료를 조사하던 중, StreamZ + On2 옵션으로 다음에 납품된 것을 알게 되어 기술한 부분인데, 오히려 글의 논지만 흐려 놓은 것 같습니다. 다음 측이 아닌 총판 측으로부터 얻은 정보이니, 확실성을 위해 삭제하도록 하겠습니다.

U.Seung 2007-02-25 10:29:30     답글 삭제
지금 당장은 WMV 포맷이 WMP를 필요로 하여서 Windows Platform에서만 돌아갑니다만 Micrsoft가 이에 대항해서 WPF/E를 내놓았지요. 현재는 CTP만 공개가 되었고, 올해 상반기 내로 Linux/MAC/Windows에서 돌아가는 WPE/E Player를 출시할 예정이며 올해 하반기내로 모바일 플랫폼용 Player도 출시할 계획이라고 합니다. 네이버 입장에서는 Play서비스의 Viewer단을 WPF/E로 교체하기만 하면 Opera, Firefox를 무리없이 지원할 수 있게 된다는 것이지요. 이런 면에서 Encoding을 Windows Media Encoder에서 쉽게 Encodrding을 할 수 있는W WMV가 추가적인 비용을 지불해야하는 FLV(VP6)보다 더 유리한 위치에 있다고 볼 수 있을 것 같습니다.
앤디 2007-02-25 21:23:01     삭제
WPF/E는 분명히 기대주입니다. 개발자의 시각을 제대로 알고 있는 MS이기 때문에, 디자이너의 시각에서 출발한 Flash와 재미 있는 경쟁을 하게 될 것이라 생각하고 있습니다.

현재 WPF/E는 말씀하신 대로 Windows Media 9의 재생을 지원하고 있습니다. 그리고 계획대로 진행된다면 일차적으로 Windows 기반의 타 브라우저 사용자들을 지원할 수 있을 것이고, 그 후 Non-Windows 플랫폼을 지원할 수 있을 겁니다.

하지만 이것은 아직까지는 "목표" 또는 "예정"일 뿐이고, 현실은 아니기 때문에 실제 뚜껑이 열리는 시점을 지켜 봐야 할 것이라 생각합니다.

제 개인적으로는 제대로 개발되어 Adobe와의 경쟁이 심화되길 기대하고 있기는 합니다. 미디어 플레이 이외의 많은 부분에서 말이지요. ^^

okumi 2007-02-25 11:01:19     답글 삭제
U.Seoung님.. 그러면 Firefox 유저는 WPF/e로 보기만 하고 동영상 올리기 없어도 된다는 말씀?

U.Seung 2007-02-25 14:59:18     답글 삭제
okumi //
무슨 말씀이신지 잘 이해가 안가지만 Viewer단과 Uploader단을 혼재해서 생각할 필요는 없습니다. Firefox 유저에게는 거기에 맞는 Uploader을 만들어주면 됩니다.이걸 WPF/E를 사용하던 Flash를 사용하던 Ajax를 사용하던 이것은 다른 문제이며 만들기 나름입니다.

Huck 2007-02-25 17:29:32     답글 삭제
on2 vp6도 클라이언트 사이드 인코딩 가능합니다.
단지 Daum에서 서버사이드로 선택했을 뿐이지요..

가까이에서 볼 수 있는 예로
Cyworld 동영상 업로더가 on2 vp6코덱 클라이언트 사이드 인코딩으로 만들어져 있습니다.

flv냐 wmv냐는 비용이나 서버사이드/클라이언트사이드 인코딩의 문제로 보기는 힘듭니다.
앤디 2007-02-25 21:56:30     삭제
말씀이 맞습니다. 포맷과 트랜스코딩 위치와는 사실 나누어 생각해야 하는 부분입니다.

그런데 대부분 서비스 운영자들이 FLV를 채택하는 이유중 가장 큰 것은 플랫폼이나 브라우저에 대한 종속 없이 모든 사용자를 지원할 수 있다는 점일 겁니다.

그 장점을 제대로 살리기 위해 서버 사이드 인코딩을 선택하는 것이죠. 그 장점이 필요 없다면 당연히 클라이언트 사이드 인코딩을 사횽해도 문제 될 것이 없습니다.

제 글이 FLV = 서버사이드 인코딩, WMV = 클라이언트 사이드 인코딩 으로 나누는 것으로 읽혀 졌다면 제 불찰입니다.

부족한 필력에 이런 저런 생각을 한 꺼번에 밀어 넣으니 혼란을 가져 오게 되었군요.
(참고로 제가 지금 진행중인 프로젝트에서는 On2 VP6기반의 FLV와 WMV9를 모두 지원하고, 모두 서버 사이드에서 트랜스코딩을 합니다.)

좋은 피드백 감사합니다.

PS ) 싸이월드하고는 워낙 친하지 않아 내용을 잘 몰랐는데, 덕분에 한번 살펴 보게 되었습니다. 감사합니다. ^^;;

미디어몹 2007-02-26 09:04:54     답글 삭제
스마트플레이스 회원님의 상기 포스트가 미디어몹에 링크가 되었습니다.

deal 2007-02-26 09:30:24     답글 삭제
WFP/E도 결국 닷넷 프레임워크 아닌가요...닷넷 3.0에 포함(?) 되는것 같던데......그럼 멀티 플래폼은 불가능할 가능성도 크겠군요...
그냥 2007-02-26 11:34:55     삭제
WPF/E는 MS가 cross-platform을 대상으로 만들었기 때문에, 현재 Windows, Mac를 지원합니다. 다만, 어디까지가 지원될지가...(WPF가 닷넷3.0에 포함되고 현재 Window에서만 돌아갑니다. WPF/E가 WPF기술을 사용합니다)
http://msdn2.microsoft.com/en-us/asp.net/bb187401.aspx#config

이름 비밀번호
홈페이지
덧글
비밀글
RSS 피드
전체글한RSS 추가 구글추가
스마트가젯북스타일
Demo Day