1주차 팀 멘토링 ‐ 11.02

논의 사항 및 질문

기획/ 설계

• 요구사항 실현가능성

  백로그표를 작성해두었습니다.

  멘토님이 보시기엔 5주내(실질적으론 4주내)에 구현할 수 있을 것 같은지 조언을 듣고 싶습니다.

• 요구사항 우선순위

  시간상 기능 우선순위는 아래와 같이 산정하였습니다.

  블록 조립 → 블록 변환 → 초기사용자 고려한 툴팁

  워크스페이스에 선생님이 함께 접속해 같이 블록코딩 진행하기기능인 동시편집도 구현하고 싶지만, 시간상 불가능할 것 같다고 판단하였습니다.

  멘토님께서 보시기에 어떤 작업이 우선되어야 한다고 생각하시는지 궁금합니다.

• 업무 분담 조언

  • 저희도 이제 백로그표를 바탕으로 맡을 파트를 정해야하다보니, 현업에서 업무 분담하는 방식은 어떤 방식인지 궁금합니다.
  • 그리고 네부캠에서는 계속 분업이 아닌 협업 을 강조하시는데, 어떻게 해야 적절하게 맡을 파트로 나누되 협업 성격을 챙겨나갈 수 있을지 멘토님의 조언을 듣고 싶습니다.

기술 스택

• 선택한 기술 스택이 서비스에 적합한지

  기술 스택

  • 저희 팀 기술 스택입니다. 해당 페이지에 다른 기술들의 장단점과 선택한 기술의 이유를 작성해두었습니다.
  • 멘토님이 보시기에 기술 선택 이유가 적절한지, 서비스에 적합해 보이시는지 궁금합니다.

• pnpm 현업에서의 사용성 및 프로젝트 적합 여부

  • pnpm이 이 사이트에서 S티어인데, 왜 S티어인지 궁금했습니다.

    pnpm에 대해 찾아본 결과 pnpm의 경우에는 프로젝트별로 node_modules에 매번 패키지를 설치했던 것과는 달리 global 저장소에 패키지를 한 번만 저장함으로써 저장 공간을 절약할 수 있다는 아주 큰 장점을 가지고 있다. pnpm을 사용한다면 똑같은 라이브러리를 중복해서 설치할 필요가 없다는 의미다. 이 점이 큰 장점으로 다가오는 패키지 매니저라고 생각했습니다. 다만 이 장점이 개발환경에서는 글로벌 저장소에 저장하다보니 거부감이 있다고 생각했습니다.

    하지만 배포를 pnpm으로 하면 좋을 듯.. 하면서도 회사같은 큰 배포 규모에만 좋은 패키지매니저인지, 저희 팀 프로젝트 같은 작은 단위의 프로젝트에서는 다른 패키지매니저와 비교해 큰 장점이 있는지 잘 모르겠더라고요.

    그래서 현업에서는 pnpm 패키지 매니저를 잘 사용하는지, 그리고 저희 프로젝트에서는 사용해볼만한지 멘토님 의견을 여쭙고 싶습니다.

    +멘토님께서 현업에서 다루셨던 기술스택들도 궁금합니다!

구현 과정

• 블록을 조작할 때 서버에 실시간으로 저장하는 게 맞을지

  http 요청으로 블록을 조작할 때마다 저장하면 서버에 부하가 클 수 있을 것 같은데 socket.io를 써서 실시간으로 처리하는 게 더 좋을지 여쭙고 싶습니다.

진행상황 및 참고 자료

1. 팀빌딩

• 그라운드 룰: [링크]
• git 전략: [링크]

2. 아이디어 선정

