내가 더 좋은 개발자가 될 수 있었던 방법

 

 

 

 

React Conf에서 만난 사람들이 저에게 더 좋은 개발자가 되려면 어떻게 해야 하는지 물어봤던 적이 있습니다. 아마 저를 꽤 높은 수준의 프로그래머라고 생각하셨던 것 같습니다. 그래서 저는 이번 기회에 수년 동안 제가 어떤 방식으로 프로그래밍에 접근해 왔었는지 "멘탈 모델"을 적어보는 시간을 가지려고 합니다.

 

일단 저에 대한 정보를 몇 가지 말씀 드리자면, 저는 32세이고, 10년 이상의 경력을 가지고 있습니다. 최근에야 비로소 제가 하고 있는 일에 자신감을 가졌습니다. 하지만 전 여전히 제자신을 끊임없이 의심하고 있습니다. 아마 이런 느낌은 영원히 사라지지 않을 것 입니다. 여러분들은 이 기분을 무시하고, 열심히 개발을 하고, 경험을 쌓으시길 바랍니다.

 

---

 

 

이번에 제가 말씀드리는 것들은 프로그래밍 기술을 향상시키기 위한 팁들입니다.

포스트를 읽으시며 가장 나에게 적합한 방법이 무엇인지 찾으시길 바랍니다. 제가 말씀드리는 팁들은 그저 저에게 도움이 된 것들일 뿐입니다.

---

 

당신에게 영감을 주는 사람을 찾되, 맹목적으로 믿지는 마세요

 

 

 

수년동안 새로운 기술과 정보를 습득하기 위해 많은 사람들의 자료를 찾았었습니다. 저는 그들의 말이 옳다고 믿었고, 그들이 작업한 것들을 공부하며 많은 것들을 배웠습니다. 그 사람들은 매우 생산적이였고, 똑똑했고, 저나 다른사람들에게 영감을 주었습니다. 여러분들도 그런 사람들을 찾아 영감을 받고 배우시길 바랍니다.

 

하지만 그들의 말이 맹목적으로 전부 옳다고 생각하지는 않길 바랍니다. 트위터에서 봤을 때, 엄청 대단해 보이는 것들도, 실제로 작동 방식을 보면 별반 크게 다를 바가 없습니다. 모든 수단과 방법을 가리지 않고, 작동하는 코드를 쓰려고 하는 것일 뿐입니다. 만약 그 사람들의 의견에 동의가 되지 않는 경우가 생기시다면, 그들에게 의견을 제시하고 그 과정을 배우시길 바랍니다. 저에게 가장 생산적인 대화 중 일부도 이런식의 과정을 통해 나왔었습니다.

 

저의 Emacs 설정은 엉망입니다. 제 OCaml 자동완성은 한달이 지났지만 아직까지도 왜 되지 않는지 모르겠습니다. 저는 작업을 자동화 하지 않기에, 필요한 쉘 커맨드를 실행할 때에는, 쉘 히스토리를 뒤지기도 합니다. 저도 처음에는 끔찍하게도 더러운 코드를 작성 합니다. 그리고 제가 하고 있는 작업이 명확해질 때까지, 전역 객체에 무언가를 붙입니다. 숙련된 개발자들은 항상 여러가지 방법을 사용합니다. 중요한 것은 당신이 무언가를 하고 있다는 것 입니다.

 

 

 

 

당신의 일을 스스로 낮게 평가하지 마세요

 

 

초보 개발자들은 자신들이 초보니까 자기가 만든 작업물이 그다지 가치가 있지 않다고 느끼는 경향이 있습니다. 심지어 경험이 많은 개발자들도 익숙하지 않은 개발을 할때 초보 개발자들과 같은 생각을 하고 있습니다. 제가 생각하기에는 가장 좋은 아이디어 중 몇가지는 틀에 박힌 의견을 가진 사람들이 아닌, 새로운 개발자에게서 나옵니다.

 

당신이 하는 일은 무엇이든 가치가 있습니다. 혹여나 당신의 아이디어가 효과가 없더라도, 그 방식이 왜 되지 않는지 방법을 배우게 됩니다. (참고 사항 : 위에 말씀드린 일을 실천하시고 새로운 사용자들을 잘 맞아주세요)

 

 

 

 

 

