직무 설명

롯데 정보 통신, “카드IS 부서” 소속 선임 롯데 카드, 지원 파트의 업무 공통 (팀단위) UMS 담당 선임

1. 알림 및 마케팅, 캠페인과 관련된 messaging system 레거시를 하나로 통합하는 프로젝트를 담당했습니다.
   1. “CMS”에서 넘어오는 캠페인 및 홍보 데이터 메시징 처리, “승인계” 쪽에서 넘어오는 결제 관련 데이터 메시징 처리, “채널계” 에서 넘어오는 push 및 알림 데이터 메시징 처리, 현업이 사용하는 “단말” 쪽에서 발송하는 단순 메시징, 그리고 admin에서 바로 가능한 메시징 처리의 레거시를 모두 UMS를 통해 client가 해당 정보를 받게 하는 프로젝트였습니다.
   2. 기본적인 솔루션은 SI 업체와 계약을 해서 뼈대는 있었지만 기존 레거시 시스템에 통합과 지속적인 코드 수정, unit test, QA가 필요했습니다.
2. 레거시 batch들의 수행 모니터링 및 이슈 핸들링 (java - DevOn 프레임워크 활용)
   1. 일간, 월간 배치들 데일리 보고서 작성, 전문 확인 작업
3. 신규 프로젝트를 위한 신규 batch 작업 (java - DevOn 프레임워크 활용)
   1. 인사 시스템에서 신규 입사자 정보 전문으로 받아, 단말에 회원 등록, 일간 배치 작업

본인이 기여한 점

1. UMS, 발송 관련 table, index 추가 세팅, query 최적화 발송 속도 상승
2. 신규 배치 작업으로 신규 입사자 단말 자동 회원가입 처리

어려웠던 점

1. 신규 배치 작업과 관련 코어 뱅킹 시스템에 대한 이해
   1. 큰 규모의 데이터를 기반하는 배치 작업을 대상으로 하는 작업을 처음하여, 어떻게 프로세스를 도는지 과정에 대한 이해가 어려웠었습니다. Control-m(솔루션)에서 프로세스를 관장하고 EzJOBs라는 연동된 웹 솔루션으로 쉽게 배치 관련 데이터를 처리할 수 있게 되어 있었습니다. 배치의 시간, 선-후행, 전문(파일) 그리고 진행 상태값 에 대한 큰 규모에서의 이해를 할 바탕으로 신규 배치를 등록할 수 있었습니다.
   2. 크게 배치작업과 서비스 작업으로 나뉘는 금융권 IT에서, 서비스는 DevOn 이라는 프레임 워크를 활용했습니다. 다양한 곳 (MCI, 대외계, EAI 등)이 인터페이스를 통해 전문(데이터)을 교환하고 DevOn에서 다양한 흐름제어, 거래제어, 비즈니스 로직 처리를 통해 진행하는 큰 그림을 보고, 코어 뱅킹에 대한 이해도를 조금 더 높일 수 있었습니다.
2. 메시징 시스템 및 인프라에 대한 이해
   1. 기존에 하셨던 분들이 퇴사하고, 신규 업무 단위이며, 주 담당자가 신입인 제가 맡게 되어서 책임감이 무거웠었습니다.
   2. 발송을 요구하는 데이터들이 내부, 대외, 채널계 등의 아주 다양한 곳에서 인터페이스를 통해 넘어와 해당 데이터를 처리하는 과정에 대해, 어떻게 처리를 해야 하는지 레거시부터 이해가 필요했습니다.
   3. 메시지 발송은 배치와 실시간(서비스) 성격 모두 가지고 있었기 때문에 위 (1) 코어 뱅킹에 대한 기본적인 이해도 필요했었습니다.
   4. 발송 되는 채널이 Email, XMS(SMS, LMS, MMS), RCS, Kakao talk(채널톡, 친구톡), push 알림 과 같이 다양한 채널이 존재 했고, 각 채널마다 필요한 데이터 셋 형태와 룰을 따라야 했기 때문에, 각 채널이 요구하는 특성에 대해 이해 할 필요가 있었습니다.
   5. 해당 신규 프로젝트에 심도 있는 이해가 필요 했었기 때문에, 외주 팀 (연구원)과 매일 전화 및 대면을 하여 코워킹을 했습니다.
   6. 크게 java, spring 기반으로 [ 전문 탐지 - watcher ] ←→ DBMS ←→ MQ (Rabbit MQ) ←→ 비즈니스 로직 처리 ←→ LDCC(통신사와 연결된 본사) / push 서버 ←→ (실패시) MQ (Rabbit MQ) 의 구조를 가지고 있는 것을 이해하고, unit 단위 테스트 부터 현업의 문의 대응을 순차적으로 처리하며 어려운 점을 해결할 수 있었습니다. (세부 로깅이나 DB단 처리는 생략했습니다.)
3. push 알림 시스템에 대한 이해
   1. “앱 알림은 앱에서 보내야 하는 것이 아닌가?” 가 처음 push 알림 시스템에 대한 이해였습니다.
   2. FCM, APNs와 같은 push 알림 서버의 용도와 존재 이유를 깨닫고 위 의문을 지울 수 있었습니다. “마케팅 성격이 강한 알림은 이렇게 분리해서 작업하는 게 바른 접근방법”이라는 것도 깨달을 수 있었습니다.
   3. push 알림 서버는 또 다양한 마케팅에 대한 대응이 필요했습니다. 마케팅(캠페인)에 “누구” 에게를 정의할 때, 특정 앱버전, 특정 기기 등에 대한 정보와 “데이터 무손실” 에 대한 최소한의 보장과 “추적 가능한 로깅” 과 같이 다양한 부가 시스템에 필요하다는 것을 알 수 있었습니다.

결과