[Sku-Deview] 개발자 커뮤니티 팀 프로젝트 회고

 

🧑🏻‍💻 Sku-Deview (개발자 커뮤니티 웹 서비스)

⌛️개발 시기: 2023.05.14 ~ 2023.09.30⌛️

올해 초, 한이음 프로젝트 주제 선정에서 떨어졌었다,,
협업 경험을 너무 하고 싶었기에 해당 팀에서의 한명의 팀원과 연락을 주고 받아 2인으로 팀 프로젝트를 진행할 수 있었다. (운이 좋았다!)

초기에 우리는 한이음 프로젝트 주제였던 TikTok을 레퍼런스로한 개발자 커뮤니티 웹 서비스를 만드는 것이 목표였다. 하지만 2명 모두 개발 경험이 부족하였고, 해당 서비스를 만들기에 무리라고 느꼈기에 우선적으로 개발자 커뮤니티 웹 서비스를 구현하기로 했다. 추후 리팩토링 해줄 때 영상처리 부분을 추가하여 한이음 프로젝트 주제를 구현하기로 하였다.

앞서 말했듯 우선 1차적으로 완료한 프로젝트이고, 배포와 게시판에서의 동영상 처리를 위한 S3를 도입하기 전 코드의 개선사항이 너무 많아 보여서 현재는 중지하였고 리팩토링을 올해 말 부터 다시 시작해줄 예정이다!.. 
나 자신의 부족함을 너무 많이 느끼는 계기가 되었다.. 😂

 

https://github.com/soohykeee/Sku-Deview

GitHub - soohykeee/Sku-Deview

 

 

---

 

 

✍🏻 프로젝트 회고

🙆🏻‍♂️프로젝트를 진행하며 만족했던 부분과 계속 이어나갈 사항

• 커밋 규칙을 정하였던 것이 좋았다. 팀 스터디를 진행하며 커밋 규칙에 대해 들었던 적이 있었기에 이를 적용해주기 위해서 커밋 규칙을 정하였었다. (지키긴 어려웠다..)
  
  
• 같은 학교이고, 2인이라는 소규모 팀 프로젝트였기에 프로젝트 중간부터는 대면으로 회의를 진행했었다. 비대면으로 진행할 때와는 다르게 회의의 퀄리티도 더욱 올라가게 되었고, 혼자서 해결하지 못했던 부분을 대면으로 진행하니 해결하기 더욱 수월했다. (비대면일 때는 회의를 얼른 마치기에 급급했었고, 미루거나 까먹는 일이 많았었다..)
  
  
• 의견 조율 시 대화를 통해 해결했었다. 어떠한 의견이 나왔을 때 서로 강압적으로 나가는 부분 없이 충분한 회의를 통해 진행했었다.
  특히 질문'넌 이거에 대해서 어떻게 생각해?' 라는 질문을 수시로 던지며 의견 조율하기가 수월했다.
  
  
• 질문을 두려워하지 않았다. 팀 프로젝트를 진행할 때 모르는 부분이 있거나 자신이 습득한 지식 공유에 대해 소극적으로 대처하지 않았다. 나와 팀원 모두 개발하다 막혔을 때 어떤 점 때문에 어려운지, 무엇을 잘 모르겠는지에 대해 서로 소통했었다. 혼자 해결하려 끙끙거리지 않았던 부분으로 인해 개발의 속도도 더욱 올라갔었다.

 

🙅🏻‍♂️프로젝트를 진행하며 불편했던 부분과 개선이 필요한 사항