• 서비스명: BooLock
• 서비스 목표: 코딩 입문자들이 HTML과 CSS 개념을 블록 코딩으로 쉽게 배우기
• 서비스 핵심 기능:

  1. 제공되는 학습 콘텐츠를 이용해 HTML, CSS 개념을 블록을 이용해서 학습하기

  2. 워크스페이스에서 블록 코딩으로 자유롭게 웹사이트 만들기

  3. 워크스페이스에 선생님이 함께 접속해 같이 블록코딩 진행하기

     👉 현재 3번 기능(동시 편집)은 개발 양이 많아 우선 제외하고 진행하려 합니다. 다만, 다른 기능들을 빠르게 구현한 후 남은 그룹 프로젝트 기간 동안 가능하다면 3번 기능도 진행하고 싶습니다.

3. 기술 스택

기술 스택 선택 이유

4. FE 컨벤션: [링크]

5. 백로그: [링크]

6. 디자인(진행 중)

1. 디자인 가이드: [링크]
2. 와이어프레임: [링크]
3. 프로토타입: [링크]

✔️ 멘토링 내용

서기: 홍현지

요구사항 실행 가능성

• 스토리 하나하나가 볼륨이 큰 편 같다.
  • 예를 들어 슬라이드 형식 하나 만들어도, UI제작, api 제작, 라이브러리 학습, pr리뷰 받는 것 등등 여러 사항을 고려하면 이틀정도 걸릴 수도 있음

⇒ 백로그 모든 걸 다 하기는 좀 어려워 보임

→ 기획을 아예 빼기보다는 우선순위를 확실하게 두기

• 예를 들어 프리뷰탭이라면 리사이징같은 건 우선순위를 크게 두지 않아도 되는 기능이라고 생각. (상/중/하) 우선순위를 확실하게 정해서 상인 기능들만 먼저 구현해보기

• 필요해보이는 부분

  • 3, 4, 5 에픽 및 6-3 스토리가 가장 큰 우선순위로 보임

• 확대, 축소 버튼, 상하좌우 스크롤 같은 건 우선순위를 낮추길..

• 학습 컨텐츠 이용 부분

  • 학습 컨텐츠 이용이 사용자 입장에선 좋음. but, 개발자 입장에선 학습컨텐츠 이용을 개발하여 얻을 수 있는 이득이 있는지 모르겠음

  • 차라리 학습 컨텐츠 이용 부분을 빼고, 동시편집을 해보는 게 기술적으로 얻을 수 있는 이득이 많지 않나?

  • 사용자도 중요하지만, 개발자 입장에서 학습컨텐츠 이용이 굉장히 큰 컨텐츠로 보이는데 이게 정말 필요한 기능인지 생각해보기

    • 차라리 영상을 찍어서 뿌려보는 대안을 생각해보는 것도 추천

  • 학습컨텐츠를 넣는 이유

    • 질문 : 공통적으로 3순위 우선순위로 나온 게 사용자 위주의 완성도 높이기 여서 학습컨텐츠를 넣은건데, 멘토님은 개발자 입장을 먼저 고려하는 게 좋다고 생각하시는지?

      • 사용자 입장보다는 프로젝트 개발자가 기술적으로 얻어가는 것, 스토리텔링을 만들 수 있는 것, 취업에 유리한 것을 고려해보는 것이 더 중요하다고 생각. 그래서 학습컨텐츠 이용이 그렇게 메리트가 잇어보이진 않음

      • 사용자 중심 중요하긴한데, 그걸 감안해도 학습컨텐츠이용 테스크가 너무 크다.

      • 영상이라는 대체제가 있으니 사용해보는 건 어떤지?

• 엔트리 블록과 기능이 엄청 많은데, 어느정도의 블록이 있고, 어느정도의 프로그램을 만들 수 있나?

  • 간단한 웹사이트를 엔트리로 한 번 만들어보고, 거기에 필요한 기능들을 간단하게 추려서 아이디에이션 해보길 추천

  • 확실하게 어떤 작품을 만들 수 있는지 방향성을 잡아서, 그것에 필요한 위주의 기능들을 만들어야 사용자에게 설득력을 주길 바람

