앱 메인 개편 회고 - 마무리(관심 카테고리)

관심 카테고리

앱 메인 화면에 관심 카테고리에 따른 관심 상품 목록이 추가되었다. 따라서 관심 카테고리를 등록 및 수정 할 수 있는 기능을 만들게 되었는데 해당 기능은 단순 CRUD였기에 구현에 별다른 어려움은 없었다. 하지만 지금 생각해보면 DB 설계에 살짝의 아쉬움이 남는다. 자세한 내용은 하단에서 설명하겠다.

 

테이블 설계

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

user와 category 테이블은 예상할 수 있듯이 사용자와 기존의 카테고리 정보들을 저장한 테이블이다. 

---

interest_category

사용자의 관심 카테고리를 저장하기 위한 테이블이다.

category_seq	카테고리 테이블의 기본키이다. 카테고리 테이블과 1:N 관계를 가지며 다중 기본키(PK)값 중 하나이다. 사용자의 관심 카테고리 정보를 나타낸다.
user_seq	사용자 테이블의 기본키이다. 사용자 테이블과 1:N 관계를 가지며 다중 기본키(PK)값 중 하나이다. 관심 카테고리를 저장한 사용자 정보를 나타낸다.
order	사용자가 설정한 관심 카테고리의 순서이다.
reg_date	등록일이다. 등록일만 존재하는 이유는 사용자가 수정할 때 DELETE를 통해 삭제처리 되기 때문이다.

 

interest_category_sub

최초의 테이블 설계에서 생각했던 테이블이다.

interest_seq	기본키로 사용할 값이다.
user_seq	사용자 정보를 저장하기 위한 외래키이다.
categories	사용자의 관심 카테고리를 저장하는 항목이다. 데이터는 리스트 형태로 저장되며 순서와 항목을 한 번에 모두 저장할 수 있다.
reg_date	등록일이다.
update_date	수정일이다.

설계 당시의 생각

 정말 별거 없지만 많은 고민을 했다. 당시의 내 생각은 단순히 user와 1:1 관계를 가지고 관심 카테고리 목록을 저장하는 테이블이 더 낫다고 생각했다. 그 이유는 다음과 같다.

• 전달해주는 형식이 리스트였다.
• 전체 관심 카테고리 상품 목록을 미리 조회하고 전달해주는 부분이 있었는데, 상품 목록 조회시 호출되는 외부 api의 parameter가 리스트 형태였다.
• 순서를 따로 저장할 필요가 없다.
• 테이블 row수가 적다.

 물론 단점도 존재한다.

• 제 1 정규화를 만족시키지 못한다.(테이블의 컬럼이 원자값(Atomic Value, 하나의 값)을 갖도록 테이블을 분해하는 것)
• 각 카테고리마다 항목이 추가되어야 할 때 적용이 불가능하다.
• 각 카테고리 항목을 따로 조회해서 사용할 수 없다.

충분한 근거가 있다면 의견을 말해보자

 위의 단점은 추후 관심 카테고리를 목록으로 사용하는게 아닌 따로 적용해야 할 일이 있을 때 생기는 문제들이었다. 하지만 단순히 사용자가 관심있는 카테고리를 저장하기 위해 사용될 것으로 보였기 때문에 큰 문제로 생각되지 않았고 최초 설계로도 충분하다고 생각했었다. 이때까지의 내용들로 보면 interest_category_sub 테이블이 적용됐을거 같은데 그렇지 못한 이유는 뭘까?

 그것은 팀장님의 의견과 달랐기 때문이다. 당시의 난 내가 설계한 테이블을 보여드리며 조언을 부탁드렸었다. 지금 생각해보면 단순히 테이블 설계에 대해서만 물을 게 아니라 파악한 로직에 대해 말하면서 테이블 설계에 대한 이유를 좀 더 잘 말했어야 했었다. 팀장님은 대략적인 내용은 아시지만, 내부 로직은 자세히 모르시기에 단순히 테이블 설계의 관점에서만 보셨다. 당연히 정규화가 잘 된 테이블 구조로 짜도록 하셨을 것이다. 당시의 나는 '나보다 더 잘 아시니까 이게 맞을거야'라고만 생각했었다. 그래서 별다른 의견을 말하지 않고 받아들인 뒤 로직을 작성했다. 

 

