팀, 친구, 연애 등 사람들은 평생 많은 사람들을 만나며 살아갑니다. 다만 자신의 기대와 다른 사람을 만나고 헤어지고를 반복하죠. 도도독동료는 그 굴레를 끊고자 합니다. 자신이 원하는, 자신과 맞는 사람들을 처음부터 만나갈 수 있다면, 많은 사람과 갈등을 겪는 과정을 줄여갈 수 있을까요? 원하는 동료를 한 번에 찾는 미래를, 도도독동료는 꿈꾸고 있습니다.

1. 문제 인식 및 내적 개발 동기

• ‘도도독동료’ 팀 구성 후, 학회/친목 활동 중 대화를 나누며 대부분의 팀원이 ‘팀 형성과 활동 과정에서 발생하는 문제’를 겪어본 경험이 있음을 공유함.
• 이와 같은 문제는 대부분의 대학생이 대학 생활 중 경험하는 강의 과제 조 모임, 소모임부터, 동아리/학회 등의 대규모 단체 활동, 공모전/대회, 사이드 프로젝트 등 크고작은 팀 활동에서 발생함을 인지함.
• 또한, 대부분의 대학생이 이러한 팀 활동을 수 차례 경험하게 되는 주요한 이유 및 목적은 대체로 ‘취업을 위한 스펙 쌓기’라는 점을 인지함.

2. FGI를 통한 문제 접근

• 이에 “취준을 위한 팀 형성 및 활동 과정에서 발생하는 문제”를 구체적으로 발굴하고자 자체 FGI를 진행함.

  (1) 타겟: 사이드 프로젝트, 창업, 공모전/대회, 강의 과제 조 모임 등 다양한 팀 활동을 경험해본 대학생/취준생 집단 20명
  
  (2) 질문: ‘팀 모집 및 활동 과정에서 겪었던 문제들은 무엇인가요?”
  
  (3) 결과

  • 1위. 기대했던 바와 실제 팀원의 역량이 다름 (55%)
  • 2위. 팀원들이 잘 구해지지 않음 (27%)
  • 공동 3위. 업무방식에 대한 정보 부족 (9%)
  • 공동 3위. 정보 탐색 비용 (9%)

  ⇒ 과반수 이상의 인터뷰이들이 가장 큰 고통을 경험한 문제: ‘힘들게 구한 팀원이 자신이 기대했던 것과 다른 역량/태도를 보이는 문제’ ex) “열심히 발품을 팔며 팀원을 구했지만, 알고 있던 자기소개와 전혀 다른 역량을 보여주는 팀원을 만났다”, “자기소개와 달리 태만한 태도를 보이는 팀원을 만난 경우도 대다수였다” 등

  • 해당 문제를 가장 심각하게 경험하는 집단: 공모전/대회 팀 활동을 경험한 집단
  • 공모전/대회는 좋은 성과를 거두는 것이 가장 궁극적이고 본질적인 목표이므로, 수상에 유리한 장점과 성향을 가진 적합한 팀원의 존재가 매우 절실함.

  (+) 창업 / 사이드 프로젝트 팀의 경우, ‘개발자’, ‘디자이너’ 등 구체적으로 팀이 필요로 하는 구체적인 파트가 존재하며, 이 직무의 팀원을 구하는 문제를 더 중요하게 인식함. → ‘팀원이 발휘할 퍼포먼스의 질’을 기대하기보다는, ‘얼라인하여 출시까지 안정적으로 함께할 수 있는 팀원인지’ 여부를 더욱 고려함.

3. 추가 양적 리서치를 통한 문제 정의 및 타겟 구체화
   • 해당 문제에 공감하는 고객이 실재하는지 확인하기 위해 추가적인 설문 조사 진행
     • 타겟: 공모전/대회 팀 활동을 경험해본 대학생/취준생 집단 (n = 98)
   • 질문: 공모전/대회 등을 위해 팀을 모은 후, 팀원의 열정, 역량, 성향이 기대했던 것과 달라 어려움을 겪은 경험이 있으십니까?
   • 결과 응답자의 68.4%(98명 중 67명)가 ‘기대했던 바와 팀원이 달라 고통받은 경험이 있다’고 응답. → 70%에 가까운 고객이 문제에 공감하고 있음.

