5주차 멘토링

✔️ 체크리스트

• 사용자가 서비스를 사용할 수 있는 수준으로 주요 기능이 개발되었다.
• GitHub 저장소만 봐도 프로젝트 개요, 기술적 도전, 구현 과정을 누구나 알 수 있다.
• 나와 우리 팀의 기술적인 자랑거리나 강점이 무엇인지 그 이유와 함께 설명할 수 있다.
• 6주차에 리팩토링 또는 개선할 영역에 대한 계획이 있다.

✔️ 결론 및 To Do

✔️ 멘토링 아젠다

논의 사항 및 질문

• 멘토님께서는 리팩토링 기간에 어떤 작업을 하셨나요?

• 리팩토링할 때 어떤 부분을 중점으로 고쳐나가야 할까요? (코드 품질, 성능 등등)

• Nginx 로드밸런싱을 진행해보면서 Socket.io를 사용하는 저희 서비스의 특성 상 세션이 유지되어야 하기 때문에 ip hash방식으로 로드 밸런싱을 진행하게 되었습니다. ip 가 달라져야 로드밸런싱이 일어나는 이러한 서비스에서 부하 테스트를 해보는 좋은 방법이 있을까요..? 나름대로 찾아봐도 방법을 찾을 수가 없어서 여쭤봅니다..

• 최종 발표 준비를 어떻게 해야 할지 고민됩니다.

  • 이번 주 주간 발표 시간에 미니 데모 발표 느낌으로 발표를 하라고 되어있던데, 그날 받은 피드백 위주로 고쳐나가면 되는 걸까요?

  • 6주 동안의 고민과 구현 과정을 15분에 녹이는게 쉽지 않은 것 같습니다.

    JuGa 5주차 데모 공유 발표.pdf

    그룹 리뷰 및 발표 준비 (여기에 대본이 있습니다!)

• 저희 깃허브를 처음 방문하시는 분들은 위키보다는 리드미를 먼저 보실텐데, 리드미에 어떤 정보들이 들어가야 할까요?

  • 또, 네부캠 멘토님과 마스터님들은 깃허브 위키에 우리의 활동이 기록되고 있다는 걸 알고 계시니까 자연스럽게 위키로 들어가셔서 보시는데.. 이 이외에 이력서 등에 활용할 때를 대비해 리드미에 위키로 가는 링크도 추가해야 할까요?

• 저희가 웹소켓 자원을 아끼기 위해 즐겨찾기 종목 탭 같은 경우에 실시간 주가를 지원하지 않고 있는데, 실시간을 어디까지 지원하는게 사용자 관점에서 좋을까요? 멘토님께서 사이트에 들어오셨을 때 어떤 부분이 실시간이었으면 좋겠다, 어떤 부분은 실시간이 아니어도 될 것 같다, 하는 부분이 있을까요??

• 프론트엔드 error boundary, suspense 설정 관련해서 좋은 팁이 있을까요??

• 현재 로그인이 되었는지 안되었는지 판별하는 check라는 api가 isLogin을 false로 반환할 때 status code를 401로 해야할까요? 200으로 해야할까요?

진행상황 및 참고 자료

멘토가 일지를 보고 멘토링을 준비할 수 있도록, 팀의 진행상황과 참고 자료를 정리해서 넣어주세요.

JuGa

• ID: jindding, PW: 1234

✔️ 멘토링 내용

멘토링을 진행하며 나눈 이야기가 휘발되지 않게 기록해보세요.

• 멘토님께서는 리팩토링 기간에 어떤 작업을 하셨나요?

• 리팩토링할 때 어떤 부분을 중점으로 고쳐나가야 할까요? (코드 품질, 성능 등등)

  • 취업 연계를 했어서 이력서 작성
  • light house 점수 올리기
  • 버그 수정
  • 발표 준비
  • 문서화
  • 손이 좀 남는 사람은 최적화
  • 테스트 코드 작성
  • 모듈화! (코드 마음에 안들었던 부분 수정해보면서~)

  ⇒ 기능 추가는 어렵고, 기술적 도전도 어려운 6주차. 그런건 나중에 한다고 가정하고, 리팩터링! 버그 발생하는 걸 잡는게 가장 좋을 듯하다.

  ⇒ 손이 좀 남는 사람이 있다면 최적화 신경 써보기

