다시보는 <디즈니 플러스(Disney+)>의 Flow_코드스테이츠 PMB 11기| W7D4

 오늘의 과제는 W6D1 회고이다. 매주 금요일에 하던 회고를 뺏긴 기분이기도 하고, 과제로 회고를 수행한다니 뭔가 다른 느낌이기도 하다. 모듈 3에 진입한 지 벌써 2주째. 처음 발을 들였던 6주 차 첫 째날과 2주가 지난 시점의 지금은 뭐가 달라졌을까? 스스로 느끼기에는 잘 모르겠지만, 오늘의 과제를 수행하며 다시 한번 돌아보고자 한다.

W6D1 회고

<디즈니 플러스(Disney+)>의 Flow 탐색 (light ver.)_코드스테이츠 PMB 11기| W6D1

 이번 과제를 수행하기 위해서 동기분들과 스터디(아닌 스터디)를 통해 같이 논의해보고 인사이트를 얻었다. 물론 자기 자신을 스스로 돌아보는 것도 중요하지만, 다른 분들이 바라본 나의 과제에 대한 시선도 중요하지 않을까?! 요즘 글 읽기 싫어 병에 걸려서 그런지.. 글도 잘 안 읽히지만 내가 내 과제를 다시 보는 것도 힘들다. 그리고 아무래도 아직은 아는 게 그다지 없다 보니 자기 객관화도 부족할 것 같은 느낌? 그래서 동기분들의 힘을 빌렸다! 두 영역의 의견이 모두 담기길 바라며, 6주 차의 첫날 과제에 대한 회고 시작-!

Flow Chart

 

위의 Flow chart는 디즈니 플러스 앱에 접근한 후, 영화를 재생하기까지의 여정을 간단히 표현했다. 아직은 뭣도 배운 것도 없고(?) 그저 뇌피셜일 뿐이지만, 큼직한 flow는 담겼지 않을까😀
Flow는 위에서 아래로 진행되는 것이 기본이며, 노란색 마름모 부분은 '조건'이나 '선택'에 관련된 부분을 표현했다. 타 서비스/프로덕트의 경우 마지막이 결제나 종료로 끝나겠지만, 위의 Flow에서는 영상 재생을 끝으로 flow를 종료했다.
 디즈니플러스로 국한시키긴 했지만, 아마 위의 Flow의 큰 틀은 타 OTT도 비슷한 형태를 가지지 않을까 생각한다. 결국 OTT의 목적은 "영상 감상"이기에, 과연... Flow에서 차별성이 나타날 수 있을까?라는 의문도 든다.

다시 보기

 당시에는 유저가 앱에 접근해서 영화를 감상하기까지의 전체 flow를 작성했다. 물론 많이 생략하고 간결하게 작성했지만, 오늘 과제를 통해 이 process를 좀 더 잘라서, 특정 부분에 집중해서 자세히 살펴보고자 한다. 

 내가 다시 볼 영역은 <유저가 Application에 접속한 후 메인 화면을 만나기>까지의 영역이다. 기존의 Flow chart 공식에 맞춰 좀 더 formal 하게(?) 작성해 보자면 아래와 같다. 

 지난번에는 유저에게 보이는 부분을 위주로, 많은 생략을 거쳐 매우 단순하게 표현했다면, 오늘의 Flow chart는 나름 뒷얘기(?)를 함께 표현했다. 보이지 않는 DB나 알고리즘과 같은 백엔드 부분을 함께 나타내니... 좀 더 복잡해 보인다. 사실 이것 또한 많이 생략된 표현이다. 실제 개발 과정에는 매우 복잡한 알고리즘과 요청과 출력이 발생하기에... 그 부분은 제외하고, 나름 표면적인? 큼직한 부분만 나타내 보았다. 

 유저가 App에 접속하면, App은 로고 애니메이션을 보여준 뒤 해당 유저의 IP를 기반으로 로그인 이력이 있는지 조회한다. 만약 로그인 이력이 존재한다면 자동 로그인을, 그렇지 않다면 회원가입이 되어 있는지를 유저에게 묻는다. (로그인 창 등장!) 유저가 회원가입이 되어 있는 기존 유저라면 ID와 PW를 입력하고, App은 이를 회원정보 DB와 비교하여 일치하는지를 확인한다. 유저의 입력 데이터(ID, PW)가 일치하지 않는다면 Error 메시지를 띄운 뒤 다시 ID, PW를 입력하는 화면으로 돌아가고, 일치한다면 로그인 처리를 진행해 계정 내 프로필을 선택하는 화면을 띄운다. 

 유저가 원하는 프로필을 선택하면, 해당 프로필이 잠금(PIN 번호)이 되어 있는지 확인하고, 잠금이 없다면 바로 메인 홈을, 그렇지 않다면 PIN을 입력하는 창을 노출시킨다. 유저가 입력한 PIN을 회원정보(or PIN) DB의 정보와 비교해 일치하지 않는다면 다시 PIN 입력 화면을, 일치한다면 메인 홈을 나타낸다.