항상 무언가를 해야한다는 압박감은 느끼지 마세요

 

 

매일 새로운 기술이 등장하면서, 쉬면 하루라도 뒤쳐질 것 같은 기분이 들 때가 있습니다. 하지만 절대 그렇지 않습니다. 당신이 일을 하지 않는 시간이 오히려 더욱 나은 결과를 낳게할 수 있습니다. 오히려 신선한 관점을 가질 수 있게 도와주고, 또 새로운 아이디어를 떠오르도록 도와줍니다.

 

매일 등장하는 대부분의 내용은 그전에 있던 아이디어를 재탕한 것 입니다. 진정으로 혁명적인 일은 몇 년에 딱 한 번씩만 나타납니다.

 

관련 강연 : Hammock Driven Development

 

 

 

 

 

 

자잘한 것(Fluff)들은 무시하세요

 

더 빨리 목표를 위해 달려가는 방법은, "자잘한 것(Fluff)"을 무시하는 겁니다. 다른 말로 표현하자면 "시간을 효율적으로 사용하세요"라는 말과 같습니다. 하루에 주어진 시간들중 핵심적인 내용에 많은 시간을 쓴다면, 아마 시간이 지나면서 큰 차이를 보게 될 것 입니다.

 

그렇다면 자잘한 것(Fluff)은 무엇일까요? 그건 여러분들이 생각하는 것에 따라 달려 있지만, 몇 가지 예로 언어의 문법, 라이브러리의 API, 빌드 도구의 설정 방법과 같은 것들을 들 수 있습니다. ES7 이후의 자바스크립트 문법등을 익힌다고 해서 컴파일러의 동작원리를 익히는 것만큼 더 좋은 개발자로 만들어주는 것은 아닙니다.

 

 

기존에 있던 아이디어를 새로운 API를 사용하는 라이브러리를 채택해서 쓰는 일은 그닥 흥미롭지 않습니다. 물론 위에 말씀드린 것들이 모두 중요하지만, 더욱 심층적인 내용에 시간을 더 쓰시는 것을 추천 드립니다.

 

여러분들께 질문을 드리겠습니다. 코드를 "멋지게" 보이게 만들기 위해 많은 시간을 쓰시나요? 만약 그렇다면 그러지 않는 것이 좋습니다. 시간이 지나면 코드는 많이 변경이 됩니다. 그저 해결하려는 문제와 추상화 계층에 더욱 시간을 쓰시는 것이 좋습니다. 모든 작업을 끝마치면, 그때서야 남은 시간에 코드를 다듬으세요. (이것은 DRY 원칙에도 적용 됩니다. 너무 걱정하지 마시고, 자유롭게 중복 코드를 작성해보세요.)

 

 

 

 

 

 

과거의 연구했던 것들을 파헤치세요

 

 

어떤 아이디어가 떠오르면, 바로 자리에 앉아 작업하고 싶을 때가 있습니다. 하지만 기존의 사람들이 문제를 어떻게 해결해 왔는지, 간단하게라도 살펴보기 전에는 그렇게 하시면 안됩니다. 주제를 조사하는 데 며칠을 쓰신다면, 내가 항상 해왔던 해결하는 방법이 완전히 바뀔 수 있습니다.

 

학술 논문을 읽는 방법도 좋습니다. 저는 수학적 의미론/조작적 의미론 같은 용어를 몰라 논문을 읽지 못했던 적이 많이 있습니다. 하지만 수학 대신 코드를 사용하여 읽는다면 그렇게 어렵지 않습니다. 지난 30년 동안의 논문에는 엄청나게 많은 정보들이 담겨 있습니다. 논문에서 이런 정보들을 잘 추출해낸다면, 당신은 곧 지식을 선도하는 사람(thougjt-leader)이 될 것 입니다.

 

Prettier 가 이것에 대한 완벽한 예시 입니다. 저는 제가 뭘 하고 싶은지는 알겠는데, 어떻게 구현해야하는지 방법을 몰랐었습니다. 하지만 조사를 해보니 이 논문을 찾을 수 있었고, 며칠 뒤에 내가 무엇을 해야 하는지 정확히 알 수 있었습니다. 그러고 나니 기본적인 작업을 일주일만에 끝낼 수 있었습니다. 만약 사전에 조사를 하지 않았더라면, 훨씬 더 오래 걸렸을 것 입니다.

 

