디프만 - 인프런 스터디 후기 (feat. Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트)

참여 동기

사실 스터디 참여 동기는 디프만 참여 동기와 같은 흐름이었다.

지방에서 개발하며 함께 소통할 사람이 없다는 것. 스터디 같은 것들을 진행해도 나와 목표가 비슷한 사람은 적었고, 마음이 맞는 사람도 적었다. 시간이 지날수록 참여율이 저조해졌고, 스터디를 준비하는 시간에 비해서 스터디에 대한 만족감은 점점 줄어들고 있었다.

그 이유가 나에게 있지 않을까 싶기도 했다. 보통 내가 팀장으로 진행을 했는데, 운영이나 스터디 준비에 많은 시간을 사용했지만, 그에 비해서 스터디의 운영 방식이나 시스템이 효율적인가에 대해서는 조금 부정적인 생각을 했다. 제대로 된 스터디를 참여해본 적이 없기 때문에 정확하게 평가하기도 힘들었고, 더 나은 방향을 찾기도 쉽지 않았다.

이러한 생각 때문에 '좋은' 스터디의 시스템을 경험해보고 싶었다. 디프만을 합격하기 전엔 고려하지 않았지만, 디프만을 합격한 순간에는 스터디를 무조건 참여해야겠다는 생각을 했다. (윤범님의 벨로그를 통해서 스터디가 운영된다는 걸 알고 있었기에 기대하고 있었다 ㅎㅎ)

추가로, 항상 목말라 있던 백엔드 개발자들과 소통할 수 있고 배우고, 토론할 수 있는 그런 스터디에 참여해서 성장해보고 싶었다. 덤으로는 강제성 부여를 통해 끝을 보고 싶었기도 했다. (데드라인이 정해져 있지 않거나 강제성이 없으면 나태해지는 느낌이 없지 않아 있기 때문...ㅎㅎ)

내가 신청을 넣을 당시에는 백엔드 스터디가 이 스터디 하나 밖에 없었다. (나중에 추가 개설되긴 했는데, 운이 좋게도 이 스터디가 제일 마음에 들었다 ㅋㅋ 멤버도 완전 어벤져스였음ㅎㅎ) 

 

스터디 진행

스터디 주제

Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트

Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트 강의 | 김우근 - 인프런

 

우리의 스터디 주제는 인프런에서 김우근님의 강의로 진행됐다. 매주 정해진 범위의 강의를 수강하고 실습, 공부 등을 한 이후 의견을 주고받으며 스터디를 진행하게 되었다.

운영 방식

우리 스터디 장은 이전에 경험이 있으셨던 윤범님이 맡아주셨다. 스터디의 큰 틀과 운영 방식은 그때의 방식을 많이 차용하셨다고 한다.

오프라인으로만 진행하기에는 다들 힘들다고 해서 격주로 온(게더)/오프라인 병행으로 진행되었다.

일시

온라인 : 목요일 오후 10시
오프라인 : 주말

온라인은 목요일 오후 10시를 기본으로 하는데, 미리 논의하여 변경하여 진행한 적도 꽤 있었다.

오프라인은 보통 디프만 정규 세션이 있는 날 정규 세션 전에 진행했다.

진행 시간

기본 1시간, 최대 2시간

진행 시간이 너무 길어질 경우 늘어지고, 효율이 떨어질 수 있기에 최대 2시간을 넘지 않도록 진행했다.

(다만, 스터디가 끝난 후에도 개발 이모저모 시간을 자주 가졌는데, 이게 생각보다 재밌고 너무 유익했던 시간들이 많았다.)

 

세부 사항

체크인/체크아웃

짧은 체크인/체크아웃 시간을 통해 아이스브레이킹을 위해 TMI를 공유했다. 체크 아웃에서는 스터디에 대한 피드백을 주로 나눴던 것 같다.

01

아이스브레이킹의 역할로는 충분했던 것 같다 ㅋㅋㅋ

작성하면서 농담도 하고, 약간의 준비가 필요한 사람들은 재정비 시간을 갖기도 하면서 좋았던 것 같다.

스터디 기록 아카이빙 (서로 공유)

해당 주차에 해당하는 노션 페이지에 미리 스터디 내용을 정리하고 공유했다. 이를 통해서 조금 어려운 주차에는 다른 분들의 자료를 염탐하며 도움을 받기도 했다. (가끔, 다른 분들이 정리한 내용에서 잘 못 된 내용이 있으면 말하기도 하고 좋았다.)

 

