회의에 솔루션을 더하다, 밋플

🙂 ‘밋플(Meetpl)’은 회의에서 겪는 불편함과 어려움을 발견하고, 팀 회의를 보다 효율적으로 개선할 수 있는 솔루션입니다.

👫Team. 미팅남녀

‘회의를 남다르게 하는 녀석들, 미팅남녀’ 팀 입니다.

보다 효율적인 회의를 하기 위한 솔루션을 개발하는 팀인만큼,

팀 내에서의 회의의 생산성을 향상시키기위해 꾸준히 노력하고 있습니다.

1️⃣ R&R

분야	이름	포지션
기획	신민선	📈 PM, 서비스 기획, 와이어프레임, 비즈니스 모델 설계
기획	박지호	📊 서비스 기획 리드, 세부기능기획, 비즈니스모델 설계
기획	정예진	📋서비스 기획, 플로우차트, 비즈니스모델설계
디자인	김다형	📢 디자인 시스템 구축, UI 디자인
개발	홍민서	🔦 Web 개발 리드
개발	김승훈	📱 Web 개발
개발	배현서	💻 Server 개발
개발	류관곤	🖥️ Server 개발

2️⃣ 팀문화

집요하게 몰입하는 사람들이 모여 남다른 프로덕트를 만듭니다.

📍실시간 업무 상황 공유

업무의 시작과 끝에 서로의 오늘 업무에 대해 브리핑하며 매일매일 어떤 업무를, 언제, 얼마나 했는지 공유합니다.

📍모두 다 함께

‘코어타임’을 통해, 모두가 함께 서비스와 팀에 대한 애정으로 프로덕트를 만들어내기위해 노력합니다.

📌서비스 개요

1) 문제정의

협업툴을 사용하며 회의를 자주 경험하는 팀에 속한 사람들이 회의에 불만을 가지거나, 비효율적인 회의를 개선하지 않는 문제

2) 해결방안

팀 회의 데이터를 제공하여, 회의의 생산성을 확인합니다.모

발견 및 정의하지 못했던 팀 회의의 문제를 알려줍니다.

해당 문제를 해결할 수 있는 솔루션을 제안합니다.

👫목적 및 필요성

1️⃣ 목적

우리 팀 회의의 개선점을 찾고 솔루션을 제공하는 서비스, ‘밋플’ 은 사용자에게 보다 나은, 효율적인 회의 경험을 제공하는 것을 목적으로 합니다. 서비스를 통해 회의 전반에서 겪는 어려움을 개선하고, 활발한 의견 공유를 도모하여 생산적인 회의 시간이 될 수 있도록 합니다.

❓ 효율적인 회의란?

  미팅남녀팀이 정의한 효율적 회의란, 논점에서 벗어나지 않고 모두가 활발히 의견을 공유하며 의사결정을 내리는 것으로, 미리 정해둔 시간안에 목표한 안건에 대한 결론을 도출하는 회의
  (ex. 사용자가 미리 정한 안건의 90%이상을, 목표 회의시간의 120%내로 회의를 종료하는 것)라고 할 수 있습니다.

2️⃣ 필요성

두 차례에 걸친 유저리서치(231013,15:41 기준 n=366)와 데스크리서치를 통해,

1) 현재 회의에 대한 각종 어려움을 겪고 있다
2) 회의의 어려움을 개선해야한다는 인지는 있지만, 실제로 행동으로 이어지지 않는다
3) 보다 효율적인 회의에 대한 니즈가 있다

위 3가지를 확인할 수 있었으며, 회의를 개선할 수 있는 행동 유도를 촉구하는 서비스의 필요성을 느꼈습니다.

리서치 자료 확인하기

[유저리서치를 통한 고객 니즈 파악]

회의 개선에 대한 니즈를 가지고 있는 사람 중 회의에 대한 어려움을 겪고 있는 사람은 76%에 달하며, 회의를 개선할 수 있는 솔루션을 제공하는 서비스가 필요하다고 느꼈습니다.
[데스크리서치를 통한 프로덕트의 필요성 파악]

데스크리서치로 팀의 높은 생산성과 업무 효율성을 위해서는 보다 효율적인 회의의 선행이 필수 조건이라는 점을 파악할 수 있었으며 다양한 회의 생산성을 높일 수 있는 방법들이 있지만, 회의에서의 특정 문제를 해결하기위한 방법을 제시하고 있는 프로덕트는 부재하다는 것을 파악하였습니다.

특히, 회의 관련 제언 연구에 따르면 회의는 팀의 의사결정과 업무환경 개선에 있어 중요한 요소이지만, 회의의 시간과 빈도가 증가할수록 개인은 참여를 꺼리는 부담감으로 작용하며 회의 부담의 지각은 정서적 측면, 효과성 측면에 모두 부정적 효과를 가져온다는 결과가 있었습니다. 이처럼 저희 팀은 회의가 팀 내에서 갖는 중요성은 크지만, 회의에서 겪는 문제 상황들이 명확히 존재하며 아직 해결되지 못했다는 점에 주목하여 회의를 개선할 수 있는 행동 유도를 촉구할 수 있는 프로덕트를 개발하고자 합니다.

[출처-국내 기업의 회의만족과 회의 효과성에 영향을 미치는 요인들에 관한 탐색적 연구]

📊리서치 및 시장조사

1️⃣ 리서치에 기반한 문제인식

문제인식 1. 국내 직장인 및 대학생은 비효율적 회의로 인한 업무 생산성 저하의 문제를 겪고 있습니다.

1) 회의의 목적성을 알지 못하고, 회의 자체에 대한 부정적인 인식을 갖고있는 직장인

