인문학도 개발자되다

[회색인간을 꿈꾸는 문돌이의 한걸음]
마르코님의 이 책은 우선 저자도 비전공 나도 비전공, 그리고 똑같이 국비교육을 받은 이력을 가지고 있다보니(정확히는 나는 현재 교육을 받고 있는)  깊이 공감되는 책이었다. 다 읽고 난 뒤에 우리 반의 다른 분께 빌려주며 같이 읽자고 제안했다.

언제나 새로운 영역에 들어간다는 게 어렵고 힘든 과정이긴 하지만, 특히나 문돌이가 공돌이의 영역으로 들어간다는 건 공돌이가 문돌이의 영역으로 들어가는 노력과 고통의 100배쯤은 힘들다고 생각한다. 그럼에도 불구하고 그런 노력과 고통을 감내해야 할 상황이라면 먼저 그 길을 걸어간 선배의 자취를 보는것만으로도 조금 더 마음이 놓이고, 동질감을 느끼기 마련이다.

이 책은 그런 점에서 정말 선배에게 술 한 잔 사달라고 했을 때 들을 수 있는 얘기를 저렴한 가격에 들을 수 있는 책이었다.

다만 마르코님은 아쉽게도 국비교육 초반에 이상한 선생님과 40명의 대규모 학생이 함께한 가운데 수업을 들었지만, 나는 계속해서 메모리구조와 API문서를 강조하시는 학생들을 쥐었다 폈다 밀당(?!)의 고수 선생님과 21명의 학생들로 구성된 반에서 수업을 받고 있다. 그 점에서는 조금 더 나은 상황인 듯 했다. 지금도 어디에선가는 마르코님의 국비교육 초반에 이상한 강사들이 대충 코드 치고 말겠지만, 어디에선가는 정말 열심히 연구하고 강의하시는 선생님들이 계신거 같다. 이 점에서는 평가체계가 더 개선되어야 할거 같다. 그래야 좋은 선생님들이 더 열심히 하시고 대충 하시는 분들이 도태될거라 생각한다.

이 책을 보며 내가 교육을 받는 동안 생각해야 할 목표는 
1. 내가 개발하고 싶은 서비스와 플랫폼
2. 영어 동영상 강의 수강 능력 + 영어 독해 능력
3. 애자일 + 스프린트 + 뽀모도로 로 대표되는 생산성 향상기법 내재화
4. 해커랭크, 코딜리티, 리트코드 학습을 통한 알고리즘 학습
5. SI업체를 제외한 기업 채용 분석이다.

하나하나 다 어려운 목표이지만, 책에서 배운대로 조금 더 세분화시켜서 이뤄나가야 하는 목표다. 어차피 이런 목표를 이룰 수 없다면 어떤 프로젝트도 진행시키지 못하고, 자기 자신을 향상시킬 수 없다고 생각이 들었다. 넘어야 할 목표라면 고통스럽더라도 이뤄내고 싶다.

11일만에 자바 다형성까지 학습하는 정신없는 일정속에서 이 책은 지금의 이 고통이 그리 나쁘지 않고 조금 해볼만한 거라고 속삭여주었다. 만약 나같이 방황하고 있는 인간이 있다면 술 사주는 대신에 이 책을 한 권 쥐어주는 것도 죽비를 내리칠 수 있는 좋은 방법일듯 하다.

p.31

나는 항상 남들이 하지 않더라도, 내가 관심 있는 것을 조금 더 하려고 노력했다. 학원에서는 다들 웹 개발만 할 때 안드로이드를 기웃거렸고, 그 결과 안드로이드 개발 기회가 있는 회사에 입사할 수 있었다. 그리고 첫 회사에 다니면서 친구에게 선물 받은 맥북으로 iOS 개발을 영문 인터넷 강의로 혼자서 공부했고, 그 덕분에 다음 회사에 좋은 조건으로 이직할 수 있었다. 남들보다 조금 더 준비했고, 덕분에 기회가 왔을 때 잡을 수 있었다. 무엇보다 당시에는 새로운 것을 배우는 것이 너무 즐거웠다. 누가 시키지 않아도 출퇴근 시간에 공부했고, 집에 와서는 늦은 시간까지 공부한 내용을 직접 서비스로 만들었다.

p.46~47

