[회고]개발 역량을 가진 PM이 되자! Nike Run Club의 흐름 분석(Flowchart, 작동 과정)

1. 지난 2주동안 (W6, W7) 강의를 바탕으로 본인이 선택한 프로덕트에서 유저가 할 수 있는 행동에 대한 Flow Chart를 간단하게 만들어 봅시다. (Technical Flow Chart 검색 시 다양한 플로우차트 작성 방법이 나옵니다)
2. 지난 2주동안 (W6, W7) 강의를 바탕으로 본인이 선택한 프로덕트의 UI, 클라이언트, 서버, DB가 각각 어떻게 보이고 작동할지 예상하여 적어 봅시다.

이번 과제는 이전의 W6D1 과제를 2주동안 배운 개념을 토대로 회고하면서 부족하거나 잘못된 부분을 개선하는 것이다. 저 과제를 작성했을 때가 그렇게 오래 되지 않은 것 같은데 시간이 참 빠르다는 생각이 든다.. 사담은 그만하고 과제를 살펴보자.

 

회고하면서 이전 과제의 원본을 수정하지 말라는 요구사항이 있었기에, 기존 과제에서 보충할 부분만 보라색으로 색인을 표시하여 대비될 수 있도록 하였으니 비교하면서 과제를 읽으면 좋을 것 같다.

---

오늘 데일리 과제에서 선정한 프로덕트는 내가 예전에 한창 러닝에 빠졌을 때 자주 사용했던 애플리케이션인 'Nike Run Club'이다. 핸드폰의 GPS를 추적하여 러닝 중 오디오로 가이드 메시지 제공, 월별 챌린지, 사용자의 입맛에 맞게 원하는 거리를 설정하는 맞춤형 챌린지, 코칭 플랜 등 다양한 방식으로 동기 부여를 제공하여 러닝에 도움을 주는 서비스이다. 부트캠프에 탑승한 지 벌써 6주 차인데 하루 종일 컴퓨터 앞에 앉아있으면서 지내니 몸도 뻐근하고, 날도 풀린 겸 러닝을 재개해야겠다고 생각하여 과제하면서 의지를 다지기 위해서 선정하게 되었다. 

빨리 와라 나의 브룩스 !! ㅜㅜ

1. 프로덕트에서 유저가 할 수 있는 행동에 대한 Flow Chart를 간단하게 만들어 봅시다.

나이키 런 클럽에서는 러닝 기록 외에도 다양한 기능을 제공하지만 '러닝 기록'이 앱을 사용하는 가장 주요한 이유이므로 사용자가 애플리케이션을 실행하여 러닝을 기록하는 행동에 대한 플로우 차트를 작성해 보았다.

[after]

기존 플로우차트에 클라이언트와 서버가 어떤 액션을 취하는지 파악하기 위해서 색을 입히고, 이전 플로우 차트에서는 사용자의 행동이 변화할 때마다 러닝 리포트를 제공한다는 점을 반영하지 않아 중간에 추가하였다.

서버는 클라이언트의 요청 사항에 응답하는 결과(앱을 실행할 때 자동 로그인으로 설정, 사용자가 로그인하여 기본 메인 화면인 '러닝' 메뉴 출력, 러닝 중의 실시간 러닝 리포트, 일시 정지 및 정지 시의 러닝 리포트)를 보여준다.

클라이언트는 서버에게 유저가 이러한 행동을 했으니 그에 맞는 결과를 보여달라는 요청을 한다.

2. 프로덕트의 UI, 클라이언트, 서버, DB가 각각 어떻게 보이고 작동할지 예상하여 적어 봅시다.

https://yeo0.github.io/pg/2018/10/25/%EC%9B%B9-%EC%84%9C%EB%B2%84-%EC%A2%85%EB%A5%98/

위 그림은 프로그램의 동작 방식을 그림으로 간단하게 표현한 것이다. 나이키 런 클럽이 어떻게 보이고 작동하는지 알아보자.

 

1) UI

러닝 종료 메시지는 과제 당시에 실시간으로 러닝 리포트를 만들 수 없어 예전의 좋은 기록 이미지로 대신했다.

2) 클라이언트

클라이언트는 서버와 연결된 단말기와, 단말기에서 이용하는 웹에 접근하는 소프트웨어를 지칭한다. 우리가 이용할 수 있는 애플리케이션도 클라이언트에 해당한다고 볼 수 있겠다. 주로 사용자의 입력을 처리하고, 서버에 요청을 보내는 일을 한다.

 

나이키 런 클럽 앱에서의 클라이언트는 사용자에게 위의 UI를 바탕으로 러닝에 대한 정보를 제공하고, 사용자가 러닝 시작 액션을 취하면 추후에 있을 러닝 리포트를 위해 러닝이 종료될 때 까지 기록을 서버에 계속 전송한다. 서버는 전송받은 기록 정보를 데이터베이스를 거쳐 처리한 뒤에 클라이언트에게 실시간으로 킬로미터, 평균 페이스, 시간, 칼로리, 고도, BPM 정보를 반환하고, 클라이언트는 이를 시각적으로 사용자에게 보여준다.

 

