2020.12.11(금) 회의록

2020.12.11 (금) 회의록

의제

1. 공동 가계부 유형을 분리하는 것은 어떤가?

• 우리의 서비스가 '공동'이 메인이기 때문에, 가계부 유형에 대한 방향성을 논의해보자.

• 현재는 한 명만 관리자고 나머지는 일반 구성원인 공동 가계부

• '구성원 전부가 관리자가 돼서 관리하는 공동 가계부' 컨셉을 추가하는 것은 어떨까?

• 넣었을 때 장점은 무엇이 있는가? 마감이 일주일 남은 시점에서 도입해야만 하는 것일까?

  • 가계부를 더욱 다양하게 활용할 수 있어 풍부한 사용자층을 확보할 수 있다.

    • 현재 서비스의 경우, 특정 조직의 예산 담당자(경리, 총무 등)가 가계부를 전체적으로 관리하고 구성원들이 가계부 관리에 기여할 수 있는 형태이다.
    • 하지만 위 기능을 추가했을 경우, 모든 구성원들이 관리자 권한을 갖게 되어 다 같이 카테고리/결제수단/구성원을 관리할 수 있다. 이렇게 되면 커플통장을 관리하는 연인, 공동 가계부를 작성하는 가족 등 더욱 다양한 사용자층을 확보할 수 있을 것이다.
    • 현재 권한의 구분을 '비로그인 유저', '로그인한 일반회원', '로그인한 관리자' 세 개로 구분하고 있는데, 이 구분을 변경할 필요없이 '로그인한 일반회원'이 사용할 수 있는 기능을 조금 더 풀어놓으면 될 뿐이라 엄청나게 시간이 들 것 같지도 않다.

안건에 대한 의견 및 결론

• 가계부의 일반 유저에게 권한을 더 부여하자
• 일반 유저는 카테고리 관리, 결제수단 관리, 유저검색, 추가 기능을 사용할 수 있다.
• 가계부 관리자는 추가적으로 관리자 권한 위임, 유저 추방 기능을 사용할 수 있다.

2. 로그인 여부를 검증하는 hoc, 어떻게 관리할 것인가?

현재 매 페이지 접속시 로그인 여부 및 페이지에 대한 권한을 검증하는 API를 호출한 다. 검증에 통과할 경우, 페이지에서 필요한 API를 호출하고 페이지 렌더링이 이루어진다. 근데 로그인 및 권한을 검증하는 API가 DB 조회를 2회 하므로, 페이지 렌더링이 완료되는 데까지 0.15초 정도의 지연시간이 생긴다.

꼭 로그인 여부 및 권한 검증을 매 페이지에서 해줘야 하는 걸까? 불필요한 API호출이라고 생각된다.

안건에 대한 의견 및 결론

불필요한 API 호출인 것으로 결론났다. 각 페이지 컴포넌트를 감싸고 있는 hoc에서 호출하고 있는 API를 없애주고, mobx에서 상태값으로 권한을 관리하자.

• 로그인한 이후 /로 들어왔을 때, 해당 유저가 가지고 있는 accountbook 상태를 갱신한다.

• 갱신된 accountbook 상태에서 각 accountbook에 대한 권한을 user store에서 관리한다.

• 이후 user store에 있는 권한 상태를 사용하여 특정 가계부에 대한 접근을 FE에서 제어한다. 그렇게 되면 매 페이지에 접근할 때 로그인 여부 및 권한 검증을 위해 호출하는 2번의 API는 더이상 호출하지 않아도 된다.