정말 좋은 스타트업은 내가 하고 싶은 일을 할 수 있게 해주는 곳이다. 아무리 달콤한 약속을 하더라도 스타트업은 도박에 가깝기 때문에, 실제로 약속된 것들이 내 손에 들어오기까지는 많은 시간과 운이 필요하다. 그렇기 때문에 스타트업에 다니면서는 내가 이 기업을 키워서 제대로 된 보상을 가져가겠다는 욕심을 가지고, 내가 그 조직에 기여하고 싶은 부분이 분명히 있어야 한다.

"나는 이 회사에서 애플리케이션의 에러를 모조리 잡아내겠어."
"나는 앞으로 동영상이 비전이 있는 것 같으니, 그쪽 기술을 갈고 닦겠어."
"나는 데이터를 통해서 사용자를 이해하는 과정이 좋으니, 그로쓰 해킹(Growth hacking)을 해보겠어."

위와 같이 회사에서 일하는 분명한 목표와 전문성이 당신을 돋보이게 만든다. 스타트업은 작은 조직이다. 그 누구도 당신에게 학교처럼 친절하게 알려주지 않는다. 당신은 회사에 들어가서 '내가 무엇을 해야 하지'라고 고민하는 것이 아니라, 이미 내가 할 수 있는 것을 알고 있어야 한다.

만약 신입 개발자라면? 최소한 내가 개발하고 싶은 서비스와 플랫폼에 대해 생각해 두었어야 한다.

"전자상거래 서비스에서 안드로이드 애플리케이션을 만들고 싶다."
"O2O 서비스에서 서버 개발을 하고 싶다."

이런 목표는 내가 그 분야의 회사에 들어갔을 때, 더 신나게 일을 할 수 있는 동기를 제공해준다. 내가 관심없는 분야의 제품을 만드는 건 회사 입장에서나 개발자 입장에서 모두 손해이다.

p.81

이런 식으로 연습해 보자. 항상 업무를 시작하기 전에 해당 업무를 앞에서 언급한 것처럼 최대한 세부적으로 나눈다. 그리고 업무마다 소요될 예상 시간을 적는다. 그리고 각각의 업무 시간을 측정하면서 진행해보고, 예상 시간과 얼마나 달랐는지 기록하고, 하루 업무를 마감하면서 어떤 부분에서 차이가 발생했는지 그 원인을 써본다. 그러면 점점 예상 시간과 실제 업무 시간이 비슷해지는 경험을 할 수 있다.

p.81~82

업무를 잘게 나눴다면 이제는 이 일을 실제로 할 수 있는 시간을 확보하고 일이 언제 끝날지를 계획할 시간이다. 시간관리에서 많은 사람들이 간과하는 부분은 바로 실제로 업무 할 시간을 확보하는 일이다. 하루 종일 업무할 때 이틀 정도 걸리는 일이 있다고 할 경우, 내가 이틀 동안 이 업무에만 집중할 수 있는 시간이 있는지, 해당 업무 외의 미팅 등 다른 일을 처리해야 하는 건 아닌지 미리 생각할 필요가 있다. 그리고 당연히 해당 작업을 수행 중에 먼저 처리해야 하는 다른 업무가 생긴다면 전체 일정을 늘려서 잡는 것이 맞다. 이걸 제대로 하지 못한다면 기본적으로는 프로젝트를 관리하는 매니저의 역량 부족이겠지만, 이차적으로는 일정이 조절되어야 하는 것을 제대로 설명하지 못한 개발자의 책임도 분명히 존재한다. 왜냐면 내 업무에 소요되는 시간은 본인이 가장 잘 알기 때문이다.

그리고 혹시 특정 업무가 에러 등으로 지연된다면 그 사실을 빠르게 알리는 것이 좋다. 일을 하다보면 예상치 못한 일이 생기기 마련인데, 사람들은 그걸 공유하기 어려워하고 혼자서 끙끙대는 경우가 많다. 그런데 이걸 제때 밝히지 않고 계속해서 프로젝트 진행이 늦춰진다면 결국 같이 일하는 사람들의 신뢰를 잃게 될 가능성이 크다. 따라서 특정한 업무가 지연되거나 혹은 빠르게 마무리되었다면, 꾸준히 변경 사항을 업데이트하고 신뢰를 쌓는 것이 정말 중요하다.

