Privatization은 사실 아무것도 아니다. 프로그램을 병렬화할 때 전역으로 선언된 어떤 자료구조를 각 스레드마다 가질 수 있도록 하는 것이다. 아래 같은 코드가 있다.

static int  g_data;

static int* g_vector = new int[100];

스태틱이나 전역 변수가 안 좋다는 건 익히 알고 있으나 그냥 넘어가고, 이렇게 전역으로 스칼라(int) 변수 하나와 배열 하나가 선언되어있다. 원래 프로그램은 싱글 스레드였고 이 변수들은 아무런 문제 없이 쓰고 읽을 수 있다. 그런데 이 코드를 멀티스레드로 해서 동시에 실행시키면, 아주 쉽게 예상할 수 있듯이, 문제가 발생한다. 전역 변수 혹은 스태틱 변수에 여러 스레드가 동시에 값을 쓰니 데이터 레이스(data race)가 발생하고 프로그램이 죽을 수 있다. 달리 쓰면 이 코드는 재진입 가능하지 않고(non-reentrnt) 스레드 안전(thread-safe)하지도 않다.

그럴 때, 이 자료구조를 ‘민영화’시키면된다. 아주 간단하고 직관적이다.

int  g_data[num_threads];

int* g_vector[num_threads];

for (int i = 0; i < num_threads; ++i)

  g_vector[i] = new int[100];

스레드 개수 만큼 데이터를 복제했다. n차원 배열은 n+1차원 배열이 된다. 그리고 이 데이터를 쓰는 놈들은 아래처럼 thread id를 주어 접근하도록 하게 하면 된다.

// Thread: tid

g_data[tid] = ...

.. = g_vector[tid][..]

이렇게 하면 정확하게는 돌아간다.

그런데 문제는 효율적으로 잘 돌아가지 않을 수 있다. 병렬 프로그래밍은 그래서 더욱 어렵다. 버그 없이 돌아가게 하는 것도 굉장히 어려운데, 이걸 효과적으로 돌아가게 하는 것도 비슷한 수준으로 어렵다. 위에서 간단하게 보여준 privatization의 문제점은 사실 명백하다. False sharing이라는 아주 유명한 문제인데, 어떤 데이터가 스레드 사이에서 실제로는 공유가 되지 않음에도 불구, 하드웨어 캐시 구조의 특성으로 공유되는 것과 같은 효과를 내어, 성능을 때론 크게 하락시킬 수 있다.

위 코드에서 g_data[0]은 0번 스레드가 g_data[1]은 1번 스레드가 쓰게 될 것이다. 이 둘은 서로 공유되지 않는다. 그런데 이 둘은 같은 캐시 라인에 놓일 확률이 매우 높다. 보통 캐시 라인의 크기는 64바이트이다. 즉, 프로세서가 캐시를 읽고 쓰고 하는 단위가 1바이트, 4바이트가 아닌 공간적 지역성(spatial locality)를 활용하기 위해 이보다 큰 64바이트 정도로 읽고 쓴다. 그래서 이 둘은 같은 캐시 라인에 있을 수 있고 여러 코어가 이 캐시 라인의 사본을 가지고 있다. 이 때, 어느 한 코어가 이 캐시 라인에 데이터를 쓰면 다른 사본을 모두 없애야 한다. 그래야 어떤 코어이던 어떤 데이터 값을 읽었을 때, 가장 마지막으로 쓰여진 최신 값을 읽어 프로그램의 정확성을 보장할 수 있다. 그런데 이 캐시 무효화하는 비용이 적지 않다. 그래서 false sharing이 병렬 프로그래밍의 성능에 큰 악영향을 미칠 수 있다.

위 같은 방법보다는 아래처럼 하는 것이 일반적으로 더 낫다.

struct THREAD_DATA {

  int  data;

  int* vector; // = new int[100];

  byte padding[..];

};



THREAD_DATA* thread_data = new THREAD_DATA[num_threads];

한 스레드가 쓰는 데이터를 모아서 하나의 구조체가 만들고 적절한 패딩을 넣어 이 구조체가 false sharing되는 것을 최소화할 수 있다. 이렇게 하는 것은 비단 false sharing 뿐만 아니라 데이터 접근 효율성 자체를 높일 수 있다. 왜냐면 이 방법으로 하면 data를 읽어오면 그 인접한 데이터도 같이 캐시에 올라오기 때문에 캐시 미스를 조금이라도 줄일 수 있다. 그리고 실제로 효과가 분명 있다.

malloc/new도 똑같은 false sharing 문제가 있다. 작은 데이터를 아주 많이 만들고 또 여러 스레드가 쓰고 읽기를 반복하면 성능 손실은 심각할 수 있다. 확장성(scalality, 즉 코어 개수를 늘리면 스루풋도 따라 늘어야 함)이 필수인 고성능 멀티스레드 프로그램에서는 메모리 할당자 역시 매우 신중히 써야 한다. Intel의 Threading Building Block의 메모리 할당자는 이런 문제를 해결한다.

지금 내가 만드는 프로그램이 싱글 스레드 용이었는데 병렬화해야 했다. 정말 수많은 자료구조를 ‘민영화’ 시키는 것은 엄청난 노가다였다. 그런데 어떤 변수들은 위의 예처럼 쉽게 스레드 개수 만큼 복제한다고 되는 것이 아니다. 예를 들어, 통계 값을 가지는 변수가 있다고 치면, 멀티스레드가 되면 각 스레드에서 나온 통계값을 다시 모아 합산하는 과정도 필요하다 (이러한 과정을 reduction이라고도 부른다). 또, 진정 골치아픈 경우는 변수 자체가 서로 의존성을 만들어 반드시 뮤텍스를 써야 하는 경우도 있다. 지금 이 글에서 소개한 privatization은 가장 간단한 예 중 하나다.

p.s. 코드 뜯어 고치다가 너무 지쳐서 잡담. 방금 컴파일 환경에 따라 Visual Studio가 디버거로서 어태치를 못하는 경우를 보고 급좌절 중... 도대체 이건 뭐야;;

그런데, 구세주가 나타났다. CPU 클럭 속도가 막혀 좀처럼 싱글 스레드 성능 향상에 애를 먹었는데 난데 없이 SSD라는 놈 때문에 새로운 길이 보인다. SSD는 익히 잘 아실 것으로 예상하고 자세한 설명은 생략. 이제 컴퓨터는 두 가지다. SSD이냐 SSD가 아니냐. 그런데 SSD 중에서도 워낙 구린 것이 많아서 다시 이 문장을 고치면:

인텔 SSD가 있는 컴퓨터인가? 그러하지 아니한가?

