프로젝트 회고록 : "Folioverse"

나의 첫 프로젝트 "포트폴리오 공유 서비스 : Folioverse"가 끝이 났다. 2주 동안 진행되었는데 시간이 정말 빠르게 지난 것 같다!

1. 프로젝트 소개:

팀 구성: 팀 "포레버"

• 프런트엔드 3명 
• 벡엔드 3명 

서비스 소개 - Folioverse -

💡 "folio"와 "universe"를 합친 이름으로, 포트폴리오의 세계로 여러 사람들이 모여서 자신의 작품을 공유하는 공간이라는 의미를 담고 있습니다.

사용자가 포트폴리오를 자유롭게 공유하고, 자극을 받고 영감을 받을 수 있는  서비스를 만들겠다고 정하고, 서비스의 이름을 정해보았다. 팀원들과 회의를 하다가 모두 맘에 딱 드는 것이 없어서 "인공지능의 시대인데, 한번 chatGPT에게 물어보자"라는 이야기가 나왔고, 결론은 매우 성공적이었다...(이쯤 되니 정말 무섭다)
서비스의 이름이 정해지니, 그때부터  서비스의 모습이 그려지기 시작했다. 

🚀 Stacks

• HTML
• CSS
• JavaScript
• React.js
• Node.js
• Express.js
• MongoDB

🛠  Tools

• VSCode
• PhotoShop
• Figma
• Git

👥  Collaboration

• GitLab
• Notion
• Discord

구현기능

• 기본적으로 React클라이언트와 Express서버와 MongoDB데이터베이스 사용 
• CSS는 대부분의 상황에서 Tailwind 이용 
• 회원가입, 로그인, 로그아웃 기능 : Passport와 JWT를 통해 로컬스토리지에 토큰을 저장하고 인증받는 방식
• 암호화는 bcrypt를 통해 이루어짐
• 다크모드는 Zustand를 통해 로컬스토리지에 테마 상태를 저장하고 바디태그에 클래스를 추가하고 Tailwind로 감지하는 방식
• 대부분 CRUD는 mongoose를 통해 스키마를 정의하고 model을 통해 스키마를 조작하고, 라우터를 통해 오는 요청을 Service 쪽에서 처리함
• 로그인, 로그아웃 상태에서의 서버요청을 토큰을 체크하는 미들웨어를 통해 분리시킴
• 마이페이지의 항목들을 선택적으로 View 하는 방식은 Zustand를 통해 로컬스토리지에 뷰 여부를 저장함
• 쪽지 기능 및 방명록 기능은 기본적인 CRUD 외에도 폴링방식을 통해 실시간으로 Toast메시지로 수신여부를 확인할 수 있음
• 폴링이 필요한 요청은 리액트쿼리의 refetchInterval 기능을 통해 1초마다 서버로 요청을 보내며, 이전 데이터의 배열길이보다 길어질 때에만 변경을 감지하고 상태를 전달함(메시지 및 방명록이 추가되었을 때만 보여야 하기 때문)
• 프로필 이미지에 대한 설정은 AWS의 S3버킷을 통해 저장됨
• 회원탈퇴 시에는 관련된 데이터를 모두 삭제하도록 처리함
• 방문자 수에 대한 데이터는 리액트쿼리의 staletime설정으로 인해 캐시 된 데이터를 기준으로 get요청을 감지하기 때문에 무한정 올라가지는 못하도록 설정
• 통계에 대한 데이터는 해당 사용자에게 담긴 모든 데이터를 날짜기준으로 sorting 하며, react-chartjs-2와 chart.js로 뷰를 구현함
• PDF기능은 html2 canvas를 html클래스 기준으로 캔버스를 생성하고 jspdf를 통해 pdf파일로 변환시킴

2. 프로젝트 진행과정

설계 및 기획 단계!

프로젝트를 시작할 때, 기획 및 설계가 중요하다는 의견을 피력하였고, 팀원들과 첫 이틀 온종일 회의를 하며 전체적인 기능과 흐름등을 정하고 프런트는 프로토타입을 제작해 보고 벡엔드는 데이터 스키마를 설계하였다.

