2020.11.22(일) 회의록

2020.11.22 (일) 회의록

의제

1. 가계부 선택 페이지 중, 가계부 컴포넌트 내부 우측 상단의 '삭제' 컴포넌트

• 현재까지 합의된 내용에는 해당 가계부의 삭제 버튼이 관리자에게만 보여야 할지, 아니면 모든 구성원들에게 보여야 할지 정해진 게 없었다.
• 해당 가계부의 관리자가 아닐 경우에도 ❌ 버튼이 보이게 하고, 해당 버튼을 누르면 가계부를 나가는 것으로 하는 것이 맞지 않을까?
• 가계부에 속한 유저들이 존재하지 않더라면 해당 가계부의 관리자가 가계부를 삭제해버려도 상관 없겠지만, 1명이라도 존재할 경우 공동으로 관리했던 것인데 바로 삭제하기보다는 관리자 또한 해당 가계부를 나가는 로직으로 해야하지 않을까?
• 그렇다면 관리자를 제외하고 가계부에 2명 이상 속해있을 경우를 대비하여, 해당 가계부의 관리자가 나가면서 다음 관리자를 지정해줘야 하진 않을까?
• 이 내용에 따르면, 관리자 설정 페이지에서도 '소셜' 탭에서 다른 유저에게 관리자를 넘길 수 있는 기능이 필요하지 않을까?

안건에 대한 의견 및 결론

• 우선, 삭제 기능을 아예 미뤄놓자.
• 시간이 남는다면 꼭! 본 기능을 구현하기. 소셜 기능이 정상적으로 구현되었다고 하려면, 본 안건은 구현해야 마땅하긴 하다.

2. 가계부 관리 페이지 중, 가계부 별칭, 지출/수입 카테고리 이름, 결제수단 이름 중복 검사

• 현재까지 합의된 내용에는 가계부 관리 페이지에서 설정 완료 버튼이 존재하지 않는다. 가계부 관리 페이지에서 가계부에 대한 내용을 수정한 다음 어떠한 방식으로 수정한 내용을 서버에 전달해야 할까?
• 우측 상단에 유저 프로필 컴포넌트를 제거하고 설정 완료 버튼 컴포넌트를 만들어주는 건 어떨까?
• 설정 완료 버튼 컴포넌트를 눌렀을 때 가계부 별칭의 중복검사가 이루어지게 할까, 아니면 그 이전에 별칭 검사를 클라이언트에서 처리한 후 버튼을 누르는 것으로 할까?

서버 쪽에 무리를 덜 주기 위해 클라이언트 쪽에서 먼저 중복 검사를 하기로 했다. 단, 실질적으로 DB 내용을 수정하는 API를 호출할 때에는 미들웨어에서 중복 검사를 한 번 더 실시하여 안정성을 도모한다.

• 사용자의 가계부 별칭 입력이 1초 이상 이루어지지 않으면, 해당 사용자가 속해있는 가계부의 이름들과 중복검사하여 사용자가 입력한 별칭을 사용할 수 있는지 체크해준다.
• 만약 별칭이 중복된다면, 입력창 내부 가장 오른쪽에 빨간색 경고 아이콘을 보여주며 입력창 하단에 '이미 존재하는 별칭입니다.'를 빨간색 글씨로 렌더링해준다.
• 만약 별칭이 중복되지 않는다면, 입력창 내부 가장 오른쪽에 초록색 체크 아이콘을 보여주며 입력창 하단에 '사용 가능한 별칭입니다.'를 검정색 글씨로 렌더링해준다.
• 중복 검사의 방식은?
  • 지출/수입 카테고리 이름, 결제수단 이름의 경우에는 생성을 시도하면서 백엔드 쪽에서 중복 검사하는게 나을 것 같고..
  • 가계부 별칭 중복 검사는 나름 실시간으로 되는 것이기 때문에 프론트에서 해도 괜찮을 듯 싶다.

안건에 대한 의견 및 결론

• 결론적으로, 가계부 별칭에 대한 중복검사는 하지 않는다. 하지만 중복된 가계부 별칭이 존재할 수 있으므로, 가계부를 표현해주는 컴포넌트에서 가계부 별칭 우측에 #1과 같은 넘버링을 해주도록 한다.
• 넘버링은 accountbook 테이블의 id 속성값을 활용한다. ex) '부스트캠프 가계부 #1'
• 지출/수입 카테고리 이름, 결제수단 이름에 대한 중복검사는 실시한다. 방식은 클라이언트에서 상태값을 활용하여 중복검사를 한다. 중복되었는지에 대한 여부를 표현하는 것은 위에서 언급했던 방식을 활용하도록 한다.

3. SMS/MMS 파싱 작업은 백엔드에서 할지, 프론트에서 할지?

• 백엔드에서 처리할 경우

  1. SMS/MMS 내용을 입력 후, '확인' 버튼을 눌러 SMS/MMS 내용을 서버에 전달한다.
  2. 서버에서 파싱한 이후, 파싱된 데이터를 JSON 형태로 클라이언트에게 응답한다.
  3. 클라이언트에서 받은 응답값을 각 입력 컴포넌트(금액, 카테고리, 계좌, 내용 등)에 알맞게 위치시킨다.
  4. 사용자는 올바르게 입력되었는지 재확인한 후, 수정해야 할 것들을 수정한 뒤 '완료' 버튼을 누른다.