잡플래닛의 설문조사 결과에 따르면, 회의의 목적성을 알지 못하고 있는 직장인이 총 40.5%를 차지하였으며, 회의시간에 대한 부정적인 의사 (회의가 비생산적이다)를 표명한 직장인은 70.3%으로 조사되었습니다. 이러한 상황 속에서 하루 평균 회의 횟수가 4회 이상인 직장인이 9.6%, 2-3회인 직장인은 27.7%로 대부분의 직장인은 회의를 경험하고 있습니다. (설문응답자 24,950명 대상)

2) 장시간 회의로 인한 업무 생산성 저하 및 수직적 회의방식의 문제

약 2000명의 직장인 중 67%는 긴 회의로 인해 업무 생산성에 부정적 영향을 받았으며 연속적인 회의가 이루어질 경우 중간 쉬는 시간이 필요하다는 것을 확인하였습니다.¹또한, 하버드비즈니스리뷰의 설문조사에 따르면 회의가 40% 감소했을 때, 생산성이 두 배 이상 증가하는 결과를 보였습니다. 특히, 상사가 주도하는 회의가 감소했을 때의 만족도가 52% 상승하며² 개인의 책임 권한에 대한 인식이 회의에서도 중요하다는 사실을 확인했습니다.

[출처1- 직컨설팅회사 콘페리에서 실시간 설문조사, 마이크로소프트 휴먼 팩터 랩의 뇌파실험]

[출처2-하버드비즈니스리뷰 설문조사 결과]

3) 회의에 대한(시간, 참여도, 빈도, 효율성 등) 커뮤니티의 부정적인 반응

직장인 및 대학생 유저가 많은 에브리타임, 링커리어, 블라인드에 ‘회의’ 라는 키워드로 검색하여 커뮤니티 반응을 확인했습니다.

분류	커뮤니티	반응
국내 대학생 커뮤니티	에브리타임	1. 팀플 회의 시간에 아무도 참여하지 않음 2. 회의록 작성방법을 모르겠고, 적극적으로 참여하지 않는 팀원에 불만을 느낌
	링커리어	1. 적극적으로 참여하고 싶지만, 끼어들 타이밍이 어렵고 눈치 보임 2. 회의록 작성방법을 모르겠음
직장인 커뮤니티	블라인드	1. 비효율적 회의에 불만임 2. 결론이 없는 회의에 회의감을 느낌 3. 회의 중 필요없는 TMI로 지침 4. 회의 안건을 미리 공유하여 회의시간을 줄이고 싶음 5. 집단적 독백과 중구난방 회의로 지침

4) 회의와 관련된 물품 및 서비스에 대한 온라인 시장 반응

회의와 관련된 물품과 서비스의 검색량은, 보다 나은 회의를 추구하는 잠재고객의 규모를 반증하는 지표라고 판단하였습니다. 회의에 대한 사람들의 관심 수준을 파악하고, 넓은 표본 집단을 대상으로 객관적인 수치 자료를 얻기 위해 데이터 분석 사이트(네이버 데이터랩, 썸트렌드, 구글애널리틱스 등)를 활용하여 리서치를 진행하였습니다.

수치로 보여지는 검색량 추이를 확인하기 위해 회의 관련 단어의 검색량을 비교해보았고, 회의 연관 검색어를 파악하여 회의에 대한 전반적인 인식을 파악하고자 하였습니다.

리서치 결과 ‘회의’와 관련된 단어를 검색하는 사용자는 20대부터 60대 중 특히 40~50대에서 총 67%의 비율을 차지하였습니다. 그리고 관련 연관 검색어로 ‘적극적’, ‘효율적’, ‘성공적’, ‘구글 타이머’, ‘회의 관련 협업 툴’이 많이 검색된 것을 통해 효율적인 회의를 향한 사용자들의 니즈가 있음을 파악할 수 있었습니다. 이와 같은 데이터 인사이트를 바탕으로 온라인 시장은 효율적인 회의를 하고 싶다는 니즈를 가지고 **[회의를 개선하고자 하며, 회의 관련 툴을 탐색하고 있다]**는 것을 알 수 있었습니다.

문제인식 2. 회의에서 겪는 문제를 해결하고자 하는 니즈를 발견하였지만, 이를 해결 할 회의 관련 서비스가 부재함을 알 수 있었습니다.

회의에서 겪는 문제를 해결하고자 하는 니즈

응답자 중 78%는 효율적 회의를 경험하기 위해 개선의 의지를 갖고 있다고 응답했습니다.

해당 문제를 해결할 회의 관련 서비스의 부재

불만족스러운 회의를 개선하고자 팀 내 소통을 시도하지 않은 응답자 비율은 47.4%
회의를 개선하고자 팀 내 소통을 시도한 응답자 비율은 52.6%였지만 그에 대한 솔루션 및 개선 효과는 경험하지 못했음을 확인할 수 있었습니다.

효율적 회의를 경험하고 싶은 사람의 비율	78%
만족스럽지 못한 회의	회의의 논점을 벗어난 회의
	회의 시간이 너무 길어진 회의
	회의가 끝나도 결론이 나지 않는 회의
불만족스러운 회의를 개선하고자 한 본인의 노력	없다(모르겠다)
	회의와 무관한 언행을 하지 않게 한다
	주제를 벗어나는 이야기를 한 경우 주의를 준다

2️⃣ 리서치를 통한 문제정의 및 방향성 확정

2차 리서치를 통해 3가지 정성적 가설을 검증함으로써, 회의의 문제를 정의하고 솔루션을 제시해 ‘보다 효율적인 회의’를 경험할 수 있는 서비스가 필요하다는 결론을 도출했습니다.

유저리서치(n=366) 및 FGI(n=14)를 통해

회의에서 문제를 겪은 경험이 있다
회의에서 겪은 문제를 해결하고 싶다
보다 좋은, 효율적인 회의를 경험하고 싶다.

라는 정성적 가설을 검증하였습니다. 회의에 참여하는 수많은 나이 대(1952-2004년생)의 다양한 직업(학생, 직장인 등을 포함한 11개 직군)을 가진 사람들 모두 공통적으로 회의에 겪는 어려움을 해결하고 싶지만, 이를 해결할 수 있는 회의 관련 서비스의 부재로 불편함을 겪고 있었습니다.

