점 잇기 : 개념/이론 학습을 시작하는 주니어 개발자에게 전하고 싶은 말

안녕하세요, 회사에서는 백엔드 개발을 하며, F-Lab에서 BE 멘토로 활동하고 있는 Scott입니다.
F-Lab에서 멘토로 활동을 시작한 지가 어느덧 3년 차가 다 되어갑니다. 멘토로 활동하는 일은 누군가를 가르치는 것과 동시에 가장 누군가로부터 가장 잘 배우는 기회임을 느끼고 있습니다. 많은 멘티분들을 지도하며 주니어 시절 제가 저질렀던 실수와 시행착오들, 그리고 그것을 극복하는 것에 도움이 됐을 것 같은 노하우들을 스스로 배우고 있는데요, 오늘은 그중에서도 “프로그래밍/CS 개념 학습에 임하는 주니어 개발자분들" 께 꼭 전하고픈 말씀들을 글로 풀어보고자 합니다.

가까운 곳에서 출발하세요

평소 공부하지 않았던 주제를 학습하는 것은 힘든 일입니다. 저도 개발자 취업을 준비하던 시기엔 그랬습니다. 더구나 한 번도 전문적인 컴퓨터 공학 교육을 받아본 적이 없는 저로서는 무슨 개념을 공부하기 위해 어떤 책을 봐야 하는지, 누구의 인터넷 강의를 들어야 하는지도 전혀 몰랐습니다. 정말 아무것도 몰랐기 때문에 무작정 자격증 시험 수험서부터 사서 처음부터 끝까지 읽는 실수를 범하기도 했습니다.

이런 학습법이 잘못됐다는 것을 알게 된 것은, 책을 3회독한 후에도 모의 면접 질문에 거의 대답하지 못하는 제 자신을 발견한 후였습니다. 예를 들어, 저는 다음과 같은 질문에 제대로 된 답변을 거의 하지 못했습니다.

• java.util.ArrayList의 .get() 과 .add() 가 갖는 시간 복잡도를 설명해 보세요.
• java.util.HashMap의 조회 성능을 결정짓는 요소는 무엇일까요?
• Java에서 synchronized가 동시성을 해결하는 방법은?

Java BE 개발자라면 사실 꽤 잘 대답해야 하는 질문들임에도 불구하고, 더구나 학습 시간을 많이 들여 책을 몇 번이고 읽은 후인데도, 제대로 된 답변을 내놓지 못하는 것은 꽤 큰 문제였습니다.

문제를 해결하기 위해 “가까운 곳에서부터 다시 배우자”는 생각으로 저는 Java에서 자료구조와 알고리즘을 가장 쉽게 접할 수 있는 Java Collection Framework의 소스 코드들을 살펴보는 것으로 학습을 다시 시작했고, 이 과정에서 많은 것들을 새로 학습할 수 있었습니다.
 

내가 가장 즐겨 사용하던 클래스들의 소스 코드를 열어보고, 내가 아무 생각 없이 사용하던 메소드들이 실제로 어떻게 구현되어 있는지를 확인하는 과정은 정말 즐거웠고, 많은 배움이 일어났습니다. 책을 읽으며 생소한 개념과 용어들을 달달 외워야 하는 지식인 줄 알았는데, 이미 친숙한 클래스와 메소드들을 뜯어보며 공부하는 건 몹시 흥미로웠죠. 그리고 놀랍게도…. 이 과정을 몇 주간 진행하니, 그동안 쩔쩔매던 모의 면접 문제들에도 양질의 답변을 술술 해낼 수 있게 되었습니다. 내가 이미 알고 있는 것들에서부터 생소한 개념으로 지식을 확장시켜나가는 것이 언제나 효율적인 접근 방법이라는 것을 깨달은 순간이었죠.

