[프로젝트 회고] aloharoom

📢  프로젝트 소개

• 프로젝트 : 룸메이트를 모집하는 1인 가구 웹서비스
• 프로젝트 인원 : 4명 (프론트엔드 2명, 백엔드 2명)
• 프로젝트 기간: 2023.02.16 ~ 2023.06.01
• 기술 스택
  • Front-end : React, JavaScript
  • Back-end : SpringBoot, Spring Data JPA, Spring Security, QueryDSL, MySQL
  • Infra : AWS EC2, AWS RDS, AWS S3
• 협업 : Notion, Figma, Discord
• 시스템 구조도

• GitHub

 

 

🧑‍💻 나의 역할

• 백엔드 개발
  • 회원가입/로그인
  • 지도 상 위치에 따라 룸메이트 모집 마커 제공
  • 룸메이트 모집 정보 제공 (작성자 정보, 집 사진, 주소, 주거 형태, 월세, 댓글 등)
  • 룸메이트 모집 정보 필터링 (성별, 방 개수, 주거 형태, 월세, 평수, 해시태그 등)
  • 룸메이트 모집 정보 즐겨찾기
  • 사용자 댓글 알림 제공
  • 사용자의 성향 해시태그, 사용자의 집 해시태그 제공
  • 선호하는 성향 해시태그, 선호하는 집 해시태그 제공
  • 데이터 정보 제공(월별 가입자 수, 지역별 방의 수치, 평수별 월세 분포도)
  • 최근 본 룸메이트 모집 정보 제공 (최대 10개)
  • 내가 쓴 룸메이트 모집 정보 제공
  • 댓글 단 룸메이트 모집 정보 제공
  • 즐겨찾기 한 룸메이트 모집 정보 제공
  • 커뮤니티 제공 (방 자랑, 정보 공유, 자유)

• DB 설계/구축
• Infra(AWS EC2, AWS RDS, AWS S3) 구축

 

 

📍 백엔드를 선택한 이유

학부 과정에서 프론트엔드 전공 수업을 수강했었다. 내가 디자인한 결과물이 눈앞에 바로 보이는 점에서 즐거움도 느꼈었다. 그럼에도 불구하고 백엔드를 선택한 이유는 결과물이 보이는 건 재밌지만 잘하는 것은 아니기 때문에 금방 싫증을 느꼈다. 재밌는 건 맞지만 못 하기에 시간이 지날수록 재밌지 않다고 느낀 것 같다.

 

당시에 백엔드 전공 수업이 없었어서 인프런을 통해 백엔드 강의를 수강해 보았다. 평소 자바에 대한 자신감이 있어 Spring Boot 프레임워크를 선택했고, 이를 통해 백엔드 개발에 대한 이해를 높일 수 있었다.

 

백엔드에서는 눈에 보이지 않는 곳에서 일어나는 일들에 주로 집중하며, 이는 내 성격과 더 잘 맞는 것 같았다. 또한 결과물이 시각적으로 나타나지 않더라도 효율적으로 문제를 해결하고 업무 흐름을 최적화하는 과정에서 성취감을 느꼈기에 더욱 확고해졌다.

 

그래서 인터넷 검색을 통해 백엔드에 대해 더 알아본 결과, 프로젝트에서의 인력 비율에서 백엔드가 더 큰 비중을 차지한다는 사실을 알게 되었다. 이는 백엔드 개발자의 수요가 더 높다는 것을 의미하며, 서비스의 지속적인 유지를 위해서는 백엔드 개발자의 역할이 중요하다는 확신을 얻게 되었고 이를 토대로 백엔드로 진로를 결정하게 되었다.

 

 

 🎉 결과

최종적으로 캡스톤 디자인 웹공학 트랙부문에서 최우수상을 수상하게 되었다. 우리 팀이 상을 받았다고 생각하는 이유는 완성도가 있었고 미래에 룸메이트를 구하는 활동이 활발해진다면 실제로 쓰기 좋은 플랫폼이기 때문이다. 

 

 

📖 배운 점 / 느낀 점

REST API

이전에 기능을 구현할 때 HTTP 메소드의 의미를 모르고 GET, POST 등을 사용하였었다. 이번엔 RESTful한 코드를 작성하고 싶은 마음이 있어서 REST API 스타일을 지키면서 코드를 작성해보니 확실히 가독성도 좋고 의미를 판단하기 매우 편리함을 느꼈다. 하지만 명확한 기준이 정해져있지 않기에 개발자마다 스타일이 조금씩 달라 협업을 진행할 때 기준을 잡고 가면 좋겠다고 생각했다.

 

DTO(Data Transfer Object)

