[OrientalUnity] HookKiller팀의 OrientalUnity프로젝트 회고

목차

 

1️⃣ 프로젝트 소개

프로젝트의 시작을 알리는 아티클에서 적었지만 또 적어보면... 

 

번역을 기반으로 피해자와 가해자들의 모임인 한.중.일이라는 언어도 틀리고, 역사가 꼬여있는 세개의 국가를 주제로 동북아 커뮤니티이다

 

👉 깃허브 코드 

 

아래 이미지처럼 글을 남길 경우 한국어, 영어, 일본어, 중국어 총 4개국어로 글들이 자동번역되어 타 국가의 사용자와 교류할 수 있는 커뮤니티다.

---

2️⃣ 구현에 사용된 기술스택

Front의 경우에는 React를 채택하였고, 메인으로 집을만한 라이브러리는 다국어의 페이지를 만들기 위한 i18next과 게시물의 내용을 HTML로 받기 위한 React Quill을 짚어볼 수 있을 것 같다. 

 

Back의 경우에는 Java + Spring을 기본으로 채택하였고, 추가적으로 짚어볼 만한 라이브러리는 Security와 JPA를 사용한 정도로 보인다.

 

사용한 외부 API의 경우에도 매우 핵심이라 짚을 만한건 Naver Cloud Platform의 Papago Translation이라 할 수 있다.

---

3️⃣ KPT방식의 회고?

어떻게 이글을 작성해야 좋을까 계속 생각하면서 보게된게 KPT회고란걸 알게 되었다. 

Keep, Problem, Try의 약자로 Keep은 만족을 했고, 계속해서 이어나가고자 하는 요소, Problem은 내가 불편하게 느꼈고 개선이 필요하다 생각되는 부분, Try는 Problem에 대한 해결책과 당장 실행가능한, 다음회고때 판별이 가능한 요소를 정의한다고 한다.

 

근데 나는 KP만 할 수밖에 없는 환경같은데..?

 

쩃든 KP에 대해 적어보도록 하며, Problem에서 기술적인 이슈 문제는 블로그에 포스팅한 내용에 대해서는 적지 않으려 한다..(이미 블로그에 그와 관련된 내용을 다 포스팅 한 것이기 때문)

 

1. Keep

• 리뷰를 하면서 팀원들한테 지속적으로 "왜 그렇게했어?"를 물고 늘어졌었다. 팀원들의 성장이 눈에 띄게 빠르게 올라가는걸 보면서 정말 기뻤다. (다라고 말할 수는 없겠지만...)
• 최대한 매일 일일스크럼을 하려고 했다, 그러면서 팀원들한테 자신이 배운 것, 익힌것을 스크럼시간에 다른 팀원한테 전파하도록 시키고자 하였고 그 시간이 매우 소중했다.
• Reference가 없는 서비스를 내가 직접 사용해 보면서 Reference를 만들어 버린 것. (NCP의 ELSA사용방법)
• Docker를 바탕으로 실행하는 Spring Boot Application에 PinPoint Agent를 실행하는 방법을 알게 된 것
• 서버의 모든 인프라 환경을 Private로 구축에 성공한것

2. Problem

• k8s환경을 구축해보지 못했던 것
• 부하테스트를 진행해보지 못한 것
• Front와 React의 지식이 BackEnd에 비하여 많이 부족했던 부분
• BackEnd에서의 아쉬웠던점 (일부로 하지 않은 부분이며, 팀원이 못따라 올 것이라 판단하여 하지 않음)
  • TestCase의 작성을 하지 못한 것
  • QueryDSL을 사용해보지 못한 것
  • Swagger나 Spring Rest Docs를 사용하지 못한 것
  • BackEnd도 다국어 처리를 해야했는데 하지 못한 것
  • RestAPI에서 Entity를 반환하는 기능들이 많다는 것?
• FrontEnd에서의 아쉬웠던점
  • 상태관리 Redux와 Redux Saga의 개념이 너무 부족했던 것
  • 한개의 컴포넌트에 어쩔 수 없이 모든 기능을 다 떄려박을 수 밖에 없던 것
• Jenkins에서 Pipeline을 통한 배포를 하지 못한 것

 

이정도 인것 같다..

---

4️⃣ 프로젝트를 하면서 느낀 점?

사실 매번 PM을 어쩔 수 없이 맡게 될 때마다 불편했다. 나도 그냥 팀원으로써 기능구현을 하고 PM마음고생시키면서 같이 작업하는게 더 재밌는데 말이다.

 

어쨋든 토이프로젝트를 할 때면 같이 하게 되는 사람들이 다들 PM이 되는 것도 기피하고 실제 자신의 문제를 털어놓거나 자신의 의견을 강하게 밀어주는 사람들이 없었고,  그냥 어떻게든 될대로 되겠지 하면서 의욕없어하는 팀원들을 보면서 늘 재미가 없었고 불편했다. (내가 팀운이 없는건지, 팀원들한테 의욕이 없어지도록 만드는건지 모르겠는데 매번 이러니까 후자같아보이기도 하다..😭😭😭😭)

 

그래서 실력과 상관없이 마음맞는 사람끼리 하고자 싶어 했고, 심지어 잘 안되더라도 다들 끝까지 노력하는 모습을 보면서 처음으로 타인과 같이 하는 프로젝트가 재밌었었다.

 

또한, 내가 재직할때 당시 팀장이 날 보던 모습이 이러지 않았을까 했던 생각도 많이 들었었고, 아 시니어의 고충이 이런거구나를 얄팍하게나마 느낄 수 있던 시간이었다.

 

팀원의 전체 코드리뷰를 해주고, 코멘트를 달아주면서, 기능에 대해서 생각하고, 기능구현 못한걸 119마냥 가서 구급대처럼 구현해주고, 팀원들한테 내 말에 대한 신뢰를 주고자 했던 행동들을 생각해보면 정말... 많은걸 경험해 볼 수 있고 느꼈던 프로젝트다. 🤣🤣🤣🤣🤣

 

 

그리고 마지막으로 내 탱킹과 말빨이 그래도 나쁘지 않다는걸 많이 체감했었다.

---

5️⃣ 아쉬웠던 점?

되돌아 보면, 치열하게 싸우면서 논쟁을 했던 시간이 거의 없었다. 이게 좀 아쉬웠던 점이지 않을까 싶다.

 

매번 이슈가 발생하면 CS적으로, 코드적으로 문제를 추적하면서 이슈를 바로바로 해결했었다 보니 논쟁을 펼칠 일이 안생겨 버린게 아쉬웠지 않았나 생각이 든다.

 

또한, 프로젝트의 기간이 짧았던 것도 너무 아쉬운 요소라고 생각했다.

실제 구현해보고 싶은 것은 너무 많았는데 기능구현이 2주였나밖에 되지를 않았다. 이게 가장 아쉬웠던 요소라 생각이 지금은 든다.

---

6️⃣ 추가적인 리팩토링이 필요한 것?

 

FrontEnd의 코드를 전체적으로 기능단위를 잘게 잘라서 제작하는것과, KP의 Problem에 적은 BackEnd의 코드적인 부분을 좀 건드려보면 좋지 않을까 싶다~

---

7️⃣ 참고한 Reference

• KPT회고에 대하여
  • https://brunch.co.kr/@jinha0802/35