액티브엑스 vs. NSAPI

코멘트 중에 모질라 및 상당수 다른 브라우저에서 사용되는 NSAPI 플러그인도 액티브엑스만큼 나쁜것 아니냐는 얘기가 있었다. 맞는 말이다. 그래서 이러한 플러그인들은 반드시 “최소한” 으로 사용되어야 한다. 현재 리눅스 64비트에서 돌아가는 내 파이어폭스에는 5개의 플러그인이 깔려 있는데, 그 중 4개는 시스템의 미디어 플레이어고, 나머지 하나는 (눈치챘겠지만) 아도비 플래쉬다.

그런데 파이어폭스 3.6 부터, 이런 플러그인들의 보안 품질 관리에 도움이 될 기능이 들어갔다고 한다. 파이어폭스가 자동 업데이트 되듯이, 플러그인들의 버전 데이타베이스를 자동으로 업데이트 해 주는 것이다. 심지어 NSAPI 가 파이어폭스 외의 브라우저에서도 사용된다는 점을 반영하여 서비스 API 까지 공개해 놨으니, 조만간 NSAPI 를 사용하는 브라우저들의 플러그인 보안 문제는 상당히 좋아질 것으로 기대된다.

반면, 내가 사용하는 버추얼박스에서 돌아가는 윈도우즈 XP 의 IE 에 깔린 액티브엑스는 17개다. 온라인 쇼핑 할때는 반드시 가상계좌이체 하는데도 이렇다. 은행에서 사용하는것 외에 일부는 회사 인트라넷에 사용되는것도 있고, 연말정산하느라 깔았다가 지웠는데 제대로 안 지워진 것들도 보인다.

이런 현실에서도 액티브엑스가 나쁜 것이 아니라고 한다면, 나도 더 할 말은 없다.

구글 넥서스 원: 빵빵한 파이프

발빼기 & 배째기: 지금 술마신 상태에서 답답한 속을 풀기위해 글을 쓰고 있는거라, 매우 불친절하게 쓰고 있다 (언제는 친절하게 썼나). 링크도 귀찮아서 안 걸지만 최소한 검색해 볼만한 키워드들은 들어있으니 알아서들 하시길. 어쨌든 평소 글보다 확실히 중구난방이긴 할테니 양해해 주세요. *굽신굽신*

북미 IT 업계의 구루들이 하는 말이 있다. “언제나 쓸 수 있는 빵빵한 파이프 내놓고 꺼져라.” (Fat pipe, always on, get out of the way). 여기서 말하는 파이프란 당연히 인터넷 파이프를 말한다. (v4 가 실용적이겠지만 v6 라도 아마 괜찮을 것이다) 통신사업자들이 자꾸 인터넷 서비스에 끼어들어서 이른바 “노상강도 사업 모델” 을 집행하지 말고, 자신들만이 할 수 있는 (그렇기 때문에 가장 잘할 수 있는) “패킷 장사” 만을 하라는 얘기다.

내가 팀 브레이 (Tim Bray) 횽아를 내 마음의 구루로 삼은 것이 언제부터인지 모르겠으나, 이 횽아는 왠지 모르게 한국에서 잘 알려지지 않은 인터넷 유명인 중 하나다. 어쨌든 팀은 통신사업자에게 패킷 장사 말고 한가지를 더 제안한다. 즉 자신의 망에서 돌아다니는 모든 “과금” 을 떠맡으라는 거다. 수수료를 떼 먹을수 있으니 통신사업자에게 좋을 뿐만 아니라, 돈을 내야 하는 창구가 단일화되니까 사용자에게도 좋은 일이다. 아이폰이든 노키아 심비안 폰이든 안드로이드 폰이든 어플리케이션을 사서 깔면 모두 전화 요금 청구서에 합쳐져서 나온다고 생각해 보라, 얼마나 편할지. 그리고 그런 “편리함” 이 모바일 어플리케이션 시장을 얼마나 키울지 생각해보라. (물론 모모한 회사들처럼 수수료를 30% 씩 처먹으란 얘긴 아니다)

말난 김에 얘긴데, 현대의 정보 시장은 기존 제조업 시장의 “가격” 과 “성능” 으로 움직이는 것이 아니다. 물론 그 두 가지도 중요하지만 그 위에 “획득 편의성” 이 그 못지 않게 중요한 요소로 동작하고 있다. 아무리 공짜 MP3 파일이 널렸다고 해도 일반인이 Tor 피어를 셋업해서 돌릴 거라곤 생각하기 힘들다. 한국 콘텐츠 시장이 근래 갑자기 암울해 보이기 시작한 것은, P2P 프로그램이 너무나 쓰기 편해진데다 정보교환 (불법) 커뮤니티들이 너무나 친절한 설명을 해 주고 있기 때문이다. P2P 사용하는거 보다 더 편하게 음악/영화/소설을 접근할 수 있게만 해 주면, 정말 곡당 천원 정도의 “푼돈” 은 누구나 낼 거다. 아이튠즈 스토어가 무슨 “대단한 기술” 로 성공했다고 생각하는 사람들을 볼 때마다 너무 답답해서 하는 얘기다.

