앱 메인 개편 회고 - 2(퀵메뉴)

퀵메뉴 개편

 기존의 퀵메뉴는 하드코딩된 값들과 사용자별로 인기 카테고리들을 내려주고 있었다. 해당 항목을 수정하고, 유동적으로 내려주기 위해선 일단 먼저 DB 테이블에 저장하고 불러오는 기능이 필요했다. 이전엔 퀵메뉴 테이블이 존재하지 않았기에 테이블 설계부터 진행했다.

 

테이블 설계

 아래의 ERD는 실제 운영 DB의 ERD가 아닌 이해를 돕기 위해 임의로 작성한 테이블이다. column의 이름이 이상하거나, 없거나 실제 테이블의 데이터 형식과 차이가 있다. ERD 작성은 quickDBD를 이용했다.(https://app.quickdatabasediagrams.com/)

menu

퀵메뉴 정보를 저장하기 위한 테이블이다.

menu_seq	기본키로 사용할 값이다.
order	퀵메뉴에 나타낼 순서를 뜻한다.
name	퀵메뉴의 이름이다.
image	이미지 주소이다.
type	퀵메뉴의 타입이다. 나중에 설명하겠지만 인기 카테고리와 등록한 퀵메뉴와의 구분을 위해 추가했다. device, os, login_flag를 굳이 따로 두지 않고 type으로 두는게 더 좋았을까?라는 생각을 해봤지만 type수가 너무 많이 늘어나 비효율적일 것 같았다.
device	장치에 따른 노출 여부를 구분하기 위한 값이다.
os	ios와 aos의 차이에 따른 노출 여부를 구분하기 위한 값이다.
login_flag	로그인 여부에 따른 노출 여부를 구분하기 위한 값이다.
use_flag	사용여부이다.
start_date	노출 시작 시간이다.
end_date	노출 종료 시간이다.
reg_date	등록일이다.
update_date	수정일이다.

 

menu_link

퀵메뉴 링크를 저장하기 위한 테이블이다. 앱과 웹의 링크가 다르기 때문에 menu 테이블과 1:N 관계를 가진다.

link_seq	기본키로 사용할 값이다.
menu_seq	어떤 메뉴의 링크인지 지정하기 위한 외래키이다.
url	링크 주소이다.
type	링크 타입이다. 앱과 웹의 링크를 다르게 설정하기 위해 존재한다.
use_flag	사용여부이다.
reg_date	등록일이다.
update_date	수정일이다.

 

menu_history

퀵메뉴 변경 이력을 저장하기 위한 테이블이다.

history_seq	기본키로 사용할 값이다.
history	이력을 남긴 데이터들이다.
reg_date	등록일이다. 이력은 수정되기 않기에 update_date가 존재하지 않는다.

 

메인화면에 전달하기

 테이블 설계가 끝났으니 메인 화면에서 퀵메뉴를 불러오는 부분을 작업했다. 조회한 데이터를 가공해서 전달하기까지의 과정을 정리하면 다음과 같다.

1. 먼저 사용여부가 true인 항목들을 찾아 order에 따라 정렬해서 조회한다.
2. 조회한 데이터들이 현재 시간이 노출 기간에 포함되는지 확인한다.
3. 포함된 데이터들 중 인기 카테고리 항목이 있다면 외부 api를 호출하여 데이터를 채워 넣는다.
4. 내용을 담아 전달한다.

다른 건 모두 손쉽게 구현할 수 있었지만 3번 항목은 어떻게 구현할 것인가에 대한 고민이 필요했다. 고민 결과 인기 카테고리 type을 가진 빈 row들을 등록하고 해당 항목들을 원하는 순서로 설정한 뒤 서비스 로직에서 채워 넣기로 했다. type이 인기 카테고리인 항목이 존재한다면 외부 api 호출을 통해 3위까지 조회한 뒤, 반복문을 통해 인기 카테고리인 항목이면 순위 순서대로 채워 넣는 방식으로 구현했다.

 

백오피스 개발하기...가 더 어려운데?

 퀵메뉴를 유동적으로 관리하기 위해 DB 테이블을 생성하고 조회 로직까지 수정했으니 등록, 수정 삭제 기능을 추가할 차례였다. 백오피스에 단순히 CRUD 기능들을 추가하는 건 정말 간단했는데 프론트 개발에서 사용자 편의를 위해 많은 요청이 있었다. 메뉴 등록, 수정까지는 당연한 기능이기에 무난하게 작업했고 그리 오랜 기간이 걸리지 않았다.

 문제는 순서 변경과 사용 여부 수정이였다. 조회 페이지에서 순서 변경을 누르면 드래그 앤 드롭으로 순서가 변경되게 하고, 사용여부를 해당 페이지에서 수정할 수 있게 하며, 항목을 미사용으로 수정하면 해당 페이지의 사용 항목 밑으로 자동적으로 보내달라는 요청들이 있었다. 해당 항목들은 이런저런 시도들을 해보며 열심히 작업해서 결국 성공적으로 기능을 구현했다. 이후 수정이력도 볼 수 있게 해 달라는 요청이 있어 menu_history 테이블을 만들어 이력을 남길 수 있게 작업했다. 지금 생각해 보면 단순히 이력만을 쌓는 테이블이면 DocDB 같은 NoSQL DB에 데이터를 저장하고 조회해서 사용하는 게 더 좋았을 것 같다는 생각이 든다.

 작업에 소요된 시간을 생각하면 서비스 로직 30% 관리자 페이지 70%의 비율인 것 같다. 작업할 당시에는 몰랐는데, 이후 들어보니 이런 요청들은 공수가 너무 많이 들어 거절하고 있었다고 했다. 어쩐지 요구사항에 해당하는 기존에 작업된 페이지가 존재하지 않았다. 어쩌다보니 공수가 많이 들어 개발하긴 힘들지만 사용자의 편의성이 많이 개선된 페이지를 만들게 되었다.

 이후 비슷한 요청이 들어올 때마다 모두들 내가 만든 페이지를 참고했다. 그 때마다 느끼는 심정은 뿌듯하다기 보단 너무 부끄러웠다. 프론트엔드에 대해 잘 알지도 못하고 기능만 돌아가게 만든 코드를 누군가 보고 참가한다는 게 마음에 들지 않았다. 그래서 언젠가 기회가 된다면 프론트엔드 부분도 좀 더 공부해서 충분히 이해하고 구현하고 싶다는 생각을 가지게 되었다. 개발은 하나의 영역을 깊이 아는 것도 중요하지만 전체적인 흐름을 파악하는 것도 중요하다고 생각하기에 프론트엔드 공부는 나에게 많은 도움이 될 것 같다.