1. 시장 호응 가설 수립 (이 솔루션에 시장이 얼마나 호응할 것인가?)

   [검증하고자 한 시장 호응 가설]

   ‘대회/ 공모전에서 좋은 성적을 거두기 위해 팀원을 찾는 대학생/취준생’(타겟 집단) 중 최소 20%가 ‘팀 지원자와 같이 활동해본 사람들이 그 지원자에 대해 남겨주는 리뷰를 볼 수 있는 플랫폼’을 이용할 것이다. → 최소 20%가 선뜻 이용할 의사를 보인다면, 이 서비스는 존재 가치가 충분한 서비스일 것이다.

   [가설을 검증할 수 있는 형태로 축소]

   ‘에브리타임에서 공모전/대회 수상을 위해 좋은 팀을 구할 수 있는 플랫폼이 출시되었다는 홍보 글을 보고 유입된 사람’ 중 최소 20%가 출시되지도 않은 이 서비스의 마케팅 페이지를 보고 사전 예약을 위해 전화번호를 남길 것이다. (단, 홍보 글에는 기능 설명을 일절 포함하지 않는다)

   • 검증을 위한 가정

     (1) 타겟 집단을 표본 집단으로 축소: 서비스 기능 설명이 일절 없이 니즈를 자극하는 문구만을 보고 유입된 집단은, 타겟 집단과 동일한 니즈를 가진 표본 집단일 것이라고 판단.

     (2) 측정할 수 있는 소비자 행동으로 설정: 서비스 출시 전에는 서비스를 정말로 타겟이 사용할지에 대해 알기 어려우므로, 서비스가 나오기 전 ‘충분한 사용 의지의 표명’으로 판단할 수 있는 행동을 유도. 서비스가 나오기도 전에 마케팅 페이지만을 보고 사전 예약을 한다면, 나아가 민감한 정보인 전화번호를 입력한면, 그 고객은 차후 서비스가 출시되면 충분히 서비스를 사용할 만한 고객일 것이라 가정

2. 가설 검증 링크를 클릭하고 서비스 설명을 읽어 본, 즉 타겟의 니즈에 공감하는 100명 중 21명이 출시도 되지 않은 서비스에 관심을 가지고 개인정보를 남김 → 21명의 고객을 이미 확보

   

3. 기존 대안의 문제점

   3-1. 팀 구인 커뮤니티의 문제 - 에브리타임, 캠픽, 링커리어 - 게시글을 통해 유저들이 댓글과 대화로 ‘알아서’ 팀원을 구해야 함 - 자기소개가 거짓말이나 과장을 포함하는지 검증할 수 없음 - 지극히 주관적인 관점에서 자신의 정보를 제공해 정보의 신뢰성이 낮음

   3-2. 지인 추천의 문제 - 지인의 풀이 한정적이므로, 참여를 원하는 특정 공모전에 함께 나갈 팀원을 구하기 어려움 - 함께 일해본 경험 없이 단순히 알기만 하는 지인일 경우, 여전히 정보의 신뢰성이 낮음

1. 문제 정의 및 분석

• 발굴한 문제: 공모전/대회에 참여하여 좋은 성과를 내고자 하는 대학생/취준생이 기대하는 팀원을 구하기 어렵다.
• 문제의 원인: 정보의 부족.
  • 타겟 집단에게는 ‘팀 지원자가 자신과 함께 좋은 성과를 낼 수 있는 사람이 맞는지’를 판단할 수 있는, 신뢰성 있는 정보가 충분히 주어지지 않음.
    • 모르는 사람이 지원자일 경우: 자기 소개에 내재된 거짓말/허풍의 가능성 → 지원자의 자기 PR을 전적으로 신뢰할 수 없음
    • 지인 추천: 실제로 같이 활동한 경험 없이 단순히 ‘알기만 하는’ 지인을 추천할 경우 → 해당 지원자에 대한 정확한 정보를 알 수 없음 ⇒ 즉, ‘같이 일해보기 전까지는 그 사람에 대해 잘 알 수 없다’.

2. 솔루션 제시

   2-1. 솔루션: 같이 일해본 사람에게 지원자에 대한 정보를 들어보자 ‘같이 일해보기 전까지는 모른다’? → 과거 함께 활동한 경험이 있는 사람을 통해서라면 지원자에 대하여 보다 다면적인, 신뢰 가능한 정보를 얻을 수 있을 것이다.

   2-2. 해당 솔루션을 제공할 수 있는 서비스의 형태: 팀 지원자와 같이 활동해본 사람들의 리뷰를 들어볼 수 있는 플랫폼 → “원하는 팀원”을 구할 수 있는 플랫폼, [Wanteam]

   2-3. 서비스 솔루션 가설: A와 과거 함께 일해본 팀원들로부터 그 사람에 대한 리뷰와 추천사까지 받아볼 수 있다면, 기존의 자기PR에 의존하는 커뮤니티나, 함께 일해보지 않고 그저 알기만 하는 사람을 추천하는 지인 추천보다도 신뢰할 수 있는 정보를 제공할 수 있을 것이다.

