업무 정리 및 회고 (2)

기업체 관리자 페이지 수정

DB TABLE 내에 업체코드가 존재하는 회사인 경우, WebID 나타내는 칼럼 추가하여 보여주도록 페이지 수정

목적 : 큐알코드로 회원가입 하는 사람들의 아이디를 각 기업체 매니저들이 확인하기위한 기능

 

아이디 입력 란에 기능 추가 (javascript)

아이디 입력란에 다음과 같이 동작하도록 기능 추가

1. 공백제거 : trip()을 통한 공백 제거
2. 한글 입력 막기 : javascript function 호출을 통해 정규식으로 영문자, 숫자만 허용하기

 

포인트 선물 내역 페이지 검색 Bugfix

저번주에 개발한 포인트 선물 내역 페이지에서 사번 검색이 정상적으로 동작하지 않는 오류 발견했음. Mapper 내에 query를 확인하니 사번에 대한 column을 잘못 입력했음. empId가 아닌 empNo인 column으로 검색해야 했는데 이름이 비슷하여 착각함. 

 

뿌리오 문자 서비스 API 연동

키오스크 내에서 회원가입을 하는 경우 다이렉트 센드 업체를 이용하여 문자 인증번호를 받도록 로직이 구성되어 있었다. 하지만 최근에 다이렉트 센드 업체의 서버가 여러 번 다운 되어, 회원가입을 하려는 고객들이 인증번호를 받지 못하는 상황이 발생하였다.

인증번호를 받지 못해 회원가입을 못하게 되는 경우를 대비하여, 에러 발생 시 다이렉트 센드 업체에서 뿌리오 업체로 switch할 수 있도록 뿌리오 문자 서비스 API를 연동할 수 있도록 기능 개발 및 기존 로직을 수정했음.

 

<업무 순서>

비교적 복잡한 업무라고 생각해서 미리 업무 프로세스를 다음과 같이 정의하고 시작했다.

 

1. 기존에 사용중인 다이렉트 센드 SMS 서비스 로직 관련 소스코드 분석 (sendSmsMobilePhoneConfirmNumber())
2. 뿌리오 문자 서비스 API 문서 참고 (예제 코드 참고)
3. 개발
4. switch 구현 (Setting 관련 TABLE 이용, ENUM 활용)
5. 테스트
   1. 해당 TABLE에서 deviceId 확인
   2. Notion에서 기존 API 명세서 확인
   3. PostMan에서 API Test
6. 서버 배포
7.  실서버 테스트

 

<새롭게 알게 된 점>

 

1. 기존에 다이렉트 센드의 문자 서비스 API가 연동이 되어있을 때는 URLConnection을 이용해서 API를 호출하였다. 해당 코드를 참고하여 뿌리오의 API를 연동하려 했는데, 사수 분이 RestTemplate Class를 이용하여 API 호출하는 것을 제안했다. 두 방식 사이에 어떤 차이가 있고 장단점은 무엇인 지 궁금했다. 관련해서 공부하여 포스팅할 예정이다. 어찌됐든 많은 시행착오 끝에 (원인 모를 에러 때문에 무한 삽질했다...... 생각만해도 끔찍하다) 기존의 방식에서 RestTemplate을 이용해 API 호출에 성공했다. 뿌듯뿌듯

 

 

2. 필요한 경우에 switch를 해주어야 했는데, 어떤 방식으로 구현할 지 감이 잡히지 않았다. 단순히 if 문 사용해서 500 Error 뜨면 뿌리오로 다시 문자를 보내주는 방식을 하기엔 오버헤드가 너무 컸다. 한 번 다이렉트 센드에서 에러가 나면 한동안은 계속 뜰텐데 그렇게 되면 문자를 한 번 전송하는데 latency가 매우 길 거라고 생각했다. 그래서 사수 분께 여쭤봤고 새롭게 알게된 점은 다음과 같다.

 

Switch가 필요할 때 직접 클라이언트 코드를 수정하면 좋은 코드가 아니라고 한다. DB 내에 TABLE을 살펴보니 SYSTEM_SETTING TABLE이 존재했다. 설정과 관련된 테이블인데, 이 것을 이용하기로 했다. 먼저, settingId값과 settingValue 값에 row를 추가하고 상위 클래스 (CommonService 같은 super class)에서 메소드를 만든 후 필요할 때 query로 불러온다. 이런 식으로 구현하면 코드를 수정하지 않고 DB Table 내에서 settingValue만 update 해주면 쉽게 switch 할 수 있다. 꿀팁!

 

 

3. 2에서 말했듯이, 상위 클래스에서 메소드를 만들어 settingId에 해당하는 value를 가져온다고 했다. 자주 사용하는 메소드는 상위 클래스에다가 만들어서 필요한 경우 쉽게 메소드를 사용할 수 있도록 자바의 다형성을 이용하면 좋을 것 같다. 설계할 때 정해놓고 메소드를 만든다기 보다는 필요한 경우 메소드를 만드는데 자주 사용할 것 같다? 그럼 상위 클래스에다가 메소드 만들기!

 

그 외 

• 각각의 프로젝트마다 스타일이 다르겠지만 여기 회사에서는 다음과 같이 코드가 구성되어 있다. core module에서 package로 domain, exception, template을 각각 만들어 관리해준다. 기능 개발을 하다가 domain class가 필요한 경우 core의 domain에다가 class를 정의하고 이 곳에서 가져온다. exception과 template도 마찬가지인데, 이렇게 구성하니 공통적으로 사용하는 class를 관리하기가 쉬워져서 앞으로 적극 활용하면 좋을 것 같다는 생각을 했다.
• Domain package에서 Class를 생성할 때 field값 마다 모두 null을 넣어주었다. 예측하건대, NullPointerException 방지 및 따로 Dto를 만들지 않고 소분해서 이용할 수 있도록 하는 용도인 듯 하다. 지금까지 사이드 프로젝트 할 때 이런 경우에는 무조건 Dto를 따로 만들어서 받아왔는데 그렇지 않은 경우도 있음을 알게 되었다.

 

Retrospective

• 검색 기능 구현할 때 어떤 칼럼을 사용하여 검색해야 하는 지 정확하게 파악하기. 이름 비슷하다고 막 사용하면 안됨!
• 외부 서비스를 연동하는 경우, 외부 서비스의 서버가 항상 정상적으로 동작할 거라고 생각하면 안됨. 외부 서비스를 무조건적으로 신뢰하는 것이 아니라 해당 외부 서버 다운 되는 경우도 고려해서 예외처리 잘 해놓기! 추가로 불안정한 상황이 자주 발생하면 대체할 수 있는 외부 서비스를 이용하던가 혹은 문제 발생 시 다른 업체로 Switch 될 수 있도록 구현하기.
• 자꾸 백업 DB랑 운영 DB랑 헷갈려서 테스트 한다. 실제 운영 DB에는 있는 row가 백업 DB에는 존재하지 않는 경우가 많아 필요하지 않은 삽질을 하여 시간을 낭비했다. 내가 지금 어떤 console 내에서 작업하는 지 파악하는 것은 필수인 것 같다.

 

 

 

To Study List

• URLConnection, RestTemplate 차이점 및 RestTemplate을 이용한 API 호출
• 깃 명령어 stash 공부