UI vs. Client vs. Server vs. DB

App 접속 시 메인 화면

 먼저 유저가 디바이스에서 (1) App을 눌러 접근하면, UI는 기본 세팅값인 '로고 애니메이션'을 송출하면서 (2) Client에게 User의 접근을 알린다. 접근을 감지한 Client는 Server에 해당 디바이스의 IP를 기준으로 (3) 회원정보 확인을 요청하고 Server는 (4) DB에 해당 회원의 정보 자체를 요청한다. DB는 Server의 요청에 따라 (5) 회원정보를 출력하여 Server로 전송하고, Server는 (6) 회원을 확인하여 Client에게 알린다. 사전에 입력된 회원가입 유무와 로그인 설정값(ex. 자동 로그인) 등의 모든 조건을 만족하면, Client는 UI에 (7) 메인 홈을 송출하고, 유저는 이 UI를 통해 (8) 메인 화면을 보게 된다. 

 

작품 감상

 앞의 단계에서 유저가 메인 홈을 통해 여러 Action을 수행한 후 보고 싶은 작품을 선택했다. 바로 위의 이미지는 유저가 선택한 영상을 재생할 때의 프로세스를 그린 것이다. 

 유저가 작품 홈에서 (1) 재생 버튼을 누르면, Client는 (2) 재생 CTA(버튼)의 활성화 신호를 감지한다. 신호를 감지한 후 (3) Server에 영상을 요청하고, Server는 (4) DB에게 해당 영상 파일을 호출한다. DB에 저장되어 있던 (5) 영상 파일 정보가 Server로 전송되며, Server는 DB에게 이 정보를 받아 (6) Client에게 영상을 출력한다. Client는 이를 유저에게 보여주기 위해 (7) UI를 통해 화면(영상)을 송출하고, 유저는 UI를 통해 (8) 영상(작품)을 감상할 수 있다.

다시 보기

 당시에 글을 적을 때도 고민이 많았던 부분은 바로 "UI"이다. UI는 Client의 얼굴과 같은 영역이라 별다른 신호를 주고 보내는(?) 장치가 아니다. 하지만 과제에서 제시한 관계에 UI가 포함되어 있기에.... 이번 과제에서도 많이 고민했다. 혼자 고민 고민을 하다! 해당 부분에 대한 고민을 동기님들과 나누고 조언을 얻어 기존의 도안을 수정했다.

App 접속 시 메인 홈

  유저가 (1) App에 접속하면 (2) Client는 Server에 회원 확인을 요청하고, (3) Server는 DB에 회원 정보를 요청한다. (아마 해당 과정에서 유저의 디바이스(모바일, PC 등)의 IP 주소를 활용해서 회원정보를 요청할 것이라 예상한다.) (4) DB는 요청받은 회원정보를 출력하고, (5) Server는 이를 대조하여 Client에 회원 확인과 관련된 응답을 전송한다. 만약 유저가 기존에 가입한 회원이고, 해당 IP에서 로그인한 이력이 있다면 (6) Client는 유저에게 메인 홈을 송출한다.

 앞서 언급했던 Flow chart와 같은 과정에 대해 다뤘지만, 복잡하면서도 간단해 보이는...? 그런 절차이다. 물론 모든 예외 상황과 error 발생 가능성을 배제하고, 스무스한 상황만을 가정해서 그럴 수도 있다:)

 

---

오늘의 과제는 작성 시간보다 고민의 시간이 더 길었던 것 같다. 회고 날이 아닌데 지난 과제를 다시 보려니... (우욱)ㅋㅋㅋ 다시 과제를 바라보기 위해 오랜 시간과 노력을 쏟았달까...^^ 대체 뭘 바꿔야 하지?라는 고민을 혼자 오래 했지만, 이에 도움을 주신 동기님들, 정말 최고이시다👍 6주 차 첫째 날에 불러냈던 너굴맨은 바로 동기님들^^

 2주 동안 배웠던 내용을 다 쏟진 않았지만, 해당 부분에 대해서는 어느 정도 적용해 본 기분이랄까...? 자세하게 API 등을 다루기엔... 너무 무궁무진하다^^ 만약 회원가입 절차를 다뤘다면 API를 자세히 살펴볼 수 있었겠지만(과거의 나, 진짜 칭찬해!!!) 너무 아쉽다🤣🤣🤣 오늘의 과제는 여기까지! 끝!

fin.