멍그

[node.js] 서버접속해보자.

멍그 — Sat, 07 Jan 2012 03:26:06 +0900

우선 파일 만들고

root@easiers:/project/nodejs/public_html# vi server.js

var http = require("http");

http.createServer( function( request , response ) {

response.writeHead( 200 , {"Content-Type": "Text/plain"} );

response.write("Hello World");

response.end();

}).listen(8888);

서버이므로 뒷단으로 실행 시켜보자.( 그냥 ^^; )

root@easiers:/project/nodejs/public_html# node server.js &

[2] 8990

서비스 실행 되었는지 프로세스 확인

root@easiers:/project/nodejs/public_html# ps -ef | grep node

root 8990 31975 3 03:09 pts/4 00:00:00 node server.js

root 8993 31975 0 03:09 pts/4 00:00:00 grep --color=auto node

포트도 확인해 보자.

root@easiers:/project/nodejs/public_html# netstat -nap | grep LISTEN

tcp 0 0 127.0.0.1:6011 0.0.0.0:* LISTEN 29959/3

tcp 0 0 127.0.0.1:6012 0.0.0.0:* LISTEN 31211/4

tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 3897/dovecot

tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN 3897/dovecot

tcp 0 0 1.234.23.199:3306 0.0.0.0:* LISTEN 25179/mysqld

tcp 0 0 127.0.0.1:587 0.0.0.0:* LISTEN 2530/sendmail: MTA:

tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 3897/dovecot

tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 3897/dovecot

tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 13566/apache2

tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 8913/vsftpd

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 22587/sshd

tcp 0 0 0.0.0.0:8888 0.0.0.0: LISTEN 8990/node

tcp 0 0 1.234.23.199:3000 0.0.0.0:* LISTEN 3318/ruby

tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 2530/sendmail: MTA:

tcp6 0 0 ::1:6011 :::* LISTEN 29959/3

tcp6 0 0 ::1:6012 :::* LISTEN 31211/4

tcp6 0 0 :::22 :::* LISTEN 22587/sshd

tcp6 0 0 :::9911 :::* LISTEN 19706/java

tcp6 0 0 :::9912 :::* LISTEN 19706/java

unix 2 [ ACC ] STREAM LISTENING 825629 25179/mysqld /var/run/mysqld/mysqld.sock

unix 2 [ ACC ] STREAM LISTENING 2479 1/init @/com/ubuntu/upstart

unix 2 [ ACC ] STREAM LISTENING 6724 2272/python /var/run/fail2ban/fail2ban.sock

unix 2 [ ACC ] STREAM LISTENING 6540803 4669/PassengerHelpe /tmp/passenger.1.0.30570/generation-3/socket

unix 2 [ ACC ] STREAM LISTENING 6540807 4671/Passenger spaw /tmp/passenger.1.0.30570/generation-3/spawn-server/socket.4669.21417632

unix 2 [ ACC ] STREAM LISTENING 6540833 4676/PassengerLoggi /tmp/passenger.1.0.30570/generation-3/logging.socket

unix 2 [ ACC ] STREAM LISTENING 7919059 6632/dbus-daemon /var/run/dbus/system_bus_socket

unix 2 [ ACC ] STREAM LISTENING 7894237 2530/sendmail: MTA: /var/run/sendmail/mta/smcontrol

unix 2 [ ACC ] STREAM LISTENING 5599213 3897/dovecot /var/run/dovecot/dict-server

unix 2 [ ACC ] STREAM LISTENING 5599215 3897/dovecot /var/run/dovecot/login/default

unix 2 [ ACC ] STREAM LISTENING 5599220 3897/dovecot /var/run/dovecot/auth-worker.3900

root@easiers:/project/nodejs/public_html#

다시한번 실행해 보자.

root@easiers:/project/nodejs/public_html# node server.js

node.js:201

throw e; // process.nextTick error, or 'error' event on first tick

Error: listen EADDRINUSE

at errnoException (net.js:632:11)

at Array.0 (net.js:733:26)

at EventEmitter._tickCallback (node.js:192:40)

root@easiers:/project/nodejs/public_html#

이 테스트는 싱글 쓰레드라는 node.js의 특성을 보기 위함. ( http://www.google.co.kr/search?source=ig&hl=ko&rlz=&q=node.js+single+thread&btnG=Google+%EA%B2%80%EC%83%89
)

자 이제 브라우져로 해당 서버 접속해 보자. 8888 포트로
http://1.234.23.199:8888/
그대가 접속할때에 떠있을지는 모르겠수다...

node.js - hello world

멍그 — Sat, 07 Jan 2012 02:47:41 +0900

ubuntu 10.4 환경.

-- nodejs project user create

root@easiers:/# mkdir /project

root@easiers:/# adduser --home /project/nodejs nodejs