액티브엑스

액티브엑스가 나쁜 것이 아니라는 글을 읽었다. 사실 컴퓨터 기술을 잘 모르는 사람들에게는 이런 주장도 그럴 듯 하게 들리기 때문에 혼란을 가중시키기 십상이다. 이런 주장들을 어떻게 설득할 것인가… 하나 하나 토론해 보자.

1) 액티브엑스는 하늘에서 떨어진게 아니라 OLE 의 확장이다.

맞다. 하지만 아무리 역사가 길고 좋은 기술이라도 급변하는 보안 환경에 적응하지 못한다면 이득대비 위험이 너무 크고, 제한된 환경 (인터넷을 사용하지 않는 어플리케이션이라든가) 에서만 사용되는 것이 바람직하다.

2) 액티브엑스는 단순히 IE 만을 위한 것이 아니다.

그렇다. MS 오피스 등에서도 사용된다. 그리고 같은 보안 위험을 갖고 있다.

3) 액티브엑스로 대규모 해킹 사건이 벌어지기라도 했나?

한국을 제외하면, 액티브엑스는 일반 사용자들이 쓰는게 아니라 기업의 인트라넷에 많이 사용된다. 따라서 “대규모” 해킹사건은 적지만 회사들이 얼마나 많은 사건들을 돈으로 때우고 쉬쉬하고 있을지는 모를 일이다. 기업 보안의 가장 큰 구멍이 IE+액티브엑스 라는 보고서를 분명 봤는데 찾기가 힘드네.

4) 어쨌든 액티브엑스가 뭐가 나빠서?

액티브엑스는 매우 약한 보안 모델을 갖고 있다. 쉽게 말해, “사용자가 설치를 허가한” 액티브엑스는 시스템에 무슨 일이든 할 수 있다. 법적으론 아무 문제가 없지만, 전문가가 아닌 사용자에게 모든 책임을 지우는 이러한 구조는 취약하다.

심지어 자체적으로 인터넷에서 프로그램을 받아다 설치할 수도 있기 때문에 게임 업체들이 “사용자들의 편의를 위해” 사용하고 있다. 문제는 이러한 기능을 악성코드 제작자들도 사용할 수 있다는 것이다. 현재 대부분의 봇넷들은 액티브엑스로 배포된다. 감염된 사용자의 MSN 메신저 등으로 주소록의 사람들에게 링크를 보내면, 잘 모르는 사용자들은 “설치하지 않으면 기능을 이용할 수 없다” 는 문구에 협박당해 (어디서 많이 보던 문구 아닌가?) 주어진 액티브엑스에게 설치허가를 내주기 마련이다.

정상적인 액티브엑스 콘트롤이라도, 품질 관리의 문제가 심각하다. 인트라넷에서 많이 사용되는 콘트롤들 중 악용할수 있는 보안 구멍이 있는 콘트롤들은 악성코드 제작자들에게 널리 알려져 있다. 심지어 MS 가 직접 개발한 액티브엑스 콘트롤도 보안 문제가 있고, 이것을 악성코드 제작자들이 이용 하기도 한다.

5) 자바, 자바스크립트, 플래쉬도 마찬가지 아니냐? 그것도 액티브엑스로 돌아가는것 아니냐?

IE 를 위한 자바와 플래쉬 액티브엑스 콘트롤은 썬 (Sun) 과 아도비 (Adobe) 의 주요 사업 분야중 하나다. 따라서 해당 프로그램에 보안 위협이 알려지면 상당히 빨리 업데이트하고 있기 때문에 위에서 언급한 문제는 적다. 이것은 파이어폭스용 플러그인도 마찬가지다.

자바/자바스크립트/플래쉬로 만들어진 “어플리케이션” 들의 경우엔 프로그래밍 API 및 모델에 의해 할수 있는 일이 매우 제한되기 때문에 보안 위험이 적다. 물론 없는건 아니지만 최소한 봇넷은 깔 수 없잖나.

6) 웹 표준은 변한다. XMLHttpRequest 도 액티브엑스로 가능해졌다.

물론 웹 표준은 발전한다. 지금도 HTML5 WG 가 다음 세대의 HTML 을 다듬는 중이다. 이렇게 해야 더 빠르고 편하게 웹 어플리케이션을 개발할 수 있고, 악성코드 제작자들이 나쁜 코드를 만들기가 힘들어진다.

하지만 당신이 액티브엑스로 IXMLHttpRequest (맨 앞 i 에 주의) 를 사용하는 IE5 를 사용하고 있다면 당신은 과거에 살고 있다. 과거가 좋은 경우도 있지만, 최소한 기술 세계에서는 “과거” 는 거의 언제나 현재보다 나쁘다. 보안 위험은 말할 필요도 없다.

