[프로젝트 회고] COMEET 개발자들을 위한 모각코 커뮤니티 사이트 프로젝트

회고는 중요하다!

오늘 먹은 점심도 기억이 안날 정도로 너무 많은게 흘러들어오는 요즈음, 기록은 정말 정말 중요하다!

첫 규모있는(?) 프로젝트인 만큼 잘 기록하고자 하는 마음에 분량이 조금 많아진 것 같다ㅎㅎ 아쉬운 점도 많았지만 불과 1년 전 나를 바라본다면 여기까지 온 내 자신에게 조금은 뿌듯하기도 하다. (그 때 나는 RAM과 CPU 차이도, 버블소트가 뭔지도 몰랐다..) 큰 의미는 없지만, 최우수 프로젝트로 선정되었으니 기분은 좋았다!

각설하고 회고를 시작해보자 :)

✅ Comeet

https://github.com/Damongsanga/comeet
SSAFY 10기 공통 프로젝트 최우수상

✅ 프로젝트 설명

• 서비스 설명 : 개발자들을 위한 모각코 커뮤니티 사이트
• 기획 배경
  • 왜 스터디를 모집하는 공간과 스터디를 진행하는 공간이 분리되어야할까? 라는 불편함에서 시작
  • 더 나아가 함께 지식을 공유하는 개발자들만의 문화를 적극 반영한 온라인 스터디 플랫폼을 구상하게 됨
• 개발 기간 : 2024.01.08 ~ 02.16 (6주)
• 인원 : 6명

✅ 역할 (백엔드)

• 인증 인가
• 멤버, 방, 채널, 라운지 도메인 서비스
• 메타데이터 로직

✅ 주요 기술 스택

Spring Boot, Spring Data JPA, Querydsl, Spring Security, JWT, Oauth2
MySQL, Redis, Mongodb, AmazonS3
Gitlab, Jira, Notion

✅ 기술적 고민과 성장

1. 인증 인가

• 사용자 편의 및 서버 리소스 효율성 위해 JWT 사용, Refresh token을 redis 에 저장하여 관리
• Access Token 만료시 자동으로 refresh token을 확인하여 재발급되도록 하여 사용자 편의성 증대
• Github Oauth2 를 활용한 소셜로그인 구현
• CSRF, XSS 공격에 대한 방지
  • CSRF : Referer 검증
  • XSS : refresh token cookie에 넣어서 http-only 설정

• 프로젝트 후 남은 질문
  • stateful하게 구현할 때 만약 서버가 많다면 어떻게 sessionID를 공유할 것인가?
  • stateful하게 구현할 때 이에 소비되는 리소스는 합리적인가?
  • 만약 JWT로 온전히 stateless하게 한다면 이 토큰이 탈취될 때 리스크를 어떻게 최소화할 수 있는가?

2. 트랜잭션 & 데이터 일관성

• 읽기 및 쓰기 성능 개선을 위해 현재 방에 접속한 유저 정보와 현재 유저 위치 별도 자료구조로 redis에 저장
• Redis transaction을 통해 두 자료 간 데이터 일관성을 확보
• Update 발생시 스프링 트랜잭션 맨 마지막에 배치하여 에러 발생시 spring 트랜잭션 단위로 롤백되어 영향받지 않도록 함

• 프로젝트 후 남은 질문
  • redis 트랜잭션을 스프링 트랜잭션 안에 포함되도록 어떻게 구현할 수 있는가?
  • 트랜잭션 단위를 어떻게 최소화하여 가져갈 수 있는가?

3. 쿼리 성능 개선

• NoOffset을 사용하여 조회 쿼리 성능을 개선
• 5개의 테이블을 동시 조회하는 단일쿼리에서 병목현상이 있는 것을 확인, 무리한 Join을 줄이고 카티널리티를 고려하여 다중쿼리로 분할하여 병목현상 해결
• Querydsl에서 되도록 불필요한 entity 조회를 지양하고 dto 조회를 통해 필요한 컬럼만 가져오도록 함

4. 이외

• 프로젝트 후 남은 질문
  • 반드시 테이블에 모두 연관관계가 필요한가? 때로는 fk constraint 없이 그냥 join하는 것이 좋을 때도 있다. 언제 이렇게 할 수 있을까?
  • soft delete는 무조건 다 필요한가?
  • DB 설계 시 unique 설정을 넣어줄지 말지는 생각보다 고민해봐야 할 문제이다. index가 걸리기도 하고 soft delete시에 어떻게 처리할지를 고민해줘야하기 때문이다.

✅ Keep

이번 프로젝트를 하면서 계속 가져가고 싶은 점이다!

기술

