The fact.: 설명은 쉽지 않다.

HAJUNHO

brunch.co.kr/@hajunho 글쓰기 좋아요 알림

내 브런치
작가의 서랍
통계

브런치 홈
브런치 나우
브런치 책방
피드
위클리 매거진

설정 로그아웃

경험주의자
설명은 쉽지 않다.

base에는 항상 이 생각뿐.
byHAJUNHOJun 12. 2016

하루의 대부분을 2권의 책을 쓰는데 보내고 있다. 6개월 만에 끝내는 것이라면 정말 대단히 빨리 쓰는 것이라는 기준점을 받았지만 한번 집중하면 18시간 이상씩 매달리다 보니 첫권이 초안은 1달 반 만에 나왔고, 공저자의 피드백을 거쳐 초안 2, 초안 3으로 넘어가고 있다. 첫권의 소스는 기술의 흐름을 타는 것도 아니고, 검증이 딱히 필요 없는 부분이고 이미 오랫동안 갈구하던 책이었기에 오래간만에 리얼포스 하이프로 키보드를 두드리는 재미에 흠뻑 빠졌다. 물론, 출판사 프로세스를 보면 모든 과정이 끝나려면 출판까지 최소 8개월이다. 와이프한테 비싼 키보드를 여벌로 여러 개 사놓은 것에 대해서도 이제 변명을 할 수 있을 것도 같다. 해피해킹이 단종만 안되었어도 이런 두려움은 없었겠지

기술이 자꾸 깊어지는 책의 경우 문제가 발생한다. 설명의 최종판은 항상 어셈블리어로 끝나는 것이 정석이다. 왜냐면 컴퓨터가 알아듣는 언어는 기계어이고 해당 기계어가 돌아가는 프레임웍(보통은 운영체제)까지 설명해야 유레카를 외치게 만들 수 있기 때문이다.

JAVA 설명하면서 JVM 소스를 파헤치고 그것을 토대로 설명을 하는데 PE 파일 포맷 구조에 파일 시스템까지 들어가고 이기종까지 설명하려니 ELF랑 EXT4, Mach-O랑 HFS+... 그간 유사 프로젝트들을 진행하면서 빠르게 지나가야 했던 풍경들을 다시 찬찬히 볼 수 있는 기회가 기쁘기도 하다. 그러나 마냥 자신이 좋아서 쓰는 거면 "블로그"나 "일기"를 쓰는 게 맞다. 중간 뭉치들을 동료 프로그래머들을 통해 중간 피드백을 거치면 항상 어려운 설명으로 치부되고 만다. 내가 쓰고 싶은 글로만 남겨져 버리고 만다. 늘 자전거를 가르친다는 기준으로 생각하는데 어떤 코스는 정말 비슷한 길을 가 본 사람만이 서로에게 설명할 수 있는 것들이 있다는 것이 너무도 아쉬울 뿐이다. 세미나 및 개인 지도도 하다 보면 바로 옆에서 가르쳐 줘도 개개인의 수많은 지식이 다름에 맞춤형 지도를 선택해야 한다. 공통적으로 보는 책이니 타깃 독자를 고려하고 하나의 주제로 나아가며, 너무 잘하거나 도저히 못 따라올 이상치에 있는 독자를 배제해서 평균적 설명을 하려고 노력하더라도 중위수까지 맞추기는 쉽지가 않다. 설명의 폭이 평균 안에 있다고 해도 최댓값, 최솟값을 왔다 갔다 하고 최솟값에 있는 독자들은 따라오지 못할 거라는 두려움이 앞선다. 그래서 장황한 설명이 이어지면 최댓값에 가까운 독자들은 지루함을 느낄거라 예상한다. 내 능력상으로는 얻지 못하는 최신 통계지만 생각에 도움이 되려고, 수년 된 통계치를 조사하기도 한다. 타깃 독자층의 대상을 조사하고, 상반되는 의견을 가진 책들도 조사하고 그들이 대상으로 하는 독자층, 전국 대학생 수 및 IT 관련 학과 수, 학생 수, 학원 강사를 하다 보면 남녀가 받아들이는 방식도 다르기 때문에 남녀 비율을 보다 보면 2016년 최신의 통계치를 얻는 것은 힘들기 때문에 최근에 가르쳤던 경험들이 정말 소중함을 느낀다.

이런 저런 생각 중 아이디어가 떠올랐다.

