1. 아이디어 결정
   • 서울 주요 장소 50곳에 대한 인구 밀도 정보를 제공하는 서비스
   • 지도 API와 서울시 실시간 데이터 API를 사용하여 구현할 계획
   • 구체적인 기능들은 정하지 못한 상태, 이번주 정할 예정
   • 대략적인 기능들
     • 지도로 서울 주요 장소 50곳에 대한 인구 밀도 정보 제공
     • 단톡방 같은 채팅방으로 해당 장소에 있는 사람들에게 실제 인구 밀도가 어떤지 물어볼 수 있는 서비스 제공
     • 크리스마스 같이 사람이 밀집되는 기간 같은 경우, 과거의 정보를 그래프로 제공
       • 코로나 같은 사회 이슈가 있을 수 있기 때문에 5~10년 정도로 계획 중
2. 그라운드 룰 결정
   • 그라운드 룰 및 코드 컨벤션 원하시면 보여드리기
3. 아이디어 구체화 회의 진행
   • 기능 요구사항이 어느정도 도출됨

1. 협업하는 방식
   • 서로 생각하는 협업의 개념이 다름
   • 페어 프로그래밍을 꼭 해야하는지?
2. 기획서의 깊이
   • 짧은 시간 내에 프로젝트에 대해 어느정도의 계획과 설계를 해야하는지
   • 기획서는 유동적으로 변동할 수 있는가?

1. 협업하는 방식
   • git flow와도 연관지어 생각하면 좋을 것 같다.
   • 어떤 것이 동기부여가 더 잘 될 것인지 생각해보자.
   • 우리가 생각한 방향이 이상한 건 아니다..! 충분히 고민해볼만한 것이었다.
   • 현업에서는 페어를 못하기 때문에 지금이 페어를 할 수 있는 마지막 기회일 수도 있다.
2. 기획서의 깊이
   • MVP방법론 추천 - 주별 스프린트를 나눠서 매주 마지막 날에는 무조건 배포하는 것을 추천
   • 기획서는 유동적으로 변동할 수 있는가?
     • 개발자와 기획자의 관점이 다를 수 있다. 기획을 다같이 하면 문제가 생기지 않을 수도 있다. 기획을 따로 하면 의견 충돌이 생길 수도 있다. 기획서는 유연하게 바꿀 수 있다.(다만 고통받을 수는 있다.)
3. 아카이빙
   • 노션이 닫히면 후에 문제가 생길 수 있으니 깃헙 올인원하자.
4. 스터디 방식
   • 6주라는 시간을 고려했으면 좋겠다.
   • 뭐든지 호흡을 짧게 가져가자.
   • 사이클 기준으로 생각하자.

• SSE(Server Sent Event)란 무엇일까?
• 클라이언트 식별과 쿠키
• 인증과 인가 / OAuth를 해야 하는 이유
• 웹푸시

• UI 기획서 작성
• 기술 스택(큰 범위) 정하기
• 설계 공유 준비하기(10분 분량)

1. 상준
   • 2명씩 나누어 페어프로그래밍 진행
   • 페어끼리 어떻게 프로그래밍 할지는 직접 정하기
   • 각 페어의 PR 내용은 데일리스크럼 시간에 공유
2. 현정
   • 일주일 단위로 페어 변경
3. 한빈
   • 데일리스크럼에서 페어 간 의사 결정 이유 공유 및 코드 리뷰
   • 4명이 함께 결정할 것들을 모두 끝낸 후 페어 진행
4. 윤우
   • PR의 단위는 작으면 좋음

⇒ 결론 : 일주일 단위로 2:2 페어프로그래밍 진행, 진행 방식은 각자 정함

• 배포
  • CI/CD 관련 학습
  • 배포 만큼은 시간이 오래 걸려도 완료
• 피어세션 자료 준비
  • 기존 문서 추려내서 공유
• 데모 자료 준비
  • 영상은 소리 없이 촬영, 발표 시간에 직접 설명
  • 대본은 기능 리스트에서 추려내서 공유

기한	설명
Day1 10:00~12:00	주간 계획서 작성
Day4 13:00~17:00	버그 수정 및 배포
Day4 17:00~19:00	데모 및 피어세션 준비
Day5 16:00~17:00	팀 회고 및 개인 회고 wiki 작성

# 1. 멘토님과의 미팅