-- source donwload ( main site : http://nodejs.org/ )

root@easiers:/project/nodejs# wget http://nodejs.org/dist/v0.6.6/node-v0.6.6.tar.gz

root@easiers:/project/nodejs# cp ./node-v0.6.6.tar.gz /usr/local/src

-- configure & compile

root@easiers:/project/nodejs# tar xpvfz node-v0.6.6.tar.gz

root@easiers:/project/nodejs# cd node-v0.6.6

root@easiers:/project/nodejs# ./configure ; make ; make install

----- now is mealtime becouse long~~ compile time

-- Set the location of the application

root@easiers:/project/nodejs# mv node-v0.6.6 /usr/local/nodejs

root@easiers:/project/nodejs# PATH=$PATH:/usr/local/nodejs

root@easiers:/project/nodejs# export PATH

................... [setting complete]

-- hello world

root@easiers:/project/nodejs# cd /project/nodejs/

root@easiers:/project/nodejs# vi /project/nodejs/helloworld.js =================================

console.log("Hello World");

root@easiers:/project/nodejs# node /project/nodejs/public_html/helloworld.js

Hello World

................... [OK]

-- Testing for dependence

root@easiers:/project/nodejs# cp -pR /usr/local/nodejs /nodejs

root@easiers:/project/nodejs# mv /usr/local/nodejs /usr/local/nodejs.bak

root@easiers:/project/nodejs# /nodejs/node /project/nodejs/public_html/helloworld.js

Hello World

root@easiers:/project/nodejs# rm -rf /nodejs

root@easiers:/project/nodejs# mv /usr/local/nodejs.bak /usr/local/nodejs

................... [OK]

NGINX 와 FLASH 를 바라보며.. 싱글 쓰레드와 멀티 쓰레드의 일장일단.

멍그 — Thu, 24 Nov 2011 10:50:19 +0900

node.js nginx 이야기를 주워 들어 좀 검색좀 해봤다.

http://h3.paran.com/2011/talk.html

node.js 가 도대체 뭐시길래 한쪽은 뻗고 , 한쪽은 CPU 점유율이 20%로 버텨 낸단 말인가.

http://blog.doortts.com/219

위 글 보면 싱글 쓰레드라 이러이러하다 머가 좋다... 칸다.

nginx 가 apache 와는 달리 싱글 쓰레드라서 멀티 쓰레드가 가져가는 자원 리소스를 동접자에 대비해 훌륭한 퍼포먼스를 보여준다.

그럼 nginx 가 진리 일까?

플래쉬는 차기 버전에서 멀티 쓰레드를 제공한다고 들었다.

플래쉬 같은 경우 jpg 엔코딩을 뜨거나 자원 리소스를 마구 잡아 먹는 일들을 하게 될때, 플래쉬가 랜더링을 못한다.

싱글 쓰레드의 한계로 , 특정 로직에서 자원을 극한으로 잡아 먹고 한참동안 리소스를 쥐고 있으면 기본적으로 진행이 되어야 할 일들을 하지 못해 이상현상을 가져올수 있다.

이런 한계에 대한 노티로 플래쉬는 싱글 쓰레드에서 멀티 쓰레드를 지원하게 된다.

반대로 , nginx 는 apache 의 멀티 쓰레드의 한계를 노티로 싱글 쓰레드 컨셉의 설계로 apache 자리를 비집고 들어 오고 있다.

파란의 컨퍼런스 같은 경우의 케이스엔 nginx 가 제격인 셈이다.

허나 꼭 이게 진리일까... 글세...

'DBMS 냐 NO-SQL 이냐 라는 질문은 망치냐 드라이버냐 라고 하는 것과 같은 어리적은 질문이다.'

이런것을 우문현답 이라고 하나보다.

이런 여자를 만나고 싶다.

멍그 — Mon, 14 Nov 2011 10:49:43 +0900

사랑의 경험에 상처를 주기도, 상처를 받아 보기도 했으면 좋겠습니다.

감정의 무뎌짐을 힘듦으로 헤어짐을 주어보기도, 헤어짐을 당해보기도 해서 상처의 경험이 있었으면 좋겠습니다.

더욱 성숙한 감정의 다룸을 가질수 있을것 같기 때문입니다.

헤어짐을 당해보아서 그 아픔을 알고 많은 생각을 해보면 좋기 때문입니다.

헤어짐을 주어 보기도 하여 사랑의 어려움과 인간의 속성을 잘 알게 되기 때문입니다.

아킬레스건 같은 무언가 부족한 한가지가 있었으면 좋겠습니다.

평범한 이에게 없는 가정사의 비범함 , 또는 육신의 제약 , 또 다른 성품의 약함 을 가지고 있고,

그 부분을 충분지 제가 채워줄수 있는 사람이었으면 좋겠습니다.

그것이 더욱 서로가 절실해 질수 있는 감사함이 될수 있기 때문입니다.

더욱 애틋해 지는 도구가 되며, 나에게 있어서는 쓰임 받는다는 마음이 있기 때문입니다.

반대로도 그랬으면 좋겠습니다.

저의 부족함을 채울수 있는 사람이었으면 좋겠습니다.

그래서 서로가 서로에게 꼭 필요한 사람이었으면 좋겠습니다.

나의 부족함을 보고 바뀌길 바라기 보단,

나의 좋은 부분을 보고 배우고 학습하는 사람이었으면 좋겠습니다.

나와 관계하면서 이런 성품을 신기해 하며 좋은 부분을 누리는 사람이었으면 좋겠습니다.

누구나 일장일단의 성품을 가지고 있습니다.

어려운 부분을 계속 바라보게 되면 마음도 어려워 지기 때문입니다.

딱히 다른 단어가 생각이 나지 않아 체념이라는 말로 채워봅니다.

지혜로운 체념은 관계를 건강하게 합니다.

자존심이 강하지 않았으면 좋겠습니다.

자존심이라는 것에 사랑을 놓치는 경우를 많이 보기 때문입니다.

상이한 대립의 상황이 오더라도 충분히 상대방의 입장을 이해하고 공감할수 있게 되기 때문입니다.

혹, 실수를 하더라도 용서를 구할 수 있는 용기가 생기기 때문입니다.

자존심이 강하게 되면, 스스로의 자격지심에 쌓이기 쉽기 때문입니다.

자기 자신을 객관적으로 볼수 있는 사람이었으면 좋겠습니다.

주관적인 사고에 집중하게 되면 남들이 스스로를 바라보는 눈에 멀어지기 때문입니다.

나의 지인이 이런 상황을 어떻게 보게 될까. 위에서 바라보면 어떤 마음일까.

하는 것들을 볼수 있다면 어떻게 행동하고 어떻게 처신해야 하는지가 명확해 지기 때문입니다.

그리고 마지막으로... 어리고 예뻤으면 좋겠습니다.

W3C 의 힘이 어느 사기업보다 막강해 지는 시기가 올것 같다.

멍그 — Fri, 11 Nov 2011 11:43:47 +0900

http://blog.creation.net/513
http://www.thisisgame.com/board/view.php?id=682186&category=102&xkdlq=oc
http://clien.m.oolzo.com/View.aspx?site=141&page=0&wr_id=1154651&sfl=wr_subject%7C%7Cwr_content

사기업들은 자체 플랫폼 제국을 꿈꾸고 있지만 서로의 견제로 인해 시장은 n등분되고,
결국 html5 라는 대안을 찾아 서로 쉐어 해 가게 되며
결국엔 w3c 가 어부지리로 막강한 시장의 악덕이 되게 되는데....

- 명규 생각 -

Simplex Internet 에 입사하다.

멍그 — Thu, 06 Oct 2011 11:32:45 +0900

회사를 옮겼다.
이제 한달이 지나가고...

이전 회사에 비해 사뭇 다른 분위기에 적응중이다.

지난 내 발길을 돌아보면 , 쭉 자라오는 모습을 본다.

내 인생은 현재 진행중이다.

안녕. 내 과거야. 너도 니 갈길을 가는구나...

findphar.com 도메인을 등록했습니다.

멍그 — Wed, 14 Sep 2011 12:35:35 +0900

findjar.com 사이트를 찾는 java 개발자처럼
findphar.com 사이트를 찾는 phper 들이 범용적이게 될려면...
2년이면 될까요..??

혹시나 해서 도메인 검색해 보았더니 findphar.com 도메인이 아직 미등록 도메인 이네요.
일단 등록. 흠.. 이제 어떻게 구현을 할까. 방치를 할까가 고민이네요. ㅎㅎ

Unexpected termination of script, debugging ended.

멍그 — Tue, 06 Sep 2011 14:33:14 +0900

PDT 를 사용하다가 디버깅중에 위 문구를 만나게 되면,

아마도 Variable variables ( 가변변수 ) 를 사용하고 있어서가 아닐까 싶다.

그게 아니라면 아직 메모리상에 상주하지 않은 값을 Expressions 에서 사용하고 있어서 이다.

class foo {
    var $bar = 'I am bar.';
}

$foo = new foo();
$bar = 'bar';
$baz = array('foo', 'bar', 'baz', 'quux');
echo $foo->$bar . "\n";
echo $foo->$baz[1] . "\n";

이 소스를 디버깅 돌려보면 잘 돌아 간다.

허나 Expressions 에 $foo->$bar 를 찍어 보면 위와 같은 에러문구를 만나게 된다.

즉 $bar 가 존재 하지 않은 중에 $foo->$bar 를 참조하기 때문인듯.

정부 주도 OS 개발 발표에 대한 개발자의 생각.

멍그 — Wed, 24 Aug 2011 11:12:15 +0900

부제 . 소프트웨어는 여자 다루듯이 해야 한다.

부제가 좀 거슬릴수 있겠다.

하지만 너무나 적합한 멘트 이기에 무리해서 사용했다.

최근 구글의 모토로라 인수에 따른, 소프트웨어 업체 구글이 하드웨어 업체를 인수하면서 소프트웨어와 하드웨어의 기술력을 동시에 보유하여 최적화된 상품을 만들어 낼수 있는 기반을 조성하였다.

이에 기존의 구글의 소프트웨어 기술력에 기생하여 훌륭한 하드웨어 기술력으로 시장에서 좋은 성과를 가져 왔던 삼성에 발등에 불이 떨어졌다.

이에 질세라 삼성은 소프트웨어에 관심을 가지기 시작했고 자체 OS 인 바다나 그외 기술자에 대해 관심을 가지기 시작했고 , 정부에서도 마찬가지인 행보를 보이고 있다.

어떻게 해야 할지의 방향성은 잘 잡았으나, 어떻게 해야 하는지의 방법에 대해선 너무 모른다는 생각을 해본다.

여자를 만나야할 필요성은 있지만, 어떻게 여자의 마음에 들수 있도록 해야 하는지를 모르는 젬병처럼...

소프트웨어라는 것은 마치 여자이듯이 소중히(?) 대면해야 한다.

하드웨어와는 달리....

하드웨어는 기계이다.

기계의 최상의 퍼포먼스를 가져오기 위해 성능을 업그래이드 하기 위해 최적화라는 방법이 먹히는 곳이다.

아니 그러듯 하다. 잘 몰라서 겉으로 보기엔...

허나 소프트웨어라는 것은 이와 다르다.

소프트웨어라는 것은 굉장히 추상적인 것이며, 어떻게 대하느냐에 따라 결과물이 천차 만별이다.

그래서 하드웨어동네에는 없는 오픈 이라는 개념이 있고 오픈을 해야 발전을 한다는 기대라는 것이 있는 것이다.

기존에 잘 사용되어지는 소프트웨어들을 보면 크게 두가지가 있다.

첫째로, 주최자가 이 기술이 시장에 먹힐것 같다는 생각에 내가 개발하여 시장에 내어 놓아서 판다.

좋은 기술이고 유용한 기술이기에 많은 사람들에게 알려지고 해당 기술을 배포하는 사람은 수익을 창출하게 된다.

사람들에게 알리기 위해 무료로 우선적으로도 배포하는 형태를 가지기도 한다.

( 이에 오픈이라는 타이틀을 붙이기도 하는데 이건 오픈이 아니라 무료 인것이다. )

대표적인 것이 무료로는 우리가 유용하게 사용하는 알집,곰플레이어,네이버의 많은 서비스들....

유료로는 윈도우OS,MS-OFFICE 등등이 있겠다.

많은 사람들이 알고 있고 사용하고 있으니 성공한 소프트웨어라고 할수 있겠다.

둘째로는, 이런 기술이 추후에 시장에서 필요로 할수 있을것이고 많들면 많이들 유용하게 사용하겠다라고 생각되는 기술을 개발하기 시작하면서 동지자들을 모집한다.

같이 개발하는 것이니 소스는 서로 공유하며, 많은 사람들이 개발에 참여 할수 있도록 오픈하여 함께 참여하여 좋은 소프트웨어를 만들어 보자고 시작한다.

날고 기는 많은 개발자들이 진행하는 프로젝트 리더와 만들고자 하는 산출물의 시장 needs 를 보고 관심을 가지기 시작하고 함께 동참한다.

많은 디버깅과 테스트 , 그리고 해당 프로젝트의 애착심이 버무려져서 소프트웨어 프로젝트는 발전을 한다.

해당 프로젝트의 공헌도에 따라 해당 개발자는 명성을 얻을수 있게 되며 순수한 소프트웨어 개발의 장인정신으로 애착을 가지며 프로젝트를 진행하게 된다.

이것이 진행될수 있는 기본적인 베이스는 개발자는 생계의 걱정을 하지 않을수 있는 기반이 조성이 기본이 되어 있을테고 , 이는 사회에서 이미 보장되어 있는 부분이다. 다시 말해서 우리나라처럼 열악하지않은 환경에서 개발하며 훌륭한 기술자는 좋은 대우를 돈은 어떻게는 굴러 들어와 있다.

소프트웨어는 안정성을 바탕으로 무럭무럭 발전한다.

조금이라도 프로젝트 멤버들이 프로젝트를 신경을 안쓰면 , 진행이 되지 않으며 발전은 스스로 되지 않는다.

많은 수고가 들어가야 한다. 위에서 까라고 그냥 딱 만들어 질 물건이 아니라는 것이다.

대표적인 사례가 안드로이드 이다.

기존의 오픈 프로젝트로 모바일 플랫폼 프로젝트 였으며, 여기에 구글이 사들이며 몇년의 준비기간을 거쳐 그나마 시장에 내어 놓을수 있는 OS가 탄생한것이다.

우리나라가 자체 OS의 필요성을 가진것에 대한 방향성은 긍정적이라고 생각한다.

하지만 발젼시키기 위한 접근성은 정말 답답하기 그지없다.

많은 개발자들이 순수하고 해당 물건에 대한 공헌도에 따라 각 개발자들에게 권한이 할당되지 않는이상 위에서부터 내려온 명령하달적인 프로젝트 구성엔 소프트웨어는 산으로 갈수 박에 없다. 하라는 것만 하게 되며, 겉으로 되는것같이만 보이게 될 뿐이며, 결국엔 또 몇백억짜리 쓰레기가 되는 것이다.

참 안타깝다.

여자친구가 된 여자에게 이미 여자친구이니 돈을 들이부으면 되겠지 싶어하면 안된다.

애착을 가지고 관심을 가지고 사랑을 하고 서로 교감을 해야한다. 그래야 좋은 여자친구를 유지(?) 할수 있으며 좋은 여자친구를 만날수가 있을 것이다.

소프트웨어도 마찬가지다.

관심을 가지고 애착을 가지고, 그런 애착들이 있는 사람들이 모여서 주도적으로 만들어야 좋은 소프트웨어를 만날 수 있다.

여자친구를 부하 다루듯이 하면 떠나기 마련이다.

소프트웨어를 만드는 기술자를 부하 다루듯이 하면 원하던 소프트웨어는 없고, 단지 쓰레기만 생길 뿐이다.

소프트웨어는 생태계라는 말을 사용한다. 하드웨어 생태계라는것은 못들어 본듯 하다.

조금 답답하다. 세금 몇백억이 또 많은 SI와 쓰레기 코드를 짜게 만드는 환경에서 불보듯 뻔히 또 그런 소스를 짜고 있을... ( 그러고 싶지않지만. ) 곳으로 세어 나갈 것을 보게 될테니...

아래는 공감되는 퍼온글이다.

540억 투자...

일단 컨소시엄 들어온 삼성전자,LG전자,팬택 불러다 놓고 가 모듈별 담당자 지정...

커널,프레임웍(SDK),툴,관리시스템 등등

lg전자 삼성전자 내부인력 구할수 없기에 SDS,cns에 발주..SDS는 외주인력 수배 각종 개발 커뮤니티에 올라옴

ex) 정부 OS 프로젝트 구인 C,C++,Java XXX역 근무 중급,초급

