[야놀자 X 패스트캠퍼스 프론트엔드 개발 1기] 멘토링

🚀개요

 야놀자X패스트캠퍼스 부트캠프에서는 현직에서 종사하시는 멘토님들과 주 1회씩 궁금한 것을 물어보는 시간을 가집니다. 평소에는 그룹 스터디 멘토님이, 개인 질문과 그룹 스터디 질문을 받아주셔 궁금증을 해결해 주십니다. 그리고 토이 프로젝트를 할 경우, 각 프로젝트 시에는 프로젝트 멘토님이 저희들의 질문을 받아주셔 다 같이 궁금한 내용을 해결합니다.

 

멘토님들마다 성향과 경험과 경력이 다 달라 소통과 설명이 달라질 수 있지만, 모든 멘토님들마다 최선을 다해 열정있게 가르쳐 주셨습니다. 

 

 보통 하다가 막힌 경우 에러의 원인에 대해서 묻기도 하였고, 멘토님의 현업 경험에 대해 묻기도 하였습니다. 또한 프로젝트 멘토님께는 프로젝트 질문을, 그룹 스터디 멘토님께는 그룹 스터디 방향에 대해 질문하기 편했습니다. 

 

저 같은 경우는 새로운 기술에 관심이 많아, SSR, CSR과 섞어 사용하는 방법, 현업에서의 기술 스택이나 최적화 등에 대해 많이 물어 본 것 같습니다.

 

👀어떤식으로 멘토링이 이뤄지나요?

평시에는 그룹 스터디 멘토님과, 프로젝트 시에는 프로젝트 멘토님과 함께 주 1회씩 멘토링이 이뤄집니다

 

📚 멘토링 진행 과정

1. 멘티들의 질문들을 사전 요청서에 작성 (멘토링 24시 전까지 작성)

2. 멘토님의 사전 요청서 질문 답변

3. 멘토링 시간에 질문에 대한 상세 설명과 추가 질문과 소통 시간

 

 아래는 토이 프로젝트 진행중에 만난 이XX 멘토님과 함께 만들어간 사전 요청서입니다. 

 

✨실제 멘토링 사전 요청서

멘토링 사전 요청서 (1주치 분량)
멘티들의 질문
멘토님의 답변

 

동료분들의 학습에 대한 열정과, 멘토님의 정성 담긴 답변이 만나 기존 정해진 멘토링 시간인 1시간을 훨씬 넘은 멘토링이었습니다. (구글 미트가 1시간 회의까지 무료로 제공되는데, 중간에 시간을 초과해서 새로 방을 파서 답변을 이어나가주셨습니다.. 사랑합니다 멘토님) 질문과 답변에 대한 자세한 내용은 아래에서 다루도록 하겠습니다.

 

 

🤔질문들에 대한 멘토님의 대답

기존에 진행한 멘토링을 기반으로 저를 포함한 멘티들의 질문과 멘토님의 대답에 관해 간략히 요약해 보여주고자 합니다. 저가 간력히 요약하여 설명 드리다 보니 멘토님의 의도와 다른 요약이 이뤄졌을 수도 있습니다!

 

1️⃣실무에서 SSG와 SPA(SSR, CSR), 또는 섞어 사용하는 방식 중 어떤 방식을 사용하는지?

- CSR, SSR, SSG 방식에 대해 잘 알 필요가 있다.

- SPA : 다른 페이지로 이동하지 않고 한 페이지에서 동작하는 것 처럼 느끼게 해준다

- SSG : HTML/CSS/JS 와 같은 정적인 웹 페이지

- CSR 의 단점 : SEO에 취약하고, 첫 로드에 모든 로직을 받아와 초기 로딩 속도가 오래 걸린다

- SSR : 서버측에서 렌더링, 사용자가 접근하면 html, view 등 리소스를 전달해줍니다

- SSR의 장점 : SEO 최적화에 유리, 초기 로딩 속도가 CSR에 비해 빠릅니다

- SSR의 단점 : 유저 경험이 좋지 않다. 유저가 요청했을 경우 페이지를 받아오므로 초기 로딩 속도는 빠를지라도 이동 속도가 느립니다

- SSG : 클라이언트에서 필요한 페이지를 미리 준비했다가, 요청 받으면 완성된 파일을 단순히 반환하여 브라우저에게 보여줍니다.

-SSR와 SSG의 차이 : 서버에서 요청할 때 즉시 만들기 vs 미리 만들어 놓은 페이지의 차이

 

정리

- CSR은 유저와 인터랙션이 많고, 고객정보를 다루는 프로덕트, 서비스 일 경우, 즉 백 오피스 프로젝트에 어울립니다

- SSR은 랜딩 페이지여서 검색 노출이 많이 돼야하고, 누군가에게나 같은 페이지를 보여줘야 하고, 데이터의 업데이트가 자주 일어나는 곳에 어울립니다

- SSG는 회사 홈페이지와 어울리는데, 업데이트가 자주 일어나지 않고, 누구에게나 똑같은 내용을 보여주고, 초기 진입속도가 빨라야 하는 곳에 어울립니다

- Next JS 프레임 워크를 이용해 3가지 방법을 적절히 섞어서 사용합니다

