1. 프로젝트 개요

• '공부의 숲'은 사용자들이 스터디 습관을 관리하고 집중 시간을 기록할 수 있는 웹 애플리케이션입니다. 핵심 기능으로는 스터디 생성 및 관리, 습관 기록, 집중 시간 측정, 포인트 시스템 등이 있습니다. 사용자는 스터디를 생성하고, 습관을 등록하여 매일 체크하며, 집중 시간을 측정해 포인트를 획득하는 과정을 통해 학습 동기부여와 지속적인 관리가 가능합니다.

2. 담당한 작업

• 스터디 수정하기 기능
• 스터디 응원이모지남기기 기능
• 데이터베이스 스키마 관리(DB업데이트 및 적용)

3. 기술적 성과

• 프로젝트에서 사용한 기술 스택 : React, Express, Nodemon, BCrypt, Prisma, PostgreSQL, emoji-picker-react
• 프로젝트에서 구현한 주요 기능 : 스터디 수정하기 기능, 스터디 응원이모지남기기 기능
• 풀스택 개발에서 주요한 기술들로 스터디 수정하기, 스터디 응원이모지남기기 기능을 구현하며 스터디 기능의 핵심이자 CRUD의 Update에 해당하는 기능인 스터디 수정하기 기능을 구현 완료하였고, emoji-picker-react 오픈소스 이모지 라이브러리를 사용해 스터디 상세화면에서 이모지를 추가 또는 삭제할 수 있고, 등록된 이모지가 3개가 넘을 시 토글 모달을 이용해 더많은 이모지를 보거나 닫을 수 있는 기능을 구현했습니다. 이로써 스터디 상세화면에서 스터디 데이터를 수정할 수 있게 되었으며, 스터디 상세화면에서 이모지를 추가하나 삭제하고 자유롭게 남긴 이모지들을 확인할 수 있도록 사용자에게 유용한 편의성을 제공할 수 있게 되었습니다.

4. 문제점 및 해결 과정

• 스터디 수정하기 기능 구현 초기에 API 엔드포인트를 명세표를 작성해놓지 않아 어떤 엔드포인트로 API를 통해 데이터를 주고받을지 고민하다가 많은 시간을 소모했습니다. 그러다 팀원들이 전체적으로 백엔드구현에 집중하게 되는 시기에 자연스럽게 API 엔드포인트를 작성할 수 있는 기회가 와서 이때를 기준으로 팀프로젝트의 배포 결과물이 유의미하게 도출되기 시작했던 것 같습니다. API 엔드포인트를 미리 합의하여 작성해두고 그 URI를 따라 구현했더라면 훨씬 더 적은 시간을 들이면서 효율적으로 개발할 수 있었을거라는 생각이 들었습니다.

5. 협업 및 피드백

• 협업 과정에서 느낀점: 팀원들 모두가 코딩과 깃허브에 익숙한 것은 아니지만, 긍정적으로 의논하고 새로운 방법을 찾고, 더 나은 도구를 사용하는 등 독단적인 선택 없이 의견 나누기와 회의를 통해 적극적으로 새로운 방법을 찾아 구현 및 발전시켜나가는 모습을 보며 저 또한 팀프로젝트에 적절한 기여를 남길 수 있도록 열심히 해야겠다는 생각이 많이 들었습니다.
• 협업 과정에서 배운점: 팀원들이 코드뿐만 아니라 깃허브를 다루거나 코드 협업 방식에 대해 토의하는 등 코드 내적인 부분 이상으로 커뮤니케이션 방식, 협업 방식에까지 많은 노력을 들여 팀프로젝트에 대한 최선의 결과물을 도출해내기 위해 노력하는 모습을 보며, 저 또한 팀원들에게, 그리고 팀프로젝트의 최종 결과물에 긍정적인 영향을 남길 수 있도록 팀원들에게서 소통 방식이나 협업 규칙을 정하는 데에 있어서 많이 배울 수 있었습니다.
• 협업 과정에서 피드백: 깃허브 PR에 대해 리뷰어 팀원들이 코멘트를 남겨주는 방식으로 코드에 대한 피드백을 진행했는데, 스스로는 못 봤던 실수와 의미가 부족한 코드 등을 다른 사람이 볼 때는 훨씬 더 잘 보이게 된다는 점을 인지했습니다. 그래서 페어 코딩 및 코드 리뷰가 코드 작성 실력을 높이는 유효한 방법이라는 점을 실감할 수 있었습니다.

6. 코드 품질 및 최적화

• 프로젝트 중 코드의 가독성과 유지보수성을 높이기 위해 기능 별로 패키지를 나눠 각 패키지 안에서 단위 기능을 완성할 수 있도록 프로젝트 구조를 설계했습니다. 그리고 성능 최적화를 위해 Netlify 환경에 배포된 프로젝트와 로컬에서 실행한 프로젝트를 직접 비교하여 성능이 떨어지는 부분에 대해 직접 코드를 수정하는 방법으로 성능을 최적화했습니다.

7. 향후 개선 사항 및 제안

• 프로젝트가 완료된 이후에도 배포 환경을 꾸준히 모니터링하거나 서버가 너무 느리다면 새로운 서버로 프로젝트를 옮겨보는 시도를 할 수 있습니다. 그리고 개발단계에서 발견하지 못한 오류를 대처하기 위해 깃허브에 푸쉬되어있는 배포용 브랜치의 코드를 개선 및 리팩토링 작업을 진행해 볼 수 있습니다. 향후 프로젝트에서는 개발 요구사항에 맞게 프레임워크를 선택하여 더 나은 협업 환경 및 코드 품질을 기대해 볼 수 있을 것입니다.