Flow Chart를 Technical Flow Chart로 승진시켜보자 (W7D4)

과제 ) W6D1 데일리 과제 회고하기

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

PM의 코멘트 : 지난 W6D1과제의 회고입니다. W6D1 과제를 복사하여 그 아래에 관련 내용들을 과제를 진행합니다. (이전 과제에 덧붙여넣기나 원본이 수정되지 않도록 합니다)

W6D1 과제에서 추가적인 내용을 작성하였는가?

W6D1 과제에서 추가한 내용에 충분한 근거를 제시하였는가?

본인이 느낀 점을 이전 강의를 바탕으로 충분히 설명하였는가?

⊙ 과제의 핵심 용어(또는 이론)

API
OPEN API
SERVER DB UI CLIENT

오늘 과제는 약 2주 전에 했던 과제를 그간 배웠던 내용을 토대로 보충해보는 것이다.

---

오늘 다룰 Product

2023.01.16 - [PM 부트캠프(22.12.12~23.03.15)/과제] - Sleep Tracker의 데이터 구조가 어떻게 작동할지 짧은 고객 행동으로 추정해보자 (W6D1)

오늘 과제는 개발 지식을 제대로 배우기 전에 선행하여 작성했던 과제를 보완해보는 것이다.

나는 수면 트래커라는 수면 관리 어플을 다뤘었다.
수면의 질을 파악하여 숙면을 돕고 상쾌한 기상을 하게 하는 앱이다. 수면 패턴을 분석, 품질을 평가하여 통계와 분석을 해준다. 더 많은 내용은 해당 링크를 확인해주시라.

선정 사유는 생략한다.

---

| Flow Chart

원본에서 API와 메소드 부분 추가하였음.
UI, 클라이언트, 서버, DB로 구분하였음.

⊙ 원본

원래 과제에서 데이터 수집 근거를 적어놨었는데 부가적인 요소라서 이번 과제에 옮기지 않는다. 해당 이미지에서 기록한 데이터는 개인정보정책을 참고하였다.

원래 과제에서는 2가지 행동으로 플로우 차트를 그렸는데, 작동 구조는 한가지로만 판단했기 때문에 이번 과제에서도 한 가지 흐름만 다룬다.

아래 행동에 대한 플로우 차트를 그려보았다.
◆ 데이터를 백업하는 행위: (최초 1회) 구글 계정을 연동, 동기화 새로고침


[요지]
1. 데이터 동기화 할 때, 구글 계정의 정보를 앱 서버에 저장하고, 로컬 장치에 있는 수면 시간 등의 정보를 앱 서버에 전달
2. 일반 실행 시, 수면 시간과 노이즈 데시벨 로그를 로컬 장치에 저장하여 수면 패턴 분석

⊙ 보충한 flow chart

추가한 내용과 그 이유

1. 구글 클라우드에 백업하는 기능과 구글 계정을 연동하는 것, 구글 계정이 자동 로그인되는 것은 OPEN를 사용하여 타사의 서비스에 접근하는 대표적인 사례임
2. 유저의 행동과 UI, 클라이언트(로컬)이 요청하면 앱 서버와 자체 DB이 처리하고 응답해준다고 배웠기에 작동 과정을 추가하여 구분하였음
3. 지금 보니 이미지 만들 때 실수한 거 같은데 클라이언트에서 백업 전 계정 정보를 재확인할 때는 GET(데이터 조회) 메소드를 쓰고 앱 서버에서 구글 API로 백업을 요청할 때 POST(데이터 생성) 메소드를 쓸 것이다.
4. 마찬가지로 최초 로그인할 때(연동할 때) 구글 서버는 구글 DB에 데이터 조회(GET)를 요청할 것이다. 회원 정보가 일치하는지 확인하고 나서는 구글 로그인 API(구글 서버)는 카톡 로그인 API와 마찬가지로 회원정보에 접근해도 된다는 허가서 같은 개념인 토큰을 발급할 것이다. 즉 앱 서버에서 구글 로그인 API에게 POST 메소드로 요청했기 때문이다.
5. 오가는 데이터는 우선 DB 부분에만 표시하였다.

