비전공자가 개발 책 끝까지 읽는 법
비전공자를 위한 개발 책은 없다.
실은 5월 초순부터 본격적으로 개발 공부를 제대로 하고 있다. 운이 좋다면 커리어를 체인지 할 수 도 있겠지만.. 지금은 그냥 내가 좋아서, 궁금해서 공부하고 있다. 처음에는 그냥 말로만 때우는 사람이 아닌 진짜 증명할 수 있는 사람이 되고자 하는 오기로 시작했다가 책을 많이 사고.. 그 책들을 하나씩 읽을 시간이 생겨서 읽다 보니 그렇다면 이건 과연 어떤 것인가?라는 의문이 들기 시작했다. 당분간 이러한 자신의 근본적인 문제를 해결하기 위해 모아둔 돈으로 벌은 이 시간을 책을 보고 실제로 작성해보면서 보낼 것 같다. 이렇게 될 것이라는 것을 몇 년 전부터 예상하였지만.. 생각보다 빠르게 이런 시간이 올 줄은 몰랐다. 각설하고, 어제부터 발견한 책을 읽는 방법에 대해 작성하고자 한다. 이 글을 읽는 개발자들이 보기에는 무식한 방법일 수도, 또는 어리석은 방법 일 수 도 있지만.. 낮은 시선에서 이해한 결과라고 생각해 줬으면 한다.
1. 여러분이 생각하는 개발 책은 친절하지 않다.
비전공자들이 개발 책으로 독학하기 어려운 이유 중에 하나는 "시중에는 비전공자를 위한 책이 많지 않다"에서 출발한다. 주변의 개발자들에 대해 냉정하게 바라볼 필요가 있다. 과연 그들이 비전공자에서 출발하여 유능한 개발자로 발전한 과정 중 한 군데도 개발과 밀접한 관련이 없었는가.. 에서 유능한 비전공자 출신 개발자 중 YES라고 대답하는 사람은 그다지 많지 않을 것 같다. 혹자는 이것을 재능이라고 이야기하는데 실은 재능이 아니라 먼저 경험한 부분이라고 생각된다. (그래서 개발을 공부하는 비전공자들에게 좌절하지 말라고 이야기해주고 싶다.) 단기간에 비전공자 출신은 그들을 따라잡을 수 없다. 가장 큰 이유는 일생에서 돌이켜 볼 때 학창 시절이 순수하게 책과 문제를 손에 쥘 수 있었던 시기였었고, 경제활동을 하면서 배운다고 가정하면 이것이 쉽지 않은 일이기 때문에 길고 멀리 봐야 할 것이다. 본론으로 돌아가서 당장 손에 쥐고 있는 개발 책의 저자를 확인해 보라... 그들 중 비전공자 출신의 비율은 얼마나 있는가? 가장 큰 문제는 이 부분에서 시작한다. 여러분이 가지고 있는 개발 서적 중 비전공자가 저자일 확률은 그다지 높지 않을 것이다.
2. 일부 책은 개발자 또는 전공자일 것으로 간주하고 작성한다.
내가 개발 도서들을 읽으면서 가장 힘들었던 부분 중 하나가 개발 책의 표현 방법이다. 물론 영어 그대로 외워야 한다는 사람도 있다. 사실 그렇게 자연스럽게 받아 들일 수 있다면 이 글을 작성할 필요도 없을 것이다. 일부 책들의 표현법은 개발언어 + 조사 형식으로 되어 있다. 기초적인 예를 들면 "프로퍼티/메서드라는 관점에서 객체를 봤을 때 겍체란 고기능의 용기라고 할 수 있다. " 여기서 프로퍼티/메서드/객체라는 책에서 엄청나게 많이 볼 수 있게 될 것이다. 이런 단순한 문장을 해석하는데도 시간이 오래 걸릴 수 있다. 그러나 대부분의 책에서는 이런 단어들의 뜻을 알기 쉽게 모아서 정리해주지 않는다. 대부분 그냥 알고 있다고 가정하고 넘어간다.
3. 일부 개발 책의 경우 앞에서 이야기한 후 자세한 설명을 뒤에서 한다.
가장 짜증 나는 유형이다. 친절한 책은 뒤에 설명이 있다고 표기하지만, 아예 안내가 없는 책들도 있다. 내가 이것을 이해하고 일단 모르는 것을 넘어가는 방법을 익힌 것이 2014년 12월이다. 그동안 내가 구매했던 개발 책들은 거의 초반만 읽었다고 보면 된다. 이 방법을 깨달았을 때 정말 약이 오른다는 표현을 쓰기 딱 좋은 환경이었다. 거의 3-6 챕터 부분에서 이 부분이 나타나는데, 어제 책을 다 읽었을 때.. 아아아.. 이놈들(?) 뒤에 설명해놨겠거니.. 생각하고 넘어가서 읽어본 뒤 다시 앞으로 돌아간다. 이것은 저자가 다분히 개발에 대해 안다는 가정하에 작성하는 책이라는 것을 보여주는 것이라고 할 수 있다.
4. 그렇다면 어떻게 해야 끝까지 읽을 수 있을까.
첫 번째로 단어장을 만드는 방법을 권하고 싶다. 책을 읽으면서 사람들이 우스개 소리로 외계어라고 하는데 책의 문체가 어색하기 그지없기 때문인 게 첫 번째 문제라고 생각한다. 나의 경우 단어 + 조사 + 단어 구조에서 단어가 많이 헷갈리기 때문에 이해가 떨어지는 원인이 첫 번째였다. 휴대폰으로 단어장을 만들어 옆에 써놓으면 책을 읽으면서 참고할 수 있어 단어의 뜻을 자연스럽게 외우기 전까지 참고하며 읽을 수 있다. 이 부분에 대해서 부끄러워하지 않았으면 좋겠다. 구글링을 하던 무엇을 하던 상관없이 혼자서 책을 읽는 시간에는 누구도 스스로를 방해할 수 없다는 것을 믿었으면 좋겠다.
5. 코드도 말로 표현하자.
예제들을 그냥 지나치는 경우가 많은데... 실제 그렇게 하면 많은 부분을 놓치게 되는 것 같다. 일부 책들 중에는 코드 위에 주석으로 해당 코드가 어떻게 동작하고 왜 그렇게 되어 있는지 텍스트로 잘 설명되어 있는 책들이 있다. 문제는 그런 책이 일부라는 것이다. 잘 작성한 그 일부의 책을 발견하여 그것을 자주 읽어 본 후 다른 책도 그렇게 하는 방법을 사용하는 것이 좋은 결과를 얻어낼 수 있다는 것을 깨달았다. 예를 들면 주석에 1-페이지 로드 시 이벤트 헨들러 작성 2-리스트를 위한 배열 준비 3-순서대로 태그 취득 4-속성을 결과에 대입 5-배열을 연결해 표시 이렇게 표현하고 다음으로는 코드 자체를 예를 들면 변수 XX는 문서에 있는 엘리먼트 네임을 참조하는데.. 이렇게 말을 해보는 방법을 사용해 보았다. 처음에는 정말 시간이 오래 걸린다. (나도 지금 이렇게 오래 시간을 들이는 방법을 사용하고 있고 실제로 많이 애먹고 있다. )
6. 시간이 오래 걸림을 인정하자.
사실 비전공자인 우리는 전공자보다 공부에 기울인 시간이 많지 않다. 그들과 조금이나마 비슷한 결과를 얻어 보려고 노력한다면, 적어도 그들과 비슷한 정도는 미치지 못해도 더 많은 시간과 노력, 또는 돈이 드는 것임을 인정해야 할 것 같다. 그리고 조급해하지 말아야 괴로운 부분을 넘길 수 있을 것 같다. 공부를 하면서 정말 실행이 안 되는 것도 많고, 이해가 안 되는 것들도 많다. 그리고 직접 해보면서 책들에 있는 내용을 다 이해한다 하더라도 실제 개발에서는 책 내용 이외에 다양한 부분을 알게 되어야 개발 공부하는 목적을 채울 수 있을 것 같다. 내가 평소에 주변인들에게 주장하는 우리의 가장 큰 잘못 중 하나가 가성비 이론인데 가격 대비 성능이라는 것은 전자기기나 가구에서나 찾아보는 것이다. 실제 사람의 능력은 가격 대비 성능으로 측정 불가하며 스스로 재미있을 것 같다고 느껴지는 것을 하는 게 자신에게 좋을 것 같다. 비록 그것이 시작은 불순하였어도 다른 사람들보다 배우는 속도가 느리더라도 그냥 다음에 어떻게 될지 궁금해서 하는 공부가 좋아서 이 과정이 길고 좋지 않은 결과를 얻더라도 후회하지 않을 것 같다. 좋지 않더라도 재미있었기 때문에 계속 도전할 것 같으며 시간이 오래 걸리더라도 나보다 빠르게 습득하고 잘하는 사람이 나타나도 별로 기분 나빠하지 않을 것 같다.
