한국 스칼라 유저그룹인 라 스칼라 코딩단에서는 계속해서 스터디를 진행하고 있었었는데 후기를 남기는건 이번이 처음인듯 하다.(스터디도 후기를 계속 남기려고 하지만 이상하게 잘 안되더라는...) 스터디를 시즌으로 구분해서 진행하는데 벌써 5시즌이다. 지난 3,4시즌에서도 Programming in Scala를 진행했었는데 5시즌에서도 Programming in Scala(이하 PiS)로 진행을 했다. 두껍다는 것 외에는 굳이 다른 스칼라 책을 볼 필요가 없다고 느낄 정도로 좋은 책이니까...

라 스칼라 코딩단은 오랫동안 초기 멤버만 활동을 했기 때문에 스터디도 대부분 우리끼리 정하고 우리끼리만 모여서 진행을 하곤 했다.(물론 공지는 했지만 아무도 오지 않았다.) 그러다가 이유는 알 수 없지만 작년 후반기부터 새로운 멤버들이 많이 참여를 하게 되면서 스터디에 대한 요구가 높아졌지만 진행은 잘 되지 않았다. 일단 바로 얼마전에 PiS를 스터디 했기 때문에 또 하고 싶진 않은 마음이 있었기 때문일 것이다. 그래서 신규멤버 중심으로 스터디가 진행되었으면 하는 마음에 쓰레드가 자주 오갔지만 실제적으로 진행이 되지 않았고 스터디 주도는 잘 안하는 편이긴 하지만 PiS를 봤어도 1년 넘게 봤기 때문에 앞에는 다 까먹었고 다른 교재가 있는 것도 아니라서 이번엔 총대를 메고 진행을 하기로 했다.

그래도 그룹 스터디는 여러번 했기 때문에 이번에는 몇가지 시도를 해봤다.

