이 글은 James Long의 ‘How I Became a Better Programmer’ 의 번역본입니다
React Conf 에서 만난 몇 분이 더 나은 개발자가 되기 위한 조언을 청한 적이 있습니다. 여러가지 이유로 사람들은 제가 꽤 높은 경지의 프로그래머라고 생각하시나 봅니다. 그래서 제가 수년 간 어떻게 프로그래밍에 접근해왔는지 “멘탈 모델” 을 적어보는 시간을 가지는게 좋겠다고 생각했습니다.
저에 대해 조금 자세히 말씀드리겠습니다. 저는 서른 두 살이며 10 년이 넘는 업계 경력을 지니고 있습니다. 저는 최근 몇 년 전까지 제가 하고 있는 일에 자신감이 별로 없었습니다. 지금도 제 자신을 끊임없이 의심하고 있습니다. 중요한 것은 이런 기분은 절대 사라지지 않는다는 겁니다. 그러니까 계속 자존감이 떨어지는 기분을 무시하면서 열심히 개발을 하고, 경험을 쌓으세요.
아래 말씀드리는 팁은 프로그래밍 기술을 향상시키기 위한 수 많은 조언 중 일부에 불과합니다. 궁극적으로 어떤 방법이 자신에게 맞는지 찾아내야 합니다.
여러분에게 자극을 주는 사람을 찾되, 맹목적으로 따르지 마세요
수 년간 저는 새로운 기술을 습득하고 정보를 얻기 위해 많은 사람들의 트위터, 블로그 등을 찾아보고 발표 영상을 보았습니다. 그저 그 사람들이 옳다고 믿으며 그들이 한 작업을 파고들면서 많이 배웠습니다. 이런 사람들은 굉장히 생산적이고, 똑똑하며, 다른 이들에게 영감을 주는 편입니다. 그런 부류의 사람들을 찾아서 자극받고 배우도록 하세요.
하지만 방금 말씀드린 유형의 사람들을 맹목적으로 따르면 안됩니다. 트위터에서 보면 엄청나보이는 사람도 실제로 일하는 모습을 보면 우리가 일하는 모습과 그리 다르지 않습니다. 모든 수단과 방법을 가리지 않고 작동하는 코드를 쓰려 합니다(Hacks everywhere). 우리는 그저 더 나은 방법을 위해 계속 실험하고 있는겁니다. 그리고 무작정 그런 사람들을 믿지도 마세요. 어떤 대단해 보이는 사람의 생각이 자신과 다르다고 생각한다면 의견을 제시하고 그 과정을 통해 배우세요. 제게 가장 생산적이었던 대화 몇몇은 이런 과정을 통해 나왔습니다.
제 Emacs 설정은 개판입니다. 어쩌다 제 OCaml 자동 완성이 되지 않는지 파악도 안 됩니다(벌써 한달은 넘었군요). 저는 작업을 자동화하지도 않고, 때때로 필요한 쉘 커맨드를 실행하기 위해 전에 쉘 히스토리를 뒤적이기도 합니다. 저는 처음에는 끔찍하게 더러운 코드를 작성합니다. 제가 하고 있는 작업이 명확해질 때까지 전역 객체에 무언가를 집어넣기도 합니다. 경험이 풍부한 개발자들은 언제나 여러 가지 방법을 시도해봅니다. 중요한 것은 당신이 무언가를 하고 있다는 겁니다.
여러분의 일을 낮게 평가하지 마세요
초보 프로그래머들은 자신들이 초보니까 자기가 만든 작업물이 그다지 가치가 없다고 생각하는 경향이 있습니다. 심지어 경험이 있는 개발자들도 익숙지 않은 영역의 개발을 할 때 비슷한 생각을 합니다. 제 생각에 가장 좋은 아이디어들 중 일부는 비교적 새로운 프로그래머들로부터 나옵니다. 그 사람들은 기존 기술의 발전을 지켜보면서도 이미 틀에 박힌 의견을 보지 않는 사람들인 경우가 많습니다.
여러분이 하는 일은 어떠한 경우에도 가치가 있습니다. 여러분이 제시한 아이디어가 제대로 받아들여지지 않았다면 커뮤니티는 왜 그 방식이 제대로 되지 않는지 가르치고 배우게 됩니다. (커뮤니티에 청하건대 위에 말씀드린 일을 실천하시고 새로이 오는 사람들을 잘 맞아주세요)
언제나 무언가 해야한다는 압박을 받지 마세요
새로운 기술이 매일 등장하면서, 하룻밤 사이에 뒤쳐지는 기분이 들게 될 수 있습니다. 하지만 그렇지 않으며 실제로는 여러분 자신을 풀어둘 때 더 생산적인 일을 할 수 있고, 신선한 관점을 유지할 수 있습니다. 저는 일하지 않을 때 무의식적으로 새로운 아이디어가 떠오르곤 합니다.
매일 등장하는 대부분의 새로운 라이브러리 등은 그저 기존에 있던 같은 아이디어의 재탕입니다. 진정 혁명적인 물건은 몇 년에 한번씩 나타납니다. 이 내용에 대한 좋은 발표가 있습니다. 제목은 해먹 주도 개발(Hammock Driven Development)입니다.
자잘한 것은 무시하세요 (Ignore fluff)
목표를 향해 더 빨리 잘 나아가는 방법은, 실제로 실력을 끌어올리는데 도움이 되지 않는 “자잘한 것(fluff)” 를 무시하는 겁니다. 다른 말로 하자면 “시간을 효율적으로 사용하라” 고 할 수 있겠네요. 여러분은 하루에 실질적으로 몇 시간만 제대로 쓸 수 있는데 이 시간에 핵심적인 내용에 몰두하면 금세 큰 차이를 느낄 수 있습니다.
그렇다면 “자잘한 게” 뭘까요? 여러분이 생각하시기 나름입니다만, 제가 자잘한 것이라 생각하는 몇 가지 예를 드리겠습니다. 언어의 문법, 라이브러리의 API, 빌드 도구의 설정 방법, ES7 이후의 자바스크립트 문법 등을 익히는 일은 컴파일러의 동작원리 등을 익히는 일에 비교하면 여러분을 더 좋은 개발자로 만들어주지 않습니다. 기존에 있던 아이디어를 새로운 API 로 구현해 놓은 수준의 라이브러리를 채택해서 쓰는 일은 그닥 도움이 되지 않습니다. 물론 위에 서술한 모든 것들이 도움이 되긴 합니다만, 심층적인 내용에 시간을 더 투자하길 권합니다. 그러면 몇년 뒤에 큰 도움이 됩니다.
여러분께 질문을 드려봅니다. 대부분의 시간을 코드가 “깔끔하게” 보이는데 쓰고 있나요? 그렇다면 그러지 마시길 권합니다. 어차피 여러분의 코드는 여러 번에 걸쳐 변하게 되어있습니다. 해결하고자 하는 문제 및 추상화 계층에 많은 시간과 노력을 들이는게 더 낫습니다. 모든 문제가 정리되었다면 약간의 시간을 들여서 코드를 정리하는 작업을 하면 됩니다. (DRY 원칙에 위배될 수 있습니다만, 일단 너무 걱정하지 마시고 마음 내키는대로 중복 코드를 작성해보세요)
과거의 연구물을 파헤쳐보세요
어떤 아이디어가 떠올라서 바로 작업에 착수하고 싶어질 떄가 있습니다. 하지만 기존에 다른 사람들이 그 문제를 어떻게 해결했는지 간단히라도 살펴보기 전 까지는 무작정 시작하지 마세요. 특정 주제를 며칠 정도 조사해보는 버릇은 언제나 문제를 해결하는 방법을 송두리째 바꿔줍니다.
논문을 읽는 방법을 배우는 것도 좋습니다. 저는 수학적 의미론/조작적 의미론 등의 용어는 하나도 몰라서 읽을 수 없는 논문이 많습니다. 하지만 수학 용어 대신 코드로 이루어진 논문도 많으며 읽는 것도 그리 어렵지 않습니다. 과거 30 년간 엄청난 양의 지식이 논문을 통해 축적되었습니다. 여기서 필요한 지식을 잘 추출하는 능력만 기르면 금세 지식을 선도하는 사람(thought-leader)이 될 수 있습니다.
Prettier는 위에 설명드린 팁의 완벽한 예시입니다. 저는 제가 뭘 하고 싶은지는 알겠는데 구현하는 방법은 전혀 떠올리지 못했습니다. 조사를 좀 해보니 이런 논문을 발견했고, 며칠 뒤 뭘 해야하는지 정확히 파악할 수 있었습니다. 그러고 나니 기본적인 작업은 1 주일만에 끝났습니다. 만약 사전에 조사해보지 않았다면 훨씬 오래 걸렸을겁니다.
혹시 논문을 찾아보고 싶으시다면 Papers We Love 라는 훌륭한 Github 저장소부터 살펴보시길 바랍니다.
큰 프로젝트를 맡아보세요. 익숙지 않은 일에 뛰어드세요.
무언가를 익히는데 직접 경험하는 것 보다 더 나은 수단은 없습니다. 모든 사람들이 뛰어들 수 있진 않지만, 만약 시간이 있다면 큰 프로젝트를 맡아보세요. 굳이 끝까지 마칠 필요는 없습니다. 그냥 컴파일러 작성을 해보는데 머리를 싸매다 보면 몇 주만에 아주 많은 것을 배울 수 있습니다.
저는 솔직히 복잡한 문제를 해결하고 싶은데 하나도 모르는 기분이 싫습니다. (익숙지 않아서) 불편합니다. 문제 해결의 실마리라도 얻으려면 많은 양의 조사를 하고 배워야 한다는 것도 압니다. 하지만 이 모든 과정을 거치고 나면 저는 언제나 더 나은 프로그래머가 됩니다.
새로운 언어를 배우는 것부터 시작해보세요. 지금 여러분이 가지고 있는 버릇을 걷어내고 새로운 관점을 얻는 가장 효과적인 방법입니다. 제가 더 어린 프로그래머였던 시절 제일 잘했던 일은 Scheme 을 배웠던 겁니다. 이 언어는 아주 단순하고 모든 코드를 함수형으로 작성하도록 강제합니다. 그리고 코드의 동작 원리를 익힐 수 있습니다. 제가 Scheme 을 배우며 보낸 몇 년의 시간은 여전히 많은 이자를 내어 주고(큰 도움이 되고) 있습니다. 제가 코드를 보는 방식이 근본적으로 바뀌었습니다. (심지어 저는 Shift Reset LLC 라는 이름의 회사를 설립했는데 여기서 shift/reset은 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 입니다. 이 모든 언어들은 각자 고유한 기능이 있으며 그 기능을 통해 새로운 사고방식을 배우도록 만들어줍니다.
번역 후기
오랜만에 범용적인 주제로 번역을 해 보았습니다. 저를 비롯한 많은 사람들이 가면 증후군(Imposter Syndrome)에 시달리고 계실 테고, 지금 내가 나아가는 길이 맞는지 끊임없이 의심과 불안을 안고 살아간다고 생각합니다. 이 글은 프로그래밍의 아주 깊은 부분을 파고들어보고 기틀을 다지는 방법을 제시합니다.
사실 UI 그리기에 치중된 프론트엔드 개발자의 경우 과연 이 내용이 얼마나 도움이 될까 싶겠지만 점점 복잡해지고 있는 프론트엔드 생태계와 효율적인 자바스크립트 코드 작성의 필요성이 점점 대두되고 있는 와중에 많은 도움이 되리라 생각합니다. 백엔드 개발자분들께는 굳이 말할 필요도 없겠지요.
마침 지금 보고 있는 스칼라 함수형 프로그래밍 책을 다 보고 나면 다음에 볼 책을 HTDP(프로그램 디자인 어떻게 할 것인가)로 정해놓았기 떄문에 본문에 Scheme 이 추천된 것을 보고 더욱 기대하고 있는 중입니다. 또한 이미 컴퓨터 공학을 전공하시고 대학원 교육까지 받으신 분들은 논문 읽기에 익숙하실테지만 이번 번역을 계기로 짧은 논문 위주로 읽어보고 싶어집니다. 영어가 문제군요.
아마 비 영어권 개발자 한정으로 본문의 마지막 팁은 약간 수정되어야 할 것 같습니다. — 아무거나 새로운 프로그래밍 언어 배우기. 영어는 꾸준히 하기. 처럼요.