훌륭한 프로그래머가 되기 위해: 주도적 학습

개요

저는 현재 게임 회사에서 클라이언트 프로그래머로 일하고 있습니다.

처음 게임 개발에 뛰어든 이후로 시간은 흘러 흘러 어느덧 꽤 나이 든 프로그래머가 되었습니다.

나이가 들고 경력이 쌓였지만 훌륭한 프로그래머인가 하면 여전히 그렇진 않은 것 같습니다.

 

함께 자라기: 애자일로 가는 길이란 책을 보면 이런 내용이 있습니다.

경력이 10년인 개발자가 2년인 개발자보다 더 우수하지 않았다. 경력과 생산성은 아무 상관관계가 없었다.
<톰 드마르코와 티모시 리스터의 연구>
- p.22

(이 책의 내용이 궁금하시다면 요약 및 발췌해놓은 내용이 있으니 여기서 한번 읽어보시기 바랍니다.)

 

이 글은 훌륭한 프로그래머가 되는 방법에 대한 내용이 아닙니다. 만약 그런 방법을 알고 있다면 저도 이미 훌륭한 프로그래머가 되어 있었겠죠.

대신 제가 생각하기에 어떻게 하면 훌륭한 프로그래머에 한발짝 더 가까이 갈 수 있을지에 대해 조금씩 써보려 합니다.

 

조금씩 노력하다보면 어느샌가 훌륭한 프로그래머가 되어 있을지도 모르니까요. 

 

만약 제가 미처 알지 못한 훌륭한 프로그래머의 능력이나 자질, 태도가 있다면 알려주세요!

 

---

훌륭한 프로그래머: 끊임없는 주도적 학습

사람마다 훌륭한 프로그래머의 덕목에 대한 우선순위가 다를 수 있습니다.

이번엔 그 중에서도 지식과 관련된 덕목에 대해 이야기해보고자 합니다.

 

그 어떤 프로그래머도 모든 지식과 노하우를 갖춘 채로 태어나진 않았겠죠.

훌륭한 프로그래머도 처음에는 모르는 것이 많았을 겁니다.

그렇다면 무엇이 훌륭한 프로그래머로 하여금 많은 지식을 익히게 했을까요?

바로 끊임없이 주도적으로 학습하는 태도라고 생각합니다.

 

자신이 처한 상황과 주어진 일에서 스스로 배울 점을 찾아내고 또 배워나가는 것, 그것이 바로 주도적으로 학습하는 태도입니다.

 

그럼 일상에서 어떻게 하면 주도적으로 학습을 할 수 있을까요?

아래에 평소 제가 학습을 하는 방법들을 정리해 봤습니다.

1. 코드 읽기

먼저 함께 일하는 다른 동료의 코드를 읽습니다. 

동료의 코드를 읽으면 새로운 코딩 방식을 알게 될 수도 있고, 컨벤션에 정의되지 않은 동료의 코딩 스타일을 알 수도 있습니다.

특히 컨벤션으로 정의하기 어려운 설계 영역의 경우 상황에 따른 많은 케이스를 볼 수 있어 꽤나 도움이 되는 편입니다.

코딩을 하면서 항상 동일한 문제를 만나는 경우는 거의 없습니다. 비슷해 보여도 제가 해결한 상황과 동료가 처한 상황은 조금씩 다르게 마련입니다. 

문제가 다르기 때문에 그에 따른 설계나 해답에 항상 정답이 있진 않습니다. 

만약 비슷한 상황에서 나와 동료의 해결 방식이 서로 다르다면 아직 제가 눈치채지 못한 이유와 의도가 숨어 있을 수 있습니다.

동료의 코드를 읽음으로써 그 의도를 파악하고 그에 따른 해결 방법을 간접적으로 체험할 수 있습니다.

 

두 번째로는 오픈 소스 코드를 읽습니다.

오픈 소스 프로젝트의 코드는 어느 정도 검증된 양질의 코드를 볼 수 있습니다.

물론 기술적으로 이해하기 어려운 로직도 많습니다만 굳이 모든 로직을 이해하지 않아도 오픈 소스 프로젝트에서 많은 것을 배울 수 있습니다.

예를 들어 해당 도메인에서의 용어들을 배울 수도 있고, 대규모 프로젝트에서 호율적으로 프로젝트 구조를 관리하는 방법을 배울 수도 있겠죠.

 

세 번째로는 과거의 내가 짠 코드를 읽습니다.

사실 과거의 내가 짠 코드는 자기반성이자 훈련의 목적으로 읽는 경우가 많습니다.

