Sandy Bridge Architecture

사실 최근에 나온 Intel의 Sandy Bridge를 제대로 살펴본 적이 없었고, 그냥 mega trend인 GPU 통합 정도만 생각했었는데, 생각보다 변한 것이 많은 architecture군요.
아래 기사를 쭉 읽어 보았는데, 오랫만의 intel의 새로운 microarchitecture라는 표현까지 있네요. 사실 P4에서 speed-daemon approach로 밀어붙였다가 피를 본 이후로(프레스핫이라는 명예로운 별명과 함께), Pentium Pro에 기반을 두고 notebook용으로(당시는 mobile용이라 표현을..) 발전시킨 architecture를 core-duo에서 전격적으로 채택해서 살아나고..
여하튼, 이번이 (processor의 microarchitecture의 측면에서는) 실질적으로 새로운 step이라 할 수있다네요.
느낌상으로는 Bulldozer가 더 우아해보이긴 하지만 약간 고전적인 느낌이고, 여러가지 tool이 보강되었다는데서는 sandy bridge가 더 재미있을듯합니다.
언제나 그렇듯이 언젠가 한번 제대로 review해 보겠다는 공수표를 한번 날리죠 (그렇더라도 위의 기사보다 잘쓸 자신은 없네요 🙂 )

Code 예약 판매 시작!

그동안 블로그를 조용하게 만든 주범(?)인 책이 나왔습니다.