프로젝트 내용이나 실습, 코드 같은 경우에는 스터디 레포를 만들어서 각자가 편한 방식으로 했다.

대부분 각자의 브랜치를 만들어서 진행했고, 나는 fork해서 PR하는 식으로 진행했다. (실수하면 부끄러우니까...ㅎㅎ)

 

발표

당일 랜덤 추첨을 통한 발표 진행

노션에 정리한 내용과 깃허브에 정리한 내용 등을 바탕으로 당일 랜덤으로 발표자를 선정하는 방식으로 진행됐다.

미리 선정하면 다른 사람들은 대충해올 수 있다는 점 때문이었다.

이거 덕분에 진짜 매주 조마조마하면서 열심히 발표 준비했던 기억이 있어서 좋은 시스템 중 하나였던 것 같다.

근데, 발표 한 번도 걸린 적이 없다... 뭔가 좋았는데 아쉬워...

 

좋았던 점

사실 그냥 모든게 다 좋았다!

팀원들도 너무 열정적이고, 스터디의 시스템이 너무 마음에 들었다.

 

1. 체크인/체크아웃은 스터디 초반에는 아이스 브레이킹의 역할을 톡톡히 해줬다. 서로 서먹할 땐 활동적으로 참여하기 힘들 수 있는데, 체크인은 빨리 친해지고 활발하게 참여할 수 있게 해 주었고, 체크아웃의 경우엔 스터디가 종료된 이후 놓쳤던 내용에 대해서 다시금 깨닫게 되거나 이후 남은 사람들끼리 추가로 논의를 진행하게 되는 상황도 만들어 주었다.

이런 점에서 아주 짧은 시간이지만 효율이 좋은 시간이었다는 생각이 들었다.

 

2. 아카이빙을 통한 공유는 위에서 잠시 언급했던대로 내가 힘든 주차에 대한 내용을 다른 팀원들이 작성한 내용을 참고함으로써 갈피를 잡거나, 놓친 내용을 파악하고 다시 점검하는 시간을 제공해 주었다.

또한, 추후에도 언제든 노션에 접속하면 복습을 할 수 있다는 점도 좋았다. 강의를 수강하면서 이전에 내용이 필요할 때가 있었는데, 이전 스터디 내용이 아카이빙되어 있어서 참고 자료로서의 역할을 많이 해주었기 때문이다.

 

3. GitHub 레포 운영을 통해서 서로의 코드를 볼 수 있는 점도 좋았다. 나는 따라가기에 급급했기에 스터디 당시에는 강의에 나온 내용에서 크게 벗어나지는 못했던 경우가 많았다. 하지만, 다른 뛰어난 팀원분들은 강의를 따라가는 것에서 벗어나서 더 나은 코드를 작성하기 위해 고민하고 이를 적용해서 스터디에 참여하는 경우가 있었다. 이런 내용들을 말로만 듣는 것이 아니라, 깃허브에 접속해서 코드로 살펴볼 수 있다는 점이 너무 좋았다.

 

4. 당일 추첨을 통한 발표는 나태해지는 것을 방지하는 데 큰 역할을 했다. 스터디 기간 동안 유럽에 머물렀던 적이 있는데, 이때 놀러 다니고 싶다는 생각에 대충 정리할까 고민했던 적이 있었다. 이때 아마 '추첨'이 아니었다면 '내 차례가 아니니까 괜찮겠지?'라는 생각에 대충 하지 않았을까 생각하고 있다.

이때가 아니더라도 매번 발표를 하게 될 수 있다는 점 때문에 더욱 열심히 자료를 정리하고 공부했던 것 같다.

 

아쉬운 점

솔직히 없다.

아쉬운 점은 나에 대한 아쉬움만 남아있다.

'조금 더 열심히 참여했으면 어땠을까?' 라는 생각과 위에서 언급했던 내용 중 강의를 따라가기만 하는 것이 아니라 '더 나은 코드를 작성하기 위해 고민하고, 이를 적용해 보는 것' 부분에서 조금 아쉬움이 남는다.

