독후감 - 코딩 호러의 이펙티브 프로그래밍
스택 오버플로우 공동 창립자가 알려주는 소프트웨어 개발의 비밀
내가 읽어 본 IT 관련 서적은 크게 두 분류로 나눌 수 있었다.
1. 순수 기술 서적
대표적인 예를 들자면, 자바 개발자라면 누구나 한 번쯤 읽어봤음직한 헤드퍼스트 자바(http://shopping.daum.net/search/%ED%97%A4%EB%93%9C%ED%8D%BC%EC%8A%A4%ED%8A%B8%20%EC%9E%90%EB%B0%94/&docid:H3499502251&srchhow:Cexpo)가 있겠다. 이런 책들은 대부분 바로바로 실전에 적용할 수 있게 문제 해결을 위한 코드나 방법이 구체적으로 나와있다.
2. 프로그래밍 '철학' 서적
이런 책은 당면한 업무 문제를 빨리 해결하는 데는 별 도움이 되지 않는다. 대신 프로그래머로서 내 진로 전반을 돌아보고 계획하는 데 도움을 준다. 폴 그레이엄이 쓴 해커와 화가(http://book.daum.net/detail/book.do?bookid=KOR9788968480713) 도 이 쪽 분야에서 추천할 만한 책이다.
올바른 자기계발을 위해선 두 분류 간 독서량 균형을 잘 맞춰야 한다고 생각하지만
자꾸 2번 쪽 책에만 손이 간다. 1번은 보면서 노트북을 켜고 실제 적용을 해봐야 하는데 퇴근 후 하려니 시작이 너무 힘들다. 2번 책은 들고 다니면서 출퇴근 길에 봐도 되고, 애들 잠든 틈을 타 소파에 누워서 봐도 잘 읽힌다. 그래서 1번 책은 정말 급할 때 필요한 부분만 발췌 독서를 하게 된다. 이런 방식도 나쁘진 않다. 그렇지만 좀 더 깊이 있게 파악하려면.. 진짜 내 지식으로 만들려면.. 정독 및 실습이 필요한데.. 애들이 좀 더 커야 가능할 거 같다.
아무튼 빌려온 책을 반납하기 전에 독후감을 남긴다.
이 책에 관심이 간 건 이 책의 저자가 스택 오버플로우(https://stackoverflow.com/)의 공동 창립자이기 때문이다. 프로그래밍 하면서 최근 몇 년 동안 스택 오버 플로어에서 정말 많은 도움을 받았다. 홈페이지상 설립년도는 2008년인데, 내가 실제로 알게 된 건 3년 전인 2014년쯤이다. 좀 더 일찍 알았으면 야근이 줄어들었을테지. 늦게 알아서 아쉽다. 이 정도의 사이트를 만들고 운영한 사람이 쓴 책이라면 내게 많은 도움이 될 거 라는 생각이 들었다.
완독 결과, 매우 만족스럽다. 기분이 좋다.
이 책의 내용은 저자가 운영하는 블로그의 게시물을 엮은 것이다. 저자는 프로그래머로서 일하며 경험했던 내용들을 블로그에 올리고 있는데, 그 내용들이 매우 알차다. 블로그에 올려진 수많은 게시물들을 적당히 추려 책으로 출판한 거 같다. 책의 꼭지는 저자가 블로그에 올린 게시물 단위다.
책의 초판이 출판된 게 2013년이고, 블로그에 게시된 건 그보다 더 전일 테니, 책 내용 중 몇몇 꼭지들은 out of date란 느낌을 받을 수 있다. 하지만 그 당시의 상황을 고려하여 저자가 어떤 식으로 생각을 풀어나갔는지를 확인할 수 있으니 읽어보면 나름 도움이 된다.
이를 테면 https와 관련해서 저자가 처음에는 굳이 모든 사이트가 전부 https를 사용할 필요가 있을까라고 의문을 제기한다. 현재 컴퓨팅&네트웤 성능의 향상과 보안 이슈와 맞물려 대부분 https 로 전환돠고 있는 상황에 비추어 볼 때 저자의 생각은 틀렸다고 할 수 있다. 이런 부분에선 이 정도의 프로그래머도 잘 못 판단할 수 있구나 라는 생각이 들며 위안이 된다. 저자는 뒤에 올린 글에서 자신의 생각이 틀렸음을 인정한다. 이렇게 자신의 생각이 틀렸음을 인정하는 자세 또한 배울 만한 점이다.
독후감은 내가 인상 깊었던 꼭지 위주로 남긴다.
책에서 꼭지의 시작을 ;로 하고 있어 독후감에서도 그대로 표시했다.
;그들이 어떤 말을 하든 그것은 결국 사람과 관련된 문제다
저자는 이 꼭지에서 브루스 에켈이라는 사람의 말을 인용한다. 브루스 에켈 이란 사람은 내가 식견이 짧아 잘 모르겠다. 이 꼭지에서 저자는 프로젝트의 성공 여부를 판단할 수 있다는 3가지 질문을 말한다.
1. 당신의 팀이 얼마나 많은 줄의 코드를 작성할 것인가?
2. 어떤 종류의 소프트웨어를 만드는가?
3. 동료 프로그래머들을 좋아하는가?
이 3가지 질문 모두 인상적이었지만 그중에서도 마지막 3번째 질문이 가슴 깊이 와 닿았다.
나는 지금 내가 좋아하는 사람들과 일을 하고 있는가.
저자는 꼭지 말미에 이렇게 덧붙여 놓았다.
그리고 지금까지 나 자신의 경험에 비춰봤을 때
직업 만족도는 거의 완벽하게
성공 여부와 연관된다.
행복하고, 건강하고, 손발이 척척 맞고,
사회적 기능이 원활하게 돌아가는
소프트웨어 개발팀이 실패하는 경우를
나는 본 적이 없다.
그런 팀이 별로 많지 않다는 사실은
아쉬운 일이다.
이런 팀원을 만난 적이 있었던가 라는 질문 전에 나는 과연 이런 팀원인 적이 있었던가 라고 돌아보게 되었다. 너무나도 이런 팀원이고 싶고, 너무나도 이런 팀원을 만나고 싶다.
;저길로 가라 총알처럼
이 꼭지에서 저자는 스택오버플로우를 회사의 관점에서 운영할 때, 비즈니스와 관련된 조언을 커티스 암스트롱이라는 한 사람으로 부터만 받고 있다고 한다. 마치 유명한 경영인 같았지만 알고 보니 미국의 유명한 코미디언이었다.
저 길로 가, 총알같이 빠르게. 눈앞에 뭐가 나타나면 방향을 틀어.
산에서 스키를 타는 방법에 대해 커티스 암스트롱이 이렇게 말했다고 한다.
스스로 돌아보면 내가 가장 못하는 방법이다. 소심하고 걱정이 많은 나는 일단 시작하는 법을 모른다. 또한 문제에 부딪쳤을때 대담하게 방향을 틀 줄도 모른다.
저자가 든 다른 예시는 구글 크롬과 MS 익스플로러의 차이다. 크롬이 2008년 12월 11일부터 2010년 9월 2일까지 V1에서 V6으로 발전하는 동안 익스플로러는 V7에서 V8까지 단 한 번 버전업이 되었다고 한다. 그 차이의 결과는 우리 모두가 잘 알고 있다. 익스플로러는 시장점유율의 상당 부분을 크롬에게 내주었다.
지금 나에게 가장 필요한 기술은 저 길로 총알처럼 가는 기술이다.
;버전 1은 엉망이야. 하지만 어쨌든 출시하라고.
이 꼭지는 바로 위 꼭지와 연결된 내용이라고 할 수 있다.
저자가 말한 것처럼 대부분의 소프트웨어 개발자는 완전히 만족하면서 버전 1을 출시하지 않는다. 아마 개발자들에게 데드라인을 연장할 수 있는 권한이 주어진다면 그들은 무덤에 들어갈 때 까지도 버전 1을 출시하지 않을 것이다.
하지만 이는 잘못된 행동이다. 저자가 말하고자 하는 바를 요약하면 다음과 같다.
아무리 디버깅해도
결국 우리가 파악할 수 있는 결함엔 한계가 있다.
따라서 적당한 선에서 끊고 일단 출시한 뒤에
실제 사용자의 피드백을 받아 디버깅하는 게
훨씬 효율적이다.
여기서 중요한 건 출시한 뒤 우리의 태도다.
사용자의 피드백에
어떤 태도로 얼마나 빨리 반응할 것이냐가
진짜로 중요한 점이다.
사용자는 하나의 버전보다는
우리가 피드백에 반응하는 속도와 태도에
더 크게 좌우된다.
물론 소프트웨어의 종류에 따라 이견이 있을 수 있다. 미사일에 들어가는 소프트웨어를 이런 식으로 출시할 수는 없을 테니. 하지만 그런 경우에도 내가 만든 모듈을 나 혼자 100% 검증할 수 없으니 적당한 선에서 통합 테스트 쪽으로 연결을 시킨다 라는 식으로 이해하면 될 것 같다.
소프트웨어는 일단 출시하고,
그 후 피드백에 따라 총알같이 빠르게 반응하는 쪽이 나은 거 같다.
;애플리케이션은 결국, 작은 디테일의 모음이다.
소프트웨어 개발을 하다 보면 스스로 메인 기능, 킬러 기능이라고 생각하게 되는 기능이 생긴다. 그리고 자연히 메인 기능 개발에만 주력하게 되면서 상대적으로 다른 디테일 기능에 소홀하게 된다. 저자가 이 꼭지에서 말하고자 하는 부분은 이런 부분이다.
디테일을 소홀히 하지 말자.
잠깐 생각을 해보았다. 정말 킬러 기능이 뛰어나고 선구적이어서 디테일이 다소 미흡하더라도 성공할 수 있는 소프트웨어가 있을까? 예를 들어 만약 티맵이 막히는 상황까지 고려한 가장 빠른 길을 기가 막히게 찾아내지만 실행 후 맵을 보기까지 매번 두 세 단계의 터치를 거쳐야 했었다면? 구글이 지금의 검색 능력은 그대로 갖췄지만 최초 페이지가 마치 네이버와 같았다면?
이런 식으로 생각해보면 애플리케이션은 결국, 작은 디테일의 모음이란 말에 동의하지 않을 수 없다.
메인 기능은 당연히 잘 작동해야 한다. 그런데 거기서 멈추면 안된다. 메인 기능이 작동하는 속도, 메인 기능 실행까지의 UX 등의 디테일이 잘 더해져야 한다. 그래야 시장에서 살아남을 수 있다. 요즘 세상에서 내가 만든 메인 기능은 여기저기서 쉽게 개발할 수 있는 기능일 가능성이 크다. 메인 기능 하나만 믿고 있다간 금방 따라 잡히고 말 것이다.
;사용자 인터페이스가 애플리케이션이다
아무리 뛰어난 기능과 성능을 갖춘 애플리케이션이라도 사용자가 UI에 질려 사용하길 거부한다면 아무짝에 쓸모없는 애플리케이션이 될 것이다.
물론 내부 기능이 전부 완성된 뒤에 사용자 인터페이스를 설계, 개발하겠다고 생각할 수 도 있다.
하지만 이 말은 틀렸다.
일단 UI가 바뀌면 애플리케이션의 많은 부분이 바뀔 가능성이 크다. 전부 완성되었다고 생각한 내부 기능의 핵심 모듈까지도 건드려야 할 수도 있다.
두 번째로 시간이 기다려주지 않는다. 총알처럼 빨리 가기 위해서는 사용자에게 되도록 빨리 검증을 받아야 하는데 이때 UI가 뒷받침해주지 않는다면 피드백이 효과적으로 나오지 않을 가능성이 크다. 따라서 UI도 내부 기능만큼이나 빨리 개발되어야 한다.
;프로그래머 권리 장전
프로그래머로서의 자기 권리를 주장하라!
그리고 기억하라.
당신은 회사를 바꾸거나(이직)
아니면 회사를 바꿀 수 있다는(회사 개혁)
사실을
이런 관점에서 저자는 다음과 같은 권리를 주장한다.
1. 모든 프로그래머는 두 대의 모니터를 가져야 한다.
2. 모든 프로그래머는 빠른 PC를 가져야 한다.
3. 모든 프로그래머는 마우스와 키보드를 자기가 원하는 것으로 선택할 권리가 있다.
4. 모든 프로그래머는 편안한 의자를 가져야 한다.
5. 모든 프로그래머는 인터넷에 연결할 수 있어야 한다.
6. 모든 프로그래머는 조용한 작업 환경을 가져야 한다.
워낙 구체적으로 잘 정리된 권리 장전이라 내가 특별히 덧붙일 만한 내용이 없다.
현재 내가 일하는 사무실 환경에 비추어 볼 때,
이 중에서 특히 5번과 6번이 절실하다.
;무질서한 원숭이와 함께 일하기
제목만 보면 무슨 내용인지 한 번에 파악하기 힘들다.
우선 요약하자면 이렇다.
우리 시스템이 있다.
그리고 그 옆에 아무 생각 없는 원숭이가 있다.
원숭이가 우리 시스템의 어느 한 부분을 가리키면 그 부분은 다운된다.
이런 원숭이와 함께 일하게 된다면?
자연히 시스템을 fault tolerance 하게 만들게 된다.
이 꼭지에선 두 가지 사례가 소개된다.
첫 번째는 넷플릭스가 자사 테크 블로그에 올린 내용이다.
넷플릭스는 AWS로 옮겨간 뒤 여러 번 원인 파악이 힘든 장애를 경험한 거 같다. 그래서 그들은 각각의 시스템이 다른 시스템의 상태와 상관없이 본인의 서비스를 제공할 수 있도록 설계했다고 한다. 이를 테면 개인화된 DVD 추천 시스템이 다운되면 고객에게 아무 서비스도 제공되지 않는 대신 일반화된 추천 DVD가 화면에 나타나는 식이다. 이를 위해 넷플릭스는 무질서한 원숭이라는 시스템을 구축했다. 그리고 이 원숭이 시스템과 함께 넷플릭스의 아키텍처는 강력하게 발전해나갔다.
두 번째는 저자가 직접 겪은 일이다.
상황은 비슷하다. 며칠마다 한 번씩 원인 파악이 불가능한 서버 다운이 발생했고, 셧다운 외에 할 수 있는 조치가 없었다. 결국 이들은 서버를 이중화하고, 백업 기능을 만들고, 의존성을 제거하고, 핵심서 버가 동작을 멈춘 뒤에 대한 대비까지 마련해놓았다. 그리고 그들도 무질서한 원숭이를 기르게 되었다.
무질서한 원숭이가 갖는 장점은 분명하다. 원숭이 덕분에 작은 실패를 거듭하며 발전하게 되는 것이다.
내가 후에 어떤 소프트웨어를 책임지고 개발하게 된다면, 이 원숭이 시스템을 꼭 도입하고 싶다.
;빠른 해싱
저자는 해시와 체크섬의 차이를 말하면서 시작한다.
체크섬이 사람의 이름이라면 해시는 사람의 지문이다.
사람의 지문은 고유해서 신분에 대한 증명이 가능하다. 따라서 보안에 신경을 많이 써야 한다.
하지만 이름은 고유하지도 않고 신분에 대한 증명도 불가능하다. 여기선 보안이 중요한 고려사항이 아니다.
체크섬은 보통 전송 데이터에 적용되기 때문에 빠르게 계산되어야 한다.
하지만 해시는 보안을 위해 사용되기 때문에 오히려 계산이 느릴 필요가 있다.
최근 GPU 컴퓨팅 파워가 혁신적으로 개선되면서
어렵고 느린 연산을 무기로 쓰던 해시가 위험에 노출되고 있다.
관련해서 저자는 직접 수행한 실험 결과를 블로그에 올려놓았다.
실험에서 저자는 ATI Radeon 7970 그래픽 카드를 사용했는데 2012년에 출시된 제품이니
최근에 나온 그래픽카드로 교체 후 실험하면 더 빠른 결과가 나올 것으로 예상된다.
실험 내용은 몇 개의 문자로 구성된 비밀번호 MD5 해시를 대상으로
GPU를 이용하여 비밀번호를 찾는 실험이다.
첫 번째 실험은 US 키보드의 키값을 전부 이용하는 형태의 실험이었다.
실험 결과 6개의 문자로 구성된 비밀번호 MD5는 47초 만에 풀렸다.
7개는 1시간 14분, 8개는 약 465일이 걸렸고 9개는 알 수 없음이란 결과가 나왔다.
두 번째 실험은 대소문자와 숫자 키값만 이용하는 형태의 실험이었다.
이 실험에선 9개 문자까지 10일에 풀렸고, 11개는 되어야 알 수 없음이란 결과가 나왔다.
이런 실험을 보면 비밀번호의 길이와 특수문자 사용 여부가 왜 중요한지 알 수 있다.
꼭지 말미에 SALT란 개념이 나온다. 해시 값에 적용하면 해시값 자체를 다시 한번 바꿔주는 기법 같은데,
이 책에서 처음 접하게 된 개념이라 구체적으로 어떤 방식인진 이해하지 못하고 넘어갔다.
;사전 공격 기초
이 꼭지 역시 보안과 관련된 꼭지이다.
사용자가 설정하는 비밀번호의 길이와 구성에 대해 말하고 있다.
사전(dictionary) 공격이란
비밀번호를 공격할 때 사전에 나와있는 단어만 사용하여 공격하는 것을 의미한다.
사용자가 비밀번호를 만들 때 보통 의미가 있는 단어를 사용하는 경우가 많기 때문에 가능한 공격 기법이다. 저자가 글을 쓸 당시 옥스퍼드 사전에는 약 171,000개의 단어가 수록되어 있었다고 한다.
만약 비밀번호가 7개의 소문자로 이루어져 있고 사전의 제약이 없다고 하면 가짓수는 80억 개 정도 된다.
비밀번호 설정 시 자신만의 조합을 사용하라고 권장하는 이유이다.
보통 이런 형태의 공격은 비밀번호를 찾을 때까지 무한정 로그인 시도를 하게 된다.
따라서 이런 공격을 막기 위해서 로그인 시도 가능 횟수를 제한하는 방법이 등장했고,
각 로그인 실패마다 일정 시간의 지연을 설정하는 방법도 등장했다.
그리고 몇 번의 실패가 반복되면 화면에 캡챠(CAPTCHA, 복잡한 그림 배경의 문자 그림을 띄우고 해당 문자를 입력하라고 하는 것)를 띄우기도 한다.
최근에 비밀번호 설정이 왜 어렵고 복잡해지는지, 로그인 시도에 제한을 두는지 이해할 수 있는 꼭지였다.
;프로그래머가 어째서 프로그래밍을 못하는 걸까?
이 꼭지에서 기억에 남는 부분은 '피즈 버즈(FizzBuss) 질문'이다.
피즈 버즈 질문은 아래 내용의 프로그램을 작성하는 문제이다.
1~100까지 수를 출력하는 프로그램을 만드는데,
3의 배수에선 숫자 대신 Fizz를 출력하고, 5의 배수에선 Buzz를 출력한다.
그리고 3과 5의 배수에 모두 해당할 때는 FizzBuzz를 출력한다.
여기까지 읽었을 땐 굉장히 간단한 문제라고 생각했다.
그런데 다음 제약사항을 보고 생각이 바뀌었다.
이 프로그램을 손으로 2분 내에 종이에 적을 수 있는가?
IDE의 도움 없이 손으로 2분 내라면 생각보다 쉽지 않을 문제였다.
;전화 인터뷰로 걸러내는 과정을 올바로 수행하기
이 꼭지에서도 인터뷰 관련 질문들이 크게 5가지 분류로 나왔다.
1. 코딩. 후보자는 본인이 자신 있는 언어를 사용해 정확한 문법으로 간단한 프로그램을 작성해야 한다.
- 문자열의 순서를 뒤집는 함수를 작성하라.
- N번째 피보나치 수를 계산하는 함수를 작성하라.
- 구구단 표를 12*12까지 출력해보라
- 한 줄에 하나의 정수가 적혀 있는 텍스트 파일을 읽어 그것들을 모두 더하는 함수를 작성하라
- 1~99 사이에 존재하는 홀수를 모두 출력하는 함수를 작성하라.
- 정수형 배열에서 가장 큰 값을 찾아라
- (세 개의 1바이트 수로 이뤄진) RGB 값을 6개의 수로 이뤄진 16진수 문자열로 표현하라
2. 객체지향 설계.
후보자는 기본적인 객체지향 개념을 설명하고, 간단한 문제를 해결하기 위한 클래스를 만들어야 한다.
- 여러 가지 카드 게임 애플리케이션에 사용할 수 있는 카드 한 벌을 설계해 보라.
- 가상 동물원 프로그램에서 사용할 수 있게 동물의 왕국을 클래스 시스템으로 모델링 하라.
- 파일 시스템을 나타내는 클래스를 설계하라
- HTML을 모델링하는 객체지향 표기법을 설계하라
3. 스크립트 작성과 정규 표현식. 후보자는 50,000개의 HTML 페이지에서 전화번호를 추출해 내야 한다.
/website라는 유닉스 디렉터리 트리 안에 50,000개의 HTML 페이지가 있다.
모든. html 파일 중에서
(xxx) xxx-xxxx 혹은 xxx-xxx-xxxx라는 형태의 전화번호를 담고 있는 것으로 보이는 파일의 목록을
이틀 안에 제출할 수 있도록 작성해보라
4. 자료구조. 후보자는 기본적인 자료구조에 대한 지식을 드러내야 한다.
- 예를 들어 java.util 같은 데 포함되어 있는 아주 흔한 자료구조는 무엇인가?
- 언제 연결 리스트를 사용하고 언제 벡터를 사용할 것인가?
- 트리를 이용해 맵을 구현할 수 있는가? 리스트도 구현할 수 있는가?
- 트리에 저장돼 있는 노드를 각 레벨 순으로 출력하려면 어떻게 해야 하는가?
(즉, 첫 번째 레벨의 노드를 모두 출력하고, 그다음에 두 번째 레벨, 다음에 세 번째 레벨과 같은 식으로 진행하는 것이다.)
- 해시 테이블에 데이터를 추가할 때 최악의 경우에 해야 하는 성능은 무엇인가? 이진트리의 경우는?
- 우선순위 큐를 구현하기 위한 방법으로는 어떤 것들이 있는가?
5. 비트와 바이트. 후보자는 비트, 바이트, 이진수에 대한 간단한 질문에 답해야 한다.
- 바이트 안에 존재하는 최상위 비트의 값이 설정돼 있는지 검사하는 방법을 말하라
- 정수 안에 존재하는 모든 비트의 수를 세는 함수를 작성하라. 이 함수의 시그니처는 다음과 같다. int CcountBits(int x)
- 정수를 받아들여 그 수의 비트 패턴이 해당 패턴을 거꾸로 했을 때와 동일하면(회문 형태라는 뜻이다) 참을 반환하는 함수를 작성하라. 시그니처는 이렇다. boolean isPalindrome(int x)
이 질문에 나는 전부 대답할 수 있는가?
물론 이 질문에 전부 대답한다고 훌륭한 프로그래머라고 100% 확신을 할 순 없다.
반대로 대답 못했다고 훌륭한 프로그래머가 아니라는 확신도 할 수 없다.
하지만 결국 여러 자원의 제약이 있는 인터뷰라는 관점에서
회사는 대답을 잘하는 사람이 높은 확률로 훌륭한 프로그래머라고 가정할 수밖에 없을 것이다.
;몇 년이나 경험했는가, 라는 질문에 담긴 미신
저자는 '특정 플랫폼에서 몇 년동안의 경험 필요!' 라는 식의 채용공고가 무의미하다고 말하고 있다.
한발 더 나아가서 이런 식으로 채용공고를 내는 회사를 조심하라고 얘기한다.
100% 동의할 순 없지만, 중간에 저자가 던진 이 말은 맞는 거 같다.
어느 특정한 기술적 내용이라도
그것을 이용해 12개월 정도 일을 하고 나면
그것에 정통하거나 아니면 영원히 정통할 수 없거나 둘 중 하나다
이 글을 읽고 나서 스스로를 돌아보게 되었다. 슬프다.
;쓰지 않으면서 쓰기
이 꼭지를 읽고 이 독후감을 쓰게 되었다.
인용된 말들이 매우 훌륭하다.
그래서 그대로 옮겨놓았다.
다음은 스택오버플로우의 공동 창시자인 조엘 스폴스키의 글에서 따온 내용이라고 한다.
그저 참고 봐줄 만한 프로그래머와
위대한 프로그래머 사이에 존재하는 차이는
그들이 얼마나 많은 언어를 알고 있는가가 아니다.
그들이 파이썬을 선호하느냐 자바를 선호하느냐도 아니다.
그것은 그들이 자신의 아이디어를
얼마나 잘 설명하는가에 달려있다.
위다핸 프로그래머는 다른 사람을 설득함으로써 영향력을 확대한다.
명확한 설명과 기술적인 스펙을 통해 그들은
다른 프로그래머들이 자신의 코드를 잘 이해하게 만들고,
그렇게 함으로써 다른 프로그래머들이 새로운 코드를 작성하는 대신
자기가 작성한 코드를 사용할 수 있게 만든다.
이러한 능력이 없다면 그들이 작성하는 코드는 아무 의미가 없을 것이다.
다음은 저자가 직접 쓴 글 같다.
사람들은 효과적으로 글을 쓰는 방법을 익히면서 평생을 보낸다.
이 과정에는 속임수가 없다.
글을 쓰는 능력은 돈을 주고 살 수도 없다.
스스로 열심히 익히는 방법 외에는
다른 방법이 없다.
바로 그렇기 때문에 글을 쓰는 것을 두려워하는 사람들은 블로그를 시작해야 한다.
그것은 일종의 운동과 같다.
아무리 몸매가 엉망인 사람이라도
매주 몇 번씩 운동을 열심히 하다 보면 몸매가 차츰 나아지기 마련이다.
자신의 블로그에 짧은 글이나마 일주일에 몇 차례씩 글을 올리면
글쓰기 능력도 차츰 나아진다.
글을 쓰는 것이 무서워서 글쓰기를 회피하면
엉망인 몸매로 평생을 살아가야 한다.
마지막으로 저자가 인용한 존 스키트 란 사람의 글이 인용되어 있다.
모두가 아주 많이 글을 써야 한다.
블로그든, 책이든, 스택 오버플로우의 답글이든, 이메일이든 상관없다.
글을 쓰고, 그 글에 대해 잠시 생각을 하는 것이다.
내 경험에 의하면
글을 명확하게 하는 것은
자신의 내면적 사고의 흐름을 명확하게 하는 데 도움을 준다.
어떤 것을 다른 사람에게 정확하게 설명하고자 노력해 보면,
자기가 얼마나 많은 부분을 제대로 모르고 있었나
하는 것을 깨달으며 놀라게 된다.
바로 그 지점에서
완전히 새로운 발견이 시작되는 것이다.
윗글에 100% 공감한다. 너무나도 많이 경험해 본 일이다.
특히 회사에서 여러 사람을 리스트에 넣고 메일을 작성할 때 자주 경험한다.
메일을 작성하다 보면 내가 이 현안에 대해서 잘 이해하지 못했던 점들이 속속들이 나타나기 시작한다.
그래서 메일을 완성할 즈음엔 최초 작성 시 의도했던 것과는 사뭇 다른 논조로 메일이 발송될 때가 많다.
내가 브런치에 첫 글을 남긴 건 꽤 오래전이다.
몇 개 끄적이다가 결국 발행 버튼을 누르지 못하고
쉬고 있었는데,
'저길로 가라, 총알처럼' 꼭지를 읽은 뒤
바로 발행 버튼을 누르게 되었다.
서랍에 넣어두고 나 혼자 고민하는 것보단
여러 사람이 읽어주는 게 더 좋은 글로 만들어 줄 거라는 생각에서.
우선 좋은 책들을 보며
독후감으로 작문 실력을 길러보려 한다.
이렇게 연습해놓으면 좋은 영감이 떠올랐을 때,
그게 프로그래밍 업무에 관한 영감이건
아님 소설 쪽 영감이건,
좀 더 수월하게 써내려 갈 수 있겠지.
그리고 이젠 발행 버튼을 누르는 게
예전처럼 두렵진 않겠지.
다음 독후감은 최근에 관심이 생긴 프로그래밍 언어,
파이썬에 관한 기술서적으로 하려고 한다.
최근에 여기저기서 파이썬에 대해 듣게 되면서
조금씩 관심이 생기고 있었는데,
지난 7월 6일 참석했던 구글 콘퍼런스에서
머신러닝에 대해 큰 관심이 생기면서
파이썬을 배우고자 하는 마음이 확 커졌다.
현재 조대협 님이 추천해 준 홍콩 과기대 김성훈 교수님의 온라인 강의를 듣고 있는데,
강의 목차를 보니 후반부에 파이썬으로 텐서 플로우를 활용해 머신러닝을 직접 해보는 꼭지가 있다.
강의를 듣다가 파이썬을 사용하게 될 때쯤, 적당한 책을 하나 골라 파이썬을 익히려고 한다.
잘할 수 있겠지.