3) 서버

서버는 웹 서버와 웹 애플리케이션 서버(WAS)로 다시 분류할 수 있는데,

웹 서버는 웹 페이지, 사이트 또는 앱을 저장하는 프로그램을 말한다. 클라이언트에서 요청한 메시지를 확인하고, 데이터를 처리한 뒤에 다시 클라이언트에게 응답하는 일을 한다.

웹 애플리케이션 서버는 사용자 장치에 웹 애플리케이션을 수행하는 미들웨어를 말한다. 서버가 클라이언트에게 메시지를 받았을 때 요청에 필요한 데이터베이스 연동이나 페이지 로직을 위해 WAS에 요청하고, WAS는 데이터베이스에서 데이터를 받아오고 처리하고, 페이지 처리를 수행한다. 이는 다시 서버에게 반환된다.

 

나이키 런 클럽 앱에서의 서버는 클라이언트가 리포트를 위해서 요청하는 기록 메시지를 확인하고, 이를 데이터베이스에 처리를 요청하여 실시간으로 처리되는 러닝 정보를 클라이언트에게 응답하는 일을 한다. 

 

3) 데이터베이스

데이터베이스는 말 그대로 데이터의 정보를 저장하는 곳이다. WAS의 데이터 요청에 필요한 데이터를 찾아 응답하는 일을 한다.

 

나이키 런 클럽 앱에서는 사용자의 러닝 데이터와 리포트를 보관하고, 평균 페이스, 시간, 소모 칼로리, 고도 상승, 케이던스 등의 정확한 리포트를 생성하기 위해서 서버의 요청에 맞게 데이터를 연동하여 실시간으로 반영하는 일을 한다.

 

뭔가 써보니까 다 말이 거기서 거기인 것 같은데.. 정리하자면

1. 클라이언트가 러닝 기록 정보를 서버에 보내 러닝 실시간 정보와 리포트를 요청하고,

2. 웹 서버는 클라이언트에게 받은 러닝 기록 정보를 WAS에게 보내 WAS는 데이터베이스가 요청에 응답할 수 있도록 데이터를 처리하여 보내고,

3. 데이터베이스는 이를 처리한 결과를 WAS에 반환하고 WAS는 이를 서버가 클라이언트에게 전할 수 있도록 정보를 정제하여 웹 서버에 반환하고

4. 최종적으로 웹 서버가 요청 사항에 응답하여 클라이언트가 사용자에게 킬로미터, 평균 페이스, 시간, 칼로리, 고도, BPM 정보를 실시간으로 반환하고 러닝 종료 시의 최종 러닝 리포트를 보여주는 구조라고 볼 수 있겠다.

 

정리하면서도 뭔가 계속 빙빙 도는 이느낌.. 다음주에는 해결할 수 있겠지.. 괜히 러닝 앱을 골라가지고.. 실시간으로 변화하는 데이터가 어떻게 처리되는지는 한번도 생각해 본적이 없는데.. 나는 과연 컴퓨터공학과가 맞는가? 자질이 의심된다. 더 더 열심히 공부해야겠다.

---

[after]

각 장치간 흐름에 대한 설명은 크게 수정할 점은 없다고 생각되나(내가 바보기 때문에), 일단 나이키 런 클럽은 애플리케이션이기 때문에 서버 명칭을 웹이 아닌 '앱'으로 바꿔야 하겠다. 그리고 실시간으로 변화되는 데이터가 어떻게 처리되는지에 대해 정확하게 알지 못했는데, 이 부분은 API 개념을 공부하면서 API가 서버와 데이터베이스의 출입구 역할을 하고, 앱과 기기가 원활하게 데이터를 주고받을 수 있는 통신을 지원한다는 역할을 한다는 것을 알게 되었고, 따라서 나이키의 자체 API를 사용하지 않을까? 라는 생각을 하게 되었다. (관련 api가 있나 검색해봤는데 이전에 나이키 developer 페이지가 있었으나 지금은 접속되지 않았고, 나이키 런 클럽에 관해 공개된 api에 관한 정보를 찾을 수는 없었다.) 확실하지는 않지만 나이키의 자체적인 API를 통해 데이터를 처리하고, 이 때 데이터의 형식은 JSON으로 이루어졌다는 설명을 추가하겠다. 또한, 사용자의 러닝 경로를 GPS 기반으로 시각화한 데이터를 포함한 러닝 리포트를 보여주기 위해 기기의 자원을 적극 활용하므로, 나이키 런 클럽은 앱의 4 가지 유형 중 '네이티브 앱'에 해당한다는 설명을 보충할 수 있겠다.

 

[코드스테이츠 PMB 11기_W7D4]