📝 [2024-11-14] 3주차 배포를 위한 회의

📝 회의 목표

• 통합을 위한 회의

📝 회의 안건

총 회의시간 : 2시간

• 통합때 사용자 시나리오 고려해서 합쳐야함.

  • 통합관련해서 어떻게 할지도 이야기 → 20분

• 프론트앤드 통신 시나리오 (상태 시나리오) → 20분

  • ~~React Router 에 데이터 담을 수 있어서.. 이걸 변수로 받아올 수 있음. 페이지간에.~~
  • 데이터 플로우
  • 더미데이터 넣기
  • API로 어느 페이지에서 통신해서 받아올 건지 → 10분

• 통신 모듈 → API로 만듦 → AXIOS → 5분

  • 제가 할게요
  • utils에 뺼게요.

DIM = 5

MODAL = 100

TOAST = 500

• z-index :: 이야기 → 10분

• 액션관련해서 불편한거 → 10분

• 문서 정리 관련해서도 이야기한번 해봐야함 → 10분정도

  • 내가 이 프로젝트에서 무엇을 보여주고 싶은지 드러나도록

• 발표자료 + 멘토님 :: 문서 공통으로 작성 → 1시간정도로 빨리 끝냅시다. → 1시간(문서작성이라)

📝 회의가 끝났을 때의 상태

• 회의가 끝났을 때 우리는 통합관련해서 생각이 일치하고, 바로 통합 작업에 들어간다.

📝 회의 내용

🏃 사용자 시나리오

💾 Backend

로그인 :: 로그인 화면에서 API

• 최소한은 해야할 거 같아서 토큰은 추가해두었다.
• 토큰을 저장해야한다.

홈아이디 :: userId 파라미터로 보내면 채널 ID, 채널 이름이 리스트 형태로 나오게 된다. 배열이 반복문을 통해서 나오게 된다.

• 수정, 삭제는 아직 API 없다.

경로 추가 화면 :: 경로 설정 등 모든걸 다 폼에서 갖고 있고 폼에서 반환하도록 구현

손녀 기준 화면 :: 채널에 대한 ID, 유저 ID를 갖고 있으면 이걸 다 가져오는 형태로 해서 프론트에서 다 뿌려주면 된다.

• 어떻게 최적화? ⇒ 일단 구현해보고 생각

🏃 z-index :: 이야기 → 10분

• 확실히 잡고 넘어가야함

• 혜인님…

• Toss

  • 1000번 단위로 나눔
  • 0번은 그냥 메인화면
  • 9000번 같은 경우는 alert → 모달 같은것도

• 메인화면이 0번대, 레이아웃 1000번대, ,캔버스가 4000번, 그 위에 올라오는것들이 6000번~~

  • 맞아요. Absolute 써야하는 순간에만…
  • 레이아웃

• Layout 헤더 높이 어떻게 할지는 ⇒ @Zen 테스트도 해서 알려드림

🤔 Action 관련 불편한거

• 수정 요청 → 깃허브 액션에서 확인 라벨 붙임
• CI에서 테스트… 이거 어케 좀 조건부로 해볼 방법 없나… ⇒ 메일이 계속옴…
• Reviewer도 조건부로 안붙는거 무조건 2명 붙음…
  • 수정하고 확인요청하면 다시 붙음
• 자동머지 안되는거 개불편
• 머지완료 되고 나서 작업완료 바꾸니까 확인요청되고 다시 리뷰요청이 옴…
• 제목에 # 없으면 머지 안되고, 그 PR 명 확인 작업 (옵션)
• 프로젝트 안붙이면 머지 안되게

팀별로 분명히 하다가 공부하거나, 스터디하거나, 트러블슈팅 한 내용이 있을거다. → 개인블로그에 올리는 것들…?

이거를 팀 단위의 성장 스토리랑 / 팀원 단위의 성장 스토리로 풀어서 올려도 될거같다.

