개발자가 공부로 살아남는 방법

개발자가 공부로 살아남는 방법


이번 포스팅에서는 개발자들에게 뗄레야 뗄 수 없는 키워드인 공부에 대해서 포스팅 해보려고 한다. 물론 다른 직종도 마찬가지겠지만 다른 업계보다 빠르게 변화하는 IT 업계의 특성 상 개발자는 시대의 흐름을 따라가기위해 은퇴 전까지 계속 해서 공부를 하는 수 밖에 없다.

개발자들은 아무래도 기술을 활용하는 최전선에 있는 사람들이기 때문에 이런 변화에 민감하다. 그 변화는 스쳐지나가는 한 때의 유행일수도 있고, 앞으로 20년을 버틸 수 있는 근본적인 지식일 수도 있다. 하지만 아무리 우리가 매일 공부를 한다고 해도 쏟아져 나오는 기술의 양이 워낙 많기 때문에 전부 공부한다는 것은 불가능하다. 그래서 우리는 이 기술이 단순한 유행인지, 오래 써먹을 수 있는 기술인지 혹은 지금 당장 나에게 필요한 기술인지 등을 파악하며 자신에게 맞는 기술을 습득해야한다.

그래서 이번 포스팅에서는 필자가 지금까지 4년 동안 거의 난장판이나 다름없던 웹 프론트엔드 생태계에서 어떤 기준을 가지고 공부할 것을 선택하고, 어떤 방법을 사용하여 공부를 해왔는지 한번 가볍게 적어보려고 한다. 물론 이 내용은 필자 개인의 주관적인 의견이므로 정답도 아닐 뿐더러 여러분과는 맞지않는 비효율적인 방법일 수도 있다. 그냥 이런 사람도 있구나 정도로 가볍게 읽어보고 참고하는 것을 추천한다.

우리가 공부를 게을리하면 안되는 이유

필자가 공부하는 방법을 설명하기에 앞서, 먼저 왜 개발자는 공부를 게을리 하면 안되는가?에 대해서 한번 이야기해보려고 한다. 사실 굳이 상세한 이유를 들지 않아도 빠르게 변화하는 업계에서 도태되지 않고 살아남으려면 공부를 해야한다는 간단명료한 대답이 있긴 하지만, 사실 이 대답은 제대로 된 대답은 아니다. 약간 결과론적인 대답이라는 느낌이 든다. 공부 안하면 도태당하니까 공부를 열심히 해야지 이런 느낌이랄까?

이런 대답은 질문자에게 제대로 된 동기 부여도 되지않을뿐더러 에 대한 궁금증을 해결해주기 힘든 대답이다. 그래서 필자는 저 조금 더 자세하게 이야기를 해보려고 한다.

기술이 발전하는 속도는 생각보다 빠르다

일 시작한지 4년밖에 안된 개발자인 필자조차 일을 하다보면 뭐가 이렇게 빨리 바뀌어?라고 생각한 적이 꽤 있었다. 그렇게 바뀐 것들은 오 좋은 게 새로 나왔네 정도인 가벼운 변화부터 응...? 도대체 이게 뭐지...?라고 생각할만한 급격한 변화까지 아주 다양했다.

꼴랑 4년 차인 필자가 이런 생각을 할 정도면 10년이 넘으신 시니어들은 아마 더할 것이라고 생각한다. 게다가 옛날에 비해서 기술이 발전하는 속도는 점점 빨리지고 있기 때문에 앞으로는 더 빠르게 바뀔 수도 있다고 생각한다.



인류의 기술 발전 속도는 점점 더 빨라지고 있다


위의 예시는 산업혁명이 언제 발생 했는지 나타낸 것인데, 1차 산업혁명이 발생한 1784년에서 시작해서 4차 산업혁명이 발생한 오늘날에 이르기까지 점점 더 간격이 줄어드는 것을 볼 수 있다. 이렇듯 인류의 기술 발전 속도는 선형이 아닌 지수형태로 증가하고 있다.