---

| UI, 클라이언트, 서버, DB 간 작동 분석

⊙ 분석글 원본

client (고객 스마트폰)에 저장된 수면 정보

1. client(고객 스마트폰)에 사용 데이터가 저장되어 있음

• 오디오 녹음 
- 소음 데시벨 로그, 오디오 클립
• 취침 및 기상 시간
• 통계 및 분석 데이터
• 수면 메모
• 그 외 설정값(asmr 생성 등)

2. client에서 앱 서버로 일부 데이터를 전송

• 새로고침 일자와 시간
• 소음 데시벨 로그
• 취침 및 기상 시간
• 통계 및 분석 데이터, 수면 메모, 그 외 설정값도 함께 저장되는지는 정확한 확인 필요
• ※ 최종 수정일이 언제인지 모르는 앱 내부 개인정보처리방침에서는 위에 두 가지만 저장된다고 표시되어 있음.

3. 앱 서버에서 데이터 베이스로 데이터를 전송
5. 데이터 베이스가 앱 서버로 '새로고침 일자와 시간' 정보를 반환
6. 앱 서버가 '새로고침 일자와 시간' 를 ui에 띄우라고 명령
7. 데이터가 다시 client로 이동
8. client가 '새로고침 일자와 시간' 데이터를 출력하여 ui에 마지막 동기화 시간이 현재로 수정되어 표시됨


다른 액션일 때, 최초 로그인할 때는 제3자인 구글에서 여러 정보(이름, 이메일 주소, 연락처 목록 등 이미 연결된 데이터)를 전달받아서 데이터베이스에 고유값으로 넣고 그중에 이메일 주소만 빼내어 클라이언트에 전달, ui로 표현하는 과정이 추가될 듯하다.


[요약]
UI ─ 버튼 클릭 → Client ─ 내 수면 정보와 현재 시간 → app Server ─ 야 저장해! → Database ─ ㅇㅋ 했음. 현재 시간→ app Server ─ 현재 시간 표시해! → Client ─ ㅇㅋ 했음 →UI

⊙ 보충한 작동 관계

1. client(고객 스마트폰)에 사용 데이터가 저장되어 있음
2. 유저가 백업 버튼을 누름 
3. client에서 앱 서버로 내 요청 사항을 전달. GET(데이터 조회) 메소드 
4. 앱 서버가 최초 로그인인지 자동 로그인 상태인지 판단하기 위해 DB에 정보를 요청함 
5. 앱 DB는 회원 데이터를 조회한 결과를 앱 서버로 보냄 
6. 앱 서버는 결과를 토대로 API 행선지를 결정 
   1. 최초 로그인: 구글 로그인 API (GET 메소드)  - 구글 클라우드 API (POST 메소드)
   2. 자동 로그인: 클라우드 API (POST 메소드)
7. API 서버가 준 정보를 앱 서버가 데이터 베이스로 전달
8. DB가 갱신 기록, 연동 정보를 저장하고 앱 서버로 '새로고침 일자와 시간'과 '구글 이메일' 정보를 반환 
9. 앱 서버가  '새로고침 일자와 시간'과 '구글 이메일'를 ui에 띄우라고 클라이언트에게 응답  
10. 클라이언트가 새로운 데이터로 수정된 화면을 다시 출력함
11. ui에 마지막 동기화 시간이 현재로 수정되어 표시됨 
12. 유저 만족

---

⊙ 느낀 점

