[Milestone Week 4(마지막 마무리)] Push Notification/개인정보 관리/로그아웃

push notification을 구현하면서 지금까지 프로젝틀를 하면서 키운 내공들+가치들이 한꺼번에 발휘되었던 것 같다. 
모든 팀원들의 책임감있는 태도에 힘이 났으며,
혼자 할 때는 막막했던 것이 HJ님과 협력하니 내가 몰랐던 부분이 채워지고, 
필요한 기능이 무엇인지 정확하게 파악하고,
그 기능을 구현하기 위해 정확하고 효율적인 질문/검색을 하고,
찾은 해답을 어떻게 내 상황에 맞게 적용할 수 있었다. 
그리고 추가로, 
언제나 답은 '공식 문서'와 '원리 파악'에 있다는 값진 깨달음도 얻었다. 🙂

이제 앞서 [프로젝트 기획 및 준비작업] 마일스톤 정하기, UX/UI 디자인, 컴포넌트 리스트업의 <1. Project관리를 위한 Issue카드 생성 및 마일스톤 정하기>에서 계획한 모든 기능구현은 마무리 되었고, 내가 한 일에 대한 회고 글도 끝이 났다. 

 

자면서도 코딩하는 꿈을 꿔서 어떤 문제를 해결하지 않고는 쉬어도 쉰 것 같지가 않았고, 

오전까지 하겠다고 어제 약속드린 기능을 구현하려고 일어나자마자 노트북을 주섬주섬 켜기도 하고, 

자려고 누웠는데 '아 그거 그렇게 구현하면 무한로딩 될텐데!!' 라는 생각이 드는걸 잊지 않으려고 녹음으로 남겨두기도 했다. ㅋㅋ

팀원분들과 빡!! 집중해서 하루만에 해결해보자!고 마음먹은 이슈는 자주 오프라인으로도 만나면서 더 친해지기도 했다. 

 

시작 할 때만 해도 우리가 이정도까지 할 수 있을지 실감이 잘 나지 않았다. 그리고  약 한달 반 정도를 프로젝트에 푹 빠져서 몰두했던 시간 자체가 너무 행복했다. 

 

아직 AWS도입, .then지옥, 이미지 인식 모델 성능 개선 등의 문제가 남아있어서 프로젝트 이후에도 계속된 리팩토링이 필요하지만 이젠 어떤 태도를 가지고 임해야하는지 알기 때문에 전혀 미리 겁먹거나 주저하지 않는다. 

 

그리고 이 모든게 팀원들 덕분인 것 같아서 2020년 최고의 행운이라고 할 만 큼 감사드린다. 

1. Push Notification

복용 '알람' 서비스인데 Push Notification을 맨 마지막에서야 구현하다니.. 좀 방심했던 감이 없진 않다. 

SH님께서 push 구현을 하려고 자료를 보시다가 쉽지 않을 것 같다는 말씀과 함께 몇개의 reference 자료들을 공유해주셨다. 

 

마음이 급해져서 그 다음날 아침부터 push 알람 공부와 시험버전을 구현하기 시작했다. 

 

먼저 공식문서를 보고 따라해봤다. (expo는 공식문서가 정말 정말 잘 되어있다!)

우선 push 알람 permission을 묻는 창을 띄우고, push 보내기 버튼을 누르면 아래처럼 push 알람이 올 수 있도록 구현하였다. 

그런데 

우리는 유저가 앱에서 버튼 클릭과 같은 이벤트를 발생시키지 않고 앱 환경을 나가서라도 기존에 등록한 알람 날짜&시간이 되면 자동으로 파악하여서 알람을 보내주어야 한다. 여기서부터 머리가 복잡해지기 시작했다. 

 

그럼 어떤 admin이 DB기록을 항상 모니터링하면서 알람 날짜&시간이 되면 push를 보낼 유저를 파악해서 보내야한다는 건데, 그럼 우리에게 admin은 누구인가? 항상 모니터링이 가능은 한가?

 

게다가

이러한 플로우를 가지며 push 알람이 보내지게 되는데, 5번 단계인 '푸쉬 발송 옵션 및 대상 설정(즉, 우리에겐 복용 알람을 보내드릴 유저)'을 하는 Admin이 도대체 무언인가?에서 막혀서 도저히 혼자 힘으로 해결할 수 없을 것 같았다. 그리고 항상 모니터링해주는 서버를 구축하기 위해 Firebase를 사용하기에는 너무 시간이 부족했다. 

그래서 팀원분들께 도움을 요청했고, HJ님과 함께 밤을 꼬박 새며 해답을 찾아나갔다. 

 

먼저 HJ님께서 Admin이 그냥 말 그대로 '사람, 관리자'가 아닐까 라는 의견을 주셨다. 그렇게 push에도

1. 전체 유저 (디바이스)를 대상으로 어떤 일관된 사항(가령 광고나 업데이트 사항.. 등)을 보내주기위해 admin이 필요한 경우가 있고, 

2. 그냥 개인 디바이스 내에서만 이루어지면 되는 것들(즉, 내가 설정한 알람은 내 디바이스에서만 push 알람이 오면 됨)

로 종류가 나뉠 수 있음을 알았다. 

 

우리의 경우 후자에 해당하며 그래서 따로 admin이 필요하지 않는 것이다. 

게다가 expo는 expo 자체의 SDK서버를 제공한다. 그래서 push를 관리하는 server도 자체 구축할 필요가 없다. 

아래의 그림에서 'Your backend'에 해당하는 부분이 우리는 그냥 Client(디바이스)가 된다. 

 