산업혁명을 예로 들면 너무 거시적이여서 와닿지 않을 수 있다. 하지만 기술자가 평소에 느끼는 기술의 변화 하나하나는 비록 자잘한 것들일 수 있어도 결국 산업 전반에 걸쳐 이런 것들이 쌓이고 쌓여서 서로 시너지 효과를 내며 임계점을 돌파하게 되는 것이기 때문에 기술자들이 기술의 변화를 느끼고 따라갈 수 있는 능력 또한 무시할 만한 것은 아니다.

즉, 사람들이 자주 이야기하는 도태된다라는 것은 이런 의미이다. 예를 들어 농사짓는 법을 마스터한 신라의 장인이 있다고 생각해보자. 그 사람은 1000년이 지난 후의 조선에서도 그 스킬을 가지고 충분히 먹고살 수 있다. 무려 1000년의 간극이 있는데도 말이다. 그에 비해 1970년대에 미국 국방성에서 계산 업무를 하던 인간 컴퓨터들은 2019년인 지금은 아예 사라진 직업이 되었다.

이 변화는 앞으로 점점 더 빨라질 것이며, 그렇기에 사람들이 도태되지 않으려면 공부해야해라는 소리를 하는 것이다. 물리 서버에서 클라우트 컴퓨팅으로 넘어가는 기술의 흐름은 아주 사소한 것처럼 보일 수 있지만, 그렇다고 그냥 가볍게 보고 넘겨버린다면 2년 정도만 지나도 그 이후에 나온 새로운 패러다임을 따라가기는 점점 더 어려워진다.

IT 업계의 변화는 파장이 크다

사실 당연히 IT를 제외한 다른 계열의 지식들도 세월이 지남에 따라 변화한다. 그러나 IT 업계가 변화한다는 것은 단순히 속도 면에서 빠르게 변한다는 것 외에도 기존의 패러다임이 뒤집어 질 정도로 큰 변화가 자주 일어난다는 것을 의미한다.

예를 들어 물리학 같은 경우, 기존의 이론이 잘못 되었음을 증명하고 새로운 이론을 제시하게되면 전 세계의 물리 교과서가 다시 쓰여질 정도로 그 파장은 어마무시하다. 그러나 그런 경우는 생각보다 자주 일어나는 일이 아니다. 대표적인 예로 아인슈타인이 제시한 시간은 관찰자의 상태에 따라 상대적으로 흐른다라고 제시한 상대성 이론이 있다. 지난 몇천년의 세월동안 늘 절대적인 흐름일 것이라고 생각했던 시간이라는 개념이 한순간에 뒤집힌 사례이다.

또한 법학의 경우, 법이 개정됨에 따라 새로운 법을 공부하고 새로 제정된 법과 비슷한 사례가 적용된 판례를 다시 찾아보는 경우가 있다. 이는 정부에서 크고 작은 법을 개정할 때마다 반복되기 때문에 빈도는 잦을 수 있지만 기존의 법이 가지고 있던 패러다임을 완전 뒤집어 놓지는 않는다. 그 정도로 파격적인 법안을 제정하기란 쉽지 않기 때문이다.

그러나 IT 업계에서 발생하는 변화는 속도 면으로도 빠르게 변화하면서도 기존의 패러다임을 뒤집는 경우가 종종 있다. 몇가지 예를 들어보면, jQuery에서 AngularJS로 넘어갔을 때, MVC 패턴에서 Flux 패턴으로 넘어갔을 때, Docker라는 가상 컨테이너가 처음 나왔을 때도, 서버리스 아키텍처라는 개념이 처음 나왔을 때도 그랬다. 아마 필자가 직접 겪지는 않았지만 클라우드 컴퓨팅 서비스를 제공하는 AWS가 처음 나왔을 때도 그랬을 것 같다.

