알림앱 유지보수 경험..

알림앱의 서버 유지보수를 맡았던 적이 있었다. 앱은 놔두고 서버만 딱 담당하는 게 말이 되는지 모르겠으나, 어차피 앱은 해본 적도 없었고 해당 업무로 들어가게 되었다. 앱은 입출금, 전자고지 등이 있을 때 알림 기능이 주인 앱이었고 구조는 다음과 같았다.

 

 

용어가 맞나 모르겠는데, 사용자와 직접 접하는 채널계의 앱이었고... 이 앱은 하이브리드 앱이었기 때문에 JSP 소스를 전달받았다[A]. 알림 앱이었지만 받은 소스 안에는 알림 관련 소스는 없었다(처음엔 뭔가 싶었다). 당연하게도 회원만 알림 수신이 가능했기에, 앱에는 가입, 서비스 신청(그에 대한 알림 수신) 기능이 있었다. 서비스 신청을 한 경우, 알림을 위한 FCM 토큰이 저장되었다[B]. 이후 계정계에서 입출금이 일어나면, 메세징 시스템을 거쳐 Push 솔루션에서 솔루션 DB의 APP_ID, 알림 DB의 Token을 참고해 알림을 보내는 구조였다(정확친 않지만 대충 내 머릿속에선..). 그래서 이에 대한 몇 가지 기본적인 정기적 업무가 있었다.

 

1. 서비스 해지한 적 없는데 알림이 안 온다는 민원 업무가 간혹 있었다.

2. 채널계 업무였기에, 전자고지가 매달 있었는데 화면 수정 요청이 있었다.

 

1의 경우 DB에서 회원인지 회원이라면 서비스 신청을 했는지, 즉 Token이 존재하는지 확인하면 될 것 같지만 쉽지 않았다. 앱의 입출금 알림 기능이 타앱으로 이관되면서 알림 서비스 신청 상태가 계정계 DB에서 관리되었고, 계정계 DB의 조회 권한은 없었기 때문이다. 민원 요청이 오면 나도 계정계 DB 조회 요청을 해야 하는 번거로운 상황이었다. 발송 성공/대기/실패 등 상태는 솔루션 DB에서 관리하고 있었는데, 따로 확인하기가 쉽지 않은 상황이었다.

 

2의 경우도 화면 수정 후 반영만 하면 끝나는 건 아니었다. 대외계에서 보내준 테스트 데이터가 채널계쪽으로 들어오면 안드로이드 애뮬레이터로 제대로 반영되었는지 확인해보는 것까지가 끝이었다. 사실 테스트 데이터가 들어왔을 때 알림이 와야 하는데, 애뮬레이터[C]의 경우 내부망 환경이라 FCM 알림을 위해선 외부망 환경이 필요했다. 반쪽짜리 화면에서 화면 테스트만 한 셈이었던..

 

이런 업무의 경험이 있었는데, 앱 자체가 있으니 담당자를 배정해놓은 건 그렇다 해도... 메세징 시스템의 한 부분이어서 테스트도 쉽지 않았고, 계정계나 앱 담당자가 따로 있었던 것도 그렇고... 내가 부족하기도 했지만... 애초에 이 포지션으로 사람을 왜 뽑았는지 지금 생각해도 좀 의아하긴 하다.

 

------

A. 사실 네이티브, 하이브리드 이런 걸 잘 몰랐고 지금도 그렇긴 한데.. JSP로 작업하고 웹뷰로 띄워준다 정도, 알게 되었다. 공부의 필요성이...

B. 채널계에 앱 DB에 저장되었다. IOS도 FCM이었던가..

C. 알림앱 APK 파일을 받아 PC(내부망) 애뮬레이터에 설치한 후 확인하는 식으로 진행했다.