• 전체 git commit, 클래스 및 메서드 컨벤션 지켜서 진행하여서 좋았다. 그러나 변수명, 함수명은 보다 클린코딩하게 발전할 필요가 있다.

• 노션에 공부한 내용이나 트러블 슈팅한 내용을 정리한 점이 매우 좋았다.

• 에러에 대한 커스텀 응답을 반환하여 내부 로직은 숨기고, front-back 간의 소통할 수 있었다.

• redis 트랜잭션을 관리해 방 입장, 나가기, 메타데이터 로직 관리할 수 있었다.

• soft delete 사용시의 데이터 관리에 대해 고민할 수 있었다.

협력

• 스크럼시 한 내용, 할 내용, 같이 상의해야 할 내용을 나눌 수 있어서 좋았다. 그런데 이번 프로젝트 컨설턴트님은 스크럼에서 너무 업무적인 내용만 하면 안된다고 하는데.. 이 또한 맞는 말이다. 아무래도 팀 분위기가 좋아서 담소 같은 것들은 스크럼 전 후에 많이 해서 불필요하다고 생각했던 것 같다. 다음에는 일하는 공간에서 조금 떨어져서 가볍게 진행해보자.

• 팀장이 지라를 통해 얼마나 진행되었는지 서로의 진척도를 챙기고 업무를 중간에 재분배하거나 개인 팀원에게 전체 팀원의 진척도를 공유해주는 노력이 좋았다.

• 수정사항이 있으면 공통된 문서에 기록하여 변경 내용과 시기를 쉽게 찾을 수 있게 관리하였다.

• 모르는 내용이 있으면 일정 시간까지만 고민하고 팀원들에게 해당 내용을 공유하는 팀 문화를 가져갔다. 때문에 불필요하게 오래 고민하는 시간을 줄여 프로젝트 진행을 스피드있게 가져갈 수 있었다.

✅ Problem

다음은 아쉬웠던 점들이다. (쓰다보니 왤케 많지..) 아무래도 6인이 진행하는 프로젝트는 처음이다 보니 개인적으로 부족함을 많이 느꼈던 것 같다. 하지만 첫술에 배부를 수는 없는 것 아닐까?! 이를 바탕으로 다음 프로젝트에서 하나씩 개선해보고자 한다.

기술

• 테스트 코드를 제대로 작성하지 못했다. 원래 메소드 별로 작성을 하였지만.. 6주라는 기간에 메인 CRUD를 맡다보니 테스트 코드에 대해 공부하고 작성할 시간이 부족했었다. 결국 절반정도 작성하다가 모두 지우게 되었는데, 단위는 아니더라고 비즈니스 로직 단위로는 작성을 했어야 하지 않았나라는 아쉬움이 남는다.

• 패키지 구조 설계가 미흡했다는 생각이 든다. 도메인 별로 나눠야할지 dto를 어디에 둬야할지, enum을 패키지 단위로 따로 빼야할지에 대해 통일성이 많이 부족했다. 경험이 많이 부족한 것도 사실이다. 다음에는 아키텍쳐를 어떻게 가져가는 것이 해당 서비스에 어울리는지에 대한 고민을 해야겠다.

• query 성능을 객관적으로 판단할 테스트를 진행하지 못했다는 아쉬움이 있다. 임시로 System.currentTimeMills()로 매우매우 추상적인 비교만 진행하였는데, 이는 객관적이지도 못하고 다양한 상황에 있어 고려되지 않았기에 성능을 대변해줄 수 없다..

• admin 계정을 통해 복합적으로 얽혀있는 엔티티를 삭제하는 로직을 구현하지 못했다. 그러다 보니 추후 테스트 데이터를 삭제할 때 복잡하게 얽힌 테이블 constraint로 인해 불필요한 데이터를 SQL로 직접 지우는데 불편함이 있었었다.

• mongoDB는 단순 메타데이터를 저장, 읽기에만 사용했다. 보다 깊이 공부하여 사용하지 못했다는 아쉬움이 있다.

• 이번에 맡지 않은 웹소켓을 이용한 방 동시성 관리 및 채팅쪽의 내용 숙지가 부족하다는 점이 아쉽다. 이후 별도로 소켓 통신에 대해 공부하였고 담당했던 팀원에게 설명을 들었지만 완벽한 플로우를 이해하는데에는 부족함이 있었다.

협력

• 지라를 사용하긴 했지만, 뭔가 실무에서만큼 효과적으로 활용하지 못했던 것 같다. 기능이 너무 많았고 복잡하다보니 초반에 지라가 아니라 스크럼에서 공유되는 내용으로 주로 다른 팀원들의 진척도를 파악했었던 것 같다. 후반으로 갈 수록 익숙해졌지만 다음 프로젝트에서는 꾸준히 전체 진척도를 확인하며 사용해야할 필요성을 느꼈다.