지금 34nm 기반 제2세대 인텔 X-25M 80GB의 가격이 다소 높다. 그런데 30만원 초반만 되면 아무 생각 없이 사면 된다. 인텔 SSD는 진리입니다. 다른 회사 제품 중에는 OCZ Vertex 정도만 고려하고 나머지 SSD는 무시하세요. SSD의 성능은 결국 4K 랜덤 쓰기 읽기인데 현재로서는 인텔 2세대 제품이 월등하다. 문제가 있다면 80GB는 너무 작다. 80GB를 쓰던 시절이 언제였는지도 모르겠다. 7~8년 전 같은데.. 정답은 SSD + 1/2TB 하드 조합.

윈도우 7 성능 점수에서도 하드디스크 점수가 제일 높다. 그래픽 카드는 그래도 nVidia 9800GT인데 너무 하네.

2. 컴퓨터의 성능은 레이턴시(latency, 응답시간, 측정 단위는 ‘초’ 같은 시간)와 스루풋(throughput, 단위 시간 당 처리량, 예: MB/s)로 표현할 수 있다. 그런데 이 둘을 개선시키는데 필요한 방법론은 사뭇 다르다. 그래서 나는 대충 “컴퓨터 성능이 좋아진다”라는 표현을 매우 싫어한다. 정확하게 레이턴시를 개선하는지 스루풋을 개선하는지 확실히 해야 한다. 대표적으로 파이프라인은 명령어 처리 스루풋을 늘리는 기술이다. 레이턴시는 개선시키지 못한다. 캐시는 명령어 완료 레이턴시 개선에 더 큰 목적이 있다 (궁극적으로는 명령어 스루풋을 늘리기도 하지만).

보통 데스크탑 같은 프로그램은 레이턴시가 생명이다. 왜 그런지 자세한 설명은 필요 없을 것이다. 그런데 보통 서버 쪽 프로그램은 스루풋이 훨씬 중요하다. 인터넷 쇼핑몰을 운영하는데 최종 결제 처리를 하는데 1초가 걸리나 2초가 걸리나 소비자는 큰 불만이 없다(물론 10초가 걸리면 이야기가 달라지지만). 그러나 스루풋이 딸리면 그건 바로 매상과 직결되므로 스루풋이 일반적으로 더 중요하다.

인텔 제품을 예로 들면, 서버 제품군으로 Xeon이 있다. 그런데 얘들이 데스크탑/노트북 용 프로세서와 구조적으로 다른 것은 거의 없다. 똑같은 놈인데 서버는 쉬지 않고 24시간 매일 돌아야하므로 높은 안정성이 요구된다. 그래서 가격이 더 비싸고 클럭이 데스크탑 제품군 보다 현격히 낮다. 예를 들어, Core i7-860의 클럭은 2.8GHz이고 가격은 290불이다. 그런데 같은 구조에 같은 클럭으로 Xeon 프로세서를 찾으면 1200불이다. 물론 Xeon 프로세서는 다중 소켓(그러니까 메인 보드에 여러 개 CPU를 꼽는 거)이 지원되는 등 부가 기능이 있지만 기본적인 명령어 파이프라인이나 캐시 구조는 같다. 그냥 완전히 같다.

학교 연구실에 있는 서버 머신의 클럭은 낮다. 그런데 나는 요즘 클럭이 빠른 컴퓨터가 필요하다. 결국 내 데스크탑 컴퓨터를 쓰고 있다. 실험 좀 빨리빨리 해보겠다고 오버 클럭도 더 빡세게 해봤다. 원래 2.67GHz인데 3.6GHz로 오버 클럭 했다. 정말 같은 Nehalem 기반의 Xeon 2.3GHz 프로세서보다 20~30% 이상 빠르다.

역시 컴퓨터 성능, 정확히 말해 레이턴시는 클럭이 짱. 그러니 인텔이 터보 부스트 같은 것을 넣는다.

3. A+ 학회에 논문 하나 붙이기는 쉽지 않다. 물론 한번에 척하고 붙은 사람도 더러 있지만 보통 한두 번 떨어지고 다시 수정하고 그래야 하나 붙을까 말까 한다. 운도 사실 굉장히 많이 따라야 한다. A+급 학회는 구현을 얼마나 잘 했냐 보다는 아이디어로 승부하는 경우가 절대 대다수다. 그런데 논문에서 제기하는 문제에 동의하지 않고 그 아이디어를 높게 평가하지 않은 리뷰어를 만나면 힘들다. (물론 객관적으로 평가가 가능하지만 리뷰어의 주관에 의존적인 것도 많다. 컴퓨터 시스템 분야가 수식으로 딱 증명되는 것이 별로 없기 때문이다)

이번에도 도전 중인데 결과는 또 떨어진다. 글을 개떡같이 쓴 내 잘못이 가장 크기는 하다. 그런데 이번에 받은 리뷰 중 비판적인 내용은 그 자체는 맞지만 도저히 수긍을 못하겠다. 지엽적인 구현 문제를 가지고 “나는 이 접근 방식이 맘에 안 들어”라고 말하면 대책이 없다. 논문이 맘 안 드는데 마땅히 깔게 없고 그러면 이런 문제로 걸고 넘어진다. 아니면 근원적으로 가지고 있는 문제를 따진다. 좋게 봐준 리뷰도 있지만 그래서는 붙기 어렵다. Strong Reject이 있으면 절대 못 붙는다. 다행히 이건 없는데 Strong Accept도 없다. 기적적으로 붙으려면 내 논문을 좋게 봐준 그 리뷰어가 최종 심사할 때 나타나 열심히 내 논문을 변호 해주어야 하는데 그런 가능성은 거의 없다.

지금 내가 하는 일은 일종의 프로파일러(profiler)를 만드는 것이다. 프로파일링이라면 개발자라면 아주 친숙한 단어일 것이다. 예를 들어, 어떤 프로그램의 병목 지점을 알고 싶다면 프로파일러를 돌려 어떤 함수가 자주 실행되고 또 그 함수가 얼마나 많은 캐시 미스나 페이지 폴트를 만들어 냈는지 살펴보면 된다.

내가 만드는 건 병렬화 가능한 루프를 찾아주는 프로파일러이다. 대충 이야기하면, 바이너리 exe를 입력 받아 실제 실행시키면서 이 프로그램이 작동하는 걸 분석한다. 그래서 병렬화 가능한 루프가 있다면 밝혀주고, 그러하지 않다면 그 이유(data dependence)를 자세히 프로파일링 해준다. 그런데 이 짓거리를 하는데 매우 많은 시간과 메모리가 필요하다. 지금까지 이 문제를 거론한 사람도 없다. 내가 만든 프로파일러와 유사한 논문이 있긴 있지만 전부다 작은 프로그램만 가지고 돌려보았다. 그런데 조금만 큰 프로그램을 돌리면 메모리와 시간이 감당할 수 없을 정도가 된다. 수십 GB메모리와 1천 배 이상 느려진다. 그래서 내가 이 문제를 풀었다(라고 황구라를..)