흔히 파이어폭스가 IE 보다 보안측면에서 낫다고들 말하지만 과거 버전들에는 잘 알려진 보안 구멍들이 꽤 있다. 이것을 빨리 해결하고, 보안 문제에 둔감한 사용자들에게도 자동 업데이트 기능을 제공하기 때문에 파이어폭스가 비교적 안전한 것이지 무안단물이라도 뿌려서 안전한건 아니다.

---

정리하자면 문제는 “품질 관리” 다. 하늘아래 완벽한 소프트웨어는 없고 문제가 발견될 때마다 열심히 고치는 수밖에 없다. 하지만 그렇게 열심히 고칠 수 없는 소프트웨어라면 시스템적으로 제한을 걸어서 애초에 큰 피해를 입힐 수 없게 하는것이 안전하다. 액티브엑스는 이 두 가지 조건을 만족시키지 못하는 기술이기 때문에 보안 전문가들이 가장 싫어하는 기술로 남아있는 것이다.

윗 글에서 한가지는 맞다. 웹 기술은 변하고, 그렇게 변하는 현실을 웹 표준이 반영한다. 그렇기 때문에 구시대의 기술인 액티브엑스를 계속 가져가는건 한계가 있다는 거다.

In Search of an Application

아르스 테크니카 (Ars Technica) 에 이런 글 이 올라왔다. 현재 엔비디아 (NVidia) 의 최고급 라인인 콰드로 (Quadro) FX 4800 맥 에디션의 벤치마크인데, OS X 기본 드라이버의 성능 문제가 많아서, 이번엔 엔비디아가 직접 제공한 드라이버를 사용해 본 벤치마크 기사이다. 이 기사를 읽고 만감이 교차했다.

기사를 읽어보면 알겠지만 맥 OS X 위에서 1080p H.264 변환 (LV 4.1) 을 하는데, CUDA 로 돌린 것이 10분 11초가 걸렸고 CPU 인코더를 사용한 것이 11분 03 초가 걸렸다. CPU 는 네할렘 2.66 GHz 옥타코어 (8코어) 였다. 네할렘 옥타코어는 SMT 로 16 개의 코어처럼 돌아가니까 반칙이라고 말하는 사람이 있을지도 모르지만, 원본 디코딩에만 CPU 를 50% 가까이 사용했다는게 문제다. 콰드로를 사용할 때도 그만큼 CPU 가 소비되었으니 CPU 만 사용할 때도 그만큼 소비되었다고 생각하는게 정상이다. 물론 PCI-E 버스로 데이타 보내는데 들어간 스핀록 (spin lock) 시간은 빼야겠지만, 그러든 말든 콰드로의 H.264 인코딩 능력이 일반 CPU 옥타코어보다 떨어진다는 것은 굴욕이 아닐 수 없다.

아니면, 같은 하드웨어로 윈도우즈 CUDA 드라이버를 사용하면 더 빨라질 수 있을지 모른다. Maya 2010 7M Poly fly-by 벤치마크에선 윈도우즈 쪽이 2배 가까이 빨랐다고 하니까. 마침 그런 벤치마크가 있길래 찾아봤더니 43초 vs 33 초로 엔비디아 쪽이 더 빠르긴 한데, CPU 가 옥타코어가 아닌 쿼드코어다. 미디어 인코딩은 거의 무지막지 파라렐 (embarrassingly parallel) 범주에 들어가니까 코어 수가 두 배가 되면 거의 두배에 가깝게 빨라질텐데, 그렇게 되면 오히려 네할렘 쪽이 CUDA 보다 더 빨라질 수도 있다. 으음…

가격을 생각해 봐도, 콰드로 FX 4800 은 구글 검색해 보면 $1200 인데 인텔 E5520 (2.26GHz 쿼드코어) 가 $925, 두 개를 달아서 옥타코어를 만들면 $1850 이다. 하지만 FX 4800 은 어차피 CPU 가 없으면 동작하지 않는다. 게다가 소프트웨어 가격을 생각해 보자. 물론 일반 CPU 에서 멀티쓰레드 프로그래밍 하는것도 장난은 아니지만, 그보다도 “10배 어렵다” 고 말하는것이 CUDA 플랫폼의 현실이다. 게다가 지난번에도 얘기했다시피 현재 네할렘은 차세대 SIMD 인스트럭션인 AVX 를 갖고 있지도 않다 (SSE4.2 를 지원한다). 물론 SSE4 에 동영상 인코딩 (block alignment) 명령이 있다지만, 그리고 AVX 명령어 인코딩이 꽤 길긴 하지만, 어쨌든 벡터 길이가 두 배로 늘어나는데다 3 op (x = a op b) 명령을 지원하니까, 설마 딱 두배나 빨라지진 않겠지만 (명령어 인코딩이 꽤 길어서 L1I 에 부담이 된다) GPGPU 진영이 경쟁하려면 훨씬 강력하고 프로그래밍하기 쉬운 — 즉 소프트웨어 가격이 싼 — 아키텍처를 만들지 않으면 안된다.

