Today I Learned

날짜

2023년 12월 18일 월요

내용

• 데모 어드민 페이지 만들기

  지난 주에 했던 회고대로, 데모로 설정할 어드멘 계정을 환경변수로 설정할 이유가 없었다. 슈퍼관리자 페이지에 데모 계정을 설정 하는 기능을 만들고자 하였다. 그런데 내가 생각을 너무 얕게 했었다. 이 기능은 결국 DB에 현재 누가 데모 계정인지를 저장해야 한다. 이에 따라 두가지 방법이 떠올랐다.

  1. 데모 계정을 표시하는 새로운 테이블을 생성한다.
  2. 기존 계정(혹은 샵)이 저장된 테이블에 데모임을 표시하는 새로운 Column을 추가한다.

  두 경우 모두 일이 생각보다 많이 커질 것 같았다.. 데모 계정 하나를 등록하자고 새로운 테이블을 만드는 것도 비효율적이라고 생각했고, 기존에 존재하는 Table을 수정하는 것은 더 최악으로 느껴졌다. 괜히 내가 잘 할 자신이 없어서 겁 먹은 건지, 진짜 이 방법들이 효용성이 떨어지는 지 확인받았다.

  내려진 결론은

  1. 데모 계정을 바꾸는 경우는 거의 없다. 있어도 매우 드물다.
  2. 사용 빈도가 낮을 뿐더러, 개발하기 위한 시간 소모가 크다.

  였다.

  하지만 기존 환경 변수를 건드리는 로직은 분명히 수정할 필요가 있었기 떄문에, 그냥 백엔드 코드에 설정하는 것을 선택했다. 그냥 계정 정보와 shop의 unique ID만 입력하기 떄문에 보안과도 거리가 멀다.

• 메일 발송 활성화 토글

  기존에 Notification Email은 3가지로 분류되었는데, 이 중 Verification Email 기능만 잠시 제거된 상태였다. 해당 기능의 On/Off 기능을 추가할 것. 그리고 Notification Email에 포함되는 3가지 기능 모두 Off 설정 시 모달창을 띄워서, 현재 발송 예정 상태인 메일들에 대한 처리를 User에게 물어볼 것. 따라서 Off 일 떄만 모달창을 띄우고, 현재 발송 예정 상태인 메일들의 갯수를 출력시켜 주었다. 유저의 선택에 따라 해당 레코드들을 삭제해주는 기능도 추가했다.

  뭔가 많이 놓치고 있다는 생각이 들어서, 전체적인 로직을 점검하던 중 다음과 같은 질문을 만들었다.

  1. use_email, use_sns 등 각 방식의 사용 여부에 대한 칼럼이 있는데 use_setting_type_detail는 왜 있을까?
  2. notification_email의 발송을 처리하는 함수에서 기존에 sending_status를 검증하지 않았던 이유는 무엇일까? On/Off가 따로 없어서 무조건 발송해도 상관 없던 것일까?
  3. Verification emaill은 아예 on/off 기능이 없던걸까? 그럼 나머지 2개는 있는데 얘만 없던 이유는 무엇일까? 원래 로직은 어땠을까?
  4. 현재 messaging_log에서 삭제하는 로직을 구현했는데, CHANNEL_OFF로 바꿔주는 것이 맞을까? 다시 살려야 하는 로직도 필요할까?

  빨리 갈피를 잡아야겠다.

회고

자꾸 내가 생각이 너무 얕다는 걸 느끼고 있다. 조금만 더 차근차근 심도있게 고민해야함.

---

---