8주차 회고
드디어 6주간의 실전프로젝트가 시작되었다.
우리팀은 팀리더를 맡은 분께서 힙합을 주제로 진행하고 싶다고 먼저 말을 하셨고, 다같이 회의를 진행하여 그 주제를 가지고 프로젝트를 진행하기로 했다.
힙합에 관련된 공연 정보나, 힙합 크루들 정보같은 건 현재 하나의 사이트에서 확인할 수 있는 곳이 거의 없고, 대부분 각자의 팀SNS로 공연을 홍보하고 팀을 홍보하고 있다고 한다.
그래서 힙합에 관심이 있는 사람이 아니면 정보를 얻기가 어렵다고 한다.
위와 같은 상황을 고려하여 우리팀은 힙합에 관련한 쇼츠 영상,피드를 게시할 수 있는 커뮤니티를 기반으로 한 서비스를 기획했다.
힙합 크루로 인증을 받은 크루의 경우에는 공연 정보를 게시할 수 있게 하여 보다 효율적으로 홍보를 할 수 있도록하고, 유저에게는 힙합에 관한 영상/게시글을 통해 소통하고 공연정보를 한곳에서 얻을 수 있도록 하는 서비스를 만들고자 한다.
실전 프로젝트는 6주이지만 총 3주에 걸쳐 MVP를 개발하고 나머지는 유저 피드백을 받으며 , 우선은 와이어프레임을 만들고 첫주차 개발 scope를 정했다.
다들 항해에서 마지막으로 진행하는 프로젝트이고 실전 프로젝트인 만큼 욕심들이 생겨 상당히 많은 수의 기능 이야기가 나왔고, 그것들을 추리는데 많은 시간을 소비했다.
💡그렇게 정해진 1주차 Scope
1. 회원가입, 로그인, 소셜로그인(카카오)
2. Shorts 등록,수정,삭제 / Shorts 댓글 등록,수정, 삭제 / Shorts 좋아요
3. Feed 등록,수정,삭제 / Feed 댓글 등록,수정, 삭제 / Feed 좋아요
4. 전체적인 디자인 결정, 로고 결정
1주차 Scope가 정해지고 백엔드에서는 바로 엔티티 설계를 시작했는데, 지금까지 진행했던 프로젝트에서보다 다뤄야할 테이블이 늘어나고 여러 연관관계를 맺어줘야 하다보니 테이블 설계도 정말 어려웠다.
(프로젝트 도중에 여러번 테이블을 전부 날리고 다시 생성하는 삽질도 했다...)
테이블 설계가 끝나고 1주차 개발은 단순 CRUD라서 코드 작성이 오래걸리지는 않았다.
나의 경우 이미지, 동영상 업로드를 위해 S3 설정과 관련 코드 작성도 함께 해야 했는데, 처음 다뤄보는 S3라 걱정했지만 여러 기술 블로그를 참고하여 큰 문제없이 금방 구현할 수 있었다.
(기술 블로그여 영원하라!✨)
생각보다 담당 부분의 구현이 빨리 마무리 되어, 팀원들에게 자청하여 https 설정 및 서버 배포를 맡아 진행하였다.
서버 배포는 지금까지 여러번 해왔기에 큰 문제가 없었지만 https 설정은 2일에 걸쳐 겨우 마무리 할 수 있었다.
여러 기술 블로그를 보며 설정을 진행했는데, 원래 가지고 있던 가비아 도메인으로 https 설정을 진행하니 중간 과정이 없는 블로그들도 있어 따로 찾아보며 진행하느라 허둥지둥 했었다.
그리고 EC2에서 설정해준 포트포워딩에서 80 -> 8080 하나의 경우만 진행해도 되는데, 443 -> 8080도 같이 진행해버려 무언가 충돌이 나는 건지 계속 https 접속이 실패해서 "혹시나..?"하고 두번째 포트포워딩 설정은 삭제하니 아무문제 없이 https 접속이 되어버려 잠깐 현타가 오기도 했다🙀
1주차는 비교적 여유로웠기에 CI/CD 를 활용한 자동 배포도 도전해보고 싶었는데, https 설정에 생각보다 많은 시간이 소요되어 2주차로 미뤄진게 너무 아쉬웠다.
앞으로는 기술 블로그를 참고할 때 무작정 따라하는 것이 아니라, 한번 내용을 정독하고 나의 상황과 맞는지 잘 살펴보고 진행 해야겠다고 다짐하게 되었다.
(늘 이렇게 생각하지만 성격이 급해 무작정 해보고 마는데, 앞으로는 반복되는 삽질을 줄이기 위해서라도 찬찬히 살펴보는 습관을 들여야 겠다!)
9주차 회고
실전 프로젝트 2주차가 시작되었다.
2주차에서는 1주차에 비해 비교적 작은 범위의 Scope를 진행하기로 했다.
1주차의 CRUD를 전부 구현한 백엔드와 다르게 프론트엔드 분들은 기능에 관련하여 따로 공부하고 구현을 진행하느라 생각만큼 CRUD 기능 구현이 되지 않아, 2주차의 목표는 작게 잡을 수 밖에 없었다.
💡2주차 개발 Scope
1. CI/CD 자동 배포
2. 관리자 기능 구현
3. 구독,알람 기능 구현
4. 이메일 인증 기능 구현
5. 서버 로깅 설정
6. Redis Cache 설정
그래서 백엔드에서는 첫날에 CI/CD 자동 배포를 설정하고 2주차 부터 구현한 코드를 자동 배포해보기로 했다.
CI/CD 설정 자체는 큰 문제없이 완료되었는데, 2주차 내내 여러번 배포에 실패하는 일이 있었다.
원인은 여러가지가 있었다.
EC2에 설치한 Code Deploy Agent가 중지된 상태에서 배포를 시도해서 배포에 실패하기도 했고, 수동으로 서버에 nohup으로 어플리케이션은 실행시킨 다음번에 CI/CD를 통해 자동배포를 한 경우도 배포에 실패했다.
추측컨데, 수동으로 실행한 경우 EC2의 Code Deploy Agent가 인식하지 못해서 배포에 실패하는 것이 아닌가 생각된다.
그렇게 여러번 배포 소동을 겪고 나서, 배포 하기 전에 Code Deploy Agent의 실행 상태를 확인하고 배포를 진행하니 문제없이 배포가 되는 것을 확인할 수 있었다.
또 CI/CD 외에 쿼리 성능 향상과 Redis 캐시 설정에 대해 팀원들과 많은 이야기를 나누었다.
지금까지는 발생하는 쿼리의 횟수를 줄이는 것에 중점을 두고 JPQL을 사용해 테이블을 조인해서 한번에 데이터를 조회 해오도록 해왔는데, 기술 매니저님께서 쿼리의 횟수보다는 한번의 쿼리에 얼마나 많은 조건이 걸려있느냐가 성능을 더 저하시키는 요인이라고 말씀하셔서 쿼리문을 리팩터링하여 지금까지 작성한 쿼리와 어느쪽의 성능이 더 좋은지 테스트를 거친뒤 프로젝트에 적용하기로 했다.
사실 우리 프로젝트의 규모에는 크게 성능 차이가 느껴질 것 같지는 않지만, 쿼리 성능 향상에는 원래부터 관심이 많았기에 여러 방식으로 쿼리문을 작성해보고 반드시 성능 테스트를 진행하려고 한다.
Redis를 이용한 캐시 기능을 적용하려고 하던 중 "우리 프로젝트에는 캐시 기능을 적용하지 않는 것이 더 좋은게 아닐까?"하는 생각이 들었다.
동영상, 이미지를 메인화면에 많이 불러오기 때문에 캐시 기능을 사용하려고 했던 것인데, 아무래도 SNS 처럼 생성하고 수정하는 서비스 이기 때문에, 우리 서비스에서 대량의 트래픽이 발생하진 않겠지만, 게시글이나 댓글을 작성했을 때 바로 바로 반영시켜 주려고 하니 어떻게 캐시 기능을 설정해줘야 할지 고민이 되기 시작했다.
등록, 삭제때는 캐시를 삭제해주고 수정때는 등록된 캐시를 수정하는 방식으로 운영하려고 했는데, 수정된 사항을 실시간으로 반영시키는 부분에서 작성된 코드가 생각대로 작동하지 않아서 코드에 대한 고민과 함께 수정,삭제를 하기 쉬운 SNS 서비스에 캐시 기능을 적용하는 것이 맞는가? 하는 의문이 들기 시작했다.
이글을 쓰는 지금까지 계속 Redis 캐시 기능에 대한 자료들을 찾아보고 있는데, 내일 팀원들과 좀 더 구체적으로 캐시 기능을 어떻게 적용하고 운영할 것인지 이야기를 해봐야 할 것 같다.