그러니 이런 상황에서, 그래픽스 말고 대체 어떤 어플리케이션이, 날이 갈수록 무식하게 코어 수 + 벡터 길이가 늘어가는 CPU 에 맞서 CUDA/CELL/GPGPU 아키텍처의 가격 경쟁력을 담보해 주고, 차세대 아키텍처 개발이 가능할 만큼의 시장 크기를 제공해 줄 것인가? 가히 현재 기준으로 $3.424B  – (테그라 + Ion) 짜리 질문이 아닐 수 없다.

이 문제에 더 생각해 보고 싶은 분들은 RWT 의 이 글을 참고하시는 것도 좋겠다. 숫자들이 딱 정확한 것은 아니라는 생각이 들지만, 참고가 될 것이다.

라라비, 인텔, 엔비디아

세시아군이 내 떡밥을 물었네. 얘가 웬일이지. 여튼 이런 주장이 나왔다.

… 라라비를 개량해 vector 연산 코어로서 CPU와 융합시키는 방향으로 나갈 것이라는 것. 인텔이 라라비를 연구/개발하는 목적도 HPC도 그래픽스도 아닌, client 에서의 워크로드 성능 향상을 위한 것이기 때문에.

몇 가지 고려할 점들:

• 기존의 인텔 그래픽 칩은 꽤 구형 프로세스로 찍어냈다. 라라비는 최신 (45nm) 프로세스다. CPU 와 융합하려면 당연히 그래야 한다.
• 언제나 그렇지만 최신 프로세스에서 새 칩을 찍어내는것은 높은 리스크와 높은 개발비를 감당해야 한다.
• 높은 개발비를 감당하려면 대량으로 팔아야 한다.

“클라이언트 워크로드” 라는 말을 하기는 쉽지만, 1) 네할렘 코어가 견딜 수 없으면서 2) 라라비 구조에서 해결할 만하며 3) 대다수의 사용자들에게 필요해서 기꺼이 돈을 지불할 만한 워크로드가 그래픽스 외에 어떤게 있을지 난 별로 상상이 안간다. 현재의 네할렘이 처리하기 힘든 워크로드를 찾았다고 안심해도 곤란하다. 향후의 네할렘에 들어갈 AVX 로도 처리하기 힘든 워크로드를 찾아야 한다. “기껏해야 1080p” 동영상 돌리자고 라라비같은 전력 관리 어려운 칩을 사용하는 것은 곤란하다. i5 에서 SSE3 소프트웨어 H.264 코덱 돌려도 1080p 동영상 잘 보인다니까. 대다수의 사용자들이 1080p 실시간 인코딩 (디코딩 말고) 을 원할거라고 생각되지도 않고. 설마 CPU 와 퓨전하기만 하면 싫어도 사야하니까 (외부 GPU 는 여전히 필요해도) 상관없다고 생각하는 사람은 없을터이다. 그랬다간 AMD 퓨전 프로세서에 깔끔히 발릴테니까.

그렇다고 값을 낮추기 위해 구형 프로세스에서 찍는 길을 간다면 네할렘 코어와 퓨전은 물건너 가는거다. 같은 다이 (die) 에 넣을수도 없고, MCM 으로 만들기도 애매하고… 다른 프로세스로 만든 다이를 MCM 으로 만든 회사가 있었는지는, 나는 모르겠지만, 전력 요구사항이 다를텐데 어렵지 않을까?

차라리 HPC 시장은 작아도 마진이 높으니까, 개발 난이도에 비해 성능이 나와 주기만 하면 (즉 절대 성능이 CELL 보다 못해도) 장사 할만 할 것이다. 하지만 미국 국방부가 PS3 를 대량으로 구매하는 거지근성을 발휘하는 요즘 세상에 손해나 안보면 다행인가… 여하간 앞으로 나올 HPC 라라비1(.5?) 은  HPC 에 꼭 필요한 ECC 인터페이스를 달고 나오지 않을까 싶다. 이 부분에서 실제 릴리즈가 늦어질 것이고.

그런데 짜잔. 여기서 등장하는 새 떡밥 하나.

… 언젠가부터 (라라비는) 엔비디아를 향한 무기가 아니라, 인텔이 엔비디아를 사는걸 방해하는 장애물이 되었다. 그래서 라라비는 사라져야했다. 그 칩만 없으면 인텔은 반독점법을 적용하려는 법무성과 연방통상위원회의 눈에 훨씬 덜 띄게 된다.

흠좀무.

사실 라라비 없다고 반독점에 안 걸릴거라고는 생각하지 않는다. AMD 와는 달리 어쨌든 인텔에겐 GMA 도 있고, 그걸로 그래픽스 시장 대부분을 점유하고 있는 현실이니까. FTC 가 성능 따지고 있겠어 시장 규모 따지지. 게다가 아톰이 엔비디아 테그라 (Tegra) 와 같은 모바일 시장에서 아톰으로 싸우고 있는건 안 걸릴까? 떡밥은 떡밥일 뿐 오해하지 말자!