3️⃣ 리서치를 통한 인사이트 및 방향성 정의

데스크리서치를 통해 시장성과 서비스의 방향성을 구체화하였으며

1차 리서치를 통해, 타겟군을 ‘다수의 회의를 경험하거나 회의 툴을 사용하는 유저‘로 설정,

2차 리서치를 통해, 타겟군이 서비스를 통해 보다 효율적인 회의를 경험할 수 있도록 페인포인트와 니즈를 기반으로 세부기능을 설계하였습니다.

따라서 ‘밋플’은 회의의 불편한 점을 개선하여 효율적인 회의로 발전할 수 있도록 그들에게 솔루션을 제시해보고자 합니다.

PROBLEM	SOLUTION	EXPECT
회의에서 잘못된 부분이 있어도 이를 알려줄 수 있는 사람이나 객관적인 가이드라인이 없음	팀 회의 데이터와 회의 목표를 비교 분석하여 문제 요약 기능 제공	회의의 문제점을 파악하고 솔루션을 통해 개선해나가는 과정을 통해 효율적인 회의를 경험할 수 있음
효과적으로 회의를 진행하고자 하지만 방법을 모르겠음	솔루션 제안 기능 제공	회의를 실시간으로 원활하게 진행할 수 있고 회의에 대한 분석으로 더 나은 회의를 이끌어나갈 수 있음
결론이 정해지지 못한 채로 회의가 늘어지거나 결정된 바가 없이 끝나버림	안건 별 next step 설정 기능 제공	1. 정해진 시간 안에 회의의 안건에 대한 결론을 도출함으로써 효율적인 회의를 경험할 수 있음 2. 놓치는 안건 없이 회의의 목적을 달성할 수 있음
회의가 언제 끝날지 모르는 상태에서 늘어지는 회의에 집중력이 떨어짐	회의 목표 소요시간 사전 공유 기능 제공	회의 예상 시간을 파악하여 늘어지는 것 없이 회의에 집중할 수 있음
하고 싶은 말이 있어도 말을 하지 못한 채로, 회의에 적극적으로 참여하기가 어려움	말풍선 보내기 기능 제공	적극적으로 회의에 대한 의견을 말하며 회의에 대한 만족도와 회의의 질이 높아짐
내가 속한 팀이 잘 하고 있는 건지 모르는 상태로 팀에 대한 소속감이 떨어짐	회의 현황 대시보드 기능 제공	우리 팀의 회의에 대해 파악, 분석하는 과정을 통해 팀에 대한 소속감이 높아짐

4️⃣ TAM-SAM-SOM

5️⃣ 유사서비스 조사

기존에 프로젝트를 관리할 수 있는 협업툴은 다양합니다. 하지만 ‘회의’만을 집중적으로 관리하고, 회의의 문제와 솔루션을 제시하고 있는 플랫폼은 부재합니다. 따라서 해당 내용을 밋플의 차별성으로 하며, 협업툴 사용자들이 경쟁 서비스와 함께 사용하여 보다 효율적인 회의를 경험하는 것을 목적으로 합니다.

또한 밋플 서비스 내에서도 팀 스페이스를 생성하며, 팀 내 현황을 관리&확인을 통한 효율 향상에 중점을 둔다는 점이 협업툴과 유사하여 유사 서비스로 선정하였습니다.

	밋플	노션	지라	네이버 웍스
서비스 소개	효율적인 회의를 위해 문제점을 개선하고 솔루션을 도출하는 서비스	회의에서의 효율적인 협업을 위한 서비스	팀 내 문제를 발견하는 프로젝트 관리서비스	업무용 협업 도구로 솔루션 연계를 통한 커스터마이징을 지원하는 서비스
제공 기능	1) 대시보드, 2) 문제점과 해결책 도출, 3) 실시간 회의록	1) 공동 작업 및 협업, 2) 템플릿 생성, 2)문서 작성	1) 이슈 추적, 2) 칸반 보드, 2) 프로젝트 생성	1) 솔루션 연계, 2) 팀 내 소통, 3) 업무 관리
장점	-직관적이고 보기 쉬운 UX/UI -팀 회의 대시보드를 바탕으로 맞춤형 문제점과 솔루션 제공 -실시간 회의 가이드라인	팀 협력을 위한 워크스페이스 생성이 용이	다양한 팀 프로젝트 관리 용이	다양한 협업체와의 연계로 도움 얻을 수 있음
단점	-다른 회의 협업 툴과의 실시간 연동 어려움 -회의 보조 툴로 우리 서비스 내에서 회의 전반의 과정을 관리하기 어려움	협업 도구에서 나아가 프로젝트 관리를 하기는 어려움, 팀마다 다른 노션 스페이스로 사용자 경험의 일관성 부족	초기 사용자가 사용하기에 복잡함, 문서를 공유하고 협업하는 과정이 어려움	외부서비스와 연계 필요 유료 서비스, 다른 도구와 함께 사용할 때 연동 어려움

🔥서비스 확장 계획

🎯서비스 타겟층

서비스 타겟층은 회의에서 어려움을 경험한 사람 중,

1) 회의 진행 시 문제를 개선하고 싶지만, 문제점을 정의내리기 어려운 사람

2) 회의 진행 시 문제 원인을 파악 하였지만, 솔루션을 찾지 못한 사람입니다.

회의에서 어려움을 경험한 후, 문제점 개선의 필요성을 느낀 사람을 1차 타겟 고객으로 설정하며, 아래와 같이 점차 확장할 계획입니다.