프로젝트 팀 구조

총괄 PM : 정부기관 산하 전산관련 업체 간부..

총괄PMO : 지경부 4급 공무원

모듈 PM : 삼성전자 차부장급..

모듈PL:삼성SDS 차부장

서브모듈 PL : 삼성SDS 정규직 직원

개발자 : 외주

아키텍쳐 : 교수님은 이름걸고 대학원생 대거 파견....실제 기업들이 좌지 우지 함으로 완전 꿔다놓은 보릿자루

프로젝트 진행

3년 프로젝트면 한 1년 기획하고 6개월 개발하다가 뒤집어 엎음.....외주개발자 다 도망감....

그리고 또 1년 기획하고 6개월 남음..통합 테스트까진 2개월 남음

기존 MM 대비 3배 개발자 투입........

2개월 동안 기획이고 모고 없고 오픈소스다 덕지덕지 붙임

종료.... 일단 결과물은 아주 쓰레기로 나옴

종료후

앱이 없으므로 앱프로젝트 발주... 또 각종 SI업체 들어와서 집단으로 개발 시작 ...

삼성전자LG전자 생색내기로 폰 1~2개씩 출시 통신사들 지들 멋대로 단말기 제조사에 지시 이거고쳐라

저거고쳐라..결국 서비스 시작되고