• 부하 테스트

  • 마스터 클래스에서 질문해보기!
  • 몇천번 보내서 서버 터트려보고, 로드 밸런싱 추가한 다음에 잘 동작하는지를 보여준 거 같음.
  • 임의의 스크립트를 짜서 계속 요청 보내보는 방식으로 해보기..

• 최종 발표 준비

  • 소스 자체는 좋다! 아래 피드백대로 잘 생각해보기 ㅎㅎ
  • 메인 페이지, 상세 페이지, 랭킹 화면 사진으로 찍어서 올리기
    • 화면이 이미 있는데 저런 이미지 파일 쓸 이유가 없다고 생각!
  • 2번 세분화
    • 1, 2, 3, 6 트러블슈팅 + 라이브러리 없이 차트 구현하다가 발생한 이슈는 여기에
      • 앞에 1, 2, 3, 6 되게 좋음. 발표한다면 3개가 제일 무난할 거 같음. 시간 되면 4개 하고.
    • 4 기술
    • 5 구현내용, 시연에서 강조하면서 이야기하기!
    • 해결 못한 7번 빼기! UX적으로 해결해나갈 예정이면,, 해결하고 나중에 추가해도 될듯
  • 5주간의 과정(트러블 슈팅) 이거 하나당 2분만 잡아도 시간이 많이 걸릴 듯 하다.
    • 제일 임팩트 있는 부분을 꺼내서 쓰기
    • 세션 어쩌고
      • 해결하려던 과정이랑! 결과가 있으면 좋겠는데…. 결과가 사실은 없으니까
      • 트러블 슈팅 과정을 원인과 과정, 그리고 결과까지 있으면 좋다
        • 원인: 세션 당 41개밖에 안되는데 효율적으로 쓰고 싶음
        • 과정: 중복 구독 안되게 하고, 연결 끊기면 바로 끊기게하고, 로드밸런싱 하고..
        • 결과: ??? 실질적 효과는 잘 모르는 부분. 열심히 하고 학습은 됐지만 실질적인 도움이 됐는지를 판단할 수 없어서, 조금 애매할 수는 있다!
          • 효과를 봐야했는데, 효과를 못본 걸 수도 있으니까..
          • 결과를 수치로 만들 수 없으면 후순위로 미뤄도 될 거 같음
          • 과정까지만 말해도 괜찮긴 할 거 같다! 그치만 결과가 있으면 더 좋을 거다!
    • Redis
      • 비교군이 하나 더 있으면 좋겠다. / 스케줄러 만들어서 하나 더 하는거 생각하긴했는데 이렇게 해도 괜찮을듯.
      • 로그인 유저에 대해서 히스토리 저장한다는 사실을 언급하면 좋을 거 같음
        • 로컬 스토리지는 비로그인, 레디스는 로그인 유저에 대해서.. UX에 대해 고민한 거 같음
        • 로그인하면 로컬 스토리지가 날라가는지???? → 로그인하기 전에 검색해서 로컬 스토리지에 저장된거랑, 로그인 하고 난 뒤에 레디스에 저장된거랑.. 둘이 똑같은거 검색했을 때 중복해서 뜨지 않는지.. 뭐 이런걸 처리했는지???
      • 이슈 발생이 안됐는데 적용한 느낌이 있긴 함. 그냥 이렇게하면 좋지 않을까싶어서 반영한게 좀 많긴 한 거 같음
        • 시간이 된다면, MySQL 응답 속도와 Redis 응답 속도를 비교해서 성능에서 어느 정도 이점을 받았는지 보여줘도 괜찮을 것 같음
    • 체결 동시성 트랜잭션 처리
      • 그림 자체만 보면.. 느낌은 알겠지만 로드밸런서랑 뭔 상관인지 하나도 알 수 없음! 말로 설명한 걸 그림에 잘 녹여내면 좋을 듯
    • 기술 소개 같은건 앞에 빼도 좋을 거 같음, 서비스 핵심 기능 얘기한다음에 기술 쓴 거 싹 나열해도 괜찮을 것 같음 (SSE socket 비교 같은거. PPT 넣어도 되는데 리드미나 위키에 넣어도 좋을 거 같음! 기술 소개할 때 언급해도 좋을 거 같다)
  • 핵심 기술 소개할 때 자랑스럽게 이야기할 거 같은 내용을 넣기.
    • 매수할 수 있고, 매도할 수 있어도, 그냥 약식으로 매수만 보여주고! 이런 식으로 해도 상관없음. 트러블 슈팅이나 핵심 기술 같은거 중에 더! 중점으로 보여주고 싶은걸 잘 골라서 해보기
  • 트러블 슈팅 과정은 굉장히 좋음!