분류	1차 타겟 유저	2차 타겟 유저
타겟설명	1. 팀 회의의 문제를 개선하고 싶지만, 문제점을 정의내리기 어려운 회의 경험자 2. 팀 회의의 문제 원인을 파악 하였지만, 솔루션을 찾지 못한 회의 경험자	회의 툴 사용 경험이 없으며, 효율적 회의에 대한 가이드라인이 필요한 회의 입문자
관련기능	‘실시간 회의툴을 통한 회의 데이터 저장’, ‘대시보드를 통한 현황 분석’, ‘문제 정의&솔루션 제시’ 기능을 통해 보다 효율적 회의로 개선될 수 있도록 사용자 경험을 제공	회의 툴 사용 경험이 없는 회의 입문자에게도 밋플 서비스를 통해 효율적인 회의의 기준선을 잡아갈 수 있도록 돕는 기능 제공

🎯핵심 기능

기능	설명	기획의도
실시간 회의록	회의에서 겪는 어려움 해소를 도우며 효율성을 증진시킬 수 있는 기능 제공 - 회의 목표 리마인드, 타이머, 아이스브레이킹 주제 추천, 안건 작성, 말풍선을 활용한 의견 표현, 안건별 next step 작성 및 요약	각 팀에서 사용하는 협업툴과 함께 띄워서 사용하며, 해당 기능으로는 회의 중 필요한 도구(타이머, 주제 추천, 의견 제시 등)를 제공하는, 보다 효율적인 회의를 위한 'tool'로써 사용되고자 함.
대시보드	아래 항목을 그래프로 표현하여 회의 현황을 분석하는 기능 제공 - 날짜별 회의 진행 시간과 회의에 소요된 시간, 회의 문제 태그 모음, 작성한 안건 대비 해결되지 못한 안건 수, 회의 종류별 비율, 날짜별 우리팀 회의 점수, 회의에서 의견이 활발히 공유된 정도	실시간 회의록의 데이터와, 회의 직후 받은 데이터를 기반으로 '대시보드'를 제공함으로써 우리팀 회의의 생산성을 확인하고, 개선 현황을 파악할 수 있도록 함.
문제 발견하기	우리팀 회의 목표 기준에서 벗어난 회의 데이터 값을 찾아 문제를 정의하는 기능 제공	회의의 문제를 정의하기 어려워하거나, 우리팀 회의의 문제를 인지하지 못하고 있는 사용자에게 개선해야할 문제를 알리기 위함.
솔루션 제안하기	우리팀 회의에서 발견된 문제에 따른 솔루션을 제안하여, 보다 편리하게 개선할 수 있도록 돕는 기능 제공	서비스를 통해 발견한 문제를 해결하기 위한 솔루션을 제시하고, 해당 기능을 통해 사용자가 '보다 효율적인 회의'를 경험할 수 있음.

🎯기능 확장 계획

기능	설명	목적
회의 자체 관리 기능	제시받은 솔루션을 서비스 내에서 시도하는 것을 데이터로 받고, 개선하는 것에 대한 피드백을 지속적으로 제공하는 기능	효율적인 회의를 위한 궁극적인 사용자의 행동 목표는 솔루션을 받고 회의를 개선하는 것이기 때문에, 해당 기능을 추가함으로써 유저 리텐션을 유지하고 회의의 개선점을 계속 발견할 수 있도록 함
실시간 회의록 커스터마이징	현재 실시간 회의록에서 사용할 수 있는 도구는 [회의 목표 리마인드, 타이머, 아이스브레이킹 주제 추천, 안건 작성, 말풍선을 활용한 의견 표현 , 안건별 next step 작성 및 요약]으로 정해져있는데, 팀의 필요에 따라 사용할 기능들을 추가하거나 삭제할 수 있도록 하여 우리팀 회의의 ‘tool’의 역할을 다할 수 있도록 하는 기능	팀 회의에 맞게 필요한 기능을 사용할 수 있도록 하여 해당 회의에만 집중해서 서비스를 이용할 수 있도록 함
다른 팀 회의 솔루션 및 개선 현황 열람 기능, 회의록 템플릿 공유	- 다른 팀들이 회의를 어떻게 하고 있는지 참고하여 더 나은 회의로 나아갈 수 있게 회의록 템플릿과 팀 문화를 공유하는 기능 - 다른 팀의 회의 솔루션과 개선 현황을 열람할 수 있도록 하여 서비스의 모든 사용자가 ‘보다 효율적인 회의’를 경험할 수 있도록 하는 기능	궁극적으로는 회의 솔루션에서 나아가 회의 전반을 관리할 수 있는 ‘All in one’ 서비스로 성장할 수 있도록 함

📋메뉴구조도

💵비즈니스 모델 설계

관련파트너 1	관련파트너 2	내용
밋플	유저	[기능 추가에 따른 요금제 확장] 1. 솔루션 미리보기 → 솔루션 제공 → 실시간 솔루션 제공 2. 팀당 인원수 제한 → 무제한 3. 저장기한 제한 → 무제한 4. 대시보드 기본 제공 → 커스터마이징 기능 제공
밋플	팀	[건수에 따른 요금 지불] 1. 다른 팀 대시보드 열람 2. 1:1 전담 컨설팅 3. 외부툴 연동
밋플	기업	1. 페이지 내 광고 배너 2. 기업 회의 프로세스 공유 및 열람

👀디자인

🎨디자인 무드보드/시스템

📃UX라이팅 원칙

UX 라이팅 원칙 추가 설명

명확하고 간결하게 표현
- clear 명확한: 정확하고 명확하게 정보 전달, 명사형으로
- concise 간결한: 꼭 필요한 내용만 간결하게
- 쿠션어X, 다크 패턴 채택X
- 문제점과 솔루션의 워딩을 명확하게
- 숫자 표현 지향, 추상적 표현 지양
- 동사화하기-타이틀, 단일텍스트 ex. 밋플하다
일반 표현의 사용
- casual 친근한: 딱딱한 회의에서 어려운 표현보다는 친근한 표현 사용
- easy to speak: 별도의 학습 없이 이해할 수 있게 직관적으로
- universal words: 모두가 이해할 수 있게
응원하는, 따뜻한, 즐거운 표현의 사용
- ~해요체(괜찮아요, ~해보세요)
- respect 존중하는: 문제점, 솔루션에서 특히 주의하여 존중하는 표현 사용
- emotional 공감하는: 솔루션, 실시간 회의록에서 주의하여 사용
- 미래시제, 미래지향적 설명
- 숫자 표현 지양, 문장보호 사용X
- 아이콘과 함께 한눈에 들어오기: 아이콘과 텍스트의 조화

