타 대학 확장안 & 모의지원 대비

[whqtker]

사용자 별로 출신(국내) 대학 유지

국내 대학에 대한 테이블인 DB에 있습니다(home_university). 그러나 site_user 가 이를 참고하는 키가 없습니다.

일반적으로 하나의 사용자가 하나의 출신 대학을 가지므로, 단순히 FK를 참조하도록 합니다.

학교 인증

학교 이메일로 인증하거나, 마이페이지에서 별도로 인증하거나, 성적, 지원 과정에서 연계해서 인증하는 방법이 있습니다.

교환닷컴에서는 학교 이메일로 인증하는 방식을 선택했다고 합니다.

만약 이메일 인증 방식을 택한다면, site_user에 출신 학교 FK, 인증 여부, 인증 시점을 저장하거나, 아예 별도 인증 관련 테이블로 분리하는 방법이 있습니다. 어떻게 할 지.

학교 이메일이 인증 시에만 사용된다면 굳이 DB에 저장할 필요는 없을 거 같습니다. 아니면 그래도 저장할지, 현 이메일 회원가입을 학교 이메일로만 제한할지(단, 학교 이메일로 회원가입하지 않은 사용자에 대한 별도 처리 필요).

학교와 학교 도메인을 어떻게 관리할지. 테이블로 관리하거나 enum으로 ? 저는 테이블이 좋아 보입니다. 한 학교가 여러 학교 도메인을 가질 수도 있습니다.

현재 존재하는 회원에 대하여 출신 학교를 어떻게 수집할지.

학교 이메일 인증을 코드를 입력하거나, 링크를 눌러 인증하는 방식 중 어느 것으로 할지. 후자같은 경우 인증 토큰을 발행하고, 링크를 눌렀을 때 토큰을 비교하는 방식으로. 저는 후자가 구현 측면에서 간편할 거 같아 좋아 보입니다. 근데 전자의 이점이 없어 보이는데 전자 방식이 있는 경우는 뭘까요 ... 또한 이메일 전송 시간 제한을 두는 게 좋아 보입니다.

university_info_for_apply 테이블 컬럼 관련

현재는 인하대 교환학생 파견 학교 관련 정보들로 컬럼을 구성하고 있습니다. 그러나 타 대학에서 인하대에서 제공하지 않는 의미있는 정보를 제공할 수 있습니다.

JSON 컬럼 괜찮은데, 기존 데이터를 잘 마이그레이션해야 하고, 정합성 챙기지 못하는데 개인적으론 좀 걸립니다. 뭔가뭔가 두 마리 토끼를 다 잡을 수 있는 좋은 방법이 있을까요 ...??

지원 대학 정보 어드민 기능 생성

지원 대학 정보를 삽입하는 어드민 기능이 있어야 합니다. 다만, university_info_for_apply 테이블 컬럼 관련 논의가 완료된 후 진행되어야 할 것 같습니다.

멘토 카드에서 아티클 보여지도록

2개 보여지고, 멘토 상세 페이지 들어가면 다 보이도록

여기서는 다 보이도록

여기서는 최대 2개만 보이도록

=> API를 분리해야 할지

출신 대학(협정 대학)을 어떻게 전달할 것인지

• 별도의 API를 만들기 ?
• JWT 클레임에 담아서 (추천)

소속 학교 커뮤니티 사용가능 -> 권한 부여를 어떻게 할 수 있을 지
인증 여부 저장시 대학만 저장 or (대학, 인증 여부)로 저장

대학만 저장시 인증 여부 판단시 값이 있으면 인증됨, null이면 미인증으로 간단히 판별 가능

(대학, 인증 여부)로 저장할 시, 대학 등록 인증 여부 false인 약한 인증과, 인증 여부 true인 강한 인증으로 분리 가능

이 경우 소속 학교를 등록은 했지만, 제대로 인증되지 않은 <약한 인증> 상태에서 에타의 새내기게시판처럼 제한된 권한 부여 가능
즉 기획에서 나올 수 있는 다양한 시나리오에 대처할 수 있는 확장성? 이 늘어남

멘티 -> 멘토 승격은 5번만 가능

이건 본인이 몇 번 신청했는지 관리하면 될 듯 합니다.

초기 채팅 이미지 전송 시 기본 이미지 보임

-> 웹 쪽 문제로 보임

[sukangpunch]

제 의견 다음과 같습니다.

1. 사용자별 출신(국내) 대학 유지
   의견: site_user 엔티티에 home_university_id(nullable = true) 필드를 추가 하는 것이 좋을 것 같습니다.
   이유: 단일 학교로부터 교환학생 지원이 사실상 고정.