• 저희 깃허브를 처음 방문하시는 분들은 위키보다는 리드미를 먼저 보실텐데, 리드미에 어떤 정보들이 들어가야 할까요?

  • 리드미에 위키 바로가기 같은 링크 걸어도 됨!
  • 리드미를 엄청 길게 쓴 사람도 있는데… 취향차이임.
  • 둘 다 비슷하게 써라~

• 실시간이어야 할 거 같은 부분, 실시간이 아니어도 될 거 같은 부분?

  • 즐겨찾기 부분은 실시간으로 왔다갔다 하는게 보고 싶음. 즐겨찾기 부분은 필요할 거 같다!
  • 세션 늘릴 거면 하고싶은거 다해봐라!
  • 세션은 현실적으로 많이 못만드는 거니까! 30개 하는거 고려해도 좋고,
  • 41개 다 찬 이후에 새로운 요청 오면 사용자가 많아서 사용이 불가능하다~ 하는 경고창 띄워도 좋을 거 같음!!
  • 웬만해서는 다 실시간인게 좋을 거 같다..ㅎㅎ

• 프론트엔드 error boundary, suspense 설정 관련해서 좋은 팁

  • 지금 설정? error boundary는 루트에만 해놓고, react query isloading, iserror 이렇게 받아오면 텍스트로 띄워두고 있는 상태
  • 에러 코드 잘 구분해서, (백엔드랑 잘 협의해서) 에러 메시지 띄워줄 수도 있을 거 같고, alert으로 메시지 띄워줄 수도 있을 거 같고.. API에서 예외처리를 많이 해주는게 중요함.
  • 로그인 필요한 곳인데, 로그인 안된 채로 접근하려고 하면 서버에서 에러메시지 잘 뿌려주는게 중요!
  • 이 정도만 해도 될 거 같은데?? 궁금한 키워드 + best practices 라고 검색하면 좋은 자료들이 좀 많이 나옴!
  • 백엔드에서 에러를 예쁘게 내려주고, 프론트가 어떻게 캐치해서 할지 고민을 많이 하는 편

• 로그인 판별 API 상태 코드?

  • auth/check 같은건 isLogin 내려온 건 에러가 아니니까
  • 로그인이 안되어있는게 에러는 아니니까, 200이 오는게 맞는 거 같음. 그냥 true인지 false인지 그거니까
  • 지금은 에러를 캐치해서 로그인 여부를 확인하고 있었다. 그러면 false로 내려오는 의미조차 없는거겠네용

• 멘토님 회사에서 일어났던 일

  • 게임하고 잘려고 하는데 갑자기 슬랙에서 알람이 진짜 수백개가 왔었음 (회사에러)
  • POST API에 파라미터에 UTF-8 아닌 거 보내면서 에러 발생시키고 있었음 (루비에서 utf8 아닌거 json으로 바꾸니까 에러가 나긴했음..)
    • 슬랙이 수천개 와서, 일단 슬랙에 안울리게 하고 IP 밴을 했음
  • 같은 IP에서 1초에 5번씩 막 요청하고 있었음.. 이러면 이슈가 없나?
    • 회사에서 1초에 천개까지는 요청을 받을 수 있음. 그래서 다행히 큰 문제는 없게 넘어갔음
    • 막는 방법
      • IP 차단하기
      • AWS 쓰면 WAF 라는 기능도 있었음! 이런거 알아보면 도움이 될 수도 있을 거 같다!

리팩터링, 버그 수정, 발표 준비 잘하고!! 발표 전날에 만나는 게 좋을 거 같다~ 회고 미팅 + 발표자료 가볍게 보는 자리를 갖는게 어떨까 싶다.

진짜 한주 남았으니까 한주 힘내시길 바랍니다!!