v2. Choeaein Project를 진행하며..
이전에 진행한 v1.MyFavor project를 build-up하여 나오게된 결과물이 v2.Choeaein project이다. 이 프로젝트를 진행하면서 느꼈던 점들을 KPT회고 방식을 통해 정리해보고자 한다.
v1.MyFavor -> build-up => v2.Choeaein
v1은 5명(FE3 + BE2)이서 한 프로젝트를 v2에서는 FE1 + BE1으로 진행하였으며 나는 백엔드를 담당했다.
KPT 회고
Keep : 잘한 점과 지속해야 할 것
Problem : 문제가 된 것
Try : 시도한 점과 시도해야 할 것
Keep
- 서로 처한 문제상황을 공유하여 의견을 나누고 왜 발생했는지, 어떻게 해결해야 하는 게 나을지 합의를 도출한 점
- Query 최적화 prefetch_related와 select_related 이용함
- API 주소를 환경 변수 등으로 관리하여 인증링크의 노출을 막음
- 다중 카테고리와 일정 data를 client가 선택한 값을 전달 받아 이에 대한 data만 front에 전달함
- 이미지 서버 유지
- 배포를 위한 main branch, develop branch를 나누어 개선시킬점을 바로 배포하지 않고 따로 branch를 생성해서 개발생태계를 유지함
- Service 유지
- SMTP 서버 구축
Problem
- 로그인시에 서로 다른 Domain간 세션 쿠키 저장이 안됌
( Backend 개발 서버 https://~ - Frontend 개발 서버 127.0.0.1:3000 ) - 렌더링 하는 속도가 너무 느리다 -> 사용자의 이탈 가속 우려
- Django N+1문제
- 기존의 프로젝트는 Client-Side Rendering 으로 모든 page내에 있는 코드를 한번에 다운 받아서 client 단에서 실행 -> 이때 API를 호출하는 것도 시간이 걸림
- Cache를 적용시키는 것이 과연 브라우저 렌더링 속도를 높이는것에 무조건적으로 좋은 방법이라고 할 수 있나?
- 사용자가 회원가입을 완료하기 위해서는 이메일 인증을 해야하는데,
이때의 문제점은 사용자가 입력한 이메일 주소로 인증 링크가 전송되고 해당 인증 링크에서 Backend-API 주소가 노출된다는 점 - 다중 카테고리와 scheduel data를 모두 호출하는 문제
Try
- 우선, 장고 setting을 검토하고 front의 proxy서버 설정에 문제가 있는것으로 진단하였고 해결함.
- Query 최적화
- 이미지 서버 구축 ( AWS S3 )
- idol-image data를 cache화
- 아이돌 굿즈 상품들에 대한 항목 추가
느낀점
기존 프로젝트에서 유지할 기능, 개선될 페이지, 그리고 아예 변경이 필요한 API를 세분화했다면 작업을 수월하게 할 수 있었을텐데 라는 아쉬움과, 그럼에도 불구하고 새롭게 기획한 페이지와 개선해야 할 기능들은 서로 회의한 대로 잘 나온 것 같아서 너무 보람찼다. 개선을 진행하며 동작만 하면 끝냈던 코드들을 효율성 측면에서 다시 바라보니 또 다른 문제였고 다른 방식으로 해결해야 함을 인지할 수 있었다.
동료와 소통할 때 어떤 방식으로 얘기를 해야 할지에 대해 계속 고민하게 되었고, 같은 회의를 진행해도 서로 다르게 이해할 수도 있다는 것을 깨달았다. 그래서 회의가 끝나면 끝!이 아니라, 지속적으로 의견을 나누고 중간점검을 해야 서로를 위하여 덜 힘들고 작업능률이 올라감을 느꼈다.
서로의 지식을 공유하고 함께 문제를 해결하는 과정에서 단순히 코드적으로 잘친다가 아니라 어? 이건 생각하지 못한 방식인데? 하고 물음표가 느낌표가 되는 느낌을 많이 받았고 많이 배웠다.
회고를 하면 프로젝트가 진행되는 동안 '나의 행동'에 대해 이성적으로 생각하게 되고 생각 정리를 할 수 있어서 부족한 점과 내 방향성에 대해 고민할 수 있어서 참 좋은것 같다. 회고때 느낀 점들을 잘 기억하여 조금 더 개선된 내가 되고 싶다. 이상이다.
