관리자 풀스택 Migration 및 기능 개발일기
[서비스 환경]
1. native app , web view
2. aws cloud server
3. Jenkins
유저 api, 관리자 api, 채팅 api, 프로모션 모듈별 api, 배치 api, databridge view 등등 사용별로 나눈 api 프로젝트를 유지
server는 spring framework restful API 기반
manager server는 spring framework 기반의 thymeleaf -> jsp 로 마이그레이션
[마이그레이션 및 자동화 사유]
1. 기존 서비스는 돌아가는 상황에서 당장 관리자 기능이 필요했고
레퍼런스가 제일 많았던 jsp로 선택 (빠른 개발을 위해)
2. 대부분의 문제점을 수동 DB 업데이트를 통해 cs를 해결하고 있던 상황(개발자들이 개발 이외에 공수를 소비)
3. 속도 측면에서 별 차이가 없었고 빠른 copy&paste가 가능한 소스이기 때문
[오픈소스 및 API 활용]
Kakao Maps API는 가이드가 굉장히 잘 짜여져있다.
1일 300,000회까지 무료로 서칭이 되는 점은 트래픽이 높지 않은 부분(관리자 웹 영역)에서 무료 그대로 사용할 수 있다는 점도 좋았다. (네이버나 구글 역시 무료로 제공되는 트래픽 횟수가 있는 것으로 알고 있다)
이런 레퍼런스가 많음에도 불구하고 비슷한 API를 다뤄본 적이 없어서 그런지 시간을 꽤 잡아먹었다.
일괄 지급/회수의 경우 난해한 부분이 몇가지 있었다.
우선 단순 count만 하는 경우에도 시간을 꽤 잡아먹었는데 지금 생각해보면 이건 소스나 쿼리로 해결한다기보다는 indexing이 훨씬 큰 영향을 미치는 것 같다.
Indexing을 제대로 잡고(이는 기획, 정책, 개발이 제대로 잡힌 상태여야 한다고 나는 생각한다) 해당 컬럼을 쿼리로 조합한다면 고작 10만건 정도를 가지고 퍼포먼스 타령을 할 이유가 없지싶다.
스타트업이 DBA를 따로 가지긴 쉽지 않은 구조이다보니 CTO나 팀장급에서 혹은 실무진(과장,대리)이 설계도 같이 하는 경우가 대부분인 것으로 알고있다.
게다가 스타트업+서비스 특성상 덕지덕지 붙는 경우까지 감안한다면 수 초 이내에 쿼리 결과가 나오는게 어찌보면 용한 거 같기도하다...
웹페이지 권한의 경우 기존 프로젝트를 가져다 썼기 때문에 직접 구현하지는 않았지만 해당 프로젝트에 맞게 수정할 정도로는 파악을 해놓았다.
preHandler와 postHandler를 통한 페이지별 권한 체크를 하고 관련 권한 부여 페이지를 통해 부서/팀/유닛 별로 나누어 rwx(x = a) 권한을 부여할 수 있도록 구성했다.
log는 crud에 관한 모든 내역을 히스토리에 저장하는 방식으로 되어 있으며, 추후 필터를 통해 조절이 가능하도록 하면 좋을 것 같다는 생각을 했다.
이것 역시 카카오 Maps 레퍼런스를 활용한 기능으로 각 클라이언트에서 정해진 시간마다 위도와 경도를 받아 DB에 적재하고 이를 화면 상에 그려주었다.
IOS는 예전부터 그랬지만 Android도 최근에 정책이 바뀌어서 사용자의 정보를 수집하는 것에 대해 엄격해져 해당 디바이스의 위도와 경도를 받기 위해서는 받는 순간 사용자가 알아야하며 받기 위한 사전 동의 역시 필요하다고 한다.
기존 카카오의 레퍼런스가 잘되어 있어서 특별한 스킬을 요구하지는 않았고, 기존의 예시 소스에 우리가 가지고 있는 위도, 경도를 API에서 받아 Marker로 표시하는 부분을 추가하고 디자이너를 통해 받은 이미지로 마커 이미지를 교체하는 작업 정도를 진행했다.
좀 더 디테일한 커스텀을 하기 위해서는 관련 문서를 정독해 함수별 파라미터의 쓰임새를 정확히 이해해야 할 것 같았다.