두근 두근 설레고 긴장되는 첫 날이었다. 아무래도 첫 만남이라 그런지 다들 어색했었지만, 다행히도 아이스 브레이킹 시간을 가지면서 조원들을 포함하여 어색함을 조금이라도 덜어낼 수 있는 시간이어서 좋았다.
아이스 브레이킹 시간은 처음이었는데, 너무 좋은 경험으로 남을 것 같다.
말 그대로 어색한 분위기를 얼음에 빗대어서 얼음을 부수는 것(?) 같았다 ㅋㅋ
아이스 브레이킹 시간을 가지면서, 서로 대화도 하며 얼굴을 그려주고, 자신의 관심사 3가지 그리고 마지막으로 24시간(?) 일할 수 있을만큼 이상적인 업무환경을 직접 모의로 제작해보고 발표해보는 시간을 가져보았다.
이 후 오늘부터 수업이 어떻게 진행될 지, 수료 기준은 무엇인 지 부트캠프에 대한 설명을 진행해주셨다.
그리고 조원들과 어색한 점심 식사(?)를 함께한 뒤 첫 개발 기획 수업이 시작되었다 ❗❗
아❗ 그리고 서울 시청 한복판에서 아아를 1000원에 먹을 수 있던 점도 매우 좋았다 😀
플랫폼
은 기차역 승강장을 비유하여 말합니다.Device
의 변화에 밀접한 관계가 있다.
예전에는 PC
(Personal Computer), TV
의 보급이 잘 되어있지 않았고, 전화번호부 등 정보를 소유하는 것이 재산이 되었다.
하지만 시대가 지나면서 PC
가 보급이 되고, 개인적으로 사용하게 되는 스마트폰이 보급되면서 정보를 소유하는 것이 개인화 되면서 서비스의 이용 그리고 보급 또한 달라지게 되었다.
사용자들이 플랫폼을 이용하고, 이용하면서 만들어내는 정보가 수익을 만들어내는 구조.
"고객의 행동으로 이뤄지는 플랫폼 생태계"
더욱 콘텐츠를 잘 올리고 서비스 퀄리티를 높일 수 있도록 편집/송출 기능을 제공하고 있습니다
TikTok
이 흥행할 당시에 Youtube
의 편집/송출 기능은 PC Web
환경에서만 제한적이었다.
반면에 TikTok
은 모바일 환경에서 편집/송출이 가능하였다.
현재는 Youtube
또한 모바일 환경에서 가능하다.
이러한 점에서 우리는 "디바이스의 영향을 제대로 예측하여 서비스를 개선해야한다" 는 점을 알 수 있다.
관계 | 수단 | 플랫폼 |
---|---|---|
정보를 주고받고 공감하는 관계 | 정보 공유(다면 플랫폼) | 페이스북, 네이버 |
상품을 주고받는 관계 | 상품 판매(거래 플랫폼) | 옥션 |
서비스와 개인을 연결해주는 관계 | GATE 역할(생태계 플랫폼) | 앱스토어, 구글 플레이 스토어 |
서비스를 접목시켰을 때, 어색하지 않도록 서비스 패턴을 고려하여 설계하여야 한다.
서비스 패턴은 "암묵적으로 습관화되어 있는 규칙" 과 같으며 소비자는 새로운 패턴이 아닌 이미 알고있는 패턴으로 쉽게 적응한다.
말 그대로 암묵적으로 습관화되어 있는 규칙, 패턴으로 볼 수 있다. 예를 들면 어떤 무엇인가를 확인(OK) or 승인(accept) 하는 버튼은 대부분 오른쪽에 위치해있고, 로그인 박스에서 사용자 정보를 입력한 뒤 로그인 버튼이 오른쪽에 위치하는 것과 유사한 말이다. 로그인 버튼이 왼쪽에 위치해있는 경우는 매우 드물다.
이러한 이유가 서비스 패턴을 지키기 위함이다.
기업의 신뢰성
개인의 신뢰성
초기에는 무료로 사용하게 하자.
개인의 신뢰성
예시.
연락처에 있는 자동 친구 추가
기능을 통해 자신의 지인들이 왜 이 서비스를 사용하지 않는 지 ?
고객이 고객을 끌어오는 대표적인 예시가 된다.
기술의 발달로 인하여 "신규 서비스" 트렌드가 생길 수 있다.
이러한 "신규 트렌드"에 적응하여 서비스의 콘셉트를 변화시켜야 한다.
플랫폼 서비스를 구축하기 위한 아이디어 ? 🤔
아이디어는 완성 상태로 떠오르지 않는다.
오직 실행하는 과정에서 명료해지는 것이다.
** [과제] 플랫폼 App 구축에 대한 아이디어 도출 **
초등 또는 중학생에게 제공될 학습 App 플랫폼에 대해 자신이 생각한 아이디어를 작성해 보세요.
- 목적
- 서비스 대상
- 서비스 모델
- 유사 App과 다른 경쟁력
우리 조는 과제를 진행하면서 요즘 오픈카톡방 또는 웹사이트 를 통해서도 유사 방 탈출을 진행할 수 있다.
방 탈출
이라는 요소가 대중적으로 굉장히 흥미를 유발하는 요소라고 생각이 들었고, 초등 또는 중학생들이 방 탈출
이라는 요소를 통해 학습을 하면 어떨까 ? 더 재미있어하지 않을까 라는 생각이 들게 되었다
초등 또는 중학생의 학습에 흥미를 유발하기 위함
초등 또는 중학생
플랫폼을 설계할 때, 어떤 순서로 설계를 해야할까 ?
1. Front를 먼저 설계한다. (Front는 사용자가 서비스를 이용할 때 보이는 부분이라고 볼 수 있다)
2. Front를 기준으로 Admin에는 어떤 기능들이 있을 지 추측하며 설계한다.
서비스 모델은 마인드 맵 툴인 FreeMind
를 사용하여 플랫폼의 IA(Information Architecture)
를 구축하였다.
FreeMind Download << 다운로드 링크이다.
이와 같이 서비스 모델의 IA
를 구축해보았다.
App
서비스 또한 제공하여 사용자의 접근이 더욱 쉽습니다.오전에는 전 날 구축하였던 IA
의 디테일링 과제를 진행하였다.
디테일링 과정에서 팀원들 간 의견 충돌이 꽤 있었고 맞는 의견인지 잘 모르겠고 틀린 의견일까봐 표현하기 어려웠었다 ㅠㅠ
고심끝에 팀원들과 디테일링 작업을 완료한 IA
의 모습이다.
눈에 띄게 바뀐 점은 관리자의 공지사항, 고객센터 신고기능, 문제 정렬, 유저들의 유저 정보를 수정
할 수 있는 기능들이 필요하다고 생각하여 추가해주었고, 실제 Depth
에 따라 게시글 및 댓글에 대한 기능들을 레벨화하였다.
위 작업에서 숫자들로 구현 우선순위 Priority 값을 주었는데 이는
MVP
기획 기법 을 사용한 것이다.
MVP
는 최소 기능 제품(Minimum Viable Product)을 의미하며
이 기획 기법에 대해서 잘은 모르지만 팀원 분이 알려준 덕분에 잘 이해하게 되었다.
MVP 1 -> 서비스가 동작되기 위한 최소한의 기능.
MVP 2 -> 추가적인 확장 기능.
MVP 1
은 검은색 숫자 0 MVP 2
는 주황색 숫자 8로 표시하였다.
너무 처음부터 완벽함에 가까운 기능을 구현할 수 없을 뿐 더러 기능들은 언제든지 유지보수되며 추가될 수 있고,
너무 방대한 기능들을 초기에 구현하게 되면 제작 기간이 길어질 뿐 더러 루즈해질 수 있다.
MVP 1
을 통해 배포하게 되면 고객들의 여러 의견, 요구를 얻을 수 있고, 시장성을 확보하여 MVP 2
에 어떤 추가적인 기능들을 추가하는 것이 좋을 지 파악할 수 있다.
UML
- Unified Modeling Language시각화
하여 규정화하고 시각화하며 문서화
하는 언어이다.객체 지향 모델링 언어
라고도 불리며, 이러한 필요한 행위를 기반
으로 하여 객체 지향 모델링
이 가능해진다.어떠한 현상들을 단순화
, 일반화
, 추상화
하는 과정
( 프로세스를 정의 )
내부 구조
나 동작하는 행위
에 대한 표현의 자유
시스템의 구성 요소
들이 서로 어떻게 연결
되어 있는 지 확인이 가능하다.
ex) 결제 시스템 <-> 배송 시스템 (결제가 완료되거나 결제가 취소될 때 상호작용)
설계와 구현 간의 일관성
이 유지
레벨화
가 가능하다. ( 기능의 중요도에 따라 우선순위
를 매길 수 있다. )
ex) 옥션의 장바구니 vs 고객센터
명확한
의사소통의 도구가 된다.
우리는 플랫폼을 만들 때 2가지의 근본적인 어려움을 겪고 있다.
복잡성 / 변경
복잡성
으로 인해 이해관계자 간 플랫폼에 대한 이해가 다를 수 있고, 개발 프로세스 중간 변경
을 통해 서비스의 전체를 뒤집어야 할 수도 있다.
규격화된 규칙으로 인한 손쉽게 이해
할 수 있는 시각화
가 필요하다.
정확하게
어떤 것을 무엇을 나타내는지 그림으로 표현되어 있어 이해하기 더 쉽다.
사람의 행위
를 단계적
과정을 시점상으로 표현한 것.
절차
와 단계
의 가설을 키워드로 표현, 시나리오를 확장
하는 순차적 단계
식으로 나타냄.
시각화
이해도
정확성
의사전달
일관성
=> 모두 성공적인 플랫폼의 구축 필수 요건
이해관계자가 서로 커뮤니케이션 할 수 있는 소프트웨어 시스템의 구조
와 행위
를 정의하고 기술함으로써 빠르고 정확한 플랫폼을 구현할 수 있다.
대표적으로 UML에서 사용하는 Diagram으로는 Activity Diagram
, Use Case Diagram
, Sequence Diagram
, State Machine Diagram
이 있다.
시스템의 행위
를 모델링, 시스템의 요구 사항
을 표현하는 데 사용
시스템의 상위 레벨 기능과 범위를 기술
기능을 어떻게 구현할 것인지를 기술하지 않습니다.
What ?
- 무슨 기능이 필요한지에 대해서만 표현.
방 탈출 플랫폼의 메인 기능인 문제 풀이, 문제 제작, 로그인 기능에 대해서 액터를 중학생(유저), 교사(출제를 한 유저), 관리자로 구분하였다.
활동 다이어그램은 시스템의 실행과 행위의 흐름
을 표현.
비즈니스 프로세스 또는 작업에서 이용하는 고객의 흐름
을 표현하는데 적합.
“목적을 위한 기능”을 만들자. 기능으로 목적을 만들지 말자..
플랫폼 또는 서비스를 개발하면서 개발자 관점, 구축자 관점, 고객의 관점
에서 플랫폼으로 바라볼 수 있다.
고객을 위한 서비스
를 개발해야 하므로 고객 VOC를 통해 고객의 니즈, 현황, 요구
를 파악하는 것이 중요하다.
오전에는 전 날 부여받았던 과제로 진행하는 플랫폼의 클래스 다이어그램을 작성하는 과제를 진행해보았다.
학부에서도 UML
을 작성하는 법을 배웠었는데 클래스 다이어그램
을 작성하는 방법을 배웠었는데 그 당시에는 애매모호한 부분이 있었는데 이번 수업을 통해서 조금 더 자세하게 배울 수 있었던 것 같다.
오늘부터는 역량 강화 교육이 시작되는 날이다.
이 전에 퍼실리테이터 분들과 매니저 분께서 말씀해주셨듯이 오늘부터는 조가 "역량 강화 교육"을 진행하기 위해 기술 스택
별로 조가 편성이 되었고, 새로운 조원들과 인사하는 시간을 가졌다.
퍼실리테이터분들께서 역량 강화 교육 OT를 휼륭하게 진행해주신 덕분에 조금 어색했던 얼어있던 분위기가 풀릴 수 있었고, 앞으로 기획 개발 교육이 끝난 Week 2
부터는 어떻게 진행이 될 지 협업 툴인 Slack
과 Notion
을 어떻게 사용해야 하는 지 ? 잘 알려주셨고
특히 Notion
에 있어서는 협업 과정에서 사용하게 될 페이지들( 너무 잘 만들어주셨다 ㅠㅠ )을 어떻게 사용하는 지 지도해주신 덕분에 협업 과정에서 문서화가 잘 이루어질 수 있을 것이라는 생각이 들었다.
이 후, 조원들과 점심식사를 같이 하면서 얘기도 하며 어색함도 덜어내고 식사 이 후, 퍼실리테이터분이 부여해주신 Mission(광화문에서 팀원들과 사진 찍기)
을 수행하면서 더 친해질 수 있어서 좋았다.
오후부터는 마지막(?)이 될 자기소개 시간을 가진 후, 팀원들과 앞으로의 Meeting에서 지켜야 할 암묵적인 Rule인 Ground Rule
을 작성하였다.
앞으로 교육에서 진행하게 될 팀 Meeting, 그리고 과제를 수행하기 위해서 Rule을 작성하였고 룰을 지키지 않은 팀원에게 패널티(?)를 부여하는 룰도 추가하였다 ㅋㅋ
다음 주 부터는 진짜 개발 역량 강화 교육이 시작될 것이다.
이번 주 진행한 기획 개발 수업을 통해 "기획"하는 과정에 대해서 많은 것을 배우게 되었고
또한 과제를 진행하면서 조원들과의 의견 충돌도 있었고 하고 싶었던 의견을 속으로 삭힌 적(?) 등등 실무에 협업에 있어 미리 어려움이 있었고 UML 다이어그램 및 IA
를 구축하는 데에 있어 좀 복잡해서 어렵고 머리도 아팠던 것 같다.
학부과정에서도 이러한 다이어그램을 작성해본 적도 있긴 하지만 이렇게 정석적으로 작성해본 적이 없었어서 뜻 깊었다.
나중에 취업을 하게 되어 실무에 나가게 되어서도 서비스를 "기획"하는 부분에 있어서
개발자로서 어떤 자세로 임해야 하는 지 어떻게 의견을 제시하는 것이 좋을 지 이번 수업을 통해서 배우게 되었고, 앞으로는 "기획 및 스케치" 과정을 통해 단계적인 개발 절차를 적용해보려 한다.
유데미 바로가기: https://bit.ly/3SFlXDy
유데미 STARTERS 취업 부트캠프 공식 블로그 보러가기: https://blog.naver.com/udemy-wjtb
💡 본 후기는 유데미-웅진씽크빅 취업 부트캠프 2기 - 프론트엔드&백엔드 과정 학습 일지 리뷰로 작성되었습니다.