<div id="readability-page-1" class="page"><div id="content"><p>　다양한 방식으로 스터디를 해왔다. 정말 많은 것을 배웠던 스터디도 있는가 반면에 지나고 보면 시간이 아까울 정도의 스터디도 있었던 것 같다. 직접 만들어 보기도 했고 참여도 해봤던 것 같다. 이런저런 경험들 끝에 작년 중순에 직접 만들었던 스터디 멤버와는 어느덧 반년을 넘어가고 있는데 바쁜 회사 생활을 하면서도 이제까지 지속할 수 있었던 노하우를 공유해 보고자 한다.</p><h2 id="그룹-스터디-방식">그룹 스터디 방식</h2><h3 id="인원">인원</h3><p>　다 그런 건 아니지만 기존 회사 분들과 스터디를 할 때면 아무래도 원래 알던 사이라 바빠서 준비를 못 해오거나 불참을 하는 경우에 “그럴 수도 있지”, “괜찮아” 하며 관대해졌던 것 같다. 또는 다양한 의견을 듣자며 10명 이상 진행을 했던 것 같다. 그렇다 보니 스터디 진행에 집중도가 떨어질 수밖에 없었고 모였을 때 이야기하던 사람들만 이야기한다든지, 중도 하차하는 경험도 많았다.</p><figure><a href="/images/a-good-developer-in-terms-of-group-study/blind.png" title="/images/a-good-developer-in-terms-of-group-study/blind.png" data-thumbnail="/images/a-good-developer-in-terms-of-group-study/blind.png" data-sub-html="<h2>블라인드 글에 첨부한 스터디 참여 설문</h2>"><img src="https://taetaetae.github.io/images/a-good-developer-in-terms-of-group-study/blind.png" data-srcset="/images/a-good-developer-in-terms-of-group-study/blind.png, /images/a-good-developer-in-terms-of-group-study/blind.png 1.5x, /images/a-good-developer-in-terms-of-group-study/blind.png 2x" data-sizes="auto" alt="/images/a-good-developer-in-terms-of-group-study/blind.png" width="60%"></a><figcaption>블라인드 글에 첨부한 스터디 참여 설문</figcaption></figure><p>　이번 스터디는 직접 ‘블라인드’라는 익명 커뮤니티를 통해 인원을 모았다. 작년 중순쯤 자바 백엔드 관련된 주제를 스터디 하겠다며 나와 비슷한 연차분들 위주로 모으겠다고 글을 작성했더니 신기하게도 3~40명 되는 분들이나 지원하셨고 그중 오프라인 모임을 고려해서 나 포함 6명 만으로 구성을 하였다.(뭔가 서류 전형 인사담당자가 된 느낌;;) 작은 규모 그리고 새로운 분들과 하게 되니 집중도가 오르는 경험을 할 수 있었고 무엇보다 6명 모두 다른 회사라 각 회사를 대표하는 것 같은 느낌이 들어 스터디 참여에 몰입이나 책임감이 더욱 올랐던 것 같다. 또한 한 주제에 대해 각 회사에서의 경험들을 이야기하다 보니 완전히 다른 시각을 얻을 수 있다는 장점도 있었다.</p><p>　별거 아닐 수도 있지만(또는 오해가 될 수도 있지만) 남녀 성비, 그리고 나이대(연차)를 최대한 맞추고 싶었다. 그래야 분위기가 적당히 딱딱하지도, 부드럽지도 않을 것 같았기 때문이다. 지금은 여자 한 분 나머지 남자분들이라 초반에 걱정도 되었지만 생각보다 분위기가 잘 흘러가서 다행이라 생각을 한다.</p><h3 id="주제와-목표">주제와 목표</h3><figure><a href="/images/a-good-developer-in-terms-of-group-study/roadmap.png" title="/images/a-good-developer-in-terms-of-group-study/roadmap.png" data-thumbnail="/images/a-good-developer-in-terms-of-group-study/roadmap.png" data-sub-html="<h2>배워야 할게 한도 끝도 없는 개발자 세상스터디 목표에 따라 집중해야 할 범위를 좁히자!</h2>"><img src="https://taetaetae.github.io/images/a-good-developer-in-terms-of-group-study/roadmap.png" data-srcset="/images/a-good-developer-in-terms-of-group-study/roadmap.png, /images/a-good-developer-in-terms-of-group-study/roadmap.png 1.5x, /images/a-good-developer-in-terms-of-group-study/roadmap.png 2x" data-sizes="auto" alt="/images/a-good-developer-in-terms-of-group-study/roadmap.png" width="50%"></a><figcaption>배워야 할게 한도 끝도 없는 개발자 세상<br>스터디 목표에 따라 집중해야 할 범위를 좁히자!</figcaption></figure><p>　처음부터 모니터 받침으로 하기 좋을만한 두꺼운 책은 피했던 것 같다. 가볍게, 스터디원들끼리의 친밀도부터 올려야 한다는 생각으로 너무 딥 다이브 한 기술적인 내용보다는 누구나 한마디 정도 할 수 있을만한 가벼운 책부터 시작했다. 그러면서 최대한 참여도를 올리는데 집중했던 것 같다.</p><p>　어디까지나 “공부"를 하기 위한 모임이긴 하지만 이 또한 사람과 사람 사이의 “관계"가 중요하다고 생각했기에 모였을 때 바로 스터디 이야기를 하는 것보다 부드러운 아이스브레이킹을 자주 해왔다. 또한 너무 루즈 해지지 않게 1달~1달 반 정도로 끝날 수 있을만한 주제를 선정했다. 아무래도 한 주제가 2~3달 걸리다 보면 집중도가 떨어지는 경험이 많았기 때문이다. 책 한 권을 다 읽었다는 기간을 짧게 가져가면서 작은 성취의 효과를 최대한 활용하고 있다. 이번 회차가 벌써 네 번째인걸 보면 그래도 나름 잘 선택한 방법이라 생각이 든다.</p><p>　한 회차가 끝날 즈음엔 다음 스터디는 무엇을 할 것인지에 대해 이야기를 하고 다수가 동의하는 주제를 선정한다. 또한 매 회차가 끝날 때마다 어쩌면 어색할 수 있는 이야기지만 스터디 참여를 그만 둘지에 대해 의사를 분명히 물어본다. (그런데 신기하게도 지금 스터디 모임은 이런 이야기를 하기도 전에 스터디 하고 싶은 주제를 먼저 말씀해주시는 편이라, 어쩌면 스스로 사람 운이 좋다는 생각도 해본다.)</p><p>　그저 하나의 책을 읽기로 끝나는 “책 읽기 모임” 이 아닌 만큼 책을 기반으로 하는 스터디 모임일지라도 목표를 분명하게 잡는다. 여기서 목표는 개인마다 다를 수 있다. 가령 스터디 시간에 나왔던 내용을 각자의 팀에 공유 및 반영을 해본다든지, 스터디 내용에 대해 주도적으로 이야기를 하며 다른 분들의 지식을 훔쳐보겠다든지(?). 책 읽는 것으로 끝나면 안 되고 가능하다면 해당 내용을 실제로 경험하는 사이클까지 만드는 게 더 중요하지 않을까 생각을 해본다.</p><h3 id="최소한의-강제">최소한의 강제</h3><p>　앞서 “그럴 수도 있지”, “괜찮아"라며 이해하고 넘어가는 상황을 최대한 피하기 위해 최소한의 강제 장치를 마련했다. 한 회차 시작 전에 각자 최소한의 책임감을 부여하기 위한 용도로 예치금을 걷는다. 혹시 중도 하차할 경우 다시 돌려주지 않겠다는 무서운(?) 공지와 함께. 일주일에 한 번씩 만나는 당일 무작위로 선정해 발표 형식으로 진행을 하는데 만약 준비를 못 해왔다거나 개인 사정으로 참여가 어려울 경우(그 사정이 어떤 사정이라도 무관) 벌금을 걷기로 했다. 물론 다음 스케줄을 매주에 정하는데 모두의 합의가 이뤄지면 변경하며 진행할 수 있지만 정해진 일정에 진행을 할 수 없게 되면 다른 사람들에게 다양한 피해를 주기 때문에 벌금이라는 최소한의 강제를 만들었다. 이렇게 모인 돈으로는 한 회차가 끝날 때 모여서 식사 비용으로 사용할 수 있어 일석이조의 효과를 누렸다.</p><p>　스터디를 하기 전에 혹시 너무 한 사람만 이야기하는 걸 방지하기 위해 그날의 호스트가 사회(?)를 잘 봐야 한다는 의무감을 줘야겠다 했었는데 지금의 스터디는 자연스럽게 모두가 다 참여하게 되는 분위기가 만들어졌고 가끔 온라인으로 모였을 때는 오디오가 겹치는 상황을 최대한 방지하기 위해 “손들기” 기능을 활용하여 race condition을 최대한 회피하고자 하였다.</p><h3 id="기타-여러-장치들">기타 여러 장치들</h3><figure><a href="/images/a-good-developer-in-terms-of-group-study/roulette.gif" title="/images/a-good-developer-in-terms-of-group-study/roulette.gif" data-thumbnail="/images/a-good-developer-in-terms-of-group-study/roulette.gif" data-sub-html="<h2>스터디 중에 가장 쫄깃한 순간 : 발표자 선정출처 : https://quasarzone.com/bbs/qb_humor/views/558834</h2>"><img src="https://taetaetae.github.io/images/a-good-developer-in-terms-of-group-study/roulette.gif" data-srcset="/images/a-good-developer-in-terms-of-group-study/roulette.gif, /images/a-good-developer-in-terms-of-group-study/roulette.gif 1.5x, /images/a-good-developer-in-terms-of-group-study/roulette.gif 2x" data-sizes="auto" alt="/images/a-good-developer-in-terms-of-group-study/roulette.gif" width="50%"></a><figcaption>스터디 중에 가장 쫄깃한 순간 : 발표자 선정<br>출처 : <a href="https://quasarzone.com/bbs/qb_humor/views/558834">https://quasarzone.com/bbs/qb_humor/views/558834</a></figcaption></figure><p>　스터디 시작 전에 미리 발표할 영역과 담당 인원을 정하게 되면 본인이 담당이 아닌 영역일 땐 스터디의 집중도가 떨어지는 경험을 많이 해왔다. 그래서 모두 해당 영역에 대해 요약/정리를 하여 발표 준비를 해오고 스터디 당일 실시간으로 무작위 룰렛을 돌려 발표자를 선정하는 방식으로 진행했다. (사용하는 무작위 선정 툴 : <a href="https://search.naver.com/search.naver?ie=UTF-8&amp;query=%EB%84%A4%EC%9D%B4%EB%B2%84+%EC%82%AC%EB%8B%A4%EB%A6%AC&amp;sm=chr_hty" target="_blank" rel="noopener noreffer">네이버 사다리</a>, <a href="https://lazygyu.github.io/roulette/" target="_blank" rel="noopener noreffer">룰렛</a>) 정확히는, 발표자를 뽑는다기 보다 오늘 스터디를 진행하는 “호스트"에 더 가깝다. 선정된 호스트는 해당 영역에 대해 발표 또는 리뷰를 하고 토론을 진행한다. 무작위 그리고 토론이라는 장치가 긴장감을 주게 되고 이는 집중도를 올리는데 효과적이라고 생각한다.</p><p>　다들 바쁜 직장인들이다 보니 매주 모이는 게 현실적으로 어려운 경우도 있다. 처음엔 열정이라는 명목하에 잘 진행돼가다도 스터디의 내용이 어려워질 때면 집중도가 흐려질 수밖에 없다. 그래서 온라인 모임과 오프라인 모임을 적절하게 분배하고 한 달에 한 번 정도는 쉬는 “방학” 기간을 가지기도 한다. 그때는 개인 일정을 소화하거나 스터디 간에 못 따라 간 부분이 있다면 보충학습을 개별적을 갖기도 한다.</p><p>　앞서 이야기 한 것처럼 학습도 중요하지만 관계 또한 그만큼 중요하다고 생각하기에 평소에 단톡방을 활용하여 잡담도 나누고 각 회사/팀에서 가지고 있는 고민거리에 대해서 스스럼없이 주고받으며 어색함을 최대한 낮추는 노력을 통해 조금이나마 유대감을 형성하기도 한다.</p><h2 id="앞으로의-계획">앞으로의 계획</h2><p>　사실 이렇게 오랫동안 유지가 될 줄은 몰랐다. 신기하게도 구성원분들의 조합이 좋아서인지 오랫동안 지속될 수 있었던 것 같고 그러면서 매 스터디마다 회사에서 얻을 수 없었던 꽤 큰 인사이트를 얻기도 했다. 지난 약 6개월 동안 3번의 스터디를 해보니 단순히 책 읽는 것을 넘어서 서로 사례를 이야기하는 과정에서 배우는 게 더 많았던 것으로 기억되어 올해부터는 스터디 과정을 <a href="https://github.com/team-json-delivery" target="_blank" rel="noopener noreffer">어딘가</a>에 기록하고자 한다. 이를 바탕으로 스터디 팀 기술 블로그를 만들어 공유하면서 또 다른 인사이트를 얻는 장치로써 활용할 수 있을 것 같고 단순하게 책을 읽는 것을 넘어서 논의하는 시간을 더 많이 가져가며 집단지성의 힘과 기록의 힘, 거기에 공유의 힘까지 더해 스터디의 효과를 극한으로 끌어 올려보고자 한다.</p><h2 id="마치며">마치며</h2><figure><a href="/images/a-good-developer-in-terms-of-group-study/study.jpeg" title="/images/a-good-developer-in-terms-of-group-study/study.jpeg" data-thumbnail="/images/a-good-developer-in-terms-of-group-study/study.jpeg" data-sub-html="<h2>사람 살려출처 : https://www.fnnews.com/news/201112141617440705</h2>"><img src="https://taetaetae.github.io/images/a-good-developer-in-terms-of-group-study/study.jpeg" data-srcset="/images/a-good-developer-in-terms-of-group-study/study.jpeg, /images/a-good-developer-in-terms-of-group-study/study.jpeg 1.5x, /images/a-good-developer-in-terms-of-group-study/study.jpeg 2x" data-sizes="auto" alt="/images/a-good-developer-in-terms-of-group-study/study.jpeg" width="80%"></a><figcaption>사람 살려<br>출처 : <a href="https://www.fnnews.com/news/201112141617440705">https://www.fnnews.com/news/201112141617440705</a></figcaption></figure><p>　바빠 죽겠는데 사람들끼리 스터디를 어떻게 할 수 있느냐고 누군가 묻는다면 질문 속에 답이 있다고 말하고 싶다. 즉, 바빠 죽겠으니 혼자 무언가를 공부하는데 꾸준하게 지속하기 어려우니 다른 사람들과 규칙을 만들어 가면서라도 스터디를 진행하고 있다.(그렇지 않고서는 도태되는 불안함을 이겨내기 힘들기에)</p><p>　스터디는 참여하는 방식과 직접 만들어 이끄는 방식이 있다. 참여하는 방식은 다른 고민은 스터디를 운영하는 사람이 하게 되니 스터디 주제에만 집중할 수 있다는 장점이 있는가 반면 직접 만들게 되면 반대로 고민할 부분들이 더 많아질 수밖에 없지만 그만큼 최소한의 책임감이 생겨 더 적극적으로 스터디를 진행할 수 있게 된다는 장점이 있다. 그래서 가급적이면 스터디를 직접 만들어서 진행해 보는 것을 추천한다. 물론 성향에 따라 오히려 역효과가 날 수도 있지만.</p><p>　또 언젠가 스터디를 하게 된다면, 그리고 내가 직접 스터디를 만들게 된다면 앞서 말했던 방식으로 스터디를 진행해 볼 생각이다. 그리고 이러한 인연이 계속 지속되어 함께 성장하는 기쁨을 나누고 싶다. 이 글을 빌미 삼아 함께 스터디를 진행하고 있는 <code>Team JSON 상하차</code> 스터디원분들께 감사의 인사를 전한다.</p></div></div>

