1주차 일요일 첫 미팅 (10.27)

[KingNono1030]

프로젝트 주제

• 프로젝트 참가를 희망하는 사람에게 접근성을 제공하는
• 포트폴리오가 있어야만 이용이 가능한 서비스 -> 포트폴리오 없는 유저가 이용하기에 막막한
  • 만일 접근 제한이 있다면, 열람에서 제한이 있는게 어떨까 (2 ~ 3 개 까지는 열람 가능, 추가 열람은 인증 요구) like 화해
  • 기술적으로 어떤 식으로 접근할 지
  • 프론트 단에서 id 값을 가진 유저의 클릭 -> count 의 증가, 3개 이상이 되면 열람 제한

프로젝트 핵심 기능

• 핵심 기능
  • 스터디 구인 (게시글)
  • 프로젝트 구인 (게시글)
  • 기능 자체보다 채용시장에서 선호되는 기술들을 사용하는 편이
  • api 없이 프론트 단에서 바로 광고 삽입하는 기술
• 도전해볼만한 기능
  • 키워드에 맞는 채용공고 추천 (사람인 api -> 심사가 요구되는)
  • 웹소켓, 파이어베이스 -> 실시간
  • 알림 기능
  • 사용자 권한 관리
    • 사용자의 포트폴리오 제출 여부에 따른 열람 제한

기술 스택

• 타입스크립트
• 넥스트 앱 라우터
  • 서버 사이드 렌더링 -> 서버 컴포넌트 활용의 이점
• tailwind.css
• hook-form
• zustand
  • 상태 값의 저장 X, 중복 호출 X -> 성능적인 이점
    • 유저 정보와 세션 정보 저장에서의 긍정적인 경험
  • 쿼리와는 다른 방식

개발 환경 세팅

• 버전 관리
  • git 전략
    • 브랜치 main/dev
    • 커밋, 브랜치 생명주기
• 배포 환경
  • vercel, netlify
  • aws 배포
• CI/CD 도구
  • Github Actions -> public 무료
  • Jenkins
  • AWS CodePipeLine
  • GitLab
• 테스트
  • 단위 테스트
  • 통합 테스트
  • 참고 자료

프로젝트 목표

• 보여지는 것 자체보다 완성도를 많이 고려해서
• 기술을 사용한다면, 왜 이걸 사용하는지, 다른 대안이 있었는지, 둘을 비교해봤는지
• 기간: 한 달 추정

협업

• github discussions 활용
• 프로젝트 회의 -> 기본은 주 3회, 필요에 따라 유동적으로
• 컨벤션
  • 깃 컨벤션은 비슷
  • 커밋 컨벤션의 준수
    • 커밋 단위, 어떤 기능에 대한 변화가 있는지 명세
    • 깃 모지
  • 린트, 프리티어 -> airbnb 참고

역할 분담

• 유저 기능
• 텍스트 에디터
  • 에디터 자체보다 커스텀에서의 까다로움
• 공용 컴포넌트
  • 버튼, 드롭다운, 모달 / 토스트, input

[KingNono1030]

GPT 피드백

회의록을 살펴본 결과, 첫 번째 회의에서의 논의는 전체적으로 잘 구성되어 있으나, 추가로 다루어야 할 부분 및 더 깊이 논의가 필요한 부분도 있습니다. 다음은 피드백입니다:

누락된 논의 항목

