공부법에 대해

최근 마음을 잡고 개발 공부를 시작한 동생에게

유독 프로그래머라는 직업은 “끊임없이 배운다”는 인식이 강한 것 같습니다. 아무래도 기술의 변화가 빠르고 기술을 익히는 것에 제약이 적기 때문인 것 같습니다. 거대한 실험실이나 공장이 없어도, 인터넷이 연결된 좋은 컴퓨터 한 대만 있으면 어디서든 새로운 기술을 시도해볼 수 있습니다. 덕분에 진입장벽이 낮기도 하지만, 새로운 지식을 익히지 않으면 금방 도태되기도 합니다.

이번 글에서는 제가 프로그래밍을 비롯해 지금까지 공부해 온 방법에 대해 소개해볼까 합니다. 한 분야에 통달한 박사님도, 가르치는 데 일가견이 있는 선생님도 아닌 제가 공부를 논하는 것이 처음에는 오만이 아닐까 생각했습니다. 그러다 ‘누구나 저마다의 방법으로 공부를 하는 데 굳이 잘하는 사람만 공부에 관해 이야기해야 하나?‘는 생각으로 이어졌습니다. 미식가가 아닌 평범한 사람의 식도락기를 보는 것처럼, 평범한 사람의 평범한 공부법 하나 쓱 읽고 가주시면 감사하겠습니다.

동기 부여

공부법을 논하기 이전에, 공부를 하는 이유, 즉 동기가 명확하다면 이미 궤도에 올라탔다고 봐도 무방합니다. 따라서 스스로 어떤 동기 부여에 불타오르는(!) 사람인지 확인하고, 이를 적극 활용할 수 있는 공부법을 이용하는 것이 좋습니다.

제 얘기를 조금 해보자면 저는 이기고 지는 것에 목숨을 거는 사람이었습니다. 그래서 저는 오랫동안 승부욕을 기반으로 한 동기 부여의 효과를 많이 봐왔습니다. 내신과 학점처럼 등수나 점수를 기반으로 한 경쟁 시스템을 좋아했습니다. 한참 알고리즘 공부를 할 때는 문제 풀이 사이트의 등수를 올리는 것에 하루하루 즐거움을 느끼기도 했습니다. 경쟁 시스템이 아닌 공부는 최대한 경쟁의 형태로 만들어서 공부하기도 했습니다. 친구들과 내기를 하고, 온라인 커뮤니티에서 그룹 스터디를 하기도 했습니다.

하지만 돌이켜보면 이 동기 부여로 불타오르는 동안 마음이 아주 힘들었습니다. 1등을 하거나 좋은 성적을 받아도 기쁨은 잠시, 다음 시험이 기다리고 있었으니 다시 긴장할 수밖에 없었고, 실수 때문에 성적이 안 나오면 다음 시험을 볼 때까지 우울했습니다. 게다가 이렇게 시험을 위한 공부는 “얼마나 그 분야를 잘 이해하는가?” 보다는, “시험이라는 시스템에 얼마나 잘 맞는 사람인가?” 에 초점을 맞추게 되다 보니, 효율도 많이 떨어지고 시험 이후에 남는 것이 많이 없다고 느꼈습니다.

졸업하고 하나의 기준으로 전체를 평가하는 시스템에서 벗어나게 됐을 때는 한동안 방황을 했습니다. 다행히 시간이 지나니 오히려 하고 싶은 것을 할 수 있는 자유에 감사하게 됐습니다. 최근에는 스스로 부여한 목표를 달성하는 성취감이 동기 부여가 되고 있습니다. 부족함을 채워가는 것을 동기로 공부하고 있습니다. 예를 들면 지금 블로그도 “글쓰기가 많이 부족한 것 같다”라는 생각에서 시작했고, 일을 하다 보면 아키텍처 중에 일부가 잘 이해가 안 되지만 핵심이 아니라 그냥 넘어가는 것들이 종종 있는데, “다시 만났을 때는 꼭 이해하고 써보자”라는 생각에서 공부하기도 합니다.

성취의 단위를 작게

