코딩 독학 하는 좋은 방법

Coding?

 코딩을 배워볼까? 하고 관심있어서 인터넷을 서칭하는 경우가 많을텐데요. 저도 코딩을 독학으로시작했고 이후에도 독학이 95% 비중을 차지합니다. 문돌이 27년에 코딩을 공부한다는 것은 저한테는 큰 도전이었고 염려와 걱정이 많았습니다. 지금은 그런 걱정은 없는데, 돌아보면 여러가지 생각이 드는 부분입니다.

 

지금은 코딩을 독학하기 좋은 환경

 제가 코딩을 공부할 때는 거의 대부분 인식이 학원에서 공부해야 한다는 것이 많았습니다. 주변에 코딩한다는 사람도 없고 인터넷에서는 국비 지원 학원 강의라도 들어라는 얘기가 많았지요. 그러나 지금은 학원을 가지 않아도 인터넷에서 편하게 강의를 들을 수 있는 환경입니다. 유튜브나 유/무료 인터넷 강의도 많이 올라와 있습니다. 지금은 골라들을 수 있죠. 다만 유일한 단점은 선택지가 많아지다 보니 좋은 강의를 구분하는 것이 쉽지 않은 상황입니다. 그만큼 좋은 강의를 찾는 시간이 걸리게 되지요. 이전에는 제공된 것만으로도 감사하며 들었었습니다. 

 

나의 독학 스타일

 저는 강의 듣는 걸 좋아하지 않는 스타일입니다. 일단 지루해하구요. 그래서 책을 사서 공부하는 것이 저의 공부방식이었죠. 책으로 공부하는 것도 좋긴한데 책의 특성상 많은 내용을 담고 있는데다가 설명하다보니 책을 읽다보면 지루해진다는 점이 있었고 무엇이 중요하고 무엇이 덜 중요한지 구분하기가 쉽지 않았습니다. 더군다나 코딩을 처음 접하면 무엇이 중요하고 무엇이 덜 중요한지 구분하는 것은 더 어렵습니다. 저는 무식하게 처음부터 끝까지 보는 스타일이다보니 그 만큼 고생은 더 많았고 시간도 오래걸렸습니다. 다행히 지루함을 이겨내어 그나마 끝까지 볼 수 있었죠. 돌아보면 그렇게 좋은 방식은 아닌것 같습니다. 코딩이나 개발은 공부해야 할 양도 많고 방대하기 때문에 이것 저것 공부하다 보면 세월아 네월아 하게 됩니다. 뭐..지금은 필요한 부분만 레퍼런싱합니다.

 

공부하면 공부할 수록 부족함을 느낀다

내 뇌피셜에 의한 성장 곡선

 

'모르는게 약'이라는 속담이 있죠. 코딩이라는 것을 간단하게 생각하고 쉽게 접했었는데요. '어? 해볼만한 하겠는데?'하고 시작하게 되고 'Hello World'를 찍어봤습니다. 그리고 언어의 문법을 하나씩 익히며 호기심이 많아지고 재미있는 시기가 오더라구요. 그러나 무엇을 만들려고 하다보면 어디서 부터 어떻게 해야 할지 막막해졌습니다. 그러나 인터넷이라는 것이 있죠. 서칭을 하면서 하나씩 찾아나가며 공부하게 되는데, '왠 걸?' 알면 알수록 모르는 것은 더 많아지고 공부 해야할 것은 산더미처럼 쌓였습니다. 자료구조, 네트워크, 운영체제, 알고리즘, 소프트웨어 공학, 데이터베이스, 디자인 패턴, 아키텍처 등 배워야 할 것이 엄청 많다는 것을 알게 되었었습니다. '이거 모두 알아야해?' 하고 생각했었지요. 공부하고 공부하다보니 이런것도 저런것도 알아야겠고 모르면 안될 것 같은 느낌을 받았었습니다. 그때 순간 숨이 턱 막히더군요. '알면 알수록 장난이 아니었구나, 너무 쉽게 생각했다'하구요. 코딩을 배운 원래 목적이 사업을 위해서 였는데 주객전도 되는 느낌도 되었습니다.

 

그런데 피해갈 수는 없어