1.	프로젝트 목적과 타겟 사용자 정의
•	Dev for Dev 프로젝트의 목적과 타겟 사용자가 명확히 정의되지 않았습니다. 프로젝트가 개발자 간 커뮤니티 형성을 목표로 한다면, 주 타겟이 신입 개발자인지, 경력자까지 포괄할 것인지 명확히 정하고 그에 맞는 기능과 UI를 계획하는 것이 중요합니다.
•	이에 따른 추가적인 UX/UI 요소와 서비스의 사용자 경험 최적화 방안에 대한 논의도 필요할 수 있습니다.
2.	세부 기능 스펙 정의 및 기술 우선순위
•	기능 목록이 나열되어 있지만, 각 기능이 왜 중요한지, 어떤 기술을 먼저 도입할지에 대한 우선순위가 정해지지 않았습니다.
•	예를 들어, 실시간 알림 기능과 포트폴리오 열람 제한 기능 중 어떤 기능이 프로젝트 초기에 더 필요한지, 개발 리소스를 어떻게 배분할 것인지에 대한 논의가 추가되어야 합니다.
3.	보안 및 인증
•	포트폴리오 열람 제한 기능을 포함하여, 사용자 인증이나 데이터 접근에 관한 보안적인 측면이 간과된 것 같습니다. 특히 사용자 인증과 데이터 접근 제어는 개발자 커뮤니티 사이트에서 중요한 요소이며, 보안에 대한 논의가 이루어져야 합니다.
•	OAuth나 JWT를 통해 사용자 인증을 할 것인지, 외부 로그인 서비스를 제공할 것인지 등을 결정할 필요가 있습니다.
4.	데이터베이스 및 백엔드 아키텍처
•	클라이언트 쪽의 기술 스택은 나열되었으나, 백엔드와 데이터베이스에 대한 구체적인 논의가 필요합니다.
•	사용자의 포트폴리오나 스터디/프로젝트 게시글을 저장할 데이터베이스 구조, 그리고 이를 관리할 API 설계가 중요한데, 이에 대한 내용이 누락되었습니다.
5.	사용자 피드백 루프
•	사용자 피드백을 반영할 방법이나 주기가 정해져 있지 않습니다. 사용자가 어떤 기능을 자주 사용하는지, 불편한 점이 무엇인지 등 피드백을 받아 프로젝트를 발전시키는 과정이 필요합니다.
•	예를 들어 베타 테스트 기간을 두고 피드백을 반영하는 계획을 수립하는 것이 좋습니다.

더 깊이 논의가 필요한 부분

1.	열람 제한 및 포트폴리오 접근성
•	열람 제한을 통해 포트폴리오가 없는 사용자도 참여할 수 있도록 접근성을 높인다는 접근은 좋은 아이디어이지만, 구체적인 제한 방법과 유저 경험을 고려한 세밀한 설계가 필요합니다.
•	예를 들어 3개까지 열람 제한 후 추가 열람 시 인증을 요구하는 방식에서, 인증 방식이 무엇인지 (예: 이메일 인증, 전화번호 인증 등)와 이로 인해 발생할 수 있는 UX 문제를 충분히 논의해야 합니다.
2.	API 통합 방식 및 기술 도입 의의
•	사람인 API 통합, 실시간 알림 구현을 위한 웹소켓이나 Firebase 도입과 같은 기능의 구현 방식에 대해 좀 더 구체적인 논의가 필요합니다. API 연동에서 고려할 부분, 예상되는 어려움 등을 충분히 논의하고 도입 이유를 정리하는 것이 좋습니다.
•	또한, 도입할 기술이 왜 선호되는지, 팀이 해당 기술을 통해 어떤 것을 얻을 수 있을지에 대한 비교도 필요합니다.
3.	배포와 유지보수 계획
•	배포 환경을 다양한 옵션으로 열거했으나, 장기적으로 어떤 배포 환경을 선택할지에 대한 심도 있는 논의가 필요합니다. 예를 들어, 프로젝트의 트래픽이 증가했을 때 확장 가능한 배포 옵션이 있는지, 지속적인 유지보수와 CI/CD 관리 방식에 대한 결정이 필요합니다.
4.	협업 툴과 커뮤니케이션 방식
•	협업 툴로 GitHub Discussions와 주 3회 회의만 언급되었습니다. 각 팀원이 어떻게 일정을 공유하고 진행 상황을 체크할 것인지, 회의 외에 비동기식 협업이 필요한지에 대한 방안이 구체적으로 마련되지 않았습니다.
•	특히 기능별 진행 상황과 이슈 관리를 효율적으로 하는 방안, 예를 들어 Jira나 Notion 등 프로젝트 관리 툴을 활용할지 여부를 논의할 필요가 있습니다.

이와 같은 피드백을 바탕으로 프로젝트를 좀 더 견고하게 기획하고 구체화할 수 있을 것입니다.

[KingNono1030]

https://chatgpt.com/share/671e3b30-2354-800c-aabb-eb7c1399e031