코드잇_스프린트_SB3기. 중급프로젝트 후기(고봉)

으음~ 귀찮아서 블로그 잘 안쓰는데,,
팀원들 프로젝트 후기도 넘 재밌고
어쩌다보니 마지막 타자가 되버려서 끄적여본다
 
현재 나는 코드잇 부트캠프 3기 백엔드 과정을 수강하고 있고,
그 안에서 초급, 중급, 고급 총 3가지의 프로젝트를 진행하게 된다.
 
초급은 약 2주, 중급은 약 한달, 고급은 약 한달 반정도의 기간동안 이루어지며
개인 과제와, 이론 수업을 토대로 요구사항이 점점 높아진다
이 흐름에서 파트가 4개로 분리되는데,
이론과 과제 위주인 파트1
초급 프로젝트가 포함된 파트2
중급 프로젝트가 포함된 파트3
고급 프로젝트가 포함된 파트4로 나뉜다
 
초급때 어쩌다 팀장을 맡긴했지만, 프로젝트 경험도, 기본 지식도 부족한 상태여서
프로젝트를 잘 끝내고 나서도 마음이 불편했다 ㅜ
팀원들의 캐리로 만족스러운 발표와 결과물이 나와서 팀원들에게 너무 고마웠다
그래서 중급 프로젝트에선 초급을 기반삼아 더욱 열심히(?) 소통하고자 했다
 
파트1, 파트2를 거치며 팀운이 너무 좋다는 생각을 항상했었는데
이번에도 좋은 팀원들을 만났다…!
파트1땐 팀원들과 멀어지는게 아쉬웠는데
점점 지나고 보니 새로운 사람들과 소통하고,
문제 상황이 생겼을 때 여러 도움과 정보를 받을 수 있어서 좋았다
 
사실 대면으로 프로젝트를 진행했다면 이렇게까지 친해질 수 있었을까..? 싶다
 
프로젝트 주제는 두가지로

• 덕후감

도서 이미지 OCR 및 ISBN 매칭 서비스
대시보드에서 인기 도서, 유저, 리뷰를 확인할 수 있는 책 커뮤니티 서비스

• 모뉴

MongoDB 및 백업 및 복구 시스템
여러 뉴스 api를 통합해 관심사 기반으로 뉴스를 저장하는 통합관리 플랫폼

 
우리팀은 이 중 덕후감을 진행하기로 했다
사실 주제를 보자마자 덕후감을 하고싶었는데
초급 프로젝트때 했던 hrbank와 유사한 것같아 모뉴로 마음을 틀었다,,
한편으론 이해할 수 있을까..? 싶은 걱정이 있었는데
투표 결과 3:2로 덕후감으로 결정되어 뭔가 다행(?)이였다
 
 

1. 프로젝트

프로젝트 주제

• 프로젝트 기간 : 7/ 8 ~ 7/30
• 제목: 덕후감
• 소개: 도서 이미지 OCR 및 ISBN 매칭 서비스

📚 책 덕후들을 위한 특별한 공간, 덕후감에 오신 걸 환영합니다! 덕후감은 ISBN 정보를 기반으로 책 정보를 자동으로 불러와 리뷰와 감상을 나눌 수 있는 책 커뮤니티 플랫폼입니다. 덕후감은 독서를 혼자만의 취미가 아닌, 함께 나누는 즐거움으로 확장하는 경험을 제공합니다. ✨📘

• 난이도: 중급

프로젝트 구조

사용한 기술 스택

Spring Boot, JPA, QueryDSL, AWS, Spring Batch, Tesseract OCR, Naver OpenAPI, H2, PostgresSql, docker

 
프로젝트 구조는 도메인 주도설계패턴으로 패키지를 분류했는데
전 프로젝트나, 미션땐 기능 위주로 분리해서, 안 써봤던 방식을 써보고싶었다
적용해본 소감은 패키지가 엄청나게 많아져서 조금 복잡해보인다는 생각이 들었다
확인하기가 불편했다..
다만 기능 하나를 작업할 땐 짱 편했다!
 
기능

• 사용자, 도서, 리뷰, 댓글, 알림, 대시보드
• 각 기능들은 물리삭제가 아닌 논리삭제방식을 사용한다
• 대시보드 기능은 배치로 연산해 순위를 구함

이 중에서 나는 리뷰와 댓글 기능을 팀원과 분담해 맡았다

---

2. 프로젝트 흐름

프로젝트를 들어가기 전에 약 4일간의 회의를 진행했다

• 팀 규칙
• 요구사항 파악
• R&R분배
• ERD 설계
• 공통 코드 작성