그렇다고 코딩을 취미로 할 생각은 없었습니다. 일단 한 번하기로 마음 먹었으면 제대로 하는게 낫다고 생각했습니다. 그러다보니 결국 공학적인 부분을 피할 수 없었습니다. 그래서 기본 과목들을 정면으로 마주하고 공부했습니다. 그리고 학교에서 1년동안은 전공 과목들로 도배하여 수업을 들었습니다. 사실 학교에서 들었던 과목들은 크게 저한테 도움이 되지 않았습니다. 오히려 도움이 많이 되는 것은 공학과 관련된 책을 보고 혼자서 깊게 생각하는 것이었습니다. '왜지? 왜그래야하지?, 또 다른 방법은 없나?' 하고 생각하는 것이 가장 큰 도움이 되었습니다. 이 부분의 장점은 주입식으로 이론을 머리속에 넣는 것이 아닌 마인드 맵 처럼 머리속에 그물을 펼쳐놓고 계속해서 생각하며 뻗어나가며 생각의 힘을 기르는 점입니다. 다만 단점은 시간이 굉장히 오래걸린다는 점입니다. 더군다나 나이가 많거나 시간이 없다면 권장드리지 않습니다. 저는 나이가 있는데도 무식하게 했었습니다. 지금와서 권장드리는 것은 시간을 최대한 압축할 수 있고 생각을 하도록 하는 좋은 강의를 찾아서 듣는 것이 낫습니다.

 

개인의 성장 잠재성은 기초에서 갈린다

 지금도 생각하지만 공학적인 부분을 등한시하지 않은 것이 정말 잘했다고 생각합니다. 이게 현업에서 인하우스 방식으로 최소 2년 이상 달리신 분들은 아시는 부분인데 이게 어느 정도 단계에 오르면 성장이 더딥니다. 이때가 개발할 때 웬만하면 머릿속에 견적이 나오는 시기입니다. (제대로 달렸다면) 거의 대부분이 경험했던 것들을 머릿속에 꺼내서 코딩하는 그런 경우가 대부분입니다. 그렇다고 새로운 도메인을 접한다고 하더라도 막 그렇게 실력이 느는 느낌은 아닙니다. 여기서 이제 비슷한 경험치만 쌓아 나가느냐 새롭게 커리어를 전환하느냐 또는 더 깊숙이 파고드느냐 하로 방향이 갈리게 됩니다. 저는 깊숙이 파고드는 방향으로 선택했으며 그때 공학적인 기초가 많이 관여되고 성장하는 데 도움이 많이 되었습니다. 어떻게 관여되었는가를 얘기하려면 내용이 엄청 길어지기 때문에 넘어가겠습니다. 별개로 10~20년 더하여 40년까지 엔지니어로 일하신 분들은 정말 대단하신 것 같습니다.

 

코딩 독학 하는 좋은 방법

이제 본격적으로 코딩 독학 하는 좋은 방법을 정리해보겠습니다.

 

1. 좋은 멘토를 만난다.

 솔직히 말해서 좋은 멘토를 만나는 것은 하늘에 별 따기 입니다. 만나셨다면 감사해 하시길 바랍니다. '좋은 멘토'의 기준은 사람마다 주관적으로 생각하기 때문에 정답은 없으나 개인적인 의견으로는, '멘티에게 왜? 라는 질문을 던지거나 또는 왜? 라는 질문에 대답할 수 있는 분'을 좋은 멘토라고 생각합니다. 일을 하다보면 대부분 사수가 있는 경우가 많은데요. 좋은 사수는 '왜? 라는 질문을 받았을 때 귀찮긴 하지만 그래도 대답을 해주시는 분'입니다. 그러나 좋은 멘토를 바라기 전에 좋은 멘티가 되는 법도 중요합니다. 개인적인 의견으로 좋은 멘티란 '고민을, 고민을, 고민을 많이하고 진짜 많이하고 나름의 생각과 답을 가지고 나서. 왜? 라는 질문을 할 수 있는 분'이라고 생각했습니다. 그냥 다짜고짜 '왜죠?' 라고 물으면 좋은 멘토라 하더라도 사람이기 때문에 귀찮아하고 '인터넷에서 찾아봐' 라고 말할 가능성이 높습니다. 어찌됬든 멘토와 멘티 관계는 사수와 부사수 이전에 사람과 사람간의 관계입니다. 그러니 현명하게 잘 관계를 쌓아나가는 것이 좋습니다. (물론 저는 멘토가 없었으며 지금도 멘토는 없고 멘티만 있습니다..)

 