그런데 논문에서 이 프로파일러와 이 개선 알고리즘을 모두 이야기하니 오히려 글이 산만해지는 것 같다. 알고리즘 자체는 별 딴지도 없고 다들 좋다고 한다. 문제는 이 프로파일러의 방향에 대한 것. 어떤 리뷰어는 “너 왜 바이너리를 받는 걸로 하냐? 그냥 소스 받아서 하는 걸로 하지?” 라고 장황하게 딴지를 건다. 누가 모르냐. 이건 단순히 구현의 일부인데 이런 걸로 까면 정말 할 말 없다. 내 프로파일러는 소스 파일 받는 걸로도 쉽게 바꿀 수있다. 그런데 프로파일 하려면 매번 재컴파일 해야한다. 바이너리 수준의 프로파일러는 그럴 필요 없다. 분명 장단점이 있는데 “나는 이거 동의 안해” 이러면 어쩌라고 ㅠㅠ

또 하나의 문제는 프로파일러는 인풋에 의존적이다. 무슨 말이냐면, 입력 값에 따라 결과가 달라질 수 있다는 것. 이건 나만의 문제가 아니라 프로파일러, 일반적으로 말해 동적 프로그램 분석의 근본적인 문제다. 프로파일러만 하더라도 극단적으로 입력에 따라 자주 실행되는 함수가 다를 수 있다. 나도 이 문제를 알고 있어 분명 논의를 하기는 했지만 자세히 정량적으로 밝히기는 매우 어렵다. 이 자체가 하나의 논문 감이다. 그런데 리뷰어 한 놈은 이걸로 그냥 계속 물고 늘어진다. 엄밀히 말하면 ‘잠재적으로’ 병렬화 가능한 루프를 찾는 것이다. 왜 이걸 논문 첨부터 이야기 안 했냐고 투덜거린다. 사실 잘못하기는 했지만 그래도 이것만 딴지 거는데 힘이 빠진다.

무엇보다 어려운 것은 지금까지 이런 툴이 나온 적이 별로 없어서 설득시키기가 어렵다. 사실 내 논문에는 많은 허점이 있지만, 논문 중에 허점이 없는 것은 없다. 고작 2컬럼 10페이지에 모든 것을 이야기할 수도 없다. 그래서 이번에는 아예 툴을 제안하는 부분은 빼버리고 프로파일링 알고리즘에 집중해서 다시 도전하기로 했다. 사실 얼마 전 마감이었던 다른 A0 급 컨퍼런스에 냈다면 붙을 확률이 매우 높은데 괜히 객기를 부린 것 같기도 하고..

4. 서머타임이 끝난다. 한국에 있을 때처럼 “9시 뉴스”를 매일 보는 것이 아니라 오히려 일기 예보나 서머타임 끝 같은 사소한 것을 놓치기 쉽다. 그런데 기특하게도 윈도우 7의 시계 창이 이 사실을 알려준다.

11월 1일 오전 2시를 기점으로 다시 한 시간을 뒤로 돌리면 된다. 우리나라도 서머타임을 한다고 하는데, 정부에서 이걸 뭐 녹색 어쩌고 해서 호도하는 건 웃긴 것이 맞다. 그런데 또 서머타임을 하면 생체 리듬이 바뀌어서 짜증난다고 하는 사람이 많은데 그냥 이명박이 싫어요라고 말하는 것이 훨씬 논리적이다. 1 시간 시차로 생체 리듬이 바뀌어 한 달 동안 고생하신다는 분도 봤는데 이 분은 어떻게 해외출장 갈지 모르겠다. 서머타임으로 얼마나 에너지 절약이 되는지는 나도 좀 회의적이다. 그런데 그거 한다고 해서 큰 일 날 것도 없다.

서머타임 덕으로 한 시간 벌었다. 이 시간을 블로깅하는데 썼다. 보람차다.

• 1년 전에 쓰려고 했는데 아직도 못 쓴 내용: ActiveX 같은 것을 대체할만한 새로운 웹 플러그인 기술. 핵심은 바이너리를 플랫폼과 상관 없이 또 보안을 지키며 실행하는 것. 구글은 NaCl(NativeClient)라는 이름으로 (슬라이드), 마이크로소프트는 Xax라는 이름으로 대안을 제시 중. 실제로 이 방법론이 현재의 느려터진 RIA 방법을 효과적으로 대체할지는 미지수이나 언젠가는 도입이 될 기술로 봄.
• 역시 1년 전에 아주 재밌게 본 기사인데 올려야지 하면서 아직까지 못 올린 내용: 제임스 라루스라는 유명한 분이 쓴 재미있는 아티클. 처음 본 것은 테크니컬 리포트 버전. 그리고 올해 CACM에 출판된 아티클.
• 쓰다가만 volatile 내용
• 역시 쓰다가만 트랜잭셔널 메모리
• 리얼포스 87U 나름대로 심층 감상문 (결국 학교/집 두 개 샀다)
• 최근 nVidia가 새롭게 공개한 차세대 아키텍처 페르미(Fermi)에 대한 내용.

11월 말이면 올해 모든 일이 다 끝나서 한가해진다. 코딩도 잔뜩 해야 하고 실험도 엄청나게 해야 하는데 문제는 하기가 싫다는 것 –_-; 역시 교수들이 대학원생 뽑을 때 “motivation”을 1순위로 두는 이유가 다 있어.

윈도우 95 시절부터 작업줄의 모퉁이, 흔히 트래이 영역이라고 불리는 (정확한 용어는 notification area) 곳에는 현재 시각 및 날짜가 나온다. 이걸 더블 클릭하면 위 그림처럼 “날짜 및 시간 등록 정보”가 뜬다. 그런데 윈도우 비스타 이전에는 이 창을 닫으려면 명시적으로 X표를 누르거나 확인/취소를 눌러야 했다. 이 말은 즉 이 날짜 창은 사용자가 다른 곳으로 키보드나 마우스로 포커스로 옮겨도 계속 떠 있음을 뜻한다. 그냥 일반 창과 같다.

그런데 윈도우 비스타와 윈도우 7은 그러하지 않다.

일단, 윈도우 비스타의 시계 기능은 훨씬 예뻐졌다. 최대 3개의 시계를 동시에 보여주는 것도 아주 좋다. 그런데 치명적인 단점은 위 그림을 보면 이 창을 닫는 단추나 확인 버튼이 없다. 그래서 그냥 키보드나 마우스를 다른 프로그램으로 찍기만 하면 사라져 버린다. 창처럼 하지 않고 툴팁이나 메뉴처럼 만든 것이다.

종종 이 날짜 시간 창을 계속 띄어놓고 보고 싶은 일이 있는데 그 때마다 너무 아쉽다. 사실 윈도우 비스타/7에는 가젯이 추가되어 날짜와 시각을 늘 띄어놓고 볼 수가 있어 이 기능을 대체할 수는 있다. 가젯 사용을 유도하기 위해 의도적으로 바꾸었는지 몰라도 왜 꼭 굳이 이렇게 만들었을까?