이렇게 일정 변경에 대해 꾸준히 소통했을 때 좋은 점은 '업무가 늘어나면 일정도 늘어난다'는 아주 기본적인 사실을 팀원들 전체와 공유할 수 있다는 것이다. 특히 한국에서는 업무는 더 하길 원하면서 일정은 그대로 지켜지길 원하는 문화가 있는데, 이런 것을 초기에 제대로 말하지 못하고 야근이나 주말 출근으로 해결하려 든다면 결국 개발자의 번아웃으로 이어진다. 결국 조직에도, 개발자 본인에게도 좋지 않은 상황으로 이어지는 것이다.

p.82~83

뽀모도로(Pomodoro)라는 시간 관리 방법론을 만나 보자. 뽀모도로는 이탈리아어로 토마토라는 의미인데, 이탈리아에서 토마토 모양의 알람 시계로 처음 시작해서 이런 이름을 붙였다고 한다. 방법은 간단하다. 25분 알람을 맞춰 놓고, 그동안은 다른 일을 아무것도 하지 않고 업무를 마친다. 그리고 5분 쉬고, 다시 25분간 일을 한다. 이렇게 4번 일을 하고 나면(약 2시간 가량), 20분 정도 휴식 시간을 준다. 각자 하루 목표에 따라서 적게는 6 뽀모도로, 많게는 10 뽀모도로를 하면 좋다. 가장 많이 일해도 10 뽀모도로라면 휴식시간을 포함해서 5시간이 조금 넘는다. 여기서 포인트는 25분간 다른 걸 아무것도 하지 않고 업무에 집중하는 것이다.

그런데 직접 해보면 느끼겠지만, 하루에 10 뽀모도로, 즉 5시간을 온전히 일에만 집중하는 것이 결코 쉬운 일이 아니다. 이 시간에는 웹 서핑도, 문자 보내기도 금지한다. 쉬는 시간 5분에 화장실도 다녀오고 문자도 보낸다. 이렇게 중간에 쉬는 시간을 통해서 재충전하고, 약 10 뽀모도로를 한 날의 업무 성과를 되돌아보면 스스로도 놀라울 정도다. 아무런 계획 않고 하루에 10시간 앉아 있는 것보다, 뽀모도로를 통해서 5시간을 관리하는 것이 훨씬 효과적이다.

그리고 나와 약속한 뽀모도를 충실히 이행한 경우 나에게 선물을 주자. 프리랜서라면 컴퓨터 앞을 떠나 읽고 싶었떤 책을 읽거나, 회사에 다니는 직장인이라면 혼자서 잠깐의 커피 한 잔의 여유를 갖는 등 스스로를 충분히 보상해 주면 효과가 더욱 좋다.

p.113~114

비전공자로서 개발을 배우는 사람이라면 최대 6개월 안에 개발자로 취업하라고 조언한다. 특히 비전공자에게는 완전히 다른 분야에 도전해서 개발자로 일한다는 것이 굉장히 무섭게 다가오는 것이 사실이다. 하지만 앞서 개인 프로젝트를 하면서 배우라는 것과 같은 맥락에서, 내가 혼자서 공부하는 것과 실무에서 개발을 배우는 것은 질적으로 너무나도 다르다. 아무리 독학으로 다양한 내용을 배운다고 하더라도, 실제 회사에서 사용하는 기술이 회사마다 너무 다양하기 때문에 어차피 새롭게 많은 내용을 배워야 할 가능성이 크다. 회사에서 일을 하다 보면 회사에서 사용하고 있는 기술이 더 입체적으로 눈에 들어오기 때문에, 내가 무엇을 알고 있는지 그리고 내가 앞으로 무엇을 공부해야 하는지 파악하기도 쉽다. 그뿐만 아니라, 직접 사용자를 만나는 코드를 짜야 하기 때문에 혼자서 개발할 때 대충대충 넘길 수 있는 부분도 회사에 다니면 좀 더 완성도 있게 코드를 짜게 되기 마련이다. 즉, 더 수준 높은 코드를 개발할 수 있게 된다.