기존 대안의 문제점

• 팀 구인 커뮤니티의 문제 - 에브리타임, 캠픽, 링커리어
  • 게시글을 통해 유저들이 댓글과 대화로 ‘알아서’ 팀원을 구해야 함
  • 자기소개가 거짓말이나 과장을 포함하는지 검증할 수 없음
  • 지극히 주관적인 관점에서 자신의 정보를 제공해 정보의 신뢰성이 낮음
• 지인 추천의 문제
  • 지인의 풀이 한정적이므로, 참여를 원하는 특정 공모전에 함께 나갈 팀원을 구하기 어려움
  • 함께 일해본 경험 없이 단순히 알기만 하는 지인일 경우, 여전히 정보의 신뢰성이 낮음

Wanteam이 제공하는, 경쟁사보다 더 우월한 가치

과거 함께 활동해본 팀원들이 지원자에 대해 남긴 리뷰를 볼 수 있다는 Wanteam의 솔루션은, 팀 지원자에 대해 신뢰성 있는 정보를 제공한다는 근본적 해결책을 제시함으로써 3가지 측면에서 기존의 대안과 차별점을 가짐

• 타인의 평가라는 객관성 확보 : 지원자에 대해 자기 PR뿐만 아니라, 과거 실제로 함께 일해본 팀원이 남긴 리뷰를 제공함으로써, 주관적인 자기 평가보다 훨씬 믿을 수 있는 정보를 제공

• 다수의 리뷰 누적으로 신뢰성 제고 : Wanteam을 통해 팀을 구한 이들은, 활동 종료 시 함께한 팀원에 대한 리뷰를 또 한 번 남김 → 한 유저에 대한 리뷰가 쌓여갈수록 리뷰를 남겨주는 집단의 크기와 리뷰의 개수 모두 증가하는 것이므로, 단순히 한 사람의 지인을 통한 소개보다 신뢰성을 제고 가능

• 좋은 팀원에 대한 상대적 기준점 제시 : 단순히 리뷰를 남기는 것을 넘어 팀의 MVP에게만 줄 수 있는 추천사 작성 기능을 통해, ‘수상에 유리한 좋은 팀원인지’ 파악할 수 있는 양적/질적 기준 제공.

  ⇒ Wanteam은 기존의 경쟁 서비스들보다 고객의 문제를 더욱 잘 해결할 수 있음.

TAM 2023년 전국 대학교 재학생 수 2,393,128명

SAM 2022년 기준 대학생 대외활동 참여율 43%, 공모전 참여율 약 35%

SOM 2023년 기준 대학생 대외활동 관련 어플리케이션 사용자 수 평균 약 80,000명

1. 고객 세분화 (Customer Segment)

1-1. 기준: ‘공모전/대회에서 좋은 성과를 내고 싶다’는 궁극적 목표에 대한 의지가 얼마나 강한가?

(i) 도도독동료 팀이 처음 유저 인터뷰를 통해 발견한 불만사항: ‘합류 전 기대했던 모습과, 함께하게 된 팀원의 모습이 너무 다르다는 것’ → 하지만 ‘기대와 다르다’는 점이 직접적으로 불만으로 이어지는 것은 아님.

(ii) 해당 내용이 고객의 입장에서 문제가 되는 근본적 이유: 고객이 ‘공모전/대회에서 좋은 성과를 내고 싶다’는 본질적 목표를 가지고 있기 때문. → 그러나 ‘기대했던 바와 다른 팀원’이 해당 목표 달성을 어렵게 만듦. → 고객은 이러한 문제 상황을 해결하고 궁극적 목표를 달성하고자 하는 니즈를 가지고 있음.

1-2. 분류

- 라이트 유저 (Light User) : 성과에 대한 의지가 강력하기보다는, 참여 및 경험에 의의를 둠.

공모전 특성과 자신의 상황에 맞는 팀원을 원함. 자신과 시너지를 낼 수 있는 팀원들을 만나 즐겁게 공모전/대회에 임하고자 함.

