바로 직전에 나온 책이 “CODE”라서 비슷한 내용이 아닐까 생각하실 수 있는데, 하드웨어 부분은 전혀 가지고 있지 않은 책이며, 원제인 Code that fits in your head에 맞게 ‘이해하기 쉬운’ 코드란 어떤 것이며, 이런 코드를 만드는 관례(practices)에 대한 대한 책입니다. 사실 이해하기 쉬우면 읽기도 쉬워지기 때문에 책 제목이 이해할 만 합니다.
이 책은 저자가 경험한 방법들 중에서 모두 알아야 할만한 프랙티스들을 체계적으로 정리해서 코드를 작성할 때 어떤 식을 적용할 수 있는지 알려주는 책입니다.
소프트웨어 엔지니어 분들은 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#과 차이가 많고 웹 개발에 필요한 부분에 대한 이해가 필요했습니다. 최대한 해보려고 했는데, 여전히 아쉬운 부분이 있습니다. 조금 더 매끄럽고 잘 읽히게 하고 싶었는데 그렇지는 않더군요. 아마도 제가 완전하게 제 언어로 이야기하지 못해서 그런 것이라 생각됩니다. 이 부분은 번역을 마치고 나면 항상 아쉽더군요. 어떤 글을 쓰게 되어도 그렇지 않을까 하는 생각도 듭니다.
10년전에 이 슬라이드의 영문판을 Linkedin에 공유했었는데, 왠지 올해도 공유해야 할 것 같습니다. 🙂 (여러가지 이유가 있습니다만..)
몇 일전 술잔을 기울이다 나온 이야기에 대해서, 제가 가지고 있는 생각이 어디서 왔을까 생각해보니, 상당 부분 이 자료인 것 같기 때문입니다. (물론, 전 직장에 같이 있던 M님과 D님이 열렬한 신봉자셨기 때문에 영향을 받은 부분을 부인하지는 못하지만, 많은 부분 공감하고 있습니다.)
그간에 “규칙 없음 (https://www.yes24.com/Product/Goods/92275597)”이란 책이 국내에서 베스트셀러에 이름을 올린 것을 보면, 이 내용에 공감하는 분들이 많을 것으로 생각합니다. (일부는 Netflix의 고속 성장 비법을 확인하실 생각으로 보신 분도 있겠지만.. 뭐 틀린 이야기는 아닐 것 같습니다.)
현실적으로 모든 것을 따를 수는 없겠지만, 저 자신을 돌아봐야 할 때 다시 한번 읽어 볼만한 부분은 여전히 많은 것 같습니다. 시간이 지나면서, 큰 규칙보다 점점 절차를 만들어 가는 경우가 있는데, 아마도 두려움이 많아졌기 때문이 아닌가 싶습니다.
저는 회사란 것이 “kid’s recreational team”이 아닌 “pro sports team”이여만 하고, 실제로는 이보다 ‘더욱 더 같이 발전하는 관계’라는 관점에 공감하며, 매우 좋아합니다. 이런 관점에서 ‘나에게 자극을 줄 수 있는 좋은 동료’가 많은 회사가 좋은 회사인 것이죠. 이런 분들이 같이 있을 때 감사하는 마음을 가지게 되며, 저도 남에게 ‘좋은 자극’이 될 수 있는 사람이 되려고 노력하는 것이 목표입니다.
간혹 ‘즐겁다’를 recreation의 관점에서 보시는 경우가 있는데, 회사에서의 즐거움은 ‘어려운 목표’를 같이 도달했을 때 얻는 것이지, 미디어에서 이야기하는 삶을 즐기는 ‘즐거움’과 거리가 있다고 봅니다. 프로스포츠 팀의 즐거움은 ‘우승’ 혹은 (적어도) ‘향상’이지 않을까요.
또 하나.. 회사의 문화란 “구호”가 아니라는 생각도 아주 중요할 것 같습니다. 구호와 문화가 일치하지 않는 경우는 너무 많으니까요. ‘차카게 살자’는 조폭도 구호가 없는 것이 아니라 그런 문화가 없는 것일테니까요.
좋아하는 책을 다양한 측면에서 읽어보고, 해석하는 것이 매우 즐거울 수 있다는 것 때문에 가끔 번역을 합니다.
다만, 언제부터인가 시간이 부족한 나이가 되면서(진실을 이야기하면 예전처럼 빠르게 배우지 못하는 나이가 되면서 새로운 뭔가를 하려면 더 많은 시간을 사용해야 하는 것이겠습니다.), ‘엔지니어의 정성’의 영역에서 해결되는 일들에 대해서 더욱 충분히 시간을 들이지 못하는 것이 아쉬울때가 많습니다.
분명히 한번씩 더 볼때마다 조금씩 조금씩 더 좋아지는 부분이 있는데, 여러번 읽다보니 너무나 자연스럽게 인지의 밖으로 벗어나는 경우들이 있습니다. 더욱이 고쳐지는 부분들이 적어져서 ‘이부분..’이라는 생각에 넘어간 부분이, 나중에 시간을 두고 읽었을 때 또는 다른 편집자/리뷰어 분들에게 너무나도 명확한 오류를 발견하면서 크게 놀랐던 경우도 있습니다. 어느 순간에는 작업을 끝내야 하는데, 결국 효율성과 효과성, 완결성 사이의 어떤 부분에서 끝내게 됩니다.
항상 마지막 교정본을 보낼때마다 ‘실수로 넘어간 부분이 있으면 어떻게 하지’라는 생각이 듭니다.
편하게 읽을 수 있도록 만들고 싶었는데, 그렇다고 내용이 바뀌면 안되니까 다시 추가했다가 점점 더 복잡하게 만들게 되고, 리뷰하다가 지우는 과정을 반복하게 되더군요. 문제는 여러번 우물쭈물하다가 적은 문장은 이도 저도 아니게 오류가 많은 문장이 되어서, 교정 과정에서 편집자님께 많이 죄송했습니다. 교정도 오랜시간동안 진행되었고요.
역자 서문에도 썼지만, 이 책은 저에게 상당히 깊은 의미가 있는 책입니다.
저는 석사때 한동안 다양한 컴퓨터 아키텍처 책을 읽었던 적이 있습니다. 당시에 교보문고에는 ‘교재’용으로 비교적 저렴하게 나온 원서들이 많았고, 학교 도서관에도 다양한 책이 있었는데, 이 서고의 작은 한 부분을 다 읽어보는게 목표라면 목표였던 시절이었습니다. 당시에는 여러 대가들이 같은 부분을 서로 다른 관점과 여러가지 수준으로 설명하는 것이 재미있었습니다. 또한, 책을 읽을수록 더욱 속도가 붙는 것에 한참 재미를 느끼던 시절이기도 했고요.
이때 읽었던 책 중의 하나가 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장: 분기에 대해서 다룹니다. 연산된 결과를 통해서 만들어지는 플래그를 통해서 ‘조건’ 분기가 이루어지며, 함수 호출은 돌아올 곳을 저장하는 일종의 특수한 형태의 ‘분기’라는 점만 이해하셔도 됩니다.
구체적인 예를 따라가 보시면 더 즐길 수 있으시겠지만, 재미가 떨어지는 수준까지 고민하실 정도는 아닙니다. 위의 내용(개념)만 잡으면서 지나가시고, 언젠가 필요할 때 지나가셨던 부분을 한번 더 읽으시는 게, 이 책을 읽을 때 더 좋은 방식이라 생각합니다.