• 앞서 커밋 규칙을 정했었다고 했지만 이를 지키기란 쉽지 않았다. 그렇기에 규칙을 정해서 각자가 개발했던 내용에 대해 추적하거나 어떠한 커밋이 이루어졌는지 명확하게 파악하기 힘들었다. (어설프게 사용해주려다 더욱 혼동만 왔었다..) 또한 git 형상관리에 대한 이해 부족으로 인한 충돌 해결 능력 부족과 branch를 효율적으로 사용하지 못하였다.
  
  
• 느린 피드백, 둘다 학생이고 우선순위가 학교 수업과 과제에 더 초점이 맞춰져 있었기에 개발 속도가 더뎠다. 또한 PR에 대한 속도가 너무 느렸다. 다른 팀 프로젝트를 진행하는 사람들의 조언을 들어보니, PR에 대한 리뷰를 하루, 또는 몇시간 내로 올려주기로 합의를 보았다고 했었다. 이런 식으로 약속을 정한다면 더욱 효율적인 개발을 진행할 수 있을 것 같다.
  
  
• 개발 실력 부족으로 인한 잘못된 설계를 했었다. @OneToMany의 사용으로 인해 N+1 문제가 발생했었다. 애초에 설계를 진행할 때 @OneToMany을 사용해주기로 하였기에 발생했던 문제였다. 이를 해결해주기 위해서 개발 진행중에 @ManyToOne으로 연관테이블을 추가로 생성하여 설계를 바꿨었다. 중간에 설계를 바꾸며 코드를 수정하는데 많은 자원을 쏟게 되었다.
  
  
• PO와 같은 중재자의 필요성을 느끼게 되었다. 2인이라는 소규모 프로젝트였음에도 의견 충돌이 있었다. 정말 사소한 것에도 의견 조율이 필요했다. 몇가지를 이야기해보면 다음과 같다. '클래스 및 함수 명명 규칙', 'service의 경우 interface와 impl을 구분하여 사용할 것인지 아닌지와 그에 대한 이유', 'dto와 entity간 매핑 함수를 어디서 선언하여 사용해줄 것인지', '주석 작성' 등 수없이 많았다.
  이러한 의견 충돌이 발생했을 때, 2인 프로젝트였기에 진행방향을 다수결로 정할 수 없었기에 회의에 쏟는 시간이 많았었다.

 

🤷🏻‍♂️개선이 필요했다고 느낀 사항에 대한 해결책

• 우선 git 형상관리에 대해 공부의 절실함을 느끼게 되었다. git에 대해 공부하는 편이 좋다는 조언을 많이 들었었고, 실천하기 위해서 강의를 결제했지만 미처 다 공부하지 못하고 프로젝트를 진행하였다. ('프로젝트를 진행하며 부딪히며 해결되지 않을까?' 라는 안일한 생각을 했었다.😔)
  
  
• 설계의 중요성을 다시 한번 깨닫게 되었다. 전공 시간에 entity 구조를 개발 중에 변경하게 된다면 큰 어려움과 자원낭비가 있을 거라 수도 없이 배웠었다. 해당 중요성을 직접 체험해보며 뼈저리게 느끼게 되었다.
  
  
• 빠른 피드백이 필요하다고 느꼈다. 위에서 말한것처럼 PR에 대한 리뷰가 빠르게 이루어지지 않으니 개발의 속도에 차질이 있었다. 이를 해결하기 위해 PR에 대한 알림을 켜놓고 하루 또는 몇시간 내로 리뷰를 달아주기로 팀원간의 약속을 정해야겠다.
  
  
• PO를 뽑아 의견 조율이 필요하다고 느꼈다. 아무리 2인 프로젝트여도 PO를 뽑아 의견을 정할 때 더욱 신속하게 정할 수 있도록 해줘야겠다.

 

 

---

 

 

😤느낀점

주위의 개발자들이나, 기업에서 협업에 대한 언급을 자주 하는 이유를 깨달을 수 있었다!! 남들처럼 4인, 5인처럼 다수의 인원으로 진행한 프로젝트가 아니였음에도 불구하고 잦은 의견 충돌과 개발에 대한 스트레스가 많았다. 취직하게 되어 회사에 다니게 된다면 이런 어려운 점은 정말 아무것도 아닐 것이다. 이럴 때 해결할 수 있는 능력도 길러야함을 느끼게 되었다.
또한 혼자서 개발할 때와는 달리 정말 빠르고 효율적인 개발 속도를 경험할 수 있었다. 혼자서 개발하게 되면 스스로에게 다음과 같은 말을 하며 타협하게 되는 경우가 많았다. ('오늘은 이쯤이면 됐다.', '어제 열심히 했으니 좀 쉴까?', '이런 것까지 적용을 해줘야 할까? 너무 어려우니 뺄까?' 등 정말 타협하는 경우가 많았었다..😩) 하지만 팀원과 개발의 범위, 시간과 계획을 세우게 되니 책임감이 생겨 타협할 수 없었다. 나태함을 없애기 위한 좋은 족쇄였다고 느꼈다!
그리고 배움의 공유와 막혔던 부분에 대해 같이 고민하고 해결해줄 수 있는 사람이 생겨서 좋았다. 사람마다 생각하는 것이 다르기에, 문제에 직면했을 때 고민을 통해 다방면으로 해결방법을 찾을 수 있었다. 나 혼자서는 시간이 많이 소요됐을 문제들을 빠르게 해결할 수 있었다.

정말 협업은 스트레스가 많이 받는 일이지만 이보다 취할 수 있는 득이 너무너무 많은 일이라고 느꼈다.

 

 

---