관련 논문 : Paper We Love

 

 

 

 

 

 

 

큰 프로젝트를 맡으시고, 익숙지 않은 일을 해보세요

 

 

 

경험하는 것이 가장 좋습니다. 모든 사람들이 다 도전할 수는 없지만, 만약 기회가 있다면, 큰 프로젝트에 도전해보시기 바랍니다. 굳이 끝까지 마칠 필요도 없습니다. 그냥 컴 파일러를 작성하는 것만 해보더라도 많은 것들을 배울 수 있습니다.

 

복잡한 문제를 어떻게 풀어야 할지 모르겠을 때, 기분은 솔직히 좋지 않습니다. 익숙하지 않기 때문에, 해결 방법을 찾기 위해서 더 많은 공부와 연구가 필요합니다. 하지만 이 과정을 겪는다면, 훨씬 더 좋은 개발자가 될 것 입니다.

 

새로운 언어를 배워보는 것부터 시작하세요. 기존에 있던 습관을 벗어나, 새로운 관점으로 사물을 볼 수 있도록 도와주는 효과적인 방법 입니다. 제가 초보 개발자던 시절, 가장 잘했던 일은 바로 Scheme을 배웠던 것 입니다. 이 언어는 매우 간단하고, 모든 코드를 함수형으로 작성하도록 강요합니다. 제가 Sheme을 배웠던 시간들은 지금도 여전히 도움을 주고 있습니다. 일단 코드를 보는 방식이 근본적으로 바뀌었습니다.(제가 설립한 회사 "Shift Reset LLC"도 Scheme에서 따온 것 입니다.)

 

 

 

 

 

---

 

 

마지막으로 몇 가지 방법을 추천드리겠습니다. 전부 제가 개발자로 활동하면서 큰 도움을 주었던 것들 입니다.

 

거의 대부분이 지금도 작업하는데에 도움을 주고 있으며, 새로운 관점을 가지도록 도움을 줍니다. 굳이 이것들을 전부 할 필요는 없습니다. 그저 제가 더 좋은 개발자가 될 수 있도록 도움이 되왔던 방법들이니, 여러분들은 참고만 해주셔도 좋습니다.

 

 

---

 

 

· C배우기

아직 해보신 적이 없으시다면, 기초만 배우세요. 왜 사람들이 C를 가지고 불평하는지, 이해하는 것도 중요합니다.

 

 

· 컴파일러 작성

아마 익숙하지 않을 일을 하면서 배우는 방법 중 가장 좋은 방법일겁니다. Super Tiny Compiler을 확인해보세요.

 

 

· 매크로 배우기

Scheme, Lisp, Clojure(Script)를 참조해보세요. 매크로는 코드를 보는 방법을 크게 바뀌어 줍니다.

 

 

· Sicp

Sicp는 아주 오래된 책이지만, 지금도 여전히 유용한 정보들이 많습니다(몇 사람들은 그렇게 생각하지 않지만). 프로그래밍 지식이 거의 없는 사람들을 대상으로, meta-circular evaluator와 컴파일러를 구현하는 방법이 자세히 담겨 있습니다.제가 컴파일러에 빠져들도록 했던, 너무 재밌게 읽었던 책을 추천 드리자면 Lisp In Small Pieces 입니다.

 

 

· Continuation 을 이해하기

Continuation는 낮은 수준의 제어 흐름 원리 입니다. Scheme은 이것을 유일하게 구현한 언어입니다. 실무에는 절대 사용하지 않지만, 제어 흐름에 대한 생각을 바꾸게 할 것 입니다.

 

 

· 새로운 프로그래밍 언어를 배우기

Clojure, Rust, Elm, OCaml/Reason, Go 또는 Scheme 중 하나를 추천드립니다. 이 언어들은 모두 각자 고유한 기능을 가지고 있으며, 새로운 사고 방식을 가질 수 있도록 도와줄 것 입니다.

 

 

 

 

 

 

 

 

*본문 내용은 https://archive.jlongster.com/How-I-Became-Better-Programmer 를 각색한 자료입니다.