2019년 회고

1. 지원동기

 

  2019년에는 뱅킹시스템을 구축중이었는데  실제로 사용하는 코드를 코딩을 해보고 싶어

  내가 직접 지원하여 KG이니시스 차세대 PG 승인 시스템 구축 프로젝트에 들어갔다.

  세미나를 하는 것보다, 코딩이 하고싶어서 지원했다. 개인적으로 세미나보다 코딩이 더 장기기억에 많이 남는것 같다.

 

2. 기간  

 

2019.12~2020.01

6개월 개발, 6개월을 단위테스트, 통합테스트, 운영테스트 모니터링을 하였다

 

3. 개발한 서비스

• PROXY(취소, 부분취소, OID취소, SID취소)
• 빌게이트 (빌키 발급, 빌링 승인, 빌키 조회, 망 취소)
  • 신용카드 빌링
  • 휴대폰 빌링
• 기관 망 취소 배치(승인, 취소, 부분취소), 가맹점 망취소 배치(ACK)
  • 포인트
    • OK캐쉬백, GS포인트, U포인트, 엘포인트
  • 상품권
    • 문화상품권, 도서문화 상품권, 해피머니 상품권, 스마트 문화 상품권
  • 휴대폰
    • 다날, 모빌리언스
  • 신용카드
  • ISP
  • 계좌이체
  • 알리페이
  • 페이팔
  • 뱅크월렛
  • 제로페이
• 테스트 MID 자동취소 배치
• 신용카드 TVPAY 채널 거래
• 인터파크 KMPS 수신
• CONFIRMD
• 신용카드 취소
• ISP 취소
• BIZ 취소 노티 공통

4. 배운것

 

  1) 언어

   

    C언어를 이해하지 못하면 JAVA인 차세대로 전환이 불가능하기 때문에 C언어를 공부하고, 테스트할 일이 많았다.

    C언어와 자바의 차이점과 객체지향 프로그래밍을 통한 효율적인 설계등을 해보며 재미를 느꼈다.

    간단한 디자인 패턴을 업무에 적용해 봄으로써 효율적인 서비스 설계를 할 수 있는 능력을 많이 기를 수 있었다.

   

    C언어와 JAVA에 대한 이해도도 많이 높일 수 있었던 좋은 경험이 되었던 것 같다.

    

  2) 협업

   

    인터페이스팀과 협업을 많이한 경험도 소중한 경험이라고 생각한다. 수많은 기관과 대외통신을 많이 하는 경험은

    흔치 않기 때문이다. 전문을 만들고 정합성을 유지해야하는 부분은 힘들었지만 통신이 정상적으로 되는 과정에

    기여하는 것은 신선하고 재미있었다. 인터페이스 제품을 직접 활용하여 개발을 하진 못해봤지만,

    협업을 하며 이론으로만 공부했던 네트워크에 대한 지식을 직접 체험해 보는 기분이 들었다.    

 

    고객에게 개발과 관련된 이슈, 업무에 관련된 이슈, 차세대 설계변경에 따른 이슈 등 다양한 이슈에 관하여

    소통하고 해결해 나가면서 의사소통 능력을 키우는 값진 경험을 할 수 있었다.

    나는 개발단계부터 참여해서 잘 몰랐지만 초기에 설계된 것들이 업무를 이해하지 못한 채 작성된 잘못된 설계가

    많았다. 고객과 직접 협의하여 업무도 재설계해 보았고, 서비스 설계도 바꾸어 보았다.

    일반적으로 PL급이 할만한 일을 직접 하였기 때문에 재미있었다.

    

    무엇보다 고객을 어떻게 이용해야 개발과 테스트를 빠르게 완료할 수 있는지에 대한 노하우를 점점 쌓아간 것 같다.

 

  3) 도메인 지식

   

    전체 거래의 80%정도를 차지하는 신용카드, ISP 승인, 취소를 다뤄보았다.

    ISP 취소는 내담당이 아니었지만, 내가 한 신용카드 취소와 비슷한 부분이 많아 내가 급하게 맡게 되었다...

    신용카드 승인은 담당자가 실거래 반영하는 시기에 해외여행을 가서 그주는 매일 2시넘어서 퇴근한거 같다.

    제로페이와 토스페이는 버그가 많아서 승인 테스트 결과서 문서작성만 30개 이상한것 같다.

    안그래도 할게 넘쳐났는데.. 나말고 업무대행을 할 수 있는 사람이 없었다ㅜ

   

    망취소를 배치를 테스트하며 전 지불수단을 다 파악해야하는 곤혹을 치뤘다.

    승인거래나, 취소거래의 원장의 정합성이 안맞으면 망취소가 실패하기 때문이다.

    신기하게 DB 정합성이 안맞는 이런 심각한 경우에도 승인이나 취소가 기관 정상통신을 하는 경우가 매우 많다.

    이런 경우 개발하는 입장에서 거래를 취소하기가 매우 귀찮아지는데..

    이건 PG 승인 시스템의 전반적인 개선 사항이라고 생각한다.

    망취소 배치를 개발하면서 망취소가 존재하는 모든 지불수단 업무를 대부분 다 파악할 수 있었다.

 

    막상 프로젝트를 할때는 도메인 지식이 의사소통만 되는 거지 별거 아니라고 생각했는데,

    신입을 가르치면서 도메인 지식이 있으면 개발을 할때 훨씬 디테일한 부분까지 고려할 수 있다는 것을 깨달았다.

    새로운 업무나 연관업무도 훨씬 빠르게 이해할 수 있고 더 효율적으로 설계가 가능하다.

 

  3) 기타

   

    1) 문서 작성능력

      테스트기간에 테스트 뿐만아니라 수백건의 테스트문서를 직접 작성했기 때문에 엑셀과 친해졌다.

      QA 버그 리포팅 시스템이 없는게 아쉬웠지만.. 어쩔수 없었다..

    2) 유틸 프로그램 개발

      ① 실거래 전문로그를 요청전문으로 만드는 프로그램 개발

        · PG에서 당연히 있을거라 생각한 이런 전문 변환 프로그램이 없었다. 그래서 java로 개발해서 사용했다.

        → 인터페이스 팀에서 유용하게 사용하였다.

      ② C to JAVA 전문 매핑 자동 변환 코드 개발

        · 매핑되는 변수만 설정해놓으면 sprintf를 set, printf를 get함수로 변환하는 프로그램을 개발했다.

         공통적으로 사용하긴 각 지불수단 담당자들의 메타매핑 작업을 하는게 무리가 있어 이건 그냥 혼자 썼다.

      ③ NPE등 exception으로 원장에 정상적으로 데이터가 입력되지 않는 경우

       (개발중이나 테스트중에는 일어나지만 실거래에서는 절대 일어나지 않는 케이스)

       다른 테이블의 의존관계를 이용하여 데이터가 insert되지 않는 테이블에

       데이터를 넣는 서비스를 호출하는 프로그램을 개발하여 개발 효율성을 증진시켰다.

      

 

