[BOOK] 행복한 프로그래밍

책 소개

책 제목에는 프로그래밍 이라는 말을 사용했지만, 읽어보면 프로그래밍 교양서 느낌이 굉장히 많이난다. 그래서 프로그래밍에 종사하지 않는 분이 읽어도 괜찮을 것 같다는 생각이 들었다. 실제로 저자도 책 머릿말에 행복한 프로그래밍 이라는 책 제목에서 프로그래밍이 아닌 “행복한” 이라는 형용사에 초점을 맞춰 소프한 이야기를 전달한다고 적어두었다. 프로그래밍 교양을 탐하고 싶은 분들은 이 책을 꼭 읽어보기 바란다. 책을 통해 간단한 논리(프로그래밍을 안해도 이해할 수 있는 정도?)뿐 아니라 인생에 자세도 함께 배울 수 있는 좋은 기회이다.

인사이트

현재 프로그래밍 업계에 종사하는 입장으로 책을 읽는동안 부끄러움을 느끼고 자세를 다시하자는 다짐을 많이 가졌다. 저자는 책에서 부터 프로그래밍을 좋아하는 것이 많이 보이고 프로그래밍 덕후(?) 기질을 보여주었다. 특히, 영화나 책을 통해 프로그래밍 인사이트를 추출하는 행위들을 보면서 “아 이사람은 찐이다..” 라는 생각이 많이 들었던 것 같다. 책에서 보면 이것보다 더한 사람도 많다라는 걸 이야기하는 것 보고 나도 좀 더 관심을 많이 가져야겠다 생각을 했다. 어느 브런치 글 에서 프로그래밍을 늘리기 위한 사람은 관심도를 향상시켜야하고 시간을 확보해야한다는 적은 것을 보았다. 브런치 글은 2019년에 쓰여졌으며, 나도 당시 2019년에 글을 읽었던 것으로 기억한다. 하지만, 이번책을 통해 브런치글이 다시 떠오르게 되었고 난 지금 관심을 그만큼 갖고 있나? 하는 부끄러움도 많이 들었다. 좀 더 성장하고 더 나은 삶을 꿈꾸기 위해 더 많은 관심을 갖고 치열하게 프로그래밍을 해야겠다는 생각을 했다.

저자는 한국에서 프로그래밍을 한다? 하면 한 번쯤 들어봤을 것 같은 유명한 사람이다. 한국 개발자를 위한 프로그래밍 책 또는 나.프.잘 등을 운영하며 좀 더 나은 개발자 생태계를 구축하기 위해 노력해왔다. 나도 기회가 된다면, 프로그래밍 생태계를 발전 시킬 수 있는데 도움이 되고 싶다.

좋은 구절

책 내용 중 논리적으로 설명하는 부분들도 굉장히 좋았지만, 그 부분은 생략하도록 한다. (그림 추가가 힘들어짐..)

비트코인, 가상화폐는 P2P 라는 프로토콜은 기본적으로 ‘중앙’의 개입을 상정하지 않는다. 정부의 개입을 배제한 비트코인은 가상 세계의 자유주의자들, 사이버 펑크들, 해커들의 열렬한 환영을 받았다. 각국의 정부나 은행은 비트코인을 외면했지만 비트코인에 매료된 B급 경제시장에서는 비트코인을 중심으로 하는 생태계가 형성되기 시작했다.

비트코인의 개념을 쉽게 설명해줘서 좋았고, 한편으로는 우리가 점차 익숙해지고 있구나 하는 생각이 들었다. 가상화폐의 개념은 꽤 오래전에 들어왔다. 하지만, 하드웨어 성능 소프트웨어 기술등이 기반이 되지 않았고 무엇보다 사람들 인식에 가상화폐라는 개념을 심어주기가 너무 힘들었던 것 같다. 최근들어 토스 카카오 등 은행을 내면서 물질적이지 않은 돈에 사람들은 익숙해져가고 있다. 이는 가상화 돈에 익숙해져 가고 있다는 뜻 아닐까? 결국 사람들이 익숙해질 때 쯤 가상화폐가 다시 등장할 것이라 생각한다.

Y2K 버그의 경우를 생각해보면 금방이해할 수 있다. 당장 1밀리초와 1바이트를 절약할 수 있는 기법이 있다고 해도 그것이 장차 프로그램을 관리하게 어렵게 만들 수 있다.

Y2K 버그는 우리가 99년에서 2000년 시대로 넘어가면서 발생한 에러를 말한다. 프로그램을 개발하던 시기 사람들은 2000년을 고려하지 않고, 19xx 중 xx만 변경하면 된다는 생각을 갖고 프로그램을 작성하였다. 따라서, 2000년이 되는 순간 그 전에 개발된 프로그램들이 일제히 버그를 유발했고, 손해가 많이 발생했었다. 프로그램 언어를 선택하는 관점에서 어느 방향으로 가는게 좋을까?를 고민해볼 수 있는 좋은 이야기 인 것 같다.

“도대체 말이지” 하고 롤린스 교수는 말을 시작했다. “내가 (유닉스 운영체제에서) 명령어를 두세번 정도 잘못 입력했으면, 그다음부터는 컴퓨터가 내가 무슨 명령을 내리려고 하는지 대충 알아들어야하는거 아닌가? 어째서 내가 매번 글자 하나 틀리지 않고 정확하게 명령을 내려야 하지?”

위의 문장을 보고 큰 충격을 받았다. 나는 왜 저런 생각을 하지 않았을까? 명령어가 틀리면 그냥 다시 치면 되지 라고 수동적인 생각을하고 살았던 것 아닐까? 더 나은 삶을 만들기 위해서는 질문을 다양하게 던져보는 것이 중요하겠다 생각을 했다.

프로그래머가 갖추어야하는 ‘내공과 외공’이라는 덕목에 항목하나를 또 추가해야한다. 그것은 바로 ‘의사소통 기술’이다.

철학하는 사람은 토론(의사소통)을 통해 자신의 이론을 증명하면된다. 수학자는 수식을 통해 맞다 틀리다만 이야기를 하면된다. 프로그래머는..? 둘 다 고려해야한다. 어찌보면 두 가지의 능력을 가져야한다는(?) 좋은 관점으로 생각하자 :)

프로그래머들의 실력이 제아무리 뛰어나다고 해도 버그가 없는 프로그램을 만들수는 없다. 그것은 마치 바둑의 최고 고수인 이세돌이나 조훈현 같은 사람들도 실수를 범해서 승부를 그르치는 일이 있는 것과 마찬가지다.

프로그래머들은 버그가 없는 프로그램을 작성할 수 없다는 것을 인정하자. 그럼 버그가 유발을 막으려면 어떻게 해야하는가?

두가지이다. 하나는 소프트웨어의 치명적인 허점이 발견될 때마다 고객으로 부터 받은 금액 일부를 환급해주거나 고객 사이트에 직접 사람을 보내서 패치를 설치하는 방법이다. 이는 비용이 많이든다. 또 다른 하나는 오픈소스 소프트웨어나 자유 소프트 웨어의 형태로 프로그램을 공개하여 외부 프로그래머들의 도움을 받는 것이다. 이는 곧 독점적인 저작권을 포기해야함을 뜻한다.

둘 다 매력을 갖는 방법이지만, 역시나 리스크는 존재한다. 어떤 방향으로 버그를 막아야하나.. 그건 owner의 결정에 따르겠지만, 개인적으로는 후자가 더 낫다고 생각한다. 질 좋은 소프트웨어를 위해!