• 장소 마련을 위한 회비를 걷는다. 예전에는 무료로 이용할 수 있는 장소를 찾아서 점프하면서 진행했었는데 이제는 그것도 어려워서 돈으로 해결하기로 했다. 그래서 Toz같은 곳을 이용하기로 했고 매달 첫 모임때 돈을 2만원 정도씩 걷기로 했다. 매달 걷기로 한 이유는 모임이 길어질 것이므로 초기에 너무 많은 부담을 주지 않으려는 의도였고 스터디가 진행되면서 인원이 계속 변하기 때문에 매달 첫 모임때만 걷기로 했다. 누군 내고 누군 안내고 체크하는건 귀찮은 일이기 때문에 첫주 안나오고 두번째 주에 나온다고 쫓아가서 수금하진 않는다. 의도적으로 그렇게까지 하는걸 막기 위해서 관리하느니 관리비용을 줄이겠다는 의도였지만 중간에 NIPA의 커뮤니티 지원을 알게되어 2-3번 정도의 모임후부터는 NIPA의 지원을 받게 되었다. 이건 무척 좋은 일인데 돈을 더이상 걷지 않아도 되는건 둘째치고 장소 예약을 위해서 매주 이번주 예상 인원을 파악해서 예약하는게 보통일이 아니기 때문에(이 예상이 실패하면 금액에 대한 리스크가 운영하는 입장에선 무척 크다.) NIPA 덕에 무척 편하게 이용을 했다.
• 발표중심으로 하지만 스터디를 하지만 발표자를 미리 선정하지 않는다. 스터디를 꽤 해봤지만 한 명이 이번주 진도에 대한 내용을 발표하고 나머지는 들으면서 질문하거나 토론하는 등의 방식이 제일 무난하다. 다른 방법들도 있지만 모두가 적극적으로 참여하지 않는다면 좀처럼 쉽지 않다. 하지만 이 방식의 문제는 발표자는 책임이 있으니 열심히 공부하게 되지만 나머지는 시간이 지날수록 손놓게 된다는 점이다. 그리고 개인적인 일이 생겨서 발표하기로 된 주에 못나오게 된 경우이 공백도 너무 커서 대처하기가 어렵다. 그래서 택한 방법이 발표자(우린 진행자라고 불렀다.)를 스터디 시작할때 사다리타서 정한다는 것이었다. 공부는 모두 해오고 한명이 발표하는 것이 아니라 한명이 진도에 따라서 진행을 하면서(진행자이므로 다른 사람 시키거나 해도 되지만 아무도 그렇게 하진 않음.) 다같이 보자는 의도였다. 아주 잘 됐는지는 모르겠지만 스터디가 진행되는데 큰 무리는 없었기에 만족하고 있다.
• 공부한 내용을 [위키](https://github.com/codeport/scala/wiki/Programming-in-scala)에 정리한다. 앞의 방식으로 진행자를 현장에서 뽑아서 진행하려면 미처 공부 못해온 분도 진행을 할 수 있도록 어떤 정리된 내용이 필요했다. 이미 3,4시즌에 대충이나마 정리한 위키가 있었기에 거기에 내용을 채우는 방식으로 진행을 했다. 누가 진행을 하게 될지 모르므로 다같이 정리를 하도록 하는 의도였고 이렇게 정리된 내용이 있으면 다른 사람의 공유는 부차적이고 일단 공부한 사람들이 나중에 잊어버린 내용을 다시 공부할 때 참고하기 좋다고 본다. 물론 뒤로 갈수록 위키 정리양은 약해지긴 했지만 주업도 아닌 스터디에 너무 큰 부담을 주는건 아니라고 보므로 괜찮다고 생각한다.
• PiS 스터디를 두번으로 나누어서 진행한다. 경험상 한 스터디가 6개월이 넘어가면(매주하던 격주로 하던) 엄청 힘들다. 개개인의 피로감이 커지고 진행도 힘들고 참여율도 많이 떨어지게 된다. 더군다나 PiS는 책이 꽤 두껍기 때문에 매주 한장씩 나가도 6개월 이상이 필요하고 중간에 이런 저런 일을 생각하면 1년은 걸릴것 같았기에 두번으로 나누기로 했고 뒷부분은 스칼라 내부 내용이라 빼고 20장정도까지만 나가는 걸로 해서 10장씩 나누어서 진행하기로 했다.(실제로는 12장까지 진도를 뺐다.) 초반에 고려한 타이밍은 아니지만 마침 목표한 일정이 휴가시즌을 앞두고 끝나서 쉬기 적절한 타이밍인것 같다.(사람들도 약간씩 지친것 같고..)
• 실습과 이론을 병행한다. 스칼라 스터디를 하면서 매번 반복되는 이슈 중 하나가 책을 보다보니 실제 코드를 잘 못짜겠고(업무에서 쓰는게 아니라) 코드를 짜는 스터디를 하면 이론을 몰라서 또 못짠다. 그래서 PiS 스터디와 실습을 병행해서 하고 싶었고 실습을 오일러 프로젝트로 하는 걸 제안했다. 다같이 프로그램을 하나 짜는건 좀 어렵고(중간에 끼기도 힘들고) 알고리즘 풀이는 스칼라 작성보다는 알고리즘을 고민하는데 시간을 다 보내게 되서 오일러를 선택했다. 오일러는 대부분이 익숙한 자바로 된 풀이가 이미 존재하고 있기 때문에(물론 다른 언어도 거의 다 있다.) 기본 정책은 자바로 짜여진 코드를 스칼라로 포팅하는 수준으로 잡았다. 알고리즘 고민 대신에 스칼라로 어떻게 작성하기를 바랬고 같은 코드를 보고 다른 사람들은 어떻게 작성하는지 비교하면서 볼 수 있기를 바랬다. 뒤로 갈수록 사람들이 각자의 알고리즘으로 풀어오면서 재미도 꽤 있었다. 2차 스터디에는 어떻게 할지 아직 안정했지만 나쁘지는 않았다고 본다. 오일러 문제를 푸는 주간에는 참여율이 낮아진다는 가설은 결국 해결되지 않았지만....

이번 스터디는 유부남들이 많아서인지 일요일 아침 스터디를 원하는 사람이 많아서 일요일 아침 10시에 스터디를 했다. 보통 주말에는 오후까지 자는게 일상인 나는 특히 아침에는 쥐약인 편이라 무척 힘들었고 뒤로 갈수록 지각이 많았졌다.(거기에 두번이나 제꼈다.) 그래도 운영진으로 자원해주신 이승우님의 백업(무한 감사를..)으로 스터디는 원활하게 진행이 됐다.(운영자가 게을러서 힘들;;;)

그래도 첫 모임때는 20명이 좀 넘었었는데 마지막까지 남은 사람이 10명이 약간 넘으니까 이정도면 엄청난 참여율이라고 생각된다. 짧은 스터디도 아니고 4월부터 7월까지 4달동안 진행한 스터디인데 50%나 놀라울 정도다. 다들 관심도 많고 적극적으로 해주다 보니 매끄럽지 못한 운영(?)도 잘 넘어간 것 같다. 특히 초반에 진도빼고 남는 시간을 통해서 자발적으로 발표했던 내용들은 재미있었다. 아침에 일찍 일어나니 알찬 주말을 계속 보내긴 했지만 그래도 좀 쉬자.. ㅎ