작년 한 해는 스터디에 정말 많이 참여했고, 스터디를 하면서 정말 많이 배웠던 것 같다. 그중에서도 좋았던 스터디들의 특징을 생각해 보니, 특히 배운 점이 많았던 스터디에서 공통점을 발견할 수 있었다. 그 공통점을 소개해 보려고 한다.
스터디의 목표가 있다
스터디 구성원 모두 각자 스터디에 참여한 목적이 있을 것이다. 스터디를 시작하는 날에는 각자 이 스터디를 왜 하는지, 그리고 어떤 것을 얻어 가고 싶은지 얘기를 나눠 보면 좋다. 각자가 어떤 목표를 가졌는지를 알면, 스터디를 어떻게 운영하는 것이 효과적일지 발견할 수 있다.
우리 회사 프론트엔드 챕터에서는 테스트 코드에 관심이 있는 개발자들이 모여서 테스트 코드 스터디를 진행하고 있다. 스터디 첫날에는 스터디 구성원이 모두 모여서 이 스터디를 통해서 어떤 것을 얻어 가고 싶은지 돌아가며 얘기를 나눴다.
각자 얻어 가고 싶은 것들을 정리해 보니 아래와 같았다.
- 어떤 코드가 테스트하기 좋은 코드인지 알고 싶다
- 잘 짠 테스트를 만들려면 어떻게 짜야 하는지 알고 싶다
- 실제 프로덕트에 테스트를 작성해 보고 싶다
- 우리 프로젝트에 테스트가 많이 작성됐으면 좋겠다
얻어 가고 싶은 것들을 토대로 우리 스터디의 목표를 정할 수 있었다.
- 우리 프로젝트의 테스트 컨벤션과 가이드 문서를 만든다
- 팀 내에 테스트 작성 문화를 전파한다
사실 스터디를 진행 계획에 대해 전혀 생각하지 않고 시작했었는데, 스터디의 목표가 잡히니 스터디를 어떤 식으로 진행해야 할지 윤곽이 잡히기 시작했다.
2주 차부터는 테스트의 이론적인 지식을 공부하고, 테스팅 라이브러리의 철학과 테스트하기 좋은 코드에 대해 조사해서 공유해 보기로 했다. 다른 회사나 오픈소스 라이브러리에서 테스트를 어떻게 작성하고 있는지에 대한 사례도 조사해서 공유하는 시간을 가졌다.
이렇게 레퍼런스를 쌓아 둔 다음, 이후에는 업무를 하면서 테스트를 조금씩 작성해 보기 시작했다. 그리고 스터디 시간에 작성한 테스트 코드를 공유하며 코드에 대한 피드백을 주고받고 있다. 이 피드백을 기반으로 팀 내에서 사용할 테스트 작성 컨벤션도 조금씩 작성해 가고 있다.
이처럼 구성원 간의 논의를 거쳐 스터디의 뚜렷한 목표를 잡아 두면 그 목표를 이루기 위한 액션도 자연스럽게 찾을 수 있게 되고, 좀 더 효과적인 방식으로 스터디를 진행할 수 있게 된다. 스터디의 주제는 잡았지만 어떻게 진행하면 좋을지 갈피를 잡지 못하고 있다면, 우선 스터디의 목표에 대해 논의해 보는 것을 추천한다.
실제 사례에 적용해 본다
지금까지 시도해 본 학습 방법 중에 가장 효과적이고 빠르게 학습할 수 있는 방법은 공부한 것을 실전에 적용해 보는 것이었다. 이 방법은 특히 책이나 이론적인 내용을 공부할 때 도움이 많이 된다.
refactoring.guru 사이트의 디자인 패턴을 학습하는 스터디를 진행할 때 이 방법을 활용했었다. 이 스터디는 디자인 패턴 중 하나를 골라 개념을 소개하고, 오픈소스 라이브러리 중에서 해당 디자인패턴이 적용된 라이브러리를 찾아 활용된 방식을 소개하는 식으로 진행됐다.
https://github.com/githru-study/design-patterns/blob/main/behavioral/visitor/visitor.md#사례
사실 주제와 100% 일치하는 사례를 찾기는 정말 어렵다. (GPT에게 열심히 물어봐서 겨우 찾았었다) 하지만 사례를 찾기 위해 실제 프로젝트의 코드를 읽고 파악해 보면서, 이 코드가 주제와 맞는 코드인지를 고민해 보며 주제에 대한 이해도가 훨씬 높아지는 것 같다. 그래서 사례를 발견하지 못하더라도 이 과정에서 배운 점이 많았던 것 같다.
팀원들과 마틴 파울러의 <리팩터링 2판> 책을 읽는 스터디를 진행할 때도 이 방법을 사용했었다. 매주 한 명당 한 기법씩 개념을 정리해서 짧게 소개한 다음, 그 개념에 대한 사례를 소개하는 식으로 스터디를 진행했다. 단, 사례를 소개할 때 우리 프로젝트 안에서 사례를 찾아 리팩터링 기법을 직접 적용해 보기로 했다.
리팩터링 책은 텍스트로만 읽었을 때는 너무 당연하다고 느끼고 넘어간 챕터가 있었던 것 같다. 그런데 책의 기법을 실제 프로젝트에 적용해 보려고 하니, 리팩터링 기법의 목적과 효과를 더 확실히 느낄 수 있게 됐고, 당연하다고 여긴 기법에 대해서도 깊게 생각해 보게 됐다. PR 리뷰를 볼 때도 책에 나온 기법을 떠올리며 더 나은 코드를 제안해 볼 수 있게 됐다.
특히 책에는 반대되는 기법이 여러 가지 나오는데, (ex. 함수 추출하기 vs 함수 인라인하기) 프로젝트의 코드를 보며 과연 이 코드는 두 기법 중 어느 것이 적용되는 게 좋을지에 대해 토론하며 우리만의 기준을 세울 수도 있었다.
책에 아무리 좋은 사례가 있더라도, 그 사례는 실제 프로덕션 코드가 아닐 가능성이 높고 현실 세계의 코드에 비해서 너무 단순한 경우가 많다. 그래서 책의 사례만으로 공부하는 것보다는 실제 프로젝트의 코드 사례를 활용하는 게 학습에 훨씬 효과적인 것 같다.
이런 사례를 찾기 가장 좋은 곳은 본인이 작업하고 있는 프로젝트이다. 같은 주제로 스터디를 하더라도 같은 프로젝트를 작업하는 팀원들과 함께 스터디를 진행했을 때 더 큰 효과를 볼 수 있었다. 만약 팀에 신규 입사자가 있다면 이 방법을 통해서 프로젝트 온보딩 효과도 볼 수 있다.
질문을 잘 활용한다
스터디가 진짜 시작되는 순간은 질문 타임부터인 것 같다. 발표식 스터디를 진행한다면 각 발표에 대한 질문 시간을 마련해 두면 좋고, 발표 중간중간에 끼어들어서 질문하는 분위기를 형성해 두는 것도 좋다. 발표를 들으면서 잘 이해하지 못한 부분이나 궁금한 점이 있다면 질문을 통해 발표 내용을 더 풍부하게 만들어 줄 수 있다.
사이드 프로젝트를 함께 했던 분들과 함께 일주일에 한 번씩 개발과 관련된 주제로 미니 세미나를 진행하고 있다. 이 세미나에서 SSR 서버를 구성해 본 경험에 대해 공유했던 적이 있다. (무슨 내용인지 궁금하다면? → 확인하기)
발표 내용 중에 자바스크립트를 최소화하면서 CSS-in-JS 방식으로 스타일링하기 위해 Linaria를 사용했다는 내용이 있었는데, styled-component를 사용해도 어차피 SSR 시점에 스타일이 생성되니 차이가 없지 않으냐는 질문이 들어왔다. 두 라이브러리의 정확한 동작 방식에 대해서는 대략적으로만 생각해 본 것 같은데, 이 질문을 계기로 더 깊이 생각해 볼 수 있게 됐다. (참고 - Linaria는 서버 빌드 시점에 CSS 파일이 생성되고, 만약 해당 프로젝트에 styled-component를 사용했다면 SSR 렌더링 시점, 즉 서버 런타임 시점에 자바스크립트를 실행하여 스타일이 생성됐을 것이다)
이처럼 질문은 듣는 사람의 궁금증을 해소하는 건 물론이고, 발표하는 사람도 질문에 대해 한 번 더 생각해 보면서 발표한 내용에 대해 더 깊게 생각하게 해준다.
유익한 질문을 더 많이 할 수 있게 하기 위해서, 편하게 의견을 낼 수 있는 분위기를 조성하는 것도 중요한 것 같다. 그래서 스터디원끼리 공부만 하는 게 아니라 어느 정도의 친목도 다지면 좋은 것 같다. 우리 회사는 스터디 식대를 지원해 주고 있어서 스터디를 하는 날에는 저녁을 다 같이 먹고 스터디를 진행하고 있다. 회사 외부 동아리에서 스터디를 진행할 때는 심적 거리감을 좁히기 위해서 만난 첫날부터 반말을 쓰기로 약속하고 진행한 적도 있는데, 편하게 의견을 주고 받는 데 도움이 많이 됐던 것 같다.
마치며
효과적인 스터디의 핵심은 팀원들의 적극적인 참여를 이끌어내는 데 있는 것 같다. 함께 공부하는 과정에 모두가 적극적으로 참여할 때, 스터디의 효과는 가장 커진다. 이 글에서 공유한 스터디 운영 방식이 스터디를 활기차고 효과적으로 만드는 데 도움이 되었으면 좋겠다.