대학교 학부 시절 그 수 많은 리포트를 아래아 한글로만 작성했다. 그래서 지금도 아래아 한글이 꽤나 편하고 특히나 수식 편집은 매우 익숙하다. 그럼에도 불구 난 정말 그렇게 오래 아래아 한글 쓰면서 한번도 욕을 안 한적이 없다. 비록 수식 편집이나 일부 표현 기능은 훌륭하지만 프로그램 자체로서의 점수는 낙제에 가깝기 때문이다.

대부분의 사람들은 아래아 한글을 윈도우에서 쓴다. 아니 거의 전부라 해도 과언이 아닐 것이다. 그런데 아래아 한글은 아직까지도 매우 고약한 버릇을 못 고치고 있는데 바로 황당한 단축키 구성이다. 아무리 한글이 도스 시절부터 내려온 프로그램이라 하더라도, 윈도우에 왔으면 제발 기본적인 윈도우의 단축키 규칙은 따르면 좋겠다.

윈도우 응용 프로그램에서 단축키는 기본적으로 Ctrl과의 조합으로 이루어진다. Ctrl, Ctrl+Shift, Ctrl+Shift+Alt로 구성된다. Alt는 보통 시스템 단축키로 예약되어있다. 그런데 아래아 한글은 기본적인 단축키의 조합이 Alt로 시작한다. Ctrl+N이 대부분의 윈도우 응용 프로그램에서 새로운 문서 열기라면 아래아 한글은 Alt+N이다. 그런데 윈도우에 오다 보니 매우 익숙한 복사/삭제/붙여넣기 때문에 Ctrl 조합의 단축키도 있다. 그래서 도통 일관성이 없다.

대표적으로 윈도우 응용 프로그램에서 Alt+Space를 누르면 시스템 메뉴라 불리는 닫기/최소화/이동/크기가 있는 메뉴가 뜬다. 그런데 아래아 한글은? 직접 해보시라. 아래아 한글은 단축키 조합이 대부분이 Alt로 시작하기 때문에 엉뚱한 일이 벌어진다. 나처럼 창의 최대화를 Alt+Space를 눌러 X를 누르는 사람에겐 성가신 일이다. 

여기서 보면, 찾아가기는 희한하게 Alt로 시작한다. 이 정도는 괜찮다고 치자. 소프트웨어나 하드웨어나 하위 호환성이 중요하니 예전 사용자를 배려해서 뒤죽박죽 키 조합은 애교로 봐준다.

그런데 드디어 오늘 대형 사고를 치고 말았다. 그건..

보다시피 아래아 한글은 매우 황당하게 ‘다시 실행’의 기본 단축키가 Ctrl+Y가 아니다. Ctrl+Y는 워드패드, 오피스 등 ‘다시 실행’이 지원되는 거의 모든 응용 프로그램에서 ‘다시 실행’으로 예약되어있다. (사실 아래아 한글에서 ‘다시 실행’이 지원된 것도 오래된 일이 아니다. 아래아 한글 97은 아마 내 기억이 맞다면 다시 실행이 없었다. 그래서 표 작업할 때 사람을 아주 환장하게 만들었는데, 다른 한글 파일을 열고 작업 중간 중간 결과물을 복사해서 보관하곤 했다)

여기서 더더욱 재앙은 아래아 한글에서 Ctrl+Y는 한줄 지우기로 다른 명령으로 할당되어있다!!!!

이런 배째라 식의 단축키 구성은 다음과 같은 상황에서 재앙을 만들어 낸다.

1. 열심히 한 1천 개의 작업을 한다. Undo 리스트에 1천 개의 작업이 뜬다.
2. 200 개를 Ctrl+Z를 열심히 눌러 되돌렸다. 그러면 200개는 Redo 리스트로 옮겨 간다.
3. 여기서 한 작업을 다시 되돌리고 싶어 Ctrl+Y를 누른다.
4. 아래아 한글에서 Ctrl+Y는 지우기이기 때문에 한줄이 지워지면서 200개의 Redo리스트는 몽땅 날라간다.

아마 이쯤이면 이 참담한 시나리오가 이해 갈 것이다.

다음 달 마이크로소프트웨어에 글을 하나 작성하고 있었다. 그런데 아쉽게도 마소 측에서 아직도 아래아 한글을 쓰고 있다. 열심히 초반부 두 장을 쓰다가, 암튼 언두를 좀 많이 해야 할 일이 있었다. 그리고 다시 리두를 하려는데 그만 Ctrl+Y를 누르고 쓴 내용을 거의 다 날렸다. 혹시나 .asv 자동 세이브 파일도 뒤져봤건 허사였다. 사실 이 문제는 예전부터 알고 있어서 아래아 한글을 깔면 반드시 단축키 설정을 바꿨다. 그런데 최근 윈도우 7로 새로 깔면서 그걸 깜빡하고 말았다. 내가 바보 병신 짓 한 것 맞다. 조금만 주의 했어도 됐는데 어쩌다가 이런 참혹한 실수를 하고 말았다.

최근 블로그에 글을 올릴 때 나름대로 세운 원칙 중 하나가 너무 까대는 글은 자제하자는 것이었다. 그런데 도저히 아래아 한글은 안 깔래야 안 깔 수가 없다. 그래도 단순히 까는 걸로 글을 마감하고 싶지 않고 좀 건설적인 결론으로 이 글을 마치도록 하자.

개성도 중요 하지만 기본적인 규칙은 지킵시다. 특히 프로그램을 만들 때 해당 운영체제의 기본적인 단축키 정책 뿐만 아니라 룩앤필(Look & Feel)도 고려해서 좀 쌈빡한 프로그램을 만들어 봅시다. 다시 콕 찝어 지적하면:

1. 지멋대로 단축키 구성은 하지 말지어다.
2. 별로 이쁘지도 않은 스킨은 제발 쓰지 말지어다.

추가: 아래아 한글이 리두를 Ctrl+Shift+Z로 해서 많이 화내는 것이 아닙니다. Ctrl+Y가 한줄 삭제라는 리두/언두 리스트에 영향을 주는 명령으로 기본 설정 되어있다 보니, 경우에 따라 심각한 사용상의 실수를 겪을 수 있는 것이 문제입니다. Ctrl+Y를 리두로 생각하는 사람들은 매우 많습니다.

1. Dell 2408WFP

24인치 모니터 하나로는 부족해서 델 24인치 모니터를 하나 더 샀다. 노동절 기념 100불 세일해서 449불이니 꽤 저렴하다고 생각했는데, 역시나 이런 저런 문제가 좀 있다. 원래 쓰던 모니터가 Dell 2407인데 패널이 다른 녀석이다 보니 색감 차이가 상당히 나서 짜증이 샘솟는다. 2408은 푸른끼, 2407은 붉은끼가. 컬러 캘리브레이션 이런 건 몰라요. 원래 19인치 듀얼을 쓰다가 24인치로 넘어왔는데, 듀얼 모니터를 쓸 땐, 다시 한번 느끼지만, 동일한 모니터 두 개를 쓰는 것이 가장 좋다. 그런데 와이드 24인치 듀얼은 솔직히 많이 넓긴 하다.