IA 설계

ERD 설계

프로토타입 구현

설계 및 기획 단계를 마무리하고, 전체 팀원 회의를 진행하여 2주간 진행계획 WBS를 정하였다.

서비스 이름을 정하고, 필수 기능과 추가기능을 구분 짓고, 웹 디자인을 정하는 과정에서 팀원들과 정말 많은 시간을 이야기한 것 같다. 회의를 최종적으로 완료했을 때는 너무 힘들었지만 그 과정은 너무나도 재밌었던 것 같다. 
2주간의 타이트한 시간제한을 생각했을 때, 필수 기능을 우선시해서 개발하고 그것을 뼈대로 추가기능을 덧붙여 나가기로 팀원들 모두 원만히 결론을 지었던 것 같다.

매일 아침 10시에 팀 스크럼 시간을 정하였다. 각자 전날에 어떤 것을 하였는지, 오늘은 무엇을 하고 어디까지 할 것인지 체크하고 팀원에게 공유하는 것으로, 서로서로 진행상황을 공유하여 방향성을 놓치지 않기 위해 노력했던 것 같다.

코드 리뷰 & 계획 점검

일주일 동안 정말 열심히 달렸던 결과! 벡엔드는 필수기능을 거의 다 구현하여, 오류 수정단계에 있었고, 프런트도 마찬가지로 각자가 맡은 페이지 모습을 어느 정도 구현을 끝냈었다. 하지만, 모든 것이 순탄하지는 않았다. 프런트 담당 팀원 분 중 한 분이 우리가 사용하기로 한 React를 전혀 사용하지 않고 HTML, CSS만 이용하여 구현하고 계셨고, 진행상황도 다른 팀원분들과 비교해 매우 더딘 상태였다... 후에 더 자세히 느낀 점을 쓰겠지만 이런 부분에서 커뮤니케이션이 중요하구나를 다시 한번 느꼈다. 
다행히도, 벡엔드에서 조금은 여유가 있었던 승현 님께서 프런트 부분도 많이 지원해 주셔서 무사히 넘어갈 수 있었던 것 같다... 감사해요!

일주일의 개발을 마치고, 주말에 팀 회의를 진행하여 코드리뷰를 하였다. 오류가 있는 부분과 프런트와 벡엔드의 연결성을 확인하고 다시 한번 어떻게 요청을 보내고 응답을 처리할 것인지 이야기하였다. 두 번째로, 코드 컨벤션에 대해 정하기 시작했고, 그에 맞게 지금까지 짠 코드들을 리팩터링 하는 시간을 주말에 갖기로 결정하였었다. 남은 일주일은 추가 기능 구현에 힘을 쏟고 마지막 이틀은 코드를 픽스하기 위해 버그를 찾아내고 수정하는 것에 시간을 할애하였었다.

3. 프로젝트 회고

좋은 협업태도란 무엇인가에 대한 기준 

처음으로 개발 프로젝트를 진행했던 나는 좋은 협업이 무엇인가에 대한 기준이 명확하진 않았었다. 물론 다른 분야에서 팀 프로젝트를 한 경험은 있지만 개발 프로젝트는 또 다른 느낌이었던 것 같다. 첫 프로젝트를 마무리하고 세우게 된 좋은 협업의 기준은 다음과 같다. 

1. 내가 하고 싶은 것을 정확히 전달하고 다 말할 수 있어야 한다. (꼭 부드러운 말투와 함께~)
-한 팀이 되어 하나의 주제로 진행한다 하여도, 각자 구현하고 싶은 것들이 다 다르다. 이 모든 것을 꺼내어 아이디어로 제안하는 것이 완성도 높은 결과물에 가까워진다고 생각이 들었다. 하지만 절대 고집을 부리거나 강요하는 것은 안되고 부드러운 말투로 친절히 제안하는 것이 중요하다. 그래야 모든 팀원들이 거부감 없이 아이디어의 본질만을 볼 수 있다고 생각이 든다. 

