it is power

http://www.cdrinfo.co.kr/entry/%EB%8F%99%EC%98%81%EC%83%81-%ED%99%94%EB%A9%B4%EB%B9%84Aspect-Ratio%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B8%B0%EC%B4%88-%EC%A7%80%EC%8B%9D

MP3 의 모든 원리 

MP3에 대해 이해하기 위해서는 MPEG 오디오에 대한 이해가 앞서야 한다. MPEG 오디오는 기본적으로 60분이나 72분 정도의 CD에 포함된 44.1KHz의 샘플레이트에 16비트 음의 깊이를 가진 오디오 데이터의 크기를 줄이는 것이 주목적이다.

음의 깊이는 서로 다른 소리의 세기로 8비트일 경우에는 256개의 단계를 가지며 16비트는 65,536가지로 음의 세기를 표현할 수 있다. 셈플레이트는 1초동안 나타낼 수 있는 음의 표본(샘플)으로 22KHz는 22,000개의 샘플을 1초에 나타낼 수 있다.

예를 들어 650MB에 해당하는 오디오 데이터가 있을 경우, 크기를 줄일 수 있는 여러 가지 방법이 있다. 가장 고전적인 방법은 여기에 포함된 정보를 줄이는 것이다. 이 데이터가 16비트로 구성됐을 경우 8비트로 줄이면 데이터는 반으로 줄어들게 된다 이 경우 역동적인 음을 잃게 되며 잡음이 생긴다. 만일 샘플레이트를 감소시키면 음의 선명도가 떨어진다.

MPEG을 이용할 경우에는 파일 크기는 감소하지만 디지털화된 정보의 양은 그대로이다. 이것은 아주 간단해 보이는 공식이지만 MPEG의 장점을 가장 잘 표현한 것이다.
사람들은 흔히 감소(Reduction)와 압축(Compression)을 혼동한다. 하지만 사용자들은 데이터가 감소된 음악은 원하지 않는다. 

만일 사용자가 차를 샀을 경우 움직이기를 바란다 .이것은 가장 기본적인 기능으로 자동차가 많은 양의 기름을 사용할 경우에는 적은 양의 기름보다 훨씬 강력한 파워를 발휘한다. 하지만 적은 양의 기름을 사용했더라도 자동차는 움직인다. 적은 양의 기름을 사용하는 자동차라 해도 연소율이 높다면 강력한 파워를 가질 수 있다. 이와 마찬가지로 MPEG 의 경우 작은 크기의 파일이라 해도 여기에 많은 양의 데이터를 담을 수 있다.

MPEG 의 경우 오디오나 비디오 데이터를 저장하는 용도로 사용하는데, 영상이나 음성에 관련된 재생을 보다 효율적으로 수행한다. 8시간 분량의 오디오 데이터를 MPEG 방식으로 압축하면 원음과 동일한 음질로CD-ROM 1장에 담을 수 있다.

MPEG 사용 이유
MPEG 오디오 레이어
MPEG 오디오 파일(MP3)의 구성
MP3의 발전
MP3의 기술 배경

MPEG 오디오 작동 원리

MPEG 오디오가 어떤 식으로 정보를 재생하는가는 별로 중요하지 않다. MPEG 오디오는 기본적으로 인간의 인지 능력에 기반을 두고 있다. 따라서 인코더는 어떤 정보가 중요하며 어떤 정보는 빼버릴 지를 결정한다. 

우리가 어떤 소리를 들을 때 입력된 데이터는 우리의 두뇌를 통해 분석한다. 두뇌는 입력된 소리를 해석하며 부적절한 정보를 여과해 낸다. MPEG 오디오는 이러한 작업을 미리 수행해 버린다. 이것을 "인지코딩(Perceptual Coding)"이라고 부른다.

좀더 기술적으로 설명하면 강한 신호가 발생했을 때 뒤에 있는 약한 신호는 인식하기 힘들다. MPEG 오디오의 코덱은 이런 약한 신호를 제거한다.

이것은 매우 현명한 방법으로 MPEG 오디오를 이용하면 우리의 두뇌에 들어 있는 필터가 필요없는 정보를 제거할 필요가 없으며 하드디스크 공간이나 인터넷 트래픽을 훨씬 덜 발생시킨다.

만일 사용자가 매우 강한 압축률로 인커딩한다면 MPEG 오디오는 덜 중요한 정보까지 모두 제거해 버려 음질이 약간 떨어지지만, 낮은 압축률(192 kbs이하)을 이용하면 사용자는 압축하지 않은 원음과 차이를 거의 느끼지 못한다.

MPEG 사용 이유

새로운 기술을 산업에 적용시키는 이유는 무척 간단하다. 같은 수준의 성능에서 가격 경쟁력이 생기기 때문이다. 다음 리스트는 현재 MPEG 오디오 기술이 적용된 곳이다. 

* 인터넷에서 이용되는 스트리밍 오디오(매크로미디어 SWA, 오디오액티브)
* 디지털 오디오 브로드캐스팅(Digital Audio Broadcasting - DAB, ADR)
* 필립스 DDC

MPEG 오디오는 디지털 미디어 저장 장치를 매우 싼 값에 소비자에게 제공해준다. 간단한 예로 CD-ROM 드라이브를 이용해 오디오 데이터를 하드디스크 드라이브로 추출한 뒤 MPEG 오디오 방식으로 압축하면 최소 공간을 이용해 쥬크박스를 제쟉할 수 있다.

MPEG 오디오 레이어

현재 MPEG 오디오 레이어에 대한 많은 혼란이 있다. 모든 레이어는 기본적으로 '인지 코딩(Perceptual Coding)' 이라는 동일한 코딩 방식을 사용한다. 하지만 코덱의 복잡성은 레이어가 증가함에 따라 증가한다. 즉 레이어 2는 레이어 1에 해당하는 비트레이트로 우수한 음질을 만들기 위해 많은 노력을 한다. 따라서 레이어 3의 코덱이 가장 복잡하다. 

레이어 1의 정신분석학적인 음향 모델은 단지 주파수 위장에 그치고 있다. 이말은 고음 뒤에 숨어 있는 주파수만을 제거하는 수준이다. 때문에 384kbps 이상으로 압축을 할 수 없게 된다. 이것은 가장 단순한 레이어로 일반적인 사용자에게 적합하다. 레이어 1은 서브밴드 필터링으로 32 길이의 동일한 서브밴드로 구성되는데 이 서브밴드에는 적당한 크기의 비트와 압축된 정보가 들어간다. 비트레이트는 32kBit(모노)에서부터 448kBit(스테레오)까지 존재한다. 인코더의 복잡성에 따라 CD 수준의 스테레오일 경우 256~384 kb/s 까지 전송률울 가진다. 디커더에 비해 인코더는 대략 1.5배에서 3배정도 복잡하다. 
레이어 1의 경우 Solid State Audio, 디스크 편집이나 저장, CD-I 풀모션 비디오에 사용된다. 

레이어 2는 약간 더 많은 필터 기능을 가진다. 레이만(Layman)의 정의에 따르면 이것은 원본으로부터 필요없는 더욱 많은 정보를 제거할 수 있다. 따라서 160Kbps로 인코딩하면 우수한 수준이 되며, 192Kbps일 경우 원본과 차이점을 느낄 수 없으며 256Kbps일 경우에는 하이파이 수준의 음질을 구현한다. 레이어 2는 레이어 1에 비해 더 높은 압축률을 가진다. 따라서 레이어 2는 오디오 방송이나 텔레비전, 음성 통신과 같이 일반 사용자나 전문 오디오에 많이 사용되고 있다. 모노의 경우 32~192 kb/s의 비트레이트를 가지며 스테레오는 64~384 kb/s를 이용한다. CD 수준의 고음질일 경우에는 192~256 kb/s의 비트레이트를 필요로 한다. 디커더의 경우 레이어 1에 비해 25퍼센트 정도 더 복잡하며 인코더는 2~4배 정도이다.

레이어 2는 CD-I 풀모션 비디오, 비디오 CD, Solid State Audio, 디스크 저장 및 편집, 디지털 오디오 방송, DVD, 케이블/위성 라디오, 케이블/위성 TV, 방송, 영화 사운드트랙 등에 이용되고 있다. 

레이어 3은 가장 복잡한 MPEG 오디오 모델이다. 이것은 레이어 2에 비해 훨씬 많은 필터를 사용하며 허프만 코더를 이용한다.. 112 Kbps로 인코딩하면 우수한 음질을 들을 수 있으며 128 Kbps일 경우 원본과 거의 동일하며 160 Kbps 나 192 Kbps의 경우 귀로는 원본과 차이를 구별할 수 없다 레이어 3은 MPEG 1 을 더욱 확장한 것으로 ISDN을 이용한 음성 통신과 보다 전문적인 오디오를 위한 규격이다. 현재 레이어 3은 ISDN을 이용한 방송에 사용되고 있다.

MPEG 오디오 레이어의 복잡성
                인코더       디코더
레이어1     1.5 ~ 3         1.0
레이어2     2 ~ 4           1.25
레이어3     7.5 이하        2.5


MPEG 오디오 파일(MP3)의 구성

흔히들 사용하는 MP3 파일은 헤더와 CRC, 오디오 데이터, 보조 데이터로 구성된다. 헤더는 32비트의 고정된 필드에 위치하는데 여기에는 레이어와 샘플링 주파수, 남아 있는 프레임과 같은 정보를 담고 있다. 

CRC(Error Detection Code)는 선택 사항으로 이것의 유무는 헤더에서 정의되며 길이는 16비트이다. 하지만 디지털 오디오 하드디스크 레코딩 시스템에서는 사용되지 않는다.

오디오 데이터는 실제로 압축된 데이터를 담고 있는데, 그 길이는 음악에 따라 다르다. 보조 데이터는 사용자가 정의한 구역으로 여기에는 추가적인 정보가 들어가며 크기도 변동적이다.

MP3의 발전