이렇게 IT의 경우, 기존의 그것들을 구성하고 있는 패러다임을 완전히 버리고 온전히 새로운 것에 집중해야 이해할 수 있는 것들이 많았고, 그때마다 이 생태계는 많은 변화가 있었다. 그리고 그때마다 개발자 뿐만 아니라 개발자가 아닌 사람들의 생활에도 큰 영향을 끼쳤다.

사실 이런 이야기를 하면 이런 것들이 어떻게 사람들의 생활에 영향을 준다는 거지?라고 생각할 수 있는데, 대표적인 예를 몇개 들어보겠다.

이런 변화들 덕분에 지금은 많은 회사들이 실제 물리 서버를 구매한 후 IDC(Internet Data Center)에 입주해서 사용하지 않고 클라우드 컴퓨팅을 사용하여 서버를 운영하고 있다. 이는 서버를 직접 관리해야하는 리소스의 감소와 유연한 트래픽 대처로 이어졌고, 결과적으로 서버를 운영할 때 발생하는 부담을 상당 수 줄여주었다.

또한 요즘에는 JavaScript 하나만 할 줄 알아도 웹 클라이언트, 모바일 어플리케이션, 데스트톱 어플리케이션, 서버까지 전부 만들 수 있으며, 이는 개발자들이 용도에 맞는 어플리케이션을 개발하려고 할 때 여러 개의 언어를 공부하지 않아도 바로 원하는 서비스를 뚝딱 만들어낼 수 있다는 것을 의미한다.

또한 방금 설명한 클라우드 컴퓨팅 서비스를 제공하는 회사에 약간의 돈만 지불하면 백엔드 인프라도 클릭 몇번으로 간단하게 구성 및 관리할 수 있기 때문에 단 한명의 개발자가 거대한 시스템을 운영하는 것도 가능하다.

이런 변화들 덕분에 프로그래밍에 대한 장벽이 옛날에 비해 많이 내려간 상태이고 누구나 아이디어만 있다면 새로운 IT 사업에 도전할 수 있는 시대를 이끌어 냈으며, 그 결과 Google이나 Facebook 같은 IT 대기업들이 생겨나게 되어 우리에게도 직접적인 영향을 주고 있다.

내가 공부하는 방법

필자 또한 급격한 기술의 흐름 속에서 뒤쳐지지 않으려 발버둥 치고있는 개발자 중 한 사람이기 때문에, 당연히 평소에 공부를 하고 있다. 그러나 이 포스팅에서 필자는 공부를 해야한다라는 당연한 사실보다는 나는 이렇게 공부하고 있다에 대한 이야기를 하고 싶었다.

필자는 주변에 많은 개발자 분들이나 또는 개발을 공부하고 계신 분들, 혹은 어떤 분야에 있다가 다른 분야로 넘어가시는 분들이 공부에 대한 어려움을 표하는 것을 많이 들어본 적이 있다. 이들의 어려움은 공부해야하는 기술 자체의 난이도보다는 어떤 것부터 공부해야할지 모르겠다라는 것이다.

이건 요즘 같이 새로운 정보가 쏟아져 나오는 시대에는 당연한 이야기인데, 개발 공부를 시작하기 전에 선택해야할 것이 많아도 너무 많다. 언어와 프레임워크를 먼저 공부할 것인지 컴퓨터에 대한 기초부터 공부해야 하는 것인지부터 시작해서, 어떤 언어를 공부해야 하는지, React를 공부해야 하는 지 Vue를 공부해야 하는 지 등 개발 공부를 시작하려고하면 선택해야할 것도 너무나도 많다.

게다가 이런 것들은 정답이랄게 없기 때문에 주위의 개발자들에게 물어보거나 커뮤니티에 물어봐도 사람마다 다른 답변이 돌아올 가능성도 높다.

필자 개인적으로는 우리의 이런 성향에는 대한민국의 사회 분위기가 어느 정도 적용한 것 같다는 생각이다. 솔직히 우리는 어릴 때부터 내가 스스로 정하는 길이 아닌 부모님이 하라는 대로 열심히 학교나 학원가서 공부하고 자란, 그런 세대지 않은가? 심지어 대학 진학 시 과를 고를 때도 자기가 공부하고 싶은 학문이 아니라 성적에 맞춰서 가는 경우도 많다.