2. 긍정적인 사고! 말투!
- 타이트한 스케줄과 많은 업무량 때문에 당연히 지칠 수밖에 없는 시점이 온다. 그럴 때마다 우리 팀원들은 서로에게 "뭐 어떻게든 해보죠 , 하면 돼요"라는 말들을 외치며, 힘들지만 계속 코드를 작성했던 것 같다. 별거 아닌 것 같지만 그 말 한마디 한마디를 나눌 때 자극이 되고 리프래쉬 하면서 앞으로 나아갈 수 있었던 것 같다. 긍정적인 말 한마디가 일의 효율성을 훨씬 높일 수 있었다!

3. 끊임없는 커뮤니케이션 (열린 마음)
- 이 부분도 정말 중요하다고 배운 것이, 위에서도 언급한 것과 같이 프로젝트 진행 상황에서 문제가 조금 있었다. 매일 같이 스크럼을 하고 진행 상황을 공유하는 시간을 가졌지만, 팀원 한분이 그 시간에 적극적으로 참석과 공유를 하지 않았던 부분이 있었는데, 잘하고 계시겠지 하는 생각에 어느 누구도 체크하지 않았었다. 이 부분에서 적극적으로 소통하고 다른 팀원들의 상황도 체크하는 부분도 필요하다는 것을 배웠다.

잘한 점 /  아쉬운 점

잘한 점: 처음으로 코드를 파일 구조부터 생각하면서 A부터 Z까지 내 손으로 만들어 보았다. 그동안 공부를 열심히 했다 해도 코드의 흐름을 파악하는 것과 프런트와 벡엔드 사이에서 통신으로 넘어오는 데이터를 어떤 형태로 받을지, 어떠한 로직으로 처리를 할 것인지 전체적인 흐름을 파악하는 것이 매우 부족하였다. 하지만, 내가 부족한 것에 주눅이 들거나 실망하지 않고, 주변에 뛰어난 팀원분들께 하나라도 더 배워야겠다는 마음가짐을 가지고, 모르는 부분, 필요한 부분에 대해 끊임없이 질문하고 찾아보며 프로젝트에 임했다. 그 덕분에 2주 전의 나와 현재의 나를 비교해 보면, 정말 많은 성장을 했다 고 생각한다. 나를 성장시켜 준 우리 팀원분들께 너무나도 감사하다.

아쉬운 점: 잘한 점과 이어지는 부분이기도 하다. 실력이 부족했었던 나는 여러 가지를 공부하고 이해하면서 코드를 작성하였다. 그 과정에서 세부적인 컨벤션이나 Api 명세서 같은 문서화 부분을 신경 쓰지 못하였던 것이 아쉽다. 또한 벡엔드 코드를 설계하면서 파라미터의 변수명이 직관적이어야 했는데, 비슷하거나 한눈에 이해하기가 힘든 변수명을 사용해서 로직들을 연결할 때 파라미터 값을 잘 못쓰는 실수들이 많았었다. 그런 부분도 처음부터 잘 생각해서 코드를 작성해야겠다고 느꼈다. 마지막으로 설계와 기획단계가 매우 중요하다고 느꼈다. 물론 시간적인 여유가 많지 않은 상황이었어서 대략적인 설계를 한 부분을 인정하고, 그때 당시에는 최선이라고 생각했었다. 하지만, 진행을 하면서 조금씩 수정을 반복하고 기능을 추가하고, 기존에 작성했던 코드의 로직들을 변경하는 상황을 겪으면서, 코드를 변경하는 것이 훨씬 더 많은 시간과 노력이 필요한 것을 느꼈다. 처음부터 완성도 높은 설계를 하면 일의 효율성이 높아질 거라고 생각한다.

결과물:

마무리:

정말 많은 배움이 있었고, 같이 열심히 달려준 팀원분들께 감사하다. 프로젝트를 하면서, 코드를 잘 만들고 뛰어난 능력도 중요하지만, 무엇보다도 팀원들 간의 소통과 화합이 성과에 매우 큰 역할을 한다는 것을 다시 한번 체감하였다. 결국 사람이 중요하다.
프로젝트에서 부족했던 부분들을 보완하고 공부해서 다음에 있을 프로젝트에서 더 나은 퍼포먼스를 보일 것이다!!!