- 헤비 유저 (Heavy User) : 성과에 대한 의지가 매우 강력함.

자신의 상황과 잘 맞음은 물론, 다른 이들에게도 인정받는 최고의 역량을 가진 팀원과 함께함으로써 수상에 유리한 조건을 확보하여 좋은 성과를 내고자 함.

⇒ 서로 다른 니즈를 가진 라이트 유저, 헤비 유저는 Wanteam을 각기 다른 목적으로 사용할 것임.

→ Wanteam은 이러한 유저의 니즈와 사용 목적에 적절히 대응하는 서비스를 제공하도록 설계되었음

2. 페르소나

3. 서비스 플로우

Wanteam 서비스는 ‘공모전, 대회를 비롯한 대외활동을 함께할 검증된 팀원을 찾는 대학생’들이 겪는 ‘기대했던 것과 다른 팀원을 뽑게되어 고통받는 문제’ 를 ‘본 서비스에서 구성한 팀 회고 평가 방식 및 상호 확인’을 통하여 해결하고자 합니다.

1. 키워드 리뷰와 한 줄 추천사

   Wanteam에서는 지원자들의 정보를, 직접 함께 활동했던 옛 동료들이 남겨준 리뷰를 통해 확인할 수있음. 이를 통해 고객은 수상을 위한 팀원을 모집하는 데 필요한 신뢰성 있는 정보를 확보하게 되는데, 이때 라이트 유저와 헤비 유저들은 서로 원하는 ‘신뢰성 있는 정보’의 종류가 다름.

   1-1. 키워드 리뷰 : 라이트 유저들이 원하는 정보

   공모전/대회에서 성과를 내는 것도 물론 좋지만, 모두에게 인정받는 최강의 팀원보다는, 공모전특성과 자신의 상황에 맞는, 보다 즐겁게 협업할 수 있으며 자신과 시너지를 낼 수 있는 팀원을원함. 이를 위해 Wanteam은 ‘지원자들의 장점과 성향’을 파악할 수 있는, 과거 함께했던 팀원이 남겨주는 키워드 리뷰 기능을 제공함.

   Wanteam을 통해 팀원을 모은 팀은 활동 종료시, 함께 활동했던 팀원들 모두가 서로에게 ‘장점 키워드’ 및 ‘성향 키워드’ 리뷰를 남긴다. 해당 리뷰들은 리뷰를 받은 유저의 프로필에 누적되며, 그 유저의 프로필에 시각화되어 노출된다. 이를 Wanteam에서 팀을 구하는 유저들이 확인하게 되며, 주로 라이트, 헤비 유저들이 자신과 잘 맞을 팀원들을 찾는 데 사용할 정보이다.

   • 장점 키워드
     
     팀 지원자가 어떤 장점을 가지고 있는지 보여준다. 같은 키워드에 대해 반복적으로 리뷰를 받을 수록 레벨이 상승하며, 팀원을 구하기 위해 리뷰 프로필을 보는 입장에서 어떤 장점을 가장 강력히 가지고 있는지 알 수 있다.
     
     
   • 성향 리뷰
     
     팀 지원자가 어떤 성향을 가지고 있는지 보여주며, 팀을 구하는 입장에서 자신과 적합한 성향의 팀원을 구하고 싶은 경우 적절한 정보를 제공한다. 리뷰로 각기 다른 성향을 받은 경우 그 평균 값이 표시되며 지원자가 구체적으로 어떤 성향을 얼마나 가지고 있는지 파악할 수 있다.

   1-2. 한줄 추천사 : 헤비 유저들을 위한 서비스 제공

   헤비 유저들은 자신에게 잘 맞음은 기본이고, 수상 확률을 높일 수 있도록 가능한 최고의 팀원을 뽑고 싶어함. 직접 함께 활동해본 사람이 추천하는 팀원, 팀 활동에서 에이스로 꼽히는 팀원을 찾고 싶은 것. 이를 위해 Wanteam에서는 팀 활동 종료 시 팀원 각자가 팀에서 MVP를 1명씩 뽑아 ‘한 줄 추천사’를 작성하도록 함. 한 줄 추천사를 많이 받았다는 것은 과거 팀 활동에서 최고의 팀원으로 추천받은 경우가 많다는 것을 의미하며, 뽑는 입장에서 한 줄 추천사의 내용을 통해 그 팀원의 장점에 대해 더 자세히 이해하고 선발할 수 있음.
   
   

   Wanteam에서 모은 팀이 활동을 종료할 경우, 가장 추천하고 싶은 MVP를 골라 한 줄 추천사를 남기게 된다. 한 줄 추천사의 숫자는 곧 그 사람이 얼마나 많은 사람들에게 최고의 팀원이었는지를 뜻하며 헤비 유저들이 ‘함께하면 수상할 확률이 높은 좋은 팀원’을 판별하는 기준이 된다. 도도독동료 팀은 헤비 유저들이 지금껏 지 못했던, 좋은 팀원을 판별하는 기준을 이용하기 위해 선뜻 유료 티켓을 구매하여 한줄 추천사를 열람하는데 사용할 것이라 판단했다.