DTO라는 것을 알고는 있었지만 어떻게 쓰는 지 몰랐어서 써보질 않았다. 이번엔 백엔드와 프론트엔드 간의 데이터 교환을 단순화하고 데이터 모델을 분리하기 위해 DTO 패턴을 도입하였다. 실제로 써보니 불필요한 정보 노출을 방지하여 보안성이 강화되고 데이터의 크기도 최적화되어 성능도 높아짐을 느꼈다. 또한 데이터 모델 변경 시 DTO만 수정하면 되기에 유지보수면에서도 훌륭하다고 생각했다.

하지만 DTO를 사용함으로써 DTO 클래스 관리, 추가 코드 증가로 인한 복잡성, 데이터 모델의 중복등 단점도 분명 있었다. 이런 단점에도 불구하고 DTO를 사용하는 것이 추후 유지보수 관점에서 훨씬 큰 이점이 있다고 생각이 든다.

 

복잡한 필터링

필터링 기능을 사용하여 원하는 데이터를 추출하기 위해 복잡한 쿼리와 로직을 작성하였다. 이 부분에서 QueryDSL 프레임워크를 활용하여 안전하게 쿼리를 작성할 수 있는 능력을 향상시켰다. 이전에는 이를 알고는 있었지만, 이번 프로젝트를 통해 QueryDSL을 잘 이해하고 활용할 수 있게 되었다.

 

협업

이번 프로젝트는 전과 비교하면 상대적으로 규모가 있기에 어떻게 해야 서로 소통을 잘 하면서 프로젝트를 완성시킬 수 있을지 고민했다.

해결책으로 Notion을 사용하였다. Notion을 사용해 회의록, 해야할 일, API 명세서, 요구사항 명세서 등을 정리하다보니 프로젝트의 기반을 잡으면서 협업이 잘 이뤄졌다고 생각한다. 

 

문제해결 (방 필터링)

 데이터베이스에 저장된 방 데이터들을 프론트엔드에서 요청한 조건에 따라 필터링하여 응답하는 기능은 다양한 조건을 고려해야 했기에 처리 시간이 길어지는 문제가 있었다.

 이 문제를 해결하기 위해, 쿼리문을 작성할 때 가능한 한 많은 조건을 고려하고, 일대다 관계에 대해서는 가장 데이터가 많은 쪽에 Fetch Join을 사용하여 최대한 성능을 높였다. 추가적으로 Fetch Join이 없는 연관관계에 대해서는 Batch Size를 적용해 In 쿼리로 성능을 보장했다. 이렇게 함으로써 사용자가 원하는 조건에 따라 빠르고 효율적으로 방 게시물을 필터링하고 응답할 수 있도록 개선할 수 있었다.

 

 

📖 아쉬운 점

알림

 프로젝트에서 댓글에 대한 알림 기능을 두었다. 알림 기능을 구현하기 위한 방법으로 크게 3가지가 있다. 폴링, 웹소켓, SSE(Server-Sent-Events)이 존재한다. 현 프로젝트에서는 폴링 기법을 사용해 알림 기능을 구현하였다. 

 폴링 기법은 구현이 간단하지만 클라이언트에서 서버에 계속 요청을 보내기에 서버에 대한 부담이 점점 증가한다. 또한 실시간으로 동작한다고 보기도 어렵다. 주기적으로 요청을 보내는 것이기에 바로 응답한다는 것에 대한 보장이 없다. 그래서 알림 기능에 대한 아쉬움이 남는다. SSE를 안 써봤기에 시도조차 해보지 않았다. 다음에는 SSE를 사용해서 구현을 해볼 예정이다.

 

채팅

 웹 서비스를 이용하는 사용자들 간에 실시간 소통이 필요한 상황에서 댓글 기능과 카카오톡 오픈 채팅 링크를 도입하여 소통의 창구를 마련하였다. 사용자들에게 더 나은 서비스를 제공하기 위해 웹 소켓을 통한 실시간 채팅 기능을 도입하려 했으나 시간적 비용이 크기도 하고 어렵기에 넣지 않았다. 다음에는 웹 소켓을 통한 실시간 채팅 기능을 도입해야겠다. 

 

테스트 코드

 개발 초반에는 테스트 코드 작성에 신경을 썼지만, 프로젝트가 진행됨에 따라 테스트 코드를 작성하지 못 했다. 엔티티의 변경으로 인해 이전에 작성한 테스트 코드가 더 이상 유효하지 않아 오류가 발생하고, 작성하기 귀찮다는 이유로 최근에는 테스트 코드 작성을 소홀히 하였다.이로 인해 기능 테스트가 번거롭고 오래 걸리며 불편함을 느꼈다. 다음에는 테스트 코드 작성에 더 집중하고 완벽하게 작성해보기로 결심했다.