프로젝트를 수행하기 위해 필요한 것들을 의논하고,
주어진 요구사항을 분석해 분담한다
이때 팀원 중 한분이 재밌는 제안을 하셨는데..!
바로바로 출석부찍기
넘 재밌었다 ㅎㅎ 출석부 찍으려고 주말에도 편의점에서 플젝하고 그랬다.ㅎ.ㅎ
빼곡히 채워지는 출석부를 보면서 뭔지 모를 성취감(?) 이 느껴졌달까..
 

요구사항 분석

중간 발표를 기점으로 1차, 2차로 개발 기간을 나눴다
이유는 대시보드같은 경우 배치로 연산해야하는데, 한명이 감당하기엔 부담이 크고,
다른 기능과 관련도가 높아서 기본적인 기능을 개발하고, 후에 대시보드 기능을 구현하기로 했다
팀원 중 현업 경험이 있는 분이 계셔서 꼼꼼한 요구사항 분석이 가능했다..! 💟
사이즈와 중요도를 같이 분석하고 그에 맞게 개인 일정을 정했다

⛅ ERD 설계

초급 때 초기 erd 설계가 너무 중요하다는 걸 느꼈었는데..
완벽하다고 생각했던 erd도 개발을 진행하다보면 또 수정 사항이 생겼다 ㅜ
초급때 문제상황을 간략히 말해보자면
이때는 물리삭제를 기반으로 기능 구현을 진행했는데

직원을 삭제하면 수정 로그 테이블에서 참조하고 있는 직원 id값이 notnull로 지정되어있어
삭제가 안됐었다.. null 처리를 할지 고민하다
팀원 한분이 논리 삭제 처리하는 방법을 제안하였고,
이때 논리 삭제 방식을 적용해 리팩토링 했으나..
부서를 삭제할땐 직원이 존재하면 삭제되지 않도록 해야하는 요구사항이 있었는데
실제 삭제되는 직원은 없기 때문에 부서를 영영 지우지 못하는.. ㅜㅜ 문제가 있었다
 
결과적으로는 수정 로그 테이블에 직원 id fk를 제거하고, 사원 번호 컬럼을 추가해 해결했었다
무튼 이때 논리삭제를 찍먹해보았기 때문에 이번 플젝에서 잘 적용할 수 있을 것같았다..
 
 
이번에 생겼던 문제상황은
도서(1개) → 리뷰(1개) → 댓글(n개) 의 흐름에서
도서id와 사용자 id를 unique로 걸어놓았었는데
리뷰를 삭제하면, 사용자 입장에선 다시 리뷰를 등록할 수 있다고 판단하겠지만,,
db에는 해당 사용자를 해당 책에 리뷰를 남긴것으로 남아있어
추가 등록이 안됐었다
 
유니크제약을 제거해야할지 고민하다
팀원이 좋은 방법을 제시해주셨다!
기존 제약을 제거하고, where is_deleted = false 조건을 포함한 인덱스를 만들어서
논리 삭제되지 않은 리뷰에 한해서면 유니크 조건을 걸어주는 것이당!
 
초급때 이방식을 적용했으면 부서 삭제도 가능했을 듯하지만
사실 수정 로그 테이블에선 직원 id를 가지고 있을 필요가 없었기 때문에 적절한 방법이였다는 생각이 든다!
 
추가로 리뷰-좋아요를 논리 삭제할지 의논했었는데
사용자가 의도적으로 좋아요, 취소를 반복하는 경우 delete 쿼리가 계속해서 나가게 되어
성능적으로 문제가 있을 것같다는 의견이 있었다
멘토님도 삭제, 생성과정이 사용량도 크고 비용도 높아 논리삭제를 고려하는것이 좋을 것같다고 하셨지만
강사님은 의도적인 좋아요/취소가 많지 않을 것같고, 보통 그런 과정은 배포후에 모니터링을 통해 수정한다고 하셨다
그래서 우리는 일단 물리삭제로 진행하기로 했다
 
또, 다대다 관계 해소를 위한 중간 테이블에는 pk값이 필요하지않다고 생각했었는데
현업에서는 복합키만 쓰는 경우는 거의 없다고 했다!
 

🐰 코드래빗, 디스코드 연동, 코드위드미

이번 플젝에서 팀원이 코드래빗 설정과
깃허브와 디스코드를 연동해 바로 알림받을 수 있도록 해주셨는데
넘나 유용했다..!
특히 코드래빗은 리뷰어가 놓친 부분이나,
기능 구현자가 생각하지 못했던 부분을 바로 짚어줘서 너무 좋았다
프로젝트 구조를 알고 있기 때문에 리뷰 자체의 퀄이 좋달까..
 
