Day 1 - OT 및 기획 개발 수업 😀

💡 OT & Ice Breaking

두근 두근 설레고 긴장되는 첫 날이었다. 아무래도 첫 만남이라 그런지 다들 어색했었지만, 다행히도 아이스 브레이킹 시간을 가지면서 조원들을 포함하여 어색함을 조금이라도 덜어낼 수 있는 시간이어서 좋았다.

아이스 브레이킹 시간은 처음이었는데, 너무 좋은 경험으로 남을 것 같다.
말 그대로 어색한 분위기를 얼음에 빗대어서 얼음을 부수는 것(?) 같았다 ㅋㅋ

아이스 브레이킹 시간을 가지면서, 서로 대화도 하며 얼굴을 그려주고, 자신의 관심사 3가지 그리고 마지막으로 24시간(?) 일할 수 있을만큼 이상적인 업무환경을 직접 모의로 제작해보고 발표해보는 시간을 가져보았다.

이 후 오늘부터 수업이 어떻게 진행될 지, 수료 기준은 무엇인 지 부트캠프에 대한 설명을 진행해주셨다.
그리고 조원들과 어색한 점심 식사(?)를 함께한 뒤 첫 개발 기획 수업이 시작되었다 ❗❗

아❗ 그리고 서울 시청 한복판에서 아아를 1000원에 먹을 수 있던 점도 매우 좋았다 😀


플랫폼 ? 🤔

  • 플랫폼은 기차역 승강장을 비유하여 말합니다.
  • 인간의 관계에서 생성되는 교류의 정류장 역할
  • 서비스와 유저들 간에 이뤄지는 다양한 교류가 발생하는 기업과 개인이 공동의 이익을 형성하는 곳.

플랫폼은 어떻게 진화하였는가 ? 🤔

Device의 변화에 밀접한 관계가 있다.
예전에는 PC(Personal Computer), TV의 보급이 잘 되어있지 않았고, 전화번호부 등 정보를 소유하는 것이 재산이 되었다.

하지만 시대가 지나면서 PC가 보급이 되고, 개인적으로 사용하게 되는 스마트폰이 보급되면서 정보를 소유하는 것이 개인화 되면서 서비스의 이용 그리고 보급 또한 달라지게 되었다.


플랫폼으로 대표적인 Google의 수익구조

사용자들이 플랫폼을 이용하고, 이용하면서 만들어내는 정보가 수익을 만들어내는 구조.

"고객의 행동으로 이뤄지는 플랫폼 생태계"

Youtube는 사용자가 생성하는 동영상을 기반으로 수익원을 창출

더욱 콘텐츠를 잘 올리고 서비스 퀄리티를 높일 수 있도록 편집/송출 기능을 제공하고 있습니다

Youtube vs TikTok ? 🤔

TikTok이 흥행할 당시에 Youtube의 편집/송출 기능은 PC Web 환경에서만 제한적이었다.
반면에 TikTok은 모바일 환경에서 편집/송출이 가능하였다.

현재는 Youtube 또한 모바일 환경에서 가능하다.

이러한 점에서 우리는 "디바이스의 영향을 제대로 예측하여 서비스를 개선해야한다" 는 점을 알 수 있다.


플랫폼의 핵심은 무엇인가 ? 🤔

플랫폼의 전략적 가치를 발견하는 2가지 요소 - 관계, 수단

관계수단플랫폼
정보를 주고받고 공감하는 관계정보 공유(다면 플랫폼)페이스북, 네이버
상품을 주고받는 관계상품 판매(거래 플랫폼)옥션
서비스와 개인을 연결해주는 관계GATE 역할(생태계 플랫폼)앱스토어, 구글 플레이 스토어

플랫폼 서비스 설계를 위한 사고

서비스를 접목시켰을 때, 어색하지 않도록 서비스 패턴을 고려하여 설계하여야 한다.

서비스 패턴? 🤔

서비스 패턴은 "암묵적으로 습관화되어 있는 규칙" 과 같으며 소비자는 새로운 패턴이 아닌 이미 알고있는 패턴으로 쉽게 적응한다.

말 그대로 암묵적으로 습관화되어 있는 규칙, 패턴으로 볼 수 있다. 예를 들면 어떤 무엇인가를 확인(OK) or 승인(accept) 하는 버튼은 대부분 오른쪽에 위치해있고, 로그인 박스에서 사용자 정보를 입력한 뒤 로그인 버튼이 오른쪽에 위치하는 것과 유사한 말이다. 로그인 버튼이 왼쪽에 위치해있는 경우는 매우 드물다.

이러한 이유가 서비스 패턴을 지키기 위함이다.


