토끼와 거북이

나도 Google Docs를 꽤나 유용하게 사용하고 있지만, 종종 구글 닥스에 대한 조금은 황당한 이야기를 들을 수 있다. 바로 구글 닥스와 데스탑 기반의 오피스 (대표적으로 MS Office)를 비교하는 대목이다. 물론, 웹 기반이라는 점, 그리고 공유가 쉽다는 점은 뛰어나나 저 둘은 직접적인 비교 대상이 전혀 아니다. 도메인 자체가 완전히 다른 어플리케이션인데 이상하게 비교 하려는 사람들이 많다. 그러고서는 미래에는 웹 어플리케이션이 지금의 데스크탑 어플리케이션을 대체하고 운영체제도 궁극적으로 웹 기반으로 진화해 기존의 운영체제를 대체할 것이라고 주장을 편다.

좀 심하게 말하면 헛소리다. 가까운 미래에 웹 어플리케이션이 지금의 데스크탑 프로그램 수준으로 작동할 수는 있을 것이다. 그러나 그 때 가면 데스크탑 프로그램은 지금보다 훨씬 더 많은 일을 더 빠르게 할 수 있다. 그리고, 그런 기능을 필요로 하는 수요는 여전히 있다. 웹 어플리케이션은 여전히 데스크탑에 비해 제한적인 성능을 가질 수 밖에 없다. 마치 이것은 토끼와 거북이 경주와 같다. 아무리 거북이가 열심히 달려도 토끼를 따라 잡기는 힘들다.

데스크탑 어플리케이션과 웹 어플리케이션은 서로 경쟁하면서 어느 한쪽을 잡아 먹는 것이 아니라 독립적으로 발전해나갈 대상이다. 워낙 구글하고 마이크로소프트를 싸움 붙이기 좋아하는 사람들이 많아서 그런지 전혀 비교할 것도 아닌 것을 비교하고 있다. 이런 예는 곳곳에서 찾아볼 수 있다.


1. 자바 vs C/C++

정확히 10년 전, 대학교 1학년 때, 자바가 뜨고 있었다. 그러나 엄청난 속도(!)로 인해 나는 고개를 설레설레 저었다 (데스크탑 자바 응용프로그램으로 한정 지어 생각하자). 그러나 자바 옹호론자들은 곧 빠른 CPU가 등장하면 자바의 속도 문제는 별 문제가 되지 않을 것이라고 호언장담하였다. 그러나 10년 뒤, 지금을 보자. 맞다. 예전에 비해 자바 응용 프로그램의 속도는 비약적으로 빨라졌다. 그러나 그 사이 C/C++로 작성 된 프로그램도 엄청나게 빨라졌다. 여전히 자바로 짜여진 프로그램은 C/C++ 프로그램보다 느리다. 그리고 자바 프로그램은 앞으로도 계속 C/C++ 프로그램보다 느릴 것이다. 정말 혁신적으로 자바 바이트 코드를 바로 처리하는 CPU가 나오지 않는 이상, 이 둘의 속도 차는 쉽사리 줄어들지 않을 것이다.

이러한 논리는 C#과 .NET에도 적용이 가능하다. MS가 그렇게 .NET 프레임웍으로의 이전을 설교했지만 여전히 0.001초의 성능이라도 더 높여야 하는 프로그램들은 Native C/C++로 작성할 수 밖에 없다. 결국 MS도 이런 요구를 무시할 수 없고, 다음 버전의 Visual Studio에서는 Native C/C++ 및 MFC에 대한 지원을 강화하였다.

그러니까 C, C++, C#, Java는 모두 각기 다른 성격을 가지고 있고 각자만의 강점이 있으므로 그것을 존중해주면 된다.


2. 멀티미디어

멀티미디어 분야를 보면 정말 토끼와 거북이가 생각날 수 밖에 없다. 2000년, 처음으로 디빅이라는 동영상을 보았다. 정말 감탄 그 자체였다. 무려 4기가가 넘는 DVD 영화를 700MB CD 두 장 분량으로 압축하여 보는 것이었다. 그 당시에는 디빅이 제대로 재생되는 컴퓨터만 있어도 좋다고 생각 많이 했다. 그리고 이제 Core 2 Duo 같은 CPU가 보편화된 지금, 디빅 정도는 식은 죽 먹기로 재생이 가능하다. 그러나 사람들의 욕구는 디빅에 머무르지 않았다. 어제 Transformers HD-DVD 버전을 구해서 보았다. 동영상의 해상도는 1920x1080 풀 HD이고, 압축이 되었음에도 불구 무려 24기가, DVD 6장 분량이었다! 지금 내 컴퓨터로도 살짝 버벅인다. 내년에 쿼드 코어가 나오고 더 빠른 CPU가 나오면 지금 풀 HD 동영상의 재생이 용이해질 것이다. 그러나 그 때 가면 사람들은 그 보다 더 높은 사양의 멀티미디어를 요구하고 여전히 하드웨어는 힘겹게 돌아갈 것이다.