개발 공부를 하다 보면, 처음에는 직접 작성한 코드가 작동하는 것만 봐도 즐겁지만, 어느 순간이 되면 야망보다 보잘것없는 능력이 밉게 느껴집니다. “내가 만들고 싶은 서비스는 유튜브, 인스타그램 같은 서비스인데, 이렇게 공부를 한다고 만들 수 있을까?”와 같은 생각이 들기도 합니다. 걸어온 길이 꽤 된 것 같은데 아직 모르는 것이 산더미 같게 느껴지기도 합니다. 정말 그럴까요?

수학을 예로 들어 보겠습니다. 처음부터 미분을 하는 사람은 없습니다. 미분 이전에 극한을 알아야 하고, 극한 이전에 함수를 알아야 하고, 함수 이전에 집합을 알아야 하고… 이렇게 쭉 가다 보면 결국 미분을 하기 위해서는 숫자를 세는 법부터 알아야 한다는 결론에 도달합니다. 이렇듯 오늘날 우리가 얻은 지식 대부분은 항상 작은 것에서부터 시작했습니다. 그리고 그 작은 지식 하나하나 모두 의미 있는 지식입니다.

따라서 저는 작은 성취를 여러 번 반복하라는 말씀을 드리고 싶습니다. Agile Principles 12개 중 3번은 “Deliver working software frequently” 입니다. 엔지니어들은 소프트웨어를 더 자주 출시하며 유저에게 가치를 제공하고, 피드백을 받아 가며, 변화하는 환경에도 쉽게 적응할 수 있습니다. 그리고 계획에 대한 방향을 다시 한번 확인할 수 있습니다. 이는 가치를 주고, 피드백을 받는 대상이 자신이라는 점을 제외하면 공부에도 똑같이 적용할 수 있습니다. 작은 단위의 기능, 쉬운 문제라도 하나씩 구현하고 해결하다 보면, 시야가 넓어지면서 새로운 자극을 받고 다음 단계에 도전할 수 있습니다. 반대로 처음부터 너무 높은 목표를 설정하면 공부가 늘어지고, 또 어려워지게 됩니다. 개발에서는 알고리즘 공부가 문제를 푸는 것과 성취를 서로 쉽게 짝지을 수 있다는 점에서 이 방법을 자연스럽게 사용하게 되는 좋은 예시가 되겠습니다.

회사에 처음 들어와 수습 기간 중 쿠버네티스를 공부할 때, 쿠버네티스 API를 활용해 Pod의 상태를 모니터링하는 아주 간단한 프로그램을 만들었던 기억이 납니다. 제가 Minikube를 설치하고 일주일도 안됐었던 때였기 때문에, 실제 Production에서 사용할 수준은 커녕 어디가서 “했다”고 얘기하기도 민망한 수준의 작품이었습니다. 하지만 그런 경험들이 하나 둘 쌓이면서, 현재는 (여전히 부족하지만) 그 당시보다 많이 성장했다는 것을 체감하고 있습니다. 만약 그 때 무조건 성취의 크기에 집착해서 “대단한 걸 만들어보겠어!”라고 생각하고 계속 문서만 하염없이 들여다보고 있었다면, 여전히 제자리 걸음을 하고 있었을 것 같습니다.

만약 그 동안 막막했던 공부가 있다면, 오늘 딱 한 페이지만, 10분만이라도 들여다보는 건 어떨까요?

모방과 재생산

누구나 잘 알고 있고, 이미 익히 사용하고 있었을 학습 방법의 하나가 모방입니다. 우리는 어머니의 소리를 따라 하며 말을 배우는 것을 시작으로, 고등학생 시절에는 선생님의 풀이를 따라 하고, 개발하는 오늘날에도 수많은 인터넷 선지자들의 코드를 따라 합니다. 저 역시 전혀 모르는 것을 시작하는 방법으로 모방만 한 것이 없다고 생각합니다. 또 하나의 방법은 이렇게 모방으로 익힌 방법들을 응용하는 재생산입니다. 온전히 나로부터 시작된 것은 아니지만, 엄연히 내 주관이 담겨있는 결과물이라는 점에서 이러한 표현을 사용했습니다. 예를 들면 알던 문제와 비슷한 문제를 응용해서 푼다든지, 다른 프로그램에서 사용했던 코드를 잘 변용하는 과정을 말합니다.