🔖서비스 BI

🧑🏻‍💻개발

🔍 System Architecture

👦🏻 프론트엔드

개발 패턴

Presentational and Container Components

스타일링과 같은 UI적 요소들은 Presentational Component로, 기능 및 로직과 관련된 요소들은 Container Component로 분리하여 전체 코드의 UI와 로직 파트를 컴포넌트 상에서 나누어 관리하는 패턴이다.

Container Component

오직 기능 구현을 위한 로직만이 들어가는 컴포넌트로, hooks나 api 통신과 같은 코드들이 들어간다. 로직을 통해 만들어진 데이터들을 props 등을 통해 Presentational Component로 보내진다.

Presentational Component

오직 화면을 보여주기만 하는 기능을 하는 컴포넌트로, Container Component에서 보내준 데이터들을 props의 형태로 가져와서 여러 요소들 및 스타일링과 함께 화면에 보여준다.

폴더구조

public
- images: 화면에 사용되는 다양한 이미지들을 저장하는 폴더
- icons: 아이콘 및 로고들을 저장하는 폴더
src
- pages: 화면에 보여지는 페이지들을 작성하는 폴더
- containers: container 컴포넌트를 관리하는 폴더
- components: 공통된 요소들을 컴포넌트 단위로 관리하는 폴더
- interfaces: 타입들을 관리하는 폴더
- states: 전역변수 관리 폴더
- lib
  - api: api 통신 관리 폴더
  - constants: 상수 관리 폴더
  - data: 서비스에 사용되는 데이터들을 관리하는 폴더
  - hooks: hook 함수들을 관리하는 폴더
  - styles: Global Style 및 여러 스타일 관련 파일들을 관리하는 폴더

👦🏻 백엔드

[ Blue/Green 아키텍처]

소프트웨어 배포와 인프라 관리를 개선하고 운영 중인 시스템의 가용성과 안정성을 향상시키기 위한 전략으로 사용
서비스 운영적인 관점에서 사용자에게 서비스의 중단 없이 새로운 기능 및 업데이트를 제공.

[Service 분리]

HTTP 요청을 처리하는 서버와 실시간 통신을 처리하는 WebSocket 서버를 분리하여 작업을 수행하므로 성능을 최적화할 수 있다.
Main 서버와 WebSocket 서버 간의 오류가 서로 영향을 미치지 않도록 분리함으로써 시스템 전체의 안정성을 높일 수 있다.
Main 서버와 WebSocket 서버 각각 필요에 따라 기능을 확장할 수 있으므로 애플리케이션을 더 쉽게 확장할 수 있다.

[ CI/CD]

Develop Branch Push
Commit message로 Update service 확인 [Main, Socket, Global]
docker build 후 deploy.sh을 해당 EC2에 전달
deploy.sh을 이용해 Update된 docker container 실행
nginx proxy로 blue/green 서버 교체

💻 Technology

👦🏻 프론트엔드
- 언어:
- 프레임워크:
- 라이브러리: , , , ,
👦🏻 백엔드
- 언어:
- 프레임워크:
- 라이브러리: , , , ,
데이터베이스: , ,
인프라: , , , , ,

🐾 기술 스택 선정 이유

👦🏻 프론트엔드

- 가상 DOM (Virtual DOM): React는 가상 DOM을 사용하여 실제 DOM 조작을 최소화하여 웹 애플리케이션의 성능을 향상시킬 수 있고, 빠른 렌더링을 지원할 수 있습니다.
- 컴포넌트 기반: React의 컴포넌트 기반 아키텍처는 코드 재사용을 용이하게 하며, 복잡한 UI를 작은 부분으로 나눠 코드 수정 및 유지보수에 효율적입니다.
- 단방향 데이터 흐름: React는 단방향 데이터 흐름을 따릅니다. 데이터가 한 방향으로만 흐르는 특징 때문에 애플리케이션의 상태 관리와 디버깅이 더 간단해집니다.
- 대중성: React는 많은 개발자와 커뮤니티에서 활발하게 사용되며, 수많은 라이브러리, 도구, 컴포넌트 등이 개발되어 있어 생산성을 향상시킵니다. 서비스 특성상 그래프나 실시간 통신과 같은 기술에서 다양한 라이브러리들을 손쉽게 사용할 수 있습니다.
- JSX (JavaScript XML): JSX를 사용하면 JavaScript 코드 안에서 UI를 선언하는 것이 가능하며, 컴포넌트 코드를 더 직관적으로 작성할 수 있습니다.
- 정적 타입 검사: 타입스크립트는 정적 타입 어노테이션을 제공하므로 코드 작성 중에 많은 오류를 미연에 방지할 수 있어서 런타임 오류를 줄이고 코드 안정성을 높일 수 있기 때문에 채택
- 가독성 및 문서화: 타입 어노테이션을 통해 코드가 더 읽기 쉽고 문서화되어, 협업이 더 원활해지며 코드의 의도를 명확하게 표현할 수 있습니다.
- 인라인 클래스 스타일로 간단하게 스타일링하고 기본값 설정을 통해 통일된 UI를 제작할 수 있음
- Styled-Components 와 달리 태그명을 고민하는 불편함을 최소화 할 수 있음
- 공식 문서가 매우 잘 정리되어있어서 모르는 태그에 대한 검색이 훨씬 수월함
- Rest-api 를 사용할 수 있게 해주는 가장 대중적인 통신 라이브러리로 api 통신방법이 상대적으로 간편함
- 인스턴스 생성을 통해 API 호출을 할때 공통적으로 들어가는 BASEURL 이나 Credential 부분의 코드를 간소화 할 수 있음
- React와 매우 뛰어나게 통합되어 있어서 React를 사용하며 Recoil을 사용하는 것이 상대적으로 매우 간편함
- 전역변수를 관리하는 방법이 수월하며 useState와 비슷한 원리로 전역변수를 관리할 수 있어서 작업하기에 매우 용이
- Recoil은 선언적인 방식으로 상태를 관리하므로 React 컴포넌트가 불필요하게 리랜더링되는 것을 방지할 수 있으며 성능 최적화에도 많은 도움이 됨
- 코드베이스를 GitHub 또는 GitLab과 연동하면 변경사항이 자동으로 감지되어 배포되며, CI/CD 파이프라인을 따로 설정할 필요가 없기 때문에 상대적으로 매우 간편하게 배포가 가능
- 배포 설정까지의 과정이 매우 간편하며 비용이 무료임
- js 관련 패키지 관리 도구로 이를 이용해 라이브러리를 설치 및 빌드