2. 공모전/대회에 참여할 팀원 구하기

   우리의 타겟들은 우선 참여할 공모전을 선정한 다음, 가장 적절한 팀원을 구함. 이 고객여정에 맞추어, Wanteam 또한 참여할 공모전 리스트를 제공한 다음, 참여할 공모전을 특정하면 그 안에서 팀을 형성할 수 있음. 이 단계는 구체적으로 공모전을 선택하는 단계와, 팀원 및 팀을 선택하는 단계로 나뉨.

   2-1. 공모전을 선택하는 단계

   기획, 마케팅, 디자인, 개발 등 다양한 부류로 찾아볼 수 있는 공모전 리스트를 제공함. 유저들은 공모전에 대한 상세한 정보를 탐색하며 참여할 공모전을 선택할 수 있음.

   2-2. 팀 또는 팀원을 선택하는 단계

   나갈 공모전을 골랐다면, 그 안에서 팀원 모집 중인 팀에 합류하거나, 팀을 직접 오픈 할 수도 있음. 팀장으로서 지원자의 프로필을 확인할 수 있고, 팀에 지원하기 전 팀장 및 이미 합류한 팀원들의 프로필을 확인할 수도 있음.

3. 리뷰와 추천사

   3-1. 팀 활동 종료 후 각 팀원에게 작성하는 리뷰와 한 줄 추천사

   Wanteam에서 팀원을 모집하면 팀은 활동 종료 시, 각 팀원에게 리뷰를 남겨야 함. 프로필의 리뷰를 보고 팀원을 모집하고, 활동 후 팀원에게 리뷰를 작성하는 선순환을 통해 Wanteam 유저들의 프로필 리뷰를 누적해 감.

   • 리뷰 작성 유도 방법: 타인이 자신에게 리뷰를 작성해 주었을 시 자동으로 알림 이메일이 발송됨. 타인에게 받은 리뷰를 확인하기 위해서는, 함께 활동했던 다른 모든 팀원들에게 한 명도 빠짐없이 리뷰를 작성해 주어야 함. 리뷰를 작성해주지 않은 팀원이 한 명이라도 존재할 시, 프로필에 신규 리뷰 내용이 아예 업데이트 되지 않음 → 자신에게 작성된 리뷰를 보기 위해서뿐만 아니라, 추후 팀 모집 활동 시 양질의 프로필로 어필하기 위해서 타인에게 리뷰를 남길 수밖에 없음.

   3-2.가입 시 외부인에게 요청하는 추천사

   첫 가입 시 리뷰 및 추천사가 전혀 없어 팀을 구하는 데 어려움을 겪을 신규 가입자를 고려하여, Wanteam 사용자가 아니더라도 함께 활동했던 경험이 있는 외부 지인에게 1번의 리뷰 및 추천사를 받을 수 있음. → 신규 가입 회원이어도 프로필 리뷰가 있는 상태에서 팀 구인을 시작할 수 있음.

• 동적 타입 체크를 통한 코드 안정성 향상 및 오탈자를 방지합니다.

• 가장 많이 사용되고 익숙한 라이브러리로, 개발 생산성을 위해 도입하였습니다.
• 컴포넌트 기반 아키텍처: React는 UI를 컴포넌트로 나누어 개발하도록 돕는 컴포넌트 기반 아키텍처를 제공합니다. 이로써 코드를 재사용하고 유지보수하기 쉽습니다.
• Virtual DOM: React의 가상 DOM은 성능을 최적화하고 브라우저 상의 DOM 조작을 최소화하여 빠른 웹 애플리케이션을 구축하는 데 도움을 줍니다.

• 컴포넌트 재사용이 편리하고 유지보수가 간편합니다.
• 컴포넌트 수준에서 스타일링을 관리하는 효과적인 방법을 제공합니다.

