개발 서적 스터디 어떻게 해야 할까?
다양한 형태로 스터디를 진행 해보다 보니, 어떤 방식이 좋을까에 대해 조금 고민을 해보게 되었다.
같은 집단에 있던 사람들, 처음 만나는 사람들, 어느 정도 라포가 쌓인 경우 등등 같이 하는 사람들이 달랐다 보니 매번 상황, 규칙, 구성이 달랐기에 내가 경험한 스터디 방법들과 그리고 어떤 방법이 좋을까에 대해 이야기 해보려한다.
인원수, 책 선정 및 스케줄 그리고 진행 방식 이렇게 크게 3개에 대해 다뤄본다.
인원수
스터디를 같이 진행하는 인원을 4명에서 많게는 10명까지 경험해 보았다. 어느 정도의 인원수가 좋을까?
어떤 방식으로 스터디를 진행하는냐에 따라 다르겠지만 5~6명 정도가 적당하다.
만약 5~6명 보다 적어지거나 많아지면, 이런 문제가 발생한다.
인원이 적은 경우
보통 스터디를 하게 되면 각자 알아서 책만 읽는 게 아니라, 일주일에 1시간 정도 서로 모여서 이야기를 하게 된다. 그런데 인원수가 적다 보면, 스터디 인원 한명 한명의 불참이 해당 스터디 진행에 영향을 끼칠 수 있다.
불참하는 사람도 불편해지고 다른 참여자들도 불편해진다. 2,3명에서도 진행할 수도 있지만, 책을 읽고 하는 스터디는 책을 읽는 것 이상으로 서로의 의견 공유가 중요하다.
그냥 책을 읽기만 하는 것이라면 혼자 읽어도 되지만, 스터디를 하는 것은 책을 읽고 서로의 생각을 이야기하기 위해 한다고 생각한다.
인원이 적을 수록 의견 공유가 줄어든다. 보통 책을 읽고 모든 사람이 할말이 생기는 건 아니기 때문에, 다른 사람의 감상을 듣다보면 이야기가 생각나거나 한다. 이러한 선순환이 어느 정도 돌려면 최소 인원이 필요하다고 느꼈다.
책을 각자 다른 챕터를 읽고 내용 요약을 발표하는 경우여도 문제는 똑같이 발생한다. 해당 챕터를 요약해주는 사람이 없어지기 때문에 구멍이 생긴다.
결국 인원이 적은 경우의 가장 큰 맹점은 모든 사람이 책임감 있게 스터디를 진행할 수 있냐. 이게 중요하다.
만약 소수 인원이더라도 같은 회사의 사람이라던지 시간 조정이 편한 상황이거나 사람들 간의 관계성이 뚜렷한 경우 문제가 덜 생길 수도 있겠다. 하지만, 일반적으로는 최소한 5~6명 정도의 구성원이 있다면 서로 편하게 스터디를 진행할 수 있지 않을까 싶다.
인원이 많은 경우
누군가의 불참은 문제가 없어진다. 반대로 사람이 많아서 의견 공유가 힘들 수도 있는 상황이 생긴다. 사람들에 따라 많은 사람 앞에서 이야기 하는게 쉽지 않거나, 적극적인 사람들의 의견공유 속도를 따라가지 못해서 참여는 했지만 사람들과의 공유는 별로 못하는 경우가 생긴다.
이러한 문제를 방지하기 위해서 읽은 책의 요약과 이야기하고 싶은 내용을 정리해오고 같이 보는 형태가 좋다. 하지만, 인원이 많을 수록 이러한 정리된 내용도 많아지기 때문에 자신이 다루고 싶은 주제를 못 다룰 가능성이 크다. 또한, 스터디가 예상 시간보다 길어질 확률이 높다.
시도해보지는 못 했지만, 고려했던 방법 중 두팀 정도로 나누어서 해보는 것을 고려한 적도 있다. 보통은 스터디를 이끄는 리더 같은 역할을 하는 사람이 1명 존재하게 되는데, 팀이 나눠지면 리더가 없는 팀의 진행이 애매해질 것 같아 일단 한팀으로 진행해 본 기억이 있다.
한팀으로 많은 인원수를 진행을 했던 경우도 여러 이유로 사람이 오시거나 나가시거나 하시는 경우가 있었기에 적정 인원으로 맞춰지기는 했었다.
보통 차라리 인원이 적은 것보다 많은 것이 낫지만, 위와 같은 이유들 때문에 적당한 인원수가 필요하다 느꼈다. 스터디를 어떻게 진행하느냐에 따르기에 스터디의 목적과 방식에 맞게 적정한 인원 수를 고려하고 시작하는게 좋다.
책 선정 및 스케줄
어떤 스터디가 될 지 중요한 기준이다.
책의 주제에 따라 모이는 사람도 달라지고 목적도 달라질 가능성이 크다.
특정 개발 스택에 관한 책이라면 관련된 개발자들만 모이다 보다 일반적인 내용을 다루는 책보다 스터디원의 다양성이 부족해질 수 있다.
물론 비슷한 직무의 비슷한 연차의 사람들이 모여 이야기를 하는것이 재밌기는 하다.
하지만, 어떤 책을 선정하는 것에 따라 어떤 사람이 모일 것이라는 생각은 염두해 두는 것이 좋다. 만약 스터디를 참가하거나 만드는 사람이라면 어떤 사람들이 모일거라는 예상을 해보자.
또한, 책의 난이도와 페이지 수도 영향을 끼친다.
난이도가 너무 높아보이는 책이라면 같이 스터디 할 사람을 모으기 어려울 수 있고, 페이지 수가 너무 많은 경우도 참여에 부담감이 생길 수 있다.
개발 관련 책들이 양이 많고 어려운 내용이 있는 경우들도 있다 보니 책을 선정하고 스터디원끼리 특정 챕터만 다룬다던지 바로 시작하는 것이 아니라 어떤 내용에 집중할 지 같이 이야기해보고 시작하면 좋다.
예를 들어 900 쪽이 넘는 책들이 종종 있는데, 15챕터가 있다면 목차를 같이 보면서 8챕터 정도만 필수로 고른 다음에 스터디를 진행해나가면서 약간의 조정으로 추가하거나 빼거나 한다던지 할 수 있다.
보통 빼는 게 어렵기 때문에 다 하는 경우도 많을 것이다
결국, 책을 고르는 것도 중요하고 고른 후에 스터디를 하는 사람들끼리의 협의를 잘 진행하는 것이 중요하다.
진행 방식
크게 나눈다면 같은 챕터를 읽고 생각을 공유하는 방법과 다른 챕터를 각자 요약해 발표해오는 방식이 있겠다.
본인은 같은 챕터를 읽고 생각을 공유하는 방법을 선호한다. 다른 챕터를 각자 요약해 발표해오는 방식은 두꺼운 책을 여러 사람의 힘을 합쳐 책을 이해하는 방법으로 사용할 수도 있겠지만, 보통은 스터디를 통해 다른 사람과의 소통을 통해 인사이트를 가져가는 게 크다고 본다.
스터디가 시작하면 스티디원들의 스케줄을 확인하고 스터디 할 시간을 정하게 된다. 이후에 책의 목차를 보고 전체적인 스케줄을 같이 이야기해보는 것이 좋다. 스터디를 너무 길게 가져가도 안 좋기에 분량을 적당히 나누어 스터디가 언제 쯤 끝날지 알 수 있게 하자.
진행 시간은 일반적으로 1주일에 1시간 정도 시간을 잡는 것이 좋다. 그리고 주말보다는 평일이 좋다. 주말의 경우 다른 약속과 겹쳐 불참률이 높아질 수 있다. 그리고 평일에서도 월,화 보다는 수,목이 좋은데 스터디를 준비해야 하는 경우 주말에 해야지 하고 주말에 약속이 생겨 못 하는 경우 버퍼를 두기 위해 가능하다면 수, 목 정도가 적당하다. 금요일도 나쁘지는 않은데 주말과 같은 이유로 피해주자.
그리고 모이는 시간 전에 책을 요약하고 이야기할 주제를 가져오면 좋다. 요약의 경우 스터디원들에게 부담감이 될만한 분량을 요구하면 안 된다. 책을 읽고 생각을 공유하는 것이 더 중요하기 때문에 스터디가 요약하기 힘들어서 스터디가 불편하다고 느끼게 하지 말자.
이야기할 주제는 가져오면 좋지만, 위에서 언급했듯이 사람들에 따라 책을 읽고 생각이 안 떠오를 때가 있기 때문에 적당한 선에서 스터디 시간을 잘 사용할 수 있을 정도로 준비하게 하자.
요약 및 이야기할 주제를 정리하는 곳으로는 노션이나 깃헙을 생각해볼 수 있다. 둘 다 좋지만 개발자만 있는 스터디라면 깃헙도 나쁘지 않다. 그리고 만든다면 레포지토리는 오게니제이션을 만들어서 레포를 만드는 형식으로 하는걸 추천한다. 좀 더 공용의 장소로 느껴지게 하기 위해서다.
스터디 리더가 매 스터디 시간을 사회자처럼 이끄는 것도 좋지만, 이러한 사회자 역할을 매번 하는 것이 쉽지 않기도 하고 경험상 다양한 사람들이 해보는 것을 추천하기에 스터디원들이 나누어가면서 사회자 역할을 해볼 수 있게 하자. 다른 사람들 앞에서 자신의 정리한 생각을 공유하고 회의를 주도하는 경험을 다 같이 가져가는 것이 좋고, 모든 스터디원의 참여도를 높이는 이유로도 좋다.
마무리
이외에도 좋은 개발 서적 스터디를 만들기 위해 고려할 것들이 많지만 크게 보면 위의 이유들을 고려하면 어느 정도는 굴러간다.
본인 같은 경우 책은 잔뜩 사놓고 읽지 않는 경우가 많은데 그러다 보니 이러한 개발 서적 스터디가 매우 도움이 되고 있다.
그리고 다양한 직군, 회사, 연차의 사람들과의 개발에 대한 이야기를 나누는 장도 되기에 추천한다.
혼자서 책을 깊게 파보는 것도 중요하지만, 관심이 있는 사람들끼리 작은 스터디를 해보자.