👦🏻 백엔드

- 다양한 모듈을 제공하며, 데이터 액세스, 보안, 통합, 마이크로서비스 아키텍처까지 다양한 분야에서 사용할 수 있다.
- 복잡한 설정 작업을 줄이고, 개발자가 핵심 비즈니스 로직을 구현하는데 집중할 수 있다.
- 데이터베이스 액세스를 단순화하고, 단순 작업의 SQL 쿼리 작성을 줄여 준다.
- 데이터베이스와의 상호작용을 객체 지향적으로 다룰 수 있다.
- JWT는 사용자 인증과 권한 부여를 효과적으로 처리하는 간편한 방법을 제공한다.
- 서비스별로 분리된 분산 환경에서 인가, 인증을 간소화할 수 있다.
- 클라이언트 측에 토큰을 저장할 수 있으므로, 서버 측에서 세션을 관리하는 것보다 더 가볍고 확장 가능한 방식으로 사용자 신원을 관리할 수있다.
- URL 및 메서드 수준에서 액세스 제어 규칙을 정의할 수 있으며, 특정 리소스에 대한 접근을 제어할 수 있다.
- CSRF(Cross-Site Request Forgery) 공격을 방어하기 위한 기능을 제공하며, 웹 서비스와의 AJAX 요청에서 보안 토큰을 자동으로 처리한다.
  - CSRF 공격 - 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격을 말한다.
- 웹 소켓(WebSocket)을 기반으로 하며, 실시간 통신을 지원하는 프로토콜이다.
- 이벤트 기반 아키텍처를 쉽게 구현할 수 있으며, 비동기식 이벤트 처리가 가능하다.
- 메시징 프로토콜과 메시징 형식을 개발할 필요가 없다 & • 연결 주소마다 새로운 핸들러를 구현하고 설정해줄 필요가 없다.
  
  → 형식을 고민하고, 파싱하는 코드를 구현할 필요가 없어져 기능 개발에 좀 더 힘을 쓸 수 있다.
- 관계형 데이터베이스 모델로 스키마 설정을 통해 회의 통계에 대한 효율적인 데이터 관리를 할 수 있다.
- 빠른 읽기 및 쓰기 성능을 제공하며, 대용량 데이터베이스와 트랜잭션 처리에 효율적이다.
- 다양한 운영 체제에서 동작하며, Windows, Linux, macOS 등 다양한 플랫폼에서 사용할 수 있다.
  
  → 로컬환경과 배포환경이 달라도 지장이 없다.
- 스키마가 없는 NoSQL 데이터베이스로, 데이터 모델을 자유롭게 정의할 수 있다.
- 애플리케이션이 필요로 하는 형식으로 데이터가 저장되기 때문에 실시간 통신에서 조회에 대한 이점이 있다.
- 실시간 서비스는 많은 트래픽이 발생하는 서비스이기 때문에 별도의 데이터베이스가 필요하다고 판단.

📗 infra

- Github로 코드 통합 관리를 진행할 경우 연장선으로 쉽게 자동배포까지 사용이 가능하다.
- 다양한 이벤트(예: 푸시, 풀, PR, 이슈 업데이트)를 트리거로 사용할 수 있으므로, 특정 이벤트가 발생했을 때 작업을 실행할 수 있다.
  
  → Commit message check로 분산된 서버에 자동으로 배포가 가능하다.
- 리눅스, 맥, 윈도우, ARM 및 컨테이너를 쉽게 빌드, 테스트가 가능하다.
- 거의 무제한의 데이터 저장 공간을 제공한다.
- 클라우드 환경에서 사진 및 파일 데이터를 관리하기 용의하다.
- Blue/Green 무중단 아키텍처를 구성하기 위한 Proxy 역할을 합니다.
- 프로그램을 실행하는 환경을 캡슐화하여, 개발, 테스트 및 배포 과정을 일관되고 이식성 있는 방식으로 관리할 수 있다.
- 각각의 독립적인 image를 이용해 여러 서비스가 존재할 경우 관리 및 배포가 쉽다.
- MySQL 데이터베이스의 관리와 운영 부담을 줄이고, 안정성, 가용성 및 보안을 향상시킬 수 있다.
- 서로 분산된 서비스들 간의 동기화 데이터를 관리한다.
- 서비스 교체로 인해 휘발 될 수 있는 데이터를 저장하는데 용의합니다.
- Cache의 용도로 데이터베이스 액세스를 줄이고 애플리케이션 성능을 향상 시킬 수 있다.
- 서비스 교체로 인해 휘발 될 수 있는 데이터를 caching하는데 용의합니다.
- Publish/Subscribe 메커니즘을 제공하여 실시간 이벤트 처리 및 메시징 용도로 사용이 가능하다.