찰스 펫졸드의 원작인 Code라는 책인데, 여차저차해서 인사이트 출판사의 의뢰로 번역을 시작해서(솔직히 너무 쉽게 생각했죠. ㅋㅋ) 오랜시간을 거쳐서 마무리 단계입니다.
10월 11일 출간 예정이니, 마지막 인쇄 후 교정 정도가 한번 더 남아있을 것 같습니다.
이 책을 처음 접한 것은 상당히 오래되었는데, 대략 2001년이나 2002년 정도였을 것 같습니다.
당시 도서관을 들락거리면서 관련 개론서적이 있으면 읽는 요상한 취미를 가지고 있었는데요.. 예전에도 블로그에서 간단히 적었던 기억이 있습니다만, 개론서를 쓰는 사람에 따라서 같은 사실이 전혀 다르게 묘사되는 것, 그리고 완전히 다른 시각에서 같은 부분을 바라본다는 점에 흥미를 느껴서 많은 개론서를 읽었습니다.
(가끔은 뭐 쫌 그런책들도 있지만, 이미 어느정도 안다고 생각하는 부분을 “대가”의 다양한 시선으로 재구성해본다는 것이 재미있었고, 지금 생각해보면 저에게 아주 많은 도움이 되었던 거죠)
여하튼, 펫졸드의 CODE는 그러던 와중에 잡혔던 책입니다.
아주 아주 독특한 설명의 책이지요. (성격을 규정하기 좀 어렵기도 하구요..)
솔직히 아키텍쳐하는 사람의 입장으로는 “디지털 시스템 강의를 들어도 이해 못하겠다고 하는 애들 보여주면 좋아하겠네..”에서 출발했던 책이고, 비슷한 형태로 추천했던 것 같습니다. 물론, 몇몇장은 스킵하라는 친절한 설명과 함께 말이죠.. (이 책은 고상하게 이야기하자면 정보이론도 있고, 디지털 시스템도 있고, 컴퓨터 아키텍쳐도 있고, 운영체제도 있고.. 이런데, 실질적으로는 이야기책입니다. 그래서 디지털 전공하는 친구들이 어려워할만한 부분은 “귀찮으면 그냥 뛰어넘어도 무방하지 않을까?.. “라는 설명을 해준 거였죠.)
이 책을 번역했고, 출간된단다.. 라는 이야기를 하고나서 가장 많이 들은 이야기가 바로 “우와~ 어려운 책을 번역했네”입니다.
아.. 오해가 있으실까봐 덧붙이자면.. 읽어보지 않은 분들 혹은 비전공자 분들을 위주로 나오는 반응이죠.
CODE라는 용어가 참 어렵게 느껴지나봅니다. 부제로 적혀있는 “하드웨어와 소프트웨어에 숨어 있는 언어”라는 말도 왠지 좀 있어보이구요.
하지만, 이 책 CODE는 실질적으로 이야기 책이며 아주 쉬운 책으로 출발합니다.
이야기 책이라는 의미는 “전공자이든 전공자가 아니든 부담 없이 읽을 수 있다”는 이야기인데, 단호하게 “아주 쉬운 책이다”라고 이야기하지 못하는 이유는 중간에 약간 약간 어려운 부분이 나오기 때문입니다.
특히 논리회로를 이용해서 연산기 설계해서 프로세서로 확장하는 부분이 있는데, 이 부분은 스킵하고 넘어가도 크게 지장은 없지만 제대로 보시려면 이야기책 치고는 머리를 써야만 하는 부분이지요.
이 책을 이야기책으로 썼다는 것은 펫졸드 아저씨의 초기 의도이죠. 서문에 “전공한 사람이 아닌 누구에게든 권해줄 수 있는 책을 쓰고 싶었다.”라는 말이 있거든요.
저 역시, 이 책의 번역제의를 받고 수락하게 될 때 가장 많이 염두에 둔 것이 “어떻게 하면 쉽게 읽힐 수 있을 것인가?”였습니다.
음.. 번역자가 이런 이야기를 해도 되는 건지 모르겠지만(낄낄..), 약간 미흡한 것 같기도 하고.. 공식적으로는 ‘나름 노력했지만, 결과는 독자가 판단할 일이다. ‘ 정도로 입장 정리를.. (응?)
여하튼, 번역하면서 느낀건데, 사람이 참 많이 넓게 책을 읽어야 할 것 같습니다.
petzold 아저씨의 책에서 수많은 인용과 예제를 보면 그 아저씨의 박학다식함에 놀라게 되거든요 (번역하는 입장에서는 “앗 이게 도대체 뭔 소리지??? 하고 구글신에게 신탁을 받아보면 어디서 인용한 것더라.. “는 경우가 많아서 혹시라도 아무생각없이 번역했다가 책을 보시는 분들께 “발로 번역했냐”는 소리를 듣지 않으려고 긴장의 끈을 놓칠 수 없었죠..)
이후로 책을 좀 많이 넓게 읽으려고 노력하는 습관도 길러졌고..
마누라는 집에서 주말에 빈둥거리거나 게임하지 않고(흑흑.. ) 열심히 뭔가 하는 것이 좋다고 하고..
전반적으로 좋은 경험이었던 것 같습니다.
아.. 가끔 한턱 쏘라고 하시는 분들. 생각보다 기술서적 번역료 정말 얼마 안해요.. ㅋㅋ
제가 번역 시작할때 가장 많이 생각한 것은 우습게도.. 혹은 좀 쑥스럽게도.. community에 대한 환원? 뭐 이런 생각이었습니다.
대단한 건 아니고요.. 예전에 제가 처음 프로그래밍을 접했을때, 컴퓨터 아키텍처에 관심을 가졌을 때 저에게 가장 큰 도움을 준 것은 Ketel의 수많은 강좌들과 많은 “한글판” 책들이었죠. 뭐, 한글판이 몇 권 없던 시절이라.. 다들 파인애플 잘라놓은 표지가 있는 책으로 시작해서 다들 똑같은 베게책보고 C 언어를 공부했죠(무슨 책인지 다들 아시겠죠? ㅋㅋ)
가끔 “한글판 책의 조악함”에 대해서 투덜대지만 어떤 것이든 한글판.. 특히 입문서일수록 한글판 책이 많아야 한다고 생각했습니다.
여하튼, 지난 수요일에 편집자분한테 메일을 받았는데, 그날 이사였고.. (아.. babyworm의 수원시대는 끝입니다. 이제는 강북시대) , 오늘 인터넷 연결되었는데 컴퓨터가 고장나있고 (못고쳤어요.. 아무래도 파워 or mainboard 문제인듯..), 안쓰던 컴퓨터 한대에 부품 끼워맞춰서 밤이되서야 인터넷을 쓸 수 있게 되었네요.여하튼, 기쁜 소식을 늦게 올렸습니다.
오랫만에 장문의 글인가?