수능도 물론 중요하지만, 떨어지거나 인서울 못한다고 해서 인생이 망하는 건 아니더라.
필자도 맨날 놀다가 수능 망쳐서 대학 못갈 뻔 했지만 잘 살고 있다.


대학에 들어간 이후에는 남들이 하는 대로 토익 점수도 만들고 자격증도 따고 인턴십도 하면서 취업 준비를 하고 취업을 한다. 이 과정 속에서 내가 진짜로 원하는 것은 뭘까?라는 생각을 하기란 솔직히 쉽지 않은 현실이다.(남들한테 뒤쳐질까봐 그냥 정신이 없다)

이런 상황에서 갑자기 자, 이제 너는 으른이니까 니가 스스로 공부하고 싶은 것을 찾아보렴이라고 하면 적응 안되는 게 당연한 것일지도 모른다.

자, 일단 필자가 제안하고 싶은 것은 이렇다. 일단 뭘 공부해야 할지에 대한 생각은 잠깐 접어두자. 이건 어차피 뭐부터 공부를 시작하던 간에 해야할 게 너무 많기 때문에 답이 없다. 여기서 중요한 것은 뭘 공부할지를 정하는 것이 아니라 뭘 만들지를 우선 정하는 일이다.

무엇을 만들고 싶은 지 먼저 정해보자

필자에게 뭘 공부해야할지 모르겠다라는 이야기를 하는 분들에게 필자가 제일 먼저 던지는 질문이 있다.

그래서, 뭘 만들고 싶은지 생각해봤어요?

이 질문을 하면 놀랍게도 10명 중 9명은 글쎄요라고 대답을 한다. 자신이 뭘 만들고 싶은지 모르는 상태에서 개발에 대한 공부를 시작하려고 하는 것이다. 이런 접근 방식으로 개발을 공부하면 대략 이런 문제가 생긴다.


  1. 목표가 없거나 두루뭉술하기 때문에 어디까지 해야 공부가 끝나는 지 알 수가 없다.
  2. 배운 걸 바로 써먹지 못하니까 공부가 재미가 없다.

첫번째 문제같은 경우가 심각한 경우인데, 애초에 목표 자체가 없거나 단순히 개발을 잘하고 싶다와 같은 두루뭉술한 이유이기 때문에 아무리 공부해도 본인이 이 달리기의 결승점이 어디인지 알 수가 없다. 이런 경우에는 처음 시작은 열정적이었으나 점점 지쳐서 공부를 멀리 하게될 가능성이 높아진다.

공부는 사실 집중을 얼마나 잘하느냐가 중요하다. 100가지 과목을 10년 걸려서 끝내는 것보다 1가지 과목을 1달 안에 끝내고 다음 걸 하는 게 더 낫다는 이야기이다. 이때 뭐부터 공부해야할지 모르는 상황이라면 이것저것 건드려보다가 아 개어렵다...하고 그만 두게 될 가능성이 높다는 것이다.

두번째 문제의 경우, 그냥 첫번째 문제의 연장이나 마찬가지다. 그냥 재미가 없다. 초중고에서 배우는 영어나 수학이 재미없는 이유도 비슷한데, 이걸 어디다가 쓰는 지도 안 알려주고 무작정 외우라고 하기 때문에 재미가 없는 것이다. 지식이라는 것은 적재적소에 써먹어야 빛을 발하는 법인데 주구장창 외워서 시험 볼때만 사용하려고 공부한 지식은 사실 별 의미가 없다.

그래서 필자같은 경우는 어떤 기술을 공부하고 싶을 때, 그 기술을 사용해서 어떤 것을 만들 수 있을 지 먼저 고민해본다. 잘 고민해보면 분명히 한두개는 나온다. 혹은 만들고 싶은 것을 먼저 생각해보고 그걸 만들 때 해당 기술을 사용하는 방법으로 접근할 수도 있다. 중요한 포인트는 그 기술을 사용하는 것이다.