→ “우리가 6주가 지났을때 어떤 상태가 될 것인가?” ⇒ “6주 이후에 같이 여행가서 술먹고 놀 팀원이 되었으면 좋겠어요.”

⇒ 뭐가 됐든 좋으니까, 팀 소개나 이런데에 이런식의 목표를 적어두고, 기록으로 직접 보여줘라. 그래서 그게 만약 기술이면 기술적인 내용을 정리하는 공간에 잘 정리했으면 좋곘다.

(적어도 모아보더라도..)

• 팀적을 녹아나는지, 내가 어떻게 해야 팀에게 폐가 안될지.. (이미 많이 되었지만..), 이러이러한 성격인데… 좀 더 팀원들과 잘 녹아나고 싶다. 어떻게 해야하는가?

  • 성장적으로도 저 스스로는 엄청 잘 챙겨가고있는데.. 솔직히 좀 이기적이다. 너무 내가 원하는바를 팀에게 강력하게 주장을해서.. 그런 부분이 좀 걸린다.
  • 준일님도 공감.. 재도님 의견이 좀 쎄시네요..
  • 우리팀은 엄청바쁜데도 이렇게 성장을 하고 있어요. 그리고 적어도 우리팀이 원하는 인재는 “같이 성장할 수 있는 사람이에요”. ⇒ 우리주변팀들도 다 이렇다.
  • 그러면 어떤걸 가져갈 수 있을까요? 비용이 되게 적게들면서…
  1. 회고 ⇒ 역할을 분배 (함께자라기, A2C 코칭)
  2. 퍼실러리티 :: 회의를 준비하고, 주도하는 사람이에요. ⇒ 팀장이랑은 다르고, 회의에 대한 메타인지
  3. 개발같은거 사실 우리들은 잘 안봅니다. 특히 AI나오면서 정리 잘하거나 하는거…? 하면 좋은데 이게 잘 모르겠다. 진짜 관심가는거는 그 지식으로 문제를 해결하는 것.

• 근데 재도님 이야기 들어보니 기술적인 주제나, 정말 좋아요. 그러면 여기서 한번 시도해 볼만한게 관련해서 분명히 어려움이 있을거에요.

• 드랍다운 예를 들면 unmount될때 애니메이션 적용이라던지.. 이런 어려움을 글로 잘 녹여내면 좋겠어요 ⇒ 저희 독스 외부에서 검색되요.. 키워드로 티스토리처럼..

• 팀원 개개인으로, 우리가 6주 이후에 어떤 모습을 구체적으로 아주아주 구체적으로 정의하고, 팀적으로도 아주아주 구체적으로 정의를 해라. 그리고 그에 맞춰서 녹여내라

• 뭔가 한다고 하고 있고, 개발도 하고 있는데, 성장하지 이걸 모르겠다. AI를 쓰기도 하고, 구글링도 많이하고, 정리도 하는데 이게 제가 성장하는 게 맞나요?

  • 준일님은 어떻게 메타인지 하시나요?
  • 목표가 명확해야한다.
  1. 지속적으로 성장하고 싶어요.

• 지속적인게 뭔데요?

• 성장이라는 게 뭔데요?

2. 오픈소스에 기여하고 싶어요.

• 오픈소스가 뭔데요?
• 어떤 오픈소스인데요?

3. 취업하고 싶어요.

• 포폴로 쓰고 싶어요
• 어 이거는… 잘 모르겠어요.
• 포폴이라는게 뭔데요?
• 뭘 보여주고 싶은건데요?
• 포폴로 쓰는 경우가 되게 많은데 어떤걸 부각시키고 싶으신 건데요?

4. 제가 가진 지식을 다른사람들에게 공유하고 싶어요.