지경부 공무원 승진 산하 전산공기업 인센티브 팍팍

SDS,CNS 과다 MM투입으로 적자...직원들 징계...외주개발자 피토함...

뻔한 시나리오;;

Ogg Theora, H.264 and the HTML 5 Browser Squabble

멍그 — Wed, 03 Aug 2011 13:49:01 +0900

By Prince McLean
Published: 08:00 PM EST

전문가들은 HTML 5용 공식 비디오 코덱 채택을 위해, 무료인 Ogg Theora 코덱을 세우려는 모질라와 오페라가 애플에게 싸움을 걸었다고 평한다. 그러나 문제가 있다. HTML은 콘텐트용 코덱을 세우라고 만들어지지 않았다. 설사 거의 10년 전, 상업적으로 포기된 코덱인 Ogg Theora를 채택한다 하더라도, Ogg Theora는 점차 늘어나고 있는 모바일 웹용 비디오를 전달할 능력이 없다.

기술 언론들은 HTML 5를 가로막는 거대한 장벽, 혹은 자유 소프트웨어 투쟁가들과 대기업들간의 전쟁같은 불화를 기사화시키기 좋아한다. 그러나 HTML 5와 같은 사양의 현실은 정치적인 관점이 아니라 기술적인 상호작용성에 있다. 새로운 HTML 5 사양에 있는 비디오 포맷에 대한 이슈를 보자. 원래 HTML 사양은 웹 개발자들이 그래픽을 페이지에 넣는 것처럼 간단한 임베딩 비디오 시스템을 정의내린 적이 없었다.