심각한 문제점: Dell 2408 모니터는 종종, 아니 때론 매우 심각하게 계속 대기 모드로 들어가서 사용이 불가능한 상태를 겪게 된다. 재부팅을 한다거나 커넥터를 바꿔서 꼽아 준다거나 그렇게 해야 함. 이미 유명한 문제.

2. 리얼포스 87U

이미 유명한 녀석이라 자세한 설명은 생략. 내츄럴 키보드만 12년 쓰다가 처음으로 바꿨는데, 중독성 강한 터치감으로 얻는 행복감과 내츄럴이 아니라 손목이 꺾어져서 발생하는 피로가 교묘히 균형을 이루고 있는 중.

강력한 삽질: 미국에서 안 파는 줄 알고, 한국에서 36만원에 구입 후 우체국 택배로 미국으로 다시 배송. 택배비만 5만원이 들었음. 그런데 미국에서도 리얼포스와 HHK를 팔고 있는 것을 발견. 문제는 한국보다 제품 가격 자체가 저렴하다는 점. 미국 내 배송비를 고려해도 270불이고 요즘 환율이 많이 떨어져서 34만원 밖에(?) 안함. 그냥 구글에서 RealForce 87U만 쳤어도 미국에서 판다는 것을 알았을 것인데…

3. 스카이디지탈 HD6 USB mini

원래 쓰던 USB HDTV 수신카드가 있었는데 회사가 망해 드라이버 업데이트도 안되고 열 받아 새로 삼. 역시 미국에서 안 팔기에 리얼포스 87U와 함께 미국으로 배송 받음. 비스타/윈7에서도 에어로 안 꺼뜨리고 잘 돌아가고 그럭저럭 쓸만한데, 종종 소리가 안 나온다거나 HDTV에서는 영문 캡션이 안 된다거나 몇몇 문제가 있음.

그럭저럭 삽질: 자꾸 HD 채널이 잘 안 잡혀서 문제가 있나 싶었는데 결국 동축 케이블이 구려서 발생한 문제. 쉴드 잘 되어있는 12불짜리 케이블로 바꿔주니 아주 잘 나옴.

4. 레고 10197 Fire Brigage

아, 지금까지 조립한 레고 세트 중에서 탑쓰리 중 하나로 꼽고 싶다. 첨에 사진으로 봤을 때는 회색이 너무 많아 그저 그랬는데 만들어 보니까 장난이 아님. 디자이너님 그냥 존경 하겠습니다.

미국에서는 150불에 판매되는데 문제는 이건 한국에서 정식으로 발매가 안되므로 구매 대행을 해야만 함. 26만원 정도가 든다. 레고 코리아에서 정식 발매를 하면 18만원이면 충분히 살 것 같은데, 이거 레고 코리아랑 구매대행 업자들이 담합이라도 한 건가.

소니 SONY, 이 친구들은 하드웨어는 그럭저럭 만드는데 얘들이 만드는 소프트웨어의 수준은 참혹함 그 자체다. 소프트웨어도 바보 멍청하게 만들 뿐만 아니라 손쉽게 깔지도 못하게 한다. 내가 쓰는 HD 캠코더, HDR-CX7 같은 경우, 캠코더를 꼽지 않으면 아예 전용 브라우저를 깔 수도 없게 한다. 이 브라우저는 상당히 멍청하지만, 엄청나게 많은 동영상을 날짜 별로 보기에는 참 좋아서 울며 겨자 먹기로 쓴다.

이 달력 보기 기능 때문에 내가 참고 너를 쓴다.

문제의 발단은 캠코더 드라이버와 전용 소프트웨어를 깔고 윈도우를 재부팅하는데, 황당하게도 윈도우 7이 부팅이 되지 않고 복구 모드로 들어가서 자동으로 롤백을 해버린다… 친절하게도 윈도우 7은 문제의 원인도 알려주는데 pxhelp20.sys라는 거지 같은 드라이버가 문제를 일으켜 부팅에 실패해서 복구했다고 한다.

검색해봐도 이 문제를 겪은 용자는 안 보인다. 이 파일의 정체는 알 수 있었는데, 어디 DVD 관련 시스템 드라이버 같았다. 꼭 이런 거지 같은 번들 소프트웨어는 온갖 기능이 다 딸려 온다. DVD 굽는 기능도 가지고 있고 그래서 이런 드라이버 파일도 깔아준 것 같다.

하는 수 없이 직접 문제 해결에 나섰다. 2시간 정도의 긴 삽질이 끝나고… (인스톨쉴드의 ini 조작해서 세부 컴포넌트가 빠지도록 해서.. 기타 등등…) 그런데 찾은 해법은 너무 허무했다.

그냥 pxhelp20.sys를 C:\Windows\SysWOW64\drivers 폴더에서 지우면 된다.

어차피 난 동영상 임포트와 보는 것만 되면 되므로 아무런 문제가 없었다. 혹시나 소니가 이런 문제를 알고 있을까 해서 알려주기로 했다. 홈페이지고객 센터를 통해 메일을 하나 보냈다. 사실 어떠한 기술적인 답변이나 해결책을 받을 것이라고는 기대는 하지 않았다.

놀랍게도 답신 메일이 24시간도 안되어서 날라왔다. 그런데 이게 사람이 쓴 것인지 아니면 기계가 쓴 것인지 나는 분간하기 어려웠다. 혹시 고객 응답용 이메일 작성 인공지능이 개발된 것인가?

나의 질문: Windows 7 64비트에서 너희 소프트웨어 까는데 pxhelp20.sys때매 안되더라. 대책 있냐?

Jason이라는 친구의 답변:

Sony only releases full product and support information at the same time it is officially released to the marketplace by our Marketing Department. However, some limited advanced information is often published in various magazine articles. You may also want to read Sony's News Releases at: http://news.sel.sony.com

Thank you for your time.
The Sony Email Response Team C6EL Jason

무슨 말인지 이해가 안 가더라. 구글 번역기를 돌려봤다.

소니는 단지 그것을 공식적으로 시장에 우리의 마케팅 부서에 의해 발표된 같은 시간에 가득 제품 및 지원 정보를 출시하였습니다. 그러나, 몇 가지 제한된 고급 정보는 종종 여러 잡지의 기사에 게시됩니다. 또한 소니의 보도 자료를 읽을 수있습니다:

그러니까 한 마디로

야 이 색히야 아직 윈도우 7 정식 출시도 안 했는데 왜 깔고 지랄이야?

에.. 그냥 윈도우 7이 바보 같은 녀석이라고 맘을 먹기로 했다. 죄송합니다. 나는 그저 이런 정보가 소니 소프트웨어 개발팀에게 전달이라도 되기만을 바랬을 뿐인데.. 그런데 무엇보다 저 링크가 정말 압권이다. Jason은 내가 저 링크에서 찬찬히 소니 관련 뉴스 기사를 읽으면 도움될만한 정보를 얻을 수 있을 것이라고 믿은 걸까?