🔖 Naming Rules

👦🏻 프론트엔드

네이밍 종류
- camelCase : 소문자로 시작하고 대문자로 시작하는 모든 후속 단어
- PascalCase : 모든 단어는 대문자로 시작
- snake_case : 밑줄로 구분된 단어
- UPPER_SNAKE_CASE : 밑줄로 구분된 단어로 모든 단어가 대문자
- kebab-case : 하이픈으로 구분된 단어
네이밍 규칙
- 폴더명 : kebab-case
- 컴포넌트명 : PascalCase
- 이미지파일명 : kebab-case
- 변수명 : camelCase
- 함수명 : camelCase
- 상수명 : UPPER_SNAKE_CASE

👦🏻 백엔드

Class: Upper Camel Case
Method: Lower Camel Case
Variable Lower Camel Case 단, Constant 변수는 제외합니다.
데이터베이스: Lower Snake Case

모든 Class는 해당하는 domain의 이름을 접미사에 사용합니다.

  controller: UserController
  service: UserService
  repository: UserRepository
  dto/request: User_____RequestDto
  dto/response: User_____ResponseDto
  entity: User
  config: WebConfig
  error code: USER_Not_Found

Method의 이름을 선언할 경우 Method가 지닌 역할 및 기능을 생각하고 그것을 의미할 수 있는 이름을 사용해야합니다.

예를 들어 ParticipationId를 이용해 데이터베이스에서 데이터를 가져올 경우 Get이라는 메서드의 행위을 나타내는 동사와 메서드의 목적을 나타내는 Participation과 ParticipationId를 사용하겠다는 의미인 With 전치사를 함께 사용하여 Method를 만듭니다.
```
  🍀 Participation participation = getParticipationWithParticipationId()   
```

🗂️Commit Convention 및 Git Flow

👦🏻 프론트엔드

🐬 깃플로우

브랜치 정리

브랜치 명	특징
main	- 실제 배포되는 브랜치 - develop에서 배포될 코드를 머지
develop	- feature branch의 내용들을 머지하는 브랜치 - 개발자용 브랜치
feature	- 작성법: feature/기능 - 기능 구현 단위로 사용 - 기능 구현 완료 시 develop에 병합
release	- 작성법: release - [번호] - develop branch에서 생성 - 배포 전 test 및 버그 검사
hotfix	- 작성법: hotfix - [번호] - 배포이후 문제발생 시 생성

깃헙 사용 과정
1. 이슈에 본인이 작업할 내용들을 작성
2. 커밋컨벤션에 따른 태그와 태그번호를 사용한 새로운 브랜치를 만들어 코드 작성
3. 코드 작성 후 푸쉬
4. 작성된 이슈를 태그하여 PR날리며 작업한 화면 캡쳐해서 깃에 업로드
5. 상대방 개발자가 PR 내용 확인 후 최종 머지

📌커밋 컨벤션

태그	제목
feat	새로운 기능 추가
fix	버그 수정
docs	문서 수정
style	코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
refactor	코드 리펙토링
test	테스트(테스트 코드 추가, 수정, 삭제, 비즈니스 로직에 변경이 없는 경우)
chore	위에 걸리지 않는 기타 변경사항 (빌드 스크립트 수정, assets image 등)
design	CSS 등 사용자 UI 디자인 변경
comment	필요한 주석 추가 및 변경
init	프로젝트 초기 생성
rename	파일 혹은 폴더명 수정하거나 옮기는 경우
remove	파일을 삭제하는 작업만 수행하는 경우

👦🏻 백엔드

🐬 깃플로우

작업 시작 시 선행되어야 할 작업

issue를 생성합니다.
feature branch를 생성합니다.
add → commit → push → pull request 를 진행합니다.
pull request를 develop branch로 merge 합니다.
이전에 merge된 작업이 있을 경우 다른 branch에서 진행하던 작업에 merge된 작업을 pull 받아옵니다.
종료된 issue와 pull request의 label을 관리합니다.

Etc

준수해야 할 규칙
- develop branch에서의 작업은 원칙적으로 금지합니다. 단, README 작성은 develop branch에서 수행합니다.
- commit, push, merge, pull request 등 모든 작업은 오류 없이 정상적으로 실행되는 지 확인 후 수행합니다.

📌 커밋 컨벤션

[<Prefix>]:<Module_Name> #<Issue_Number> <Description>의 양식을 준수.

Prefix

태그	제목
feat	새로운 기능 구현 ex. [feat]:Main #11 구글 로그인 API 기능 구현
fix	코드 오류 수정 ex. [fix]:Main #10 회원가입 비즈니스 로직 오류 수정
del	쓸모없는 코드 삭제 ex. [del]:Main #12 불필요한 import 제거
docs	README나 wiki 등의 문서 개정 ex. [docs]:global #14 리드미 수정
refactor	내부 로직은 변경 하지 않고 기존의 코드를 개선하는 리팩토링 ex. [refactor]:Global #15 코드 로직 개선
chore	의존성 추가, yml 추가와 수정, 패키지 구조 변경, 파일 이동 ex. [chore]:Socket #21 yml 수정
test	테스트 코드 작성, 수정 ex. [test]:Global #20 로그인 API 테스트 코드 작성

Module_Name

<Module_Name>은 Github Action과 연동되어 특정한 클라우드 환경에 CI/CD가 되도록 설계되었기 때문에 반드시 준수해야합니다.

태그	제목
Main	MainService module에서 작업을 할 경우 사용합니다.
Socket	Websocket module에서 작업을 할 경우 사용합니다.
Global	모든 module에 코드를 수정할 경우 사용합니다.

⚠️ Issue

Issue Naming Rule
- Issue Naming 규칙은 Commit convention과 동일한 Prefix와 Module_Name을 사용합니다.
  - [<Prefix>]:<Module_Name> description

🍀 [feat]:Main kaka OAuth service 구현