• 전역 상태를 관리하기 위한 간단하고 직관적인 방법 제공하는 라이브러리입니다.

• HTTP 요청 라이브러리: Axios는 HTTP 요청을 쉽게 보내고 응답을 처리할 수 있는 라이브러리로, RESTful API와 통신하기 위한 강력한 도구입니다.
• Promise 기반: Axios는 Promises를 사용하여 비동기 작업을 처리하므로 코드가 간결하고 오류 처리가 효율적입니다.

• 자동으로 데이터를 캐싱하고, 주기적으로 갱신하여 최신 데이터를 유지한다.
  
  

• 자바에서 db bender에 종속되지 않고 객체 중심으로 애플리케이션 개발 가능합니다.

• 스프링 애플리케이션 배포 서버로 프리티어를 통해 무료로 일정량 사용할 수 있습니다.,

• 일정량 무료로 사용할 수 있으며 클라우드 인스턴스화 할 수 있습니다.

• 필요한 데이터를 어디서나 쉽게 저장하고 검색할 수 있도록 해줍니다.

• CICD를 진행 할 때 실행 가능한 서버 애플리케이션을 도커를 통해 컨테이너화 시켜 서버 환경에서 쉽게 실행할 수 있게 합니다.

• EC2 인스턴스 내부에서 빌드할 docker image 쉽게 관리할 수 있게 합니다.

• Github에서 제공하는 CICD 프로세스로 젠킨스와 같은 별도의 파이프라인을 구축할 필요 없다는 장점이 있습니다.

• Spring boot와 통합하여 사용자 인증과 인가에 대한 보안 요구사항을 쉽게 처리하도록 도와줍니다.

• component : PascalCase
  • 최상위 태그 : -Layout
  • 차상위 태그 : -Container
• constant : SNAKE_CASE
• 변수 : camelCase
• recoil atom : camelCaseState
• Interface
  • props : PascalCaseProps
  • api response : PascalCaseResponse

• Packages
  • 항상 소문자로 생성하기
• Classes
  • 명사여야 한다.
  • 복합 단어의 경우 각 단어의 첫글자는 대문자.
  • 완전한 단어를 사용하고, 두 문자어와 약어는 피한다.
• Interfaces
  • 인터페이스 이름도 클래스 이름과 같은 대문자 규칙을 적용한다.
• Methods
  • 동사여야 한다.
  • 복합 단어의 경우 첫 단어는 소문자로 시작한다.
• Constants
  • 클래스 상수로 선언된 변수들과 상수들의 이름은 모두 대문자로 쓰고 각 단어는 언더바 ("_")로 분리한다. -** Variables**
  • 변수 이름의 첫번째 문자는 소문자여야 한다.
  • 언더바 또는 달러 표시 문자로 시작하는 것이 허용 되기는 하지만, 사용하지 말자.
  • 짧지만 의미있게 짓는다.
  • 변수의 사용 의도를 알 수 있도록 의미적으로 짓는다.
  • 한문자로만 이루어진 변수는 암시적으로만 사용하고 버릴 변수를 제외하고는 피한다.
  • 임시 변수의 이름은 integer는 i,j,k,m,n 을 사용하고 character는 c,d,e를 사용한다.
• ETC
  • DB 테이블: lower_snake_case
  • ENUM, 상수: Upper_snake_case
  • 컬렉션(Collection): 복수형을 사용하거나 컬렉션을 명시한다. (Ex. userList, users, userMap)
  • LocalDateTime: 접미사에 Date를 붙인다.

Ex) git commit -m "feat(#8) : 앱 설치 플로팅 배너 추가"

• feat : 새로운 기능 추가
• fix : 버그 수정
• chore : 빌드 업무, 패키지 매니저, 라이브러리, dependencies 설정
• docs : 문서 수정 - README.md, .github, ..etc
• design : 사용자 UI 디자인 변경 - CSS
• style : 기능 수정 없는 코드 스타일 변경
• refactor : 코드 리팩터링
• test : 테스트 코드, 리펙토링 테스트 코드 추가
• ci : ci 설정 파일 수정
• perf : 성능 개선
• rename : 파일 혹은 폴더명 변경

• main : 출시 가능한 프로덕션 코드의 브랜치

• develop : 다음 버전을 개발하는 브랜치

• feature : 기능을 개발하는 브랜치

• hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치

  브랜치 네이밍 : feat/이슈번호