한편 세시아군은 라라비의 향후 아키텍처가 셀과 비슷한 DMA 형태로 될거라 보는데, 다른건 몰라도 일관 캐쉬 구조는 포기할거라 생각지 않는다. 그걸 포기한다면 인텔은 차라리 라라비 프로젝트 전체를 폐기할 가능성이 높다. (그렇게 되면 SCC 에 박차를 가하게 될까?) 일관 캐쉬 구조 자체가 성능에 걸림돌이 되지는 않는다. 그보다는 코어들을 링버스 (ring bus) 로 연결한 것이 패착이었다고 본다. 설마 과거 SGI 인피니트리얼리티 (InfiniteReality) 엔진이 링버스라고 그냥 베낀건 아닐텐데, 왜 그랬는지는 미스테리. 대부분의 데이타를 서로 공유하지 않는 워크로드긴 해도, 한번 캐쉬 일관 (cache coherence) 트래픽이 발생하면 생각하기도 싫은 레이턴시가 걸릴텐데 말이지.

ps. 관련 상황이 너무 바쁘게 변하는 관계로 일단 여기서 글을 끊는다. 조만간 관련 글을 올릴께요— 라고 해봤자 누가 본다고.

물리화: 하드웨어 가속 가상화

가상화가 데이타센터에서 인기라고 한다. 하나의 인터페이스로 모든 게스트 OS 를 관리할수 있고, 기계 성능이 따라가 주고 게스트의 요구량이 낮다면 실제 CPU 코어 수 보다 게스트에게 더 많은 코어를 할당하는 오버코밋 (over-commit) 해서 효율을 높일 수도 있다.

하지만 이걸로 잃는 성능도 많다. 특히 CPU 의 경우엔 VT-x 등의 하드웨어 지원으로 상황이 많이 나아졌지만 I/O 의 경우엔 애초에 하드웨어의 대역폭이 정해져 있으니 어떻게 쪼개도 느려지는건 당연지사다. 이렇다 보니 많은 양의 디스크/넷웍 I/O 를 처리해야 하는 인터넷 회사들 대부분은 (최소한 내 주위에선) 가상화를 사용한다는 얘기를 못 들어봤다. 거의 유일한 예외가 하둡 클러스터를 가상화 서버들 위에서 돌리는 건데, 하둡의 리소스 관리 기능이 약하다 보니 이렇게라도 분배해 보려는 것이지, 높은 성능이 필요한 클러스터에서 사용하는 경우는 못 봤다. 연구/교육용 으로만 사용할 뿐.

이런 면에서 요즘 슬금슬금 얘기가 나오는 “물리화” 는 하드웨어로 가속하는 가상화라고 부르면 어떨까 싶다. 이것은 아톰 같은 모바일 CPU 를 사용해서 기존보다 저전력인 서버들을 기존보다 더 많이 하나의 랙에 때려넣는 방식이다. 보통의 1U 랙 공간에 여러 개의 서버를 쟁여넣는 식이니 가상화와 비견될 만 하다. 현재 SGI (구 Rackable) 이 과 델 (DELL) 등이 이런 제품을 내놓고 있다고 한다.

근데 생각해 보면 어디서 많이 본거 같은 형태다. 0.5U 서버를 가장 먼저 개발해서 사용한건 구글 아니었나? 웹 서비스처럼, 적당한 CPU 로드와 높은 I/O 로드가 필요한 곳이라면 가상화 보다는 물리화가 더 알맞다는 반증 아닐까. “적당한 CPU” 의 버스 (FSB) 가 느릴 경우엔 I/O 에서도 신형 CPU 보다 손해를 볼 수 있지만 어차피 결국은 디스크/넷웍 속도에 묶인 신세라서.

이런 점에서, 앞 글에서 얘기한 인텔의 SCC 는 다시 쳐다볼만 하다. 온 칩 넷웍 스위치들이 얼마나 성능을 내주느냐에 따라 아톰 CPU 를 사용한 물리화 서버들 보다 훨씬 경제적인 솔루션이 될지도 모른다. 어차피 x86_64 도 안 되는 인오더 CPU 지만 그거야 아톰도 대부분 비슷하고… 오히려 문제는 디스크 인터페이스가 어떻게 되느냐인데, 일반 SATA 인터페이스가 3Gbps 니까 온 칩 넷웍을 10Gbps 까지 올릴 수만 있으면 어떻게든 (쉽진 않겠지만) 해결되지 않을까 싶다.

뭐 이러니 저러니 해도 IBM z 시리즈의 VM 이 섹시하긴 하다. CPU 만이 아니라 I/O 채널도 각각 VM 에 할당할 수도, 오버코밋할 수도 있다니까.

병렬 컴퓨팅

발빼기: 난 병렬 컴퓨팅에 대해선 약간의 경험이 있지만 그래픽 하드웨어에 대해선 줏어들은 것 밖에 모른다. 따라서 지레짐작이 많이 들어간 글이니, 에누리 많이 하고 읽으시길.

발빼기2: 하긴 내가 이 블로그에 쓰는 글 대부분이 지레짐작이다.