필자의 경우는 후자를 더 좋아하는 편이다. 일단 만들고 싶은 것을 먼저 생각하고 거기에 필요한 지식을 공부한다. 때로는 논문을 분석해야 할수도 있고, 대학교 때 잠깐 들었던 수업의 교재를 다시 꺼내봐야 하는 경우도 생길 수도 있으며 사용하고자 하는 기술의 공식 문서를 밤새도록 읽어봐야 할 수도 있지만 그래도 이왕 시작한 프로젝트를 완성하고 싶어서 끝까지 공부하게된다.



2017년부터 꾸준히 만들어온 태양계 시뮬레이터


필자는 어릴 때부터 우주를 굉장히 좋아했는데, 코딩을 처음 시작할때부터 태양계 천체의 움직임을 구현하고 싶다는 마음이 있었다. 하지만 이걸 만드려면 컴퓨터 그래픽과 수학, 천체물리학을 어느 정도 이해하고 있어야 했는데, 처음에는 엄두가 안나서 손을 안대고 있었다. 그러다가 개발자로 일을 시작하고 몇년이 지난 어느 날, 이대로 가다간 절대 이 프로젝트를 시작할 수 없겠다라는 마음이 들었고, 그 이후 그냥 무작정 케플러 궤도 방정식과 선형대수학을 공부하기 시작해서 결국 오랫동안 그려왔던 프로젝트를 어느 정도 완성할 수 있었다.

물론 굉장히 어렵고 힘들었다. 필자는 수학을 그렇게 좋아하는 편이 아니기 때문에 온통 수학 떡칠인 저 어플리케이션을 만들 수 있을지도 의문이었다. 그래서 필자는 한 1년 정도 공부 하면서 만들면 기본적인 틀을 완성할 수 있을 것이라고 생각했는데 1년은 무슨… 3개월만에 만들었다.

물론 필자가 3개월 만에 케플러 궤도 방정식과 같은 어려운 이론을 전부 이해했다는 뜻이 아니다. 그냥 태양계 시뮬레이터를 만들 수 있을 정도의 수준으로 이해한 것이다. 그리고 애초의 필자의 목적은 천체 물리학을 공부하는 것보다는 태양계 시뮬레이터를 만드는 것이었으므로 완벽하게 이해할 필요도 없었다.

필자는 그렇게 머리가 좋은 편도 아니다. 그냥 매일 잠을 줄여가면서 꾸준히 공부한 것이다. 수식이 잘 이해가 안되면 코드로 포팅해서 한 라인씩 돌려보면서 이해했다. 그리고 이런 노가다성 공부는 진짜로 이루고 싶은 목표가 있다면 사실 누구나 다 할 수 있다.(진짜 머리가 좋은 사람은 태양계 시뮬레이터 같은 거 만들 시간에 비트코인을 샀을 것이다)



필자도 여러분과 마찬가지로 면접에 조져지고 시험에 조져지고 한다


결국 공부란 이런 것이다. 뭔가에 사용하기 위해 필요한 지식을 습득하는 것이라는 것이다. 아무런 목표가 없는 공부는 우리가 단지 수능을 잘보기 위해 공부했던 고3 시절과 다름이 없다. 물론 그 당시 공부의 목표는 수능을 잘 보는 것이었겠지만 우리는 이제 그런 수박 겉핥기 같은 목표가 아니라 좀 더 본질적인 목표를 가져야 한다.

그렇게 자기 자신에게 목표를 부여함으로써 강한 동기를 이끌어내고, 그 동기로 끈기있는 공부를 할 수 있는 원동력을 만들어 가는 것이 중요하다. 무작정 공부를 시작하기 전에 내가 왜 이걸 공부해야하는 지부터 한번 만들어보자.

자기 주관대로 공부하자

