•
초기 예상보다 그룹과 채팅방간의 의존도가 높음
◦
특정 수업에서 발생한 이벤트 구독을 통한 채팅 푸시, 수업 현황 조회 등
◦
실무에서 보통 하나의 채팅방 = 사실상 하나의 주요 그룹 형태로 동작하는 빈도가 훨씬 많음
◦
기존 계획했던, 하나의 채팅방에 여러 그룹을 추가할 수 있도록 했을 때 알림 등의 기능 구현 복잡도가 상당히 높아짐.
•
“하나의 ChatRoom”에는 하나의 Group(수업)만 연결 처리하는 방향
◦
채팅방 간에 정보 공유가 목적이라면, statement 의 공유 범위를 local / subject / global 로 구분하여 여러 그룹에서 정보를 공유할 수 있도록 하는 것이 사용자 입장에서도 직관적이고 유지 보수가 용이함
◦
어떠한 그룹과도 연관되지 않은 채팅방 개설 가능함.
◦
Group 하나에는 다수의 ChatRoom 연결 가능
◦
Group 기준 채팅방과 1:1 구조 + statement scope 으로 할 경우 시나리오 예시
▪
진저 선생님이 안나 학생을 오전에는 수학 /오후에는 영어를 가르친다.
▪
이 경우 A 그룹과 A'채팅방 과 B 그룹과 B'채팅방을 만든다.
▪
A' 채팅방과 B'채팅방 에서의 local 정보는 공유하지 않고, 과목도 다르기에 subject 정보를 공유하지 않지만, global 정보는 공유된다.
•
한 그룹 내에서 두가지 수업을 하기 위한 목적으로 개설 금지. → 그룹을 나눠서 수업하도록 강제
•
한 학생에 대한 그룹별 1:1 채팅방은 1개씩만 존재 가능하다.
◦
ex. A 학생 - b그룹 - 1:1 채팅방 / A 학생 - c그룹 - 1:1 채팅방 …
◦
이런식으로 그룹별로 1:1 채팅방은 2개가 될 수 없다.
•
수업 생성 및 수업 인원 변경시 수동으로 [특정 선생님 : 특정 학생]을 선택해 채팅방 생성은 불가능하다.
•
특정 선생님 / 학생 선택해서 채팅방 생성은 그룹을 통하지 않았을 때만 가능함
•
5월 개발 목표에 N:N 채팅방 생성은 포함되지 않음
◦
다양한 이슈 고려했을 때, N:N 채팅방은 N:1 채팅방은 다르게 구현되어야 함.
1. 채팅
니즈 / 목표 / 주요 사용자
1-1. 선생님이 새 채팅방(N:1)을 생성한다
1-2. 그룹을 삭제한다
1-3. 수업 참여자가 변동되어, 채팅방 참여자를 변경한다
1-4. 채팅방 제목을 변경한다
1-5. 새 메시지가 오는 경우 알림을 확인한다
1-6. 읽지 않은 메시지가 몇 개인지 확인한다
1-7. 메시지를 생성한다
1-8. 메시지를 삭제한다
1-9. 메시지를 수정한다
부가 기능
1-10. 한 사람이 보낸 메시지를 상대방들이 읽었는지 확인한다 / 마지막으로 읽은 메시지 위치를 확인한다
1-11. 특정 메시지를 태그 후 답장한다
1-12. 예약 메시지를 보낸다
1-13. 학생에게 받은 사진/파일을 일괄 확인 및 다운로드 한다
1-14. 대화 화면을 캡쳐 후 학부모에게 공유한다
1-15. 대화 내용을 검색한다
1-16. 채팅방 내에 공지를 띄운다
1-17. 리액션 기능
1-18. 동시 발송 기능(전달 기능 like)
2. 모니터링
•
일반 이슈 : 선생님이 채팅방 접근시 경고 표시 해제
•
AI 이슈 : 선생님이 채팅방 접근 후 별도 “이슈 해결됨” 버튼 클릭시 경고 표시 해제
니즈 / 목표 / 주요 사용자
2-1. ‘대시보드’에서 학생 카드(그룹/학생 단위)를 확인한다
2-2. ‘채팅 목록’에서 활성화된 채팅방(채팅방 단위)을 확인한다
2-3. 채팅 대응 우선순위가 높은 학생을 확인한다
2-4. AI와 대화중 이슈가 발생해 개입이 필요한 학생을 확인한다
2-5. 도움이 필요한 학생을 발견했다면 빠르게 채팅방으로 접근한다
2-6. 개입을 위해 대화 컨텍스트를 빠르게 파악한다
3. AI Agent
니즈 / 목표 / 주요 사용자
3-1. 선생님이 채팅방별로 AI를 어떻게 사용할지 설정한다
3-2. AI 대화 중 이슈 발생 시, 선생님이 중지/재개한다
[부록] 우선순위 계산 표(조건별 점수, 정렬 정책) 정리 필요
•
기준 1 : 채팅 상태
◦
메시지 확인 후 미답장 / 메시지 미확인 && 2분 초과 / 미출석 / 학습 시간 초과 / 종료 필요 / 안읽은 메시지 / 미포함 상태 / 수업 시간 전 or 관리 종료 or 결석 or 수업이 아닌 경우
◦
cf) 미포함 상태는 수업중이지만, 어떠한 상태에도 포함되지 않는 상태
◦
동일 상태에서의 정렬은 기준2를 통해 정렬
•
기준 2 : 채팅 우선순위에 해당하는 채널 중에서는 마지막 메시지의 전송 시간
◦
메시지 발신자/수신자 상관없이 시간 오름차순 (오래된 메시지가 위로)
◦
안읽음 순의 기준과 동일
•
기준 3 : 채팅 우선순위에 해당하지 않는 채널중에서는 시간 내림차순
◦
참고) 세션 상태는 우선순위에 영향을 주지 않습니다.
•
고려사항
◦
예전 채팅 베타 테스트
▪
테스트 인원 24명
▪
채팅방을 띄워 놓았을 때 미리보기가 필요하다.
▪
모든 채팅이 다 안보여서 불안하다. → 여러 화면을 띄워놓기 위한 수요
◦
미접속, 미출석 태그 유용했다.
▪
열공중 태그가 유효했다.
◦
답변 필요 태그 → 선생님이 생각하는 우선순위 반영이 필요하다. 테스트시 좀 다른 점이 있었다.
▪
학생은 단순히 “네” 라고 답변해서 안읽씹했는데, 시스템에서는 단순히 답장을 안했 답변 필요라고 었음
◦
B2C 채팅창과 학습화면간의 이동에서의 불편함
▪
문제가 바로 보여지지면 유용할 것 같다.
▪
LMS를 굳이 보지 않고, 문제를 볼 수 있으면 좋겠다.
◦
학생 이름에 대한 biff 텍스트를 고려하면 좋을 것 같다. ex {학생 이름}
◦
첨부파일 전송시 드래그앤 드롭 혹은 복사 단축키로 이미지 첨부가 가능했으면 한다.
◦
수업이 늦어지는 학생
▪
수업의 시작과 끝을 명시할 수 있는게 드러나는게 필요하다.
•
아예 시스템 메시지가 발송되어도 되지 않을까? (남은 수업 n분, 수업을 시작할 시간입니다 )
◦
메모가 바로 보여지면 좋겠다.
◦
수업 시간을 같이 확인하고 바꾸면 좋겠다.
◦
세션 상태 보여지는건 유효했음
▪
모니터링 화면과 소통이 분리되어 있음 → 소통쪽에서 이걸 해결하면, 기존 모니터링 화면은 그다지 불필요하지 않을까?
◦
기존 정책에서는 수업이 아닌 경우에는 우선순위가 낮음
▪
오늘 수업을 할 경우 → 오늘 수업 한다는 상태로 돌려서 대응 우선순위 높이는 처리 필요
◦
우선순위에 따라 배경색이 변경되면 좋을 것 같다.
•
이벤트 기반 설계와 / 이벤트 기반 설계가 아닌 방식
◦
이벤트 기반
▪
펍섭 방식
▪
모놀로지
◦
ex. 그룹을 삭제하면 채팅방의 상태가 비활성화 된다.
▪
전통적 코딩
•
그룹 삭제 함수 호출
◦
그룹 삭제시, 특정 채팅방을 찾고 그 상태를 바꾼다.
▪
다른 방식
•
그룹은 삭제했다는 이벤트를 발생시킨다.
◦
이벤트를 구독하는 애가 채팅과 관련된 애에게 이벤트를 전달한다.
▪
그룹과 별개로 채팅방을 비활성화하는 이벤트가 동작한다.
▪
개발자 → 그룹을 삭제했을 때 해야 하는 행동
•
채팅방을 비활성화 만 하는게 아님
•
그룹 안에 들어있는 ~~를 하는 행동들이 여러가지 있음
•
그룹 삭제와 관련되어 다양한 행동이 있음
•
→ 이로인해서 너무 많은 영역의 일들을 개발자가 이해하고 있어야 함.
•
그래서 각자 도메인에서 신경써야하는 일을 분리한다.
•
퍼블리시를 하는 곳에서는 구독하는 곳에서 일어나야 하는 일들은 신경쓰지 않아도 된다.
▪
하지만 펍섭 방식이 항상 올바른게 아니다.
•
하나의 코드 안에서 트랜젝션을 해야 하는 경우와, 분리해야하는 경우가 있다.
•
분리를 했을 때 단점이 있다.
◦
그룹 삭제에서 이슈가 생기면, 채팅방이 비활성화
•
성공, 실패 상태에 대한 정책 관리가
▪
그룹 삭제시 행동들이 한 곳에 몰려 있다.
•
펍섭 방식은 가려져 있기 때문에, 다른쪽에서 어떤 정책을 가지고 있는지 모른다.
•
이벤트가 변경되었을 때, 문제가 발생할 수 있다.
◦
그래서 분리했을 때 →
•
커서 →
◦
인공지능 채팅 - 인터페이스 구조
▪
선생님이 AI 에게 무언가를 시킬 수도 있음을 염두에 두고 설계를 해야 한다.
▪
1차 범위에도
•
어플리케이션