개발자의 공부법
모르는 게 힘인 개발자의 쾌락 학습법
'개발자 (혹은 좋은 개발자)가 되려면 어떤 걸/어떻게 공부해야 될까요?'라는 질문이 커뮤니티에 많이 보인다. IT 업계 광풍과 함께 '개발자'라는 직업이 핫해지면서 이런 질문들이 많이 보인다. 개발자로서 공부를 어떻게 대하고 어떤 식으로 접근해왔는지 정리해보려 한다. 나의 공부는 모른다는 걸 인지하면서부터 시작됐다.
모르는 건 문제가 아니다
모르는 게 무엇인지 모르는 게 문제다
개발을 공부를 처음 시작할 때 마주한 난관은 모르는 게 너무 많아서 무엇을 모르는지 조차 알지 못한다는 것이었다. 개발 공부의 시작은 무엇을 모르는지 알아보는 것부터였다. 경력 10년, 20년 배테랑(?) 개발자도 턱 하고 막히는 지점이 '모르는 것이 무엇이지'이다. 경력 무관하게 '무엇을 공부해야'하는지 질문이 올라오는 이유이다. 많이 알면 알수록 공부 의지나 필요성이 약해지는 이유도 비슷하지 않을까?
능력이 부족한 개발자는 모르는 게 많을까?
제아무리 날고 긴다는 개발자도 모르는 게 많다. 물론 아는 것도 많다. 아는 게 많으면 모르는 게 적은 게 아닌가?라는 생각을 할지도 모르겠다.
개발 지식의 총량(y)은 시간(x)이 증가함에 따라 무한대로 발산한다(다만 시간이 흐름에 따라 기술은 진보한다를 전제로 한다). 새로운 기술과 지식이 끊임없이 양산되므로 개발 천재(?)라 해도 (24/7 잠 안 자고 공부하지 않는 이상) 발산하는 지식의 총량을 따라갈 수 없기에 모르는 게 많을 수밖에 없다.
대신 ***능력 있는 개발자는 x와 y에 비례하여 증가하는 y'를 갖는다(물론 정비례는 아닐 것이다). 모르는 게 많아지는 만큼 아는(혹은 앞으로 알아갈) 것도 많아진다는 의미이다. 무엇을 모르는지 찾아가고 모르는 것들을 줄여 나가게 된다.
***능력 있는 개발자의 정의에 '능력 있는 개발자가 되기 위해 노력하는 자'도 포함한다
모르는 것 어디서 찾을 수 있을까?
스스로 찾거나 타인이 알려주거나 두 가지이다.
무지하다 못해 백지의 상태라면 무엇을 모르는지 조차 모를 수 있다. 이때는 관련 분야의 사람에게 '내가 무엇을 알아야 하는지'를 물어봐야 한다. 사람이 아니라면 커뮤니티 혹은 책 등등 어떤 채널이어도 좋다. 주변에 아는 사람이 있다면 좋겠지만 없다면 커뮤니티, 외부 강연, 컨퍼런스를 적극 활용해야 한다. 외부 활동이 부담스럽다면 유튜브, 블로그 등등 개발 관련 자료들은 차고 넘친다. 내가 모르는 것/알아야 할 것을 키워드 위주로 정리해보자.
현직자라면 코드 리뷰나 동료들과의 기술 잡담이 알짜배기 지식 소스가 된다. 리뷰와 공유 과정에서 본인이 생각하지 못했던 키워드나 인사이트가 많이 도출된다. 개발이 협업인 이유이다. 개발자 지식과 경험의 총량은 개인에 국한되지 않고 팀으로 확장되는 경향이 있다. 혼자 끙끙 대거나 부끄러워하지 말고 동료들에게 적극적으로 공유하고 피드백받기를 주저하지 말자.
키워드가 도출됐다면 이제 내용을 채워갈 차례이다. 하지만 알아가는 과정은 온전히 본인의 몫일 수록 좋다. 개발자들의 대화에서 "오늘 프록시 서버 세팅하면서 엄청 삽질했어요"와 같은 류의 대화가 종종 보인다. '오랜 시간 시행착오를 겪으면서 무언가를 하는 것'을 보통 삽질이라고 한다. 이런 말을 들으면 동료들은 어떤 생각을 할까? 그 개발자가 무능력하다고 생각할까? 아니다. 오히려 그 개발자가 익숙지 않은 기술도 활용할 수 있는 능력이 있고 프록시 서버도 다룰 줄 알게 됐구나라고 생각할 것이다.
타인의 경험과 지식을 통해 삽질을 줄일 수 있다면 짧은 시간 안에 문제를 해결할 수 있어 효율적이다. 아마도 위에서 언급한 개발자도 필요한 부분에서 타인의 도움을 받았을 것이다. ****여기서 강조하고 싶은 것은 온전히 본인의 것으로 만드는데 삽질만큼 좋은 것은 없다는 것이다. 해당 분야에 지식이 어느 정도 있는 상태라면 조력자의 도움을 통해서 빠르게 많은 것을 배우는 게 유리하다. 하지만 초심자라면 혹은 삽질의 경험이나 능력(또는 자신감)이 부족하다면 삽질을 해보는 것을 추천한다. 모든 상황에서 조력자가 있을 순 없을 뿐더러 언젠가는 본인의 것을 타인에게 전달하는 순간이 돌아오기도 한다. 이런 의미에서 알아가는 정은 본인의 몫이어야 한다.
****모든 상황에서 삽질하라는 게 아니니 오해하지 말길 바란다. 외부 채널을 적절히 활용하는 것도 공부를 잘하는 방법이자 문제 해결 전략이다.
모르는 것을 부끄러워하지 말고 드러내자
모르는 것을 모르는 것만큼 문제인 것은 모르는 것을 드러내지 않는다는 것이다. 전자와 후자의 차이는 의도했는가 안 했는가이다. 모르는 것을 부끄러워하던 모르는 걸 굳이 얘기하지 않는 것이던 상관없다. 모른다는 것을 감췄다는 데는 결과는 동일하니까. 잘못했다는 것은 아니다. 다만 모른다는 것을 드러내게 되면 지식을 전달받는 기회가 많아진다. 알아가기 위한 액션을 더 적극적으로 취할 수 있기도 하다.
현업에서 개발을 하다 보면 동료들을 통해서 지식이나 경험을 공유받을 수 있는 기회가 아주 많다. 공부 시간이 부족한 직장인들에게 단비와 같은 소스들이다. 하지만 모른다는 걸 동료들이 모른다면 알려줄 수가 없다. 더욱이 모른다는 거에 부끄러움을 느끼는 성향이라면 더더욱 알려주기 어려울 것이다. 알려주는 게 오히려 관계를 훼손한다고 생각해서 조심스러울 수 있기 때문이다. 동료들과의 소소한 대화 속에서 얻은 키워드와 경험들이 공부의 좋은 출처들이 된다. 모른다는 것을 적극적으로 표현해보자. "내가 모르는 것을(혹은 네가 알고 있는 것을) 나에게 제발 알려줘"라고.
추측하지 말아라
대충 이럴 것이다라고 넘겨짚는 것을 지양하자. 그대로 넘어간다면 모르는 것을 덮어두게 되는 꼴이다. 추측도 습관이 된다. 문제가 되는 부분이 있다면 어떤 부분이 어떻게 문제가 됐는지 검증하고 넘어가야 한다. "이거 이렇게 하면 저렇게 동작할 걸요?", "이래서 문제가 되는 걸 거예요"는 옳지 않다. 기능을 만드는 것만큼 만들어진 기능을 검증하는 역량도 개발자에게 필요하다. 기존의 기술을 검증하는 과정에서 차용할 수 있는 기술을 배우는 쏠쏠함도 있다. 평소에 큰 고민 없이 사용하던 라이브러리나 프레임워크가 있다면 검증해보는 시간을 가져보는 것도 도움이 될 것이다.
*****최근에 스프링 프레임워크 코드를 까보는 시간을 가졌는데 내부 구현과 원리를 이해하는 시간을 가졌다. 디테일한 프레임워크 활용과 이슈 발생 시 문제 해결이 수월해졌다. 코드로 읽는 스프링 프레임워크
필요 없는 공부는 없다
최근 블라인드에 "도커 공부해야 할까요?"라고 질문하는 글을 봤다. 흥미로운 건 그 질문에 달린 답변들이다. 도커를 왜 공부해야 하는지 또는 왜 공부할 필요가 없는지와 같은 기다 아니다의 답변들이 아니었다.
그거 한번 해보는 게 어렵나요?
할까 말까 고민할 시간에 그냥 한번 해보세요
그렇다. 공부를 고민할까 말까 고민할 필요가 없다. 알 필요가 없는 지식은 없다. 모른다면 공부를 해보면 된다. 그리고 필요 없다고 생각이 들면 멈추면 된다. 그 시간마저 의미가 있다. 왜 도커가 왜 필요 없는지 알게 됐지 않은가. 걸러내려면 뭘 알아야지 걸러낼 것 아닌가. 단순히 모른다고 해서 걸러낼 것인가? 더불어 당장은 필요 없는 기술일지 모르지만 가까운 미래에 문제를 해결하는 좋은 기술(또는 키워드)이 될 것이 분명하다. 도커라는 단어를 알고 있는 것만으로도.
작은 관심이라도 있는 분야라면 고민하지 말고 일단 공부해보는 것이 좋다. 키워드 정도 얻은 수준이라도 해도 의미가 있다. 개발자들이 괜히 커뮤니티나 컨퍼런스에 기웃기웃하는 게 아니다. 키워드를 줍줍 하기 위함이다. 나중에 또는 당장 마주한 문제의 실마리를 풀게 되는 힌트가 될 수 있다. 깊게 들어가는 것은 그다음에 고민해도 늦지 않다. 아는 만큼 보이고 힘이 된다는 사실을 잊지 않았으면 좋겠다. 개발에 있어서 만큼은 몰라도 되는 것은 없다. 고민하면서 아무것도 안 하는 것보단 일단 시작해보자.
예비 개발자 혹은 학생들에게 어떤 언어를 공부할 것인가를 지나치게 신중하게 고민하는 경향이 보인다. 개발의 근간이 되는 기본적인 CS만 탄탄하다면 어떤 언어를 공부하더라도 문제가 되지 않는다. 트렌드는 바뀌지만 개발의 본질은 변하지 않는다. 그리고 현업에 오면 개발 언어 2개 이상을 필연적으로 하게 될 것이며 언어를 바꾸는 사례도 비일비재하다.
주의: 당장 공부하고 싶은 것이 많다면 우선순위를 정해서 공부하자. 인간의 시간은 유한하다.
하나를 깊게 판다고 개발이 깊어지지 않는다
개발자가 코드 작성에 많은 시간을 보내지만 언어 학습이 개발 공부의 전부는 아니다. 개발 환경은 운영체제, 네트워크, 데이터베이스, 하드웨어 등등 기술적인 요소부터 커뮤니케이션, 협업, 서비스 기획 등 비기술적인 분야들로 구성돼있다. 개발자는 코드 잘 짜는 게 중요하다고 말한다. 동의한다. 하지만 개발하면서 맞닥뜨리는 문제는 코드에서만 오지 않는다. 네트워크, 데이터베이스, 하드웨어, 운영체제 등등 기술 관련한 곳에서 오기도 하고 사람 또는 조직, 문화, 업무 방식에서도 온다.
개발 생태계는 꽤나 복합적인 이슈들로 똘똘 뭉쳐있다. 모든 분야를 통달할 필요는 없지만 한 분야에 편중된 역량은 개발자의 사고를 둔하게 만든다. 날카로운 문제 해결은 다양한 각도에서 문제를 바라볼 수 있는 역량에서 온다. 그 바탕은 지식과 경험의 넓이에서 온다. 당장은 필요 없는 지식이고 간접적인 지식일지라도 알아두면 나중에 좋은 무기가 될 수 있다. 혹은 앞서 반복해서 말했다시피 좋은 키워드가 될 수 있다. 그리고 트렌드는 변하고 환경은 지속적으로 변한다. 지금 중요한 기술이나 지식이 중요해지지 않을 수도 있고 중요하지 않았던 기술이나 지식이 각광받기도 한다. 편식하지 말고 거시적인 관점에서 쾌락 학습하는 것을 추천한다.
단 당장의 무기는 하나 필요하다.