플랫폼을 성공시키려면 🤔

  • 소비자에게는 신뢰성이 매우 중요한 요건 기업의 신뢰성
  • 기업의 신뢰가 없다면 사람과 사람 관계를 이용하자. 개인의 신뢰성
  • 처음부터 비용을 선뜻 지불하는 고객은 거의 없다. 초기에는 무료로 사용하게 하자.
  • 이용을 하지 않으면 손실을 보는 듯한 기대가치를 부여해보자.

카카오톡의 "자동친구추가"

개인의 신뢰성 예시.

연락처에 있는 자동 친구 추가 기능을 통해 자신의 지인들이 왜 이 서비스를 사용하지 않는 지 ?
고객이 고객을 끌어오는 대표적인 예시가 된다.


플랫폼의 서비스 성장이 더뎌지는 이유 🤔

기술의 발달로 인하여 "신규 서비스" 트렌드가 생길 수 있다.
이러한 "신규 트렌드"에 적응하여 서비스의 콘셉트를 변화시켜야 한다.


플랫폼 서비스를 구축하기 위한 아이디어 ? 🤔
아이디어는 완성 상태로 떠오르지 않는다.

오직 실행하는 과정에서 명료해지는 것이다.


💡 [과제] 플랫폼 App 구축에 대한 아이디어 도출

** [과제] 플랫폼 App 구축에 대한 아이디어 도출 **

초등 또는 중학생에게 제공될 학습 App 플랫폼에 대해 자신이 생각한 아이디어를 작성해 보세요. 

- 목적
- 서비스 대상
- 서비스 모델
- 유사 App과 다른 경쟁력

우리 조는 과제를 진행하면서 요즘 오픈카톡방 또는 웹사이트 를 통해서도 유사 방 탈출을 진행할 수 있다.
방 탈출 이라는 요소가 대중적으로 굉장히 흥미를 유발하는 요소라고 생각이 들었고, 초등 또는 중학생들이 방 탈출이라는 요소를 통해 학습을 하면 어떨까 ? 더 재미있어하지 않을까 라는 생각이 들게 되었다

목적

초등 또는 중학생의 학습에 흥미를 유발하기 위함

서비스 대상

초등 또는 중학생

서비스 모델 설계

설계 순서 🤔

플랫폼을 설계할 때, 어떤 순서로 설계를 해야할까 ?

1. Front를 먼저 설계한다. (Front는 사용자가 서비스를 이용할 때 보이는 부분이라고 볼 수 있다)
2. Front를 기준으로 Admin에는 어떤 기능들이 있을 지 추측하며 설계한다.

서비스 모델은 마인드 맵 툴인 FreeMind를 사용하여 플랫폼의 IA(Information Architecture) 를 구축하였다.

FreeMind

FreeMind Download << 다운로드 링크이다.

이와 같이 서비스 모델의 IA를 구축해보았다.

유사 App과 다른 경쟁력

유사 App 서비스

  1. 플레이 더 월드 (https://playthe.world/](https://playthe.world)
  2. 오일팔닷컴 (https://sites.google.com/view/51840escape)

다른 점

  1. 유사 서비스는 모두 온라인 웹 서비스이지만, 저희는 App서비스 또한 제공하여 사용자의 접근이 더욱 쉽습니다.
  2. 랭킹 시스템을 통한 이로운 경쟁이 가능합니다.

Day 2 - 기획 개발 수업 - UML

💡 오전 과제 : IA 디테일링

오전에는 전 날 구축하였던 IA의 디테일링 과제를 진행하였다.
디테일링 과정에서 팀원들 간 의견 충돌이 꽤 있었고 맞는 의견인지 잘 모르겠고 틀린 의견일까봐 표현하기 어려웠었다 ㅠㅠ

고심끝에 팀원들과 디테일링 작업을 완료한 IA의 모습이다.

눈에 띄게 바뀐 점은 관리자의 공지사항, 고객센터 신고기능, 문제 정렬, 유저들의 유저 정보를 수정 할 수 있는 기능들이 필요하다고 생각하여 추가해주었고, 실제 Depth에 따라 게시글 및 댓글에 대한 기능들을 레벨화하였다.

위 작업에서 숫자들로 구현 우선순위 Priority 값을 주었는데 이는 MVP 기획 기법 을 사용한 것이다.


MVP ? 🤔

MVP는 최소 기능 제품(Minimum Viable Product)을 의미하며
이 기획 기법에 대해서 잘은 모르지만 팀원 분이 알려준 덕분에 잘 이해하게 되었다.

MVP 1 -> 서비스가 동작되기 위한 최소한의 기능.
MVP 2 -> 추가적인 확장 기능.

MVP 1 은 검은색 숫자 0 MVP 2는 주황색 숫자 8로 표시하였다.

MVP 1, 2를 나누어 얻을 수 있는 이점 🤔

너무 처음부터 완벽함에 가까운 기능을 구현할 수 없을 뿐 더러 기능들은 언제든지 유지보수되며 추가될 수 있고,

너무 방대한 기능들을 초기에 구현하게 되면 제작 기간이 길어질 뿐 더러 루즈해질 수 있다.

MVP 1 을 통해 배포하게 되면 고객들의 여러 의견, 요구를 얻을 수 있고, 시장성을 확보하여 MVP 2에 어떤 추가적인 기능들을 추가하는 것이 좋을 지 파악할 수 있다.


UML ? 🤔

  • UML - Unified Modeling Language
  • 프로그래밍이 아닌 시스템 자체의 산출물의 역할을 시각화 하여 규정화하고 시각화하며 문서화 하는 언어이다.
  • 객체 지향 모델링 언어라고도 불리며, 이러한 필요한 행위를 기반으로 하여 객체 지향 모델링이 가능해진다.

UML에서 정의하는 모델링

어떠한 현상들을 단순화, 일반화, 추상화하는 과정
( 프로세스를 정의 )

  • 내부 구조동작하는 행위에 대한 표현의 자유

  • 시스템의 구성 요소들이 서로 어떻게 연결되어 있는 지 확인이 가능하다.
    ex) 결제 시스템 <-> 배송 시스템 (결제가 완료되거나 결제가 취소될 때 상호작용)

  • 설계와 구현 간의 일관성이 유지

  • 레벨화가 가능하다. ( 기능의 중요도에 따라 우선순위를 매길 수 있다. )
    ex) 옥션의 장바구니 vs 고객센터

  • 명확한 의사소통의 도구가 된다.