저에게 있어 모방과 재생산의 경계는 “왜?”라는 질문입니다. 모방은 무조건적인 수용입니다. 이를테면 Stack Overflow의 코드를 그대로 가져다 붙이는 것이 있습니다. 그 자체로 기능을 원활하게 하고 본인이 만족한다면 이는 모방의 결과입니다. 하지만 코드를 찬찬히 살펴보며 “왜?”라는 질문을 던져 고친 코드를 사용한다면, 혹은 비슷한 상황에서 자기가 뚜렷한 이유를 가지고 모방했던 코드를 재현한다면 이는 재생산입니다. 어쩌면 그 코드를 그대로 사용할 수도 있지만, 만약 모든 코드에 자기 스스로 이유를 댈 수 있다면 같은 코드라도 재생산이라고 볼 것 같습니다.

제 공부는 대부분 이 모방과 재생산의 반복입니다. 예를 들어, Django를 시작했다고 합시다. 우선 주어진 가이드를 찬찬히 읽고 커맨드와 코드를 따라 하며 차근차근 하나의 앱을 구현하는 것을 목표로 합니다. 처음에는 잘 모르는 것들이 많지만, 이는 그때그때 확인할 수도 있고, 전체적인 그림을 한 번 훑고 다시 익힐 수도 있습니다. 그다음에는 지금까지 구현한 것들을 가이드에 의존하지 않고 다시 구현하는 것을 목표로 합니다. 이 과정에서 스스로 무엇을 모르는지 확인할 수 있습니다. 마지막으로는 이와 구조적으로 유사한, 다른 목적을 가진 앱을 만들어 봅니다. 이번에 배운 것뿐 아니라 기존에 본인이 알고 있던 지식을 가미하면 더 좋습니다. 이렇게 하면 모방에서 시작해 재생산으로 끝나는 하나의 학습이 끝납니다.

물론 이 둘 사이에서 적절한 균형을 잡기는 쉽지 않습니다. 스스로 풀 수 있는 문제임에도 답지를 본다든가, 생각을 좀 더 하면 구현할 수 있는 코드인데도 검색창에 먼저 손이 올라가는 시간이 많아진다면, 어느 순간 생각하는 힘이 줄어들게 될 것입니다. 반대로 너무 재생산에 집착하게 되어, 공부가 늘어지고 생산성이 떨어지는 것 역시 지양할 필요가 있습니다. 시기별로, 난이도별로 자신의 수준을 되돌아보고 적절한 방법을 사용하도록 합시다.

마치며

주저리주저리 글이 길어졌지만, 결국 저마다 맞는 공부법이 있다고 생각합니다. 이 글을 읽으신 여러분께서도 “이 사람은 이렇구나” 정도로 생각해보시고, 자신의 공부법에 대해 한번 생각해보시는 시간을 가지시면 좋겠습니다.

그 외

• 프로그래머에게 “랭킹”이 있다면 어떤 기준이 있을까요? 알고리즘이라면 Codeforces, 데이터 사이언스라면 Kaggle, 심지어 Github도 Stars를 기준으로 Gitstar Ranking 같은 사이트가 있지만, 보편적인 순위를 정하긴 아직까진 어려워 보입니다.
• 만약 프로그래밍, 나아가 컴퓨터가 아직 낯선 분이라면, 개인적으로 Interactive한 Web IDE가 있는 교육 플랫폼에서 학습을 시작하는 것을 추천합니다. IDE, 언어 설치와 같은 “개발 환경의 설정”도 아주 중요한 프로그래머의 덕목이긴 하지만, 시작도 못하고 한참 개발 도구와 씨름하다가 지치면 안되니까요. 개인적으로는 freeCodeCamp, DataCamp가 좋았습니다.