• 위 방식을 선택하기 위해서는 현재 구현되어 있는 userStore에서 관리할 상태값을 변경해줘야 한다.

  • 현재 방식

  constructor(rootStore: RootStore) {
      makeObservable(this);
      this.userId = null;
      this.provider = '';
      this.nickname = '';
      this.profileUrl = '';
      this.isAdmin = null;
      this.rootStore = rootStore;
  }
  

  isAdmin 상태값은 매 페이지를 갈 때마다 갱신해줬다. 즉, 단일 페이지에 대한 권한이다.

  • 추후 변경할 방식

   constructor(rootStore: RootStore) {
       makeObservable(this);
       this.userId = null;
       this.provider = '';
       this.nickname = '';
       this.profileUrl = '';
       this.isAdmin = {};
       this.rootStore = rootStore;
   }
  

  이제는 객체 형태로 각 가계부에 대한 권한을 관리한다. 로그인 이후, 가계부 선택페이지로 이동 후 accountbookStore에서 관리하는 상태값을 갱신하고, userStore.isAdmin은 다음과 유사한 형태로 갱신된다.

  userStore.isAdmin = {
      1: true,
      2: false,
      3: false,
      4: false,
  }
  

  • 여기서 key는 가계부의 고유 식별 번호이고, value는 해당 가계부에 대한 권한이다. 참고로 true는 관리자, false는 일반 유저, null은 로그인하지 않은 유저이다.
  • 만약 해당 유저가 특정 url로 가계부에 접근했을 때, userStore.isAdmin의 key에 없는 가계부 식별 번호였다면 권한이 없는 페이지로 접근한 것이기 때문에 /로 손쉽게 리다이렉트 시킬 수 있다.

3. 가계부 관리 페이지 중 소셜탭에서 유저 검색 결과에 대한 후처리

• 가계부 관리 페이지 중 '소셜' 탭 내부에서 유저를 검색하면 검색 결과가 출력된다.
• 이후 다른 탭으로 이동했다가 '소셜' 탭을 들어오면 검색 결과가 그대로 남아있는 것을 발견했다.
• 출력 결과를 남겨두는 것이 괜찮을까, 지우는 게 괜찮을까?

안건에 대한 의견 및 결론

• 가계부 관리 페이지 중 소셜 탭을 들어갈 때마다, useEffect에서 검색된 유저를 초기화 해주는 방식으로 해결하자.
• 주말에 민수님이 담당

4. 사파리/파이어폭스에서 svg나 달력 폼이 정상적으로 나오지 않는 문제

• 크롬에서는 정상적으로 출력되는 svg나 달력 폼이, 사파리와 파이어폭스에서는 정상적으로 나오지 않는 문제가 발견되었다.

안건에 대한 의견 및 결론

현실적으로 지금 다양한 웹 브라우저를 지원할 수 있도록 처리하는 것은 무리가 있다. README에 크롬으로만 가능하다고 명시를 해두는 것으로 결정했다.

5. 다음 주에 추가적으로 기능을 구현할 것인가, 유지보수에 힘을 쏟을 것인가?

• 우선 남아있는 필수 기능을 생각해보자. 그리고 각 기능을 할당해보자. 다음주 화요일까지 끝낸다는 마인드로 가자 🔥

  • sms 파싱 기능 (프론트)

    • 영근

  • sms 파싱 기능 (백)

    • 현우

  • 가계부 생성

    • 현우, 민수

  • 가계부 삭제

    • 일반유저

      • 민수

    • 관리자

      • 민수

  • 사이드바에서 가계부 교체

    • 병화

  • 가계부 리스트 페이지

    • 현우

  • csv export

    • 병화

  • 가계부 구성원 추가 로직 수정 (color, description 부분)

    • 민수

  • 문서 정리

    • README에 실행 방법 기재

      • 현우

    • SMS 회의록 정리

      • 현우

    • 12/11 회의록 정리

      • 현우

• 마스터클래스를 들은 이후, 생각해놨던 추가적인 기능은 거의 다 포기하기로 결정했다. 사실 위에 풀어 써보면서도 여기서 더 하는 건 무리라고 생각했다.

  • 데이터 fetch해오는 것을 swr을 활용하여 캐싱해두기 성공! 👍🏻
  • 거래내역 무한 스크롤
  • CSV import
  • 웹 소켓을 활용하여 실시간으로 데이터 렌더링해주기 성공! 👍🏻
  • Cypress E2E
  • 등등... 잘가 안녕...

보완해야 할 작업

• 달력 기능을 구현하지 않기로 결정. 그에 따라 accountbook 테이블 스키마 수정
  • start_day 제거
  • gmt 제거