[Sprint 4]회원관련 기능/push 기능 구현(Week7)

실제 코드 구현 기간: 12/14~12/22

 

가장 기본적인 회원 관련 기능을 가장 마지막 Sprint로 뺀 이유는, 해당 기능은 first project에서 이미 구현했으므로, 비교적 빨리 구현할 수 있을 것이라 생각했기 때문이다. 즉 가장 중요하고 어려운 기능부터 구현하자는 생각에 메인 기능 -> 회원 관련 기능으로 진행했다. 

 

프로젝트 Sprint 4주차

4주차의 주요 이슈사항은 기능적으로는 회원관련 기능/ push 였고, 실질적으로 프로젝트 발표 이전의 마지막 시기였으므로 최대한 완성도를 높여야 하는 점이었다.

 

1. [Server] 회원 관련 기능
   -> 암호화 (flask bycrypt)
   -> 비밀번호 찾을 시에 임시 비밀번호 등록된 메일로 발송해주기
2. [Client] Expo push 기능 구현
3. 에러 alert 추가
4. 에러핸들링 / 리팩토링 고민 

 

ToDo 1. 회원관련 기능 구현

 

**회원관련 기능

회원 관련 기능 자체는 다른 기능들에 비해서 코드를 짜는 것에 있어서 크게 어렵지 않았다.

해당 기능에서 가장 메인은 1. 암호화 2. 임시비밀번호 메일로 보내주기 였다.

 

암호화와 관련해서는 flask의 라이브러리를 설치해서 사용하면 매우 간단하게 사용할 수 있다.

그러나 bycrpt 와 bycrypt.generate, 두 개의 메소드 구조는 완전히 다르므로, 실제 사용에 있어서 혼용하면 안된다. 

 

flask의 라이브러리로 데이터 암호화 하기(블로그 정리글)

 

암호화의 경우, 개인정보보호로 인해 매우 중요한 사항이다. 그리고 암호화해서 저장한 데이터는 다시 복호화해서 볼 수 없다. 

그렇다면 로그인 시에 비밀번호 번호 일치 여부는 어떻게 파악하는 것일까? 이는 복호화와는 별개로 암호화 관련된 라이브러리에서 제공하는 기능을 활용하여 일치 여부를 체크하는 것이다.

 

이로 인해 비밀번호 찾기 기능을 쓸 경우 일반적으로 비밀번호 변경 링크를 보내주거나, 임시 비밀번호를 등록된 메일로 보내주는 것이다.

우리는 임시 비밀번호를 등록된 메일로 보내주도록 했다.

해당 기능을 위해 flask-mail 라이브러리를 활용했다. first project 때는 node mail 기능을 썼고 이 때는 금방 해결했는데 flask-mail은 좀 더 시간이 걸렸던 것 같다.

 

기본적으로 보내려는 사람 구글 계정에 접속해야 하기 때문에, 사용할 수 있는 구글 계정을 만들어두거나 보안 적으로 조치를 취하는 것이 좋다. 이에 대해서도 차후에 블로그에 정리할 예정이다.

 

ToDo 2. Push 기능 구현

 

마지막 남은 복병이었다. 카메라 연동/ 이미지 데이터 처리/ 캘린더 화면 구현 등 어려운 것은 이미 해결했다고 생각했는데, 프로젝트 마감을 고작 몇 일 앞두고 제일 중요한 Push 기능을 구현하지 못했던 것이다. 

 

기능적으로 자세한 부분은 블로그에서 다룰 예정이다.

 

expo에 물론 push 기능에 대한 라이브러리도 존재하고, 이에 대한 블로그들도 존재하긴 했었다. 그러나 그 과정자체가 너무 복잡했다. 

push를 관리해주는 push 서버가 필요했고, 이를 또 만들어줄 수 없기 때문에 파이어 베이스나 AWS 람다 같이 이미 만들어둔 서버리스 서비스를 사용해야 했고(이를 위해선 또 공부가 필요했다.) , 어드민도 필요했다.

 

push 기능이 우리 프로젝트에서 가장 메인 기능 중에 하나였으므로, 포기할 수 없다고 생각했고, 현정님과 둘이서 밤을 새서 push 기능에 대해서 공부하고 기능 구현을 고민했다. 

처음에는 기본적인 공식문서와 블로그 글을 이해하는 것 부터 시작했던 것 같다. 

그러다 보면서 느낀 것이 어드민이라는 것이 진짜 그 관리자 페이지인 어드민을 의미하는 것이 아닐까? 하는 생각이 들기 시작했고, 

이 push가 우리가 구현하고자는 push 기능과는 조금 차이가 있다고 느꼈다.

그래서 expo push의 다양한 메소드를 살펴보았고, schedules~ 관련한 메소드로서, trigger 하여 시간을 걸어둔 다음 예약 발송할 수 있는 기능이 있음을 발견했다.

 

결론적으로 우려했던바와 달리 별도의 서버 구성/ 어드민없이 기능을 구현할 수 있었다.

push는 크게 두가지 기능이 있었는데,

1. 우리가 흔히 마케팅 푸시를 받는 그 push와

2. 별도의 관리자에 의한 변경없이 순수하게 예약 한 바를 디바이스 알려주는 알람과 같은 push 기능이 있던 것이다. 

일반적으로 push를 사용할 때, 그리고 블로그에 정리한 것은 전자를 위함 이었던 것이었다.

후자의 기능에 대해서는 정리가 잘 된 블로그를 찾을 수가 없어서, 공식문서를 분석하면서 하나하나 필요한 부분들을 구현하고 디버그 하는 과정이 오래 걸렸다. 

 

확실히 기본적으로 어떤 기능을 구현하기 위해서는, 우리가 원하는 기능이 무엇인지를 정확히 파악하고, 그다음에 사용하는 언어와 제공하는 라이브러리에 대한 공식문서를 꼼꼼하게 읽어야 함을 느꼈다. 만약에 우리가 무턱대고 (좀 더 편하기 위해서) 블로그 글들을 우선으로 봤다면 기능 구현은 하지 못한 채 헛바퀴만 돌렸을 수도 있겠다 느꼈다. 

 

ToDo 3. 에러 핸들링 / 에러 alert 추가

 

Push 기능을 구현하고 난 이후에는, 새로운 기능을 구현하기 보다는 기존 기능들의 완성도를 높이는 것에 집중하면서 발표 자료를 준비했다. 그 과정에서 어떠한 경우에 서비스에 에러가 발생한다면, 웹앱의 경우는 새로고침이 있지만 아직 우리의 모바일 서비스에는 새로고침 기능을 추가하지 못했고(모바일 앱은 새로고침 기능 또한 별도로 넣어주어야 하는 것이 신기했다.) 만약 에러가 어쩌다 나면 앱을 나갔다 들어오는 수밖에 없었다.

 

마지막 단계에서 발생하는 에러들은 보통 새로고침을 통해서 통신을 다시 해주면 해결 되었다. (transaction 처리로 인해서 가상 데이터나 중복 데이터가 잘못 저장되는 일은 없었고, 에러가 나면 API 자체가 rollback 되어서 다시 실행해 주어야 했다.)

고민하다가 일반적으로, 모바일 앱을 사용하면, 에러 발생시에 다시 시도해 달라는 alert가 기본적으로 있었던 것이 떠올랐고,  우선은 해당 기능으로 에러에 대한 추가적인 조치를 하기로 하였다.