• 팀이잖아요. 팀이 빛을 발하는게 이럴떄에 발해요. ⇒ 구현하는거 사실 솔직히 말하면 기술적인 성장 관점에서는 팀보다는 혼자 구현하는게 더 얻어가는게 많고, 더 성장할 수 있어요.

  • 팀은 솔직히 작업속도를 늦출 뿐이지 좋냐..? 라고 하면 오히려 5명인팀보다 3명인 팀이 개발이 더 빠를 수 있따.
  • 이런관점에서 보시면 안된다.
  • Q. 이게 무슨말이죠?
  • 서로 서로를 관찰할 수 있다는거
  • 서로가 서로의 어려움을 공유하고 같이 생각할 수 있다는 거
  • 목표를 명확히 한다면, 서로가 관찰하면서 피드백을 주는 것도 좋아요. 다같이 코드리뷰하자! 이런것보다는 누군가가 코드리뷰가 필요하고, 이 장치로 매일 하겠다! 했는데 이게 잘 지켜지는지..
  • 혹은 재도님의 고민처럼, 재도님께서 말을 많이하니까… 누군가가 옆에서 관찰해서 하루에 한번 이야기주기. 재도님 말 너무 오늘 많이 하셨어요..
  • 아니면 아싸리 대화시간을 통계내서 오늘 재도님이 100분중 80분을 말했다. 이런거 해서 서로가 서로에게 핖드백을 장치로 활용하면서
  • 이런게 그룹프로젝트의 가치라고 생각하고, 이렇게 했을때 재도님꼐서 이야기한 소프트스킬적인, 분업이 아닌 “협업”관점에서의 이야기가 되요.

• 목표 잡아라.

  • 그리고 정리하자. 글로. ⇒ 장치들은 많으니까..

📝 결론

오늘 회의 요약

---

1. 백엔드 (Backend)

• 로그인
  • 로그인 화면에서 API 연동
  • 최소 기능으로 토큰 추가
  • 토큰 저장 필요
• 홈아이디
  • userId 파라미터로 요청 시 채널 ID 및 이름 리스트 반환
  • 배열을 반복문으로 처리하여 프론트엔드에 전달
  • 수정 및 삭제 API는 아직 구현되지 않음
• 경로 추가 화면
  • 경로 설정 등 모든 기능을 폼에서 처리
  • 폼에서 데이터를 반환하도록 구현 예정
• 손녀 기준 화면
  • 채널 ID와 유저 ID를 통해 모든 데이터를 가져와 프론트엔드에서 렌더링
  • 최적화 방안은 우선 구현 후 검토 예정

---

2. z-index 관리

• z-index 체계 확립 필요성 강조
  • Toss 스타일 적용 사례
  • z-index를 1000 단위로 분류
  • 0번: 메인 화면
  • 1000번대: 레이아웃
  • 4000번대: 캔버스
  • 6000번대 이상: 모달, 알림(alert) 등 오버레이 요소
• 사용 시기
  • Absolute 포지셔닝은 꼭 필요한 경우에만 제한적으로 사용
• 추가 논의 사항
  • 레이아웃 헤더 높이에 대한 결정은 @Zen의 테스트 결과를 바탕으로 추후 공유 예정

---

3. GitHub Actions 관련 불편 사항

• 수정 요청 프로세스
  • GitHub Actions에서 '확인' 라벨 자동 부착
• CI 테스트 이슈
  • 조건부 실행 방법 모색 필요 (현재 메일이 지속적으로 발송됨)
• Reviewer 설정 문제
  • 조건부 설정 불가, 항상 2명의 리뷰어 필요
  • 수정 후 확인 요청 시 리뷰어가 다시 할당됨
• 자동 머지 불편
  • 자동 머지 기능 미지원으로 인한 불편함
  • 머지 완료 후 작업 완료로 변경 시 확인 요청 및 리뷰 요청이 반복 발생
• PR 제목 규칙
  • 제목에 #가 없으면 머지 불가
  • PR 명 확인 작업 옵션 추가 고려
• 프로젝트 연동
  • 프로젝트 미첨부 시 머지 불가하도록 설정 필요

---

📝 기타

• Dev에 언제까지 올릴까요?
  • 3시 45분
  • 제가 할게요 그거
• 올리면 혜인님이 배포