8주간의 개발자 스터디를 운영하며

최근 "가상 면접 사례로 배우는 대규모 시스템 설계 기초" 스터디를 마무리했다.

 
사내 JPA 스터디 이후로 오랜만에 운영했던 스터디인데, 성공적으로 마무리된 것 같아서 뿌듯하다!
무엇보다 적극적으로 참석해 주고, 유종의 미를 거두게 해 준 스터디원분들께 정말 감사하다.

 

안그래도 요즘 F-Lab에서 열린 블로그 챌린지 2기에 참여하고 있기 때문에, 무슨 글을 써볼까 고민하고 있던 참...🤔
스터디를 2번째 운영하면서 느낀 점들과 앞으로 개발자 스터디(도서)를 효과적으로 운영하는 방법에 대해 정리해보고자 한다.
 

스터디는 어떻게 시작하면 좋을까?

 계속 읽고 싶었던 책이라, 혹시 계실까 해서 활동하는 개발자 단톡에 이렇게 꺼냈는데...

 

 
생각보다 반응이 너무 뜨거워서 살짝 놀랐다...! 허거덩스
 

몇 명이 모여야 할까?

"몇 명이서 하냐"도 스터디에서 굉장히 중요한 요소다.
너무 많으면 관리가 어렵고, 너무 적으면 다양한 관점을 얻기 힘들다.
 
내 경험상 도서 스터디에서 가장 적절한 인원은 3~5명이다.
보통 디스코드 같은 음성 채널에서 스터디를 할 텐데, 6명 이상이면 목소리가 겹치거나 각각의 참여도가 떨어진다고 생각한다.
 
실제로 우리는 8명으로 시작했지만 시작 전에 2분이 회사 사정상 하차하시고, 나머지 1분은 1회만 하고 하차하셨다.
결과적으로 5명이 완주했는데, 이 정도 규모가 딱 적절했다.
 

무엇을 위한 스터디인지 명확히 하자

단순히 도서 스터디지만, 발표로 진행할 수도 있고 회고로 할 수도 있고 방법은 다양하다.
 
발표도 고려했었지만, 이 책 자체가 난이도가 있고 또 재직자들이 많기 때문에 발표 자료까지 준비하는 건 타이트하다고 생각했다.
무엇보다 이 책은 2~3회독 해야 하는 책이기 때문에 빠르게 1회독을 해보자라는 목표로 설정했다.
 

우리가 정한 진행 방식

• 발표는 없이 개인 노트 정리 (선택)
• 깃허브 이슈에 각 장을 읽으며 궁금했던 질문을 1~3개씩 등록 (필수)
• 질문 중심으로 회고 진행

이렇게 하니 부담은 줄이면서도 깊이 있는 토론이 가능했다.
 

이건 잘했다

벌금 제도를 도입하지 않은 것

보통 보증금을 거두거나, 지각/불참에 대해 벌금을 거두는 규칙을 많이 세우는데, 난 그렇게 하기 싫었다.
 
왜냐!
스터디라는 건 본인이 자발적으로 신청한 거고, 공부 안 하면 본인 손해라고 생각한다.
무엇보다 강제성을 부여하는 건 좋지만, 오히려 "이런 장치가 없어도 적극적으로 참여하는 사람들이 모이는 게 낫지 않을까?" 생각했다.
 
실제로 우리는 아무런 강제 장치 없이도 높은 참여율을 유지했다.
0~1회 차에 회사가 바빠져 하차하신 분들 말고는 중도 하차한 스터디원이 전혀 없었다. 

 

스터디 일정을 유동적으로 변경하지 않은 것

야근하는 스터디원들이 1~2분씩 빠지는 경우가 있어서, 항상 풀 멤버로 진행되지는 않았다.
3명이서 할 때도 많았는데, "그럼 내일 하면 더 많이 오지 않을까?" 해서 변경도 생각했었다.
 
하지만 유동적으로 시작하면 다음 진도를 위한 시간이 줄어들 뿐만 아니라,
"유동적으로 되니까 빠져도 되겠지?"라는 여지를 주는 것 같다고 생각했다.
 
결과적으로 "무슨 일이 있어도 진행한다"는 생각이 있으니 무조건 그전에는 읽어야지.. 하게 돼서 좋았다.
그리고 기간을 너무 러프하게 잡으면 흐지부지될 가능성이 높아서 "무조건 8주만에 완주해야지"라는 생각이 확고했다.
 

질문을 기반으로 회고한 것

처음 킥오프 미팅 때는 "각자 인상 깊었던 부분을 공유할까?" 싶었다.
하지만 개발 서적을 읽다 보면 "왜?", "뭔 말이지?"라는 의문이 꼭 생긴다.
그리고 이 부분을 찾아보면서 알아내야 이 책에서 배우는 점이 생긴다고 생각한다.
 