방금 필자는 공부의 목표가 얼마나 중요한 것인지에 대해서 이야기했다. 필자가 방금 설명한 만들고 싶은 것을 정하자라는 목표는 나에게 당장 필요하지 않은 지식일지라도, 그 필요를 만들어내는 하나의 방법이다. 이 지식이 나에게 필요한 상태로 정의됨에 따라서 동기를 부여하는 방법이다.

하지만 이 방법은 공부를 시작하고나서 중간에 포기하지 않도록 만들어 주는 힘이 더 강하다. 그래서 우리는 어떤 지식이 나에게 필요한 지식인가?도 함께 생각해봐야한다. 단, 이 필요한 지식이라는 기준이 사람마다 다르다.

필자같은 경우 필요한 지식의 우선 순위는 철저하게 내가 뭘 만들 때 필요한 지식이다. 어떤 기술이 유행하든 세계 점유율이 90%가 넘든 간에 별로 흥미가 안가면 공부를 안하는 편이다. 그러다가 어떤 회사에 들어갔는데 그 지식이 필요하다싶으면 그때가서 공부하기도 한다.

필자가 지금까지 만든 프로젝트들만 봐도 알겠지만, 필자는 웹 프론트엔드 개발자이기 때문에 태양계 시뮬레이터나 오디오 이펙터같은 걸 만들어봤자 거기서 얻은 지식을 써먹을 확률은 상당히 낮다. 그래서 면접에 들어갔을 때 면접관이 이건 왜 만드신거에요?라고 물어보면 그냥 쿨하게 자기만족이요라고 대답한다.

이렇게 사람마다 필요한 지식의 정의는 달라질 수 있기 때문에 필자는 어떤 것이 필요한 지식이고 필요없는 지식인지를 알려줄 수 없다. 단, 필자가 이야기하고 싶은 것은 공부를 할 때도 자기 주관이 있어야 한다는 것이다.

자기 주관이 무엇인지에 대해 설명하기 위해 구글에서 만든 크로스 플랫폼 프레임워크인 Flutter를 공부하고 있는 분들을 예로 들어볼 수 있겠다. 이걸 공부하는 분들은 Flutter가 갑자기 잘나가서 공부하는 게 아닐 것이다. 애초에 Flutter는 아직 유명하지도 않을 뿐더러 이 프레임워크에서 사용하는 언어는 Dart이기 때문에 사실 상 Flutter가 아니면 써먹을 데도 별로 없다.



codementor가 조사한 2018년도에 배우길 추천하지 않는 언어
Dart가 당당히 3개 부문 1위를 차지했었다. 물론 2019년에는 많이 좋아졌다.


그럼 왜 하는 것일까? 뭐 사람마다 여러가지 이유가 있겠지만 아마도 재밌을 것 같아서, 신기하니까, 테스트 해보고 싶어서 등의 이유가 많지 않을까? 왜냐면 아직 그렇게 유명하지도 않고, 성능이나 버그 등이 제대로 검증되지 않은 프레임워크이기 때문에 직장에 적용하기도 쉽지 않기 때문이다. 그래서 필자는 아마 이 분들의 개인적인 흥미가 크게 작용했을 것이라고 생각한다.

자기 주관이 있는 사람들은 유행에 크게 흔들리지 않는다. 자신에게 필요한 것을 계속 찾아서 공부하고 자기가 하고 싶은 공부를 한다. 이런 사람들은 본인이 네트워크에 관한 지식이 부족하다고 느끼면 어떤 부분이 부족한 건지 찾아내서 그걸 공부하지, 유행 따라서 쿠버네티스(Kubernetes)부터 공부하지는 않을 것이다.

하지만 내가 지금 어떤 것이 부족한 상황인가?라는 질문의 해답을 찾기는 꽤 힘든 과정이다. 끊임없이 자기 자신에게 질문하고, 다른 사람과 비교도 해보고 자신이 앞으로 어떤 길을 가고 싶은 지도 생각해봐야 한다. 혹시 지금까지 이런 것에 대한 고찰을 깊게 해본 적이 없다면 한번 생각해보자.

마치며