💭 Branch

Branch Naming Rule
- branch를 생성하기 전 issue를 먼저 작성합니다.
- issue 작성 후 생성되는 번호와 domain 명을 조합하여 branch의 이름을 결정합니다.
- <Prefix>/<Issue_Number>-<Domain> 의 양식을 준수합니다.
Prefix

태그	제목
main	개발이 완료된 산출물이 저장될 공간입니다.
feature	기능을 개발하는 branch 입니다. 이슈 별 & 작업 별로 branch를 생성 후 기능을 개발하며 naming은 소문자를 사용합니다.

Domain 예시

user
home
error
config
…

Ex

feature/7-user
feature/5-config

💯 Pull Request

develop & main branch로 merge할 때에는 pull request가 필요합니다. pull request의 내용에는 변경된 사항에 대한 설명을 명시합니다.

Pull Request Naming Rule
- PR Naming은 해당 번호에 맞은 Issue와 같게 합니다.
Ex

[feat]:Main 약속 잡기 API 구현

[chore]:global spring data JPA 의존성 추가

🔗기능명세서

구분	Depth1	Depth2	기능설명	우선순위
온보딩A	온보딩 팝업		서비스 소개 페이지,창닫기	MID
소셜로그인	소셜로그인 페이지			HIGH
		구글로 밋플하기		HIGH
		Kakao로 밋플하기		HIGH
온보딩B	기본정보 입력 팝업		1. 닉네임 2. 팀 생성 / 참여 여부 3. 팀 생성 or 참여 팝업 4. 밋플과 함께하세요 (환영 팝업)	HIGH
대시보드	팀 회의 현황 요약 그래프			HIGH
		날짜별 회의 진행 시간과 회의에 소요된 시간	1.X축 회의 날짜 &Y축 회의 진행 시간 및 소요시간 2.문제 발견 시 아이콘	HIGH
		회의 문제 태그 모음	문제 발견 시 아이콘	HIGH
		목표한 안건 대비 해결되지 못한 안건 수	1. X축 날짜 & Y축 안건 대비 미해결 수 2. 문제 발견 시 아이콘	HIGH
		날짜별 우리팀 회의 스코어	1. X축 날짜& Y축 스코어 2. 문제 발견 시 아이콘	HIGH
		활발한 의견표출 정도	1. X축 날짜 &Y축 말풍선 클릭 빈도 2. 문제 발견 시 아이콘	HIGH
		회의 카테고리별 비율		HIGH
	팀 정보			LOW
		팀 회의 스타일	이번주 회의 소요 시간에 따라 스타일 변동	LOW
문제 & 솔루션	대시보드 그래프 요약			HIGH
	문제&솔루션 요약		대시보드 그래프와 문제를 함께 제시	HIGH
		자세히 보기		HIGH
실시간 회의록	메인페이지			MID
		캘린더		MID
		회의록 모음	날짜별 회의록	MID
	실시간 회의도구			HIGH
		회의목표 / 타이머 / 아이스브레이킹 / 안건요약/ 말풍선		HIGH
		완료	회의 한줄평 및 스코어 작성	HIGH
팀 설정				LOW
팀 개설 및 초대	팀 생성하기 페이지			MID
	팀 초대하기 페이지			MID

Name		Name	Last commit message	Last commit date
Latest commit History 6 Commits
profile		profile
README.md		README.md

Kusitms-28th-MeetUp-C/.github

Folders and files

Latest commit

History

Repository files navigation

회의에 솔루션을 더하다, 밋플

👫Team. 미팅남녀

1️⃣ R&R

2️⃣ 팀문화

📌서비스 개요

👫목적 및 필요성

1️⃣ 목적

2️⃣ 필요성

📊리서치 및 시장조사

1️⃣ 리서치에 기반한 문제인식

문제인식 1. 국내 직장인 및 대학생은 비효율적 회의로 인한 업무 생산성 저하의 문제를 겪고 있습니다.

문제인식 2. 회의에서 겪는 문제를 해결하고자 하는 니즈를 발견하였지만, 이를 해결 할 회의 관련 서비스가 부재함을 알 수 있었습니다.

2️⃣ 리서치를 통한 문제정의 및 방향성 확정

2차 리서치를 통해 3가지 정성적 가설을 검증함으로써, 회의의 문제를 정의하고 솔루션을 제시해 ‘보다 효율적인 회의’를 경험할 수 있는 서비스가 필요하다는 결론을 도출했습니다.

3️⃣ 리서치를 통한 인사이트 및 방향성 정의

4️⃣ TAM-SAM-SOM

5️⃣ 유사서비스 조사

🔥서비스 확장 계획

🎯서비스 타겟층

🎯핵심 기능

🎯기능 확장 계획

📋메뉴구조도

💵비즈니스 모델 설계

👀디자인

🎨디자인 무드보드/시스템

📃UX라이팅 원칙

🔖서비스 BI

🧑🏻‍💻개발

🔍 System Architecture

👦🏻 프론트엔드

개발 패턴

폴더구조

👦🏻 백엔드

[ Blue/Green 아키텍처]

[Service 분리]

[ CI/CD]

💻 Technology

🐾 기술 스택 선정 이유

👦🏻 프론트엔드

👦🏻 백엔드

📗 infra

🔖 Naming Rules

👦🏻 프론트엔드

👦🏻 백엔드

🗂️Commit Convention 및 Git Flow

👦🏻 프론트엔드

🐬 깃플로우

📌커밋 컨벤션

👦🏻 백엔드

🐬 깃플로우

Etc

📌 커밋 컨벤션

⚠️ Issue

Issue Naming Rule

💭 Branch

Branch Naming Rule

Prefix

Domain 예시

Ex

💯 Pull Request

Pull Request Naming Rule

Ex

🔗기능명세서

About

Resources

Stars

Watchers

Forks

Releases

Packages 0

Contributors 2

Packages