여담으로 정말 소프트웨어의 버전 간의 불 일치는 쉽게 꼬여 버리는 이어폰 줄과 같은 존재와 같다. 비단 윈도우와 드라이버 문제 뿐만 아니라, 특히 오픈소스 쪽은 컴포넌트끼리의 버전이나 컴파일러가 조금만 바뀌어도 안 되는 것이 부지기수다. 요즘 학교의 SVN 서버가 잘 안 돌아간다.

찾아보니 SVN 서버와 클라이언트 버전이 안 맞아서 그렇다는데 맞춰도 안 된다. 아…

정말 행복한 세상에서 살고 싶다.

PC 판매량은 꾸준히 증가하고 있다. 1999년, 처음으로 1억 대가 넘는 PC가 팔리기 시작했다. 잠시 닷컴 버블 붕괴로 2001년의 판매량은 조금 줄었지만 2002년에 판매된 PC의 수는 1.37억 대였다. 그런데 2007년에는 이 두 배에 가까운 2.64억 대가 팔렸다고 한다 (참고 자료). 윈도우의 시장 점유율은 2009년 7월 현재 전세계적으로 93%라고 한다. 따라서 2002년에서 2007년까지 판매된 엄청난 PC 중 사실 상 대부분의 컴퓨터는 윈도우 XP가 깔렸다고 볼 수 있다. 이런 엄청난 XP의 판매량은 오히려 부메랑이 되어 비스타의 채용을 더욱 더디게 만들었다.

또 하나, 이렇게 절대적으로 많은 컴퓨터가 XP다 보니 대부분의 프로그램과 하드웨어 드라이버도 XP를 기준으로 만들어져 있다. 그런데 아쉽게도 사람은 근본적으로 게으르고, 소프트웨어 개발자들은 더욱 더 게으르기 때문에 아무리 윈도우 비스타가 나와도 배째는 드라이버와 소프트웨어가 부지기수다. 윈도우 비스타가 XP와는 상당히 다른 보안 정책 등으로 혼란을 빚은 것은 맞다. 그러나 비스타가 추구한 방향은 옳다. UAC가 많은 욕은 먹었지만 그건 제대로 잘 마감이 안되어서 그렇지 UAC 도입 자체는 매우 합리적이다.

소프트웨어 개발자도 이런 방향을 따라야 하는데 그냥 놀고 업데이트는 무시한다. 나는 비스타를 첫 출시부터 썼고, 더군다나 64비트를 썼지만, 소프트웨어 호환성 문제를 겪은 적이 (거의) 없다. 물론 몇몇 하드웨어 드라이버는 문제가 있었다. 거지 같은 로지텍의 구닥다리 웹캠이 드라이버 업데이트를 공식적으로 배째서 못 쓰고 버렸다.

어찌되었건 비스타는 이런 저런 이유로 결국 실패했다. 그 중에서도 XP 호환성이 큰 이유라는 것을 잘 아는 마이크로소프트는 Windows 7에서 어떻게 보면 매우 단순하지만, 한편으론 매우 옳은 방법으로 XP 호환성 문제를 해결하려 한다. 바로 가상화(virtualization) 기술을 이용한 것이다.

가상화 기술(Full virtualization)은 컴퓨터 안에 온전한 컴퓨터를 몇 개나 더 만들어 준다.

컴퓨터 잘 다루는 분들은 이미 VMware Workstation 같은 프로그램으로 윈도우 위에서 리눅스나 아니면 다른 버전의 윈도우를 돌려본 경험이 있을 것이다. 맥 사용자라면  Parallels라는 가상화 소프트웨어로 윈도우를 맥 위에서 작동시킬 수 있다. 여기에 사용된 기술이 바로 가상화라는 기술인데, 물리적으로 하나인 컴퓨터를 마치 여러 대인 것처럼 속이는 기술이다. 서버 시장에서는 여러 물리적인 컴퓨터를 하나로 합칠 수 있기에 (즉 원가 절감) 매우 중요한 기술이지만, 상대적으로 클라이언트 데스크탑에서는 윈도우에서 리눅스를 깔아보는 것과 같은 일종의 장난감 역할을 주로 했다.

그런데 이 가상화 기술은 윈도우 비스타가 겪은 하위 호환성 문제를 푸는데 아주 멋진 해법을 제시한다.

윈도우 비스타나 윈도우 7이 XP와의 완벽한 호환성을 목표로 했다면, 과거 구현의 단점을 계속 벗어 나지 못할 것이다. 소프트웨어 개발한 분들은 절감하겠지만, 예전 버전 호환성을 늘 지키는 것이 얼마나 괴로운지 잘 알 것이다. 윈도우는 이 하위 호환성 문제가 매우 심각하다. 단적인 예로 늘 문제가 되는 ActiveX 정책을 들 수 있다. 최초로 ActiveX가 나왔을 때는 이걸 이용한 보안 취약성 문제를 고려하기 힘들었다. 그래서 사용자의 어떠한 개입 없이도 특정 웹페이지만 가면 ActiveX가 다운로드 되어 컴퓨터에 설치될 수 있었다. 그러나 각종 스파이웨어나 악성 프로그램이 이 경로로 설치되자 XP 서비스 팩 2부터는 사용자의 명시적인 클릭 없이는 설치되지 않도록 했다. 그리고 윈도우 비스타, 7 역시 하위 호환성을 위해 ActiveX는 여전히 제공되지만 더욱 더 많은 장벽을 두어 악성 프로그램이 쉽게 깔리지 않도록 하고 있다.

이걸 마이크로소프트가 첨부터 설계를 멍청하게 해서 그랬다고 욕할 수도 있다. 그러나 90년대 초반에 이런 보안 취약성 문제를 생각한 사람은 거의 없다. 그런데 ActiveX 뿐만 아니라 지금 우리가 쓰는 데스크탑 운영체제와 소프트웨어, 더 나가 CPU가 근본적으로 보안을 심각히 고려해서 설계된 것이 아니다. 사실 원초적인 소프트웨어 취약성은 CPU 자체가 너무나 낮은 수준의 보안 기능을 제공하기 때문이다. 과거에는 컴퓨팅 파워가 약했는데 보안 및 권한에 많은 자원을 써버리면 정작 계산을 별로 할 수가 없었다. 그래서 과거에는 보안에 별로 신경 쓰지 않은 것이 큰 문제가 되지 않았는데, 이것이 지금 와서 큰 문제를 만드는 것이다. 윈도우 95가 나올 당시 개인용 데스크탑 컴퓨터가 인터넷에 늘 연결되리라고 상상한 사람은 별로 없었다.