• back 팀원과의 협력을 더 할 필요성을 느꼈다. 다행히 빨리 맞추었지만 되돌아보니 설계단계에서 컨벤션을 꼼꼼히 맞추지 않아서 서로의 코드를 이해하는데에 불필요한 시간을 쏟았었다. 오히려 초반에 충분한 시간을 들여 컨벤션을 맞추는 것이 시간을 아끼는 일임을 배웠다.

• front-back 간의 소통도 조금 더 필요했었다는 생각이 든다. API 문서를 처음으로 작성하다보니 request, response 데이터에 통일성이 부족해서 프론트에서 수정 요청이 잦았고, back에서 에러 처리를 하면서 커스텀 응답을 했었지만, front에서는 STATUS Code만 확인하여 디버깅 시에 잘 활용하지 못했었다. 소통의 중요성은 얼마나 강조해도 부족함이 없구나..

• 코드리뷰의 부재가 아쉬웠다. 큰(?) 규모의 프로젝트를 처음 진행하다보니 다들 주어진 일정만 급급하게 따라가고 다른 사람들의 코드를 확인할 여유가 부족했다. Merge Request 시 백 간의 코드는 확인하며 이해했지만 충분히 시간을 가지고 서로 의견을 주고받을 만큼의 리뷰시간을 가지지는 못했다. 솔직히 말하면 내 일에만 집중하느라 다른 사람들의 코드도 잘 보지 못했던 것 같다... 다음 프로젝트에는 적어도 같은 파트를 맡은 팀원간의 주기적인 코드 리뷰 시간을 가질 필요성을 느꼈다.

전략

• 팀원들간의 회의로 나온 결과이긴 하지만 깃 브랜치명을 issue 번호로만 가져간 것은 아쉬웠다. 심플하고 통일성 있었지만 누가 작성하는지, 어떤 내용인지, back인지 front인지도 브랜치 명 만으로 판단할 수가 없었고 반드시 jira를 들어가서 확인했어야 했다.

• API를 구성할 때 예외 케이스를 더 단단하게 짜고 코드를 작성하는 단계로 들어갔어야 한다고 생각이 든다. 마음이 급해서 빨리 설계를 마무리했지 않았나라는 반성이 든다.

✅ Try

글을 작성하는 지금, 두 번째 6주짜리 프로젝트를 진행하고 있다. 아쉬웠던 점들을 이번 프로젝트에 Try 해보자!

• 지라를 통해 다른 팀원들의 진척도를 보다 주기적으로 파악해보자.

• 다음 프로젝트에서는 인프라를 맡았으나 백과 소통하여 JMeter를 통한 쿼리 성능 테스트를 진행해보자.

• API 설계시 같이 참여하여 예외 케이스를 보다 꼼꼼하게 구현하자.

✅ 소감

🐱‍🏍 운좋게 좋은 팀원들을 만나서 도움을 많이 받았고, 전체적으로 기획부터 설계, 배포까지 프로젝트가 어떠한 플로우로 진행되는지 알 수 있었다. 좋은 분위기에서 프로젝트를 마무리할 수 있어서 행복하다 :) 다만 이번 프로젝트에서 내가 맡은 부분을 완전히 끝내는 것을 목표로 하다 보니, 서버 아키텍쳐와 통신 흐름에 있어서 이해가 부족함 또한 느끼게 되었다. 지금 프로젝트에서는 이를 극복하고자 인프라를 맡아 진행하고 있다.

🤦‍♂️ 기존에 업무를 진행할 때 큰 틀만 정하고 그 안에서 즉흥적으로 대응하는 것을 선호했는데, 프로젝트를 진행할 때는 설계를 더 탄탄하게 가져갈 필요성을 강하게 느꼈다. 3~4 주차 즈음 얼추 필요한 기능이 완료되었다고 생각했는데, 뒤로 갈 수록 오류도 많고 자잘하게 수정할 것이 많아졌다. 빨리 코드를 작성하는 것보다 같은 일을 반복하지 않도록 고민하여 설계하는 것이 오히려 더 빠른 방법임을 배웠다.

🙌 퇴사 후 비교적 늦은 나이에 도전하고, 시장 상황이 정말 좋지 않음을 알다보니 요즈음은 늘 조급한 것만 같다. 아직 많이 부족하지만 이럴 때일 수록 "우선 멈추고 박수치며 축하하고 가자"는 말을 품고 천천히 한 계단씩 밟으며 성장하고자 한다. 다들 파이팅이다 !.!