지금 스터디 정리글을 작성하며 이전 스터디 내용들을 정독하고 있는데, 확실히 시간이 지난 후에 보니 '레거시'가 되어버린 나의 스터디 내용들에 대한 아쉬움이 남는다.

 

 

얻은 점

스터디를 통해 얻은 점

동기 부분에서 언급했던 '좋은 스터디' 참여 경험을 얻었다는 것 자체에서도 의의가 있었다.

다시금 내가 운영했던 스터디들의 운영 방식과 시스템에 대해서 고민해 보게 되었고 아쉬운 점이 많았다는 것을 알게 되었다. 예를 들어서, 매주 발표자가 주제를 정해서 발표하는 걸 선호했었는데, (스터디 내용이나 성향에 따라 다를 수 있지만) 이는 다른 사람이 맡은 주제에 대해서 이해도가 아주 낮다는 단점이 있었고, 자신의 차례가 아닐 때엔 확실히 참여율과 집중력이 낮았다는 걸 알게 되었다.

그런 부분을 알게 되고, 나은 방향을 깨닫고 고칠 수 있게 되었다는 점에서 좋았다.

 

부가적으로 스터디를 진행하며 디프만 내에서 다른 팀의 서버 파트원들과 소통하고 개발 관련해서 논의할 수 있다는 점에서 좋았다. 내가 겪어 보지 못했던 경험을 듣는 것은 물론, 내 경험을 얘기하고 조언을 받거나 그 반대의 상황을 겪어보면서 시야를 넓히는 데에 도움이 되었던 것 같다.

 

강의를 통해 얻은 점

테스트 코드 자체에 대해서 배웠다는 점도 만족하고 있다. 이전에는 테스트 코드를 작성하는 것에 막막함을 느꼈었는데, 테스트 코드에 익숙해지고, '테스트 코드를 작성하기 좋은 코드와 설계'를 하는 방법을 배운 것도 도움이 되었다.

테스트 코드를 작성하기 어렵다면 이는 '테스트 코드가 보내는 경고'라는 부분이 와닿았었다. 리팩토링을 진행하며 기본적으로 이전과 같은 동작을 하는지 증명해야 했다. 이를 위해서 테스트 코드가 필수라고 생각했지만, 테스트 케이스를 만들거나 실제로 코드로 작성하는 것이 쉽지 않았다. 강의를 수강하며 이전에 내가 작성했던 코드와 설계 자체에서 문제점이 있는 경우가 있다는 것을 알게 됐고, 테스트 코드를 작성하기 좋은 설계를 하는 것에 대해서도 고려하게 되었다.

 

누군가에겐 작은 내용일 수 있지만, 나는 이번 스터디에서 아주 큰걸 건진 게 있다.

바로, '의존성을 역전하고, Fake를 작성해 이를 통해서 테스트를 작게 만드는 것'이다.

이 내용은 홈페이지와 쇼핑몰을 만드는 외주를 진행하며 큰 도움을 받았다. 이전에는 테스트 코드가 매우 무겁고 의존적이었는데 강의해서 배운 내용을 바탕으로 테스트를 리팩터링 해서 5-10배 큰 폭의 테스트 코드 성능 향상을 이뤄냈다.

 

마무리

이번 스터디를 진행하면서 배운 내용이 엄청 많았던 것 같다.

다른 백엔드 개발자들과 소통할 수 있는 시간을 가졌다는 점에서도 만족스러웠고, 디프만을 진행하면서 팀 프로젝트가 바빠서 다른 팀의 개발자들과 소통할 수 있는 시간이 많지 않았는데, 스터디를 참여하면서 그런 부분을 많이 채워서 좋았던 것 같다.

강의도 질이 좋은 강의였고, 스터디도 만족스러웠다. 이번 스터디 경험이 너무 좋았는데, 이게 멤버들도 다들 잘하는 사람들이고, 스터디가 상위권에 들만큼 좋았던 걸 알고 있어서 다음 스터디에 만족할 수 있을지 걱정이 조금 되는 것 같다. (중도 이탈자나 포기자가 없는 것부터가 말 다한 것 같기도...?)

마지막 뒷풀이 사진 - 너무 좋았던 우리 스터디원들...! (나현님과 한음님은 이슈로 인해... 뒷풀이 사진에 없다ㅠㅠ)

 

너무 좋은 기억을 남기며, 이 스터디는 이렇게 마무리되었다...!