Team

🗃️ Github

GitHub - echo1241/echo

GitHub - echo1241/echo-web

📽️ 시연 영상

https://youtu.be/L4MEjR3aq1w

https://youtu.be/09nnVIYdOkc

🗒️ 발표 자료

Echo.pdf

final echo.pdf


1. 프로젝트


2. 기획 관련 메모

1차 스코프


2차 스코프

3. WBS & Tasks


🏝️ Ground Rules

🕑 **회의**
1. 10:00 - 11:00
2. 14:00 - 14:30
3. 20:30 - 21:00

🍚 식사 시간	 
  - 점심시간 : 12:00 ~ 14:00
  - 저녁시간 : 18:00 ~ 20:00
* 위 시간 내에서 한 시간 내로 먹고오기! *

1. 회의할 때 마이크랑 캠 꼭 키기! 
2. 계획표 잘 작성하기(당일 오전 9시에 작성)
3. 적극적으로 의견 내기
4. 진행상황 자주 공유하기
5. 튜터님에게 자주 찾아가기
6. 10분 이상 없을 때는 슬랙에 남기기(댓글로 복귀까지 꼭 표시)
7. ZEP에 자기 상태 표시하기(잠깐 비울 땐 자리비움 / 식사시간 땐 휴식중)
8. 슬랙은 관련된 내용은 댓글로만 

🚩 Goals

구현 완료 및 배포

🏝️ 주요 일정

1. `07/19 (금) 자정`까지 : S.A 제출
2. `07/23 (화) 21시까지` : S.A 서면 피드백 
3. `08/02 (금) 11시 까지`  : 중간 발표회 자료 제출
4. `08/05 (월) 오후 2:00` : 중간 발표회
    - 팀 MVP, 기술적 의사결정 & 트러블 슈팅 발표 후 튜터님 피드백 진행
5. `08/06 (화)` 코드 감상회
6. `08/07 (수) ~ 08/16 (금)` : 중간발표 피드백 개선 + 유저 피드백 받아보는 기간
7. `08/21 (수)` : 최종 발표회
    - 발표회는 박람회 형식으로 온라인으로 진행
8. `09/06 (금)`: 수료식

🕑 회의

1. 10:00 - 11:00
2. 14:00 - 14:30
3. 20:30 - 21:00

🚦 Project Rules

Code Convention

Github Rules

KPT 회고

📢 SA 서면피드백

[기획 및 설계]
- WebFlux, RSocket, WebRTC, Kafka, MSA .... 등등 고민 정말 많으셨습니다.
  - 23일 튜터링 시간에 정한 것 처럼 중간발표회 전까지는 WebFlux, WebRTC 기반으로 핵심 기능 구현 완료를 목표로 달립시다!!!
  - Kafka, 멀티모듈 구조 등에 고도화는 그 이후에 도전!!
- UseCase 다이어그램, 테스트 시나리오, 사용자 시나리오 작성하신 거 확인했습니다!!! 진심 최고!!
  - 전날 말씀드린건데 이렇게 바로 작성해주시고 정말 훌륭하십니다.
  - 분명히 작성하시면서 Echo 서비스의 큰 흐름이 확실하게 정리되셨을 겁니다!! (정말 잘해주셨습니다!!!! 나중에 README에도 꼭 링크 달아주세요!)
- Git, Code Convention등 규칙들도 작성해주셨네요!!! 아주 좋습니다!!
- 추가로 나중에 README 작성하실 때 선택한 기술 버전 꼭 작성해주세요!! (선택 이유도 같이 작성되어있어도 좋을 것 같습니다)
- 저녁 튜터링 때 말씀드렸던 것 처럼 부리더님께서 애자일 방법론 프로세스 잘 정해주셔서 문서에 반영해주세요!!!
[API 명세]
- 전체적으로 URI 네이밍, 메서드 선택등 크게 문제 없이 잘 해주셨습니다.
- 구현 하시면서 API 수정이 계속 생길 가능성이 높습니다!(B.C. 채팅..WebRTC)
  - 반드시 변경 내용을 실시간으로 문서에 반영해주세요!
[스코프 및 역할분담]
- WebFlux, WebRTC라는 새로운 기술을 사용하시기 때문에 러닝커브를 고려했을 때 아주 적당합니다.
- 금일 튜터링 시간에 정한데로 진행 해주시면 될 것 같습니다! (화이팅!!)
[ERD]
- 현재는 아주 단순하게 ERD가 되어있네요. (몽고디비를 사용하게 된다면 추후에 ERD 작성을 새롭게 다시 그려주시면 좋을 것 같아요!)
- 채팅 기록을 어떻게 저장할지가 매우 어려운 부분인데 이부분은 참고하실 수 있도록 간단하게 정리해보겠습니다.
   - 채팅을 위한 설정 정보, 친구 목록(e.g. 디스코드 친구목록) 등의 관계가 명확하고 안정성이 중요한 데이터들은 RDB로 저장하시면 좋습니다.
   - 가장 중요한 채팅 이력은 결론 부터 말씀드리자면 key-value 형태의 저장소로 관리하는 것이 좋습니다.
     - 키벨류 형태의 저장소는 수평 확장이 쉽습니다. 특히나 채팅처럼 대용량 데이터를 관리해야할 때 효과적입니다.
     - 키벨류 형태의 저장소는 데이터 접근 지연시간이 낮기 때문에 채팅 처럼 데이터 접근이 빈번한 경우 효과적입니다.
     - 여러분들이 벤치마킹하고 있는 디스코드와 같은 경우에도 몽고디비를 사용하여 관리했었습니다.(현재는 성능 문제등의 이유로 다른 DB를 사용하고 있습니다.)
     - 디스코드 개발 블로그 링크입니다! 나중에 한번 읽어보시면 좋을 것 같아요! [<https://discord.com/blog/how-discord-stores-trillions-of-messages>]
- 추가로 채팅방에서 추가되는 미디어 같은 경우 이미지, 비디오 , 파일 이렇게 구분해주셨는데 우선 비디오, 파일은 제외하고 이미지만 먼저 저장될 수 있도록 구현하시는 것이 좋을 것 같습니다. 비디오, 파일은 추후에 빠르게 기능 구현이 끝난다면 그때 추가하는 것이 좋을 것 같아요! (그리고 실제 이미지는 S3를 사용해서 저장하고 해당 주소를 DB에 저장하는 쪽으로 고민해주시면 좋을 것 같아요.)
- 또한 채팅 메시지의 최대 크기도 지정하셔야합니다. (e.g. setMaxTextMessageBufferSize, setMaxBinaryMessageBufferSize, Client에서도 처리해주셔야해요 입력창에서)

📄 회의록

4. 와이어프레임

https://www.figma.com/embed?embed_host=notion&url=https%3A%2F%2Fwww.figma.com%2Fdesign%2FOkJgxStnmXQjR3vZNrm6Pu%2FUntitled%3Fnode-id%3D0-1%26t%3Daffyzm26DKMdvoCD-0

5. API 명세서

API 공통 prefix: /api

API 명세서

6. ERD DIAGRAM

Echo.png


7. USECASE DIAGRAM


Untitled

8. 시나리오


테스트 시나리오