생소한 개념들을 학습하며 머리가 아픈 분들이라면, 어떻게든 지금 알고 있는 것에서부터 연결 고리를 만들어낼 수 있는 지점을 찾아보시기를 강력하게 권합니다. 머릿속 연결 고리들을 강화하며 배운 지식은 배움의 과정 자체가 즐겁기도 하지만, 배운 후에도 쉽게 잊혀지지 않습니다. 무엇보다도 단순 암기를 통해 머리에 쑤셔 넣은 지식은 많은 경우에 멀리 떨어진 점들로 존재하며 면접과 실무에 도움을 주지 못하지만, 이렇게 단단한 고리의 형태로 학습한 지식들은 서로가 항상 유기적으로 연결되며 여러분의 실력을 키워주고, 여러분을 좋은 회사로 데려다줄 것이고, 무엇보다 학습과 성장의 기쁨을 느끼게 해 줄 것입니다.
 

스스로를 가르치기 : 기술 블로그, 손 코딩, 화이트보드

우리가 블로그에 기술 아티클을 발행하면, 누가 가장 먼저 들어와서 읽을까요? 검색엔진의 수집 봇일 수도 있고, 디버깅에 여념이 없는 동료 개발자일 수도 있고, 그냥 이런 글들 읽기를 좋아하는 누군가일 수도 있겠습니다만, 저는 “내 글은 내가 가장 먼저 읽는다"라고 생각합니다. 글의 종류를 막론하고, 그 글을 처음 읽는 사람은 필자 자신입니다.

흔히 “취업 치트키"라고 일컬어지는 기술 블로그 정리가 중요한 이유가 바로 여기에 있습니다. 기술 블로그 활동을 통해 내 이력서와 포트폴리오를 돋보이게 만드는 것도 중요하지만, 내가 가장 어렵게 배운 기술, 삽질하며 배운 API 사용법 등을 담은 나의 기술 블로그 포스팅은 그 누구보다도 가까운 미래의 나에게 가장 많은 것을 가르쳐 줄 것입니다.

어쩌면 좋은 개발자가 되는 과정은 “스스로를 잘 가르치는 방법을 알아가는 과정" 이 아닐까 생각합니다. 커리어 내내 쏟아지는 신기술과 지식에 맞서(?) 스스로 중심을 잡고, 내가 알아야 할 것들을 내가 가장 좋아하는 방법으로 가르쳐야 하는 여정입니다. 이 여정을 위한 기록을 남기고 학습 자료를 만드는 것을 중요한 작업으로 여겨야 합니다.

이런 작업들 중에서도 기술 블로그 활동과 손 코딩, 그리고 화이트보드 강의는 누구나 즐겁게 진행할 수 있는 일들이라고 생각되어 소제목을 이렇게 정해 봤습니다. 개념/이론 학습을 위해 이런 활동들을 진행할 때 주의해야 할 점을 정리해 보겠습니다.
 

기술 블로그

기술 블로그 집필은 누구나 쉽게 시작할 수 있고 부담 없이 이어나갈 수 있는 활동입니다. 그러나 주니어 개발자분들, 특히 개발자로서 첫 취업을 준비하는 분들이 흔히 저지르는 실수들이 있어, 아래의 원칙을 지켜보시면 어떨까 합니다.

• 절대로 누군가의 글을 복사/붙여넣기 하지 않는다. 글 전체를 베껴오는 것은 물론이고, 일부, 심지어 몇 개의 문장을 베껴오는 것도 자제하시기 바랍니다. 누군가의 글을 읽고 뭔가를 배웠다면, 자신만의 언어와 표현으로 이것을 다시 표현할 줄 알아야 합니다. 무단 전재는 그 자체로 범죄이기도 하지만 무엇보다 그런 식으로 품을 들여봐야 내 실력이 늘지 않습니다.

 

• 글의 구성과 데코레이션, 삽화 등에 지나친 시간을 투입하지 않는다. 내 글을 가장 열렬히 읽을 독자는 내 자신입니다. 누군가에게 잘 보일 글을 쓰는 건 무의미합니다. 내 스스로가 잘 읽고 이해할 수준의 글을 써나가는 것에 집중해 보시기 바랍니다. 잘 읽히는 글을 쓰는 것은 파워 블로거가 된 후에 고민해도 늦지 않습니다.

 