2. 학교 인증
   의견: 학교 이메일 인증 방식으로 구현, 교환 닷컴 방식을 그대로 활용
   이유: 이미 사용되고 있는 방식 재활용이 가장 효율적이라 판단.

3. university_info_for_apply 테이블 컬럼 관련
   의견: JSON 컬럼을 추가해서 대학별 추가 정보만 JSON 으로 관리, 필수 정보는 고정
   이유: 해당 기능을 위한 추가 테이블은 비용이 크다고 판단. JSON 필드로 유연하게 대처 가능
   - 대신 학교 별 JSON 규격도 강제화가 되어야 할 듯 함.

4. 지원 대학 정보 어드민 기능
   의견: 표준 필드(공통) + 추가 필드(JSON, 대학별 차이) 구조로 설계, 대학별 템플릿을 정해놓고 운영자가 값만 입력할 수 있도록
   이유: 3번과 동일 마찬가지로 대학별 템플릿 강제화 관리를 어떻게 해야 할지는 논의

5. 멘토 카드에서 아티클 보여지도록
   의견:

   • 멘토 입장: 멘토 마이페이지 프로필 조회(/mentor/my api) + 멘토 아티클 조회(전체) api
   • 멘티 입장: 멘토 마이페이지 프로필 조회 + 아티클 2개 조회 (/mentor/profile-card api )
     이유: 현재 멘토 프로플 수정 페이지에선, 멘토 프로필 정보 + author_id 기반 멘토 news 조회 api로 분리가 되어있습니다. 그대로 활용 가능하면 좋을 것 같고, 멘티 입장에서는 여러 멘토를 조회 할 수 있고, 이를 카드로 확인해야 하는데 한 멘토당 2개의 api 호출을 하게 되는 것은 네트워크 낭비라 생각이 되어 새로운 api에 멘토 아티클 2개를 포함하는 편이 좋을 듯 합니다.

6. 출신 대학(협정 대학)을 어떻게 전달할 것인지.
   의견: 별도의 api를 만드는 것에 복잡도가 너무 커보여서 jwt 클레임기반이 좋을 듯 합니다.

7. 멘티 → 멘토 승격은 5번만 가능
   의견: site_user에 mentorApply(or Promotion)Count 컬럼을 추가. 혹은 MentorApplication 개수 확인(정합성 의존도 존재 하지만 편리함). 일단 MentorApplication 개수로 판단하는게 편해보이긴 합니다.

[Hexeong]

1. 사용자 별로 출신(국내) 대학 유지

• 단순 FK 참조 방식으로 해결에 동의합니다. 기존 회원의 데이터에 대해서도 null 값으로 시작한 다음, 학교 인증 이후 채워지는 방식을 사용하면 문제 없이 마이그레이션이 가능할 것 같습니다.

2. 학교 인증 처리 관련

2-1. 인증 수단과 인증 확인 방식

• 이메일 인증 코드 발송과 링크 접속 인증 방식 둘다 너무 좋은 것 같습니다.
• 하지만 조사 결과 링크 접속 인증 방식에서 토큰을 구현하는 것은 기존 RedisService를 활용하면 구현이 간단하나, 저희가 현재 IOS 앱 또한 배포를 고려중이기에 앱 개발하시는 분께서는 딥링크를 사용해 처리해야 한다고 해서 앱 개발자분과도 상의를 하면 좋을 것 같습니다.

2-2 학교 이메일 저장 여부

• 말씀하신 대로 학교 이메일 인증시에만 사용되면 실제 기능 구현할 때는 DB에 저장할 필요는 없어보이긴 합니다.
• 하지만 대부분의 서비스에서 본인이 언제 인증을 했는지와 인증 만료 기간을 제공하는 측면에서 저는 인증 이력을 관리하는 방식이 좋아보인다고 생각합니다. 또한 보안과 관련된 부분이기에 이력을 남기는 게 후일 도움이 될 수 있을 것이라고 생각합니다.
• 다만 걱정이 되는 부분은 학부 이메일 주소가 1개가 아닐수도 있다는 점이 걸립니다. 인하대학교만 하더라도 학번@inha.edu와 본인이_지정한_아이디@inha.edu로 1개의 계정에 2개의 이메일 주소가 바인딩 되는 경우가 있어서 만약 이력을 관리하는 테이블이 있다고 했을 때 site_user와 어떻게 매핑시켜야 할지 애매하네요... 이부분에 대해서도 기획에서 얘기가 끝난 상태인지 궁금합니다.