2. 소프트웨어는 항상 사용하는 '사용자'가 존재함을 인지해야 한다.

 소프트웨어를 개발할 때 프론트든 백엔드이든 항상 머리속에 인지하고 있어야 하는 부분은 '사용자'입니다. 프론트 개발 같은 경우는 사용자와의 접점이 많기 때문에 '사용자' 관점에서 생각을 많이 할 수 있지만 백엔드는 '사용자'와의 접점이 적기 때문에 잊고 개발할 수 있습니다. 그러나 오히려 잘 생각해보면 백엔드의 퍼포먼스가 따라와줘야지 '사용자'에게 쾌적한 환경의 소프트웨어를 제공할 수 있습니다.

 

지금의 예시는 프론트나 백엔드 개발에서 '사용자' 관점에서 생각해야 하는지에 대한 이유를 작성했습니다. 프론트나 백이든 모두 연관이 있습니다.

 

1) MS Bing에 의하면 웹서비스가 1초 느려지면 매출이 3%하락

2) 페이지 로드 시간이 3초 이상 될 때, 40%의 이용자가 이탈

3) Amazon에 따르면 페이지 로딩시간이 100ms늘어나면 매출이 1%하락

4) Google의 페이지 로딩 시간이 0.5초 증가하여 매출과 트래픽이 20%하락

5) Shopzilla 사이트 속도 6초에서 1.2초로 개선후 매출 12%증가, 페이지뷰 25%증가

6) AOL 상위 10%사이트 속도에서 하위 10%사이트 속도때보다 50%나 더 많은 페이지뷰

7) Yahoo 사이트속도 0.4초 개선시 트래픽(방문자) 9%증가

8) Mozilla 사이트 속도 2.2초 개선시 년간 6천만건의 추가 Firefox 다운로드

 

해당 예시는 웹사이트 기준이지만, 앱 서비스도 이런 부분을 등한시 할 수는 없습니다.

 

 결론적으로 소프트웨어를 개발하는 이유는 '사용자'를 위해서 개발하기 때문에 '사용자'가 존재함을 항상 인지하고 있어야 합니다. 그리고 이런 생각은 여기까지 확장하게 됩니다.

 

포트폴리오를 만들 때도 '왜 이렇게 했는지'에 대한 스토리나 이유가 있어야 합니다. '누군가가 이렇게 하라고 해서요'라고 한다면 신입이실 경우 취업의 고배를 마실 수 있습니다. 그렇다면 포트폴리오를 어떻게 잘 만들 수 있을까로 다시 생각하게 됩니다. 다른 사람들도 눈으로 보이기에는 괜찮은 포트폴리오를 작성해서 취업시장에 진입합니다. 그렇다면 어떻게 자신만의 강점을 내세울 수 있을 것인지 생각해 봐야 합니다. 여러 사람의 포트폴리오가 유사하더라도 시니어들은 디테일한 부분을 체크할 수 있는 능력이 있기 때문에 자신의 포트폴리오를 양으로 승부하는 게 아니라 디테일한 부분을 다듬고 다듬고 또 다듬어서 보여줘야 합니다. 양은 중요하지 않습니다. 하나의 질 좋은 포트폴리오만 있으면 됩니다. '사용자' 관점에서 포트폴리오를 디테일하게 잡아보세요. 그러다 보면 자신이 무엇이 부족한지 알게 되며 스스로 찾아서 공부하게 됩니다.

 

'사용자 관점에서 생각하게 되면 자신이 무엇이 부족한지 알게 되며 그 부족한 부분을 찾아서 공부하게 된다.'

 

3. 좋은책, 좋은 강의를 찾는다.

 주변에 도움을 받을 사람이 없다면 최고의 멘토는 좋은 책, 좋은 강의 입니다. 개발을 어느정도 했다면 좋은책, 좋은강의가 무엇인지 알 수 있으나 입문 입장에서는 구분하기도 힘듭니다. 그래서 제가 입문 당시 했던 방법을 공유합니다. 

 

1) 책은 두꺼워야 한다. 200~300p짜리 책은 테크니컬한 부분을 다루는 입문서인 경우가 많습니다. 그정도의 정보는 인터넷에서도 찾을 수 있다고 생각했습니다. 그러나 700p 이상정도 되는 책은 세부적이나 깊은 부분을 다루고 설명하기 때문에 개인적으로는 좋은 책이라고 봤습니다. 그리고 목차도 슥 보고 어느정도로 디테일하게 들어가나를 보고 체크했습니다. 200~300p 책은 한 번 쓱 보고 이후에도 거의 볼 일이 없는 책이 대부분이나 레퍼런스급의 책(700p~)들은 이후에도 볼 수 있기 때문에 돈이 아깝지 않았습니다.(이건 개인적인 의견입니다..^^)

 