• “일일 일 포스팅" 등의 정량적 지표에 신경 쓰지 않는다. 냉정하게 생각해 봅시다. 정말 하루에 하나씩 배우실 수 있나요? 하루에 글 하나씩은 남겨야한다는 강박에 억지로 쥐어짠 아티클에 좋은 내용을 싣기란 거의 불가능에 가깝습니다. 일주일에 한 건, 보름에 한 꼭지여도 상관없으니 내 머릿속에 강렬하게 남은 지식을 글로 풀어봅시다. 물론 간단한 일상 포스팅이나 조금이라도 성장한 것을 개조식으로 정리하는 글 정도는 매일 하나씩 남기셔도 괜찮습니다.

손 코딩

플랫폼 기반 PS 형식의 알고리즘 테스트가 보편화되면서 손코딩 연습이 무의미해졌다고 생각하는 분들도 많은 것 같지만, 저는 아래와 같은 이유로 손 코딩이 여전히 매력적인 학습법이라고 생각합니다.

• 자동완성이 없다. 여러 가지 도구로 자동완성을 사용할 수 있는 PS 연습과 달리(심지어 요즘은 코딩 테스트 플랫폼들도 꽤 완성도 높은 자동완성을 제공하죠) 연필과 공책은 코드를 완성시켜주지 않습니다. 자동완성 없이 로직을 짜고 코드를 완성시켜보며 내가 습관적으로 사용하던 개념들에 대한 이해를 강화할 수 있습니다.

 

• 고민할 시간을 만든다. 어려운 문제에 직면했을 때 빠르게 레퍼런스를 찾을 수 있는 코딩과는 다르게 손 코딩에서는 스스로의 힘으로 고민할 기회와 시간을 만들 수 있습니다. 이 과정에서 머릿속을 스쳐가거나 떠오르는 개념들은 강력한 연결 고리를 형성하며, 평생 머리에 남을 지식을 형성시켜 줍니다.

 

• 뿌듯하다. A4용지 몇 장을 가득 채우는 손코딩은 그 자체가 좋은 공부 흔적으로 남아 성취감을 가져다줍니다. 깃허브에 심은 잔디와 빼곡한 커밋 로그와는 색다른 형태의 기쁨을 줄 것입니다.

여러모로 장점이 많은 손코딩이지만, 진행할 땐 아래 주의사항은 꼭 참고해 보셨으면 좋겠습니다.

• 한 문제로 고민할 최대 시간을 정한다. 이것은 제가 멘티분들이 PS 준비를 시작하실 때도 늘 강조하는 것인데요, 우리의 시간은 유한하고 할 일은 많기 때문에, 하나의 문제 혹은 과제에 투여할 시간의 상한을 꼭 정해야 합니다. 예를 들어, 나는 한 문제에 30분 이상은 고민하지 않기로 결정했다면, 30분이 지나도 풀리지 않는 문제와 씨름을 이어나가지 말고 빨리 인터넷을 켜서 레퍼런스를 보거나 모범 답안을 가져와야 합니다. 그리고 그렇게 가져온 모범 답안을 종이에 손글씨로 그대로 옮겨 적어 보세요.

 

• 예쁜 흔적을 남기려 노력하지 않는다. 기술 블로그 코너에서 정리한 것과 비슷한 맥락입니다. 내 자신, 단 한사람을 만족시킬 정도의 흔적이면 충분합니다. 누군가에게 예뻐 보일만한 내용을 남기려고 노력하지 마세요. 오히려 필요한 것은 남겨진 종이 그 자체로 치열한 전투(?) 의 고단함이 느껴지는, 지우개똥과 연필 손때가 가득 남은 A4용지 묶음일 수도 있습니다.

화이트보드