• 질문: html, css만 고려하고, js는 크게 고려를 안하고 있는데 css는 정적인 ui만 만들 수 있는 범위만 생각함. 미디어관련 태그도 후순위로 고려를 함. 태그들을 굉장히 단순하게 범위를 줄여서 기능이 어렵지 않을 것이라고 생각했어서 엔트리를 먼저 써보라는 멘토님 의견을 이해하지 못하겠음.

  • 간단한 웹사이트를 만든다 했을 때, 어떤 웹사이트를 만드는 것인지?

    • 웹사이트지만, 동작이 안되고 ui정도만 제작할 수 있는 정도만 생각했음

  • 굳이 엔트리가 아니여도, 이 기능을 내가 다 만들었을 때, 최종본이 머릿속에 그려지나요?

    • 아무 웹사이트 레이아웃을 비슷하게 따라 만들 수 있는 정도?

  • 웹사이트 제작도구로 보면 될까요?

    • ui만 만드는 측면에선 비슷한 것 같다.

    • js가 아예 없고, html, css로만 하면 웹사이트라는 것에 맞나? 그래서 js도 온클릭같은 이벤트를 넣을까 하다가 볼륨이 너무 커질까봐 나중에 하자라고 의견이 나왔다.

  • 완전히 정적인 웹사이트이고, 그 안에서 인터렉션은 없는, api도 없는 상태라고 이해 → 이 프로젝트의 최종본에 대한 설명이 없어, 최종본 없이 추상적으로 가고 있나 싶어서 걱정이 되었음. 하지만 최종본이 어느정도 잡혀있는 것 같으니 괜찮은 것 같다.

  • +) 처음에 그렇게 간소하게 가는 것도 찬성/우선 만들고 그 다음에 붙이자 !

• 최적화에 초점을 맞추셔야한다.

  • 멘토님이 봤을 땐 사용자에게 편한 기능들이긴한데 주요한 기능들은 아니라고 생각. 기능이 좀 많다.

• 질문: 방금 얘기한 최적화가 프론트/백 둘 다 말씀하시는 게 맞으신가요?

  • 답: 백엔드는 최적화에 관해 조언해주기 어려운 것 같음

  • 이슈가 생기면 좋아해야한다. (최적화 거리가 생겼다..!)

  • 프론트는 프리뷰형식의 렌더링 이슈가 하나 생길 가능성이 있음

    • https://www.joshwcomeau.com/react/use-deferred-value/

  • 기능들을 좀 간소화하게 두고, 최적화하며 좀 딥하게 들어가길 추천

  • 최적화할 게 모르겠다 싶으면 이전 기수들의 개선건중에서 찾아보거나 멘토링할 때 물어봐랍

    • 가장 최고는 문제를 발견하고 해결하는 것..!

업무분담 조언

• 현업에서 테스크를 우리처럼 만들어둔다. → 해당 테스크에서 원하는 사람이 가져감 / 원하는 사람이 여러명이면 서로 얘기해서 합의 봄 / 회사이다보니 테스크가 마감일자가 촉박하면 시니어한테 줌(잘하는 사람한테 줌) → 두가지를 고려해서 담당자를 정하자

  • 너무 하고 싶으면 해라..! 하지만.. 마감이 촉박해지면 잘하는 사람한테..

• 협업이 중요하긴 함. 이 프로젝트를 만드는 모든 과정이 협업이라고 생각함.

  • 사실 기능 하나를 맡아도 결국 나중에는 합쳐야해서 그 과정에서 협업이 이루어지게 됨

  • 파트를 나누어도 협업이 아니다 는 아닌 것 같음

• 추가 질문: 태스크 단위로 쪼개서 하나의 스토리를 여러 명이 하는 것보다 한 명이 하나의 스토리를 담당하는 게 효율적이지 않나?

  • 2-1 하나같은 경우엔 api하나 만들기, 슬라이드 하나 만들기 두개로 나누어질 것 같은데, 솔직히 한명이 그냥 다 맡는 게 나을 것 같음

    • 하나의 스토리는 한명이 진행하는 게 효율적이긴 함.

    • 하나의 테스크(스토리) = 1명 권장

    • 코드 리뷰 하면서 서로의 파트를 이해할 수 있다.