2-3 학교 도메인 관리

• 말씀하신대로 저도 테이블 관리에 동의합니다. 단순 enum으로 관리하는 정책은 추후 변경시 다른 테이블의 컬럼과 데이터 정합성 문제를 일으킬 수도 있다는 생각이 드네요.. ㅎㅎ

2-4 기존 회원에 대한 출신 학교를 어떻게 수집할지

• 이해하기로는 코드 인증 방식과 링크 접속 방식 모두 특정 기간 동안 활성되는 비밀값을 통해 인증하는 방식이 될 것 같습니다.
• 때문에 코드 인증 방식도 랜덤 비밀값을, 링크 접속 방식도 url의 쿼리 파라미터로 비밀값을 넘겨 인증하는 방식이 될 것이라고 생각해서 둘의 차이는 별로 없어보이긴 합니다. 실제로 타서비스들은 전송한 이메일 본문에 2가지 방식 모두를 제공하는 경우도 많이 있던 걸로 압니다.
• 그래서 결론은 웹/앱 개발하시는 분들의 편의에 맞춰 제공하는 게 좋을 것 같습니다. 학교 인증 워크플로우를 처리하는 과정에서 웹/앱 두분 모두 편한 방식으로 제공하는게 좋을 것 같다는 생각입니다.

3. university_info_for_apply

• 저도 형준님 의견에 동의합니다.
• 시스템 기능 제공을 위한 필수 정보는 테이블의 컬럼으로 제공하되, 추가 정보와 같은 경우 JSON 칼럼을 활용하면 좋을 것 같습니다.
• 이 방식으로 하면 1차로 필수 정보를 마이그레이션해서 서비스를 중단시키지 않게 하고, 서비스하는 와중에 추가 정보 입력 기능이 반영되어도 어색함이 없을 것 같습니다.
• 정합성을 챙기는 부분에 있어서는 해당 컬럼이 단순 조회가 아닌 특정 기능 제공에 사용되는 경우 테이블 컬럼으로써 변환하는 방식이 좋아보입니다.
• 만약 JSON 필드에 조건을 걸어 조회해야 하는 방식이면 가상 컬럼(Virtual Column) + B-Tree 인덱스가 가장 정석적인 방법이 될 수 있을 것 같습니다. JSON 내부의 특정 키(Key)를 추출하는 가상 컬럼(Generated Column)을 만들고, 그 가상 컬럼에 인덱스를 거는 방식입니다. (일반적으로 mysql의 JSON 타입에는 직접 B-Tree 인덱스를 못 거는 것으로 알고 있습니다.)

4. 지원 대학 정보 어드민 기능

• 이 방식은 위의 논의가 적용되면 추가 의견을 진행하면 좋을 것 같습니다.

5. 멘토 카드에서 아티클 보여지도록

• API 분리가 가장 깔끔해보이긴 합니다.
• 대신 분리를 요약 API와 추가 정보 API로 분리해서 둘을 따로따로 요청할 수 있는 구조면 좋을 것 같습니다.
• 세부 페이지에서는 요약 API와 추가 정보 API를 둘 다 호출해서 각각 바인딩 하면 유지보수하는 과정에서 중복 제공되는 측면이 없다보니 편할 것 같습니다.

6. 출신대학을 어떻게 전달할 것인가?

• 지금 JWT 토큰 + Redis BlackList를 제공하는 과정에서 JWT 클레임에 homeUniversityId를 담는 방식이 자연스러울 것 같긴 합니다. 하지만 학교 변경/재인증시에는 토큰 재발급 로직이 반영되어야 할 것 같다는 추가 작업 사항이 있어야 할 것 같습니다.

7. 멘티 -> 멘토 승격은 5번만 가능

• 형준님이 주신 의견 정말 좋은 것 같습니다. MentorApplication 데이터가 삭제될 일이 없다면 count 쿼리를 날리는 방식은 데이터 정합성 유지에 가장 좋은 방법이 될 수 있을 거라 생각이 드네요.

[whqtker]

학교 인증 만료
학교 이메일 변경 가능한 학교가 있음 -> 학교 이메일 저장하자 ?
인증 시 사용한 이메일 전부 관리(한 학교 당 복수 이메일, 편입 등)
인증 안 된 사용자는 팝업으로 인증해야 서비스 이용할 수 있도록
univforinfo : 필수 정보는 각각 컬럼으로, 나머지는 JSON 컬럼으로