웹브라우저는 GIF에서 JPEG, PNG에 이르는 그래픽 포맷을 인식하고 표시하기 위해 "img"라는 태그를 사용한다. 그러나 HTML 내에 비디오나 오디오를 임베딩하기 위해 똑같은 역할을 하는 태그는 없었다. 대신 웹 개발자들은 비디오를 나름 임베디드 파일로 포스팅하였고, 이를 정확히 표시할줄 모르는 브라우저가 있을 수 있었다.

웹상에서 오디오와 비디오 재생에 이런 문제가 있었던 이유는, 퀵타임, 그리고 ISO MPEG 비디오표준 개발의 역사와 궤를 같이 한다. 모질라와 오페라, 오픈소스 지지자들 일부가 덤비고 있는 산업과 동일한 산업이다. 물론 마이크로소프트도 한 몫 하고 있다.

The QuickTime Plugin

모든 브라우저에서 동일하게 잘 작용되는 비디오 표시방법은 쉽지 않다. 서로 경쟁중인 멀티미디어 재생 플러그인이 특정 컨테이너 파일(미디어 데이터를 담는 형식)과 코덱(오디오와 비디오 데이터 압축방식)만을 지원할 때가 많아서다. 초창기 웹 개발자들은 MJPEG (Motion JPEG)을 사용했다. MJPEG는 JPEG 스틸로 화면을 재생하고, 기본적인 WAV 파일로 오디오를 재생시키는 간단한 비디오 포맷이다. 사실 모든 브라우저에서 다 돌아가는 유일한 포맷이 MJPEG이다. 그러나 다운로드 크기나 화질로 볼 때 MJPEG은 그리 효율적이지 못하다.

애플의 퀵타임은 MJPEG를 포함, 여러가지 코덱 안에서 비디오를 재생하기 위한 시스템으로서 웹보다 앞서 나왔다. 따라서 써드파티에서 나오는 새로운 코덱도 지원 가능했다. 90년대 웹이 유명해지자, 애플은 넷스케이프와 그 외 브라우저용 퀵타임 포맷을 제공하였다. 브라우저 내에서 오디오와 비디오를 직접 재생시킬 수 있게 하기 위해서였다. 덕분에 퀵타임은 웹 비디오에 진출하게 되었고, 특히 웹 사용자와 웹 개발자들의 맥 사용비율은 당시 맥 사용비율과는 사못 달랐다.

개방성 웹, 그리고 윈도 독점에 웹이 지닌 잠재성에 주목하게 된 마이크로소프트는 넷스케이프를 죽음으로 몰아넣는다. 마이크로소프트는 퀵타임도 죽이려 하였다. 당시 마이크로소프트는 NCSA의 SpyGlass 브라우저 코드(넷스케이프도 이 코드를 기반으로 만들어졌다)를 라이센스받아 인터넷 익스플로러를 만든다. 그리고 이를 윈도에 무료로 번들시켜서 넷스케이프 브라우저 시장을 파괴시킨다.

Microsoft's War on QuickTime

그러나 퀵타임 베끼기와 죽이기는 더 어려웠다. 이미 마이크로소프트는 90년대 초, Video for Windows를 선보였으나 퀵타임의 질에 미치치 못하였다. 그리고는 샌프란시스코 Canyon 스캔들때문에 퀵타임 코드를 의도적으로 훔쳤다는 법정공방에까지 빠지게 되었다. 맥과 윈도 시스템의 표준 비디오 재생용 퀵타임을 죽이는데 실패한 마이크로소프트는 90년대 후반, 인터넷 익스플로러가 설치된 퀵타임 플러그인을 무시하도록 하였다.

넷스케이프를 파괴시킨 혐의에 집중된 마이크로소프트 독점 재판 때, 애플 중역진들은 넷스케이프가 퀵타임 플러그인과 잘 작동되었다 증언했다. 그러나 인터넷 익스플로러의 후대 버전들은 점차 퀵타임으로 비디오를 적절히 보내지 않았으며, 이 때문에 소비자들은 퀵타임이 잘 안돌아간다 여길 수 있었다. 재판 때 애플은 22개의 미디어 파일의 차트를 보여주면서, 윈도 95의 넷스케이프 4에서 22개 미디어 모두가 퀵타임으로 잘 돌아갔지만, 인터넷 익스플로러 3에서는 15개만이, 익스플로러 4에서는 11개만이 퀵타임으로 잘돌아갔다. 이것이 윈도 98 상에서는 4개에 불과했다. 마이크로소프트 변호사들은 마이크로소프트가 악의를 갖고 퀵타임 호환성을 일부러 깨뜨렸다는 주장은 아무도 입증할 수 없노라 주장할 뿐이었다.