• 프론트에서 처리할 경우

  1. 위 과정에서 1번 과정을 생략하고, 클라이언트에서 사용자가 입력한 입력값을 상태값으로 가지고 있는다. '확인' 버튼을 클릭했을 경우, 해당 상태값을 이용하여 클라이언트에서 파싱한다.
  2. 클라이언트에서 파싱 처리한 결과를 각 입력 컴포넌트(금액, 카테고리, 계좌, 내용 등)에 알맞게 위치시킨다.
  3. 사용자는 올바르게 입력되었는지 재확인한 후, 수정해야 할 것들을 수정한 뒤 '완료' 버튼을 누른다.

안건에 대한 의견 및 결론

• 핵심 비즈니스 로직이라고 볼 수는 없겠으나 분명 우리 서비스에서 중요한 기능 중 하나인 것은 틀림없다. 해당 기능을 클라이언트 쪽에 두는 것보다 서버 쪽에 숨겨 두는 것이 옳다고 본다.

4. 소셜 기능에서 구성원들을 초대하거나 추방하는 작업에 대한 알림 기능

안건에 대한 의견 및 결론

• 가계부 초대, 추방에 대한 알림 기능은 UX 차원에서 정말 좋은 아이디어이다. 하지만 이제 4주 밖에 남지 않은 상태에서 알림 기능을 넣게 되면 목업 디자인이나 기획서는 물론이고, 테이블 설계까지 다시 바뀌어야 하는 상황이라 우선 순위에서는 뒤로 미뤄둬야 하지 않을까 싶다.
• 우선은 카카오톡의 단체 대화방 느낌으로 초대되어도 별도의 알림 없이 바로 가계부가 생성되는 것으로 가기로 결정되었다.

5. 가계부 관리 페이지에서 가계부 내용을 수정하고자 설정 완료 버튼을 누른 후, 관리 페이지를 빠져 나가게 하는 것이 좋을까? 아니면 해당 페이지에 남아있는 것이 좋을까?

안건에 대한 의견 및 결론

• 관리 페이지에 남아있는 것으로 결정했다.
• 수정이 되었음을 알려주는 것은 어떠한 방식으로 해줘야 할지 미정. alert는 너무 허접해보이고, 그렇다고 다른 방식으로 깔끔하게 알려줄 방법이 마땅히 없는 것 같아 고민이 깊었다. 추후 이 페이지를 구현할 때 다시 의논해보기로 했다.

6. 가계부에 대한 설명과 색상은 각 구성원들이 따로 설정할 수 있어야 하지 않는가?

안건에 대한 의견 및 결론

• 그게 맞는 것 같긴 한데... 그렇게 되면 너무 많은 것들이 바뀌어야 한다.

• 어떤 것들이 바뀌어야 하는가?

  1. accountbook 테이블과 user_accountbook 테이블 속성 변경

     • user와 accountbook 테이블 간의 관계 테이블 user_account 테이블에서 color와 desc 속성을 넣어주기
     • accountbook 테이블에서 desc 속성과 color 속성을 없애주기
     • 위 두 개의 작업을 통해 accountbook의 기본 색상과 기본 설명을 없애고, 관계테이블 내의 레코드에서 각 유저가 해당 가계부에 대한 색상과 설명을 어떻게 설정했는지 정보를 담고 있기

  2. 가계부에 새로운 구성원을 추가할 때 어떻게 처리해야 할지 논의

     • 특정 가계부와 유저 간의 관계테이블 user_accountbook 내에서 관리자에 대한 레코드가 가지고 있는 color와 desc를 새로 추가되는 유저에 대한 레코드에도 담기

     • 가령, 유저 test(id=1)가 가계부1(id=1)이라는 가계부를 만들었고 색상은 #ffffff, 설명은 가계부 설명이라고 저장했다. 그 결과, user_accountbook 테이블에는 다음과 같은 레코드가 저장된다.

       athority	color	desc	deleted_at	accountbook_id	user_id
       admin	#ffffff	가계부 설명	false	1	1

     • 거기서 유저 test가 stranger(id=2)라는 유저를 가계부1에 초대할 경우, user_account 테이블에는 다음과 같은 레코드가 추가된다.

       athority	color	desc	deleted_at	accountbook_id	user_id
       member	#ffffff	가계부 설명	false	1	2

• 생각은 여기서 그쳤지만, 더 고려해야 할 것들이 많을 것 같다. 우선은 기존에 설계한 방식대로 가자.

보완해야 할 작업

• 가계부 관리 페이지에서 카테고리 생성 모달, 결제수단 생성 모달 목업 디자인 만들기
• 카테고리, 결제수단 중복검사하는 목업 디자인 만들기
• 위 목업 디자인을 기획서에 반영
• 기획서에 새로운 장표가 추가되어 기획서 슬라이드의 번호가 바뀌었기 때문에, 기획서 내에 n페이지 참고 혹은 n페이지로 이동 등의 내용에서 n을 수정해주기
• 기획서 중 '가계부 관리 페이지 - 가계부 설정 - 가계부 색상 설정(7p)'에서 preview에 (기본)이라는 글자를 빼기