3. 주기억장치 vs 하드디스크

주기억장치의 종말: http://mbastory.tistory.com/290

결코 이 글을 비난하려는 뜻은 아니다. 나도 저런 생각을 많이 했다. 하드디스크가 DRAM 수준으로 빨라지면 얼마나 좋을까라고. 부팅은 정말 5초 안에 될 것이고 하드 버벅임도 없고 무소음 시스템도 만들 수 있을 것이다.

가까운 미래에 하드디스크가 지금의 DRAM 수준으로 빨라지면 정말 주기억 장치를 대체할 수도 있을 것이다. 그러나 이 경우도 위에서 예로 든 경우와 똑같다. 미래에 가면 CPU는 지금보다 더 빨라져 있을 것이고, 주기억 장치에 사용되는 DRAM 역시 많이 빨라져 있을 것이다. 따라서 여전히 하드디스크는 (비록 지금의 DRAM 수준으로 빨라졌다 하더라도) 가장 느린 녀석이 될 것이고, CPU Register – L1 Cache – L2 Cache – DRAM – Hard Disk – Network로 이어지는 Memory Hierarchy는 여전히 유효하다 (물론, 천년 만년 지속된다는 소리는 아니고). 아무리 하드 디스크가 빨라져도 DRAM을 뛰어넘어 그것을 대체하는 것은 쉽지 않다. DRAM도 계속 발전하고 있기 때문이다.


한 줄 요약: 토끼는 잠만 자고 있지 않다.

by object | 2007/11/01 06:30 | 컴퓨터 | 트랙백(2) | 덧글(18)
트랙백 주소 : http://minjang.egloos.com/tb/1565248
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Tracked from 세상을 보는 또 다른 시선 at 2007/11/01 10:59

제목 : 주기억장치의 종말
요즘 IT 기술발전을 보면 정말 대단하다는 생각이 듭니다. 1960년대에 컴퓨터라는 것이 처음 생긴 이래 다른 분야에서는 상상조차 할 수 없는 엄청난 속도로 IT 분야가 발전을 계속해 오고 있는데, 이러한 변화의 흐름을 쫓아가다 보니 앞으로 몇 년 안에 큰 변화가 일어날 것이라고 예상이 됩니다. 제 생각엔 그런 변화들 중에서 현재 쓰고 컴퓨터에서 가장 먼저 변화가 일어날 분야가 바로 주기억장치가 아닐까 생각합니다. 주기억장치는 컴퓨터가 발전해 ......more

Tracked from kkamagui의 프로.. at 2007/11/01 18:39

제목 : [잡담] 약간 성격이 다른 A와 B를 비교하는 상당..
원문 : 토끼와 거북이오늘도 어김없이 RSS를 돌다가 상당히 공감이 가는 글을 봐서 한자 남긴다.나도 그렇지만, 습관적으로 A와 B를 비교하고 평가를 내리고 나름대로 결론을 내리는 습관을 가진 프로그래머가 많은데... 이 글을 읽다보니, 문득 그동안 비교했던 것이 서로의 "목적" 또는 "성격"을 고려하지 않고 단순히 그 "기능" 또는 "역할" 에만 초점을 맞추어 비교한 것이 아닌지 반성하게 되었다.끄응... 앞으로는 좀더 신중하게 생각......more

Commented by 상희스타일 at 2007/11/01 08:49
3번은 저도 공감합니다. 가격때문이라도 세개(CPU-주기억장치-보조기억장치(HDD든 뭐든))로 시스템을 만들 수 밖에 없을 것 같습니다. 자바 이야기도 공감이 가네요. ㅎ 사람들은 빠른걸 원하니까요. 웹사이트들이 0.1초라도 사이트를 빨리 뜨게 하려고 별짓을 다 하는것이나 사람들이 3초 안에 웹사이트가 안뜨면 refresh 버튼을 누르는 것을 보면 알 수 있지요. 오늘도 좋은 글이시네~
Commented by havien at 2007/11/01 09:09
저도 가끔씩 하던 생각들인데, 잘보고 갑니다~
Commented by Lohengrin at 2007/11/01 09:19
1. 다 그런지는 모르겠지만 주변을 보면 UI는 C#으로 핵심 엔진 류는 C/C++ 혹은 ASM으로 짜는 경우가 많이 보입니다.

