DEVOCEAN

3개월 동안 진행된 ‘대규모 시스템 설계 기초’ 스터디가 7월 15일을 마지막으로 종료되었습니다. 첫 킥오프 미팅은 4월 22일에 열렸고, 총 6회의 모임을 가졌습니다.

이번 스터디는 ‘가상 면접 사례로 배우는 대규모 시스템 설계 기초’ 책을 교재로 사용하여, 대규모 시스템을 이해하고 실무에 활용할 수 있는 능력을 기르는 것을 목표로 했습니다.

대규모 인프라와 백엔드를 모두 다뤄보는 스터디로 저의 경우 시스템 운영 경험이 많지 않다보니 학습이 쉽지 않았지만, 여러 개발자들이 모여 실무 사례와 경험을 공유하고 토론하는 기회를 가졌습니다.

이를 통해 대규모 서비스 운영에 대한 이해를 넓힐 수 있었습니다.

스터디를 마치며 운영자로서도 느낀 점이 있었는데요. 저는 이번에 처음으로 개발자 스터디를 진행했는데, 학습뿐만 아니라 운영에도 많은 신경을 써야 한다는 것을 알게 되었습니다.

이번 회고에서는 스터디 운영에서 느낀 점들을 정리해 보겠습니다.

스터디 진행 방식

6회 정도 스터디를 이어가면서 진행 방식에 관한 고민을 계속했습니다.

스터디 참고도서가 있었기 때문에 처음에는 가벼운 생각으로 '책을 정리해 가며 진행하면 되겠지?'라고 생각했는데

선정 도서 자체가 깊이 보다는 넓은 관점에서 서술되어 있어 멤버 분들이 단순 리뷰는 스터디로 모자란 것 같다는 의견을 주셨습니다.

때문에, 해당 도서를 발표자 2인을 랜덤 선정하여 리뷰하는 형태로 진행하려던 방식을 수정해야 했습니다.

지난 스터디에서 챕터를 나누어 발표할 때 집중도가 떨어지는 문제가 있었습니다.

그래서 이번에는 모든 참여자가 같은 내용을 공부한 후, 당일 랜덤으로 발표자를 선정하는 방식을 시도해보려 했습니다.

그러나 이 방법 역시 충분하지 않다는 의견이었습니다.

멤버들의 의견을 수용해 1회 차 모임 이후 토론 형태의 모임으로 변경해보았습니다.

챕터 리뷰보다는 스터디를 하면서 궁금한 부분, 잘 이해 안 되는 부분들을 사전에 구글 시트에 질문으로 정리해서 토론하는 것입니다.

토론 방식은 좋은 질문이 있을 때 집중도가 높아지고 배울 점도 많았습니다. 그러나 매번 좋은 질문이 나오는 것은 아니기 때문에,

이 방식만으로는 항상 효과적인 스터디를 유지하기 어려웠습니다. 또한, 실무자들로 구성된 스터디다 보니 각자의 업무가 바빠, 질문을 미리 준비하기 힘들었네요.

결국, 랜덤 발표자가 리뷰를 진행하면서 중간중간 궁금한 점이나 실무에서의 사례를 공유하고, 잘 이해되지 않는 부분에 대해 논의하는 방식으로 전환했습니다.

이 방식은 리뷰를 가볍게 진행하면서도 학습 중 모르는 부분을 더 상세히 다루는 방법이었습니다.

리뷰와 토론을 섞어서 진행한 결과, 스터디 초반 보다 좀 더 나아진 느낌이었습니다.

발언 분산하기

스터디에는 서로 잘 모르는 사람들이 모여 있으니, 몇몇 사람만의 친목 모임이 되지 않도록 주의해야 했습니다.

발언이 특정 멤버에게만 집중되지 않도록 신경 썼고, 다양한 의견이 반영되도록 했습니다.

특히 경력이나 목소리의 크기에 따라 발언 기회가 불균형해질 수 있기 때문에, 가능한 한 모든 멤버가 발언할 수 있도록 노력했는데요.

이렇게 신경 쓴 부분이 멤버들에게도 잘 전달되었길 바랍니다. 서로의 의견과 발언을 존중할 수 있는 그라운드룰 이 잘 설정된다면 좋은 모임이 될 것 같습니다.

사라진 네트워킹 시간

사실 스터디를 시작한 이유 중 하나는 ‘대규모 시스템’이라는 흥미로운 분야를 학습하고자 하는 욕구도 있었지만, 같은 관심사를 가진 사람들과 네트워킹을 하고 싶었던 것도 컸습니다.

