개발자 여러분은 평소 스터디 준비를 어떻게 하시나요? 나만의 공부 방법이 있으신가요?
개발 스터디에 들어갔지만 스터디 준비 방법에 대해 고민하는 분들께 도움이 되기를 바랍니다.
시작에 앞서
이 글을 쓰게 된 계기
필자 본인은 혼자보다 사람들과 함께 공부하는 것을 선호한다.
평소 “모르는 것을 모르는” 상태를 경계하는데, 함께 공부하면 내가 모르는 것이나 놓친 부분을 잘 알 수 있다. 뿐만 아니라 동기부여와 자극을 받을 수 있기도 하다.
이런 이유로 프로그래밍을 시작하고 약 1년 반 동안 6개의 스터디에 참여해 왔다. 스터디를 하지 않는 기간이 없던 것이다. 그동안 스터디 리딩도 하고 참여도 하면서 어떻게 하면 스터디를 최대한 잘 활용할 수 있을까 고민하며 이런저런 시도를 해보았다. 그러다 요즘은 나에게 맞는 학습 방법을 찾아 적용 중이다.
최근 한 스터디원이 스터디 준비 방법에 대해 궁금해 했고, 나의 시행착오와 학습 방법을 공유하기로 했다.
(소개하는 방법은 아마 ‘기술 서적 스터디’에 가장 적합할 듯 하다)
왜 스터디를 잘 준비해야 하나
보통 스터디를 참여할 때는 목적과 목표가 있기 마련이다. 부족한 무언가를 채우기 위해, 혹은 사람들과 함께 공부하며 좋은 자극을 받기 위해 등등.
이러한 이유의 공통점은 무엇일까?
바로 ‘현재 부족한 것을 채우는 것’ 이다.
그렇다면 어떻게 하면 스터디를 통해 부족한 것을 효과적으로 채울 수 있을까?
스터디 준비부터 진행, 이후 복습까지. 나만의 스터디 활용 방법을 소개한다.
스터디 준비하기
최소 준비 기간
개인적으로 스터디는 최소 이틀 전부터는 준비한다. 시간적 여유가 없으면 정신적 여유도 없기 때문이다. 정신적 여유가 없으면 학습의 깊이도 얕아질 수 있다. 그러니 천천히 시간 여유를 두고 깊이있게 공부한다.
한 바퀴 돌기
스터디 이틀 전에는 분량까지 1회독을 한다. 분량이 많으면 3일 전부터 해도 좋다.
개인적으로는 50페이지를 1회독 할 때 2시간 정도 걸린다. 스마트폰의 방해 없이 집중해서 읽으면 2시간도 안 걸리고 후루룩 읽을 수 있다.
이처럼 스터디 준비를 할 때 직접 시간을 재보면서 준비에 얼마나 걸리는지 파악해 보아도 좋다. 물론 책 내용이나 난이도에 따라 소요시간은 다르겠지만, 보통 본인이 스터디를 위해 얼마 정도의 시간을 써야 하는지 알면 준비 시간 산정에 도움이 될듯 하다.
두 바퀴 돌기
스터디 2~3일 전에 챕터 한 바퀴를 돌았다면, 두 바퀴를 돌아도 좋다. 사실 스터디 준비하면서 꼭 2회독까지 해야 할 필요는 없겠지만.. 필자 경험 상 한 바퀴를 돌았을 때보다 두 바퀴를 돌았을 때 이해의 폭과 깊이가 훨씬 깊어졌기 때문에 추천한다. 이해가 어려웠던 부분이, 한번 더 읽으면 이해가 잘 되는 경험을 할 수 있을지 모른다.
깊숙이 파고들기
2회독의 포인트는 밑줄 친 부분이나 이해가 어려웠던 부분 등을 더 깊게 공부하는 것이다. 1회독을 하며 그냥 지나쳤던 부분은 이해가 어렵지 않았거나 별로 중요하지 않은 부분이었을 가능성이 있다.
따라서 2회독을 할 때는 이해가 어려웠던 개념과 중요한 개념을 구글링, GPT, 관련 서적 등을 활용해 해당 개념을 더 파고들어 보자.
가르칠 걸 염두하기
2회독의 또다른 포인트는 ‘가르칠 것을 염두하며 읽기’다.
보통 개발 책 스터디를 하면 챕터별로 리딩하는 사람을 정해서 해당 챕터의 진행을 이끄는 편이 흔할 것이다. 필자는 리딩하는 사람이 랜덤으로 정해지든 이미 정해져 있든 누군가를 가르친다는 생각으로 읽는 편이다. 그래야 이해가 훨씬 잘 되기 때문이다.
조금 과장해 말하자면 기술면접을 준비한다는 생각으로 읽는다. 왜냐하면
꼬리 질문을 대비하고, 이야기 할 소스를 준비해야 하기 때문이다.
해당 챕터 진도를 나가면서 어떤 스터디원이 해당 내용에 대해 의문을 가지거나 궁금해한다면, 그 질문이 나를 향할 수 있다. 무조건 내가 대답해야 하는 건 아니지만, 해당 챕터를 리딩하는 사람으로서 더 잘 설명할 수 있다면 좋지 않을까.
그리고 스터디를 진행할 때 그냥 책을 줄줄 읽는 것도 나쁘지 않지만, 이야기 할 소스를 가득 준비해 가서 관련된 주제를 던지고 이야기를 나눈다면 더욱 스터디 시간이 풍성해지지 않을까?
대학 시절 교수님들이 가뜩이나 재미없는 전공 책을 그냥 읽으시는 것보다, 책을 기반으로 교수님만의 소스를 가득 담아 가르쳐주시면 더 기억에 남고 재미있게 느껴졌던 경험을 떠올려보자.
스터디도 마찬가지이다.
사람들과 함께 하는 만큼, 청자를 위한 준비 또한 필요하다.
자, 책을 읽었다면 다음 스텝으로 가보자.
감상평 쓰기
필자가 진행했던 스터디 중 가장 좋다고 생각했던 방법이 있었다. 아래와 같이 Github의 Issue, Discussion 기능을 활용하는 것이다.
Github의 Discussion 기능을 활용해 토론하는 모습
그 중 매 주 할당량을 읽으면 Discussion에 본인이 공부한 내용이나 같이 이야기 나누고 싶은 내용을 공유한다. 쉽게 말해 ‘감상평’을 작성하는 것이다.
원래 이는 필자가 진행하는 스터디에서 강제가 아니었는데, 간혹 책을 읽지 않고 스터디를 참여하는 경우가 있어 매번 모든 사람들이 감상평을 남기기로 했다. 만약 남기지 않으면 꼭 그 다음주에라도 남겨야 한다. 덕분에 진도를 놓치지 않고 읽을 수 있다.
그래서, 감상평은 아래와 같이 적었다.
감상평 예시 1
감상평 예시 2
감상평 주제는 다양한데 주로 이런 내용들을 쓰곤 한다. 아래는 예시다.
•
인상깊었던 책의 내용과 인상깊었던 이유
•
현업 등 코드에 반영할 수 있는 방법과 생각
•
관련 아티클이나 이해를 돕는 자료를 첨부
•
새롭게 알게된 점이나 이해가 어려웠던 점
•
그 외 이번 챕터의 난이도나 사담들
감상평 형식 또한 다양해도 좋다. 필자 스터디에서는 감상평을 한 두줄로 간단하게 남기는 사람도 있고, 많은 내용을 적는 사람도 있다. 개인적으로는 감상평의 분량이 노력이나 깊이에 꼭 비례하진 않는 것 같다. 그러니 자유에 맡기거나, 스터디에서 최소 가이드라인을 정해도 좋겠다.
스터디 진행하기
자, 이제 스터디 당일이 되었다. 어떻게 진행하면 좋을까?
스터디 주제나 목적에 따라 진행 방법은 상이하겠지만, 필자는 보통 아래와 같이 진행했다.
감상평 읽기
스터디 초반에 준비 과정에서 적었던 감상평을 돌아가면서 읽는다. 이 과정이 조금 무의미해보일 수 있지만 생각보다 괜찮은 방법이다.
각자가 어떤 생각으로 책을 읽었는지, 어떤 부분이 어려웠거나 새롭게 알게 되었는지를 미리 짚을 수 있기 때문이다.
예를 들어 필자는 어떤 스터디원이 특정 페이지의 단락이 이해가 되지 않는다고 써 둔 부분을 기억해 놨다가, 스터디 진행 중 해당 부분을 진행할 때 한번 더 언급해서 다같이 머리를 맞대고 이해하고 넘어갔던 경험이 있다. (경험상 내가 이해가 어려운 부분은 남들도 이해하기 어려운 적이 많았기 때문)
혹은 스터디 진행 중에 감상평에 언급되었던 아티클들을 다같이 읽으며 더욱 심도있게 스터디를 진행한 적도 있다.
이렇듯, 감상평 읽기는 생각보다 많은 이점들을 가져다줄 수 있다.
일단 말하기
전형적인 한국식 교육을 받은 사람이라면 질문하거나 토론하는 것에 익숙하지 않을테다. 그래도 노력해보자. 필자는 본인을 평가하기에 ‘말 많은 스터디원’ 이라 생각한다. 그만큼 스터디 때 (시간과 진도를 고려하며) 토론을 많이 하려고 한다.
물론 처음엔 쉽지 않았다. 특히나 최근에 했던 스터디는 필자 본인은 아직 0년차 비전공자 신입 개발자였고, 나머지 스터디원들은 현업에 최소 1년차에서 5년차였기 때문이다. 처음에는 ‘나는 아직 부족한 것 같은데 이 말을 해도 될까’ 고민했다.
하지만 처음에 언급한듯이 스터디에는 분명한 목적을 가지고 참여한다. 이 목적을 달성하기 위해서는 최대한 스터디와 스터디원들을 통해 많은 것들을 얻어가야 한다. 그러니 두려워하지 말고 모르면 물어보고, 조금이라도 아는 게 있으면 말해보자.
말하는 사람이 많아질수록 스터디 시간은 더욱 풍요로워질 것이다.
모르는 것을 적기
스터디원들과 이야기 할 때 모르는 단어가 나오면 무조건 받아 적는다. 주로 아예 몰랐거나, 알고 있었다고 생각했지만 다시 공부해야 할 것 같은 키워드들, 혹은 대화에서 파생된 궁금증들을 적어둔다.
예시1: 역참조 라는 단어에 대해 알고는 있으나 설명을 못해 적어두었다.
예시2: 시스템 호출의 종류에는 무엇이 있을까 문득 궁금해 적어두었다.
또한 종종 스터디를 진행하면서 주제와 맞지 않는 대화로 빠지는 경우가 있는데, 그럴 때도 모르는 기술이나 단어가 나오면 받아 적는다. 예를 들면 이런 식이다.
스레드 성능에 대해 이야기하다가 → 웹 사이트 성능 관련 이야기가 나와서 → ‘레이지 로딩(Lazy Loading)’ 이라는 단어가 언급되었다 → 근데 난 레이지 로딩이 뭔지 모른다 → 책에 메모해 둔다.
이렇게 적은 것들은 스터디 복습을 할 때 매우 유용하다. 녹음한 것을 다시 듣지 않는 한 어떤 내용이 오고갔는지 알기 어려우니, 키워드가 나왔을 때 빠르게 적어두는 것을 추천한다.
스터디 복습하기
3바퀴 돌기
앞서 말했듯 n회독은 필수가 아니나, 스터디 후에 책을 한번 더 읽는 것을 추천한다. 종종 책 내용이 스터디 전과 다르게 다가올 뿐 아니라 텀을 두고 여러번 학습하면 장기기억으로 가져갈 수 있기 때문이다.
놓치지 않기
감상평은 Github의 Discussion 기능을 사용해 적었다면, 새롭게 알게되었거나 공유하고 싶은 자료들은 Issue 기능을 사용하곤 했다.
스터디 진행 중 언급된 단어를 놓치지 않고 적어두면 아래와 같이 스터디가 끝난 후 더 깊게 공부할 수 있다.
스터디 때 나왔던 주제와 자료들을 정리한 이슈
더 깊게 공부하기
예를 들어 스터디 때 언급된 ‘역참조’ 라는 단어를 알고 있었지만 스스로 잘 설명하지 못할 것 같아 적어두었다. 그래서 스터디가 끝난 후 아래와 같이 다시 공부했다.
물론 굳이 공유하지 않고 혼자 기록하며 공부해도 된다. 필자 본인은 공개 아카이빙 겸, 스터디원들과도 한번 더 나누고자 적은 것이다.
결국 핵심은
시간을 두고, 반복하는 것
이 두 가지인 것 같다.
시간을 두지 못하면 조급해서 내용이 눈에 잘 안 들어오기 마련이다. 그럼 결국 스터디 준비를 제대로 못할 수밖에 없다. 그러니 위에서 언급한 듯이 최소 스터디 2일 전에는 시작하자. (특히나 필자는 불안하고 조급한 상황 자체를 만들고 싶지 않은 성향이어서 더 그렇다)
물론.. 정신없이 이런 저런 일에 치이다보면 스터디 2시간 전에 급하게 할 때도 있다. 그럴 땐 ‘다음 주에는 꼭 2일 전에 준비해야지’ 라고 다시 한번 다짐해 보자. 다짐해도 안 되면 다시 해보고, 그래도 안 되면 스터디원들과 내기를 통해 스스로와의 약속을 지켜도 좋을 것 같다.
마지막으로, 참고하면 좋을 영상 하나를 첨부한다. 미국 변호사인 서동주 님이 추천하는 공부법인데, 요약하자면 책을 한 번 읽고나서 텀을 두고 다시 한번, 그리고 이후에 또 다시 한번 읽으며 완전히 장기 기억로 만들라는 내용이다. 이 글의 내용과 맞닿아있는 부분이 있어 공유한다.
글에서 소개한 방법이 정답은 아니다.
이것저것 시도해보면서 나만의 학습 방법을 찾는 것이 핵심이다.
더 좋은 나만의 방법이 있다면 함께 공유해도 좋을 것 같다.
오늘도 열심히 스터디하는 모든 개발자를 존경하며 이 글을 마친다.