합리적인 작업량이란?

요즘에 많이 읽고 있는 이런 저런 책들에서 공통적으로 이야기하는 것을 요약하자면 다음과 같습니다. (톰 드마르코의 책들이 특히 많습니다만..)

“지식 노동자의 경우 기존의 과학적인 관리 방법과는 다른 성향을 보인다. 예전 방식으로 뭔가 짜내려고 하지 마라”
그런데 내가 예전에 존경하던 교수님들(무려 교수님들이다..)께 듣기로는
“공학이란 예전부터 도제 시스템에 의하여 운영되었다. 장인이 제자를 키울때 처음에는 전혀 의미없어 보이는 일을 끝도 없이 시키고, 가혹하게 훈련시킨다. 그리고 난 이후에야 한사람의 장인이 탄생할 수 있다.”
그리고, “대학원생들은 ‘아야’소리도 나지 않을 정도로 짜내야 한다. 고 들었는데.. 이 접점을 찾을 수 없는 두 가지 관점에서 어떤 것을 옳은 것으로 생각해야 할까요?
제 생각에는 두 가지 관점 모두 진리라고 생각합니다.
공학이라는 분야에 있어서 말이지요.
비단 공학에만 국한된 이야기는 아니지만 많은 일이 처음에는 기술에서 출발하여 예술의 경지(state of the art)에 도달하게 되어 드디어 한 사람의 장인(artisan)이 탄생하게 됩니다.
처음의 기술을 익히는 단계에서 가장 중요한 것은 많은 실수를 겪는 것이며, 이를 위해서는 많은 시도가 필수적일 것 같습니다. 극한의 스트레스도 겪어볼 필요가 있고, 몰입의 즐거움을 느낄 필요도 있고(자의에 의해서건 타의에 의해서건) 이 기술이 자기 자신에게 어울리는 것인지 확인하는, 몸으로 체득하는 기간이 필요하다고 봅니다.
1만 시간의 법칙이 적용되는 기간이라 봅니다.
이 시간동안에 얼마나 많은 고민을 했고, 얼마나 미친듯이 달려보았는지가 나머지 엔지니어의 경험에서 큰 영향을 미치겠죠.
그 이후에는 다양한 변수에 대해서 고민할 때가 됩니다.
실질적으로 이때부터가 진정한 지식 노동자(?)의 초입에 들어가는 것이고, art까지는 아니더라도 아름다움에 대해서 고민할 때가 아닌가 싶습니다.
더 지나면 artist에 가까워지는 artisan이 되겠죠. 저는 뭐 아직 근처에도 도달하지 못했으니 아직은 모르겠지만요..
이런 측면에서 도았을때 실질적으로 눈으로 보이는 작업의 량은 초기에는 좀 많은 듯 해서 기술을 익히고, 조금 지나면 실질적인 지식 노동자되면서 생각의 질이 높아가면서 정량적인 작업량의 추정이 쉽지 않아질 수 있을 것 같습니다.
지식 노동(?)의 특징이라는 것이, 필요하다면 즉 데드라인이 결정되어 있는 경우 어떤식으로든 결과를 낼 수 있는데, 그것이 전혀 아름답지 않을 수도 있고, state of the art일수도 있지요.
slack에서 표현하고자 했던 것이 바로, 이런 측면이 아닌가 싶습니다.
“지식 노동자를 데드라인으로 압박하지 말아라.. 결과를 얻을 수는 있겠지만, 최선의 결과는 결코 아닐 것이다.”
따라서 합리적인 작업량, 합리적인 데드라인이란 지식 노동자의 수준인 엔지니어에게는 “회사에서 요구하는 작업의 질에 따라” 자기 자신이 설정해나가는 것이 가장 좋겠지요. (물론, 자기 자신에게 알맞는 데드라인을 정하는 것 자체가 별로 훈련이 되지 않은 상태일 것이므로, 적응해 나가는데 시간이 필요할 것 같습니다.)
지식 노동자에 다가가고 있는 중이라면 필요에 따라서 약간 강한 작업량을 가져가는 것이 도움이 되겠죠.