👨‍💻꿈꾸는 태태태의 공간

다양한 방식으로 스터디를 해왔다. 정말 많은 것을 배웠던 스터디도 있는가 반면에 지나고 보면 시간이 아까울 정도의 스터디도 있었던 것 같다. 직접 만들어 보기도 했고 참여도 해봤던 것 같다. 이런저런 경험들 끝에 작년 중순에 직접 만들었던 스터디 멤버와는 어느덧 반년을 넘어가고 있는데 바쁜 회사 생활을 하면서도 이제까지 지속할 수 있었던 노하우를 공유해 보고자 한다.
그룹 스터디 방식 인원 　다 그런 건 아니지만 기존 회사 분들과 스터디를 할 때면 아무래도 원래 알던 사이라 바빠서 준비를 못 해오거나 불참을 하는 경우에 “그럴 수도 있지”, “괜찮아” 하며 관대해졌던 것 같다. 또는 다양한 의견을 듣자며 10명 이상 진행을 했던 것 같다. 그렇다 보니 스터디 진행에 집중도가 떨어질 수밖에 없었고 모였을 때 이야기하던 사람들만 이야기한다든지, 중도 하차하는 경험도 많았다.
블라인드 글에 첨부한 스터디 참여 설문" 블라인드 글에 첨부한 스터디 참여 설문  　이번 스터디는 직접 ‘블라인드’라는 익명 커뮤니티를 통해 인원을 모았다. 작년 중순쯤 자바 백엔드 관련된 주제를 스터디 하겠다며 나와 비슷한 연차분들 위주로 모으겠다고 글을 작성했더니 신기하게도 3~40명 되는 분들이나 지원하셨고 그중 오프라인 모임을 고려해서 나 포함 6명 만으로 구성을 하였다.(뭔가 서류 전형 인사담당자가 된 느낌;;) 작은 규모 그리고 새로운 분들과 하게 되니 집중도가 오르는 경험을 할 수 있었고 무엇보다 6명 모두 다른 회사라 각 회사를 대표하는 것 같은 느낌이 들어 스터디 참여에 몰입이나 책임감이 더욱 올랐던 것 같다. 또한 한 주제에 대해 각 회사에서의 경험들을 이야기하다 보니 완전히 다른 시각을 얻을 수 있다는 장점도 있었다.
　별거 아닐 수도 있지만(또는 오해가 될 수도 있지만) 남녀 성비, 그리고 나이대(연차)를 최대한 맞추고 싶었다. 그래야 분위기가 적당히 딱딱하지도, 부드럽지도 않을 것 같았기 때문이다. 지금은 여자 한 분 나머지 남자분들이라 초반에 걱정도 되었지만 생각보다 분위기가 잘 흘러가서 다행이라 생각을 한다.
주제와 목표 배워야 할게 한도 끝도 없는 개발자 세상스터디 목표에 따라 집중해야 할 범위를 좁히자!" 배워야 할게 한도 끝도 없는 개발자 세상
스터디 목표에 따라 집중해야 할 범위를 좁히자!  　처음부터 모니터 받침으로 하기 좋을만한 두꺼운 책은 피했던 것 같다. 가볍게, 스터디원들끼리의 친밀도부터 올려야 한다는 생각으로 너무 딥 다이브 한 기술적인 내용보다는 누구나 한마디 정도 할 수 있을만한 가벼운 책부터 시작했다. 그러면서 최대한 참여도를 올리는데 집중했던 것 같다.
　어디까지나 “공부"를 하기 위한 모임이긴 하지만 이 또한 사람과 사람 사이의 “관계"가 중요하다고 생각했기에 모였을 때 바로 스터디 이야기를 하는 것보다 부드러운 아이스브레이킹을 자주 해왔다. 또한 너무 루즈 해지지 않게 1달~1달 반 정도로 끝날 수 있을만한 주제를 선정했다. 아무래도 한 주제가 2~3달 걸리다 보면 집중도가 떨어지는 경험이 많았기 때문이다. 책 한 권을 다 읽었다는 기간을 짧게 가져가면서 작은 성취의 효과를 최대한 활용하고 있다. 이번 회차가 벌써 네 번째인걸 보면 그래도 나름 잘 선택한 방법이라 생각이 든다.
　한 회차가 끝날 즈음엔 다음 스터디는 무엇을 할 것인지에 대해 이야기를 하고 다수가 동의하는 주제를 선정한다. 또한 매 회차가 끝날 때마다 어쩌면 어색할 수 있는 이야기지만 스터디 참여를 그만 둘지에 대해 의사를 분명히 물어본다. (그런데 신기하게도 지금 스터디 모임은 이런 이야기를 하기도 전에 스터디 하고 싶은 주제를 먼저 말씀해주시는 편이라, 어쩌면 스스로 사람 운이 좋다는 생각도 해본다.)
　그저 하나의 책을 읽기로 끝나는 “책 읽기 모임” 이 아닌 만큼 책을 기반으로 하는 스터디 모임일지라도 목표를 분명하게 잡는다. 여기서 목표는 개인마다 다를 수 있다. 가령 스터디 시간에 나왔던 내용을 각자의 팀에 공유 및 반영을 해본다든지, 스터디 내용에 대해 주도적으로 이야기를 하며 다른 분들의 지식을 훔쳐보겠다든지(?

그런 개발자로 괜찮은가 - '그룹 스터디' 편

댓글