항해99 실전프로젝트 중간발표 이후 개인 회고록 | 벌써 3분의 2지점 | 2022.11.28 월 |

항해99 실전프로젝트 중간발표 이후 개인 회고록

요즘은 팀원 분들 덕에 배워가는 것들이 너무 많은 하루하루다. 무에서 유를 창조해낸 기적같은 2달이었다. 드디어 끝이 보인다는 것에 감격스럽기도 아쉽기도 하고 그렇다. 함께가 아니었다면 이렇게 빠른 성장을 이룰 수 있었을까? 

아직 배워야 할 것도 많고 나눌 이야기도 많고 시간이 아주 조금만 멈춰줬으면 좋겠지만 아쉬움이 남아야 여운도 길게 남는 법. 아직 1달 정도 항해 유효기간이 남았으니 오늘도 후회가 남지않게 뒤돌아보지 말고 달려나가도록!

 

목차

- 중간 발표 피드백 정리

- 중간 발표 이전까지 트러블 슈팅 정리

- 중간 발표 이후 해야할 일

항해 실전프로젝트 중간 발표 피드백 정리

 

※ 내가 맡은 부분에 대한 피드백

이때 ❎는 지적 및 고쳐야할 점 🅾️는 약간의 칭찬이다.

 

🅾️ S3가 아닌 Cloudinary를 도입한 부분 참신

 

 피드백 내용 : 대부분 이미지 전송 할때 국룰로 모두 S3를 쓰는데 S3가 아닌 Cloudinary를 도입한 부분이 참신하다.

진짜 저렇게 말해주셔서 너무 감사했다. Cloudinary를 도입하기로 마음먹기 전에 S3로 이미지 업로드를 수행하고 있었지만 좀 더 실험 정신을 발휘해보고 싶었다. ( Cloudinary 말고도 몇 가지 선택지가 더 있었는데 특별히 클라우디너리를 선택한 이유를 알고 싶다면 아래에 있는 이전 포스팅을 참고해주시길 부탁드립니다.)

S3 대신 사용할 수 있는 클라우드 저장소들에 대한 고찰 : AWS S3, Cloudinary, 구글 클라우드 서비스

 

확실히 S3가 Cloudinary보다 빠르게 이미지가 업로드 된다. 지금 당장 사용하기에는 문제가 없지만 사용자가 늘어났을 경우엔 S3로 바꿔야하거나 Cloudinary에서 제공하는 성능 업그레이드 티어를 사야할지도 모른다. 일단 런칭 시 우리 서비스가 문제없이 돌아가서 사용자 경험에 지장을 주지 않으려면 다양한 솔루션을 만든 뒤 런칭 시 문제가 발생하면 재빠르게 교체할 수 있도록 로직을 설계해놔야할 듯하다.

도입 이유	프로젝트 초기에 폼으로 전송되는 멀티미디어 데이터를 모두 서버의 특정 경로에 저장했는데 불필요한 서버 자원의 낭비와 보완 위협이 수반되었다. 이를 해결하기 위해 클라우드 저장소의 도입을 선택했다. 백업 파일의 저장, 그리고 복구 측면에서 장점이 있고 확장성이 좋아 프로젝트의 '예상치 못한 성공'에도 미리 대비할 수 있을 듯 하다. 그래서 앞으로 해야 할 일은 비용적인 측면이 최우선으로 고려된 저장 방식의 도입 및 저장소 운영 비용의 효율적인 관리가 되겠다. AWS S3 등 다양한 선택지 중 Cloudinary를 특별히 선택한 이유는 서비스의 '초기 단계' 상황에서 MVP가 아닌 추가 기능 구현에 사용되는 자원에 대해선 비용 대비 나쁘지 않은 성능을 보여줄 수 있는 쪽을 채택하는 편이 이후 프로젝트 진행을 위한 비용관리 측면에서 더 도움이 될 것 같아서다.
문제 상황
해결 방안
결정

 

 

 

 

❎ 에러 처리 지적

에러 핸들링에 대한 지적을 받았다. ( 프로필 이미지 업로드 부분 )

개선 : 중간 발표 피드백 이후 설계되는 API에 대해서 TDD 를 적용. 단위 테스트를 하며 코드를 작성하고 통합 테스트를 거쳐 좀 더 견고하고 탄탄한 코드가 되도록 할 것이다. 이 를 위해 주말 이틀 동안 테스트코드 개념을 갈고 닦았지 하하

 

❎ 문자 인증 서비스의 불안정성

도입 이유	아무래도 사람과 사람간의 만남이 주축이 되어 돌아가는 서비스이다 보니 범죄에 악용될 수 있지 않을까 하는 우려의 목소리가 초기 서비스 설계 단계에서 부터 팀내에 꾸준히 들려왔고 개인의 안전 그리고 우리 서비스의 신뢰성을 잃지 않기 위해선 본인 인증 서비스의 도입이 필수불가결 하다는 판단 하에 문자 인증 서비스를 도입하게 되었다.
문제 상황	현재 사용하고 있는 setTimeOut 함수를 이용한 디비 관리는 좋은 처리 방식이 아님 (이유1) 인증번호 발급 후 배포가 이루어지는 상황에 대한 고려가 이루어지지 않음 (이유2) 서버에 큰 부하를 줄 수 있는 처리 방식임
해결 방안
결정
설계

 

 

 

