올해의 내 막무가내 계획

내가 마련한 무식한 올해 계획이다.

• 악기하나.
• 수학공부재개.
• 프로그래밍언어2개.
• 그림(스케칭)연습재개.
• Tactile문화생활.
• 독서집중력향상.
• 제2외국어재개.
• 스터디2개이상참여.
• 이외의개인적인몇가지목표상향조정.

완전 지키지도 못할 막무가내군. 내년의 나이와 내가 계획한 30대의 성취율에 맞추려면 이런 계획일 수 밖에. 보이즈 비 앰비셔스!

유니프로세서 시절의 철지난 기존 지식이지만

http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.html

이 논문에 나온 “철지난 기존 지식(Outdated Conventional Wisdom)”들을 옮겨본다:

• 전원은 공짜지만, 트랜지스터는 비싸다.
  New – “파워 장벽(Power Wall)”. 공급할 수 있는 전원보다 많은 트랜지스터를 집적할 수 있다.
• 전원에 대해서 걱정할 것은 동적 전원(Dynamic Power)이다.
  New – PC나 서버에서 샐 수 있는 정적 전원(Static Power)는 40%나 된다.
• 실리콘 Monolithic 유니프로세서는 내부적으로 안정적이고 문제는 핀에서 온다.
  New – 칩의 집적도가 65nm 이하가 되면서 높은 소프트/하드 에러율이 발생할 것이다.
• 기존 성공 위에 새로운 추상화를 얹어서 하드위어 디자인의 크기를 증가시킬 수 있다.
  New – Wire delay, noise, cross coupling (capacitive and inductive),
  manufacturing variability, reliability, clock jitter, design validation등등으로 65nm이하의 큰 디자인의 개발시간과 비용이 커지게 된다.
• 연구자(Researcher)들은 칩을 만들어서 새로운 아키텍쳐를 시연한다.
  New – 65nm이하의 공정 마스크의 비용, 이런 칩 디자인을 위한 설계(eCAD) 소프트웨어의 비용 그리고 GHz 클럭을 위한 디자인 비용등으로 인해 연구자들은 더이상 믿을만한 프로토타입을 만들기 힘들어졌다. 아키텍쳐를 시험해볼 새로운 접근이 개발되어야 한다.
• 퍼포먼스 향상은 낮은 레이턴시(latency)와 높은 대역폭(bandwidth)를 가져온다.
  New – 많은 기술들에 있어서 대역폭은 최소한 레이턴시(latency) 향상의 제곱 이상 향상된다.
• 곱셈연산(multiply)는 느리고, 적재(load)/저장(store)은 빠르다.
  New – “메모리 장벽(Memory Wall)”. load/store는 느리고 multiply는 빠르다. 모던 마이크로프로세서에서 DRAM 접근은 200클럭까지 걸릴 수도 있지만 부동소수점(floating-point) 곱셈 연산은 4클럭이면 된다.
• 컴파일러와 아키텍쳐 이노베이션으로 ILP(instruction level parallelism, 연산 레빌 병렬성)을 높일 수 있다. (branch prediction, out-of-order execution, speculation, Very Long instruction Word system사용 등)
  New – “ILP 장벽”. 더 많은 ILP를 찾는게 점차 힘들어지고 있다.
• 유니프로세서의 퍼포먼스는 18개월마다 2배가 된다. (무어의 법칙은 유니프로세서는 아님)
  New – “전원 장벽”+”메모리 장벽”+”ILP 장벽”=막다른길. 1986년부터 2002년까지는 18개월마다 2배가 되었지만, 이제는 유니프로세서가 2배가 되기위해서 5년이나 걸릴 수 있다.
• 병렬화할 필요 없이 좀 기다리면 결국 컴퓨터가 빨라져서 병렬화할 필요가 없어진다
  New – 직렬 컴퓨터의 속도 향상은 길어지고 있다.
• 프로세서의 퍼포먼스를 향상시키는 가장 좋은 방법은 클럭주파수를 늘리는 것이다.
  New – 병렬성을 늘리는 것이 프로세서 퍼포먼스를 향상시키는 가장 좋은 방법이다.
• 멀티프로세스 응용프로그램의 선형 스케일링 이하는 실패 요소다
  New – 병렬 컴퓨팅으로의 이전한다면, 병렬성을 사용한 속도 향상은 성공 요소이다.

2006년 논문이지만, 그래도 생각할 꺼리는 흡족할만큼 있다. 일부는 최근 논문을 찾아보고 Revise해봐야겠다.

2005년의 이런 글이 있긴 하지만, 소프트웨어에 있어서 병렬성의 잠재성은 아직도 걸음마 수준이고 새로운 패러다임을 찾고 있는 알파상태다. 병렬성이 이런 이유는 그 복잡성 더하기 예측불가의 불확실성일테지.