인텔이 라라비를 일반 사용자용으로 생산하지 않고 HPC 용으로만 생산하겠다는 결정을 내렸다. 데이빗 칸터의 분석으로는 개발 기간이 오래 걸리는 바람에 경쟁력이 없어서 이렇게 된 거라고 하고 있는데, 내 생각은 그보다는 약간 더 비관적이다.

사실 GPGPU 라는 것은, HPC 용의 칩을 만들고 싶지만 그 시장은 너무 좁으니 사용자 그래픽 시장에 편승하겠다는 의미다. 그 과정에서 미래 핵심 기술인 병렬 컴퓨팅에 필요한 소프트웨어 및 플랫폼 기술을 확보하겠다는 얘기고.

그런데 3D 그래픽 분야가, HPC 기술을 확보하는데 적당할 만큼 하드웨어 기술적으로 비슷한지 모르겠다. 그래픽 처리를 위해서는 벡터/매트릭스 처리 능력도 중요하지만 그 못지 않게 텍스처/래스터라이저, 그리고 DX11 환경에서는 테셀레이션 능력도 중요하다 (고 한다). 현재 PC 그래픽 시장의 최강자인 RV870 은 이 세 가지를 모두 전용 하드웨어로 처리하고 있는데, 라라비는 이 부분을 (텍스처를 제외하고) 하드웨어가 아닌 소프트웨어로 처리한다고 한다. GPU 보다는 HPC 성능에 초점을 맞춘 칩이다 보니 이런 결정을 내린거 같은데, 이러다 보니 그래픽 시장에 중요한 전용 하드웨어를 충분히 갖춘 ATI 칩보다 성능이 떨어질 수 밖에 없다. 그렇다고 필요한 하드웨어를 모두 포함시키다 보면 ATI 칩보다 차별화를 하기가 쉽지 않다. 이런 저런 고려 끝에 HPC 시장에만 공급한다는 강수를 둔 것으로 보인다.

그래도 나는 언젠가 라라비 (버전 3? 4?) 가 테셀레이터/래스터라이저와 H.264 코덱까지 하드웨어로 갖추고 시장에 나왔으면 한다. 그렇게 해야만 그래픽 시장에서 통할 수 있고, 그 시장을 발판으로 양산 가격을 확보하여 HPC 시장에도 나갈 수 있으니 말이다. HPC 에서 사용되지 않는 실리콘이 잔뜩 붙는다는 문제는 있지만 그 시장은 그 정도의 프리미엄은 감수할 수 있는 시장이니까.

내가 라라비에 이렇게 집착하는 이유는, 최초로 양산되는 일관 캐쉬 (Coherent Cache) 벡터 머신이기 때문이다. 지금까지 양산된 벡터 처리 칩은 IBM 의 CELL 과 NVidia 의 테슬라 플랫폼이 있는데 (ATI 칩은 아직 OpenCL 드라이버 완성도가 떨어진다고 들었으니 생략), 둘 다 일관 캐쉬가 없기 때문에 프로그래머가 다루기가 쉽지 않다. NVidia 의 경우엔 CUDA 라는 플랫폼으로 하드웨어를 숨겨놨으니 그나마 평가가 괜찮지만, CELL 의 경우는 아예 “프로그래머에게 적대적” 이란 소리마저 듣는 판국이니.

그런데 CELL 로 시작된 이 GPGPU “시장” 은, 가만히 들여다 보면 하나의 패턴이 있다. CELL 도 처음엔 모든 것을 소프트웨어로 처리하는, CPU/GPU 를 겸하는 칩이라고 홍보했지만 결국 PS3 의 그래픽 대부분을 래스터라이저/텍스처 엔진이 달린 전용 GPU 가 처리하고 있다. 라라비도 그 경로를 따라가는 듯 하고, NVidia 의 페르미도 같은 수순을 밟으면서 끝없이 지연되는 중이다. AMD/ATI 를 제외한 대형 로직 칩 업체 세 군데가 모두 “소프트웨어 GPU” 라는 콘셉트에 낚였다고 봐야 할 판이다. 인텔 입장에선 AMD 까지 낚이는게 좋았을텐데.

여기서 조금 다른 얘기.

인텔의 다른 한편에선 테라스케일 SCC (Single Chip Cloud) 라는 꽤 괴랄한 칩을 만들어서 연구용으로 제공하고 있다. 한편에선 이것이 메시지 패싱 병렬처리에 사용될 칩이라고 말하고들 있지만, 그보다는 인텔이 붙인 이름 대로 “칩 하나에 넣은 데이타서버” (정확히는 랙 하나) 라고 보는게 맞을 듯 하다. 이전의 테라스케일 칩에서도 TCP/IP 스택을 하드웨어 가속하는 등의 얘기를 하고 있었으니, 코어 간 통신 대부분은 TCP/IP 스택을 통할 거라는 예측도 가능하다. 물론 MPI 를 깔아서 사용하는걸 말릴 사람은 없지만, HPC 에 사용하기엔 개별 코어가 너무 느려 보인다. 하둡 같은 (개별 CPU 는 비교적 적게 사용하는) 대용량 데이타 처리라면 몰라도 말이다. 문제는 이런 용도에 기존의 캐쉬 공유 (Shared Cache) 하드웨어에 버추얼 넷웍 인터페이스를 사용하는게 빠를지 SCC 처럼 메시지 패싱 넷웍을 하드웨어로 만드는게 빠를지인데. 공학의 전가 보도인 “워크로드 따라 달라요” 라고 할 밖에는…

