최종융합프로젝트-POV_회고

GitHub - ureca-final/pov-backend: LG U+ 유레카 1기 백엔드 비대면 융합 프로젝트

3줄 요약

• 근거있는 기술도입을 하는 개발자가 되자. 현업에서는 이러한 생각과 데드라인 사이를 잘 조율해야한다.
• 다른 분야의 사람들과 협업하기 위해서는 내가 개발하는 것만큼 노력해야한다. 내가 편하고 싶으면, 타인을 편하게 해줘야한다.
• 멘토링 양날의 칼날...

LG U+의 유레카 과정의 마지막 프로젝트, 가장 큰 프로젝트, 최종융합 프로젝트에 대한 회고를 작성한다.

기간 : 2024.11.12 ~ 2024.12.24 (6주)

팀원 : 백엔드 4명, 프론트 3명

구현 기능(제시된 세부 과업)

• 영화 리뷰 공유
• 맞춤 영화 추천
• 클럽 서비스
• 알림 서비스
• 시사회 응모 및 결제

---

이번 프로젝트를 진행하면서 가장 기억에 남는 점은 근거있는 기술 도입이다.

 

지금까지 일단 기능을 만들고 그 다음 리팩토링 해야지! 라고 생각하며 개발했었다. 덕분에 다른 사람들에 비해서는 빠르게 기능을 만들어냈고, 스스로도 뿌듯했던거같다. 마치 개발을 '잘' 해서 빠르게 기능을 만들었다고 생각했다.

 

하지만, 이번 팀원들 덕분에 개발을 하기전 생각하는 방법을 터득했다.

지금까지 DTO를 만들 때는 class를 사용했다면 이번에는 record 타입을 선택했다.
테스트코드를 작성할 때 메소드명을 객체_테스트내용 식으로 한글로 작성했다.
controller와 service 메소드명에서 restful한 네이밍을 구분했다.
여러 서비스가 겹치는 상황에서 퍼사드패턴을 선택했다.
실제 서비스를 근거로 MAU를 예측하여 메모리를 선택했다.

 

이 외에 수많은 컨벤션과 규칙이 있었고 이런 내용 하나하나를 선택할 때 

• 왜 이렇게 사용해야하는지
• 이렇게 사용안하면 안되는지
• 현실적으로 지금 도입이 가능한지

등의 내용을 서로 의논했다.

 

근거있는 기술 도입을 위해 dto 네이밍과 같은 어쩌면 사소할 수 있는 컨벤션 조차 30분정도의 회의가 이어졌다.

물론 이런 회의로 인해 결과적으로 우리 프로젝트 자체의 완성도가 떨어졌다고 말할 수 있다. 실제로 시간이 매우 부족했고, 이것이 수상에 영향이 갔을 수 있다.

 

하지만 나중을 고려했을 때 

몇천줄씩 되는 기능적 코드 vs 수많은 시간을 갈아넣은 코드 몇줄

을 선택하라면 당연히 후자이다. 

 

이번 프로젝트는 수상 관점에서는 불완전했다. 그러나 이 시간 덕분에 생각하는 개발자가 되는 연습을 할 수 있었다.

---

이번 최종 융합 프로젝트는 백엔드와 프론트 함께 프로젝트를 진행했다.

 

저번 종합프로젝트때 프론트때문에 댕고생을 해서 프론트와 함께 하는 프로젝트가 너무 감사했다.

 

하지만, 이것또한 만만하지 않았다.

우선 무슨 기능이 들어가고 어떤 api가 호출될지 다 알고 있던 기존 프로젝트와 달리, 이번에는 모든 팀이 해당 내용을 공유하고 있어야했다.

단순히 리뷰에 이미지를 올리는 방식에서도 프론트 개발자와 백엔드 개발자가 생각하는 방법이 달랐고, 이를 통일화하지 않은 대가는 너무 피곤했다.

 

이를 위해 백엔드는 swagger을 작성하여 api 문서화를 진행했다.

사실 우리팀은 api 관련된 내용, 기능적 내용을 모두 노션에 정리하고 있었기때문에 굳이 swagger가 필요한가? 했었는데, 실제로는 프론트 개발자들이 swagger을 크게 신뢰..? 하는걸 보고 더 꼼꼼하게 내용을 반영했다.

 

그리고 내가 담당한 기능의 프론트를 개발하는 팀원과 계속 소통했다. 다행스럽게 이번 프론트 팀원들과 안면이 있었고 그 덕에 더 쉽게 말을 건낼 수 있었던 것 같다.

---

이번 프로젝트는 현업자 멘토링이 유독 많았다.

2-3주에 1번 LG U+ 현업자의 멘토링, 2주에 1번씩 외부 현업자 멘토링이 있었는데 이러다보니 1주일에 1번씩 멘토링이 진행되었다.

 

현업자에게 직접 멘토링을 받는건 정말 귀한 시간임에 틀림없다.

실무경험으로만 알 수 있는 협업 내용, 풍부한 사전지식등등.... 특히 기술적으로 고민을 많이 했던 우리 조는 멘토링 시간을 효율적으로 사용할 수 있었다.

 

하지만, 멘토링 시간이 너무 자주 주어지다보니, 멘토링을 위한 준비 시간을 따로 가져야했다.

안그래도 시간이 부족한데 멘토링을 위한 준비를 따로 진행하는게 부담스러웠고, 궁금증을 해결하기 위함이 아닌, 멘토링 시간을 때우기 위한 질문을 만든다는게 역설적이었다.

 

또한, 성향이 다른 여러 현업자 분들에게 멘토링을 받다보니, 하나의 이슈에도 다른 피드백을 받았다.

이 부분은 멘토링의 아쉬움보단,
나 스스로 조금 더 기술적으로 성숙했으면, 귀한 피드백들 중에 판별하는 능력을 가지고 있었을 텐데 그러지 못하고 갈팡질팡했던 시간이 아쉽다.

 

결론

이번 프로젝트 시작할 때 기술적으로 성장이 목표였는데, 좋은 팀원들과 많은 논의를 하면서 개발을 할 때 생각하는 힘을 길렀다.

생각할수록 이 기술을 왜 사용해야하는지 정리할 수 있었고, 이러한 점에서 기술적 성장을 달성한 것 같다.