그러니 바로 그 때, 마이크로소프트 중역들은 애플이 퀵타임을 포기하고 마이크로소프트와의 경쟁을 없애지 않는 한, 애플의 비디오 오쏘링 사업을 파괴시켜 버리리라 위협하고 있었다. 그러나 이런 위협에 굴복한 다른 기업들과는 달리 애플은, 마이크로소프트의 그 유명한 "knife the baby" 요구를 거절하고, 직접적인 경쟁에 나섰다.

마이크로소프트에 대한 격렬한 경쟁이 퀵타임 3이라는 결과물을 냈으며, 마이크로소프트가 발표한 다양한 기술들은 모두 실패하였다. 마이크로소프트는 크로스-플랫폼 Active Movie를 약속했으나 전혀 발표하지 못하였고, 새로운 윈도 미디어 컨테이너 파일 또한 별 반응을 이끌어내지 못하였다. 1998년 ISO는 MPEG-4 멀티미디어 표준으로서 퀵타임 컨테이너를 채택하였다.

Microsoft pushes Flash against Adobe

비디오에서 애플의 퀵타임과 싸우는 한편, 마이크로소프트는 PGML을 밀고 있던 어도비와 썬과의 싸움도 벌이고 있었다. PGML은 어도비 포스트스크립트에 기반하며, 벡터그래픽을 웹에 표시하기 위한 공개표준이었다. 마이크로소프트는 매크로미디어와 연합하여, 고유의 경쟁 표준인 VML을 선보였다. W3C 표준기구는 결국 두 진영으로부터 협상을 이끌어내서, 새로이 SVG (Scalable Vector Graphics)라 불리우는 표준을 만들어낸다.

그러나 마이크로소프트는 SVG 표준을 지원하지 않았다. 마이크로소프트는 인터넷 익스플로러에서 계속 VML을 밀었다. 그 결과 시장은 혼란스러워했고, SVG에 대한 실질적인 채택이 이뤄지지 않았다. 어도비의 무료 SGV 웹플러그인의 채택을 방해하기 위해, 마이크로소프트는 1999년, 인터넷 익스플로러 5에 매크로미디어의 폐쇄형 Flash 플레이어를 번들하기 시작한다. 윈도 독점을 이용, Flash 벡터 그래픽 플러그인에게 광범위한 기반을 안겨다준 것이다. 마이크로소프트는 Flash를 이용하여 특정 영화 포맷과의 호환성을 깨면서까지 퀵타임을 죽이려고도 했었다.

마이크로소프트의 퀵타임에 대한 반-경쟁적인 압박은 Flash에 새로운 기능을 안겨다준다. 바로 비디오 재생 기능이다. Flash 플러그인이 워낙 광범위하게 설치되었기에, 브라우저 안에서 폐쇄형 비디오를 재생시키는 데에 쓸 수 있었다. 표준형 비디오 파일을 비디오 플러그인 형태로 링크시키는 대신, 웹 개발자들은 폐쇄형 Flash 무비파일을 Flash 플레이어 플러그인으로 재생시키도록 웹을 만들기 시작했다. 다름 아닌 마이크로소프트가 광범위하게 배포시킨 플러그인이 Flash다.

인터넷 익스플로러를 사용하지 않는 사용자들도 매크로미디어 Flash 플러그인을 퀵타임 플러그인처럼 다운로드받을 수 있다. 웹 비디오가 이제 Flash 포맷에 묶였기에, 퀵타임-호환형 영상을 다른 미디어 소프트웨어에서 재생시킬 수 있는 것처럼, 다른 대안형 플레이어로 Flash 파일을 돌릴 수 없다. 추가적으로 매크로미디어 Flash 플레이어는 윈도에서만 대단히 잘 돌아간다. 이 때문에 Flash 콘텐트를 익스플로러에 묶어두는 효과가 발생하였다.

Apple takes back media with the iPod

웹비디오를 장악하는 데 실패했었던 마이크로소프트는 적어도 인터넷 익스플로러에서 제일 잘 돌아가는 포맷으로 웹 비디오를 끌어들이는 데에 성공하였다. 그 다음 마이크로소프트는 음악과 비디오 저작용 표준에 관심을 기울이기 시작했다. 마이크로소프트는 DVD의 ISO MPEG-2 표준을, 같은 디스크 상에서 DRM화된 윈도 미디어 포맷으로 바꾸기를 희망하였다. 소위 iHD라 불리우는 포맷이다. 음악에 있어서는 MPEG MP3를 윈도 미디어 오디오로 바꾸려 하였다. 불법복제가 불가능한 DRM을 약속하면서 제작사들도 끌어들였다.

그러나 마이크로소프트는 약속했던 윈도미디어 DRM 기술을 제 때 선보이지 못하였다. 이 때문에 애플 아이포드와 아이튠스 뮤직스토어가 성업하게 된다. 애플은 ISO의 표준 MPEG AAC를 채택하였다. 이 AAC는 세련된 데이터 압축 형식이며, 제작사들이 요구한 DRM도 지원하였다. 더구나 아이포드의 성공덕택에, 상업적인 오디오 배포용 포맷으로서 WMA는 위축되었고, 윈도용 아이튠스는 AAC를 맥과 윈도 양측의 새 표준으로 만들어버렸다. 데스크톱 전쟁에서 2%까지 줄어들었던 회사치고는 놀라운 성공이다.

그 다음 애플은 비디오에서도 같은 전술을 펼쳤다. MPEG H.264 표준을 아이튠스 비디오로 채택하고, 효율적인 재생을 위해 아이포드 상에서는 하드웨어 비디오 디코딩까지 지원하였다. WMV 재생기능을 준-표준화시키는 데에 실패한 마이크로소프트는 미국 내 SMTPE 표준을 통해 WMV 코덱을 겨우 세워 두었다. 후에 이 포맷은 이름이 VC-1으로 바뀌게 된다. VC-1은 Blu-Ray와 HD-DVD 사양 모두에 일부로 들어가 있게 되지만, 실제로 사용한 사양은 불운의 HD-DVD 뿐이었다. 그동안 아이튠스는 음악의 AAC처럼 비디오에서 H.264를 대중화시켰다.

