1주차 멘토링 일지

✔️ 1주차: 기획/설계 내용과 분량, 난이도가 적절한지

✔️ 결론 및 To Do

멘토링 이후 결론과 챙길 것을 정리하여 업데이트합니다.

✔️ 멘토링 아젠다

멘토링 24시간 전에 준비하여 멘토에게 공유합니다.

논의 사항 및 질문

멘토의 조언이 필요한 부분을 질문으로 정리합니다.

• 2주차 화면⋅음성 구현, 3주차까지 MVP 구현을 상정하고 계획을 세웠는데 분량이 적절할까요?
• 현실성 있는 계획일까요..?
• 완성도 기준

진행상황 및 참고 자료

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

• 프로젝트명 GOMZ (= 공부 + zoom. )

• 아이디어 캠을 켜고 다른 사람들과 함께 공부하는 시간을 기록할 수 있는 온라인 학습 플랫폼

• 기능

  베이스

  • 화면 공유
  • 음성 대화
  • 채팅
  • 공개방/비밀방
    • 공개방: 전체 공부방 리스트
    • 비밀방: 비밀번호 혹은 링크로 참여할 수 있는 방
  • 누적 공부 시간 타이머

  추가적인 기능

  • 날짜 별 순공 시간 통계 + 과목 태그

  • 과목별 타이머

  • 공부방 카테고리 분류

  • 메시지? DM?

  • 저화질 화면 공유

  • 로그인

  • 아바타 - Three.js, Babylon.js + mediapipe

  • 투두리스트 → 공개/비공개 설정 ex. progress만 보여주는 방식 + 캘린더

  • 누적 공부 시간 랭킹

    • 사용자 닉네임 설정
    • 일별, 주간별, 월별

  • 뽀모도로 타이머

  • 숨김방

• 기능 요구사항 정의: 프로젝트 상세 기획 - 기능 요구사항 정의

• 서비스 핵심 기능의 완성도 기준

  • 웹 접근성
  • 반응형 브라우저
  • 버퍼링이 없는 화면 공유
  • 비회원이더라도 웹 페이지를 떠나기 전까지 공부시간 누적
  • 공부방 참여/퇴장 시에도 참여인원이 집중할 수 있는 환경
    • ex. 참여/퇴장 시 화면이 깜빡거리는 현상 개선
  • url 조작만으로 비밀방에 접근할 수 없도록
  • 공부방/참여 인원이 많은 경우의 트래픽 관리
  • 에러 발생시 서버 가용성 처리
  • 테스트 커버리지

✔️ 멘토링 내용

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

전반적인 멘토링 피드백

1. 스펙이 많은 것 같다.

   • 합을 안 맞춰본 5명이, 6주안에 구현하기에 양이 많음

2. 웹 접근성을 통해 무엇을 달성하려는 것인지 잘 모르겠음.

   현재 프로젝트에서 중요도가 높지 않은 것 같음.

3. 3주차 MVP 완성 → 할 수는 있겠지만 난장판으로 될 것 같다.

   • 공부까지 잘 챙겨가면서 못할 것 같아 좋은 것인지 모르겠음
   • 스펙이 너무 많아서 그런 것 같음

4. 문서화를 더 잘 할 수 있을 것 같음

   • 결정⋅생각의 과정이 잘 느껴지지 않음
   • 일할 때 도움이 되거나 참고할 수 있을지 잘 모르겠음
     • 너무 결과만 적혀있음
     • 어떤 고민을 했는지, 왜 들어가야 하는지 알 수 없음

5. MVP

   • 이 기능이 없으면 프로젝트가 전혀 구현되지 않는 기능만
   • 화면 켜고, 음성 대화, 시간 기록 정도?
   • 변화에 유연한 구조를 생각하며 하는 것은 좋음 → 실현이 될지는 모르겠지만..

6. 투두리스트

   • 이것 자체만으로도 앱 하나 같아 좀 크다

7. 분량이 적절한가요? 현실적인 계획일까요? → 아닌 것 같다..

완성도의 기준?

• 많이 배우고 물어봤을 때 잘 대답할 수 있어야 함
• 현재 작성한 완성도의 기준을 채운다고 완성도가 높아질 것 같지는 않음
  • 그냥 신경써야할 부분인 것 같고 이것이 되지 않는다고 완성도가 낮아지는가..?
  • 완성도라기보다 개인적인 목표가 섞여있는 느낌
  • 이것 하겠다보다 왜 하려는지, 해서 어떤 것을 이루려는지(수단) 등을 작성하면 좋을듯
  • 적혀진 완성도가 너무 구체적인 것 같아 더 헷갈리는듯
  • 테스트 커버리지 → 높여서 어떤 것을 개선하려는 것인지?

구현 목표보다 큰 범위의 목표가 있으면 좋을 것 같다.

이 프로젝트를 통해 무엇을 하고, 무엇을 배우려는 것인지 잘 모르겠음

백로그 예상 시간 채워보고 실제로 6주 시간으로 계산해봤을 때 어디까지 구현할 수 있을지 확인하기

생각보다 오래 걸릴 수 있기 때문에..

🗯️ 추가 질문

1. 기획을 할 때 어디까지 세세하게 해야할 지 모르겠어요

   기능을 구현하기 위한 코드들도 기획 단계에서 설계하고 가야 하는 것일까요? → 불가능

   (대체로) 틀을 잡아놓는 것만으로도 충분

   내가 감당할 수 있는 규모로 만들고 하는 것이 중요함

   압박이 느껴지거나 헷갈린다면 잠시 물러서서 생각해보는 것이 도움이 됨

   한/하지 않은 이유를 아는 게 가장 중요