• 일정관리 감을 잡을 때 스토리 포인트(테스크를 수행할 때 얼마나 시간이 걸릴지 이야기 하는 것 1sp → 하루동안 할 수 있는 양 - 회사라 8시간 (sp는 테스크하고 pr올리고 머지까지의 시간을 기준으로 해야함))

  • 개인이 입력할 순 있음 → 하지만 객관성을 유지할 거면 [플래닝포커](https://swiperjs.com/) 해보기

    • 하지만 플래닝포커는 시간이 오래 걸리니 적절하게 적용해보기

기술스택

• docker 공부하고 싶은 사람이 없으면 빼도 되겠다

• 백엔드쪽 다 좋다.

• react도 seo를 대응할 수 있음 private하긴 하지만 메인페이지가 하나 있어야하기 때문에 seo가 필요하긴 함. 쇼핑몰같은 seo가 필요 없는 것..

• 위 제외하면 리액트 선택 이유 괜찮다.

• ts, vite, zustand, tanstack-query 사용 굿

  • tanstack-query가 socket도 호환해줌, react와의 호환도 아주 좋음

    • 멘토님팀은 zustand와 tanstack-query를 이미 쓰기 때문에, context api를 지양하긴 함.

      • context까지 하면 상태관리 cost가 너무 크다고 판단

  • css모듈이나 scss를 고려하지 않은 이유가 있나요? → 고려를 안했다기 보다는 서로 사용해보고 싶은 css라이브러리 종류가 tailwind, styled-component로 나왔어서 장단점 조사를 안해봤던 것

    • 멘토님팀은 css module을 사용함. 의외로 cssmodule, scss 쓰는 사람이 많음

    • 테일윈드는 디자인시스템이 잘 구축되어있을 때 큰 힘을 발휘한다고 생각.

      • 애니메이션 쪽이 조금 까다로움

      • 이런 부분들이 같이 고려가 되었는지? 생각해보길

      • 애니메이션은 프로젝트에 많이 들어갈지를 생각 못해봐서 고려를 못했음 + 디자인 시스템은 간격 제외하고는 잘 만들어짐 (갓유진………………. 그저 빛)

• 기술스택 전반적으로 딥하게 고민한 것 같아서 잘 결정한 것 같다.

• 질문: css module쓰면 이름 짓는 거 시간이 오래 걸리진 않나..?

  • 답: cssmodule도 해시화를 해줘서 시간이 오래 걸리지 않음 (css 모듈 장점임)

• pnpm

  • 멘토님팀도 pnpm씀

  • 멘토님팀은 모노레포 환경임

  • 빠른속도와 ghost dependency 없애자 관점에서 pnpm을 사용했었음

  • 회사같은 큰 배포 규모에만 좋은 패키지 매니저인 건 아님

  • yarn berry, pnpm 둘 중 무얼 선택해도 좋음

    • 장단점이 뚜렷하게 있진 않음..

  • pnpm이랑 yarn berry 비교해보고 선택해보기

• postcss, cssmodule, vite, react, zustand, tanstack-query, sentry, axios, i18next, react-helmet, storybook+msw, swiper 사용

  • postcss 설명 부분? 아 까먹었다. 뭐랑 호환돼서.. → 나중에 들으신분 추가좀

  • sentry: 웹사이트의 에러를 왓칭함. sentry 에러 중 에러율이 높은 걸 보고 미리 방지하는 모니터링 시스템… 적어도 마감 일주일 전에는 배포를 해야 의미가 있음

  • react-helmet: spa에서 메타태그를 지원해줌. seo가 프로덕션 입장에선 중요하기에

  • storybook+msw 같이 사용: 컴포넌트 테스트 편의성, 백엔드 api 안나오고 프론트끼리 작업할 때도 유용하게 사용

  • swiper: 캐러셀만들어야할 때..

구현과정

• 엔트리는 블록하나하나 둘 때 소켓열어두고 보내는 것 같음 → 로컬에 저장되어있지 않으니 db에 저장해두는 것 같음

• 자동저장기능을 제공할 것인가? 아닌가를 명확하게 해야할 듯

추가질문?

• blockly를 이용해서 구현할 것 같은데 멘토님이 생각하시기에 저희가 라이브러리를 잘 사용해서 빨리 구현이 되었다고 할 때, 동시편집을 먼저 하는 게 좋을지, 라이브러리를 만들어보는 게 좋을지?

  • 기획자 입장: 동시편집 기술 우선

  • 공부하는 입장: 라이브러리 우선

  • 멘토님 기준: 동시편집이 기술 시도를 해보는 게 좋기는 한데, 그렇게 어려운 기술도 아니고 누구나 해볼 수 있는 기술임 (구글링해보면 다 나옴) → 동시편집에 비해 라이브러리를 만든다는 것은 깊이 파고드는 것도 중요하고, 블록리는 굉장히 잘 만든 라이브러리이고 개발자 편의성이 들어간 라이브러리이기 때문에 그런 걸 잘 고려하면서 라이브러리를 만들어보는 것이 스토리텔링이 되고 좋을 것 같음

  • 조금 우려스러운 부분이 이 프로젝트가 블록리 라이브러리에 너무 의존성이 강해서, 이 라이브러리만 공부하다가 끝나면 어떻게 되지? 라는 생각이 듦

    • 리액트라이브러리를 잘 쓰면 사람들이 잘 알아주지만, 블록리는 대중성이 너무 없음

  → 시간이 남으면 차라리 라이브러리를 분석해서 만들어보는 게 더 차별점이 될 것임

• 멘토님: 브랜치를 나눈다는 것은 버전관리가 필요한 경우라고 생각.

• 풀스택으로 작업한다고 하면 fe/be 브랜치를 나눠서 하면 불편할까요?

  • 네.. pr하나는 한브랜치에만 넣을 수 있고, pr하나에 한 기능을 다 넣으면 be/fe 분리를 해서 올리기 힘들지 않을까?

• 100명정도 모아서 운영하는 경험을 가지면 좋다고 생각한다고 들었는데, 우리 프로젝트는 모으기가 어려워서.. 그걸 생각하지 못하고 있는데, 그런 운영 경험이 필수적으로 중요한지?

  • 백엔드 입장에선 운영하는 경험이 중요함.

  • 프론트엔드 입장에서도 중요한 것 같음

    • 발견하지 못한 버그들을 발견할 수 있음 → 보통 크로스브라우징에서 발생함. (멘토님은 엣지를 싫어한다..)

    • 버그를 발견하고 개선해나가는 과정이 중요한 경험인 것 같음

      • 그걸 경험하고 싶으면 4주차 끝날 때 쯤에 먼저 선보여야… 사람들 다 들어가서 해보고.. 버그 왕창 나오고.. 선출시를 먼저 해봐야 이목을 끈다……

회의 후 결정 사항

1. 학습 컨텐츠 제외 → 동영상으로 대체

2. 브런치 FE / BE 통합 → dev 만 사용

3. 수동 저장 → 동시 편집을 하면 자동 저장

4. 만들 수 있는 최종 레이아웃을 같이 구상해보자

   정적인 레이아웃

5. 동시 편집 vs 라이브러리 (일부만?) → 나중에 결정

6. docker → 하고 싶은 사람 있어서 안 뺌

7. storybook + msw → 다음 주에 결정

   • jest를 안 쓸거면 storybook 써보는건 어떤지

8. yarn berry vs pnpm → 조사해오고 결정

   • yarn berry 모노레포에서 이슈가 많았음

9. 멘토님이 말씀하신 라이브러리 중 추가로 사용해보고 싶은 게 있다면 공부해오기