Apple takes on WMV and Flash

애플은 상호 운용 가능한 공개표준을 위해 콘텐츠만 활용하지 않았다. 윈도 전용으로 콘텐츠를 묶어버리는 비표준 코덱에 대한 의존성도 없애버리는 작업을 시작하였다. 원래 마이크로소프트는 맥용 WMA와 WMV 지원을 결국 거부했었고, 매크로미디어 또한 맥과 리눅스, 인터넷 익스플로러 외의 브라우저용 Flash 플러그인을 거의 개선시키지 않고 있던 상황이다.

맥과 아이포드 하드웨어에서 상용 콘텐츠를 모두 잘 돌리도록 하기 위해, 애플은 아이포드 상에서 마이크로소프트의 폐쇄형 WMA/WMV 코덱 지원을 거부하고, 원형 WAV 오디오 포맷에서 MP3이나 AAC 표준만 지원해주는 음악 시장을 조성하는 데에 아이포드를 활용하였다. 아이포드 비디오도 마찬가지다. 아이포드 비디오는 WMV나 리얼비디오와 같은 폐쇄형 포맷이 아닌, MPEG-4/H.264 포맷만을 지원하였다.

아이폰이 나오자 이번 상대는 Flash였다. 아이폰은 Flash 영상 재생을 마찬가지 이유로 거부하였다. 공식적으로야 현재 어도비가 소유하고 있는 Flash가 아이폰과 잘 돌아가지 않는다는 이유다. 사실일 것이다. 그러나 아이폰용 Flash를 죽여야 할 진짜 이유는 웹개발자들이 다시금 표준형 비디오 포맷을 사용하도록 하기 위함이다. 폐쇄형 Flash 바이너리에 둘러싸인 콘텐트가 아니고 말이다.

좀 아이러니컬한데, 마이크로소프트는 Silverlight 런타임과 함께 원래 Sparkle이라 부르던 고유 포맷을 들고 나섰다. 어도비 Flash를 노리고 나온 포맷이다. 인터넷 익스플로러는 이제 경쟁자도 많아지고 점유율도 하락하고 있으며, 퀵타임에게 했던 것처럼 경쟁사(Flash)의 플러그인을 죽일 수 있는 힘은 약화되었다.

HTML 5 and the Ogg Theora option

그동안 오페라와 모질라의 파이어폭스, 애플의 사파리, 구글의 크롬과 같은 브라우저가 나와, 웹브라우저 시장에서 마이크로소프트의 통제력을 조금씩 뺏어갔다. 그리고 이들이 한데 모여, 비디오를 표시할 표준을 모의하기에 이르렀다. HTML 5는 비디오 파일 임베딩을 간단히 정의내려서 클라이언트 브라우저가 이를 표시할 수 있게 만든다. 마이크로소프트 입장은 일단 두고보자이다. 상호운용이 불가능하고 웹-표준에 적대적이며 Flash를 베껴서 만든 자신의 Silverlight이나 Flash의 수요를 떨어뜨릴 기세를 보인다면, 표준화 작업을 파괴시키려들 것이다.

애플은 이미 구글을 설득하여 YouTube 비디오 포맷에 H.264를 더해 놓았다. 이는 아이폰용 YouTube로 첫등장하였다. 구글은 또한 Flash 없이, H.264 비디오를 HTML 5 기본지원으로 보여주는 YouTube 웹사이트를 시연한 적도 있다.

그러나 문제점은 남아 있다. 무료 배포에 의존하는 두 브라우저의 회사 둘(모질라와 오페라) 다 H.264 코덱 라이센스에 적대적이기 때문이다. 이들은 H.264 대신, W3C가 HTML 5 공식 비디오 코덱으로 Ogg Theora를 채택하기 바라고 있다. Ogg Theora는 원래 On2에 묶여있던 VP3 비디오 기술을 기반으로 하고 있으며, 현재는 버려진 포맷이다. Flash 비디오가 On2의 VP6 기반이며, Skype의 고유 화상회의는 VP7을 사용한다. ISO의 상호운용가능 표준에서 보면 On2는 마이크로소프트의 WMV/V1만큼이나 독점적인 코덱이다. 다만 마이크로소프트의 영향력이 없을 뿐이다.

오픈소스 커뮤니티는 2001년 On2가 포기한 포맷인 VP3을 H.264에 대한 대안으로 홍보해왔다. 소프트웨어 개발자에게 있어서, Ogg Theora 사용은 MPEG 회원사들의 특허를 공유하기 위해 지불하는 로열티를 없애준다. 덕분에 비디오 게임 개발자나 Wikipedia와 같은 조직들이 Ogg Theora를 채택해왔다.

Ogg Theora vs. H.264

그러나 애플과 노키아와 같은 하드웨어 업체들은 여러가지 실용적인 이유를 들면서 Ogg Theora와 HTML 5의 결합에 반대하고 있다. 첫째로 H.264 라이센스 비용은 애플이나 노키아 입장에서, 소규모 소프트웨어 개발사들만큼 부담이 안된다. (즉, 무료로 소프트웨어를 배포하는 브라우저 회사 입장에서는 비용이 크다.) 애플도 사파리를 무료로 배포하기는 하지만, 사파리 사용자 대부분은 맥이나 아이폰을 구입하여 사파리를 돌린다. 이에 반해 모질라의 파이어폭스 사업방식은 1년에 구글이 모질라에게 지불하는 검색창값 5천만 달러가 거의 전부다. 구글과 같은 더 거대한 기업들 또한 Ogg Theora 사용에 특별히 비용을 고려하지는 않는다.