UML을 사용하는 이유 🤔

우리는 플랫폼을 만들 때 2가지의 근본적인 어려움을 겪고 있다.

복잡성 / 변경

복잡성으로 인해 이해관계자 간 플랫폼에 대한 이해가 다를 수 있고, 개발 프로세스 중간 변경을 통해 서비스의 전체를 뒤집어야 할 수도 있다.

1. UML은 이야기가 가능한 시각화 Tool

규격화된 규칙으로 인한 손쉽게 이해할 수 있는 시각화가 필요하다.

정확하게 어떤 것을 무엇을 나타내는지 그림으로 표현되어 있어 이해하기 더 쉽다.

2. UML은 사람의 행위를 기반으로 한다.

사람의 행위단계적 과정을 시점상으로 표현한 것.

절차단계의 가설을 키워드로 표현, 시나리오를 확장하는 순차적 단계식으로 나타냄.

3. UML은 사용자의 문제를 기반으로 모델링한다.

UML 모델링의 이점

  • 시각화
  • 이해도
  • 정확성
  • 의사전달
  • 일관성

=> 모두 성공적인 플랫폼의 구축 필수 요건

4. UML은 모델 주도적 개발방식이다.

이해관계자가 서로 커뮤니케이션 할 수 있는 소프트웨어 시스템의 구조행위를 정의하고 기술함으로써 빠르고 정확한 플랫폼을 구현할 수 있다.


대표적으로 UML에서 사용하는 Diagram으로는 Activity Diagram, Use Case Diagram, Sequence Diagram, State Machine Diagram 이 있다.

Use Case Diagram 🤔

  • 시스템의 행위를 모델링, 시스템의 요구 사항을 표현하는 데 사용

  • 시스템의 상위 레벨 기능과 범위를 기술

  • 기능을 어떻게 구현할 것인지를 기술하지 않습니다.

  • What ? - 무슨 기능이 필요한지에 대해서만 표현.

교육용 방탈출 플랫폼 메인 기능 Use Case Diagram

방 탈출 플랫폼의 메인 기능인 문제 풀이, 문제 제작, 로그인 기능에 대해서 액터를 중학생(유저), 교사(출제를 한 유저), 관리자로 구분하였다.

  1. 로그인 및 회원가입 된 회원은 관리자의 회원 관리 기능에 의해 관리된다.
  2. 문제를 풀이하는 과정에서 출제자의 문제가 풀이자에게 공유된다.
  3. 출제된 문제는 관리자에 의해 문제가 관리된다.
  4. 풀이자가 문제 풀이 중 어려움을 겪을 경우, 질문 답변을 이용할 때 관리자에 의해 게시글 및 답변이 관리될 수 있다.
  5. 풀이자의 후기 및 추천 글이 관리자에 의해 관리된다.

Activity Diagram 🤔

  • 활동 다이어그램은 시스템의 실행과 행위의 흐름을 표현.

  • 비즈니스 프로세스 또는 작업에서 이용하는 고객의 흐름을 표현하는데 적합.