그래도 마치 모뎀이 전화선으로는 2400이 마지막이라느니 2400MNP가 최고라느니 14400은 넘을 수 없다느니, 56k가 끝이라느니 계속되는 배리어깨기처럼 인간이라는 녀석은 뭔가를 찾아 배리어를 깰 것이라는 생각을 한다. 자야겠다.

싸인 오프, Sign off!

어제는 Silverlight 2의 첫 Servicing 업데이트를 Sign off했다. Servicing이라 함은 정식 버젼 출시 이후의 문제들을 해결하는 업데이트라고나 할까, Windows로 치면 서비스 팩이나 보안 패치등이라 할 수 있겠다. 어떤 제품이든지 메이저 업그레이드와는 별도로 마이너 업그레이드와 패치등이 모두 Servicing에 해당된다. 소프트웨어가 아닌 물리적인 제품이라면 A/S에 해당할 것이지만, 소프트웨어라는 특성상 꽤 다르다.

Servicing은 예산에 굉장히 민감한 부분이기 때문에 항상 빡빡하고 욕도 많이 먹는 부분이기도 하다. Servicing이라고는 하지만, 세상에는 완벽한 제품도 없고 사용자의 요구는 무한대기 때문에, 이를 조절하는 것은 골치아픈 일이다. 예산과 리소스에 맞게 고치고 업데이트할 부분들을 잘 갖춰서 밸런싱해야하고, 어쩔 수 없이 해결하지 못한 부분에 대한 리스크를 감수해야하는 것이다. (예를 들어, 저쪽에서는 용어 하나 바꾸는 것으로 인한 기존 제품/문서 수정 비용으로 몇주째 논의…) 사용자가 천만명인데 그 중에서 십만명이 골치를 썩는 문제와 만명이 골치를 썩는 문제 두개 중에서 한개 밖에 해결할 수 없는 리소스가 어쩔 수 없이 할당되었다면, 어느 것을 고칠까? 무조건 십만명? 다양한 이유로 그렇지는 않다.

아무튼 Silverlight 2도 출시된지 좀 지났고, 중요한 버그들이 있었고 몇몇을 고치고 시장의 요구를 귀담은 수정을 내놓게 되는데 이에 대한 소프트웨어 준비가 완료되었다. Sign off를 뭐라고 번역해야할까. 사전을 찾아보면 대충 비슷한 의미의 숙어로:

《美속어》[계획 등]을 서명하지 않고 비공식적으로 승인하다.

가 있는데 이렇게 생각하면 될 것 같다. (국내 업체들에는 각 기업마다 다른 용어를 사용하겠지, 검수 혹은 결재 등) 릴리스(Release)가 있기 전에 계획(기획) 단계에서 어떤 팀들과 사람들이 최종적으로 Sign off를 하게 되는가를 정하고 이에 담당자를 할당하게 되고, 마지막 기한까지 자신이 책임진 부분에 있어서 Sign off를 하면 되는 것이다. 팀마다 제품마다 다르게, 어떤데는 툴을 사용하여 Sign off를 하기도 하고, 이메일을 많이 사용하기도 한다. Windows같은 복잡한 제품은 제품 기능별 뿐만 아니라 엔지니어링에 관련된 Sign off와 퍼포먼스/안정성/UX등의 속성들에 대해서도 각기 다른 담당자가 모두 Sign off를 해야 출시할 수 있다. 물론 나는 Loc팀의 일환으로 Sign off를 했다(Silverlight같은 제품은 글로벌 마켓의 순위가 높기 때문에 다행히 인식이 조금 높은(높아진) 편이니 다행이다).

여담] Sign off라는 말도 내가 생각한 것과 용법이 다르다. “A is signing off on B.”가 맞을 것 같지만, 내가 Sign off하는 것이기 때문인지 “A signs off on B.”라고 적더라.

모든 팀들이 Sign off를 완료하면 전체를 책임진 owner가 “Ship it” 승인을 하고, 이를 바탕으로 RTM(공장등에 CD를 만들도록 보내는 등)을 하거나 RTW(웹에 다운로드 할 수 있도록 스테이징을 하는 등)를 하게 되기 때문에 Sign off 스케줄과 출시와는 다르다. 그러니까 Sign off를 했다더라…라고 뉴스가 혹여 나오더라도 항상 바로 받아 사용할 수 있는 것은 아니다. RTW를 했다더라는 뉴스라면 그렇겠지만.

