User Story

서비스를 개발할때 가장 먼저 해야하는게 '사용자가 경험할 서비스'를 구체적으로 상상하는 것이라고 생각했다. 그래서 우리는 이를 User Story라 이름짓고, 이를 우선적으로 결정하기로 했다.
(사실은 User Story도 안정해놓고 서비스 구조 생각하다가 1주정도의 시간을 갖다 버리고 다시 돌아온거에요...)

[그림1. Figma를 이용해 작성한 wire-frame]

wire-frame이란 서비스의 골격 레이아웃을 간단하게 시각화한 것인데, 우리는 이를 Figma라는 웹 기반 툴을 이용해 그려보았다.

영상 업로드가 안되서 아쉬운데, Figma를 사용하면 저 화살표 이어진것 끼리 레이아웃 슬라이딩을 해서 프로토타입으로도 구현 가능하다. 이거 굉장히 편하다. 못올려서 아쉽네...

대략 결정한 User Story들

개발할 단계에 따라
1단계. 영상 전송/ 화면공유 /아바타 투영 등 온라인 강의 플랫폼의 가장 기본 기능
2단계. 가상 강의실에 몰입할 수 있는 컨텐츠
3단계. Security 솔루션
이렇게 단계를 나눠 User Story를 결정하려 노력했다.

// 1단계. 영상 전송 / 화면공유/ 아바타 투영
1단계에서 user스토리 ( infra )
- 학생입장
	ㄱ. 내 아바타와 다른 사람의 아바타가 강의실에 잘 배치되어 있으면 좋겠다
	ㄴ. 교사의 비디오와 오디오가 나에게 잘 전달되면 좋겠다

"As a student, 
I need the virtual classroom where I interact with other students 
as an avatar that represents my emotion captured from my facial expression."

"As a studnet,
I need real-time audio/video of the class sent over,
so that I can participate in the class and feel like being in the actual classroom."


- 교사입장
	ㄱ. 강의실에 학생들의 아바타가 잘 보이면 좋겠다
	ㄴ. 내 비디오와 오디오가 학생 모두에게 잘 전달되면 좋겠다.

"As a teacher,
I need to see the students' statuses at once, so that I can feel the atmostphere of the classroom."

"As a teacher,
I need to push my video and audio to the students with little latency, so that I can teach my students."

// 2단계. 가상 강의실에 몰입할 수 있는 컨텐츠
2단계에서 user스토리 ( contents )
- 학생입장
	ㄱ. 내 아바타를 내가 직접 움직일 수 있으면 좋겠다
	ㄴ. 다른사람의 아바타와 대화할 수 있으면 좋겠다 (chat)

"As a student, 
I need a controll system to move my own avatar"

"As a student, 
I need to communicate with others so that I can feel like being contact with them"

// 3단계. Security 솔루션
3단계에서 user스토리 ( Identification )
- 교사입장
	ㄱ. 학생들의 아바타가 실제 본인과 매칭되는지 확인할 수 있으면 좋겠다
    
"As a teacher, 
I need to confirm whether an avatar is real owner of it or not
so that I can believe this online classroom platform"

- 학생입장
	ㄱ. 얼굴인식을 통해 빠르고 간편한 신원확인이 이루어지면 좋겠다

"As a student, 
I need a convenient and fast Authorization system
so that I can be in virtual classroom wo\ any annoying"

기술 스택

경험 없는 학부생팀의 장점이자 단점이있는데, 단점은 어떤 기술이 필요하는지 감을 잡을 수 없다는 것이었고, 장점은 어차피 할 줄 아는게 없었기 때문에 어떤 기술을 골라도 똑같다는 것... 이었다.

그럼에도 불구하고! 기본적으로 정해봤던건
1. 웹 기반, 크로스 플랫폼으로 개발하자 - 온라인 강의를 컴퓨터로만 듣지는 않을테니깐
2. 서버, 클라이언트 통신은 '웹소켓'을 이용하자 - 강의실을 업데이트 하는데 http만으로는 너무 느리다
3. 웹캠 영상/ 공유화면/ 오디오 전송은 webRTC를 이용한 P2P통신을 이용하자 - webRTC가 써보고 싶은 팀원이 있다 (진짜로 이런 이유였다)

위 세 가지를 원칙으로 하고, 서버 개발/클라이언트 개발은 개발 인원 각자 원하는 스택을 사용하기로 했다

난 Back-End

이렇게 전체적인 아이디어를 구체화 한 후, 난 애초에 맡기로 했던 백엔드 어플리케이션을 개발하기로 했다. 이에 관한 이야기는 다음 포스팅에 하도록 하겠다