지금의 나는 과거의 나보다 더 많은 지식을 알고 있고 프로그래밍에 더 숙련되어 있을 수 있습니다.

과거의 내가 저지른 실수를 지금의 나라면 좀 더 우아하고 자연스럽게 해결할 수 있겠죠.

뿐만 아니라 새롭게 공부한 개발 방법론을 적용해 볼 수도 있을 겁니다.

다른 사람의 코드를 훈련 용도로 활용할 수도 있겠죠. 하지만 그러기 위해선 적어도 코딩의 의도와 결과를 완벽히 파악하고 있어야 합니다. 한 발짝 더 나아가 다른 사람의 결과물에 대해서 충분한 예의를 갖춰야 할 경우도 있겠죠.

하지만 내가 만든 쓰레기라면 아무런 양심의 가책없이 치울 수 있습니다.

2. 책

전 주기적으로 yes24에서 프로그래밍 관련 신간을 확인하는 편입니다.

책은 많은 베타 리더들과 출판사의 전문가들이 어느 정도 검수를 한 결과물이기 때문에 좀 더 내용을 신뢰할 수 있습니다.

물론 자주 버전 업데이트가 일어나는 기술에 대해서라면 책보다는 해당 기술의 문서를 읽는 편이 더 좋습니다.

예를 들어 제가 관심을 갖고 있는 Flutter의 경우 정말 짧은 시간 안에 메이저 버전 업데이트가 2회나 있었습니다.

 

그러다 보니 주로 프로그래밍 방법론이나 수학, 기술적 이론에 관련된 서적을 구매하는 편입니다.

가끔 프로그래밍 언어 서적도 구입해 보곤 하는데, 그때는 책에 포함된 예제를 기준으로 구매를 결정합니다.

최근에는 Rust 언어를 공부하고 있는데 Rust 공식 문서가 이미 매우 충실하게 잘 만들어져 있습니다만 그래도 더 다양한 예제를 보고 싶어서 인사이트에서 발간한 한 줄 한 줄 짜면서 익히는 러스트 프로그래밍 ebook을 사서 보는 중입니다.

 

출퇴근 시간이 오래 걸리기 때문에 대중교통을 타고 다니면서 책을 보는 경우가 많은데 그럴 때에는 주로 프로그래밍 방법론에 대한 책을 읽는 편입니다.

이런 방법론들을 현업에, 특히 게임 개발에 온전히 적용하기란 정말 어렵습니다.

하지만 여러 방법들이 제안된 배경을 이해하고 문제를 해결하기 위한 접근법과 의도를 파악하는 것이 프로그래밍에 관한 사고를 확장하는데 많은 도움이 됩니다.

굳이 말하자면 프로그래머의 인문학이라고나 할까요.

 

프로그래밍 서적은 yes24에서 ebook으로 구매하는 편입니다. 

발간한 지 시간이 좀 지난 책을 알라딘 중고서점에서 구매해 pdf로 스캔해서 들고 다니고요. 

참고로 개인 용도의 스캔은 불법은 아닌 걸로 알고 있습니다...

 

Manning 출판사도 종종 이용하는데 한번 구매하면 책들을 pdf, epub 등의 포맷으로 무제한 다운로드하여서 볼 수 있습니다. 굳이 단점이라면 모두 영어 서적이라는 겁니다.

그러나 LiveBook은 웹으로 바로 볼 수 있는데 이때 구글 번역을 돌리면 깔끔하게 한국어로 볼 수도 있어서 꽤 편리합니다.

 

기술 용어를 영어로 볼 수 있고, 나름 영어 공부도 되니 Manning에서 직접 책을 사서 보는 것도 괜찮을 것 같습니다.

물론 어떤 책을 판매하느냐도 중요하죠. 

최근 개인적으로 재밌게 봤던 쏙쏙 들어오는 함수형 코딩이란 책이 있는데 내용이 좋아서 팀 동료들에게도 추천했었습니다. 알고 보니 Manning에서 판매한 Grokking Simplicity라는 책의 번역판이었습니다.

최근에 구매한 러스트 프로그래밍 책도 Manning에서 출판한 Rust in Action을 번역한 것이구요. 

좋은 책들이 많으니 한번 뒤져 보시는 걸 추천드립니다.

 

다만 MEAP라고 해서 책을 Early Access로 판매하는 경우가 있는데 이 때 책이 출판되지 않고 취소되는 경우가 종종 생기기도 합니다.

최근에 게임 디자인 패턴에 관한 책을 MEAP로 구매했었는데 한동안 챕터 업데이트가 없더니 결국 출판이 불발되었더군요. 