처음부터 끝까지 Source로 설명하고 그것이 주가 되면 어떨까? 그런데 해당 Source를 이해하는지 자기 평가를 할 수 있도록 Self-Tests를 제공한다면 책을 읽기 전에 스스로 설명하는 타깃 독자층의 평균에 있도록 할 수 있지 않을까? 하는 것이다. 자칫하면 소스 설명서가 될 수도 있기는 하다. 그리고 나역시 그런 류라면 온라인이 훨씬 좋다.

최근 신입 프로그래머들을 대상으로 평가를 진행했는데 반발이 엄청났다. 프로그래머를 어떻게 평가할 수 있겠냐는 것이었다. 그도 그럴 것이 과학기술원, 서울대, 연세대, 한양대 등... 나랑 같이 잘못된 교육 과정에서 성장했지만 머리는 똑똑한 친구들이기에 충분히 그럴 수 있다는 생각이 들었다. 여기에 대한 논리로는 딱 2가지 밖에 없다.

1. 피 평가자가 원하는 것을 듣고 그 원하는 것의 공통분모를 찾아내어서 문제를 내야 한다.

2. 문제는 피 평가자가 맞거나 틀린 문제에 대해서 수긍이 가능하도록 완벽해야 한다.

는 것이다.

여기서 오는 스트레스는 상당할 것 같지만 생각 외로 쉽다. 이미 많은 교수님들이 또 책의 저자들이 항상 말하던 기초 안에 답이 있기 때문이다. - 사실, 소프트웨어 공학적으로 생각하면 더 잘하는 사람에게 맡겨도 된다. - 다만 조금 아쉬운 것은 이미 있던 책에 있는 좋은 내용을 싣고 싶은데 그러지 못하는 부분도 있다. 한동안 너무 연락을 안 하던 고교 동창에게 연락도 해야 했다. 연락처는 폰 바꿀 때 마다 새롭기에 페이스북 밖에 연결점이 없어서 쓴 책 내용이 너무 좋아서 일부분을 가져와서 그대로 쓰고 싶다고 물었는데 묵묵부답이다. 해당 책은 절판된 지 많이 오래되어서 출처 밝히고 그대로 쓰고 싶은데 말이다. 결국 더 나은 설명 방법을 고심을 하려고 해도 이 정도면 내가 원하는 독자들에게 딱인데 하는 아쉬움이 남는다. 어차피 외서에 다 있는 내용이라 더 낫도록 설명하는 '척'을 해도 되지만 성격상 맞지도 않다.

헛소리로 마무리를 짓게 될 것 같다.

사실 Thinkpad를 찬양할 때는 "뚝심"이란 게 있었고, 애플 제품으로 모두 넘어오고 나서는 좋은 건 그냥 좋은 대로 가는 것이 좋다는 식으로 삶의 철학이 바뀌었다. 애플이 자사 칩을 써도 되는데 Intel이 좋으니 Intel을 썼던 것이랑 같다. 또한, 옛것도 쉽게 버려 버린다. 그러면서도 중요한 부분은 그대로 살리려고 한다. 이 철학을 이어받는다면 독자들에게 정말 중요한 부분은 굳이 더 가공할 필요 없기도 하다는 것이다. 왜 진정 IT 발전을 위하는 사람들이 GPL 정신으로 무장하는지 다시 한번 깨닫게 되는 사색이다. 일단 개인의 역량으로 맡기고, 프로그래밍을 공부하게 해 주었던 창시자들의 책을 기초로 생각할 시간을 추가해야겠다.

개인적으로 가장 멋진 철학을 가지고 있는 기업이라고 여겨졌던 Sun Microsystems 社처럼 내 책에 모든 프로그래머들을 위하는 철학도 담겼으면 좋겠다. 앞으로 내년 3월 까지는 한권의 기술적 내용을 온라인에 담지는 않을 것 같다.

내가 이렇게 말하는 언어도 누군가가 만든 것이고(한글은 당연히 세종대왕), 컴퓨터도 누군가가 만든 것이고, 내가 얻은 프로그래밍 지식도 누군가가 만든 프레임웍 속에서 했던 프로젝트에서 나온 결과물을 뿐이겠지만 말이다.
keyword
설명
프로그래밍
magazine경험주의자
설명은 쉽지 않다. 현재글
김제동이 대단한 이유
삶의 아이러니