개발 내용은 개발하는 사람이 제일 잘 안다

 이후 개발을 하면서 테이블 설계에 정답은 없지만 최초의 설계가 좀 더 나았을 것 같다는 생각이 들었다. 하지만 다시 말하기에는 너무 늦은 상황이었다. 아무리 프로세스를 다 파악한 사람이라도 세부적인 로직까지는 파악할 수 없다. 그 부분은 개발하는 개발자가 제일 잘 알고 있고, 알고 있어야 한다. 당시의 난 분석하고 파악해서 설계까지 했기에 잘 알고 있었고, 잘 아는 만큼 좀 더 의견을 말했어야 했다. 그렇지 못했던 이유는 내 실력에 대한 자신이 없었고 실수할까봐 두려웠다. 작업을 마무리 하고 다시는 이러지 말자고 다짐했다. 다짐을 지키기 위해 노력했고 지금까지 많은 발전이 있었다.

자신감을 가지기 위해 공부했다

 Java와 spring에 대해 아는게 많지 않았고 비전공자였기에 cs 지식도 부족해 자신감이 없었다. 그래서 당장 필요한 spring boot에 관한 강의들을 들으며 열심히 공부했고, JPA를 사용하게 되어 JPA도 공부했다. 네트워크 공부를 간단히 한 이후 스터디에 들어가 Java의 정석을 통해 Java 언어에 대한 이해를 높였고 운영체제, 컴퓨터 구조까지 함께 공부했다. 지금은 데이터 베이스에 대한 지식을 채우기 위해 공부하고 있으며 지식이 늘어날수록 좀 더 내 생각에 자신이 생기는 것 같다.

질문 할 때 어떤 상황인지를 함께 말해준다

 질문을 할 때 내가 처한 상황도 함께 전달해서 답해주는 사람이 더 적절한 답변을 할 수 있게 한다. 예를 들어 "JPA에서 Entity 내부의 Entity 객체를 조회할 땐 어떻게 하나요?"보단 "interestCategory Entity내부의 Categories Entity를 생성자를 통해 조회하고 싶은데 어떻게 하나요?"라는 식으로 질문한다. 이렇게 하면 답변을 해주는 사람이 "생성자 조회보단 Setter를 통해서 주입하는게 더 좋아 어떻게 하냐면 ~"과 같은 상황에 맞는 답을 해줄 수 있게 된다.

실수는 아직도 두렵지만 맞서려고 노력한다

 사람은 완벽하지 않기에 실수를 한다. 실수를 하지 않기 위해 많은 노력을 하지만 나도 모르게 하게된다. 이럴땐 단순히 후회하기 보단 다시는 같은 실수를 하지 않게 피드백을 한다. 어떤게 잘못됐는지, 어떤걸 개선해야 하는지 분석을 통해 많은 것들을 배울 수 있다. 두려워만 하지 말고 좋은 경험치로 생각하려고 지금도 노력중이지만 잘 되지 않는다...

 

앱 메인 개편 전체 후기

 사실 작업한 내용이 이것들이 전부는 아니지만 나머지는 그리 중요한 내용은 아니라 생략했다. 개발하면서 했던 기술적인 고민이나 느낀점은 앞서 다 말한것 같다. 앱의 메인페이지를 개발하면서 내가 작업한 항목이 눈에 보이는게 좋았고, 눈에 띄게 개선된 사항들이 보여서 사용자 경험이 꽤 좋아진 것 같았다. 개발하면서 힘든 점도 있었지만 그것보다 느끼는 재미가 더 컸기 때문에 일하는게 즐거웠다. 이 때 영한님의 Spring MVC 강의를 집에서 들으며 공부했는데 실제 개발할 때 유용하게 쓸 수 있는 지식들이 있어 많은 도움이 되었다. 현재는 문서 정리 후 인수인계를 통해 다른 팀 담당이 되었다. 문서 정리 과정에서 되돌아보니 후회되는 부분과 아쉬운 부분이 정말 많았고, 보여주기 부끄러운 코드들도 있었다. 덕분에 이해하기 쉬운 코드, 효율적인 코드를 작성할 수 있도록 좀 더 노력하게 된 것 같다.