MeetUP C팀의 Demo 보러가기 ✔️

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

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

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

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

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

📍실시간 업무 상황 공유

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

📍모두 다 함께

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

1) 문제정의

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

2) 해결방안

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

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

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

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

❓ 효율적인 회의란?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 및 여러 스타일 관련 파일들을 관리하는 폴더

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

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

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

• 👦🏻 프론트엔드

  • 언어:
  • 프레임워크:
  • 라이브러리: , , , ,

• 👦🏻 백엔드

  • 언어:
  • 프레임워크:
  • 라이브러리: , , , ,

• 데이터베이스: , ,

• 인프라: , , , , ,

• 
  • 가상 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 데이터베이스로, 데이터 모델을 자유롭게 정의할 수 있다.
  • 애플리케이션이 필요로 하는 형식으로 데이터가 저장되기 때문에 실시간 통신에서 조회에 대한 이점이 있다.
  • 실시간 서비스는 많은 트래픽이 발생하는 서비스이기 때문에 별도의 데이터베이스가 필요하다고 판단.

• 

  • Github로 코드 통합 관리를 진행할 경우 연장선으로 쉽게 자동배포까지 사용이 가능하다.

  • 다양한 이벤트(예: 푸시, 풀, PR, 이슈 업데이트)를 트리거로 사용할 수 있으므로, 특정 이벤트가 발생했을 때 작업을 실행할 수 있다.

    → Commit message check로 분산된 서버에 자동으로 배포가 가능하다.

  • 리눅스, 맥, 윈도우, ARM 및 컨테이너를 쉽게 빌드, 테스트가 가능하다.

• 
  • 거의 무제한의 데이터 저장 공간을 제공한다.
  • 클라우드 환경에서 사진 및 파일 데이터를 관리하기 용의하다.
• 
  • Blue/Green 무중단 아키텍처를 구성하기 위한 Proxy 역할을 합니다.
• 
  • 프로그램을 실행하는 환경을 캡슐화하여, 개발, 테스트 및 배포 과정을 일관되고 이식성 있는 방식으로 관리할 수 있다.
  • 각각의 독립적인 image를 이용해 여러 서비스가 존재할 경우 관리 및 배포가 쉽다.
• 
  • MySQL 데이터베이스의 관리와 운영 부담을 줄이고, 안정성, 가용성 및 보안을 향상시킬 수 있다.
• 
  • 서로 분산된 서비스들 간의 동기화 데이터를 관리한다.
  • 서비스 교체로 인해 휘발 될 수 있는 데이터를 저장하는데 용의합니다.
  • Cache의 용도로 데이터베이스 액세스를 줄이고 애플리케이션 성능을 향상 시킬 수 있다.
• 
  • 서비스 교체로 인해 휘발 될 수 있는 데이터를 caching하는데 용의합니다.
  • Publish/Subscribe 메커니즘을 제공하여 실시간 이벤트 처리 및 메시징 용도로 사용이 가능하다.

• 네이밍 종류

  • 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()   

• 브랜치 정리

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

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

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

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

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

• Prefix

• Module_Name

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

• Issue Naming Rule

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

🍀 [feat]:Main kaka OAuth service 구현

• Branch Naming Rule

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

• Prefix

• Domain 예시

user
home
error
config
…

• Ex

feature/7-user
feature/5-config

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

• Pull Request Naming Rule

  • PR Naming은 해당 번호에 맞은 Issue와 같게 합니다.

• Ex

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

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