그래서 이슈에 각자 이 책을 읽으면서 생긴 질문들을 올리고,
"나는 이 부분에서 이게 뭔 말인지 모르겠더라, 근데 찾아보니 ~라고 한다"
"이 부분에서 ~는 어떻게 되는걸까? 했는데 이런 거라고 하더라" 이런 식으로 공유했다.
 
이런 식으로 진행하니 같은 책을 읽어도 다른 관점에서 접근할 수 있다는 걸 알게 되어 좋았고, 다양한 사례들도 접할 수 있어서 좋았다.
 

모든 회고록을 녹음하고, 기록한 것

디스코드로 회고록을 녹음하고 클로바노트를 사용해서 스크립트로 만들었다.
그리고 AI를 활용해서 우리가 이 질문들에서 어떤 내용을 나눴고, 어떤 걸 개선하면 좋은지? 회고록을 작성했다. [예시]
그리고 각 스크립트는 따로 스터디원들한테 공유했다.

지금 당장 필요하지 않더라도 회독하면서 "아 이때 이런 얘기를 했었구나, 이게 맞았네" 이렇게 할 수만 있어도 좋다고 생각한다.
 
 

아쉬웠던 부분들

이 정보가 정확한 정보일까?

우리는 각자 질문을 기반으로 회고를 진행했기 때문에, 그 질문에 대해 본인이 알아낸 정보를 공유하는 식이었다.
근데 이 내용이 대규모 시스템 기반이고, 난이도가 있다 보니 실무에서 설계를 해보지 않은 사람이면 잘 몰라서 AI의 도움을 많이 받게 됐다.
때문에 이 정보가 확실한 건지 정확히 알기 어렵다는 점이 공통적인 아쉬운 점이었다.
 
그래서 카프카같은 분야가 나오면 데이터 엔지니어 친구에게 물어서, 그 내용을 스터디원들에게 공유하거나,
"어느 회사에 다니는 분이 이런 말씀을 하시더라" 식으로 현업 경험자들의 사례를 들었다.
하지만 모든 내용을 검증하기에는 한계가 있었다. 🥲
 
지금 생각하면 질문에 대해 좀 더 자세히 알아보고 했으면 좋았겠지만,
재직자분들이 있으니 그렇게 하면 완주하기가 힘들 것 같아서 포기했다.
애초에 이 책은 최소 2회독을 목표로 잡았기 때문에 러프하게 진행한 면도 있다.
 
 

다음에는 이렇게 해보고 싶다

실무 경험자 멘토 섭외

다음 스터디에서는 해당 분야 실무 경험자를 멘토로 섭외해서 정기적으로 질문을 받아보는 시간을 가져보고 싶다.
여기서 뭔가 사이드 프로젝트 아이디어가 떠오르기도 했다...(뭔지는 🤫)
이론만으로는 한계가 있는 부분들을 실무 관점에서 물어볼 수 있을 것 같다.
 

간단한 실습 시간 추가

이 스터디를 하면서, 뭔가 한 챕터를 골라서 직접 작은 트래픽을 고려해서 구현한 다음에,
책의 내용을 적용해 보면 확실히 기억에 남겠다는 생각을 했다.
이 부분은 시간이 정말 오래 걸릴 거고, 1장만 구현해도 n달이 걸릴 수도 있다고 생각해서.. 어떻게 진행할지 고민 중이다.
 

마무리

8주간의 스터디를 마무리하며 가장 큰 깨달음은 역시 혼자 하는 것보다 같이 하는 게 낫다는 것이었다.
또, 벌금이나 보증금 같은 장치 없이도 충분히 성공적인 스터디를 운영할 수 있다고 느꼈다.
 
또한 질문 중심의 토론이 발표 형식보다 오히려 나을 수도 있겠다는 생각을 했다.
발표는 내가 맡은 부분만 기억에 남을 수도 있을 수도 있기 때문에,
각자의 궁금증에서 시작된 회고가 오히려 더 다양하고 실용적인 인사이트를 줬다.(나한테는)
 
무엇보다 함께 공부할 수 있는 동료들이 있다는 것 자체가 큰 동기부여가 되었다.
예전에 일할 때는 사내에 같이 스터디할 사람이 없으니 혼자서 공부하는 경우가 많았는데..
그러니 자꾸 중간에 그만 읽고 다른 책을 읽거나 하는 경우가 왕왕 있었다.
혼자서는 끝까지 읽기 어려웠을 책도 함께라면 완주할 수 있다는 것을 다시 한번 느꼈다.