코드윗미는 전체가 인텔리제이 창에서 코딩할 수 있는 기능인데
공통 코드 작성할 때 편했다
한명이 화면 공유를 하면서 의논하고 필요한 부분을 서로 채울 수 있었다
컴터 이름으로 사용자가 보이는데..
내 컴이름이 PC_1M이였어서 한창 놀림받았다 (보다보니 멋진거 같기도..)
그 안에서도 이름 변경되던데 구냥 컴터 이름이랑 루트폴더명도 바꿔버렸다
(이때 컴터 날라갈 뻔했다..)
 
 

개인 기능 구현

핵심 기능은 도서라 주요 기능은 아니였지만(힘써주신 팀원들 최고~!)
초급 때 사용자기능을 맡았었기 때문에
이번엔 리뷰와 댓글쪽을 맡았다
커서값 파싱때문에 잔잔한 오류들이 있었고,,
 

📖 리뷰 기능 !

중간에 위에서 말한 유니크 조건 때문에 시간을 썼었다
이때 처음 적용한 방식이 논리삭제된 도서-사용자의 리뷰가 존재하면
그 db값을 가져와서 is_deleted=false로 바꾸고, 내용을 변경하는 복구방식을 적용했었다

관련 pr리뷰

 
팀원들과 의논 끝에 결론적으론 인덱스 생성으로 깔끔하게 해결되었다..!
 
 
추가로, 프론트에선 0.5단위 평점도 선택이 됐었는데, 실제 값은 정수로 반올림되고 있었다
스웨거에서도 평점 타입이 나와있었는데.. 이걸 놓쳐서 스키마를 수정할 일이 또 생겼었다
 

👍🏻 좋아요 기능!

요구사항 명세에서는 post응답 하나로 liked를 true, false로 변경해 공통 200응답으로 반환하길래
처음엔 등록, 삭제를 따로 구현했다가
한 메서드에서 토글 형식으로 변경했다
 
 

🧑🏻 사용자 삭제배치 기능

이건 나중에 추가된 기능이였고 구현하지 않아도 된다고 했던 부분인데
팀원들이 대시보드 기능으로 힘들어하고 있을 때 아무 도움도 주지 못한게 너무 미안했었다..
나중에 요구사항을 보니 논리삭제된 사용자를 배치로 하루마다 삭제해주는 기능이 추가됐길래
해보고 싶어서 내가 하겠다구 했다
다른 분들보다 간단했지만 직접 해보면서 공부해보니 팀원들의 얘기가 무슨 말인지
잘 이해할 수 있었다!!
 

그 외

초반에 글로벌 핸들러도 추가해보고, 커스텀 예외를 위한 구조도 추가했다
팀원들이 열심히 배포할 때.. 스웨거 명세도 작성하고,
본인이 남긴 댓글은 알림이 안가도록 제외하는 리팩을 진행했다
배포해준 팀원들 짱~!
 
코드가 합쳐질 때마다 기능이 점점 작동하는게 넘나 재밌었다..
멍청 이슈로 많은 의견을 나누지 못한게 미안하다 ㅜ
 

🎯 테스트

tdd방식을 적용해 프로젝트를 진행하라는 요구사항이 있었지만,,
쉽지 않았다ㅜ
 
후에 강사님의 협상안으로
TDD 자체에 있어 집착하지말고, 테스트자체에 더 집중해도된다는
얘기를 듣고
한개의 기능에만 red-greean-refactor를 적용해 보았었다!
 
그 외에도 테스트 환경(h2)과 실제 스키마(postgresql)이 달라 발생했던 문제,
잘 되던 테스트가 ./gradlew 로 테스트시 깨지는 문제 등..
여러 고난이 있었지먄..
다들 열심히 수정해주신 덕분에 약 80퍼의 코드 커버리지를 찍었당~!
 

---

3. 후기

사진 잘쓸게용

팀 분위기 덕분에 재밌는 프로젝트 기간이 됐었다..! 낯가려서 장난도 잘 못치다가..
슬쩍 던져봤는데 다들 넘 잘받아주셔서 그때부턴 신나게 떠들었다
물론 텍스트 한정으로..ㅎㅎ
 
중간에
피싱 이슈
정전 이슈
단도리 이슈
쌀이, 광복이 귀여운 이슈
강사님 보따리 이슈
알고리즘 어려워 이슈
등등 기억에 많이 남는 플젝일 듯하다!
 
나만 너무 멀리 살아서 ㅜㅜ
연예인 한명, 천재 악마 한명, 슬픈 눈을 가진 사나이, 모자 다수 보유한 출석부 광공맨
실물 영접 못한게 아쉽다..
서울 갈 때 꼭 집합 시키겠습니다 저와 놀아주세요

ㅎㅎ

 
이상 중급 플젝 후기 끝- dO_Ob