많은 멘티분들이 개념에 대한 정확한 이해와 매력적인 경험을 갖고도 기술 면접에서 고전하시는 것을 봐 왔습니다. 학습 방법의 문제인 경우도 있고, 학습 주제가 잘못 설정되어 있던 경우들도 있었습니다만, “누군가에게 내가 아는 것들을 설명하는 경험" 이 부족한 멘티분들을 많이 볼 수 있었는데요, 이런 경우라면 화이트보드를 사용해 개념을 스스로 설명하는 학습법이 큰 도움이 될 수 있습니다. 아래 사항들을 유념해 화이트보드 학습을 진행해 보시면 큰 도움이 되리라 생각합니다.
 

• 당연히 알고 있을 거라고 생각하는 개념을 선정한다. 우리는 많은 것들을 “안다" 고 스스로 믿지만, 착각인 경우가 무척 많습니다. 예를 들어 Java 개발자라면 GC와 JVM의 메모리 구조에 대해 잘 알고 있다고 스스로 생각하고 있을 수 있지만, 막상 누군가에게 이를 설명해 보라고 하면 입도 벙긋하지 못하는 경우가 자주 일어납니다. 화이트보드 학습법은 이런 개념들을 접근할 때에 무척 유용합니다.

 

• 내 앞에 초등학생이 앉아있다고 생각한다. 고수는 어려운 것을 쉽게 이야기합니다. 화이트보드 학습법을 진행할 때 우리는 누구나 “고수의 길" 을 지향해야 합니다. 지금 이 순간 내 앞에 앉아 내 화이트보드 특강을 듣고 있는 사람은 애플리케이션 개발은커녕 터미널 한번 열어본 적이 없는 컴맹이라고 전제해야 합니다. 이 사람에게 그 개념을 이해시킬 수 있다면, 우리는 자신 스스로에게 그 개념을 가장 잘 가르치고 있는 것입니다.

 

• 작은 화이트보드를 사용한다. 화이트보드가 크면 안 됩니다. A3 정도 크기의 작은 화이트보드를 선택하세요. “설명" 이 핵심이 되기 위해서입니다. 내가 모르는, 혹은 잘 알고 있다고 착각하는 개념을 말로 풀어 가상의 누군가에게 설명하는 경험을 갖는 것이 가장 중요합니다. 이를 위해 작은 화이트보드를 사용해서, 다이어그램이나 그림을 그리는 것은 최소화하고, 개념을 관통하는 몇 개의 도식 만으로도 누군가에게 능숙히 어떤 개념을 설명할 수 있는 연습을 진행해 보세요.

마무리 : 점 잇기

프로그래밍을 배우고 개발자로 성장해 나가는 것은 거대한 “점 잇기 게임" 같은 것이라고 생각합니다. 프로그래밍과 개발에 대해 전혀 모르던 사람이 우연한 기회에 개발에 입문해 syntax 학습부터 시작해 깊이 있는 CS 지식을 탐구해 나가기까지, 모든 과정은 드문드문한 점으로 존재하던 머릿속 지식들을 이어나가 단단한 연결고리를 만들어내는 과정으로 요약할 수 있습니다. 제 스스로도 이런 과정을 걸어오며 학습과 성장의 즐거움을 느꼈는데, 이제는 멘토로서 멘티분들이 같은 과정을 소화해 나가며 성장해 내는 모습을 지켜보는 뿌듯함과 보람을 다시 한번 느끼고 있습니다.

많은 분들이 이 과정에서 “점찍기"에 매몰되지 않기를 바라며 이 글을 썼습니다. 머릿속의 점들을 하나하나 이어나가며 느끼는 보람과 성취감, 기술적 성장 그리고 그에 부수되는 커리어적인 성공과 경제적인 보상은 개발자가 자신의 직업을 통해 가질 수 있는 최고의 리워드들이기 때문입니다.

어려운 학습의 과정이 끝나고 느끼는 짜릿함을 반복해 나가며, 모두가 원하는 회사에서 일하며 직업적 성취와 자아실현을 누리는 기회를 갖게 되시기를 기대합니다. 긴 글 읽어주셔서 감사합니다. 🙂