패스트캠퍼스X야놀자: 백엔드 개발 부트 캠프 - 기업연계 프로젝트 최종 회고

 

 

개요

1월 29일 최종발표까지 하면서 파이널 프로젝트가 끝났습니다. 한달이 넘는 시간동안 15명이 함께 매우 고생하며 만든 작품이라 애정도 가고 보람차기도 했습니다.

저번 중간점검 글에 이어 파이널 프로젝트 회고 글을 시작하도록 하겠습니다.

https://programmer-may.tistory.com/190

패스트캠퍼스X야놀자: 백엔드 개발 부트 캠프 - 파이널 프로젝트 : 야나바다 중간점검

 

 

 

 

프로젝트 초반엔  야놀자측에서 제시한 RFP 를 기반으로 정책을 만들고, 번개장터, 당근마켓, 캔슬마켓등 레퍼런스를 참고하며 서비스을 틀을 잡고 전체 회의를 통해 저희가 런칭할 서비스에 대해 어떻게 구현할 것인가에 대해 서로 의논을 하였습니다.

 

프로젝트 초반 피그마 서비스 와이어프레임

 

 

프로젝트 초반 설계 및 기획 전체 회의

 

 

 

프로젝트 디자인 와이어 프레임

 

 

PM분들이 세세한 기획과 틀을 다잡아주시고, 디자인이나오면서 프론트엔드에선 마크업 작업을 시작하고 저희 백엔드에선 레포지토리 틀 구축과 ERD 설계, 그리고 팀 컨벤션을 정했습니다.

 

이 파트에선 제가 담당하여 프로젝트 초반 틀을 구축하였습니다.

PR 템플릿과 커스텀 구글 자바 컨벤션파일을 두어 깃허브 액션스 체크스타일 검사와, 빌드 테스트 통과시에만 머지할 수 있도록 브랜치 보호 정책을 설정했습니다. 컨벤션도 제가 미니때 정하고 쓴 컨벤션이 가장 좋다고 팀원들이 생각하여 대부분이 미니때 컨벤션과 비슷하게 진행됐습니다.

파이널 프로젝트 팀원들이 잘 따라올 수 있도록 문서화 작업을 하여 백엔드 아카이브에 두어 팀원들이 모두 볼 수 있게 했습니다. 미니때와 마찬가지로 파이널때도 깃허브 액션스 체크스타일 검사와, 빌드 테스트에 만족도가 제일 높았습니다. 실무에서 작업하는 것과 비슷하다고 팀원들이 만족했습니다.

 

 

프로젝트 QA

 

 

일반적인 개발 프로세스

 

실무에서 진행되는 개발 프로세스에 맞는 프로세스처럼 진행된 프로젝트라 개발단도 기획단도 매우 흡족해 했습니다. 특히나 테스트 서버와 본서버를 따로 두었기 때문에 자체적인 테스트를 진행하였습니다. 프론트에서 브랜치를 Vercel에 배포할때 백엔드처럼 디벨롭 브랜치, 릴리즈 브랜치 각각 배포가 되는지 물었지만, 레포지토리당 하나 밖에 안된다 하여, 프론트 배포 사이트를 백엔드 본서버에 연동하고 테스트 서버는 개발단에서 자체 QA를 진행하고 본서버로 서비스를 옮겼습니다.

기획단은 완성된 홈페이지 QA를 진행해주어 서비스 배포전 고쳐야할 부분을잡아주셨습니다. 

 

프로젝트 결과

⚖️ API 명세서

 

🗺️ 프로젝트 파이프라인

 

 

🗄️서버 인프라

 

🗣️ 프로젝트 발표

 

⏯️ 프로젝트 시연 동영상

 

 

🏆 기업연계 프로젝트 우수 그룹 수상

 

 

 

🫂 팀회고

• 동민
  • 프로젝트 전제 정리/일정 조율 아쉬웠던 점