이런 경우 환불을 받을 수 있으니 걱정할 필요없습니다. 다만 자동 환불이 아니라 원클릭으로 환불 신청을 해야 합니다.

3. 블로그

보통 책은 특정 주제를 좀 더 깊이 있게 확인하고 싶을 때 구입해서 봅니다.

반면 최근 프로그래밍 트렌드를 확인하거나 얕지만 넓게 학습 키워드를 얻고 싶을 때는 블로그를 이용하는 편입니다.

 

보통 출근할 때 Medium 뉴스레터를 체크합니다. 관심 분야를 설정해두면 자동으로 해당 분야의 최근 포스트를 요약해서 보내주니 편리합니다.

다른 회사의 개발 블로그를 즐겨찾기 해두는 것도 좋은 방법입니다. 특히나 같은 업종의 회사라면 견문을 넓히기에 더 도움이 됩니다. 

저는 우아한 형제들 기술 블로그, 데브 시스터즈 기술 블로그, 라인 엔지니어랑 기술 블로그, 카카오 테크 블로그를 즐겨찾기 해두고 종종 들어가 보곤 합니다.

 

혹은 유명한 네임드 개발자의 블로그를 구독하는 것도 좋습니다. 개인적으로는 조대협님의 블로그를 종종 들어가 봅니다.

 

레딧 토픽을 구독해두는 것도 도움이 됩니다. 다만 잡담이 많은 편이라 적당히 걸러서 봐야 합니다.

블라인드의 게임 라운지와 IT 라운지에서도 은근히 좋은 정보들이 올라오곤 합니다. 

페이스북에서 월간 개발자스럽다 같은 채널을 찾아서 구독해두면 트렌드 파악에 도움이 됩니다. 생활 코딩 같은 그룹에서도 가끔 좋은 정보를 얻을 수 있습니다.

4. 동료와의 대화

1번 코드 읽기에서 동료의 코드를 읽는 게 학습에 도움이 된다고 했었습니다.

그런데 동료의 코드를 이해하는 가장 좋은 방법은 바로 동료에게 직접 들어보는 것입니다.

 

동료와 이야기하다 보면 단지 코딩 스킬에 국한하지 않고 배울 수 있는 것이 많이 있습니다.

세 사람이 길을 가면 그중에 반드시 내 스승이 있기 마련이다.
착한 사람에게선 그 선함을 배우고, 
악한 사람에게선 그를 보고 자신의 잘못을 반성할 수 있다.
- 공자

 

모두 같은 프로그래머지만 사람들마다 특출한 장점이 서로 다르게 있기 마련입니다.

어떤 사람은 대화 스킬이 좋아서 커뮤니케이션을 잘할 수 있습니다.

어떤 사람은 팀의 분위기를 훈훈하게 이끌어 갈 수 있습니다.

어떤 사람은 꼼꼼해서 문서화를 잘 할 수도 있습니다.

어떤 사람은 직관이 뛰어나서 설계 아이디어가 뛰어날 수 있습니다.

 

실제로 신작 게임을 만들 때 주요 시스템의 설계 회의를 모든 프로그래머들이 모여서 함께 진행했었는데 

주니어급 프로그래머의 번뜩이는 아이디어 덕분에 성공적으로 결과를 냈던 경험이 있었습니다.

 

만약 설계 회의 때만이 아니라 평소에도 프로그래밍에 대해 더 많이 이야기하고 공유할 수 있는 분위기가 되면 서로가 더 많은 것을 가르치고 배울 수 있지 않을까 생각합니다.

 

다만 그전에 네트워킹을 잘 못하는 제 약점부터 고쳐야겠지만요...

5. 검색

마지막으로 검색을 잘하는 것이 중요합니다.

동료도 잘 모르는 문제가 있다면? 블로그나 책에도 나오지 않은 문제를 해결해야 한다면 어떻게 해야 할까요?

블로그든 책이든 누군가가 생산해 낸 컨텐츠입니다. 하지만 내가 문제에 대한 해답을 만들어야 하는 순간이 반드시 있습니다.

 

처음부터 해답을 머릿속에 가지고 있다면 좋을 텐데 그렇지 않다면 스스로 실험해서 검증을 하거나 검색을 통해 기본적인 필요 지식을 얻어야 합니다.

 

스스로 가설을 세우고 실험을 계획하고 검증하는 건 쉽지 않은 일이니 일단 제외하고... 

검색을 잘하기 위해 필요한 게 무엇일까요?

 

먼저 자신이 속한 영역을 주도하는 언어를 잘 사용해야 합니다.