MP3는 MPEG의 발전과 함께 시작됐다. MPEG 오디오 표준은 바이너리 데이터 표준과 디코딩 전송 방식을 기술하고 있다. 91년 ISO/MPEG 오디오 압축 알고리즘은 업계 표준으로 정착됐다. 이 표준은 CCETT(Centre Commun d'Etudes de Telecommunications et de Telediffusion), 프랑스의 IRT, 독일 그리고 네덜란드의 필립스가 개발했다.

MPEG 오디오 표준은 비트 스트림 신택스나 디코더 규격을 정의하고 있다. 이것은 공개된 아키텍쳐이기 때문에 지속적으로 성능을 향상시킬 수 있으며 규격을 만족시키는 프로그램을 쉽게 개발할 수 있다. 이러한 유연성 때문에 MPEG 에 기반을 둔 오디오 시스템은 심리음성학을 이용한 최신 기술을 대부분 사용할 수 있다. 한편으로 디코딩 방식은 거의 동일하지만 인코딩 방식은 업체에 따라 약간씩 다르다.

MPEG 오디오 표준에서는 프레임을 시리얼포트를 통한 바이너리 데이터의송수신으로 표현한다. 따라서 서로 다른 제조업체에서 만든 시스템이라도 해도 MPEG 오디오 파일을 디코딩해서 읽을 수 있다.

MP3의 기술 배경

간단한 오디오 압축 방식
전통적인 무손실 압축방식(허프만, LZW 등)은 일반적으로 오디오 압축에서는 제대로 작동되지 않는다. 그 이유는 이미지 압축과 비슷하다. 현재 다음과 같은 다양한 방식의 압축 알고리즘이 사용되고 있다. 

1. 무음압축(Silence Compression) 
- 무음 부분을 찾아내 압축하는 방식으로 런렝쓰(Run-Length) 코딩 방식과 비슷하다.

2. ADPCM(Adaptive Differential Pulse Code Modulation) 
- CCITT G.721-16/32Kbit/sec, 2개의 연속되는 신호의 차이를 기록한다. 이 방식은 애플 컴퓨터에 의해 ACE/MACE라는 이름으로 사용됐다. 압축률을 2:1로 다음번 웨이브의 형태를 예측할 수 있다.

3. 리니어 프리딕티브 코딩(Linear Predictive Coding, LPC) 
- 음성 시그널에 적합한 방식으로, 마치 컴퓨터가 이야기하는 것과 같은 하우링 현상이 있다. 전송률은 2.5 Kbits/sec 수준이다.

4. 코드 익사이티드 리니어 프리딕터(Code Excited Linear Predictor, CELP)는 LPC 기능에 에러 정정 코드를 삽입한 방식으로 오디오 회의 수준의 음성을 들려 준다. 전송률은 4.8Kbit/sec 정도이다.

심리 음성학
인간의 귀는 20Hz 에서 20 KHz까지 들을 수 있지만 대부분 2KHz 에서 4KHz 구간에서 가장 민감하며 다이내믹 레인지는 대략 96dB 정도이다. 일반적인 음성일 경우 500KHz에서 2KHz 사이며, 모음이나 베이스 영역은 낮은 진동수를 가지며 자음부분은 높은 진동이 발생한다. 또한 강한 신호음을 듣고 그 신호가 멈추어도 그에 대한 여운이 얼마 동안 남게 된다. 예를 들면 1KHz에 60dB의 진동음에 1.1KHz에 40dB의 신호를 더한다면 40dB의 신호는 들리지 않는다. 

MPEG 오디오 압축
MPEG-1의 경우 1.5Mbits/sec의 오디오와 비디오 전송률을 가지는데 여기서 비디오는 1.2Mbits/sec이며 오디오는 0.3Mbits/sec를 전송한다. 실제로 압축더ㅣ지 않는 CD 오디오는 44,100 샘플/sec x 16비트/샘플 x 2 채널로 1.4Mbits/sec보다 많은 데이터이다. MPEG-1의 압축률은 2.7에서 24배까지이며 6:1(48KHz에 16비트 스트레오 샘플일 경우 256 kbits/sec)정도의 압축률일때 전문가도 원음과 구별하지 못 할 정도의 최적 음질을 구현할 수 있다. MPEG 오디오는 32,44,1,48KHz의 샘플링 프리퀀시를 지원한다. 현재 1개나 2개의 오디오 채널을 통해 4가지 모드를 지원한다. 

1. 모노포닉(Monophonic) - 싱글 오디오 채널
2. 듀얼 모너포닉(Dual-monophonic) - 2개의 독립적인 채널
3. 스테레오 - 비트를 나누어 사용하는 스테레오 채널. 조인트 스테레오 코딩을 사용하지 않는다.
4. 조인트 스테레오 - 스테레오 채널간에 상관관계를 향상시킨 방식

오디오 압축 알고리즘
오디오 암호화 기술에 있어서 가장 기본이 되는 것은 사람의 귀이다. 불행히도 이것은 완벽한 음향기기는 아니지만 우리가 가진 우수한 도구이다. 사람의 귀가 가진 결점 중에서 일직선으로 연결돼 있지 않고 정확한 소리의 시작점을 찾지 못한다는 것이 장점으로 활용되고 있다. 

소리의 진원지가 어느 수준 이하가 되면 사람든 듣지 못한다. 개인적인 차이는 있지만 대부분 2 ~5 KHz 사이에서 가장 민감하게 반응한다. 사무실에서 누군가 큰 목소리로 이야기한다면 어느 누가 이야기하는지 쉽게 파악할 수 있다. 하지만 그 순간 비행기가 지나간다면 전혀 들리지 않게 된다. 또한 비행기가 지나간 뒤에도 그 여운이 남아 잘 들리지 않는다. 이와 같은 현상은 'Masked' 라고 표현한다. 

이 효과는 보편적이며 특히 음악에서 적절하게 사용된다. 오케스트라가 악기를 매우 큰소리로 연주한다면 다른 악기 소리는 사람의 귀에 들리지 않는다. 하지만 이 음악을 레코딩한다면 모든 악기 소리가 적당히 녹음된다. 그 이유는 녹음기기는 모든 음을 동일하게 받아들이기 때문이다. 만일 녹음된 음악을 재생해도 사람들은 거기에 포함된 작은 악기 소리는 듣지 못한다. CD 등을 사용한 이러한 1차적인 기록은 위의 관점에서 본다면 효율적이지 못하다. 하지만 현재 대부분의 음악 데이터에는 실제 듣지 못하는 데이터가 같이 담겨져 있다. 오디오 압축 알고리즘은 이러한 부분의 데이터를 음의 손상없이 압축하는 것이다. 

이를 수행하기 위해서 먼저 인식 서브밴드 오디오 인코더는 지속적으로 들어오는 오디오 시그널을 분석하고 위에서 설명한 마스킹커브(큰소리 때믄에 사람들의 귀에 들리지 않는 작은 소리)를 분석한다. 다음은 이상의 과정과 다음 과정을 간단하게정리한 것이다.

1. Sub-Band 필터링
포선형(Convoluton) 필터를 이용해 오디오 시그널(예를 들면 48KHz 사운드)을 대략 32개의 중요한 주파수 대역으로 나눈다.

2. 심리 음성학 모델
위에서 설명한 심리 음성학을 이용해 나누어진 근처의 주파수 대역에서 들리지 않는 대역을 가려낸다.

3. 심리 음성학 모델을 이용해 결정한 대역 중에서 가장 강하게 들리는 음의 시작이라면 여기는 인커딩하지 않는다. 

4. 잡음이 아닌 신호 데이터로 충분하게 표현될 수 있는 비트수를 결정한다

2007년 8월 인터넷의 대부로 불리는 빈트 서프는 영국의 한 일간신문에서 전통적인 개념의 TV시대는 끝났다고 말한 바 있다.

음악산업이 MP3플레이어의 등장으로 붕괴되기 시작한 것과 유사한 형태로 TV 역시 아이팟 시대를 향해 가고 있다는 내용이었다. 빈트 서프는 생방송으로 시청할 필요가 있는 뉴스, 스포츠, 비상상황 등을 제외한 대부분의 프로그램은 아이팟처럼 녹화하여 나중에 보는 형태가 도래 할 것이라고 주장했었다. 당시 방송 프로그램의 85%가 생방송이 아닌 녹화물이었다.

빈트 서프의 TV 종말론은 서서히 무게감을  더해가고 있는 느낌이다. 인터넷 동영상서비스가 TV와 접목되면서 주문형 TV 시장에서는 새로운 움직임과 가능성이 나타나고 있다. OTT 서비스가 영역 확산을 모색하고 있는 것이다.

OTT 서비스란?

OTT(OVER-THE-TOP)서비스는 인터넷 동영상서비스 또는 인터넷 VOD 서비스와 유사한 개념이다. 기존의 통신 및 방송

사업자가 아닌 제3사업자들이 브로드밴드를 통해 제공하는 영화나 방송프로그램 등의 프리미엄 동영상 서비스를

의미한다.

그런데 OTT는 초기의 인터넷 동영상서비스와 달리 PC 뿐만 아니라 전용단말기(셋톱박스)를 통해 TV에서도 구현이 되는 서비스로 진화하였다. 굳이 말하자면, 이같이 전용단말기를 통해 TV에서 구현되는 인터넷 동영상서비스를 진정한 OTT 서비스라 할 수 있다. OTT라는 명칭도 전용 단말기(셋톱박스)를 사용하고 있다는 것과 무관하지 않다.

최근 들어 OTT 서비스는 인터넷을 통해 영화나 방송프로그램 등과 같은 동영상 콘텐츠를 전달하는 서비스를 총칭하는 의미로도 사용된다. 동영상 이외에 데이터, 광고, 전자상거래 등 멀티미디어 콘텐츠도 서비스 영역으로 포함된다. 이렇게 볼 때 TV에만 구현되는 인터넷 동영상서비스를 협의의 OTT, PC와 TV 모두 구현되는 동영상서비스를 광의의 OTT로 정의할 수 있다.

2008년 말 미국 NBC의 대표적 심야방송 프로그램인 'Saturday Night Live'의 경우 시청자의 절반 이상이 케이블 방송 대신 OTT 서비스를 활용한 것으로 조사된 바 있다. 이러한 여세를 반영하듯 넷플릭스, 훌루닷컴 등과 같은 성공적인 OTT 서비스 업체들도 등장하고 있다.

현재 CATV가 주도해온 유료방송시장은 통신회사들의 IPTV가 가세하여 치열한 점유율 경쟁이 전개되고 있다. 이러한 상황에서 OTT는 소리 소문 없이 CATV와 IPTV의 아성에 도전하는 다크호스로 급부상하고 있다.

OTT의 등장 배경

첫째, OTT 서비스는 값싸고 간편하게 영화나 방송프로그램을 시청하고자 하는 소비자의 니즈를 적절하게 충족시켜주는

서비스이다. 채널선택권 제약이나 생활패턴의 차이로 인해 정해진 시간을 놓치면 시청하기 쉽지 않은 TV 프로그램과는 달리

자신이 원하는 프로그램을 시간에 관계없이 시청할 수 있는 개인용 매체라는 속성을 지니고 있다.

데이터베이스를 검색하여 자신이 원하는 프로그램을 마음대로 선택할 수 있으며,

실시간 방송 내용을 별도의 저장매체에 보관할 수 있는 자기 통제적 성격을 갖춘 매체이기도 하다.

또한 기존의 케이블방송에 비해 가격도 훨씬 저렴하다. 미국에서 케이블방송을 청취하려면 매달 100달러 이상의

비교적 높은 비용을 지불해야 하는 반면, OTT의 일종인 넷플릭스의 경우 9달러 수준에 불과하며

훌루닷컴의 경우 무료로 영화나 방송 프로그램의 시청이 가능하다.

둘째, 최근 OTT 서비스가 활성화되고 있는 것은 네트워크 및 전송기술의 향상과 방송사 등 콘텐츠 소유업체들의

유통채널 확장 전략 등 공급측면에서의 장벽들이 해소되고 있기 때문이다.

초기 OTT 서비스의 경우 일반 유저들이 제작한 아마추어 동영상 UCC가 주류였지만 메이저 방송사들이 TV에 방송된 프로그램을 곧바로 인터넷으로 유통시키면서 OTT 시장의 콘텐츠는 소비자의 니즈에 부합할 수 있을 정도로 풍부해지고 있다.

ADSL과 케이블모뎀의 속도 향상과 FTTH의 등장으로 네트워크의 광대역화가 빠르게 진행됨에 따라 인터넷과 웹캐스팅은

메이저 콘텐츠 업체들이 자신들의 대용량 동영상 콘텐츠를 배포하는 새로운 유통 플랫폼으로 활용가능하게 되었다.

또한 네트워크 성능 향상과 더불어 웹상에서 동영상을 쉽게 구현할 수 있는 플래시 등과 같은 리치 인터넷 기술의 확산도

OTT 서비스의 확산을 촉진시키고 있다. 그 결과 인터넷은 방송의 보조적 배포 수단이 아니라 그 자체로 독립적인

서비스 플랫폼의 지위를 확보하게 되었다.

셋째, 단말기의 진화도 OTT 서비스의 확산에 한 몫을 하고 있다. PC로 국한되었던 기존의 인터넷 동영상서비스가 TV로

확산되고 있다. Apple TV, Netflix Player by Roku, Blockbuster MediaPoint, VUDU Box 등과 같이 OTT 동영상 서비스를

TV로 시청할 수 있도록 지원하는 다양한 셋톱박스가 출시되어 있기 때문이다.

또한 X-Box 360과 같은 게임기들고 OTT를 지원한다. 특히 최근에는 OTT를 지원하는 브로드밴드 HDTV도 출시되고 있다.

이미 일본의 5대 가전회사들은 공동 TV포털 서비스인 'acTVila' 기능이 내장된 TV를 생산하고 있으며, 향후 acTVila 내장 TV의 비중을 전체 디지털TV의 절반정도로 높일 예정인 것으로 알려지고 있다.

OTT의 4가지 사업 유형

OTT는 소비자들이 직접 체감 할 수 있는 요금이나 서비스 형태에 따라 가입비형, PPV형, 광고기반형, TV포털형 등

4가지 유형으로 분류될 수 있다.

먼저 가입비형은 매달 일정 금액을 지불하고 제한 또는 무제한으로 비디오를 시청하는 형태다.

넷플릭스가 제공하는 OTT 서비스가 여기에 해당한다.

PPV형은 고객이 시청하는 비디오마다 건당으로 과금하는 유형이다.

애플의 Apple TV, 아마존 VOD, 블록버스터의 Movielink 등이 여기에 해당한다.

이 유형의 경우 대부분의 디지털 형태의 영화구매도 동시에 지원한다.

광고기반형의 경우 고객은 콘텐츠 비용을 지불할 필요가 없다. 그대신 반드시 광고를 시청해야 한다.

훌루닷컴이나 유튜브 등이 이 유형에 속한다.

마지막으로 TV포털은 셋톱박스가 내장된 TV를 통해 직접 동영상 콘텐츠를 서비스하는 유형이다.

기본서비스가 무료로 제공된다는 점에서 광고기반형과 유사한 점이 있긴 하지만 유료 콘텐츠도 제공한다.

TV 포털형은 OTT 서비스 뿐만 아니라 다양한 정보와 뉴스를 제공하기 때문에 종합적인 TV포털의 속성을 갖고 있다.

일본에서 서비스되고 있는 acTVila가 이 유형에 속한다.

현재 OTT는 다양한 비즈니스 모델을 통해 사업화가 활발히 진행되고 있다. 따라서 각 유형별로 성공체험을 하고 있거나 유의미한 특징을 갖고 있는 사례를 자세히 살펴봄으로써 OTT의 성장가능성과 잠재력을 판단해 볼 수 있을 것이다.

국내 OTT 활성화 더뎌

우리나라에서도 곰TV, 판도라TV 등 초기 온라인 콘텐츠 스트리밍 업체들이 OTT의 명맥을 이어가고 있다.

하지만 OTT 서비스가 빠르게 확산, 진화되기는 쉽지 않을 것 같다.

우리나라의 경우 대화면 디지털TV의 보급이 활발한 가운데 CATV와 IPTV가 유료방송시장을 주도하고 있을 뿐 아니라

이들 유료방송이 이미 대부분의 가정에 보급되어 있어 OTT 서비스가 비집고 들어갈 여지가 거의 없는 실정이기 때문이다.

넷플릭스, Apple TV 등과 같이 전용단말기를 통해 서비스되는 OTT 유형은 국내 IPTV에 비해 차별적 우위를 확보하기 어렵다.

우리나라 IPTV는 2006년 VOD 기반으로 상용화되었으며, 2008년 11월 이후 실시간방송도 완벽하게 구현하고 있어 기존의 CATV의 강력한 대체제로 부상하고 있다. 특히 IPTV는 자금력이 풍부한 통신회사가 사업을 주도하고 있기 때문에 고객들은 무료로 IPTV용 셋톱박스를 사용하고 있다. 게다가 IPTV를 초고속인터넷 및 VoIP 서비스와 번들로 가입할 경우 번들할인을 통해 요금은 무료에 가깝다.

반면, 국내에서는 영화나 TV 방송 등 유료 콘텐츠를 저렴하게 공급할 수 있는 경쟁력 있는 미디어 업체나 대형 콘텐츠 어그리게이터의 출현이 이루어지지 않고 있어 OTT 사업자가 IPTV와 가격경쟁을 벌이는 것은 불가능하다.

국내에서 대형 OTT의 탄생이 어렵다면 넷플릭스나 훌루닷컴과 같은 해외 OTT 업체들의 국내 진출 가능성은 얼마나 될까?

아쉽게도 낮을 것 같다. 무엇보다도 저작권 문제로 인해 해외 OTT 업체들의 국내진출이 원천 봉쇄되어 있기 때문이다.

우리나라에서 시청하는 외국 영화나 TV 드라마는 전부 국내의 배급사나 에이전트를 통해 수입되며, 글로벌 영화나 방송프로그램 제작사들은 전세계 지역별로 저작권을 엄격히 관리하고 있다.

만일 해외 OTT 업체들이 저작권 문제를 해결하고 국내에 진출한다고 해도 외국의 영화나 방송 프로그램만으로는 국내 소비자들을 공략하기가 쉽지 않다. 국내 소비자들은 우리나라 드라마에 대한 선호도가 매우 높은 특징을 보이고 있기 때문이다. 지난 2006년 TNT 미디어 코리아의 자료에 의하면 국내 CATV 전체 시청률은 11.9%인 반명 지상파는 32.6% 였다. 이러한 비중은 최근에도 크게 변화하지 않은 것으로 추정된다. 우리나라 지상파 방송의 시청률은 대부분 자체제작하고 있는 드라마에서 나오고 있으며, 이 때문에 지상파 방송은 국내 방송시장의 킬러 콘텐츠의 역할을 지속하고 있다. 이렇게 볼 때 국내에서는 당분간 OTT가 유료방송시장의 다크호스로 부상하기는 어려울 것으로 판단된다.

IPTV와 결합한 새로운 사업모델 등장 가능

하지만 변화의 여지는 있다. IPTV의 등장이 국내 VOD 및 유료방송 시장이 재조명될 수 있는 계기를 제공하고 있기 때문이다.

불법 콘텐츠 다운로드가 사회적 문제로 인식되면서 디지털 콘텐츠를 활용하기 위해서는 적정한 비용 지불이 불가피하다는

방향으로 소비자 의식이 바뀌고 있다. 안방의 거실에 설치되어 있는 대화면 디지털 TV를 이용하여 저렴한 비용으로 IPTV의 영화를 관람하는 것은 비록 초기 PC 기반의 동영상 서비스와는 차원이 다르지만 진화된 OTT 서비스를 통해 유사한 체험이 가능하다.

이러한 변화의 움직임은 그동안 미미했던 OTT 시장의 확대와 더불어 새로운 OTT 업체의 탄생으로 이어질 가능성이 높다.

그렇지만 국내의 치열한 경쟁에서 OTT가 세력을 확장하기 위해서는 어떠한 노력이 필요할까?

무엇보다도 OTT 사업의 기본은 콘텐츠 소싱 역량에 있다. 따라서 풍부한 콘텐츠를 확보해야 한다. 온라인 DVD 대여업의 사업기반과 콘텐츠 어그리게이트의 강점을 적절히 활용하여 OTT 사업에 진입하고 있는 넷플릭스, 광고기반의 무료서비스를 지향하는 훌루닷컴 등의 성공 모델은 모두 풍부한 콘텐츠를 기반으로 하고 있다.

또한 구체적인 수익모델을 확보해야 한다. 일본의 OTT 업체 하테나는 2007년 2월 유튜브의 UCC 동영상을 TV 방송 채널로 제공하는 리모(Rimo) 서비스를 제공했다. 하지만 유튜브도 극찬했던 리모는 수익모델 부재로 불과 1년 6개월만인 2008년 8월에 사이트를 폐쇄하고 말았다. 대표적인 OTT로 인정받고 있는 유튜브는 비록 범세계적으로 소비자 관심을 끄는데 성공했지만 저작권 문제로 인해 수익모델을 제대로 정착시키지 못하고 있다. 적자가 누적될 경우 향후 사업의 지속성을 보장받기 어렵다는 업계의 평가가 있다.

마지막으로 국내에서는 기존 유료방송과의 출혈경쟁 대신에 국내 매체환경과 국내 소비자들의 특성을 감안한 사업모델 확보가 전제되어야 한다. 예컨데 OTT와 IPTV가 서로 제휴하는 모델을 고려해 볼 수 있다. OTT 업체는 IPTV의 특정 채널을 통해 OTT 서비스를 제공하고 IPTV 업체는 OTT 서비스를 통해 부족한 콘텐츠 역량을 보완할 수 있다.

세상에는 수많은 프로그래밍 언어가 존재한다. 각 프로그래밍 언어는 자신만의 독특한 장단점을 가지고 있기 때문에 모든 프로젝트에 적합한 최고의 프로그래밍 언어는 존재하지 않는다. 결국 프로젝트의 요구 사항과 성격, 개발자의 자질, 여러 환경 요소를 모두 고려하여 가장 적절한 프로그래밍 언어를 고르는 일이 중요하다. 이 글에서는 프로그래밍 언어를 선택할 때 어떤 요소들을 고려해야 하는지 알아보자.  

 
소프트웨어 개발자들은 성경에 나오는 바벨탑의 교훈을 잊어버린 걸까? 세상에 존재하는 수많은 언어 때문에 존재하는 불편함을 잘 알고 있는 프로그래밍 언어 개발자들이 왜 각자 문법과 어휘가 다른 수많은 프로그래밍 언어를 만들어 냈을까? 프로그래밍 언어는 단순히 의사소통을 하기 위한 수단만은 아니다. 소프트웨어는 세상에 산재하는 수많은 도메인(domain)의 문제를 풀어야 하고, 이 모든 문제들을 쉽게 풀 수 있는 최적의 언어는 존재하기 힘들기 때문이다. 소프트웨어 개발자들은 자신이 개발해야 하는 소프트웨어의 성격에 따라 프로그래밍 언어를 달리해야 한다. 시스템 소프트웨어를 작성한다면 C 언어와 어셈블리 언어가 적합할 것이며, 간단히 자신의 알고리즘을 테스트해보거나 프로토타이핑을 한다면 인터프리팅(interpreting)되는 스크립트 언어가 적합하다.
 
비교적 간단한 프로그램을 작성해보는 것이라면 사실 어떤 언어를 사용해도 무방하다. 하지만 비교적 큰 프로젝트의 산출물은 여러 가지 요소에 의해서 그 품질이 결정되는데, 여기에는 적절한 프로그래밍 언어의 선택이 중요하다. 따라서 프로젝트 초기에 프로젝트를 계획하면서 개발 도구와 환경을 결정할 때 프로그래밍 언어를 정하는 과정도 반드시 포함되어야 한다. 이 과정에서 여러 개의 프로그래밍 언어를 후보로 올려놓고, 프로젝트의 성격에 따른 여러 기준을 적용하며 의사 결정을 하게 된다. 프로그래밍 언어를 고르는데 있어서 절대적인 잣대는 없지만, 이 글에서는 이 과정에서 사용할 수 있는 몇 가지 유용한 판단 기준을 제공하고자 한다.
 
컴파일 vs. 인터프리터
숙련된 프로그래머 중에서 컴파일되는 프로그래밍 언어와 인터프리터되는 프로그래밍 언어의 차이점을 모르는 사람은 없을 것이다. 인터프리터되는 언어는 비교적 빠른 속도로 프로그램을 짤 수 있고, 결과를 쉽게 확인할 수 있다. 반면 컴파일되는 언어는 수행 속도가 빠르다. 프로그래밍 언어를 선택할 때 가장 먼저 적용해봐야 할 잣대 중에 하나는 해당 언어의 컴파일러나 인터프리터가 존재하느냐는 것이다.
 
경우에 따라서는 컴파일러와 인터프리터가 모두 존재할 수도 있고, 두 가지가 혼합된 형태일 수도 있다. 예를 들어 자바의 경우 자바 프로그램이 바이트코드(bytecode)로 컴파일되고, 자바 가상 머신(Java Vir tual Machine)에 의해서 다시 인터프리트되는 것이 일반적이다. 그러나 모바일 컨텐츠나 게임을 만들 때는 자바로 프로그램을 만들고 수행 속도 향상을 위해 타겟 플랫폼에 맞춰 미리 컴파일(AOTC, Ahead Of Time Compilation)하는 경우가 흔한데, 이는 자바 언어의 컴파일러라고 볼 수 있다. 비슷한 예로, 수행되기 직전에 머신 코드로 컴파일되는 JIT(Just In Time) 컴파일 방법도 있다.
 
같은 언어로 프로그래밍되더라도 컴파일러냐 인터프리터냐에 따라 성능과 사용성이 크게 달라진다. 일반적으로 컴파일되는 프로그래밍 언어는 두 가지 장점이 있는데, 하나는 수행 속도 향상이고 또 하나는 소스코드의 암호화(obfuscation)이다. 컴파일러가 인터프리터에 비해 같은 프로그램을 빠른 속도로 수행하게 만드는 것은 분명하다. 컴파일 시간은 런타임과 별도로 한 번만 수행되면 되기 때문에 각종 최적화(optimization) 기술을 적용하기가 유리하다. 물론 최근에는 자바 가상 머신(JVM)이 이런 컴파일러의 최적화 기술을 빌려와 동적으로 머신 코드를 생성하는 기술(adaptive compilation or HotSpot)을 도입했지만, 일부 최적화 기술은 그 특성상 많은 시간이 걸리기 때문에 같은 언어를 컴파일하여 얻어진 프로그램보다 빠를 수는 없다.
 
또 하나의 차이점은 소스코드를 얼마나 알아보기 힘들게 만들 수 있는가이다. 컴파일된 프로그램의 경우 해당 고급 언어의 특징이 거의 사라진, 기계어로 번역되어 있기 때문에 머신 코드를 바탕으로 원본 소스코드를 복원해 낼 수 있는 가능성은 거의 없다. 반면에 인터프리터되는 언어는 수행을 위해 소스코드가 건네져야 하므로, 소스코드 공개 의사가 없는 상업적인 프로젝트의 경우 해결하기 힘든 문제에 봉착할 우려가 있다.
 
필자도 프로젝트를 수행하면서 소스코드의 비밀 유지 때문에 많은 문제를 겪었다. 필자는 디지털 텔레비전을 위한 미들웨어 플랫폼을 만드는 일을 했었는데, 여기서 하드웨어와 운영체제를 바탕으로 시스템을 빌드하는 일은 C 언어로 했지만, 해당 플랫폼이 자바를 기반으로 하기 때문에 API를 자바 기반으로 작성해야 했다. 문제는 이를 배포하기 위해 바이너리를 줘야 하는데, C 언어로 컴파일된 바이너리는 문제가 없었지만 자바로 작성한 클래스를 배포할 때 문제가 생겼다.
 
자바의 경우 일단 한 번 바이트코드로 컴파일된 후에 자바 가상 머신 위에서 인터프리트되지만, 바이트코드는 가상 머신에서 동작하는 일종의 기계어임에도 불구하고 실제 기계어인 인텔이나 ARM, PowerPC 등의 어셈블리 언어에 비해서는 대부분의 자바 심볼(symbol)을 보존하고 있는 고급 언어라 할 수 있다. 시중에는 자바의 클래스 파일을 바탕으로 원래의 자바 소스코드를 복원해주는 디컴파일러(decompiler)가 많이 존재한다. 따라서 자바로 만든 프로그램을 배포할 때는 이를 컴파일하여 클래스 파일만 배포하더라도 누군가가 소스코드를 엿볼 수 있다는 불안에 시달려야 하는 것이다.
 
필자의 회사에서 시도한 첫 번째 방법은 자바 소스코드를 뒤죽박죽으로 만들어 주는 프로그램(Java Obfuscator)을 이용하는 것이었다. 이 프로그램은 원래 자바 프로그램의 의미를 훼손시키지 않고, 단순히 변수 이름과 클래스 이름을 a, b, c 등의 의미 없는 이름으로 바꾸어서 해당 프로그램을 해독하기 힘들게 만들어 준다. 그러나 이 방법도 완벽하진 않았다. 클래스와 변수 이름을 이상하게 바꿀 수는 있어도, 외부로 참조해야 하는 API의 이름을 바꿀 수는 없을 뿐더러, 비교적 제한된 애플리케이션 범주라면 숙련된 자바 프로그래머의 경우 바이트코드에서 복원된 소스코드를 읽는 것이 어렵지 않기 때문이다.
 
이 미들웨어는 결국 자바 클래스 파일을 JAR가 아닌 별도의 암호화 방법으로 압축했다. 그리고 이 클래스를 읽는 방법은 비밀에 붙인 채, C 언어로 암호화된 클래스 파일을 해석하여 원래의 클래스로 복원하여 자바 가상 머신에 로딩해 주는 방법을 사용하게 되었다. 이와 달리 일반적인 애플리케이션의 경우 인터프리팅되는 언어를 사용한 프로그램의 소스코드가 공개되지 않기를 바란다면, 이는 패키지로 만들어서 서버에서 수행한 후 결과만 웹 브라우저를 통해 알려주는 서블릿(servlet) 형태가 되어야 할 것이다.
 
결국 프로젝트에 있어서 성능이 중요하거나 소스코드 유출 방지가 높은 우선순위를 차지한다면, 인터프리터 언어가 주는 유용성, 개발의 편리성을 감안하더라도 치러야 할 대가가 크다는 사실을 알 수 있다. 따라서 특정 프로그래밍 언어를 선택하기 위해서는 해당 프로그래밍 언어의 컴파일러가 존재하는지, 혹은 인터프리터가 존재하는지를 확인해보는 것이 필요하다.
 
언어간 통합 문제
완벽한 한 가지 프로그래밍 언어는 존재하지 않는다고 말했다. 프로그래밍 언어가 가지는 각각의 특징 때문에 한 프로젝트 안에서 2~3개 이상의 프로그래밍 언어를 사용해야 할 경우는 생각보다 빈번하다. 이 경우 각각의 프로그래밍 언어가 가지는 특징도 중요하지만, 두 언어가 얼마나 유기적으로 잘 융합되어 하나의 시스템을 만들 수 있는지도 중요한 판단 기준이 된다. 대부분의 소프트웨어를 C++로 작성하고, 일부 테스트 프로그램과 간단한 유틸리티를 파이썬으로 작성했다면 언어간 통합은 큰 문제가 아닐 수도 있다. 그러나 시스템의 특성상 2가지 이상의 언어가 서로 유기적으로 얽혀서 구성되어야 하는 경우 두 언어간 통합이 원활하지 않다면 이는 프로젝트의 위기로 연결될 수도 있다.
 
필자는 프로그래밍 언어간 통합 문제로 크게 고생을 한 적이 있다. 이미 언급했듯이 필자가 참여했던 DTV용 미들웨어 프로젝트는, 셋탑 박스에 올라가는 실시간 운영체제(Real-time OS) 위에 미들웨어를 올리고 미들웨어 응용 프로그램을 위한 자바 API을 제공해야만 했다. 즉 자바 API는 자바로 작성하되, 셋탑 박스(STB)의 하드웨어 자원에 접근해야 하는 경우 C 언어를 사용할 수밖에 없었다. 또한 셋탑 박스 또한 임베디드 환경이기 때문에 메모리가 한정되어 있고, CPU 속도가 충분치 않아 자바로 수행할 경우 속도가 느린 모듈은 C 언어로 내리는 작업도 병행해야 했다.
 
자바의 경우 “한 번 작성하고 모든 곳에서 사용한다(Write Once, Run Everywhere)”는 모토에 따라 시스템 의존적인 C 언어와 통합할 이유가 없을 것 같다. 하지만 실제로 임베디드 시스템의 경우 자바를 사용하더라도 하드웨어가 제공하는 고유의 기능에 접근하기 위해서는 C 언어로 된 시스템 API를 호출해야 하기 때문에 C 언어와의 통합이 필수적인 경우가 많다. 자바도 이 필요성을 인지하고 JNI(Java Native Inter face)라고 하여, 자바 메쏘드를 C 언어로 작성할 수 있는 표준 인터페이스를 정의해 놓았다.
 
C 언어와의 통합을 위한 표준 인터페이스까지 존재하는 언어인 자바는 C 언어와 통합이 필요한 경우 이상적인 언어라고 판단할 수도 있다. 사실 다른 언어와의 인터페이스를 표준화하거나 구체적으로 명시한 언어조차 드문 상황이다 보니, 이 정도면 언어간 통합 문제를 어느 정도 해결해주고 있지 않느냐는 결론을 내릴 수도 있다. 
그러나 실제로 자바와 C를 사용하여 프로젝트를 수행한 필자의 경험에 따르면, 언어간 통합은 절대로 쉬운 일이 아니었다. 자바에서 C 언어로 작성된 라이브러리를 로드하고 이 메쏘드를 부르는 것은 물론이고, C 언어로 작성된 자바 메쏘드에서 자바 객체의 필드에 접근하고 자바 메쏘드를 호출하게 만드는 일이 결코 간단하지 않았다. JNI 자체가 프로그래머의 실수를 유도하기 쉽게 만들어진 면도 많았고, 숙련된 프로그래머조차 버그 없이 한 번에 C와 자바를 통합하는 일은 힘들었다.
 
이는 어떻게 생각해보면 당연한 일인지도 모른다. C 언어에서 자바 메쏘드를 호출하고 객체를 사용하기 위해서는 기존의 C 언어에는 존재하지 않는 개념인 클래스나 객체, 필드, 메쏘드 등 객체지향 프로그램 언어의 특징을 C 언어의 구조체(struct)나 함수 포인터(function pointer) 등을 이용해 표현해줘야 하고, 이를 이용하는 것도 자바처럼 간단하지 않다. 자바에서 지원하는 예외 처리(exception handling) 방법도 C 언어에서 일일이 특정 함수를 호출하여 확인한 후 적절히 리턴해줘야 하고, 자바의 메모리를 접근하기 위해서도 가비지 콜렉터(garbage collector)와의 연관 관계를 생각해야만 한다. 즉 자바가 가상 머신 속에 감추어둔 내부 구조가 C 언어로 건너오면서 노출되는 것이다.
 
좀 더 일반적으로 말하면 두 언어를 연결하기 위해서는 두 언어 중 하나의 언어가 다른 언어의 기능을 흉내내줘야 한다. 프로그래밍 언어가 처음 만들어질 때부터 다른 언어와의 연관 관계를 생각하지 않았다면 이런 기능을 바라는 것은 힘들 수도 있다. 이상적인 관점을 버리고 특정 언어가 최소한 C 언어와 얼마나 잘 통합될 수 있느냐만 보는 것도 현실적인 접근 방법이다. 왜냐하면 대부분의 라이브러리가 C 언어로 작성되어 있기 때문이다. 파이썬이 태생부터 다른 언어와의 접착성(glue)을 강조하며 나타났던 것도 이런 생각이 깔려 있으리라 짐작 된다.
 
이 문제를 근본적으로 접근하여 해결책을 제시한 것은 마이크로소프트(MS)였다. MS가 닷넷 플랫폼에서 강조한 내용 중에 하나가 교차 언어(cross-language) 플랫폼인데, 이 개념의 핵심은 서로 다른 언어로 작성한 모듈이나 클래스를 서로 호출하여 사용할 수 있음을 의미한다. 대표적인 예로 VB.NET으로 작성한 클래스를 아무런 수정 없이 C#에서 사용할 수 있다는 점을 들 수 있다. 물론 서로 기본형(primitive-types)과 기능이 다른 프로그래밍 언어가 아무런 제약 조건 없이 서로를 호출해 사용할 수는 없기 때문에 CLS(Common Language Specification)를 만들어 이에 부합해야만 교차 언어를 사용할 수 있다. 그러나 닷넷이 언어간 통합 문제를 어느 정도 해결한 것은 분명해 보인다.
 
비슷한 움직임으로 썬(Sun)에서도 자바 외에도 자바 바이트코드로 변환되어 실행되는 프로그래밍 언어의 표준화 작업을 시작했다. 일례로 그루비(Groovy)는 바이트코드로 변환되어 실행되는 스크립트 언어인데, 자바와 그루비 모두 바이트코드 형태로 변환되기 때문에 그루비는 자바로 짠 라이브러리와 API를 마음대로 접근하여 사용할 수 있는 특성이 있다. 언어 간의 통합 문제가 점차 더 큰 요구 사항이 된다면, 이러한 시도는 점차 확대되리라 생각한다.
 
얼마나 객체지향적인가
지난달에 기고했던 ‘프로그래밍 언어론을 배우자’에서 프로그래밍 언어의 4가지 패러다임에 대해 설명한 바가 있다. 프로그래밍 언어는 크게 지시형(procedural) 언어, 객체지향 언어, 함수형 언어, 선언형 언어로 나뉘고 각 패러다임에 따라 언어의 특징이 크게 다르다고 이야기했다. 그러나 프로젝트를 위한 프로그래밍 언어를 선정하는 시점에 오면 판단 기준은 한 가지로 집중된다. 얼마나 객체지향적인가?
 
함수형 언어나 선언형 언어는 프로그래밍 방법론에 있어서 여러 가지 가치있는 시사점을 전달해주고, 기존의 지시형 언어와 객체지향 언어에 많은 영향을 미친 것이 사실이지만, 그 자체로 함수형, 선언형 언어는 비교적 도메인에 제한적이고, 실제로 프로젝트에 사용되는 일이 드문 편이다. 결국 C와 C++로 대변되는 지시형 언어와 객체지향 언어의 사이에서 어느 지점을 택할 것인가가 가장 현실적인 문제로 남게 된다.
 
객체지향 언어의 장점은 잘 알려져 있다. 데이터의 캡슐화(encapsulation), 코드 재사용(code reuse), 상속(inheritance), 다형성(polymorphism) 등 기존의 지시형 언어가 가지지 못한 여러 장점을 선사한다. 그러나 좀 더 객체지향적일수록 프로젝트에 적합하다는 일반론은 옳지 않다. 순수 객체지향(OO)을 표방하는 언어들이 비교적 느린 수행 속도로 악명 높고, 실제로 객체지향적일 필요가 없는 코드까지 객체지향적으로 사고하도록 강요하는 경우도 있다. 간단히 몇 가지 일련의 명령을 수행하고 싶은데도, 이를 추상화하여 클래스로 만들고 객체를 생성하고 메쏘드를 호출해야 하는 것은 분명 장점만은 아니다. 또 순수 객체지향 언어일수록 비교적 수행 속도가 느리다는 단점도 안고 있다.
 
반대로 객체지향 언어의 특징 중 일부만 빌려와도 크게 생산성이 향상될 수 있는 경우도 있다. 임베디드 시스템의 경우 칩셋(chipset) 회사들이 보통 컴파일러까지 제공한다. C++나 다른 고급 언어 컴파일러도 제공하면 좋겠지만, 칩셋 회사들의 특성상 보통 C 언어 컴파일러를 제공한다. 따라서 이런 임베디드 시스템에서 프로그래밍을 한다면 할 수 없이 C 언어를 사용해야 하는 경우가 많다. 팜과 같은 초창기 임베디드 시스템의 API를 보면 프리픽스(prefix)만 달리한 수많은 함수의 나열에 기겁한 경험이 있을지도 모른다. 비슷한 기능을 하는 함수들을 묶어서 네임 스페이스만 달리 줄 수 있었어도, 이런 환경에서 프로그래밍하는 개발자의 생산성을 훨씬 높아졌을지도 모른다.
 
그 예로 비교적 성공한 OS로 평가받고 있는 스마트폰용 운영체제 시스템인 심비안(Symbian)이 있다. 심비안 OS의 API가 C++로 작성되어 있어서 기존의 C 언어 API에 비해 비교적 정리가 잘 되어 있고 개발도 용이한 편이다. 그러나 이 성공이 C++ 언어 전체의 기능 때문만은 아니다. C++의 특성 중 일부인 클래스를 이용한 네임 스페이스 분리, 예외 처리 등만 C에 추가되었어도 비슷한 효과를 얻었을 것이다.
 
객체지향과 관련하여 또 하나 언급하고 싶은 것은, 객체지향 언어의 기능 중 일부는 아직도 완전한 동의 없이 서로 다른 방법으로 구현되고 있다는 점이다. 대표적인 예가 다중 상속(multiple inheritance)이다. 다중 상속은 말도 많고 탈도 많은 기능 중 하나이다. 잘 사용하면 강력한 기능이 되기도 하지만, 코드를 복잡하고 이해하기 힘들게 만드는 주범 중에 하나이기도 하다. 자바는 C++의 다중 상속이 마음에 들지 않아 이를 인터페이스로 대체했고, 또 루비를 비롯한 일부 언어는 믹스인(mix-ins)이라는 방법을 이용하여 코드를 조합하여 사용하기도 한다. 또 일부 언어는 일반적인 상속 관계와 코드 재사용을 구분하여 코드 상속(code inheritance)을 따로 지원하기도 한다. 언어를 선택할 때 이런 논쟁적인 부분을 해당 언어에서는 어떤 접근 방법으로 해결하고 있는지를 잘 살펴보는 것도 중요하다.
 
부수적인 조건이 아닌 안정성
보통 프로그래밍 언어의 안정성(reliability)은 부수적인 요건으로 여겨졌다. 하지만 프로그래밍 언어의 안정성은 개발 속도와 버그 발생률, 디버깅의 편의성, 테스트 등에 모두 영향을 미치는 매우 중요한 요건이다. 안정성이나 테스트의 편의를 결정하는 프로그래밍 언어의 특징은 타입 시스템(type system), RTTI(Run Time Type Inspection), 가비지 컬렉션 등을 들 수 있다. C 언어는 비교적 약한 타입 시스템을 가진 언어이다. C 언어에서 데이터 형은 어떤 다른 형으로도 캐스팅될 수 있고, 이 점은 C 언어의 강력한 장점이자 가장 큰 문제점이기도 하다. C 언어 타입 시스템의 약점은 개발 후반에 재앙으로 나타날 수 있는데, 이는 해결하기 힘든 버그 중에 하나이다.
 
임베디드 시스템 개발에 C 언어를 사용하는 예를 들어보자. 이 경우 C는 최선의 대안임이 분명하지만, C 언어의 특징 때문에 여러 가지 문제가 일어난다. C 언어에서 가장 흔히 하는 실수는 배열의 인덱스가 잘못되어 잘못된 메모리에 값을 쓰는 경우, 포인터 연산이 잘못되어 잘못된 메모리의 값을 읽거나 쓰는 경우다. 임베디드 시스템이 사용하는 OS는 대부분 메모리 공간이 하나로, 커널과 유저 모드의 구분이 없다. 즉 잘못된 메모리에 접근하더라도 세그먼테이션 폴트(segmentation fault)가 나지 않는다. 즉 커널 영역의 메모리 주소에 잘못된 포인터 연산으로 특정 값을 쓰더라도 그 시점에는 아무런 문제없이 넘어간다. 문제는 그렇게 바뀐 메모리 주소를 나중에 읽으려고 할 때 잘못된 값을 읽어 와서 프로그램이 이상 동작할 경우이다. 이 경우 문제 시점과 원인의 발생 시점이 다르기 때문에 그 원인을 파악하는 게 사실상 거의 불가능해 진다.
 
만약 C 언어가 아니라 자바처럼 메모리 포인터가 없고, 배열의 경우 항상 배열의 경계값 검사를 해주는 프로그래밍 언어를 사용했다면 저런 문제는 절대 발생할 수 없었을 것이다. 즉 프로그래밍 언어의 타입 시스템에 따라 어떤 종류의 프로그램 버그는 원천 봉쇄할 수도 있다는 이야기다. 이러한 점은 프로그래밍 언어를 선택할 때 반드시 고려해야 한다.
 
리플렉션(reflection)이라 불리는 언어의 기능은 테스트 프레임워크를 만드는데 많은 도움을 준다. 리플렉션은 런타임에 프로그래밍 언어의 타입을 동적으로 조사하고 이를 호출하여 사용할 수 있는 기능을 말한다. 즉 프로그램이 동작 중에 어떤 데이터 타입이 있는지 확인한 후에, 해당 메쏘드를 무작위로 불러보는 일이 가능해진다. 이 기능은 보통 자바로 작성된 API의 경우, API가 표준에 맞는 클래스 이름과 메쏘드 이름, 그리고 인자들을 가지고 있는지 동적으로 확인한다. 또 해당 시스템의 API를 무작위로 호출하여 시스템의 안정성을 테스트할 때 사용된다.
 
언어의 런타임이 가비지 컬렉션을 지원하느냐의 여부도 넓게 봐서 언어의 안정성에 포함된다. malloc/ free나 new/delete를 사용하는 프로그래밍 언어는 대부분 자원 관리를 적절히 하기 위해 엄청난 노력이 소요된다. malloc한 메모리는 반드시 어느 시점에서인가 free해줘야 하는데, 이를 여러 조건에 빠짐없이 처리해주는 것만으로 시스템의 복잡도가 상당히 올라감을 알 수 있다. 이를 실수하면 곧바로 메모리 누수(memory leak)로 이어지기 때문에 여간 신경쓰이는 일이 아니다. 가비지 컬렉션을 지원한다면 프로그래머를 이러한 자원 관리 문제에서 어느 정도 해방시키기 때문에 생산성이 향상되고, 자원 관리 문제로 인한 버그를 예방할 수 있는 장점이 있다.
 
얼마나 많은 라이브러리가 표준화되어 있나
프로그래밍 언어를 선택함에 있어서 가장 중요한 부분은 어쩌면 그 언어의 사용을 도와주는 얼마나 많은 지원이 있느냐 일지도 모른다. 여기서 지원은 각종 프로그래밍 언어 서적, 웹 사이트, 그 프로그래밍 언어를 사용하는 사람들의 숫자, 전문가, 바로 사용할 수 있는 라이브러리 등이다.
 
프로그래밍 언어도 네트워크와 마찬가지(network effect)로 사용하는 사람이 많을수록 그 언어를 사용하는 모든 사람이 이득을 얻는 특징이 있다. 사람들은 전문적인 지원이 없으면 그 언어의 선택을 꺼리는 경향이 있고 더 많은 사람들이 사용하는 언어를 선택하는 경향이 강하다. 컴퓨터 산업이 어느 정도 성숙되고 나서 상업적으로 성공한 언어가 대부분 MS나 썬과 같이 대기업의 전폭적인 지원이 있었다는 사실도 이를 보여준다. 수많은 책을 펴내고 그 언어의 사용을 장려하기 위해 여러 프로모션 정책을 펴는 것이 프로그래밍 언어의 성공에 있어서 생각보다 중요한 요소인 것이다.
 
이런 지원 중에서 가장 중요한 요소는 사용 가능한 라이브러리가 얼마나 많이 있느냐다. 자바의 성공은 자바 프로그래밍 언어의 특징에도 있었지만, 또 하나의 요소는 바로 사용 가능한(out-of-the-box) 표준 라이브러리가 언어의 런타임과 함께 배포되었다는 점이다. 프로그래밍 언어의 이러한 특징으로 인해 개발 작업은 새로운 것을 만들어내는 일에서 이미 작성된 라이브러리를 최대한 잘 활용하며 어떻게 조합하느냐로 바뀌었을 정도다. 이러한 변화를 잘 반영하는 말이 있다. 흔히 자바 프로그래밍을 처음 시작하는 사람에게 해주는 충고로 “어디에 있는지를 알아라!(Know Where)”라는 이야기를 많이 한다. 과거 프로그래밍은 언어의 기본적인 기능만으로 모든 것을 만들어 써야 하던 ‘Know What, Know How’의 시대였다면 현재의 프로그래밍은 자신이 사용하고자 하는 기능이 어떤 클래스에 어떻게 구현되어 있는지를 알고 이를 재빨리 찾아서 사용하는 것으로 바뀌었다. 따라서 얼마나 다양하고 많은 라이브러리를 제공하느냐는 프로그래밍 언어의 성패를 정하게 되었다.
 
여기서 주목해야 할 것은 단순히 얼마나 많은 라이브러리가 있느냐가 아니라 얼마나 많은 라이브러리가 표준화(standard library)되어 있느냐다. 사실 C 언어의 경우 정말 엄청난 양의 라이브러리가 존재하고, 상당수가 오픈소스로 존재하지만 서로 다른 컨벤션(convention)과 스타일을 사용하는 라이브러리를 자신의 구미에 맞게 요리하여 사용하기란 쉬운 일이 아니다. 남의 코드를 가져다 쓴다는 게 얼마나 어려운 일인지는 조그마한 라이브러리를 가져오려고 시도해 본 적이 있는 사람은 모두 공감할 것이다.
 
결국 프로그래밍 언어 자체가 이미 표준화된 라이브러리를 매우 풍부하게 제공하여 대부분의 기능한 제3자를 통하지 않고서도 직접 프로그래밍할 수 있는 환경을 만들어 주는 것이 중요하다. MS와 썬은 이미 이런 방향으로 자신들의 언어를 개발하고 있고 많은 성공을 거두었다. 우리가 프로젝트에서 어떤 언어를 선택한다면 그 언어의 특징은 물론 그 언어의 표준 라이브러리가 얼마나 잘 정리되었는지도 반드시 고려해야 할 것이다.
 
절대 기준은 없다
앞에서 프로그래밍 언어의 선택 기준을 몇 가지 언급했지만, 사실 프로그래밍 언어를 선택하는 절대적인 기준이란 없다. 바꿔 말하면 거의 모든 요소를 고려해도 부족하다는 말이 될 수도 있다. 언어의 특징을 규정짓는 요소들, 예컨대 가독성, 이식성(portability) 등도 모두 언어를 선택할 때 고려해야 할 요소들이고 각각의 생산성에 어떤 식으로든 영향을 미친다. 중요한 점은 프로젝트 시작에 앞서 몇 가지 선택된 기준을 바탕으로 몇 개의 프로그래밍 언어를 평가한 후에 프로젝트 언어를 결정하는 신중함을 가지라는 점이다. 프로젝트 초반의 시간 절약은 나중에 더욱 큰 화살이 되어 돌아올 수 있음을 항상 명심해야 한다.  
 

- System Board
System Board는 모든 전자기기의 기본 Frame으로 각 구성요소들을 적절히 연결시켜주거나 결선, 고정, Self Error Check 등의 기능을 담당한다.

- Tuner
DTV Set-top의 튜너는 기존 Analog와 유사한 역할을 담당한다. 위성이나 지상파 혹은 케이블에서 들어오는 신호(Video , Audio , Data)를 '수신"하여Demodulator(혹은 Modulator)에 전달하는 역할을 담당한다.

- Demodulator
Analog 신호를 샘플링하고 디지털 Bit Stream으로 변환시키는 역할

- Demultiplexer & Decryptor
Demodulator를 거쳐나온 Mpeg-2 stream 은 PID(Packet ID)로 구성되고 구별되는데 Demultiplexer 에서는 PID를 기준으로 Audio, Video, Data를 풀어디코더에 건네준다. 
상업상의 이유로 암호화된 Stream인 경우(유료채널 등)에 암호를 해독하여 전달하는 루틴이 필요하고, 이 역할은 decryptor에서 담당하게 된다. 물론 표준화된 Decryptor규격은 없는 실정이다.

- Decoder
Demodulator와 Demultiplexer를 거쳐 나온 Video / Audio 신호들은 실제로 시청자가 들을 수 있는 신호로 풀어줘야 하는데 , Decorder가 그 역할을 담당, 최종적으로 TV 및 스피커로 Output을 보낸다.

- CPU and Memory
CPU는 Realtime OS , HDD, GPU , System Board 등 Set-top 내의 각 요소들을 통제하고 관리하는 주된 역할을 담당하며 웹서비스 요청 및 응답, E-mail 수신등의 Data Processing 부분을 담당하고, 메모리는 CPU의 연산과정에 필요한 부분과 , 임시로 저장해둬야 하는 내부데이터 등의 저장소로써, 보다 빠른 연산이 요구될수록 물론 많은 메모리가 필요하다.
Set-top Box에서 사용되는 메모리의 종류로는 소프트웨어적인 업그레이드 등에 사용되는 Flash 메모리, 
임시저장소인 RAM , 커널 혹은 I/O system이 로드되는EEPROM 등이 있다.

- GPU
초기모델과 달리 특별히 부각되어지는 부분이 GPU인데, 가령 수신된 데이터를TV화면에 Overlay 처리해야 할 경우라든가, 웹페이지를 TV화면에 디스플레이 하기 위해 그래픽처리의 중요성이 늘기 때문에 점차 고사양화 되고 있는 추세.

- Storage Device
ReplayTV나 디지털스트림의 DStream 2000 Set-top Box 과 같은 2세대 Set-top 들에 적용된 기능 중 DVR (Digital Video Recording)기능은 , 용량대비 저렴한 비용의 HDD와 같은 저장장치를 이용해 TV영상을 저장하게끔 한다. 원하는 방송을 자유롭게 녹화, 재생하는 것이 가능하다는 점 이외에도 사용자의 신용정보나 Wallet정보등 매번 입력되어야 하는 정보들을 저장하기에 용이하다는 특징이 있다. 
부가적인 보조기록장치로는 ZIP / JAZZ , SmartCard 등도 활발하게 시도되고 있다.

- Physical Interface
RS232C , IDE , PCMCIA , SCSI, IrDA , SmartCard 등 Set-top Box와 외부기기들을 연결시키기 위해서 , 혹은 내부기기들의 Data 교환을 위한 인터페이스 등, 물리적으로 연결지어줄 각종인터페이스 역시 빼 놓을 수 없는 구성요소.

- Real Time OS
하드웨어적인 모든 구성요소가 갖춰젔다면 , 실제 Set-Top 박스의 각 요소들을 구동시키고 제어하며, 시청자(운영자)와의 입출력을 처리할 소프트웨어가 있어야 하는데, Operating System 이 그것. Set-top Box의 OS는 우리가 일반적으로 사용하는 Desktop PC와 비슷하지만 그 목적에서 달라야 한다. 
Set-top Box OS는 각 하드웨어 구성요소를 제어해야 하고 , Real Time 스케줄링, 제한된 메모리 자원의 관리 , 인터넷서비스의 전송 등 Set-top Fuction 등을 관리하는 기능들이 위주가 되어야 한다. 
물론 OS의 커널(kernel)은 그 크기가 작고 빠르게 반응해야 하고 안정적으로 동작해야 함은 물론이다. 
API의 제공역시 중요한 부분. 소프트웨어 개발자들에게 일관된 개발환경을 제공하는 목적 이외에도 , OS차원으로 볼때 PC와는 달리 Set-top Box OS의 경우엔사용자와 메시지창으로 '대화'하는 부분이 거의 없게 마련이므로 탄탄한 프로그래밍 환경도 중요하다. 이미 출시된 Real Time OS 종류에는 PowerTV OS , VxWorks , pSOSystem , Microware's DAVID OS-9 , Microsoft's Windows CE ,JavaOS , Linux 등 다양한 제품군들이 있다.

- Middleware
기본적인 H/W 입출력 담당 및 제어 등이 Set-Top OS의 특징이라면, 언제나 다양한 종류의 A/V, Data등을 처리하고 , 다양한 종류의 사용자지원 서비스등을 일괄적으로 지원하기 위한 중간 역할은 Middle Ware에서 담당하게 된다. 사실 많은수의 Set-top Box제조사들이 각자 고유의 H/W Platform과 각사의 개발환경에 맞는 OS등을 채택하고 있기 때문에 , 통합 S/W 표준을 잡기가 모호하다. 이러한 추세에 발맞춰 Open Architecture 지향의 중간운용 소프트웨어가 발표되기 시작하였는데 이들 Middle Ware들의 공통지향 운영범위는 HTML Machine , Java Virtual Machine , Script Interpreter 등이며, 대부분의 Set-top Box 에서 표준적으로 지원되어야 할 범위를 담고있는 일종의 레이어 역할을 하게 된다. 
Microsoft's TV PAK, OpenTV, Media Highway, eNavigator, PowerT ,PlanetTV 등의 제품군들이 이미 시장에 출시되어 있으며 점차 적용되어가고 있다.

- API(Application Program Interface)
H/W , OS , Middle Ware 까지 구성되었다면 이제 실제로 Set-Top에서 구동될 특화된 어플리케이션을 제작 혹은 이용하는 부분에는 API에 입각해 개발, 운용 되어지는데 . OS에 따라 , Middle Ware에 따라 어떠한 API를 지원하는지 틀려진다. 어떤 API 를 제공하는가 하는점 역시 H/W적인 완성도 못지 않게 중요하고, 보다 많은 컨텐트를 쉽게 개발되어지게끔 하는 중요한 요소의 하나이다. 
주요 API로는 JavaTV API, MHP(Multimedia Hardware Platform) API등이 있다

다음의 그림을 통해 다시 한번 프로그램의 컴파일과정을 이해해 보겠습니다.

<프로그램 컴파일 과정>

기억나실 듯 합니다.

우선 프로그램 소스코드를 작성하고(물론 개발도구 프로그램과, 프로그래밍 언어를 가지고...)나서,

컴파일을 하게 되면 실행가능한 프로그램이 생성이 된다고 말씀드렸습니다.

이러한 프로그램을 목적 프로그램이라고도 하지만, 컴퓨터 하드웨어(CPU)가 알아 들을 수 기계어로 번역되었다는 의미에서 바이너리 파일이라고도 합니다.

여기서 눈여겨 보셔야 할 부분이 푸른 색 화살표로 표시된, 번역과 실행의 부분입니다.

컴파일은 번역과 실행이 따로 되기 때문입니다.

자 그럼,

오늘 처음 배우게 되는 인터프리팅 언어에 대해 알아보도록 하겠습니다.

역시 그림을 참조해보겠습니다.

위의 컴파일 과정과 그림 상의 차이를 알아보시겠죠?

일단, 인터프리팅은 프로그램 소스코드가 목적프로그램, 또는 바이너리 파일로 변환되는 번역과정이 일어나지 않는다는 것입니다.

프로그램 소스코드가 바로 한줄한줄 실행되어 기계어로 미리 번역되어서 저장(바이너리 파일)되는 절차가 생략되어 있는 것입니다.

컴파일이든, 인터프리팅이든 둘 다 모두 번역(기계어로 번역)이라는 단계는 무조건 거쳐야만 합니다.

그래야 컴퓨터 하드웨어가 무슨 말인지 알아들을 수 있기 때문입니다.

프로그래밍 언어를 분류하는 또다른(이전에는 주된 적용분야에 따라 구분했던 것 기억나시죠?) 중요한 기준 중의 하나가 바로 이 번역방식에 따른 구분입니다.

현재 현장에서 사용하는 프로그래밍 언어는 대부분 컴파일 언어들이기는 하지만, 인터프리팅 언어 또한 만만치 않게 사용되고 있으며,

웹 프로그래밍 분야의 경우는 컴파일 언어보다는 오히려 인터프리팅 언어가 더욱 활발하게 쓰이는 경우가 많이 있습니다.

우선, 컴파일 언어의 대표적인 예는, 그 동안 우리가 자주 들어왔던

C, C++, JAVA, C# 등등이 있습니다.

그리고, 인터프리팅 언어는 주로 스크립트(Script)와 마크업(Mark-Up)이라고 불리우는 언어들을 지칭하는 것으로

자바스크립트(Javascript), 액션스크립트(ActionScript), VB스크립트, SQL, HTML 등등이 있습니다.

일반적으로 컴파일 언어가 구현할 수 있는 프로그램의 기능이 월등이 많다고 보시면 될것 같습니다.

대부분의 인터프리팅 언어들은 특수한 목적을 위해 태어난 언어들이기 때문에,

사용하는 용도가 무척 제한적입니다.

자바스크립트 언어의 예를 들면, 우리가 거의 매일 보다시피 하는 홈페이지를 좀더 풍부한 기능으로 만들어 주는 역할을 주로 하는데 사용됩니다.

물론 극히 일부분 다른 용도로 사용되고는 있지만, 원래 태생 자체가 홈페이지 제작용이라는 한정적이고, 특수한 용도로 태어난 언어이기 때문입니다.

(JAVA 언어와, Javascript가 이름이 비슷하다고 혼동해서는 안됩니다. 이 둘은 각각 다른 기업에서 만든 언어일 뿐만 아니라, 그 용도와 탄생배경까지 모두 전혀다른 별개의 언어들입니다.)

또한 인터프리팅 언어의 또 다른 한 종류인 SQL 언어의 경우 관계형 데이터베이스 시스템(Relational DataBase System)이라는 대용량 데이터 저장 시스템에 저장되어있는 데이터를 검색하고, 관리하기 위해 사용되는 프로그래밍 언어로서 오로지 단 한가지의 목적을 위해 만들어낸 프로그래밍 언어입니다.

이렇듯이, 인터프리팅 언어들의 특징은 매우 한정적이고, 제한적인 사용용도를 가지고 있기 때문에

한때는 컴파일 언어만을 사용하여 프로그램을 개발하는 프로그래머들에게 조금은 무시당하는 경향이 있는 언어들이었으나,

현재에는 필요에 따라 반드시 익혀야 하는 언어임에는 분명한 듯 합니다.

(현재 기업에서 사용하는 업무용 프로그램 수요의 약 80% 정도가 관계형 데이터베이스 시스템을 사용하여 제작되고 있습니다. 당연히 SQL 언어는 어떠한 프로그래머이든 필수적으로 알아야 하는 인터프리팅 언어가 되어가고 있습니다)

번역되는 과정에 프로그래머가 할일은 없다!

지금까지 프로그래밍 언어를 기계어로 번역하는 과정에 따라 컴파일 언어와 인터프리팅 언어로 구별하여 설명을 드렸습니다.

복잡하게 설명은 드렸지만, 이는 사실 프로그래머인 여러분들이 신경을 쓸일은 거의 없을 것 같습니다.

왜냐하면,

컴파일 방식 언어이든, 인터프리팅 방식 언어이든 번역은 여러분들의 몫이 아니라, 별도의 컴파일러, 인터프리터라는 이름의 프로그램이 알아서 처리해주기 때문입니다.

프로그래머가 할일은 결국 여러분이 작성하게 될 프로그래밍 언어를 익히는 것과,

소스코드를 작성할 개발도구 프로그램의 사용법을 익히는 것.. 그리고,

컴파일러와 인터프리터 프로그램을 개발도구가 설치된 컴퓨터에 같이 설치해주는 것 정도입니다.

사실, 프로그램 소스코드 작성은 여러분들의 윈도우 운영체제에 있는 '메모장 프로그램'으로도 가능합니다.

어떤 측면에서는 메모장 프로그램은 매우 효율적인 개발도구 프로그램일 수 있기 때문입니다.

그런 의미에서, 지금부터 정말 간단한 프로그램을 하나 작성해볼까요?

다음의 순서를 따라 한번 해보세요.

1. 메모장 프로그램을 실행한다.

2. 다음의 프로그램을 직접 메모장에 적는다.(영문 대소문자 틀리지 않게 잘 써주세요~)

<script language="javascript">

    document.write("이순신 장군은 13척의 배로, 일본적선 333척을 물리쳤다")

</script>

3. 모두 작성했으면, 바탕화면이든 어떤 폴더이든 저장한다.

   저장할 때의 파일이름은 MyFirstProgram.html로 한다.

   저장할 때 주의사항은 파일의 확장자가 .txt라고 되어서는 안된다는 것이다. 반드시 주의!

4. 저장한 폴더에 가서 MyFirstProgram.html 파일을 더블클릭해서 실행한다.

5. 결과를 확인한다.

혹시 위의 파일을 더블클릭 했을때 인터넷 익스플로러가 실행되면서 "... 사용자의 컴퓨터에 액세스 할 수 있는 스크립트나 ActiveX... "라는 메시지가 화면 상단에 나타나면 이를 클릭해서 [차단된 컨텐츠를 허용]을 다시 클릭해주면 됩니다.

그러면 인터넷 익스플로러에 '이순신 장군은 13척의 배로, 일본적선 333척을 물리쳤다'라는 글자가 선명하게 출력되는 홈페이지를 하나 보여줄 것입니다.

아래의 화면입니다.

자, 어떻습니다.

여러분이 작성했던 프로그래밍 코드는 어딜가고, 화면에 글자만 출력되고 있는 것이 확인되시죠?

바로 여러분의 소스코드는 해석과 번역과정을 거쳐 사라져 버리고 프로그래머인 여러분들이 내린 명령(document.write라는 명령)에 따라 화면에 글자를 찍어주는 행동을 취해서 보여준 것입니다.

여러분이 작성한 소스코드는 자바스크립트 언어이며, 개발도구 프로그램은 메모장이었습니다.

그럼 인터프리터 프로그램은 어디있냐구요?

^^

자바스크립트 언어를 번역하는데 필요한 인터프리터는 별도로 설치해줄 필요없이 인터넷 익스플로러에 내장되어 있기 때문에 여러분은 전혀 신경을 쓸 필요가 없었습니다.

이렇게 프로그래밍이라는 것이 어찌보면, 원리만 깨달을 수 있다면 어떤 언어이든 그리 어렵지 않게 접근할 수 있다는 것입니다.

컴포넌트 비디오(component video)는 두 개 이상의 컴포넌트로 나뉘는 영상 신호를 말한다. 일반적으로는 세 개의 구분된 신호로 전달하거나 저장되는 아날로그 영상 정보의 일종을 가리킨다. 컴포넌트 비디오는 모든 영상 정보를 선 하나에 합치는 컴포지트 비디오(NTSC,PAL, SECAM)와 대비된다. 케이블 단자의 모양은 컴포지트와 동일하며, 컴포지트 비디오와 비슷하게 컴포넌트 비디오 케이블은 오디오를 전달하지 않는다. 480i, 480p, 576i, 576p,720p, 1080i, 1080p의 해상도를 지원한다.

여러 가지 아날로그 영상 표준 중 컴포넌트 비디오가 가장 효과적으로 컬러를 재생성할 수 있으며, 그 이유는 사진에서 볼 수 있듯이 컴포지트 비디오나 S-비디오와 다르게 세가지 신호를 각각 분리시켜 놓아서 간섭잡음의 영향을 줄일 수 있기 때문이다.^[1]

컴포지트 비디오(Composite Video)는 아날로그 텔레비전 신호의 형식(음성 제외)으로, 음성 신호와 합쳐져서 RF 반송파상에 변조되기 전의 신호이다. 이것은 NTSC, PAL, SECAM 등의 방송 표준에 포함된 형식이다. 컴포지트 비디오는 Y, U, V(합쳐서 YUV라고 한다)라는 세 개의 소스 신호를 동기화를 위한 싱크 펄스(sync pulse)와 합친(composite) 것이다.

여기서 Y는 영상의 밝기 혹은 휘도(luminance) 성분을 나타내며, 싱크 펄스를 포함한다. 따라서 Y 신호만으로도 흑백 영상을 디스플레이할 수 있다. U와 V 신호는 색상 정보를 나타내며, 색상 반송파 신호의 두 개의 직교 위상과 혼합되어 색차(crominance) 신호를 형성한다. 이후에 Y 신호와 UV 신호가 합져진다. Y는 기저 대역 신호이고 UV는 반송파에 실린 신호이기 때문에 이렇게 합쳐진 컴포지트 비디오 신호는 주파수 분할 다중 방식(WDM: wavelength-division multiplexing)에 해당한다.