• 승현
  • 포인트나 리뷰 부분 할 때 PM + FE 만 이야기가 되어서 진행에 어려움이 있었음
  • 다 같이 의견을 조율하는 자리가 더 있었어야 했을 것 같다.
  • 원래 개발 시작 일정에서 많이 밀렸던게 아쉽다.
• 서영
  • 화면설계서를 자세하게 작성했다고 생각했지만, 개발과 함께 진행하면서 좀 더 보완이 필요하다고 생각했음.의견이 좀 달랐던 부분이 있었음. 끝까지 함께 해주셔서 감사합니다. 
• 예인
  • 화면설계는 ppt로 만들어주는게 훨씬 편하다… 피그마 너무 불편했습니다…!문서화가 더 필요했을 것 같습니다.
  • 시안 작업하면서 추가되는 사항들이 많이 있었어서.. 개발하면서 플로우를 그려보는 시점은 너무 늦지 않았나. 기획시안 나온 시점부터 나도 같이 플로우 고민도 해보고, 의견도 내보는게 필요했을 것 같음
• 주현
  • 4 직무가 하나의 팀이 되어서 집중하는게 좋았다.
  • 백엔드 측면에서는 수치를 정확하게 전달주었어야 했는데 기획단에서 너무 당연하게 생각하는게 많았다…
  • 프로젝트 초기에 예외 사항에 대한 정책이 부족했던 것 같다. 그래서 시간을 많이 씀
    • ex) 채팅방을 삭제하고 다시 채팅했을 때 정책 등등 그런 여러가지 예외 사항
    • 사용자가 우리 서비스를 잘못 사용했을 때 어떤 일이 발생했을지, 어떻게 해결할지 등 디테일을 챙겼다면 백엔드 개발 과정이 좀 더 수월했을 것 같다.
  • 문서화 작업의 중요성을 매우 매우 느낌.
  • 워딩의 통일이 필요함. 특히 알림에서! → 불필요한 로직을 많이 짜기도 했었음
  • 와이어프레임과 API명세서와 연결을 잘 못했다. EX)C-6 / G-8 등등
• 규철
  • 스스로 이기적인 부분이 있지 않았나 하는 회고, 팀이 더 잘되는 방향으로 원 팀이라는 마인드를 더 가져갈 필요가 있었을 것 같음.
• 재준
  • 규철과 비슷…! 뒤에서 칭찬이 아닌 앞에서도 칭찬을 많이 하는 사람이 되어보겠음니다…!
• 범식
  • 프로젝트 자체를 너무 만족함
  • 아쉬웠던 점은 패캠에서 디자이너를 한명으로 배정한게 너무 힘들었음.
  • 개발단에서 요청한 것들을 시간적 여유가 없어 많이 들어주지 못한 것이 죄송했음
  • pm 분들이 모든 논의에 디자인을 껴준 것이 고마웠고, 개발 분들이 디자인한 것들을 최대한 구현하려고 노력해주셔서 너무 감사했습니다.
  • 기능단위로 와이어프레임을 맡아서 짠 것은 효율적이라고 생각하나 각 기능별로 단어 통일이 되지 않아있다던가…EX)판매가/양도가/할인가 등등
• 솔미
  • 모든 팀원들이 열심히 하고, 실력도 다들 우수하셔서 감사했습니다.
  • 기획부터 시작해서 어느정도 기획 된 후에 개발이 되었는데, 시간이 많이 부족했습니다. 코드에 대한 고민을 할 시간이 많이 없어서 후반에 에러가 많이 발생한 것 같다. 한 주 정도라도 개발이 일찍 시작되었다면 좋았을 것 같다.
  • 수수료 정책 같은 것들은 후순위로 미뤄두고 마크업을 먼저 할 수 있도록 일이 더 쪼개져서 진행이 되었으면 시간을 더 잘 쓸 수 있었을 것 같다.
  • 동민 → 개발 소요가 많이 든 것은 뭔가요?
    • 승현 → FCM 부분에서 많이 애먹었습니다.
