전체직인 프로젝트 후기
-
리팩토링 후 코틀린 마이그레이션 진행하는 방향이 좋다.
-
성공한 경우에는
resultCode를 200으로 단일 처리하는 것이 좋다.
(실제로 현업에서도 201, 204 등 따로 처리하는 것이 거의 의미가 없다.) -
서버의 개수가 늘어나면 Stomp와 SSE에 변화가 필요하다. 중간에 처리하는 외부 브로커를 추가해야 한다.
→ 외부 브로커를 통해 메시지를 중앙에서 관리하면, 여러 서버가 동시에 클라이언트와 통신할 수 있으며, 데이터의 일관성을 유지할 수 있다. -
채팅의 경우, 처음부터 Stomp로 시작하기보다는 WebSocket으로 먼저 실습해보는 것이 좋다.
다른 팀이 도입한 기술 구현 및 효과
| 주제 | 구현 방식 | 도입한 기술 | 효과 |
|---|---|---|---|
| 팔로우 - 팔로잉 기능 | Redis를 사용하여 팔로우/팔로잉 관계를 캐싱하고, Redis 장애 시 DB에서 데이터를 복구하는 스케줄러 구현 | Redis, 스케줄러 | 데이터 일관성 유지, 장애 발생 시 빠른 복구 가능 |
| 도서 검색 | n-gram 인덱스를 사용하여 제목과 설명을 인덱싱하고, 두 글자 키워드로 검색 속도 향상 | n-gram 인덱스 | 검색 속도 및 정확도 향상 |
| 채팅/알람 기능 | SSE를 구현하여 실시간 알림을 제공하고, Postman으로 테스트하여 기능 확인 | SSE, Postman | 실시간 데이터 전송, 사용자 경험 개선 |
| 첨부파일 처리 | 에디터에서 임시 이미지를 업로드하고, 최종 업로드 시 해당 이미지를 파일로 교체하는 방식 구현 | 이미지 처리 기술 | 사용자 편의성 증대, 이미지 관리 효율성 향상 |
| 페이지네이션 처리 | 최근 게시글 위주로 3개월 이내의 게시글만 표시하거나 오래된 게시글을 삭제하여 페이지네이션 최적화 | 데이터베이스 관리 | 페이지네이션 개수 감소, 사용자 경험 개선 |
| 휴대폰 인증 | 사용자가 번호를 입력하면 CoolSMS를 통해 인증번호를 발송하는 기능 구현 | CoolSMS API | 인증 과정 간소화, 사용자 신뢰도 향상 |
우리팀, POFO 프로젝트 피드백
-
사용자가 작성한 글을 삭제한 경우, DB에 남겨놓는게 더 좋다.
→ 정책에 따라 DB에 남겨놓지 않을수도 있는데 탈퇴 시 완전 삭제를 진행시키는 방향이 더 좋을 것 같다. -
소셜 로그인 계정 통합 및 관리자 대시보드 기능이 잘 구현되어 있으며, 실제 서비스에서도 기본적으로 해당 기능들이 구현된 경우가 많다.
→ 다만, 이메일 인증의 경우 개인정보 보호 방침 때문에 강사님은 이메일과 같은 개인정보를 최대한 받지 않는 방식을 선호하지만 해당 프로젝트는 토이 프로젝트이므로, 해당 내용은 참고하기
추후 프로젝트를 어떻게 고도화하면 좋을까?
아래와 같이 요청하신 내용을 표에 추가하였습니다.
| 고도화 방법 | 설명 |
|---|---|
| 성능 개선 수치화 및 마이그레이션 감소 수치화 | 성능 개선 및 마이그레이션으로 인한 감소 사항을 수치화하면 신뢰도 향상. ✅PPT에 수치가 많을수록 좋다 |
| AOP를 활용한 로그 저장 | AOP를 활용하여 Error 로그 및 Info 로그 저장. logback 설정으로 날짜별, 크기 초과 시 압축 및 일정 기간 후 삭제. |
| 깃허브 액션 CI 활용 | develop 브랜치에 올라오는 PR에 대해 병합 전 자동 빌드 및 테스트 진행. (빌드 시 gradle.test 진행하므로 별도의 test진행할 필요X) |
| 문의사항 게시판에서 채팅으로 변경 | 문의사항을 게시판에서 채팅으로 변경. 이미지 첨부, 이미지 저장, 드래그 앤 드랍 기능 추가. |
| Docker Compose 활용 | 운영 및 개발 서버의 시간 감축을 위해 Docker Compose 활용. |
| Swagger API 도입 | API 문서화를 위해 Swagger API 도입. |
| Redis 캐시 활용 | API로 내용을 가져올 때 Redis 캐시 사용하여 성능 개선 비교. |
| AI 도입 | chatGPT 가격 정보 고려해야 함. 무료 사용을 원한다면 구글 AI 사용 추천, SKT 통신사를 이용한다면 Perplexity 사용 추천 |
cf) 코틀린으로 마이그레이션 시 라인 수 변화 : 스프링 부트로 혜택을 보고 있기 때문에 코틀린으로 마이그레이션 시 30~40% 감소는 어렵고, 5%~10%가 이상적임
→ 만약, 스프링부트로 게임 개발을 한다면 코틀린으로 마이그레이션 시 코드라인 수가 많이 감소한다는 걸 체감할 수 있을 것이다.
→ 줄어든 라인수에 집착하기 보다는 코드가 코틀린스러운지를 파악하는게 더 좋을듯!
- Gemmni AI활용한 PR리뷰 써보기 : Gmmini API key env 파일에 넣기
- 로그저장
추가 공부해야하는 개념
- 동시성 이슈 : Redisson Lock
- webSocket : RabbitMQ
- JPQL → QeuryDSL 변환: kept, Qclass
- 페이징 방식 성능 최적화 : 데이터가 많을 수록 offset이 아닌 no-offset 활용해 부하를 줄일 수 있다.
- 현재 Hibernate lazyloading 문제 발생 중.. JPQL 오류와 관련이 있을 수 있음..