다른 직장에서 일하는 분들이 어떻게 업무를 처리하고 어떤 프로세스로 일을 진행하는지, 노하우나 잡담을 나누고 싶었죠. 그러나 평일 저녁에 스터디를 진행하는 것 자체가 쉽지 않았습니다.

저희 스터디는 주로 격주 월요일 저녁 7시 30분에 모였는데, 모임 시간이 늦고 스터디만 해도 2시간이 금방 지나가더군요.

스터디 내용만으로도 2시간이 훌쩍 지나서, 다른 이야기를 할 시간이 거의 없었습니다. 그래서인지 다들 많이 이야기를 나누지 못했어요.

그나마 스터디가 끝나고 집에 가는 길에 잠깐 나눈 대화가 전부였습니다.

그런데 쫑파티 식사 자리에서는 다들 이런저런 이야기를 하며 즐거운 시간을 보냈습니다. 평소에는 말씀이 많지 않았던 분들도 많이 이야기하셨던 것 같아요.

좀 더 커뮤니케이션 할 시간이 많았으면 어땠을까 생각해보았습니다.

다양한 스터디 기회

이번 스터디에는 주니어와 시니어가 적절히 섞여 있었습니다. 특히 주니어 분들 중에는 다양한 스터디 활동을 활발히 하는 분들이 있었습니다.

그래서 이번 스터디에도 참여하신 거겠죠? 저도 그분들 덕분에 제가 몰랐던 여러 커뮤니티에서 다양한 주제로 스터디가 이루어지고 있다는 것을 알게 되었습니다.

SK의 오픈랩 뿐만 아니라 다양한 스터디 활동과 커뮤니티 활동들이 있고 서로 DevRel 관점에서 교류하면 좋을 것 같다는 생각을 했습니다.

미련의 Aim High

스터디 초반에는 매 회차마다 학습한 내용을 실제로 구현해보려고 했습니다.

예를 들어, 1장에서는 시스템 확장 예제를 AWS에 구축하고, 스케일 확장 시 어떤 변화가 있는지 퍼포먼스 도구로 측정해보기도 했죠.

하지만 챕터가 진행될수록 설계 구조가 복잡해지고, 시간도 부족해서 챕터 내용을 정리하는 것만으로도 힘들었습니다.

그럼에도 불구하고 MVP(최소 기능 제품) 하나는 꼭 만들어보자는 생각에, 간단하게 11장 ‘뉴스 피드 시스템’의 일부를 구현해 보았습니다.

실제로 구현해 보니 학습의 깊이가 확실히 다르다는 것을 느꼈습니다.

책에서는 간단한 컴포넌트들로 설계 구조를 제시했지만, 실제 구현할 때는 세부적인 부분들을 어떻게 처리할지에 대해 토론할 기회가 많아지고, 설계에 대한 이해도 더 깊어졌습니다.

학습과 병행해 실제 구현할 수 있는 시간을 좀 더 잘 배분했으면 어땠을까 하는 미련이 남습니다. (그래도 다시 하라면 안 하겠죠?)

2주라는 모임 주기

2주라는 모임 주기는 길다면 길고, 짧다면 짧습니다. 현업에 쫓기다 보니 2주라는 시간이 순식간에 지나가버리곤 했습니다.

멤버분들께 그리고 스스로에게도 빡빡하게 일정을 관리하면 오히려 스터디 참여율이 떨어질 수도 있지만, 2주라는 짧지 않은 시간을 어떻게 더 효과적으로 활용할 수 있었을지 고민하게 됩니다.

지금 생각해 보니, 모임이 없는 한 주는 가벼운 챌린지나 미션을 부여해서 서로 대화를 나누는 기회를 마련했다면 좋았을 것 같습니다.

그런 방식이 서로의 참여도와 학습 효과를 높이는 데 도움이 되었을 것 같네요!

마무리하며

스터디한다고 정신없는 와중엔 몰랐으나 막상 끝났다고 하니 아쉬운 마음이 듭니다.

게으른 저도 정기적으로 모임이 정해져 있으니 한 페이지라도 더 보고 집에서도 관련 자료를 하나라도 더 찾아보려고 했었습니다.

스터디를 안 했을 땐 어떻게든 회사 일을 머릿속에서 지우려고 노력했는데 OpenLab 모임은 '개발'이라는 순수한 호기심을 자극할 수 있었던 시간이었습니다.

그리고 함께했던 멤버 분들도 본인 시간을 할애하여 같이 배우고자 하는 모습을 보여주셔서 더욱 동기부여 할 수 있었네요.

이제 하반기 OpenLab 스터디가 활발히 진행될텐데요.

참여하시는 분들 모두 좋은 경험과 인사이트 얻어가실 수 있길 바라겠습니다!