• 성수
  • 본인 파트가 아닌 부분에 대해서 피그마로 보는게 어려웠음
  • 프로젝트와 다른 일을 병행을하게 되어 초반에 BE장으로서 역할에 미흡한 점이 있지 않았나
  • 손이 빠른 사람에게 일을 넘겨버리는게 옳은 선택이었을까… 성찰의 시간
  • 다음에는 하나의 서비스를 위해 각 팀이 따로 존재하는 것이 아니라 하나의 팀이라는 것을 잊지 말아야 할 것 같다.
• 보미
  • 개발에 대한 고려 없이 서비스를 구상했던 점이 부족했다.
  • 야놀자 지울겁니다.
• 문경
  • 화면설계서에서 버전관리를 잘 했으면 좋았을 것 같다. 워딩이나 변경사항에 대한 것들이 관리가 안되어서 발생하는 소통의 문제가 아쉬웠음
  • 피그마로 화면설계 하는게 페이지 별로 나눌 수 있어서 버전관리에 장점이 있다고 생각했으나, 작업을 하다보니 버전관리를 놓친게 아쉬움
• 용준
  • PM분들 죄송하고 감사합니다!
  • 야놀자 회사 너무 무책임하다고 생각했다. 큰 회사라고 다를 것은 또 없던 것 같다.
  • R&R이 명확하게 잡혔어야 했을 것 같다. 그에 반해 프로덕트는 잘 나온듯
  • 감사감사합니다~
• 수지
  • 처음 코딩을 입문해서 진도 따라가기가 힘들었습니다…ㅠㅠ
  • 팀원분들 코드 리뷰를 하며 배울 수 있는 점이 많았습니다!
  • 앞으로 많은 경험이 필요하다고 생각했습니다.
  • 하나의 프로덕트가 만들어나가지는 과정이 너무너무 뿌듯했고, 감사했습니다.
• 수빈
  • 좋은 사람들을 많이 만나서 너무 좋았습니다~~~ 다들 수고하셨습니다~~~~~

 

🤔 개인회고

🥰 Liked : 좋았던 점

팀 기획에도 적극적으로 참여하고, 많은 걸 배울 수 있어서 좋았습니다. 특히나 PM, UIUX, Frontend 다른 직무와 협업하면서 소통과 문서화가 얼마나 중요한지 느꼈고, 백엔드 아카이브에 공유 문서들을 작업을 해서 다른 팀원들이 도움이 됐다는 이야기를 많이 들었습니다.

또한 팀명과 서비스명, 도메인명을 제가 정했는데, 팀 프로젝트 UT 할 때나 발표할 때 야놀자 멘토님등 다른 조 수강생 등 여러 사람에게 칭찬을 들어 매우 뿌듯했습니다.

야놀자 프론트엔드 멘토님께 서비스명 칭찬 받고 난 후

 

또한 다른 직무 팀원들을 비롯하여 백엔드 팀원과도 잦은 소통을 하며 도움을 많이 줬다는 생각에 매우 뿌듯했습니다. 그래서 많은 팀원에게 감사의 인사를 받았습니다. 

 

프론트 팀원 감사 인사

 

 

백엔드 팀원 감사 인사

 

 

또한 기업연계 프로젝트 우수 그룹상을 수상하면서 저희가 해온 방식이 틀린 것이 아니라는 자부심과, 결과물에 뿌듯했습니다.

📚 Learned : 배운 점

HTTP 메소드가 아닌 다른 프로토콜을 사용하는 API를 만들면서 더 많은 네트워크 지식을 공부할 수 있었고, 데이터 스트리밍 서비스 중 메세징 시스템에 대해 공부할 수 있어서 좋았습니다.