따라서 미래의 윈도우 운영체제가 늘 과거 운영체제의 취약한 보안 문제점을 가지면서 하위 호환성을 지키는 것은 좋은 선택이 아니다. 이보다는 완전히 독립된 가상 머신에 예전 운영체제를 띄우고 거기서 프로그램을 돌게 하는 것이 더욱 합리적이다. 가상 머신이 하나의 완벽한 샌드박스를 제공하므로 아무리 악성 소프트웨어가 가상 머신을 망가뜨려도 여러분의 컴퓨터는 말짱하다. (물론, 미래의 아주 무시무시한 악성 프로그램이 가상 머신을 통해 호스트 컴퓨터를 공격할지도 모른다) 그래서 Windows 7의 XP Mode 도입은 매우 중요한 의미를 가진다.

Windows 7의 XP Mode는 사실 아무것도 아니다. 이미 마이크로소프트가 제공하는 가상화 소프트웨어인 Virtual PC에다 미리 깔려있는 XP를 사용하기 더 쉽도록 배포한 것이다. Windows 7을 깔고 XP Mode를 다운 받으면 끝난다. 너무 간단하다. 윈도우 XP가 하나 뜬다.

가상 머신을 써본 분에게는 전혀 새로울 것도 없는 익숙한 화면일 것이다. 여기다 비스타에서 잘 안 돌던 프로그램을 깔면 된다. 그런데 이런 모습으로만 제공되었다면 정말 별 볼일 없는데, 다행스럽게도 XP Mode에서 뜨는 프로그램이 윈도우 7 데스크탑에 녹아 들어가 훨씬 자연스러운 인터페이스를 볼 수 있다. 구현은 원격 데스크탑을 이용한 것으로 보인다. VMware의 클라이언트 가상화 프로그램에서도 Unity라는 기능으로 데스크탑을 공유할 수 있다. 그러나 완벽하지는 않다. 써보면 조금씩 이상한 점을 발견하지만 그래도 상당히 이음새 없이 잘 쓸 수 있다.

XP Mode에서 실행된 IE7이나 인터넷 뱅킹 프로그램이 Windows 7 데스크탑 위에서 작동 중이다.

IE7에서 C:\ 같은 것을 치면 탐색기도 잘 뜨고 아무런 프로그램을 다 실행시킬 수 있다. 자동으로 내 컴퓨터의 드라이브도 다 연결되어 파일 공유도 간단하다. 다만 XP Mode의 창으로 파일을 끌어다 놓을 수는 없다.

XP Mode에서 프로그램을 깔면 바로 윈도우 7 메뉴에 해당 프로그램 단축키가 설정이 되기도 한다. 무척 편리하게 잘 만들었다. (물론 어떤 경우에는 잘 안 되기도 하지만 대부분 프로그램은 바로 추가가 된다) 어떻게 하면 이렇게 추가되는지는 이 동영상을 참고.

단, 하나 아쉬운 것은 XP Mode에서 게임 같은 것을 돌리는 것은 불가능에 가깝다. 이건 XP Mode 뿐만 아니라 현재 구현되고 있는 데스크탑 가상화 기술이 가지고 있는 공통적인 문제이다. 가상화 기술에서 CPU와 램은 연구가 많이 이루어져서 해법이 많이 나와있다. 하드디스크도 가상화도 간단하다. 그러나 아직까지 VGA, 그래픽 카드에 대한 가상화는 별로 잘 이루어진 것이 없다. 일반적으로 가상 머신에서 작동 중인 게스트 운영체제는 VGA 하드웨어 가속을 쓸 수 없으므로 DirectX 기반이 게임은 작동되기 어렵다. 물론, 맥에서 쓸 수 있는 Parallels 사의 가상화 제품은 DirectX 9.0과 256MB의 비디오 메모리를 지원한다. (써보지는 않아서 얼마나 원활한 성능이 나오는지는 모르겠다. 혹시 DirectX 기반의 게임도 무난히 작동 되는지 궁금하다) 그러나 아직까지 XP Mode는 이런 기능까지는 지원되지 않는다. 그래도 간단한 동영상 보는 것은 전혀 문제 없었다.

보다시피 XP Mode 안의 XP에서 잡히는 VGA는 듣보잡으로 잡힌다.

Windows 7의 XP Mode 도입은 간단하지만 상당히 의미 있는 일이다. 미려하게 인터페이스만 잘 다듬고 정말로 내부에 윈도우 XP가 도는지도 모르게 만든다면 윈도우 운영체제가 겪은 고질적인 하위 호환성 문제도 풀 것이다.

한줄요약: 그지 깽깽이 같은 인터넷 뱅킹 AcitveX는 이제 XP Mode에서만 볼지어다.

한줄 더: nProtect 더 이상 너를 안 봐도 되는구나.. ㅠㅠ

(그러나 현실은 가상머신에서 도는 것을 감지, 안 되게 막아 놓은 곳도 많다고 합니다)

p.s. 다른 Windows 7 컴퓨터에 세팅한 XP Mode를 전송하는 방법은 단순히 vhd 파일만 복사하면 된다. 그러나 디폴트 XP Mode VM 설정 같은 방법이 전통적인 레지스트리를 통하지 않아 약간의 삽질이 필요했다. 참고 삼아 찾은 링크를 기록 차원에서 남김: 링크1(가장 확실한 방법), 링크2, 링크3

마이크로소프트 윈도우즈 사업부 수석 부사장인 Bill Veghte씨는 윈도우즈 7에서는 하이퍼스레딩 지원이 강화 된다고 밝혔다. 마이크로소프트는 하이퍼스레딩 지원 강화를 위해 인텔과 긴밀한 협조 체제를 유지해오고 있으며, 윈도우즈 7의 스케쥴러 부분을 손봐 멀티코어 프로세서의 이점을 최대한 끌어낼 수 있을 것이라 한다.

하이퍼스레딩은 하나의 CPU가 마치 두 개처럼 보이게 하지만, 대부분의 실행 자원과 캐시는 공유된 채 스레드 문맥 교환 비용만 없어지도록 한다. 그래서 운영체제가 똑같은 CPU로 간주하고 스케쥴링을 하면 별로 좋지 않은 성능이 나올 수 있을 것이다. 예를 들어, 바쁘게 돌아가는 두 스레드를 하이퍼스레딩 관계의 두 논리 CPU에 할당하면 얘들 끼리 한정된 캐시나 실행 자원을 가지고 서로 경쟁하기 때문에 오히려 성능 하락이 있을지도 모른다. 따라서 운영체제가 하이퍼스레딩을 인지하여 더 똑똑하게 스케쥴링 로직을 짜는 것은 합당한 일이다.

윈도우 7을 이제 본격적으로 쓰기 시작했는데, 비스타와는 다른 스케쥴링을 목격할 수 있었다.

좌로부터 각각 한 쌍의 CPU 중 한 녀석에게 주로 일감이 있음을 볼 수 있다.

Core i7은 쿼드 코어지만 하이퍼스레딩으로 총 8개의 논리 CPU가 보인다. 좌로부터 0, 1, …, 7로 번호를 붙이면, 0번과 1번 CPU가 서로 하이퍼스레딩 관계다. 마찬가지로 2와 3, 4와 5, 6과 7도 그러하다.