5. 아쉬웠던 점

   

   - 자바는 c처럼 메모리 제어가 불가능한데 DBIO를 제어하는 Data Object를 최대한 리펙토링 하지 못한 점이 아쉽다.

    → 시간관계상 하지못했다. 레거시 구조체를 그대로 Data Object로 사용하였다.

   

   - 망취소 배치를 DB처리를 더 효율적으로 설계하고 싶었는데, 그러려면 각 지불수단 원장 제어방식을 바꿔야했다.

     차세대 서비스 정상동작 여부를 확인하는 요소중 하나가 원장이기도 하고 내가 바꿀 권하도 없어서 못한게 아쉽다.

   

   - 서비스가 보통 팩토리 패턴으로 구현되어 서비스가 호출될때마다 필요한 객체가 생성되는 방식이었는데,

     동일한 기능을 하는 객체는 싱글톤으로 구현하여 메모리를 더 효율적으로 사용했으면 좋겠다고 생각했다.

   

   - 서비스마다 context를 유지하고 있는데, 이 컨텍스트를 callee 서비스에 인계를 하는 등

     더 효율적으로 제어하도록 프레임웍 소스를 고치고 싶었는데 이것도 시간이 부족해서 못함

   

   - 서비스 제어 프레임웍 equal함수 compareto 등이 override가 안되어 있어서 불편한점 개선 못함

   

   - 인터페이스 제품을 사용하지 못해봤다.. 시간만 있었어도..

 

6. 한풀이

 

  그냥 주관적으로 판단했을때 내가 일이 제일 많았던 것 같다.

  프로젝트 마지막쯤엔 10명이 운영배포하는데 내 배포가 전체의 1/4 쯤 되었던거 같다.

  개발은 먼저 개발을 하고 있던 사람들이 승인을 가져갔고,

  난 6개월 늦게 들어와서 취소관련된 것들을 할당받았는데.

  먼저 개발하던 팀장포함 4명은 연봉협상, 팀내 갈등 등의 원인으로 프로젝트 중간에 나갔다.

   TVPAY거래등은 인계받은것도 아니었지만, 인계자보다 내가 더많이 알아서 그냥 내가 했다.