- 현업에서  프로젝트의 특성에 따라 사용하는 비율이 천차 만별입니다.

 

2️⃣ 라이브러리 설치 시 충돌을 --force 로 설치하는데, 안정성 측면에서 괜찮은지?

 

- 라이브러리의 버전 관리는 프로젝트 진행에 중요한 측면이며, 코드를 왔다갔다하면서 발생하는 에러를 줄이는 역할을 합니다.

- 프로젝트 초기에 라이브러리를 세팅할 때 해당 버전을 기록하는 것이 핵심입니다.

- 이를 위해 package.json을 활용하거나 다양한 방법을 사용할 수 있습니다.

- 라이브러리를 설치할 때 특정 버전을 지정하여 설치하는 것이 좋으며, 버전 충돌을 방지하기 위해 정기적으로 package.json을 확인하고 업데이트하는 것이 필요합니다.

- 라이브러리를 자동으로 업데이트하는 도구를 사용할 수 있습니다.

- `npm-check-updates` 라이브러리를 전역에서 설치하고 라이브러리를 사용하면 버젼을 업데이트 할 수 있습니다

- 하지만 버전 업데이트 시에는 충돌 가능성을 고려하여 신중하게 처리하는 것이 중요합니다.

 

3️⃣프로젝트는 어떻게 진행해야 하는지? 가이드라인이 혹시 존재하는지?

 

기획

• 아이디어 - 우리 서비스가 어떤 기능을 제공할 것인지 설명(홈화면이 될수도 있다)
  • 이번 토이에서는 아이템이 정해져 있으니 디자인 기획정도로 볼 수 있을 듯
• 팀 규칙 정하기
  • 게더타운/토이 회의실 같은데서 9-6 접속해 있기, 점심 가는 것 공유하기
  • 의견 대립할 때 어떻게
  • github 사용 규칙 (선택)
• 기능 등 개발적 해야하는 것들 체크리스트
  • 필수 구현기능 등을 구체적으로
    • 캘린더는 어떤 라이브러리 사용해서 만든다거나,
    • 로그인 구현시 JWT 라이브러리 사용하기
    • 이런 식으로 필수구현 + 팀에서 정한 기술스택 등 여러 기획을 엮어서.
• 개발 기능 구분하기
  • 필수 구현(기능단위로) - bare minimum > 일부 인원에 몰리지X, 팀원들이 각각 나눠서 ,각자 맡은 페이지나 기능 → 우선순위
    • 페이지 단위 로 1차 나누고 더 세분화한다면 > 기능 단위로도 가능할 듯
    • 파일이 겹치지 않는 수준으로 나누어보기 (충돌 방지)
    • (현업에서도 일감을 나누는 게 꽤 고민이다!)
  • 중간 정도 어려운 기능인데 목표해볼 만한 거 - middle advanced
  • 이건 정말 어려운 기능 (가능성 낮지만 정말 위에까지 다했다면 도전)
• 기술 스택 정하기
• 디렉토리 구조도 서로 보고들은 거 공유해서 공통적인 구조 뽑기
• (디자인) User flow / prototype → 디자인하기 *피그마 같은 툴로 간단하게라도. 보고 개발할 것이 필요하니까. (늦어도 수요일 안까지)
  • 와이어프레임 수준, 어떤 컬러톤/ 무료 이미지 소스 을 다 같이 기획
  • 디자인에 관심있는 팀원이 1~2명이 피그마로 빠르게 기획 + 같이 리뷰 + 수정할 게 있으면 빨리 수정 (많은 페이지 X 2주 프로젝트니 필요한 페이지만 퀄리티 있게)

ㄴ 여기까지는 필수

• 필요하다면 DB 스키마 짜기 (2주 FE프로젝트에서는 생략)
• API 문서 (2주 FE프로젝트에서는 생략해도.)
• Final App screen 정리 (최종 만든 화면 캡처/gif 및 설명으로 서비스 소개 페이지 작성)
• 팀원들이 각자 뭐했는지 담당한 거 정리 * 내가 뭘했는지 설명할 수 있는 것 중요 - 이력서에 넣는다면..
  • 로그인 기능 ← 이런건 한사람이 하는게 맞는 단위.

중요

• 데일리 스크럼 (매일 1시간씩 회의하면서 분업 / 하고 있는 작업상황 공유 및 문제 없는지. 조율할 일 이 있는지)
• 이 모든걸 github wiki로 정리하기
• (개인) 트러블슈팅 / 에러로그(개발말고도 프로젝트하면서.) 블로깅하면 좋을 듯

 

🎈마치며

 멘토링을 토대로 막힌 문제의 실마리를 얻을 수도, 내가 관심 있는 기술들에 대해 인사이트를 얻을 수도 있습니다. 또한 프로젝트나 그룹 스터디의 방향성에 대해서도 도움을 많이 받았고, 특히 협업을 처음하는데 협업에 대한 가이드 툴을 잡아주셔서 되게 감사했습니다. 

 

멘토님의 가이드 툴로 'FASTWIKI' 프로젝트에서 코어타임(오후2 ~ 7시까지 같이 개발하며, 편하게 이야기를 나눌 수 있는 시간)을 정해서 팀원들과의 협업을 원활히 할 수 있었습니다.