K 팝이나 K 드라마에 대한 가장 깊고 새로운 지식을 알고 싶다면 한국어로 검색을 해야 합니다.

마찬가지로 프로그래밍에 대한 지식을 알고 싶다면 영어로 검색을 해야 합니다.

 

예전 인턴 프로그래머를 교육하는 업무를 맡은 적이 있었습니다.

그 인턴은 주로 동료와 대화하는 방식으로 학습하곤 했습니다. 기초적인 것도 다 물어봤다는 뜻입니다.

시간이 넉넉하거나, 같이 의논해볼 만한 주제라면 직접 가르쳐 주기도 했지만 기초적인 주제라면 키워드를 던져주고 과제 삼아 검색해오도록 시켰습니다.

 

그런데 한국어로 네이버에서 검색을 하더군요...

물론 네이버에서 한국어로 검색을 해도 양질의 자료를 얻을 수는 있습니다만, 그래도 한계가 있기 마련입니다. 

특히 네이버는 자사의 생태계에 있는 자료를 우선 노출하는 경향이 있어서 다양한 채널의 자료가 필요할 때 사용하기엔 좋지 않은 검색 엔진입니다. 

 

언어를 익혔다면 어휘를 익혀야 합니다.

자신이 속한 도메인에서 공통적으로 사용하는 용어들을 잘 파악해야 합니다.

기술적 용어는 그 안에 많은 내용은 포함하고 있습니다. 긴 기술적인 내용을 템플릿 메서드 패턴이라는 어휘로 축약해서 나타낼 수 있다면 그만큼 더 많은 내용을 검색할 수 있을 겁니다.

만약 템플릿 메서드 패턴이라는 용어를 모른다면 템플릿 메서드 패턴을 설명하는 길고 긴 검색어를 타이핑해야만 하겠죠. 

 

언어와 어휘를 익혔다면 이제 글쓰기를 할 차례입니다.

좋은 해답을 얻으려면 좋은 질문을 해야 합니다. 모르는 것이 무엇이고 알아야 할 것이 무엇인지를 명확히 파악하고 그것을 한 줄의 글로 표현해낼 수 있어야 합니다.

 

개인적으로 프로그래밍은 일종의 글쓰기라고 생각합니다.

물론 프로그래밍이 공학의 영역에 속해 있고 공학적인 표현을 수학으로 검증하고 측정할 수 있으나 결국 프로그래밍의 본질은 기계에게 할 일을 논리적으로 설명하는 것입니다.

그리고 논리는 전통적으로 철학의 영역이었죠. 어떻게 보면 프로그래밍, 컴퓨터 과학은 공학과 논리, 인문학의 접점에 있는지도 모르겠습니다.

 

그래서 저는 프로그래머들은 글을 잘 쓰고, 말을 잘할 수 있어야 한다고 생각합니다. 적어도 논리적으로 생각을 표현할 줄 알아야겠죠. 

실제로 제가 만난 훌륭한 프로그래머들은 대부분 정말 말도 잘하고 글도 잘 쓰시더군요. 

말하는 걸 즐기지 않던 분들도 한번 입을 열면 어찌나 말을 잘하시는지...

 

마지막으로 검색을 통해 결과를 얻었다고 해서 절대 만족해선 안됩니다.

검색 결과로 얻은 지식을 검증하고 실험하고 자신의 상황에 맞춰 개선해 나가야만 합니다.

그러다 보면 그 지식이 자신의 상황에 잘 들어맞는지 알 수 있게 됩니다.

가끔 다른 방법을 찾아야만 하는 경우가 생기기도 하는데 그럴 때는 방금 얻은 새로운 지식을 더해서 더 나은 결과를 찾을 때까지 다시 검색해야 합니다.

바로 끈기가 필요하죠.

맺음말

석사 과정을 밟고 있을 때 지도교수님께서 해주신 말씀이 있습니다.

학사는 기초를 세우는 것이고 석사는 스스로 공부하는 법과 태도를 배우는 것이다. 그리고 박사는 새로운 지식을 발견하고 만들어내는 것이다.

 

스스로 공부하는 법과 태도를 체득하는데 2년이란 시간이나 사용한다는 것은 주도적인 학습이 그만큼 중요하다는 반증일 것입니다.

 

어떤 분야든 마찬가지일 것입니다.

자신이 속한 분야에서 훌륭해지려면 스스로, 주도적으로 학습하고 훈련하며 개선해나가야만 하지 않을까요.

 

저도 아직 부족함을 많이 느낍니다. 그런 만큼 지금도, 그리고 앞으로도 계속해서 나아지려 노력하고자 합니다.