트리 형태의 캐쉬 공유 구조라면 O(log(n)) 번 데이타가 오갈텐데 메쉬라면 O(sqrt(n)) 번 오가야 하니까 더 느리다고 말할 수도 있겠지만 그건 레이턴시 얘기고 대역폭에서는 (최소한 이론상으론) 잇점이 있을수 있으니, “최소한 SQL DB 는 돌리지 마세요” 밖에 확실한 얘길 할 수가 없다. :-P

미디어 스트리밍 서비스

얼마 전에 last.fm 한달 이용권을 끊었다. 이것은 사용자가 평소 듣는 음악을 사이트에 등록해 주면 (이 과정을 scrobble 이라 한다), 그걸 바탕으로 해서 사용자가 좋아할 만한 음악을 골라서 라디오로 틀어주는 서비스이다. 워낙 국내에 CD 가 잘 들어오지 않는 팝 아티스트 음악만 골라 듣는 꼬인 취향이다 보니 이런 서비스가 매우 소중하다.

하지만 문제가 있는게, last.fm 은 상당히 많은 음악을 보유하고 있긴 하지만 그럼에도 중간 중간 메이저 아티스트들의 음악을 들을 수 없는 경우가 생긴다. 위키페디아를 찾아보니 3백5십만개의 트랙을 갖고 있다는데, 비슷한 서비스인 lala.com 의 8백만 트랙 에 비교하면 아무래도 밀린다는 인상이다. 현재 미국 시장에서 가장 인기있다고 알려진 padora.com 은 겨우 5십만 정도인거 같긴 하지만…

그런데 오늘, 애플이 lala.com 을 살지도 모른다는 얘기가 나왔다. 이렇게 되면 이 시장의 판도가 바뀌게 된다.

last.fm 의 소프트웨어는 사용하기 쉬운 편이긴 하지만, 그래도 “scrobble” 과정이라든가 호환 소프트웨어 등의 문제는 일반 사용자가 쉽게 이해할 수 있는 것은 아니다. 그런데 이러한 사용자 데이타가 많지 않으면 사용자가 좋아할 만한 음악을 찾을 수 없다. 현재도 이런 문제는 쉽게 찾을 수 있다. 한국 아티스트가 한 사람이라도 들어 있으면 별로 관계 없는 한국 아티스트들도 추천 라디오 (Recommended Radio) 에서 나오는 것이다. 대부분의 사용자가 비 한국인이다 보니, 한국 문화에 관심있는 사람들이 한국 음악 아무거나 섞어서 듣기 때문에 생기는 현상이라 본다.

pandora.com 은 이런 문제를 해결하기 위해 음악을 분석해서 비슷한 음악들끼리 모으는 작업을 하고 있다. 다만 이것이 인공지능 형태다 보니 생뚱맞은 트랙을 추천할 가능성이 있고, 그럴 경우 사용자의 피드백을 받아 수정하는 메카니즘인 듯 하다. padora.com 은 한국에서 사용할 수가 없다 보니 정확히는 모르겠지만.

한편 lala.com 은 원래 중고 CD 트레이딩 사이트였다가, mp3 업로드 & 스트리밍 사이트였다가, 현재는 mp3 를 구매해서 스트리밍하는 사이트로 바뀌었다고 한다. 사용자 프로파일링 하면 추천 메카니즘도 만들 수 있겠지만 현재는 그런 서비스를 하는지는 모르겠다.

애플이 lala.com 을 사게 되면, 8백만 곡의 라이센스를 확보한 lala.com 이라면 아이튠즈 스토어에 있는 거의 모든 곡들을 스트리밍 할 수 있을거라 생각한다. 즉 이제 사용자는 음악을 사서, 다운로드 받아서, 다시 아이팟에 싱크 시켜 들을 필요 없이, 음악을 한번 사 놓기만 하면 얼마나 많은 음악을 샀던 간에 어디서든 네트웍으로 들을 수 있게 되는 것이다. 음악을 더 이상 들고 다니지 않아도 되니까 남는 용량에는 더 많은 어플리케이션을 설치할 수도 있다. 게다가 지금까지 쌓인 수많은 사용자들의 구매 패턴을 분석해서 쉽게 추천 트랙을 만들 수도 있고, 이런 트랙들을 틀어주면 전반적인 음악 판매량 상승에도 도움이 될 것은 자명하다.