위 그림을 보면 최대한 하이퍼스레딩으로 만들어진 두 코어에 동시에 작업을 주지 않고, 물리적으로 다른 코어에 작업을 배치함을 알 수 있다. 0-1을 보면 0번이 주로 사용되고 있다. 비슷하게 1-2, 3-4, 5-6에서도 각각 한 녀석만 주로 스케쥴링 되고 있다. 어차피 전체 CPU 사용률이 20%도 안되기에 여유가 많다. 이럴 때는 하이퍼스레딩의 부작용을 막고자 최대한 물리적으로 다른 코어에 우선 순위를 주어 스케쥴링 함을 쉽게 유추할 수 있다.

물론 정확한 스케쥴링 알고리즘은 알 수 없다. 그런데 전체 사용율을 대략 40%까지 올려보며 테스트 해보았는데 충분히 이러한 사실을 확인할 만큼 CPU 사용율이 잘 분배되었다. 비스타에서는 이러하지 않았다. 같은 상황이라면 8개 CPU가 고르게 분배되곤 했다.

이 예에서 보듯, 윈도우 7은 이제는 기본이 된 멀티 코어를 더 효율적으로 이용한다. 몇 가지 예는 더 찾아 볼 수 있다. 윈도우 7은 멀티 코어를 적극 활용해 하드웨어 초기화 시간을 줄여 부팅 시간을 단축했다고 한다. 또, 비스타부터 도입된 새로운 데스크탑 그래픽 엔진(DWM)도 병행성을 늘리도록 프로그램을 개선하여, 여러 프로그램을 돌렸을 때 더 나은 확장성을 얻을 수 있었다.

윈도우 7의 구현은 더욱 똑똑해졌습니다(라고 쓰고 비스타의 구현은 참 멍청했구나라고 이해합니다)

이렇게 하드웨어가 멀티 코어화 되니 운영체제도 여기에 대응을 하고 있다.

맥 OS X의 최신 버전 Snow Leopard도 OpenCL(솔직히 거의 CUDA를 그냥 베낀 것 같은데)이라는 GPU를 보다 활용할 수 있는 녀석을 제공한다. 솔직히 일반 사용자에게 큰 영향을 주는 것은 아니다. 비유하자면, 그냥 nVidia CUDA 같은 녀석이나 DirectX가 그냥 깔려 배포된다고 보면 된다. 그러나 어쨌든 OS X 개발자들이 OpenCL에 더 쉽게 다가갈 수 있게 되었다.

여러분의 소프트웨어는 어떻게 좀 멀티 코어를 고려하고 있습니까?

이제 노트북의 판매량이 데스크탑을 추월했다는 소식은 놀랍지도 않다. 많은 사람들은 아주 높은 수준의 컴퓨팅 파워가 필요치 않으므로 이동성이 매우 우수한 랩탑을 그냥 집에서도 늘 쓰게 되었다. 덕지덕지 수많은 케이블 고민을 하지 않아도 된다. iMac도 이런 점에서는 매력적이다.

그러나 늘 트레이드 오프가 있는 법. 노트북이나 아이맥은 결코 내가 원하는 성능을 주지 못하기에 난 늘 집에서 만큼은 고성능 데스크탑을 써야만 한다. 같은 이유로 나 같은 사람들은 언제나 존재할 것이기 때문에 데스크탑이 노트북이나 넷북에 밀려 사라지는 일은 없을 것으로 단언한다. 다만 그 크기만 줄 뿐.

내가 하고 싶은 이야기는 컴퓨터 기술은 눈부시게 발전했는데 왜 이렇게 컴퓨터의 전선의 수는 줄이지 못할까라는 아주 원초적인 불만이다. 지금 내 데스크탑 컴퓨터에는 아래와 같은 전력/데이터 케이블이 있다:

1. 본체 파워 케이블
2. 모니터 파워 케이블
3. 모니터 DVI 신호 케이블
4. 모니터에 있는 USB 허브를 쓰기 위한 본체와 연결된 USB 케이블
5. 스피커 파워 케이블
6. 스피커와 본체를 연결하는 신호 케이블
7. 좌우 스피커를 연결하는 케이블
8. 공유기와 벽에 있는 랜 단자를 연결하는 랜 선
9. 공유기에서 내 컴퓨터까지의 랜 선
10. 공유기에서 내 노트북까지의 랜 선(사는 곳이 학교 내 아파트라 보안 상 랜을 무선으로 공유하지 못함)
11. 공유기의 파워 케이블
12. 키보드를 연결하는 USB 케이블
13. 마우스는 무선인데, 마우스 충전기 때문에 파워 케이블이 필요함
14. 노트북용 파워 어댑터 및 파워 케이블
15. HD 캠을 위한 충전용 어댑터 및 파워 케이블
16. HD 캠을 연결하는 USB 케이블
17. 웹 캠을 연결하는 USB 케이블
18. 마지막으로 핸드폰 충전을 위한 파워 케이블

총 18개, 7개의 파워와 11개의 신호 케이블이 필요하다. 정신이 혼미해진다. 블루투쓰가 좀 많이 쓰이긴 하지만 여전히 데스크탑에서는 요원하다. 데이터의 무선 전송이야 정말 10~15년 정도 있으면 어떻게 해결이 될 것 같은데, 내가 궁금한 것은 과연 전력을 무선으로 전송할 수 있는가 이다.

이 정도는 그냥 애교지요…

실제로 어느 정도 가능한 것으로 알고 있다. 전동 칫솔의 충전은 어떠한 금속의 접점 없이 무선(?)으로 충전이 된다. 물리학 지식이 짧아 더 이상 설명하는 것은 불가능하지만, 전자기유도 현상을 이용하는 것이라 한다. 그런데 이 보다 훨씬 높은 전력도 무선으로 전송이 가능할까? 만약 이렇게 된다면, 장 시간 회의할 때도 그냥 노트북만 들고 가면 테이블 자체에서 무선으로 전기를 퍼뜨려 노트북에 전원이 공급된다면 얼마나 좋을까?

위키를 찾아보니 무선 에너지 전송에 대한 글도 볼 수 있었다. 대략 살펴보니 가까운 곳은 전자기 유도나 공명으로 되는데 먼 거리는 레이저, 마이크로파로 해야 한다고 한다. 200년 전 사람들이 지금의 무선 전화나 리모컨을 쉽게 상상하지는 못했을 것이다. 과연 우리가 죽기 전에 무선 전력 송신을 볼 수 있을지 모르겠다. 나는 살아 생전에 꼭 인류의 화성 착륙과 상온 초전도체 발견 그리고 이 무선 전력을 꼭 보고 싶은데 과연?

p.s. 사실 이사하면서 가장 힘들었던 건 레고 운반… 이렇게 한 3번 정도 날라야 했음… 아래 사진에 있는 녀석의 현재 가격만 따져도 2500불이네… 공부는 안 하고 뭐 하는 짓?