만약, 수능 쪽집게 강의처럼 공부 잘하는 방법을 기대하고 들어온 독자에게는 미안하지만, 필자는 공부를 잘 하는 방법을 알려줄 수 없다. 공부에는 왕도가 없다. 그냥 꾸준히 하다보면 느는 것이기 때문이다. 대신 필자가 이 포스팅에서 이야기하고 싶었던 것은 공부를 조금이라도 효율적으로 하는 방법이었다.

위에서 이야기한 두 가지를 한 문장으로 정리해보자면 대략 이런 느낌이다.

  1. 내가 이 공부를 왜 해야하는 지 알고 하자
  2. 남들이 다 React한다고 나도 반드시 React를 해야할 필요는 없다.

1번 같은 경우는 위에서 거듭 강조했던 동기부여에 대한 말이다. 공부가 아니라 그 어떤 것을 하던 간에 동기부여가 제대로 되지 않은 일은 재미도 없고 기계적으로 하게 될 수 밖에 없다. 그냥 열심히만 하는데는 한계가 있기 마련이다.

2번은 사람마다 의견이 조금 갈릴 수 있는데, 일단 필자 생각은 이렇다. 남들이 다 React를 사용할 때 나도 React를 공부한다면 취업은 조금 더 쉬워질 수 있을 것이다. 그러나 대부분의 경우, 특히 프레임워크같은 경우는 유행을 어느 정도 타기 마련이다. 그 시대에서 원하는 패러다임과 여러가지 한계 상황을 반영한 것이기 때문이다. 2~3년 뒤에 React보다 더 좋고 획기적인 프레임워크가 나오지 않을 것이라고 어느 누가 말할 수 있을까?

사실 여러 커뮤니티에서 자주 보이는 React가 좋아요? Vue가 좋아요?와 같은 질문도 어떤 것을 선택해야 최소 비용을 투자하여 최대 이윤을 얻을 수 있는 지를 고민하는 과정에서 나오는 질문인데, 그냥 아무거나 이름이나 로고가 맘에 드는 거 골라서 공부하자. 어차피 둘 중에 뭘 선택하든 3년 뒤에는 둘 다 버리고 새로운 거 공부해야할 수도 있다.

중요한 것은 지금 나에게 필요한 것이 무엇인가?이지, 아무 이유없이 단지 사람들이 많이 사용하고 있다거나 사람들이 이 프레임워크가 좋다고 말하는 정도로 그 기술의 공부를 시작하지는 말자. 물론 사람들이 많이 사용하고 있으니까 공부를 하려고 한다는 것도 하나의 이유가 될 수 있다. 필자가 말하는 것은 자기가 결정한 것이 아니라 친구따라 강남가는 식의 결정을 말하는 것이다.

사람들이 그 프레임워크가 좋다고 말해서 공부해보고 싶다면 적어도 진짜 그 프레임워크가 어떤 점이 좋다고 하는 것인지, 진짜 좋은 것인지 정도를 스스로 판단하고 공부를 시작할 수 있는 주관이 필요하다. 면접볼 때 본인이 어떤 기술을 공부했다고 하면 그걸 왜 공부했냐, 어떤 점이 좋았고 나빴냐고 물어보는 게 괜히 물어보는 것이 아니다.

글의 서두에서도 한번 언급했지만 이 포스팅은 절대 정답이 아니다. 필자는 필자만의 공부 방법을 찾은 것이고 여러분의 방법은 필자와 같을 수도, 또 다른 방법 일수도 있다. 가장 중요한 것은 여러분 스스로 어떤 것에 흥미를 느끼는 지, 어떨때 집중이 잘되는 사람인지 계속 자기 자신에게 질문하고 답을 찾아가는 것이다. 어쨌든 이 포스팅은 필자의 주관적인 생각이지만, 그래도 개발을 공부할 때 뭐부터 시작해야할지 고민하고 있는 분들에게 도움이 되었길 바란다.

이상으로 개발자가 공부로 살아남는 방법 포스팅을 마친다.

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×