지난 2년 간, 꾸준히 성장하기 위한 시스템들을 구축해왔으며, 이번에는 그 중 하나인 ‘스터디’에 대해 소개하고자 합니다.
현재까지 페어 프로그래밍, 알고리즘, 면접, 블로깅, 프론트엔드 CS 등 10개 이상의 스터디를 직접 운영을 해보았고, 지금도 진행 중이다.
내가 스터디장이 아니라 스터디원으로써 참여했던 스터디로는 이력서 스터디, 책 ‘모던 자바스크립트’ 스터디, 면접 스터디 등이 있다. 하지만 이력서 스터디를 제외한 모든 스터디는 끝까지 운영되지 못하고 중간에 끝이 났다. 팀원들의 일정이 계속해서 맞지 않아 결국 파토가 나거나, 하나 둘씩 스터디원이 빠지기 시작하더니 자연스럽게 스터디가 소멸되는 경우도 있었다.
여러 차례 스터디의 실패를 겪고, 직접 스터디를 만들어야겠다고 생각했다. 예전에 프로젝트를 한 번 리딩해봤던 경험을 살려서 스터디도 잘 운영할 수 있을 거 같았다.
내가 가장 재밌게 했던 스터디지 않을까 싶다. 페어 프로그래밍은 스터디보다도 프로젝트 협업 방식 중 하나에 가깝지만 주기적으로 시간을 두고 실천했다는 점에서 스터디에 분류하였다.
Gloddy프로젝트를 시작한 지 얼마 안되었을 때이다. 팀원과 나름 컨벤션을 정하고 개발을 시작했지만, PR을 올릴 때면 코드 컨벤션이 맞지 않는 부분이 계속 발견되었다. 이에 페어 프로그래밍을 제안하였다. 한 명은 어떻게 설계를 하면 되는 지, 어떤 컨벤션으로 작성하면 되는 지 이야기를 해주는 네비게이터 역할을 하였고, 한 명은 키보드를 통해 네비게이터의 가이드 대로 개발을 하는 드라이버 역할을 하였다. 만약, 드라이버가 네비게이터 생각에 다른 의견이 있다면 언제든 지 이야기하여 열띈 토론을 펼쳤다.
페어 프로그래밍을 함으로써 가장 좋았던 점은 언제든 지 토론을 할 수 있다는 것이었다. 혼자 개발할 때는 무심코 넘어가는 것들이 많다. PR을 할 때는 그 코드의 결과물만 보고 글로 논의를 하게 된다. 실시간으로 논의할 수 없다는 점과, 과정에 대한 이야기를 하는 데에는 어렵다는 한계가 있다. 페어 프로그래밍을 하기에 앞서 팀원과 1시간을 약속했으나 너무 재밌고, 서로의 개발 과정에 대한 생각을 알아가는 과정이 흥미로워 3-4시간동안 했던 기억이 있다. 또한 페어 프로그래밍 덕분에 Gloddy 프로젝트의 초기 설정 과정에서 프로젝트의 전반적인 설계, 코드 컨벤션에 대해 맞출 수 있었다.
하지만 같은 작업을 해도 시간이 상당히 오래 걸린다는 단점이 존재한다. 그래서 프로젝트 개발할 때마다, 혹은 매일 진행할 수는 없다고 생각하였다. 그래서 매 주 프로젝트 팀원들과 모각코 시간이 있었는데, 그 때 3시간 정도 페어 프로그래밍을 진행하였다.
여러 면접과 코딩테스트를 치르며 한없이 부족함을 느끼고, 꼭 채워야겠다고 느낀 것들이다. 잘 못하는 것이여서 그런 지, 혼자 하기에는 도저히 동기가 생기지 않았다. 그래서 같은 목표를 가진, 열정적인 팀원들과 같이 준비를 하면 어떨까 해서 시작하게 되었다.
면접 스터디는 한 명이 면접자가 되고 나머지는 면접관이 되어 면접을 진행한다. 그리고, 서로 피드백을 주고받는 방식이다. 알고리즘 스터디과 프론트엔드 CS스터디, 블로깅 스터디는 한 명씩 발표자가 되어 각자 준비한 문제/주제/아티클에 대해 발표를 진행한다. 그리고 다른 팀원들이 이에 대한 피드백을 주는 방식이다.
사실, 스터디 특성상 ‘피드백’면에서는 나보다 실력이 뛰어난 개발자가 있지 않다면 얻어가는 것이 적을 수 있다는 점이 있다. 피드백이 도움이 되기 위해서는 날카로운 지적이나 새로운 의견에 대한 제시가 있어야 하기 때문이다. 하지만, 피드백 외에도 얻어갈 수 있는 점들이 많다. 스터디의 장점 에서 더 자세히 이야기하겠지만 메타인지, 다양한 시각 그리고 강제성이라는 스터디의 강력한 장점이 있다.