2) 좋은 강의는 '이유를 설명해주는 강의'이어야 한다. 사실 입문자분들은 이유까지 생각할겨를 없이 방법론에만 치중해서 공부하느라 급급합니다. 비전공자인 경우 전공자들 대비 부족한 부분이 있을 수 밖에 없고, 시간도 부족하고 나이도 어느정도 찼기 때문이죠. 저는 이해하고 공감합니다. 그래도 조급하면 안됩니다. 어떤 일이든 조급하면 큰 일을 할 수가 없습니다. 공부할 시간이 부족하면 잠을 자지않으면 됩니다. 비유적으로 든다면 대학에서 미적분을 공부하고 사용해야 하는 상황일 때, 중학교 수학, 고등학교 수학을 패스하고 공부하면 결국엔 한계를 느낍니다. 어차피 다시 중학교, 고등학교 수학 다시 공부하게 됩니다. 그렇게 헤매는 시간이 오히려 차분히 공부해서 쌓아 올리는 시간 보다 더 걸립니다. 진짜입니다. 믿어주세요. 또한 전문 엔지니어로 성장하기 위해서는 '이유'가 중요합니다. 그러므로 '이유를 설명해주는 강의'가 좋은 강의라고 생각합니다. 그러니 '이유'를 아는 시간도 공부시간에 포함해보세요. 

 

4. 라이브러리 사용하는 것도 좋지만 가급적 다 직접 만들어 보도록 노력한다.

 

 

React, RecyclerView, 실제론 엄청 빠름.

 

(해당 영상 설명: Android의 RecyclerView와 iOS의 UICollectionView의 아이디어를 차용, Circle Queue방식의 재사용뷰 방식. Delegate 패턴으로 코드가 작성되어 있으며, Vertical, Horizontal, Swipe, Paging 대응 가능한 라이브버리. 직접 구현) 

 

 개발을 공부하다 보면 라이브러리를 많이 사용하게 됩니다. 이것저것 다 끌어와서 사용합니다. 물론 현업에서 일할 때는 시간이 없으니 직접 만드는 것보단 라이브러리를 검증하고 사용하는 경우가 많지만, 공부할 때는 직접 만들어보도록 해야 합니다. 만드는 과정에서 만든 사람의 철학과 이유를 깨닫습니다. 그리고 만드는 과정에서 기초 공학 요소가 생각보다 많이 들어갑니다. 대부분 기초 공학 요소가 실제로 개발할 때 많이 사용하지 않고 안 들어간다고 착각할 수 있는데, 그건 감사하게 누군가가 도구들을 만들어서 그런 것이지, 도구가 없는 문제라면 직접 해결해야 합니다. 단순한 개발은 공학적 요소가 많이 안 들어갈 수 있지만 큰 프로그램을 만들다 보면 공학적 요소는 거의 필수적으로 생각해야 하고 실제로 들어갑니다. 그리고 기존에 없는 새로운 것을 만들 때 인사이트는 공학적 요소의 기반에서 많이 영감을 얻습니다. 그러므로 직접 라이브러리를 만들면서 공학적 요소들을 같이 생각하며 융합하는 연습하는 과정에 익숙해지다 보면 독학의 파워는 강해집니다.

 

 

마치며

코딩 독학을 잘하는 방법에 대해 원론적인 얘기만 한 것 같습니다. 사실 테크니컬 한 공부 방식은 인터넷에도 많이 올라와 있고 굳이 얘기를 꺼낼 필요가 없어서 꺼내지는 않았습니다. (예시로 클론 코딩이라던가, 프로젝트부터 만들어보라던 가.) 저는 좀 더 독학을 하면서 장기적으로 성장할 수 있는 부분에 포커스를 맞추고 작성해봤습니다. 사실 다 주관적인 이야기이고 경험이며 정답은 없습니다. 필요한 부분은 가져가고 필요 없는 부분은 버리시면 됩니다. 얻어 가실 수 있는 것이 있다면 더할 나위 없습니다.

 

 

 

독학으로 자바를 공부하신다면 해당 강의로 시작해보세요. 좋은 시작이 될 수 있어요. 회원가입하면 전 강의가 무료예요.

일단 코딩이 나랑 맞는지 확인해봐요.

 

https://www.codelatte.io/courses/java_programming_basic

자바로 배우는 프로그래밍 - 코드라떼