※ 팀원 분들이 맡은 부분에 대한 피드백

✅ 우리 서비스가 레디스 도입으로 얻는 이점에 대해 재논의 필요

도입 이유	우리 서비스 특징 중 하나가 채팅방을 나가면 상대에 대한 정보가 모두 사라져 "찰나의 순간을 놓치면 기회는 다시 돌아오지 않는다"는 모티브에서 따왔기 때문에 채팅방 내용이 영구적으로 보관될 필요가 없다. 또한 우리는 의사결정 단계에서 이미 채팅 데이터를 수집해 2차 가공하는 행위를 배제했다. 위 두 가지 상황을 고려해봤을 때 REDIS를 활용하는 것도 나쁘지 않겠다고 판단했고 일단은 채팅 서비스에 국한해 레디스를 도입해봤다.
문제 상황	- 레디스에 들어가는 데이터들이 정말 유실이 되어도 괜찮은가? - 레디스를 도입해서 얻는 이점들이 그냥 몽고디비를 사용했을 때에 비해 탁월히 우수한가? -만약 레디스를 실제 서비스에 도입한다면 그 장점의 크기를 가장 극대화할 수 있는 방법에는 어떤 것들이 있을까?
해결 방안	레디스를 서비스에 도입할지 말지에대한 논의가 필요한 상황 우리 서비스에서 레디스를 도입했을경우 다음 트리거가 발생 1. 데이터 삭제 비용이 크다 2. 데이터의 무궁무진한 활용가능성을 막는 꼴
결정
이후의 진행

 

중간 발표 이전 까지의 트러블 슈팅 정리

 

중간 발표 이후 해야 할 일들

1. 업로드 가능한 이미지 확장자 늘리기 ✅

현재는 png와 jpg만 가능하지만 png, jpg에 더해 jpeg까지 업로드 가능하도록 이미지 업로드 미들웨어( 멀터 미들웨어 ) 수정하기

변경 전	png, jpg
변경 후	png, jpg, jpeg

2. 컨트롤러와 유효성 검사 부분 완벽히 분리하기 ✅

컨트롤러는 컨트롤러의 역할만 할 수 있도록 유효성 검사 부분을 미들웨어 처리로 대체한다. 이때 사용할 라이브러리는 npm에서 제공해주는 Joi. 

변경 전 ( 예시 ) 유저 컨트롤러 부분 코드	변경 후 ( 예시 ) 유저 컨트롤러 부분 코드

유효성 검사 부분을 따로 빼니 코드가 반절 이나 줄어든 것을 볼 수있다. 

에러 문구를 커스텀하게 주는 방법도 알아봐야 할 것 이다.

 

3. 닉네임 중복검사 기능 API 로 따로 빼기 ✅

기존 로직에서는 닉네임 중복 검사 기능을 POST /user라는 유저 회원 가입 후 필수 정보 기입 API 내에서 수행한다면 새로 바뀌는 로직에서는 닉네임 중복 검사 기능만 수행하는 POST /user/check라는 닉네임 중복검사 API를 따로 호출한다. 따라서 닉네임 중복 검사 기능만 따로 수행하도록 메소드를 분리해서 작성해주도록 하겠다. 

 

4. 문자 메시지 인증 로직 변경 

현재 사용하고 있는 setTimeOut 함수를 이용한 디비 관리는 좋은 처리 방식이 아니다. 이유는 크게 2가지로 추려진다.

첫번째, 인증번호 발급 후 배포가 이루어져야하는 상황이라고 가정해보자. 서버가 내려가면 작업 대기 중이던 함수가 모두 종료된다. 이렇게 되면 setTimeOut함수가 실행되지 않은 상태에서 종료되고 인증번호가 디비에 남아있어 인증번호 만료 시간인 3분이 지나더라도 인증이 가능한 상황이 벌어진다. 로그인 인증 토큰을 탈취해서 그 사용자 인 척 사용하는 공격처럼 이 인증번호도 가로채서 계속해서 사용하는 것이 가능하다.

두번째, 동시간대에 가입하려는 사람들이 몰렸다고 가정해보자.(가정이 아니라 런칭할 때 100프로 발생할 상황이다.ㅠㅠ)  사람들이 인증서비스를 사용하면 setTimeOut 함수 스택이 계속해서 쌓일 것이고 몰려있게 될 것이다. 

변경 전	변경 후
- setTimeOut 함수를 활용한 인증 만료 처리	- 디비 스케줄러를 통해서 인증 만료 처리 - 디비에 인증번호 저장할 때 생성 시간을 기록(혹은 몽고디비에 기록되어있는 생성시간을 써도 되겠다) - 생성된지 오래된 데이터를 한번씩 날려주기

거기에 더해서 혹시 모를 에러에 대비해 이메일 인증 서비스도 구축해놓아야 할 것같다

 

5. 이메일 인증 서비스 구축

문자 인증 서비스 문제 있을 경우 대비해 이메일 인증 서비스도 구축해놓아야 한다.

 

6. 관심사 태그 수집 및 가공

관심사 태그(해쉬태그)를 수집하면 어떻게 가공해서 사용할 것인가?