끝으로 개발자로 취업하고 일하는 과정에서 혼자서도 공부할 수 있는 능력을 키워야 한다. 우선 영어 문서를 읽을 수 있는 정도의 영어 독해 능력을 갖추는 것이 좋다. 왜냐면 대부분의 개발 문서는 영문으로 되어 있기 떄문이다. 어느 정도 기본적인 개발 능력을 갖추게 되었다면 각 기술을 개발하는 팀에서 제공하는 개발 문서를 직접 읽는 것이 좋다. 개발자의 세상에서는 더 많은 개발자가 사용하는 기술이 곧 힘이기 때문에 더 많은 기술을 무료로 제공하고, 더 좋은 문서를 작성하기 위해서 노력한다. 사실 발행되는 개발 책들은 이런 기술 문서를 바탕으로 하는 경우가 대부분이다. 이런 기술 문서를 읽기 시작하면 가장 정확한 최신 정보를 얻게 되는 것이다. 마지막으로 코드를 직접 보고 이해하기 위해서 노력하는 것이 좋다. 최근 사용되는 거의 모든 기술은 오픈소스로 공개되어 있다. 마음만 먹으면 언제든지 그 코드에 직접 접근할 수 있다. 실제로 코드를 보고 그 기술 자체를 이해하게 된다면 어떤 기술이든 스스로 이해할 수 있는 능력을 갖췄다고 말할 수 있다.

p.152

만약 3개월 안에 구직을 할 계획이라면 해커랭크와 코딜리티를, 6개월에서 1년 이상 기간을 갖고 면접을 준비할 예정이라면 리트코드를 통해 알고리즘을 공부하는 것을 추천한다. 단, 해커랭크와 코딜리티는 정말 많은 회사에서 사용하고 있기 때문에 면접 전에는 충분히 연습을 하는 것이 좋다.

p.218

만약 해외에서 취업하기 위해서 개발을 공부하고자 하는 사람이 있다면, 권하고 싶은 방법이 하나 있다. 보통 해외에서 취업하고 싶다고 말하는 개발자들이 계속해서 도전을 미루는 이유는 먼저 영어를 공부하기 위한 경우가 많다. 그런데 영어 공부라는 게 하려고 마음을 먹으면 끝도 없다. 뭐든 그렇지만 하다 보면 점점 더 높은 수준이 눈에 들어오고 쉽게 도전하기가 힘들다. 내가 권하는 방식은 당장 이력서부터 쓰고 회사에 지원해보라는 것이다. 단, 내가 붙어도 가고 싶지 않은 회사부터 지원하는 것이 포인트다. 결국 면접용 개발 영어는 거기서 거기다. 내가 지금까지 어떤 프로젝트를 해왔는지, 그리고 코딩 테스트라면 내가 왜 이런 코드를 짰는지 설명하면 된다. 면접이라는 시간은 1시간에서 2시간 남짓 아주 짧은 시간이지만, 한편으로 매우 강렬한 경험이기 때문에 영어 실력을 단기간에 끌어올리는 데 큰 도움이 된다.

p.230

개발을 처음 공부할 때 사람들이 오해하는 것 중 하나는 내가 대충 질문을 해도 사람들이 내 문제 상황을 이해해 줄 거라고 생각한다는 점이다. 예를 들어, 웹 사이트를 개발할 때 "지금 웹 개발 공부를 하고 있는데 CSS 적용이 안 돼요." 라고 질문을 올린다. 정말 미안하지만 이렇게 질문을 하면 이게 왜 안 되는지 답변해 줄 수 있는 사람은 아무도 없다. 사람마다 개발하는 환경이 모두 다르고, 개발 환경마다 다른 에러가 발생할 수 있기 때문이다. 따라서 질문을 할 때는 현재 사용하고 있는 운영체제와 운영체제의 버전, 그리고 개발 중인 프로그래밍 언어와 버전, 그리고 모바일 앱이라면 앱의 버전과 웹서비스라면 사용하는 그 브라우저의 버전까지 공유를 해주어야 한다. 또한, 어떤 행동을 할 때 에러가 발생하는지 구체적으로 설명해야 왜 그 문제가 발생하는지 추측할 수 있다. 해당 코드와 에러 로그를 함께 공유해야 하는 것은 물론이다. 예를 들면 아래와 같이 질문하는 것이 좋다.

"현재 윈도우 10을 파이썬(3.6.5 버전), 장고 (2.1 버전)로 웹 개발을 하고 있는데, 크롬 브라우저상에서 CSS 수정이 반영되지 않습니다. HTML 파일은 반영이 되는데, CSS파일은 반영이 되지 않네요. 파일 이름도 바꿔 봤는데 잘 적용이 안 되는데, 오늘 새로 켰더니 수정한 부분이 반여오디어 있었습니다. 그런데 또 새로 변경한 건 적용되지 않네요."

p.