팀 협업에서 소통과 문서화가 얼마나 중요한지 배웠고, 이를 잘하려면 어떻게 해야하는지도 배웠습니다. 회의록 같은 경우 매 회의때마다 기록을 남겨 타 직무에서도 회의록만 보고도 저희의 결정사항을 알 수 있게끔 하였고, 데일리 스크럼과 기술스택 사용법에 대해선 최대한 자세히 적어 모르는 사람도 글만 보고 알 수 있도록 친절하고, 상세히 적어야한다는 점을 배웠습니다.

또한 글을 적었더라도 줌이나 디스코드에서 팀원들을 초대해 사용 방법을 화면을 공유하며 라이브로 보여주었을 때도 팀원들이 매우 좋아한다는 걸 배웠고, 백문불여일견에 대해서 확실히 느꼈습니다.

그리고 획일화된 소통이 얼마나 중요한지 배웠습니다. 같은 단어를 사용하면서 말하더라도 서로 다른 걸 떠올리며 말할 수 있다는 걸 경험했습니다. 마치 동상이몽처럼 말이죠. 따라서 잘 정해진 정책 위에서 획일화 된 워딩을 사용한 소통이 얼마나 효율적으로 일의 진행을 이끌어 낼 수 있는지 배웠습니다. 

기술적으로는 QueryDSL 과 DB 스케줄링 방법에 대해서 배울 수 있어서 좋았습니다.

 

🪫 Lacked : 부족했던 점

프로젝트 들어가기 전 3가지 목표가 있었는데,  리버스 프록시 서버는 구현했지만 시간이 부족하여 무중단 배포와 Source - Replica Architecture를 도입해보지 못한게 아쉽습니다. 이번 프로젝트때는도입하진 못했지만, 공부를 하였기 때문에 다음번엔 도입할 수 있겠다는 자신감이 생겼습니다.

채팅 도메인을 담당하면서 실시간 채팅 서비스를 만드니 실제 카카오톡 서비스에선 실시간 채팅을 어떻게 구현하고 대규모 트래픽 상황에서 어떻게 대처하는지 궁금해졌습니다. 대규모 트래픽을 감당하기 위해서 서버 증설말고 어떤 인프라를 구축하는지 궁금해졌습니다. 

저는 스프링 자체 내장되어 있는 메세지 브로커를 사용한 STOMP 통신을 하였지만, 실제 카카오톡은 카프카 같은 외부 데이터 스트리밍서비스를 사용하여 메세지를 주고 받을 것이란 생각을 했습니다. 

아직 제가 만든 채팅 서비스는 대규모 트래픽을 감당하기엔 조금 부족해 보였고, 이를 감당하기엔 다른 기술스택을 이용해야할 것 같다는 생각을 했습니다.   

🕯️ Longed for : 바라는 점

API 명세서와 피그마의 와이어 프레임을 연관짓는 속성을 정해서 적어두면 다른 사람의 기능을 확인할 때 페이지 화면도 바로바로 확인할 수 있을 거 같아서 다음번 API 명세서를 작성하다면 피그마 와이어 프레임 속성을 추가할 거 같습니다.

커뮤니케이션 미스로 인한 시간 낭비가 조금 아쉬웠습니다. 서비스에서 제공되는 알림으로는 파이어베이스를 이용한 푸시 알림과 웹 앱에서 종모양의 알림 두 가지가 있었습니다. 기획단과 알림이란 단어로 소통할 때 서로 다른 알림을 떠올리며 말해서 불필요한 로직을 짜기도 했습니다. 워딩의 통일화를 느끼며, 왜 유비쿼터스 언어가 중요한지 새삼 깨달았습니다. 다음 번 기획단과 개발 프로젝트를 진행할 땐 이런 언어와 화면 설계를 확실하여 커뮤니케이션 미스에 대한  비용을 낮추도록 노력해 봐야겠습니다.

또한 다음 프로젝트를 한다면 꼭 무중단 배포를 도전하고 싶어졌습니다.