Sign off를 한 팀이라도 하지 못하고 스케줄을 정지시킬 일이 발생하면 Redmond는 난리가 난다. 모든 담당자가 모여서 우선 해결하고 임팩트를 생각한 뒤에 모든 Sign off를 취소할 것인지 결정한 뒤에 취소되면 다시 테스트 기간을 가지게 된다. 물론 팀별로 테스트 양은 책임지고 조절한다, 자기 Sign off이기 때문에. 돌려서 사악하게(?) 이야기하면 (물론 정당한 이유로) 내가 Sign off하지 않으면 출시는 미뤄질 수 있다.ㅎㅎㅎ (나는 특정 제품 그룹이 아니라 글로벌 마켓에 해당하기 때문에 한달에 Sign off를 많게는 열댓게, 적게는 한두개하니 지금까지 얼마나 많이 했을랑가ㅎㅎㅎ)

Servicing의 경우 아무런 이야기 없이 조용히 출시하는 경우도 많기 때문에 뭐가 언제 어떻게 나오느냐에 대해서는 언급하면 안되지만, 그것에 아니더라도 요즘에는 다음 버젼의 Visual Studio인 VS2010을 버즈로 마케팅 중이기 때문에 당분간은 조용히 있으리라 생각된다.

이번 테스트에서는 (우리나라와 상관 없는) 큰 변화가 있었기 때문에 그 업무량이 좀 많아져서 조금 골치가 아프긴 했다. 테스팅은 중국 테스팅 벤더와 우리나라의 팀 양쪽에서 테스팅해야되기도 하고, 원격 벤더와 일할때는 작은 디테일까지 모두 전달을 해줘야 하기 때문에 일의 양이 많으면 배가되기 때문이다. 다음 테스팅 기간에는 설 연휴가 겹친데다가 중국은 설이 엄청나게 길기 때문에 여기에 맞추는 것도 골때리는 일이다. (이에 대해서는 다음에 기회가 있으면 해볼지도)

아무튼 Sign off를 하는 것은 뭐래도 속시원한 일이다.

내 몸속의 긱코드를 만족시킬 뭔가를 찾아 헤메이다

난 긱(Geek)이고, 그게 좋다. 그 중에서도 뼈속까지 소프트웨어 긱이다. 긱 중에서도 뭔가 새로운데에 환장한다. 나에게 있어서 새로운 소프트웨어란 내가 접해보지 못한 새로운 “분야”의 소프트웨어나 기발하거나 신기한 새로운 “아이디어”의 소프트웨어다.

새로운 소프트웨어를 써보는 것이라면 그렇게 환장했었는데, 뭔가 이상하다. 소프트웨어가 발전해가면서 그 복잡성이 되려 소프트웨어의 오리지낼러티를 잃어버리는 경향을 만들어내는 것 같다는 느낌이랄까. (아니면 복잡성을 이해하지 못해서 흥미를 느끼지 못하는 것일지도…) 새로운 것을 봐도 새롭지가 못하거나 혹은 그 복잡성을 내가 쫓아가지 못해 흥미가 생기지 않거나 혹은 그냥 비슷비슷하다거나…하여튼 내 DNA에 자극을 주지 못한 소프트웨어 세상이랄까. 아니면 내가 무디어졌을지도 모르겠다.

뭔가 새로운 것이 나왔다는 소식이 어딘가에 뜨기만 하면 한번 써보지 못해 안달난 어린 시절을 기억한다(지금도 그렇지만). 8비트때는 게임보다는 코딩에만 관심이 있었지만 PC로 넘어오면서, 시에라(Sierra)의 Quest 씨리즈에 환장해서 나오면 바로 해보려고 난리였던 때도 있고, Apogee 게임 모으면서 커맨더킨같은것에 집착하던때도 있다. 많은 분들이 그때는 그랬지만, 잡지의 질안좋은 5.25인치 디스켓이 깨졌는데 실행해보고 싶어 수십페이지짜리 어셈블리 코드를 입력하던 것도 기억나고 울펜슈타인3D 만들겠다고 설치던것도 기억난다. Windows 2.0 나오고 DOS에서 돌아가는 여러가지 GUI 프로그램들을 보면서 하나 흉내내 만들어보기도 했었다. 아직도 쓸데도 없는 AutoCAD니 Lotus123 배우고, 포토샵이니 Maya니 배우고, 어떤 소프트웨어의 소스코드가 공개되었다더라라는 뉴스가 나면 눈깜빡하기도 전에 모뎀부터 연결했다. Demo Scene에 환장해서 FutureCrew의 행적을 그루피처럼 쫓아다니고 트래커를 만들어 흉내내기도 하고, irc에서 유명해커/크래커들이랑 채팅하면서 좋아라하던 때도 있다. Pixar의 Renderman(PRMan)이  처음 돌았을때 써보고 싶어 난리였던 때도 기억하고, NeXT의 WebObjects 문서들을 보고 좋아하던 때도 기억난다.