2. 블루레이 소스 재 압축 안 한 영상을 플레이 해 봤는데 Core 2 Duo(6700이긴 합니다만)에서 넉넉하게 가능하더군요. VC-1 퍼포먼스는 측정해 본 적이 없어서 잘 모르겠습니다만 요즘은 GPU가 지원해 주는 추세라서 뭐 어떻게든 되는듯. 그보다 코덱의 멀티코어 지원 여부가 더 중요할듯 합니다. 1080P 영상 이후는 방송용으로 울트라 어쩌고인가를 준비하고 있긴 한데 언제 나올지는 상당히 미지수;

3. 대용량 기억장치가 RAM보다 빨라지는 일은 없을거라 봅니다; DDR2에서 초당 2기가의 데이터 전송률을 보였던 걸로 기억하는데 초당 100mb도 안 나오는 디스크들이;;
Commented by kc at 2007/11/01 09:33
위의 얘기 모두 공감합니다. 특히 3번 문제는 컴퓨터 시스템에 왜 DRAM이 들어 있어야 하는 지를 잠깐 망각한 것이 아닌가라고 생각됩니다. HDD 같은 보조 기억 장치는 바로 메모리 맵핑이 불가능하잖아요. 즉 랜덤 억세스가 불가능하다는 것입니다. 이게 제일 중요한 것인데... ^^
Commented by 5throck at 2007/11/01 10:58
제 글에 조금 오해가 있으신 것 같아서 댓글을 답니다. 하드디스크가 주기억장치를 대체한다는 것으로 이해를 하시는 것보다 주기억장치와 보조기억장치가 메모리를 이용한 기억장치로 변환된다는 것으로 이해를 하시는 것이 더 맞을 것 같습니다. 대신 지금의 하드디스크는 백업용 장비로 그 위상을 변화하게 될 것 같습니다.
Commented by object at 2007/11/01 11:23
네. 저도 5throck님의 큰 그림은 잘 알겠습니다. 컴퓨터 구조 책 펴들고 하나하나 따지면 좀 틀린 점이 있다는 것이지 큰 그림은 누구나 그렇게 생각할 수 있습니다.

Lohengrin님 말씀이 정답이네요. GUI는 WPF나 C#으로 빠르고 화려하게 만들고 핵심 엔진은 그렇게 짜면 되겠네요. 블루레이 소스를 재 압축하지 않았다면 아주 잘 돌아갑니다. 제가 받은 파일들은 보통 .ts, .mkv인데 이건 압축을 빡시게 한 것이라 훨씬 힘들죠. DVD 비디오도 mpeg2라서 돌리기 쉽지만 디빅은 그것보다는 훨씬 많은 계산을 요구하죠.

램이 필요한 것은 kc님 말씀대로 random access 때문이죠.

마지막으로... 비슷한 이야기 또 할 수 있어요. 우분투 7.10이 정말 편해지긴 했는데 여전히 윈도우에 비하면 불편해요 :) 우분투가 편해질 동안 윈도우도 많이 편해졌거든요.
Commented by Lohengrin at 2007/11/01 11:47
아 물론 블루레이도 .ts에 H264로 압축되어 있습니다. HD-DVD 소스도 크게 힘들지 않게 디코딩 될 것 같은데 한번 구해서 해봐야 겠네요. VC-1은 MS에서 만든거라 많이 안 쓰이는 추세라서 말이죠.

그리고 사실 압축을 빡시게 하던 간에 코덱이 같다면 인코딩 시의 퍼포먼스는 차이가 날 수 있지만 디코딩 퍼포먼스는 거의 화면 사이즈랑 프레임 레이트만 비슷하면 큰 차이 안 난답니다. 뭐 여튼 H264 코덱은 좀 알지만 VC-1 코덱은 전혀 몰라서 한번 해 봐야 겠네요.
Commented by 백승우 at 2007/11/01 12:53
어디에서나 코드가 맞아야되죠...
예전 어떤 교수님이 어려운말씀을 하셨죠..
이런게 다원화다..(이해는 못하겠지만..)
Commented by 녹슨 at 2007/11/01 13:07
저도 트랜스포머 HD DVD를 봤는데 정말 화질이 기절할 수준이더군요
제까짓게...라고 생각했는데 오산이었습니다
반면 8기가짜리 립버전은 그저 그랬구요

HD나 블루레이로 옮겨갈라고 해도, HD DVD롬은 팔지도 않더군요 --;;
블루레이야 플3 사면 된다고 쳐도 ;
Commented by felucca at 2007/11/01 14:35
그래도 위상이 변할 수는 있죠. 어셈 쓰던 데에 C 쓰는 것 처럼요 ㅋㅋ. 자바 VM은... 쓰라고 설계한 데 보다 다른데서 더 많이 쓰이니까 좀 그런 것 같고요..
Commented by object at 2007/11/01 14:43
사실 C/C++을 묶어서 써버렸는데 리누스 토발즈 같은 사람이 들으면 거품을 물 듯. C++도 느리다고 C만을 쓰는 곳도 많으니깐 -_-... 자바는 뭐 서버에서는 대성공을 거뒀지만 클라이언트에서는 이클립스말고 널리 쓰이는 프로그램이 없는 듯. C#도 그러한가..

