바로 직전에 나온 책이 “CODE”라서 비슷한 내용이 아닐까 생각하실 수 있는데, 하드웨어 부분은 전혀 가지고 있지 않은 책이며, 원제인 Code that fits in your head에 맞게 ‘이해하기 쉬운’ 코드란 어떤 것이며, 이런 코드를 만드는 관례(practices)에 대한 대한 책입니다. 사실 이해하기 쉬우면 읽기도 쉬워지기 때문에 책 제목이 이해할 만 합니다.

• 교보문고: https://product.kyobobook.co.kr/detail/S000212756007

이 책은 저자가 경험한 방법들 중에서 모두 알아야 할만한 프랙티스들을 체계적으로 정리해서 코드를 작성할 때 어떤 식을 적용할 수 있는지 알려주는 책입니다.

소프트웨어 엔지니어 분들은 Clean Code라던지, 조엘 온 소프트웨어라던지, Code complete라던지, 혹은 refactoring, design patterns 같은 책을 통해서 이미 여러가지 프로그래밍 방법론과 관례에 익숙하실 것이라 생각합니다.

이 책은 Clean Code를 쓴 로버트 마틴 시리즈(https://www.amazon.com/Robert-C.-Martin-14-book-series/dp/B085D95SX5) 중의 하나로, (제 생각에는) 코드라는 것이 왜 복잡할 수 밖에 없는지, 그리고 이전부터 가지고 있던 코드에 대한 잘못된 생각이 실제 코딩을 바라볼때 어떤 문제를 일으키고 있는지에 대한 이야기부터 시작해서, 아주 간단한 프렉티스들, 그리고 이 작업들이 내포하고 있는 의미를 체계적이고 단계적으로 하나 씩 설명해 줍니다.

저는 개인적으로 이 책에서 가장 중요한 교훈은 다음과 같다고 생각합니다.

“여러분은 보통 코드를 작성하는 것보다 읽는데 더 많은 시간을 사용합니다.”

따라서, 작성하기 편한 코드를 만드는 것보다 “읽기 쉬운(잘 이해될 수 있는)” 코드를 만드는 것이 조직의 관점에서 훨씬 효율적일 수 밖에 없습니다 .

이 지점이 정말 중요한 부분이라 생각하며, 조직에서는 이 부분을 지원하기 위한 방법을 찾아내야만 합니다. (이 부분은 뒤에 더 이야기하죠)

잘 읽히는 코드는 코드 자체가 잘 읽히는 것도 중요하지만(이 부분을 위한 관례들은 Code complete에서 잘 설명되어 있습니다.), 잘 이해되는 코드를 작성하는 방법이 필요하다고 할 수 있는데, 이 책은 여기에 조금 더 집중하고 있습니다. (이 책과 비슷한 결의 책으로 “프로그래머의 뇌“라는 책이 있는데, 프로그래머의 뇌가 조금 더 과학적인 근거에 집중했다면, 이 책은 많은 사람들이 사용하는 프랙티스들을 설명하고 이게 어떤 근거를 가졌는지 설명한 후 예제를 보여주는 형식으로 구성되어 있습니다.)

사실 이 책은 대부분의 프로그래머분들과 “관리자”분들께 권하고 싶습니다.

앞에서 설명한 것처럼 작성하기 편한 코드를 만드는 것보다 “읽기 쉬운(잘 이해될 수 있는)” 코드를 만드는 것이 조직의 관점에서 훨씬 효율적이라는 점을 잘 알아야 하기 때문이죠. 이 부분을 왜 알아야 하냐 하면, (최근에는 한물 가기는 했지만) 성과 주의를 강조하면 ‘개인이 얼마나’ 빠르게 코드를 작성하는지에 초점이 맞춰지는 경우가 생길 수 밖에 없으며, 이는 코드를 망쳐버리는 일을 발생시킵니다.

문제는 ‘이미 동작하는 좋지 않은 코드가 만들어 졌을 때 입니다.’ 보통 ‘잘 돌지않냐’는 거센 저항에 부딛치는 근거가 되기 때문이며, 조직에서도 코드의 구조나 가독성 등을 위해서 리뷰와 리펙토링, 혹은 새로 코드를 작성하는 부분에 대해서 자신의 성과에 대한 ‘이의 제기’로 받아들여질 여지가 커진다는 부분입니다.

물론 이 책에 나온 것처럼 linter 등을 잘 사용해서 ‘안 고치면 안되는 것처럼’ 이야기할 수 있습니다. 하지만, 이 부분 역시 개발자 간에 문화가 있어야 하는 부분이겠죠. 즉, 최대한 문화가 지원해 주어야만 하며, 이런 문화가 만들어 질 수 있도록 만드는 것이 조직에서 고민해야 할 부분일 것입니다.

그럼, 이 책을 하드웨어 IP 개발자인 제가 번역하게 되었는지 궁금하실 수 있는데요. 이 내용은 거의 정확히 HDL을 이용해서 하드웨어 IP를 개발하는 것에도 적용될 수 있다고 생각했습니다. 사실 HDL을 기반으로 하는 Soft IP들의 개발 과정은 점진적으로 잘 개발되어 있는 소프트웨어 개발 방법론을 사용하고 있기 때문입니다.

개인적으로 저는 오랜 시간 동안 HDL이라는 언어를 이용해서 재사용 가능한 코드인 하드웨어 IP를 개발해왔습니다. 이런 개발 과정은 하드웨어 개발이지만, 개발 과정에서는 소프트웨어 개발론이 적용되면 훨씬 더 체계적이 될 수 있는데, 이외로 잘 안되는 부분들이 많았기 때문에 항상 부딛치는 수 밖에 없었기 때문이죠. (다행히 좋은 매니저 분들과 경영진을 만나서 적어도 제가 있던 직장들에서는 버전관리 시스템과 이슈 트래킹 시스템, 지식 관리 시스템이 잘 적용되었고, 원활하지 않더라도 여러가지 방법론이 시도되었습니다. 물론 일부는 실패하기도 했고 일부는 변형이 필요한 부분이 있었다 하더라도 말이죠.)

하드웨어에서는 여기 나온 모든 것을 적용할 수는 없는 부분이 있기는 하지만, 정말 많은 부분에서 도움이 됩니다. 정말입니다. 도움이 필요하시다면 불러주세요. 어떤 부분에서 도움이 되는지 알려드리겠습니다.

이 책은 많은 부분에서 하드웨어에서도 적용할 만 합니다. 책에서 사용한 언어가 C#이고, 웹 개발을 예제로 사용한 것은 중요하지 않습니다. 내용은 정말 참고할 만 합니다. 다양한 부분에서 말이죠. 이 책의 번역을 해야겠다고 결심한 지점 중의 하나가 바로 이 부분입니다. 물론, 당시에 있던 junior 엔지니어 들에게 도움 될만한 내용이 많았다고도 생각했습니다.

이 책의 번역을 시작한 것이 이전 책 “CODE”보다 빠른데요. 제가 이 책에서 예제로 사용한 C# (특히 web 개발을 위한 library들)을 그리 잘 알지 못하는 관계로 오래 걸렸습니다. C#을 사용했던 것이 워낙 오래전인데, 지금 C#과 차이가 많고 웹 개발에 필요한 부분에 대한 이해가 필요했습니다. 최대한 해보려고 했는데, 여전히 아쉬운 부분이 있습니다. 조금 더 매끄럽고 잘 읽히게 하고 싶었는데 그렇지는 않더군요. 아마도 제가 완전하게 제 언어로 이야기하지 못해서 그런 것이라 생각됩니다. 이 부분은 번역을 마치고 나면 항상 아쉽더군요. 어떤 글을 쓰게 되어도 그렇지 않을까 하는 생각도 듭니다.

그럼에도.

많은 분들이 즐겁게 읽으시길 바랍니다.

저는 회사란 것이 “kid’s recreational team”이 아닌 “pro sports team”이여만 하고, 실제로는 이보다 ‘더욱 더 같이 발전하는 관계’라는 관점에 공감하며, 매우 좋아합니다. 이런 관점에서 ‘나에게 자극을 줄 수 있는 좋은 동료’가 많은 회사가 좋은 회사인 것이죠. 이런 분들이 같이 있을 때 감사하는 마음을 가지게 되며, 저도 남에게 ‘좋은 자극’이 될 수 있는 사람이 되려고 노력하는 것이 목표입니다.

간혹 ‘즐겁다’를 recreation의 관점에서 보시는 경우가 있는데, 회사에서의 즐거움은 ‘어려운 목표’를 같이 도달했을 때 얻는 것이지, 미디어에서 이야기하는 삶을 즐기는 ‘즐거움’과 거리가 있다고 봅니다. 프로스포츠 팀의 즐거움은 ‘우승’ 혹은 (적어도) ‘향상’이지 않을까요.

또 하나.. 회사의 문화란 “구호”가 아니라는 생각도 아주 중요할 것 같습니다. 구호와 문화가 일치하지 않는 경우는 너무 많으니까요. ‘차카게 살자’는 조폭도 구호가 없는 것이 아니라 그런 문화가 없는 것일테니까요.

10년전에 링크한 원본은 다음과 같습니다.

참고로.. 넷플릭스 문화가 실제로 좋은지 어떤지는 모르겠습니다. 다만, 적어도 뛰어나기 위해서 노력하는 모습이나 자신감 자체는 항상 보기 좋더군요.

지난주에 CODE 2판의 마지막 교정본을 보냈습니다. 그리고, 드디어 다음 주면 책이 나옵니다.

• YES24: https://www.yes24.com/Product/Goods/124110681
• 알라딘: https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=330301790&start=slayer
  

좋아하는 책을 다양한 측면에서 읽어보고, 해석하는 것이 매우 즐거울 수 있다는 것 때문에 가끔 번역을 합니다.

다만, 언제부터인가 시간이 부족한 나이가 되면서(진실을 이야기하면 예전처럼 빠르게 배우지 못하는 나이가 되면서 새로운 뭔가를 하려면 더 많은 시간을 사용해야 하는 것이겠습니다.), ‘엔지니어의 정성’의 영역에서 해결되는 일들에 대해서 더욱 충분히 시간을 들이지 못하는 것이 아쉬울때가 많습니다.

분명히 한번씩 더 볼때마다 조금씩 조금씩 더 좋아지는 부분이 있는데, 여러번 읽다보니 너무나 자연스럽게 인지의 밖으로 벗어나는 경우들이 있습니다. 더욱이 고쳐지는 부분들이 적어져서 ‘이부분..’이라는 생각에 넘어간 부분이, 나중에 시간을 두고 읽었을 때 또는 다른 편집자/리뷰어 분들에게 너무나도 명확한 오류를 발견하면서 크게 놀랐던 경우도 있습니다. 어느 순간에는 작업을 끝내야 하는데, 결국 효율성과 효과성, 완결성 사이의 어떤 부분에서 끝내게 됩니다.

항상 마지막 교정본을 보낼때마다 ‘실수로 넘어간 부분이 있으면 어떻게 하지’라는 생각이 듭니다.

편하게 읽을 수 있도록 만들고 싶었는데, 그렇다고 내용이 바뀌면 안되니까 다시 추가했다가 점점 더 복잡하게 만들게 되고, 리뷰하다가 지우는 과정을 반복하게 되더군요. 문제는 여러번 우물쭈물하다가 적은 문장은 이도 저도 아니게 오류가 많은 문장이 되어서, 교정 과정에서 편집자님께 많이 죄송했습니다. 교정도 오랜시간동안 진행되었고요.

역자 서문에도 썼지만, 이 책은 저에게 상당히 깊은 의미가 있는 책입니다.

저는 석사때 한동안 다양한 컴퓨터 아키텍처 책을 읽었던 적이 있습니다. 당시에 교보문고에는 ‘교재’용으로 비교적 저렴하게 나온 원서들이 많았고, 학교 도서관에도 다양한 책이 있었는데, 이 서고의 작은 한 부분을 다 읽어보는게 목표라면 목표였던 시절이었습니다. 당시에는 여러 대가들이 같은 부분을 서로 다른 관점과 여러가지 수준으로 설명하는 것이 재미있었습니다. 또한, 책을 읽을수록 더욱 속도가 붙는 것에 한참 재미를 느끼던 시절이기도 했고요.

이때 읽었던 책 중의 하나가 CODE 입니다.

사실 기술 서적이라기에는 너무 글자가 많아서 주저 주저했는데, 당시 일종의 바이블이었던 Programming Windows를 지은 펫졸드님의 책이라는 점에서 손이 가는 걸 어쩔 수 없었습니다. 다만, 당시에는 앞 부분의 내용은 다 아는 내용이네.. 라고 간단하게 생각하면서 대충 대충 읽어가다가 ‘오~’ 했던 기억이 있습니다.

한참 지나서 저를 잘 평가해주셨던 제 첫 회사에서 상용 마이크로 프로세서를 만들고, 관련된 시스템 소프트웨어들을 고쳐가면서 알게 된 것들을 회사의 대외비가 아닐 법한 것들 혹은 개인적인 취미생활(?)에서 알게 된 것을 공유하는 블로그에 이런 저런 글을 쓰고 있던 와중에 이 책에 대한 번역 의뢰가 왔었고, 이 책의 초기 번역판에 대한 문제를 저도 알고 있었기에 영어를 잘하지도 못하면서 어줍지 않게도 ‘이 책은 다른 분들이 조금 많이 읽는 책이 되어야 한다’는 생각을 가지고 작업했습니다. 이 책이 제 첫 번역서가 되었습니다.

가끔 물어보시는 분들께도 이야기하지만, 이 작업은 저에게 ‘해야 할 일’ 혹은 ‘즐거운 일’의 범주에 들 수 있을 때만 진행합니다. 번역을 해본 분은 아시겠지만, 매우 비효율적이거든요. 특히 저처럼 영어를 잘 못하는데다가, 회사 일을 하면서 주말 정도에만 작업을 진행해야 하는 경우에는 말이죠.

그럼에도 이 책은 그럴만한 가치가 있었습니다.

아무도 읽지 않으실 역자 서문에도 적었지만, 이 책은 읽기 쉬운 전반부(대략 13장까지)와 잘 안 읽히는 후반부(대략 24장까지), 그리고, 그나마 조금 읽을만한 끝부분(25장부터 28잘까지)으로 이뤄져 있습니다. 사실 저는 후반부 부분이라 할 수 있는 논리 회로를 ‘효율적/효과적’으로 잘 만들어내는 방법을 찾는 사람이라 후반부의 설명이 추가되고, 1판에서 내용이 갑자기 튀는 부분들이 줄어들어서(대신 양이 매우 많이 늘어났죠) 아주 좋았습니다.

이 후반부를 읽으실 때는 최대한 https://codehiddenlanguage.com/ 에 있는 interactive demo를 참고하세요. 제 생각에 이번 판에서 가장 중요한 contents는 이 홈페이지에 있는 예제들입니다. 스위치들을 조작하면서 어떻게 동작하는지 ‘조금이라도’ 직관적으로 받아들이실 수 있습니다.

그럼에도, 소프트웨어 하시는 분들 혹은 초보자분들에게는 후반부(특히 18장부터 23장까지)가 매우 어려울 수 있겠다고 생각합니다. 서문에 적었듯이 자세한 부분들은 그냥 그러려니 넘어가셔도 됩니다. 나중에 다시 읽어보면서 ‘이게 이렇게 연결되는 것이었다니!’하는 순간이 있을텐데, 처음부터 너무 정신력을 소모하실 필요는 없다고 생각합니다.

중요한 것은 어떤 ‘생각의 흐름’으로 프로세서가 만들어지는 것인지를 보는 것입니다. 실제로 만드실 분이 아니라면 클럭이 어떻게 분주되는지, 각각의 명령어가 어떤 제어 회로의 어떤 신호를 켜주는지, 각 프로세서의 제어 사이클이 어떻게 될지 아는 것이 아주 중요하다고 생각하지는 않습니다. (요즘의 책에서는 여기에 있는 multi-cycle implemtation보다 pipeline implementation을 더 많이 설명하는데, 제 경험으로도 그렇고, 다른 분들의 의견도 이렇게 제어를 설명하는 것이 학생들에게 더 쉽게 받아 들여지는 것 같기도 합니다.)

다만, 메모리에 있는 어떤 값을 읽어와서 ‘명령어로 인식’하는 stored program (혹은 von Neuman architecture라고도 할 수 있는) 개념이나, 읽어온 명령어가 디코더에서 해석되어 제어신호를 만들고, 제어신호가 적절한 산술/논리 회로를 제어하고, 적절한 경로를 제어함으로써 최종적인 결과를 얻어낸다는 점, 그리고, 분기가 어떤 효과가 있는지 정도만 알아도 충분합니다. 즉, 하나 하나 어떤 방식으로 쌓아 올린 것인지 아는 것이 중요하다는 것이죠.

이런 측면에서 컴퓨터, 즉 하드웨어와 소프트웨어를 잘 harmonize시키는 것은 마치 건축물을 하나 하나 쌓아 올리는 것과 비슷하고 할 수 있습니다. 건축물을 볼 때, 전반적인 형태나 구성이 중요하지, 각 블록의 재질이나 특성을 정확하게 이해하는 것은 만들 분들은 꼭 알아야 하는 것이겠으나, 조망하시는 분들은 알면 더 재미있는 부분 정도로 넘어가도 됩니다.

음.. 길어졌는데, 후반부에는 앞의 내용을 기억하지 못하면 따라가기 힘든 detail들이 상당히 있습니다. 회로를 만들어야 하기 때문이죠. 하지만, 이런 부분을 못따라가도 그러려니.. 하면서 지나가셔도 됩니다. 아.. 이렇게 생겨서 이렇게 제어 신호를 넣어주나 보다, 이 부분은 이렇게도 되네.. 정도로 생각하면 매우 좋고, 그것도 힘들면 그냥 뭔가를 만들고(data path라 불리는 연산 혹은 데이터의 경로), 이걸 제어하는 부분(control unit이라 불립니다.)을 만드는 순서로 프로세서가 만들어지는 것이고, 이 제어 부분과 데이터 처리 부분은 클럭에 의해서 제어된다는 정도만 아셔도 되는 것이죠.

따라서, 클럭이 빨라지면 더 많은 연산을 할 수 있고, 범용 머신에서는 ‘속도가 모든 것을 말하는 경우’가 되면서 속도에 따라 응용 분야가 크게 늘어나게 되는 것이죠. 대부분의 실시간 처리라던지, 영상 처리라던지, 인공지능과 같은 대부분의 것이 ‘실질적으로 사용할 수 있는 수준의 성능에 도달하면서 가능해진 것입니다. 즉, 알고리즘은 이전부터 있었으나, 예전에는 ‘속도 문제’로 불가능했던 것이 이제 ‘가능한’ 것이 되는 경우가 허다합니다. (물론, application의 폭발적인 증가로 인해서 ‘전용 하드웨어’가 보조하는 경우도 많죠.)

힘드셨던 후반부를 지나가시면, 이제 읽으실 만한 종반부로 달려가게 되는데, 이 부분에서는 프로세서가 외부 세계와 소통하는 부분, 프로세서에 올라가는 소프트웨어의 발전, 그리고 인터넷의 발전으로 구성됩니다.

인터넷 부분은 기술적인 내용이라기 보다는 저로써는 ‘새로운 시각’이라는 점에서 좋았습니다. 전공이 전공이다보니 OSI 7계층이니, TCP/IP니, 소켓 등을 배우던 사람에게, 예전부터 많은 사람들의 상상이 실제로 실현되는 과정이라는 관점과 이러한 지식의 집대성으로 wikipedia를 지적한 것이 매우 흥미로운 부분이었습니다. 몇 명의 전문가가 만들어내는 시대에서 많은 사람들이 데이터를 공유하고, 수정하면서 더욱 더 좋은 내용이 채워지는 것이죠.

물론, 국내에서는 wikipedia 보다는 나무위키가 더 유명하고, 체계적으로 지식이 정리되어 있죠. (물론, 틀린 부분도 있습니다만, 많은 분들이 참고하실 것으로 생각합니다.), 최근에는 LLM 덕분에 이걸 찾아보는게 아니라 ‘물어보는 것’이 너무나도 자연스러운 시대가 된 것 같습니다. 저만해도 Bard, Bing Chat, ChapGPT에게 묻는 것이 자연스러워졌으니까요. (또 한 15~20년쯤 후에 이 부분이 너무 자연스러워진 시점에서 3판이 나오지 않을까요?)

CODE에 있는 논문의 예로 들은 JSTOR의 경우(저는 보통 IEEExplorer나 AMC digital library를 주로 참고하는지라, JSTOR에 갈 일이 별로 없기는 한데요.) 사건이 많아서 각주가 길어져서 일부분만 남겨두었는데, 최근에는 Open Access 전용 저널들이 나오면서 어느 정도 빗장이 풀리는 추세입니다. 제가 장문의 역자주를 썼지만, 책에 들어가기에는 너무 많아서 줄여서 들어갔는데..여기에 적자면.. (너무 길기는 하네요. 사실 저 사건을 읽었을 때 약간 분노(?)하기도 했고, 최근까지 여러개의 Digital Library를 구독하면서 매우 폐쇄적인 정책에 고생하기도 해서 너무 글이 길어진 것이죠. )

JSTOR의 경우 저널/논문에 대한 접근 권한을 기업이나 기관에 판매하는 모델을 가지고 있었는데, RSS를 만든 애런 스워츠가 과도한 양의 저널 논문을 다운받은 사실을 확인하고 고소를 진행했으며, 이로 인해서 애런 스워츠가 자살하면서 강력한 비판을 받은 사건입니다. https://www.harvardmagazine.com/2013/01/rss-creator-aaron-swartz-dead-at-26
이 사건 이후에 JSTOR은 몇개의 논문은 무료로 받을 수 있도록 정책을 변경했습니다.
여기는 나와있지 않으나 과연 많은 연구자들의 노력으로 만들어지고, 공적인 자금이 투입된 논문을 사유화해서 판매하는 것이 옳은지(게다가 원저자에게 따로 수익을 분배하고 있지도 않고, 심지어 논문 게재비를 받고 있으니까요)에 대한 비판이 매우 강하며, 최근에는 Open Access라는 이름으로 다양한 학회에서 무료 논문지 혹은 저자의 동의에 의해서 일부 논문을 공개하는 모델을 만드는 추세가 확대되고 있습니다.
극단적인 예이기도 하지만, 유료 논문들을 모아서 Open Access로 공개해버린 sci-hub 역시 논문을 사유화하고 있는 출판사에 대한 비판에서 출발한 프로젝트라 할 수 있습니다.

제 생각에 이 책은 ‘자세히’ 다 읽기 쉽지 않은 책입니다. 저처럼 ‘하드웨어’와 ‘소프트웨어’ 중간 혹은 하드웨어에 중심을 두고 소프트웨어를 바라보시는 분들, 임베디드 소프트웨어/시스템 소프트웨어를 하면서 약간 하드웨어 쪽을 더 알고 싶으셨던 분은 후루룩(혹은 약간 ‘끙~’하면서) 읽어보실 수 있을 것이지만, 소프트웨어 쪽에서 바라보기엔 조금 어려운 부분들이 분명히 있습니다.

다만, 후반부의 많은 부분은 ‘디테일’까지 알지 못하더라도 대략의 흐름만 잡으면서(극단적으로는 약간씩 스킵을하시더라도) 끝까지 도달해 보시길 바랍니다.

여러분을 조금이라도 도와드리기 위해서, 후반부가 어려운 분들을 위해서 제가 추천하는 ‘읽어야 할 부분’입니다.

• 14장: 논리 게이트 종류와 논리 연산에 대해서 이해하고, 이진수 덧셈을 논리 게이트로 바꿔보는 것
• 15장: 요 장은 읽기 편하실 것 같습니다. 이야기 읽듯 읽으시면 됩니다.
• 16장: 이진수 뺄셈이 보수를 이용한 덧셈이라는 점을 이해하세요. 회로는 중요하지 않습니다.
• 17장: 피드백이라는 것이 어떤 것인지, 플립플롭이 어떻게 데이터를 저장하는지 개념만 아시면 됩니다. 모두 피드백을 통해서 데이터를 가두는 것이죠.
• 18장: 클럭이란 것을 어떻게 만들고, 분주하는지, 실제로는 카운터 같은 것이라는 점을 이해하시면 됩니다. 실제 BCD 시계를 만드는 과정을 보실텐데, 대략 논리적으로 ‘이런 논리’를 만들어서 회로로 만든다는 예를 보여주는 것입니다. 회로가 중요하지는 않지만, 궁금하신 분들도 있을 것 같습니다.
• 19장: 앞에서 본 플립플롭을 어레이로 배치해서 메모리를 만들 볼 겁니다. 실제 여러분이 아시는 DRAM은 이렇게 만들어지지는 않지만, 대충 ‘주소’란 것이 어떤 것인지에 대해서 이해하시면 됩니다.
• 20장: 자.. 이제 프로세서입니다. 연산을 자동화 시키는 것이 어떻게 가능한지만 따라가 봅시다. 메모리에 있는 값을 ‘제어신호’로 바꾸는 부분이 핵심입니다. 제어 명령 하나를 읽어서 더하는 ‘데이터 패스’를 조정하는 겁니다.
• 21장: 데이터패스를 추가하는 겁니다. 더 복잡해졌으니, 더 복잡한 제어가 필요하겠죠? 대충 넘어가셔도 됩니다. 연산의 결과를 이용해서 ‘플래그’라는 것을 만드는 것은 나중에 조건 분기에서 사용됩니다.
• 22장: 메모리만 사용하는 것이 아니라, 내부 레지스터와 버스를 사용하는 방법을 알려줍니다. 즉, 데이터 패스 구성요소를 설명하는 것입니다. x86을 조금 깊게 읽어보신 분들은 Ax, Bx, Cx, Dx라는 전통적인 레지스터들을 아실텐데, 여기에 대한 내용입니다. 이 부분을 이해하시면 나중에 x86 어셈블리 읽을 때 도움됩니다. 읽으실 일이 없다면, 대충 이런게 있군.. 하고 넘어가셔도 됩니다.
• 23장: 제어 유닛 부분입니다. 아마도 가장 읽기 어려우실 수 있겠습니다. 회로는 중요하지 않으며, 데이터 패스를 ‘각각의 실행 사이클’에서 어떤 방식으로 제어해서 해당 동작을 만들어내는지 이해하면 좋습니다.
• 24장: 분기에 대해서 다룹니다. 연산된 결과를 통해서 만들어지는 플래그를 통해서 ‘조건’ 분기가 이루어지며, 함수 호출은 돌아올 곳을 저장하는 일종의 특수한 형태의 ‘분기’라는 점만 이해하셔도 됩니다.

구체적인 예를 따라가 보시면 더 즐길 수 있으시겠지만, 재미가 떨어지는 수준까지 고민하실 정도는 아닙니다. 위의 내용(개념)만 잡으면서 지나가시고, 언젠가 필요할 때 지나가셨던 부분을 한번 더 읽으시는 게, 이 책을 읽을 때 더 좋은 방식이라 생각합니다.

모두 즐겁게 즐기시길 바랍니다.

여하튼, 저는 컴퓨터 학회 관련 논문을 볼 생각으로 ACM professional member로 몇 년 째 가입되어 있었는데요(참고로 학생때는 훨씬 더 저렴했습니다.). ACM Digital Library가 비교적 저렴한 가격($199)에 많은 논문을 제공해주고 있다고 생각하고 있었습니다.

사실 ACM DL과 IEEE Computer Society DL, CAS (Circuit & System) DL 정도만 구독하면, 제가 관심분야 논문은 거의 얻을 수 있습니다.

여하튼, 작년쯤부터 ACM learning center라는 것이 있다는 것을 인지하고 사용하고 있는데요. 매우 매우 강력히 추천해 드리고 싶습니다. ACM learning center를 통해서 O’RELLY learning center를 사용할 수 있고요(이게 연간 구독료가 $199죠), SkillSoft도 사용할 수 있습니다. 작년까지만 해도 Elsevier의 science direct까지 지원했으니 정말 좋았습니다. (아쉽게 올해부터는 제외되었습니다.) 만일 O’RELLY learning center에 관심이 있으시다면, 차라리 ACM+DL 옵션으로 가입하셔서 사용하시는게 훨씬 더 좋겠습니다.

다만, 이 회사에서 주장하는 video sharing에 대한 기술(즉, 사용자의 요구에 따라 다양한 형식으로 영상을 transcoding해서 저장한 후 사용자 장치에 맞게 전달하는 기술)이 정말 주장대로 특허성이 있는지를 잘 모르겠네요.

이 개념에 대해서는 2000년 정도에 매우 흔하게 있었던 것으로 기억하거든요. (학교에 있을 때 이런 목적의 transcoding 하드웨어 가속에 대해서 이야기가 많이 나왔던 것을 생각하면요..) MPEG에서 이야기하는 simulcast와 뭐가 다른지도 잘 모르겠고요.

물론 이 개념 자체가 VideoShare에서 처음 이야기한 것이 맞다면 모를까, 아니라면 구글이 주장하고 있는 ‘혁신성에 대한 문제로 특허가 무효화 되어야 한다’는 취지가 더 맞다고 생각합니다.

여하튼, 이 회사는 2019년에 Google에 대해 소송을 제기했고 (아마도 특허의 유효기간 문제가 아니었을까.. 하는 생각도 듭니다만..), Facebook에도 소송을 제기했다니 뭐 이후에 좀 더 정확한 내용이 나오겠지요.

그때 ‘마이크로 소프트웨어’라는 잡지에서는 줄창 C++의 시대가 온다고 이야기했던 것으로 기억합니다. 그리고, 군대 나와서 복학해보니 정말 C++을 많이 사용하더군요. (WinAPI를 C로 연결하는 경우도 많았지만..) 다만, 왜 그렇게 짜야 하는지는 모르고, 그냥 C++을 이용한 절차적 프로그래밍을 열심히 짜고, 정말 기본적인 객체를 짜는 정도였는데.. (복잡하단 생각만..)

당시에 통신망(저의 경우 하이텔)의 프로그래밍 동호회에서 가장 유행하던 글이 바로 아래의 “Stroustrup Interview” (원문은 https://www-users.cs.york.ac.uk/susan/joke/cpp.htm) 라는 글이죠. Stroustrup이 IEEE Computers와의 인터뷰에서 “사실 C++은 그럴듯하지만, 크고 느리고 엉망인 프로그램을 만들도록 해서 프로그래머들이 더 오랫동안 돈을 잘 벌게할 수 있을지 장난으로 만든 거다”라는 요지의 글이었고, 이 글은 엄청난 호응과 함께 퍼졌던 적이 있습니다.

사실 지금은 code reuse란 것이 일상화되어 있고, code reuse를 위한 coding practices (혹은 methodology, design patterns)가 잘 잡혀있고, 실제로 인터넷에서 코드를 가져다 재활용하는 일이 많다 보니(프로그래밍할 때 보면 코드의 반절은 github와 stack overflow가 만들어준 코드일지도.. ), 위의 이야기가 설득력있게 들리지 않지만, 당시에는 전산 계통에선 모르는 사람이 없는 인터뷰였습니다.

오죽하면, IEEE Computers에서 “The Real Stroustrup Interview” 를 98년 6월호에 실었습니다. 원문은 https://www.stroustrup.com/ieee_interview.pdf 에서 보실 수 있는데, 링크에서 보실 수 있듯, Stroustrup이 직접 올려둔 걸 보면, 꽤 시달렸나보다 싶습니다. 한글 번역본도 있으니 참고하십시오. (https://cdecl.net/55 ; 서진택의 C++ complete guide중에서 발췌하셨다네요..)

얼마 전에 후배와 이야기하다가 ‘사실 C++이 장난으로..’ 라는 이야기가 나와서 한참 웃다가 생각나서 올립니다. ㅎㅎ

리마스터링판은 대부분 새로운 그래픽으로 보이지 않는다고 생각해서 설정을 몇 번이나 찾아봐야 할 정도로 그래픽이 별로였고(W3는 오히려 나빠지지 않았나.. 하는 생각도..), 귀찮을 정도로 불편한 인터페이스에 뭔가를 할 때까지 오래 걸렸다는 공통점이 있습니다. 예전에는 그 불편함이란 걸 전혀 느끼지 못했는데, 아마도 최신 게임 시스템이란게 알게 모르게 뭔가를 편하게 만들었었나 봅니다.

그럼에도 불구하고, 리마스터가 나올때마다 한 번씩 해 보는 건 어쩔 수 없는 것 같습니다. 사람은 10대 20대에 향유했던 문화를 지속적으로 소모한다는 이야기가 있는데, 이제 그 세대가 구매력도 커졌으니 이 부분을 공략하는 것이겠죠. 다행히 Quake나 C&C는 게임 패스를 통해서 그냥 할 수 있기도 했으니, 쉽게 쉽게 접근할 수 있다는 점에서 조금은 편리했습니다.

그래도.. 음 대부분 씁쓸해지는 건 어쩔수 없군요

요 몇년간에는 이 정도로 멀리까지 뚜렷하게 보이는 날이 많지 않았는데, 올해는 거의 매일이 그림 같네요.

중국에서 다시 생산활동이 활발해지면 일년내내 뿌연 하늘을 보게 될 수도 있으니, 지금을 즐겨야 겠습니다.

최근 들어서 모바일 네트웍이 3G에서 4G/LTE로, 이제 5G로 바뀌면서 killer app으로 cloud gaming을 잡고 있는 것으로 보입니다. 사실 4G의 가장 직접적인 수혜를 입은 것이 video streaming이라고 볼 수 있는데요. 이전에는 wired network을 대상으로 하던 수 많은 서비스들이 모바일로 가면서 시장이 폭발적으로 증가했다고 볼 수 있습니다.

5G의 가장 큰 특징이 latency의 감소이기 때문에, 가장 혜택을 볼 수 있는 것이 cloud gaming이라는 생각이죠. 물론, 네트웍 지연이 줄어들면서 혜택을 볼 수 있는 분야는 많습니다. 가장 크게 생각하고 있는 부분은 자동차에서 사용하는 통신 (V2X / V2V)인데, 이것도 5G의 low latency 특성에 힘을 받을 것으로 생각합니다. 다만, 안정성 문제때문에 edge에서 가장 중요한 부분이 처리될 것이고, 여기에 통신을 통한 정교한 인식이나 정보처리, 주변과의 통신을 이용하는 자율주행에 V2X/V2V를 사용할 것으로 생각됩니다. 현재로서는 V2X나 V2V는 인프라의 문제나 자동차에 들어가는 장치가 바뀌어야 하기 때문에, 변화하는데 시간이 걸릴 것으로 봅니다. (자동차가 바뀌는 시간을 생각하면 대략 15~20년 쯤? 기술적인 문제가 아니라 제도의 문제때문에..)

여하튼, 다시 클라우드 게이밍으로 돌어오면, 그래픽 카드 가격이 코인 덕분에 너무 비싸져서 high-end 게이밍 환경을 갖추는 비용이 너무 커진 부분도 있고, 프로세서들에서 비디오 코덱을 잘 지원하면서 low latency encoder들도 더 좋은 화질을 제공할 수 있고(하드웨어 코덱도 많이 퍼져있고..), 비교적 넓은 네트웍 bandwidth를 제공할 수 있는 네트웍 인프라도 깔려있고, 심지어 최근 몇년간 비디오 코덱 역시 video gaming을 성능 개선 목표로 두기도 했습니다. 일례로 HEVC의 경우 SCC profile에서 컴퓨터 화면을 효과적으로 보낼 수 있는 알고리즘들을 넣었지만, 실제로 대부분의 디코더는 main profile만 지원하기 때문에 크게 효과가 없었는데, AV1의 경우 main profile 수준에서 컴퓨터 화면을 잘 압축하기 위한 알고리즘들을 넣어놨기 때문에 AV1을 지원하는 장치에서는 cloud gaming 영상들을 더 잘 압축하게 될 것으로 봅니다.

이런 측면에서 최근에 국내에서 서비스를 시작한 Microsoft Cloud Gaming beta의 경우 놀랍습니다. 가장 놀라운 것이, 별도의 앱을 사용하는 것이 아니라 웹브라우져를 통해서도 클라우드 게이밍을 구현했기 때문입니다. 이 게이밍은 클라우드 상에 있는 XBOX Series X를 통해서 게임이 구동되고 1080p 60fps의 품질로 영상이 전송되어, 웹브라우저에서 보이도록 되어 있는 것이며, 게임의 조작은 게임 컨트롤러(xbox 패드나, PS dual shock, MS 게임 패드 등)를 통해서 하도록 되어 있습니다. 이전에 SKT에서 MS 클라우드 게이밍 앱을 안드로이드에서 서비스했었습니다. (지금도 MS의 파트너로 서비스 중입니다.) 다만, 당시에는 앱을 써야 했었는데, 이것 대신 브라우져를 통해서도 서비스를 시작한 거죠. 물론 앱에서는 게임 컨트롤러 없이 터치를 이용해도 가능한 게임들이 제공됩니다. (예를 들어 드래곤 퀘스트 11의 경우는 터치로 하기도 크게 무리가 없더군요)

웹을 통해서 제공되는 MS cloud gaming을 하려면 MS game pass가 필요한데, 어쩌다보니 game pass를 가지고 있어서 실제로 HALO라는 대표적인 FPS를 해봤습니다. 결론적으로 FPS도 할만하다는 생각입니다. 물론, 패드로 하는 것이니 마우스를 사용하는 FPS에 비하면 정확도가 그 자체로 떨어지기도 할테니 잘못 느끼는 부분도 있겠습니다. (latency와 FPS관련 논문을 보면 100ms 정도까지는 정밀도와 크게 관련이 없다는 결과가 있으니, 생각보다 일반적인 게이머는 그리 민감하지 않은 것이겠죠). 게임의 반응과 더불어, 화질도 생각보다는 매우 훌륭했습니다.

이외에 MLB The show21도 해봤는데, 오히려 여기서 약간 지연이 있다는게 느껴졌습니다 (워낙에 타이밍을 맞춰서 버튼을 눌러야 하는 경우가 많아서..). 다만 인간은 적응의 동물이라 아주 금방 적응하게 됩니다. 전반적으로 예상했던 것과는 다르게 매우 상당히 만족스러운 게이밍 경험이었습니다.

인터넷 상의 이야기를 보면 웹브라우져를 이용한 클라우드 게이밍은 iOS를 지원하기 위한 묘책이라는 의견이 많은데, 안드로이드의 경우 앱의 형태로 베타를 진행했던 것이나, 애플의 불명확한 과금 정책등을 생각하면, 충분히 이해가 되네요.

웹브라우져로 이 정도 수준의 클라우드 게이밍이 구현된다면, 클라우드 게이밍이란 분야가 더 빨리 다가오지 않을까 생각됩니다.

wordpress의 경우 plugin은 아래 디렉토리에 존재합니다.

<HOME>/wordpress/wp-content/plugins/

문제가 되는 plugin을 선택하셔서 폴더 이름을 mv로 바꿔두시면 일단 뜨기는 뜹니다. (뭐 지우셔도 됩니다만..)
현재 버전에 맞는 새 버전의 plugin이 나왔다면 설치하시면 되고, 그렇지 않은 경우에는 그냥 없는 상태로 몇일 살아야겠죠. (다행히 footnotes plugin은 바로 업데이트 되어 있더군요.)

그런데, 만일 현재 사용중인 테마가 문제라면 그렇게 쉽게 되지는 않고, 이전 버전으로 롤백시키거나 해야 합니다. 관련해서 적은 글이 있으니 참고하세요. 이런 일이 있을때마다 간혹 그냥 잘 만들어진 어딘가로 이동할까.. 싶기도 하네요.

2.

DVCON2021 도 virtual 로 열렸습니다. 사실 live로 들어가기는 어렵다보니 저는 그냥 Keynote와 Panel Discussion만 보는 무료 registration을 사용했습니다. 항상 그렇지만 DVCON의 Keynote/Panel 은 볼만했습니다. (다만 virtual이니, 음량 문제나 토론 중에 끊김이라든지 자잘한 문제가 있었지만요..)

여러가지 중에 저는 Verification In the Ope-Source Era라는 panel discussion을 가장 흥미롭게 지켜봤습니다. 바로 뒤에 있는 Chip design on Cloud 와 통하는 부분이 있으니, 앞의 것을 보고 뒤의 것을 보시길 바랍니다. 여하튼 찬찬히 듣다보면 1) RISC-V에서 활성화되기 시작한 open hardware라는 것이 verification 쪽에도 영향을 주고 있고 이 과정에서 verification 환경을 공유하는 형태가 늘었다는 점, 현재 가장 대중화된 CRV에서 Deep Learning 기반의 verification이 시도되면서 python과 verification이 묶이고 있고(이번에 발표된 pyuvm은 처음봤을때는 cocotb와 엮여야 해서, 이런걸 왜.. 라는 생각이었는데.. deep learning과 엮이고 보니 그럴만한 이유가 있었다는 생각이 들더군요.), 그러다보니 서버팜으로 대표되던 private cloud에서 commercial cloud로 연결되는 흐름까지, panel discussion에서 잘 다루어졌다고 생각합니다. 전반적으로 verification 엔지니어들이 이런 흐름에 상당히 빠르게 대응하고 있다는 생각이 들더군요.

아직 registration이 되는지 모르겠습니다만, 전례로 봤을때 상당히 빠른 시점에 풀릴테니, 못보신 분들은 한번 보시길 권해드립니다.

• 6/2일 update: Semiconductor Engineering에 위의 panel discussion 전문이 실렸습니다. 참조하십시오.