아직도 한국의 모바일 미디어는 DMB 를 위주로 생각하고 있는 것 같다. 하지만 사용자 입장에서 “방송” 형태의 모델은 더 이상 구미에 맞지 않는 서비스다. 내가 무엇을 언제 원하든 공급자가 공급하는 시간에 묶여 있어야 하는 것이다. 유선 미디어는 IPTV 가 제공하고 있긴 하지만 각 가정에 겨우 1 채널 들어갈까 말까 한 IPTV 보다 1인 1대를 가진 모바일 시장에서 스트리밍 서비스가 빨리 제공되어야 한다. 한국 디지탈 음원 시장은 누가 1인자인지 모르겠는데, 벅스 같은 비교적 개방적인 회사에서 빨리 스트리밍 서비스를 해 줬으면 싶다. 물론 음저협과 추가 협상을 하긴 해야겠지만, 최근의 아이폰 열풍에 벅스 라디오 서비스가 편승할 수도 있지 않을까.

더불어, 음악 만이 아니라 TV 의 많은 콘텐츠도 다운로드가 아닌 스트리밍 형태로 서비스를 바꾸는게 나을텐데, 하나같이 자사 플랫폼에 콘텐츠를 꽁꽁 묶어둘 생각들만 하고 있으니.

Karmic XMonad

회사에서 갑자기 Full HD 24 인치 모니터를 던져주는 바람에, 윈도우 관리에 애로사항이 꽃피었다. 예전 1280×1024 17 인치 시절에는 모든 윈도우를 최대화하고 사용하면 됐지만, 가용 면적이 거의 두배에 가까운 모니터에서 그렇게 할 순 없는 노릇.

그런데 JM 님이 xmonad 를 강추하길래 일단 삽질로 돌려보니 꽤 괜찮다. 하지만 .xsession 에 넣는 방식으로는 카르믹에서 동작하지 않고, gdm 에서 XMonad 세션을 선택하면 gnome-screensaver 도 뜨지 않기 때문에 화면 잠그기를 할 수가 없다. 그래서 정상적인 GNOME 세션에서 metacity 자리에 XMonad 를 돌리는 방법을 찾아 헤맸다. 이렇게 하면 된다.

• gconf-editor 를 사용해서, /desktop/gnome/session/required_components/windowmanager 의 값을 metacity 에서 gnome-wm 으로 바꾼다.
• $HOME/.xprofile 이라는 파일을 만들고 그 안에 export WINDOW_MANAGER=xmonad 라고 넣는다.

이제 gdm 화면에서 정상적으로 로긴하면 xmonad 를 쓸 수 있다. 더 좋은 점은, 앞으로 윈도우 매니저를 바꾸고 싶으면 $HOME/.xprofile 안의 값만 바꾸면 된다는 것.

근데 /desktop/gnome/session/required_components/windowmanager 값이 원래 gnome-wm 이라야 할거 같은데, 이거 버그 아닌가 모르겠네.

또 한가지 문제: Gwibber 는 트레이 아이콘 클릭해서 윈도우 숨기기가 제대로 동작한다. 근데 Empathy 는 “Unknown ClientMessageEvent 257″ 라는 메시지만 남기고 안된다. 왜 이럴까.

키보드 배틀의 구조

슈타인호프님이 무명씨라는 사람과 키배 붙은 덕분에 옆에서 구경하는 나같은 사람도 일제시대의 교육 구조에 대한 상당한 정보를 알게 되었다. 이 아니 기쁠 손가.

그렇긴 해도 이 무명씨라는 사람이 대체 무슨 생각으로 이렇게 물고 늘어지는걸까 보다가, 댓글에서 옛날 키배 흔적을 발견했다. 그런데 당시 키배 상대였던 진명행이라는 사람이 이 글에 남긴 코멘트를 보고, 눈이 확 떠지는 느낌이었다. (오타는 원래부터, 강조는 내가)

Commented by 眞明行 at 2008/10/28 01:26

아아.. 참..ㅋㅋㅋ.. 메카시즘이라는 용어를 만들어냈던 사람들이 결국 간첩이었다는 사실은 얘기안하시네. 단일결정론을 들먹이는 것을 보니 들은 건 있나보네요? 생긴대로 사세요.

아 그리고 주변지식을 다양하게 접한 사람의 블로그 내용이 그 꼬라지 입니까? ^^

오호라.

흔히 키배를 논쟁이라고 부르는 사람들이 있는데, 이들은 “논쟁” 을 하려는 것이 아니다. 이들은 한국 사회 나아가 세계에서 빨갱이 (또는 파시스트, 또는 식민사학자, 또는…) 를 몰아내겠다는 원대한 의지를 갖고 “투쟁” 하고 있는 것이다. 원대한 정의를 위해 투쟁하고 있는데 사실관계나 논리 같은 것은 “잠깐 희생해도” 되는 건 당연하다. 한국 사회의 근대화를 위해 노동자들이 “잠깐 희생” 했듯이. 흔히 이들이 동문서답하는 모양을 두고 지능이 떨어진다고 생각하는 사람들이 있는거 같은데 천만에. 이들은 “철인” 의 길을 걷고 있는 것이다.

따라서 이들을 설득하려는 것은 헛수고다. 범인 범부가 이들에게 할 수 있는건 그저 이들의 투쟁 상대를 파악하고 투쟁 의도 자체를 희화화하는 것 뿐.