HD-DVD 롬은 팔지 않더군요. 왜 안파는지 궁금합니다. 사실 제 컴퓨터 (E6400@2.8GHz)면 HD-DVD 립도 아무런 문제 없이 잘 재생이 됩니다. 그래도 예전 디빅에 비하면 헥헥 거리는 수준이죠.
Commented by Sungbae at 2007/11/02 12:47
메이플스토리 서버가 C#으로 만들어졌다던데요. 확실하지는 않아요. 다른 거 하고 혼동하고 있는 것 같기는 합니다;
Commented by 백승우 at 2007/11/02 16:22
자바로 만든 온라인게임도 있다는 사실!! ㅡ ㅡa 리눅스용..
Commented by sayhappy at 2007/11/03 01:00
글을 시원시원하게 참 잘쓰시는 것 같아요. ^^;
논문도 한 번 아이디어만 잡으시면, 정말 잘 쓰실 것 같습니다
Commented by object at 2007/11/04 03:20
사실 논문의 성패는 주제 잡는 것이 거의 8할 같더군요. 물론 주제를 좋게 잡아도 잘 끌어내지 못하는 경우도 있는데 훌륭한 지도교수와 어느 정도 머리만 받쳐주면 다 잘 나오는 것 같더군요. 잘 하는 학교는 주제도 좋고 이끌어 내는 능력도 출중하고... 반면에 조금 허접한 곳은 주제는 좋은데 끌어내는 능력이 부족한 곳이 좀 있어요.
Commented by Core_Geek at 2007/11/06 19:21
역시 한줄 요약은 좋아요 ^^
Commented by noname at 2007/11/12 06:49
아, 안 그래도 요즘 그런 생각을 하고 있었습니다.

그리 오래 되지 않은 예전에 이런 말이 있었죠. 소프트웨어의 속도를 최적화 하지 않아도 하드웨어의 발전이 그걸 커버해준다고 말이죠. 하지만 시간이 흘러서 하드웨어가 발전하면 그만큼 한계 속도를 소프트웨어가 쓰게 되더군요. 게임을 보면 알 수 있습니다. 몇 년 전에 나온 게임을 요즘 퍼포먼스 사양의 그래픽 카드면 쌩쌩하게 돌아가지만, 여전히 최신 게임은 하이엔드 그래픽 카드가 아니면 버벅임이 있습니다. 이런 현상이 계속 되풀이 되더군요.

웹페이지만 해도, 과거에 비해 엄청나게 cpu 성능이 빨라졌음에도 불구하고 html 코드를 엉망으로 짜면 브라우저가 매우 버벅거립니다. 하드웨어 성능 믿고 몇십만 바이트짜리 소스를 토해내면 브라우저가 다운될 때도 있죠.

한쪽이 발전하면 다른 한쪽도 자연스레 따라가는 게 이쪽 계열이라 앞으로도 변함 없을 것 같습니다.
토끼를 마취시키거나 강제로 재워버리면 거북이도 앞설 수는 있겠지만... 그럴 리는 없겠죠. ^^
Commented by object at 2007/11/12 09:21
네, 게임, 웹페이지 등등 거의 모든 분야에서 제가 말한 토끼와 거북이 논리가 적용이 됩니다. 언제나 최신 게임은 그 시대의 최고 컴퓨터를 요구하지요.

:         :

:

비공개 덧글

<< 이전 페이지 다음 페이지 >>





by 김민장 2008 이글루스 TOP 100
최근 등록된 덧글
개발자 입장에서의 수많은 ..
by Jiyoon at 02/04
저도 아들 돌잔치때 돌잡이 ..
by 박상욱 at 01/18
미국 대학원 원서 작성중에 p..
by 태클사이야 at 01/13
TO: 박PD 로그인 하지 않아..
by 박응용 at 01/10
http://gigglehd.com/zbx..
by dhunter at 12/28
우와.. 좋네요. 태반이 ..
by 윤광배 at 12/17
항상 좋은 글 잘 보고 있습니..
by y2k at 11/23
글이 좋아서 제 블로그에 담..
by 쏭섭 at 11/23
최근 등록된 트랙백
조엘 스폴스키의 강연 (Sta..
by 인덕원칸타타
[Redis] sds.c를 분..
by 조급하지말고 천천히
메뉴릿
이글루 파인더

website counter

Add to Google

rss

skin by 이글루스