API를 추가한 게 가장 큰 발전 포인트 같다. 약 2주 전에 과제할 때는 어림잡지도 못한 지점이다. API를 개발자분한테 들은 적은 있었는데 작동과정에 넣는다는 건 생각을 못했지. 왜냐면 나는 어리바리 전사이기 때문이다.
그리고 일반 플로우와 다르게 테크니컬 플로우를 그릴 때는 백엔드와 프론트 4가지 파트를 중심으로 나누는 게 효과적임을 배웠다. 왜냐면 이 네 가지는 물 밑에서 엄청 열심히 움직이기 때문이다.
내가 내 눈에 보이는 버튼을 똑 누르면, 그 짧은 시간에 내 깜찍한 휴대폰이 버튼이 의미하는 바를 앱 서버에 전달한다. 버튼이 내포하는 의미는 다양하겠다. 새로고침을 하겠다고 하면 DB에서 새로 업데이트된 정보를 토대로 수정한 화면을 구성하여 브라우저를 그려줄 것이고 자바 스크립트로 만들어진 버튼을 클릭했다면 별다른 로딩 없이 그 행동을 해줄 것이다. 다른 예를 들면 검색바에 입력한 키워드를 검색하는 게 있겠는데 이런 경우는 키워드를 토대로 클라이언트가 조회 요청을 한다. 서버는 이를 받아서 적절한 파일을 DB한테 뜯어다가 클라이언트한테 갖다바친다. 브런치에 '명예인간 시험'을 검색하면 해당 키워드가 본문과 제목 텍스트 파일 안에 포함된 글을 조회하여 (기획자가 설정한 정책이자 백엔드가 코드로 재현한) 정렬 기준에 따라 나열해줄 것이다. 아무튼 이해는 좀 된 거 같은데 정확한지 잘 모르겠다. 누군가한테 내가 잘 이해했는지 확인 받으면 좋겠구나~
잘 이해했는지 점검하려면 누군가한테 설명할 수 있어야 하므로 자꾸자꾸 생각해보면 좋을듯 하다. 직접 차트를 그리진 않아도 행동 단위마다 데이터가 어떻게 이동할지, 어떤 API를 활용할 것 같고 어떻게 작동할지 머릿속으로 계속 그려보는 훈련을 하면 좋겠다는 생각이 들었다. 내가 다룬 행동은 ui 화면이 안 바뀌다보니 프론트가 어떻게 작동할런지 생각할 필요가 없었다. 작동 과정을 상상할 때 출력이랑 ui 구조까지 포함해서 프론트 부분도 같이 생각하면 좋을듯 하다.
나중에 확인할 때는 개발자한테 물어보면 된다. 인터넷 세상에는 답답한 논리는 가만 안놔두는 개발자분들이 분명 많이 살고 있을 거라 믿는다. 왜냐면 내가 상상하는 개발자 사고체계?는 구조적으로 이루어져 있기 때문이다. 나같은 문과 성향 사람은 흐릿한 스펙트럼에 다양한 의미를 붙여서 사고해서 인문학이나 철학이 그나마 잘맞았는데, 코딩 언어 자체가 체계적이고 구조적인 특징을 갖고 있어서 이에 흥미를 잘 붙이거나 쉽게 내재화하는 사람은 사고체계가 그와 닮아있지 않겠는가? 그렇기 때문에 나같은 사람들이 '어 그런가? 그것도 일리가 있지.'라고 반응할 때 개발자분들은 이미 검증된 논리 체계에 어긋나는 포인트를 탐탁치 않게 여기지 않을까 하고 망상을 해보았다. 아닌가? 이건 사고 구조의 문제가 아니라 아이디어에 얼마나 개방적인지와 수용성 성향과 관련이 더 많나? 일단 나의 경우는 가치 진보성, 수용성, 타인에 대한 신뢰도가 높아서 잘 속는다. 이런 근거 불충분한 추측을 개발자분들이 보면 엄벌을 내리겠지? ㅎㅎ 하지만 나는 개발자 두뇌 안에 들어갔다 나와본 적 없으니 모를 수도 있지 않은가? 벌을 내릴 거면 땡벌을 내려주길 바란다.



