멘토링 6주차

최종 멘토링

• 발표 피드백
• Q&A

최종 발표 피드백

• 전체적인 Flow가 좋다.

  • 문제점 + 해결 + 결과의 틀이 있어서 좋다.

• 아쉬운 점: 초밥이라는 SW에 대한 설명이 너무 없고, 기술적인 설명에만 초점이 있음 → 간단하게 라도 넣자. 모임방 + 방 안에서 음식점 찾고 + 투표한다. 라는게 1~2장은 있어야함 처음보면 뭘 구현한지 모를 듯.

• 아키텍처에 대한 사진이 없는데, 그게 필요. (프론트, 백엔드 서버.. 어떻게 통신. .. ) 소프트웨어 아키텍처. 그림이 한 장은 있어야 함

• 기술을 선택한 이유에 대해 설명하는게 엄청 중요한데, 그런게 잘 들어있어서 좋다. (Redis, infinity scroll)

• 기술적 도전 → 기술적 도전도 괜찮은데, 이슈의 관점으로 접근해도 좋을 듯. 우리가 만난 이슈 + 기술적으로 어떻게 풀어냈다.. 이슈를 만났을 때, 어떻게 풀어내는가? 이게 중요! Redis를 이용한 캐싱 → 외부 API 를 효율적으로 사용해야하는 이슈? 이런식으로.. 왜 했는지 문제 상황을 정확히 정의하고. 아~ 그래서 했구나.가 명확하게.. 나오도록 제목 바꾸기

• 데이터 플로우 아키텍처가 있어야함. → 추가적 요소. (외부 API 언제 호출? 어떤 플로우로 데이터가 왔다갔다? 어디에서 문제가 생겨서 레디스를 넣은건지 딱 볼 수 있도록 )

• 15p 움짤 좋았음.

• 17p 페이징 도입 이유를 좀 더 자세히 설명해라. 초기 렌더링이 느린 문제, 백엔드 API의 초기 부담이 넘 많다던지.. 그런 이슈들을 고민하다가 페이징을 고민했다. 식으로 이슈를 구체화!

• 18p 가상화 목록 사진?

• 인피니티 스크롤 result 사진은 .. 백엔드 요청 수 줄어든거를 보여주면 좋다.

• 백엔드에서 Compression 쓰면 알아서 gzip으로 묶어줌. (보통 메가바이트, 500kb 넘으면 압축. 보내는 시간이 길어서 느려져서..) → 그러면 바이트 단위로 내려오기 때문에 응답속도 빨라짐.

  그리고 큰 데이터만 보통 gzip으로 묶고, 작은건 안함. → 하는게 더 손해 압축, 압축 푸는게 더 낭비.. 압축 이유: 보내는 시간 단축. http 전송이 최대 용량이 1500바이트 → 3웨이 핸드셰이킹 여러 번 발생하는 것을 막아줌.

  마커 이미지 줄이려고 gzip 썼다.는 내용은 좋음.

Q&A

Q1. 현재 페이지네이션은 썸네일 이미지에 대해서만 적용되는 사항인데 이를 따로 설명해주어야 하는지 고민이 됩니다.

현재 인피니티 스크롤, 가상화 목록이 적용되는 부분은 썸네일 이미지에 한정적입니다. 이를 발표를 듣는 사람에게 정확히 전달해야 할까요??

A1.

굳이 자세히 언급하지 않아도 될 것 같다. 적용한 기술 위주의 Q&A가 될 가능성이 높아서 주저리주저리 설명하게 되면 오히려 전달력이 떨어질 수도 있다.

---

Q2. 가상화 목록을 도입하여 발생하게 된 이슈가 있는데, 이에 대해 따로 언급을 해야할 지 고민이 됩니다.

가상화 목록 적용 시 뷰포트 내 리스트 요소들이 재렌더링 되면서 깜빡거리는데, 이로 인한 버튼 이슈가 존재합니다. 이를 따로 언급하는 것이 좋을까요??

A2.

개발 기간이 굉장히 짧았기 때문에(6주) 해결하지 못한 이슈가 당연히 존재할 수 있고 이러한 부분들은 마지막 장에 따로 언급을 해줘도 나쁘지 않을 것 같다. 실제 현업에서도 크리티컬한 이슈가 아니라면 이슈에 대한 파악만 해두고 해결은 나중에 한다.

Q2-1. 이에 대한 해결 방안이 아직 나오지 않아 언급하기 망설여집니다.

A2-1.

시간이 남는다면 그래도 언급하면 좋을 것 같고, 그렇지 않다면 빼도 괜찮겠다.

---

Q3. 인피니티 스크롤 부분의 Result가 좀 부족한건 아닌지??

A3.

지표를 보여주고 싶다면 BE에서 받은 요청 수의 감소? 같은 것을 측정해서 추가해도 좋을 것 같다.

---

Q4. 전송되는 svg 파일의 크기를 줄이려고 gzip 압축을 도입한 것은 맞으나, 결론적으로는 전반적인 정적 파일에 대해 압축이 적용되었습니다. 이를 발표 시에는 지도 렌더링 성능 최적화에만 국한지어 언급을 해도 되는지 궁금합니다.

A4.

괜찮다고 생각한다. 추가적으로 백엔드 측에서 Compression을 이용하면 정적 파일들의 압축을 알아서 수행해줘서 편리하다.

Q4-1. 정적파일 중 덩치가 큰 파일만을 따로 압축하는 이유가 있는지 궁금합니다.

A4-1.

파일의 크기가 너무 커지면 여러번에 걸쳐 파일을 전송하게 된다. 각 TCP 전송의 최대 청크는 1500kb이기 때문에 더 많은 handshake가 발생하고 이는 속도의 저하로 이어진다. 파일의 크기가 작다면 불필요한 압축이 되는데, 이는 압축된 파일을 클라이언트 측에서 푸는 과정이 추가되기 때문이다. trade-off가 존재하기 때문에 적절한 압축 파일 사이즈를 정하는 것은 중요하다.

---

Q5. 개발 일정에 쫓겨 테스트 코드 작성이 아예 안되어있는데 이 것이 어떻게 작용할까요???

A5.

물론 작성이 잘되어있다면 무조건 플러스 요인이지만, 그렇다고 없다고 해서 마이너스가 되지는 않을 것이다. 얘네 바빴구나 ~ 정도로 생각할 수도 있다.

---

Q6. 시연 영상에는 자막을 넣는게 좋을까요? 아니면 실제 육성을 넣는게 나을까요??

A6.

개인적으로 자막을 추천한다. 실제 기업들도 자막을 많이 쓰는 것 같다.