5️⃣ 5주차 멘토링 일지

✔️ 체크리스트

마지막 멘토링에서는 우리 팀의 최종 상황을 점검하고, 이후 리팩토링과 최종 발표를 위한 피드백을 받습니다.

6주차에는 추가 기능을 개발한다기 보다는, 이번주까지 마무리한 것들에 대해 테스트/리팩토링 하며 완성도를 올리는 기간이 되어야 합니다.

아래 체크리스트에 응답하며 우리 팀의 객관적인 상황을 파악해보세요.

사용자가 서비스를 사용할 수 있는 수준으로 주요 기능이 개발되었다.
GitHub 저장소만 봐도 프로젝트 개요, 기술적 도전, 구현 과정을 누구나 알 수 있다.
나와 우리 팀의 기술적인 자랑거리나 강점이 무엇인지 그 이유와 함께 설명할 수 있다.

→ 피드백 기반 점진적 개발이 강점인 것 같습니다.
6주차에 리팩토링 또는 개선할 영역에 대한 계획이 있다.
- 리팩토링
- 개선 영역에 대한 계획

✔️ 결론 및 To Do

멘토링 이후 결론과 챙길 것을 정리하여 업데이트합니다.

✔️ 멘토링 아젠다

멘토링 24시간 전에 준비하여 멘토에게 공유합니다.

논의 사항 및 질문

멘토의 조언이 필요한 부분을 질문으로 정리합니다.

메인 리드미를 어떤식으로 정리하는게 좋을까요?
- 줄줄이 TMI 다 적기 vs. 핵심 경험별로 2~3줄만 딱 적고 Wiki로 링크 걸어두기
리드미의 목적? → persona를 정의하고 해당 persona가 이룰 목표를 만들기

항목별 분량? → 세일즈 한다고 생각해보기 (특정 persona는 어떤걸 궁금해할까?)

⇒ 인기많은 오픈소스 리드미를 참고해보기

https://github.com/twentyhq/twenty
리팩터링 기준??
- 어떤 기준으로 리팩터링을 시행해야 하고 / 어떻게 리팩터링을 평가할 수 있을까
_좋은 코드에 대한 학습이 되어야 보임_ _→ n번 반복, 함수 길이, 불편함을 느낀 지점 …_ _→ 특이한 방법을 도입해도 좋음 (다른 사람보고 해당 코드의 흐름을 설명하라고 해보기)_

_⇒ AI의 도움을 받는 것도 좋습니다. (방향성에 대한 도움 받기) - cursor, coderabbit …_
지금 워크스페이스: 게스트 초대 로직이 괜찮은지 검토 부탁드립니다.

A. 워크스페이스 종류, 역할(Role) 종류
- 역할(Role)
  - (1) 소유자인 owner (workspace 삭제, 게스트 초대 기능)
  - (2) 초대받은 사람인 guest (workspace 안 문서, edge, node등 편집, 삭제, 생성 가능)
  → 이렇게 두가지 role만 만들어놓고
- workspace 자체는
  - (1) public (모두에게 공개)
  - (2) private (자신 + 초대받은 guest들에게만 공개)
B. private workspace에서 owner가 guest를 초대하는 로직
1. 워크스페이스 소유자가 링크 만들기 ⇒ 암호화된 링크 생성
2. 해당 링크로 초대받은 사람이 접근
3. 서버에서 해당 링크 검증
4. DB에 초대받은 사람 Guest로 Role 업데이트
5. ~~초대받은 사람 JWT Token에 Role 업데이트 → 그래서 해당 사람 workspace 접근할 때 DB 참조 안하고 바로 허가 내리게~~
→ 5번 부분이 변수가 많음, Token은 회수가 안됨

→ 상태를 Role DB에서 서버가 update하면서 킵해두는 상태, 일단 JWT는 인증에만 사용할것

→ 알림 구현 없이 (너무 작업량이 많을 것 같아) 워크스페이스에 또다른 사용자를 초대하는 기능을 만드려고 일단 이렇게 로직을 짜놨는데 괜찮은가요?

사용자 입장에서 자연스러운 흐름인지, 보안성이 괜찮은지 검토 부탁드립니다

개인적으로는 보안성이 살짝 부족하다고 생각해 해당 링크의 유효시간을 줄이거나 / 한 링크 당 한명만 초대가 가능하게 하거나 / N명을 동시에 초대할 수 있는 링크를 만들거나 → 이 세가지 방안을 생각해봤습니다

→_ robot.txt → 미공개 url_

_→ 누구나 접근할 수 있는데 url만 노출된 상태 → 굳이 url 유효시간 필요 없을듯??_
현재는 guest가 해당 워크스페이스안의 문서, edge, node들을 모두 편집가능하지만 편집은 안되고 보기만 가능한 role도 하나 추가하고 싶은데, 이걸 FE + BE에서 어떻게 편집을 막아야할지 감이 안잡힙니다…. - 권한을 FE에서 확인하면 쉬운데, 그게 안전한 방식인지 모르겠습니다.

https://www.okta.com/kr/identity-101/role-based-access-control-vs-attribute-based-access-control/
소켓 통합 테스트를 하는 게 좋을까요…?

→ 이거는 예전에 서비스 계층으로 테스트 하라고 하셨던 것 같기도 합니다..
redis를 postgres 데이터베이스와 함께 두는 것이 좋을까요?

현재 데이터베이스 용 서버에 postgres를 배포한 상황이고 api 서버용 서버에 nest를 배포한 상황입니다.

여기서 redis를 도입하여 데이터베이스 쿼리 수를 줄이려고 하는데 postgres와 같은 서버에 둘 지 아니면 api 서버와 같은 서버에 둘 지 고민이 됩니다.

이전에 메모리와 cpu를 효율적으로 사용하려면 api 서버와 데이터베이스를 같은 서버에 두는 게 좋다고 말씀하셨던 것 같은데 api 서버와 redis를 같은 서버에 두는 게 좋을 지 안정성을 위해 postgres와 함께 두는 게 좋을지 궁금합니다.

_→ 메모리 버전 sqlite 사용해보기 (메모리 적게 먹음), 메모리 데이터베이스는 WAS와 함께 두는 것이 좋을 듯, 캐싱을 sqlite로 사용하면 응답이 빨라짐_
one more thing…? 어떤 피드백이라도 달게 받겠습니다
- 헉 화이팅만 해주셔도 됩니다

진행상황 및 참고 자료

멘토가 일지를 보고 멘토링을 준비할 수 있도록, 팀의 진행상황과 참고 자료를 정리해서 넣어주세요.

https://github.com/boostcampwm-2024/web15-OctoDocs

현재 진행도

에픽	FE 진행도	BE 진행도
1. 노트 CRUD	100%	100%
2. 연관 관계 보여주기	100%	100%
3. 실시간 편집	100%	100%
4. 추가 기능	20%	20%
4-1. 개인 워크스페이스	20%	30%
4-2. 최적화	10%	50%
4-3. 연결된 노드 시각화	0%	0%
4-4. 검색	0%	0%
5. 배포	-	-10% ㅜㅜㅠㅠ

이번 주 예상

에픽	FE 진행도	BE 진행도
1. 노트 CRUD	100%	100%
2. 연관 관계 보여주기	100%	100%
3. 실시간 편집	100%	100%
4. 추가 기능	70%	70%
4-1. 개인 워크스페이스	100%	100%
4-2. 최적화	50%	90%
4-3. 연결된 노드 시각화	100%	100%
4-4. 검색	0%	0%
5. 배포	-	100%