2. 스펙 작게 잡아보고 기능들은 다시 한 번 생각해보기 → 하고 싶은 기능이 무엇인지

   우선순위를 리오더링 하는 것이 중요

   기획 측면/기술 측면 계획을 분리해보는 것도 좋은 방법

   망가져도 좋으니까 일단 해보자

3. 기술 스택 선택 이유가 세세한 편이신가요?

   엄청 중요하게 해야함

   왜 선택했는지, 다른 대안에는 무엇이 있는지

   “이 스택은 어떤 문제를 해결할 것 같은데 내 프로젝트는 이런 문제를 겪을 것 같으니 이 스택을 선택했다”

   ex. 리액트

   진짜 작은 프로젝트에서 상태 관리 라이브러리를 사용하지 않은 이유

   어떤 스택이/라이브러리가 좋고 안 좋고의 단순한 비교는 ❌

4. vue, angular를 사용하지 않은 이유를 잡고 가는 것이 좋을까요?

   vue 구조는 이렇고요 저렇고요는 X

   러닝 커브가 있고 내가 가진 시간은 이정도라서 사용해본 리액트를 골랐어 (의외로)O

   → 6주 간의 정말 짧은 기간에 구현해야 하는 프로젝트이기 때문에 러닝 커브가 주요 이유가 될 수 있음

5. 계획을 실현할 시간이 부족할 것 같다고 피드백 해주셨는데, 저번 미팅 때 해주신 말씀처럼 빠른 배포 후 고쳐가는 학습을 해보려고 했습니다. 그런데 빠른 배포의 경우 학습을 진득하게 할 수는 없을 것 같은데 어떤 방식으로 하는 것이 좋을까요?

   라이브러리 가져다 쓰면 2~3주 안에 구현이 가능하겠지만..

   공부하면서 배울 때와 빨리 배포해 고쳐가며 배울 수 있는 영역이 다른 것 같음.

   어떤 것이 부족하고 무엇을 배우고 싶은지에 따라 선택이 달라질듯

   프로젝트를 실무처럼 돌려보며 겪는 어려움을 마주해보고싶음 → 빠른 배포

   천천히 배워가며 도메인을 진득하게 학습하고 싶다 → 공부 집중

   빠른 배포 후 고치며 학습하는 것은 좋은 방식이지만 난이도가 매우 어려움

   큰 철학없이 “빠른 배포”에만 집중한다면 학습의 깊이가 낮을 것이고, 주니어에게는 깊은 지식을 원하는 편

6. Three.js 굿바이 👋

   무엇을 써보겠다가 중요한 것이 아니고 무엇을 해보겠다가 중요한 것이다.

7. 기술적인 도전을 위해서 주제에 관계없는 라이브러리를 쓰는 건 조금 아닌 거 같다.

8. 추가 기능은 핵심적인 기능에서 조금 더 파보는 것이 좋을 것 같다.

9. 우리 프로젝트에서 정말 핵심으로 들어가면 “줌”인데, 그렇다면 서비스적인 기획보다 “줌”, “화상회의”에 집중하는 것이 좋을까요?

   아닙니다. 프로젝트의 깊이를 깊게 만들기 위해서는

   이런게 있으면 좋을 것 같다 → 필요한 기술을 학습하고 찾아보는 것 O

   기술을 찾고 → 기능을 만드는 것 X

10. MVP만 뽑아서 클론 코딩하는 방향으로 나아가는 것이 깊이를 깊게 만들 수 있을까요?

    아닙니다.

    깊이라고 하는 것이 depth보다는 프로젝트에 얼마가 깊게 생각했느냐의 여부입니다.

    “이어지는 생각”이 중요

    기술기반 생각보다 내 프로젝트의 핵심 기능은 무엇인지 생각해보고 몰입하는 것..!

    주제인 공부에 도움되는 기술이 뭐가 있는지 고민을 해보자

    타이머로 어떤 가치를 제공할 수 있고, 어떤 것을 주겠느냐에 따라 스펙이 다양해질 수 있고 깊이가 깊어질 수 있다고 생각함 → 예상되는 문제나 새로운 아이디어들이 떠오르면 → 기술적으로 도전적인 주제가 나온다

    지금 적혀있는 기능들은 한 번 봤을 때 대충 어떻게 구현할지 감이 오는 것이 대부분 → 깊이가 얕다

기본기가 부족하고 도메인에 대한 학습을 해보고 싶다면 너무 새로운 기술에 도전하지 않는 것이 좋다.

>> 내가 6주동안 이 프로젝트로 무엇을 하고 싶은지 <<

“내가 무언가를 했다” 정도로는 큰 의미가 없는 세상이 되어버렷음 😢 → 깊이를 잘 가져가야함

할 말(고민)이 없다고 생각이 들면 반성해야함.

✔️ 체크리스트

1주차 멘토링에서 이야기 나누면 좋을 주제입니다. 우리 팀의 상황은 어떤가요? 팀원 및 멘토와 함께 셀프 체크하고, 그 이유를 작성해보세요. 추가하고 싶은 항목이 있다면 직접 추가해도 좋습니다.

• 프로젝트 기획과 설계의 뼈대가 나왔다.
• 프로덕트 backlog가 제작되었다.
• 서비스 핵심 기능에 대한 완성도의 기준 또는 기술적 목표가 수립되었다.
• 현실성 있는 계획이 수립되었다.