둘째로 애플과 구글, 노키아는 이미 H.264에 투자를 해 놓았다. 예전에 버려진 코덱을 지원하기란 별로 바람직스럽지 못하다는 의미다. 구글은 YouTube의 엄청난 스트리밍을 훨씬 덜 효율적인 Ogg Theora로 지원해줄 방법이 없다고 지적하였다. 덜 세련된 압축방식때문에 세상의 인터넷 대역을 소비해버리면 안된다는 의미다. 또한 Ogg Theora는 H.264처럼 하드웨어 가속 기능을 갖고 있지 않다. 즉, 넷북이나 스마트폰 사용에 있어서 Ogg Theora는 완전히 매력이 없다.

오페라와 모질라는 휴대용 기기를 만들지 않기에, 하드웨어 가속 기능에 연연해하지 않는다. 모질라는 휴대기기용 브라우저도 갖고 있지 않다. 반면 오페라는 오페라 미니에 모바일 사업을 집중시키고 있지만, 오페라 미니는 웹브라우저가 아니라 하나의 애플릿이다. 실제 브라우저를 돌릴정도로 강력하지 못한 휴대폰들을 위해, 오페라의 웹프록시 서버가 뿌려주는, 이미 렌더링된 웹페이지를 보여주기 때문이다. 진보적인 새 휴대기기들은 아이폰/아이포드 터치에서부터 Palm Pre, 블랙베리 Storm, 구글 안드로이드에 이르기까지 모두 WebKit 기반의 브라우저를 사용한다.

애플은 Ogg Theora의 특허권이 불명확하다는 주장도 하고 있다. 이것도 모질라와 오페라에게는 중요한 사안이 아니다. 문제가 될 경우, 두 회사 모두 Ogg Theora를 버리면 그만이기 때문이다. 전력이 있다. Unisys가 GIF을 사용하는 모두를 소송하고 있을 때, GIF에 대한 상용 지원을 일시적으로 포기했던 사례가 있었다. 그러나 애플과 같은 기업들은 미디어 콘텐트를 판매하고 있으며, 휴대용기기에서 하드웨어 가속을 지원해야 할 입장이다. 따라서 잠재적으로 특허소송이 날 수 있는 코덱 기술을 섣불리 채택할 수 없다. 게다가 애플에게는 현금이 많다. 특허괴물들이 노릴 만하다. 모질라와 오페라는 그러하지 못하다.

A problem that lacks any need for a solution

HTML 5의 미래를 둘러싼 진짜 문제는 다른 데에 있다. 공식 코덱을 지정해야 할 필요가 있느냐이다. 그래픽에는 공식 코덱이 없다. 웹 개발자들은 JPEG이나 GIF, PNG를 자유로이 선택할 수 있다. 사용자가 이미지를 볼 수 없다면, 관련 플러그인을 설치하면 될 일이다. 즉, 공식 그래픽 포맷이 없다하여 문제가 발생하지 않는다.

비디오도 마찬가지이다. 모질라가 제일 야단이기는 하지만, 브라우저가 비디오 코덱 지원을 라이센스해야 할 이유는 없다. 파이어폭스를 다운로드받아 쓸 정도의 자세라면, 퀵타임도 다운로드받아서 H.264 비디오를 볼 수 있다. 아니면 무료 H.264 코덱을 사용할 수도 있을 것이다. VLC와 FFmpeg, HandBrake가 사용하는 엔진인 GPLed x264을 포함한, FOSS 플랫폼용 코덱을 이용해도 된다.

더구나 웹 개발자들이 단일 코덱만 지원해야 할 필요도 없다. HTML 5는 H.264나 Ogg Theora, 심지어 Flash 바이너리도 쉽게 제공할 수 있게 되어있다. MPEG 라이센스를 하지 않기 위해 Ogg Theora를 택한 Wikipedia와 같은 조직이 아니라면, 퀵타임이나 다른 미디어 시스템의 오픈소스 코덱 컴퍼넌트 패키지를 다운로드 받아서 쓰면 된다.

즉, HTML 5용 공식 비디오 코덱을 둘러싼 전쟁은 지어낸 전쟁이다. 문제 거리가 못된다. HTML 5 자체의 채택이야말로 진짜 문제이다. 상호운용 가능한 비디오 홍보에 더해서, HTML 5는 클라이언트-사이드 데이터베이스와 오프라인 지원 등 웹 애플리케이션 지원을 골자로 하고 있다. HTML 5는 Flash나 Silverlight와 같은 폐쇄형 플러그인에 대한 의존을 없애고, 세련된 클라이언트-사이드 상호운용성으로 웹 콘텐트를 표시하려 한다.

누가 최고로 HTML 5를 지원하느냐가 유일한 문제다. 지난 과거의 폐쇄형 기술로 발목을 잡아끄는 이들은 뒤쳐질 것이다.

출처 : http://www.appleforum.com/mac-column/57512-ogg-theora%EC%99%80-h-264-%EA%B7%B8%EB%A6%AC%EA%B3%A0-html-5-a.html

============================================================================================================

위 글은 2009년에 쓰여진 글이다.

그 뒤로의 행보를 조금더 설명을 하자면 ,

구글의 on2 인수 - 구글의 공개 코덱 웹M ( H.264 죽이기 행보 ) - H.264 의 웹 컨텐츠에 한해서 라이센스 무료화 선언.

결론적으로 H.264 코덱에 대해서 웹 컨텐츠로 사용하는데에 라이센스를 지불하지 않으며,
하드웨어 제조업체들 , 즉 비디오를 플레이 하는 기계들을 만드는 업체들은 , 해당 기계에서 H.264를 지원을 하게 되면 라이센스를 지불 해야 한다 라는 방향으로 세상은 흘러 가고 있다.

위 글을 읽어 보면 느끼는 부분이, 어제의 동지가 오늘의 적.
이라는 것 ^^
기술이라는 것이 참 정치적인데 특히 영상 코덱 동네는 정말 치열하다.

참고 URL :
http://wonsuk73.tistory.com/4
http://www.bloter.net/archives/46324
http://www.zdnet.co.kr/news/news_view.asp?artice_id=20100520055856