대학생들이면 누구나 한번 해보는 학교 웍스테이션 백도어 만들어 쓰면서 좋아라하던 것도 기억나고, Netscape2를 처음 접해보고 브라우저 만들겠다고 생각하고 회사에서 만들던 생각도 나고, IBM에서 eclipse가 공개되자마자 다운받아 신나하던 때도 기억난다. 맨날 하는 이야기지만, Flash의 전신인 FutureSplash라는 녀석이 나왔다는 뉴스에 처음 접하고 사장형한테 이거 살 수 없냐고 했던 때도 기억난다. OS에 미쳐서 분석하겠다고 OS 소스 구하기에 미친 적도 있으니 Linux 첫 버젼들도 집 어딘가 디스켓에 들어있고, 아마존으로 구매한 Lions Book도 있다. 지금은 죽은 수많은 유명 아카이브들 (hornet이나 fravia등) 자료들도 집 어딘가에 쳐박혀 있을게다. 코드명이 Chicago인 Windows 95의 당시 고해상도 화면을 보고 뜯어보고 싶어 미치던 때도 있고(그래서 앤드류 슐만의 Unauthorized Windows 95라는 책이 내 평생 가장 좋아하는 책이다), 뜯어보는데(Reverse Engineering)에 미쳐서 수많은 소프트웨어들을 수많은 디스어셈블러와 디버거로 뜯어보던 기억들도 생생하다(비싼 IDA도 돈주고 샀다). 아무튼 소프트웨어를 접하고 신났던 내 세대의 상황들을 계속 나열해서 수십장 써내려갈 수 있다.

그런데, 최근에는 새로운 소프트웨어를 대할때의 임팩트가 이전같지 않다. (물론, 회사 내부에서 보는 눈뒤집어지는 아이디어들을 아직도 접하면서 즐거워하고 있긴 하지만, 이는 나눌 수 없는 것들이고 회사를 옮기면 겪을 수 없다.) 새롭다고 해도 지속성도 짧고, 일때문에 파고들 시간도 부족하다. 또 나이가 들수록 그런 작업 비중이 줄어들고 줄어든다. WM해킹도, 공개 툴체인으로 건드려보는 iPod Touch 코딩도, 이전같지 않다. 매일 머릿속에 아이디어가 넘쳐도 이전처럼 기록하지도 않는다. 게다가 요즘에는 블로깅도 거의 안하는데, 하고자 하면 신선하지가 않은 느낌이 밀려드는 것이…의무감에 하는 것은 의미가 없다싶어 적다가 때려친다. 그런 기분으로 요즘에는 블로그들도 거의 잘 안본다.

정말 내 Geek-Knob에 문제가 생긴 것일까. 닳고 달은 것일까. 아니면 매너리즘?

요즘에는 그래서 뭔가 다른 곳으로 눈을 돌려보면 어떠할까 생각해봤다. 개인적인 생각이지만, 내가 컴퓨터를 전공한 것을 후회할때가 있다. 다른 뭔가 전문성을 가지고 컴퓨터를 적용해서 컴퓨터를 잘하는 것이 훨씬 더 Geeky하지 않았을까…하는 생각이다. 그래서 다른 분야를 둘러보는 이상한 작업을 한다. 마치 대학교때 과를 결정하기 위해서 고민하듯이 말이다. 대학교 입시를 공부하던때보다 세상은 정말 엄청나게 복잡해졌다는 생각을 하면서, “이건 어떨까? 이건 무슨 분야지, 무슨 학문이지?” 한다. Criminology에 관해서도 찾아보고, Anthropology에 관해서도 찾아본다. 하룬야야와 리처드도킨스 싸우는 것도 찾아보고, 혹은 세상에 어떤 언어들이 있나 찾아보기도 한다. 수학 올림피아드 문제도 한두개 풀어보고, 경계(?)하던 PC게임도 조금 한다. 여러가지를 하다보면 마찬가지로 여러가지 생각이 들고 기억들이 생각난다. 예를 들어, 내가 대학교 1지망이 화학공학과였는데, 교수님과의 인터뷰에서 왜 화공과를 지망했는냐는 질문에 “영화 특수 효과를 하고 싶었다”는 이야기를 한 것도 생각나고, 대학교 들어가자마자 1학년때 결혼해서 살꺼라는 다짐도 생각나고, 대학 들어가면 얼만지도 모르고 찝차(맥가이버가 타던)를 부모님께 사달라고 했던 기억도 생각난다.

아무튼 이런 기억들을 다시 떠올리는 것이 내 긱코드를 다시 뾰족하게 연마하는데에 도움이 될런지는 잘 모르겠다. 사는게 재미없는 것도 아니고, 일하는 것에 싫증난 것도 아니고, 하루하루가 지겨운 것도 아닌데, 이상한데서 블럭이 생겨버린 것 같아서 영 찜찜했다. 연초라 올 한해를 준비하는 기분으로 그런가 하지만, 그 와중에 이렇게 포스팅 하나 또 하게 되었으니 뭔가 있는 것은 아닐까.