diff --git a/docs/docusaurus/dev_log/authors.yml b/docs/docusaurus/dev_log/authors.yml
new file mode 100644
index 00000000..947059c1
--- /dev/null
+++ b/docs/docusaurus/dev_log/authors.yml
@@ -0,0 +1,33 @@
+zen:
+ name: 임재도
+ title: J210
+ url: https://fantasmith.com
+ image_url: https://github.com/effozen.png
+ socials:
+ x: EffoZen
+ github: effozen
+ linkedin: effozen
+
+leedongyull:
+ name: 이동율
+ title: J174
+ url: https://github.com/leedongyull
+ image_url: https://github.com/leedongyull.png
+ socials:
+ github: leedongyull
+
+juwon5272:
+ name: 김주원
+ title: J060
+ url: https://github.com/juwon5272
+ image_url: https://github.com/juwon5272.png
+ socials:
+ github: juwon5272
+
+happyhyep:
+ name: 정혜인
+ title: J234
+ url: https://github.com/happyhyep
+ image_url: https://github.com/happyhyep.png
+ socials:
+ github: happyhyep
\ No newline at end of file
diff --git a/docs/docusaurus/dev_log/intro.mdx b/docs/docusaurus/dev_log/intro.mdx
new file mode 100644
index 00000000..4bfec3f6
--- /dev/null
+++ b/docs/docusaurus/dev_log/intro.mdx
@@ -0,0 +1,127 @@
+---
+slug: ground_rule
+title: ⚖️ Ground Rule
+tags: [teamInfo]
+sidebar_position: 2
+sidebar_label: ⚖️ 그라운드 룰
+keywords: ['members', 'team', '팀원', '소개']
+pagination_label: Markdown features
+authors: [zen]
+last_update:
+ date: 2024-10-30
+ authors: [zen]
+---
+
+
+
+> 우리들의 공통 목표와 그에 따른 행동 강령입니다.
+팀의 모든 의사결정은 그라운드 룰에 입각해서 판단합니다.
+>
+
+
+## ❓ 제 1 원칙
+
+### ❓ No Dummy Qeustion!
+
+- 세상에 바보같은 질문은 없습니다. 그 태도에 문제가 있을 뿐.
+- 저희는 절대 그 어떠한 질문에도 비웃음, 조소 등을 표하지 않습니다..!
+- 어떠한 질문에도 최선의 답을 제공합니다.
+- 반대로, 질문자는 반드시 질문하는 것에 대한 근거를 마련한 상태로 질문합니다.
+- 상호 예의를 존중합니다.
+
+
+
+## 📝 프로젝트에 대한 공통의 목표
+
+### 🚀 포트폴리오에 쓸 수 있는 실사용자를 위한 서비스
+
+- **포트폴리오에 담을 가치 있는 프로젝트를 개발**: 모든 팀원은 포트폴리오로 활용할 수 있는 완성도 높은 프로젝트를 목표로 한다.
+- **실사용자에게 의미 있는 서비스**: 프로젝트는 실제 사용자에게 도움이 될 수 있는 기능을 제공해야 한다. 재미를 위한 프로젝트일지라도, 명확한 사용자 경험(UX)을 기반으로 해야 함.
+- **유지보수 가능성**: 프로젝트는 지속적으로 유지보수될 수 있도록 설계하며, 최소 1년간 유지보수할 수 있도록 계획을 세운다.
+
+
+
+
+## 📝 기술적인 목표
+
+- 추후 주제가 정해지면 도입
+
+
+
+## 📝 팀 문화
+
+### 😆 싱글벙글 하하호호 우리들
+
+- **즐겁고 활발한 팀 분위기**: 팀원들 간에 **소통이 원활하고 편안한 분위기**를 유지한다. 스몰톡이나 비공식적인 대화를 통해 팀 분위기를 활기차게 유지하며, 서로의 동기부여를 위해 노력한다.
+- **건강과 워라밸 존중**: 과도한 업무보다는 건강을 최우선으로 고려하며, **휴식이 필요한 경우** 언제든 자유롭게 쉬는 문화를 장려한다. 장기적으로 **지속 가능한 프로젝트**를 목표로 한다. 단, 마감 직전이나 스프린트 때는 달린다.
+- **각자의 의견 존중**: 서로의 의견을 경청하고, 의견 충돌이 발생했을 때는 둘 사이에서 해결보다는 반드시 팀원 전체가 참여하여 논의한다. 이때, 다수결 또는 협의를 통해 해결한다. 필요한 경우 **카드를 사용한 의사결정 방식**(ex: "나 말 좀 하게 해줘 카드")을 도입해 원활한 의사결정을 진행할 수 있도록 한다.
+
+
+
+## 📝 협업 및 의사소통 규칙
+
+### 💬 잦은 커뮤니케이션을 할 수 있어야 한다.
+
+- **슬랙 및 협업 도구 활용**: 슬랙을 기본 소통 도구로 사용하며, 메시지를 읽었을 때는 **이모지 대신 명확한 답변**을 남겨 소통의 명확성을 유지한다.
+- **실시간 협업 도구 사용**: 실시간 소통이 필요한 경우, `Zep` 을 사용해 비대면 상황에서도 **실시간 피드백과 소통**이 이루어지도록 한다.
+- **코어 타임 준수**: 매일 10시부터 7시까지 코어 타임을 운영하며, 이 시간 동안에는 집중적으로 프로젝트에 참여하고 빠른 피드백을 제공한다. 코어 타임 외에는 자율적으로 활동할 수 있지만, 긴급한 상황에서는 `Zep`, `슬랙`을 통해 즉각적인 소통이 이루어져야 한다.
+- **신뢰**: 주변의 반응 및 생각에 흔들리지 말고, 팀이 결정한 내용을 전적으로 신뢰한다.
+
+
+
+
+## 📝 의사결정 방식
+
+### 🤝 팀 전체가 동의하는 의사결정
+
+- **의사결정은 팀 전체가 참여**: 주요 결정은 팀원 모두가 논의하며, GitHub Issue를 통해 정리된 문제점과 해결 방안을 공유한 후, 충분한 근거를 바탕으로 결정한다.
+- **데일리 스크럼**: 매일 아침 **데일리 스크럼**을 통해 각자의 작업 진행 상황을 공유하고, 문제점 및 해결책을 논의한다.
+- **긴급 의사결정**: 필요시 `Zep` 또는 `슬랙` 언급을 통해 팀원들을 소집해 **긴급 의사결정**을 빠르게 내린다.
+- **내 말좀 들어줘 카드!:** 각자 2 장의 카드가 부여되며, 서로가 납득할만한 수준에서 의견이 대립될 때 사용한다. 사용한 사람의 의견을 무조건적으로 수용한다. (”서로가 납득 가능한 상식선”이라는 전제)
+
+
+
+## 📝 프로젝트 개발 원칙
+
+### 😇 사용자 경험(UX) 중심의 개발
+
+- **사용자 경험(UX) 중심 개발**: 기술적인 완성도뿐만 아니라 **사용자의 관점에서 서비스의 유용성**을 고려한다. 기능이 잘 동작할 뿐 아니라, 사용자가 쉽게 이해하고 사용할 수 있어야 한다.
+- **작업 공유 및 문서화**: 모든 작업은 명확히 공유되어야 하며, **GitHub Issue**와 **노션**을 통해 진행 상황과 문제점을 기록한다. 트러블슈팅, 배운 기술, 이슈 등을 꼼꼼히 문서화해 프로젝트의 전체 진행을 기록한다.
+
+
+
+## 📝 작업 분배 및 기록 관리
+
+### 🧑🤝🧑 분업이 아닌 협업
+
+- **작업 기록 관리**: 모든 작업은 노션과 GitHub Pull Request, Issue 등을 통해 **투명하게 관리**된다. 이를 통해 프로젝트의 진행 상황을 쉽게 파악하고, 작업의 흐름을 유지할 수 있다.
+- **스프린트 방식 도입**: 코어 타임 내에서 주어진 작업을 마무리하고, **주 단위로 목표를 설정해 달성 여부를 확인**한다. 스프린트 종료 후 회고를 진행해 다음 스프린트에 반영할 개선점을 도출한다.
+
+
+
+## 📝 코드 리뷰 및 PR 규칙
+
+### 🧑💻 4명의 PR Approve 및 최소 주 2회의 코드 리뷰
+
+- **최소 주 2회의 컨벤션 및 맥락 파악 목적의 코드 리뷰**: 팀원들이 서로의 코드를 리뷰하며, 코드의 품질도 중요하지만, 이때의 핵심은 우리의 컨벤션을 서로 얼마나 잘 지키고 있는지 이다.. 코드 리뷰는 팀원의 성장뿐 아니라, **서로의 작업을 이해하고 소통하는 과정**으로 삼는다. 즉, 각자의 개발 맥락을 파악하는 목적을 주로 한다.
+- **PR 승인 규칙**: 4명 모두의 **PR 승인**이 있어야만 기능을 머지할 수 있으며, 모든 팀원이 해당 기능에 대한 충분한 이해를 갖출 수 있도록 한다.
+- **작업의 투명성 유지**: 코드 리뷰와 PR을 통해 프로젝트의 모든 진행이 투명하게 공유되며, 이는 팀원 간의 신뢰를 강화하는 중요한 요소로 작용한다.
+- **데일리 스크럼의 활용:** 이슈나, 코드 공유 등은 데일리 스크럼 시간에 더하여, 아침에 소통하도록 한다.
+
+
+
+## 📝 프로젝트 회고
+
+### 🎨 Figma, Miro 등을 이용한 시각적인 회고
+
+- **회고 방식**: 프로젝트 진행 중 **KPT(Keep, Problem, Try) 방식**으로 주기적인 회고를 진행해, 잘한 부분과 개선할 점을 분석하고 다음 스프린트에 반영한다. 피드백은 GitHub 또는 피그마 등을 활용해 시각적으로 정리한다.
+- **결과 기록**: 회고 내용과 함께 프로젝트 과정에서의 문제점과 해결 방안을 기록하여 **포트폴리오에서 활용**할 수 있는 자료로 남긴다.
+
+
+
+## 📝 긴급 상황 대응
+
+### 👀 ”이의있소!”
+
+- **TMT, TMI 방지 카드**: 각 팀원은 필요시 언제든지 **"나 힘들다 카드"**를 사용해 TMT, TMI를 막을 수 있다. 이때, 😪, 😴 와 같은 이모지나 기능을 사용해서 알린다.
+- **스톱 카드**: 기술에 대한 학습이나, 구현이 요구사항을 넘어서 너무 깊어질 경우 **"스톱 카드"**를 사용해 중단시키고, 본래 해야하는 업무에 집중시킨다. 이는 PR 리뷰를 하면서든, 언제든지 자유롭게 제안할 수 있다.
diff --git a/docs/docusaurus/dev_log/tags.yml b/docs/docusaurus/dev_log/tags.yml
new file mode 100644
index 00000000..54b2f87b
--- /dev/null
+++ b/docs/docusaurus/dev_log/tags.yml
@@ -0,0 +1,24 @@
+tech:
+ label: Tech
+ permalink: /tech
+ description: 기술적인 시도와 도전을 담은 내용입니다.
+
+troubleshooting:
+ label: Troubleshooting
+ permalink: /troubleshooting
+ description: 문제 해결과 디버깅을 다루는 내용입니다.
+
+boostcamp:
+ label: Boostcamp
+ permalink: /boostcamp
+ description: 네이버 부스트캠프 9기 웹⋅모바일 과정과 관련된 내용입니다.
+
+retrospective:
+ label: Retrospective
+ permalink: /retrospective
+ description: 회고와 배운 점을 정리한 내용입니다.
+
+growth:
+ label: Growth
+ permalink: /growth
+ description: 성장과 발전에 대한 내용입니다.
\ No newline at end of file
diff --git a/docs/docusaurus/docs/about/about_members.mdx b/docs/docusaurus/docs/about/about_members.mdx
new file mode 100644
index 00000000..4efef878
--- /dev/null
+++ b/docs/docusaurus/docs/about/about_members.mdx
@@ -0,0 +1,22 @@
+---
+slug: about_members
+title: '🧑💻 팀원 소개'
+tags: [about]
+sidebar_position: 1
+sidebar_label: 🧑💻 팀원 소개
+keywords: ['members', 'team', '팀원', '소개']
+pagination_label: Markdown features
+last_update:
+ date: 2024-10-30
+ author: happyhyep
+---
+
+## 팀원 소개
+
+> Front-End 4명으로 구성되어 있으며, 전면 온라인으로 진행되었습니다.
+
+|J060_김주원|J174_이동율|J210_임재도|J234_정혜인|
+|:--:|:--:|:--:|:--:|
+|||||
+|FE|FE|FE|Full Stack (FE + BE)|
+|@juwon5272|@leedongyull|@effozen|@happyhyep|
diff --git a/docs/docusaurus/docs/about/card_list.mdx b/docs/docusaurus/docs/about/card_list.mdx
new file mode 100644
index 00000000..d23a9990
--- /dev/null
+++ b/docs/docusaurus/docs/about/card_list.mdx
@@ -0,0 +1,40 @@
+---
+slug: card_list
+title: 🎴 카드 리스트
+tags: [about]
+sidebar_position: 3
+sidebar_label: 🎴 카드 리스트
+keywords: ['팀', '규칙']
+pagination_label: Markdown features
+last_update:
+ date: 2024-10-30
+ author: happyhyep
+---
+
+## 🧑💻 내 말좀 들어줘 카드
+
+> 내 말좀 들어줘 카드는 팀 내 의사결정의 순간에 근거는 합당한데 좀처럼 답이 나오지 않을 경우, 사용할 수 있는 카드입니다.
+카드 사용 시 사용자의 의견을 팀원 전체가 수용합니다.
+최초 2장 발행되어 있습니다.
+>
+
+| 사용자 | 남은 횟수 | 사용 맥락 |
+| --- | --- | --- |
+| @Zen | 2 | |
+| @동율 이 | 2 | |
+| @혜인 정 | 2 | |
+| @주원 김 | 2 | |
+
+## 🧑💻 저 조금만 쉬어갈게요 카드
+
+> 프로젝트를 하다보면 정말정말 지치는 순간이 올 수 있습니다.
+팀의 개발 일정에 지장이 가지 않는 선에서라면 반차 느낌으로 2회 사용할 수 있는 카드입니다.
+이걸 사용하면, 해당 반차 시간 동안은 팀은 급한 상황이 아니라면 팀원이 쉴 수 있게 돌봐줍니다.
+>
+
+| 사용자 | 남은 횟수 | 사용 맥락 |
+| --- | --- | --- |
+| @Zen | 2 | |
+| @동율 이 | 2 | |
+| @혜인 정 | 2 | |
+| @주원 김 | 2 | |
\ No newline at end of file
diff --git a/docs/docusaurus/docs/about/ground_rule.mdx b/docs/docusaurus/docs/about/ground_rule.mdx
new file mode 100644
index 00000000..ffef8cfc
--- /dev/null
+++ b/docs/docusaurus/docs/about/ground_rule.mdx
@@ -0,0 +1,126 @@
+---
+slug: ground_rule
+title: ⚖️ Ground Rule
+tags: [about]
+sidebar_position: 2
+sidebar_label: ⚖️ 그라운드 룰
+keywords: ['members', 'team', '팀원', '소개']
+pagination_label: Markdown features
+last_update:
+ date: 2024-10-30
+ author: zen
+---
+
+
+
+> 우리들의 공통 목표와 그에 따른 행동 강령입니다.
+팀의 모든 의사결정은 그라운드 룰에 입각해서 판단합니다.
+>
+
+
+## ❓ 제 1 원칙
+
+### ❓ No Dummy Qeustion!
+
+- 세상에 바보같은 질문은 없습니다. 그 태도에 문제가 있을 뿐.
+- 저희는 절대 그 어떠한 질문에도 비웃음, 조소 등을 표하지 않습니다..!
+- 어떠한 질문에도 최선의 답을 제공합니다.
+- 반대로, 질문자는 반드시 질문하는 것에 대한 근거를 마련한 상태로 질문합니다.
+- 상호 예의를 존중합니다.
+
+
+
+## 📝 프로젝트에 대한 공통의 목표
+
+### 🚀 포트폴리오에 쓸 수 있는 실사용자를 위한 서비스
+
+- **포트폴리오에 담을 가치 있는 프로젝트를 개발**: 모든 팀원은 포트폴리오로 활용할 수 있는 완성도 높은 프로젝트를 목표로 한다.
+- **실사용자에게 의미 있는 서비스**: 프로젝트는 실제 사용자에게 도움이 될 수 있는 기능을 제공해야 한다. 재미를 위한 프로젝트일지라도, 명확한 사용자 경험(UX)을 기반으로 해야 함.
+- **유지보수 가능성**: 프로젝트는 지속적으로 유지보수될 수 있도록 설계하며, 최소 1년간 유지보수할 수 있도록 계획을 세운다.
+
+
+
+
+## 📝 기술적인 목표
+
+- 추후 주제가 정해지면 도입
+
+
+
+## 📝 팀 문화
+
+### 😆 싱글벙글 하하호호 우리들
+
+- **즐겁고 활발한 팀 분위기**: 팀원들 간에 **소통이 원활하고 편안한 분위기**를 유지한다. 스몰톡이나 비공식적인 대화를 통해 팀 분위기를 활기차게 유지하며, 서로의 동기부여를 위해 노력한다.
+- **건강과 워라밸 존중**: 과도한 업무보다는 건강을 최우선으로 고려하며, **휴식이 필요한 경우** 언제든 자유롭게 쉬는 문화를 장려한다. 장기적으로 **지속 가능한 프로젝트**를 목표로 한다. 단, 마감 직전이나 스프린트 때는 달린다.
+- **각자의 의견 존중**: 서로의 의견을 경청하고, 의견 충돌이 발생했을 때는 둘 사이에서 해결보다는 반드시 팀원 전체가 참여하여 논의한다. 이때, 다수결 또는 협의를 통해 해결한다. 필요한 경우 **카드를 사용한 의사결정 방식**(ex: "나 말 좀 하게 해줘 카드")을 도입해 원활한 의사결정을 진행할 수 있도록 한다.
+
+
+
+## 📝 협업 및 의사소통 규칙
+
+### 💬 잦은 커뮤니케이션을 할 수 있어야 한다.
+
+- **슬랙 및 협업 도구 활용**: 슬랙을 기본 소통 도구로 사용하며, 메시지를 읽었을 때는 **이모지 대신 명확한 답변**을 남겨 소통의 명확성을 유지한다.
+- **실시간 협업 도구 사용**: 실시간 소통이 필요한 경우, `Zep` 을 사용해 비대면 상황에서도 **실시간 피드백과 소통**이 이루어지도록 한다.
+- **코어 타임 준수**: 매일 10시부터 7시까지 코어 타임을 운영하며, 이 시간 동안에는 집중적으로 프로젝트에 참여하고 빠른 피드백을 제공한다. 코어 타임 외에는 자율적으로 활동할 수 있지만, 긴급한 상황에서는 `Zep`, `슬랙`을 통해 즉각적인 소통이 이루어져야 한다.
+- **신뢰**: 주변의 반응 및 생각에 흔들리지 말고, 팀이 결정한 내용을 전적으로 신뢰한다.
+
+
+
+
+## 📝 의사결정 방식
+
+### 🤝 팀 전체가 동의하는 의사결정
+
+- **의사결정은 팀 전체가 참여**: 주요 결정은 팀원 모두가 논의하며, GitHub Issue를 통해 정리된 문제점과 해결 방안을 공유한 후, 충분한 근거를 바탕으로 결정한다.
+- **데일리 스크럼**: 매일 아침 **데일리 스크럼**을 통해 각자의 작업 진행 상황을 공유하고, 문제점 및 해결책을 논의한다.
+- **긴급 의사결정**: 필요시 `Zep` 또는 `슬랙` 언급을 통해 팀원들을 소집해 **긴급 의사결정**을 빠르게 내린다.
+- **내 말좀 들어줘 카드!:** 각자 2 장의 카드가 부여되며, 서로가 납득할만한 수준에서 의견이 대립될 때 사용한다. 사용한 사람의 의견을 무조건적으로 수용한다. (”서로가 납득 가능한 상식선”이라는 전제)
+
+
+
+## 📝 프로젝트 개발 원칙
+
+### 😇 사용자 경험(UX) 중심의 개발
+
+- **사용자 경험(UX) 중심 개발**: 기술적인 완성도뿐만 아니라 **사용자의 관점에서 서비스의 유용성**을 고려한다. 기능이 잘 동작할 뿐 아니라, 사용자가 쉽게 이해하고 사용할 수 있어야 한다.
+- **작업 공유 및 문서화**: 모든 작업은 명확히 공유되어야 하며, **GitHub Issue**와 **노션**을 통해 진행 상황과 문제점을 기록한다. 트러블슈팅, 배운 기술, 이슈 등을 꼼꼼히 문서화해 프로젝트의 전체 진행을 기록한다.
+
+
+
+## 📝 작업 분배 및 기록 관리
+
+### 🧑🤝🧑 분업이 아닌 협업
+
+- **작업 기록 관리**: 모든 작업은 노션과 GitHub Pull Request, Issue 등을 통해 **투명하게 관리**된다. 이를 통해 프로젝트의 진행 상황을 쉽게 파악하고, 작업의 흐름을 유지할 수 있다.
+- **스프린트 방식 도입**: 코어 타임 내에서 주어진 작업을 마무리하고, **주 단위로 목표를 설정해 달성 여부를 확인**한다. 스프린트 종료 후 회고를 진행해 다음 스프린트에 반영할 개선점을 도출한다.
+
+
+
+## 📝 코드 리뷰 및 PR 규칙
+
+### 🧑💻 4명의 PR Approve 및 최소 주 2회의 코드 리뷰
+
+- **최소 주 2회의 컨벤션 및 맥락 파악 목적의 코드 리뷰**: 팀원들이 서로의 코드를 리뷰하며, 코드의 품질도 중요하지만, 이때의 핵심은 우리의 컨벤션을 서로 얼마나 잘 지키고 있는지 이다.. 코드 리뷰는 팀원의 성장뿐 아니라, **서로의 작업을 이해하고 소통하는 과정**으로 삼는다. 즉, 각자의 개발 맥락을 파악하는 목적을 주로 한다.
+- **PR 승인 규칙**: 4명 모두의 **PR 승인**이 있어야만 기능을 머지할 수 있으며, 모든 팀원이 해당 기능에 대한 충분한 이해를 갖출 수 있도록 한다.
+- **작업의 투명성 유지**: 코드 리뷰와 PR을 통해 프로젝트의 모든 진행이 투명하게 공유되며, 이는 팀원 간의 신뢰를 강화하는 중요한 요소로 작용한다.
+- **데일리 스크럼의 활용:** 이슈나, 코드 공유 등은 데일리 스크럼 시간에 더하여, 아침에 소통하도록 한다.
+
+
+
+## 📝 프로젝트 회고
+
+### 🎨 Figma, Miro 등을 이용한 시각적인 회고
+
+- **회고 방식**: 프로젝트 진행 중 **KPT(Keep, Problem, Try) 방식**으로 주기적인 회고를 진행해, 잘한 부분과 개선할 점을 분석하고 다음 스프린트에 반영한다. 피드백은 GitHub 또는 피그마 등을 활용해 시각적으로 정리한다.
+- **결과 기록**: 회고 내용과 함께 프로젝트 과정에서의 문제점과 해결 방안을 기록하여 **포트폴리오에서 활용**할 수 있는 자료로 남긴다.
+
+
+
+## 📝 긴급 상황 대응
+
+### 👀 ”이의있소!”
+
+- **TMT, TMI 방지 카드**: 각 팀원은 필요시 언제든지 **"나 힘들다 카드"**를 사용해 TMT, TMI를 막을 수 있다. 이때, 😪, 😴 와 같은 이모지나 기능을 사용해서 알린다.
+- **스톱 카드**: 기술에 대한 학습이나, 구현이 요구사항을 넘어서 너무 깊어질 경우 **"스톱 카드"**를 사용해 중단시키고, 본래 해야하는 업무에 집중시킨다. 이는 PR 리뷰를 하면서든, 언제든지 자유롭게 제안할 수 있다.
diff --git a/docs/docusaurus/docs/about/reference_link.mdx b/docs/docusaurus/docs/about/reference_link.mdx
new file mode 100644
index 00000000..1b834647
--- /dev/null
+++ b/docs/docusaurus/docs/about/reference_link.mdx
@@ -0,0 +1,28 @@
+---
+slug: reference_link
+title: 🎗 프로젝트 관련 링크
+tags: [about]
+sidebar_position: 4
+sidebar_label: 🎗 프로젝트 관련 링크
+keywords: ['팀', '링크']
+pagination_label: Markdown features
+last_update:
+ date: 2024-11-09
+ author: zen
+---
+
+## 🎥 줌 미팅 링크
+
+[https://zoom.us/j/95368420241?pwd=7DYDMGTxbtt3WxtAkOHeJtLMA0qc67.1](https://zoom.us/j/95368420241?pwd=7DYDMGTxbtt3WxtAkOHeJtLMA0qc67.1)
+
+## 🔗 Zep 링크
+
+[네이버부스트캠프 웹 모바일 9기 - Web28 | 쉽고 재미있는 메타버스 ZEP](https://zep.us/play/Gppd67?secret=F4)
+
+## 🔗 공용 깃허브 링크
+
+[https://github.com/boostcampwm-2024/web28-a11yGeolocationService](https://github.com/boostcampwm-2024/web28-a11yGeolocationService)
+
+## 🔗 8기 선배들 작업물 링크
+
+[부스트캠프 웹·모바일 8기](https://github.com/boostcampwm2023)
\ No newline at end of file
diff --git a/docs/docusaurus/docs/about/tags.yml b/docs/docusaurus/docs/about/tags.yml
new file mode 100644
index 00000000..8cc28967
--- /dev/null
+++ b/docs/docusaurus/docs/about/tags.yml
@@ -0,0 +1,4 @@
+about:
+ label: 팀 정보
+ permalink: /about
+ description: 팀에 대한 소개와 정보를 분류한 자료입니다.
\ No newline at end of file
diff --git a/docs/docusaurus/docs/archive/authors.yml b/docs/docusaurus/docs/archive/authors.yml
new file mode 100644
index 00000000..947059c1
--- /dev/null
+++ b/docs/docusaurus/docs/archive/authors.yml
@@ -0,0 +1,33 @@
+zen:
+ name: 임재도
+ title: J210
+ url: https://fantasmith.com
+ image_url: https://github.com/effozen.png
+ socials:
+ x: EffoZen
+ github: effozen
+ linkedin: effozen
+
+leedongyull:
+ name: 이동율
+ title: J174
+ url: https://github.com/leedongyull
+ image_url: https://github.com/leedongyull.png
+ socials:
+ github: leedongyull
+
+juwon5272:
+ name: 김주원
+ title: J060
+ url: https://github.com/juwon5272
+ image_url: https://github.com/juwon5272.png
+ socials:
+ github: juwon5272
+
+happyhyep:
+ name: 정혜인
+ title: J234
+ url: https://github.com/happyhyep
+ image_url: https://github.com/happyhyep.png
+ socials:
+ github: happyhyep
\ No newline at end of file
diff --git a/docs/docusaurus/docs/archive/intro.mdx b/docs/docusaurus/docs/archive/intro.mdx
new file mode 100644
index 00000000..10cd6c61
--- /dev/null
+++ b/docs/docusaurus/docs/archive/intro.mdx
@@ -0,0 +1,15 @@
+---
+slug: intro
+title: 🚪 문서 소개
+sidebar_position: 1
+sidebar_label: 🚪 문서 소개
+keywords: ['members', 'team', '팀원', '소개']
+tags: []
+last_update:
+ date: 2024-11-09
+ authors: [zen]
+---
+
+## 📝 개요
+
+팀이 함께 모여서 한 활동들에 대한 문서를 기록하는 공간입니다.
diff --git a/docs/docusaurus/docs/archive/mentoring/_category_.json b/docs/docusaurus/docs/archive/mentoring/_category_.json
new file mode 100644
index 00000000..860bb28e
--- /dev/null
+++ b/docs/docusaurus/docs/archive/mentoring/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "\uD83D\uDCD3 멘토링일지",
+ "position": 5,
+ "link": {
+ "type": "generated-index",
+ "description": "멘토링 내용 및 이를 통해 성장한 내용을 기록한 문서입니다."
+ }
+}
diff --git a/docs/docusaurus/docs/archive/minutes/20241024-preteam-meeting-log.mdx b/docs/docusaurus/docs/archive/minutes/20241024-preteam-meeting-log.mdx
new file mode 100644
index 00000000..32721954
--- /dev/null
+++ b/docs/docusaurus/docs/archive/minutes/20241024-preteam-meeting-log.mdx
@@ -0,0 +1,264 @@
+---
+slug: 20241024-preteam-meeting-log
+title: 📝 [2024-10-24] 사전 팀 미팅 일지
+sidebar_position: 1
+sidebar_label: 📝 [2024-10-24] 사전 팀 미팅 일지
+keywords: ['회의', '팀미팅', '준비']
+tags: [minutes]
+last_update:
+ date: 2024-10-24
+ authors: [zen]
+---
+
+## 👋 참고 문서
+
+[[👀 사전 팀 미팅 일정 정하기 및 사전 준비 (작성일 : 2024 10 24)|👀 사전 팀 미팅 일정 정하기 및 사전 준비 (작성일 : 2024 10 24)]]
+
+## 👋 렛미인트로듀스
+
+> 우리를 소개해봅시당!
+
+
+- 우리팀 짱짱맨
+- 첫 회의 사진입니다.
+
+## 📝 회의 안건
+
+> 회의 안건에 대해서 자유롭게 적어주세요!
+회의 전에 정리해서 같이 논해봐요!
+
+### 📋 슬랙 메세지 읽었으면 답장 누르기
+
+@Zen :: 이거 좋네요. 개인적으로는 이모지대신 답장이 좋을 듯 합니다. 만약 서로 소통이 늦어지는 게 보이면 통계를 내서, 원인 분석하면, 이 역시도 포폴에서 할말이 많을 것 같아서요!
+
+@동율 이 :: 저도 좋은 방법인 것 같습니다. 아무래도 온라인이다 보니 소통이 더욱 활발하면 좋을 것 같아요!
+
+⇒ 개발자적 표현 쓰면 :: 데이터베이스 쌓아두기. 언젠가는 쓰이겠지. (추적가능성 고려)
+
+### 🚀 팀의 목표에 대한 논의
+
+- 서로에 대한 이야기
+- 각자의 목표
+
+#### 📝 각자의 목표
+
+> 그라운드 룰에 앞서서 여러분들의 이번 미션에서의 목표는 무엇인지 적어주실 수 있나요?
+
+| 이름 | 목표 | 상세 |
+| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| J210 @Zen | 🚀 1. 내가 쓸 수 있는, 내가 겪은 문제를 해결하는 프로그램을 만들고 싶다. 🚀 2. 작은 기능이어도 좋으니까, 이후 확장 및 `유지보수`가 가능하게 제대로 완성도 있게 구현이 되었으면 좋겠다. 🚀 3. 모든 과정이 깃허브에 기록되어 아카이빙 되었으면 좋겠다. ⇒ `포폴`에 쓰고 싶다. 🚀 4. 거창한 기술을 사용하기 보다는 React 등의 기본 기술을 이용해서 UX에 기반한 기술적인 완성도를 높이고 싶다. 🚀 5. 분업이 아닌 협업을 겪어보고 싶다. | 🤔 제가 가진 개발에 대한 가치는 작은 문제라도 괄시하지 않고 기술적으로 해결해보자! 입니다.
또한, 어제 강연에서 연사님들이 “현실적인 문제를 해결한 프로젝트에 눈길이 갔다. 그 외는 자기가 쓰지도 않을 거면서 그냥 있어보이게 만들어서 정말 실망했다.”라는 뉘앙스의 피드백을 주셨습니다.
이에 따라서, 진짜 현실의 문제를 해결할 수 있고, 일단 우리부터 매일 쓸만한 프로그램을 만들고 싶었습니다.
🤔 “기술을 학습하는 데 어려운 건 진짜 큰 의미가 없다고 생각한다. 작은 기술이어도, 그 기술로 어떤 문제를 해결하기 위해 고군분투할 때 그것이야말로 가치가 있다.” 라는 테오님의 말씀이 있었고, 제가 가진 철학과 합치하는 부분이 있었습니다.
프로젝트를 하다보면 기술에 매몰되어서, 정작 중요한 “본질”을 보지 못하는 경우가 많았습니다. 그리고, 보통 이럴 때 스스로도 납득이 안되어서 쉽게 흥미를 잃거나 결과적으로 완성도가 떨어지는 것 같습니다.
프론트엔드 4명이 모였기 때문에, 많은 시도를 할 수 있겠지만, 반대로 4명이 모였기 때문에 리액트만 쓰더라도, 완성도를 극도로 끌어올릴 수 있는 프로젝트를 만들어 볼 수 있겠다는 생각이 듭니다.
🤔 포트폴리오에 쓰고 싶다는 생각이 있습니다.
백이 없다는 것은 반대로 말하면, 프론트엔드 입장에서 백이 완성이 안되었을 때 저희가 서비스를 어떻게 개발해 나갈 수 있는지, 어떻게 데모를 구축할 수 있는지를 잘 보여줄 수 있는 기회라고도 생각합니다.
여러 모킹 방법도 있고.. 무엇이 되었든 프론트 4명이라서 생기는 여러 가지 고민이 있을 것이고, 그걸 정말 좋은 팀원분들과 함께 해결해나가는 게 일상이 되리라고 생각합니다.
포트폴리오를 만들다보면 기록이 부족해서 어려움과 극복 사례가 잘 드러나지 않는 경우가 있는데.. 이번에는 그걸 제대로 기록해서 확실하게 이거 하나만으로도 내세울 수 있는 프로젝트로 만들고 싶습니다.
🤔 즐겁게 하하호호 웃으면서 하고 싶다.
사이드프로젝트를 하다보면, 너무 비즈니스적으로 가는 경우가 있습니다. 그렇게 했을 때, 장기적으로 보면 많이 힘들어지는 것 같습니다.
저희가 고생하면서 달려온 여정의 종지부를 찍는 그룹프로젝트인 만큼, 모두 다 같이 웃으면서 하고 싶습니다. ㅎㅎ.
오프라인이었으면 술 한잔 하면서 대화하면 좋았겠지만.. 온라인인만큼 다른 방면으로 하하호호 하면서 즐겁게 해보고 싶습니다. ㅎㅎ.
🤔 내가 사용할 프로그램을 만들기 위해 온전히 몰입해보고 싶다.
좋은 분을 만나서, 그것도 프론트엔드의 길을 걷는 분들과 만나서 하나의 목표로 달려갈 수 있는 기회는 좀처럼 없다고 생각합니다.
이런 좋은 기회에 반해, 제 능력이 많이 부족하네요.. 여러분들께 누가 되지 않을까 싶습니다.
한편으로는 진짜 제대로 프로젝트를 통해서 실무적으로 성장하고 싶다는 생각도 있습니다.
그래서 온전히 프로젝트에 몰입하는 기간으로 보내고자 합니다. 할 수 있는 역량을 제대로 파악하고, 맡은 역할을 책임지고 수행하면서 점차적으로 스스로 성장을 이루고 싶습니다.
그래서, 저 개인적으로는 6주간 한번 모든 시간을 투자해보고 싶습니다. (순수하게 저 개인에 대한 이야기입니다 ㅎㅎ.) |
+| J060 김주원 | - 처음부터 끝까지 만들어보며 전반에 관한 이해를 높이고 싶다 - `포트폴리오`에 쓸 수 있는 프로젝트를 만들고 싶다 | |
+| J174 이동율 | - 저도 `포트폴리오`에 쓸 수 있는 프로젝트를 만들고 싶습니다. (실 사용자가 있는) - 서비스를 `유지 보수`하는 경험도 해보고 싶습니다. - 기능이 거창하지 않더라도 완성도가 있는 프로젝트였으면 좋겠습니다. | |
+| J234 정혜인 | - 계속해서 `포트폴리오`로 사용할 수 있는 프로젝트 - `적어도 1년 정도`는 계속 배포되어있는 지속 가능한 프로젝트 | |
+
+### 아이디어 노트
+
+#### 📝 아이디어 제안
+
+| 제안자 | 아이디어 | 예상 사용 기술 | 이유 | 추가 피드백 |
+| --- | ---|---| --- |---|
+| @주원 김 | 🗺️ 네이버 지도 개선 - 오늘의 장소 리스트에 오늘 갈 장소들을 담아둔다 - 단톡에 이를 공유하면 약속 일정 공유와 함께 장소를 이동할 때 바로 해당 링크에서 길안내를 시작할 수 있다 - 좋았던 여행 경로 등을 기록해두고 공유할 수 있다
🤔 확장 (1,2월 기간을 활용해서 더 추가해볼만한 사항) 1. 경로추천 - 경로 설정(A,B,C) 3가지 목적지가 있을 경우 A→B→C가 빠른지 B→A→C가 빠른지 등 빠른 경유지 탐색 2. 3D를 사용 - 실내(롯데타워 같은 곳에서는 실내 길안내) 3. AI 사용 - 여행의 경우에 추가할만한 방문지 추천 4. 재도님 프로젝트와의 결합? - 링크에 접속한 사람들의 실시간 위치를 표시(옵션 추가) → 위치의 정확성 높이기 → 어르신 픽업, 흩어져서 놀다가 모이기 등등 | | 이전의 지도는 단톡방에 공유되어있는 장소 정보나 인터넷 검색을 통해 1명이 길찾기를 진행하는 방식으로 진행되어왔다. 따라서 단톡방에 일정을 공유할 때 장소 각각에 대한 링크들을 공유하는 것이 아니라 장소들의 목록을 공유하여 번거로움을 줄이고자 한다. | @Zen Travel이라는 어플이 있어요. 이거 벤치마킹 해봐도 재밌을 것 같음. 실제로 일본 여행 때 요긴하게 썼음. → 구글지도 연동 |
+| @Zen | 🚀 약속 정하기 위해 사용하는 프로그램
[핵심] :: 실시간 위치 추적 - 지도에 실시간으로 각 사용자의 위치를 표시한다. - 이를 보면서 사용자 간의 서로 현재 어느 위치에 있는지 파악한다
[추가 기능] - 실시간 위치 표시를 넘어서 장소에 댓글을 남겨봐도 괜찮을 것 같다. 일종의 추억 저장이라 해야 하나…? 1. WhenToMeet처럼 시간을 타임테이블 형식으로 정할 수 있었으면 좋겠다. 2. 약속 장소를 리스트업하고, 이를 바탕으로 주변 사람들의 위치를 파악할 수 있었으면 좋겠다. 3. 중간 지점이 되는 장소를 자동으로 찾고, 경로를 알려줬으면 좋겠다. (예상 시간까지.) 4. 버스 타는 지점이나 대중교통 타는 지점 등을 알려줬으면 좋겠다. 5. 막차에 대한 정보를 정확하게 제공했으면 좋겠다. 혹은 현재 버스가 어디에 있는지도. | - Geolocation API - 네이버 지도 API - React - React Native | **1. 약속을 정하기 위해서 항상 어려운 것은 다음과 같습니다.** - ㄱ) 공통된 시간을 정하는 문제 - ㄴ) 중간 지점을 찾는 문제
이에 대해서 뭔가 하나로 합쳐진 서비스가 있었으면 했습니다. (당장 저희만 해도 관련해서 정하는데 꽤 오래 걸렸잖아요? ㅎㅎ)
**2. 막차를 제대로 알려주는 서비스가 있었으면 했습니다.**
얼마 전 집 근처 지하철역에서 집까지 막차를 타는데, 버스가 16분 후로 찍혀있는 겁니다. 7 정거장 전이었구요. 그래서 그런가 보다 했는데 10분 딴짓하다 다시 보니 14분입니다… 그래서 아 뭔가 막히는가 보다 했는데.. 20분 더 기다려서 보니 버스가 사라져있습니다… 아놔.. 이러면서 다른 버스 기다리는데 20분 후 그 버스가 다시 나타나고 6분 후가 되었더군요.. 3 정거장 전…
심지어 기다리던 다른 버스에서도 비슷한 문제가 발생했습니다.
결국 밖에서 1시간 10분을 기다린 끝에 탔습니다.
이런 경우 다른 건 모르겠고 실시간 버스 위치만 추적이 되어도 괜찮지 않을까 했습니다.
그리고, 이런 기능은 약속 정할 때 실시간 위치 추적과도 크게 기능상 다르지 않을 것 같아서.. 이 정도만 있어도 `약속 정하기 위한 프로그램`이 아니라 `버스의 위치 추적`만 제공을 해주고, 도메인을 `버스 추적기`라고 해서 개발해도.. 저는 이 프로그램을 사용할 거라고 생각했습니다.
**3. 저희 조부모님의 동네에는 1시간에 버스가 1대 옵니다. 그리고, 정해진 시각에 도착하는 경우가 거의 없습니다. 현재 위치가 어딘지 몰라서.. 조부모님께서는 항상 덥든 춥든 힘든 몸을 이끌고 최소 20분은 대기하십니다..**
버스의 위치만을 알아도 이런 문제가 덜하지 않을까 생각했습니다.
**4. 조부모님께서 열차로 올라오실 때 서울 지리가 익숙치 않아서 길을 자주 헤매십니다.. 저희가 마중 가도 위치 파악이 안 되어 헤매는 경우가 많습니다.**
이 경우 실시간 위치만 제대로 보여줘도, 그 위치로 저희가 가면 되니까 얼마나 좋을까? 하는 생각이 있었습니다.
**5. 약속 때에도 항상 길이 엇갈리는 경우가 생깁니다.** 그런 경우에도 이런 서비스가 있었으면 좋겠다고 생각합니다.
**6. 위치 서비스를 쓰면 차는 몰라도 도보는 현재 내 위치가 제대로 파악이 안 되는 경우가 많습니다. 이걸 프론트엔드의 기술을 써서 해결해보면 어떨까 했습니다.** | @혜인 정 부산에서 카카오는 시범 운행하고 있다. 현재 버스 위치를 실시간으로 보여준다.
이미 있는 서비스를 클론 코딩 하는 것도 좋지만, 개선하거나 새롭게 했으면 좋겠다.
개발 말고 기획 단계에서 생각해야 하는 부분이 많을 것 같다.
API도 없을 것이다.
시간이 부족할 것 같다.
@혜인 정 위치를 공유하면서, 카메라로 실시간 위치를 보여주면 좋을 것 같다는 생각이 들었다.
밤에 그런 의도로 활용해도 좋을 것 같다는 생각이 들었다.
위험한 상황이 생기면 경찰에 전화에서 톡톡 같은 번호 2번 누르면 크롬 화면으로 넘어가고, 현재 상황을 보여줄 수 있게 되어 있다.
카메라도 보이고, 위치 서비스도 제공하면서, 경찰에 보내는 건 조금 부담스럽다. 이런 느낌일 때 사용하면 좋을 것 같다.
계속 브레인스토밍하는 것이다.
@동율 이 https://kakaomap.tistory.com/281 요거 이용하면 도착지까지 친구들의 위치와 예상 시간도 알 수 있어요! 저도 최근에 알게 돼서 공유드립니다 |
+| @혜인 정 | 🚗 초보자를 위한 운전 연수 웹
네이버 지도의 네비게이션처럼 길을 알려주지만, 현재 위치를 기반으로 해서 유턴을 해야 할 때는 핸들을 꺾는 각도를 함께 보여준다거나, 구간 단속이나 비보호 좌회전, 유턴 신호 등 간단하지만 처음에는 헷갈릴 수 있는 규범이 나왔을 때 어떤 용도(?)인지를 목소리로 알려주는 웹앱 | | 부모님이 멀리 계시거나 연수는 비싸서 많이 할 수 없는 경우에는 면허증이 있어도 운전을 시작할 엄두가 안 나는 초보자들을 위해… | @혜인 정 개발이 아니라 기획 단계에서 할 게 많아서 제외시키면 좋을 것 같았다. |
+| @혜인 정 | 🧭 위치 기반 날씨 시각화 웹 (백엔드 필요 없을 듯)
사용자의 현재 위치와 날씨 정보를 통해 구름, 비, 눈 등의 날씨 요소를 three.js를 통해 3D로 표현해주는 웹 (추가로 인구 밀도, 교통량, 미세먼지 등도 표현하면 괜찮을듯) | WebGL, Three.js |백엔드 기술이 최대한 들어가지 않는 웹을 생각해보다…….|@혜인 정 백앤드 필요없는 프로젝트가 제일 베스트가 아닐까? 하는 생각에서 아이디어가 시작되었다.
현재 위치를 통해서 지도를 보여주는 것이다. 그 지도에 날씨 요소를 넣는 것이다.
인구밀도 교통량, 미세먼지 등을 표시해주는 것.
현재 위치를 기반으로 하면, 다른 여행지를 갈 때 날씨를 볼 텐데, 다른 지역을 볼 때가 더 효율적이지 않을까 하는 생각이 들고..
뭔가 근거가 충분하지 않은것 같다. 조금더 생각해보면 좋을 것 같다. |
+| @혜인 정 | 🚲 여행 기록 3d animation 웹 내가 여태껏 다닌 여행지를 애니메이션 형태 (인스타 등에 자랑?할 수 있는 형태)의 영상으로 추출해주는 웹 개인적으로 ‘내트리에놀러와’ 같이 그 영상을 서로 공유하는 웹사이트로 만들어도 재밌을 듯 아래 링크 참고 https://mult.dev/studio | | 제가 여행을 정말 좋아해서 기록하고 SNS에 공유하는 것을 좋아하는 편인데, 예쁜 애니메이션 형태로 공유할 수 있는 웹사이트가 있으면 좋겠다고 생각하였습니다. (다만 급하게 생각해낸 거기도 하고 현재 실시간 위치를 반영하는 웹은 아니라서, 더 고민해봐야할듯…) | @혜인 정 Three.js를 쓸 수 있는 방법을 생각했다. 인스타용으로 많이 쓸 수 있을 것 같았다. 한국인 환경에 맞는 느낌, UI/UX가 별로라서 만들고 싶었다. @주원 김 카카오 API나 여러가지로 받아오고, 여행을 한다음 Three.js 와 같은 애니메이션으로 경로를 바꿔서 보여주면 좋을 것 같다. 네이버API, 카카오API와 합쳐도 재밌을 것 같다는 생각이 들었다. @혜인 정 이미지를 넣으면 이미지에 위치 정보가 담겨 있으니까, 그 정보를 이용해서 경로를 보여주는 것도 좋을 것도 좋을 것 같다. |
+| @혜인 정 | 크리스마스 특집 이건 진짜 아이디어가 아니고 브레인 스토밍 용인데, 12월 딱 프로젝트 마무리 할 때 쯔음 되면 크리스마스일테니, 내 트리에 놀러와 같은 크리스마스 용 웹사이트를 만들어도 재밌을 듯 | | | @혜인 정 뭔지 생각 안하고 만든 것. 크리스마스 용도로 산타에게 선물을 보낸다거나.. FE만 사용해도 쓸 수 있는 그런걸 만들고 싶었다. |
+| @동율 이 | 여행 도감 이미 해봤던 아이디어긴 하지만 매우 미약하고 퀄리티가 떨어져서 다시 디벨롭 해보고 싶은 생각이 있습니다! 기능은 각 도시들 마다 유명한 관광지들을 도감에 비활성화 상태로 넣어두고 실제 그 관광지에 들어간 뒤 5분이 지나면 도감에 사진과 글을 등록할 수 있도록 합니다! 그 이후 각 도시들마다 진행도를 넣고, 등록한 관광지의 수 만큼 경험치를 얻거나 크레딧을 얻는 방식입니다! 이를 three.js를 사용해서 멋지게 만들어 보거나 혜인님 아이디어와 결합해도 재밌을 것 같아요!! 추가적으로는 등록을 위한 여행 루트도 짜주는 시스템도 들어가면 좋을 것 같아요! 시간이 모자라서 구현을 못했던 기능입니다 | | 주제가 공익적이거나 전국적인 사회 문제를 해결할 수 있는 앱이었고, 현재 우리나라는 수도권 집중화가 과도하게 되어있어, 이를 해결하기 위한 앱이었습니다. 아무래도 기업을 옮기거나 인프라를 늘리는 방법은 저희가 할 수 없기 때문에, 여행을 통한 유동 인구를 늘려 지역 경제를 활성화 시키자는 아이디어로 시작했습니다 비인기 도시일수록 크레딧을 많이 주는 방식으로 하면 좋은 방향이 될 수 있을 것 같아요 | @동율 이 예전에 썼던 건데, 2학년때 만든것. 퀄리티가 굉장히 떨어짐. 관광지들을 많이 알려서, 유동인구를 늘려서 해결하면 되겠다. 하는 아이디어에서 출발. 각각 도감이 있다. 직접 그곳으로 가서 실시간으로 위치를 감지를 해서 반경 몇 미터 이내에 들어가면 활성화가 되고, 사진이랑 글을 넣을 수 있도록 해두었다. 사람들이 많이 안가는 곳일수록 경험치를 많이 주도록 유도를 하고자 했다. 수익성도 고려를 했어야 했다. 아직 등록이 안된 부분은 어떻게 하면 더 재밌게 즐길 수 있을 지 플랜도 짤 수 있게 하면 재밌겠다 생각을 했다. 여행 도감이라는 아이디어가 괜찮은 것 같다. 그 지역들에 대한 관광지 소개가 괜찮은 것 같다. 이걸 디벨롭 시켜보고자 하는 마음이 있었다. |
+| @Zen | 현실 메세지 | | | @동율 이 재밌을것같아요! |
+
+## 📋 공통의 내용
+
+### 1. 포폴에 쓰는 경험
+
+- 포폴에 쓰는 걸로 그치지 않고, 개선 및 사용하는 것에 대한 생각
+- 실사용자가 있었으면 좋겠다.
+
+### 2. 유지보수
+
+- 적어도 1년은 썼으면 좋겠다.
+
+@혜인 정 :: 실 사용자가 있는, 내가 쓸 것 같은 프로그램을 만들 거면 단순히 재미만을 위해서 만드는 것도 괜찮을 수 있다. 이미 문제를 해결하기 위한 것은 이미 다 있다. 그렇다고 하면, 써보면 좋을 것 같다는 생각이 들어왔다. 내트리를 들어와 라는 것을 보면서 사이드프로젝트이면서 정말 많은 사용자가 들어올 수 있는 서비스라는 생각이 들더라.
+
+@동율 이 :: 대회를 2번 나갔다. 그 대회가 다 똑같은 대회인데, 사회적 문제를 해결하는 대회였다. 사회적인 문제나 공익적인 문제를 생각하면 애초에 사용을 하기가 쉽지 않다. 서비스를 한다고 하면 수익성이 없는 것도 있지만, 문제를 해결하면서 수익을 얻기도 굉장히 까다롭다. 어떤 문제를 해결한다는 것은 당연히 좋지만, 엄청난 아이디어가 있지 않는 이상은 쉽지 않을 수 있다. 그래서 혜인님과 비슷한 생각이다.
+
+@주원 김 :: 문제를 해결하려고 해결방안에 몰두하는 일이 많을 수 있다. 이미 다 필요하다고 생각했던 것이고, 누구나 다 생각할 수 있는 것이니까. 우리가 생각하는 범위 내에서 불편한 점이 있을 수 있기 때문에 거기에서 한번 주제를 던져보고, 안되면 재미를 위해서 기술에만 집중할 수 있는 것을 다음으로 선택해보면 어떨까 생각해보고 있다.
+
+- 어느 정도 기술적 역량이 있는가
+- 어떤 경력이 있는가
+
+@Zen :: 서로의 기술적 역량을 미리 공유했으면 좋겠습니다.
+
+### 팀원의 목표에 대한 이야기
+
+@주원 김 리액트를 이용하여 개발하는 법을 알고 해당 프로젝트를 왜 이렇게 만들었고 어떤 개선점들이 있었는지 설명할 수 있게 되는 성장을 하고 싶습니다 → 단순히 만드는 것이 아니라 꾸준히 개선이 필요하다고 생각합니다.
+
+@주원 김 우선은 취업이 목적이다 보니, 포폴에 들어갈 수 있는 프로젝트를 만드는 게 목표인 거 같습니다. 특히 제가 로봇 관련 전공이다 보니 위치 기반에 대해 관심을 많이 가지고 있는데 정말 이 방향이 맞는지 점검하고 기반이 되는 프로젝트를 만들기 그리고 단순 구현이 아니라 왜?를 알고 개발하기입니다.
+
+### 완성도 있는 프로젝트란 무엇인가에 대한 논의
+
+@혜인 정 :: 코드적으로 완성도가 있는지, 코드는 좀 더럽더라도 서비스적으로 완성도가 되었는지… → 사용자가 보기에 제대로 돌아가는 게 먼저이다., 코드적으로 완성도를 높이는 게 목표이다.
+
+@주원 김 :: 6주는 프로젝트 완성이라는 기간, 완벽한 기능을 하게 만들어놓고, 이후 기간에 리팩토링을 했으면 좋겠다. 스스로 불만족하는 그런 코드를 개선하는 시간을 갖는 방향이 좋지 않을까 생각 중.
+
+@동율 이 :: 실사용자가 있어야 하고, 유지보수를 1년은 했으면 좋겠다. → 서비스 완성이 되어야 한다. 기간도 짧고.
+
+- 공통의 목표에 대한 논의
+- 팀원 개개인의 목표에서 공통의 목표 추리기
+ - 공통의 목표는 각자 작성해온 목표에 도움이 되어야 한다.
+ - 공통의 목표는 팀의 의사결정에 기반이 되어야 한다.
+
+### 공통의 목표를 바탕으로 행동 규칙에 대해 논의하기
+
+@Zen :: 이에 대해서는 팀의 문화에 대한 이야기에서 논의해봐도 좋을 것 같습니다.
+
+## 🚀 팀의 문화에 대한 논의
+
+### 우리는 어떤 팀이 될 것인가?
+
+@Zen :: 온라인이지만, 의사소통이 원활하고 활발하게 이루어졌으면 좋겠습니다. 코어 시간에라도 서로가 무언가를 물어보면 빠른 피드백이 올 수 있었으면 좋겠습니다.
+
+슬랙의 경우 작업하다보면 슬랙 스스로 알림을 끄는 경우가 있어서, `Zep`, `게더타운` 등으로 각자 일하더라도 캐릭터가 찾아가서 말 걸 수 있는 그런 환경이었으면 좋겠습니다. 그리고 코어시간 외나, 하루에 주어진 할당을 빨리 끝냈더라도 팀에 서로서로 무언가 더 기여하고자 하는 팀이었으면 좋겠습니다.
+
+@혜인 정 :: 서로 친하고 편한 분위기면 좋겠습니다! 그리고 효율적인 팀이었으면 해요! 완전 노는 목적(?)이면 상관없는데, 불필요하게 회의를 길게 하고 그런 건 정말 비효율적이라고 생각합니다 ….. 개인적으로 회의 길게 하는 팀은 다 산으로 가고 작업률은 떨어지고 팀에 대한 집중은 깨지게 되더라고요 ….. 놀 땐 놀고, 할 땐 하는 팀이었으면 좋겠습니다!
+
+@주원 김 :: 우선 분위기는 최대한 좋게 가져가기 위해서 스몰톡도 하는 팀이었으면 좋겠습니다. 네부캠 마지막 코스인 만큼 마지막까지 불태울 수 있도록 서로 동기부여할 수 있는 팀이 되고 싶습니다.
+
+@동율 이 :: 제 생각에도 아무래도 친해질수록 말도 많이 하게 되고 소통도 원활하게 될 것 같아서 화목한 팀이 되었으면 좋겠습니다.
+
+⇒ 베타테스트 해보고 별로면 다른 걸 찾아보자. → “서로 실시간으로 편하게 소통할 수 있는 창구이자 장치를 뒀으면 좋겠다.” || “보이스로”
+
+### 코어시간 활동 규칙 정하기
+
+- 코어시간과 주어진 시간을 어떻게 활용할 것인가?
+
+@Zen :: 개인적으로 코어 시간 내에 `게더타운`이나 `Zep`을 이용해서 항상 화면공유하고 있었으면 좋겠습니다.
+
+온라인으로 비동기적 소통을 하더라도, 실제 오프라인처럼 팀원의 위치로 가서 대화를 할 수 있고, 자유롭게 소통이 되었으면 합니다.
+
+@혜인 정 :: 저는 개인적으로 휴식과 일/공부 등이 제대로 분리되어야 더 빠르고 확실하게 작업을 할 수 있는 편이라, 최대한 코어타임 내에 모든 걸 효율적으로 진행하고 코어타임 외에는 작업을 진행하지 않았으면 좋겠습니다! 물론 본인이 맡은 작업이나 정말 필요한 경우는 당연히 해야겠지만, 장기적으로 달리는 프로젝트이기 때문에 과하게 하는 것보다는 멀리 보고 마라톤 경주를 할 수 있으면 좋겠어요! (부캠하면서 건강 해치시는 분들 너무 많이 봐서 항상 모두의 건강과 컨디션이 우선이라 생각합니다!)
+
+@주원 김 :: 제가 부족함이 좀 큰 것 같아서 이번 기간에 좀 빠짝 해보고 싶어요ㅎㅎ 코어타임에는 줌이나 허들에 접속해있고 코어타임 외에는 자유롭게 개발을 하거나 쉬거나 하는 식으로 활용해도 좋을 것 같습니다.
+
+@동율 이 :: 그룹 프로젝트이기도 하고 마무리 프로젝트인 만큼 코어 타임을 지키는 게 좋을 것 같습니다! 개인적으로는 캠보다는 허들이 더 좋을 것 같네요! 재도님 말처럼 게더타운이나 Zep을 활용하는 방법도 좋을 것 같습니다.
+
+@Zen :: 개인적으로 코어 시간 내에 `게더타운`이나 `Zep`을 이용해서 항상 화면공유하고 있었으면 좋겠습니다. 온라인으로 비동기적 소통을 하더라도, 실제 오프라인처럼 팀원의 위치로 가서 대화를 할 수 있고, 자유롭게 소통이 되었으면 합니다.
+
+@혜인 정 :: 저는 개인적으로 휴식과 일/공부 등이 제대로 분리되어야 더 빠르고 확실하게 작업을 할 수 있는 편이라, 최대한 코어타임 내에 모든 걸 효율적으로 진행하고 코어타임 외에는 작업을 진행하지 않았으면 좋겠습니다! 물론 본인이 맡은 작업이나 정말 필요한 경우는 당연히 해야겠지만, 장기적으로 달리는 프로젝트이기 때문에 과하게 하는 것보다는 멀리 보고 마라톤 경주를 할 수 있으면 좋겠어요! (부캠하면서 건강 해치시는 분들 너무 많이 봐서 항상 모두의 건강과 컨디션이 우선이라 생각합니다…!)
+
+@주원 김 :: 제가 부족함이 좀 큰 것 같아서 이번 기간에 좀 빠짝 해보고 싶어요ㅎㅎ 코어타임에는 줌이나 허들에 접속해있고 코어타임 외에는 자유롭게 개발을 하거나 쉬거나 하는 식으로 활용해도 좋을 것 같습니다.
+
+@동율 이 :: 그룹 프로젝트이기도 하고 마무리 프로젝트인 만큼 코어 타임을 지키는 게 좋을 것 같습니다! 개인적으로는 캠보다는 허들이 더 좋을 것 같네요! 재도님 말처럼 게더타운이나 Zep을 활용하는 방법도 좋을 것 같습니다.
+
+### 기록은 어떻게 할지 정하기
+
+@Zen :: 노션은 지금처럼 실시간으로 함께 정리하는 용도로 쓰고, 이에 대한 요소도 이후 깃허브에 모두 올렸으면 좋겠습니다. 회의록 항목 따로, 이슈가 발생하면 깃허브 이슈로 작성하고, 항상 어떤 제안을 하기 전에 깃허브 이슈 문서로 정리하고 이야기를 하면 좀 더 효율적인 커뮤니케이션이 되지 않을까 싶었습니다.
+
+트러블 슈팅도 그렇고, 발견한 문제, 배운 기술 등등 모두 깃허브의 기능을 제대로 활용해봤으면 합니다. ⇒ 포폴 때 노션 링크에 들어가는 것조차 비용이라는 말을 들었고 깃허브를 굉장히 잘 쓴 게 보이면 그것 자체로도 이미 +일 것 같기 때문입니다.
+
+### 의사결정 방식 정하기
+
+@Zen :: 의사결정을 어떻게 할지도 굉장히 중요한 문제 같습니다. 개인적인 제안 사항은, 깃허브 이슈에 문제를 먼저 정리하고 그에 대한 근거를 마련해옵니다. 그리고, 그에 대한 논의를 이해관계자가 하는 것이 아닌 팀 전체가 매번 나누었으면 좋겠습니다.
+
+4FE인 만큼, 모든 이슈와 기술 내용이 공유되어도 좋다고 생각하기 때문입니다. (저희가 같은 도메인인 만큼 언젠가는 만날 문제일 테니까요!)
+
+@동율 이 :: 모르는 부분이 생기면 바로바로 이야기하면 좋을 것 같아요! (제가 모르는 게 굉장히 많아서 ㅎㅎ)
+
+@주원 김 :: 매일 아침 데일리 스크럼에서 토의가 필요하지 않을까 생각합니다.
+
+→ 깃허브 Issue에 자유롭게 남기기. ⇒ 좋은 것, 나쁜 것, 트러블 슈팅 등등 전부 기록.
+
+→ 데일리 스크럼 때 길게 잡아서 자유롭게 이야기.
+
+→ 급하면 Zep에서 사람을 불러서 하기.
+
+### 코드리뷰 및 PR 규칙 정하기
+
+@Zen :: 4FE인 만큼 저희 모두가 서로의 기술을 자세히 알면 좋지 않을까 하는 생각이 있습니다. 동료의 코드를 리뷰해주는 것과 더불어서, 이런 기술에 이렇게 쓰이고 있구나 하는 걸 이해하면 좋을 것 같다는 생각입니다. 이런 맥락에서 코드리뷰를 매일 해도 좋지 않을까 하는 생각이 있습니다. 모두 FE인 만큼, 서로의 코드에 담긴 기술적인 내용에 대한 백그라운드가 같으므로, 매일 하는 코드리뷰는 서로에게 큰 도움이 될 거라고 생각하기 때문입니다.
+
+진행 상황 파악도 그렇고, 맥락에 대한 파악도 그렇고, 문서화도 그렇고 여러 가지로 온라인이기에 발생할 수 있는 여러 커뮤니케이션 문제를 해결할 수 있는 장치가 될 수 있지 않을까 했습니다.
+
+@Zen :: PR에 대해서 4명 다 Approve 해야 올라갈 수 있게 하면 어떨까 하는 생각을 해보았습니다. PR도 지금까지와 달리 작은 기능 단위로 올라올 텐데, 4FE인 만큼, 이를 제대로 파악만 해둬도, 서로에 대한 기술적인 이해에 대한 갭이 줄어들 거라고 생각하기 때문입니다. (품이 많이 든다를 제외하면, 제 개인적인 생각에서는 단점이 크게 보이지 않는 것 같다는 생각이 있는데… 언제나 그렇듯 그 품이 많이 드는 게 문제이지만요 하하!)
+
+@주원 김 :: 비슷한 작업을 하고 있는 페어를 정해서 리뷰어를 정해봐도 좋을 것 같습니다 → 코드리뷰보다는 PR 리뷰면 좋을 것 같다. 코드 하나하나 보지 말고 이렇게 하는 게 어떨까. 방향성만 한번씩 보는. 코드 설명을 간략하게 하는 시간도…
+
+@혜인 정 :: 데일리 스크럼에서 활용해보면 어떨까? 이 코드가 괜찮아야…
+
+@Zen :: 공통된 규칙을 잡아갈 것. → 코드 스타일 가이드, TS ⇒ 타입 정할 것. 그리고 몇 가지 코드 쓸 때 공통적으로 통일해야 하는 부분 || 어긋나는지 안 어긋나는지. ⇒ 코드 리뷰하고, 데일리 스크럼에서… 어느 정도에서 스크럼.
+
+### 서로에 대한 작업 공유
+
+@Zen :: 저는 매일 코드리뷰와 4명 모두 PR Approve가 어느 정도 작업 공유에 대한 장치가 된다고 생각합니다. 이에 더해서, 하루에 작업 상황에 대한 요소를 기록하는 부분을 따로 빼서, 모았으면 합니다. (하루마다 스스로 평가해서 올리는 것이죠. 무엇을 했다, 무엇을 하고 있다, 어디서 문제가 발생했다 등…) ⇒ 개발자로서 탐구하는 자세도 중요하지만, 마감을 지키는 게 더욱 중요하다고 생각합니다. 6주간 프로젝트이고, 4FE인 만큼 매일마다 공유하고 서로가 한 일을 서로가 매일 상세히 이해하는 게 나쁠 게 없다고 생각합니다.
+
+@혜인 정 :: 노션 등과 같은 툴을 이용해서 일감 관리를 하면 어떨까 싶습니다! 인턴할 때는 먼데이라는 일감 관리 앱을 써본 적이 있는데, 팀 단위 작업을 할 때 일감 관리 플랫폼을 이용해서 관리하면 정말 편하고 서로 좋더라고요!
+
+@주원 김 :: 7시에 끝나기 전에 허들로 간략히 얘기 나눠봐도 좋을 것 같습니다. 그리고 노션에도 간략히 기록해둔다면 쉽게 찾아볼 수 있을 것 같아요.
+
+@Zen :: 매일마다 코어시간 전에 하루에 대한 상황을 아주 짧게 요약해서 말해보는 것도 좋은 것 같아요. 실제로 지난 스터디그룹 때 해봤는데, 비용은 적게 드는 반면 얻는 효과는 굉장히 컸던 기억이 있어요! 단, 이게 PR 리뷰와 코드리뷰라는 측면에서 겹칠 수가 있어서 이것도 논의해보면 좋을 것 같아요!
+
+### 회고 방식에 대한 생각
+
+@Zen :: 현업에 있는 친구들과 회고를 하고 있는데, 생각보다 피그마를 활용한 회고가 좋은 것 같더라구요. 수료생 분이 하신 이야기와도 같은 방식인데, 이에 대해서는 이따 회의 때 이야기 드리겠습니다.
+
+@주원 김 :: 회고는 아직 잘 모르겠네요… 생각한 것은 각자 작성하는 것과 금요일에 회고 시간을 갖자 정도인 것 같습니다.
+
+→ KPT ⇒ 쁘띠쁘띠…
+
+→ F4
+
+- 깃허브 파야함. 리포지토리.
+ - 네부캠에서 파주나요…? 거기 아래에서 우리끼리 하는것…?
+ - 팀명은 생각해보는걸로….
+
+## 카드
+
+- 휴식! 카드
+- 나 힘들다 카드 → 😴🥱 → 무제한
+- 나 말좀 하게 해줘 카드 → ✋ → 무제한
+- 스탑! 거기까지만… 너무깊게 가지마.. 카드 → 각자 PR에 남기기…
+- 2장씩 → 내 말 무조건 들어줘 || 의사결정할때.
+ - 조건! 2:2 갈릴 경우만..
+ - 기본적으로는 다수결…
+ - 모두가 납득은 했을 떄
+ - 상식적인 선에서
+- 2장씩 → 반차 (건강 때문에)
+ - 최소한의 할일은 끝내자.
+ - 마지막 바쁠땐 안됨.
+
+---
+
+## 🚀 그라운드 룰
+
+### 📝 추구하는 가치 - 목표
+
+- 포트폴리오 → 할말이 있어야 한다.
+ - 4FE :: 서로가 한 개발 내용은 자기가 개발하진 않더라도 다 이해했으면 좋겠다.
+- 실사용자가 있었으면 좋겠다.
+- 적어도 1년은 썼으면 좋겠다.
+
+- 단순히 자기만족 프로젝트라기 보다는 프로젝트 그 자체가 가치가 있었으면 좋겠다. 그게 재미든, 뭔가 사회적 문제 해결이든, 우리가 장난식으로 쓰든(재미), 그냥 사용할만한 확실한 이유가 있었으면 좋겠다.
+
+### 📝 완성도
+
+- @혜인 정 :: 서비스는 사용자 기준으로 맞춰서 완성이 되어야 한다.
+- @동율 이 :: UX를 신경써서 서비스를 해보면 좋을 것 같다.
+- @주원 김 :: 가이드 → 만들어도 좋을 것 같다.
+- @Zen :: UI/UX 사용자 중심으로
+
+- UI/UX 사용자 중심으로 생각한다.
+ - 코드리뷰 경우도, 코드 자체의 품질이런것도 좋지만, 사용자경험에서의 코드리뷰
+
+### 📝 어떤 문화를 갖출 것인가?
+
+---
+
+1. 지금 한 내용 정리하기
+2. 멘토님 발표나면 바로 초대
+3. Zep이든 게더타운이든 하나 파서 공유
+ - 찜질방 넣기
+4. 월요일 :: 아이디어 생각해보기 → 아이디어 :: 만약에 올리시면 슬랙에 올렸다고 이야기…
+5. 멘토님께 누가 될 수 있으니까, 우리끼리 소통할 수 있는 창구를 만들어볼까요?
+ - 그냥 있는곳 쓰죠.
+
+- 10시 7시 코어타임만큼은 집중하고 그 이외에는 자율 → 마지막이나 스프린트 다가오면 그때 결정하고, 일단은…
+ - 점심도 알아서 먹되, 쉬겠다는 룸으로 가면 적당히.. 눈치껏 ^^
+- 아이디어 가져올때, 어느정도 좀 구현가능한 기술같은거 근거를 확실히 마련해옵시다.
\ No newline at end of file
diff --git a/docs/docusaurus/docs/archive/minutes/20241028-teambuilding.mdx b/docs/docusaurus/docs/archive/minutes/20241028-teambuilding.mdx
new file mode 100644
index 00000000..bc2ead20
--- /dev/null
+++ b/docs/docusaurus/docs/archive/minutes/20241028-teambuilding.mdx
@@ -0,0 +1,181 @@
+---
+slug: 20241028-teambuilding
+title: 📝 [2024-10-28] 팀빌딩 회의
+sidebar_position: 2
+sidebar_label: 📝 [2024-10-28] 팀빌딩 회의
+keywords: ['회의', '팀빌딩']
+tags: [minutes]
+last_update:
+ date: 2024-10-28
+ authors: [zen]
+---
+
+## 📚 참고자료
+
+[팀빌딩 사전 준비](./20241024-preteam-meeting-log.mdx)
+
+## 📝 회의 안건
+
+> 회의 안건을 자유롭게 적어주세요.
+
+### 📝 팀 운영 관련
+
+#### 🚀 크레딧은 어느 계정에 받을 것인가?
+
+@Zen 계정에 받는걸로
+
+- 이유:
+- 새로 개설되는 계정이다. (조건에 부합)
+- 신속한 행정 처리
+
+@주원 김 :: 주제 먼저 이야기하고 → 바로 정해지지 않을 테니 머리 식힐 겸 컨벤션 이야기 → 다시 주제 이야기
+
+@동율 이 :: 이 시간이 그라운드룰이나 리포를 파는 시간으로 알고 있어서 컨벤션부터 이야기해도…?
+
+@Zen :: 주제이야기하다가 → 쉬는 시간 나오면 쉬고 → 컨벤션 이야기 → 쉬고 → 주제
+
+### 📝 주제
+
+> 어떤 아이디어로 끌고 나갈 것인가?
+
+| 제안자 | 아이디어 | 예상 사용 기술 | 이유 | 추가 피드백 |
+| --- | --- | --- | --- | --- |
+| @주원 김 | 🗺️ 네이버 지도 개선 - 오늘의 장소 리스트에 오늘 갈 장소들을 담아둔다 - 단톡에 이를 공유하면 약속 일정 공유와 함께 장소를 이동할 때 바로 해당 링크에서 길안내를 시작할 수 있다 - 좋았던 여행 경로 등을 기록해두고 공유할 수 있다
🤔 확장 (1,2월 기간을 활용해서 더 추가해볼만한 사항) 1. 경로추천 - 경로 설정(A,B,C) 3가지 목적지가 있을 경우 A→B→C가 빠른지 B→A→C가 빠른지 등 빠른 경유지 탐색 2. 3D를 사용 - 실내(롯데타워 같은 곳에서는 실내 길안내) 3. AI 사용 - 여행의 경우에 추가할만한 방문지 추천 4. 재도님 프로젝트와의 결합? - 링크에 접속한 사람들의 실시간 위치를 표시(옵션 추가) → 위치의 정확성 높이기 → 어르신 픽업, 흩어져서 놀다가 모이기 등등 | | 이전의 지도는 단톡방에 공유되어있는 장소 정보나 인터넷 검색을 통해 1명이 길찾기를 진행하는 방식으로 진행되어왔다. 따라서 단톡방에 일정을 공유할 때 장소 각각에 대한 링크들을 공유하는 것이 아니라 장소들의 목록을 공유하여 번거로움을 줄이고자 한다. | @Zen Travel이라는 어플이 있어요. 이거 벤치마킹 해봐도 재밌을 것 같음. 실제로 일본 여행 때 요긴하게 썼음. → 구글지도 연동 |
+| @Zen | 🚀 약속 정하기 위해 사용하는 프로그램
[핵심] :: 실시간 위치 추적 - 지도에 실시간으로 각 사용자의 위치를 표시한다. - 이를 보면서 사용자 간의 서로 현재 어느 위치에 있는지 파악한다.
[추가 기능] - 실시간 위치 표시를 넘어서 장소에 댓글을 남겨봐도 괜찮을 것 같다. 일종의 추억 저장이라 해야 하나…? 1. WhenToMeet처럼 시간을 타임테이블 형식으로 정할 수 있었으면 좋겠다. 2. 약속 장소를 리스트업하고, 이를 바탕으로 주변 사람들의 위치를 파악할 수 있었으면 좋겠다. 3. 중간 지점이 되는 장소를 자동으로 찾고, 경로를 알려줬으면 좋겠다. (예상 시간까지.) 4. 버스 타는 지점이나 대중교통 타는 지점 등을 알려줬으면 좋겠다. 5. 막차에 대한 정보를 정확하게 제공했으면 좋겠다. 혹은 현재 버스가 어디에 있는지도. | - Geolocation API - 네이버 지도 API - React - React Native | **1. 약속을 정하기 위해서 항상 어려운 것은 다음과 같습니다.** - ㄱ) 공통된 시간을 정하는 문제 - ㄴ) 중간 지점을 찾는 문제
이에 대해서 뭔가 하나로 합쳐진 서비스가 있었으면 했습니다. (당장 저희만 해도 관련해서 정하는데 꽤 오래 걸렸잖아요? ㅎㅎ)
**2. 막차를 제대로 알려주는 서비스가 있었으면 했습니다.**
얼마 전 집 근처 지하철역에서 집까지 막차를 타는데, 버스가 16분 후로 찍혀있는 겁니다. 7 정거장 전이었구요. 그래서 그런가 보다 했는데 10분 딴짓하다 다시 보니 14분입니다… 그래서 아 뭔가 막히는가 보다 했는데.. 20분 더 기다려서 보니 버스가 사라져있습니다… 아놔.. 이러면서 다른 버스 기다리는데 20분 후 그 버스가 다시 나타나고 6분 후가 되었더군요.. 3 정거장 전…
심지어 기다리던 다른 버스에서도 비슷한 문제가 발생했습니다.
결국 밖에서 1시간 10분을 기다린 끝에 탔습니다.
이런 경우 다른 건 모르겠고 실시간 버스 위치만 추적이 되어도 괜찮지 않을까 했습니다.
그리고, 이런 기능은 약속 정할 때 실시간 위치 추적과도 크게 기능상 다르지 않을 것 같아서.. 이 정도만 있어도 `약속 정하기 위한 프로그램`이 아니라 `버스의 위치 추적`만 제공을 해주고, 도메인을 `버스 추적기`라고 해서 개발해도.. 저는 이 프로그램을 사용할 거라고 생각했습니다.
**3. 저희 조부모님의 동네에는 1시간에 버스가 1대 옵니다. 그리고, 정해진 시각에 도착하는 경우가 거의 없습니다. 현재 위치가 어딘지 몰라서.. 조부모님께서는 항상 덥든 춥든 힘든 몸을 이끌고 최소 20분은 대기하십니다..**
버스의 위치만을 알아도 이런 문제가 덜하지 않을까 생각했습니다.
**4. 조부모님께서 열차로 올라오실 때 서울 지리가 익숙치 않아서 길을 자주 헤매십니다.. 저희가 마중 가도 위치 파악이 안 되어 헤매는 경우가 많습니다.**
이 경우 실시간 위치만 제대로 보여줘도, 그 위치로 저희가 가면 되니까 얼마나 좋을까? 하는 생각이 있었습니다.
**5. 약속 때에도 항상 길이 엇갈리는 경우가 생깁니다.** 그런 경우에도 이런 서비스가 있었으면 좋겠다고 생각합니다.
**6. 위치 서비스를 쓰면 차는 몰라도 도보는 현재 내 위치가 제대로 파악이 안 되는 경우가 많습니다. 이걸 프론트엔드의 기술을 써서 해결해보면 어떨까 했습니다.** | @혜인 정 부산에서 카카오는 시범 운행하고 있다. 현재 버스 위치를 실시간으로 보여준다.
이미 있는 서비스를 클론 코딩 하는 것도 좋지만, 개선하거나 새롭게 했으면 좋겠다.
개발 말고 기획 단계에서 생각해야 하는 부분이 많을 것 같다.
API도 없을 것이다.
시간이 부족할 것 같다.
@혜인 정 위치를 공유하면서, 카메라로 실시간 위치를 보여주면 좋을 것 같다는 생각이 들었다.
밤에 그런 의도로 활용해도 좋을 것 같다는 생각이 들었다.
위험한 상황이 생기면 경찰에 전화에서 톡톡 같은 번호 2번 누르면 크롬 화면으로 넘어가고, 현재 상황을 보여줄 수 있게 되어 있다.
카메라도 보이고, 위치 서비스도 제공하면서, 경찰에 보내는 건 조금 부담스럽다. 이런 느낌일 때 사용하면 좋을 것 같다.
계속 브레인스토밍하는 것이다.
@동율 이 https://kakaomap.tistory.com/281 요거 이용하면 도착지까지 친구들의 위치와 예상 시간도 알 수 있어요! 저도 최근에 알게 돼서 공유드립니다 |
+| @혜인 정 | 🚗 초보자를 위한 운전 연수 웹
네이버 지도의 네비게이션처럼 길을 알려주지만, 현재 위치를 기반으로 해서 유턴을 해야 할 때는 핸들을 꺾는 각도를 함께 보여준다거나, 구간 단속이나 비보호 좌회전, 유턴 신호 등 간단하지만 처음에는 헷갈릴 수 있는 규범이 나왔을 때 어떤 용도(?)인지를 목소리로 알려주는 웹앱 | | 부모님이 멀리 계시거나 연수는 비싸서 많이 할 수 없는 경우에는 면허증이 있어도 운전을 시작할 엄두가 안 나는 초보자들을 위해… | @혜인 정 개발이 아니라 기획 단계에서 할 게 많아서 제외시키면 좋을 것 같았다. |
+| @혜인 정 | 🧭 위치 기반 날씨 시각화 웹 (백엔드 필요 없을 듯)
사용자의 현재 위치와 날씨 정보를 통해 구름, 비, 눈 등의 날씨 요소를 three.js를 통해 3D로 표현해주는 웹 (추가로 인구 밀도, 교통량, 미세먼지 등도 표현하면 괜찮을듯) | WebGL, Three.js | 백엔드 기술이 최대한 들어가지 않는 웹을 생각해보다…….| @혜인 정 백엔드가 필요 없는 프로젝트가 제일 베스트가 아닐까? 하는 생각에서 아이디어가 시작되었다.
현재 위치를 통해서 지도를 보여주는 것이다. 그 지도에 날씨 요소를 넣는 것이다.
인구 밀도, 교통량, 미세먼지 등을 표시해주는 것.
현재 위치를 기반으로 하면, 다른 여행지를 갈 때 날씨를 볼 텐데, 다른 지역을 볼 때가 더 효율적이지 않을까 하는 생각이 들고..
뭔가 근거가 충분하지 않은 것 같다. 조금 더 생각해보면 좋을 것 같다. |
+| @혜인 정 | 🚲 여행 기록 3D 애니메이션 웹 내가 여태껏 다닌 여행지를 애니메이션 형태 (인스타 등에 자랑할 수 있는 형태)의 영상으로 추출해주는 웹 개인적으로 ‘내트리에놀러와’ 같이 그 영상을 서로 공유하는 웹사이트로 만들어도 재밌을 듯 아래 링크 참고 https://mult.dev/studio | | 제가 여행을 정말 좋아해서 기록하고 SNS에 공유하는 것을 좋아하는 편인데, 예쁜 애니메이션 형태로 공유할 수 있는 웹사이트가 있으면 좋겠다고 생각하였습니다. (다만 급하게 생각해낸 거기도 하고 현재 실시간 위치를 반영하는 웹은 아니라서, 더 고민해봐야할 듯…) | @혜인 정 Three.js를 쓸 수 있는 방법을 생각했다. 인스타용으로 많이 쓸 수 있을 것 같았다. 한국인 환경에 맞는 느낌, UI/UX가 별로라서 만들고 싶었다. @주원 김 카카오 API나 여러 가지로 받아오고, 여행을 한다음 Three.js와 같은 애니메이션으로 경로를 바꿔서 보여주면 좋을 것 같다. 네이버 API, 카카오 API와 합쳐도 재밌을 것 같다는 생각이 들었다. @혜인 정 이미지를 넣으면 이미지에 위치 정보가 담겨 있으니까, 그 정보를 이용해서 경로를 보여주는 것도 좋을 것 같다. |
+| @혜인 정 | 크리스마스 특집 이건 진짜 아이디어가 아니고 브레인 스토밍 용인데, 12월 프로젝트 마무리 때쯤 크리스마스일 테니, 내 트리에 놀러와 같은 크리스마스 용 웹사이트를 만들어도 재밌을 듯 | | | @혜인 정 크리스마스 용도로 산타에게 선물을 보낸다거나.. FE만 사용해도 쓸 수 있는 그런 걸 만들고 싶었다. |
+| @동율 이 | 여행 도감 이미 해봤던 아이디어긴 하지만 매우 미약하고 퀄리티가 떨어져서 다시 디벨롭 해보고 싶은 생각이 있습니다! 기능은 각 도시마다 유명한 관광지들을 도감에 비활성화 상태로 넣어두고 실제 그 관광지에 들어간 뒤 5분이 지나면 도감에 사진과 글을 등록할 수 있도록 합니다! 그 이후 각 도시마다 진행도를 넣고, 등록한 관광지의 수만큼 경험치를 얻거나 크레딧을 얻는 방식입니다! 이를 three.js를 사용해서 멋지게 만들어 보거나 혜인님의 아이디어와 결합해도 재밌을 것 같아요!! 추가적으로는 등록을 위한 여행 루트도 짜주는 시스템도 들어가면 좋을 것 같아요! 시간이 모자라서 구현을 못했던 기능입니다 | | 주제가 공익적이거나 전국적인 사회 문제를 해결할 수 있는 앱이었고, 현재 우리나라는 수도권 집중화가 과도하게 되어있어, 이를 해결하기 위한 앱이었습니다. 아무래도 기업을 옮기거나 인프라를 늘리는 방법은 저희가 할 수 없기 때문에, 여행을 통한 유동 인구를 늘려 지역 경제를 활성화 시키자는 아이디어로 시작했습니다. 비인기 도시일수록 크레딧을 많이 주는 방식으로 하면 좋은 방향이 될 수 있을 것 같아요 | @동율 이 예전에 썼던 건데, 2학년 때 만든 것. 퀄리티가 굉장히 떨어짐. 관광지들을 많이 알려서, 유동 인구를 늘려서 해결하면 되겠다 하는 아이디어에서 출발. 각각 도감이 있다. 직접 그곳으로 가서 실시간으로 위치를 감지해서 반경 몇 미터 이내에 들어가면 활성화가 되고, 사진이랑 글을 넣을 수 있도록 해두었다. 사람들이 많이 안 가는 곳일수록 경험치를 많이 주도록 유도를 하고자 했다. 수익성도 고려를 했어야 했다. 아직 등록이 안 된 부분은 어떻게 하면 더 재밌게 즐길 수 있을지 플랜도 짤 수 있게 하면 재밌겠다 생각을 했다. 여행 도감이라는 아이디어가 괜찮은 것 같다. 그 지역들에 대한 관광지 소개가 괜찮은 것 같다. 이걸 디벨롭 시켜보고자 하는 마음이 있었다. |
+| @Zen | 현실 메시지 | | | @동율 이 재밌을 것 같아요! |
+
+## 🚀 팀의 의견 합치 과정
+
+@Zen :: 저.. 사실 두려움 있어요… 너무 내가 말을 많이 하나…?
+
+@Zen :: 문제를 기술적으로 해결하는 경험 → 근데 그 문제가 일상에서 나오는.. 내가 느낀 사소한 불편함 등을 기술로 해결하고 싶다.
+
+- 막차 ⇒ 실제로 겪음.. 어제도 겪음… 개짜증… 다 안된다고만 함… 어쩌라고.. 그걸 해결하는 게 개발자인데.
+- 할머니도 ⇒ 실제로 겪음… 근데 아무도 안된다고 함… 근데 해결할 수 있을 것 같음.
+- 혼자하기에는 이 모든 게 시간이 걸림… 그래서 동료들과 머리 부딪히고 으으으으으으 하면서 쥐어짜내서 하나의 문제 해결에 도전해보고 싶었음.
+
+- 기술적인 부분도 새로운 기술 배우면 최소 일주일은 적응 기간이 필요하잖아요? 근데 기술 그 자체의 의미보다는 기술이 어떤 문제를 해결했고, 내가 그 문제를 해결하기 위해 어떤 근거로 기술을 도입했을 때가 제일 재밌는 것 같아서… 저는 뭐든 상관없는데… 그냥 사소한 문제라도 좋으니 일상에서 겪는 것을 해결해보고 싶어요.
+
+@혜인 정 :: 새로운 기술을 어느 정도는 배웠으면 좋겠다. 사이드 프로젝트를 하다 보면 맨날 리액트, 타입스크립트를 써서 백엔드와 통신하고 보여주고… 새로운 기술이 있었으면 하는 마음이 있다. 만약 없더라도, 분업에 대해서 말씀드린 이유가 새로운 기술을 배우고 싶다는 입장이고.. 재도님은 조금은 반대의 입장… 만약 분업을 제대로 하지 않게 되면… 분업을 함으로써 어느 누구도 포기하지 않을 수 있다고 생각을 한다. 재도님과 저를 예로 기준으로 둔다면, 새로운 기술을 도입하지 않으면 어떻게 보면 제가 포기하는 기술이 들고, 새로운 기술을 도입함으로써 러닝 커브가 들게 되면 재도님이 포기하게 되는 입장이 있을 수 있다. 그래서 팀원 모두가 하고 싶은 것을 했으면 좋겠다 하는 마음이 있다. 그 누구도 하고 싶은 것을 포기하지 않고, 할 수 있는 것을 했으면 좋겠다는 생각이 있다. 분업을 해서 조금 더 짬뽕이 되더라도, 어떤 목표에서 기능이 조금 더 추가되어도.. 문제가 없지 않을까…?
+
+회사에서 일을 할 때에도 프론트엔드에서도 어떤 사람은 이 페이지를 개발하고, 다른 사람은 이 페이지를 개발하고… 보통 같은 기능을 함께 개발하는 경우는 거의 없다. 최대한 분업이 되었으면 좋겠다.
+
+@Zen :: 분업에 대해서 한번 합치를 하고 가도 좋을 것 같다.
+
+@주원 김 :: 각자의 현재 과정이 다르다. 저마다 필요한 게 다르다. 자신은 리액트 포폴이 필요하고, 혜인님은 리액트 포폴은 충분해서 새로운 것을 시도하고 싶다. 이런 부분은 각자에 맞추어서 넓게 가져가도 좋을 것 같다. 이 프로젝트가 다들 6주로 끝내자고 생각하는 분들이 없다고 생각해서, 처음에는 리액트를 바탕으로 한 프로젝트를 하고 대신 확장이 가능한 프로젝트를 하자. 일단 6주간은 같이 리액트를 만들고, 그 이후에는 `Three.js`, `AI` 등을 쓰면서 확장을 해보자는 생각을 했다. 처음부터 `Three.js`를 하게 되면 12월, 1월에도 `Three.js`를 하게 될 것 같고, 이렇게 되면 나는 리액트를 해야 하는데 그러지 못할까 봐 염려가 된다.
+
+@혜인 정 :: 분업이란? 어떤 분은 `React`를 하고 싶을 수도 있고, `Three.js`를 할 수도 있고… 이걸 다 할 수 있지 않을까? 모두가 만족할 수 있는 주제로 분업을 하면 좋지 않을까 하는 생각이 있다.
+
+@Zen :: 주제 → 주제 내에서 기능이 나와서 이를 나눠서 한다 ⇒ 맞다고 생각, 혜인, 주원님 ⇒ 각자 하고 싶은 거 종합해서 이걸로 일단 기능을 나누고 ⇒ 조합해서 주제를 뽑자.
+
+주제를 바탕으로 해서 기능을 나눠서 한 명을 나눠서 하는 그런 케이스.
+
+@주원 김 :: 기능을 한 사람이 책임지고 하나를 구현해서 하는 방안으로 구현을 한다.
+
+@혜인 정 :: 분업을 예측할 수 없는 주제는 패스하자.
+
+@동율 이 :: 메인 생각은 재도님 말씀처럼 주제를 딱 정하고, 주제 내에서 기능을 나누고, 각자 가져가서 분업을 하는 게 맞다고 생각한다. 위에서 이야기했던 것은 처음에 네비게이션에서 누가 뭘 하고, 여행 관련된 건 누가 하고, 버스 관련된 건 재도님이 하자 이렇게 생각을 했다. 이걸 위해서 추가하는 느낌이 들어서.. 그건 반대하는 의견이다. 그냥 여행 앱인데 이걸 하기 위해서 굳이 버스 막차 기능을 억지로 넣는다던지.. 그런 느낌이 별로… 주제만 잘 나와서 기능이 잘 나눠지면 그건 오케이.
+
+@Zen :: 공통의 목표 → 주제를 빨리 정하는 게 중요하다.
+각자 공통으로 챙겨가고 싶은 역량을 뽑아서 그라운드 룰로 잡자.
+
+## ❓그라운드 룰이란
+
+> @Zen :: 팀의 의사결정 과정에서 공통으로 두고 팀 전체가 의사결정을 내릴 때의 기준이 된다고 생각합니다.
+의사결정 방식에 대한 고민이라고도 볼 수 있을 것 같습니다.
+원하는 것에 사용하고 싶은 기술, 여기서 가져가고 싶은 것, 이루고 싶은 것 등 자유롭게 적어주세요! 이유도 함께 적어주시면 좋을 것 같습니다.
+
+그래서, 원하는 것을 먼저 맞춰보고자 하고, 안된다는 생각이 들면 이유를 바탕으로 해서 서로 어느 정도는 타협하고, 어느 정도는 맞춰가고, 어느 정도는 챙겨가면서 그룹 전체가 나아갈 수 있는 방향을 잡으면 좋을 것 같아요.
+
+- 참고 자료입니다.
+
+[https://pmikorea.kr/?p=4054](https://pmikorea.kr/?p=4054)
+
+### 🏃 꾸준하게, 일정하게 🏃
+
+- 이게 우리의 가치
+
+## 🤔 주제가 중요하다.
+
+- 주제를 먼저 생각하고, 거기서 출발하자.
+- 주제에 맞는 기술을 선정하면 뭐든 OK
+- 기술 먼저 생각보다는 주제를 정하는 게 중요하다.
+
+그렇다면 지금부터 저희는 주제 이야기할 때 기술을 빼고 생각합시다.
+
+프론트엔드 팀이니깐, 핵심은 **문제를 해결하는 데 초점을 맞추자**는 것입니다.
+
+### 📝 팀 운영 관련
+
+- 크레딧은 어느 계정에 받을 것인가?
+- 컨벤션은 어떻게 가져갈 것인가?
+- 깃허브 사용 전략 → 모노레포 여부, 백엔드 통합 여부 논의 필요
+
+@Zen :: 매주 빠르게 기능 하나를 완성해서 배포하는 걸 목표로 삼았으면 합니다. 5일은 개발에 쓰고, 1일은 안정화 작업을 하는 것도 좋은 방안 같습니다. (논의해봅시다.)
+
+@Zen :: 코드 리뷰 대신 팀원들이 PR을 할 때 핵심 기능에 대한 테스트 코드를 작성해 보는 것도 좋을 것 같습니다.
+
+@Zen :: 프로젝트 종료 후 위키를 기술 블로그로 활용하는 것도 좋을 것 같습니다.
+
+- Nextra의 docs를 참고해 보세요.
+- MD 문서 기반이라 배포가 쉽습니다. 이를 통해 문서화를 더 체계적으로 관리할 수 있습니다.
+
+@Zen :: `Three.js` 사용 여부에 대해서는 학습 소요 시간을 고려해야 할 필요가 있습니다.
+
+@Zen :: 개발 속도를 높이기 위해 `headless UI`와 같은 라이브러리를 활용해보는 것도 생각해볼 수 있습니다. 중요한 것은 핵심 기능에 집중하는 것입니다.
+
+## 📝 팀의 가치 정리
+
+##3 🤔 주제
+
+- 내가 사용할 수 있는 서비스(쓸것 같은 서비스)
+- **“내가 이게 필요한 이유를 팀원 전체가 공감해야 함.”**
+ - **설득의 영역이 아니라, 감정의 영역..**
+
+### 🤔 포트폴리오
+
+- 주원님의 이야기가 나오다보니.. 우리는 주제를 바꾸는건 크게 좋은 선택이 아닌 것 같음
+- 주제에 대한 도메인
+- 위치기반으로 오기도 했고… 그니까 이 범주 내에서 생각
+
+### 🤔 협업
+
+- @혜인 정 :: “집중할 때 집중하자.” → 심리적 나태함 방지
+ - 데드라인을 명확히!
+ - 팀적으로 생산성을 극대화하자. → 안되면 바로 옆에 말하고, 작업상황 빠르게 공유해서 누구하나 야근 없이 정해진 작업량을 제시간에
+ - 팀의 핵심 기능 개발에 대해서 야근이 있어서는 안된다.
+ - 혼자 끙끙 거리지 마라.
+- @혜인 정 :: 팀의 핵심 기능 개발에 대해서 주어진 시간을 넘기지 마라. → 곧바로 공유해라.
+ - 그외는 알아서 해도 되는데.. 팀에게도 지장갈 수 이쓴이
+- @동율 이 :: 6주가 짧다. → 그니까 이후에 유지보수로 추가할 생각하지 말고 핵심 기능은 6주에 다 담자.
+- @동율 이 :: 팀이 지치지 않는 것도 중요하니까, 6주가 짧지만 기니까… 컨디션 관리를 할 수 있게 여유를 두자. (완충을 잘 두자.)
+- @주원 김 :: 공통의 목표를 향해서 다 같이 으쌰으쌰하는 경험. → 밤새라는 말은 아님. 비동기소통을 하든 뭘 하든 문제를 공유하거나 지식을 공유했을때 피드백이 빨라서 서로 빨리빨리 뭔가 몰입해서 됐으면 좋겠다.
+- @주원 김 :: 피드백이 빨라서 작업흐름이 팀적으로 쭉 이어졌으면 좋겠다.
+- @Zen :: 분업이 아닌 협업이었으면 좋겠다.
+- @Zen :: 다 같이 한주에 기능 하나 구현해서 배포를 목적으로 달려들었으면 좋겠다. (일정은 이 범주내에서 여유롭게 알아서…)
+ - 스프린트 백로그 나오면 각자 알아서 가져가서 구현하고 합치는거…
+
+#### 🏃 꾸준하게, 일정하게 🏃
+
+- 이게 우리의 가치
+
+### 🤔 주제가 중요하다.
+
+- 주제를 먼저 생각하고, 거기서 출발하자.
+- 주제에 맞는 기술을 선정하면 뭐든 OK
+- 기술먼저 생각보다는
+
+- 그러면 지금부터 저희는 주제이야기할때 기술 뻅시다.
+ - 프론트면되요.
+
+---
+
+## 📝 주제 정하기
+
+- 3표가 나왔는데 끌리지 않은 이유? → @동율 이 :: 다른 주제가 더 끌림 - 여행 관련주제 + AR 관련해서
+ - 나왔던 아이디어가 재밌어 보여서
diff --git a/docs/docusaurus/docs/archive/minutes/20241029-idea-meeting.mdx b/docs/docusaurus/docs/archive/minutes/20241029-idea-meeting.mdx
new file mode 100644
index 00000000..53af1ae8
--- /dev/null
+++ b/docs/docusaurus/docs/archive/minutes/20241029-idea-meeting.mdx
@@ -0,0 +1,193 @@
+---
+slug: 20241029-idea-meeting
+title: 📝 [2024-10-29] 아이디어 회의
+sidebar_position: 3
+sidebar_label: 📝 [2024-10-29] 아이디어 회의
+keywords: ['회의', '아이디어']
+tags: [minutes]
+last_update:
+ date: 2024-10-29
+ authors: [zen]
+---
+
+
+## 📝 아이디어 노트
+
+[[💭 아이디어 꺼내기|💭 아이디어 꺼내기]]
+
+| 이름 | 발제자 | 분류 |
+|:-----------------:|:---------:|:---------:|
+| [💭 Three.js에 대한 생각 by 임재도](https://github.com/boostcampwm-2024/web28-DDara/wiki/%F0%9F%92%AD-Three.js%EC%97%90-%EB%8C%80%ED%95%9C-%EC%83%9D%EA%B0%81-by-%EC%9E%84%EC%9E%AC%EB%8F%84) | Zen | idea |
+| [💭 공간에 기억을 담다 by 임재도](https://github.com/boostcampwm-2024/web28-DDara/wiki/%F0%9F%92%AD-%EA%B3%B5%EA%B0%84%EC%97%90-%EA%B8%B0%EC%96%B5%EC%9D%84-%EB%8B%B4%EB%8B%A4-by-%EC%9E%84%EC%9E%AC%EB%8F%84) | Zen | idea |
+| [💭 아이디어 합치기 by 김주원](https://github.com/boostcampwm-2024/web28-DDara/wiki/%F0%9F%92%AD-%EC%95%84%EC%9D%B4%EB%94%94%EC%96%B4-%ED%95%A9%EC%B9%98%EA%B8%B0-by-%EA%B9%80%EC%A3%BC%EC%9B%90) | 주원 김 | discuss |
+| [💭 GPT의 아이디어 by 이동율](https://github.com/boostcampwm-2024/web28-DDara/wiki/%F0%9F%92%AD-GPT%EC%9D%98-%EC%95%84%EC%9D%B4%EB%94%94%EC%96%B4-by-%EC%9D%B4%EB%8F%99%EC%9C%A8) | 동율 이 | idea |
+| [💭 중장년층을 위한 지도 서비스 (토론)](https://github.com/boostcampwm-2024/web28-DDara/wiki/%F0%9F%92%AD-%EC%A4%91%EC%9E%A5%EB%85%84%EC%B8%B5%EC%9D%84-%EC%9C%84%ED%95%9C-%EC%A7%80%EB%8F%84-%EC%84%9C%EB%B9%84%EC%8A%A4-(%ED%86%A0%EB%A1%A0)) | Discuss |discuss|
+| [💭 중장년층을 위한 지도 서비스 by 임재도](https://github.com/boostcampwm-2024/web28-DDara/wiki/%F0%9F%92%AD-%EC%A4%91%EC%9E%A5%EB%85%84%EC%B8%B5%EC%9D%84-%EC%9C%84%ED%95%9C-%EC%A7%80%EB%8F%84-%EC%84%9C%EB%B9%84%EC%8A%A4-by-%EC%9E%84%EC%9E%AC%EB%8F%84) | Zen |idea |
+| [💭 중장년층을 위한 지도 서비스 by 이동율](https://github.com/boostcampwm-2024/web28-DDara/wiki/%F0%9F%92%AD-%EC%A4%91%EC%9E%A5%EB%85%84%EC%B8%B5%EC%9D%84-%EC%9C%84%ED%95%9C-%EC%A7%80%EB%8F%84-%EC%84%9C%EB%B9%84%EC%8A%A4-by-%EC%9D%B4%EB%8F%99%EC%9C%A8) | 동율 이 |idea |
+| [💭 중장년층을 위한 지도 서비스 by 정혜인](https://github.com/boostcampwm-2024/web28-DDara/wiki/%F0%9F%92%AD-%EC%A4%91%EC%9E%A5%EB%85%84%EC%B8%B5%EC%9D%84-%EC%9C%84%ED%95%9C-%EC%A7%80%EB%8F%84-%EC%84%9C%EB%B9%84%EC%8A%A4-by-%EC%A0%95%ED%98%9C%EC%9D%B8) | 혜인 정 |idea |
+| [💭 중장년층을 위한 지도 서비스 by 김주원](https://github.com/boostcampwm-2024/web28-DDara/wiki/%F0%9F%92%AD-%EC%A4%91%EC%9E%A5%EB%85%84%EC%B8%B5%EC%9D%84-%EC%9C%84%ED%95%9C-%EC%A7%80%EB%8F%84-%EC%84%9C%EB%B9%84%EC%8A%A4-by-%EA%B9%80%EC%A3%BC%EC%9B%90) | 주원 김 |idea |
+
+
+## 📝 회의 안건
+
+### 🧑💻 주제를 어떻게 할 것인가?
+
+@Zen :: 기존에 이야기를 한 것은 디자인적인 측면이 강한 것 같았다.
+
+@혜인 정 :: `A11y`에 대한 아예 접근성을 고려하는게 좋을 것 같다. 접근성자체를 기술적으로 가져가봐도 좋을 것 같다.
+
+@혜인 정 :: 지도에 대한 상태관리를 해봐도 좋을 것 같다. 치킨집마다 다른 뿌링클 맛을 평가하는 웹사이트가 있었으면 좋겠다 해서 전국 뿌링클 맛집 지도를 만든적이 있는데, 전국 맛집에 대한 마킹을 해두고 마킹 별로, 리뷰를 넣을 수 있는 그런 식으로 사용을 했다. 네이버 지도 API나 카카오 지도 API를 사용하면 그건 진짜 간단하다. 기술적인 도전으로 가져가기에는 아쉬움이 있을 것 같다. 상태관리에 대한 기술적 도전보다는 API적용에 대한 기술적 도전이 될 것 같다. 포트폴리오적으로 맞지 않을 것 같다.
+
+@Zen :: 위치 정확도를 올리고 싶으면 알고리즘을 건드려야 한다.
+
+@Zen :: 기술적인 도전을 할 거면 2개를 생각해볼 수 있을 것 같다. 1. 지도 만들기. 2. 실내에서 위치 안내해주기. 다만, 이 경우는 FE프로젝트라기 보다는 임베디드, CS 프로젝트가 될 가능성이 있다.
+
+@혜인 정 :: 위치에 대한 것에 집중하면 threejs라는 기술 자체에 도전하는 것과 다를게 없을 것 같다. 기술적인 도전을 했으면 좋겠다.
+
+@혜인 정 :: 그냥 멘토님께서 말씀하신 스토리북을 도입해서 프론트엔드 개발적인 도전을 해보자. 주제는 어제 정한 걸로 동일하게 하고,
+
+@Zen :: A11y로 할 것이라면 `TDD`로 하자. 그냥 `TDD`를 넘어서 모든 과정을 테스트하고, 이를 기술적인 도전으로 삼자.
+
+@동율 이 :: 뭐든 “왜?” 라는 질문에 대답을 확실히 할 수 만 있으면 상관이 없을 것 같다.
+
+@주원 김 :: 6주동안 `TDD`하는게 잘 없을 것 같아서, 면접때 주제를 모을 수 있고.. 장점이 많을 것 같다. 딥다이브한 범위 내에서 주제를 가져갈 수 있을 것 같다. 부정적이면 부정적인 이유를 나열할 수 있고, 등등.. 다만 확장성에 대한 부분
+
+@동율 이 :: 실시간 위치나, 접근성이나 UX도 디자인적인게 강하다. 이에 대해서 기술적 도전을 할게 아니라면 `TDD`등 평소에 해보기 어려운 확실한 주제를 잡아서 가는 게 좋을 것 같다.
+
+@혜인 정 :: 우리가 할 수 있는 제일 큰 기술적인 도전인 것 같다. 구현하는 데 신경을 많이쓰면 `TDD`를 도입하기 어려울 것 같다. 우리가 구현할 수 있는게 적어야 할 것 같다. 간단한 프로젝트 처럼.
+
+@혜인 정 :: 문서화를 도전으로 해봐도 좋을것 같다.
+
+@동율 이 :: 문서화는 기술적 도전이 아닌 것 같다. 굳이 `TDD`가 아니더라도, 다른 방법으로 고민해봐도 좋을 것 같다.
+
+@주원 김 :: 여행계획 `TodoList`로 가더라도, 주제는 좀 짜쳐도 상태관리 `TodoList`로 넣어도 괜찮지 않을까? 계획 세우기를 J식으로 해서 상태관리를 해봐도 좋을 것 같다.
+
+@Zen :: 시간이 부족할 것이라는 생각이 든다면, `코어타임` 규칙을 깨자. 코어타임까지만 개발을 하더라도 문서화, 공부는 그 외시간에 하는 게 맞다고 생각한다. 내가 생각하는 일정 산출에는 학습 시간 및 문서화 시간은 포함되어 있지 않다.
+
+@혜인 정 :: 주제만 작게 잡으면 시간적인 측면에서는 상관 없을 것 같다.
+
+@Zen :: 문서화나, 학습은 코어시간 이후에 진행하자. 대신 학습을 하면 동기화는 빠르게 하자.
+
+@혜인 정 :: 프로젝트가 작으면 테스트를 할 게 그만큼 적어진다.
+
+@Zen :: 그럼 아예 클론 코딩을 해버리는 건?
+
+### 📝 지금까지 나온 내용 정리
+
+1. 어떤 주제를 하든 상관없으나, `TDD`등 모든 과정에 대한 테스트 주도 개발을 기술적 도전으로 함.
+2. 주제는 위치관련된 것이면 된다. ↔ 자유롭게 해보고 최대한 고려 (포폴적으로 확실하게…)
+3. 코어타임시간에는 온전히 개발만. 일정 산출도 개발진도에 대한 부분만. (늘어짐 방지) - 회의시간은 포함 → 테스트코드 작성
+4. 문서화 및 학습은 코어타임 이후에 자유롭게. 적게하든 많이하든 무조건 코어타임 이후. (개발하면서는 최소한의 것만 보기.)
+
+- 문서정리 → 아카이빙해서 가져가면 좋을 것 같다는 생각… 나중에 회으ㅜ
+
+- 이후 쉬고와서 :: 주제선정
+
+> 최대한 노션 페이지는 안만들고 여기에 적을게요. GPT가 잘 인식을 못하네여 ㅠㅠ..
+>
+
+### 테스트 관련 학습에 도움될 자료들
+
+> 나중에 따로 아카이빙 하겠습니다.
+>
+
+#### 제로초님의 Jest 테스트 강의
+
+[테스트 with Jest: 제로초에게 제대로 배우기 강의 | 제로초(조현영) - 인프런](https://www.inflearn.com/course/%ED%85%8C%EC%8A%A4%ED%8A%B8-with-jest-%EC%A0%9C%EB%A1%9C%EC%B4%88/dashboard)
+
+#### 프론트앤드 테스트 강의
+
+[2시간으로 끝내는 프론트엔드 테스트 기본기 강의 | 강병진 - 인프런](https://www.inflearn.com/course/%EC%A3%BC%EB%8B%88%EC%96%B4-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B8%B0%EB%B3%B8%EA%B8%B0/dashboard)
+
+- 생각해보니 Cypress도 있었네요. 당근은 이거쓴다던데
+
+#### 실무에 바로 적용하는 프런트엔드 테스트
+
+[실무에 바로 적용하는 프런트엔드 테스트 - 1부. 테스트 기초: 단위・통합 테스트 강의 | 코드 조커, 오프 - 인프런](https://www.inflearn.com/course/%EC%8B%A4%EB%AC%B4%EC%A0%81%EC%9A%A9-%ED%94%84%EB%9F%B0%ED%8A%B8%EC%97%94%EB%93%9C-%ED%85%8C%EC%8A%A4%ED%8A%B8-1%EB%B6%80?attributionToken=iAHwhwoMCNeLgbkGEJPn8cABEAEaJDY3MmE5NjZmLTAwMDAtMmQzNi04OTc0LTI0MDU4ODcxNDYyNCoGMzUwNDY3MjCjgJcit7eMLajlqi2c1rctjr6dFcXL8xfC8J4V1LKdFZruxjCf1rctkPeyMI6RyTA6DmRlZmF1bHRfc2VhcmNoSAFoAXoCc2k)
+
+[실무에 바로 적용하는 프런트엔드 테스트 - 2부. 테스트 심화: 시각적 회귀・E2E 테스트 강의 | 코드 조커, 오프 - 인프런](https://www.inflearn.com/course/%EC%8B%A4%EB%AC%B4%EC%A0%81%EC%9A%A9-%ED%94%84%EB%9F%B0%ED%8A%B8%EC%97%94%EB%93%9C-%ED%85%8C%EC%8A%A4%ED%8A%B8-2%EB%B6%80?attributionToken=iAHwhwoMCNeLgbkGEJPn8cABEAEaJDY3MmE5NjZmLTAwMDAtMmQzNi04OTc0LTI0MDU4ODcxNDYyNCoGMzUwNDY3MjCjgJcit7eMLajlqi2c1rctjr6dFcXL8xfC8J4V1LKdFZruxjCf1rctkPeyMI6RyTA6DmRlZmF1bHRfc2VhcmNoSAFoAXoCc2k)
+
+#### 근본있는 프론트앤드 유닛테스트
+
+[근본있는 프론트엔드 유닛테스트 강의 | 어쩔코딩 - 인프런](https://www.inflearn.com/course/%EA%B7%BC%EB%B3%B8%EC%9E%88%EB%8A%94-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EC%9C%A0%EB%8B%9B%ED%85%8C%EC%8A%A4%ED%8A%B8?attributionToken=iAHwhwoMCNeLgbkGEJPn8cABEAEaJDY3MmE5NjZmLTAwMDAtMmQzNi04OTc0LTI0MDU4ODcxNDYyNCoGMzUwNDY3MjCjgJcit7eMLajlqi2c1rctjr6dFcXL8xfC8J4V1LKdFZruxjCf1rctkPeyMI6RyTA6DmRlZmF1bHRfc2VhcmNoSAFoAXoCc2k)
+
+#### TDD 책
+
+- 개인적으로 만약 TDD 프로젝트로 가면 이 바이블 책 정도는 읽어봐야 할 것 같아서, 이걸로 그룹프로젝트 내부 스터디해도 재밌을 것 같습니다.
+
+[product.kyobobook.co.kr](https://product.kyobobook.co.kr/detail/S000001032985?LINK=NVB&NaPm=ct%3Dm2ttkuyo%7Cci%3D91c03e1d02c7e76ad2d4c42c68f88c625345fc4d%7Ctr%3Dboksl1%7Csn%3D5342564%7Chk%3D64f0f97a04902723ec370820d752bbe1be9684be)
+
+#### 코드와함께 살펴보는 프론트엔드 단위 테스트 - 배달의민족
+
+[코드와 함께 살펴보는 프론트엔드 단위 테스트 – Part 1. 이론 편 | 우아한형제들 기술블로그](https://techblog.woowahan.com/17404/)
+
+[코드와 함께 살펴보는 프론트엔드 단위 테스트 – Part 2. 실전 편 | 우아한형제들 기술블로그](https://techblog.woowahan.com/17721/)
+
+#### 프론트엔드 개발자가 알아야 할 ‘유닛 테스트’ 작성법
+
+[프론트엔드 개발자가 알아야 할 ‘유닛 테스트’ 작성법 | 요즘IT](https://yozm.wishket.com/magazine/detail/2483/)
+
+#### 프론트엔드에서 의미있는 테스트 코드 작성하기 - 미디움
+
+[프론트엔드에서 의미있는 테스트 코드 작성하기](https://team.modusign.co.kr/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C%EC%97%90%EC%84%9C-%EC%9D%98%EB%AF%B8%EC%9E%88%EB%8A%94-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1%ED%95%98%EA%B8%B0-4992409c7f2d)
+
+#### 프론트엔드 테스트 코드 도입기
+
+[프론트엔드 테스트 코드 도입기](https://techblog.pet-friends.co.kr/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%BD%94%EB%93%9C-%EB%8F%84%EC%9E%85%EA%B8%B0-c3a1865250ee)
+
+#### 모던 프론트엔드 테스트 전략
+
+[모던 프론트엔드 테스트 전략 — 1편](https://blog.mathpresso.com/%EB%AA%A8%EB%8D%98-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%A0%84%EB%9E%B5-1%ED%8E%B8-841e87a613b2)
+
+[모던 프론트엔드 테스트 전략 — 2편](https://blog.mathpresso.com/%EB%AA%A8%EB%8D%98-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%A0%84%EB%9E%B5-2%ED%8E%B8-de069e271b3d)
+
+#### 프론트앤드 개발을 위한 테스트 입문
+
+[프런트엔드 개발을 위한 테스트 입문 - 예스24](https://m.yes24.com/Goods/Detail/127005970)
+
+#### 실용적인 프론트엔드 테스트 전략 - NHN Cloud
+
+[실용적인 프론트엔드 테스트 전략 (1) : NHN Cloud Meetup](https://meetup.nhncloud.com/posts/174)
+
+[실용적인 프론트엔드 테스트 전략 (2)](https://ui.toast.com/weekly-pick/ko_20190116)
+
+#### Toast UI의 테스트코드 관련 내용 모음
+
+[Posts](https://ui.toast.com/posts/ko/testing/2)
+
+#### 프론트앤드에서도 TDD가 가능한 것을 보여줍니다.
+
+[[A5] 프론트엔드에서 TDD가 가능하다는 것을 보여드립니다.](https://youtu.be/L1dtkLeIz-M?si=25BwALs6nBzW_Ih-)
+
+@혜인 정 :: 걸리는게 뭐냐면, `TDD`가 현업에서 부정적인 이미지가 많은데.. 이걸 써야하는 게 후킹하지 않다고 생각한다. 예시를 들면 멘토님이 써야하는 프로젝트가 전역 상태 라이브러리를 써야한다는 방향으로 나아갔다. 거기에서 `Context`를 써보고, 안좋은 것이 있다는 것을 발견했고, 그래서 왜 안좋은지 알 수 있었다가 흐름이 되는건데… 우리로 따지면 전역상태관리를 쓰지 않고 그냥 `useContext`가 됐다. 라고 생각한다. 우리로 치면 `useContext`가 `TDD`라고 생각한다. `Storybook`이 `Redux`가 아닌가 싶다. 많이 바뀌고, 테스트코드가 바뀌기 때문에 비효율적인것 같다가 대다수고… 간단한 스토리북을 사용하는 경우가 훨씬 많고. 제가 생각했을 때는 멘토님이 `useContext`를 썼을 떄 그정도로 후킹했을까 싶다.
+
+@주원 김 :: 썻을떄 비용은 많이 들었지만, 코드가 어떻게 변했다. 이게 포커싱이 될 것 같다. `TDD`를 썼을때의 효과는 이거이거했으니까 좋고, 전 프로젝트는 어떤 관점이 부족하고… 사이드이펙트가 생길지 몰랐는데.. 다음 프로젝트는 이거이거… 그렇게까지 하는게 되는게 아닐까 생각하고있다.
+
+@혜인 정 :: 결론이 부족한게 너무 걸린다…
+
+---
+
+@혜인 정 :: 테스트와 빡센 문서화면 프로젝트로도 가치가 있을 것 같다.
+
+@Zen :: 테스트를 제대로 할 수 있으면 좋을 것 같다. (팀 전체가 동의한다면)
+
+@주원 김 :: 일단 써보자가 의의인 것 같다. 일단 그래도 쓰자 라는 주의이다.
+
+@동율 이 :: 테스트를 하고 싶어 하는 것 같다. 테스트가 주가 되기 보다는 어디서든 쓸 수 있다. 굳이 좋은 주제가 있는 게 아니면 그대로 써보자.
+
+@혜인 정 :: 일단 어제 정했던 주제로 가서 TDD를 입히고, 거기서 해보는 걸로 가자.
+
+---
+
+[[📝 아이디어 노트|📝 아이디어 노트]]
+
+| 제안자 | 아이디어 | 예상 사용 기술 | 이유 | 추가 피드백 |
+| --- | ---|---| --- |---|
+| @주원 김 | 🗺️ 네이버 지도 개선 - 오늘의 장소 리스트에 오늘 갈 장소들을 담아둔다 - 단톡에 이를 공유하면 약속 일정 공유와 함께 장소를 이동할 때 바로 해당 링크에서 길안내를 시작할 수 있다 - 좋았던 여행 경로 등을 기록해두고 공유할 수 있다
🤔 확장 (1,2월 기간을 활용해서 더 추가해볼만한 사항) 1. 경로추천 - 경로 설정(A,B,C) 3가지 목적지가 있을 경우 A→B→C가 빠른지 B→A→C가 빠른지 등 빠른 경유지 탐색 2. 3D를 사용 - 실내(롯데타워 같은 곳에서는 실내 길안내) 3. AI 사용 - 여행의 경우에 추가할만한 방문지 추천 4. 재도님 프로젝트와의 결합? - 링크에 접속한 사람들의 실시간 위치를 표시(옵션 추가) → 위치의 정확성 높이기 → 어르신 픽업, 흩어져서 놀다가 모이기 등등 | | 이전의 지도는 단톡방에 공유되어있는 장소 정보나 인터넷 검색을 통해 1명이 길찾기를 진행하는 방식으로 진행되어왔다. 따라서 단톡방에 일정을 공유할 때 장소 각각에 대한 링크들을 공유하는 것이 아니라 장소들의 목록을 공유하여 번거로움을 줄이고자 한다. | @Zen Travel이라는 어플이 있어요. 이거 벤치마킹 해봐도 재밌을 것 같음. 실제로 일본 여행 때 요긴하게 썼음. → 구글지도 연동 |
+| @Zen | 🚀 약속 정하기 위해 사용하는 프로그램
[핵심] :: 실시간 위치 추적 - 지도에 실시간으로 각 사용자의 위치를 표시한다. - 이를 보면서 사용자 간의 서로 현재 어느 위치에 있는지 파악한다
[추가 기능] - 실시간 위치 표시를 넘어서 장소에 댓글을 남겨봐도 괜찮을 것 같다. 일종의 추억 저장이라 해야 하나…? 1. WhenToMeet처럼 시간을 타임테이블 형식으로 정할 수 있었으면 좋겠다. 2. 약속 장소를 리스트업하고, 이를 바탕으로 주변 사람들의 위치를 파악할 수 있었으면 좋겠다. 3. 중간 지점이 되는 장소를 자동으로 찾고, 경로를 알려줬으면 좋겠다. (예상 시간까지.) 4. 버스 타는 지점이나 대중교통 타는 지점 등을 알려줬으면 좋겠다. 5. 막차에 대한 정보를 정확하게 제공했으면 좋겠다. 혹은 현재 버스가 어디에 있는지도. | - Geolocation API - 네이버 지도 API - React - React Native | **1. 약속을 정하기 위해서 항상 어려운 것은 다음과 같습니다.** - ㄱ) 공통된 시간을 정하는 문제 - ㄴ) 중간 지점을 찾는 문제
이에 대해서 뭔가 하나로 합쳐진 서비스가 있었으면 했습니다. (당장 저희만 해도 관련해서 정하는데 꽤 오래 걸렸잖아요? ㅎㅎ)
**2. 막차를 제대로 알려주는 서비스가 있었으면 했습니다.**
얼마 전 집 근처 지하철역에서 집까지 막차를 타는데, 버스가 16분 후로 찍혀있는 겁니다. 7 정거장 전이었구요. 그래서 그런가 보다 했는데 10분 딴짓하다 다시 보니 14분입니다… 그래서 아 뭔가 막히는가 보다 했는데.. 20분 더 기다려서 보니 버스가 사라져있습니다… 아놔.. 이러면서 다른 버스 기다리는데 20분 후 그 버스가 다시 나타나고 6분 후가 되었더군요.. 3 정거장 전…
심지어 기다리던 다른 버스에서도 비슷한 문제가 발생했습니다.
결국 밖에서 1시간 10분을 기다린 끝에 탔습니다.
이런 경우 다른 건 모르겠고 실시간 버스 위치만 추적이 되어도 괜찮지 않을까 했습니다.
그리고, 이런 기능은 약속 정할 때 실시간 위치 추적과도 크게 기능상 다르지 않을 것 같아서.. 이 정도만 있어도 `약속 정하기 위한 프로그램`이 아니라 `버스의 위치 추적`만 제공을 해주고, 도메인을 `버스 추적기`라고 해서 개발해도.. 저는 이 프로그램을 사용할 거라고 생각했습니다.
**3. 저희 조부모님의 동네에는 1시간에 버스가 1대 옵니다. 그리고, 정해진 시각에 도착하는 경우가 거의 없습니다. 현재 위치가 어딘지 몰라서.. 조부모님께서는 항상 덥든 춥든 힘든 몸을 이끌고 최소 20분은 대기하십니다..**
버스의 위치만을 알아도 이런 문제가 덜하지 않을까 생각했습니다.
**4. 조부모님께서 열차로 올라오실 때 서울 지리가 익숙치 않아서 길을 자주 헤매십니다.. 저희가 마중 가도 위치 파악이 안 되어 헤매는 경우가 많습니다.**
이 경우 실시간 위치만 제대로 보여줘도, 그 위치로 저희가 가면 되니까 얼마나 좋을까? 하는 생각이 있었습니다.
**5. 약속 때에도 항상 길이 엇갈리는 경우가 생깁니다.** 그런 경우에도 이런 서비스가 있었으면 좋겠다고 생각합니다.
**6. 위치 서비스를 쓰면 차는 몰라도 도보는 현재 내 위치가 제대로 파악이 안 되는 경우가 많습니다. 이걸 프론트엔드의 기술을 써서 해결해보면 어떨까 했습니다.** | @혜인 정 부산에서 카카오는 시범 운행하고 있다. 현재 버스 위치를 실시간으로 보여준다.
이미 있는 서비스를 클론 코딩 하는 것도 좋지만, 개선하거나 새롭게 했으면 좋겠다.
개발 말고 기획 단계에서 생각해야 하는 부분이 많을 것 같다.
API도 없을 것이다.
시간이 부족할 것 같다.
@혜인 정 위치를 공유하면서, 카메라로 실시간 위치를 보여주면 좋을 것 같다는 생각이 들었다.
밤에 그런 의도로 활용해도 좋을 것 같다는 생각이 들었다.
위험한 상황이 생기면 경찰에 전화에서 톡톡 같은 번호 2번 누르면 크롬 화면으로 넘어가고, 현재 상황을 보여줄 수 있게 되어 있다.
카메라도 보이고, 위치 서비스도 제공하면서, 경찰에 보내는 건 조금 부담스럽다. 이런 느낌일 때 사용하면 좋을 것 같다.
계속 브레인스토밍하는 것이다.
@동율 이 https://kakaomap.tistory.com/281 요거 이용하면 도착지까지 친구들의 위치와 예상 시간도 알 수 있어요! 저도 최근에 알게 돼서 공유드립니다 |
+| @혜인 정 | 🚗 초보자를 위한 운전 연수 웹
네이버 지도의 네비게이션처럼 길을 알려주지만, 현재 위치를 기반으로 해서 유턴을 해야 할 때는 핸들을 꺾는 각도를 함께 보여준다거나, 구간 단속이나 비보호 좌회전, 유턴 신호 등 간단하지만 처음에는 헷갈릴 수 있는 규범이 나왔을 때 어떤 용도(?)인지를 목소리로 알려주는 웹앱 | | 부모님이 멀리 계시거나 연수는 비싸서 많이 할 수 없는 경우에는 면허증이 있어도 운전을 시작할 엄두가 안 나는 초보자들을 위해… | @혜인 정 개발이 아니라 기획 단계에서 할 게 많아서 제외시키면 좋을 것 같았다. |
+| @혜인 정 | 🧭 위치 기반 날씨 시각화 웹 (백엔드 필요 없을 듯)
사용자의 현재 위치와 날씨 정보를 통해 구름, 비, 눈 등의 날씨 요소를 three.js를 통해 3D로 표현해주는 웹 (추가로 인구 밀도, 교통량, 미세먼지 등도 표현하면 괜찮을듯) | WebGL, Three.js |백엔드 기술이 최대한 들어가지 않는 웹을 생각해보다…….|@혜인 정 백앤드 필요없는 프로젝트가 제일 베스트가 아닐까? 하는 생각에서 아이디어가 시작되었다.
현재 위치를 통해서 지도를 보여주는 것이다. 그 지도에 날씨 요소를 넣는 것이다.
인구밀도 교통량, 미세먼지 등을 표시해주는 것.
현재 위치를 기반으로 하면, 다른 여행지를 갈 때 날씨를 볼 텐데, 다른 지역을 볼 때가 더 효율적이지 않을까 하는 생각이 들고..
뭔가 근거가 충분하지 않은것 같다. 조금더 생각해보면 좋을 것 같다. |
+| @혜인 정 | 🚲 여행 기록 3d animation 웹 내가 여태껏 다닌 여행지를 애니메이션 형태 (인스타 등에 자랑?할 수 있는 형태)의 영상으로 추출해주는 웹 개인적으로 ‘내트리에놀러와’ 같이 그 영상을 서로 공유하는 웹사이트로 만들어도 재밌을 듯 아래 링크 참고 https://mult.dev/studio | | 제가 여행을 정말 좋아해서 기록하고 SNS에 공유하는 것을 좋아하는 편인데, 예쁜 애니메이션 형태로 공유할 수 있는 웹사이트가 있으면 좋겠다고 생각하였습니다. (다만 급하게 생각해낸 거기도 하고 현재 실시간 위치를 반영하는 웹은 아니라서, 더 고민해봐야할듯…) | @혜인 정 Three.js를 쓸 수 있는 방법을 생각했다. 인스타용으로 많이 쓸 수 있을 것 같았다. 한국인 환경에 맞는 느낌, UI/UX가 별로라서 만들고 싶었다. @주원 김 카카오 API나 여러가지로 받아오고, 여행을 한다음 Three.js 와 같은 애니메이션으로 경로를 바꿔서 보여주면 좋을 것 같다. 네이버API, 카카오API와 합쳐도 재밌을 것 같다는 생각이 들었다. @혜인 정 이미지를 넣으면 이미지에 위치 정보가 담겨 있으니까, 그 정보를 이용해서 경로를 보여주는 것도 좋을 것도 좋을 것 같다. |
+| @혜인 정 | 크리스마스 특집 이건 진짜 아이디어가 아니고 브레인 스토밍 용인데, 12월 딱 프로젝트 마무리 할 때 쯔음 되면 크리스마스일테니, 내 트리에 놀러와 같은 크리스마스 용 웹사이트를 만들어도 재밌을 듯 | | | @혜인 정 뭔지 생각 안하고 만든 것. 크리스마스 용도로 산타에게 선물을 보낸다거나.. FE만 사용해도 쓸 수 있는 그런걸 만들고 싶었다. |
+| @동율 이 | 여행 도감 이미 해봤던 아이디어긴 하지만 매우 미약하고 퀄리티가 떨어져서 다시 디벨롭 해보고 싶은 생각이 있습니다! 기능은 각 도시들 마다 유명한 관광지들을 도감에 비활성화 상태로 넣어두고 실제 그 관광지에 들어간 뒤 5분이 지나면 도감에 사진과 글을 등록할 수 있도록 합니다! 그 이후 각 도시들마다 진행도를 넣고, 등록한 관광지의 수 만큼 경험치를 얻거나 크레딧을 얻는 방식입니다! 이를 three.js를 사용해서 멋지게 만들어 보거나 혜인님 아이디어와 결합해도 재밌을 것 같아요!! 추가적으로는 등록을 위한 여행 루트도 짜주는 시스템도 들어가면 좋을 것 같아요! 시간이 모자라서 구현을 못했던 기능입니다 | | 주제가 공익적이거나 전국적인 사회 문제를 해결할 수 있는 앱이었고, 현재 우리나라는 수도권 집중화가 과도하게 되어있어, 이를 해결하기 위한 앱이었습니다. 아무래도 기업을 옮기거나 인프라를 늘리는 방법은 저희가 할 수 없기 때문에, 여행을 통한 유동 인구를 늘려 지역 경제를 활성화 시키자는 아이디어로 시작했습니다 비인기 도시일수록 크레딧을 많이 주는 방식으로 하면 좋은 방향이 될 수 있을 것 같아요 | @동율 이 예전에 썼던 건데, 2학년때 만든것. 퀄리티가 굉장히 떨어짐. 관광지들을 많이 알려서, 유동인구를 늘려서 해결하면 되겠다. 하는 아이디어에서 출발. 각각 도감이 있다. 직접 그곳으로 가서 실시간으로 위치를 감지를 해서 반경 몇 미터 이내에 들어가면 활성화가 되고, 사진이랑 글을 넣을 수 있도록 해두었다. 사람들이 많이 안가는 곳일수록 경험치를 많이 주도록 유도를 하고자 했다. 수익성도 고려를 했어야 했다. 아직 등록이 안된 부분은 어떻게 하면 더 재밌게 즐길 수 있을 지 플랜도 짤 수 있게 하면 재밌겠다 생각을 했다. 여행 도감이라는 아이디어가 괜찮은 것 같다. 그 지역들에 대한 관광지 소개가 괜찮은 것 같다. 이걸 디벨롭 시켜보고자 하는 마음이 있었다. |
+| @Zen | 현실 메세지 | | | @동율 이 재밌을것같아요! |
\ No newline at end of file
diff --git a/docs/docusaurus/docs/archive/minutes/20241030-schedule-planning-meeting.mdx b/docs/docusaurus/docs/archive/minutes/20241030-schedule-planning-meeting.mdx
new file mode 100644
index 00000000..f89439ec
--- /dev/null
+++ b/docs/docusaurus/docs/archive/minutes/20241030-schedule-planning-meeting.mdx
@@ -0,0 +1,197 @@
+---
+slug: 20241030-schedule-planning-meeting
+title: 📝 [2024-10-30] 일정 및 기획 회의
+sidebar_position: 4
+sidebar_label: 📝 [2024-10-30] 일정 및 기획 회의
+keywords: ['회의', '일정', '기획']
+tags: [minutes]
+last_update:
+ date: 2024-10-30
+ authors: [zen]
+---
+
+
+
+## 📝 회의 내용 정리
+
+### 📝 주제
+
+중장년층을 위한 지도 서비스
+
+- @Zen :: 중장년층을 빼고, 주제에 대한 후킹 없이 그냥 서로 약속 엇갈리는거 방지 이런느낌으로 가고 확장해도 좋을 것 같습니다.
+- @혜인 정 :: 타겟층은 명확한게 좋으니, 일단은 주제는 유지하되, 나중에 변경을 했으면 좋겠습니다. ⇒ MVP가 중요할 것 같습니다. (이거에 맞추어서 진행합시다.)
+
+### 📝 핵심 기능
+
+실시간 위치 공유 서비스
+
+- 5명 동시접속이 가능해야 함
+
+### 📝 기술적 목표
+
+#### ⚙️ 공통의 목표 :: 문서화
+
+- TSDoc, JSDoc 을 이용해서 문서로 바꿔서 퍼블리싱한다. (정적페이지 퍼블리싱이니 vercel 아니면 github docs 이용) ⇒ 6주차 / 깃위키 정도는 매일한건데… 그건 따로이야기
+- 프론트앤드 :: storybook 등을 이용
+- 백앤드 :: swagger
+
+@Zen :: Lint 등 함께 공유하는 요소는 빡세게 초반에 잡아도 좋을 것 같습니다. BE / FE 모두 공용으로요. 그 이후에 그거 기준으로 각자 추가합시다.
+
+#### ⚙️ Front-End
+
+- TDD
+ - @Zen :: 되게 이론이 많은데 1차적으로는 백로그에 있는 기술을 구현하기 전에 테스트코드 먼저 작성 이후 구현하는 형태로 가고 매주 개선해봅시다.
+ - @Zen :: 관련해서 공용 문서 개설할 예정입니다. 학습 정리 등 해둬도 좋을 것 같습니다. 정확히는 경험적인 측면에서 적으면 좋을 것 같습니다.
+- 실시간 위치 정보 구현 (여러 사용자에 대해서 하나의 화면에 위치 공유)
+- 상태관리
+ - @Zen :: Test 코드의 장점은 유지보수/리팩토링에서 사이드이팩트를 감소시킬 때 나온다고 생각합니다. 이에 따라서, 전부 전역 상태관리를 해보지 않았다면, `useContext`로 먼저 구현을 하고, 그 다음에 리팩토링을 하면서 그때 상황에 맞추어서 전역 상태관리 툴을 선택해서 도입해도 괜찮을 것 같습니다. 멘토님을 뛰어넘어보죠.
+
+#### ⚙️ Back-End
+
+- TDD
+ - @Zen :: 초반에는 맡기겠습니다.
+ - @혜인 정 :: 백앤드 홀로 도전하는 것 자체가 도전
+ - @혜인 정 :: 새로운 기술에 도전하는게 도전. 백앤드로 구현하는 것 자체가 도전이다.
+ - @혜인 정 :: 사용될 기술이 아직 몰라서 뭐가 있다고 말을 하기 어렵다. Websocket 등의 네트워크 적인 것을 좀 알아갈 수 있지 않을까 (추측)
+
+ - @Zen :: 계정 알려드릴게요. 아니면 필요하면 말씀하시면 API키나 이런거 다 드릴게요. ⇒ 저는 24시 Zep 상주중
+
+- 코드리뷰
+ - @Zen :: 코드리뷰 백 프론트 안가리고 저희 합시다. ⇒ 코드리뷰 + PR리뷰를 백이라 안하는게 아니라 프론트도 백을 봐주고, 백도 프론트 봐주는…
+ - @Zen :: 해봐야 알거같고.. 이런 룰들은 매주마다 개선해야 된다고 생각
+ - 4명이 전부 Approve해야 Merge 되는걸로…?
+ - @혜인 정 :: 초반에 적게 봤으면 좋겠다. 그 사실상 처음이니까 에로사항이 있을수도 있을 것 같다. 그래서 초반에는 학습시간까지 고려해서 초반에 PR이 적을 수 있다. 그니까 주기를 조금 덜 가져갔으면 한다.
+
+### 📝 팀 구성
+
+#### 🧑💻 Front-End
+
+- @Zen
+- @동율 이
+- @주원 김
+
+#### 🧑💻 Back-End (Full-Stack - 나중에 백 구현 끝나면 프론트 합류 예정)
+
+- @혜인 정
+
+#### 📝 기술 스택
+
+#### ⚙️ Front-End
+
+- `React`
+- `TypeScript`
+
+- 논의해볼 사항
+ - node.js 모듈 관리는 무엇으로? (pnpm, NPM, bun, yarn 등)
+ - @Zen :: 개인적으로는 pnpm 선호합니다.
+ - `pnpm`
+ - 자바스크립트 컴파일러는 무엇으로?
+ - `swc` → `vite`
+ - swc :: rust → 성능이 좋고, 평소 쓴대로
+ - tsc :: c → 나쁨, 다만 평소 쓴대로
+ - 번들러/빌더는 무엇으로?
+ - webpack
+ - `vite`
+ - 테스트 도구는 무엇으로?
+ - jest
+ - CJS 디폴트
+ - `vitest`
+ - import/export :: ESM 디폴트
+ - `storybook`
+ - `msw` :: 서버가 실제로 있는 느낌
+ - 서버 통신에 대한 모킹
+
+- pnpm
+- swc
+- vite
+- vitest
+- storybook
+- msw
+
+→ 기술적인 완성도라고 하면, 테스트가 잘 짜여져서 코드품질이 잛 보장되는 코드
+
+#### ⚙️ Back-End
+
+- `Node.js`
+- `Javascript`
+- `pnpm` :: 개발환경
+- `express`
+
+#### ⚙️ 개발 환경
+
+-
+
+- 논의해볼 사항
+ - `모노레포`
+
+---
+
+- 기술 좀더 구체적으로 빠르게 선정하고 (환경설정)
+- 기능 구현 어떻게 할지 논의해봅시다.
+- 이걸 바탕으로 PAI나 기능 테스트 등 조사해야하는게 있는데, 이거 이번주에 빠르게 하고 가능한지 불가능한지 뽑아냅시다.
+- 피그마
+- 그리고 일정 산출
+
+---
+
+## 🚀 Figma 기반으로 프로젝트 진행
+
+
+
+
+
+
+
+### 네이버지도 api
+
+@혜인 정 :: https://api.ncloud-docs.com/docs/ai-naver-mapsdirections-driving
+
+@혜인 정 :: 자동차로만 가능
+
+
+
+#### 대중교통으로 길찾기 API
+
+[https://developers.google.com/maps/documentation/routes/transit-route?hl=ko](https://developers.google.com/maps/documentation/routes/transit-route?hl=ko)
+
+#### 대중교통으로 길찾기 예시
+
+@혜인 정 :: 공공데이터포털에서 정류소별 버스 도착 예정 시간을 따로 불러와서 우리가 합쳐주는 작업 필요
+
+아래 예시 참고
+
+[https://lab.odsay.com/guide/guide#guideWeb_2](https://lab.odsay.com/guide/guide#guideWeb_2)
+
+#### 경로선 그리기
+
+[https://kimmandooo.tistory.com/138](https://kimmandooo.tistory.com/138)
+
+---
+
+[NAVER Maps API v3](https://navermaps.github.io/maps.js.ncp/docs/tutorial-digest.example.html)
+
+[[TMAP] TMAP API 도보 길찾기](https://velog.io/@ghenmaru/TMAP-TMAP-API-%EB%8F%84%EB%B3%B4-%EA%B8%B8%EC%B0%BE%EA%B8%B0)
+
+[Guide | T MAP API](https://tmapapi.tmapmobility.com/)
+
+[Guide | T MAP API](https://tmapapi.tmapmobility.com/main.html#webservice/docs/tmapRoutePedestrianDoc)
+
+[https://tmapapi.tmapmobility.com/main.html#webservice/sample/WebSamplePedestrian](https://tmapapi.tmapmobility.com/main.html#webservice/sample/WebSamplePedestrian)
+
+[네이버 지도 JavaScript API 완벽 가이드 – 오버레이 편](https://d2.naver.com/helloworld/3380225)
+
+[앱 제작 (3) 네이버지도 유틸 앱](https://gift123.tistory.com/28)
+
+[[iOS] NaverMap API - Directions(네비게이션 루트 기능)](https://d0ngurrrrrrr.tistory.com/202)
+
+## 🧑💻 테스트할 수 있는 방법
+
+[NAVER Maps API v3](https://navermaps.github.io/maps.js.ncp/docs/tutorial-polyline-dynamic.example.html)
+
+1. 실시간으로 GPS 공유 (실시간으로 위치 파악이 가능한지)
+2. 다중 GPS 실시간 공유 (동시에 여러 사용자가 GPS를 공유할 수 있는지)
+3. GPS 바탕으로 지도 위에 찍을 수 있는지 (마커에 대한 CRUD 작업)
+4. 마커를 바탕으로 경로를 그릴 수 있는지
+
+- [[기능 테스트 (socket)|기능 테스트 (socket)]]
+- [[기능 테스트 (지도 API)|기능 테스트 (지도 API)]]
\ No newline at end of file
diff --git a/docs/docusaurus/docs/archive/minutes/20241031-planning-meeting.mdx b/docs/docusaurus/docs/archive/minutes/20241031-planning-meeting.mdx
new file mode 100644
index 00000000..c2b89ae5
--- /dev/null
+++ b/docs/docusaurus/docs/archive/minutes/20241031-planning-meeting.mdx
@@ -0,0 +1,174 @@
+---
+slug: 20241031-planning-meeting
+title: 📝 [2024-10-31] 기획 회의
+sidebar_position: 5
+sidebar_label: 📝 [2024-10-31] 기획 회의
+keywords: ['회의', '기획']
+tags: [minutes]
+last_update:
+ date: 2024-10-31
+ authors: [zen]
+---
+
+
+## 테스트 진행 현황
+
+@Zen :: 테스트 환경 세팅 (vite, tailwind 등), 네이버 맵 api 사용해서 불러오는 것, polyline 사용해서 마킹 되는지 여부 확인
+
+[[기능 테스트 (socket)|기능 테스트 (socket)]]
+
+[[기능 테스트 (지도 API)|기능 테스트 (지도 API)]]
+
+---
+
+## 네이버 지도 API 관련
+
+네이버에서 @types/navermap 관련한 타입을 전체 정리해둠, 사용하면 됨
+
+준일님 :: tdd는 반대, 테스트는 할 수 있는게 없을듯,
+
+여러가지 놓고 봤을 때 포폴로 쓸 수 있을지? 프론트엔드는 인터렉션, 백엔드는 웹소켓으로 끝날 것 같음
+
+기술적으로도 주제적으로도 사용할 수 있는게 없을듯
+
+→ 시나리오 관련해서 정리 필요
+
+[[사용자 시나리오 by 김주원|사용자 시나리오 by 김주원]]
+
+[[사용자 시나리오 by 임재도|사용자 시나리오 by 임재도]]
+
+[[사용자 시나리오 by 정혜인|사용자 시나리오 by 정혜인]]
+
+[[사용자 시나리오 by 이동율|사용자 시나리오 by 이동율]]
+
+
+## 📝 김주원
+
+- 사용자의 그룹화 → 선은 마트가는 길로 뺴놓겠어.
+- 길을 여러번 꺾이게 그렸는데 경로 하나하나 선택하는 것은 너무 사용자 경험이 떨어진다고 생각.
+- 초록색이 두 칸이 있어도 하나하나
+
+## 📝 정혜인
+
+- 해당 사용자만 보는 것과 같은 관리가 필요하다.
+- 사용자별로 출발지 도착지 마커를 찍고, 그림으로 조작을 하는 것.
+- 정말 저작도구처럼 그리는 느낌
+ - 직선 툴 같이 사용하면 좋을 것 같다. 하나하나 그리는 것보다 직선 툴 처럼 그리는 것.
+
+@주원 김 :: 이미지로 저장하는 방법도 있을 것 같은데 혹시 이건 어떻게 생각하시나요?
+
+@혜인 정, @Zen :: 지도가 커지면 이미지도 커져야 해서 깨질 위험이 있다. 파일이 많아지면 로딩도 오래걸릴 것 같다. 여러 사용자에 대해서 이미지가 겹쳤을 때 `z-index` 설정 등이 어려울 것 같다.
+
+
+## 📝 이동율
+
+- 사용자가 다르거나 다른 경로라면, 탭 만들어서 보여줘도 좋을 것 같다.
+- 핵심은 여러 마커와 지도로 설명한다가 핵심인 거 같다.
+ - 굳이 다른 사람에게 보내는 용도가 아니라, 내가 쓸 수 있도록 지도를 커스텀할 수 있게끔 커스텀을 해도 좋을 것 같다.
+ - 주제가 심플해지면서, 실시간적으로 하는 건 내 위치 정도만 들어가고, 큰 기술도 많이 줄고, 축제를 가거나, 내가 모르는 위치를 가거나 했을 때 그 주변 위치를 잘 모른다.
+ - 매번 확인을 해야하는데, 여행을 가기 전에 미리미리 그려두고 이것만 참고를 한다던지.
+
+## 📝 임재도
+
+- 지도 위에 그리는 걸로 구상해왔는데, 혜인님이 가져오신 선으로 그리는 아이디어가 더 나은듯
+- 처음에는 오전에 얘기했던 것처럼 이미지로 저장하는 것을 생각했는데, 지우개를 생각하면 혜인님 말ㅆ므대로 canvas 사용하는게 더 좋을듯
+- 화면을 이동해서 벗어났을 때는 그림에 대한 렌더링을 아예 해버리지 않는 방식도 괜찮을듯
+- 로그인 기능, **그림 기능** (메인 기능), 지도 기능 (지도 기능은 api로 충분)
+- 기술적 도전 - 리스트화 해둠, 그냥 다 적은거임 (canvas 사용하여 최적화, 반응형 - 옵션, 코드 품질 정도)
+
+10:40 ~ 11:00 : 트랙 1 👁🗨👀
+
+## 서비스 명
+
+- 따라길
+- ~~내비친구~~
+- ~~길동무~~
+- ~~길비서~~
+- ~~따라와길~~
+- ~~안내지기~~
+- 따라오길 @주원 김 2 @동율 이 2 @Zen 2
+- ~~손마중~~
+- ~~손그림~~
+- ~~손그림따라?~~
+- ~~손길~~
+- ~~손길따라~~
+- ~~그림따라길~~
+- ~~이길저길~~
+- ~~따라가는길~~
+- ~~그림따라~~
+- ~~따라지도~~
+- ~~손따라길따라~~
+- 선따라길따라 @Zen : 3 @동율 이 3 @주원 김 3 @혜인 정 제 의견 필요없음…….
+
+- 중장년층 사용자가 쉽게 길 안내를 받을 수 있도록 설계된 웹서비스
+
+---
+
+## 결론
+
+팀명 : 따라따라
+
+프로젝트 제목 : 선따라 길따라 (DDara)
+
+프로젝트 한 줄 소개 : 중장년층 사용자가 쉽게 길 안내를 받게 해주는 모바일 웹서비스
+
+기술 키워드 : #지도, #저작도구, #실시간 위치
+
+깃허브 링크 : [https://github.com/boostcampwm-2024/web28-DDara](https://github.com/boostcampwm-2024/web28-DDara)
+
+---
+
+## 20241101(금)까지 해야 할 일
+
+1. @혜인 정 피그마 기획서 수정
+2. @혜인 정 리드미 작성
+3. @주원 김 @동율 이 필요한 기능 정리 → 기능 추출
+4. @Zen 멘토님께 전달 드릴 문서 작성
+5. @Zen 20241101 발표 준비
+
+## 20241104(월)까지`
+
+1. 커밋 전략 및 코드 컨벤션
+ 1. 에어비앤비 : [https://github.com/airbnb/javascript](https://github.com/airbnb/javascript) (번역본 : [https://github.com/ParkSB/javascript-style-guide](https://github.com/ParkSB/javascript-style-guide))
+ 2. 네이버 : [https://github.com/naver/eslint-config-naver/blob/master/STYLE_GUIDE.md](https://github.com/naver/eslint-config-naver/blob/master/STYLE_GUIDE.md)
+ 3. JavaScript Standard Style **:** [https://standardjs.com/readme-kokr.html](https://standardjs.com/readme-kokr.html)
+2. 타입스크립트 → 옵션 어떻게 줄건지
+3. 테스트 전략
+4. 스토리북 사용법 익혀오기
+ - 각자 해오기로 (프론트)
+5. (백엔드) 혜인님도 스웨거 익혀오기
+6. Vitest
+
+[Vitest 처음 시작하기](https://www.daleseo.com/vitest/)
+
+7. Github action → 자동화
+8. 자동화 배포 어떻게 할건지 → 정해오시면… 편하신걸로…
+9. FE 빌드 및 배포 → `Vercel` 이용하기
+ - @Zen :: 도메인 살꺼에요? → 임시도메인 이용하기
+ - CloudFlare(DNS) → Vercel(Proxy, Router) → 정적배포
+ - 버셀이 검사합니다. 빌드되는지 안되는지
+ - 그래서 항상 코드 PR 날리기 전에 ts build 해보셔야 됨.
+10. WAS → 혜인님 재량
+- @혜인 정
+
+- 월요일 목표는 환경설정 끝내기
+- 만약에 안적은거 잇어도 공유하고 싶은거 있으면 즉각즉각 슬랙에 공유.
+- Zep은 항상 열려있어요 여러분.. 와주세요….
+
+- 저희 기능 테스트 어제 해오신것처럼 가능하면 조금씩 해도 좋아요.
+
+| 태그 이름 | 설명 |
+| --- | --- |
+| Feat | 새로운 기능을 추가할 경우 |
+| Fix | 버그를 고친 경우 |
+| Design | CSS 등 사용자 UI 디자인 변경 |
+| !BREAKING CHANGE | 커다란 API 변경의 경우 |
+| !HOTFIX | 급하게 치명적인 버그를 고쳐야하는 경우 |
+| Style | 코드 포맷 변경, 세미 콜론 누락 등 코드 수정이 없는 경우 |
+| Refactor | 프로덕션 코드 리팩토링 |
+| Comment | 필요한 주석 추가 및 변경 |
+| Docs | 문서를 수정한 경우 |
+| Test | 테스트 추가, 테스트 리팩토링 |
+| Chore | 빌드 테스트 업데이트, 패키지 매니저를 설정하는 경우 (프로덕션 코드 변경 X) |
+| Rename | 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우 |
+| Remove | 파일을 삭제하는 작업만 수행한 경우 |
\ No newline at end of file
diff --git a/docs/docusaurus/docs/archive/minutes/20241104-preparation-meeting.mdx b/docs/docusaurus/docs/archive/minutes/20241104-preparation-meeting.mdx
new file mode 100644
index 00000000..70c17c4b
--- /dev/null
+++ b/docs/docusaurus/docs/archive/minutes/20241104-preparation-meeting.mdx
@@ -0,0 +1,581 @@
+---
+slug: 20241104-preparation-meeting
+title: 📝 [2024-11-04] 사전 작업 회의
+sidebar_position: 6
+sidebar_label: 📝 [2024-11-04] 사전 작업 회의
+keywords: ['회의', '사전 작업']
+tags: [minutes]
+last_update:
+ date: 2024-11-04
+ authors: [zen]
+---
+
+
+## 📝 정리자료
+
+[[⚙️ 환경설정 관련 정리|⚙️ 환경설정 관련 정리]]
+
+## 📝 회의 안건
+
+### 🧑💻 1번 안건 (식사 전)
+
+- 코어시간 및 MH 논의
+- PR 조건에 대해서 재논의
+- 코드리뷰에 대해서도 재논의
+- 문서화 → 기술적인 내용이 들어가는데 어떻게 적을지?
+- 용어사전집
+- 회의록 자동화에 대한 논의 (클로바노트)
+
+### 🧑💻 2번 안건 (식사 이후)
+
+- 컨벤션
+- 브랜치
+- 모노레포 관해서 커밋 메세지 내용도 좀 더 세분화 (FE, BE, story, swagger 등에 대해서 논의)
+- 백로그
+
+### 🧑💻 3번 안건 (시간 남거나 에너지가 남을 경우)
+
+- E2E → End to End Test → 어떻게 보여줄건가? (Cypress 나중 나중 발표 직전. 할지말지)
+- Storybook → 시각화 테스트 → 어떻게 해볼지? (Storybook 때문에 비용이 안듦. 할지말지)
+
+## 📝 오전 회의 내용
+
+### ✏️ 코어시간 및 MH 논의
+
+#### 🗣️ 코어시간에 대한 용어 정의
+
+- @Zen :: 근무시간과 코어시간은 다르다.
+- @혜인 정 :: 우리가 생각하는 코어시간은 근무시간에 가깝지 않았나? MH에 대한 기준만 정해도 될 것 같다. 네부캠 특성 상 큰 분류의 큰 의미는 없을 것 같다.
+- @주원 김 :: 쉬는 시간만 중간중간 갖고, 네부캠 코어시간에는 다 앉아있을 것이기에 그렇다.
+- @Zen :: 10~7시가 코어시간 개념대로라면 맞는거 같고, 그 외는 12시까지는 근무시간으로 두는데, 이떄는 진짜 자유.
+ - 코어시간에는 `Zep` 항상 들어와있기
+ - 그 외에는 자유
+
+#### 🗣️ MH에 대한 논의
+
+- @주원 김 :: MH는 10시간으로 생각하긴 했다. 하루에 2.5 Task를 생각했다. 한 테스크 당 4MH로 잡았다. 코드리뷰나 각자 학습할게 있기 때문에 12시간씩 잡으면 빡빡하지 않을까 생각을 했다. 10시간으로 잡고 다음주에 조정하고 하는게 좋을 것 같다.
+- @Zen :: MH에 코드리뷰나 문서화 이런거 포함시킬건지도 논의해봐야할 것 같다.
+- @혜인 정 :: 생각했던 것은 코드리뷰나 문서화는 다 시간 외라고 생각을 했다. 그때 그렇게 이야기가 된 줄 알았다. 만약에 이게 맞다면, 우리 코어타임 9시간 중 1시간을 빼서 8시간으로 잡아도 될 것 같다. 나는 사실 10시간 12시간 이렇게 되면 이 시간동안 쭉 앉아있어야 하는 것이다. 집중이 빡 안될 것 같다는 문제가 있다. 예를 들어, 10시간 기준으로 0.5 MH로 잡아서 5시간 안에 끝내겠다. 이렇게 되어있는데, 범위가 너무 넓어져버려서 집중이 빡 안될것 같다는 느낌이 있다. 일단 그렇지만 다른 분들의 의견을 따르겠습니다.
+- @동율 이 :: 코드리뷰나 문서화는 시간 외라고 생각을 했다. 이 부분을 제외하면 12시간은 너무 많은 것 같고, 10시간 이내로 잡는게 좋지 않을까 생각하고 있습니다. 물론, 나중에 주차 길어지고, 못한 부분이 많아지면 열심히 해야하는 부분이 많아지면 더 고려해야할 수도 있을 것 같다. 일단 기준점 정도는 10시간 이내로 잡는게 좋지 않을까 생각하고 있습니다.
+- @주원 김 :: 그러면 하루 MH를 8시간으로 잡고, 백로그를 작성할 때 2시간 단위인 작업들을 만들어둬서, 하고 싶은 사람이 있으면 더 가져가면 좋을 것 같다. 코어타임을 더 하라고 강요할 수는 없을 것 같고, 일단은 8시간으로 잡고 0.5 Task 정도로 쪼개놔서 “저 오늘 하나 더 할게요.”하면서 가져가면 좋지 않을까 한다.
+- @혜인 정 :: 좋긴 한데.. 제가 8시간을 주장해서 맞춰주진 않아도 됩니다.
+- @Zen, @동율 이, @주원 김 :: 지칠 수 있으니 8시간으로 잡고, 코드 기가막히게 써지면 더 해도 되고 기본은 8시간.
+- @혜인 정 :: 8시간으로 되지 않을 걸 알기에.. 걱정이 앞섭니다… 사실 8시간 못 지켜질 거 알지만…… 이거라도 정해놔야 심적으로 편할 것 같아요…………
+- @Zen :: 어떤 작업이 주어졌을때, 그걸 다 완수할거기 때문에.. 그냥 8시간은 건강을 위한 기준으로 잡아도 좋을 것 같습니다. 사실, 혜인님 말은 그렇게해도.. 항상 슬랙보면 불켜져있음…
+- @혜인 정 :: 생각이라도 하면서… 심적 부담을 줄이고 싶어요..
+
+#### 📚 정리
+
+- MH는 8시간으로 측정.
+- Task 단위는 0.25MH 2시간.
+- 일 분배 단위는 0.5MH로 잡자.
+
+### ✏️ 코드리뷰에 대한 논의
+
+#### 🗣️ 코드 리뷰를 어떻게 할 것인가?
+
+> 코드리뷰를 어떤 목적을 달성하기 위한 장치로 쓰고 싶으신가요?
+>
+- @주원 김 :: `Vitest`를 이용해서 테스트를 진행하고 있다. 테스트가 알맞게 진행되고 있는가를 확인할 필요가 있다. 테스트가 알맞다면 원래 쓴 코드에 대해서는 안정성이 보장이 된다. 이에 따라서 테스트를 보는 능력을 기르고 싶다.
+ - `Vitest` 를 통한 `Unit Test`를 진행하니까, 테스트 코드가 잘 작성이 되어 있는지, 코드 자체의 분리가 테스트 가능한 코드 단위로 잘 모듈화 되어 있는지 확인하고 싶습니다.
+ - @Zen :: 테스트코드에 대한 최소조건을 정하자. (실패케이스 몇개, 성공케이스 몇개) → 나중에 이야기
+- @주원 김 :: 데일리스크럼, 코드를 이해하는 목적이다. 질문을 미리 남겨둘 수 있는 장치로 쓰고 싶다. 다음날 데일리스크럼에서 질문을 하게 되면 서로 질문할 시간도 없고, 머리가 안돌아가는 타이밍이니 궁금한거 있으면 미리 좀 적어주면 질문을 받을 사람도 미리 준비할 수 있는 시간이 될 것 같다.
+- @혜인 정 :: 우리끼리 코드리뷰 하는 건 엄청난 실력향상이 된다거나, 코드를 더 잘짜게 된다거나 이런건 적을 것 같다. 시니어 분들이 봐주는게 아니라서, 경험 수준이 비슷하기 때문이다. 제가 느끼는 코드리뷰의 목적은 팀원들이 뭘 하고 있는지 서로의 현황을 알고, 질문을 남겨두거나, 피드백을 남겨두기 위한 장치로 생각했다.
+- @Zen :: **“누가 어떤 코드를 짰는지 모르게 하고 싶다.”** - 지식적으로나 코드적으로나 서로가 어떤 작업을 했는지 외부에서 봤을때 아예 모르게. 이런 목표를 달성하기 위한 장치로 코드리뷰를 사용하고 싶습니다.
+- @혜인 정 :: 모두가 지금 코드리뷰의 목표가 “서로에 대한 코드를 보는 것”이 장치만으로 코드를 보는 거라는 생각이 든다. 거창한 코드에 대한 리뷰! 라는 것보다는 PR에 댓글을 남기는 정도가 맞나요? 코드리뷰라는 장치로써, 모두가 어떤 것을 하는 것이 목적이라면..
+- @Zen :: 서로에 대한 작업 이해, 이해에서 나오는 서로에 대한 피드백의 장치로 쓰고 싶습니다.
+- @혜인 정 :: 좋아요.
+
+#### 📚 정리
+
+- 목적 : 서로에 대한 작업 이해, 이해에서 나오는 피드백
+- 방법 :
+ 1. 서로의 코드를 보고 다른 사람들이 작성한 코드를 이해한다.
+ 2. 만약 피드백할 사항이 있다면 피드백을 남긴다.
+ 3. 코드리뷰는 PR Approve 전에 한다.
+ 4. 피드백 사항이 있으면 이를 다 수정해서, 수정이 끝나면 Approve 진행.
+
+### ✏️ PR 조건 논의
+
+#### 🗣️ PR Approve의 조건 논의
+
+@혜인 정 :: PR Approve가 모두의 Approve를 받고 하는 건데, 조금씩 밀리면 많이 쌓이는 경우가 있을 것이라고 생각한다. 4명이 작업하다보니 많이 쌓일 것 같아서, 이건 조금 비현실적인거 같다. 제 생각에는 한명씩 1:1 랜덤으로 돌리는 게 어떨까? 오늘 예를 들어 우리가 코드를 짜서 보냈으면, PR이 4개면 4개의 PR 중에 자동화를 시키는 거다. 작성한 PR 4개 중에 하나를 올리면 자동으로 동율님이 Approve 대상으로 올라가고, 2번 PR을 올렸을때는 재도님이 Approve 하는 거고. 이렇게 계속 섞이게 되면 모두의 코드를 다 볼 수 있게 된다고 생각한다.
+
+- 랜덤으로 Approve할 사람을 뽑아서 그 사람이 해당 PR에 대해서 리뷰하게 하자.
+
+@Zen :: Approve의 조건을 2명으로 해보면 어떨까요?
+
+@주원 김, @동율 이, @혜인 정 :: 좋습니다.
+
+#### 🗣️ PR 날라오면 몇 시간 내로 리뷰할 것인가?
+
+@혜인 정 :: 현실적으로 시간을 정하지 않았으면 좋겠습니다. 저희 모두가 해야하는데 미루지는 않지 않을까 하는 생각이 들어서, 시간을 정해서 오늘까지면, 더 중요하게 작업해야 하는 게 있는데 우선순위가 꼬여버릴 것 같다는 생각이 있습니다.
+
+@주원 김 :: 당일까지로 하나요?
+
+@혜인 정 :: 그것도 정해두지말자긴 했는데, 우리 스스로의 제제가 필요할지 진짜 진짜 모르겠습니다.(I don’t know) 다른 분들 의견 듣고 싶어요. 이거 ㅈ니짠 모르겠음
+
+@주원 김 :: 코어시간에 잡은 것은 당일 내에 하고, 추가 작업을 한 것은 늦어도 다음날까지 하면 좋지 않을까 했습니다.
+
+@Zen :: 못해도 다음날 오전 10시 전(데일리스크럼 전)까지는 PR 요청이 비어있으면 합니다.. 주말은 제외 쉬셔야죠. 다음 작업 사이클 전까지 머지가 안되면 한번에 머지 시에 충돌이 엄청날꺼같아서 그렇습니다.
+
+@동율 이 :: 주원님 말씀에 동의하는게, 코어 시간에 작업한건 당일 자정(오후 11시 59분)까지 리뷰 완수, 그리고 추가 작업 분에 대해서는 언제 올라올 지 모르니 다음날 오전 10시 전까지 완수.
+
+@Zen, @혜인 정, @주원 김 :: 좋습니다.
+
+#### 📚 정리
+
+- PR 리뷰를 하면서 코드리뷰도 같이 한다. 즉, PR리뷰 === 코드리뷰
+- 테스크 분배해서 당일에 작업된 작업물에 대해서는 당일 자정(오후 11:59)까지 완수한다.
+- 팀원 개인적으로 추가 작업한 사항에 대해서는 다음날 10시까지 완수한다.
+- 이유 :: 밀려서 한번에 머지를 할 경우 충돌이 날 가능성이 있기 때문에, 다음 작업 싸이클 전까지는 PR이 다 처리되도록 한다.
+
+### ✏️ 문서화에 대한 논의
+
+#### 🗣️ 기술문서에 대한 안건
+
+- 안건 - @Zen :: `wiki`라고 하면 `나무위키`생각하면 된다. 저희의 기술 내용에 대한 설명이자, 동시에 학습 등 관련되서 처리한 프로젝트에 대한 과정 및 결과물에 대한 정보.
+ 1. `github wiki`를 어떻게 관리할 것인가?
+ 2. 기술 문서를 어떻게 적을 것인가?
+
+#### 🗣️ `Github wiki`를 어떻게 관리할 것인가?
+
+- @주원 김 :: github wiki는 노션에 있는 걸 옮기는 건가요?
+- @Zen :: 논의해봐야한다. 지금 쌓인거 옮기는 것도 일이다.
+- @혜인 정 :: 제가 해봤을 떄는 꺠지는 것은 인용만 꺠지고, 나머지는 안깨졌던 것 같아요. 데이터베이스 등도 다 되었던 거로 기억하는데 아닌가요?
+
+- @Zen :: `wiki`를 어떤 목적으로 쓸 것인가를 먼저 논의해봐야할 것 같아요.
+
+#### 🗣️ `wiki`를 어떤 목적으로 쓸 것인가
+
+> 아카이빙 목적으로 노션에 있는 자료를 다 migration 할 것인지, 아니면 정제해서 정리된 것들만 딱!딱! 올릴 건지
+>
+- @혜인 정 :: 재도님이 생각한 목적은 무엇이었나요?
+- @Zen :: 아카이빙 목적이었습니다.
+- @주원 김 :: 정제는 각자 블로그나, 여기에 하고, 아카이빙 목적으로 하자.
+- @Zen :: 회의록 아카이빙시 노션을 그대로 깃허브에 옮기고, 디렉토리 구조도 그대로 가져갈 생각이었습니다. 이에 대한 예시는 아래와 같습니다.
+- 루트
+ - 팀 소개
+ - 팀원
+ - 회의
+ - 데일리 스크럼
+ - 회의록
+ - 회의록 정리
+ - 회의록
+ - 사전 준비록
+ - 기술문서
+ - FE
+ - React
+ - Test
+ - BE
+ - WebServer
+ - WAS
+ - DB
+ - 환경설정
+
+- @혜인 정 :: `Migration` 비용이 많이 발생하지 않을까 하는 우려사항이 있습니다. 궁금한게 사실 노션 링크를 적어도 되잖아요? 깃허브 위키에 똑같이 적으려는 이유가 있나요?
+- @Zen :: 여러가지 이유가 있다.
+ 1. 노션 들어오는 거 자체를 싫어하는 분들이 많다.
+ - 링크 열고, 로딩하고, 새 창띄우는게 생각보다 짜증이 많이남.
+ - 포폴로 쓰겠다고 하면, 면접관은 우리에게 20초정도 쓰면 많이 쓴거. → 이걸 다 로딩시간으로 쓰긴 아깝다.
+ 2. `개발바닥` 에서 라이브가 있었다.
+ - 이력서+포폴 첨삭, 노션으로 제출한사람들 일단 다 짤랐습니다.
+ - 위키에 다 박아라. 그래야 우리도 포폴 볼때 프로젝트 한번에 보지 않겠느냐?
+ 3. 사실 `wiki`든, `notion`이든 안본다고 보는 게 맞긴 하다. 관심있는 몇개만 보지.
+ - 그때에 한번 들어와서 다른것도 겸사겸사 한번만 클릭해볼까? 하는 마음이 있을 때 비용을 줄여주면 아낀 에너지로 다른 것도 보게 됨.
+ - 심리적인 것을 이용함.
+- @혜인 정 :: 어쩃든 포폴로써 가치가 있기 위해서, 보여주기 위해서라면… 그리고 이거 하나하나 옮기는게 비용이 많이 들거라 생각한다. 물론 어느정도일지는 모르겠지만, 다 마치고 넣는건 어떤가?
+- @Zen :: 처음 틀만 잘 잡히면, 문서 어차피 적잖아요? 그러면 적을때 MD으로 빼서 같이 넣는건 매순간했을때 비용이 크게 안든다. 총량으로 봤을때는 같지만, 그걸 되게 작은 단위로 쪼개서 매일 한다고 생각? 한다고 하면 이에 대한 초기작업은 제가 하겠습니다. 그 이후는 팀원이 그때그때 올려도 될 것 같아요.
+ - @Zen :: 개인적인 욕심이긴 한데, 저희가 TypeDOC(JSDOC, TSDOC) + Storybook + Swagger 등도 쓰니까, 이거 하나로 다 묶어서 저희 기술문서를 만들고 싶기도 합니다.
+ - JSDoc, TSDoc 컨벤션은 이따 논의
+ - 다 끝나고 저희만의 기술문서 사이트 만들면 어떨까 했습니다. → `vercel` 무료로 계속 사용가능하니까… (관련해서는 나중에 곰터뷰 참고하셔도 좋을것 같아요.)
+
+#### 📚 정리
+
+- 위키는 아카이빙 목적으로 사용한다.
+- 노션에 있는 내용을 그대로 위키에 서술한다. 디렉토리 구조는 노션을 따른다.
+- 포폴에서 보여주기 위한 목적이다.
+- 코드 자체에 대한 내용은 노션이나 깃허브에 업로드하는 것이 아닌 `TSDoc`, `JSDoc`, `Storybook`, `Swagger`를 이용한다.
+- 최종적으로, 위키와 이걸 합쳐서 우리만의 기술 문서 사이트를 열고 배포한다.
+
+### ✏️ 용어사전집
+
+> 컨벤션이긴 하다. 우리는 이 용어를 이런 의미로 쓴다를 정리해둔것.
+ex. 피그마에 경로방 등이 있는데 이런걸 어떻게 지칭할지 정하자는 거. 그리고, 그걸 단순히 저희끼리만 아는 게 아니라 문서화 하는거.
+>
+
+#### 🗣️ 도입에 대한 내용
+
+- @Zen, @혜인 정, @주원 김, @동율 이 :: 좋습니다.
+- @주원 김 :: 이렇게 되면, `경로 드로우` 이런 식으로 저희가 이름을 붙이는 건가요?
+ - @Zen :: 네! 그렇게 하면 좋을 것 같고, 이게 모호할 수 있어서 문서로 명세하면 좋을 것 같아서 제안해봤습니다.
+- @혜인 정 :: 노션 최상단에다가 용어 사전집을 추가해서, 표처럼 만들고, 모두가 동의한 것을 하나씩 추가하고, 마지막에 완전 배포할 때 위키에 넣어도 될 것 같습니다. 완성이 되었을 떄 넣으면 좋을 것 같아요.
+
+#### 📚 정리
+
+- 용어사전집 만든다.
+- 우리가 용어를 지칭하고, 이에 대한 설명을 적는다.
+- 노션의 루트에 항목을 만들고 지속적으로 업데이트 한다.
+- 최종본이 나왔을 경우에 그때 가서 위키에 추가한다. (그 전까지는 보류)
+
+### ✏️ 회의록 자동화에 대한 논의
+
+#### 🗣️내 클로바노트의 사용에 대한 논의
+
+- @혜인 정 :: 내일부터 제가 클로바 노트로 해볼게요. 제가 썼을떄는 한창 나왔을떄라 다 무료였는데, 요약까지는 크레딧이 있어야하는지는 모르겠어요.
+- @Zen :: 대화본이 전부다 적혀있었으면 합니다. → GPT 요약이 훨씬 나아서… 네이버에겐 미안하지만…
+ - @Zen :: Claude, GPT 둘다 결제하려구요.
+ - @Zen :: 내일까지는 이렇게 적기도 하고, 클로바 노트도 사용. 대신에 만약에 클로바노트가 잘 적어지면 모래부터는 그냥 클로바노트만. 이렇게.
+
+#### 📚 정리
+
+- 클로바 노트 사용한다.
+- 2024년 11월 05일 화요일에 클로바노트 사용 및 지금처럼 회의록 작성을 하면서, 클로바노트가 우리가 사용하고자 하는 목적대로 동작하는지 테스트한다.
+- 클로바노트는 요약이 아닌, 회의록 적문을 적는 기능을 목적으로 한다.
+
+---
+
+- 점심시간 : 11시 45분 ~ 13시 00분까지
+- 장소 : Zep
+
+## 📝 오후 회의 안건
+
+### ✏️ 모노레포에 관한 논의
+
+> 1. 모노레포에 대한 개념 일치
+2. 디렉토리 구성을 어떻게 할지
+3. 자동화 도구 뭐쓸지
+>
+
+#### 🗣️ 모노레포에 대한 개념 일치
+
+@Zen :: 모노레포가 깊게 들어가면 진짜 복잡한데, 간단하게 써보려면 어느정도면 될까요?
+
+@혜인 정 전에 이야기했던 것처럼, 백엔드 프론트 함께 한 디렉토리에 넣은 것
+
+@주원 김 :: 지금까지 해온 것처럼 슬랙에 정리한 것처럼 정리하려고, 모노레포를 하라고 한 게 아닐까 싶었다. 기술적 도전보다는 레포 안에 프론트앤드 백앤드 폴더가 있으면 되지 않을까 싶다.
+
+@혜인 정 :: fe, be가 독립적으로
+
+-root
+
+-FE
+
+-package.json
+
+-tsconfig
+
+-BE
+
+-package.json
+
+-.git
+
+- eslint
+
+- prettier
+
+-husky
+
+-package.json ⇒ eslint 설치 + prettier 설치 + 관련해서 환경설정 데이터들…
+
+- 진짜 공통으로 들어가는 것 외에는 아무것도 들어가지 않게 하자.
+- 실행 권한을 다시한번 주자
+
+-readme.md
+
+@주원 김 :: 원래 레포지토리를 따로 해야하는 데 하나만 짜야하는 구조로 생각했다.
+
+@Zen :: 둘 다 독립적인 프로세스, git커밋을 제외하고는 아예 다르게 동작, cd했을때 각각 디렉토리 들어가서 조작, 컨벤션도 각각 따로? 인가요…?
+
+@혜인 정 :: 공통되는 건 eslint 같은 설정 FE, BE
+
+#### 📚 정리
+
+```markdown
+프로젝트 루트
+│
+├── README.md # 프로젝트 전반적인 설명, 설정 방법 등
+├── package.json # 루트 공통 패키지 및 스크립트 관리
+├── .eslintrc.js # 공통 ESLint 설정
+├── .prettierrc # 공통 Prettier 설정
+├── ignore 파일들(.gitignore 등) # 무시 파일 설정
+│
+├── FE # 프론트엔드 패키지
+│ ├── package.json # 프론트엔드 전용 패키지 관리
+│ ├── tsconfig.json # 프론트엔드 전용 TypeScript 설정 (루트 설정을 확장)
+│ ├── src # FE 코드가 들어가는 폴더
+│ │ └── index.tsx # FE 시작 파일
+│ └── ... # 기타 FE 관련 파일 및 폴더
+│
+├── BE # 백엔드 패키지
+│ ├── package.json # 백엔드 전용 패키지 관리
+│ ├── src # BE 코드가 들어가는 폴더
+│ │ └── index.js # BE 시작 파일
+│ └── ... # 기타 BE 관련 파일 및 폴더
+│
+└── .husky # Husky를 통한 Git Hook 관리
+ ├── pre-commit # 커밋 전에 실행할 스크립트 (ESLint, Prettier 등)
+ └── ... # 기타 Husky 관련 설정 파일
+```
+
+- 자동화도구는 별도로 사용하지 않고 pnpm으로 관리
+- package.json 명령어는 아래를 참고
+
+[pnpm으로 모노레포 환경 구축하기](https://bepyan.github.io/blog/dev-setting/pnpm-monorepo)
+
+
+### ✏️ 브렌치 전략에 대한 논의
+
+> 1. 브랜치 어떻게 명명할지
+2. 버전관리 어떻게 할지
+3. 배포전략
+4. 커밋 관련된 메세지 내용들은 어떻게 할지(브렌치 전략에서 논의해도 무방)
+>
+
+#### 🗣️ 브렌치 전략 생각해오신게 있나요?
+
+@혜인 정 deploy, develop (dev), feature/ , fix/ (깃 플로우)
+
+@동율 이 :: 깃허브 플로우, 깃플로우 두가지 전략을 알아보았다. 우리가 모듈화도 생각하고 있고, 안정성도 생각하는 부분이 있다. 이런 부분 잘 하려면 시간 조금 들더라도 Git Flow 써서 develop 등을 써서 하는게 좋지 않을까 하는 생각을 했다.
+
+@주원 김 :: 깃플로우가 나을 것 같습니다.
+
+[[GIT] 📈 깃 브랜치 전략 정리 - Github Flow / Git Flow](https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5)
+
+[우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그](https://techblog.woowahan.com/2553/)
+
+#### 📚 정리
+
+- 깃플로우 방식으로 진행 → 학습이 좀 필요할거 같으니 이건 본격적으로 코드작성 들어가기전에 이야기 (환경설정때)
+
+#### 🗣️ 브렌치 명명 전략은 어떻게 할 것인가?
+
+
+
+
+- 자료출처 : [인파님 블로그](https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5)
+- @Zen :: feature-fe-[이슈나 테스크명]-[세부내용] 이런식으로 적어보면 어떨까요?
+- @혜인 정 :: feature/fe/[이슈나 테스크명 넘버명]-[내용]-[세부 내용], 분리가 된다고 생각해서 이렇게 표기했습니다.
+- @Zen :: /가 좋은거 같아요.
+
+#### 📚 정리
+
+- [git flow 명명]/[fe/be]/[이슈나 테스트의 넘버링]-[내용]-[세부내용]
+- 예: feature/fe/01-로그인-UI구현
+
+### 🗣️ 버전관리
+
+> 0.0.1 등과 관련된 내용입니다.
+
+- @Zen :: 매주 배포를 해야하는데… 이걸 마이너로 취급한다고 치면 0.1로 갈건지 이런거…?
+- @혜인 정 :: 아직은 개발 단계라서 6주차 완성이 끝나고 버전이 그게 0.0.0이 되고 6주 이후에 버전 업그레이드를 해야하지 않을까 하는 생각이 듭니다.
+- @주원 김 :: 개발을 하면서 완성이 되고 수정하면서 기능을 늘려야 버전이 올라가는게 맞지 않나 싶어서 6주 이후에 버전이 올라가는게 맞지 않나 싶었습니다.
+- @동율 이 :: 개발이 끝나고 하는 게 나을 것 같습니다.
+
+#### 📚 정리
+
+- 버전관리는 개발이 끝나고 부터 생각. 즉, 개발이 끝난 시점이 0.0.0으로 취급. (나중에 정확한 버전은 생각)
+- 리팩토링 직전에 다시 논의
+
+[HeadVer - 기민한 프로덕트 팀을 위한 새로운 버저닝 시스템](https://techblog.lycorp.co.jp/ko/headver-new-versioning-system-for-product-teams)
+
+- 참고자료
+
+#### 🗣️ 배포 전략
+
+- @Zen :: Git Flow 전략 쓰기로 한 이상 배포는 Master가 업그레이드 되었을 때 하면 좋을 것 같습니다.
+- @혜인 정 :: 금요일마다 하는거에 굳이 힘을 쏟을 필요는 없어서 `develop` 브렌치를 보여줘도 될 것 같습니다.
+- @Zen :: 저희 그러면 `master`에 올려서 배포하는 것은 6주 이후인가요?
+ - @혜인 정 :: 처음에 계속 `master`에 올리는 건 크게 의미가 없을 것 같아요. 그때 해도 괜찮아 보여요. 4주차 금요일 혹은 5주차부터 배포 시작해서 오류나 이슈 대응
+ - @주원 김 :: 리팩토링 기간을 기점으로 해서 리펙토링 직전에 `master`에 올리고, 그 다음에 리팩토링 하면서 그때부터 계속 `maseter` 에 업데이트된 걸 올려도 좋을 것 같아요.
+- @Zen :: 버전도 나오네요. 리팩토링 직전을 기점으로 이때부터 버전관리 들어가면 되곘네요!
+
+#### 📚 정리
+
+- `Development` 브렌치를 기능 개발 완료 끝나기 전까지 활용 (5주차 전까지 끝내기)
+- 개발 끝나면 `master`에 올림
+- 그때부터 버전관리 하면서 리팩토링 시작
+
+#### 🗣️ 커밋 메세지는 어떻게 할 것인가?
+
+| 태그 이름 | 설명 |
+| --- | --- |
+| Feat | 새로운 기능을 추가할 경우 |
+| Fix | 버그를 고친 경우 |
+| Design | CSS 등 사용자 UI 디자인 변경 |
+| !BREAKING CHANGE | 커다란 API 변경의 경우 |
+| !HOTFIX | 급하게 치명적인 버그를 고쳐야하는 경우 |
+| Style | 코드 포맷 변경, 세미 콜론 누락 등 코드 수정이 없는 경우 |
+| Refactor | 프로덕션 코드 리팩토링 |
+| Comment | 필요한 주석 추가 및 변경 |
+| Docs | 문서를 수정한 경우 |
+| Test | 테스트 추가, 테스트 리팩토링 |
+| Chore | 빌드 테스트 업데이트, 패키지 매니저를 설정하는 경우 (프로덕션 코드 변경 X) |
+| Rename | 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우 |
+| Remove | 파일을 삭제하는 작업만 수행한 경우 |
+
+- @Zen :: 한글 영문 정도만 통일합시다. 의도는 뭐엿냐면, Feat(FE-taskNumber): ~~~~
+- @Zen :: Docs(Storybook):
+- @혜인 정 전 한글 한표요
+
+@혜인 정 이런늑미
+
+```
+[FE][Feat] #1 : 로그인 UI 구현
+
+- OAuth 연동
+- 회원가입과 로그인 로직 구현
+- 로그인, 회원가입 폼 컴포넌트 구현
+```
+
+```
+[FE][Feat][Fix] #1 : 로그인 UI 수정
+
+- OAuth 연동
+- 회원가입과 로그인 로직 구현
+- 로그인, 회원가입 폼 컴포넌트 구현
+```
+
+
+- description은 선택, 만약 쓸거라면 `-` 정도는 붙이기, 제목 다음에 한줄 띄고 작성
+
+#### 📚 정리
+
+- 커밋 메세지는 한글로 작성하기
+- 커밋 메세지 형식은 아래와 같은 규정을 따른다.
+ - `[FE/BE][태그 이름] #{테스크 넘버}` : 로그인 UI 구현
+ - 태그 이름은 여러개 사용 가능
+ - description은 선택, 만약 쓸거라면 `-` 정도는 붙이기, 제목 다음에 한줄 띄고 작성
+ - 그 외 양식은 자유 너무 지저분하지만 않게…
+ - 사용 예시는 아래와 같다.
+
+ ```
+ [FE][Feat] #1 : 로그인 UI 구현
+
+ - OAuth 연동
+ - 회원가입과 로그인 로직 구현
+ - 로그인, 회원가입 폼 컴포넌트 구현
+ ```
+
+- `husky`써서 push할때도 검사하도록 설정
+
+### ✏️ 컨벤션에 대한 논의
+
+> ▸ ESLint 설정
+▸ Prettier 설정
+▸ TSConfig 설정
+▸ React 관련 컨벤션 이야기
+▸ Tailwind 관련 컨벤션 이야기
+>
+
+#### 🗣️ ESLint 어떤 스타일로?
+
+@Zen, @혜인 정, @주원 김, @동율 이 :: 이미 있는거 `npm`에서 다운받아서 최대한 활용하자.
+
+@Zen :: 이미있는거에 몇가지만 +a
+
+
+#### 📚 정리
+
+[GitHub - airbnb/javascript: JavaScript Style Guide](https://github.com/airbnb/javascript?tab=readme-ov-file)
+
+[npm: eslint-config-airbnb](https://www.npmjs.com/package/eslint-config-airbnb)
+
+- `Airbnb Style Guide`로 가고, 그외 세부 설정은 `React` 가이드 쓰기 보다는 걍 우리가 정하기
+
+[npm: eslint-config-airbnb-typescript](https://www.npmjs.com/package/eslint-config-airbnb-typescript)
+
+#### 🗣️ React 관련된 코딩 스타일 컨벤션
+
+#### 📚 정리
+
+```
+export default function Div() { // @주원, @동률 이
+ ...
+}
+
+export function Div() { //
+ ...
+}
+
+export const Div = () => { // @Zen, @혜인 정
+ ...
+}
+```
+
+- @Zen :: 3번인 이유
+ 1. 호이스팅 문제 (화살표 함수는 호이스팅에서 자유롭다.)
+ 2. `export default`를 쓰게되면 코드를 사용하는 입장에서 명명을 맘대로 바꿀 수 있음. → `export`도 안되는 건 아니지만 별도의 요구사항이 있는데, `export default`는 변수에 애초에 담아버릴 수 있음. TS쓰는 의도와 어긋남.
+- 3번으로 결정
+
+
+```
+export const Div = ({prop1, prop2, ...}) => {
+ ...
+}
+
+export const Div = (props: IProps) => {
+ const {prop1, prop2} = props;
+ ...
+}
+
+export const Div = (props: IProps) => {
+ props.prop;
+ props.prop2;
+ ...
+}
+```
+
+- @Zen :: 2번, 3번 중 어느 것으로…?
+ 1. @혜인 정 :: 타입스크립트 썼을 떄 `interface` 가 직관적으로 보인다.
+ 2. @Zen :: `props`가 어디에서 쓰이는지 정확히 파악이 가능하다.
+- @혜인 정 :: 둘다 할당 안하는 경우도 있다.
+- 2, 3번 섞어서 쓰기로 결정. `props` 만 인자로 제대로 받아오자.
+
+```
+interface
+```
+
+- 다 인터페이스로 사용
+- 앞에 `I` 붙이기. (PascallCase)
+- props 쓸때 명명규칙은 `I{컴포넌트명}Props`
+ - 예: `ICustomComponentProps`
+
+#### 🗣️ Prettier 어떻게 할 것인가?
+
+#### 📚 정리
+
+[npm: eslint-plugin-prettier](https://www.npmjs.com/package/eslint-plugin-prettier)
+
+- 위에거 쓰자.
+
+#### 🗣️ Tailwind 컨벤션
+
+#### 📚 정리
+
+[npm: eslint-plugin-tailwindcss](https://www.npmjs.com/package/eslint-plugin-tailwindcss)
+
+- 위에거 씁시다.
+
+#### 🗣️ 변수명 컨벤션
+
+#### 📚 정리
+
+- 상수
+ - 스크리밍 스네이크 케이스(Screaming Snake Case)
+- 변수
+ - camel case
+- 함수명
+ - 동사+명사
+
+https://github.com/ParkSB/javascript-style-guide
+
+- 참고하기
+
+# 📝 백로그 설정
+
+
+
+
+- 정방형 사진 오늘까지 보내주세요 (readme 수정해둘게요)
\ No newline at end of file
diff --git a/docs/docusaurus/docs/archive/minutes/20241105-backlog-meeting.mdx b/docs/docusaurus/docs/archive/minutes/20241105-backlog-meeting.mdx
new file mode 100644
index 00000000..1d8632ad
--- /dev/null
+++ b/docs/docusaurus/docs/archive/minutes/20241105-backlog-meeting.mdx
@@ -0,0 +1,180 @@
+---
+slug: 20241105-backlog-meeting
+title: 📝 [2024-11-05] 백로그 회의
+sidebar_position: 7
+sidebar_label: 📝 [2024-11-05] 백로그 회의
+keywords: ['회의', '백로그']
+tags: [minutes]
+last_update:
+ date: 2024-11-05
+ authors: [zen]
+---
+
+## 📝 참고 자료
+
+[[⚙️ 환경 설정 과정|⚙️ 환경 설정 과정]]
+
+
+## 📝 회의 안건
+
+### 🧑💻 1번 안건 (식사 전)
+
+> 간단하게 브레인 워밍업하면서, 진행상황 공유
+>
+- 환경 설정 내용 공유
+- 위키 작성 내용 공유
+- 백로그 작성 내용 공유
+- 백로그 추가 논의
+- 나머지 세팅 (@Zen)
+
+### 🧑💻 2번 안건 (식사 이후)
+
+- 백로그 작성 및 수정
+
+### 🧑💻 3번 안건 (시간 남거나 에너지가 남을 경우)
+
+- E2E → End to End Test → 어떻게 보여줄건가? (Cypress 나중 나중 발표 직전. 할지말지)
+- Storybook → 시각화 테스트 → 어떻게 해볼지? (Storybook 때문에 비용이 안듦. 할지말지)
+
+## 📝 오전 회의
+
+### ✏️ 작업 진행 상황 공유
+
+#### 🗣️ 환경 설정 공유
+
+@Zen :: Github Action, Hook, Github 브랜치 옵션 설정(Main에 Approve없이 머지 안되는 것과 같은) 요소들 설정
+
+- 자세한 내용은 아래 문서 참고
+
+[환경 설정 과정](https://www.notion.so/134b1b2b6491805a9ecec64c898bfddd?pvs=21)
+
+@Zen :: 현재 `ESLint`, `Prettier`, `FE Vite` 설정 작업중. 점심까지 끝내놓을 예정
+
+#### 🗣️ 위키 작성 내용 공유
+
+@혜인 정 :: 위키 작성 내용 공유
+
+@혜인 정 :: 위키 페이지 추가하는 경우 사용법
+
+#### 🗣️ 백로그 작성 내용 공유
+
+> 했던 내용 먼저 공유 이후 논의
+>
+
+@Zen, @혜인 정 :: 범주를 먼저 잘 뽑아야 할 것 같아요.
+
+- 사용자 시나리오에 맞춰서 범주화를 하자
+- shadcn을 사용하고, 공통 컴포넌트로 분류하고 나중에 구현하고 싶으면 갈아끼우는 걸로
+
+#### 📚 정리
+
+- 아래의 내용에 대해서 완료.
+- 환경설정 부분만 딜레이 되어서 점심시간까지 처리 예정
+
+#### **📝 20241104 월요일 할일 정리 📝**
+
+**[공통]**
+
+ - 정사각형의 사진 올리기
+
+**[@혜인 정 ]**
+
+ - BE 백로그 작성
+ - README.md 사진 업로드
+ - 깃허브 위키 템플릿 잡기
+
+**[@주원 김 , @동율 이 ]**
+
+ - FE 백로그 작성
+
+**[@Zen ]**
+
+ - Github Action - PR 조건 추가
+ - Github Issue Template 수정 (일단 만들고 이후 논의 예정)
+ - 개발환경 설정
+ - Monorepo
+ - 공통 :: 린트 설정 및 husky 설정
+ - FE :: TS 및 개발 환경 설정 (Airbnb Style Guide 이용)
+
+**[내일 할 일]**
+
+ - 백로그 정리
+ - 환경설정 테스트
+ - Github Action 테스트
+ - PR 테스트 (린트 안맞을 경우 PR이 안되도록 설정)
+ - Github 이슈 테스트
+ - 일 분배후 작업 시작
+
+---
+
+기본적을 설정해야하는 것들
+
+1. 화면 사이즈나 UI적인거 → 아예 배제할 수 없어서 공통적인거 배치만
+ - 사이즈 정하고
+ - 지도 배치하고
+2. 리액트 라우터 → 라우터 잡아야함. ⇒ Figma대로
+ - CSR
+
+- 지도를 로딩하는 사람 → 비용이 듦.
+ - 컴포넌트로 만들어서 줘야함
+ - 스토리북까지
+- 화면 UI적으로 이 지도가 배치될 수 있도록 container만들어져야함.
+
+- 마커 → 따로 ⇒ 너무 세분화
+ - 출발지
+ - 도착지
+- 그 마커를 이어주는 기능 따로
+- 그 데이터들을 전송해주는 기능 따로
+ - 퉁쳐져
+
+넓게 가져가고 → 일 뽑아서 우선순위 가져가고 → 일정에 찍히는건 동율님이 하신것처럼 세분화 되어야함.
+
+작업 분배를 이 기준으로 잡은다음에, 뭉쳐져있는 작업을 작업을 더 세분화 시키는 것 부터 →
+
+뭉쳐서 작업을 가져가고 → 그걸 세분화하는건 각자에게 → 근데, 최대한 세분화시켜서 프로젝트에 반영시켜놔야 함 → 세부 작업 내용 우선순위 분배해서 하나씩 처리
+
+자기가 맡은 일이 끝나면 다른 사람의 세부 테스크보면서 거들어주기
+
+- 상태가 아닌 함수단위로 쪼개져야함 (Function === 기능)
+
+1. 작업을 뭉쳐놓고 우선순위를 스토리단위 단위로 분배
+2. 그 스토리를 누가 가져갈건지 논의하고
+3. 작업 들어갑시다.
+
+---
+
+@주원 김
+
+- 바텀시트가 목표 :: Shadcn XXXXXXX
+- 토스 bottom sheet → 전세계에서 제일 잘 만듦
+- 희망 작업
+ - UI/UX: 메인프레임 WireFrame 작업
+ - 선그리기
+
+@Zen
+
+- 희망 작업
+ - 지도랑 캔버스 연동 + 지도 붙이기
+ - 손녀기준
+
+@동율 이
+
+- 희망 작업
+ - 마커찍기
+ - 채널 추가 및 수정
+ - Form 관련된거
+
+- 네부캠에 원하기도 하고.. 점검 목록이라
+- 작업은 알아서 하되, 저렇게 나눠야 우리가 서로가 뭐하는 지 알 수 있음
+- 분배해서 데일리스크럼때 말하기 MH랑
+ - 데일리스크럼때 서로 피드백 → 대부분이 많이잡을 거 같음.
+ - 일요일 자정까지가 데드라인
+ - 월요일에는 합칩시다.
+- Branch 파서 → 계속 여기에 push
+
+- @혜인 정 :: 각각 맡은 기능이 큰 범위의 작업이다. 이걸 하나의 PR로 올리는 거다. 마커찍는거에도 출발지 마커 찍는거, 도착지 마커찍는거 커밋하기
+ - 세부사항은 최대한 잘게잘게 쪼개서 커밋하는 것을 습관화하는 걸로 하자.
+ - 본인이 생각하기에 적당히 하나의 큰 기능이다 싶으면 PR날리기.
+- @혜인 정 :: `wiki` 제가 맡아서 할게요.
+
+- 해보고 에로사항있으면 처리
\ No newline at end of file
diff --git a/docs/docusaurus/docs/archive/minutes/_category_.json b/docs/docusaurus/docs/archive/minutes/_category_.json
new file mode 100644
index 00000000..08c9ed02
--- /dev/null
+++ b/docs/docusaurus/docs/archive/minutes/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "\uD83D\uDCDD 회의록",
+ "position": 2,
+ "link": {
+ "type": "generated-index",
+ "description": "회의 내용을 기록한 문서입니다."
+ }
+}
diff --git a/docs/docusaurus/docs/archive/prepare/_category_.json b/docs/docusaurus/docs/archive/prepare/_category_.json
new file mode 100644
index 00000000..4c58a53c
--- /dev/null
+++ b/docs/docusaurus/docs/archive/prepare/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "\uD83D\uDCAC 회의 사전 준비록",
+ "position": 3,
+ "link": {
+ "type": "generated-index",
+ "description": "회의 시작 전에 사전 준비 내용을 적어둔 문서입니다."
+ }
+}
diff --git a/docs/docusaurus/docs/archive/review/_category_.json b/docs/docusaurus/docs/archive/review/_category_.json
new file mode 100644
index 00000000..6b9dfaa6
--- /dev/null
+++ b/docs/docusaurus/docs/archive/review/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "\uD83E\uDD14 그룹 회고록",
+ "position": 6,
+ "link": {
+ "type": "generated-index",
+ "description": "한 주간 팀 활동에 대해서 서로의 생각을 나누고, 피드백을 주고받는 회고 문서입니다."
+ }
+}
diff --git a/docs/docusaurus/docs/archive/scrum/_category_.json b/docs/docusaurus/docs/archive/scrum/_category_.json
new file mode 100644
index 00000000..2dee159e
--- /dev/null
+++ b/docs/docusaurus/docs/archive/scrum/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "\uD83C\uDFC3 스크럼 문서",
+ "position": 4,
+ "link": {
+ "type": "generated-index",
+ "description": "데일리 스크럼 내용을 기록한 문서입니다."
+ }
+}
diff --git a/docs/docusaurus/docs/archive/summary/20241022-pre-meeting-summary.mdx b/docs/docusaurus/docs/archive/summary/20241022-pre-meeting-summary.mdx
new file mode 100644
index 00000000..f4a16ce8
--- /dev/null
+++ b/docs/docusaurus/docs/archive/summary/20241022-pre-meeting-summary.mdx
@@ -0,0 +1,262 @@
+---
+slug: 20241022-pre-meeting-summary
+title: 📚 [2024-10-22] 사전 팀 미팅 회의
+sidebar_position: 1
+sidebar_label: 📚 [2024-10-22] 사전 팀 미팅 회의
+keywords: ['팀미팅', '회의']
+tags: [summary]
+last_update:
+ date: 2024-10-22
+ authors: [zen]
+---
+
+## 📝 참고 문서
+
+[사전 팀 미팅 일정 정하기 및 사전 준비](%E1%84%89%E1%85%A1%E1%84%8C%E1%85%A5%E1%86%AB%20%E1%84%90%E1%85%B5%E1%86%B7%20%E1%84%86%E1%85%B5%E1%84%90%E1%85%B5%E1%86%BC%20%E1%84%8B%E1%85%B5%E1%86%AF%E1%84%8C%E1%85%A5%E1%86%BC%20%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%92%E1%85%A1%E1%84%80%E1%85%B5%20%E1%84%86%E1%85%B5%E1%86%BE%20%E1%84%89%E1%85%A1%E1%84%8C%E1%85%A5%E1%86%AB%20%E1%84%8C%E1%85%AE%E1%86%AB%E1%84%87%E1%85%B5%20127b1b2b649180198365f4be386f2f6a.md)
+
+[사전 팀 미팅 일지](%E1%84%89%E1%85%A1%E1%84%8C%E1%85%A5%E1%86%AB%20%E1%84%90%E1%85%B5%E1%86%B7%20%E1%84%86%E1%85%B5%E1%84%90%E1%85%B5%E1%86%BC%20%E1%84%8B%E1%85%B5%E1%86%AF%E1%84%8C%E1%85%B5%20129b1b2b6491808b8722ef85a770c407.md)
+
+## 📝 프로젝트에 대한 공통의 목표
+
+### 🚀 포트폴리오에 쓸 수 있는 실사용자를 위한 서비스
+
+#### **포트폴리오와 실사용자 중심의 목표**
+
+- **포트폴리오에 담을 가치 있는 프로젝트를 개발**: 모든 팀원은 포트폴리오로 활용할 수 있는 완성도 높은 프로젝트를 목표로 한다.
+- **실사용자에게 의미 있는 서비스**: 프로젝트는 실제 사용자에게 도움이 될 수 있는 기능을 제공해야 한다. 재미를 위한 프로젝트일지라도, 명확한 사용자 경험(UX)을 기반으로 해야 함.
+- **유지보수 가능성**: 프로젝트는 지속적으로 유지보수될 수 있도록 설계하며, 최소 1년간 유지보수할 수 있도록 계획을 세운다.
+
+## 📝 기술적인 목표
+
+- 추후 주제가 정해지면 도입
+
+## 📝 프로젝트 개발 원칙
+
+### 😇 사용자 경험(UX) 중심의 개발
+
+- **사용자 경험(UX) 중심 개발**: 기술적인 완성도뿐만 아니라 **사용자의 관점에서 서비스의 유용성**을 고려한다. 기능이 잘 동작할 뿐 아니라, 사용자가 쉽게 이해하고 사용할 수 있어야 한다.
+- **작업 공유 및 문서화**: 모든 작업은 명확히 공유되어야 하며, **GitHub Issue**와 **노션**을 통해 진행 상황과 문제점을 기록한다. 트러블슈팅, 배운 기술, 이슈 등을 꼼꼼히 문서화해 프로젝트의 전체 진행을 기록한다.
+
+## 📝 협업 및 의사소통 규칙
+
+### 💬 잦은 커뮤니케이션을 할 수 있어야 한다.
+
+- **슬랙 및 협업 도구 활용**: 슬랙을 기본 소통 도구로 사용하며, 메시지를 읽었을 때는 **이모지 대신 명확한 답변**을 남겨 소통의 명확성을 유지한다.
+- **실시간 협업 도구 사용**: 실시간 소통이 필요한 경우, `Zep` 또는 `게더타운`을 사용해 비대면 상황에서도 **실시간 피드백과 소통**이 이루어지도록 한다.
+- **코어 타임**: 매일 10시부터 7시까지 코어 타임을 운영하며, 이 시간 동안에는 집중적으로 프로젝트에 참여하고 빠른 피드백을 제공한다. 코어 타임 외에는 자율적으로 활동할 수 있지만, 긴급한 상황에서는 `Zep`, `게더타운` 또는 `슬랙`을 통해 즉각적인 소통이 이루어져야 한다.
+
+## 📝 코드 리뷰 및 PR 규칙
+
+### 🧑💻 4명의 PR Approve 및 최소 주 2회의 코드 리뷰
+
+- **최소 주 2회 코드 리뷰**: 팀원들이 서로의 코드를 리뷰하며, 코드의 품질도 중요하지만, 이때의 핵심은 우리의 컨벤션을 서로 얼마나 잘 지키고 있는지 이다. 코드 리뷰는 팀원의 성장뿐 아니라, **서로의 작업을 이해하고 소통하는 과정**으로 삼는다. 즉, 각자의 개발 맥락을 파악하는 목적을 주로 한다.
+- **PR 승인 규칙**: 4명 모두의 **PR 승인**이 있어야만 기능을 머지할 수 있으며, 모든 팀원이 해당 기능에 대한 충분한 이해를 갖출 수 있도록 한다.
+- **작업의 투명성 유지**: 코드 리뷰와 PR을 통해 프로젝트의 모든 진행이 투명하게 공유되며, 이는 팀원 간의 신뢰를 강화하는 중요한 요소로 작용한다.
+- **데일리 스크럼의 활용:** 이슈나, 코드 공유 등은 데일리 스크럼 시간에 더하여, 아침에 소통하도록 한다.
+
+## 📝 의사결정 방식
+
+### 🤝 팀 전체가 동의하는 의사결정
+
+- **의사결정은 팀 전체가 참여**: 주요 결정은 팀원 모두가 논의하며, GitHub Issue를 통해 정리된 문제점과 해결 방안을 공유한 후, 충분한 근거를 바탕으로 결정한다.
+- **데일리 스크럼**: 매일 아침 **데일리 스크럼**을 통해 각자의 작업 진행 상황을 공유하고, 문제점 및 해결책을 논의한다.
+- **긴급 의사결정**: 필요시 `Zep` 또는 슬랙 언급을 통해 팀원들을 소집해 **긴급 의사결정**을 빠르게 내린다.
+- **내 말좀 들어줘 카드!**: 각자 2 장의 카드가 부여되며, 서로가 납득할만한 수준에서 의견이 대립될 때 사용한다. 사용한 사람의 의견을 무조건적으로 수용한다. (”서로가 납득 가능한 상식선”이라는 전제)
+
+## 📝 작업 분배 및 기록 관리
+
+### 🧑🤝🧑 분업이 아닌 협업
+
+- **작업 기록 관리**: 모든 작업은 노션과 GitHub Pull Request, Issue 등을 통해 **투명하게 관리**된다. 이를 통해 프로젝트의 진행 상황을 쉽게 파악하고, 작업의 흐름을 유지할 수 있다.
+- **스프린트 방식 도입**: 코어 타임 내에서 주어진 작업을 마무리하고, **주 단위로 목표를 설정해 달성 여부를 확인**한다. 스프린트 종료 후 회고를 진행해 다음 스프린트에 반영할 개선점을 도출한다.
+
+## 📝 팀 문화
+
+### 😆 싱글벙글 하하호호 우리들
+
+- **즐겁고 활발한 팀 분위기**: 팀원들 간에 **소통이 원활하고 편안한 분위기**를 유지한다. 스몰톡이나 비공식적인 대화를 통해 팀 분위기를 활기차게 유지하며, 서로의 동기부여를 위해 노력한다.
+- **건강과 워라밸 존중**: 과도한 업무보다는 건강을 최우선으로 고려하며, **휴식이 필요한 경우** 언제든 자유롭게 쉬는 문화를 장려한다. 장기적으로 **지속 가능한 프로젝트**를 목표로 한다.
+- **각자의 의견 존중**: 서로의 의견을 경청하고, 의견 충돌이 발생했을 때는 둘 사이에서 해결보다는 반드시 팀원 전체가 참여하여 논의한다. 이때, 다수결 또는 협의를 통해 해결한다. 필요한 경우 **카드를 사용한 의사결정 방식**(ex: "나 말 좀 하게 해줘 카드")을 도입해 원활한 의사결정을 진행할 수 있도록 한다.
+
+## 📝 프로젝트 회고
+
+### 🎨 Figma, Miro 등을 이용한 시각적인 회고
+
+- **회고 방식**: 프로젝트 진행 중 **KPT(Keep, Problem, Try) 방식**으로 주기적인 회고를 진행해, 잘한 부분과 개선할 점을 분석하고 다음 스프린트에 반영한다. 피드백은 GitHub 또는 피그마 등을 활용해 시각적으로 정리한다.
+- **결과 기록**: 회고 내용과 함께 프로젝트 과정에서의 문제점과 해결 방안을 기록하여 **포트폴리오에서 활용**할 수 있는 자료로 남긴다.
+
+## 📝 긴급 상황 대응
+
+### ‼️ ”이의있소!”
+
+- **TMT, TMI 방지 카드**: 각 팀원은 필요시 언제든지 **"나 힘들다 카드"**를 사용해 TMT, TMI를 막을 수 있다. 이때, 😪, 😴 와 같은 이모지나 기능을 사용해서 알린다.
+- **스톱 카드**: 기술에 대한 학습이나, 구현이 요구사항을 넘어서 너무 깊어질 경우 **"스톱 카드"**를 사용해 중단시키고, 본래 해야하는 업무에 집중시킨다. 이는 PR 리뷰를 하면서든, 언제든지 자유롭게 제안할 수 있다.
+
+------
+
+# 📝 아이디어 브레인 스토밍
+
+| 제안자 | 아이디어 | 예상 사용 기술 | 이유 | 추가 피드백 |
+| --- | --- | --- | --- | --- |
+| @주원 김 | 🗺️ 네이버 지도 개선
+- 오늘의 장소 리스트에 오늘 갈 장소들을 담아둔다
+- 단톡에 이를 공유하면 약속 일정 공유와 함께 장소를 이동할때 바로 해당 링크에서 길안내를 시작할 수 있다
+- 좋았던 여행경로 등을 기록해두고 공유할 수 있다
+
+---------
+
+🤔 확장 (1,2월 기간을 활용해서 더 추가해볼만한 사항)
+1. 경로추천
+- 경로 설정(A,B,C) 3가지 목적지가 있을 경우 A→B→C가 빠른지 B→A→C가 빠른지 등 빠른 경유지 탐색
+2. 3D를 사용
+- 실내(롯데타워 같은 곳에서는 실내 길안내)
+3. AI 사용
+- 여행의 경우에 추가할만한 방문지 추천
+4. 재도님 프로젝트와의 결합?
+- 링크에 접속한 사람들의 실시간 위치를 표시(옵션 추가)
+→ 위치의 정확성 높이기
+→ 어르신 픽업, 흩어져서 놀다가 모이기 등등 | | 이전의 지도는 단톡방에 공유되어있는 장소 정보나 인터넷 검색을 통해 1명이 길찾기를 진행하는 방식으로 진행되어왔다. 따라서 단톡방에 일정을 공유할때 장소 각각에 대한 링크들을 공유하는 것이 아니라 장소들의 목록을 공유하여 번거로움을 줄이고자 한다. | @Zen Travel이라는 어플이 있어요. 이거 벤치마킹 해봐도 재밌을거같음.
+
+실제로 일본여행때 요긴하게씀. → 구글지도 연동 |
+
+| @Zen | 🚀 약속 정하기 위해 사용하는 프로그램
+
+[핵심]
+:: 실시간 위치 추적
+- 지도에 실시간으로 각 사용자의 위치를 표시한다.
+- 이를 보면서 사용자 간의 서로 현재 어느 위치에 있는 지 파악한다
+
+[추가 기능]
+- 실시간 위치 표시를 넘어서 장소에 댓글을 남겨봐도 괜찮을 것 같다. 일종의 추억저장이라 해야 하나…?
+- 1. `WhenToMeet`처럼 시간을 타임테이블 형식으로 정할 수 있었으면 좋겠다.
+- 2. 약속 장소를 리스트업하고, 이를 바탕으로 주변 사람들의 위치를 파악할 수 있었으면 좋겠다.
+- 3. 중간 지점이 되는 장소를 자동으로 찾고, 경로를 알려줬으면 좋겠다. (예상시간까지.)
+- 4. 버스 타는 지점이나 대중교통 타는 지점 등을 알려줬으면 좋겠다.
+- 5. 막차에 대한 정보를 정확하게 제공했으면 좋겠다. 혹은 현재 버스가 어디에 있는지도. | - Geolocation API
+- 네이버 지도 API
+- React
+- React Native | 1. 약속을 정하기 위해서 항상 어려운 것은 다음과 같습니다.
+ - ㄱ) 공통된 시간을 정하는 문제
+ - ㄴ) 중간 지점을 찾는 문제
+
+이에 대해서 뭔가 하나로 합쳐진 서비스가 있었으면 했습니다. (당장 저희만 해도 관련해서 정하는데 꽤 오래 걸렸잖아요? ㅎㅎ)
+
+2. 막차를 제대로 알려주는 서비스가 있었으면 했습니다.
+
+얼마 전 집 근처 지하철역에서 집까지 막차를 타는데, 버스가 16분 후로 찍혀있는 겁니다. 7정거장 전이었고요. 그래서 그런가 보다 했는데 10분 딴짓하다 다시 보니 14분입니다… 그래서 아 뭔가 막히는가 보다 했는데… 20분 더 기다려서 보니 버스가 사라져있습니다…
+아놔… 이러면서 다른 버스를 기다리는데 20분 후 그 버스가 다시 나타나고 6분 후가 되었더군요… 3정거장 전…
+
+심지어 기다리던 다른 버스에서도 비슷한 문제가 발생했습니다.
+
+결국 밖에서 1시간 10분을 기다린 끝에 탔습니다.
+
+이런 경우 다른 건 모르겠고 실시간 버스 위치만 추적이 되어도 괜찮지 않을까 했습니다.
+
+그리고, 이런 기능은 약속 정할 때 실시간 위치 추적과도 크게 기능상 다르지 않을 것 같아서… 이 정도만 있어도 `약속 정하기 위한 프로그램`이 아니라 `버스의 위치 추적`만 제공해도… 저는 이 프로그램을 사용할 거라고 생각했습니다.
+
+3. 저희 조부모님의 동네에는 1시간에 버스가 1대 옵니다. 그리고, 정해진 시각에 도착하는 경우가 거의 없습니다. 현재 위치가 어딘지 몰라서… 조부모님께서는 항상 덥든 춥든 힘든 몸을 이끌고 최소 20분은 대기하십니다.
+
+버스의 위치만을 알아도 이런 문제가 덜하지 않을까 생각했습니다.
+
+4. 조부모님께서 열차로 올라오실 때 서울 지리가 익숙하지 않아서 길을 자주 헤매십니다… 저희가 마중 나가도 위치 파악이 안되어서 헤매는 경우가 많습니다.
+
+이 경우 실시간 위치만 제대로 보여줘도, 그 위치로 저희가 가면 되니까 얼마나 좋을까? 하는 생각이 있었습니다.
+
+5. 약속 때에도 항상 길이 엇갈리는 경우가 생깁니다.
+그런 경우에도 이런 서비스가 있었으면 어떨까 합니다.
+
+6. 위치 서비스를 쓰면 차는 몰라도 도보는 현재 내 위치가 제대로 파악이 안되는 경우가 많습니다. 이걸 프론트엔드의 기술을 써서 해결해보면 어떨까 했습니다. | @혜인 정 부산에서 카카오는 시범운행 하고 있다. 현재 버스 위치를 실시간으로 보여준다.
+
+이미 있는 서비스를 클론코딩 하는 것도 좋지만, 개선하거나 새롭게 했으면 좋겠다.
+
+개발 말고 기획 단계에서 생각해야 하는 부분이 많을 것 같다.
+
+API도 없을 것이다.
+시간이 부족할 것 같다.
+
+@혜인 정 위치를 공유하면서, 카메라로 실시간 위치를 보여주면 좋을 것 같다는 생각이 들었다.
+
+밤에 그런 의도로 활용해도 좋을 것 같다는 생각이 들었다.
+
+위험한 상황이 생기면 경찰에 전화해서 톡톡 같은 번호 2번 누르면 크롬 화면으로 넘어가고, 현재 상황을 보여줄 수 있게 되어 있다.
+
+카메라도 보이고, 위치 서비스도 제공하면서, 경찰에 보내는 건 조금 부담스럽다 이런 느낌일 때 사용하면 좋을 것 같다.
+
+계속 브레인스토밍하는 것이다.
+
+@동율 이 [https://kakaomap.tistory.com/281](https://kakaomap.tistory.com/281)
+요거 이용하면 도착지까지 친구들의 위치와 예상 시간도 알 수 있어요! 저도 최근에 알게 돼서 공유드립니다. |
+
+| @혜인 정 | 🚗 초보자를 위한 운전 연수 웹
+
+네이버 지도의 네비게이션처럼 길을 알려주지만, 현재 위치를 기반으로 해서 유턴을 해야 할 때는 핸들을 꺾는 각도를 함께 보여준다거나, 구간단속이나 비보호 좌회전, 유턴 신호 등 간단하지만 처음에는 헷갈릴 수 있는 규범이 나왔을 때 어떤 용도인지를 목소리로 알려주는 웹앱 | | 부모님이 멀리 계시거나 연수는 비싸서 많이 할 수 없는 경우에는 면허증이 있어도 운전을 시작할 엄두가 안 나는 초보자들을 위해… | @혜인 정 개발이 아니라 기획 단계에서 할게 많아서 제외시키면 좋을 것 같았다. |
+| @혜인 정 | 🧭 위치 기반 날씨 시각화 웹 (백엔드 필요 없을 듯)
+
+사용자의 현재 위치와 날씨 정보를 통해 구름, 비, 눈 등의 날씨 요소를 three.js를 통해 3D로 표현해주는 웹
+(추가로 인구 밀도, 교통량, 미세먼지 등도 표현하면 괜찮을 듯) | | 백엔드 기술이 최대한 들어가지 않는 웹을 생각해보다… | @혜인 정 백엔드 필요 없는 프로젝트가 제일 베스트가 아닐까? 하는 생각에서 아이디어가 시작되었다.
+
+현재 위치를 통해서 지도를 보여주는 것이다.
+그 지도에 날씨 요소를 넣는 것이다.
+
+인구 밀도, 교통량, 미세먼지 등을 표시해주는 것.
+
+현재 위치를 기반으로 하면, 다른 여행지를 갈 때 날씨를 볼 텐데, 다른 지역을 볼 때가 더 효율적이지 않을까 하는 생각이 들고…
+
+뭔가 근거가 충분하지 않은 것 같다.
+
+조금 더 생각해보면 좋을 것 같다. |
+| @혜인 정 | 🚲 여행 기록 3D animation 웹
+
+내가 여태껏 다닌 여행지를 애니메이션 형태(인스타 등에 자랑할 수 있는 형태)의 영상으로 추출해주는 웹.
+개인적으로 ‘내 트리에 놀러와’처럼 그 영상을 서로 공유하는 웹사이트로 만들어도 재밌을 듯.
+
+아래 링크 참고
+
+[https://mult.dev/studio](https://mult.dev/studio) | | 제가 여행을 정말 좋아해서 기록하고 SNS에 공유하는 것을 좋아하는 편인데, 예쁜 애니메이션 형태로 공유할 수 있는 웹사이트가 있으면 좋겠다고 생각하였습니다. (다만 급하게 생각해낸 것이고 현재 실시간 위치를 반영하는 웹은 아니라서, 더 고민해봐야 할 듯…) | @혜인 정 Three.js를 쓸 수 있는 방법을 생각했다.
+
+인스타용으로 많이 쓸 수 있을 것 같았다.
+
+한국인 환경에 맞는 느낌, UI/UX가 별로라서 만들고 싶었다.
+
+@주원 김 카카오 API나 여러 가지로 받아오고, 여행을 한 다음 `Three.js`와 같은 애니메이션으로 경로를 바꿔서 보여주면 좋을 것 같다.
+
+네이버 API, 카카오 API와 합쳐도 재밌을 것 같다는 생각이 들었다.
+
+@혜인 정 이미지를 넣으면 이미지에 위치 정보가 담겨 있으니까, 그 정보를 이용해서 경로를 보여주는 것도 좋을 것 같다. |
+| @혜인 정 | 크리스마스 특집
+
+이건 진짜 아이디어가 아니고 브레인스토밍용인데, 12월 딱 프로젝트 마무리할 때쯤 되면 크리스마스일 테니, ‘내 트리에 놀러와’ 같은 크리스마스 용 웹사이트를 만들어도 재밌을 듯 | | | @혜인 정 뭔지 생각 안 하고 만든 것. 크리스마스 용도로 산타에게 선물을 보낸다거나… FE만 사용해도 쓸 수 있는 그런 걸 만들고 싶었다. |
+| @동율 이 | 여행 도감
+이미 해봤던 아이디어긴 하지만 매우 미약하고 퀄리티가 떨어져서 다시 디벨롭 해보고 싶은 생각이 있습니다!
+기능은 각 도시들마다 유명한 관광지들을 도감에 비활성화 상태로 넣어두고 실제 그 관광지에 들어간 뒤 5분이 지나면 도감에 사진과 글을 등록할 수 있도록 합니다!
+그 이후 각 도시들마다 진행도를 넣고, 등록한 관광지의 수만큼 경험치를 얻거나 크레딧을 얻는 방식입니다!
+이를 Three.js를 사용해서 멋지게 만들어 보거나 혜인님의 아이디어와 결합해도 재밌을 것 같아요!!
+추가적으로는 등록을 위한 여행 루트도 짜주는 시스템도 들어가면 좋을 것 같아요! 시간이 모자라서 구현을 못했던 기능입니다 | | 주제가 공익적이거나 전국적인 사회 문제를 해결할 수 있는 앱이었고, 현재 우리나라는 수도권 집중화가 과도하게 되어 있어, 이를 해결하기 위한 앱이었습니다.
+아무래도 기업을 옮기거나 인프라를 늘리는 방법은 저희가 할 수 없기 때문에, 여행을 통한 유동 인구를 늘려 지역 경제를 활성화시키자는 아이디어로 시작했습니다.
+비인기 도시일수록 크레딧을 많이 주는 방식으로 하면 좋은 방향이 될 수 있을 것 같아요. |
+
+| @동율 이 | 예전에 썼던 건데, 2학년 때 만든 것. 퀄리티가 굉장히 떨어짐.
+
+관광지들을 많이 알려서, 유동 인구를 늘려서 해결하면 되겠다 하는 아이디어에서 출발.
+
+각각 도감이 있다.
+
+직접 그곳으로 가서 실시간으로 위치를 감지해서 반경 몇 미터 이내에 들어가면 활성화가 되고, 사진이랑 글을 넣을 수 있도록 해두었다.
+
+사람들이 많이 안 가는 곳일수록 경험치를 많이 주도록 유도하고자 했다.
+
+수익성도 고려를 했어야 했다.
+
+아직 등록이 안 된 부분은 어떻게 하면 더 재밌게 즐길 수 있을지 플랜도 짤 수 있게 하면 재밌겠다고 생각했다.
+
+여행 도감이라는 아이디어가 괜찮은 것 같다.
+
+그 지역들에 대한 관광지 소개가 괜찮은 것 같다.
+
+이걸 디벨롭 시켜보고자 하는 마음이 있었다. |
+| @Zen | 현실 메시지 | | | @동율 이 재밌을 것 같아요! |
+
+# ⚙️ Zep 개설
+
+[📝 Zep 개설](https://github.com/boostcampwm-2024/web28-DDara/wiki/%F0%9F%93%9D-Zep-%EA%B0%9C%EC%84%A4)
+
diff --git a/docs/docusaurus/docs/archive/summary/20241028-teambuilding-summary.mdx b/docs/docusaurus/docs/archive/summary/20241028-teambuilding-summary.mdx
new file mode 100644
index 00000000..86371ac4
--- /dev/null
+++ b/docs/docusaurus/docs/archive/summary/20241028-teambuilding-summary.mdx
@@ -0,0 +1,106 @@
+---
+slug: 20241028-teambuilding-summary
+title: 📚 [2024-10-28] 팀빌딩 회의 내용 정리
+sidebar_position: 2
+sidebar_label: 📚 [2024-10-28] 팀빌딩 회의 내용 정리
+keywords: ['팀빌딩', '회의']
+tags: [summary]
+last_update:
+ date: 2024-10-28
+ authors: [zen]
+---
+
+> GPT를 통한 정리와 개인적인 정리 내용이 합쳐져 있습니다.
+
+## 🧑💻 팀원 간의 가치 동기화
+
+### 🤔 주제
+
+- 내가 사용할 수 있는 서비스(쓸것 같은 서비스)
+- **“내가 이게 필요한 이유를 팀원 전체가 공감해야 함.”**
+- **설득의 영역이 아니라, 감정의 영역..**
+- 해결할 문제를 정해서 주제를 먼저 정하고 기술을 여기에 맞추자
+
+### 🤔 포트폴리오
+
+- 주원님의 이야기가 나오다 보니 우리는 주제를 바꾸는 건 크게 좋은 선택이 아닌 것 같음
+- 주제에 대한 도메인
+- 위치 기반으로 오기도 했고… 그니까 이 범주 내에서 생각
+
+### 🤔 협업
+
+- @혜인 정 :: “집중할 때 집중하자.” → 심리적 나태함 방지
+- 데드라인을 명확히!
+- 팀적으로 생산성을 극대화하자. → 안되면 바로 옆에 말하고, 작업 상황 빠르게 공유해서 누구 하나 야근 없이 정해진 작업량을 제시간에.
+- 팀의 핵심 기능 개발에 대해서 야근이 있어서는 안된다.
+- 혼자 끙끙거리지 마라.
+- @혜인 정 :: 팀의 핵심 기능 개발에 대해서 주어진 시간을 넘기지 마라. → 곧바로 공유해라.
+- 그 외는 알아서 해도 되는데, 팀에게도 지장이 갈 수 있으니 주의한다.
+- @동율 이 :: 6주가 짧다. → 그러니까 이후에 유지보수로 추가할 생각하지 말고 핵심 기능은 6주에 다 담자.
+- @동율 이 :: 팀이 지치지 않는 것도 중요하니까, 6주가 짧지만 기니까… 컨디션 관리를 할 수 있게 여유를 두자. (완충을 잘 두자.)
+- @주원 김 :: 공통의 목표를 향해서 다 같이 으쌰으쌰하는 경험. → 밤새라는 말은 아님. 비동기 소통을 하든 뭘 하든 문제를 공유하거나 지식을 공유했을 때 피드백이 빨라서 서로 빠르게 몰입했으면 좋겠다.
+- @주원 김 :: 피드백이 빨라서 작업 흐름이 팀적으로 쭉 이어졌으면 좋겠다.
+- @Zen :: 분업이 아닌 협업이었으면 좋겠다.
+- @Zen :: 다 같이 한주에 기능 하나 구현해서 배포를 목적으로 달려들었으면 좋겠다. (일정은 이 범주 내에서 여유롭게 알아서…)
+- 스프린트 백로그 나오면 각자 알아서 가져가서 구현하고 합치는 거…
+
+### 결론 :: 🏃 꾸준하게, 일정하게 🏃
+
+## 🚀 팀 운영 관련 내용 정리
+
+- 네이버 부스트캠프에서 제공하는 크레딧은 @Zen이 수령 후 공유한다.
+- @Zen이 GitHub 퍼블릭 레포를 개설한 뒤 팀원을 초대한다.
+- 익일(10월 29일 화요일)까지 각자 주제에 대한 아이디어를 사전에 작성해서 공유한다.
+- 슬랙에 올라간 팀원 간의 소통 글을 읽고 댓글을 남긴다.
+- 노션에도 글을 읽고 내용을 첨삭하거나 없을 경우 댓글을 남긴다.
+
+## 🚀 팀의 가치와 규칙
+
+- **시간 관리와 작업 집중도**: 각자의 집중도가 떨어지지 않도록 시간 관리를 철저히 하고, 핵심 기능은 팀 내에서 공유하며 공동의 목표로 진행하기로 했습니다. 또한 긴 작업 시간으로 인해 팀원들의 컨디션이 저하되지 않도록 스케줄에 여유를 두는 방안을 마련했습니다.
+- **심플한 주제 선정**: 심플한 주제를 유지하며 기능을 나누고, 각자의 기능을 책임지고 관리하는 방향으로 협업할 것을 강조했습니다.
+- **분업을 통한 성장과 몰입**: 팀원 각각의 강점을 살리면서도 프로젝트 전반에 걸친 협업을 경험하도록, 단순한 분업을 넘어 기술적 공유와 상호 피드백이 활발하게 이루어지도록 할 계획입니다.
+
+## 🚀 주제와 프로젝트에 대한 목표
+
+- **실제 사용 가능성**: 팀원 모두가 사용할 수 있고 현실에서 필요로 하는 서비스를 만드는 것을 목표로 삼았습니다. 주제는 단순히 기술을 구현하는 것에 그치지 않고, 일상에서 겪는 사소한 불편함을 해결하는 방향으로 설정했습니다.
+- **포트폴리오로서의 가치**: 완성된 프로젝트가 향후 포트폴리오로 활용될 수 있도록 하여, 프로젝트의 기능성뿐만 아니라 코드 품질과 유지보수 가능성을 높이기로 했습니다. 특히 각 기능이 GitHub에 기록되어 체계적으로 아카이빙될 수 있도록 관리합니다.
+
+## 🚀 유지보수와 확장성
+
+- **지속적인 개선 가능성**: 6주라는 프로젝트 기간이 끝난 이후에도 팀원들이 쉽게 유지보수할 수 있도록 코드를 작성하며, 향후 필요한 경우 기능 확장과 업데이트가 가능하도록 고려했습니다.
+- **협업과 문서화의 중요성**: 코드를 읽고 관리하기 쉽도록 문서화에 신경 쓰며, 협업 과정에서의 명확한 역할 분담과 상호 피드백을 통해 코드의 품질을 높이고자 합니다.
+
+## 🚀 팀워크와 협업 방식
+
+- **비동기적 소통**: 팀 내 피드백을 빠르게 주고받아 작업의 흐름이 끊기지 않도록 하며, 필요 시 비동기적 소통을 통해 문제 상황을 신속히 해결하는 방안을 채택했습니다.
+- **주간 목표 설정**: 매주 한 가지 주요 기능을 구현하여 배포하는 방식으로, 각 기능의 완성도를 높이는 동시에 팀원 간의 협력과 피드백을 유도합니다.
+
+# 📚 아이디어 정리
+
+## 📚 주제 선정 시 고려 사항
+
+- **필요성과 공감대**: 팀원 전원이 필요성을 공감할 수 있는 주제를 우선적으로 선정하기로 했습니다. 주제에 대한 공감이 팀 프로젝트의 동기 부여와 방향성을 높이는 데 중요하다고 판단했습니다.
+- **구현 가능성과 완성도**: 기능의 크기가 크고 복잡할 경우 완성도에 영향을 미칠 수 있으므로, 핵심 기능을 간단하고 명확하게 설계하여 전체 프로젝트의 완성도를 높이는 데 중점을 두었습니다.
+- **각 팀원의 의견과 필요**:
+- 팀원마다 목표와 필요가 다르기에 각자 원하는 방향으로의 성장 기회를 존중하고자 했습니다. 예를 들어, 일부는 React와 TypeScript의 포트폴리오에 집중하고 싶어했고, 다른 팀원들은 새로운 기술(예: Three.js)을 활용해 보고 싶어했습니다.
+- 다만 이 역시, 문제에 대한 접근을 먼저 두고, 필요에 맞춰서 기술을 도입하기로 했습니다.
+
+## 📚 아이디어 선정 과정
+
+- 자유롭게 의견 발화 이후 피그잼(Figma Jam)을 이용해 정리.
+- 포스트잇을 활용해 자유롭게 주제를 제시 후 군집화.
+- 이후 각자 스티커를 통해 3개씩 투표.
+- 투표 결과를 기반으로 팀 내 조율 및 선정.
+
+## 📚 선정된 아이디어 내용
+
+**주제**: 중장년층을 위한 지도 서비스.
+
+**목표**: Accessibility를 극도로 고려한 위치 혹은 지도 관련 서비스 개발.
+
+(우리의 가족이 쓸 수 있도록)
+
+**제약사항**: 너무 많은 타겟을 고려하려 하지 말자.
+
+- 처음에는 작게 시작하자. => 중장년층만을 대상으로.
+- 많이 고려해도, 노안, 노청 등을 고려하는 정도로만 하자.
diff --git a/docs/docusaurus/docs/archive/summary/20241031-firstweek-summary.mdx b/docs/docusaurus/docs/archive/summary/20241031-firstweek-summary.mdx
new file mode 100644
index 00000000..da87e922
--- /dev/null
+++ b/docs/docusaurus/docs/archive/summary/20241031-firstweek-summary.mdx
@@ -0,0 +1,584 @@
+---
+slug: 20241031-firstweek-summary
+title: 📚 [2024-10-31] 첫째주 활동 내용 정리
+sidebar_position: 4
+sidebar_label: 📚 [2024-10-31] 첫째주 활동 내용 정리
+keywords: ['회의', '내용정리']
+tags: [summary]
+last_update:
+ date: 2024-10-31
+ authors: [zen]
+---
+
+## 📝 2024년 10월 22일 (화요일)
+
+## 🚀 사전 팀 미팅 준비 및 목표 설정
+
+### 사전 준비 문서 작성
+
+팀원들은 "사전 팀 미팅 일정 정하기 및 사전 준비"라는 제목의 문서를 생성하여 미팅 준비를 시작했습니다.
+
+### 각자의 목표 공유
+
+**J210 @Zen:**
+
+- **개인 목표:**
+ - 실제로 사용할 수 있고 자신이 겪은 문제를 해결하는 프로그램 개발.
+ - 작은 기능이라도 이후 확장과 유지보수가 가능하도록 완성도 있게 구현.
+ - 모든 과정을 GitHub에 기록하여 아카이빙하고, 포트폴리오에 활용.
+ - 거창한 기술보다 React 등의 기본 기술을 활용하여 UX 기반 기술적 완성도 향상.
+ - 분업이 아닌 협업 경험 추구.
+- **상세 내용:**
+ - 현실적인 문제를 해결하는 프로젝트에 대한 가치 강조.
+ - 기술에 매몰되지 않고 본질에 집중하는 개발 철학 공유.
+ - 포트폴리오를 위한 프로젝트로서 기록과 아카이빙의 중요성 언급.
+ - 즐겁게 협업하고 몰입하는 기간으로 삼고자 하는 의지 표현.
+
+**J060 김주원:**
+
+- **개인 목표:**
+ - 처음부터 끝까지 만들어보며 전반적인 이해도 향상.
+ - 포트폴리오에 활용할 수 있는 프로젝트 개발.
+- **상세 내용:**
+ - 로봇 분야에서 웹으로 전향한 이유를 스토리로 만들기.
+ - 실시간 위치 시각화나 이동 경로 확인 등을 다뤄보고자 하는 의지.
+ - TypeScript와 상태 관리 도구 활용 예정.
+ - 실력을 발전시키기 위한 실전 경험 강조.
+
+**J174 이동율:**
+
+- **개인 목표:**
+ - 포트폴리오에 활용할 수 있는 프로젝트 개발 (실사용자가 있는).
+ - 서비스를 유지보수하는 경험 추구.
+ - 기능이 거창하지 않더라도 완성도 있는 프로젝트 지향.
+
+**J234 정혜인:**
+
+- **개인 목표:**
+ - 지속적으로 포트폴리오로 활용 가능한 프로젝트 개발.
+ - 적어도 1년 이상 배포되어 지속 가능한 프로젝트 목표.
+ - 새로운 기술 학습 및 적용에 대한 열정.
+ - 개인적으로 흥미 있고 사용할 만한 서비스 개발 희망.
+ - 효율적인 시간 관리와 코어 시간 내 작업 완료 중요성 강조.
+
+### 아이디어 제안
+
+**J060 김주원:**
+
+- **네이버 지도 개선:**
+ - 오늘의 장소 리스트 공유 및 약속 일정 공유 기능.
+ - 경로 추천, 3D 실내 길 안내, AI를 통한 방문지 추천 등 확장 가능성.
+ - 링크를 통해 실시간 위치 공유 기능 제안.
+
+---
+
+## 📝 2024년 10월 24일 (목요일)
+
+## 🚀 첫 팀 미팅 진행
+
+### 팀원 소개 및 친목 도모
+
+- 팀원들이 서로를 소개하고 친해지는 시간을 가졌습니다.
+- 팀원들의 사진을 공유하며 팀의 결속력을 다졌습니다.
+
+### 회의 안건 논의
+
+- **슬랙 메시지 응답 규칙 설정:**
+ - 슬랙 메시지를 읽었으면 답장을 누르는 방식으로 소통 효율성을 높이기로 합의했습니다.
+ - 온라인 환경에서의 원활한 커뮤니케이션을 위해 데이터베이스화하여 추적 가능성을 고려했습니다.
+- **팀의 목표에 대한 심층 논의:**
+ - **서로의 기술적 역량 및 경험 공유:**
+ - 각자 자신의 기술 스택과 경험에 대해 공유하여 팀의 전체적인 역량을 파악했습니다.
+ - **완성도 있는 프로젝트란 무엇인가에 대한 논의:**
+ - 사용자 관점에서 완성된 서비스를 제공하는 것을 우선시하기로 결정했습니다.
+ - 코드의 완성도와 함께 서비스의 안정성과 사용자 경험을 중요하게 고려하기로 했습니다.
+ - **공통의 목표 설정:**
+ - 포트폴리오에 활용할 수 있는 프로젝트 개발.
+ - 실사용자가 있는 지속 가능한 서비스 구축.
+ - 유지보수가 가능하고 확장성이 있는 프로젝트 지향.
+- **팀의 문화 및 그라운드 룰 설정:**
+ - **의사소통 방식:**
+ - 코어 시간 내에는 적극적인 소통을 위해 Zep이나 게더타운과 같은 플랫폼을 활용하기로 했습니다.
+ - 비동기적 소통을 보완하기 위해 실시간 대화가 가능한 환경을 조성하기로 했습니다.
+ - **코어 시간 활용 방안:**
+ - 코어 시간 내에 집중하여 작업하고, 코어 시간 외에는 개인의 자율에 맡기기로 했습니다.
+ - 효율적인 작업을 위해 휴식과 업무의 분리를 중요시하기로 합의했습니다.
+ - **기록 및 공유 방식:**
+ - 노션을 활용하여 실시간으로 회의 내용을 정리하고 공유하기로 했습니다.
+ - GitHub의 이슈 트래킹과 위키를 적극 활용하여 개발 과정과 문제 해결 과정을 아카이빙하기로 했습니다.
+ - **의사결정 방식:**
+ - 모든 팀원이 이슈에 대해 이해하고 논의할 수 있도록 GitHub 이슈를 활용하기로 했습니다.
+ - 팀 전체의 동의를 기반으로 의사결정을 진행하며, 필요한 경우 다수결을 활용하기로 했습니다.
+ - **코드 리뷰 및 PR 규칙:**
+ - 코드 리뷰를 통해 서로의 코드를 이해하고 기술적 성장을 도모하기로 했습니다.
+ - PR은 최소 두 명 이상의 승인을 받아야 Merge가 가능하도록 규칙을 정했습니다.
+ - **작업 공유 및 회고 방식:**
+ - 매일 데일리 스크럼을 통해 작업 상황을 공유하고 문제점을 논의하기로 했습니다.
+ - 주간 회고를 통해 한 주의 작업을 되돌아보고 개선점을 찾기로 했습니다.
+- **카드 시스템 도입:**
+ - 팀원들의 건강과 효율적인 작업을 위해 특정 상황에서 사용할 수 있는 카드를 도입했습니다.
+ - 휴식 카드, 의견 제시 카드, 반차 카드 등.
+
+---
+
+### 아이디어에 대한 추가 논의
+
+- 팀원들이 제시한 아이디어들을 바탕으로 프로젝트 주제를 구체화하기로 했습니다.
+- 각 아이디어의 구현 가능성, 기술 스택, 기대 효과 등을 검토하기로 했습니다.
+
+---
+
+## 📝 2024년 10월 25일 (금요일)
+
+## 🚀 프로젝트 아이디어 구체화
+
+### 아이디어 문서 작성
+
+- **J210 @Zen**이 "아이디어 1 - 공간에 기억을 담"이라는 제목의 문서를 작성하여 세부적인 프로젝트 아이디어를 제시했습니다.
+- 위치 기반 증강현실(AR) 커뮤니티 플랫폼에 대한 상세한 기획안을 마련했습니다.
+
+### 프로젝트 개요 및 목표 설정
+
+- **프로젝트명:** 위치 기반 증강현실(AR) 커뮤니티 플랫폼
+- **주요 기능:**
+ - 사용자의 위치에 따라 카메라 화면 위에 2D 컴포넌트를 통해 정보와 메시지를 표시.
+ - 지역 주민, 관광객 등이 현실 공간에서 정보를 공유하고 소통할 수 있는 플랫폼 구축.
+- **프로젝트 목표:**
+ - 현실 공간에 기반한 위치 맞춤형 증강현실 플랫폼을 통해 사용자들이 특정 장소에서 정보를 공유하고 소통할 수 있는 몰입형 커뮤니티 환경 구축.
+
+### 동기 및 예상 효과 논의
+
+- **동기:**
+ - 물리적 공간에서의 소통 가치 재발견.
+ - 위치 기반 증강현실 서비스의 대중화와 발전 가능성.
+ - 일상 속에서 가치 있는 정보 제공.
+ - 차세대 소셜 플랫폼의 가능성 모색.
+- **예상 효과:**
+ - 공간 활용과 정보 접근성 향상.
+ - 현실 공간에서의 사회적 연결성 강화.
+ - 확장성 높은 플랫폼 구축.
+ - 사용자 경험 최적화.
+
+### 주요 기능 및 기술 스택 검토
+
+- **주요 기능:**
+ - 위치 기반 정보 표시.
+ - 카메라 화면에 2D 메시지 오버레이.
+ - 사용자 위치에 따른 정보 필터링.
+ - 커뮤니티 메시지 기능.
+ - 비동기 데이터 요청과 상태 관리.
+- **예상 사용 기술 스택:**
+ - **프론트엔드:**
+ - React, TypeScript, Geolocation API, MSW, React Query 또는 Zustand, Tailwind CSS, Shadcn 등.
+ - **백엔드:**
+ - Supabase 또는 Firebase를 활용하여 빠른 백엔드 개발.
+
+### 예상되는 기술적 성장 및 학습 포인트 정리
+
+- **캔버스 및 SVG 활용 능력 향상.**
+- **CSS 트랜스폼과 애니메이션 최적화 경험.**
+- **좌표 계산과 위치 기반 렌더링 기술 습득.**
+- **성능 최적화와 모바일 최적화 경험.**
+- **JavaScript를 통한 UI 상태 및 위치 제어 능력 강화.**
+- **사용자 위치 기반 UI 업데이트와 최적화.**
+- **상태 관리와 컴포넌트 구조 설계 능력 강화.**
+- **MSW를 이용한 데이터 모킹 및 비동기 요청 처리 경험.**
+
+### 예상 구현 일정 수립
+
+- **1주차:** 기획 및 설계.
+- **2주차:** 설계 및 개발 환경 구축.
+- **3~4주차:** 핵심 기능 개발.
+- **5주차:** 테스트 및 개선.
+- **6주차:** 마무리 및 피드백.
+
+### 향후 계획 및 추가 논의 사항
+
+- 프로젝트 아이디어에 대한 팀원들의 피드백 수집 예정.
+- 기술 스택 확정 및 역할 분담 논의 예정.
+- 구현 가능성 및 현실적인 개발 범위 검토 필요.
+
+---
+
+## 📝 2024년 10월 28일 이후 계획
+
+## 🚀 팀 빌딩 사전 준비 및 추가 논의
+
+### 아이디어 추가 개발 및 검토
+
+- 팀원들이 추가적으로 아이디어를 발전시키고, 구현 가능성을 검토하기로 했습니다.
+- 아이디어의 기술적 난이도, 개발 기간, 기대 효과 등을 종합적으로 고려하기로 했습니다.
+
+### 팀 운영 관련 사항 논의 예정
+
+- **크레딧 계정 설정.**
+- **코딩 컨벤션 및 코드 스타일 가이드 확립.**
+- **주간 스프린트 계획 수립 및 역할 분담.**
+
+### 기술 스택 및 개발 도구 확정 예정
+
+- **프론트엔드와 백엔드의 구체적인 기술 선택.**
+- **협업 도구 및 플랫폼 활용 방안 결정.**
+
+### 프로젝트 진행 방식 합의
+
+- 매주 기능 단위로 개발하고 배포하여 빠른 피드백 수집.
+- 코드 리뷰 및 테스트를 통한 품질 관리 강화.
+- 문서화 및 기록을 통해 개발 과정의 투명성 및 아카이빙.
+
+---
+
+## 📝 2024년 10월 25일 (금요일)
+
+## 🚀 사전 팀 미팅 회의 내용 정리
+
+### 1. 프로젝트에 대한 공통의 목표
+
+- **포트폴리오에 활용 가능한 실사용자 중심의 서비스 개발**
+ - 팀원 모두가 포트폴리오로 활용할 수 있는 가치 있는 프로젝트를 목표로 설정.
+ - 실제 사용자에게 도움이 되는 기능을 제공하는 서비스 개발을 지향.
+ - 최소 1년간 유지보수할 수 있는 지속 가능한 프로젝트를 계획.
+
+### 2. 기술적인 목표
+
+- 주제가 정해지면 구체적인 기술 스택과 목표를 설정하기로 함.
+
+### 3. 프로젝트 개발 원칙
+
+- **사용자 경험(UX) 중심의 개발**
+ - 기능의 동작뿐만 아니라 사용자의 이해와 사용 편의성을 고려.
+- **작업 공유 및 문서화**
+ - GitHub Issue와 노션을 통해 작업 진행 상황과 문제점을 기록.
+ - 트러블슈팅, 배운 기술, 이슈 등을 문서화하여 프로젝트 진행을 투명하게 관리.
+
+### 4. 협업 및 의사소통 규칙
+
+- **잦은 커뮤니케이션**
+ - 슬랙을 기본 소통 도구로 사용하며, 명확한 답변을 남기기로 함.
+ - 실시간 협업 도구로 Zep 또는 게더타운을 활용.
+- **코어 타임 운영**
+ - 매일 오전 10시부터 오후 7시까지 집중적으로 프로젝트에 참여.
+ - 코어 타임 외에도 긴급한 상황에서는 즉각적인 소통을 유지.
+
+### 5. 코드 리뷰 및 PR 규칙
+
+- **4명의 PR 승인 및 최소 주 2회의 코드 리뷰**
+ - 모든 팀원의 PR 승인이 있어야만 기능을 병합할 수 있음.
+ - 코드 리뷰를 통해 팀원의 성장과 작업 이해를 도모.
+- **작업의 투명성 유지**
+ - 코드 리뷰와 PR을 통해 프로젝트 진행을 투명하게 공유.
+- **데일리 스크럼 활용**
+ - 매일 아침 데일리 스크럼을 통해 이슈나 코드 공유를 진행.
+
+### 6. 의사결정 방식
+
+- **팀 전체의 동의로 의사결정**
+ - 주요 결정은 팀원 모두의 논의를 거쳐 충분한 근거를 바탕으로 결정.
+- **긴급 의사결정**
+ - 필요시 Zep 또는 슬랙을 통해 팀원들을 소집하여 빠른 결정.
+
+### 7. 작업 분배 및 기록 관리
+
+- **분업이 아닌 협업**
+ - 모든 작업은 노션과 GitHub를 통해 투명하게 관리.
+ - 스프린트 방식을 도입하여 주 단위 목표 설정 및 달성 여부 확인.
+
+### 8. 팀 문화
+
+- **즐겁고 활발한 분위기 조성**
+ - 스몰톡이나 비공식 대화를 통해 팀 분위기를 활기차게 유지.
+- **건강과 워라밸 존중**
+ - 과도한 업무를 지양하고 건강을 최우선으로 고려.
+- **의견 존중**
+ - 서로의 의견을 경청하고, 의견 충돌 시 팀원 전체의 논의를 통해 해결.
+
+### 9. 프로젝트 회고
+
+- **KPT 방식의 회고**
+ - 주기적인 회고를 통해 잘한 부분과 개선점을 분석하고 다음 스프린트에 반영.
+- **결과 기록**
+ - 회고 내용과 문제점, 해결 방안을 기록하여 포트폴리오에 활용.
+
+### 10. 긴급 상황 대응
+
+- **"나 힘들다 카드"와 "스톱 카드" 도입**
+ - 필요시 TMT, TMI를 방지하고 업무 집중도를 높이기 위한 카드 사용.
+
+### 11. 아이디어 브레인스토밍
+
+- 각 팀원이 다양한 아이디어를 제시하고, 팀원 간 피드백을 주고받음.
+ - 예시: 네이버 지도 개선, 약속 시간 조율 프로그램, 초보 운전자를 위한 웹앱, 위치 기반 날씨 시각화 웹 등.
+
+### 12. Zep 개설
+
+- **협업 공간 마련**
+ - Zep을 개설하여 비대면 상황에서도 실시간 피드백과 소통이 이루어지도록 함.
+
+---
+
+## 📝 2024년 10월 28일 (월요일)
+
+## 🚀 팀 빌딩 회의
+
+### 1. 팀 운영 관련
+
+- **크레딧 수령 계정 결정**
+ - 네이버 부스트캠프에서 제공하는 크레딧은 @Zen의 계정으로 받기로 함.
+- **회의 진행 방식 논의**
+ - 주제 논의 후 컨벤션에 대한 이야기를 진행하기로 결정.
+
+### 2. 주제 논의
+
+- **아이디어 재논의**
+ - 이전에 제시된 아이디어들을 다시 검토하고 의견을 조율함.
+- **Three.js 활용 여부**
+ - 새로운 기술인 Three.js의 도입에 대한 의견 교환.
+ - 학습 곡선과 팀원들의 목표를 고려하여 신중하게 결정하기로 함.
+- **주제 선정 방향**
+ - 팀원 모두가 공감하고 사용할 수 있는 서비스를 만들기로 합의.
+ - 기술보다는 해결하고자 하는 문제에 집중하기로 함.
+
+### 3. 팀원들의 희망사항 및 목표 공유
+
+- **@Zen**
+ - 실제로 사용할 수 있는 프로그램 개발.
+ - 작은 문제라도 기술로 해결하고 싶음.
+ - 완성도 높은 프로젝트를 통한 포트폴리오 작성.
+ - 분업이 아닌 협업을 통한 성장.
+- **@김주원**
+ - 프로젝트 전 과정을 경험하여 이해도 향상.
+ - 포트폴리오에 활용할 수 있는 프로젝트 개발.
+ - 실시간 위치 시각화 및 이동 경로 확인 기능에 관심.
+- **@이동율**
+ - 실사용자가 있는 포트폴리오용 프로젝트 개발.
+ - 서비스 유지 보수 경험 획득.
+ - 심플하고 재미있는 주제 선호.
+- **@정혜인**
+ - 새로운 기술 학습 및 적용.
+ - 지속 가능한 프로젝트 개발.
+ - 정해진 시간 내에 효율적인 작업 수행.
+
+### 4. 팀의 가치와 규칙 설정
+
+- **주제 선정**
+ - 팀원 모두가 필요성을 공감할 수 있는 주제를 우선적으로 선정하기로 함.
+- **협업 방식**
+ - 분업보다는 협업을 통해 공동의 목표를 추구하기로 결정.
+- **시간 관리**
+ - 코어 타임 내에 집중적으로 작업하고, 야근 없이 효율적으로 프로젝트 진행.
+- **팀의 핵심 가치**
+ - "꾸준하게, 일정하게"를 슬로건으로 설정하여 일관된 노력과 진전을 추구.
+
+### 5. 주제 결정
+
+- **선정 주제**
+ - 중장년층을 위한 지도 서비스 개발.
+- **목표**
+ - 접근성을 극대화한 위치 또는 지도 관련 서비스를 만들어 실제로 도움이 되는 프로그램을 개발.
+- **추가 고려사항**
+ - 타겟층을 명확히 하여 중장년층에 집중.
+ - 초기에는 핵심 기능에 집중하고, 이후에 확장 가능성 모색.
+
+---
+
+## 📝 2024년 10월 29일 (화요일)
+
+## 🚀 아이디어 회의
+
+### 1. 아이디어 노트 작성
+
+- **주제에 대한 추가 논의**
+ - 기존 주제에 대한 타당성과 기술적 도전 요소를 검토.
+- **기술적 목표 설정**
+ - 테스트 주도 개발(TDD)을 프로젝트의 기술적 도전으로 삼기로 합의.
+ - 문서화와 코드 품질 향상을 위한 도구 도입 검토.
+
+### 2. 주제와 기술의 조화
+
+- **위치 기반 서비스와 TDD의 접목**
+ - 위치 관련 주제를 유지하면서 TDD를 적용하는 방안을 논의.
+- **기술 학습 시간 고려**
+ - 새로운 기술 도입에 따른 학습 시간을 일정에 포함시키기로 결정.
+
+### 3. 협업 방식 재논의
+
+- **코어 타임 활용**
+ - 코어 타임에는 개발에 집중하고, 학습과 문서화는 이후 시간에 진행하기로 함.
+- **문서화의 중요성 강조**
+ - 프로젝트 진행 과정에서의 경험과 학습 내용을 적극적으로 기록하기로 함.
+
+---
+
+## 📝 2024년 10월 30일 (수요일)
+
+## 🚀 일정 및 기획 회의
+
+### 1. 회의 내용 정리
+
+- **주제 유지**
+ - 중장년층을 위한 지도 서비스로 주제를 확정.
+- **핵심 기능 정의**
+ - 실시간 위치 공유 서비스 개발을 주요 기능으로 설정.
+- **기술적 목표 재설정**
+ - 프론트엔드와 백엔드 모두 TDD를 적용하기로 함.
+ - 문서화를 강화하고 코드 리뷰를 활성화하기로 결정.
+
+### 2. 팀 구성 및 역할 분담
+
+- **프론트엔드 담당**
+ - @Zen
+ - @이동율
+ - @김주원
+- **백엔드 담당**
+ - @정혜인 (백엔드 구현 완료 후 프론트엔드 합류 예정)
+
+### 3. 기술 스택 선정
+
+- **프론트엔드**
+ - React
+ - TypeScript
+ - pnpm
+ - Vite
+ - Vitest
+ - Storybook
+ - MSW
+- **백엔드**
+ - Node.js
+ - JavaScript
+ - pnpm
+ - Express
+
+### 4. 개발 환경 및 도구
+
+- **모노레포 구조 검토**
+ - 프론트엔드와 백엔드를 모노레포로 관리하는 방안을 논의.
+- **Lint 및 코드 컨벤션 설정**
+ - 초기 설정을 공유하고, 팀 전체가 동일한 컨벤션을 따르기로 함.
+
+### 5. 프로젝트 진행 계획
+
+- **Figma를 통한 디자인 및 프로토타이핑**
+ - 서비스의 UI/UX를 Figma로 설계하기로 함.
+- **기능 구현 우선순위 설정**
+ - 핵심 기능부터 빠르게 구현하고, 이후 추가 기능을 개발하기로 결정.
+- **API 및 기술 조사**
+ - 네이버 지도 API, TMap API 등의 사용 가능성을 테스트하고 적용 방안을 모색.
+
+### 6. 기능 테스트 및 프로토타입 제작
+
+- **실시간 위치 공유 기능 테스트**
+ - Socket.io를 사용한 실시간 위치 공유 기능을 테스트.
+ - Socket을 사용하지 않는 방식으로도 위치 공유가 가능한지 검토.
+- **마커 및 경로 그리기 기능 구현**
+ - 지도 위에 마커를 표시하고, 경로를 그리는 기능을 실험.
+- **정확한 위치 정보 확보 방안 모색**
+ - GPS의 정확도를 높이는 방법과 브라우저의 한계점을 파악.
+
+---
+
+## 📝 추가 사항
+
+### 🚀 코드 리뷰 및 PR 규칙 강화
+
+- 초반에는 PR 승인 인원을 조정하여 효율적인 개발이 가능하도록 유연하게 대처하기로 함.
+
+### 🚀 팀원 간의 적극적인 피드백
+
+- 각자의 작업 상황을 공유하고, 문제가 발생하면 즉시 팀원들과 논의하기로 약속.
+
+### 🚀 지속적인 학습과 성장
+
+- 프로젝트를 통해 새로운 기술과 개발 방법론을 학습하고 적용하기로 함.
+
+---
+
+## 📝 2024년 10월 31일 (목요일)
+
+## 🚀 기획 회의 및 사용자 시나리오 작성
+
+### 1. 기획 회의 진행
+
+- **테스트 진행 현황 공유**
+ - @Zen은 테스트 환경 세팅(vite, tailwind 등), 네이버 맵 API 사용, polyline을 활용한 마킹 기능 등을 확인하였습니다.
+ - @이동율과 @김주원도 기능 테스트를 진행하고 결과를 공유하였습니다.
+- **네이버 지도 API 관련 논의**
+ - 네이버 지도 API의 타입 정의 등 사용법을 공유하고, 활용 방안을 논의하였습니다.
+- **프로젝트 주제 및 방향성 재검토**
+ - 멘토님의 피드백을 반영하여 주제와 기술적인 도전 요소를 재검토하였습니다.
+ - TDD 적용의 현실적인 어려움과 포트폴리오로서의 가치에 대해 토론하였습니다.
+- **사용자 시나리오 작성 필요성 인식**
+ - 서비스의 구체적인 모습을 그리기 위해 각 팀원이 사용자 시나리오를 작성하기로 하였습니다.
+
+### 2. 사용자 시나리오 작성
+
+- 각 팀원이 사용자 시나리오를 작성하여 공유하였습니다.
+ - **@김주원**
+ - **지도 위 저작도구 활용**
+ - 지도에 마커, 선, 텍스트 박스 등을 추가할 수 있는 저작도구를 제시하였습니다.
+ - 에어비앤비 호스트가 숙소 주변 정보를 제공하는 예시를 통해 기능을 설명하였습니다.
+ - 그룹화 기능을 통해 여러 경로와 마커를 관리할 수 있도록 제안하였습니다.
+ - **@정혜인**
+ - **사용자별 경로 설정 및 실시간 위치 공유**
+ - 손녀가 출발지와 도착지를 설정하여 할머니에게 길 안내를 제공하는 시나리오를 제시하였습니다.
+ - 사용자별로 다른 경로를 설정하고, 실시간 위치를 공유하는 기능을 강조하였습니다.
+ - 각 사용자에게 고유한 링크를 제공하여 접근성을 높였습니다.
+ - **@이동율**
+ - **지도 커스터마이징 및 경로 저장**
+ - 사용자가 직접 지도를 커스터마이징하여 여러 경로를 저장하고 활용하는 시나리오를 제시하였습니다.
+ - 축제나 여행 시 미리 경로를 그려두고 활용하는 예시를 통해 기능을 설명하였습니다.
+ - 실시간 위치 공유의 필요성에 대해 고민하였습니다.
+ - **@임재도**
+ - **지도 위에 그림 그리기 기능**
+ - 지도 위에 그림을 그리고 저장, 수정, 공유하는 시나리오를 상세하게 작성하였습니다.
+ - 회원가입, 로그인, 펜과 지우개 도구 사용, 그림 공유 등의 기능을 포함하였습니다.
+ - 기술적인 도전 요소로 캔버스와 지도 동기화, 데이터 저장 방식 등을 제시하였습니다.
+
+### 3. 서비스 명 및 프로젝트 제목 결정
+
+- **서비스 명 후보**
+ - 따라길, 선따라길따라, 따라오길 등 다양한 후보를 제시하고 투표를 진행하였습니다.
+- **최종 결정**
+ - **팀명:** 따라따라
+ - **프로젝트 제목:** 선따라 길따라 (DDara)
+ - **프로젝트 한 줄 소개:** 중장년층 사용자가 쉽게 길 안내를 받게 해주는 모바일 웹서비스
+ - **기술 키워드:** #지도, #저작도구, #실시간 위치
+ - **깃허브 링크:** [https://github.com/boostcampwm-2024/web28-DDara](https://github.com/boostcampwm-2024/web28-DDara)
+
+### 4. 향후 일정 및 할 일 정리
+
+- **2024년 11월 1일(금)까지**
+ 1. **@정혜인**
+ - 피그마 기획서 수정
+ - 리드미 작성
+ 2. **@김주원, @이동율**
+ - 필요한 기능 정리 및 기능 추출
+ 3. **@Zen**
+ - 멘토님께 전달할 문서 작성
+ - 2024년 11월 1일 발표 준비
+- **2024년 11월 4일(월)까지**
+ 1. **커밋 전략 및 코드 컨벤션 정하기**
+ - 에어비앤비, 네이버, JavaScript Standard Style 등 참고
+ 2. **타입스크립트 옵션 설정**
+ 3. **테스트 전략 수립**
+ 4. **스토리북 사용법 익히기** (프론트엔드 팀원)
+ 5. **@정혜인**
+ - 백엔드 스웨거(Swagger) 사용법 익히기
+ 6. **Vitest 학습**
+ 7. **GitHub Actions 등을 활용한 자동화 도구 설정**
+ 8. **자동 배포 방식 결정**
+ 9. **프론트엔드 빌드 및 배포**
+ - Vercel 이용하기
+ 10. **백엔드 WAS 설정**
+- @정혜인의 재량에 맡기기로 함
+- **기타**
+ - 월요일 목표는 **환경설정 완료**로 설정하였습니다.
+ - 기능 테스트를 지속적으로 진행하기로 하였습니다.
+ - Zep을 활용하여 팀원 간 소통을 강화하기로 하였습니다.
+
+### 5. 기타 논의 사항
+
+- **커밋 메시지 규칙 정립**
+ - Feat, Fix, Design, Style, Refactor 등 태그를 사용하여 커밋 메시지의 일관성을 유지하기로 하였습니다.
+- **프로젝트의 기술적 도전 요소 재검토**
+ - 실시간 위치 공유, 지도 위의 저작도구 구현 등 기술적 도전 요소를 구체화하기로 하였습니다.
+
diff --git a/docs/docusaurus/docs/archive/summary/20241031-planning-summary.mdx b/docs/docusaurus/docs/archive/summary/20241031-planning-summary.mdx
new file mode 100644
index 00000000..10e8af17
--- /dev/null
+++ b/docs/docusaurus/docs/archive/summary/20241031-planning-summary.mdx
@@ -0,0 +1,169 @@
+---
+slug: 20241031-planning-summary
+title: 📚 [2024-10-31] 기획 회의 정리본
+sidebar_position: 3
+sidebar_label: 📚 [2024-10-31] 기획 회의 정리본
+keywords: ['회의', '내용정리']
+tags: [summary]
+last_update:
+ date: 2024-10-31
+ authors: [zen]
+---
+
+## 📝 오늘 하루 내용 요약
+
+이번 주 프로젝트 "선따라 길따라(DDara)"와 관련된 활동을 시간 순서에 따라 정리하겠습니다. 이번 주의 활동은 기획회의부터 시작하여 테스트 설정, 각 기능별 시나리오 기획, 기술적 도전 사항 및 회의 결론에 이르기까지 광범위하게 진행되었습니다.
+
+---
+
+### **1. 10월 31일 오전 - 기획 회의 및 테스트 준비**
+
+- **기획회의 진행**:
+ - 10월 31일 오전 10시부터 팀 전체 기획 회의가 열렸습니다. 이번 회의는 프로젝트 초기 구상을 명확히 하고, 필요한 기술 스택과 기능을 구체화하는 것을 목표로 했습니다.
+ - **주제 정리**: 중장년층 사용자에게 쉽게 길 안내를 제공하는 위치 기반 지도 웹서비스로 주제를 구체화하였습니다. "선따라 길따라(DDara)"라는 서비스명을 선정하고, 팀명은 "따라따라"로 결정했습니다.
+ - **사용자 설정 및 주요 기능 논의**: 사용자는 자신만의 경로를 설정할 수 있도록 하며, 경로는 지도 위에서 그리기 도구를 통해 직관적으로 설정됩니다. 경로마다 마커를 추가하고, 실시간 위치를 추적하는 기능을 통해 사용자 경험을 향상시키기로 했습니다.
+- **기술 스택 설정**:
+ - **Vite, Tailwind 및 네이버 지도 API**: 서비스 환경을 Vite와 Tailwind를 사용하여 구축하고, 네이버 지도 API로 지도를 표시하며 다양한 경로 및 마커를 추가할 계획을 세웠습니다.
+ - **@types/navermap 활용**: 네이버 지도 API에 필요한 타입을 별도로 설정하여 타입스크립트로 편리하게 작업할 수 있도록 준비하였습니다.
+- **기능 테스트 계획 수립**:
+ - 간단한 경로 설정과 마킹이 가능하도록 네이버 지도 API와 Polyline을 활용한 마킹을 테스트하여 초기 기술 환경과 지도 설정의 문제를 확인했습니다.
+
+---
+
+### **2. 10월 31일 오후 - 사용자 시나리오 기획**
+
+오후 시간에는 네이버 지도 API를 이용한 지도 생성, 경로 표시, 마커 배치 기능 등을 고려하여 구체적인 사용자 시나리오를 작성했습니다.
+
+- **사용자 시나리오 개발**:
+ - **시나리오 세부화**: 각 팀원은 중장년층 사용자를 고려하여 시나리오를 세분화했습니다. 손녀가 할머니에게 실시간으로 길을 안내하는 시나리오, 에어비앤비 호스트가 숙소 근처 주요 장소를 표시하는 시나리오 등 다양한 상황에서의 사용자 경험을 구체화했습니다.
+ - **그룹화 기능**: 특정 마커와 경로를 그룹으로 묶을 수 있도록 하는 기능을 구상하여, 마트, 은행, 카페 등 주제에 따라 경로와 마커를 시각적으로 구분할 수 있도록 했습니다.
+- **주요 기능 및 인터랙션 방식 정리**:
+ - **마커 및 경로 설정**: 사용자는 출발지와 도착지를 마커로 표시하며, 주요 경로는 직관적인 선으로 그려집니다. 실시간 위치는 지도를 통해 확인되며, 확대 및 축소 시 경로가 함께 조정됩니다.
+ - **이미지 삽입**: 복잡한 골목이나 특정 건물 앞에서 경로를 이해하기 쉽도록 지도 위에 이미지를 삽입하는 기능도 추가했습니다.
+ - **실시간 위치 공유**: 각 사용자의 실시간 위치를 손쉽게 파악할 수 있도록 WebSocket을 통한 실시간 위치 갱신을 논의했습니다.
+
+---
+
+### **3. 10월 31일 저녁 - 기술적 도전 과제 정리 및 확장 가능성 논의**
+
+저녁에는 사용자 시나리오 기획에 이어, 이 기능들을 구현하면서 발생할 수 있는 기술적 도전 과제를 분석하고 확장 가능성을 검토했습니다.
+
+- **지도와 캔버스 동기화 최적화**:
+ - **문제 분석**: 지도 이동 및 확대/축소 시 캔버스 레이어의 동기화가 성능에 큰 영향을 줄 수 있음을 확인했습니다.
+ - **해결 방안 검토**: `requestAnimationFrame`, Offscreen Canvas, WebGL 등의 성능 최적화 방법을 도입하여 부드러운 사용자 경험을 제공할 방안을 모색했습니다.
+- **데이터 저장 및 동기화 방안**:
+ - **데이터 직렬화**: 경로와 마커의 데이터를 직렬화하고, SVG를 통한 데이터 저장 방식 및 이미지 압축 기법을 검토했습니다. 실시간 데이터의 크기를 줄이기 위해 최적화된 데이터 구조를 구성할 계획을 세웠습니다.
+- **실시간 협업 기능 확장**:
+ - **WebSocket 기반 동기화**: 다중 사용자가 동시에 지도 위에서 그림을 그릴 때 발생할 수 있는 충돌 문제를 해결하기 위해, WebSocket과 WebRTC를 사용하여 실시간 통신을 구현하고 충돌 관리 기법도 함께 도입할 것을 논의했습니다.
+
+---
+
+### **4. 10월 31일 이후 - 다음 주 과제 및 환경 설정**
+
+10월 31일 회의를 마지막으로 프로젝트에 필요한 다음 과제와 환경 설정을 명확히 하여 다음 주부터 본격적인 개발에 돌입하기로 했습니다.
+
+- **커밋 전략 및 코드 컨벤션 설정**:
+ - **Airbnb 스타일 가이드**를 사용하여 코드 스타일을 통일하고, ESLint와 Prettier를 통해 코드 품질을 관리하기로 했습니다.
+ - 팀원 간 효율적인 협업을 위해 커밋 전략과 네이밍 컨벤션을 정하고, GitHub에서 코드 리뷰 프로세스를 수립하기로 했습니다.
+- **주요 기능의 테스트 전략 확립**:
+ - **Vitest**와 **스토리북**을 사용하여 각 기능에 대한 테스트를 먼저 작성하고, 테스트 주도 개발(TDD)을 적용하기로 했습니다.
+ - **자동화 및 CI/CD 구축**: GitHub Actions을 이용한 자동화 배포 및 빌드 시스템을 도입하여, Vercel을 통해 자동 배포하도록 설정할 계획을 세웠습니다.
+- **PWA 구현 계획**:
+ - **오프라인 기능**: Progressive Web App(PWA)로의 확장 방안을 모색하였으며, 서비스 워커를 통한 오프라인 기능을 지원하고 위치 데이터를 저장하는 방법도 연구했습니다.
+- **기술 학습 계획**:
+ - **Vitest와 스토리북 학습**: 모든 팀원이 각자 Vitest와 스토리북을 학습하여 다음 주부터 바로 기능별 테스트와 스토리 작성에 돌입할 수 있도록 했습니다.
+ - **백엔드 학습과 Swagger 도입**: 백엔드 경험이 부족한 팀원을 위해 REST API 설계 및 Swagger 문서화도 학습할 계획을 세웠습니다.
+
+---
+
+
+### 요약
+
+이번 주의 활동을 통해 팀 프로젝트의 주제와 기능을 구체화하고, 기술적 도전 과제와 확장 가능성을 면밀히 검토했습니다. 다음 주에는 Vite 환경 설정, Vitest와 스토리북 학습, CI/CD 구축, 기능 개발 및 테스트 작성에 집중할 예정입니다.
+
+## 📝 기획안 정리
+
+### 1. 프로젝트 개요 및 배경
+
+"선따라 길따라(DDara)" 프로젝트는 중장년층 사용자를 주요 대상으로 하는 길 안내 모바일 웹 서비스로, 사용자가 특정 경로를 그리거나 기록하고 실시간으로 자신의 위치를 추적하면서 쉽게 길 안내를 받을 수 있도록 설계되었습니다. 이 프로젝트는 특히 중장년층의 사용자 편의성을 목표로 하며, 직관적인 인터페이스와 저작 도구, 실시간 위치 추적 기능을 갖춘 모바일 지도를 제공합니다.
+
+### 프로젝트 주제
+
+- **목표**: 중장년층 사용자가 직관적이고 쉽게 길을 안내받을 수 있도록 지도 상에 경로를 설정하고, 마커 및 선을 통해 시각적으로 이해를 돕는 모바일 웹 서비스를 제공하는 것.
+- **사용자 정의**: 기본적으로 중장년층을 대상으로 하나, 사용자가 개인적으로 사용할 수도 있으며, 다수의 사용자에게 실시간 경로를 안내할 수 있도록 경로 커스텀 기능을 제공.
+
+### 프로젝트의 주요 컨셉과 특성
+
+- **지도 위 실시간 위치 추적**: WebSocket을 통해 실시간으로 사용자의 위치를 추적하고, 특정 위치에서 경로 안내를 지속적으로 제공합니다.
+- **저작 도구**: 선 그리기, 마커 추가 등 지도 위에서 직접 경로를 표시하고, 각 지점에 설명을 추가할 수 있는 기능을 제공합니다.
+- **비회원 사용**: 사용자는 로그인 없이도 지도 및 경로를 볼 수 있으며, 로그인하면 경로 저장 및 수정이 가능합니다.
+- **다양한 경로 및 테마 지원**: 숙소 근처 마트나 공원, 카페 등 주변의 다양한 정보를 포함하여 개별 사용자의 목적에 맞는 경로를 설정할 수 있습니다.
+
+---
+
+### 2. 기획 회의 정리 및 주요 논의 사항
+
+이번 주 기획 회의에서는 프로젝트의 구현 방향과 각 기능에 대한 구체적인 시나리오가 다뤄졌습니다.
+
+### **회의 주요 안건**
+
+1. **테스트 진행 현황**: Vite, Tailwind, 네이버 맵 API 설정을 통한 환경 구축 및 기본적인 폴리라인 마킹 테스트가 진행되었습니다.
+2. **네이버 지도 API**: @types/navermap의 타입을 정리하여 사용하기 쉽게 준비했으며, 기본적인 지도 표시와 경로 그리기를 검토했습니다.
+3. **주요 기능 및 사용자 시나리오**: 시나리오별로 사용자 경험을 정의하고, 경로 설정과 실시간 위치 추적의 기술적 도전 과제를 분석했습니다.
+
+### **기능별 기획 및 기술적 도전**
+
+- **경로 설정과 마커 기능**: 사용자가 지도에 마커를 추가하여 경로를 설정하는 방식과, 이를 커스터마이즈하여 시각적 구분을 두는 기능이 논의되었습니다. 각 경로와 마커는 사용자 맞춤형으로 설정할 수 있으며, 사용자의 현재 위치와 목적지까지의 안내가 포함됩니다.
+- **지도 기반 저작 도구**: 직선 그리기, 선의 굵기 및 색상 변경, 텍스트와 이미지 추가 기능이 포함되며, 실시간으로 저장하고 공유할 수 있는 기능이 필수로 포함됩니다.
+- **폴리라인 기능 및 확대/축소 관리**: 경로의 매끄러운 연결과 선의 이어짐을 유지하며 확대/축소에 대응하는 기능이 주요 쟁점이었으며, 이를 반투명 선으로 표시하고 직선 연결을 유지하는 방식이 제안되었습니다.
+- **로그인 시스템과 비회원 접근**: 비회원 사용자도 지도 및 경로 확인이 가능하지만, 커스텀 경로 생성 및 저장은 회원에게만 허용됩니다.
+- **캔버스의 확장 가능성**: 프로젝트 확장 방안으로 캔버스를 통해 추가적인 저작 기능을 구현하고, 개인화된 경로 공유를 지원하여 여러 사용자와의 경로 공유가 가능합니다.
+
+### **주요 기능 및 설정 계획**
+
+1. **경로 설정 및 마커**: 각 사용자의 출발지와 도착지 설정, 위치별 경로와 마커 설정을 통해 직관적으로 경로를 시각화할 수 있습니다.
+2. **저작 도구 UI**: 지도 위의 그리기 도구 패널과 실시간 미리보기 기능을 제공하여 사용자가 원하는 경로와 마커를 쉽게 설정하도록 지원합니다.
+3. **다중 사용자 지원**: 최대 5명의 사용자가 서로 다른 경로를 확인할 수 있으며, 실시간 위치를 표시하여 위치 간 충돌을 최소화할 계획입니다.
+
+---
+
+### 3. 사용자 시나리오
+
+### 사용자 유형 및 시나리오
+
+각 사용자 유형에 맞춘 상세 시나리오와 예상 활동이 기획되었습니다.
+
+1. **일반 사용자 시나리오**
+ - 로그인하여 경로를 생성하고, 저작 도구를 사용해 경로를 커스텀하는 방식.
+ - 예시: 숙소 근처 주요 장소 마킹, 경로 그룹화를 통해 다양한 경로와 목적지 표시.
+2. **비회원 사용자 시나리오**
+ - 로그인 없이 지도와 경로 확인이 가능하며, 실시간 위치는 확인할 수 있지만, 경로 생성 및 수정은 제한됩니다.
+
+### 서비스 확장 방안
+
+프로젝트 주제는 중장년층 대상의 길 안내 서비스로 시작했지만, 다양한 유스케이스가 논의되었습니다. 예를 들어 축제 지도를 통해 다수의 경로를 한 번에 관리하거나 에어비앤비와 같은 서비스에 활용될 수 있습니다.
+
+---
+
+### 4. 기술적 도전과 최적화 방안
+
+프로젝트의 기술적 도전과 기획에서 주요하게 다뤄진 부분입니다.
+
+### 지도와 캔버스 동기화 최적화
+
+지도 확대/축소와 이동 시에 캔버스 레이어가 매끄럽게 동기화되어야 하며, 이 과정에서 성능 최적화가 필요합니다. `requestAnimationFrame`, Offscreen Canvas, WebGL 등을 통해 성능을 개선할 계획입니다.
+
+### 데이터 저장 및 동기화
+
+사용자의 경로와 마커는 네이버 맵 API의 폴리라인과 함께 저장됩니다. 데이터가 많아질 경우에는 압축 및 최적화 기법을 사용하여 빠른 로딩을 유도하고, SVG 및 Protobuf 등으로 데이터 직렬화를 고려 중입니다.
+
+### 실시간 협업 기능
+
+여러 사용자가 한 지도를 보면서 경로를 설정할 수 있도록 WebSocket을 활용할 계획입니다. 이 과정에서 충돌 관리 기법이 적용될 것이며, 특히 실시간 위치와 경로를 동시에 표시할 수 있도록 WebRTC 등 추가적인 실시간 통신 기능도 고려합니다.
+
+---
+
+### 5. 마무리
+
+이번 주 활동을 통해 "선따라 길따라(DDara)" 프로젝트의 전체 기획, 주요 기능, 기술적 과제가 체계화되었으며, 각 기능별로 구체적인 사용자 경험이 설계되었습니다. 다음 주에는 기능 개발과 환경 설정에 들어가며, 특히 Vitest와 스토리북 등을 활용한 테스팅 및 개발을 예정하고 있습니다.
+
diff --git a/docs/docusaurus/docs/archive/summary/20241031-project-progress-summary.mdx b/docs/docusaurus/docs/archive/summary/20241031-project-progress-summary.mdx
new file mode 100644
index 00000000..c3211a89
--- /dev/null
+++ b/docs/docusaurus/docs/archive/summary/20241031-project-progress-summary.mdx
@@ -0,0 +1,56 @@
+---
+slug: 20241031-project-progress-summary
+title: 📚 [2024-10-31] 프로젝트 진행 상황 정리본
+sidebar_position: 5
+sidebar_label: 📚 [2024-10-31] 프로젝트 진행 상황 정리본
+keywords: ['프로젝트', '진행상황']
+tags: [summary]
+last_update:
+ date: 2024-10-31
+ authors: [zen]
+---
+
+## 📝 진행상황 요약
+
+- 10월 31일 목요일에 프로젝트 주제를 확정지었습니다.
+- 이에 따라, 31일(목요일)부터 기술 분석 및 계획 수립을 진행중입니다.
+
+## 📅 일정 및 회의 일지 요약
+
+> 지난주, 이번주 핵심 활동은 다음과 같습니다.
+
+### **2024년 10월 22일 - 사전 준비 및 개인 목표 설정**
+
+- **목표 공유**: 각 팀원은 실사용자 중심의 포트폴리오 프로젝트 개발, GitHub 기록, 협업 경험, 실전 기술 습득 등을 목표로 설정.
+- **아이디어 제안**: 주제로 지도 기반 서비스 제안, 실시간 위치 공유 등 다양한 기능 구상.
+
+### **2024년 10월 24일 - 첫 팀 미팅**
+
+- **팀 문화 및 목표 설정**: 사용자 관점에서 완성도 높은 서비스 제공에 중점을 두며, 협업 방식, 의사결정 규칙, PR 및 코드 리뷰, 데일리 스크럼 규칙 설정.
+- **아이디어 논의**: 제안된 아이디어를 기반으로 기술 스택, 기능 확장성, 실제 사용자 요구 등을 논의.
+
+### **2024년 10월 25일 - 프로젝트 아이디어 구체화**
+
+- **주제 선정 및 목표 설정**: 위치 기반 AR 커뮤니티 플랫폼 아이디어를 구체화. 사용자 위치에 따라 2D 메시지 오버레이 및 커뮤니티 기능 제안.
+- **기술 스택 논의**:
+ - FrontEnd :: React, TypeScript, Geolocation API, Naver Map API
+ - BackEnd :: Node.js/Express, JavaScript
+
+### **2024년 10월 28일 - 팀 운영 및 협업 방안 논의**
+
+- **운영 관련 논의**: 역할 분담, 크레딧 수령 계정 결정, 코드 컨벤션 및 스프린트 방식 도입.
+
+### **2024년 10월 30일 - 주제 선정 및 기술 스택 결정**
+
+- **주제 범위 좁히기**: 중장년층을 위한 지도 서비스 확정, 실시간 위치 공유 기능 설정.
+- **기술 스택 확정**: 프론트엔드(React, TypeScript, pnpm, Vite 등) 및 백엔드(Node.js, Express) 구성 결정.
+
+### **2024년 10월 31일 - 주제 확정 및 향후 계획 수립**
+
+- **주제 확정**: 중장년층 사용자가 쉽게 길 안내를 받게 해주는 모바일 웹 서비스.
+- **사전 준비 논의**: 코드 컨벤션, 핵심 기능 가능 여부 테스트, 커밋 전략 등을 수립하기 위한 사전 준비 작업에 대한 논의.
+
+## 📝 프로젝트 기획서
+
+> 프로젝트 기획서입니다.
+[📚 [2024-10-31] 프로젝트 기획서](./20241031-project-proposal.mdx)
diff --git a/docs/docusaurus/docs/archive/summary/20241031-project-proposal.mdx b/docs/docusaurus/docs/archive/summary/20241031-project-proposal.mdx
new file mode 100644
index 00000000..bc029cb8
--- /dev/null
+++ b/docs/docusaurus/docs/archive/summary/20241031-project-proposal.mdx
@@ -0,0 +1,239 @@
+---
+slug: 20241031-project-proposal
+title: 📚 [2024-10-31] 프로젝트 기획서
+sidebar_position: 6
+sidebar_label: 📚 [2024-10-31] 프로젝트 기획서
+keywords: ['프로젝트', '기획서']
+tags: [summary]
+last_update:
+ date: 2024-10-31
+ authors: [zen]
+---
+
+## 📝 프로젝트 요약
+
+### **프로젝트명**
+
+선따라 길따라 (DDara)
+
+### **팀명**
+
+따라따라
+
+### **프로젝트 한 줄 소개**
+
+중장년층 사용자가 쉽게 길 안내를 받게 해주는 모바일 웹서비스
+
+### **기술 키워드**
+
+#지도, #저작도구, #실시간 위치
+
+### **깃허브 링크**
+
+[https://github.com/boostcampwm-2024/web28-DDara](https://github.com/boostcampwm-2024/web28-DDara)
+
+## 📝 프로젝트 목표
+
+### **사용자 친화적인 길 안내 서비스 제공**
+
+중장년층도 쉽게 사용할 수 있는 직관적인 인터페이스와 기능을 제공합니다.
+
+### **실시간 위치 공유 및 경로 안내**
+
+실시간으로 위치를 공유하여, 사용자는 쉽게 위치를 파악할 수 있습니다.
+
+### **맞춤형 경로 설정**
+
+사용자가 자유롭게 지도 위에 경로를 그려, 원하는 경로를 공유할 수 있습니다.
+
+### **포트폴리오 가치 향상**
+
+팀원 모두가 프로젝트를 통해 기술 역량을 강화하고, 포트폴리오로 활용할 수 있도록 합니다.
+
+## 📝 프로젝트 배경 및 동기
+
+현대 사회에서 스마트폰과 네비게이션 앱은 필수적인 도구로 자리 잡았지만, 중장년층 사용자들에게는 여전히 복잡하고 사용하기 어려운 경우가 많습니다. 가족이나 친구들이 중장년층 사용자에게 길 안내를 해주고 싶지만, 기존의 지도 앱으로는 충분하지 않을 때가 있습니다. 이에 따라 중장년층이 쉽게 사용할 수 있는 맞춤형 길 안내 서비스를 제공하고자 본 프로젝트를 기획하였습니다.
+
+## 📝 서비스 예상 이미지
+
+[서비스 예상 이미지 링크](https://www.figma.com/design/r9nl4Jcz9VXIMbrpf50wY6/%EC%84%A0%EB%94%B0%EB%9D%BC-%EA%B8%B8%EB%94%B0%EB%9D%BC(Ddara)?node-id=90-1897&t=npJxpUAN7hkseqTk-1)
+
+## 📝 사용자 시나리오
+
+### 1. 사용자 유형 정의
+
+1. **일반 사용자**
+ - 웹 애플리케이션을 통해 지도를 보고, 그림을 그리고, 다른 사용자의 그림을 볼 수 있음.
+ - 아이디와 비밀번호로 로그인하여 자신의 그림을 생성, 수정(선 그리는 펜과 지우개 사용), 삭제할 수 있음.
+2. **비회원 사용자**
+ - 로그인하지 않고도 지도와 그림을 볼 수 있음.
+ - 그림을 생성하거나 수정할 수는 없음.
+
+### 2. 주요 시나리오
+
+#### 📝 시나리오 1: 회원 가입 (간단하게 구현)
+
+**배경**
+- 새로운 사용자인 **"홍길동"**은 위치 기반 그림 그리기 서비스를 이용하고자 한다.
+
+**단계**
+1. **접속**: 홍길동은 모바일 브라우저에서 웹 애플리케이션에 접속한다.
+2. **회원 가입 페이지 이동**: 화면 우측 상단의 "회원 가입" 버튼을 클릭한다.
+3. **정보 입력**: 아이디와 비밀번호 입력 후 가입 완료.
+4. **자동 로그인**: 가입 후 자동으로 로그인되어 메인 페이지로 이동한다.
+
+**예외 사항**
+- 비밀번호 불일치 시 경고 메시지 표시.
+
+#### 📝 시나리오 2: 로그인 및 로그아웃
+
+**단계**
+1. **로그인 페이지 이동** 후 정보 입력 및 로그인 성공.
+2. **로그아웃**: 우측 상단의 "로그아웃" 버튼 클릭.
+
+**예외 사항**
+- 잘못된 정보 시 경고 메시지 표시.
+
+#### 📝 시나리오 3: 지도 위에 그림 그리기 (펜 사용)
+
+**단계**
+1. **그리기 모드 진입** 후 **펜 도구 선택** 및 그림 그리기.
+2. **그림 저장** 후 저장 완료 메시지 표시.
+
+**예외 사항**
+- 저장 실패 시 재시도 요청.
+
+#### 📝 시나리오 4: 그림 수정 (지우개 사용)
+
+**단계**
+1. **수정 모드 진입** 후 **지우개 도구 선택**.
+2. **수정 후 저장**.
+
+**예외 사항**
+- 다른 사용자의 그림 수정 시 권한 부족 메시지 표시.
+
+#### 📝 시나리오 5: 지도 축소 및 확대 시 그림 연동
+
+**단계**
+1. **지도 축소 및 확대**에 따라 그림이 연동되어 표시됨.
+
+**예외 사항**
+- 동기화 오류 시 경고 메시지 표시.
+
+#### 📝 시나리오 6: 다른 사용자의 그림 보기
+
+**단계**
+1. **지도 탐색** 후 그림 선택 및 상세 정보 표시.
+
+**예외 사항**
+- 불러오기 실패 시 경고 메시지 표시.
+
+#### 📝 시나리오 7: 그림 삭제
+
+**단계**
+1. **내 그림 목록**에서 그림 선택 후 **삭제 수행**.
+
+**예외 사항**
+- 삭제 실패 시 경고 메시지 표시.
+
+#### 📝 시나리오 8: 비회원 사용자의 회원 가입 유도
+
+**단계**
+1. **그리기 모드 시도 시 팝업 표시**.
+2. **회원 가입 후 기능 사용 가능**.
+
+**예외 사항**
+- 가입하지 않을 경우 팝업 닫기.
+
+#### 📝 시나리오 9: 사용자 설정 변경 (펜과 지우개 설정)
+
+**단계**
+1. **설정 페이지 이동** 후 설정 변경 및 저장.
+
+**예외 사항**
+- 저장 실패 시 경고 메시지 표시.
+
+#### 📝 시나리오 10: 그림 공유하기
+
+**단계**
+1. **그림 선택 후 공유 링크 생성** 및 친구에게 공유.
+
+**예외 사항**
+- 비회원도 링크로 그림 확인 가능.
+
+#### 📝 시나리오 11: 경로 구분해서 추가
+
+**단계**
+1. **경로명 설정 후 저장 및 확인**.
+
+**예외 사항**
+- 오류 발생 시 이전 상태로 되돌림.
+
+#### 📝 시나리오 12: 다른 경로 확인
+
+**단계**
+1. **다른 경로 클릭 후 확인**.
+
+**예외 사항**
+- 오류 발생 시 이전 상태 유지.
+
+#### 📝 시나리오 13: 권한 허용
+
+**단계**
+1. **권한 요청 시 허용**.
+
+**예외 사항**
+- 미허용 시 재요청 메시지 표시.
+
+## 3. 추가 고려 사항
+
+- **지도와 그림의 동기화**: 지도의 확대/축소 시 그림도 연동.
+- **도구 제한**: 펜과 지우개만 제공.
+- **데이터 저장 및 동기화**: 좌표 정보 저장 및 렌더링.
+
+## 📝 유즈케이스
+
+
+
+### 설명:
+
+- **액터**:
+ - **사용자**: 로그인한 사용자로 모든 기능 사용.
+ - **비회원 사용자**: 제한된 기능 사용.
+
+- **유즈케이스**:
+ - **회원 가입, 로그인, 지도 보기, 그림 그리기/수정/삭제, 설정 변경, 그림 공유 등**.
+
+- **관계**:
+ - **포함 관계 (`<>`)**: 일부 기능이 다른 기능을 포함.
+ - **확장 관계 (`<>`)**: 특정 조건에서 기능 확장.
+
+## 📝 기술적인 도전
+
+### **모바일 환경 최적화**:
+- **Canvas API** 활용 및 성능 최적화.
+
+### **지도와 캔버스 동기화 최적화**:
+- **requestAnimationFrame**, **WebGL** 사용.
+
+### **테스트 자동화 및 CI/CD 구축**:
+- **Jest**, **Cypress**, **GitHub Actions** 사용.
+
+### **실시간 위치 추적 기능**:
+- **WebSocket** 및 **WebRTC**.
+
+### **오프라인 기능 구현**:
+- **Service Worker**, **Cache API** 사용.
+
+## 📝 사용 기술 스택
+
+### ⚙️ Front-End
+- React, TypeScript, pnpm, vite, swc, vitest, storybook, msw
+
+### ⚙️ Back-End
+- Node.js, JavaScript, pnpm, express
+
+## 📝 기타 참고 자료
+
+- [💡 기능 명세](https://github.com/boostcampwm-2024/web28-DDara/wiki/%F0%9F%92%A1-%EA%B8%B0%EB%8A%A5-%EB%AA%85%EC%84%B8)
+- [프로젝트 진행 상황 정리본](https://github.com/boostcampwm-2024/web28-DDara/wiki/%F0%9F%93%9A-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EC%A7%84%ED%96%89-%EC%83%81%ED%99%A9-%EC%A0%95%EB%A6%AC%EB%B3%B8-%28%EC%9E%91%EC%84%B1%EC%9D%BC-%3A-2024-10-31%29)
diff --git a/docs/docusaurus/docs/archive/summary/_category_.json b/docs/docusaurus/docs/archive/summary/_category_.json
new file mode 100644
index 00000000..38198ad7
--- /dev/null
+++ b/docs/docusaurus/docs/archive/summary/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "\uD83D\uDCDA 정리록",
+ "position": 1,
+ "link": {
+ "type": "generated-index",
+ "description": "회의나 활동 후의 내용을 정리하여 기록한 문서입니다."
+ }
+}
diff --git a/docs/docusaurus/docs/archive/summary/imgs/20241028_figjam.png b/docs/docusaurus/docs/archive/summary/imgs/20241028_figjam.png
new file mode 100644
index 00000000..6a3f902e
Binary files /dev/null and b/docs/docusaurus/docs/archive/summary/imgs/20241028_figjam.png differ
diff --git a/docs/docusaurus/docs/archive/tags.yml b/docs/docusaurus/docs/archive/tags.yml
new file mode 100644
index 00000000..f684360a
--- /dev/null
+++ b/docs/docusaurus/docs/archive/tags.yml
@@ -0,0 +1,29 @@
+mentoring:
+ label: 멘토링 일지
+ permalink: /mentoring
+ description: 멘토링 관련 문서 태그입니다.
+
+minutes:
+ label: 회의록
+ permalink: /minutes
+ description: 회의록 태그입니다.
+
+summary:
+ label: 정리본
+ permalink: /summary
+ description: 진행상황이나 각종 문서의 정리본에 대한 문서 태그입니다.
+
+prepare:
+ label: 사전 준비록
+ permalink: /prepare
+ description: 사전 준비와 관련된 문서 태그입니다.
+
+review:
+ label: 회고록
+ permalink: /review
+ description: 회고와 관련된 문서 태그입니다.
+
+scrum:
+ label: 스크럼 일지
+ permalink: /scrum
+ description: 스크럼과 관련된 문서 태그입니다.
\ No newline at end of file
diff --git a/docs/docusaurus/docs/study/about_members.mdx b/docs/docusaurus/docs/study/about_members.mdx
new file mode 100644
index 00000000..a0fc0661
--- /dev/null
+++ b/docs/docusaurus/docs/study/about_members.mdx
@@ -0,0 +1,22 @@
+---
+slug: about_members
+title: '🧑💻 팀원 소개'
+tags: [teamInfo]
+sidebar_position: 1
+sidebar_label: 🧑💻 팀원 소개
+keywords: ['members', 'team', '팀원', '소개']
+pagination_label: Markdown features
+last_update:
+ date: 2024-10-30
+ author: happyhyep
+---
+
+## 팀원 소개
+
+> Front-End 4명으로 구성되어 있으며, 전면 온라인으로 진행되었습니다.
+
+|J060_김주원|J174_이동율|J210_임재도|J234_정혜인|
+|:--:|:--:|:--:|:--:|
+|||||
+|FE|FE|FE|Full Stack (FE + BE)|
+|@juwon5272|@leedongyull|@effozen|@happyhyep|
\ No newline at end of file
diff --git a/docs/docusaurus/docs/study/intro.mdx b/docs/docusaurus/docs/study/intro.mdx
new file mode 100644
index 00000000..ef9966e2
--- /dev/null
+++ b/docs/docusaurus/docs/study/intro.mdx
@@ -0,0 +1,126 @@
+---
+slug: ground_rule
+title: ⚖️ Ground Rule
+tags: [teamInfo]
+sidebar_position: 2
+sidebar_label: ⚖️ 그라운드 룰
+keywords: ['members', 'team', '팀원', '소개']
+pagination_label: Markdown features
+last_update:
+ date: 2024-10-30
+ author: zen
+---
+
+
+
+> 우리들의 공통 목표와 그에 따른 행동 강령입니다.
+팀의 모든 의사결정은 그라운드 룰에 입각해서 판단합니다.
+>
+
+
+## ❓ 제 1 원칙
+
+### ❓ No Dummy Qeustion!
+
+- 세상에 바보같은 질문은 없습니다. 그 태도에 문제가 있을 뿐.
+- 저희는 절대 그 어떠한 질문에도 비웃음, 조소 등을 표하지 않습니다..!
+- 어떠한 질문에도 최선의 답을 제공합니다.
+- 반대로, 질문자는 반드시 질문하는 것에 대한 근거를 마련한 상태로 질문합니다.
+- 상호 예의를 존중합니다.
+
+
+
+## 📝 프로젝트에 대한 공통의 목표
+
+### 🚀 포트폴리오에 쓸 수 있는 실사용자를 위한 서비스
+
+- **포트폴리오에 담을 가치 있는 프로젝트를 개발**: 모든 팀원은 포트폴리오로 활용할 수 있는 완성도 높은 프로젝트를 목표로 한다.
+- **실사용자에게 의미 있는 서비스**: 프로젝트는 실제 사용자에게 도움이 될 수 있는 기능을 제공해야 한다. 재미를 위한 프로젝트일지라도, 명확한 사용자 경험(UX)을 기반으로 해야 함.
+- **유지보수 가능성**: 프로젝트는 지속적으로 유지보수될 수 있도록 설계하며, 최소 1년간 유지보수할 수 있도록 계획을 세운다.
+
+
+
+
+## 📝 기술적인 목표
+
+- 추후 주제가 정해지면 도입
+
+
+
+## 📝 팀 문화
+
+### 😆 싱글벙글 하하호호 우리들
+
+- **즐겁고 활발한 팀 분위기**: 팀원들 간에 **소통이 원활하고 편안한 분위기**를 유지한다. 스몰톡이나 비공식적인 대화를 통해 팀 분위기를 활기차게 유지하며, 서로의 동기부여를 위해 노력한다.
+- **건강과 워라밸 존중**: 과도한 업무보다는 건강을 최우선으로 고려하며, **휴식이 필요한 경우** 언제든 자유롭게 쉬는 문화를 장려한다. 장기적으로 **지속 가능한 프로젝트**를 목표로 한다. 단, 마감 직전이나 스프린트 때는 달린다.
+- **각자의 의견 존중**: 서로의 의견을 경청하고, 의견 충돌이 발생했을 때는 둘 사이에서 해결보다는 반드시 팀원 전체가 참여하여 논의한다. 이때, 다수결 또는 협의를 통해 해결한다. 필요한 경우 **카드를 사용한 의사결정 방식**(ex: "나 말 좀 하게 해줘 카드")을 도입해 원활한 의사결정을 진행할 수 있도록 한다.
+
+
+
+## 📝 협업 및 의사소통 규칙
+
+### 💬 잦은 커뮤니케이션을 할 수 있어야 한다.
+
+- **슬랙 및 협업 도구 활용**: 슬랙을 기본 소통 도구로 사용하며, 메시지를 읽었을 때는 **이모지 대신 명확한 답변**을 남겨 소통의 명확성을 유지한다.
+- **실시간 협업 도구 사용**: 실시간 소통이 필요한 경우, `Zep` 을 사용해 비대면 상황에서도 **실시간 피드백과 소통**이 이루어지도록 한다.
+- **코어 타임 준수**: 매일 10시부터 7시까지 코어 타임을 운영하며, 이 시간 동안에는 집중적으로 프로젝트에 참여하고 빠른 피드백을 제공한다. 코어 타임 외에는 자율적으로 활동할 수 있지만, 긴급한 상황에서는 `Zep`, `슬랙`을 통해 즉각적인 소통이 이루어져야 한다.
+- **신뢰**: 주변의 반응 및 생각에 흔들리지 말고, 팀이 결정한 내용을 전적으로 신뢰한다.
+
+
+
+
+## 📝 의사결정 방식
+
+### 🤝 팀 전체가 동의하는 의사결정
+
+- **의사결정은 팀 전체가 참여**: 주요 결정은 팀원 모두가 논의하며, GitHub Issue를 통해 정리된 문제점과 해결 방안을 공유한 후, 충분한 근거를 바탕으로 결정한다.
+- **데일리 스크럼**: 매일 아침 **데일리 스크럼**을 통해 각자의 작업 진행 상황을 공유하고, 문제점 및 해결책을 논의한다.
+- **긴급 의사결정**: 필요시 `Zep` 또는 `슬랙` 언급을 통해 팀원들을 소집해 **긴급 의사결정**을 빠르게 내린다.
+- **내 말좀 들어줘 카드!:** 각자 2 장의 카드가 부여되며, 서로가 납득할만한 수준에서 의견이 대립될 때 사용한다. 사용한 사람의 의견을 무조건적으로 수용한다. (”서로가 납득 가능한 상식선”이라는 전제)
+
+
+
+## 📝 프로젝트 개발 원칙
+
+### 😇 사용자 경험(UX) 중심의 개발
+
+- **사용자 경험(UX) 중심 개발**: 기술적인 완성도뿐만 아니라 **사용자의 관점에서 서비스의 유용성**을 고려한다. 기능이 잘 동작할 뿐 아니라, 사용자가 쉽게 이해하고 사용할 수 있어야 한다.
+- **작업 공유 및 문서화**: 모든 작업은 명확히 공유되어야 하며, **GitHub Issue**와 **노션**을 통해 진행 상황과 문제점을 기록한다. 트러블슈팅, 배운 기술, 이슈 등을 꼼꼼히 문서화해 프로젝트의 전체 진행을 기록한다.
+
+
+
+## 📝 작업 분배 및 기록 관리
+
+### 🧑🤝🧑 분업이 아닌 협업
+
+- **작업 기록 관리**: 모든 작업은 노션과 GitHub Pull Request, Issue 등을 통해 **투명하게 관리**된다. 이를 통해 프로젝트의 진행 상황을 쉽게 파악하고, 작업의 흐름을 유지할 수 있다.
+- **스프린트 방식 도입**: 코어 타임 내에서 주어진 작업을 마무리하고, **주 단위로 목표를 설정해 달성 여부를 확인**한다. 스프린트 종료 후 회고를 진행해 다음 스프린트에 반영할 개선점을 도출한다.
+
+
+
+## 📝 코드 리뷰 및 PR 규칙
+
+### 🧑💻 4명의 PR Approve 및 최소 주 2회의 코드 리뷰
+
+- **최소 주 2회의 컨벤션 및 맥락 파악 목적의 코드 리뷰**: 팀원들이 서로의 코드를 리뷰하며, 코드의 품질도 중요하지만, 이때의 핵심은 우리의 컨벤션을 서로 얼마나 잘 지키고 있는지 이다.. 코드 리뷰는 팀원의 성장뿐 아니라, **서로의 작업을 이해하고 소통하는 과정**으로 삼는다. 즉, 각자의 개발 맥락을 파악하는 목적을 주로 한다.
+- **PR 승인 규칙**: 4명 모두의 **PR 승인**이 있어야만 기능을 머지할 수 있으며, 모든 팀원이 해당 기능에 대한 충분한 이해를 갖출 수 있도록 한다.
+- **작업의 투명성 유지**: 코드 리뷰와 PR을 통해 프로젝트의 모든 진행이 투명하게 공유되며, 이는 팀원 간의 신뢰를 강화하는 중요한 요소로 작용한다.
+- **데일리 스크럼의 활용:** 이슈나, 코드 공유 등은 데일리 스크럼 시간에 더하여, 아침에 소통하도록 한다.
+
+
+
+## 📝 프로젝트 회고
+
+### 🎨 Figma, Miro 등을 이용한 시각적인 회고
+
+- **회고 방식**: 프로젝트 진행 중 **KPT(Keep, Problem, Try) 방식**으로 주기적인 회고를 진행해, 잘한 부분과 개선할 점을 분석하고 다음 스프린트에 반영한다. 피드백은 GitHub 또는 피그마 등을 활용해 시각적으로 정리한다.
+- **결과 기록**: 회고 내용과 함께 프로젝트 과정에서의 문제점과 해결 방안을 기록하여 **포트폴리오에서 활용**할 수 있는 자료로 남긴다.
+
+
+
+## 📝 긴급 상황 대응
+
+### 👀 ”이의있소!”
+
+- **TMT, TMI 방지 카드**: 각 팀원은 필요시 언제든지 **"나 힘들다 카드"**를 사용해 TMT, TMI를 막을 수 있다. 이때, 😪, 😴 와 같은 이모지나 기능을 사용해서 알린다.
+- **스톱 카드**: 기술에 대한 학습이나, 구현이 요구사항을 넘어서 너무 깊어질 경우 **"스톱 카드"**를 사용해 중단시키고, 본래 해야하는 업무에 집중시킨다. 이는 PR 리뷰를 하면서든, 언제든지 자유롭게 제안할 수 있다.
diff --git a/docs/docusaurus/docs/study/test.mdx b/docs/docusaurus/docs/study/test.mdx
new file mode 100644
index 00000000..a08c1661
--- /dev/null
+++ b/docs/docusaurus/docs/study/test.mdx
@@ -0,0 +1,13 @@
+---
+slug: test
+title: ⚖️ test
+tags: [teamInfo]
+sidebar_position: 3
+sidebar_label: ⚖️ 그라운드 룰
+keywords: ['members', 'team', '팀원', '소개']
+pagination_label: Markdown features
+last_update:
+ date: 2024-10-30
+ author: zen
+---
+test2
\ No newline at end of file
diff --git a/docs/docusaurus/docs/wiki/about_members.mdx b/docs/docusaurus/docs/wiki/about_members.mdx
new file mode 100644
index 00000000..a0fc0661
--- /dev/null
+++ b/docs/docusaurus/docs/wiki/about_members.mdx
@@ -0,0 +1,22 @@
+---
+slug: about_members
+title: '🧑💻 팀원 소개'
+tags: [teamInfo]
+sidebar_position: 1
+sidebar_label: 🧑💻 팀원 소개
+keywords: ['members', 'team', '팀원', '소개']
+pagination_label: Markdown features
+last_update:
+ date: 2024-10-30
+ author: happyhyep
+---
+
+## 팀원 소개
+
+> Front-End 4명으로 구성되어 있으며, 전면 온라인으로 진행되었습니다.
+
+|J060_김주원|J174_이동율|J210_임재도|J234_정혜인|
+|:--:|:--:|:--:|:--:|
+|||||
+|FE|FE|FE|Full Stack (FE + BE)|
+|@juwon5272|@leedongyull|@effozen|@happyhyep|
\ No newline at end of file
diff --git a/docs/docusaurus/docs/wiki/intro.mdx b/docs/docusaurus/docs/wiki/intro.mdx
new file mode 100644
index 00000000..ef9966e2
--- /dev/null
+++ b/docs/docusaurus/docs/wiki/intro.mdx
@@ -0,0 +1,126 @@
+---
+slug: ground_rule
+title: ⚖️ Ground Rule
+tags: [teamInfo]
+sidebar_position: 2
+sidebar_label: ⚖️ 그라운드 룰
+keywords: ['members', 'team', '팀원', '소개']
+pagination_label: Markdown features
+last_update:
+ date: 2024-10-30
+ author: zen
+---
+
+
+
+> 우리들의 공통 목표와 그에 따른 행동 강령입니다.
+팀의 모든 의사결정은 그라운드 룰에 입각해서 판단합니다.
+>
+
+
+## ❓ 제 1 원칙
+
+### ❓ No Dummy Qeustion!
+
+- 세상에 바보같은 질문은 없습니다. 그 태도에 문제가 있을 뿐.
+- 저희는 절대 그 어떠한 질문에도 비웃음, 조소 등을 표하지 않습니다..!
+- 어떠한 질문에도 최선의 답을 제공합니다.
+- 반대로, 질문자는 반드시 질문하는 것에 대한 근거를 마련한 상태로 질문합니다.
+- 상호 예의를 존중합니다.
+
+
+
+## 📝 프로젝트에 대한 공통의 목표
+
+### 🚀 포트폴리오에 쓸 수 있는 실사용자를 위한 서비스
+
+- **포트폴리오에 담을 가치 있는 프로젝트를 개발**: 모든 팀원은 포트폴리오로 활용할 수 있는 완성도 높은 프로젝트를 목표로 한다.
+- **실사용자에게 의미 있는 서비스**: 프로젝트는 실제 사용자에게 도움이 될 수 있는 기능을 제공해야 한다. 재미를 위한 프로젝트일지라도, 명확한 사용자 경험(UX)을 기반으로 해야 함.
+- **유지보수 가능성**: 프로젝트는 지속적으로 유지보수될 수 있도록 설계하며, 최소 1년간 유지보수할 수 있도록 계획을 세운다.
+
+
+
+
+## 📝 기술적인 목표
+
+- 추후 주제가 정해지면 도입
+
+
+
+## 📝 팀 문화
+
+### 😆 싱글벙글 하하호호 우리들
+
+- **즐겁고 활발한 팀 분위기**: 팀원들 간에 **소통이 원활하고 편안한 분위기**를 유지한다. 스몰톡이나 비공식적인 대화를 통해 팀 분위기를 활기차게 유지하며, 서로의 동기부여를 위해 노력한다.
+- **건강과 워라밸 존중**: 과도한 업무보다는 건강을 최우선으로 고려하며, **휴식이 필요한 경우** 언제든 자유롭게 쉬는 문화를 장려한다. 장기적으로 **지속 가능한 프로젝트**를 목표로 한다. 단, 마감 직전이나 스프린트 때는 달린다.
+- **각자의 의견 존중**: 서로의 의견을 경청하고, 의견 충돌이 발생했을 때는 둘 사이에서 해결보다는 반드시 팀원 전체가 참여하여 논의한다. 이때, 다수결 또는 협의를 통해 해결한다. 필요한 경우 **카드를 사용한 의사결정 방식**(ex: "나 말 좀 하게 해줘 카드")을 도입해 원활한 의사결정을 진행할 수 있도록 한다.
+
+
+
+## 📝 협업 및 의사소통 규칙
+
+### 💬 잦은 커뮤니케이션을 할 수 있어야 한다.
+
+- **슬랙 및 협업 도구 활용**: 슬랙을 기본 소통 도구로 사용하며, 메시지를 읽었을 때는 **이모지 대신 명확한 답변**을 남겨 소통의 명확성을 유지한다.
+- **실시간 협업 도구 사용**: 실시간 소통이 필요한 경우, `Zep` 을 사용해 비대면 상황에서도 **실시간 피드백과 소통**이 이루어지도록 한다.
+- **코어 타임 준수**: 매일 10시부터 7시까지 코어 타임을 운영하며, 이 시간 동안에는 집중적으로 프로젝트에 참여하고 빠른 피드백을 제공한다. 코어 타임 외에는 자율적으로 활동할 수 있지만, 긴급한 상황에서는 `Zep`, `슬랙`을 통해 즉각적인 소통이 이루어져야 한다.
+- **신뢰**: 주변의 반응 및 생각에 흔들리지 말고, 팀이 결정한 내용을 전적으로 신뢰한다.
+
+
+
+
+## 📝 의사결정 방식
+
+### 🤝 팀 전체가 동의하는 의사결정
+
+- **의사결정은 팀 전체가 참여**: 주요 결정은 팀원 모두가 논의하며, GitHub Issue를 통해 정리된 문제점과 해결 방안을 공유한 후, 충분한 근거를 바탕으로 결정한다.
+- **데일리 스크럼**: 매일 아침 **데일리 스크럼**을 통해 각자의 작업 진행 상황을 공유하고, 문제점 및 해결책을 논의한다.
+- **긴급 의사결정**: 필요시 `Zep` 또는 `슬랙` 언급을 통해 팀원들을 소집해 **긴급 의사결정**을 빠르게 내린다.
+- **내 말좀 들어줘 카드!:** 각자 2 장의 카드가 부여되며, 서로가 납득할만한 수준에서 의견이 대립될 때 사용한다. 사용한 사람의 의견을 무조건적으로 수용한다. (”서로가 납득 가능한 상식선”이라는 전제)
+
+
+
+## 📝 프로젝트 개발 원칙
+
+### 😇 사용자 경험(UX) 중심의 개발
+
+- **사용자 경험(UX) 중심 개발**: 기술적인 완성도뿐만 아니라 **사용자의 관점에서 서비스의 유용성**을 고려한다. 기능이 잘 동작할 뿐 아니라, 사용자가 쉽게 이해하고 사용할 수 있어야 한다.
+- **작업 공유 및 문서화**: 모든 작업은 명확히 공유되어야 하며, **GitHub Issue**와 **노션**을 통해 진행 상황과 문제점을 기록한다. 트러블슈팅, 배운 기술, 이슈 등을 꼼꼼히 문서화해 프로젝트의 전체 진행을 기록한다.
+
+
+
+## 📝 작업 분배 및 기록 관리
+
+### 🧑🤝🧑 분업이 아닌 협업
+
+- **작업 기록 관리**: 모든 작업은 노션과 GitHub Pull Request, Issue 등을 통해 **투명하게 관리**된다. 이를 통해 프로젝트의 진행 상황을 쉽게 파악하고, 작업의 흐름을 유지할 수 있다.
+- **스프린트 방식 도입**: 코어 타임 내에서 주어진 작업을 마무리하고, **주 단위로 목표를 설정해 달성 여부를 확인**한다. 스프린트 종료 후 회고를 진행해 다음 스프린트에 반영할 개선점을 도출한다.
+
+
+
+## 📝 코드 리뷰 및 PR 규칙
+
+### 🧑💻 4명의 PR Approve 및 최소 주 2회의 코드 리뷰
+
+- **최소 주 2회의 컨벤션 및 맥락 파악 목적의 코드 리뷰**: 팀원들이 서로의 코드를 리뷰하며, 코드의 품질도 중요하지만, 이때의 핵심은 우리의 컨벤션을 서로 얼마나 잘 지키고 있는지 이다.. 코드 리뷰는 팀원의 성장뿐 아니라, **서로의 작업을 이해하고 소통하는 과정**으로 삼는다. 즉, 각자의 개발 맥락을 파악하는 목적을 주로 한다.
+- **PR 승인 규칙**: 4명 모두의 **PR 승인**이 있어야만 기능을 머지할 수 있으며, 모든 팀원이 해당 기능에 대한 충분한 이해를 갖출 수 있도록 한다.
+- **작업의 투명성 유지**: 코드 리뷰와 PR을 통해 프로젝트의 모든 진행이 투명하게 공유되며, 이는 팀원 간의 신뢰를 강화하는 중요한 요소로 작용한다.
+- **데일리 스크럼의 활용:** 이슈나, 코드 공유 등은 데일리 스크럼 시간에 더하여, 아침에 소통하도록 한다.
+
+
+
+## 📝 프로젝트 회고
+
+### 🎨 Figma, Miro 등을 이용한 시각적인 회고
+
+- **회고 방식**: 프로젝트 진행 중 **KPT(Keep, Problem, Try) 방식**으로 주기적인 회고를 진행해, 잘한 부분과 개선할 점을 분석하고 다음 스프린트에 반영한다. 피드백은 GitHub 또는 피그마 등을 활용해 시각적으로 정리한다.
+- **결과 기록**: 회고 내용과 함께 프로젝트 과정에서의 문제점과 해결 방안을 기록하여 **포트폴리오에서 활용**할 수 있는 자료로 남긴다.
+
+
+
+## 📝 긴급 상황 대응
+
+### 👀 ”이의있소!”
+
+- **TMT, TMI 방지 카드**: 각 팀원은 필요시 언제든지 **"나 힘들다 카드"**를 사용해 TMT, TMI를 막을 수 있다. 이때, 😪, 😴 와 같은 이모지나 기능을 사용해서 알린다.
+- **스톱 카드**: 기술에 대한 학습이나, 구현이 요구사항을 넘어서 너무 깊어질 경우 **"스톱 카드"**를 사용해 중단시키고, 본래 해야하는 업무에 집중시킨다. 이는 PR 리뷰를 하면서든, 언제든지 자유롭게 제안할 수 있다.
diff --git a/docs/docusaurus/docs/wiki/wiki/test.mdx b/docs/docusaurus/docs/wiki/wiki/test.mdx
new file mode 100644
index 00000000..42bc005b
--- /dev/null
+++ b/docs/docusaurus/docs/wiki/wiki/test.mdx
@@ -0,0 +1,126 @@
+---
+slug: test
+title: ⚖️ Ground test
+tags: [teamInfo]
+sidebar_position: 1
+sidebar_label: ⚖️ 그라운드 룰
+keywords: ['members', 'team', '팀원', '소개']
+pagination_label: Markdown features
+last_update:
+ date: 2024-10-30
+ author: zen
+---
+
+
+
+> 우리들의 공통 목표와 그에 따른 행동 강령입니다.
+팀의 모든 의사결정은 그라운드 룰에 입각해서 판단합니다.
+>
+
+
+## ❓ 제 1 원칙
+
+### ❓ No Dummy Qeustion!
+
+- 세상에 바보같은 질문은 없습니다. 그 태도에 문제가 있을 뿐.
+- 저희는 절대 그 어떠한 질문에도 비웃음, 조소 등을 표하지 않습니다..!
+- 어떠한 질문에도 최선의 답을 제공합니다.
+- 반대로, 질문자는 반드시 질문하는 것에 대한 근거를 마련한 상태로 질문합니다.
+- 상호 예의를 존중합니다.
+
+
+
+## 📝 프로젝트에 대한 공통의 목표
+
+### 🚀 포트폴리오에 쓸 수 있는 실사용자를 위한 서비스
+
+- **포트폴리오에 담을 가치 있는 프로젝트를 개발**: 모든 팀원은 포트폴리오로 활용할 수 있는 완성도 높은 프로젝트를 목표로 한다.
+- **실사용자에게 의미 있는 서비스**: 프로젝트는 실제 사용자에게 도움이 될 수 있는 기능을 제공해야 한다. 재미를 위한 프로젝트일지라도, 명확한 사용자 경험(UX)을 기반으로 해야 함.
+- **유지보수 가능성**: 프로젝트는 지속적으로 유지보수될 수 있도록 설계하며, 최소 1년간 유지보수할 수 있도록 계획을 세운다.
+
+
+
+
+## 📝 기술적인 목표
+
+- 추후 주제가 정해지면 도입
+
+
+
+## 📝 팀 문화
+
+### 😆 싱글벙글 하하호호 우리들
+
+- **즐겁고 활발한 팀 분위기**: 팀원들 간에 **소통이 원활하고 편안한 분위기**를 유지한다. 스몰톡이나 비공식적인 대화를 통해 팀 분위기를 활기차게 유지하며, 서로의 동기부여를 위해 노력한다.
+- **건강과 워라밸 존중**: 과도한 업무보다는 건강을 최우선으로 고려하며, **휴식이 필요한 경우** 언제든 자유롭게 쉬는 문화를 장려한다. 장기적으로 **지속 가능한 프로젝트**를 목표로 한다. 단, 마감 직전이나 스프린트 때는 달린다.
+- **각자의 의견 존중**: 서로의 의견을 경청하고, 의견 충돌이 발생했을 때는 둘 사이에서 해결보다는 반드시 팀원 전체가 참여하여 논의한다. 이때, 다수결 또는 협의를 통해 해결한다. 필요한 경우 **카드를 사용한 의사결정 방식**(ex: "나 말 좀 하게 해줘 카드")을 도입해 원활한 의사결정을 진행할 수 있도록 한다.
+
+
+
+## 📝 협업 및 의사소통 규칙
+
+### 💬 잦은 커뮤니케이션을 할 수 있어야 한다.
+
+- **슬랙 및 협업 도구 활용**: 슬랙을 기본 소통 도구로 사용하며, 메시지를 읽었을 때는 **이모지 대신 명확한 답변**을 남겨 소통의 명확성을 유지한다.
+- **실시간 협업 도구 사용**: 실시간 소통이 필요한 경우, `Zep` 을 사용해 비대면 상황에서도 **실시간 피드백과 소통**이 이루어지도록 한다.
+- **코어 타임 준수**: 매일 10시부터 7시까지 코어 타임을 운영하며, 이 시간 동안에는 집중적으로 프로젝트에 참여하고 빠른 피드백을 제공한다. 코어 타임 외에는 자율적으로 활동할 수 있지만, 긴급한 상황에서는 `Zep`, `슬랙`을 통해 즉각적인 소통이 이루어져야 한다.
+- **신뢰**: 주변의 반응 및 생각에 흔들리지 말고, 팀이 결정한 내용을 전적으로 신뢰한다.
+
+
+
+
+## 📝 의사결정 방식
+
+### 🤝 팀 전체가 동의하는 의사결정
+
+- **의사결정은 팀 전체가 참여**: 주요 결정은 팀원 모두가 논의하며, GitHub Issue를 통해 정리된 문제점과 해결 방안을 공유한 후, 충분한 근거를 바탕으로 결정한다.
+- **데일리 스크럼**: 매일 아침 **데일리 스크럼**을 통해 각자의 작업 진행 상황을 공유하고, 문제점 및 해결책을 논의한다.
+- **긴급 의사결정**: 필요시 `Zep` 또는 `슬랙` 언급을 통해 팀원들을 소집해 **긴급 의사결정**을 빠르게 내린다.
+- **내 말좀 들어줘 카드!:** 각자 2 장의 카드가 부여되며, 서로가 납득할만한 수준에서 의견이 대립될 때 사용한다. 사용한 사람의 의견을 무조건적으로 수용한다. (”서로가 납득 가능한 상식선”이라는 전제)
+
+
+
+## 📝 프로젝트 개발 원칙
+
+### 😇 사용자 경험(UX) 중심의 개발
+
+- **사용자 경험(UX) 중심 개발**: 기술적인 완성도뿐만 아니라 **사용자의 관점에서 서비스의 유용성**을 고려한다. 기능이 잘 동작할 뿐 아니라, 사용자가 쉽게 이해하고 사용할 수 있어야 한다.
+- **작업 공유 및 문서화**: 모든 작업은 명확히 공유되어야 하며, **GitHub Issue**와 **노션**을 통해 진행 상황과 문제점을 기록한다. 트러블슈팅, 배운 기술, 이슈 등을 꼼꼼히 문서화해 프로젝트의 전체 진행을 기록한다.
+
+
+
+## 📝 작업 분배 및 기록 관리
+
+### 🧑🤝🧑 분업이 아닌 협업
+
+- **작업 기록 관리**: 모든 작업은 노션과 GitHub Pull Request, Issue 등을 통해 **투명하게 관리**된다. 이를 통해 프로젝트의 진행 상황을 쉽게 파악하고, 작업의 흐름을 유지할 수 있다.
+- **스프린트 방식 도입**: 코어 타임 내에서 주어진 작업을 마무리하고, **주 단위로 목표를 설정해 달성 여부를 확인**한다. 스프린트 종료 후 회고를 진행해 다음 스프린트에 반영할 개선점을 도출한다.
+
+
+
+## 📝 코드 리뷰 및 PR 규칙
+
+### 🧑💻 4명의 PR Approve 및 최소 주 2회의 코드 리뷰
+
+- **최소 주 2회의 컨벤션 및 맥락 파악 목적의 코드 리뷰**: 팀원들이 서로의 코드를 리뷰하며, 코드의 품질도 중요하지만, 이때의 핵심은 우리의 컨벤션을 서로 얼마나 잘 지키고 있는지 이다.. 코드 리뷰는 팀원의 성장뿐 아니라, **서로의 작업을 이해하고 소통하는 과정**으로 삼는다. 즉, 각자의 개발 맥락을 파악하는 목적을 주로 한다.
+- **PR 승인 규칙**: 4명 모두의 **PR 승인**이 있어야만 기능을 머지할 수 있으며, 모든 팀원이 해당 기능에 대한 충분한 이해를 갖출 수 있도록 한다.
+- **작업의 투명성 유지**: 코드 리뷰와 PR을 통해 프로젝트의 모든 진행이 투명하게 공유되며, 이는 팀원 간의 신뢰를 강화하는 중요한 요소로 작용한다.
+- **데일리 스크럼의 활용:** 이슈나, 코드 공유 등은 데일리 스크럼 시간에 더하여, 아침에 소통하도록 한다.
+
+
+
+## 📝 프로젝트 회고
+
+### 🎨 Figma, Miro 등을 이용한 시각적인 회고
+
+- **회고 방식**: 프로젝트 진행 중 **KPT(Keep, Problem, Try) 방식**으로 주기적인 회고를 진행해, 잘한 부분과 개선할 점을 분석하고 다음 스프린트에 반영한다. 피드백은 GitHub 또는 피그마 등을 활용해 시각적으로 정리한다.
+- **결과 기록**: 회고 내용과 함께 프로젝트 과정에서의 문제점과 해결 방안을 기록하여 **포트폴리오에서 활용**할 수 있는 자료로 남긴다.
+
+
+
+ );
+}
diff --git a/docs/docusaurus/src/components/HomepageFeatures/styles.module.css b/docs/docusaurus/src/components/HomepageFeatures/styles.module.css
new file mode 100644
index 00000000..b248eb2e
--- /dev/null
+++ b/docs/docusaurus/src/components/HomepageFeatures/styles.module.css
@@ -0,0 +1,11 @@
+.features {
+ display: flex;
+ align-items: center;
+ padding: 2rem 0;
+ width: 100%;
+}
+
+.featureSvg {
+ height: 200px;
+ width: 200px;
+}
diff --git a/docs/docusaurus/src/css/custom.css b/docs/docusaurus/src/css/custom.css
new file mode 100644
index 00000000..7fad3e99
--- /dev/null
+++ b/docs/docusaurus/src/css/custom.css
@@ -0,0 +1,206 @@
+/**
+ * Any CSS included here will be global. The classic template
+ * bundles Infima by default. Infima is a CSS framework designed to
+ * work well for content-centric websites.
+ */
+
+/* You can override the default Infima variables here. */
+:root {
+ --ifm-color-primary: #0052CC; /* Atlassian 파란색 */
+ --ifm-color-primary-dark: #0041a8; /* 더 어두운 Atlassian 파란색 */
+ --ifm-color-primary-darker: #00338a; /* 한층 더 어두운 파란색 */
+ --ifm-color-primary-darkest: #00226b; /* 가장 어두운 파란색 */
+ --ifm-color-primary-light: #0065ff; /* 더 밝은 Atlassian 파란색 */
+ --ifm-color-primary-lighter: #3385ff; /* 한층 더 밝은 파란색 */
+ --ifm-color-primary-lightest: #669eff; /* 가장 밝은 파란색 */
+
+ /* 보라색 계열 (Atlassian 팔레트 기반) */
+ --ifm-color-secondary: #6554C0; /* Atlassian 보라색 */
+ --ifm-color-secondary-dark: #5243AA; /* 더 어두운 보라색 */
+ --ifm-color-secondary-darker: #403294; /* 한층 더 어두운 보라색 */
+ --ifm-color-secondary-darkest: #35297A; /* 가장 어두운 보라색 */
+ --ifm-color-secondary-light: #8777D9; /* 더 밝은 보라색 */
+ --ifm-color-secondary-lighter: #998DD9; /* 한층 더 밝은 보라색 */
+ --ifm-color-secondary-lightest: #B3A7E6; /* 가장 밝은 보라색 */
+
+ /* Teal 계열 (Atlassian 팔레트 기반) */
+ --ifm-color-tertiary: #00B8D9; /* Atlassian Teal */
+ --ifm-color-tertiary-dark: #00A3BF; /* 더 어두운 Teal */
+ --ifm-color-tertiary-darker: #008DA6; /* 한층 더 어두운 Teal */
+ --ifm-color-tertiary-darkest: #00758C; /* 가장 어두운 Teal */
+ --ifm-color-tertiary-light: #33CFFF; /* 더 밝은 Teal */
+ --ifm-color-tertiary-lighter: #66D9FF; /* 한층 더 밝은 Teal */
+ --ifm-color-tertiary-lightest: #99E3FF; /* 가장 밝은 Teal */
+
+ /* 주황색 계열 (Atlassian 팔레트 기반) */
+ --ifm-color-quaternary: #FF5630; /* Atlassian 주황색 */
+ --ifm-color-quaternary-dark: #E44A26; /* 더 어두운 주황색 */
+ --ifm-color-quaternary-darker: #CC3D1D; /* 한층 더 어두운 주황색 */
+ --ifm-color-quaternary-darkest: #B33315; /* 가장 어두운 주황색 */
+ --ifm-color-quaternary-light: #FF7452; /* 더 밝은 주황색 */
+ --ifm-color-quaternary-lighter: #FF8C70; /* 한층 더 밝은 주황색 */
+ --ifm-color-quaternary-lightest: #FFAAA0; /* 가장 밝은 주황색 */
+
+ /* 녹색 계열 (Atlassian 팔레트 기반) */
+ --ifm-color-quinary: #36B37E; /* Atlassian 녹색 */
+ --ifm-color-quinary-dark: #2E9A69; /* 더 어두운 녹색 */
+ --ifm-color-quinary-darker: #257D55; /* 한층 더 어두운 녹색 */
+ --ifm-color-quinary-darkest: #1E6344; /* 가장 어두운 녹색 */
+ --ifm-color-quinary-light: #57D9A3; /* 더 밝은 녹색 */
+ --ifm-color-quinary-lighter: #79E3B8; /* 한층 더 밝은 녹색 */
+ --ifm-color-quinary-lightest: #9FEFD0; /* 가장 밝은 녹색 */
+
+ --ifm-code-font-size: 95%;
+ --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.1);
+}
+
+/* 어두운 모드에서 가독성을 위해 밝은 색상 팔레트를 사용합니다. */
+[data-theme='dark'] {
+ --ifm-color-primary: #4c9aff; /* 밝은 Atlassian 파란색 */
+ --ifm-color-primary-dark: #3b89e6; /* 어두운 파란색 */
+ --ifm-color-primary-darker: #2c70cc; /* 더 어두운 파란색 */
+ --ifm-color-primary-darkest: #1c58b3; /* 가장 어두운 파란색 */
+ --ifm-color-primary-light: #66aaff; /* 더 밝은 파란색 */
+ --ifm-color-primary-lighter: #80b9ff; /* 한층 더 밝은 파란색 */
+ --ifm-color-primary-lightest: #99c8ff; /* 가장 밝은 파란색 */
+
+ /* 어두운 모드용 보라색 */
+ --ifm-color-secondary: #8777D9; /* 밝은 보라색 */
+ --ifm-color-secondary-dark: #7565C2; /* 어두운 보라색 */
+ --ifm-color-secondary-darker: #634FA9; /* 더 어두운 보라색 */
+ --ifm-color-secondary-darkest: #513E90; /* 가장 어두운 보라색 */
+ --ifm-color-secondary-light: #998DD9; /* 한층 더 밝은 보라색 */
+ --ifm-color-secondary-lighter: #B3A7E6; /* 더 밝은 보라색 */
+ --ifm-color-secondary-lightest: #D1C3ED; /* 가장 밝은 보라색 */
+
+ /* 어두운 모드용 Teal */
+ --ifm-color-tertiary: #33CFFF; /* 밝은 Teal */
+ --ifm-color-tertiary-dark: #29B7E6; /* 어두운 Teal */
+ --ifm-color-tertiary-darker: #209EBF; /* 더 어두운 Teal */
+ --ifm-color-tertiary-darkest: #17758C; /* 가장 어두운 Teal */
+ --ifm-color-tertiary-light: #66D9FF; /* 한층 더 밝은 Teal */
+ --ifm-color-tertiary-lighter: #99E3FF; /* 더 밝은 Teal */
+ --ifm-color-tertiary-lightest: #CCEDFF; /* 가장 밝은 Teal */
+
+ /* 어두운 모드용 주황색 */
+ --ifm-color-quaternary: #FF7452; /* 밝은 주황색 */
+ --ifm-color-quaternary-dark: #E86345; /* 어두운 주황색 */
+ --ifm-color-quaternary-darker: #D45338; /* 더 어두운 주황색 */
+ --ifm-color-quaternary-darkest: #BF452D; /* 가장 어두운 주황색 */
+ --ifm-color-quaternary-light: #FF8C70; /* 한층 더 밝은 주황색 */
+ --ifm-color-quaternary-lighter: #FFAAA0; /* 더 밝은 주황색 */
+ --ifm-color-quaternary-lightest: #FFC5BE; /* 가장 밝은 주황색 */
+
+ /* 어두운 모드용 녹색 */
+ --ifm-color-quinary: #57D9A3; /* 밝은 녹색 */
+ --ifm-color-quinary-dark: #4FC291; /* 어두운 녹색 */
+ --ifm-color-quinary-darker: #47AB7E; /* 더 어두운 녹색 */
+ --ifm-color-quinary-darkest: #3D926B; /* 가장 어두운 녹색 */
+ --ifm-color-quinary-light: #79E3B8; /* 한층 더 밝은 녹색 */
+ --ifm-color-quinary-lighter: #9FEFD0; /* 더 밝은 녹색 */
+ --ifm-color-quinary-lightest: #C4FADF; /* 가장 밝은 녹색 */
+
+ --docusaurus-highlighted-code-line-bg: rgba(255, 255, 255, 0.15);
+}
+
+/* theme-doc-markdown */
+
+.markdown h1 {
+ font-size: 2.2rem;
+}
+
+.markdown h2 {
+ margin-top: 6.5rem !important;
+ margin-bottom: 2rem;
+ font-size: 1.7rem; /* 원하는 크기로 조정 */
+ color: var(--ifm-color-secondary-dark); /* 원하는 색상으로 조정 */
+}
+
+.markdown h3 {
+ margin-top: 1.8rem !important;
+ margin-bottom: 1.5rem;
+ font-size: 1.5rem; /* 원하는 크기로 조정 */
+ color: var(--ifm-color-tertiary-dark); /* 원하는 색상으로 조정 */
+}
+
+.markdown figure {
+ display: flex;
+ flex-direction: column;
+ justify-content: center;
+ align-items: center;
+}
+
+.markdown figcaption {
+ margin-top: 0.5rem;
+ color: var(--ifm-color-primary-light); /* 원하는 색상으로 조정 */
+}
+
+.markdown strong {
+ color: var(--ifm-color-quaternary-dark); /* 원하는 색상으로 조정 */
+}
+
+header {
+ padding-bottom: 2rem;
+ border-bottom: 1px solid #ccc;
+}
+
+header h1 {
+ font-size: 2.2rem !important;
+}
+
+/* 태그에 대한 CSS */
+
+/* 부모 요소에 Flexbox와 gap 적용 */
+.blog-list-page main {
+ display: flex;
+ flex-direction: column;
+ gap: 0; /* 원하는 간격으로 조정 */
+}
+
+/* 블로그 리스트 페이지에서 각 포스트 미리보기에 테두리 추가 */
+.blog-list-page main article {
+ border: 1px solid #ccc;
+ padding: 2.5rem;
+ border-radius: 5px;
+ margin-bottom: 3rem !important;
+}
+
+/* 블로그 미리보기에서 h2의 margin-top 제거 */
+.blog-list-page main article h2 {
+ margin-top: 0;
+}
+
+/* 블로그 미리보기에서 폰트 크기 축소 */
+.blog-list-page main article {
+ font-size: 0.9em;
+}
+
+/* 블로그 미리보기에서 이미지 크기 축소 */
+.blog-list-page main article img {
+ max-width: 80%;
+ height: auto;
+}
+
+/* 블로그 미리보기에서 h2의 margin-top 제거 */
+.blog-list-page main article .markdown h2 {
+ margin-top: 3rem !important;
+}
+
+.blog-tags-post-list-page main article {
+ border: 1px solid #ccc;
+ padding: 2.5rem;
+ margin-bottom: 3rem !important;
+ border-radius: 5px;
+}
+
+.theme-doc-footer {
+ margin-top: 10rem !important;
+}
+
+blockquote {
+ border-left: 5px solid var(--ifm-color-primary-light);
+ padding-left: 1rem;
+ margin-left: 0;
+ margin-top: 2rem !important;
+ margin-bottom: 2rem;
+}
\ No newline at end of file
diff --git a/docs/docusaurus/src/pages/index.mdx b/docs/docusaurus/src/pages/index.mdx
new file mode 100644
index 00000000..02ff20e1
--- /dev/null
+++ b/docs/docusaurus/src/pages/index.mdx
@@ -0,0 +1,60 @@
+