1. 아이디어 결정
   • 서울 주요 장소 50곳에 대한 인구 밀도 정보를 제공하는 서비스
   • 지도 API와 서울시 실시간 데이터 API를 사용하여 구현할 계획
   • 구체적인 기능들은 정하지 못한 상태, 이번주 정할 예정
   • 대략적인 기능들
     • 지도로 서울 주요 장소 50곳에 대한 인구 밀도 정보 제공
     • 단톡방 같은 채팅방으로 해당 장소에 있는 사람들에게 실제 인구 밀도가 어떤지 물어볼 수 있는 서비스 제공
     • 크리스마스 같이 사람이 밀집되는 기간 같은 경우, 과거의 정보를 그래프로 제공
       • 코로나 같은 사회 이슈가 있을 수 있기 때문에 5~10년 정도로 계획 중
2. 그라운드 룰 결정
   • 그라운드 룰 및 코드 컨벤션 원하시면 보여드리기
3. 아이디어 구체화 회의 진행
   • 기능 요구사항이 어느정도 도출됨

1. 협업하는 방식
   • 서로 생각하는 협업의 개념이 다름
   • 페어 프로그래밍을 꼭 해야하는지?
2. 기획서의 깊이
   • 짧은 시간 내에 프로젝트에 대해 어느정도의 계획과 설계를 해야하는지
   • 기획서는 유동적으로 변동할 수 있는가?

1. 협업하는 방식
   • git flow와도 연관지어 생각하면 좋을 것 같다.
   • 어떤 것이 동기부여가 더 잘 될 것인지 생각해보자.
   • 우리가 생각한 방향이 이상한 건 아니다..! 충분히 고민해볼만한 것이었다.
   • 현업에서는 페어를 못하기 때문에 지금이 페어를 할 수 있는 마지막 기회일 수도 있다.
2. 기획서의 깊이
   • MVP방법론 추천 - 주별 스프린트를 나눠서 매주 마지막 날에는 무조건 배포하는 것을 추천
   • 기획서는 유동적으로 변동할 수 있는가?
     • 개발자와 기획자의 관점이 다를 수 있다. 기획을 다같이 하면 문제가 생기지 않을 수도 있다. 기획을 따로 하면 의견 충돌이 생길 수도 있다. 기획서는 유연하게 바꿀 수 있다.(다만 고통받을 수는 있다.)
3. 아카이빙
   • 노션이 닫히면 후에 문제가 생길 수 있으니 깃헙 올인원하자.
4. 스터디 방식
   • 6주라는 시간을 고려했으면 좋겠다.
   • 뭐든지 호흡을 짧게 가져가자.
   • 사이클 기준으로 생각하자.

• SSE(Server Sent Event)란 무엇일까?
• [클라이언트 식별과 쿠키](https://ideveloper2.dev/blog/2019-11-16--%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8-%EC%8B%9D%EB%B3%84%EA%B3%BC-%EC%BF%A0%ED%82%A4/)
• 인증과 인가 / OAuth를 해야 하는 이유
• 웹푸시

• UI 기획서 작성
• 기술 스택(큰 범위) 정하기
• 설계 공유 준비하기(10분 분량)

1. 상준
   • 2명씩 나누어 페어프로그래밍 진행
   • 페어끼리 어떻게 프로그래밍 할지는 직접 정하기
   • 각 페어의 PR 내용은 데일리스크럼 시간에 공유
2. 현정
   • 일주일 단위로 페어 변경
3. 한빈
   • 데일리스크럼에서 페어 간 의사 결정 이유 공유 및 코드 리뷰
   • 4명이 함께 결정할 것들을 모두 끝낸 후 페어 진행
4. 윤우
   • PR의 단위는 작으면 좋음

⇒ 결론 : 일주일 단위로 2:2 페어프로그래밍 진행, 진행 방식은 각자 정함

• 배포
  • CI/CD 관련 학습
  • 배포 만큼은 시간이 오래 걸려도 완료
• 피어세션 자료 준비
  • 기존 문서 추려내서 공유
• 데모 자료 준비
  • 영상은 소리 없이 촬영, 발표 시간에 직접 설명
  • 대본은 기능 리스트에서 추려내서 공유

기한	설명
Day1 10:00~12:00	주간 계획서 작성
Day4 13:00~17:00	버그 수정 및 배포
Day4 17:00~19:00	데모 및 피어세션 준비
Day5 16:00~17:00	팀 회고 및 개인 회고 wiki 작성