이제 개념과 흐름을 파악했으니 어떻게 구현하면 될지를 알기위해 expo Notifications 공식문서의 메서드의 기능을 하나씩 파악했다. 

그 중 push 알람을 예약하고, 예약한 push를 삭제 할 수 있는 메서드가 있었고 그를 적극 활용해서 push 기능 구현을 마무리 지을 수 있었다. 

 

몸은 힘들었지만 push notification을 구현하면서 지금까지 프로젝틀를 하면서 키운 내공들+가치들이 한꺼번에 발휘되었던 것 같다. 

모든 팀원들의 책임감있는 태도에 힘이 났으며,

혼자 할 때는 막막했던 것이 HJ님과 협력하니 내가 몰랐던 부분이 채워지고, 

필요한 기능이 무엇인지 정확하게 파악하고(문제 정의 능력),

그 기능을 구현하기 위해 정확하고 효율적인 질문/검색을 하고,

찾은 해답을 어떻게 내 상황에 맞게 적용할 수 있었다. 

그리고 추가로, 

언제나 답은 '공식문서'와 '원리파악'에 있다는 값진 깨달음도 얻었다. 🙂

2. 개인정보 관리(Mypage와 개인정보 수정)

우리 서비스는 회원가입 후 DB저장 될 때 바로 핸드폰번호와 비밀번호를 bcrypt를 써서 암호화준다. (관련해서는

[초기 세팅 및 배포] DB Setting을 참고)

한번 암호화를 해준 데이터는 복호화를 할 수 없고 해서도 안된다. 그래서 Mypage, 개인 정보 수정에서 보여줄 수 있는 정보는 이름과 이메일 주소에 한정시켰다. 

그리고 개인 정보 수정도 이름, 전화번호, 비밀번호를 수정 할 수 있지만 전화번호, 비밀번호는 기데이터를 보여줄 수 없기 때문에 비워놓았지만 이를 수정하지 않는다고 해도(즉, 데이터를 입력하지 않고) 변경하기 버튼을 눌렀을 때 빈칸으로 수정되는 것이 아니라 기데이터가 유지된다는 것을 인식시키기 위해 '수정할 정보를 입력하지 않으실 경우 기존의 정보로 유지됩니다.'라는 안내문구를 넣었다. 

 

Frontend 쪽은 할 수록 UX에 대해 더 고민해보는 것 같고, 만약 이 쪽으로 간다면 깊이 공부해봐야할 주제인듯 하다.

3. 로그아웃

웹에서는 로그아웃시 session을 제거해주고 로그인 전 화면으로 redirect시켜주는 API가 필요했다. 그래서 첫 번째 웹 프로젝트인 SAFU에서는 로그아웃 API가 

session.clear()    
return redirect('/')

이렇게 구현되어져있다. 

 

그러나 앱서비스인 약올림에서 로그인을 구현한 로직을 보아 서버통신을 하지 않고 removeItem으로 토큰제거 후, 지금까지 쌓여있던 스택들을 모두 reset하도록 구현하였다.
(reset을 하지 않으면 로그아웃되어있는데도 불구하고 뒤로가기 등을 누르면 자신이 들어갔던 페이지가 보인다. )

 

그래서 로그아웃 버튼 클릭시 실행되는 Client 코드는 

resetAction = StackActions.reset({ #리셋하고
    index: 0,
    actions: [
      NavigationActions.navigate({
        routeName: 'LoginScreen', #로그인 전 페이지인 LoginScreen으로 이동하도록 함
      }),
    ],
  });

  logout = async () => {
    try {
      await removeItem(); #token제거
      this.props.navigation.dispatch(this.resetAction);
    } catch (e) {
      console.log(e);
    }
  };

이와 같다. 

 

이제 앞서 [프로젝트 기획 및 준비작업] 마일스톤 정하기, UX/UI 디자인, 컴포넌트 리스트업의 <1. Project관리를 위한 Issue카드 생성 및 마일스톤 정하기>에서 계획한 모든 기능구현은 마무리 되었고, 내가 한 일에 대한 회고 글도 끝이 났다. 

 

자면서도 코딩하는 꿈을 꿔서 어떤 문제를 해결하지 않고는 쉬어도 쉰 것 같지가 않았고, 

오전까지 하겠다고 어제 약속드린 기능을 구현하려고 일어나자마자 노트북을 주섬주섬 켜기도 하고, 

자려고 누웠는데 '아 그거 그렇게 구현하면 무한로딩 될텐데!!' 라는 생각이 드는걸 내일 잊지 않으려고 녹음으로 남겨두기도 했다. ㅋㅋ

팀원분들과 빡!! 집중해서 하루만에 해결해보자!고 마음먹은 이슈는 자주 오프라인으로도 만나면서 더 친해지기도 했다. 

 

시작 할 때만 해도 우리가 이정도까지 할 수 있을지 실감이 잘 나지 않았다. 그리고  약 한달 반 정도를 프로젝트에 푹 빠져서 몰두했던 시간 자체가 너무 행복했다. 

 

아직 AWS도입, .then지옥, 이미지 인식 모델 성능 개선 등의 문제가 남아있어서 프로젝트 이후에도 계속된 리팩토링이 필요하지만 이젠 어떤 태도를 가지고 임해야하는지 알기 때문에 전혀 미리 겁먹거나 주저하지 않는다. 

 

그리고 이 모든게 팀원들 덕분인 것 같아서 2020년 최고의 행운이라고 할 만 큼 감사드린다.