방탈출 문제 풀기 시나리오 Activity Diagram

방탈출 문제 제작 시나리오 Activity Diagram


강사님 조언

“목적을 위한 기능”을 만들자. 기능으로 목적을 만들지 말자..

플랫폼 또는 서비스를 개발하면서 개발자 관점, 구축자 관점, 고객의 관점에서 플랫폼으로 바라볼 수 있다.

고객을 위한 서비스를 개발해야 하므로 고객 VOC를 통해 고객의 니즈, 현황, 요구를 파악하는 것이 중요하다.


Day 3 - 기획 개발 수업 - 아이디어 스케칭

💡 오전 과제 : 클래스 다이어그램 작성

오전에는 전 날 부여받았던 과제로 진행하는 플랫폼의 클래스 다이어그램을 작성하는 과제를 진행해보았다.

학부에서도 UML을 작성하는 법을 배웠었는데 클래스 다이어그램 을 작성하는 방법을 배웠었는데 그 당시에는 애매모호한 부분이 있었는데 이번 수업을 통해서 조금 더 자세하게 배울 수 있었던 것 같다.


Day 4 - 역량 강화 수업 OT & 조 변경

오늘부터는 역량 강화 교육이 시작되는 날이다.

이 전에 퍼실리테이터 분들과 매니저 분께서 말씀해주셨듯이 오늘부터는 조가 "역량 강화 교육"을 진행하기 위해 기술 스택별로 조가 편성이 되었고, 새로운 조원들과 인사하는 시간을 가졌다.

퍼실리테이터분들께서 역량 강화 교육 OT를 휼륭하게 진행해주신 덕분에 조금 어색했던 얼어있던 분위기가 풀릴 수 있었고, 앞으로 기획 개발 교육이 끝난 Week 2부터는 어떻게 진행이 될 지 협업 툴인 SlackNotion을 어떻게 사용해야 하는 지 ? 잘 알려주셨고

특히 Notion에 있어서는 협업 과정에서 사용하게 될 페이지들( 너무 잘 만들어주셨다 ㅠㅠ )을 어떻게 사용하는 지 지도해주신 덕분에 협업 과정에서 문서화가 잘 이루어질 수 있을 것이라는 생각이 들었다.

이 후, 조원들과 점심식사를 같이 하면서 얘기도 하며 어색함도 덜어내고 식사 이 후, 퍼실리테이터분이 부여해주신 Mission(광화문에서 팀원들과 사진 찍기) 을 수행하면서 더 친해질 수 있어서 좋았다.

오후부터는 마지막(?)이 될 자기소개 시간을 가진 후, 팀원들과 앞으로의 Meeting에서 지켜야 할 암묵적인 Rule인 Ground Rule을 작성하였다.


Ground Rule

앞으로 교육에서 진행하게 될 팀 Meeting, 그리고 과제를 수행하기 위해서 Rule을 작성하였고 룰을 지키지 않은 팀원에게 패널티(?)를 부여하는 룰도 추가하였다 ㅋㅋ


마지막 한 마디

다음 주 부터는 진짜 개발 역량 강화 교육이 시작될 것이다.

이번 주 진행한 기획 개발 수업을 통해 "기획"하는 과정에 대해서 많은 것을 배우게 되었고
또한 과제를 진행하면서 조원들과의 의견 충돌도 있었고 하고 싶었던 의견을 속으로 삭힌 적(?) 등등 실무에 협업에 있어 미리 어려움이 있었고 UML 다이어그램 및 IA를 구축하는 데에 있어 좀 복잡해서 어렵고 머리도 아팠던 것 같다.

학부과정에서도 이러한 다이어그램을 작성해본 적도 있긴 하지만 이렇게 정석적으로 작성해본 적이 없었어서 뜻 깊었다.

나중에 취업을 하게 되어 실무에 나가게 되어서도 서비스를 "기획"하는 부분에 있어서
개발자로서 어떤 자세로 임해야 하는 지 어떻게 의견을 제시하는 것이 좋을 지 이번 수업을 통해서 배우게 되었고, 앞으로는 "기획 및 스케치" 과정을 통해 단계적인 개발 절차를 적용해보려 한다.


유데미 바로가기: https://bit.ly/3SFlXDy

유데미 STARTERS 취업 부트캠프 공식 블로그 보러가기: https://blog.naver.com/udemy-wjtb

💡 본 후기는 유데미-웅진씽크빅 취업 부트캠프 2기 - 프론트엔드&백엔드 과정 학습 일지 리뷰로 작성되었습니다.


📌 참조

profile
Yoon's Dev Blog

0개의 댓글