요지는 이렇다.

• API를 추가한 게 핵심적으로 성장한 포인트
• 기술 중심으로 흐름을 그릴 땐 UI, 로컬, 서버, DB로 나누어서 작동 과정을 파악해야 하는구나
• 작동과정을 머릿속으로 자꾸자꾸 그려보자

---

여담

뭥가 많이 이상함 어떻게 고쳐야 하지?

• 구글 API 클라우드 API 찾아보고 정확하게 쓰기
• 양측 화살표랑 글자 넣어서 깔끔하게 만들기
• 데이터 이동 제대로 표시
• 깃허브랑 제이슨 개념을 넣을 필요가 있나? 제이슨은 넣으면 좋을 거 같다 이런 데이터가 이런 형식으로 이동한다고.
• 그리고?

Technical Flow Chart 검색
예전에 잡은 범위가 작아서 보완할만큼 될까 고민했다... 하루조각으로 바꿔야 하나... 했는데 그냥 했다.

현업에서는 전문적이고 복잡한 대화가 오가는구나 하고 느꼈습니다. 이렇게 실제 서비스에 영향을 끼치는 버그인 경우 빠른 판단이 중요한데 많은 사례를 조사해보고 목록화하면 경험 부족이 어느정도 커버되지 않을까 하는 생각이 들었어요.
그럼 작동과정도 그려보고 목록화도 해야되는거겟지? 이렇게 자습할 거리 늘어나고요?

클라이언트에서 바로 API로 가던가 서버에서 가던가... 당연히 서버에서 가겠지??
백업은 PUT (수정)이 아니겟지 하나씩 주는 거니까? 이거는 API 문ㅅ 보면 해결되는 부분이고...

어떤 게 ssr 출력 쓰고 어떤 것이 csr 출력 쓸랑가?

근데 이 앱 유저 데이터 수집하는건가 당연히 수집하겠지 아하

최근에 백업한 정보, 갱신 데이터를 DB가 처리해서 주는 것 같은데 API DB가 처리해주는 거겠지?? 앱 서버는 그냥 갱신날짜를 받기만 하는거가? 갱신 언제언제 했는지 기록을 하는 거면 앱 DB로 보내서 POST 처리한 다음에 주는 건가? 기록이 안되는 거면 이전 데이터에 덮어쓰기 하는 거니까 그럼 PUT인가...? 아니면 그냥 DB를 안거치는 것 맞나?
아니 근데 이메일 정보를 반환하니까 DB 쓰는 거 아닌가?

소셜 계정으로 서비스 회원가입을 유도하는 경우에는 DB에 회원 정보가 고유값으로 저장되는 건 알겠어. 근데 이 경우는 단순 백업만 하는 것 같은데 DB에 저장하나? 소셜 계정으로 가입하겠다는 것과 단순 로그인은 다른가? 이메일은 반환해주는데 이것까지 포함해서 클라우드 API 안에 있는 로그인 기능일 뿐인가? 아니 어렵네 참.....

답변 해주시면 감사하겠습니다!! 부족한 점은 무엇인가요? 어떻게 고치는 게 좋을까요?

앱 내 로그인이 없다면 자동로그인인지 최초로그인인지 확인할 때 앱 DB를 거치지 않는다고 보면 될까요? 그럼 앱 서버에서 바로 API로 이동해주나요? 로그인되어있는지 아닌지 여부는 구글 로그인 API가 판단해주는 걸까요? 아니면 로컬에서 그런 정보도 받을 수 있나요?
이 경우는 앱 DB가 쓰일까요?
작은 글씨로 된 질문이 API 문서 보는 즉시 해결되는 부분이라면 큰 질문만 답변해주셔도 괜찮습니다!

---

분석 참고 글

---

W7D4 [코드스테이츠 PMB 16기] 과제
'데이터 구조 작동 추정' 보충